idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-18.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '...mulated servi...' -- 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 (October 7, 2013) is 3825 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: 'RFC4721' is mentioned on line 357, but not defined == Missing Reference: 'AFI' is mentioned on line 379, but not defined == Missing Reference: 'SAFI' is mentioned on line 379, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 6 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: April 2014 5 Intended status: Standards Track Matthew Bocci (Ed.) 6 Updates: RFC6073 Florin Balus (Ed.) 7 Alcatel-Lucent 9 October 7, 2013 11 Dynamic Placement of Multi-Segment Pseudowires 13 draft-ietf-pwe3-dynamic-ms-pw-18.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 April 7, 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. This document 47 also updates the length value of the PW Switching Point PE Sub-TLV 48 Type 0x06 to 14. 50 Table of Contents 52 1 Introduction ......................................... 3 53 1.1 Scope ................................................ 3 54 1.2 Specification of Requirements ........................ 3 55 1.3 Terminology .......................................... 3 56 1.4 Architecture Overview ................................ 4 57 2 Applicability ........................................ 5 58 2.1 Changes to Existing PW Signaling ..................... 5 59 3 PW Layer 2 Addressing ................................ 5 60 3.1 Attachment Circuit Addressing ........................ 6 61 3.2 S-PE Addressing ...................................... 7 62 4 Dynamic Placement of MS-PWs .......................... 7 63 4.1 Pseudowire Routing Procedures ........................ 7 64 4.1.1 AII PW Routing Table Lookup Aggregation Rules ........ 8 65 4.1.2 PW Static Route ...................................... 8 66 4.1.3 Dynamic Advertisement with BGP ....................... 9 67 4.2 LDP Signaling ........................................ 10 68 4.2.1 Equal Cost Multi Path (ECMP) in PW Routing ........... 12 69 4.2.2 Active/Passive T-PE Election Procedure ............... 12 70 4.2.3 Detailed Signaling Procedures ........................ 13 71 5 Failure Handling Procedures .......................... 14 72 5.1 PSN Failures ......................................... 14 73 5.2 S-PE Specific Failures ............................... 14 74 5.3 PW Reachability Changes .............................. 15 75 6 Operations and Maintenance (OAM) ..................... 15 76 7 Security Considerations .............................. 16 77 8 IANA Considerations .................................. 16 78 8.1 Corrections .......................................... 16 79 8.2 LDP TLV TYPE NAME SPACE .............................. 16 80 8.3 LDP Status Codes ..................................... 17 81 8.4 BGP SAFI ............................................. 17 82 9 References ........................................... 17 83 9.1 Normative References ................................. 17 84 9.2 Informative References ............................... 18 85 10 Major Co-authors ..................................... 18 86 11 Acknowledgements ..................................... 18 87 12 Author's Addresses ................................... 19 89 1. Introduction 91 1.1. Scope 93 [RFC5254] describes the service provider requirements for extending 94 the reach of pseudowires across multiple Packet Switched Network 95 (PSN) domains. This is achieved using a Multi-segment Pseudowire 96 (MS-PW). An MS-PW is defined as a set of two or more contiguous PW 97 segments that behave and function as a single point-to-point PW. This 98 architecture is described in [RFC5659]. 100 The procedures for establishing PWs that extend across a single PSN 101 domain are described in [RFC4447], while procedures for setting up 102 PWs across multiple PSN domains, or control plane domains are 103 described in [RFC6073]. 105 The purpose of this document is to specify extensions to the 106 pseudowire control protocol [RFC4447], and [RFC6073] procedures, to 107 enable multi-segment PWs to be dynamically placed. The procedures 108 follow the guidelines defined in [RFC5036] and enable the reuse of 109 existing TLVs, and procedures defined for SS-PWs in [RFC4447]. 110 Dynamic placement of point-to-multipoint (P2MP) PWs is for further 111 study and outside the scope of this document. 113 1.2. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119. 119 1.3. Terminology 121 [RFC5659] provides terminology for multi-segment pseudowires. 123 This document defines the following additional terms: 125 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 126 assumes the active signaling role and initiates the signaling for 127 multi-segment PW. 128 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 129 assumes the passive signaling role. It waits and responds to the 130 multi-segment PW signaling message in the reverse direction. 132 - Forward Direction: ST-PE to TT-PE. 133 - Reverse Direction: TT-PE to ST-PE. 134 - Pseudowire Routing (PW routing): The dynamic placement of the 135 segments that compose an MS-PW, as well as the automatic 136 selection of S-PEs. 138 1.4. Architecture Overview 140 The following figure shows the reference model, derived from 141 [RFC5659], to support PW emulated services using multi-segment PWs. 143 Native |<-------------Pseudowire------------>| Native 144 Service | | Service 145 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 146 | V V V V V V | 147 | +-----+ +-----+ +-----+ 148 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 149 | |-------|.....PW.Seg't1........PW.Seg't3......|----------| | 150 | CE1| | | | | | | | | |CE2 | 151 | |-------|.....PW.Seg't2.......|PW.Seg't4......|----------| | 152 +----+ | | |=========| |=========| | | +----+ 153 ^ +-----+ +-----+ +-----+ ^ 154 | Provider Edge 1 ^ Provider Edge 2 | 155 | | | 156 | | | 157 | PW switching point | 158 | | 159 |<---------------- Emulated Service -------------------->| 161 Figure 1: MS-PW Reference Model 163 T-PE1 and T-PE2 provide an emulated service to CE1 and CE2. These 164 PEs reside in different PSNs. A PSN tunnel extends from T-PE1 to S- 165 PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 166 across PSN2. PWs are used to connect the attachment circuits (ACs) 167 attached to T-PE1 to the corresponding AC attached to T-PE2. A PW 168 segment on the tunnel across PSN1 is connected to a PW segment in the 169 tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) 170 between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point 171 and is referred to as the switching provider edge (S-PE). PW Segment 172 1 and PW Segment 3 are segments of the same MS-PW while PW Segment 2 173 and PW Segment 4 are segments of another MS-PW. PW segments of the 174 same MS-PW (e.g., PW segment 1 and PW segment 3) MUST be of the same 175 PW type, and PSN tunnels (e.g., PSN1 and PSN2) can be of the same or 176 a different technology. An S-PE switches an MS-PW from one segment to 177 another based on the PW identifiers ( PWid, or Attachment Identifier 178 (AII)). How the PW protocol data units (PDUs) are switched at the S- 179 PE depends on the PSN tunnel technology: in case of an MPLS PSN to 180 another MPLS PSN, PW switching involves a standard MPLS label swap 181 operation. 183 Note that although Figure 1 only shows a single S-PE, a PW may 184 transit more than one S-PE along its path. For instance, in the 185 multi-provider case, there can be an S-PE at the border of one 186 provider domain and another S-PE at the border of the other provider 187 domain. 189 2. Applicability 191 In this document we describe the case where the PSNs carrying the 192 MS-PW are only MPLS PSNs using the Generalized PWID FEC element (also 193 known as FEC129). Interactions with an IP PSN using L2TPv3 as 194 described in [RFC6073] section 7.4 are for further study. 196 2.1. Changes to Existing PW Signaling 198 The procedures described in this document make use of existing LDP 199 TLVs and related PW signaling procedures described in [RFC4447] and 200 [RFC6073]. The following optional TLV is also defined: 201 - A Bandwidth TLV to address QoS Signaling requirements (see 202 Section 6.2.1). 204 This document also updates the length value of the PW Switching Point 205 PE Sub-TLV Type 0x06 to 14. 207 3. PW Layer 2 Addressing 209 Single segment pseudowires on an MPLS PSN can use attachment circuit 210 identifiers for a PW using FEC 129. In the case of a dynamically 211 placed MS-PW, there is a requirement for the attachment circuit 212 identifiers to be globally unique, for the purposes of reachability 213 and manageability of the PW. Referencing figure 1 above, individual 214 globally unique addresses MUST be allocated to all the ACs and S-PEs 215 of an MS-PW. 217 3.1. Attachment Circuit Addressing 219 The attachment circuit addressing is derived from [RFC5003] AII type 220 2, shown here: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | AII Type=02 | Length | Global ID | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Global ID (contd.) | Prefix | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Prefix (contd.) | AC ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | AC ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: AII Type 2 TLV Structure 236 The fields are defined in [RFC5003], Section 3.2. 238 AII type 2 based addressing schemes permit varying levels of AII 239 summarization, thus reducing the scaling burden on PW routing. AII 240 Type 2 based PW addressing is suitable for point-to-point 241 provisioning models where auto-discovery of the address at the Target 242 T-PE is not required. That is, it is known a-priori by provisioning. 244 Implementations of the following procedure MUST interpret the AII 245 type to determine the meaning of the address format of the AII, 246 irrespective of the number of segments in the MS-PW. All segments of 247 the PW MUST be signaled with same AII Type. 249 A unique combination of Global ID, Prefix, and AC ID parts of the AII 250 type 2 are assigned to each AC. In general, the same global ID and 251 prefix are be assigned for all ACs belonging to the same T-PE. This 252 is not a strict requirement, however. A particular T-PE might have 253 more than one prefix assigned to it, and likewise a fully qualified 254 AII with the same Global ID/Prefix but different AC IDs might belong 255 to different T-PEs. 257 For the purpose of MS-PWs, the AII MUST be globally unique across all 258 PSNs that are spanned by the MS-PW. 260 3.2. S-PE Addressing 262 Each S-PE MUST be assigned an address which uniquely identifies it 263 from a pseudowire perspective, in order to populate the Switching 264 Point PE (SP-PE) TLV specified in [RFC6073]. For this purpose, at 265 least one Attachment Identifier (AI) address of the format similar to 266 AII type 2 [RFC5003] composed of the Global ID, and Prefix part, 267 only, MUST be assigned to each S-PE. 269 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned 270 with an S-PE address, then on receiving a Dynamic MS-PW label mapping 271 message the S-PE MUST return a Label Release with the 272 "LDP_RESOURCES_UNAVAILABLE" ( 0x38)" status code. 274 4. Dynamic Placement of MS-PWs 276 [RFC6073] describes a procedure for concatenating multiple 277 pseudowires together. This procedure requires each S-PE to be 278 manually configured with the information required for each segment of 279 the MS-PW. The procedures in the following sections describe a method 280 to extend [RFC6073] by allowing the automatic selection of pre- 281 defined S-PEs, and dynamically establishing a MS-PW between two T- 282 PEs. 284 4.1. Pseudowire Routing Procedures 286 The AII type 2 described above contains a Global ID, Prefix, and AC 287 ID. The Target Attachment Individual Identifier (TAII) is used by S- 288 PEs to determine the next SS-PW destination for LDP signaling. 290 Once an S-PE receives a MS-PW label mapping message containing a TAII 291 with an AII that is not locally present, the S-PE performs a lookup 292 in a PW AII routing table. If this lookup results in an IP address 293 for the next-hop PE with reachability information for the AII in 294 question, then the S-PE will initiate the necessary LDP messaging 295 procedure to set-up the next PW segment. If the PW AII routing table 296 lookup does not result in a IP address for a next-hop PE, the 297 destination AII has become unreachable, and the PW setup MUST fail. 298 In this case the next PW segment is considered un-provisioned, and a 299 label release MUST be returned to the T-PE with a status message of 300 "AII Unreachable". 302 If the TAI of a MS-PW label mapping message received by a PE contains 303 the prefix matching a locally-provisioned prefix on that PE, but an 304 AC ID that is not provisioned, then the LDP liberal label retention 305 procedures apply, and the label mapping message is retained. 307 To allow for dynamic end-to-end signaling of MS-PWs, information must 308 be present in S-PEs to support the determination of the next PW 309 signaling hop. Such information can be provisioned (equivalent to a 310 static route) on each S-PE, or disseminated via regular routing 311 protocols (e.g. BGP). 313 4.1.1. AII PW Routing Table Lookup Aggregation Rules 315 All PEs capable of dynamic MS-PW path selection MUST build a PW AII 316 routing table to be used for PW next-hop selection. 318 The PW addressing scheme (AII type 2 in [RFC5003]) consists of a 319 Global ID, a 32 bit prefix and a 32 bit Attachment Circuit ID. 321 An aggregation scheme similar to that used for classless IPv4 322 addresses can be employed. An (8 bits) length mask is specified as a 323 number ranging from 0 to 96 that indicates which Most Significant 324 Bits (MSB) are relevant in the address field when performing the PW 325 address matching algorithm. 327 0 31 32 63 64 95 (bits) 328 +-----------+--------+--------+ 329 | Global ID | Prefix | AC ID | 330 +-----------+--------+--------+ 332 Figure 3: PW Addressing Scheme 334 During the signaling phase, the content of the (fully qualified) TAII 335 type 2 field from the FEC129 TLV is compared against routes from the 336 PW Routing table. Similar with the IPv4 case, the route with the 337 longest match is selected, determining the next signaling hop and 338 implicitly the next PW Segment to be signaled. 340 4.1.2. PW Static Route 342 For the purpose of determining the next signaling hop for a segment 343 of the pseudowire, the PEs MAY be provisioned with fixed route 344 entries in the PW next hop routing table. The static PW entries will 345 follow all the addressing rules and aggregation rules described in 346 the previous sections. The most common use of PW static provisioned 347 routes is this example of the "default" route entry as follows: 349 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 350 Hop = {IP Address of next hop S-PE or T-PE} 352 4.1.3. Dynamic Advertisement with BGP 354 Any suitable routing protocol capable of carrying external routing 355 information MAY be used to propagate MS-PW path information among S- 356 PEs and T-PEs. However, T-PEs and S-PEs MAY choose to use Border 357 Gateway Protocol (BGP) [RFC4721] with the Multiprotocol Extensions as 358 defined in [RFC4760] to propagate PW address information throughout 359 the PSN. 361 Contrary to layer 2 VPN signaling methods that use BGP [RFC6074] for 362 auto discovery, in the case of the dynamically placed MS-PW, the 363 source T-PE knows a-priori (by provisioning) the AC ID on the 364 terminating T-PE that signaling should use. Hence there is no need to 365 advertise a "fully qualified" 96 bit address on a per PW Attachment 366 Circuit basis. Only the T-PE Global ID, Prefix, and prefix length 367 needs to be advertised as part of well known BGP procedures - see 368 [RFC4760]. 370 Since PW Endpoints are provisioned in the T-PEs, the ST-PE will use 371 this information to obtain the first S-PE hop (i.e., first BGP next 372 hop) to where the first PW segment will be established. Any 373 subsequent S-PEs will use the same information (i.e. the next BGP 374 next-hop(s)) to obtain the next-signaling-hop(s) on the path to the 375 TT-PE. 377 The PW dynamic path Network Layer Reachability Information (NLRI) is 378 advertised in BGP UPDATE messages using the MP_REACH_NLRI and 379 MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, SAFI] value pair used 380 to identify this NLRI is (AFI=25, SAFI=6 (pending IANA allocation)). 381 A route target MAY also be advertised along with the NLRI. 383 The Next Hop field of the MP_REACH_NLRI attribute SHALL be 384 interpreted as an IPv4 address, whenever the length of the NextHop 385 address is 4 octets, and as a IPv6 address, whenever the length of 386 the NextHop address is 16 octets. 388 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 389 comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, 390 and the AC-ID, and encoded as defined in section 4 of [RFC4760]. 392 This NLRI is structured as follows: 394 Bit 395 0 7 8 71 72 103 104 135 136 167 396 +------+----------------+-----------+--------+--------+ 397 |Length| Route Dist | Global ID | Prefix | AC ID | 398 +------+----------------+-----------+--------+--------+ 400 Figure 4: NLRI Field Structure 402 The Length field is the prefix length of the Route Distinguisher + 403 Global ID + Prefix + AC-ID in bits. 405 Except for the default PW route, which is encoded as a 0 length 406 prefix, the minimum value of the length field is 96 bits. Lengths of 407 128 bits to 159 bits are invalid as the AC ID field cannot be 408 aggregated. The maximum value of the Length field is 160 bits. BGP 409 advertisements received with invalid prefix lengths MUST be rejected 410 as having a bad packet format. 412 4.2. LDP Signaling 414 The LDP signaling procedures are described in [RFC4447] and expanded 415 in [RFC6073]. No new LDP signaling components are required for 416 setting up a dynamically placed MS-PW. However, some optional 417 signaling extensions are described below. 419 One of the requirements that MUST be met in order to enable the QoS 420 objectives for a PW to be achieved on a segment is that a PSN tunnel 421 MUST be selected that can support at least the required class of 422 service and that has sufficient bandwidth available. 424 Such PSN tunnel selection can be achieved where the next hop for a PW 425 segment is explicitly configured at each PE, whether the PE is a T-PE 426 or an S-PE in the case of a segmented PW, without dynamic path 427 selection (as per RFC6073). In these cases, it is possible to 428 explicitly configure the bandwidth required for a PW so that the T-PE 429 or S-PE can reserve that bandwidth on the PSN tunnel. 431 Where dynamic path selection is used and therefore the next-hop is 432 not explicitly configured by the operator at the S-PE, a mechanism is 433 required to signal the bandwidth for the PW from the T-PE to the S- 434 PEs. This is accomplished by including an optional PW Bandwidth TLV. 435 The PW Bandwidth TLV is specified as follows: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |1|0| PW BW TLV (0x096E) | TLV Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Forward SENDER_TSPEC | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Reverse SENDER_TSPEC | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 5: PW Bandwidth TLV Structure 449 The PW Bandwidth TLV fields are as follows: 451 - TLV Length: The length of the value fields in octets. Value = 64 453 - Forward SENDER_TSPEC = The SENDER_TSPEC for the forward direction 454 of the PW, as defined in [TSPEC] section 3.1. 456 - Reverse SENDER_TSPEC = The SENDER_TSPEC for the reverse direction 457 of the PW, as defined in [TSPEC] section 3.1. 459 The complete definitions of the content of the SENDER_TSPEC objects 460 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 461 the data path in the direction of ST-PE to TT-PE. The reverse 462 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 464 In the forward direction, after a next hop selection is determined, a 465 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 466 an appropriate PSN tunnel towards the next signaling hop. If such a 467 tunnel exists, the MS-PW signaling procedures are invoked with the 468 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 469 tunnel, any tunnel which points to a next hop equivalent to the next 470 hop selected will be included in the search (the LDP address TLV is 471 used to determine the next hop equivalence) 473 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 474 selected, the S/T-PE MUST request the appropriate resources from the 475 PSN. The resources described in the reverse SENDER_TSPEC are 476 allocated from the PSN toward the originator of the message or 477 previous hop. When resources are allocated from the PSN for a 478 specific PW, the SHOULD account for the usage of the resources by the 479 PW. 481 In the case where PSN resources towards the previous hop are not 482 available, the following procedure MUST be followed: 483 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 484 the PSN tunnel. 485 -ii. The S-PE MAY attempt to setup another PSN tunnel to 486 accommodate the new PW QoS requirements. 487 -iii. If the S-PE cannot get enough resources to setup the segment 488 in the MS-PW a label release MUST be returned to the 489 previous hop with a status message of "Bandwidth resources 490 unavailable" 492 In the latter case, the T-PE receiving the status message MUST also 493 withdraw the corresponding PW label mapping for the opposite 494 direction if it has already been successfully setup. 496 If an ST-PE receives a label mapping message the following procedure 497 MUST be followed: 499 If the ST-PE has already sent a label mapping message for this PW 500 then the ST-PE MUST check that this label mapping message originated 501 from the same LDP peer to which the corresponding label mapping 502 message for this particular PW was sent. If it is the same peer, the 503 PW is established. If it is a different peer, then the ST-PE MUST 504 send a label release message, with a status code of "Duplicate AII" 505 to the PE that originate the LDP label mapping message. 507 If the PE has not yet sent a label mapping message for this 508 particular PW , then it MUST send the label mapping message to this 509 LDP peer, regardless of what the PW TAII routing lookup result is. 511 4.2.1. Equal Cost Multi Path (ECMP) in PW Routing 513 A next hop selection for a specific PW may find a match with a PW 514 route that has multiple next hops associated with it. Multiple next 515 hops may be either configured explicitly as static routes or may be 516 learned through BGP routing procedures. Implementations at and S-PE 517 or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV, 518 for load balancing of PWs across multiple next-hops. The details of 519 such selection algorithms are outside the scope of this document. 521 4.2.2. Active/Passive T-PE Election Procedure 523 When a MS-PW is signaled, each T-PE might independently initiate 524 signaling the MS-PW. This could result in a different path being used 525 be each direction of the PW. To avoid this situation one T-PE MUST 526 initiate PW signaling (i.e. take an active role), while the other T- 527 PE waits to receive the LDP label mapping message before sending the 528 LDP label mapping message for the reverse direction of the PW (i.e. 529 take a passive role). The Active T-PE (the ST-PE) and the Passive T- 530 PE (the TT-PE) MUST be identified before signaling begins for a given 531 MS-PW. 533 The determination of which T-PE assumes the active role SHOULD be 534 done as follows: the Source Attachment Individual Identifier (SAII) 535 and TAII are compared as unsigned integers, if the SAII is bigger 536 then the T-PE assumes the active role. 538 4.2.3. Detailed Signaling Procedures 540 On receiving a label mapping message, the S-PE MUST inspect the FEC 541 TLV. If the receiving node has no local AII matching the TAII for 542 that label mapping then the label mapping message should be forwarded 543 on to another S-PE or T-PE. The S-PE will check if the FEC is already 544 installed for the forward direction: 545 - If it is already installed, and the received mapping was received 546 from the same LDP peer to which the forward LDP label mapping was 547 sent, then this label mapping represents signaling in the reverse 548 direction for this MS-PW segment. 549 - If it is already installed, and the received mapping was received 550 from a different LDP peer to which the forward LDP label mapping 551 was sent, then the received label mapping MUST be released with 552 the status code of "PW_LOOP_DETECTED". 553 - If the FEC is not already installed, then this represents 554 signaling in the forward direction. 556 For the forward direction: 557 -i. Determine the next hop S-PE or T-PE according to the 558 procedures above. If next-hop reachability is not found in 559 the PW AII routing table in the S-PE then label release MUST 560 be sent with status code "AII_UNREACHABLE". If the next-hop 561 S-PE or T-PE is found and is the same LDP Peer that has sent 562 the label mapping message then a label Release MUST be 563 returned with the status code "PW_LOOP_DETECTED". If the 564 SAII in the received label mapping is local to the S-PE then 565 a label released MUST be returned with status code 566 "PW_LOOP_DETECTED". 567 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 568 If no tunnel exists to the next hop S-PE or T-PE the S-PE 569 MAY attempt to setup a PSN tunnel. 570 -iii. Check that a PSN tunnel exists to the previous hop. If no 571 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 572 attempt to setup a PSN tunnel. 574 -iv. If the S-PE cannot get enough PSN resources to setup the 575 segment to the next or previous S-PE or T-PE, a label 576 release MUST be returned to the T-PE with a status message 577 of "Resources Unavailable". 578 -v. If the label mapping message contains a Bandwidth TLV, 579 allocate the required resources on the PSN tunnels in the 580 forward and reverse directions according to the procedures 581 above. 582 -vi. Allocate a new PW label for the forward direction. 583 -vii. Install the FEC for the forward direction. 584 -viii. Send the label mapping message with the new forward label 585 and the FEC to the next hop S-PE/T-PE. 587 For the reverse direction: 588 -i. Install the received FEC for the reverse direction. 589 -ii. Determine the next signaling hop by referencing the LDP 590 sessions used to setup the PW in the Forward direction. 591 -iii. Allocate a new PW label for the reverse direction. 592 -iv. Install the FEC for the reverse direction. 593 -v. Send the label mapping message with a new label and the FEC 594 to the next hop S-PE/ST-PE. 596 5. Failure Handling Procedures 598 5.1. PSN Failures 600 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 601 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 602 follow the procedures defined in Section 8 of [RFC6073]. 604 5.2. S-PE Specific Failures 606 For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be 607 followed. A T-PE or S-PE may receive an unsolicited label release 608 message from another S-PE or T-PE with various failure codes such 609 "LOOP_DETECTED", "PW_LOOP_DETECTED", "RESOURCE_UNAVAILBALE", 610 "BAD_STRICT_HOP", "AII_UNREACHABLE", etc. All these failure codes 611 indicate a generic class of PW failures at an S-PE or T-PE. 613 When an unsolicited label release message with such a failure status 614 code is received at T-PE then the T-PE MUST re-attempt to establish 615 the PW immediately. However the T-PE MUST throttle its PW setup 616 message retry attempts with an exponential backoff in situations 617 where PW setup messages are being constantly released. It is also 618 recommended that a T-PE detecting such a situation take action to 619 notify an operator. 621 S-PEs that receive an unsolicited label release message with a 622 failure status code should follow the following procedures: 624 -i. If the label release is received from an S-PE or T-PE in the 625 forward signaling direction then the S-PE MUST tear down 626 both segments of the PW. The status code received in the 627 label release message SHOULD be propagated when sending the 628 label release for the next-segment. 629 -ii. If the label release is received from an S-PE or T-PE in the 630 reverse signaling direction, then then tear down both 631 segments of the PW as described in i. 633 5.3. PW Reachability Changes 635 In general an established MS-PW will not be affected by next-hop 636 changes in L2 PW reachability information. 638 If there is a change in next-hop of the L2 PW reachability 639 information in the forward direction, the T-PE MAY elect to tear down 640 the MS-PW by sending a label withdraw message to downstream S-PE or 641 T-PE. The teardown MUST be also accompanied by a unsolicited label 642 release message, and will be followed by and attempt to re-establish 643 of the MS-PW by T-PE. 645 If there is a change in the L2 PW reachability information in the 646 forward direction at S-PE, the S-PE MAY elect to tear down the MS-PW 647 in both directions. A label withdrawal is sent on each direction 648 followed by a unsolicited label release. The unsolicited label 649 releases MUST be accompanied by the Status code "AII_UNREACHABLE". 650 This procedure is OPTIONAL. 652 A change in L2 reachability information in the reverse direction has 653 no effect on an MS-PW. 655 6. Operations and Maintenance (OAM) 657 The OAM procedures defined in [RFC6073] may be used also for MS-PWs. 658 A PW switching point TLV is used [RFC6073] to record the switching 659 points that the PW traverses. 661 In the case of a MS-PW where the PW Endpoints are identified though 662 using a globally unique, FEC 129-based AII addresses, there is no 663 PWID defined on a per segment basis. Each individual PW segment is 664 identified by the address of adjacent S-PE(s) in conjunction with the 665 SAI and TAI. In this case, the following TLV type (0x06) MUST be used 666 in place of type 0x01 in the PW switching point TLV: 668 Type Length Description 669 0x06 14 L2 PW address of PW Switching Point 671 The above field MUST be included together with type 0x02 in the TLV 672 once per individual PW Switching Point following the same rules and 673 procedures as described in [RFC6073]. A more detailed description of 674 this field is also in setion 7.4.1 of [RFC6073]. However, note that 675 the length MUST be set to 14. 677 7. Security Considerations 679 This document specifies only extensions to the protocols already 680 defined in [RFC4447], and [RFC6073]. Each such protocol may have its 681 own set of security issues, but those issues are not affected by the 682 extensions specified herein. Note that the protocols for dynamically 683 distributing PW Layer 2 reachability information may have their own 684 security issues, however those protocols specifications are outside 685 the scope of this document. 687 8. IANA Considerations 689 8.1. Corrections 691 IANA needs to correct a minor error in the registry "Pseudowire 692 Switching Point PE sub-TLV Type". The entry 0x06 "L2 PW address of 693 the PW Switching Point" should have Length 14. 695 8.2. LDP TLV TYPE NAME SPACE 697 This document defines one new LDP TLV types. IANA already maintains a 698 registry for LDP TLV types called "Type, Length, and Value (TLV) 699 Type Name Space" within the "Label Distribution Protocol (LDP) 700 Parameters" as defined by RFC5036. The IANA is requested to assign on 701 permanent basis the value (0x096E) that has been assigned to this 702 document by early allocation (TEMPORARY - Expires 2008-11-21).: 704 Value Description Reference Notes/Registration Date 705 ------+----------------+---------------+----------------------- 706 0x096E Bandwidth TLV This document 708 8.3. LDP Status Codes 710 This document defines three new LDP status codes. IANA maintains a 711 registry of these called the "STATUS CODE NAME SPACE" in the "Label 712 Distribution Protocol (LDP) Parameters" as defined by RFC5036. The 713 IANA is requested to assign on permanent basis the values that has 714 been assigned to this document by early allocation 715 (TEMPORARY - Expires 2008-11-21): 717 Range/Value E Description Reference 718 ------------- ----- ---------------------- --------- 719 0x00000037 0 Bandwidth resources unavailable This document 720 0x00000038 0 Resources Unavailable This document 721 0x00000039 0 AII Unreachable This document 723 8.4. BGP SAFI 725 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 726 Information used for Dynamic Placement of Multi-Segment Pseudowires" 727 from the IANA "Subsequence Address Family Identifiers (SAFI)" 728 registry. The IANA is requested to assign on permanent basis the 729 values that has been assigned to this document by early allocation 730 (TEMPORARY - Expires 2008-11-21):: 732 Value Description Reference 733 ----- ----------- --------- 734 6 Network Layer Reachability Information used This document 735 for Dynamic Placement of Multi-Segment 736 Pseudowires 738 9. References 740 9.1. Normative References 742 [RFC6073] Martini et.al. "Segmented Pseudowire", RFC6073, 743 January 2011 745 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 746 Services", RFC 2210, September 1997 748 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" 749 RFC5036, October 2007 751 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 752 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 753 June 2005. 755 [RFC5003] "Attachment Individual Identifier (AII) Types for 756 Aggregation", Metz, et al, RFC5003, September 2007 758 9.2. Informative References 760 [RFC5254] Martini et al, "Requirements for Multi-Segment Pseudowire 761 Emulation Edge-to-Edge (PWE3)", 762 RFC5254, Bitar, Martini, Bocci, October 2008 764 [RFC5659] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 765 Emulation Edge-to-Edge", RFC5659,October 2009. 767 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 768 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 770 [RFC6074] E. Rosen, W. Luo, B. Davie, V. Radoaca, 771 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 772 rfc6074, January 2011 774 10. Major Co-authors 776 The editors gratefully acknowledge the following additional co- 777 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 778 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 779 Sugimoto. 781 11. Acknowledgements 783 The editors also gratefully acknowledge the input of the following 784 people: Mike Duckett, Paul Doolan, Prayson Pate, Ping Pan, Vasile 785 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 787 12. Author's Addresses 789 Luca Martini 790 Cisco Systems, Inc. 791 9155 East Nichols Avenue, Suite 400 792 Englewood, CO, 80112 793 e-mail: lmartini@cisco.com 795 Matthew Bocci 796 Alcatel-Lucent, 797 Voyager Place 798 Shoppenhangers Road 799 Maidenhead 800 Berks, UK 801 e-mail: matthew.bocci@alcatel-lucent.com 803 Florin Balus 804 Alcatel-Lucent 805 701 E. Middlefield Rd. 806 Mountain View, CA 94043 807 e-mail: florin.balus@alcatel-lucent.com 809 Nabil Bitar 810 Verizon 811 40 Sylvan Road 812 Waltham, MA 02145 813 e-mail: nabil.bitar@verizon.com 815 Himanshu Shah 816 Ciena Corp 817 35 Nagog Park, 818 Acton, MA 01720 819 e-mail: hshah@ciena.com 821 Mustapha Aissaoui 822 Alcatel-Lucent 823 600 March Road 824 Kanata 825 ON, Canada 826 e-mail: mustapha.aissaoui@alcatel-lucent.com 827 Jason Rusmisel 828 Alcatel-Lucent 829 600 March Road 830 Kanata 831 ON, Canada 832 e-mail: Jason.rusmisel@alcatel-lucent.com 834 Yetik Serbest 835 AT&T Labs 836 9505 Arboretum Blvd. 837 Austin, TX 78759 838 e-mail: yetik.serbest@labs.att.com 840 Andrew G. Malis 841 Verizon 842 117 West St. 843 Waltham, MA 02451 844 e-mail: andrew.g.malis@verizon.com 846 Chris Metz 847 Cisco Systems, Inc. 848 3700 Cisco Way 849 San Jose, Ca. 95134 850 e-mail: chmetz@cisco.com 852 David McDysan 853 Verizon 854 22001 Loudoun County Pkwy 855 Ashburn, VA, USA 20147 856 e-mail: dave.mcdysan@verizon.com 858 Jeff Sugimoto 859 Alcatel-Lucent 860 701 E. Middlefield Rd. 861 Mountain View, CA 94043 862 e-mail: jeffery.sugimoto@alcatel-lucent.com 863 Mike Duckett 864 ATT 865 Lindbergh Center D481 866 575 Morosgo Dr 867 Atlanta, GA 30324 868 e-mail: md9308@att.com 870 Mike Loomis 871 Alcatel-Lucent 872 701 E. Middlefield Rd. 873 Mountain View, CA 94043 874 e-mail: mike.loomis@alcatel-lucent.com 876 Paul Doolan 877 Coriant GmbH & Co. KG 878 St Martin Str. 76 879 81541 Munich 880 e-mail: paul.doolan@coriant.com 882 Ping Pan 883 Infinera 884 e-mail: ppan@infinera.com 886 Prayson Pate 887 Overture Networks, Inc. 888 507 Airport Blvd, Suite 111 889 Morrisville, NC, USA 27560 890 e-mail: prayson.pate@overturenetworks.com 892 Vasile Radoaca 893 Alcatel-Lucent 894 388 NINGQIAO RD 895 PUDONG JINQIAO 896 SHANGHAI 201206 897 CHINA 898 email: vasile.radoaca@alcatel-lucent.com 899 Yuichiro Wada 900 NTT 901 3-9-11 Midori-cho 902 Musashino-shi 903 Tokyo 180-8585 904 Japan 905 e-mail: wada.yuichiro@lab.ntt.co.jp 907 Yeong-il Seo 908 Korea Telecom Corp. 909 463-1 Jeonmin-dong, Yusung-gu 910 Daejeon, Korea 911 e-mail: yohan.seo@kt.com 913 Copyright Notice 915 Copyright (c) 2012 IETF Trust and the persons identified as the 916 document authors. All rights reserved. 918 This document is subject to BCP 78 and the IETF Trust's Legal 919 Provisions Relating to IETF Documents 920 (http://trustee.ietf.org/license-info) in effect on the date of 921 publication of this document. Please review these documents 922 carefully, as they describe your rights and restrictions with respect 923 to this document. Code Components extracted from this document must 924 include Simplified BSD License text as described in Section 4.e of 925 the Trust Legal Provisions and are provided without warranty as 926 described in the Simplified BSD License. 928 This document may contain material from IETF Documents or IETF 929 Contributions published or made publicly available before November 930 10, 2008. The person(s) controlling the copyright in some of this 931 material may not have granted the IETF Trust the right to allow 932 modifications of such material outside the IETF Standards Process. 933 Without obtaining an adequate license from the person(s) controlling 934 the copyright in such materials, this document may not be modified 935 outside the IETF Standards Process, and derivative works of it may 936 not be created outside the IETF Standards Process, except to format 937 it for publication as an RFC or to translate it into languages other 938 than English. 940 Expiration Date: April 2014