| Network Working Group | Y.T. Tanaka |
| Internet-Draft | Y.K. Kamite |
| Intended status: Standards Track | NTT Communications |
| I.M. Minei | |
| Juniper Networks, Inc. | |
| Oct 21, 2013 |
Stateful PCE Extensions for Data Plane Switchover and Balancing
draft-tanaka-pce-stateful-pce-data-ctrl-01
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). One application that stateful PCE can realize is data traffic reoptimization. Data traffic traversed in a LSP can be switched to another PCE-initiated LSP. Moreover, data traffic can also be balanced to multiple PCE-initiated LSPs using stateful PCE.
This document specifies the extensions to Path Computation Element Protocol (PCEP) that allow a stateful PCE to do switchover and balancing of data traffic with PCE-initiated LSPs. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages and the expected behavior of PCC as the RSVP-TE headend.
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. A PCE can update LSP settings (such as bandwidth, priority) using update messages calle PCUpd.
[I-D.crabbe-pce-pce-initiated-lsp] defines the exensions to PCEP to allow a PCE to create new LSPs (PCE-Initiated LSP). Before these extensions, the LSP egress point had to be preconfigured at the head end Label Edge Router (LER), the LSP would be set up with default parameters and then its settings (e.g., initial bandwidth, priority) could be modified via PCUpd messages. The extensions for PCE-initated LSPs eliminate the need for preconfiguration, and allow more flexible operation. Stateful-PCE with LSP instantiation is attracting attention as an enabler for Software Defined Networking (SDN) operation of MPLS networks.
In SDN, it is highly expected to support intelligent and interactive control of the traffic amount of the network by means of a logically-centralized controller. Optimizing the path and bandwidth of MPLS-TE LSP by using stateful PCE is a leading use case of SDN applications. A PCE is able to calculate an optimized route from the topology and bandwidth information in the TED and the LSP state database and it can integrate with a controller that takes into account additional information such as historical trending and service orders in order to trigger PCE action. For example, when data traffic on a LSP counts plenty of bandwidth utilization and if there is no capacity left in the currently signaled path (i.e., no remaining bandwidth of links), a PCE is able to update the existing LSP's parameters (PCE-updated LSP) or create a totally new LSP (PCE-initiated LSP).
The former method is oriented for keeping the existing instance of LSP tunnel. Meanwhile, the latter method is oriented for adding a new instance of LSP tunnel.
Specifically regarding the latter method, PCE-initiated LSP, there are some operational scenarios in the network: one is that PCE creates a new LSP that have alternate route with increased-bandwidth LSP and performs switchover from old LSP. Another is that PCE creates one or more additional LSPs and performs load balancing of data traffic. Today, however, there is no detailed procedure specified as to how to control data traffic switching from an old LSP to new PCE-Initiated LSP(s).
This document specifies the procedures that stateful PCE controls data traffic switchover and load balancing with multiple PCE-Initiated LSPs. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages and the expected behavior of PCC as an RSVP-TE headend.
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 [I-D.ietf-pce-stateful-pce]: Stateful PCE, LSP State Request, LSP Update Request.
This document uses the following terms defined in [I-D.crabbe-pce-pce-initiated-lsp]: LSP Create Request message.
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF].
There are two typical operations for explaining the functionality of data switchover and balancing. One is whole data switchover, where a PCC switches all data traffic from one LSP tunnel to another. The other is load balancing of multi-pathing LSP tunnels, where a PCC (headend) balances data traffic among two tunnels equally (fifty percent each, for instance). Both operational cases are completed by the messaging over a single protocol, PCEP, so this is a simple and straightforward solution for MPLS networks.
Support of the procedures listed in this document is negotiated at session init time. The capability negotiation will be speleld out in a future version of this document.
Data switchover and balancing for an MPLS-TE LSP is available once a PCEP session is established and then a PCC delegates its LSPs to a PCE.
First step is LSP creation. In this step, a PCE sends as many PCInitiate messages as PCE-Initiated LSP as it demands. Once the PCC receives them and successfully establishes PCE-Initiated LSPs, it sends PCRpt messages in reply to the PCInitiate messages and delegates the newly established LSP to the PCE. Message formats and behaviors of the PCC and the PCE are described in detail in [I-D.crabbe-pce-pce-initiated-lsp].
Second step is LSP association. After the PCE-Initiated LSP sucessfully established and delegated the PCE sends a PCUpd message that contains the ASSOCIATION-GROUP TLV in the LSP Object in order to assemble the members of an association group of LSPs to take over the traffic. Once a PCC receives the PCUpd message with ASSOCIATION-GROUP TLV, the PCC sends back a PCRpt message that contains the ASSOCIATION-GROUP TLV with current operational status.
The option of specifying the association at LSP instantiation time (as part of the PCInitiate message) will be evaluated in a future version of this document.
Third step is executing the data switchover and/or load balancing. In this step, the PCE sends a single PCUpd message which updates the operational status of the LSP from "up and carrying traffic" to just "up". This Update request message for data plane switchover/balancing execution MUST contain DATA-CONTROL TLV in LSP Object. The associated group of traffic origin and that of target to take over the traffic are listed in the DATA-CONTROL TLV. The PCC (LSP headend) load-balances between LSPs in the same association group based on their respective bandwidths. The switchover case is supported since there will be an association of a single LSP, so that LSP will get hundred percent of data traffic.
The PCC MUST send a PCRpt message to the PCE in order to notify of the result of the data switchover/balancing. The PCRpt message MUST have the DATA-CONTROL TLV that indicates the actual assigned percentages of each member of association group after the execution of the data switchover/balancing operation. The LSP object in the PCRpt will have the reserved PLSP-ID of 0.
The final step is the deletion of old LSP. It is OPTIONAL to carry out this step. The PCE sends PCInitiate message requesting deletion of the LSP that does not carry data traffic anymore after data switchover/balancing execution. Once the PCC tears down the LSP, a PCRpt message MUST be sent from the PCC to the PCE in order to notify that the LSP is no longer used and return delegation.
Note that, both RSVP-TE [RFC3209] Tunnel-ID and LSP-ID for PCE-Initiated LSP signaling is not allocated by a PCE. A PCC locally assigns those IDs that are related to RSVP-TE parameters. Therefore, the operations of data switchover and balancing specified in this document is the traffic control procedure across multiple RSVP-te Tunnels (i.e., different Tunnel instances). Data switchover method across LSPs within a single RSVP-TE Tunnel, which is the switchover in the middle of make-before-break reoptimization, is covered by [I-D.tanaka-pce-stateful-pce-mbb].
This section defines ASSOCIATION-GROUP TLV in LSP Objects. ASSOCIATION-GROUP TLV is used in the LSP Object in PCUpd messages when a PCE creates an association group of LSPs on a PCC.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |D|R| Association Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ASSOCIATION-GROUP TLV format
Flags and fields
An association group is a group of LSPs that is referenced by a single identifier, by both the PCE and PCC. This number is significant in the context of a single PCEP session. An association group may have one or more LSPs. Association groups with zero members are removed and the id can be reused. The PCE is the entity managing association, and this is considered PCE state that will be cleaned up when the State Timeout Interval expires.
The status of the association group is active when the group is up and carrying data traffic. Meanwhile, That is inactive while the group does not carry data traffic. An LSP is able to associate with up to two association groups, unless both association groups are active at any given point in time.
To create a new association group on a PCC, a PCE sends a PCUpd message which contains the LSP Object(e.g. PLSP-ID=100) and ASSOCIATION-GROUP TLV (Association Group ID=10) in the LSP object. Next, a PCE sends the another PCUpd message with another LSP Object(e.g. PLSP-ID=200) and ASSOIATION-GROUP TLV(Association Group ID=10). As a result, the PCC and PCE both recognize that Association Group ID 10 represents PLSP-ID=100 and 200.
To remove a specific PLSP-ID from the association group, a PCE sends PCUpd message which contains the LSP Object(PLSP-ID=100) and ASSOCIATION-GROUP TLV (Association Group ID=0x0000). Then a PCC removes the PLSP-ID 100 from any inactive association group on the PCC.
To flush all association groups on a PCC, a PCE sends a PCUpd message which contains the LSP Object(PLSP-ID=0x0000) and ASSOCIATION-GROUP TLV(Association Group ID=0x0000). Then a PCC flushes all association groups. A traffic handling behavior of a PCC when it flushes the active association group is left for a future version of this document.
To associate a PLSP-ID with the existing inactive association group, A PCE sends a PCUpd message which contains the PLSP-ID and the existing Association Group ID. A PCE is not allowed to add any PLSP-ID to the active association group in order to avoid rebalancing traffic without data-ctrl requests. If the PCUpd message contains a PLSP-ID and the active Association Group ID, the PCC MUST send out a PCErr with error value TBD to indicate an invalid operation.
When the LSP of the active association group is torn down by a reason of either network failure or administrative down-request from the PCE, a PCC MUST remove the PLSP-ID from the group and rebalance the traffic based on the respective bandwidths of the rest of LSPs. After rebalancing, The PCC MUST report the actual percentage to the PCE using PCRpt with DATA-REPORT TLV.
Note that a PCE is able to associate not only PCE-Initiated LSP but also existing LSP(i.e., PCE-updated LSP) with any association group on a PCC.
The definition of PCRpt messages when a PCC creates/removes/flushes an association group will be clarified in the future version of this draft. Redundant stateful PCE section needs the PCRpt in order to sync the association group IDs and actual percentages of balancing.
This document defines DATA-CONTROL TLV in LSP Objects.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Association Group ID | Flags | O |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Association Group ID | Flags | O |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (OPTIONAL) DATA-REPORT TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DATA-CONTROL TLV format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Member 1 (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member 2 (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Member N (PLSP-ID ) | MUST Zero | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DATA-REPORT TLV format
Flags and fields
An LSP Object in a PCCUpd message MUST have DATA-CONTROL TLV when a PCE operates data switchover and balancing on a PCC. DATA-CONTROL TLV is sub-TLV of an LSP Object and is used in both a PCUpd and a PCRpt message.
An operation of data switchover/balancing is the action of transferring traffic from an origin association group to a target association group. A PCUpd message with reserved LSP Object (PLSP-ID=0x0000) and DATA-CONTROL TLV (a set of an origin and a target association group) MUST triggers data switchover/balancing execution.
A PCC replies to a PCE a PCRpt message as a notification of data switchover/balancing result. The PCRpt message MUST have reserved LSP Object(PLSP-ID=0x0000) and DATA-CONTROL TLV with DATA-REPORT inside.
The PCC load-balances between LSPs in the same association group based on their respective bandwidths. If one of the LSPs goes down by network failure, the traffic would load-balance correctly over the others. If a PCE updates the bandwidth of the LSP, the traffic would rebalance after a PCC completes the signaling. If one of the LSPs is signaled with zero bandwidth, no traffic would be transfered to the LSP. If all LSPs of the association group are signaled with zero bandwidth, the traffic would load-balance equally. In switchover case, the hundred percent traffic will be transfered to the LSP even if the LSP is zero bandwidth.
The traffic on the existing LSP is able to load-balance over both the existing LSP itself and new PCE-Initiated LSPs, by means of that the existing LSP belongs to both the origin association group and that of target.
For easy understanding this section introduces typical operation examples of data switchover/balancing.
A PCE instructs a PCC to switchover 100% traffic from association group ID 1 to association group ID 2. A PCE sends single PCUpd message containing the reserved LSP Objects with DATA-CONTROL TLV.
Expected PCUpd,PCRpt messages to create association group and to trigger data switchover follow.
PCE PCC(Ingress) Egress
[LSP Association for existing LSP]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=1 | |
| + ASSOC-G: Assoc-G-ID 10| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=1 | |
| + ASSOC-G: Assoc-G-ID 10| |
[LSP Creation]
| | |
| --PCInitiate ------------>| |
| | --Path ------->|
| |<------- Resv-- | Establish a new
|<--PCRpt ----------------- | | PCE-Initiated LSP
| LSP Obj: PLSP-ID=2 | |
| | |
[LSP Association for PCE-Initiated LSP]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=2 | |
| + ASSOC-G: Assoc-G-ID 20| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=2 | |
| + ASSOC-G: Assoc-G-ID 20| |
| | |
[Switchover Execution]
| | |
| --PCUpd ----------------->| |
| LSP Obj: PLSP-ID=0x0000 | |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) : |
| Target Assoc-G-ID 20(O=active) : |
| |))))))))))))))))| Switchover
| |}}}}}}}}}}}}}}}}| Execution
|<--PCRpt------------------ | : |
| LSP Obj: PLSP-ID=0x0000 | : |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) |
| Target Assoc-G-ID 20(O=active) |
| + D-REPORT: | |
| PLSP-ID 2, 100% | |
| | |
Figure 4: Switchover Operation Example
The scenario is one where the starting state is a single LSP (of bandwidth 100 M) is carrying the traffic. To enable better bin-packing, the PCE may want to create two smaller LSPs instead, each of 50M, and load balance the traffic over them. To accomplish this, two association groups are used, the first (say association group ID 10) contains the LSP carrying the traffic, and the second (say association group ID 30) contains the two new smaller LSPs. Expected PCUpd,PCRpt messages to create association group and to trigger load-balance follow (The instantiation of the original LSP of bandwidth 100M and its association into group ID 10 is not shown)
PCE PCC(Ingress) Egress
[LSP Creation]
| | |
| --PCInitiate x2---------->| |
| BW: 50M | --Path x2----->|
| |<-----Resv x2-- | Establish two new
|<--PCRpt ----------------- | | PCE-Initiated LSP
| LSP Obj: PLSP-ID=3 | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=4 | |
| | |
[LSP Association for PCE-Initiated LSPs]
| | |
| --PCUpd ----------------->| | Create new
| LSP Obj: PLSP-ID=3 | | Association Group
| + ASSOC-G: Assoc-G-ID 30| | for PCE-Initiated
| | | LSP
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=3 | |
| + ASSOC-G: Assoc-G-ID 30| |
| | |
| --PCUpd ----------------->| | Add a new LSP
| LSP Obj: PLSP-ID=4 | | to Association Group
| + ASSOC-G: Assoc-G-ID 30| |
| | |
|<--PCRpt ----------------- | |
| LSP Obj: PLSP-ID=4 | |
| + ASSOC-G: Assoc-G-ID 30| |
[Load Balancing Execution]
| --PCUpd------------------>| |
| LSP Obj: PLSP-ID=0x0000 | |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) : |
| Target Assoc-G-ID 30(O=active) : |
| |))))))))))))))))| Balancing
| |)})})})})})})})}| Execution
| | : |
|<--PCRpt------------------ | : |
| LSP Obj: PLSP-ID=0x0000 | : |
| + D-CTRL: | : |
| Origin Assoc-G-ID 10(O=up) |
| Target Assoc-G-ID 30(O=active) |
| + D-REPORT: | |
| PLSP-ID 3, 50% | |
| PLSP-ID 4, 50% | |
| | |
Figure 5: Load-Balance Operation Example
Association group IDs are unique within a PCEP session across the primary PCE and the PCC. A backup PCE has to synchronize the association group IDs and balancing percentages in advance of the failure on the primary PCE. One practical method to synchronize is a PCC replicates each PCRpt message for the backup PCEP session. A backup PCE is able to receive the association group IDs from ASSOCIATION-GROUP TLV and the result of balancing percentages from DATA-REPORT TLV.
This document defines extensions to PCEP to control load balancing of traffic across multiple LSPs or to completely switch traffic from one LSP to another. The nature of these extensions results in more information being available for a hypothetical adversary and a number of additional attack surfaces which must be protected. As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority
In addition to the security considerations and recommendations described in [I-D.ietf-pce-stateful-pce], the following also apply.
A malicious PCE may flap the traffic between several LSPs, creating shifting patterns in the network and excessive load on the PCC. A PCC may protect itself from such an attack by enforcing a limit on the number of data-control requests per unit of time and MAY take additional steps ranging from delegation revocation to closing the PCEP session.
Because the PCE keeps state regarding LSP associations for all the PCCs, it is RECOMMENDED that the PCE have a bound on the amount of state each PCC can occupy, and in the context of this draft, the number of associations on a PCC and the number of associations each LSP may be part of. Otherwise, a malicious PCC may create an unbounded number of associations. Additionally, a malicious PCC may purposely fail data-control messages in order to force the PCE to continuously resend them and create artificial load on the PCE. The PCE may protect itself from these situations by placing a limit on the number of failures and closing the PCEP session.
This document defines the following new PCEP TLVs:
Value Meaning Reference
TBD DATA-CONTROL This document
TBD DATA-REPORT 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: DATA-CONTROL TLV missing.
Error-value=TBD: DATA-REPORT TLV missing.
19 Invalid operation
Error-value=TBD: No association group existing.
Error-value=TBD: No association group specified.
Error-value=TBD: No PLSP can be added to
the active association group.
Many thanks to Adrian Farrel and Dhurv Dohdy for their ideas and suggestions.
| [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-05, July 2013. |
| [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. |
| [RFC4872] | Lang, J.P., Rekhter, Y. and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. |
| [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. |
| [I-D.tanaka-pce-stateful-pce-mbb] | Tanaka, Y. and Y. Kamite, "Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE", Internet-Draft draft-tanaka-pce-stateful-pce-mbb-00, February 2013. |