One document matched: draft-tanaka-pce-stateful-pce-mbb-00.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-02.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-stateful-pce-protection PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.crabbe-pce-stateful-pce-protection.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-00">
<?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="18" month="Feb" 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, one-stroke mode and granular 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>
</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>
<t>
<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 act/standby LSPs for protection purposes in MPLS network.
</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, one-stroke mode and granular 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 basicprocedure of Make-Before-Break is outlined as follows,
<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 treats the sequence of data traffic switchover. 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
-->
<t>
There are possibly two modes introduced for Make-Before-Break procedure under stateful PCE.
The first one is "one stroke 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"/> and <xref target="I-D.crabbe-pce-stateful-pce-mpls-te"/>.
</t>
<t>
The second one is "granular M-B-B mode", where the operation is triggered by a LSP Create Request(PCCreate) message from a PCE, and 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 restoration LSP. An ingress node is currently transporting data traffic on the working LSP, and then it establishes one or more restoration LSPs. As per <xref target="RFC3209"/> Section 2.5. "LSP ID" of restoration LSP, which is newly signaled, differs from that of restoration LSP.
In this document, LSP ID of a working LSP describes "old" and that of a restoration LSP describes "new" as a simple example.
</t>
<t>
One-stroke 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>
Granular mode is much more flexible than One-stroke mode since it allows PCEs to manage each LSP step-by-step. Granular 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 are completed. 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, one stroke mode or granular 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="One Stroke 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 one stroke M-B-B procedure.
</t>
<!-- // Restation LSPのLSP-IDを示すPCUpd -->
<t>
First, A PCUpd message is sent from PCE to trigger M-B-B procecure. 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>
<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. If the restoration LSP failed in setup, the PCC MAY retry RSVP-TE signaling with possibly different attributes.
</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.
</t>
<t>
Following <xref target="one stroke figure"/> illustrates the example of one stroke 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 anchor="one stroke 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-------------|
| | |
| Transfer data |))))))))))))))))))))))))|
| from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
| | : |
| |---PathTear(ERO=a-b, -> |
| | LSP ID old) |
| <-- PCRpt(O=1, ----| |
| Tunnel ID=T1, | |
| LSP ID=new, | |
| RRO=a-c-b) | |
O flag = Operational flag in LSP object.
Figure 1: One Stroke Make-Before-Break Procedure
]]>
</artwork>
</figure>
</section>
<section title="Granular Make-Before-Break Mode">
<!--
// Removeで削除とD-plane載せ替えが別なモチベーションは？
//
-->
<t>
Compareing to the one stroke M-B-B mode, Granular M-B-B mode allows a PCE to control timing and sequence of subsequent make-before-break steps as follows.
</t>
<t>
First, the PCE initiates PCC's signaling of a new LSP by sending a LSP Create Request(PCCreate) message.
Second, the PCE instructs the PCC to transfer data traffic from old LSP to new LSP by sending a PC Update Request(PCUpd) message with extension TLV that are defined in this document.
Third, the PCE instructs 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 LSP triggered by a PCCreate message">
<t>
As a first step of M-B-B procedure, a PCC establishes a restoration LSP once PCC receives PCCreate message from a PCE. This document defines a PCCreate message MUST have a LSP Object with LSP Identifiers TLV, which is used to specify Tunnel ID and the new LSP ID that the PCC must 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 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. A PCRpt message from the PCC MUST have the LSP object with LSP Identifiers TLV that indicates 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 LSP failed to be established by some reason of RSVP-TE signaling, the PCC MUST send PCRpt message carrying LSP Identifiers TLV and RSVP-ERROR-SPEC TLV as defined in <xref target="I-D.ietf-pce-stateful-pce"/> Section 7.2.2. to the PCE.
</t>
<t>
<xref target="establish new lsp"/> illustrates a example, working LSP(Tunnel ID T1, LSP-ID old, ERO Ingress-a-b-Egress), restoration LSP(Tunnel ID T1, LSP-ID new, ERO Ingress-a-c-b-Egress).
</t>
<figure anchor="establish new lsp">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data traffic on old LSP |
| |))))))))))))))))))))))))|
|--PCCreate --->| : |
| (tunnel ID=T1, | : |
| LSP ID=new, | |
| ERO=a-c-b ) |---Path(LSP ID=new, --> |
| | ERO=a-c-b) |
| | |
| | <----- Resv------------|
| <-- PCRpt(O=1, ----| |
| tunnel ID=T1, |))))))))))))))))))))))))|
| LSP ID=new, | : |
| RRO=a-c-b) | : |
| | |
Figure 2: Establish new LSP
]]>
</artwork>
</figure>
</section>
<section title="Transfer Data Traffic triggered by a PCUpd message">
<t>
As a second step, PCC(Ingress) transfers data traffic from primary LSP to restoration LSP. To specify transferring data traffic, this document introduces a new TLV, called Data Contro TLV.
</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"/>). And PCUpd also carries a LSP Identifiers TLV to specify the Tunnel ID and LSP ID that data traffic will get onto.
</t>
<t>
Once the PCC receives the PCUpd message with LSP Identifier TLV and Data Control TLV in LSP Object, the PCC MSUT transfer data traffic from old LSP to new LSP immediately.(See <xref target="data transferring"/>)
</t>
<t>
If the LSP Identifiers 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>
<figure anchor="data transferring">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| | |
| |))))))))))))))))))))))))| data on old LSP
|--PCUpd ------> |))))))))))))))))))))))))|
| (tunnel ID=T1, |}}}}}}}}}}}}}}}}}}}}}}}}| data on new LSP
| LSP ID=new, |}}}}}}}}}}}}}}}}}}}}}}}}|
| +Data Control TLV)| : |
| | : |
| | |
| | |
| <-- PCRpt(O=1 --| |
| LSP ID=new, | |
| RRO=a-c-b) | |
| | |
O flag = Operational flag in LSP object.
Figure 3: Transfer data traffic from old LSP to new LSP
]]>
</artwork>
</figure>
</section>
<section title="Tear Down old LSP triggered by a PCUpd message">
<!--
// PCUpd with R flagでした．MPLS-TE LSP全て消えてしまないように！
-->
<t>
As a final step of Make-Before-Break procedure, the PCC tears down the primary LSP which the data traffic is no longer used, by the PCUpd message from the PCE server.
</t>
<t>
The PCC MUST tear down the LSP immediately once the PCC receives the PCUpd message setting Remove(R) flag 1. The PCUpd message MUST 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>
<figure anchor="tear down lsp">
<artwork><![CDATA[
__c__
/ \
PCE PCC(Ingress)--a-------b---Egress
| data on new LSP |
| |}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
|--PCUpd(R=1, ---->| : |
| tunnel ID=T1, |--PathTear(ERO a-b, -->| new LSP remains up
| LSP ID=old) | Tunnel=T1,LSP ID=old)|
| | |
| | |
| <-- 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 One Stroke 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 One Stroke 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 Granular 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 Granular Make-Before-Break">
<t>
There are two usage of PCUpd messages for Granular 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 Granular 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="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 | Flags |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Balance TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DATA-CONTROL 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 Granular 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>
<!--
<t hangText="S (Stitching - 1 bit):">Stitching(S) bit indicates that data traffic on the LSP connects to the other LSP which is specified in a Optional TLV. Detailed format will be specified in the future version of this document.
</t>
<t hangText="L (Load balance - 1 bit):">Load Balance(L) bit uses when the PCE distributes the data traffic on the LSP across multiple LSPs which are specified in a Optional TLV. Detailed format will be specified in the future version of this document.
</t>
-->
</list>
</t>
</list>
</t>
<t>Load Balance TLV(Optional TLV)
<list style="empty">
<t>
This field is used for load balancing and is available only when the Data(D) flag is positive.
<list style="hanging">
<t hangText="Load Balance type - 7 bit :">This field indicates the type of load balance.(i.e. Hash function, Round-Robin, ToS base)
</t>
<t hangText="Continue flag - 1 bit :">
If this flag set to 1, it indicates the next LSP Object in the PCUpd has also Load Balance TLV. If this flag set to 0, it indicates no more LSP Object continues and load balance calculation will be completed, then Load Balance MUST be activated.
</t>
<t hangText="Type of Service - 8 bit:">
This field is used when the Load Balance type specifies ToS base. Otherwise, this field is to be Zero.
</t>
<t hangText="Percentage field - 16 bit :">
This field specifies ratio of load balance. The sum of this field across subsequent LSP Object has to be hundred percent.
</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: Value already in use.
for one stroke mode
Error-value=TBD: Specified LSP is not existing.
for granular mode
Error-value=TBD: Specified LSP is not operational.
for granular mode
]]>
</artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>
TBD
</t>
</section>
<section title="Acknowledgments">
<t>
<!-- Many thanks to Yimin Shen, Ina Minei, Ravi Torvi 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;
&I-D.crabbe-pce-stateful-pce-mpls-te;
&I-D.crabbe-pce-pce-initiated-lsp;
</references>
<references title="Informative References">
&rfc3209;
&rfc4426;
&rfc4427;
&I-D.crabbe-pce-stateful-pce-protection;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:58:05 |