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