| Network Working Group | Y.T. Tanaka |
| Internet-Draft | Y.K. Kamite |
| Intended status: Standards Track | NTT Communications |
| Feb 18, 2013 |
Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE
draft-tanaka-pce-stateful-pce-mbb-00
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.
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.
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[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.
[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.
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.
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.
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[RFC2119].
This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer.
This document uses the following terms defined in [RFC3209]: make-before-break.
This document uses the following terms defined in [RFC4426] and [RFC4427]: recovery, protection, restoration.
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.
As for current MPLS mechanism, make-before-break(M-B-B) concept is outlined in [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).
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.
The basicprocedure of Make-Before-Break is outlined as follows,
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.
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 [I-D.ietf-pce-stateful-pce] and [I-D.crabbe-pce-stateful-pce-mpls-te].
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 Section 6.1
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 [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.
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.
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.
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.
This specifies the detailed procedure of M-B-B LSP restoration and reoptimization using exsisting messages which are defined in [I-D.ietf-pce-stateful-pce] and [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.
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 [I-D.crabbe-pce-stateful-pce-mpls-te]. This TLV contains the value for a desired new LSP ID.
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 [I-D.ietf-pce-stateful-pce] with Error-type-19(Invalid Operation) and Error-Value=[TBD](Value already in use).
If the specified LSP ID value is zero, the PCC MUST automatically assign a new LSP ID to signal restoration LSP.
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 Section 7.2).
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 [I-D.ietf-pce-stateful-pce].
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.
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.
Following Figure 1 illustrates the example of one stroke M-B-B procedure, in following conditions.
__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
Figure 1
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.
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.
Note that this procedure uses not only PC Update Request(PCUpd) but also LSP Create Request(PCCreate) message that are defined in [I-D.crabbe-pce-pce-initiated-lsp].
The following subsections specify each Make-Before-Break steps in detail.
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.
[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, [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.)
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.
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 [I-D.ietf-pce-stateful-pce] Section 7.2.2. to the PCE.
Figure 2 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).
__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
Figure 2
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.
PCUpd carries the Data Control TLV, which is used for transferring data traffic from one LSP to another(See Section 6.1). And PCUpd also carries a LSP Identifiers TLV to specify the Tunnel ID and LSP ID that data traffic will get onto.
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 Figure 3)
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 Section 7.2.
__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
Figure 3
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.
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 Figure 4). Note that the PCC MUST tear down only the LSP that is specified in LSP Identifiers TLV.
__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
Figure 4
This document defines a new TLV named DATA-CONTROL TLV.
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
Figure 5
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:
Flags
Load Balance TLV(Optional TLV)
This document defines the following new PCEP TLVs:
Value Meaning Reference
TBD DATA-CONTROL This document
This document defines new Error-Type and Error-Value for the following new error conditions:
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
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. |
| [I-D.ietf-pce-stateful-pce] | Crabbe, E., Medved, J., Minei, I. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-02, October 2012. |
| [I-D.crabbe-pce-stateful-pce-mpls-te] | Crabbe, E., Medved, J., Minei, I. and R. Varga, "Stateful PCE extensions for MPLS-TE LSPs", Internet-Draft draft-crabbe-pce-stateful-pce-mpls-te-00, October 2012. |
| [I-D.crabbe-pce-pce-initiated-lsp] | Crabbe, E., Minei, I., Sivabalan, S. and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Internet-Draft draft-crabbe-pce-pce-initiated-lsp-01, April 2013. |
| [RFC3209] | Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. |
| [RFC4426] | Lang, J., Rajagopalan, B. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. |
| [RFC4427] | Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. |
| [I-D.crabbe-pce-stateful-pce-protection] | Crabbe, E., Medved, J., Minei, I. and R. Torvi, "PCEP Extensions for MPLS-TE LSP protection with stateful PCE", Internet-Draft draft-crabbe-pce-stateful-pce-protection-00, October 2012. |