idnits 2.17.1 draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-07.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 (October 21, 2012) is 4199 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: 'RFC3471' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 623, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-15 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft W. Cao 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: April 24, 2013 A. Takacs 6 Ericsson 7 P. Pan 8 Infinera 9 October 21, 2012 11 LDP extensions for Pseudowire Binding to LSP Tunnels 12 draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-07.txt 14 Abstract 16 Many transport services require that user traffic, in the forms of 17 Pseudowires (PW), to be delivered on a single co-routed bidirectional 18 LSP or two LSPs that share the same routes. In addition, the user 19 traffic may traverse through multiple transport networks. 21 This document specifies an optional extension in LDP that enable the 22 binding between PWs and the underlying LSPs. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 24, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . . 5 66 2.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . . 7 67 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 68 4. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9 69 5. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 14 74 7.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . . 14 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Pseudo Wire (PW) Emulation Edge-to-Edge (PWE3) [RFC3985] is a 84 mechanism to emulate layer 2 services, such as Ethernet p2p circuits. 85 Such services are emulated between two Attachment Circuits (ACs) and 86 the PW encapsulated layer 2 service payload is carried through Packet 87 Switching Network (PSN) tunnels between Provider Edges (PEs). PWE3 88 typically uses Label Distribution Protocol (LDP) [RFC5036] or 89 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [RFC3209] 90 LSPs as PSN tunnels. The PEs select and bind the Pseudowires to PSN 91 tunnels independently. Today, there is no protocol-based 92 provisioning mechanism to associate PW's to PSN tunnels. 94 PW-to-PSN Tunnel binding has become increasingly common and important 95 in many deployment scenarios. For instance, when connecting two 96 remotely located sites, such as data centers, over the backbone, each 97 site may deploy a high-performance router or switch to aggregate 98 thousands of Ethernet VLAN flows. The aggregating routers and 99 switches are interconnected via one or multiple MPLS/GMPLS LSP's, 100 which may traverse through different routes or networks. Further, 101 each Ethernet flow is offered to the customers as a bidirectional 102 circuits with certain SLA attributes, such as bandwidth and latency. 103 Hence, it's important for the operators to map the forwarding and 104 reverse-direction traffic from an Ethernet circuit to the LSP's that 105 are either bidirectional (e.g. GMPLS-initiated optical path) or co- 106 routed. 108 The requirement for explicit control of PW-to-LSP mapping has been 109 described in Section 5.3.2 ( "Support for Explicit Control of PW-to- 110 LSP Binding" ) of [RFC6373]. The following figure (Figure 1) 111 provides the illustration. 113 +------+ +------+ 114 ---AC1 ---|..............PWs...............|---AC1--- 115 ---...----| PE1 |=======LSPs=======| PE2 |---...--- 116 ---ACn ---| |-------Links------| |---ACn--- 117 +------+ +------+ 119 Figure 1: Explicit PW-to-LSP binding scenario 121 There are two PEs (PE1 and PE2) connected through multiple parallel 122 links that may be on different fibers. Each link is managed and 123 controlled as a bi-directional LSP. At each PE, there are a large 124 number of bi-directional user flows from multiple Ethernet 125 interfaces. Each user flow uses PW's to carry traffic on forwarding 126 and reverse direction. The operators need to make sure that the user 127 flows (that is, the PW-pairs) to be carried on the same fiber (or, 128 bidirectional LSP). 130 As mentioned above, there are a number of reasons behind this 131 requirement. First, due to delay and latency constraints, traffic 132 going over different fibers may require large amount of expensive 133 buffer memory to compensate for the differential delay at the headend 134 nodes. Further, the operators may apply different protection 135 mechanisms on different parts of the network. As such, for optimal 136 traffic management, traffic belongs to a particular user should 137 traverse over the same fiber. That implies that both forwarding and 138 reserve direction PW's that belong to the same user flow need to be 139 mapped to the same co-routed bi-directional LSP or two LSPs with the 140 same route. 142 Figure 2 illustrates a scenario where PW-LSP binding is not applied. 144 +----+ +--+ LSP1 +--+ +----+ 145 +-----+ | PE1|===|P1|======|P2|===| PE2| +-----+ 146 | |----| | +--+ +--+ | |----| | 147 | CE1 | |............PW................| | CE2 | 148 | |----| | +--+ | |----| | 149 +-----+ | |======|P3|==========| | +-----+ 150 +----+ +--+ LSP2 +----+ 152 Figure 2: Inconsistent SS-PW to LSP binding scenario 154 LSP1 and LSP2 are two bidirectional connections on diverse paths. 155 The operator is to deliver a bi-directional flow between PE1 and PE2. 156 Using the existing mechanisms, it's possible that PE1 may select LSP1 157 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2, while 158 selecting LSP2 (PE1-P3-PE2) as the PSN tunnel for traffic from PE2 to 159 PE1. 161 Consequently, the user traffic is delivered over two disjoint LSPs 162 that may have very different service attributes in terms of latency 163 and protection. This may not be acceptable as a reliable and 164 effective transport service to the customers. 166 The similar problems may also exist in multi-segment PWs (MS-PWs), 167 where user traffic on a particular PW may hop over different networks 168 on forward and reverse directions. 170 One way to solve this problem is by introducing manual configuration 171 at each PE to bind the PWs to the underlying PSN tunnels. However, 172 this is prone to configuration errors and won't scale. 174 In this documentation, we will introduce an automatic solution by 175 extending FEC 128/129 PW based on [RFC4447]. 177 2. LDP Extensions 179 This document defines a new TLV, PSN Tunnel Binding TLV, to 180 communicate tunnel/LSPs selection and binding requests between PEs. 181 The TLV carries PW's binding profile and provides explicit or 182 implicit information for the underlying PSN tunnel binding operation. 184 The binding TLV is optional, and MUST NOT affect the existing PW 185 operation when not present in the messages. 187 The binding operation applies in both single-segment (SS) and multi- 188 segment (MS) scenarios. 190 The extension supports two types of binding requests: 192 1. Strict binding: the requesting PE will choose and explicitly 193 indicate the LSP information in the requests. 195 2. Congruent binding: a requesting PE will suggest an underlying LSP 196 to a remote PE. On receive, the remote PE has the option to use 197 the suggested LSP, or reply the information for an alternative. 199 In this document, the terminology of "tunnel" is identical to the "TE 200 Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely 201 identified by a SESSION object that includes Tunnel end point 202 address, Tunnel ID and Extended Tunnel ID. The terminology "LSP" is 203 identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209], 204 which is uniquely identified by the SESSION object together with 205 SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and 206 Tunnel endpoint address. 208 2.1. PSN Tunnel Binding TLV 210 PSN Tunnel Binding TLV is an optional TLV and MUST be carried in the 211 LDP Label Mapping message if PW to LSP binding is required. The 212 format is as follows: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |1|0| PSN Tunnel Binding (TBA) | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Flag | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 ~ PSN Tunnel Sub-TLV ~ 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 3: PSN Tunnel Binding TLV 226 The PSN Tunnel Binding TLV type is to be allocated by IANA 228 The Length field is 2 octets in length. It defines the length in 229 octets of the entire TLV 231 The Flag field describes the binding requests, and has following 232 format: 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |C|S|T| MUST be Zero | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 The flags are defined as the following: 240 C (Congruent path) bit: This informs the remote T-PE/S-PEs about the 241 properties of the underlying LSPs. When set, the remote T-PE/S-PEs 242 need to select LSPs with routes with the similar characiteristics 243 (that is, bidirectional or co-routed path). If there is no such 244 tunnel available, the node may trigger the remote T-PE/S-PEs to 245 establish a new LSP. 247 S (Strict) bit: This instructs the PEs with respect to the handling 248 of the underlying LSPs. When set, the remote PE MUST use the tunnel/ 249 LSPs specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the 250 reverse direction of the PW, or the PW will fail to be established. 252 T (Tunnel Representation) bit: This indicates the format of the LSP 253 tunnels. When the bit is set, the tunnel uses the tunnel information 254 to identify itself, and the LSP Number fields in the PSN Tunnel sub- 255 TLV (Section 2.1.1) MUST be set to zero. Otherwise, both tunnel and 256 LSP information of the PSN tunnel are required. The default is set. 257 The motivation for the T-bit is to support the MPLS protection 258 operation where the LSP Number fields may be ignored. 260 C-bit and S-bit are mutually exclusive from each other, and cannot be 261 set in the same message. 263 2.1.1. PSN Tunnel Sub-TLV 265 PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel 266 Binding TLV to specify the tunnel/LSPs to which a PW is required to 267 bind. 269 Two sub-TLVs are defined: the IPv4 and IPv6 Tunnel sub-TLVs. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | Reserved | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Source Global ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Source Node ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Source Tunnel Number | Source LSP Number | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Destination Global ID | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Destination Node ID | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Destination Tunnel Number | Destination LSP Number | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 0 1 2 3 290 Figure 4: IPv4 PSN Tunnel sub-TLV format 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Source Global ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ Source Node ID ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Source Tunnel Number | Source LSP Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Destination Global ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 ~ Destination Node ID ~ 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Destination Tunnel Number | Destination LSP Number | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 5: IPv6 PSN Tunnel sub-TLV format 312 The definition of Source and Destination Global/Node IDs and Tunnel/ 313 LSP Numbers are derived from [RFC6370]. This is to describe the 314 underlying LSP's. Note that the LSP's in this notation is globally 315 unique. 317 As defined in Section 4.6.1.2 and Section 4.6.2.2 of [RFC3209], the 318 "Tunnel endpoint address" is mapped to Destination Node ID, and 319 "Extended Tunnel ID" is mapped to Source Node ID. Both IDs can be 320 IPv6 addresses. 322 A PSN Tunnel sub-TLV could be used to either identify a tunnel or a 323 specific LSP. The T-bit in the Flag field defines the distinction as 324 such that, when the T-bit is set, the Source/Destination LSP Number 325 fields MUST be zero and ignored during processing. Otherwise, both 326 Source/Destination LSP Number fields MUST have the actual LSP IDs of 327 specific LSPs. 329 Each PSN Tunnel Binding TLV can only have one such sub-TLV. 331 3. Theory of Operation 333 During PW setup, the PEs may select desired forwarding tunnels/LSPs, 334 and inform the remote T-PE/S-PEs about the desired reverse tunnels/ 335 LSPs. 337 Specifically, to set up a PW (or PW Segment), a PE may select a 338 candidate tunnel/LSP to act as the PSN tunnel. If none is available 339 or satisfies the constraints, the PE will trigger and establish a new 340 tunnel/LSP. The selected tunnel/LSP information is carried in the 341 PSN Tunnel Binding TLV and sent with the Label Mapping message to the 342 target PE. 344 Upon the reception of the Label Mapping message, the receiving PE 345 will process the PSN Tunnel Binding TLV, determine whether it can 346 accept the suggested tunnel/LSP or to find the reverse tunnel/LSP 347 that meets the request, and respond with a Label Mapping message, 348 which contains the corresponding PSN Tunnel Binding TLV. 350 It is possible that two PEs may request PSN binding to the same PW or 351 PW segment over different tunnels/LSPs at the same time. There may 352 cause collisions of tunnel/LSPs selection as both PEs assume the 353 active role. 355 As defined in (Section 7.2.1, [RFC6073]), each PE may be generally 356 categorized into active and passive roles: 358 1. Active PE: the PE which initiates the selection of the tunnel/ 359 LSPs and informs the remote PE; 361 2. Passive PE: the PE which obeys the active PE's suggestion. 363 In the remaining of this document, we will elaborate the operation 364 for SS-PW and MS-PW: 366 1. SS-PW: In this scenario, both PE's for a particular PE may assume 367 the active roles 369 2. MS-PW: One PE is active, while the other is passive. The PW's 370 are setup using FEC 129 372 4. PSN Binding Operation for SS-PW 374 As illustrated in Figure-5, both PEs (say, PE1 and PE2) of a PW may 375 independently initiate the setup. To perform PSN binding, the Label 376 Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN 377 Tunnel sub-TLV MUST contains the desired tunnel/LSPs of the sender. 379 +----+ LSP1 +----+ 380 +-----+ | PE1|====================| PE2| +-----+ 381 | |----| | | |----| | 382 | CE1 | |............PW................| | CE2 | 383 | |----| | | |----| | 384 +-----+ | |====================| | +-----+ 385 +----+ LSP2 +----+ 386 Figure 6: PSN binding operation in SS-PW environment 388 As outlined previously, there are two types of binding request: 389 congruent and strict. 391 In strict binding, a PE (e.g., PE1) will mandate the other PE (e.g., 392 PE2) to use a specified tunnel/LSP (e.g. LSP1) as the PSN tunnel on 393 the reverse direction. In the PSN Tunnel Binding TLV, the S-bit MUST 394 be set, the C-bit MUST be reset, and the Source and Destination IDs/ 395 Numbers MUST be filled. 397 On receive, if the S-bit is set, other than following the processing 398 procedure defined in Section 5.3.3 of [RFC4447], the receiving PE 399 (i.e. PE2) needs to determine whether to accept the indicated 400 tunnel/LSP in PSN Tunnel Sub-TLV. 402 If the receiving PE (PE2) is also an active PE, and may have 403 initiated the PSN binding requests to the other PE (PE1), if the 404 received PSN tunnel/LSP is the same as it has been sent in the Label 405 Mapping message by PE2, then the signaling has converged on a 406 mutually agreed Tunnel/LSP. The binding operation is completed. 408 Otherwise, the receiving PE (PE2) MUST compare its own Node ID 409 against the received Source Node ID. If it is numerically lower, the 410 PE (PE2) will reply a Label Mapping message to complete the PW setup 411 and confirm the binding request. The PSN Tunnel Binding TLV in the 412 message MUST contain the same Source and Destination IDs/Numbers as 413 in the received binding request, in the appropriate order. On the 414 other hand, if the receiving PE (PE2) has a Node ID that is 415 numerically higher than the Source Node ID carried in the PSN Tunnel 416 Binding TLV, it MUST reply a Label Release message with status code 417 set to "Reject to use the suggested tunnel/LSPs" and the received PSN 418 Tunnel Binding TLV, and the PW will not be established. 420 To support congruent binding, the receiving PE can select the 421 appropriated PSN tunnel/LSP for the reverse direction of the PW, so 422 long as the forwarding and reverse PSNs share the same route. 424 Initially, a PE (PE1) sends a Label Mapping message to the remote PE 425 (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit reset, 426 and the appropriate Source and Destination IDs/Numbers. In case of 427 unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the 428 Source IDs/Numbers, the Destination IDs/Numbers are set to zero and 429 left for PE2 to fill when responding the Label Mapping message. 431 On receive, since PE2 is also an active PE, and may have initiated 432 the PSN binding requests to the other PE (PE1), if the received PSN 433 tunnel/LSP has the same route as the one that has been sent in the 434 Label Mapping message to PE1, then the signaling has converged. The 435 binding operation is completed. 437 Otherwise, it needs to compare its own Node ID against the received 438 Source Node ID. If it's numerically lower, PE2 needs to find/ 439 establish a tunnel/LSP that meets the congruent constraint, and reply 440 a Label Mapping message with a PSN Binding TLV that contains the 441 Source and Destination IDs/Numbers in the appropriate order. On the 442 other hand, if the receiving PE (PE2) has a Node ID that is 443 numerically higher than the Source Node ID carried in the PSN Tunnel 444 Binding TLV, it MUST reply a Label Release message with status code 445 set to "Reject to use the suggested tunnel/LSPs" and the received PSN 446 Tunnel Binding TLV. 448 In both strict and congruent bindings, if T-bit is set, the LSP 449 Number field MUST be set to zero. Otherwise, the field MUST contain 450 the actual LSP number for the associated PSN LSP. 452 After a PW established, the operators may choose to move the PW's 453 from the current tunnel/LSPs. Or, the underlying PSN is broken due 454 to network failure. In this scenario, a new Label Mapping message 455 MUST be sent to update the changes. Note that when T-bit is set, the 456 working LSP broken will not trigger to update the changes if there 457 are protection LSP's. 459 The message may carry a new PSN Tunnel Binding TLV, which contains 460 the new Source and Destination Numbers/IDs. The handling of the new 461 message should be identical to what has been described in this 462 section. 464 However, if the new Label Binding message does not contain the PSN 465 Tunnel Binding TLV, it declares the removal of any congruent/strict 466 constraints. The PEs may not map the PW to the underlying PSN on 467 purpose, the current independent PW to PSN binding will be used. 469 Further, as an implementation option, the PEs should not remove the 470 traffic from an operational PW, until the completion of the 471 underlying PSN tunnel/LSP changes. 473 5. PSN Binding Operation for MS-PW 475 MS-PW uses FEC 129 for PW setup. We refer the operation to Figure-6. 477 +-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+ 478 +---+ |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2| +---+ 479 | |---| | | | | | | |---| | 480 |CE1| |......................PW....................| |CE2| 481 | |---| | | | | | | |---| | 482 +---+ | |======| |======| |======| | +---+ 483 +-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+ 485 Figure 7: PSN binding operation in MS-PW environment 487 When an active PE (that is, T-PE1) starts to signal for a MS-PW, a 488 PSN Tunnel Binding TLV MUST be carried in the Label Mapping message 489 and sent to the adjacent S-PE (that is, S-PE1). The PSN Tunnel 490 Binding TLV includes the PSN Tunnel sub-TLV that carries the desired 491 tunnel/LSP of T-PE1's. 493 For strict binding, the initiating PE MUST set the S-bit, reset the 494 C-bit and indicates the binding tunnel/LSP to the next-hop S-PE. 496 When S-PE1 receives the Label Mapping message, S-PE1 needs to 497 determine if the signaling is for forward or reverse direction, as 498 defined in Section 6.2.3 of [I-D.ietf-pwe3-dynamic-ms-pw]. 500 If the Label Mapping message is for forward direction, and S-PE1 501 accepts the requested tunnel/LSPs from T-PE1, S-PE1 must save the 502 tunnel/LSP information for reverse-direction processing later on. If 503 the PSN binding request is not acceptable, S-PE1 MUST reply a Label 504 Release Message to the upstream PE (T-PE1) with Status Code set to 505 "Reject to use the suggested tunnel/LSPs". 507 Otherwise, S-PE1 relays the Label Mapping message to the next S-PE 508 (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the 509 information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and 510 subsequent S-PEs will repeat the same operation until the Label 511 Mapping message reaches to the remote T-PE (that is, T-PE2). 513 If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label 514 Mapping message to initiate to the binding process on the reverse 515 direction. The Label Mapping message contains the received PSN 516 Tunnel Binding TLV for confirmation purposes. 518 When its upstream S-PE (S-PE2) receives the Label Mapping message, 519 the S-PE relays the Label Mapping message to its upstream adjacent 520 S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in 521 the PSN Tunnel sub-TLV. The same procedure will be applied on 522 subsequent S-PEs, until the message reaches to T-PE1 to complete the 523 PSN binding setup. 525 During the binding process, if any PE does not agree to the requested 526 tunnel/LSPs, it can send a Label Release Message to its upstream 527 adjacent PE with Status Code set to "Reject to use the suggested 528 tunnel/LSPs". 530 For congruent binding, the initiating PE (T-PE1) MUST set the C-bit, 531 reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel 532 sub-TLV to the next-hop S-PE (S-PE1). 534 During the MS-PW setup, the PEs have the option to ignore the 535 suggested tunnel/LSP, and select another tunnel/LSP for the segment 536 PW between itself and its upstream PE on reverse direction only if 537 the tunnel/LSP is congruent with the forwarding one. Otherwise, the 538 procedure is the same as the strict binding. 540 The tunnel/LSPs may change after a MS-PW being established. When a 541 tunnel/LSP has changed, the PE that detects the change SHOULD select 542 an alternative tunnel/LSP for temporary use while negotiating with 543 other PEs following the procedure described in this section. 545 6. Security Considerations 547 The ability to control which LSP to carry traffic from a PW can be a 548 potential security risk both for denial of service and traffic 549 interception. It is RECOMMENDED that PEs do not accept the use of 550 LSPs identified in the PSN Tunnel Binding TLV unless the LSP end 551 points match the PW or PW segment end points. Furthermore, where 552 security of the network is believed to be at risk, it is RECOMMENDED 553 that PEs implement the LDP security mechanisms described in [RFC5036] 554 and [RFC5920]. 556 7. IANA Considerations 558 7.1. LDP TLV Types 560 This document defines new TLV [Section 2.1 of this document] for 561 inclusion in LDP Label Mapping message. IANA is required to assign 562 TLV type value to the new defined TLVs from LDP "TLV Type Name Space" 563 registry. 565 7.1.1. PSN Tunnel Sub-TLVs 567 This document defines two sub-TLVs [Section 2.1.1 of this document] 568 for PSN Tunnel Binding TLV. IANA is required to create a new 569 registry ("PSN Tunnel Sub-TLV Name Space") for PSN Tunnel sub-TLVs 570 and to assign Sub-TLV type values to the following sub-TLVs. 572 IPv4 PSN Tunnel sub-TLV - 0x01 (to be confirmed by IANA) 574 IPv6 PSN Tunnel sub-TLV - 0x02 (to be confirmed by IANA) 576 7.2. LDP Status Codes 578 This document defines a new LDP status codes, IANA is required to 579 assigned status codes to these new defined codes from LDP "STATUS 580 CODE NAME SPACE" registry. 582 "Reject to use the suggested tunnel/LSPs" - 0x0000003B (to be 583 confirmed by IANA) 585 8. Acknowledgements 587 The authors would like to thank Adrian Farrel, Kamran Raza, Xinchun 588 Guo, Mingming Zhu and Li Xue for their comments and help in preparing 589 this document. Also this draft benefits from the discussions with 590 Nabil Bitar, Paul Doolan, Frederic Journay, Andy Malis, Curtis 591 Villamizar and Luca Martini. 593 9. References 595 9.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 601 Heron, "Pseudowire Setup and Maintenance Using the Label 602 Distribution Protocol (LDP)", RFC 4447, April 2006. 604 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 605 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 607 9.2. Informative References 609 [I-D.ietf-pwe3-dynamic-ms-pw] 610 Martini, L., Bocci, M., and F. Balus, "Dynamic Placement 611 of Multi Segment Pseudowires", 612 draft-ietf-pwe3-dynamic-ms-pw-15 (work in progress), 613 June 2012. 615 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 616 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 617 Tunnels", RFC 3209, December 2001. 619 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 620 (GMPLS) Signaling Functional Description", RFC 3471, 621 January 2003. 623 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 624 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 625 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 627 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 628 Edge (PWE3) Architecture", RFC 3985, March 2005. 630 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 631 Specification", RFC 5036, October 2007. 633 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 634 Networks", RFC 5920, July 2010. 636 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 637 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 639 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 640 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 641 Framework", RFC 6373, September 2011. 643 Authors' Addresses 645 Mach(Guoyi) Chen 646 Huawei Technologies Co., Ltd 647 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 648 Beijing 100095 649 China 651 Email: mach@huawei.com 652 Wei Cao 653 Huawei Technologies Co., Ltd 654 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 655 Beijing 100095 656 China 658 Email: wayne.caowei@huawei.com 660 Attila Takacs 661 Ericsson 662 Laborc u. 1. 663 Budapest 1037 664 Hungary 666 Email: attila.takacs@ericsson.com 668 Ping Pan 669 Infinera 670 169 West Java Drive, Sunnyvale, CA 94089 671 US 673 Email: ppan@infinera.com