idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-22.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 (March 10, 2014) is 3690 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: 'RFC-to-be' is mentioned on line 768, 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 Expires: September 2014 5 Intended status: Standards Track Matthew Bocci (Ed.) 6 Updates: 6073 Florin Balus (Ed.) 7 Alcatel-Lucent 9 March 10, 2014 11 Dynamic Placement of Multi-Segment Pseudowires 13 draft-ietf-pwe3-dynamic-ms-pw-22.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 September 10, 2014 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 ................................ 6 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 ........................ 8 65 4.1.1 AII PW Routing Table Lookup Aggregation Rules ........ 8 66 4.1.2 PW Static Route ...................................... 9 67 4.1.3 Dynamic Advertisement with BGP ....................... 9 68 4.2 LDP Signaling ........................................ 11 69 4.2.1 Multiple Alternative Paths in PW Routing ............. 13 70 4.2.2 Active/Passive T-PE Election Procedure ............... 13 71 4.2.3 Detailed Signaling Procedures ........................ 14 72 5 Failure Handling Procedures .......................... 15 73 5.1 PSN Failures ......................................... 15 74 5.2 S-PE Specific Failures ............................... 16 75 5.3 PW Reachability Changes .............................. 16 76 6 Operations and Maintenance (OAM) ..................... 17 77 7 Security Considerations .............................. 17 78 8 IANA Considerations .................................. 18 79 8.1 Corrections .......................................... 18 80 8.2 LDP TLV TYPE NAME SPACE .............................. 18 81 8.3 LDP Status Codes ..................................... 19 82 8.4 BGP SAFI ............................................. 19 83 9 References ........................................... 19 84 9.1 Normative References ................................. 19 85 9.2 Informative References ............................... 20 86 10 Contributors ......................................... 20 87 11 Acknowledgements ..................................... 21 88 12 Author's Addresses ................................... 21 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 98 pseudowire (PW) segments that behave and function as a single point- 99 to-point PW. This 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 Single-Segment Pseudowires 111 (SS-PWs) in [RFC4447]. Dynamic placement of point-to-multipoint 112 (P2MP) PWs is for further study and outside the scope of this 113 document. 115 1.2. Specification of Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119. 121 1.3. Terminology 123 [RFC5659] provides terminology for multi-segment pseudowires. 125 This document defines the following additional terms: 127 - Source Terminating Provider Edge (ST-PE). A Terminating Provider 128 Edge (T-PE), which assumes the active signaling role and 129 initiates the signaling for multi-segment PW. 130 - Target Terminating Provider Edge (TT-PE). A Terminating Provider 131 Edge (T-PE) that assumes the passive signaling role. It waits and 132 responds to the multi-segment PW signaling message in the reverse 133 direction. 135 - Forward Direction: ST-PE to TT-PE. 136 - Reverse Direction: TT-PE to ST-PE. 137 - Pseudowire Routing (PW routing): The dynamic placement of the 138 segments that compose an MS-PW, as well as the automatic 139 selection of S-PEs. 141 1.4. Architecture Overview 143 The following figure shows the reference model, derived from 144 [RFC5659], to support PW emulated services using multi-segment PWs. 146 Native |<------Multi-Segment Pseudowire------>| Native 147 Service | PSN PSN | Service 148 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 149 | V V 1 V V 2 V V | 150 | +----+ +-----+ +----+ | 151 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 152 | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| | 153 | CE1| | | | | | | | | |CE2 | 154 | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| | 155 +----+ | | |===========| |==========| | | +----+ 156 ^ +----+ +-----+ +----+ ^ 157 | Provider Edge 1 ^ Provider Edge 2 | 158 | | | 159 | | | 160 | PW switching point | 161 | | 162 |<------------------ Emulated Service --------------->| 164 Figure 1: MS-PW Reference Model 166 The PEs that provide services to CE1 and CE2 are Terminating PE1 (T- 167 PE1) and Terminating PE2 (T-PE2), respectively. A PSN tunnel extends 168 from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel extends 169 from S-PE1 to T-PE2 . PWs are used to connect the attachment 170 circuits (ACs) attached to PE1 to the corresponding ACs attached to 171 T-PE2. 173 A PW segment on PSN Tunnel 1 is connected to a PW segment on PSN 174 Tunnel 2 at S-PE1 to complete the multi-segment PW (MS-PW) between 175 T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and is 176 referred to as the switching provider edge (S-PE). PW Segment 1 and 177 PW Segment 3 are segments of the same MS-PW while PW Segment 2 and PW 178 Segment 4 are segments of another MS-PW. PW segments of the same MS- 179 PW (e.g., PW segment 1 and PW segment 3) MUST be of the same PW type, 180 and PSN tunnels can be of the same or a different technology. An S-PE 181 switches an MS-PW from one segment to another based on the PW 182 identifiers ( PWid, or Attachment Individual Identifier (AII)). How 183 the PW protocol data units (PDUs) are switched at the S-PE depends on 184 the PSN tunnel technology: in case of a Multiprotocol Label Switching 185 (MPLS) PSN to another MPLS PSN, PW switching involves a standard MPLS 186 label swap operation. 188 Note that although Figure 1 only shows a single S-PE, a PW may 189 transit more than one S-PE along its path. Although RFC5659 [RFC5659] 190 describes MS-PWs that span more than one PSN, this document does not 191 specify how the LDP PW control protocol [RFC4447] is used in an 192 inter-AS environment. 194 2. Applicability 196 This document describes the case where the PSNs carrying the MS-PW 197 are only MPLS PSNs using the Generalized Pseudowire Identifier (PWID) 198 Forwarding Equivalence Class (FEC) element (also known as FEC129). 200 Interactions with an IP PSN using L2TPv3 as described in [RFC6073] 201 section 7.4 are for further study. 203 2.1. Changes to Existing PW Signaling 205 The procedures described in this document make use of existing LDP 206 TLVs and related PW signaling procedures described in [RFC4447] and 207 [RFC6073]. The following optional TLV is also defined: 208 - A Bandwidth TLV to address QoS Signaling requirements (see 209 Section 6.2.1). 211 This document also updates the value of the length field of the PW 212 Switching Point PE Sub-TLV Type 0x06 to 14. 214 3. PW Layer 2 Addressing 216 Single segment pseudowires on an MPLS PSN can use attachment circuit 217 identifiers for a PW using FEC 129. In the case of a dynamically 218 placed MS-PW, there is a requirement for the attachment circuit 219 identifiers to be globally unique, for the purposes of reachability 220 and manageability of the PW. Referencing figure 1 above, individual 221 globally unique addresses MUST be allocated to all the ACs and S-PEs 222 of an MS-PW. 224 3.1. Attachment Circuit Addressing 226 The attachment circuit addressing is derived from [RFC5003] AII type 227 2, shown here: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | AII Type=02 | Length | Global ID | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Global ID (contd.) | Prefix | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Prefix (contd.) | AC ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | AC ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: AII Type 2 TLV Structure 243 The fields are defined in [RFC5003], Section 3.2. 245 AII type 2 based addressing schemes permit varying levels of AII 246 summarization, thus reducing the scaling burden on PW routing. AII 247 Type 2 based PW addressing is suitable for point-to-point 248 provisioning models where auto-discovery of the address at the Target 249 T-PE is not required. That is, it is known a-priori by provisioning. 251 Implementations of the following procedure MUST interpret the AII 252 type to determine the meaning of the address format of the AII, 253 irrespective of the number of segments in the MS-PW. All segments of 254 the PW MUST be signaled with same AII Type. 256 A unique combination of Global ID, Prefix, and AC ID parts of the AII 257 type 2 are assigned to each AC. In general, the same Global ID and 258 Prefix are be assigned for all ACs belonging to the same T-PE. This 259 is not a strict requirement, however. A particular T-PE might have 260 more than one Prefix assigned to it, and likewise a fully qualified 261 AII with the same Global ID/Prefix but different AC IDs might belong 262 to different T-PEs. 264 For the purpose of MS-PWs, the AII MUST be globally unique across all 265 PSNs that are spanned by the MS-PW. 267 The AII for a local attachement circuit of a given T-PE of an MS-PW 268 and the AII of the corresponding attachment circuit on a far-end T-PE 269 (with respect to the LDP signaling) are known as the Source 270 Attachment Individual Identifier (SAII) and Target Attachment 271 Individual Identifier (TAII) as per [RFC6074]. 273 3.2. S-PE Addressing 275 Each S-PE MUST be assigned an address which uniquely identifies it 276 from a pseudowire perspective, in order to populate the Switching 277 Point PE (SP-PE) TLV specified in [RFC6073]. For this purpose, at 278 least one Attachment Identifier (AI) address of the format similar to 279 AII type 2 [RFC5003] composed of the Global ID, and Prefix part, 280 only, MUST be assigned to each S-PE. 282 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned 283 with an S-PE address, then on receiving a Dynamic MS-PW Label Mapping 284 message the S-PE MUST return a Label Release with the 285 "LDP_RESOURCES_UNAVAILABLE" ( 0x38)" status code. 287 4. Dynamic Placement of MS-PWs 289 [RFC6073] describes a procedure for concatenating multiple 290 pseudowires together. This procedure requires each S-PE to be 291 manually configured with the information required for each segment of 292 the MS-PW. The procedures in the following sections describe a method 293 to extend [RFC6073] by allowing the automatic selection of pre- 294 defined S-PEs, and dynamically establishing a MS-PW between two T- 295 PEs. 297 4.1. Pseudowire Routing Procedures 299 The AII type 2 described above contains a Global ID, Prefix, and AC 300 ID. The Target Attachment Individual Identifier (TAII) is used by S- 301 PEs to determine the next SS-PW destination for LDP signaling. 303 Once an S-PE receives a MS-PW Label Mapping message containing a TAII 304 with an AII that is not locally present, the S-PE performs a lookup 305 in a PW AII routing table. If this lookup results in an IP address 306 for the next-hop PE with reachability information for the AII in 307 question, then the S-PE will initiate the necessary LDP messaging 308 procedure to set-up the next PW segment. If the PW AII routing table 309 lookup does not result in a IP address for a next-hop PE, the 310 destination AII has become unreachable, and the PW setup MUST fail. 311 In this case the next PW segment is considered un-provisioned, and a 312 Label Release MUST be returned to the T-PE with a status message of 313 "AII Unreachable". 315 If the TAII of a MS-PW Label Mapping message received by a PE 316 contains the prefix matching a locally-provisioned prefix on that PE, 317 but an AC ID that is not provisioned, then the LDP liberal label 318 retention procedures apply, and the Label Mapping message is 319 retained. 321 To allow for dynamic end-to-end signaling of MS-PWs, information MUST 322 be present in S-PEs to support the determination of the next PW 323 signaling hop. Such information can be provisioned (equivalent to a 324 static route) on each S-PE, or disseminated via regular routing 325 protocols (e.g. BGP). 327 4.1.1. AII PW Routing Table Lookup Aggregation Rules 329 All PEs capable of dynamic MS-PW path selection MUST build a PW AII 330 routing table to be used for PW next-hop selection. 332 The PW addressing scheme (AII type 2 in [RFC5003]) consists of a 333 Global ID, a 32 bit prefix and a 32 bit Attachment Circuit ID. 335 An aggregation scheme similar to that used for classless IPv4 336 addresses can be employed. An (8 bits) length mask is specified as a 337 number ranging from 0 to 96 that indicates which Most Significant 338 Bits (MSB) are relevant in the address field when performing the PW 339 address matching algorithm. 341 0 31 32 63 64 95 (bits) 342 +-----------+--------+--------+ 343 | Global ID | Prefix | AC ID | 344 +-----------+--------+--------+ 346 Figure 3: PW Addressing Scheme 348 During the signaling phase, the content of the (fully qualified) TAII 349 type 2 field from the FEC129 TLV is compared against routes from the 350 PW Routing table. Similar with the IPv4 case, the route with the 351 longest match is selected, determining the next signaling hop and 352 implicitly the next PW Segment to be signaled. 354 4.1.2. PW Static Route 356 For the purpose of determining the next signaling hop for a segment 357 of the pseudowire, the PEs MAY be provisioned with fixed route 358 entries in the PW next hop routing table. The static PW entries will 359 follow all the addressing rules and aggregation rules described in 360 the previous sections. The most common use of PW static provisioned 361 routes is this example of the "default" route entry as follows: 363 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 364 Hop = {IP Address of next hop S-PE or T-PE} 366 4.1.3. Dynamic Advertisement with BGP 368 Any suitable routing protocol capable of carrying external routing 369 information MAY be used to propagate MS-PW path information among S- 370 PEs and T-PEs. However, T-PEs and S-PEs MAY choose to use Border 371 Gateway Protocol (BGP) [RFC4271] with the Multiprotocol Extensions as 372 defined in [RFC4760] to propagate PW address information throughout 373 the PSN. PW address information is only propagated by PEs that are 374 capable of PW switching. Therefore, the multiprotocol BGP neighbor 375 topology MUST coincide with the topology of T-PEs and S-PEs. 377 Contrary to layer 2 VPN signaling methods that use BGP [RFC6074] for 378 auto discovery, in the case of the dynamically placed MS-PW, the 379 source T-PE knows a-priori (by provisioning) the AC ID on the 380 terminating T-PE that signaling should use. Hence there is no need to 381 advertise a "fully qualified" 96 bit address on a per PW Attachment 382 Circuit basis. Only the T-PE Global ID, Prefix, and prefix length 383 needs to be advertised as part of well known BGP procedures - see 384 [RFC4760]. 386 Since PW Endpoints are provisioned in the T-PEs, the ST-PE will use 387 this information to obtain the first S-PE hop (i.e., first BGP next 388 hop) to where the first PW segment will be established. Any 389 subsequent S-PEs will use the same information (i.e. the next BGP 390 next-hop(s)) to obtain the next-signaling-hop(s) on the path to the 391 TT-PE. 393 The PW dynamic path Network Layer Reachability Information (NLRI) is 394 advertised in BGP UPDATE messages using the MP_REACH_NLRI and 395 MP_UNREACH_NLRI attributes [RFC4760]. The {AFI, SAFI} value pair used 396 to identify this NLRI is (AFI=25, SAFI=6 (pending IANA allocation)). 397 A route target MAY also be advertised along with the NLRI. 399 The Next Hop field of the MP_REACH_NLRI attribute SHALL be 400 interpreted as an IPv4 address, whenever the length of the NextHop 401 address is 4 octets, and as a IPv6 address, whenever the length of 402 the NextHop address is 16 octets. 404 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 405 comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, 406 and the AC-ID, and encoded as defined in section 4 of [RFC4760]. 408 This NLRI is structured as follows: 410 Bit 411 0 7 8 71 72 103 104 135 136 167 412 +------+----------------+-----------+--------+--------+ 413 |Length| Route Dist | Global ID | Prefix | AC ID | 414 +------+----------------+-----------+--------+--------+ 416 Figure 4: NLRI Field Structure 418 The Length field is the Prefix length of the Route Distinguisher + 419 Global ID + Prefix + AC-ID in bits. 421 Except for the default PW route, which is encoded as a 0 length 422 Prefix, the minimum value of the length field is 96 bits. Lengths of 423 128 bits to 159 bits are invalid as the AC ID field cannot be 424 aggregated. The maximum value of the Length field is 160 bits. BGP 425 advertisements received with invalid Prefix lengths MUST be rejected 426 as having a bad packet format. 428 4.2. LDP Signaling 430 The LDP signaling procedures are described in [RFC4447] and expanded 431 in [RFC6073]. No new LDP signaling components are required for 432 setting up a dynamically placed MS-PW. However, some optional 433 signaling extensions are described below. 435 One of the requirements that MUST be met in order to enable the QoS 436 objectives for a PW to be achieved on a segment is that a PSN tunnel 437 MUST be selected that can support at least the required class of 438 service and that has sufficient bandwidth available. 440 Such PSN tunnel selection can be achieved where the next hop for a PW 441 segment is explicitly configured at each PE, whether the PE is a T-PE 442 or an S-PE in the case of a segmented PW, without dynamic path 443 selection (as per RFC6073). In these cases, it is possible to 444 explicitly configure the bandwidth required for a PW so that the T-PE 445 or S-PE can reserve that bandwidth on the PSN tunnel. 447 Where dynamic path selection is used and therefore the next-hop is 448 not explicitly configured by the operator at the S-PE, a mechanism is 449 required to signal the bandwidth for the PW from the T-PE to the S- 450 PEs. This is accomplished by including an optional PW Bandwidth TLV. 451 The PW Bandwidth TLV is specified as follows: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |1|0| PW BW TLV (0x096E) | TLV Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Forward SENDER_TSPEC | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Reverse SENDER_TSPEC | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 5: PW Bandwidth TLV Structure 465 The PW Bandwidth TLV fields are as follows: 467 - TLV Length: The length of the value fields in octets. Value = 64 469 - Forward SENDER_TSPEC = The SENDER_TSPEC for the forward direction 470 of the PW, as defined in [RFC2210] section 3.1. 472 - Reverse SENDER_TSPEC = The SENDER_TSPEC for the reverse direction 473 of the PW, as defined in [RFC2210] section 3.1. 475 The complete definitions of the content of the SENDER_TSPEC objects 476 are found in [RFC2210] section 3.1. The forward SENDER_TSPEC refers 477 to the data path in the direction of ST-PE to TT-PE. The reverse 478 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 480 In the forward direction, after a next hop selection is determined, a 481 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 482 an appropriate PSN tunnel towards the next signaling hop. If such a 483 tunnel exists, the MS-PW signaling procedures are invoked with the 484 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 485 tunnel, any tunnel which points to a next hop equivalent to the next 486 hop selected will be included in the search (the LDP address TLV is 487 used to determine the next hop equivalence) 489 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 490 selected, the S/T-PE MUST request the appropriate resources from the 491 PSN. The resources described in the reverse SENDER_TSPEC are 492 allocated from the PSN toward the originator of the message or 493 previous hop. When resources are allocated from the PSN for a 494 specific PW, the SHOULD account for the usage of the resources by the 495 PW. 497 In the case where PSN resources towards the previous hop are not 498 available, the following procedure MUST be followed: 499 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 500 the PSN tunnel. 501 -ii. The S-PE MAY attempt to setup another PSN tunnel to 502 accommodate the new PW QoS requirements. 503 -iii. If the S-PE cannot get enough resources to setup the segment 504 in the MS-PW a Label Release MUST be returned to the 505 previous hop with a status message of "Bandwidth resources 506 unavailable" 508 In the latter case, the T-PE receiving the status message MUST also 509 withdraw the corresponding PW Label Mapping for the opposite 510 direction if it has already been successfully setup. 512 If an ST-PE receives a Label Mapping message the following procedure 513 MUST be followed: 515 If the ST-PE has already sent a Label Mapping message for this PW 516 then the ST-PE MUST check that this Label Mapping message originated 517 from the same LDP peer to which the corresponding Label Mapping 518 message for this particular PW was sent. If it is the same peer, the 519 PW is established. If it is a different peer, then the ST-PE MUST 520 send a Label Release message, with a status code of "Duplicate AII" 521 to the PE that originated the LDP Label Mapping message. 523 If the PE has not yet sent a Label Mapping message for this 524 particular PW , then it MUST send the Label Mapping message to this 525 LDP peer, regardless of what the PW TAII routing lookup result is. 527 4.2.1. Multiple Alternative Paths in PW Routing 529 A next hop selection for a specific PW may find a match with a PW 530 route that has multiple next hops associated with it. Multiple next 531 hops may be either configured explicitly as static routes or may be 532 learned through BGP routing procedures. Implementations at an S-PE or 533 T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV, or 534 flow-aware transport PW [RFC6391], for load balancing of PWs across 535 multiple next-hops, so that each PW has a single next hop. The 536 details of such selection algorithms are outside the scope of this 537 document. 539 4.2.2. Active/Passive T-PE Election Procedure 541 When a MS-PW is signaled, each T-PE might independently initiate 542 signaling the MS-PW. This could result in a different path being used 543 be each direction of the PW. To avoid this situation one T-PE MUST 544 initiate PW signaling (i.e. take an active role), while the other T- 545 PE waits to receive the LDP Label Mapping message before sending the 546 LDP Label Mapping message for the reverse direction of the PW (i.e. 547 take a passive role). The Active T-PE (the ST-PE) and the Passive T- 548 PE (the TT-PE) MUST be identified before signaling begins for a given 549 MS-PW. Both T-PEs MUST use the same method for identifying which is 550 Active and which is Passive. 552 A T-PE SHOULD determine whether it assumes the active role or the 553 passive role using procedures similar to those of [RFC5036] Section 554 2.5.2, Bullet 2. The T-PE compares the Source Attachment Individual 555 Identifier (SAII) [RFC6074] with the Target Attachment Individual 556 Identifier (TAII) [RFC6074] as unsigned integers, and if the SAII > 557 TAII, the T-PE assumes the active role. Otherwise it assumes the 558 passive role. 560 The following procedure for comparing the SAII and TAII as unsigned 561 integers SHOULD be used: 563 - If the SAII Global ID > TAII Global ID, then the T-PE is active 564 - else if the SAII Global ID < TAII Global ID then the T-PE is 566 passive 567 - else if the SAII Prefix > TAII Prefix, then the T-PE is 568 active 569 - else if the SAII Prefix < TAII Prefix, then the T-PE is 570 passive 571 - else if the SAII AC-ID > TAII AC-ID, then the T-PE is 572 active 573 - else if the SAII AC-ID < TAII AC-ID, then the T-PE is 574 passive 575 - else there is a configuration error 577 4.2.3. Detailed Signaling Procedures 579 On receiving a Label Mapping message, the S-PE MUST inspect the FEC 580 TLV. If the receiving node has no local AII matching the TAII for 581 that label mapping then the Label Mapping message SHOULD be forwarded 582 on to another S-PE or T-PE. The S-PE will check if the FEC is already 583 installed for the forward direction: 584 - If the FEC is already installed, and the received Label Mapping 585 was received from the same LDP peer to which the forward LDP 586 Label Mapping was sent, then this Label Mapping represents 587 signaling in the reverse direction for this MS-PW segment. 588 - If the FEC is already installed, and the received Label Mapping 589 was received from a different LDP peer to which the forward LDP 590 Label Mapping was sent, then the received Label Mapping MUST be 591 released with the status code of "PW_LOOP_DETECTED". 592 - If the FEC is not already installed, then this represents 593 signaling in the forward direction. 595 The following procedures are then executed, depending on whether the 596 Label Mapping was determined to be for the forward or the reverse 597 direction of the MS-PW. 599 For the forward direction: 600 -i. Determine the next hop S-PE or T-PE according to the 601 procedures above. If next-hop reachability is not found in 602 the S-PE's PW AII routing table then a Label Release MUST be 603 sent with status code "AII_UNREACHABLE". If the next-hop S- 604 PE or T-PE is found and is the same LDP Peer that sent the 605 Label Mapping message then a Label Release MUST be returned 606 with the status code "PW_LOOP_DETECTED". If the SAII in the 607 received Label Mapping is local to the S-PE then a Label 608 Release MUST be returned with status code 609 "PW_LOOP_DETECTED". 611 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 612 If no tunnel exists to the next hop S-PE or T-PE, the S-PE 613 MAY attempt to setup a PSN tunnel. 614 -iii. Check that a PSN tunnel exists to the previous hop. If no 615 tunnel exists to the previous hop S-PE or T-PE, the S-PE MAY 616 attempt to setup a PSN tunnel. 617 -iv. If the S-PE cannot get enough PSN resources to setup the 618 segment to the next or previous hop S-PE or T-PE, a Label 619 Release MUST be returned to the T-PE with a status message 620 of "Resources Unavailable". 621 -v. If the Label Mapping message contains a Bandwidth TLV, 622 allocate the required resources on the PSN tunnels in the 623 forward and reverse directions according to the procedures 624 above. 625 -vi. Allocate a new PW label for the forward direction. 626 -vii. Install the FEC for the forward direction. 627 -viii. Send the Label Mapping message with the new forward label 628 and the FEC to the next hop S-PE/T-PE. 630 For the reverse direction: 631 -i. Install the FEC received int he Label Mapping message for 632 the reverse direction. 633 -ii. Determine the next signaling hop by referencing the LDP 634 sessions used to setup the PW in the Forward direction. 635 -iii. Allocate a new PW label for the next hop in the reverse 636 direction. 637 -iv. Install the FEC for the next hop in the reverse direction. 638 -v. Send the Label Mapping message with a new label and the FEC 639 to the next hop S-PE/ST-PE. 641 5. Failure Handling Procedures 643 5.1. PSN Failures 645 Failures of the PSN tunnel MUST be handled by PSN mechanisms. An 646 example of such a PSN mechanism is MPLS fast reroute [RFC4090]. If 647 the PSN is unable to re-establish the PSN tunnel, then the S-PE 648 SHOULD follow the procedures defined in Section 10 of [RFC6073]. 650 5.2. S-PE Specific Failures 652 For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be 653 followed. A T-PE or S-PE may receive an unsolicited Label Release 654 message from another S-PE or T-PE with various failure codes such 655 "LOOP_DETECTED", "PW_LOOP_DETECTED", "RESOURCE_UNAVAILBALE", 656 "BAD_STRICT_HOP", "AII_UNREACHABLE", etc. All these failure codes 657 indicate a generic class of PW failures at an S-PE or T-PE. 659 If an unsolicited Label Release message with such a failure status 660 code is received at T-PE, then it is RECOMMENDED that the T-PE 661 attempt to re-establish the PW immediately. However the T-PE MUST 662 throttle its PW setup message retry attempts with an exponential 663 backoff in situations where PW setup messages are being constantly 664 released. It is also RECOMMENDED that a T-PE detecting such a 665 situation take action to notify an operator. 667 S-PEs that receive an unsolicited Label Release message with a 668 failure status code SHOULD follow the following procedures: 670 -i. If the Label Release is received from an S-PE or T-PE in the 671 forward or reverse signaling direction then the S-PE MUST 672 tear down both segments of the PW. The status code received 673 in the Label Release message SHOULD be propagated when 674 sending the Label Release for the next-segment. 676 5.3. PW Reachability Changes 678 In general an established MS-PW will not be affected by next-hop 679 changes in AII reachability information. 681 If there is a change in next-hop of the AII reachability information 682 in the forward direction, the T-PE MAY elect to tear down the MS-PW 683 by sending a label withdraw message to downstream S-PE or T-PE. The 684 teardown MUST be also accompanied by a unsolicited Label Release 685 message, and will be followed by and attempt to re-establish of the 686 MS-PW by T-PE. 688 If there is a change in the AII reachability information in the 689 forward direction at S-PE, the S-PE MAY elect to tear down the MS-PW 690 in both directions. A label withdrawal is sent on each direction 691 followed by a unsolicited Label Release. The unsolicited Label 692 Releases MUST be accompanied by the Status code "AII_UNREACHABLE". 693 This procedure is OPTIONAL. Note that this procedure is likely to be 694 disruptive to the emulated service. PW Redundancy [RFC6718] MAY be 695 used to maintain the connectivity used by the emulated service in the 696 case of a failure of the PSN or S-PE. 698 A change in AII reachability information in the reverse direction has 699 no effect on an MS-PW. 701 6. Operations and Maintenance (OAM) 703 The OAM procedures defined in [RFC6073] may be used also for 704 dynamically placed MS-PWs. A PW switching point PE TLV is used 705 [RFC6073] to record the switching points that the PW traverses. 707 In the case of a MS-PW where the PW Endpoints are identified though 708 using a globally unique, FEC 129-based AII addresses, there is no 709 pseudowire identifier (PWID) defined on a per-segment basis. Each 710 individual PW segment is identified by the address of the adjacent 711 S-PE(s) in conjunction with the SAII and TAII. 713 In this case, the following TLV type (0x06) MUST be used in place of 714 type 0x01 in the PW switching point PE TLV: 716 Type Length Description 717 0x06 14 L2 PW address of PW Switching Point 719 The above sub-TLV MUST be included in the Switching Point PE TLV once 720 per individual PW Switching Point following the same rules and 721 procedures as described in [RFC6073]. A more detailed description of 722 this sub-TLV is also given in setion 7.4.1 of [RFC6073]. However, the 723 length value MUST be set to 14 (RFC6073 states that the length value 724 is 12, but this does not correctly represent the actual length of the 725 TLV). 727 7. Security Considerations 729 This document specifies extensions to the protocols already defined 730 in [RFC4447], and [RFC6073]. The extensions defined in this document 731 do not affect the security considerations for those protocols, but 732 [RFC4447] and [RFC6073] do impose a set of security considerations 733 that are applicable to the protocol extensions specified in this 734 document. 736 It should be noted that the dynamic path selection mechanisms 737 specified in this document enable the network to automatically select 738 the S-PEs that are used to forward packets on the MS-PW. Appropriate 739 tools, such as the VCCV Trace mechanisms specified in [RFC6073], can 740 be used by an operator of the network to verify the path taken by the 741 MS-PW and satisfy themselves that it does not represent an additional 742 security risk. 744 Note that the PW control protocol may be used to establish and 745 maintain an MS-PW across administrative boundaries. Section 13 of 746 [RFC6073] specifies security considerations applicable to LDP used in 747 this manner, including considerations on establishing the integrity 748 of, and authenticating, LDP control messages. This considerations 749 also apply to the protocol extensions specified in this document. 751 Note that the protocols for dynamically distributing AII reachability 752 information may have their own security considerations. However those 753 protocols specifications are outside the scope of this document. 755 8. IANA Considerations 757 8.1. Corrections 759 IANA is requested to correct a minor error in the registry 760 "Pseudowire Switching Point PE sub-TLV Type". The entry 0x06 "L2 PW 761 address of the PW Switching Point" should have Length 14 and the 762 reference changed to [RFC6073] and [RFC-to-be] as follows: 764 Type Length Description Reference -- 765 -----+--- 766 ---+------------------------------------+------------------------- 767 0x06 14 L2 PW Address of PW Switching Point [RFC6073] and 768 [RFC-to-be] 770 8.2. LDP TLV TYPE NAME SPACE 772 This document defines one new LDP TLV types. IANA already maintains a 773 registry for LDP TLV types called "Type, Length, and Value (TLV) 774 Type Name Space" within the "Label Distribution Protocol (LDP) 775 Parameters" as defined by RFC5036. IANA is requested to assign on 776 permanent basis the value (0x096E) that has been assigned to this 777 document by early allocation (TEMPORARY - Expires 2008-11-21).: 779 Value Description Reference Notes/Registration Date 780 ------+----------------+---------------+----------------------- 781 0x096E Bandwidth TLV This document 783 8.3. LDP Status Codes 785 This document defines three new LDP status codes. IANA maintains a 786 registry of these called the "STATUS CODE NAME SPACE" in the "Label 787 Distribution Protocol (LDP) Parameters" as defined by RFC5036. The 788 IANA is requested to assign on permanent basis the values that has 789 been assigned to this document by early allocation 790 (TEMPORARY - Expires 2008-11-21): 792 Range/Value E Description Reference 793 ------------- ----- ---------------------- --------- 794 0x00000037 0 Bandwidth resources unavailable This document 795 0x00000038 0 Resources Unavailable This document 796 0x00000039 0 AII Unreachable This document 798 8.4. BGP SAFI 800 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 801 Information used for Dynamic Placement of Multi-Segment Pseudowires" 802 from the IANA "Subsequence Address Family Identifiers (SAFI)" 803 registry. The IANA is requested to assign on permanent basis the 804 values that has been assigned to this document by early allocation 805 (TEMPORARY - Expires 2008-11-21):: 807 Value Description Reference 808 ----- ----------- --------- 809 6 Network Layer Reachability Information used This document 810 for Dynamic Placement of Multi-Segment 811 Pseudowires 813 9. References 815 9.1. Normative References 817 [RFC6073] Martini et.al. "Segmented Pseudowire", RFC6073, 818 January 2011 820 [RFC2210] Wroclawski, J. "The Use of RSVP with IETF Integrated 821 Services", RFC 2210, September 1997 823 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" 824 RFC5036, October 2007 826 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 827 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 828 June 2005. 830 [RFC5003] "Attachment Individual Identifier (AII) Types for 831 Aggregation", Metz, et al, RFC5003, September 2007 833 9.2. Informative References 835 [RFC5254] Martini et al, "Requirements for Multi-Segment Pseudowire 836 Emulation Edge-to-Edge (PWE3)", 837 RFC5254, Bitar, Martini, Bocci, October 2008 839 [RFC5659] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 840 Emulation Edge-to-Edge", RFC5659,October 2009. 842 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 843 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 845 [RFC6074] E. Rosen, W. Luo, B. Davie, V. Radoaca, 846 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 847 RFC6074, January 2011 849 [RFC4271] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP-4)", 850 RFC4271, January 2006 852 [RFC6391] Bryant, S., et al, "Flow-Aware Transport of Pseudowires 853 over an MPLS Packet Switched Network", RFC6391, November 2011 855 [RFC4090] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE for LSP 856 Tunnels", RFC4090, May 2005 858 [RFC6718] Muley, P., et al, "Pseudowire Redundancy", RFC6718, August 859 2012 861 10. Contributors 863 The editors gratefully acknowledge the following additional co- 864 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 865 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 866 Sugimoto. 868 11. Acknowledgements 870 The editors also gratefully acknowledge the input of the following 871 people: Mike Duckett, Paul Doolan, Pranjal Dutta, Prayson Pate, Ping 872 Pan, Vasile Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 874 12. Author's Addresses 876 Luca Martini 877 Cisco Systems, Inc. 878 9155 East Nichols Avenue, Suite 400 879 Englewood, CO, 80112 880 e-mail: lmartini@cisco.com 882 Matthew Bocci 883 Alcatel-Lucent, 884 Voyager Place 885 Shoppenhangers Road 886 Maidenhead 887 Berks, UK 888 e-mail: matthew.bocci@alcatel-lucent.com 890 Florin Balus 891 Alcatel-Lucent 892 701 E. Middlefield Rd. 893 Mountain View, CA 94043 894 e-mail: florin.balus@alcatel-lucent.com 896 Nabil Bitar 897 Verizon 898 40 Sylvan Road 899 Waltham, MA 02145 900 e-mail: nabil.bitar@verizon.com 902 Himanshu Shah 903 Ciena Corp 904 35 Nagog Park, 905 Acton, MA 01720 906 e-mail: hshah@ciena.com 907 Mustapha Aissaoui 908 Alcatel-Lucent 909 600 March Road 910 Kanata 911 ON, Canada 912 e-mail: mustapha.aissaoui@alcatel-lucent.com 914 Jason Rusmisel 915 Alcatel-Lucent 916 600 March Road 917 Kanata 918 ON, Canada 919 e-mail: Jason.rusmisel@alcatel-lucent.com 921 Andrew G. Malis 922 Huawei 923 2330 Central Expressway 924 Santa Clara CA 95050 925 e-mail: agmalis@gmail.com 927 Chris Metz 928 Cisco Systems, Inc. 929 3700 Cisco Way 930 San Jose, Ca. 95134 931 e-mail: chmetz@cisco.com 933 David McDysan 934 Verizon 935 22001 Loudoun County Pkwy 936 Ashburn, VA, USA 20147 937 e-mail: dave.mcdysan@verizon.com 939 Jeff Sugimoto 940 Alcatel-Lucent 941 701 E. Middlefield Rd. 942 Mountain View, CA 94043 943 e-mail: jeffery.sugimoto@alcatel-lucent.com 944 Mike Loomis 945 Alcatel-Lucent 946 701 E. Middlefield Rd. 947 Mountain View, CA 94043 948 e-mail: mike.loomis@alcatel-lucent.com 950 Copyright Notice 952 Copyright (c) 2014 IETF Trust and the persons identified as the 953 document authors. All rights reserved. 955 This document is subject to BCP 78 and the IETF Trust's Legal 956 Provisions Relating to IETF Documents 957 (http://trustee.ietf.org/license-info) in effect on the date of 958 publication of this document. Please review these documents 959 carefully, as they describe your rights and restrictions with respect 960 to this document. Code Components extracted from this document must 961 include Simplified BSD License text as described in Section 4.e of 962 the Trust Legal Provisions and are provided without warranty as 963 described in the Simplified BSD License. 965 This document may contain material from IETF Documents or IETF 966 Contributions published or made publicly available before November 967 10, 2008. The person(s) controlling the copyright in some of this 968 material may not have granted the IETF Trust the right to allow 969 modifications of such material outside the IETF Standards Process. 970 Without obtaining an adequate license from the person(s) controlling 971 the copyright in such materials, this document may not be modified 972 outside the IETF Standards Process, and derivative works of it may 973 not be created outside the IETF Standards Process, except to format 974 it for publication as an RFC or to translate it into languages other 975 than English. 977 Expiration Date: September 2014