idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 (March 9, 2009) is 5527 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 638, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-11 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-06 Summary: 3 errors (**), 0 flaws (~~), 4 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: September 2009 Matthew Bocci (Ed.) 5 Intended status: Standards Track Florin Balus (Ed.) 6 Alcatel-Lucent 8 March 9, 2009 10 Dynamic Placement of Multi Segment Pseudo Wires 12 draft-ietf-pwe3-dynamic-ms-pw-09.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 9, 2009 37 Abstract 39 There is a requirement for service providers to be able to extend the 40 reach of pseudo wires (PW) across multiple Packet Switched Network 41 domains. A Multi-Segment PW is defined as a set of two or more 42 contiguous PW segments that behave and function as a single point- 43 to-point PW. This document describes extensions to the PW control 44 protocol to dynamically place the segments of the multi segment 45 pseudo wire among a set of Provider Edge (PE) routers. 47 Table of Contents 49 1 Specification of Requirements ........................ 3 50 2 Major Co-authors ..................................... 3 51 3 Acknowledgements ..................................... 3 52 4 Introduction ......................................... 3 53 4.1 Scope ................................................ 3 54 4.2 Terminology .......................................... 4 55 4.3 Architecture Overview ................................ 4 56 5 Applicability ........................................ 6 57 5.1 Requirements Addressed ............................... 6 58 5.2 Changes to Existing PW Signaling ..................... 6 59 6 PW layer 2 addressing ................................ 6 60 6.1 Attachment Circuit Addressing ........................ 7 61 6.2 S-PE addressing ...................................... 7 62 7 Dynamic placement of MS-PWs .......................... 8 63 7.1 Pseudo wire routing procedures ....................... 8 64 7.1.1 AII PW routing table Lookup aggregation rules ........ 8 65 7.1.2 PW Static Route ...................................... 9 66 7.1.3 Dynamic advertisement with BGP ....................... 9 67 7.2 LDP Signaling ........................................ 10 68 7.2.1 MS-PW Bandwidth Signaling ............................ 10 69 7.2.2 Active/Passive T-PE Election Procedure ............... 12 70 7.2.3 Detailed Signaling Procedures ........................ 12 71 7.2.4 Support for Explicit PW Path ......................... 13 72 8 Failure Handling Procedures .......................... 14 73 8.1 PSN Failures ......................................... 14 74 8.2 S-PE Reachability Failures ........................... 14 75 9 Operations and Maintenance (OAM) ..................... 14 76 10 Security Considerations .............................. 15 77 11 IANA Considerations .................................. 15 78 11.1 LDP Status Codes ..................................... 15 79 11.2 BGP SAFI ............................................. 16 80 12 Normative References ................................. 16 81 13 Informative References ............................... 16 82 14 Author's Addresses ................................... 17 84 1. Specification of Requirements 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119. 90 2. Major Co-authors 92 The editors gratefully acknowledge the following additional co- 93 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 94 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 95 Sugimoto. 97 3. Acknowledgements 99 The editors also gratefully acknowledge the input of the following 100 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 101 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 103 4. Introduction 105 4.1. Scope 107 [MS-REQ] describes the service provider requirements for extending 108 the reach of pseudo-wires across multiple PSN domains. This is 109 achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is 110 defined as a set of two or more contiguous PW segments that behave 111 and function as a single point-to-point PW. This architecture is 112 described in [MS-ARCH]. 114 The procedures for establishing PWs that extend across a single PWE3 115 domain are described in [RFC4447], while procedures for setting up 116 PWs across multiple domains, or control planes are described in [PW- 117 SEG]. 119 The purpose of this draft is to specify extensions to the PWE3 120 control protocol [RFC4447], and [PW-SEG] procedures, to enable 121 multi-segment PWs to be automatically placed. The proposed procedures 122 follow the guidelines defined in [RFC5036] and enable the reuse of 123 existing TLVs, and procedures defined for SS-PWs in [RFC4447]. 125 4.2. Terminology 127 [MS-ARCH] provides terminology for multi-segment pseudo wires. 129 This document defines the following additional terms: 131 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 132 assumes the active signaling role and initiates the signaling for 133 multi-segment PW. 134 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 135 assumes the passive signaling role. It waits and responds to the 136 multi-segment PW signaling message in the reverse direction. 137 - Forward Direction: ST-PE to TT-PE. 138 - Reverse Direction: TT-PE to ST-PE 139 - Forwarding Direction: Direction of control plane, signaling flow 140 - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs 141 that compose an MS-PW, as well as the automatic selection of S- 142 PEs. 144 4.3. Architecture Overview 146 The following figure describes the reference models which are derived 147 from [MS-ARCH] to support PW emulated services across multi-segment 148 PWs. 150 Native |<-------------Pseudo Wire----------->| Native 151 Service | | Service 152 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 153 | V V V V V V | 154 | +-----+ +-----+ +-----+ 155 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 156 | |-------|.....PW.Seg't1........PW Seg't3......|----------| | 157 | CE1| | | | | | | | | |CE2 | 158 | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | 159 +----+ | | |=========| |=========| | | +----+ 160 ^ +-----+ +-----+ +-----+ ^ 161 | Provider Edge 1 ^ Provider Edge 2 | 162 | | | 163 | | | 164 | PW switching point | 165 | | 166 |<---------------- Emulated Service -------------------->| 168 Figure 1: PW switching Reference Model 170 Figure 1 shows the architecture for a simple multi-segment case. T- 171 PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in 172 different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, 173 and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs 174 are used to connect the attachment circuits (ACs) attached to T-PE1 175 to the corresponding AC attached to T-PE2. A PW on the tunnel across 176 PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to 177 complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 178 is therefore the PW switching point and will be referred to as the 179 switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are 180 segments of the same MS-PW while PW Segment 2 and PW Segment 4 are 181 segments of another MS-PW. PW segments of the same MS-PW (e.g., PW 182 segment 1 and PW segment 3) MUST be of the same PW type, and PSN 183 tunnels (e.g., PSN1 and PSN2) can be the same or different 184 technology. An S-PE switches an MS-PW from one segment to another 185 based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are 186 switched at the S-PE depends on the PSN tunnel technology: in case of 187 an MPLS PSN to another MPLS PSN PW switching the operation is a 188 standard MPLS label switch operation. 190 Note that although Figure 1 only shows a single S-PE, a PW may 191 transit more one S-PE along its path. For instance, in the multi- 192 provider case, there can be an S-PE at the border of one provider 193 domain and another S-PE at the border of the other provider domain. 195 5. Applicability 197 In this document we describe the case where the PSNs carrying the 198 SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions 199 with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are 200 left for further study. 202 5.1. Requirements Addressed 204 Specifically the following requirements are addressed [MS-REQ]: 205 - Dynamic End-to-end Signaling 206 - Scalability and Inter-domain Signaling and Routing 207 - Minimal number of provisioning touches (provisioning only at the 208 T-PEs) 209 - Same set of T-PEs/S-PEs for both directions of a MS-PWs 210 - QoS Signaling, Call Admission Control 211 - Resiliency 212 - End-to-end negotiation of OAM Capability 214 5.2. Changes to Existing PW Signaling 216 The procedures described in this document make use of existing LDP 217 TLVs and related PW signaling procedures described in [RFC4447] and 218 [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS 219 Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" 220 section for details). 222 6. PW layer 2 addressing 224 Single segment pseudo wires on an MPLS PSN use Attachment circuit 225 identifiers for a PW using FEC 129. In the case of an automatically 226 placed MS-PW, there is a requirement to have individual global 227 addresses assigned to PW attachment circuits, for reachability , and 228 manageability of the PW. Referencing figure 1 above, individual 229 globally unique addresses MUST be allocated to all the ACs , and S- 230 PEs composing an MS-PW. 232 6.1. Attachment Circuit Addressing 234 The attachment circuit addressing is derived from [RFC5003] AII type 235 2 shown here: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | AII Type=02 | Length | Global ID | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Global ID (contd.) | Prefix | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix (contd.) | AC ID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | AC ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Implementations of the following procedure MUST interpret the AII 250 type to determine the meaning of the address format of the AII, 251 irrespective of the number of segments in the MS-PW. 253 A unique combination Global ID, Prefix, and AC ID parts of the AII 254 type 2 will be assigned to each AC. In general the same global ID and 255 prefix will be assigned for all ACs belonging to the same T-PE, 256 however this is not a strict requirement. A particular T-PE might 257 have more than one prefix assigned to it, and likewise a fully 258 qualified AII with the same Global ID/Prefix but different AC IDs 259 might belong to different T-PEs. 261 For the purpose of MS-PW the AII MUST be globally unique across all 262 interconnected PW domains. 264 6.2. S-PE addressing 266 The T-PE may elect to select a known specific path along a set of S- 267 PEs for a specific PW. This requires that each S-PE be uniquely 268 addressable in terms of pseudo wires. For this purpose at least one 269 AI address of the format similar to AII type 2 [RFC5003] composed of 270 the Global ID, and Prefix part only MUST be assigned to each S-PE. 272 7. Dynamic placement of MS-PWs 274 [PW-SEG] describes a procedure for connecting multiple pseudo wires 275 together. This procedure requires each S-PE to be manually configured 276 with the information required to terminate and initiate the SS-PW 277 part of the MS-PW. The procedures in the following sections describe 278 an method to extend [PW-SEG] by allowing the automatic selection of 279 pre-defined S-PEs, and automatically setting up a MS-PW between two 280 T-PEs. 282 7.1. Pseudo wire routing procedures 284 The AII type 2 described above contains a Global ID, Prefix, and AC 285 ID. The TAII is used by S-PEs to determine the next SS-PW destination 286 for LDP signaling. 288 Once an S-PE receives a MS-PW label mapping message containing a TAII 289 with an AII that is not locally present, the S-PE performs a lookup 290 in a local Layer 2 AII PW routing table. If this lookup results in an 291 IP address of the next PE that advertised reachability information 292 for the AII in question, then the S-PE will initiate the necessary 293 LDP messaging procedure for setting up the next PW segment. If the 294 AII PW routing table lookup does not result in a IP address of the 295 next PE, the destination AII has become unreachable, and the PW MUST 296 fail to setup. In this case the next PW segment is considered 297 unprovisioned, and a label release MUST be returned to the T-PE with 298 a status message of "AII Unreachable". 300 If the TAI of a MS-PW label mapping message, received by a PE, 301 contains the prefix of a locally provisioned prefix on that PE, but 302 an AC ID that is not provisioned, then the LDP liberal label 303 retention procedures apply, and the label mapping message is 304 retained. 306 To allow for dynamic end-to-end signaling of MS-PWs, information must 307 be present in S-PEs to support the determination of the next PW 308 signaling hop. Such information can be provisioned (static route 309 equivalent) on each S-PE system or disseminated via regular routing 310 protocols (e.g. BGP). 312 7.1.1. AII PW routing table Lookup aggregation rules 314 All PEs capable of dynamic multi segment pseudowire path selection, 315 must build a PW routing table to be used for PW next hop selection. 317 The PW addressing scheme (AII type 2 in [RFC5003]) consists of a 318 Global Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. 320 An aggregation scheme similar with the one used for classless IPv4 321 addresses can be employed. An (8 bits) length mask is specified as a 322 number ranging from 0 to 96 that indicates which Most Significant 323 Bits (MSB) are relevant in the address field when performing the PW 324 address matching algorithm. 326 0 31 32 63 64 95 (bits) 327 +-----------+--------+--------+ 328 | Global ID | Prefix | AC ID | 329 +-----------+--------+--------+ 331 During the signaling phase, the content of the (fully qualified) TAII 332 type 2 field from the FEC129 TLV is compared against routes from the 333 PW Routing table. Similar with the IPv4 case, the route with the 334 longest match is selected, determining the next signaling hop and 335 implicitly the next PW Segment to be signaled. 337 7.1.2. PW Static Route 339 For the purpose of determining the next signaling hop for a segment 340 of the pseudo wire, the PEs MAY be provisioned with fixed route 341 entries in the PW next hop routing table. The static PW entries will 342 follow all the addressing rules and aggregation rules described in 343 the previous sections. The most common use of PW static provisioned 344 routes is this example of the "default" route entry as follows: 346 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 347 Hop = S-PE1 349 7.1.3. Dynamic advertisement with BGP 351 Any suitable routing protocol capable of carrying external routing 352 information may be used to propagate MS-PW path information among S- 353 PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use Boundary 354 Gateway Protocol (BGP) [RFC4760] to propagate PW address information 355 throughout the PSN. 357 Contrary to other l2vpn signaling methods that use BGP [L2- 358 SIGNALING], in the case of the dynamically placed MS-PW if the source 359 T-PE knows a priori (by provisioning) the address of the terminating 360 T-PE. Hence there is no need to advertise a "fully qualified" 96 bit 361 address on a per PW Attachment Circuit basis. Only the T-PE Global 362 ID, Prefix, and prefix length needs to be advertised as part of well 363 known BGP procedures - see [RFC4760]. 365 As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this 366 information to obtain the first S-PE hop (i.e., first BGP next hop) 367 to where the first PW segment will be established. Any subsequent S- 368 PEs will use the same information (i.e. the next BGP next-hop(s)) to 369 obtain the next-signaling-hop(s) on the path to the TT-PE. 371 The PW dynamic path NLRI is advertised in BGP UPDATE messages using 372 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, 373 SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6 374 (pending IANA allocation)). 376 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 377 an IPv4 address, whenever the length of the NextHop address is 4 378 octets, and as a IPv6 address, whenever the length of the NextHop 379 address is 16 octets. 381 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 382 of 0 to 96 bits encoded as defined in section 4 of [RFC4760]. 384 This prefix is structured as follows: 386 0 31 32 63 64 95 (bits) 387 +-----------+--------+--------+ 388 | Global ID | Prefix | AC ID | 389 +-----------+--------+--------+ 391 Except for the default PW route, which is encoded as a 0 length 392 prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to 393 95 are invalid as the AC ID field cannot be aggregated. 395 7.2. LDP Signaling 397 The LDP signaling procedures are described in [RFC4447] and expanded 398 in [PW-SEG]. No new LDP Signaling components are required for setting 399 up a dynamically placed MS-PW. However some optional signaling 400 extensions are described below. 402 7.2.1. MS-PW Bandwidth Signaling 404 In the SS-PW case the PW QoS requirements may easily be met by 405 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 406 requirements. However in the case of an automatically placed MS-PW 407 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 408 be indicated along with the MS-PW addressing. This is accomplished by 409 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 410 specified as follows: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |1|0| PW BW TLV (0x096E) | TLV Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Forward SENDER_TSPEC | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Reverse SENDER_TSPEC | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 The complete definitions of the content of the SENDER_TSPEC objects 423 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 424 the data path in the direction of ST-PE to TT-PE. The reverse 425 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 427 In the forward direction, after a next hop selection is determined, a 428 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 429 an appropriate PSN tunnel towards the next signaling hop. If such a 430 tunnel exists, the MS-PW signaling procedures are invoked with the 431 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 432 tunnel, any tunnel which points to a next hop equivalent to the next 433 hop selected will be included in the search.(The LDP address TLV is 434 used to determine the next hop equivalence) 436 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 437 selected, the S/T-PE MUST request the appropriate resources from the 438 PSN. The resources described in the reverse SENDER_TSPEC are 439 allocated from the PSN toward the originator of the message or 440 previous hop. When resources are allocated from the PSN for a 441 specific PW, then the PSN SHOULD account for the PW usage of the 442 resources. 444 In the case where PSN resources towards the previous hop are not 445 available the following procedure MUST be followed: 446 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 447 the PSN tunnel. 448 -ii. The S-PE MAY attempt to setup another PSN tunnel to 449 accommodate the new PW QoS requirements. 450 -iii. If the S-PE cannot get enough resources to setup the segment 451 in the MS-PW a label release MUST be returned to the 452 previous hop with a status message of "Bandwidth resources 453 unavailable" 455 In the latter case, the T-PE receiving the status message MUST also 456 withdraw the corresponding PW label mapping for the opposite 457 direction if it has already been successfully setup. 459 If an ST-PE receives a label mapping message the following procedure 460 MUST be followed: 462 If the ST-PE has already sent a label mapping message for this PW 463 then the ST-PE must check that this label mapping message originated 464 from the same LDP peer to which the corresponding label mapping 465 message for this particular PW was sent. If it is the same peer, the 466 the PW is established. If it is a different peer, then ST-PE MUST 467 send a label release message, with a status code of "Duplicate AII" 468 to the PE that originate the LDP label mapping message. 470 If the PE has not yet sent a label mapping message for this 471 particular PW , then it MUST send the label mapping message to this 472 same LDP peer, regardless of what the PW TAII routing lookup result 473 is. 475 7.2.2. Active/Passive T-PE Election Procedure 477 When a MS-PW is signaled, Each T-PE might independently start 478 signaling the MS-PW, this could result in a different path selected 479 for each T-PE PW. To avoid this situation one of the T-PE MUST start 480 the PW signaling (active role), while the other waits to receive the 481 LDP label mapping before sending the respective PW LDP label mapping 482 message. (passive role). The Active T-PE (the ST-PE) and the passive 483 T-PE (the TT-PE) MUST be identified before signaling is initiated for 484 a given MS-PW. 486 The determination of which T-PE assume the active role SHOULD be done 487 as follows: the SAII and TAII are compared as unsigned integers, if 488 the SAII is bigger then the T-PE assumes the active role. 490 The selection process to determine which T-PE assumes the active role 491 MAY be superseded by manual provisioning. 493 7.2.3. Detailed Signaling Procedures 495 On receiving a label mapping message, the S-PE MUST inspect the FEC 496 TLV. If the receiving node has no local AII matching the TAII for 497 that label mapping then the S-PE will check if the FEC is already 498 installed for the forward direction: 500 - If it is already installed, and the received mapping was received 501 from the same LDP peer where the forward LDP label mapping was 502 sent, then this label mapping represents signaling in the reverse 503 direction for this MS-PW segment. 504 - Otherwise this represents signaling in the forward direction. 506 For the forward direction: 507 -i. Determine the next hop S-PE or T-PE according to the 508 procedures above. 509 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 510 If no tunnel exists to the next hop S-PE or T-PE the S-PE 511 MAY attempt to setup a PSN tunnel. 512 -iii. Check that a PSN tunnel exists to the previous hop. If no 513 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 514 attempt to setup a PSN tunnel. 515 -iv. If the S-PE cannot get enough PSN resources to setup the 516 segment to the next or previous S-PE or T-PE, a label 517 release MUST be returned to the T-PE with a status message 518 of "Resources Unavailable". 519 -v. If the label mapping message contains a Bandwidth TLV, 520 allocate the required resources on the PSN tunnels in the 521 forward and reverse directions according to the procedures 522 above. 523 -vi. Allocate a new PW label for the forward direction. 524 -vii. Install the FEC for the forward direction. 525 -viii. Send the label mapping message with the new forward label 526 and the FEC to the next hop S-PE/T-PE. 528 For the reverse direction: 529 -i. Install the received FEC for the reverse direction. 530 -ii. Determine the next signaling hop by referencing the LDP 531 sessions used to setup the LSP in the Forward direction. 532 -iii. Allocate a new PW label for the reverse direction. 533 -iv. Install the FEC for the reverse direction. 534 -v. Send the label mapping message with a new label and the FEC 535 to the next hop S-PE/ST-PE. 537 7.2.4. Support for Explicit PW Path 539 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 540 used to signal an explicit path for a MS-PW. An Explicit PW path may 541 be required to provide a simple solution for 1:1 protection with 542 diverse primary and backup path or to enable controlled signaling 543 (strict or loose) for special PWs. Details of its usage to be 544 provided in a future study. 546 8. Failure Handling Procedures 548 8.1. PSN Failures 550 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 551 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 552 follow the procedures defined in Section 8 of [PW-SEG]. 554 8.2. S-PE Reachability Failures 556 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 557 followed. However in general an established MS-PW will not be 558 affected by changes in L2 PW reachability information. 560 T-PEs that receive a label release message with a status of "AII 561 Unreachable" MUST re-attempt to establish the PW immediately. However 562 the T-PE MUST throttle its PW setup message retry attempts with an 563 exponential backoff in situations where PW setup messages are being 564 constantly released. It is also recommended that a T-PE detecting 565 such a situation take action to notify an operator. 567 If there is a change in the L2 PW reachability information in the 568 forward direction only, the T-PE MAY elect to tear down the MS-PW by 569 sending a label withdraw message and re-establish the MS-PW. In the 570 same case, an S-PE MAY do the same by sending a label withdraw 571 message in the forward direction, and a label release message in the 572 opposite direction along the MS-PW. 574 A change in L2 reachability information in the reverse direction has 575 no effect on an MS-PW. 577 9. Operations and Maintenance (OAM) 579 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 580 PW switching point TLV is used [PW-SEG] to record the switching 581 points that the PW traverses. 583 In the case of a MS-PW where the PW Endpoints are identified though 584 using a globally unique, FEC 129-based AII addresses, there is no 585 PWID defined on a per segment basis. Each individual PW segment is 586 identified by the address of adjacent S-PE(s) in conjunction with the 587 SAI and TAI. In this case, the following type MUST be used in place 588 of type 0x01 in the PW switching point TLV: 590 Type Length Description 591 0x06 10 L2 PW address of PW Switching Point 593 The above field MUST be included together with type 0x02 in the TLV 594 once per individual PW Switching Point following the same rules and 595 procedures as described in [PW-SEG]. 597 10. Security Considerations 599 This document specifies only extensions to the protocols already 600 defined in [RFC4447], and [PW-SEG]. Each such protocol may have its 601 own set of security issues, but those issues are not affected by the 602 extensions specified herein. Note that the protocols for dynamically 603 distributing PW Layer 2 reachability information may have their own 604 security issues, however those protocols specifications are outside 605 the scope of this document. 607 11. IANA Considerations 609 This document uses several new LDP TLV types, IANA already maintains 610 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 611 following value is suggested for assignment: 613 TLV type Description 614 0x096E Bandwidth TLV 616 11.1. LDP Status Codes 618 This document uses several new LDP status codes, IANA already 619 maintains a registry of name "STATUS CODE NAME SPACE" defined by 620 RFC3036. The following values have been pre-allocated: 622 Range/Value E Description Reference 623 ------------- ----- ---------------------- --------- 624 0x00000037 0 Bandwidth resources unavailable RFCxxxx 625 0x00000038 0 Resources Unavailable RFCxxxx 626 0x00000039 0 AII Unreachable RFCxxxx 627 0x0000003A 0 PW Loop Detected RFCxxxx 629 11.2. BGP SAFI 631 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 632 Information used for Dynamic Placement of Multi-Segment Pseudiwires" 633 from the IANA "Subsequence Address Family Identifiers (SAFI)" 634 registry. The following value has been pre-allocated: 636 Value Description Reference 637 ----- ----------- --------- 638 6 Network Layer Reachability Information used [RFCxxxx] 639 for Dynamic Placement of Multi-Segment 640 Pseudowires 642 12. Normative References 644 [PW-SEG] Martini et.al. "Segmented Pseudo Wire", 645 draft-ietf-pwe3-segmented-pw-11.txt, IETF Work in Progress, 646 February 2009 648 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 649 Services", RFC 2210, September 1997 651 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" 652 RFC5036, October 2007 654 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 655 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 656 June 2005. 658 [RFC5003] "Attachment Individual Identifier (AII) Types for 659 Aggregation", Metz, et al, RFC5003, September 2007 661 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", 662 RFC3212, January 2002. 664 13. Informative References 666 [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire 667 Emulation Edge-to-Edge (PWE3)", 668 RFC5023, Bitar, Martini, Bocci, October 2008 670 [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 671 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-06.txt, 672 February 2009, IETF work in progress 674 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 675 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 677 [L2-SIGNALING] E. Rosen, W. Luo, B. Davie, V. Radoaca, 678 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 679 draft-ietf-l2vpn-signaling-08.txt May 3, 2006.(work in progress) 681 14. Author's Addresses 683 Luca Martini 684 Cisco Systems, Inc. 685 9155 East Nichols Avenue, Suite 400 686 Englewood, CO, 80112 687 e-mail: lmartini@cisco.com 689 Matthew Bocci 690 Alcatel-Lucent, 691 Voyager Place 692 Shoppenhangers Road 693 Maidenhead 694 Berks, UK 695 e-mail: matthew.bocci@alcatel-lucent.co.uk 697 Florin Balus 698 Alcatel-Lucent 699 701 E. Middlefield Rd. 700 Mountain View, CA 94043 701 e-mail: florin.balus@alcatel-lucent.com 703 Nabil Bitar 704 Verizon 705 40 Sylvan Road 706 Waltham, MA 02145 707 e-mail: nabil.bitar@verizon.com 709 Himanshu Shah 710 Ciena Corp 711 35 Nagog Park, 712 Acton, MA 01720 713 e-mail: hshah@ciena.com 714 Mustapha Aissaoui 715 Alcatel-Lucent 716 600 March Road 717 Kanata 718 ON, Canada 719 e-mail: mustapha.aissaoui@alcatel-lucent.com 721 Jason Rusmisel 722 Alcatel-Lucent 723 600 March Road 724 Kanata 725 ON, Canada 726 e-mail: Jason.rusmisel@alcatel-lucent.com 728 Yetik Serbest 729 SBC Labs 730 9505 Arboretum Blvd. 731 Austin, TX 78759 732 e-mail: Yetik_serbest@labs.sbc.com 734 Andrew G. Malis 735 Verizon 736 2730 Orchard Parkway 737 San Jose, CA, USA 95134 738 e-mail: Andy.Malis@tellabs.com 740 Chris Metz 741 Cisco Systems, Inc. 742 3700 Cisco Way 743 San Jose, Ca. 95134 744 e-mail: chmetz@cisco.com 746 David McDysan 747 Verizon 748 22001 Loudoun County Pkwy 749 Ashburn, VA, USA 20147 750 e-mail: dave.mcdysan@verizon.com 751 Jeff Sugimoto 752 Nortel 753 3500 Carling Ave. 754 Ottawa, Ontario, CANADA 755 e-mail: sugimoto@nortel.com 757 Mike Duckett 758 Bellsouth 759 Lindbergh Center D481 760 575 Morosgo Dr 761 Atlanta, GA 30324 762 e-mail: mduckett@bellsouth.net 764 Mike Loomis 765 Nortel 766 600, Technology Park Dr 767 Billerica, MA, USA 768 e-mail: mloomis@nortel.com 770 Paul Doolan 771 Mangrove Systems 772 IO Fairfield Blvd 773 Wallingford, CT, USA 06492 774 e-mail: pdoolan@mangrovesystems.com 776 Ping Pan 777 Hammerhead Systems 778 640 Clyde Court 779 Mountain View, CA, USA 94043 780 e-mail: ppan@hammerheadsystems.com 782 Prayson Pate 783 Overture Networks, Inc. 784 507 Airport Blvd, Suite 111 785 Morrisville, NC, USA 27560 786 e-mail: prayson.pate@overturenetworks.com 788 Vasile Radoaca 789 Alcatel-Lucent 790 Optics Divison, Westford, MA, USA 791 email: vasile.radoaca@alcatel-lucent.com 792 Yuichiro Wada 793 NTT Communications 794 3-20-2 Nishi-Shinjuku, Shinjuke-ku 795 Tokyo 163-1421, Japan 796 e-mail: yuichiro.wada@ntt.com 798 Yeongil Seo 799 Korea Telecom Corp. 800 463-1 Jeonmin-dong, Yusung-gu 801 Daejeon, Korea 802 e-mail: syi1@kt.co.kr 804 Full Copyright Statement 806 Copyright (c) 2009 IETF Trust and the persons identified as the 807 document authors. All rights reserved. 809 This document is subject to BCP 78 and the IETF Trust's Legal 810 Provisions Relating to IETF Documents in effect on the date of 811 publication of this document (http://trustee.ietf.org/licenseinfo). 812 Please review these documents carefully, as they describe your rights 813 and restrictions with respect to this document. 815 This document may contain material from IETF Documents or IETF 816 Contributions published or made publicly available before November 817 10, 2008. The person(s) controlling the copyright in some of this 818 material may not have granted the IETF Trust the right to allow 819 modifications of such material outside the IETF Standards Process. 820 Without obtaining an adequate license from the person(s) controlling 821 the copyright in such materials, this document may not be modified 822 outside the IETF Standards Process, and derivative works of it may 823 not be created outside the IETF Standards Process, except to format 824 it for publication as an RFC or to translate it into languages other 825 than English. 827 Expiration Date: September 2009