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