idnits 2.17.1 draft-tanaka-pce-stateful-pce-data-ctrl-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 13, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4872' is defined on line 759, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-00 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-07 == Outdated reference: A later version (-08) exists of draft-tanaka-pce-stateful-pce-mbb-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Tanaka 3 Internet-Draft Y. Kamite 4 Intended status: Standards Track NTT Communications 5 Expires: August 17, 2014 I. Minei 6 Google 7 D. Dhody 8 Huawei Technologies 9 Feb 13, 2014 11 Stateful PCE Extensions for Data Plane Switchover and Balancing 12 draft-tanaka-pce-stateful-pce-data-ctrl-02 14 Abstract 16 Stateful Path Computation Element (PCE) and its corresponding 17 protocol extensions provide a mechanism that enables PCE to do 18 stateful control of Multiprotocol Label Switching (MPLS) Traffic 19 Engineering Label Switched Paths (TE LSP). One application that 20 stateful PCE can realize is data traffic reoptimization among the 21 LSPs. Data traffic traversed in a LSP can be switched to another 22 PCE-initiated LSP. Moreover, data traffic can be balanced to 23 multiple PCE-initiated LSPs and may also be policed based on a 24 signaling bandwidth of a PCE-Initiated LSP using stateful PCE. 26 This document specifies the extensions to Path Computation Element 27 Protocol (PCEP) that allow a stateful PCE to do switchover, balancing 28 and policing of data traffic with PCE-initiated LSPs. This document 29 also specifies the extensions, usage and handling of stateful PCEP 30 messages and the expected behavior of PCC as the RSVP-TE headend. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 17, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions used in this document . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. PCEP Operation for Data Switchover and Balancing . . . . . . . 4 70 5. TLVs in LSP Objects . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. ASSOCIATION-GROUP TLV in LSP Objects . . . . . . . . . . . 6 72 5.2. DATA-CONTROL TLV in LSP Objects . . . . . . . . . . . . . 8 73 5.3. DATA-REPORT TLV in LSP Objects . . . . . . . . . . . . . . 10 74 5.4. Advertising Support of Data Switchover and Balancing . . . 11 75 6. Operation Examples . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. Data switchover operation (100:0 => 0:100) . . . . . . . . 11 77 6.2. Load balancing operation (100:0 => 50:50) . . . . . . . . 13 78 6.3. Load balancing operation (100:0 => 66:33) . . . . . . . . 14 79 7. Redundant stateful PCEs . . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 16 82 8.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 16 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. PCEP TLV Indicators . . . . . . . . . . . . . . . . . . . 17 85 9.2. PCEP Error Objects . . . . . . . . . . . . . . . . . . . . 17 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 [I-D.ietf-pce-stateful-pce] describes the stateful Path Computation 95 Elements (PCE) procedures and defines the extensions to PCEP to 96 enable stateful control of LSPs between and across PCEP sessions, 97 further it also describes mechanisms to effect LSP state 98 synchronization between PCCs and PCEs, and PCE control of timing and 99 sequence of path computations within and across PCEP sessions. A PCE 100 can update LSP settings (such as bandwidth, priority, path) using an 101 update message (called PCUpd). 103 [I-D.ietf-pce-pce-initiated-lsp] defines the extensions to PCEP to 104 allow a PCE to instantiate new LSPs (called PCE-Initiated LSPs). 105 Before these extensions, the LSP ingress point had to be 106 preconfigured at the head end Label Edge Router (LER), the LSP 107 control automatically delegated to the initiating stateful PCE and 108 then its parameters (e.g., bandwidth, priority, path) could be 109 modified via a PCUpd message. The extensions for PCE-initiated LSPs 110 eliminate the need for preconfiguration, and allow more flexible 111 operations on the network. Stateful-PCE with LSP instantiation is 112 attracting attention as an enabler for Software Defined Networking 113 (SDN) operation of MPLS networks. 115 In SDN, it is highly expected to support intelligent and interactive 116 control of the amount of network traffic by means of a logically- 117 centralized controller. Optimizing the path and bandwidth of MPLS-TE 118 LSP by using stateful PCE is a leading use case of SDN applications. 119 A PCE is able to calculate an optimized route from the topology and 120 bandwidth information in the Traffic Engineering Database (TED) and 121 the LSP state database (LSPDB) and it can integrate with a controller 122 that takes into account additional information such as historical 123 trends and service orders to trigger some PCE actions. For example, 124 when data traffic on a LSP increases the bandwidth utilization and if 125 there is no capacity left in the currently signaled path (i.e., no 126 remaining bandwidth of links), a PCE is able to update the existing 127 LSP's parameters (PCE-updated LSP) or create a totally new LSP (PCE- 128 initiated LSP). 130 The former method is oriented for keeping the existing instance of 131 LSP tunnel. Meanwhile, the latter method is oriented for adding a 132 new instance of a LSP tunnel. 134 Specifically regarding the latter method, PCE-initiated LSP, there 135 are some operational scenarios in the network: one is that PCE 136 instantiate a new LSP that have alternate route with increased- 137 bandwidth LSP and performs switchover from old LSP. Another is that 138 PCE creates one or more additional LSPs and performs load balancing 139 of data traffic. Today, however, there is no detailed procedure 140 specified as to how to control data traffic switching from an old LSP 141 to new PCE-Initiated LSP(s). 143 For another example, when data traffic on a LSP increases its 144 bandwidth utilization and if there is strict traffic contract, a PCE 145 is able to force a PCC not to exceed the contract bandwidth. 147 This document specifies the procedures that a stateful PCE can use to 148 control data traffic switchover, load balancing with multiple PCE- 149 Initiated LSPs and policing activation/deactivation. This document 150 also specifies the usage and handling of stateful PCEP messages and 151 the expected behavior of PCC as an RSVP-TE headend. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC2119[RFC2119]. 159 3. Terminology 161 This document uses the following terms defined in [RFC5440]: PCC, 162 PCE, PCEP Peer. 164 This document uses the following terms defined in 165 [I-D.ietf-pce-stateful-pce]: Stateful PCE, LSP State Request, LSP 166 Update Request. 168 This document uses the following terms defined in 169 [I-D.ietf-pce-pce-initiated-lsp]: LSP Initiate Message. 171 4. PCEP Operation for Data Switchover and Balancing 173 There are two typical operations for explaining the functionality of 174 data switchover and balancing. 176 o Whole data switchover, where a PCC switches all data traffic from 177 one LSP tunnel to another. 178 o Load balancing of multi-instance LSP tunnels with different paths, 179 where a PCC (headend) balances data traffic among two or more 180 tunnels (ex fifty percent each, for two instances). 182 Both operational cases are completed by the messaging over a single 183 protocol, PCEP, keeping this as a simple and straightforward solution 184 for MPLS networks. 186 A PCEP speaker indicates its ability to support PCE control over the 187 data switchover and balancing during the PCEP Initialization phase. 188 The Open Object in the Open message contains the "Stateful PCE 189 Capability" TLV, defined in [I-D.ietf-pce-stateful-pce]. A new flag, 190 the W (LSP-DATASWITCHOVER-BALANCE-CAPABILITY) flag is introduced. A 191 PCE can control the data switchover and loadbalancing only for PCCs 192 that advertised this capability and a PCC will follow the procedures 193 described in this document only on sessions where the PCE advertised 194 the W flag. (Refer Section 5.4) 196 Data switchover and balancing for an MPLS-TE LSP is available once a 197 PCEP session is established and then a PCC delegates its LSPs to a 198 PCE. 200 First step is LSP instantiation. In this step, a PCE sends as many 201 PCInitiate messages as PCE-Initiated LSP as per demand. Once the PCC 202 receives them and successfully establishes PCE-Initiated LSPs, it 203 sends PCRpt messages in reply to the PCInitiate messages and 204 delegates the newly established LSP to the PCE. Message formats and 205 behaviors of the PCC and the PCE are described in detail in 206 [I-D.ietf-pce-pce-initiated-lsp]. 208 Second step is LSP association. After the PCE-Initiated LSP 209 successfully established and delegated the PCE sends a PCUpd message 210 that contains the ASSOCIATION-GROUP TLV in the LSP Object in order to 211 assemble the members of an association group of LSPs to take over the 212 traffic. Once a PCC receives the PCUpd message with ASSOCIATION- 213 GROUP TLV, the PCC sends back a PCRpt message that contains the 214 ASSOCIATION-GROUP TLV with current operational status. 216 [Editor's Note: The option of specifying the association at LSP 217 instantiation time (as part of the PCInitiate message) will be 218 evaluated in a future version of this document.] 220 Third step is executing the data switchover and/or load balancing. 221 In this step, the PCE sends a single PCUpd message which updates the 222 operational status of the LSP from "up and carrying traffic" to just 223 "up". This Update request message for data plane switchover/ 224 balancing execution MUST contain DATA-CONTROL TLV in LSP Object. The 225 associated group of traffic origin and that of target to take over 226 the traffic are listed in the DATA-CONTROL TLV. The PCC (LSP 227 headend) load-balances between LSPs in the same association group 228 based on their respective bandwidths. The switchover case is 229 supported since there will be an association of a single LSP, so that 230 LSP will get hundred percent of data traffic. 232 The PCC MUST send a PCRpt message to the PCE in order to notify of 233 the result of the data switchover/balancing. The PCRpt message MUST 234 have the DATA-CONTROL TLV that indicates the actual assigned 235 percentages of each member of association group after the execution 236 of the data switchover/balancing operation. The LSP object in the 237 PCRpt will have the reserved PLSP-ID of 0. 239 The final step is the deletion of old LSP. It is OPTIONAL to carry 240 out this step. The PCE sends PCInitiate message requesting deletion 241 of the LSP that does not carry data traffic anymore after data 242 switchover/balancing execution. Once the PCC tears down the LSP, a 243 PCRpt message MUST be sent from the PCC to the PCE in order to notify 244 that the LSP is no longer used. 246 Note that, both RSVP-TE [RFC3209] Tunnel-ID and LSP-ID for PCE- 247 Initiated LSP signaling is not allocated by a PCE. A PCC locally 248 assigns those IDs that are related to RSVP-TE parameters. Therefore, 249 the operations of data switchover and balancing specified in this 250 document is the traffic control procedure across multiple RSVP-TE 251 Tunnels (i.e., different Tunnel instances). Data switchover method 252 across LSPs within a single RSVP-TE Tunnel, which is the switchover 253 in the middle of make-before-break reoptimization, is covered by 254 [I-D.tanaka-pce-stateful-pce-mbb]. 256 5. TLVs in LSP Objects 258 5.1. ASSOCIATION-GROUP TLV in LSP Objects 260 This section defines ASSOCIATION-GROUP TLV in LSP Objects. An 261 ASSOCIATION-GROUP TLV is used in the LSP Object in PCUpd messages 262 when a PCE creates an association group of LSPs on a PCC. Further it 263 is used in a LSP object in a PCRpt message to confirm the 264 association. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type=TBD | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Association Group ID | Flags | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type=TBD | Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Association Group ID | Flags | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 1: ASSOCIATION-GROUP TLV format 284 Flags and fields 286 Association Group ID - 24 bits: This field specifies a 287 identifier of association group of LSPs. The IDs are assigned 288 by a PCE. 0x000000 and 0xFFFFFF is reserved for special use. 289 Flags - 8 bit: None defined. MUST be set to zero. 291 An association group is a group of LSPs that is referenced by a 292 single identifier, by both the PCE and PCC. This number is 293 significant in the context of a single PCEP session. An association 294 group may have one or more LSPs. Association groups with zero 295 members are removed and the id can be reused. The PCE is the entity 296 managing association, and this is considered PCE's state that will be 297 cleaned up when the State Timeout Interval expires. 299 The status of the association group is active when the group is up 300 and carrying data traffic. Otherwise, it is inactive when the group 301 does not carry any data traffic. An LSP is able to associate with up 302 to two association groups, unless both association groups are active 303 at any given point in time. This is done to allow a new LSP to be 304 instantiated and assigned with a new inactive association group, the 305 existing LSP is also associated with this group. This allows 306 switching to the new group. 308 To create a new association group on a PCC, a PCE sends a PCUpd 309 message which contains the LSP Object(e.g. PLSP-ID=100) and 310 ASSOCIATION-GROUP TLV (Association Group ID=10) in the LSP object. 311 Next, a PCE sends the another PCUpd message with another LSP 312 Object(e.g. PLSP-ID=200) and ASSOIATION-GROUP TLV(Association Group 313 ID=10). As a result, the PCC and PCE both recognize that Association 314 Group ID 10 represents PLSP-ID=100 and 200. 316 To remove a specific PLSP-ID from the association group, a PCE sends 317 PCUpd message which contains the LSP Object(PLSP-ID=100) and 318 ASSOCIATION-GROUP TLV (Association Group ID=0x0000). Then a PCC 319 removes the PLSP-ID 100 from any inactive association group on the 320 PCC. 322 To flush all association groups on a PCC, a PCE sends a PCUpd message 323 which contains the LSP Object(PLSP-ID=0x0000) and ASSOCIATION-GROUP 324 TLV(Association Group ID=0x0000). Then a PCC flushes all association 325 groups. A traffic handling behavior of a PCC when it flushes the 326 active association group is left for a future version of this 327 document. 329 To associate a PLSP-ID with the existing inactive association group, 330 A PCE sends a PCUpd message which contains the PLSP-ID and the 331 existing Association Group ID. A PCE is not allowed to add any 332 PLSP-ID to the active association group in order to avoid rebalancing 333 traffic without data-ctrl requests. If the PCUpd message contains a 334 PLSP-ID and the active Association Group ID, the PCC MUST send out a 335 PCErr with error value TBD to indicate an invalid operation. 337 When the LSP of the active association group is torn down by a reason 338 of either network failure or administrative down-request from the 339 PCE, a PCC MUST remove the PLSP-ID from the group and rebalance the 340 traffic based on the respective bandwidths of the rest of LSPs. 341 After rebalancing, The PCC MUST report the actual percentage to the 342 PCE using PCRpt with DATA-REPORT TLV (Section 5.3). 344 Note that a PCE is able to associate not only PCE-Initiated LSP but 345 also existing LSP(i.e., PCE-updated LSP) with any association group 346 on a PCC. 348 The definition of PCRpt messages when a PCC creates/removes/flushes 349 an association group will be clarified in the future version of this 350 draft. Redundant stateful PCE section needs the PCRpt in order to 351 sync the association group IDs and actual percentages of balancing. 353 5.2. DATA-CONTROL TLV in LSP Objects 355 This section defines DATA-CONTROL TLV in LSP Objects. A DATA-CONTROL 356 TLV is used in the LSP Object in PCUpd messages when a PCE makes a 357 PCC to execute traffic switchover or load balancing. It is also 358 mandatory in a LSP object in a PCRpt message with DATA-REPORT TLV to 359 notify the results of execution. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type=TBD | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Origin Association Group ID | Flags | O | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Target Association Group ID | Flags |P| O | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 2: DATA-CONTROL TLV format 373 Flags and fields 375 Origin Association Group ID - 24 bits: data traffic origin 376 Target Association Group ID - 24 bits: for taking over whole 377 data traffic from origin. 378 P (Policing - 1 bit: This flag is used when a PCE makes a PCC 379 apply traffic policer. If this flag is set 1, traffic 380 exceeding the bandwidth of the LSP is discarded on the PCC 381 after traffic switchover execution. Otherwise, the PCC does 382 not apply any traffic policer and traffic on a target 383 association group will not be discarded. 384 O (Operational - 3 bits): This flag represents the requested 385 operational status for each Origin Association Group ID and 386 Target Association Group ID by a PCE when this TLV is used in a 387 PCUpd message. It is also used as a status report in a PCRpt 388 message. The meanings of the values are defined in 389 [I-D.ietf-pce-stateful-pce]. 391 An LSP Object in a PCUpd message MUST have DATA-CONTROL TLV when a 392 PCE operates data switchover and balancing on a PCC. DATA-CONTROL 393 TLV is sub-TLV of an LSP Object and is used in both a PCUpd and a 394 PCRpt message. 396 An operation of data switchover/balancing is the action of 397 transferring traffic from an origin association group to a target 398 association group. A PCUpd message with reserved LSP Object (PLSP- 399 ID=0x00000) and DATA-CONTROL TLV (a set of an origin and a target 400 association group) MUST triggers data switchover/balancing execution. 402 Traffic policer is able to be applied in both traffic switchover case 403 and load-balancing case. 405 5.3. DATA-REPORT TLV in LSP Objects 407 This section defines DATA-REPORT TLV in LSP Objects. A DATA-REPORT 408 TLV is used in the LSP Object in PCRpt message to notify the results 409 of execution with the DATA-CONTROL TLV. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type=TBD | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Member 1 (PLSP-ID ) | Flags | Percentage | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Member 2 (PLSP-ID ) | Flags | Percentage | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 // // 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Member N (PLSP-ID ) | Flags | Percentage | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 3: DATA-REPORT TLV format 429 Flags and fields 431 Member(PLSP-ID) - 20 bit: This TLV is only used in a PCRpt 432 message and represents actual percentages of load balancing per 433 respective PLSP-ID after load balancing execution. Member 434 field fills PLSP-ID that is member of target association group. 435 As per [I-D.ietf-pce-stateful-pce]. 436 Flags - 5 bit: None defined. MUST be set to zero. 437 Percentage - 7 bits: This field specifies actual percentage of 438 load balancing as a closest integer, with 100% as the max 439 allowed value. 441 A PCC replies to a PCE a PCRpt message as an acknowledgment of data 442 switchover/balancing result. The PCRpt message MUST have reserved 443 LSP Object(PLSP-ID=0x00000) and DATA-CONTROL TLV with DATA-REPORT TLV 444 inside. 446 The PCC load-balances between LSPs in the same association group 447 based on their respective bandwidths.If one of the LSPs goes down by 448 network failure, the traffic would load-balance correctly over the 449 others. If a PCE updates the bandwidth of the LSP, the traffic would 450 rebalance after a PCC completes the signaling. If one of the LSPs is 451 signaled with zero bandwidth, no traffic would be transferred to the 452 LSP. If all LSPs of the association group are signaled with zero 453 bandwidth, the traffic would load-balance equally. In switchover 454 case, the hundred percent traffic will be transferred to the LSP even 455 if the LSP is zero bandwidth. 457 The traffic on the existing LSP is able to load-balance over both the 458 existing LSP itself and new PCE-Initiated LSPs, by means of that the 459 existing LSP belongs to both the origin association group and that of 460 target. 462 5.4. Advertising Support of Data Switchover and Balancing 464 New flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in 465 [I-D.ietf-pce-stateful-pce]. 467 W (LSP-DATASWITCHOVER-BALANCE-CAPABILITY - 1 bit): if set to 1 by a 468 PCEP speaker, it indicates that the PCEP speaker allows data 469 switchover and balancing. 471 6. Operation Examples 473 For easy understanding this section introduces typical operation 474 examples of data switchover/balancing. 476 6.1. Data switchover operation (100:0 => 0:100) 478 A PCE instructs a PCC to switchover 100% traffic from association 479 group ID 1 to association group ID 2. A PCE sends single PCUpd 480 message containing the mandatory LSP Objects with DATA-CONTROL TLV. 482 Expected PCUpd, PCRpt messages to create association group and to 483 trigger data switchover follow. 485 PCE PCC(Ingress) Egress 486 [LSP Association for existing LSP] 487 | | | 488 | --PCUpd ----------------->| | 489 | LSP Obj: PLSP-ID=1 | | 490 | + ASSOC-G: Assoc-G-ID 10| | 491 | | | 492 |<--PCRpt ----------------- | | 493 | LSP Obj: PLSP-ID=1 | | 494 | + ASSOC-G: Assoc-G-ID 10| | 496 [LSP Creation] 497 | | | 498 | --PCInitiate ------------>| | 499 | | --Path ------->| 500 | |<------- Resv-- | Establish a new 501 |<--PCRpt ----------------- | | PCE-Initiated LSP 502 | LSP Obj: PLSP-ID=2 | | 503 | | | 505 [LSP Association for PCE-Initiated LSP] 506 | | | 507 | --PCUpd ----------------->| | 508 | LSP Obj: PLSP-ID=2 | | 509 | + ASSOC-G: Assoc-G-ID 20| | 510 | | | 511 |<--PCRpt ----------------- | | 512 | LSP Obj: PLSP-ID=2 | | 513 | + ASSOC-G: Assoc-G-ID 20| | 514 | | | 516 [Switchover Execution] 517 | | | 518 | --PCUpd ----------------->| | 519 | LSP Obj: PLSP-ID=0x0000 | | 520 | + D-CTRL: | : | 521 | Origin Assoc-G-ID 10(O=up) : | 522 | Target Assoc-G-ID 20(O=active) : | 523 | |))))))))))))))))| Switchover 524 | |}}}}}}}}}}}}}}}}| Execution 525 |<--PCRpt------------------ | : | 526 | LSP Obj: PLSP-ID=0x0000 | : | 527 | + D-CTRL: | : | 528 | Origin Assoc-G-ID 10(O=up) | 529 | Target Assoc-G-ID 20(O=active) | 530 | + D-REPORT: | | 531 | PLSP-ID 2, 100% | | 532 | | | 533 Figure 4: Switchover Operation Example 535 6.2. Load balancing operation (100:0 => 50:50) 537 The scenario is one where the starting state is a single LSP (of 538 bandwidth 100 M) is carrying the traffic. To enable better bin- 539 packing, the PCE may want to create two smaller LSPs instead, each of 540 50M, and load balance the traffic over them. To accomplish this, two 541 association groups are used, the first (say association group ID 10) 542 contains the LSP carrying the traffic, and the second (say 543 association group ID 30) contains the two new smaller LSPs. Expected 544 PCUpd, PCRpt messages to create association group and to trigger 545 load-balance follow (The instantiation of the original LSP of 546 bandwidth 100M and its association into group ID 10 is not shown) 548 PCE PCC(Ingress) Egress 550 [LSP Creation] 551 | | | 552 | --PCInitiate x2---------->| | 553 | BW: 50M | --Path x2----->| 554 | |<-----Resv x2-- | Establish two new 555 |<--PCRpt ----------------- | | PCE-Initiated LSP 556 | LSP Obj: PLSP-ID=3 | | 557 |<--PCRpt ----------------- | | 558 | LSP Obj: PLSP-ID=4 | | 559 | | | 561 [LSP Association for PCE-Initiated LSPs] 562 | | | 563 | --PCUpd ----------------->| | Create new 564 | LSP Obj: PLSP-ID=3 | | Association Group 565 | + ASSOC-G: Assoc-G-ID 30| | for PCE-Initiated 566 | | | LSP 567 |<--PCRpt ----------------- | | 568 | LSP Obj: PLSP-ID=3 | | 569 | + ASSOC-G: Assoc-G-ID 30| | 570 | | | 571 | --PCUpd ----------------->| | Add a new LSP 572 | LSP Obj: PLSP-ID=4 | | to Association Group 573 | + ASSOC-G: Assoc-G-ID 30| | 574 | | | 575 |<--PCRpt ----------------- | | 576 | LSP Obj: PLSP-ID=4 | | 577 | + ASSOC-G: Assoc-G-ID 30| | 579 [Load Balancing Execution] 580 | --PCUpd------------------>| | 581 | LSP Obj: PLSP-ID=0x0000 | | 582 | + D-CTRL: | : | 583 | Origin Assoc-G-ID 10(O=up) : | 584 | Target Assoc-G-ID 30(O=active) : | 585 | |))))))))))))))))| Balancing 586 | |)})})})})})})})}| Execution 587 | | : | 588 |<--PCRpt------------------ | : | 589 | LSP Obj: PLSP-ID=0x0000 | : | 590 | + D-CTRL: | : | 591 | Origin Assoc-G-ID 10(O=up) | 592 | Target Assoc-G-ID 30(O=active) | 593 | + D-REPORT: | | 594 | PLSP-ID 3, 50% | | 595 | PLSP-ID 4, 50% | | 596 | | | 598 Figure 5: Load-Balance Operation Example 600 6.3. Load balancing operation (100:0 => 66:33) 602 The scenario is one where the starting state is a single LSP (of 603 bandwidth 100 M) is carrying the traffic. But as the data traffic 604 load increases another 50 M is required. The PCE may want to create 605 another LSP of 50 M, and load balance the traffic over the existing 606 and new LSP. To accomplish this, two association groups are used, 607 the first (say association group ID 10) contains the LSP carrying the 608 traffic, and the second (say association group ID 40) contains the 609 new initiated LSP as well as the original LSP. Expected PCUpd, PCRpt 610 messages to create association group and to trigger load-balance 611 follow (The instantiation of the original LSP of bandwidth 100M and 612 its association into group ID 10 is not shown) 614 PCE PCC(Ingress) Egress 616 [LSP Creation] 617 | | | 618 | --PCInitiate ------------>| | 619 | BW: 50M | --Path ------->| 620 | |<-----Resv ---- | Establish new 621 |<--PCRpt ----------------- | | PCE-Initiated LSP 622 | LSP Obj: PLSP-ID=5 | | 623 | | 625 [LSP Association for PCE-Initiated LSPs] 626 | | | 627 | --PCUpd ----------------->| | Create new 628 | LSP Obj: PLSP-ID=5 | | Association Group 629 | + ASSOC-G: Assoc-G-ID 40| | for PCE-Initiated 630 | | | LSP 631 |<--PCRpt ----------------- | | 632 | LSP Obj: PLSP-ID=5 | | 633 | + ASSOC-G: Assoc-G-ID 40| | 634 | | | 635 | --PCUpd ----------------->| | Add the old LSP 636 | LSP Obj: PLSP-ID=1 | | to the Association 637 | + ASSOC-G: Assoc-G-ID 40| | Group 638 | | | 639 |<--PCRpt ----------------- | | 640 | LSP Obj: PLSP-ID=1 | | 641 | + ASSOC-G: Assoc-G-ID 40| | 643 [Load Balancing Execution] 644 | --PCUpd------------------>| | 645 | LSP Obj: PLSP-ID=0x0000 | | 646 | + D-CTRL: | : | 647 | Origin Assoc-G-ID 10(O=up) : | 648 | Target Assoc-G-ID 40(O=active) : | 649 | |))))))))))))))))| Balancing 650 | |)})})})})})})})}| Execution 651 | | : | 652 |<--PCRpt------------------ | : | 653 | LSP Obj: PLSP-ID=0x0000 | : | 654 | + D-CTRL: | : | 655 | Origin Assoc-G-ID 10(O=up) | 656 | Target Assoc-G-ID 40(O=active) | 657 | + D-REPORT: | | 658 | PLSP-ID 1, 66% | | 659 | PLSP-ID 5, 33% | | 660 | | | 662 Figure 6: Load-Balance Operation Example 664 7. Redundant stateful PCEs 666 Association group IDs are unique within a PCEP session across the 667 primary PCE and the PCC. A backup PCE has to synchronize the 668 association group IDs, PCE that created the association group and 669 balancing percentages in advance of the failure on the primary PCE. 670 One practical method to synchronize is a PCC replicates each PCRpt 671 message for the backup PCEP session. A backup PCE is able to receive 672 the association group IDs from ASSOCIATION-GROUP TLV and the result 673 of balancing percentages from DATA-REPORT TLV. 675 8. Security Considerations 677 This document defines extensions to PCEP to control load balancing of 678 traffic across multiple LSPs or to completely switch traffic from one 679 LSP to another. The nature of these extensions results in more 680 information being available for a hypothetical adversary and a number 681 of additional attack surfaces which must be protected. As a general 682 precaution, it is RECOMMENDED that these PCEP extensions only be 683 activated on authenticated and encrypted sessions across PCEs and 684 PCCs belonging to the same administrative authority 686 In addition to the security considerations and recommendations 687 described in [I-D.ietf-pce-stateful-pce], the following also apply. 689 8.1. Malicious PCE 691 A malicious PCE may flap the traffic between several LSPs, creating 692 shifting patterns in the network and excessive load on the PCC. A 693 PCC may protect itself from such an attack by enforcing a limit on 694 the number of data-control requests per unit of time and MAY take 695 additional steps ranging from delegation revocation to closing the 696 PCEP session. 698 8.2. Malicious PCC 700 Because the PCE keeps state regarding LSP associations for all the 701 PCCs, it is RECOMMENDED that the PCE have a bound on the amount of 702 state each PCC can occupy, and in the context of this draft, the 703 number of associations on a PCC and the number of associations each 704 LSP may be part of. Otherwise, a malicious PCC may create an 705 unbounded number of associations. Additionally, a malicious PCC may 706 purposely fail data-control messages in order to force the PCE to 707 continuously resend them and create artificial load on the PCE. The 708 PCE may protect itself from these situations by placing a limit on 709 the number of failures and closing the PCEP session. 711 9. IANA Considerations 712 9.1. PCEP TLV Indicators 714 This document defines the following new PCEP TLVs: 716 Value Meaning Reference 717 TBD DATA-CONTROL This document 718 TBD DATA-REPORT This document 720 9.2. PCEP Error Objects 722 This document defines new Error-Type and Error-Value for the 723 following new error conditions: 725 Error-Type Meaning 726 6 Mandatory Object missing 727 Error-value=TBD: DATA-CONTROL TLV missing. 728 Error-value=TBD: DATA-REPORT TLV missing. 730 19 Invalid operation 731 Error-value=TBD: No association group existing. 732 Error-value=TBD: No association group specified. 733 Error-value=TBD: No PLSP can be added to 734 the active association group. 736 10. Acknowledgments 738 Many thanks to Adrian Farrel for their ideas and suggestions. 740 11. References 742 11.1. Normative References 744 [I-D.ietf-pce-pce-initiated-lsp] 745 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 746 Extensions for PCE-initiated LSP Setup in a Stateful PCE 747 Model", draft-ietf-pce-pce-initiated-lsp-00 (work in 748 progress), December 2013. 750 [I-D.ietf-pce-stateful-pce] 751 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 752 Extensions for Stateful PCE", 753 draft-ietf-pce-stateful-pce-07 (work in progress), 754 October 2013. 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 760 Extensions in Support of End-to-End Generalized Multi- 761 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 762 May 2007. 764 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 765 (PCE) Communication Protocol (PCEP)", RFC 5440, 766 March 2009. 768 11.2. Informative References 770 [I-D.tanaka-pce-stateful-pce-mbb] 771 Tanaka, Y. and Y. Kamite, "Make-Before-Break MPLS-TE LSP 772 restoration and reoptimization procedure using Stateful 773 PCE", draft-tanaka-pce-stateful-pce-mbb-02 (work in 774 progress), October 2013. 776 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 777 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 778 Tunnels", RFC 3209, December 2001. 780 Authors' Addresses 782 Yosuke Tanaka 783 NTT Communications Corporation 784 Granpark Tower 785 3-4-1 Shibaura, Minato-ku 786 Tokyo 108-8118 787 Japan 789 Email: yosuke.tanaka@ntt.com 791 Yuji Kamite 792 NTT Communications Corporation 793 Granpark Tower 794 3-4-1 Shibaura, Minato-ku 795 Tokyo 108-8118 796 Japan 798 Email: y.kamite@ntt.com 799 Ina Minei 800 Google 801 US 803 Email: inaminei@google.com 805 Dhruv Dhody 806 Huawei Technologies 807 Leela Palace 808 Bangalore, Karnataka 560008 809 INDIA 811 Email: dhruv.ietf@gmail.com