idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-17.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2013) is 3935 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) == Missing Reference: 'RFCxxxx' is mentioned on line 716, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini (Ed.) 3 Internet Draft Cisco Systems Inc. 4 Expiration Date: December 2013 5 Intended status: Standards Track Matthew Bocci (Ed.) 6 Florin Balus (Ed.) 7 Alcatel-Lucent 9 June 19, 2013 11 Dynamic Placement of Multi Segment Pseudowires 13 draft-ietf-pwe3-dynamic-ms-pw-17.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 19, 2013 38 Abstract 40 There is a requirement for service providers to be able to extend the 41 reach of pseudowires (PW) across multiple Packet Switched Network 42 domains. A Multi-Segment PW is defined as a set of two or more 43 contiguous PW segments that behave and function as a single point- 44 to-point PW. This document describes extensions to the PW control 45 protocol to dynamically place the segments of the multi segment 46 pseudowire among a set of Provider Edge (PE) routers. 48 Table of Contents 50 1 Major Co-authors ..................................... 3 51 2 Acknowledgements ..................................... 3 52 3 Introduction ......................................... 3 53 3.1 Scope ................................................ 3 54 3.2 Specification of Requirements ........................ 3 55 3.3 Terminology .......................................... 4 56 3.4 Architecture Overview ................................ 4 57 4 Applicability ........................................ 6 58 4.1 Changes to Existing PW Signaling ..................... 6 59 5 PW Layer 2 Addressing ................................ 6 60 5.1 Attachment Circuit Addressing ........................ 6 61 5.2 S-PE Addressing ...................................... 7 62 6 Dynamic Placement of MS-PWs .......................... 7 63 6.1 Pseudowire Routing Procedures ........................ 8 64 6.1.1 AII PW Routing Table Lookup Aggregation Rules ........ 8 65 6.1.2 PW Static Route ...................................... 9 66 6.1.3 Dynamic Advertisement with BGP ....................... 9 67 6.2 LDP Signaling ........................................ 10 68 6.2.1 MS-PW Bandwidth Signaling ............................ 10 69 6.2.2 Equal Cost Multi Path (ECMP) in PW Routing ........... 12 70 6.2.3 Active/Passive T-PE Election Procedure ............... 12 71 6.2.4 Detailed Signaling Procedures ........................ 13 72 7 Failure Handling Procedures .......................... 14 73 7.1 PSN Failures ......................................... 14 74 7.2 S-PE Specfic Failures ................................ 14 75 7.3 PW Reachability Changes .............................. 15 76 8 Operations and Maintenance (OAM) ..................... 16 77 9 Security Considerations .............................. 16 78 10 IANA Considerations .................................. 16 79 10.1 LDP TLV TYPE NAME SPACE .............................. 17 80 10.2 LDP Status Codes ..................................... 17 81 10.3 BGP SAFI ............................................. 17 82 11 Normative References ................................. 17 83 12 Informative References ............................... 18 84 13 Author's Addresses ................................... 18 86 1. Major Co-authors 88 The editors gratefully acknowledge the following additional co- 89 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 90 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 91 Sugimoto. 93 2. Acknowledgements 95 The editors also gratefully acknowledge the input of the following 96 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 97 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 99 3. Introduction 101 3.1. Scope 103 [RFC5254] describes the service provider requirements for extending 104 the reach of pseudowires across multiple PSN domains. This is 105 achieved using a Multi-segment Pseudowire (MS-PW). An MS-PW is 106 defined as a set of two or more contiguous PW segments that behave 107 and function as a single point-to-point PW. This architecture is 108 described in [RFC5659]. 110 The procedures for establishing PWs that extend across a single PSN 111 domain are described in [RFC4447], while procedures for setting up 112 PWs across multiple PSN domains, or control plane domains are 113 described in [RFC6073]. 115 The purpose of this document is to specify extensions to the 116 pseudowire control protocol [RFC4447], and [RFC6073] procedures, to 117 enable multi- segment PWs to be dynamically placed. The proposed 118 procedures follow the guidelines defined in [RFC5036] and enable the 119 reuse of existing TLVs, 120 and procedures defined for SS-PWs in [RFC4447]. 122 3.2. Specification of Requirements 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119. 128 3.3. Terminology 130 [RFC5659] provides terminology for multi-segment pseudowires. 132 This document defines the following additional terms: 134 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 135 assumes the active signaling role and initiates the signaling for 136 multi-segment PW. 137 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 138 assumes the passive signaling role. It waits and responds to the 139 multi-segment PW signaling message in the reverse direction. 140 - Forward Direction: ST-PE to TT-PE. 141 - Reverse Direction: TT-PE to ST-PE 142 - Forwarding Direction: Direction of control plane, signaling flow 143 - Pseudowire Routing (PW routing). The dynamic placement of the 144 segments that compose an MS-PW, as well as the automatic 145 selection of S-PEs. 147 3.4. Architecture Overview 149 The following figure describes the reference models which are derived 150 from [RFC5659] to support PW emulated services across multi-segment 151 PWs. 153 Native |<-------------Pseudowire------------>| Native 154 Service | | Service 155 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 156 | V V V V V V | 157 | +-----+ +-----+ +-----+ 158 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 159 | |-------|.....PW.Seg't1........PW Seg't3......|----------| | 160 | CE1| | | | | | | | | |CE2 | 161 | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | 162 +----+ | | |=========| |=========| | | +----+ 163 ^ +-----+ +-----+ +-----+ ^ 164 | Provider Edge 1 ^ Provider Edge 2 | 165 | | | 166 | | | 167 | PW switching point | 168 | | 169 |<---------------- Emulated Service -------------------->| 171 Figure 1: PW switching Reference Model 173 Figure 1 shows the architecture for a simple multi-segment case. T- 174 PE1 and T-PE2 provide an emulated service to CE1 and CE2. These PEs 175 reside in different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 176 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 177 across PSN2. PWs are used to connect the attachment circuits (ACs) 178 attached to T-PE1 to the corresponding AC attached to T-PE2. A PW on 179 the tunnel across PSN1 is connected to a PW in the tunnel across PSN2 180 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and 181 T-PE2. S-PE1 is therefore the PW switching point and is referred to 182 as the switching provider edge (S-PE). PW Segment 1 and PW Segment 3 183 are segments of the same MS-PW while PW Segment 2 and PW Segment 4 184 are segments of another MS-PW. PW segments of the same MS-PW (e.g., 185 PW segment 1 and PW segment 3) MUST be of the same PW type, and PSN 186 tunnels (e.g., PSN1 and PSN2) can be the same or different 187 technology. An S-PE switches an MS-PW from one segment to another 188 based on the PW identifiers. ( PWid , or AII ) How the PW PDUs are 189 switched at the S-PE depends on the PSN tunnel technology: in case of 190 an MPLS PSN to another MPLS PSN PW switching the operation is a 191 standard MPLS label switch operation. 193 Note that although Figure 1 only shows a single S-PE, a PW may 194 transit more one S-PE along its path. For instance, in the multi- 195 provider case, there can be an S-PE at the border of one provider 196 domain and another S-PE at the border of the other provider domain. 198 4. Applicability 200 In this document we describe the case where the PSNs carrying the 201 SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions 202 with an IP PSN using L2TPv3 as described in [RFC6073] section 7.4 are 203 left for further study. 205 4.1. Changes to Existing PW Signaling 207 The procedures described in this document make use of existing LDP 208 TLVs and related PW signaling procedures described in [RFC4447] and 209 [RFC6073]. The following OPTIONAL TLVs are also defined: 210 - A Bandwidth TLV to address QoS Signaling requirements (see "MS-PW 211 Next Hop Bandwidth Signaling" section for details). 213 5. PW Layer 2 Addressing 215 Single segment pseudowires on an MPLS PSN can use attachment circuit 216 identifiers for a PW using FEC 129. In the case of a dynamically 217 placed MS-PW, there is a requirement for the identifiers for the 218 attachment circuits to be globally unique, for the purposes of 219 reachability and manageability of the PW. Referencing figure 1 220 above, individual globally unique addresses MUST be allocated to all 221 the ACs and S-PEs composing an MS-PW. 223 5.1. Attachment Circuit Addressing 225 The attachment circuit addressing is derived from [RFC5003] AII type 226 2 shown here: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | AII Type=02 | Length | Global ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Global ID (contd.) | Prefix | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Prefix (contd.) | AC ID | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | AC ID | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 AII type 2 based addressing schemes permit varying levels of AII 241 summarization, thus reducing the scaling burden on PW routing. AII 242 Type 2 based PW addressing is suitable for point-to-point 243 provisioning models where it is not required to auto-discover address 244 at Target T-PE (knows the address in priori by provisioning). 246 Implementations of the following procedure MUST interpret the AII 247 type to determine the meaning of the address format of the AII, 248 irrespective of the number of segments in the MS-PW. All segments of 249 the PW MUST be signaled with same AII Type. 251 A unique combination of Global ID, Prefix, and AC ID parts of the AII 252 type 2 are assigned to each AC. In general, the same global ID and 253 prefix are be assigned for all ACs belonging to the same T-PE. This 254 is not a strict requirement, however. A particular T-PE might have 255 more than one prefix assigned to it, and likewise a fully qualified 256 AII with the same Global ID/Prefix but different AC IDs might belong 257 to different T-PEs. 259 For the purpose of MS-PWs, the AII MUST be globally unique across all 260 interconnected PW domains. 262 5.2. S-PE Addressing 264 Each S-PE MUST be uniquely addressable in terms of pseudowires in 265 order to populate the switching point PE TLV specified in [RFC6073]. 266 For this purpose, at least one AI address of the format similar to 267 AII type 2 [RFC5003] composed of the Global ID, and Prefix part, 268 only, MUST be assigned to each S-PE. 270 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned 271 with an S-PE address, then on receiving a Dynamic MS-PW label mapping 272 message the S-PE MUST return a Label Release with the 273 "LDP_RESOURCES_UNAVAILABLE" ( 0x38)" status code. 275 6. Dynamic Placement of MS-PWs 277 [RFC6073] describes a procedure for concatenating multiple 278 pseudowires together. This procedure requires each S-PE to be 279 manually configured with the information required for each segment of 280 the MS-PW. The procedures in the following sections describe a method 281 to extend [RFC6073] by allowing the automatic selection of pre- 282 defined S-PEs, and dynamically establishing a MS-PW between two T- 283 PEs. 285 6.1. Pseudowire Routing Procedures 287 The AII type 2 described above contains a Global ID, Prefix, and AC 288 ID. The TAII is used by S-PEs to determine the next SS-PW destination 289 for LDP signaling. 291 Once an S-PE receives a MS-PW label mapping message containing a TAII 292 with an AII that is not locally present, the S-PE performs a lookup 293 in a PW AII routing table. If this lookup results in an IP address 294 for the next-hop PE with reachability information for the AII in 295 question, then the S-PE will initiate the necessary LDP messaging 296 procedure to set-up the next PW segment. If the PW AII routing table 297 lookup does not result in a IP address for a next-hop PE, the 298 destination AII has become unreachable, and the PW setup MUST fail. 299 In this case the next PW segment is considered un-provisioned, and a 300 label release MUST be returned to the T-PE with a status message of 301 "AII Unreachable". 303 If the TAI of a MS-PW label mapping message received by a PE contains 304 the prefix matching a locally-provisioned prefix on that PE, but an 305 AC ID that is not provisioned, then the LDP liberal label retention 306 procedures apply, and the label mapping message is retained. 308 To allow for dynamic end-to-end signaling of MS-PWs, information must 309 be present in S-PEs to support the determination of the next PW 310 signaling hop. Such information can be provisioned (equivalent to a 311 static route) on each S-PE, or disseminated via regular routing 312 protocols (e.g. BGP). 314 6.1.1. AII PW Routing Table Lookup Aggregation Rules 316 All PEs capable of dynamic MS-PW path selection MUST build a PW AII 317 routing table to be used for PW next-hop selection. 319 The PW addressing scheme (AII type 2 in [RFC5003]) consists of a 320 Global ID, a 32 bit prefix and a 32 bit Attachment Circuit ID. 322 An aggregation scheme similar to that used for classless IPv4 323 addresses can be employed. An (8 bits) length mask is specified as a 324 number ranging from 0 to 96 that indicates which Most Significant 325 Bits (MSB) are relevant in the address field when performing the PW 326 address matching algorithm. 328 0 31 32 63 64 95 (bits) 329 +-----------+--------+--------+ 330 | Global ID | Prefix | AC ID | 331 +-----------+--------+--------+ 332 During the signaling phase, the content of the (fully qualified) TAII 333 type 2 field from the FEC129 TLV is compared against routes from the 334 PW Routing table. Similar with the IPv4 case, the route with the 335 longest match is selected, determining the next signaling hop and 336 implicitly the next PW Segment to be signaled. 338 6.1.2. PW Static Route 340 For the purpose of determining the next signaling hop for a segment 341 of the pseudowire, the PEs MAY be provisioned with fixed route 342 entries in the PW next hop routing table. The static PW entries will 343 follow all the addressing rules and aggregation rules described in 344 the previous sections. The most common use of PW static provisioned 345 routes is this example of the "default" route entry as follows: 347 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 348 Hop = S-PE1 350 6.1.3. Dynamic Advertisement with BGP 352 Any suitable routing protocol capable of carrying external routing 353 information MAY be used to propagate MS-PW path information among S- 354 PEs and T-PEs. However, T-PE, and S-PEs, MAY choose to use Border 355 Gateway Protocol (BGP) [RFC4760] to propagate PW address information 356 throughout the PSN. 358 Contrary to other l2vpn signaling methods that use BGP [RFC6074], in 359 the case of the dynamically placed MS-PW, the source T-PE knows a- 360 priori (by provisioning) the AC ID on the terminating T-PE to use in 361 signaling. Hence there is no need to advertise a "fully qualified" 96 362 bit address on a per PW Attachment Circuit basis. Only the T-PE 363 Global ID, Prefix, and prefix length needs to be advertised as part 364 of well known BGP procedures - see [RFC4760]. 366 As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this 367 information to obtain the first S-PE hop (i.e., first BGP next hop) 368 to where the first PW segment will be established. Any subsequent S- 369 PEs will use the same information (i.e. the next BGP next-hop(s)) to 370 obtain the next-signaling-hop(s) on the path to the TT-PE. 372 The PW dynamic path NLRI is advertised in BGP UPDATE messages using 373 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, 374 SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6 375 (pending IANA allocation)). A route target MAY also be advertised 376 along with the NLRI. 378 The Next Hop field of MP_REACH_NLRI attribute SHALL be interpreted as 379 an IPv4 address, whenever the length of the NextHop address is 4 380 octets, and as a IPv6 address, whenever the length of the NextHop 381 address is 16 octets. 383 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 384 comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, 385 and the AC-ID, and encoded as defined in section 4 of [RFC4760]. 387 This NLRI is structured as follows: 389 Bit 390 0 7 8 71 72 103 104 135 136 167 391 +------+----------------+-----------+--------+--------+ 392 |Length| Route Dist | Global ID | Prefix | AC ID | 393 +------+----------------+-----------+--------+--------+ 395 The Length field is the prefix length of the Route Distinguisher + 396 Global ID + Prefix + AC-ID in bits. 398 Except for the default PW route, which is encoded as a 0 length 399 prefix, the minimum value of the length field is 96 bits. Lengths of 400 128 bits to 159 bits are invalid as the AC ID field cannot be 401 aggregated. The maximum value of the Length field is 160 bits. BGP 402 advertisements received with invalid prefix lengths MUST be rejected 403 as having a bad packet format. 405 6.2. LDP Signaling 407 The LDP signaling procedures are described in [RFC4447] and expanded 408 in [RFC6073]. No new LDP Signaling components are required for 409 setting up a dynamically placed MS-PW. However some optional 410 signaling extensions are described below. 412 6.2.1. MS-PW Bandwidth Signaling 414 In order to enable the QoS objectives for a PW to be met on a 415 segment, a PSN tunnel MUST be selected that can support at least the 416 required class of service and that has sufficient bandwidth 417 available. 419 PW QoS objectives can thus be met where the next hop for a PW segment 420 is explicitly configured at each PE, whether the PE is a T-PE or an 421 S-PE in the case of a segmented PW without dynamic path selection (as 422 per RFC6073). In these cases, it is possible to explicitly configure 423 the bandwidth required for a PW so that the T-PE or S-PE can reserve 424 that bandwidth on the PSN tunnel. 426 Where dynamic path selection is used and therefore the next-hop is 427 not explicitly configured by the operator at the S-PE, a mechanism is 428 required to signal the bandwidth for the PW from the T-PE to the S- 429 PEs. This is accomplished by including an OPTIONAL PW Bandwidth TLV. 430 The PW Bandwidth TLV is specified as follows: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |1|0| PW BW TLV (0x096E) | TLV Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Forward SENDER_TSPEC | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Reverse SENDER_TSPEC | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 The complete definitions of the content of the SENDER_TSPEC objects 443 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 444 the data path in the direction of ST-PE to TT-PE. The reverse 445 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 447 In the forward direction, after a next hop selection is determined, a 448 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 449 an appropriate PSN tunnel towards the next signaling hop. If such a 450 tunnel exists, the MS-PW signaling procedures are invoked with the 451 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 452 tunnel, any tunnel which points to a next hop equivalent to the next 453 hop selected will be included in the search.(The LDP address TLV is 454 used to determine the next hop equivalence) 456 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 457 selected, the S/T-PE MUST request the appropriate resources from the 458 PSN. The resources described in the reverse SENDER_TSPEC are 459 allocated from the PSN toward the originator of the message or 460 previous hop. When resources are allocated from the PSN for a 461 specific PW, then the PSN SHOULD account for the PW usage of the 462 resources. 464 In the case where PSN resources towards the previous hop are not 465 available the following procedure MUST be followed: 467 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 468 the PSN tunnel. 469 -ii. The S-PE MAY attempt to setup another PSN tunnel to 470 accommodate the new PW QoS requirements. 471 -iii. If the S-PE cannot get enough resources to setup the segment 472 in the MS-PW a label release MUST be returned to the 473 previous hop with a status message of "Bandwidth resources 474 unavailable" 476 In the latter case, the T-PE receiving the status message MUST also 477 withdraw the corresponding PW label mapping for the opposite 478 direction if it has already been successfully setup. 480 If an ST-PE receives a label mapping message the following procedure 481 MUST be followed: 483 If the ST-PE has already sent a label mapping message for this PW 484 then the ST-PE MUST check that this label mapping message originated 485 from the same LDP peer to which the corresponding label mapping 486 message for this particular PW was sent. If it is the same peer, the 487 PW is established. If it is a different peer, then ST-PE MUST send a 488 label release message, with a status code of "Duplicate AII" to the 489 PE that originate the LDP label mapping message. 491 If the PE has not yet sent a label mapping message for this 492 particular PW , then it MUST send the label mapping message to this 493 same LDP peer, regardless of what the PW TAII routing lookup result 494 is. 496 6.2.2. Equal Cost Multi Path (ECMP) in PW Routing 498 A specific PW may find match with a PW route that may have multiple 499 next-hops associated with it. Multiple next-hops may be either 500 configured explicitly as static routes or may be learned through BGP 501 routing procedures. Implementations at and S-PE or T-PE MAY use 502 selection algorithms, such as CRC32 on the FEC TLV, for load 503 balancing of PWs across multiple next-hops. The details of such 504 selection algorithms are outside the scope of this document. 506 6.2.3. Active/Passive T-PE Election Procedure 508 When a MS-PW is signaled, each T-PE might independently initiate 509 signaling the MS-PW. This could result in a different path being used 510 be each direction of the PW. To avoid this situation one of the T-PE 511 MUST start the PW signaling (active role), while the other T-PE waits 512 to receive the LDP label mapping message before sending the LDP label 513 mapping message for the reverse direction of the PW (passive role). 514 The Active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be 515 identified before signaling begins for a given MS-PW. 517 The determination of which T-PE assume the active role SHOULD be done 518 as follows: the SAII and TAII are compared as unsigned integers, if 519 the SAII is bigger then the T-PE assumes the active role. 521 6.2.4. Detailed Signaling Procedures 523 On receiving a label mapping message, the S-PE MUST inspect the FEC 524 TLV. If the receiving node has no local AII matching the TAII for 525 that label mapping then the finagling should be forwarded on to 526 another S-PE or T-PE. The S-PE will check if the FEC is already 527 installed for the forward direction: 528 - If it is already installed, and the received mapping was received 529 from the same LDP peer where the forward LDP label mapping was 530 sent, then this label mapping represents signaling in the reverse 531 direction for this MS-PW segment. 532 - If it is already installed, and the received mapping was received 533 from a different LDP peer where the forward LDP label mapping was 534 sent, then the received label mapping MUST be released with 535 status code as "PW_LOOP_DETECTED". If the already installed PW 536 segment has not signaled explicit intent for active role then 537 installed PW segment MUST be released with status code 538 "PW_LOOP_DETECTED". 539 - If the FEC is not already installed, then this represents 540 signaling in the forward direction. 542 For the forward direction: 543 -i. Determine the next hop S-PE or T-PE according to the 544 procedures above. If next-hop reachability is not found in 545 the PW AII routing table in the S-PE then label release MUST 546 be sent with status code "AII_UNREACHABLE". If the next-hop 547 S-PE or T-PE is found and is the same LDP Peer that has sent 548 the label mapping message then a label Release MUST be 549 returned with the status code "PW_LOOP_DETECTED". If the 550 SAII in the received label mapping is local to the S-PE then 551 a label released MUST be returned with status code 552 "PW_LOOP_DETECTED". 553 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 554 If no tunnel exists to the next hop S-PE or T-PE the S-PE 555 MAY attempt to setup a PSN tunnel. 557 -iii. Check that a PSN tunnel exists to the previous hop. If no 558 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 559 attempt to setup a PSN tunnel. 560 -iv. If the S-PE cannot get enough PSN resources to setup the 561 segment to the next or previous S-PE or T-PE, a label 562 release MUST be returned to the T-PE with a status message 563 of "Resources Unavailable". 564 -v. If the label mapping message contains a Bandwidth TLV, 565 allocate the required resources on the PSN tunnels in the 566 forward and reverse directions according to the procedures 567 above. 568 -vi. Allocate a new PW label for the forward direction. 569 -vii. Install the FEC for the forward direction. 570 -viii. Send the label mapping message with the new forward label 571 and the FEC to the next hop S-PE/T-PE. 573 For the reverse direction: 574 -i. Install the received FEC for the reverse direction. 575 -ii. Determine the next signaling hop by referencing the LDP 576 sessions used to setup the PW in the Forward direction. 577 -iii. Allocate a new PW label for the reverse direction. 578 -iv. Install the FEC for the reverse direction. 579 -v. Send the label mapping message with a new label and the FEC 580 to the next hop S-PE/ST-PE. 582 7. Failure Handling Procedures 584 7.1. PSN Failures 586 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 587 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 588 follow the procedures defined in Section 8 of [RFC6073]. 590 7.2. S-PE Specfic Failures 592 For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be 593 followed. A T-PE or S-PE may receive an unsolicited label release 594 message from another S-PE or T-PE with various failure codes such 595 "LOOP_DETECTED", "PW_LOOP_DETECTED", "RESOURCE_UNAVAILBALE", 596 "BAD_STRICT_HOP", "AII_UNREACHABLE" etc. All these failure codes 597 indicate a generic class of PW failures at an S-PE or T-PE. 599 When an unsolicited label release message with such a failure status 600 code is received at T-PE then the T-PE MUST re-attempt to establish 601 the PW immediately. However the T-PE MUST throttle its PW setup 602 message retry attempts with an exponential backoff in situations 603 where PW setup messages are being constantly released. It is also 604 recommended that a T-PE detecting such a situation take action to 605 notify an operator. 607 S-PEs that receive an unsolicited label release message with a 608 failure status code should follow the following procedures: 610 -i. If label release is received from an S-PE or T-PE in the 611 forward signaling direction then S-PE MUST tear down both 612 segments of the PW. The status code received in label 613 release SHOULD be propagated while sending label release for 614 the next-segment. 615 -ii. If the label release is received from an S-PE or T-PE in the 616 reverse Signaling direction do as follows: 618 If the PW is set-up at S-PE with an Explicit Intent of Role 619 then label release MUST be sent to the next PW segment with 620 same status code. The forward signaling path SHOULD NOT be 621 tear down in such case. 623 If the PW is set-up at S-PE without an Explicit Intent of 624 Role then tear down both segments of the PW as described in 625 i. 627 7.3. PW Reachability Changes 629 In general an established MS-PW will not be affected by next-hop 630 changes in L2 PW reachability information. 632 If there is a change in next-hop of the L2 PW reachability 633 information in the forward direction, the T-PE MAY elect to tear down 634 the MS-PW by sending a label withdraw message to downstream S-PE or 635 T-PE. The teardown MUST be also accompanied by a unsolicited label 636 release message, and will be followed by and attempt to re-establish 637 of the MS-PW by T-PE. 639 If there is a change in the L2 PW reachability information in the 640 forward direction at S-PE, the S-PE MAY elect to tear down the MS-PW 641 in both directions. A label withdrawal is sent on each direction 642 followed by a unsolicited label release. The unsolicited label 643 releases MUST be accompanied by the Status code "AII_UNREACHABLE". 644 This procedure is OPTIONAL. 646 A change in L2 reachability information in the reverse direction has 647 no effect on an MS-PW. 649 8. Operations and Maintenance (OAM) 651 The OAM procedures defined in [RFC6073] may be used also for MS-PWs. 652 A PW switching point TLV is used [RFC6073] to record the switching 653 points that the PW traverses. 655 In the case of a MS-PW where the PW Endpoints are identified though 656 using a globally unique, FEC 129-based AII addresses, there is no 657 PWID defined on a per segment basis. Each individual PW segment is 658 identified by the address of adjacent S-PE(s) in conjunction with the 659 SAI and TAI. In this case, the following type MUST be used in place 660 of type 0x01 in the PW switching point TLV: 662 Type Length Description 663 0x06 14 L2 PW address of PW Switching Point 665 The above field MUST be included together with type 0x02 in the TLV 666 once per individual PW Switching Point following the same rules and 667 procedures as described in [RFC6073]. A more detailed description of 668 this field is also in setion 7.4.1 of [RFC6073] 670 9. Security Considerations 672 This document specifies only extensions to the protocols already 673 defined in [RFC4447], and [RFC6073]. Each such protocol may have its 674 own set of security issues, but those issues are not affected by the 675 extensions specified herein. Note that the protocols for dynamically 676 distributing PW Layer 2 reachability information may have their own 677 security issues, however those protocols specifications are outside 678 the scope of this document. 680 10. IANA Considerations 682 IANA needs to correct a minor error in the registry "Pseudowire 683 Switching Point PE sub-TLV Type". The entry 0x06 "L2 PW address of 684 the PW Switching Point" should have Length 14. 686 10.1. LDP TLV TYPE NAME SPACE 688 This document uses several new LDP TLV types, IANA already maintains 689 a registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 690 following values are suggested for assignment: 692 TLV type Description 693 0x096E Bandwidth TLV 695 10.2. LDP Status Codes 697 This document uses several new LDP status codes, IANA already 698 maintains a registry of name "STATUS CODE NAME SPACE" defined by 699 RFC5036. The following values have been pre-allocated: 701 Range/Value E Description Reference 702 ------------- ----- ---------------------- --------- 703 0x00000037 0 Bandwidth resources unavailable RFCxxxx 704 0x00000038 0 Resources Unavailable RFCxxxx 705 0x00000039 0 AII Unreachable RFCxxxx 707 10.3. BGP SAFI 709 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 710 Information used for Dynamic Placement of Multi-Segment Pseudiwires" 711 from the IANA "Subsequence Address Family Identifiers (SAFI)" 712 registry. The following value has been pre-allocated: 714 Value Description Reference 715 ----- ----------- --------- 716 6 Network Layer Reachability Information used [RFCxxxx] 717 for Dynamic Placement of Multi-Segment 718 Pseudowires 720 11. Normative References 722 [RFC6073] Martini et.al. "Segmented Pseudowire", RFC6073, 723 January 2011 725 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 726 Services", RFC 2210, September 1997 728 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" 729 RFC5036, October 2007 731 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 732 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 733 June 2005. 735 [RFC5003] "Attachment Individual Identifier (AII) Types for 736 Aggregation", Metz, et al, RFC5003, September 2007 738 12. Informative References 740 [RFC5254] Martini et al, "Requirements for Multi-Segment Pseudowire 741 Emulation Edge-to-Edge (PWE3)", 742 RFC5254, Bitar, Martini, Bocci, October 2008 744 [RFC5659] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 745 Emulation Edge-to-Edge", RFC5659,October 2009. 747 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 748 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 750 [RFC6074] E. Rosen, W. Luo, B. Davie, V. Radoaca, 751 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 752 rfc6074, January 2011 754 13. Author's Addresses 756 Luca Martini 757 Cisco Systems, Inc. 758 9155 East Nichols Avenue, Suite 400 759 Englewood, CO, 80112 760 e-mail: lmartini@cisco.com 762 Matthew Bocci 763 Alcatel-Lucent, 764 Voyager Place 765 Shoppenhangers Road 766 Maidenhead 767 Berks, UK 768 e-mail: matthew.bocci@alcatel-lucent.com 769 Florin Balus 770 Alcatel-Lucent 771 701 E. Middlefield Rd. 772 Mountain View, CA 94043 773 e-mail: florin.balus@alcatel-lucent.com 775 Nabil Bitar 776 Verizon 777 40 Sylvan Road 778 Waltham, MA 02145 779 e-mail: nabil.bitar@verizon.com 781 Himanshu Shah 782 Ciena Corp 783 35 Nagog Park, 784 Acton, MA 01720 785 e-mail: hshah@ciena.com 787 Mustapha Aissaoui 788 Alcatel-Lucent 789 600 March Road 790 Kanata 791 ON, Canada 792 e-mail: mustapha.aissaoui@alcatel-lucent.com 794 Jason Rusmisel 795 Alcatel-Lucent 796 600 March Road 797 Kanata 798 ON, Canada 799 e-mail: Jason.rusmisel@alcatel-lucent.com 801 Yetik Serbest 802 SBC Labs 803 9505 Arboretum Blvd. 804 Austin, TX 78759 805 e-mail: Yetik_serbest@labs.sbc.com 806 Andrew G. Malis 807 Verizon 808 117 West St. 809 Waltham, MA 02451 810 e-mail: andrew.g.malis@verizon.com 812 Chris Metz 813 Cisco Systems, Inc. 814 3700 Cisco Way 815 San Jose, Ca. 95134 816 e-mail: chmetz@cisco.com 818 David McDysan 819 Verizon 820 22001 Loudoun County Pkwy 821 Ashburn, VA, USA 20147 822 e-mail: dave.mcdysan@verizon.com 824 Jeff Sugimoto 825 Alcatel-Lucent 826 701 E. Middlefield Rd. 827 Mountain View, CA 94043 828 e-mail: jeffery.sugimoto@alcatel-lucent.com 830 Mike Duckett 831 Bellsouth 832 Lindbergh Center D481 833 575 Morosgo Dr 834 Atlanta, GA 30324 835 e-mail: mduckett@bellsouth.net 837 Mike Loomis 838 Alcatel-Lucent 839 701 E. Middlefield Rd. 840 Mountain View, CA 94043 841 e-mail: mike.loomis@alcatel-lucent.com 842 Paul Doolan 843 Mangrove Systems 844 IO Fairfield Blvd 845 Wallingford, CT, USA 06492 846 e-mail: pdoolan@mangrovesystems.com 848 Ping Pan 849 Hammerhead Systems 850 640 Clyde Court 851 Mountain View, CA, USA 94043 852 e-mail: ppan@hammerheadsystems.com 854 Prayson Pate 855 Overture Networks, Inc. 856 507 Airport Blvd, Suite 111 857 Morrisville, NC, USA 27560 858 e-mail: prayson.pate@overturenetworks.com 860 Vasile Radoaca 861 Alcatel-Lucent 862 Optics Divison, Westford, MA, USA 863 email: vasile.radoaca@alcatel-lucent.com 865 Yuichiro Wada 866 NTT Communications 867 3-20-2 Nishi-Shinjuku, Shinjuke-ku 868 Tokyo 163-1421, Japan 869 e-mail: yuichiro.wada@ntt.com 871 Yeongil Seo 872 Korea Telecom Corp. 873 463-1 Jeonmin-dong, Yusung-gu 874 Daejeon, Korea 875 e-mail: syi1@kt.co.kr 877 Copyright Notice 879 Copyright (c) 2012 IETF Trust and the persons identified as the 880 document authors. All rights reserved. 882 This document is subject to BCP 78 and the IETF Trust's Legal 883 Provisions Relating to IETF Documents 884 (http://trustee.ietf.org/license-info) in effect on the date of 885 publication of this document. Please review these documents 886 carefully, as they describe your rights and restrictions with respect 887 to this document. Code Components extracted from this document must 888 include Simplified BSD License text as described in Section 4.e of 889 the Trust Legal Provisions and are provided without warranty as 890 described in the Simplified BSD License. 892 This document may contain material from IETF Documents or IETF 893 Contributions published or made publicly available before November 894 10, 2008. The person(s) controlling the copyright in some of this 895 material may not have granted the IETF Trust the right to allow 896 modifications of such material outside the IETF Standards Process. 897 Without obtaining an adequate license from the person(s) controlling 898 the copyright in such materials, this document may not be modified 899 outside the IETF Standards Process, and derivative works of it may 900 not be created outside the IETF Standards Process, except to format 901 it for publication as an RFC or to translate it into languages other 902 than English. 904 Expiration Date: December 2013