One document matched: draft-tanaka-pce-stateful-pce-mbb-02.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'>
<!ENTITY I-D.tanaka-pce-stateful-pce-data-ctrl PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tanaka-pce-stateful-pce-data-ctrl.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-tanaka-pce-stateful-pce-mbb-02">
<?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>
<!--
<author initials='D.D' surname="Dhody" fullname='Dhruv Dhody'>
<organization abbrev="Huawei Technologies India Pvt Ltd">
Huawei Technologies India Pvt Ltd
</organization>
<address>
<postal>
<street>Leela Palace</street>
<region>Bangalore, Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
-->
<date day="21" month="Oct" 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, Path State Block.
</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 resource 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. <!-- [2013/10/20]to clalify Why M-B-B is effective in restoration case as follows --> Once failure occur, LSP becomes down, however PSB (Path State Block) of a headend node remains and keep resources. Using M-B-B, the headend node is able to resignals working LSP while the PSB remains until new restoration LSP is successfully established. 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 (Release old PSB)</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--> the M-B-B steps that a PCC takes. This procedure additionally uses a new extended TLV that is defined in <xref target="I-D.tanaka-pce-stateful-pce-data-ctrl"/>.
</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. Note that it is used for LSP-ID in LSP Ideitifiers TLVs in PCEP messages, and it differs from PLSP-ID.
<!-- [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/reoptimization 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 Networking (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/reoptimization LSP and it replies back to the PCE a PCRpt message with LSP-IDENTIFIERS TLV in the LSP Object to notify the result of signaling.
If the new LSP failed in setup, the PCC sends to the PCE the detail of the result in a PCErr message with the same SRP (Stateful PCE Request Parameters) object as that of the PCUpd message and it MAY wait for a next instruction from the PCE.
</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 new LSP is successfully established, a PCC transfers data traffic from working LSP to new LSP.
<!-- TBRemoved: If the restoration LSP failed in setup, the PCC MAY retry RSVP-TE signaling with possibly different attributes. -->
<!--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 the new LSP, the PCC tears down the (previous) working LSP by RSVP-TE signaling, then the PCC MUST send another 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. As per <xref target="I-D.ietf-pce-stateful-pce"/>, the message has to have SRP-ID set to 0x00000000.
</t>
<t>
Following <xref target="implicit figure"/> illustrates the example of implicit M-B-B procedure, in following conditions. Tunnel ID and LSP ID are included in an LSP Identifiers TLV in a LSP Object.
<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(PLSP-ID=X,->| : |
| SRP-ID=Y, | |
| ERO=a-c-b) |---Path(ERO=a-c-b-, --> |
| | LSP ID new) |
| | |
| | <-----Resv-------------|
| <- PCRpt(PLSP-ID=X,| |
| O=Up, | |
| SRP-ID=Y, | |
| Tunnel ID=T1, | |
| LSP ID=new) | |
| | |
| | |
| Transfer data |))))))))))))))))))))))))|
| from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}|
| | : |
| | : |
| |---PathTear(ERO=a-b, -> |
| | LSP ID old) |
| <- PCRpt(PLSP-ID=X,| |
| O=Dn,R=1, | |
| SRP-ID=0, | |
| Tunnel ID=T1, | |
| LSP ID=old) | |
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>
Prior to start of explicit M-B-B mode, the PCE initiates Association Group for working LSP by sending a PCUpd message with ASSOCIATION-GROUP TLV in the LSP Object that are defined in <xref target="I-D.tanaka-pce-stateful-pce-data-ctrl"/>.
</t>
<t>
First step of the explicit M-B-B, the PCE triggers PCC's signaling of a new LSP by sending a PCUpd message with TRIAL-LSP TLV that are defined in this document. The PCC sends back to the PCE a PCRpt message to notify the result of signaling new LSP.
</t>
<t>
Second, the PCE creates a new Association Group for the new LSP by sending a PCUpd message with both TRILAL-LSP TLV and ASSOCIATION-GROUP TLV in a LSP Object.
</t>
<t>
Third, the PCE instructs the PCC to transfer data traffic from old LSP to new LSP by sending a PCUpd message with DATA-CONTROL TLV. The PCC automatically tears down the (previous) working LSP once the traffic switchover successfully is executed. Then it sends back to the PCE a PCRpt message to notify the result of the switchover.
</t>
<t>
The operator may want to separate the third step into traffic switchover and tearing down old LSP. It is further study about the separate operation of third step.
</t>
<t>
The following subsections specify each Make-Before-Break step in detail.
</t>
<section title="Initiate Association Group for old LSP">
<t>
The very first of step before starting explicit M-B-B is to initiate association group for working LSP. The PCE sends to the PCC a PCUpd message that contain both TRIAL-LSP TLV and DATA-CONTROL TLV in a LSP object. RSVP-TE LSP ID that the PCE knows from LSP Identifiers TLVs in a PCRpt message MUST be set to LSP-ID of TRIAL-LSP TLV. The PCE assignes ASSOCIATION-GROUP ID in DATA-CONTROL TLV that is unique in the PCEP session.
</t>
<t>
<xref target="initiate association-group"/> illustrates an example of working LSP(PLSP-ID P1, Tunnel ID T1, LSP-ID old, Association Group ID G1 and ERO Ingress-a-b-Egress).
</t>
<figure title="Initiate Associate Group for old LSP" anchor="initiate association-group">
<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=old | |
| +DATA-CTRL TLV | |
| ASSOC-G-ID=G1 | |
| | |
]]>
</artwork>
</figure>
</section>
<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-->
</t>
<t>
TRIAL-LSP TLV triggers explicit mode M-B-B. A PCE do not have to assign RSVP-TE LSP ID for trial LSP signaling, LSP-ID in the TRIAL-LSP TLV SHOULD be set to 0x0000. The PCC assigns new LSP-ID to signal new LSP on the same RSVP-TE tunnel. <!--However it MAY specify RSVP-TE LSP ID that the PCC is going to establish.-->
</t>
<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 to the PCE 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..
</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=P1, |))))))))))))))))))))))))|
| tunnel ID=T1, | : |
| LSP ID=new, | : |
| RRO Obj=a-c-b | : |
| | |
]]>
</artwork>
</figure>
</section>
<section title="Create a New Association Group">
<t>
As a second step, the PCE creates a new Association Group for the new LSP by sending a PCUpd message with both TRILAL-LSP TLV and ASSOCIATION-GROUP TLV in a LSP Object. The PCE assignes a new ASSOCIATION-GROUP-ID, which MUST be different from that of working LSP and be unique in the PCEP session. LSP-ID in the TRIAL-LSP TLV MUST be the RSVP-TE LSP ID of the newly established LSP on the previous step.
</t>
<t>
If the PCUpd message has invalid either ASSOCIATION-GROUP-ID or LSP-ID of TRIAL-LSP, the PCC sends a PCErr message with Error-type=19 (Invalid Operation) and Error-vale=TBD (Specified LSP-ID/ASSOCIATION-GROUP-ID is not existing).
</t>
<t>
<xref target="create association-group"/> illustrates an example to create a new ASSOCIATION-GROUP-ID G2 for a new trial LSP(PLSP-ID P1, Tunnel ID T1, LSP-ID new and ERO Ingress-a-b-Egress).
</t>
<figure title="Create a new Associate Group for new LSP" anchor="create association-group">
<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=new | |
| +DATA-CTRL TLV | |
| ASSOC-G-ID=G2 | |
| | |
]]>
</artwork>
</figure>
</section>
<section title="Switchover Data Traffic triggered by a PCUpd message">
<t>
As a third step, the 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 DATA-CONTROL TLV in a LSP Object.
<!-- [Ina:2013/02/28], [Xian:2013/04/01] typos "Contro" to "Control"-->
</t>
<t>
Data switchover from old (origin) ASSOCIATION-GROUP to new (target) has to be executed in the same manner as described in <xref target="I-D.tanaka-pce-stateful-pce-data-ctrl"/>.
</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-->
<t>
The PCC SHOULD tear down the old working LSP and other trial LSPs which the data traffic is no longer used immediately once the data traffic succesfully switched over (See <xref target="data transferring"/>). In OPTIONAL, a PCC tears down old lsp separately. The PCC sends to the PCE a PCRpt message to notify the removal of both old LSP and other trial LSPs, which SRP-ID is set to 0x00000000.
</t>
<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 |}}}}}}}}}}}}}}}}}}}}}}}}|
| +DATA-CTRL TLV | : |
| | : |
| | : |
| <-- PCRpt --------| |
| LSP Object | |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=new, | |
| +DATA-CTRL TLV | |
| +DATA-REPORT TLV| |
| |--PathTear(ERO a-b, -->| Tear down old
| | Tunnel=T1,LSP ID=old) | automatically
| | |
| <-- PCRpt(O=Dn,R=1,| |
| PLSP ID=P1, | |
| Tunnel ID=T1, | |
| LSP-ID=old) | |
| | |
| | |
O flag = Operational flag in LSP object.
R flag = Remove flag in LSP object.
]]>
</artwork>
</figure>
</section>
</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=0x0000). <!--It MAY set RSVP LSP-ID in LSP-ID field of TRIAL-LSP TLV in a PCUpd message in order to notify a PCC of desired trial LSP-ID to signal.-->
</t>
<t>
<list style="hanging">
<t hangText="LSP-ID: ">This field MUST be zero in a PCUpd message when a PCE requests a PCC to signal new trial LSP. It MUST be non-zero and fill in the RSVP-TE LSP ID when a PCE sends a PCUpd message to initiate or to create Association Groups for a working/trial LSP.
</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 TRIAL-LSP TLV 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: Specified ASSOCIATION-GROUP-ID
is not existing for explicit mode
Error-value=TBD: Specified LSP-ID is not existing.
for explicit mode
]]>
</artwork>
</figure>
</section>
</section>
<section title="Operational Considerations">
<t>
</t>
<section title="Operation in multiple PCEs">
<t>
In addition to basic operations under multiple PCEs as described in <xref target="I-D.ietf-pce-stateful-pce"/>, a PCC supports both types of M-B-B operations.
</t>
<t>
Implicit mode M-B-B requires only one PCUpd message to trigger M-B-B process, therefore a PCC accepts a message from a primary PCE whom the PCC delegates the LSPs to. An attempt to update parameters of a non-delegated LSP results in the PCC sending a PCErr message as defined in <xref target="I-D.ietf-pce-stateful-pce"/>.
</t>
<t>
Explicit mode M-B-B requires at least three PCUpd messages(1. for trial-LSP signaling, 2. for new Association-Group creation, 3. for traffic switchover) to trigger each subsequent step. All steps MUST be taken by one primary PCE because state synchronization of trial-LSPs between the primary and backup PCE may be complex. If the PCC revokes LSP delegations after a Redelegation Timeout Interval, the PCC MUST tear down all trial-LSPs and redelegate a working LSP to alternate PCE. An attempt to trigger either step of explicit mode M-B-B of a non-delegeted LSP results in the PCC sending the same PCErr as implicit mode M-B-B.
</t>
</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 Dhruv Dhody 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.tanaka-pce-stateful-pce-data-ctrl;
</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:30:25 |