One document matched: draft-tanaka-pce-stateful-pce-mbb-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3209 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml'>
<!ENTITY rfc4426 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4426.xml'>
<!ENTITY rfc4427 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4427.xml'>
<!ENTITY rfc5440 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml'>
<!ENTITY I-D.ietf-pce-stateful-pce PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-pce-05.xml'>
<!ENTITY I-D.crabbe-pce-stateful-pce-mpls-te PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crabbe-pce-stateful-pce-mpls-te.xml'>
<!ENTITY I-D.crabbe-pce-pce-initiated-lsp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crabbe-pce-pce-initiated-lsp.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-tanaka-pce-stateful-pce-mbb-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='yes'?>
<front>
<title abbrev="M-B-B procedure using Stateful PCE">
Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE
</title>
<author initials='Y.T' surname="Tanaka" fullname='Yosuke Tanaka'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>yosuke.tanaka@ntt.com</email>
</address>
</author>
<author initials='Y.K' surname="Kamite" fullname='Yuji Kamite'>
<organization abbrev="NTT Communications">
NTT Communications Corporation
</organization>
<address>
<postal>
<street>Granpark Tower</street>
<street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<code>108-8118</code>
<country>Japan</country>
</postal>
<email>y.kamite@ntt.com</email>
</address>
</author>
<date day="15" month="Jul" year="2013"/>
<abstract>
<t>
Stateful PCE (Path Computation Element) and its corresponding protocol extensions provide a mechanism that enables PCE to do stateful control of MPLS Traffic Engineering Label Switched Paths (TE LSP). Stateful PCE supports manipulating the existing LSP’s state and attributes (e.g., bandwidth and route) and also creating totally new LSPs in the network.
</t>
<t>
In the current MPLS TE network using RSVP-TE, LSPs are often controlled by “make-before-break (M-B-B)” signaling by headend for the purpose of LSP restoration and reoptimization. In most cases, it is an essential operation to reroute LSP traffic without any data disruption.
</t>
<t>
This document specifies the procedure of applying stateful PCE’s control to make-before-break RSVP-TE signaling. In this document, two types of restoration/reoptimization procedures are defined, implicit mode and explicit mode. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages, expected behavior of PCC as RSVP-TE headend and several extensions of additional PCEP objects.
<!-- [Xian:2013/04/01] specified extensions of additional "PCEP" objects-->
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
<xref target="I-D.ietf-pce-stateful-pce"/> describes the stateful Path Computation Elements(PCE). Stateful PCE defines the extensions to PCEP to enable stateful control of LSPs between and across PCEP sessions, and it also describes mechanisms to effect LSP state synchronization between PCCs and PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions.
</t>
<!-- [Xian:2013/04/01] Stateful => stateful which not at the beginning of a sentence -->
<t>
<!-- [Tanaka:2013/07/07] Comment out for I-D.crabbe-pce-stateful-pce-protection expiration
<xref target="I-D.crabbe-pce-stateful-pce-protection"/> describes the extensions for the setup and management of MPLS-TE LSP path protection by PCE. This specification is focused on the control of protection path, making protection paths which are pre-signaled ahead of the failure or set up after the failure. The proposed extension is beneficial for PCEs to place several active/standby LSPs for protection purposes in MPLS network.
[Ina:2013/02/28] act/standby to active standby --->
</t>
<t>
Today, however, there is no detailed procedure specified as to how to restore and reoptimize one particular MPLS-TE LSP using stateful PCE. In today’s MPLS RSVP-TE mechanism, make-before-break (M-B-B) is a widely common scheme supported by headend LER in order to assure no traffic disruption during restoration and reoptimization. Hence it is naturally desirable for stateful PCE to control M-B-B based signaling and forwarding process.
</t>
<t>
This document specifies the definite procedures of applying stateful PCE’s control to M-B-B method. In this document, two types of restoration/reoptimization procedures are defined, Implicit mode and explicit mode. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages, expected behavior of PCC as RSVP-TE headend and several extensions of additional objects.
</t>
</section>
<section title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC2119<xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
This document uses the following terms defined in <xref target="RFC5440"/>: PCC, PCE, PCEP Peer.
</t>
<t>
This document uses the following terms defined in <xref target="RFC3209"/>: make-before-break.
</t>
<t>
This document uses the following terms defined in <xref target="RFC4426"/> and <xref target="RFC4427"/>: recovery, protection, restoration.
</t>
<t>
According to their definition the term "recovery" is generically used to denote both protection and restoration; the specific terms "protection" and "restoration" are used only when differentiation is required. The subtle distinction between protection and restoration is made based on the resource allocation done during the recovery period. Hence the protection allocates LSP resource in advance of a failure, while the restoration allocates LSP after a failure occur.
</t>
<!-- <t>
This document uses the following terms defined in <xref target="I-D.ietf-pce-stateful-pce"/>: Stateful PCE, Delegation, LSP State Request, LSP Update Request.
</t>
<t>
This document uses the following terms defined in <xref target="I-D.crabbe-pce-stateful-pce-mpls-te"/>: LSP Identifiers TLV.
</t>
<t>
This document uses the following terms defined in <xref target="I-D.crabbe-pce-pce-initiated-lsp"/>: LSP Create Request message.
</t>
<t>
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF].
</t>
-->
</section>
<section title="Motivation">
<t>
As for current MPLS mechanism, make-before-break(M-B-B) concept is outlined in <xref target="RFC3209"/>, which allows adaptive and smooth RSVP-TE LSP rerouting that does not disrupt traffic or adversely impact network operations while rerouting is in progress. M-B-B is applicable for reoptimizing LSP’s route and resources for several use cases, for example, to adopt better path for reversion after failure, to change traversing node/links for planned maintenance, to change bandwidth of LSPs. M-B-B is also used for global restoration scenario in case of failure, which is effective if operators do not want to reserve both working and standby LSPs’ bandwidth in advance. In real deployment, it can also be operated with local protection scheme FRR (Fast ReRoute).
</t>
<t>
Since M-B-B operational scheme is universally common in MPLS network today, it is naturally much desirable to utilize it under the architecture of stateful PCE.
</t>
<t>
<!--To provide restoration TE LSPs in minimal data traffic disruption or reoptimized TE LSPs with no disruption, timing and sequence of data traffic switchover after signaling is to be treated. That is because each tunnel is able to have one or more TE LSPs (i.e., it is allowed to have multiple RSVP sessions with different LSP-IDs that share a common Tunnel IDs between a pair of edge nodes) but most ingress node transmits data traffic over only one (or some) of those LSPs. In short, the restoration procedure of Make-Before-Break is outlined as follows,e restoration -->
The basic procedure of the Make-Before-Break method is outlined as follows:<!-- [Ina:2013/02/28][Xian:2013/04/01] typos + "method" + ":" -->
<list style="empty">
<t>
<list style="numbers">
<t>Establish a new LSP</t>
<t>Transfer data traffic from old LSP onto the new LSP</t>
<t>Tear down the old LSP</t>
</list>
</t>
<t></t>
</list>
In M-B-B, it is an important behavior that headend node handles the sequence of data traffic switchover.
<!-- [Xian:2013/04/01] "treats" for more detail-->
The headend is able to “make” one or more new LSPs for a particular Tunnel (i.e., it is allowed to signal multiple RSVP sessions with different LSP-IDs that share a common Tunnel IDs), and the headend will switch the traffic upon only one (or some) of those LSPs. In some use cases about stateful PCE, it is expected that operators can watch and control when the data is switched over and which LSPs are used. Therefore, this document covers such a procedure and related message extensions.
<!-- Current proposals <xref target="I-D.ietf-pce-stateful-pce"/> and <xref target="I-D.crabbe-pce-stateful-pce-protection"/> do not cover such a process requiring data transfer consideration, and are not clear about signaling and teardown processes that PCC (ingress) is to take when receiving PCEP messages. Therefore this document presents those procedure and message extensions.
-->
</t>
</section>
<section title="Make-Before-Break LSP procedures">
<!-- // 既存の規定から追加する点
// 普通のとき，載せ替えするときのPCUpdの差は解説要
// Backward compatibility
// Becauseで書いている部分．
// WORDING : Restoration LSP / Protection LSP / Working LSP
-->
<!-- [Yimin:2013/02/23],[Ina:2013/03/01] suggested from "One Stroke" to "Implicit" and from "Granular" to "Explicit"-->
<t>
There are possibly two modes introduced for Make-Before-Break procedure under stateful PCE.
The first one is "implicit M-B-B mode", where the operation is triggered by a PC Update Request(PCUpd) message from a PCE, and a PCC handles whole Make-Before-Break steps (signaling and transferring data traffic) for itself. This mode utilizes the existing messages as defined in <xref target="I-D.ietf-pce-stateful-pce"/> <!-- [Yosuke:2013/06/30] and <xref target="I-D.crabbe-pce-stateful-pce-mpls-te"/>-->.
</t>
<t>
The second one is "explicit M-B-B mode", where the operation is triggered by a PCUpd <!-- [Yosuke:2013/06/30] LSP Create Request(PCCreate) --> message with TRIAL LSP TLV, which is defined in <xref target="TRIAL-LSP-TLV"/>. A PCE also controls timing and sequence of each granular step that a PCC takes. This procedure additionally uses a new extended TLV that is defined in <xref target="DATA-CONTROL-TLV"/>
</t>
<t>
Both types of procedure require at least two LSPs residing in a single MPLS-TE tunnel, working LSP and <!-- [Yosuke:2013/06/30] restoration to trial --> trial LSPs. An ingress node is currently transporting data traffic on the working LSP, and then it establishes one or more trial LSPs. As per <xref target="RFC3209"/> Section 2.5. "LSP ID" of a restoration LSP, which is newly signaled, differs from that of a working LSP.
<!-- [Xian:2013/04/01] typos "a" restoration LSP, "a working LSP"-->
In this document, LSP ID of a working LSP describes "old" and that of a trial LSP describes "new" as a simple example.
</t>
<t>
Implicit mode has high affinity with most existing MPLS edge node implementations which perform entire steps of M-B-B automatically at once. This mode is particularly applicable for migration scenario for the existing deployment where service providers want their recovery operation be delegated to centralized PCE.
</t>
<t>
Explicit mode is much more flexible than Implicit mode since it allows PCEs to manage each LSP step-by-step. Explicit mode is applicable to several new use cases that require split control of signaling and data switchover. For example, if end-to-end data path is created by connecting multiple individual LSPs across different segments (e.g., LSP stitching), in reoptimization scenario, data flowing cannot be started unless all signaling of all LSPs is completed.
<!-- [Ina:2013/02/28] all LSPs are => is -->
Similarly, there is a case under Software Defined Network (SDN) applications, where MPLS domain is connected to other non-MPLS domains, and the end-to-end data switchover timing should be carefully coordinated with various different methods of path/flow setup in each domain.
</t>
<t>
PCC and PCE can distinguish which mode, implicit mode or explicit mode, is to be performed by checking the type of PCEP messages that are exchanged. The implementation MAY support both modes, but for each restoration/reoptimization operation, either one of them SHOULD be exclusively selected.
</t>
<section title="Implicit Make-Before-Break Mode">
<!--
// Simple M-B-B, Single M-B-B, one storoke M-B-B
// need more detail. existing message, 普段とM-B-Bの時との差
// 現在の多くの実装ではそのまま使えること．
-->
<t>
This specifies the detailed procedure of M-B-B LSP restoration and reoptimization using exsisting messages which are defined in <xref target="I-D.ietf-pce-stateful-pce"/> <!-- and <xref target="I-D.crabbe-pce-stateful-pce-protection"/> -->.
This procedure is based on the current existing messages/TLVs and no extended TLV is used.
Once a PCC receives PCUpd message from a PCE, the PCC automatically executes the implicit M-B-B procedure as described in <xref target="I-D.ietf-pce-stateful-pce"/> Section 6.2.
<!-- [Ina:2013/04/01] Agreed with our suggestion, I-D.ietf-pce-stateful-pce has the description about implicit mode -->
</t>
<!-- // Restation LSPのLSP-IDを示すPCUpd -->
<t>
First, A PCUpd message is sent from a PCE to trigger M-B-B procecure. Once a PCC received the PCUpd message, the PCC starts signaling a new restoration LSP and it sends back to the PCE a PCRpt message with LSP-IDENTIFIERS TLV in the LSP Object.
<!-- This PCUpd message MUST carry a LSP Object with LSP Identifiers TLV. LSP Identifiers TLV format is specified in <xref target="I-D.crabbe-pce-stateful-pce-mpls-te"/>. This TLV contains the value for a desired new LSP ID. -->
</t>
<t>
<!-- If the specified LSP ID value is a non-zero and is not currently used by the exsisting RSVP-TE sessions about the corresponding tunnel owned by the PCC, that value MUST be used for next signaling by PCC as headend, i.e., “make” a new LSP for restoration. If the value is already used in the existing network in the specified tunnel, a PCC replies a PCEP Error message as defined in <xref target="I-D.ietf-pce-stateful-pce"/> with Error-type-19(Invalid Operation) and Error-Value=[TBD](Value already in use).
-->
</t>
<!-- [Tanaka:2013/04/15] Implicit の条件を明記すること Inaと合意したシーケンス
PLSP-ID は 0x0001 - 0xFFFF-1 で泳ぐ？
-->
<!-- <t>
_____________________________________________________________.
If the specified LSP ID value is zero, the PCC MUST automatically assign a new LSP ID to signal restoration LSP.
</t> -->
<!-- // SymbolicもLSPも特定が出来ない場合はPCError -->
<!-- <t>
A PCC replies PCEP Error message to a PCE if a PCUpd does not carry LSP Identifiers TLV nor SYMBOLIC-PATH-NAME TLV. Error-type-6(Mandatory Object Missing) and Error-Value=[TBD](See <xref target="ERROR-CODE"/>).
</t>-->
<!-- // LSP-ID が重複している場合はPCError -->
<!-- <t>
If LSP Identifiers TLV or SYMBOLIC-PATH-NAME TLV in a PCUpd message is specifying non-delegated LSP, the PCC sends PCErr as defined in <xref target="I-D.ietf-pce-stateful-pce"/>.
</t>-->
<!-- // Transfer data trafficのタイミング -->
<t>
Second, once a restoration LSP is successfully established, a PCC transfers data traffic from working LSP to restoration LSP.
<!-- TBRemoved: If the restoration LSP failed in setup, the PCC MAY retry RSVP-TE signaling with possibly different attributes. -->
If the restoration LSP failed in setup, the PCC notifies the PCE the result in a PCRpt message and it MAY wait for a next instruction from the PCE.<!--or retry signaling until some timeout will come.-->
<!-- [Yimin:2013/02/23] mentioned that PCC simply notify PCE and let it decide what to do next -->
</t>
<!-- // PCRpt出すタイミング , LSP identifiers TLV には-->
<t>
Finally, when a PCC successfully transfered data traffic to restoration LSP, the PCC tears down the (previous) working LSP by RSVP-TE signaling, then the PCC MUST send a PCRpt message. That PCRpt message MUST carry a LSP Object with LSP-IDENTIFIERS TLV which indicates the value of RSVP-TE signaling the PCC has just <!-- established [Tanaka:2013/07/07]-->torn down.
</t>
<t>
Following <xref target="implicit figure"/> illustrates the example of implicit M-B-B procedure, in following conditions.
<list style="hanging">
<t hangText="working LSP :">ERO=a-b, Tunnel ID=T1, LSP ID=old</t>
<t hangText="restoration LSP :">ERO=a-c-b, Tunnel ID=T1, LSP ID=new</t>
</list>
</t>
<figure title="Implicit Make-Before-Break Procedure" anchor="implicit figure">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| | |
| Data on old LSP =>)))))))))))))))))))))))|
| | : |
|--PCUpd(O=1, --> | : |
| Tunnel ID=T1, | |
| LSP ID=new, |---Path(ERO=a-c-b-, --> |
| ERO=a-c-b) | LSP ID new) |
| | |
| | <-----Resv-------------|
| <-- PCRpt(O=1, ----| |
| Tunnel ID=T1, | |
| LSP ID=new, | |
| RRO=a-c-b) | |
| | |
| | |
| Transfer data |))))))))))))))))))))))))|
| from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
| | : |
| |---PathTear(ERO=a-b, -> |
| | LSP ID old) |
| <-- PCRpt(O=0,R=1 -| |
| Tunnel ID=T1, | |
| LSP ID=old, | |
| RRO=a-b) | |
O flag = Operational flag in LSP object.
R flag = Remove flag in LSP object.
]]>
</artwork>
</figure>
</section>
<section title="Explicit Make-Before-Break Mode">
<!--
// Removeで削除とD-plane載せ替えが別なモチベーションは？
//
-->
<t>
Comparing to the implicit M-B-B mode, explicit M-B-B mode allows a PCE to control timing and sequence of subsequent make-before-break steps as follows.
</t>
<!-- [Ina:2013/02/28] Compareing => Comparing -->
<t>
First, the PCE initiates PCC's signaling of a new LSP by sending a LSP Update Request(PCUpd) message with TRIAL-LSP TLV that are defined in this document.
Second, the PCE instructs the PCC to transfer data traffic from old LSP to new LSP by sending a PCUpd message with TRIAL-LSP TLV and DATA-CONTROL TLV that are defined in [I-D.tanaka-pce-stateful-pce-data-ctrl].
Third, the PCE MAY instruct the PCC to tear down the old LSP by sending a PCUpd message indicating LSP removal.
</t>
<!--<t>
Note that this procedure uses not only PC Update Request(PCUpd) but also LSP Create Request(PCCreate) message that are defined in <xref target="I-D.crabbe-pce-pce-initiated-lsp"/>.
</t>-->
<t>
The following subsections specify each Make-Before-Break steps in detail.
</t>
<section title="Establish new Trial LSP">
<t>
As a first step of M-B-B procedure, a PCC establishes a new LSP for restoration once PCC receives a PCUpd message with TRIAL-LSP TLV from a PCE. We call this newly established LSPs for restoration "trial LSP". A trial LSP is signaled the same RSVP-TE Tunnel ID but different LSP ID from active working LSP, and both the active working LSP and new trial LSPs MUST be signaled with Shared Explicit style as describes in <xref target="RFC3209"/>.
<!-- [Yimin:2013/02/23] both the old and new lSPs are signaled with SE style to avoid double counting bandwitdth over common links during the signaling of the new LSP-->
TRIAL-LSP TLV triggers explicit mode M-B-B. A PCE do not have to assign RSVP-TE LSP ID for trial LSP signaling, however it MAY specify RSVP-TE LSP ID that the PCC is going to establish.
</t>
<!-- // new LSP-ID をつけたObjectをつける or SYMBOLIC-PATH-NAME TLVで特定
// SYMBOLIC-PATH-NAME TLV はPCCローカルと被ってはいけない！なぜ？ pce-initiated-lsp Page.8-->
<t>
<!--
<xref target="I-D.crabbe-pce-pce-initiated-lsp"/> defines that PCCreate message MUST contain LSPA object with SYMBOLIC-PATH-NAME TLV. Regarding SYMBOLIC-PATH-NAME TLV, <xref target="I-D.crabbe-pce-pce-initiated-lsp"/> describes that SYMBOLIC-PATH-NAME TLV is mandatory and that value must not have conflict with LSP name of any existing LSP in the PCC.
If this specification is applied directly, PCE has to allocate different symbolic path name for every signaling of “make” procedure. If conflict happens, it leads to PCEP Error from PCC.
(authors’ note: it needs further study about treatment of SYMBOLIC-PATH-NAME TLV particularly if there is a requirement for using the same symbolic path name for reoptimization and restoration.)
-->
</t>
<t>
When a new trial LSP was signaled successfully, the PCC sends a PCRpt message toward the PCE to notify the result.
<!--by setting Operational flag 1 in the LSP object.--> The PCRpt message from the PCC MUST have the LSP object with LSP-IDENTIFIERS TLV that indicates RSVP-TE Tunnel ID and LSP ID the PCC has just established.
</t>
<!-- LSP setup fail then PCRpt with RSVP ERROR SPEC TLV -->
<t>
If a new trial LSP failed to be established by some reason of RSVP-TE signaling, the PCC MUST send a PCRpt message carrying LSP-IDENTIFIERS TLV and RSVP-ERROR-SPEC TLV as defined in <xref target="I-D.ietf-pce-stateful-pce"/> Section 7.3.4. to the PCE.
</t>
<!-- Multiple trial lsp -->
<t>
A PCC SHOULD accept multiple PCUpd messages with TRIAL-LSP TLV in a LSP Object. And a PCC SHOULD establish as many trial lsps as the number of PCUpd messages it receives.
</t>
<t>
<xref target="establish new lsp"/> illustrates a example, working LSP(PLSP-ID P1,Tunnel ID T1, LSP-ID old, ERO Ingress-a-b-Egress), trial LSP(Tunnel ID T1, LSP-ID new, ERO Ingress-a-c-b-Egress).
</t>
<figure title="Establish new LSP" anchor="establish new lsp">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data traffic on old LSP |
| |))))))))))))))))))))))))|
|--PCUpd ------>| : |
| LSP Object | : |
| PLSP-ID=P1 | : |
| +TRIAL-LSP TLV | |
| LSP ID=0 | |
| ERO Obj=a-c-b |---Path(LSP ID=new, --> |
| | ERO=a-c-b) |
| | |
| | <----- Resv------------|
|<--PCRpt ---------| |
| LSP Object | : |
| PLSP-ID=1, |))))))))))))))))))))))))|
| tunnel ID=T1, | : |
| LSP ID=new, | : |
| RRO Obj=a-c-b | : |
| | |
]]>
</artwork>
</figure>
</section>
<section title="Switchover Data Traffic triggered by a PCUpd message">
<t>
As a second step, PCC(Ingress) transfers data traffic from a working LSP to a trial LSP. To specify desired LSP for transferring data traffic, a PCUpd message from a PCE MUST have a TRIAL-LSP TLV and a DATA-CONTROL TLV in a LSP Object.
<!-- [Ina:2013/02/28], [Xian:2013/04/01] typos "Contro" to "Control"-->
</t>
<!-- TRIAL-LSP, DATA-CONTROL TLVは1 LSP Object内に格納される -->
<t>
A TRIAL-LSP TLV specifies desired RSVP-TE LSP-ID a PCC starts useing for transferring data traffic. And a DATA-CONTROL TLV triggers data traffic switch over. Both TLVs MUST be assembled into a single LSP Object.
</t>
<t>
<!-- PCUpd carries the Data Control TLV, which is used for transferring data traffic from one LSP to another(See <xref target="DATA-CONTROL-TLV"/>). -->
<!-- ToBeRemoved : And PCUpd also carries a LSP Identifiers TLV to specify the Tunnel ID and LSP ID that data traffic will get onto.-->
<!-- [The same tunnel-id and different lsp-id]-->
<!-- PCUpd message MUST contain a set of new lsp object and old lsp object in a single message. Moreover, both new and old LSP Object have Data Control TLV in it. -->
<!-- [Yimin:2013/02/23] need to claarify whether this PCUpd is the old LSP's or new LSP's-->
</t>
<t>
Once the PCC receives the PCUpd message with TRIAL-LSP TLV and DATA-CONTROL TLV in the LSP Object, the PCC MSUT start transfer data traffic to new trial LSP immediately.(See <xref target="data transferring"/>)
</t>
<t>
In DATA-CONTROL TLV, Origin(O) bit, which represents traffic origin, SHOULD set to 1, Continue(C) bit SHOULD set to 0, and Percentage(P) bit SHOULD set to 100% in order to perform whole data traffic switchover.
</t>
<t>
If the TRIAL-LSP TLV in the PCUpd message specifies invalid LSP, PCErr MUST be sent out from the PCC to the PCE. The error message with Error-Type-19 (Invalid Operation) and Error-Value[TBD](See <xref target="ERROR-CODE"/>.
</t>
<!-- [Xian:2013/04/01] O bit in the figure for more detail in the text as well-->
<figure title="Transfer data traffic from old LSP to new LSP" anchor="data transferring">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| | |
| |))))))))))))))))))))))))| data on old LSP
|--PCUpd ------> |))))))))))))))))))))))))|
| LSP Object |}}}}}}}}}}}}}}}}}}}}}}}}| data on new LSP
| PLSP ID=P1 |}}}}}}}}}}}}}}}}}}}}}}}}|
| +TRIAL-LSP TLV | : |
| LSP-ID=new | : |
| +DATA-CTRL TLV | : |
| Origin=1, | : |
| Continue=0, | : |
| Percent=100 | : |
| | : |
| | : |
| <-- PCRpt --------| |
| LSP Object | |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=new, | |
| +DATA-CTRL TLV | |
| Origin=1, | |
| Continue=0, | : |
| Percent=100 | : |
| |--PathTear(ERO a-b, -->| Tear down old
| | Tunnel=T1,LSP ID=old) | automatically
| | |
| <-- PCRpt (R=1, ---| |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=old) | |
| | |
| | |
R flag = Remove flag in LSP object.
]]>
</artwork>
</figure>
</section>
<section title="Tear Down old LSP">
<!--
// PCUpd with R flagでした．MPLS-TE LSP全て消えてしまないように！
-->
<t>
As a final step of Make-Before-Break procedure, the PCC tears down the working LSP and the other trial lsps which the data traffic is no longer used.
</t>
<t>
The PCC SHOULD tear down the old working LSP and other trial LSPs immediately once the data traffic succesfully switched over (See <xref target="data transferring"/>). In OPTIONAL, a PCC tears down old lsp separately.
<!--
The PCUpd message MAY carry LSP Identifiers TLV specifing Tunnel ID and LSP ID that will be torn down in the LSP Object.(See <xref target="tear down lsp"/>).
Note that the PCC MUST tear down only the LSP that is specified in LSP Identifiers TLV.
-->
</t>
<t>
<!-- [Xian:2013/04/01] R flag bit set to "0" to be removed according to draft-ietf-pce-stateful-pce-03 -->
<!--_ mandate to tear down lsp automatically once the data traffic succesfully switched over. -->
<!-- [Yimin:2013/02/23],[Ina:2013/04/05] mandate to tear down lsp automatically once the data traffic succesfully switched over , Tanaka modified figure 3.-->
</t>
<!-- ToBeRemoved
<figure anchor="tear down lsp">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data on new LSP |
| |}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
| | : |
| |--PathTear(ERO a-b, ->| new LSP remains up
| | Tunnel=T1,LSP ID=old)| #[NEED TO MODIFY]
| | |
| | |
| <-- PCRpt(O=0, ---| |
| Tunnel ID=T1, | |
| LSP ID=old) | |
| | |
| | |
R flag = Remove flag in LSP object.
Figure 4: Tear down old LSP
]]>
</artwork>
</figure>
-->
</section>
</section>
</section>
<!--
<section title="PCEP extensions for Make-Before-Break Restoration procedure">
<t>
The PCEP objects defined in this document are compliant with the PCEP object format defined in <xref target="RFC5440"/> and <xref target="I-D.ietf-pce-stateful-pce"/>.
</t>
<section title="PC Update Request message for Implicit Make-Before-Break">
<t>
A PCUpd message that triggers One StrokeMake-Before-Break MUST carry LSP Identifiers TLV in the LSP Object(mandatory). And the PCC MUST establish new LSPs using the value which the PCEP objects(LSP Object, ERO Object, LSPA Object and another) are specifying as described in <xref target="RFC5440"/> and <xref target="I-D.ietf-pce-stateful-pce"/>.
</t>
</section>
<section title="PC Status Report message for Implicit Make-Before-Break">
<t>
A PCC send a PCRpt message for the feedback the Make-Before-Break result to the PCE.
A PCRep message MUST carry LSP Identifiers TLV in the LSP Object. And the PCC MUST reply PCRep including RSVP signaling attributes of the new LSP which the data traffic is going through.
<xref target="RFC5440"/> and <xref target="I-D.ietf-pce-stateful-pce"/> describe these specifications for more detail.
</t>
</section>
<section title="LSP Create message for Explicit Make-Before-Break">
<t>
The LSP Object and its LSP Identifiers TLV are mandatory for the LSP Create message in order to specify the LSP which the PCC will newly establish.
On the other hand, this procedure does not require SYMBOLIC-PATH-NAME TLV which <xref target="I-D.crabbe-pce-pce-initiated-lsp"/> describes the TLV is mandatory for PCCreate.
</t>
</section>
<section title="PC Update Request message for Explicit Make-Before-Break">
<t>
There are two usage of PCUpd messages for Explicit Make-Before-Break Procedure as follows.
<list style="hanging">
<t hangText="Transfer Data :">PCUpd messages MUST carry both LSP Identifiers TLV and DATA-CONTROL TLV in LSP Object. Data traffic(D) bit MUST be set to 1 in DATA-CONTROL TLV.</t>
<t hangText="Tear Down :">PCUpd messages MUST carry LSP Identifiers TLV in the LSP Object to specify the old LSP which the data traffic is no longer going through. Remove bit in LSP Object MUST set to 1 for removal message.</t>
</list>
</t>
</section>
<section title="PC Status Report message for Explicit Make-Before-Break">
<t>
<list style="hanging">
<t hangText="Response of Transferring Data :">PCRpt messages MUST carry both DATA-CONTROL TLV (D bit set to 1) and LSP Identifiers TLV specifying new LSP which the data traffic is going through in the LSP Object.</t>
<t hangText="Response of Tearing Down :">PCRpt messages MUST carry LSP Identifiers TLV specifying the LSP which the PCC tore down. Operational bit in LSP Object set to 0.</t>
</list>
</t>
</section>
</section>
-->
<section title="Objects and TLV Formats">
<section anchor="TRIAL-LSP-TLV" title="Trial LSP TLV in LSP Objects">
<t>
This document defines a new TLV named TRIAL-LSP TLV.
</t>
<figure title="TRIAL-LSP TLV format" anchor="format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be Zero | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
TRIAL-LSP TLV is sub-TLV of the LSP Object and is used in a PCUpd message especially to perform explicit mode M-B-B. A PCC signals a trial LSP once it receives a PCUpd in which LSP object has a TRIAL-LSP TLV(LSP-ID=0). It MUST set RSVP LSP-ID in LSP-ID field of TRIAL-LSP TLV in order to notify a PCC of desired trial LSP to be carried data traffic.
</t>
<t>
<list style="hanging">
<t hangText="LSP-ID: ">This field fills the same value of RSVP-TE LSP-ID that is used in signaling. LSP-ID MUST be zero in a PCUpd message when a PCE requests a PCC to signal new trial LSP. LSP-ID MUST be non-zero when a PCE sends a PCUpd message to trigger traffic switchover execution.
</t>
</list>
</t>
</section>
<!-- MERGED to draft-tanaka-pce-stateful-pce-data-ctrl へ移動 -->
<section anchor="DATA-CONTROL-TLV" title="DATA-CONTROL TLV in LSP Objects">
<t>
DATA-CONTROL TLV in LSP Objects follows for easy reference of [I-D.tanaka-pce-stateful-pce-data-ctrl].
</t>
<figure title="DATA-CONTROL TLV format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be Zero | Flags |O|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>Flags and fields
<list style="empty">
<t>
<list style="hanging">
<t hangText="O (traffic Origin – 1 bit): "> “traffic Origin(O) = 1” indicates this is an active LSP (i.e., carring traffic now) whose traffic is to be switched over or to be load-balanced. A PCE uses this bit to specify traffic origin that it wants to manipulate. On the other hand, A PCC uses this bit in PCRpt message to notify a PCE that switching traffic succeeded and carrying data traffic.
</t>
<t hangText="C (Continue - 1 bit): "> If this flag set to 1, it indicates the next LSP Object encoded in the PCUpd has also DATA-CONTROL TLV. If this flag set to 0, it indicates no more LSP Object continues and load balancing calculation is completed, and then the PCC MUST perform switching traffic or load-balancing.
</t>
<t hangText="Percentage - 8 bit [0B11111111 is reserved]: ">This field specifies ratio of switching traffic as an unsigned char. The sum of this field across subsequent LSP Object has to be hundred percent. The value must be less than or equal to 100%(0B01100100) (e.g., If you want to set 50%, this field should be set to 0B00110010). If no traffic goes through the corresponding LSP, this field should be set to 0%. 0% LSP MUST be deleted immediately after switchover. The special value 0B11111111 indicates traffic 0%, but the LSP MUST remain after switchover.
</t>
</list>
</t>
</list>
</t>
<!--
<section anchor="DATA-CONTROL-TLV" title="DATA-CONTROL TLV in LSP Objects">
<t>
This document defines a new TLV named DATA-CONTROL TLV.
</t>
<figure anchor="format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be Zero | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TRIAL-LSP TLV format
]]>
</artwork>
</figure>
<t>
LSP Identifiers TLV is mandatory in the LSP Object to use DATA-CONTROL TLV, which means DATA-CONTROL TLV requires the target to manipulate data plane.
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The value contains the following fields:
</t>
<t>Flags
<list style="empty">
<t>
<list style="hanging">
<t hangText="D (Data traffic - 1 bit):">Data traffic(D) bit indicates the Data traffic MUST get onto the LSP. PCUpd message for Explicit M-B-B mode uses this flag. If there are multiple LSPs in a single Tunnel, all data traffic will go through only the LSP that is specified by LSP Object which contains this TLV, and stop data traffic through the other LSPs. </t>
</list>
</t>
</list>
</t>
-->
</section>
</section>
<section title="IANA Considerations">
<section title="PCEP TLV Indicators">
<t>
This document defines the following new PCEP TLVs:
</t>
<figure>
<artwork><![CDATA[
Value Meaning Reference
TBD DATA-CONTROL This document
]]>
</artwork>
</figure>
</section>
<section anchor="ERROR-CODE" title="PCEP Error Objects">
<t>
This document defines new Error-Type and Error-Value for the following new error conditions:
</t>
<figure>
<artwork><![CDATA[
Error-Type Meaning
6 Mandatory Object missing
Error-value=TBD: LSP Identifiers TLV missing
19 Invalid operation
Error-value=TBD: Percentage is not hundred.
for explicit mode
Error-value=TBD: Specified LSP-ID is not existing.
for explicit mode
Error-value=TBD: Specified LSP-ID is not operational.
for explicit mode
]]>
</artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>
TBD
</t>
</section>
<section title="Acknowledgments">
<t>
Many thanks to Ina Minei, Adrian Farrel, Yimin Shen, Xian Zhang and their develop team for their ideas and feedback in documentation.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5440;
&I-D.ietf-pce-stateful-pce;
</references>
<references title="Informative References">
&rfc3209;
&rfc4426;
&rfc4427;
<!--&I-D.crabbe-pce-stateful-pce-mpls-te;-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:29:50 |