idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 184: '... PW1 and PW3) MUST be of the same PW...' RFC 2119 keyword, line 233: '... addresses MUST be allocated to all ...' RFC 2119 keyword, line 253: '...lowing procedure MUST interpret the AI...' RFC 2119 keyword, line 265: '...of MS-PW the AII MUST be globally uniq...' RFC 2119 keyword, line 274: '...Prefix part only MUST be assigned to e...' (30 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6526 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) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-00 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-rfc3036bis-03 -- Possible downref: Normative reference to a draft: ref. 'AII' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-02 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-06 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group Luca Martini (Ed.) 3 Internet Draft Cisco Systems Inc. 4 Expires: December 2006 Matthew Bocci (Ed.) 5 Alcatel 6 Florin Balus (Ed.) 7 Nortel 9 June 2006 11 Dynamic Placement of Multi Segment Pseudo Wires 13 draft-ietf-pwe3-dynamic-ms-pw-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 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 .......................... 13 73 8.1 PSN Failures ......................................... 13 74 8.2 S-PE Failures ........................................ 14 75 9 Operations and Maintenance (OAM) ..................... 14 76 10 Security Considerations .............................. 14 77 11 IANA Considerations .................................. 15 78 11.1 LDP Status Codes ..................................... 15 79 11.2 BGP SAFI ............................................. 15 80 12 Full Copyright Statement ............................. 15 81 13 Intellectual Property Statement ...................... 16 82 14 Normative References ................................. 16 83 15 Informative References ............................... 17 84 16 Author Information ................................... 17 86 1. Specification of Requirements 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 92 2. Major Co-authors 94 The editors gratefully acknowledge the following additional co- 95 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 96 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 97 Sugimoto. 99 3. Acknowledgements 101 The editors also gratefully acknowledge the input of the following 102 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 103 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 105 4. Introduction 107 4.1. Scope 109 [MS-REQ] describes the service provider requirements for extending 110 the reach of pseudo-wires across multiple PSN domains. This is 111 achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is 112 defined as a set of two or more contiguous PW segments that behave 113 and function as a single point-to-point PW. This architecture is 114 described in [MS-ARCH]. 116 The procedures for establishing PWs that extend across a single PWE3 117 domain are described in [RFC4447], while procedures for setting up 118 PWs across multiple domains, or control planes are described in [PW- 119 SEG]. 121 The purpose of this draft is to specify extensions to the PWE3 122 control protocol [RFC4447], and [PW-SEG] procedures, to enable 123 multi-segment PWs to be automatically placed. The proposed procedures 124 follow the guidelines defined in [RFC3036bis] and enable the reuse of 125 existing TLVs, and procedures defined for SS-PWs in [RFC4447]. 127 4.2. Terminology 129 [MS-ARCH] provides terminology for multi-segment pseudo wires. 131 This document defines the following additional terms: 133 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 134 assumes the active signaling role and initiates the signaling for 135 multi-segment PW. 136 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 137 assumes the passive signaling role. It waits and responds to the 138 multi-segment PW signaling message in the reverse direction. 139 - Forward Direction: ST-PE to TT-PE. 140 - Reverse Direction: TT-PE to ST-PE 141 - Forwarding Direction: Direction of control plane, signaling flow 142 - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs 143 that compose an MS-PW, as well as the automatic selection of S- 144 PEs. 146 4.3. Architecture Overview 148 The following figure describes the reference models which are derived 149 from [MS-ARCH] to support PW emulated services across multi-segment 150 PWs. 152 Native |<-------------Pseudo Wire----------->| Native 153 Service | | Service 154 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 155 | V V V V V V | 156 | +-----+ +-----+ +-----+ 157 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 158 | |-------|.....PW.Seg't1........PW Seg't3......|----------| | 159 | CE1| | | | | | | | | |CE2 | 160 | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | 161 +----+ | | |=========| |=========| | | +----+ 162 ^ +-----+ +-----+ +-----+ ^ 163 | Provider Edge 1 ^ Provider Edge 2 | 164 | | | 165 | | | 166 | PW switching point | 167 | | 168 |<------------------- Emulated Service -------------------->| 170 Figure 1: PW switching Reference Model 172 Figure 1 shows the architecture for a simple multi-segment case. T- 173 PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in 174 different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, 175 and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs 176 are used to connect the attachment circuits (ACs) attached to T-PE1 177 to the corresponding AC attached to T-PE2. A PW on the tunnel across 178 PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to 179 complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 180 is therefore the PW switching point and will be referred to as the PW 181 switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are 182 segments of the same MS-PW while PW Segment 2 and PW Segment 4 are 183 segments of another pseudo-wire. PW segments of the same MS-PW (e.g., 184 PW1 and PW3) MUST be of the same PW type, and PSN tunnels (e.g., PSN1 185 and PSN2) can be the same or different technology. An S-PE switches 186 an MS-PW from one segment to another based on the PW identifiers. ( 187 PWid , or AII ) How the Pw PDUs are switched at the S-PE depends on 188 the PSN tunnel technology: in case of an MPLS PSN to another MPLS PSN 189 PW switching the operation is a standard MPLs label switch operation. 191 Note that although Figure 1 only shows a single S-PE, a PW may 192 transit more one S-PE along its path. For instance, in the multi- 193 provider case, there can be an S-PE at the border of one provider 194 domain and another S-PE at the border of the other provider domain. 196 5. Applicability 198 In this document we describe the case where the PSNs carrying the 199 SS-PW are only MPLS PSNs using the generalized FEC 129. Furthermore, 200 we consider the case of a ST-PE and/or TT-PE supporting FEC 128 only 201 and which establish a MS-PW through a network of FEC 129 S-PEs. 202 Interactions with an IP PSN using L2TPv3 as described in [PW-SEG] 203 section 7.4 are left for further study. 205 5.1. Requirements Addressed 207 Specifically the following requirements are addressed - see [MS-REQ]: 208 - Dynamic End-to-end Signaling 209 - Scalability and Inter-domain Signaling and Routing 210 - Minimal number of provisioning touches (provisioning only at the 211 T-PEs) 212 - Same set of T-PEs/S-PEs for both directions of a MS-PWs 213 - QoS Signaling, Call Admission Control 214 - Resiliency 215 - End-to-end negotiation of OAM Capability 217 5.2. Changes to Existing PW Signaling 219 The procedures described in this document make use of existing LDP 220 TLVs and related PW signaling procedures described in [RFC4447] and 221 [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS 222 Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" 223 section for details). 225 6. PW layer 2 addressing 227 Single segment pseudo wires on an MPLS PSN use the PWID for 228 addressing a PW using FEC 128, and Attachment circuit identifiers for 229 a PW using FEC 129. In the case of an automatically placed MS-PW, 230 there is a requirement to have individual global addresses assigned 231 to PW attachment circuits, for reachability , and manageability of 232 the PW. Referencing figure 1 above, individual globally unique 233 addresses MUST be allocated to all the ACs , and S-PEs composing an 234 MS-PW. 236 6.1. Attachment Circuit Addressing 238 The attachment circuit addressing is derived from [AII] AII type 2 239 shown here: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | AII Type=02 | Length | Global ID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Global ID (contd.) | Prefix | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Prefix (contd.) | AC ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | AC ID | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Implementations of the following procedure MUST interpret the AII 254 type to determine the meaning the address format of the AII, 255 irrespective of the number of segments in the MS-PW. 257 A unique combination Global ID, Prefix, and AC ID parts of the AII 258 type 2 will be assigned to each AC. In general the same global ID and 259 prefix will be assigned for all ACs belonging to the same T-PE, 260 however this is not a strict requirement. A particular T-PE might 261 have more than one prefix assigned to it, and likewise a fully 262 qualified AII with the same Global ID/Prefix but different AC IDs 263 might belong to different T-PEs. 265 For the purpose of MS-PW the AII MUST be globally unique across all 266 interconnected PW domains. 268 6.2. S-PE addressing 270 The T-PE may elect to select a known specific path along a set of S- 271 PEs for a specific PW. This requires that each S-PE be uniquely 272 addressable in terms of pseudo wires. For this purpose at least one 273 AI address of the format similar to AII type 2 [AII] composed of the 274 Global ID, and Prefix part only MUST be assigned to each S-PE. 276 7. Dynamic placement of MS-PWs 278 [PW-SEG] describes a procedure for connecting multiple pseudo wires 279 together. This procedure requires each S-PE to be manually configured 280 with the information required to terminate and initiate the SS-PW 281 part of the MS-PW. The procedures in the following sections describe 282 an method to extend [PW-SEG] by allowing the automatic selection of 283 pre-defined S-PEs, and automatically setting up a MS-PW between two 284 T-PEs. 286 In this document we consider the case where the PSNs carrying the 287 SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions 288 with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are 289 left for further study. 291 7.1. Pseudo wire routing procedures 293 The AII type 2 described above contains a Global ID, Prefix, and AC 294 ID. The TAII is used by S-PEs to determine the next SS-PW destination 295 for LDP signaling. 297 Once an S-PE receives a PW Setup message containing a TAII with an 298 AII that is not locally present, the S-PE performs a lookup in a 299 local Layer 2 AII PW routing table. If this lookup results in an IP 300 address of the next PE that advertised reachability information for 301 the AII in question, then the S-PE will initiate the necessary LDP 302 messaging procedure for setting up the next PW segment. If the AII PW 303 routing table lookup does not result in a IP address of the next PE, 304 the destination AII has become unreachable, and the PW MUST fail to 305 setup. In this case a label release MUST be returned to the T-PE with 306 a status message of "AII Unreachable". 308 To allow for dynamic end-to-end signaling of MS-PWs, information must 309 be present in S-PEs to support the determination of the next PW 310 signaling hop. Such information can be provisioned (static route 311 equivalent) on each S-PE system or disseminated via regular routing 312 protocols (e.g. BGP). 314 7.1.1. AII PW routing table Lookup aggregation rules 316 All PEs capable of dynamic multi segment pseudowire path selection, 317 must build a PW routing table to be used for PW next hop selection. 319 The PW addressing scheme (AII type 2 in [AII]) consists of a Global 320 Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. 322 An aggregation scheme similar with the one used for classless IPv4 323 addresses can be employed. An (8 bits) length mask is specified as a 324 number ranging from 0 to 96 that indicates which Least Significant 325 Bits (LSB) are ignored in the address field when performing the PW 326 address matching algorithm. 328 0 31 32 63 64 95 (bits) 329 +-----------+--------+--------+ 330 | Global ID | Prefix | AC ID | 331 +-----------+--------+--------+ 333 During the signaling phase, the content of the (fully qualified) TAII 334 type 2 field from the FEC129 TLV is compared against routes from the 335 PW Routing table. Similar with the IPv4 case, the route with the 336 longest match is selected, determining the next signaling hop and 337 implicitly the next PW Segment to be signaled. 339 7.1.2. PW Static Route 341 For the purpose of determining the next signaling hop for a segment 342 of the pseudo wire, the PEs MAY be provisioned with fixed route 343 entries in the PW next hop routing table. The static PW entries will 344 follow all the addressing rules and aggregation rules described in 345 the previous sections. The most common use of PW static provisioned 346 routes is this example of the "default" route entry as follows: 348 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 349 Hop = S-PE1 351 7.1.3. Dynamic advertisement with BGP 353 Any suitable routing protocol capable of carring external routing 354 information may be used to propogate MS-PW path infomation among S- 355 PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use [RFC2858] 356 to propagate PW address information throughout the PSN. 358 In the case of the MS-PW if the Source T-PE knows apriori the address 359 of the Terminating T-PE, there is no need to advertise a "fully 360 qualified" address on a per PW Attachment Circuit. Only the T-PE 361 Global ID, Prefix, and prefix length needs to be advertised as part 362 of well known BGP procedures - see [RFC2858] and, [L2VPN-SIG]. 364 As PW Endpoints are provisioned in the T-PEs, the ST-PE will use this 365 information to obtain the first S-PE hop (i.e., first BGP next hop) 366 where the first PW segment will be established and subsequent S-PEs 367 will use the same information (i.e. the next BGP next-hop(s)) to 368 obtain the next-signaling-hop(s) on the path to the TT-PE. 370 The PW dynamic path NLRI is advertised in BGP UPDATE messages using 371 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The [AFI, 372 SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=TBD). 374 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 375 an IPv4 address, whenever the length of NextHop address is 4 octets, 376 and as a IPv6 address, whenever the length of the NextHop address is 377 16 octets. 379 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 380 of 0 to 96 bits encoded as defined in section 4 of [RFC2858]. 382 This prefix is structured as follows: 384 0 31 32 63 64 95 (bits) 385 +-----------+--------+--------+ 386 | Global ID | Prefix | AC ID | 387 +-----------+--------+--------+ 389 Except for the default PW route, which is encoded as a 0 length 390 prefix, the minimum prefix length is 32 bits. As the Global ID field 391 cannot be interpreted as a prefix. 393 7.2. LDP Signaling 395 The LDP signaling procedures are described in [RFC4447] and expanded 396 in [PW-SEG]. No new LDP Signaling components are required for setting 397 up a basic automatically placed MS-PW. However some optional 398 signaling extensions are described below. 400 7.2.1. MS-PW Bandwidth Signaling 402 In the SS-PW case the PW QoS requirements may easily be met by 403 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 404 requirements. However in the case of an automatically placed MS-PW 405 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 406 be indicated along with the MS-PW addressing. This is accomplished by 407 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 408 specified as follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |1|0| PW BW TLV (0x096E) | TLV Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Forward SENDER_TSPEC | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Reverse SENDER_TSPEC | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 The complete definitions of the content of the SENDER_TSPEC objects 421 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 422 the datapath in the direction of ST-PE to TT-PE. The reverse 423 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 425 In the forward direction, after a next hop selection is determined, a 426 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 427 an appropriate PSN tunnel towards the next signaling hop. If such a 428 tunnel exists, the MS-PW signaling procedures are invoked with the 429 inclusion of the PW Bandwidth TLV. 431 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 432 selected, the S/T-PE MUST request the appropriate resources from the 433 PSN. The resources described in the reverse SENDER_TSPEC are 434 allocated from the PSN toward the originator of the message or 435 previous hop. When resources are allocated from the PSN for a 436 specific PW, then the PSN SHOULD account for the PW usage of the 437 resources. 439 In the case where PSN resources towards the previous hop are not 440 available the following procedure MUST be followed: 441 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 442 the PSN tunnel. 443 -ii. The S-PE MAY attempt to setup another PSN tunnel to 444 accommodate the new PW QoS requirements. 445 -iii. If the S-PE cannot get enough resources to setup the segment 446 in the MS-PW a label release MUST be returned to the 447 previous hop with a status message of "Bandwidth resources 448 unavailable" 450 In the latter case, the T-PE receiving the status message MUST also 451 withdraw the corresponding PW label mapping for the opposite 452 direction if it has already been successfully setup. 454 7.2.2. Active/Passive T-PE Election Procedure 456 When a MS-PW is signaled, Each T-PE might independently start 457 signaling the MS-PW, this could result in a different path selected 458 for each T-PE PW. To avoid this situation one of the T-PE MUST start 459 the PW signaling ( active role ), while the other waits to receive 460 the LDP label mapping before sending the respective PW LDP label 461 mapping message. ( passive role ). The Active T-PE (the ST-PE) and 462 the passive T-PE (the TT-PE) MUST be identified before signaling is 463 initiated for a given MS-PW. 465 The determination of which T-PE assume the active role SHOULD be done 466 as follows: the SAII and TAII are compared as unsigned integers, if 467 the SAII is bigger then the T-PE assumes the active role. 469 The selection process to determine which T-PE assumes the active role 470 MAY be superseded by manual provisioning. 472 If a ST-PE receives a reply MS-PW setup message for a particular MS- 473 PW from a PE that is not the next hop PE originally used, then the 474 ST-PE MUST send a label release message, with a status code of 475 "Duplicate AII", to the PE that originated the incorrect MS-PW reply 476 setup message. 478 7.2.3. Detailed Signaling Procedures 480 On receiving a label mapping message, the S-PE MUST inspect the FEC 481 TLV. If the receiving node has no local AII matching the TAII for 482 that label mapping then the S-PE will check if the FEC is already 483 installed for the forward direction: 484 - If it is already installed, and the received mapping was received 485 from the same LDP peer where the forward LDP label mapping was 486 sent, then this label mapping represents signaling in the reverse 487 direction for this MS-PW segment. 488 - Otherwise this represents signaling in the forward direction. 490 For the forward direction: 491 -i. Determine the next hop S-PE or T-PE according to the 492 procedures above. 493 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 494 If no tunnel exists to the next hop S-PE or T-PE the S-PE 495 MAY attempt to setup a PSN tunnel. 496 -iii. Check that a PSN tunnel exists to the previous hop. If no 497 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 498 attempt to setup a PSN tunnel. 500 -iv. If the S-PE cannot get enough PSN resources to setup the 501 segment to the next or previous S-PE or T-PE, a label 502 withdraw MUST be returned to the T-PE with a status message 503 of "Resources Unavailable". 504 -v. If the label mapping message contains a Bandwidth TLV, 505 allocate the required resources on the PSN tunnels in the 506 forward and reverse directions according to the procedures 507 above. 508 -vi. Allocate a new PW label for the forward direction. 509 -vii. Install the FEC for the forward direction. 510 -viii. Send the label mapping message with the new forward label 511 and the FEC to the next hop S-PE/T-PE. 513 For the reverse direction: 514 -i. Install the received FEC for the reverse direction. 515 -ii. Determine the next signaling hop by referencing the LDP 516 sessions used to setup the LSP in the Forward direction. 517 -iii. Allocate a new PW label for the reverse direction. 518 -iv. Install the FEC for the reverse direction. 519 -v. Send the label mapping message with a new label and the FEC 520 to the next hop S-PE/ST-PE. 522 7.2.4. Support for Explicit PW Path 524 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 525 used to signal an explicit path for a MS-PW. An Explicit PW path may 526 be required to provide a simple solution for 1:1 protection with 527 diverse primary and backup path or to enable controlled signaling 528 (strict or loose) for special PWs. Details of its usage to be 529 provided in a future version. 531 8. Failure Handling Procedures 533 8.1. PSN Failures 535 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 536 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 537 follow the procedures defined in Section 8 of [PW-SEG]. 539 8.2. S-PE Failures 541 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 542 followed. However the ST-PE MAY re-signal the PW if an alternate 543 path is available. 545 9. Operations and Maintenance (OAM) 547 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 548 PW switching point TLV is used [PW-SEG] to record the switching 549 points that the PW traverses. 551 In the case of a MS-PW where the PW Endpoints are identified though 552 using a globally unique, FEC 129-based AII addresses, there is no 553 PWID defined on a per segment basis. Each individual PW segment is 554 identified by the address of adjacent S-PE(s) in conjunction with the 555 SAII and TAII. In this case, the following type MUST be used in place 556 of type 0x01 in the PW switching point TLV: 558 Type Length Description 559 0x04 8 Global ID/Prefix of the S-PE 561 The above field MUST be included together with type 0x02 in the TLV 562 once per individual PW Switching Point following the same rules and 563 procedures as described in [PW-SEG]. 565 10. Security Considerations 567 This document specifies only extensions to the protocols already 568 defined in [RFC4447], and [PW-SEG]. Each such protocol may have its 569 own set of security issues, but those issues are not affected by the 570 extensions specified herein. Note that the protocols for dynamically 571 distributing PW Layer 2 reachability information may have their own 572 security issues, however those protocols specifications are outside 573 the scope of this document. 575 11. IANA Considerations 577 This document uses several new LDP TLV types, IANA already maintains 578 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 579 following value is suggested for assignment: 581 TLV type Description 582 0x096E Bandwidth TLV 584 11.1. LDP Status Codes 586 This document uses several new LDP status codes, IANA already 587 maintains a registry of name "STATUS CODE NAME SPACE" defined by 588 RFC3036. The following value are suggested for assignment: 590 Range/Value E Description Reference 591 ------------- ----- ---------------------- --------- 592 TBD 0 Bandwidth resources unavailable RFCxxxx 593 TBD 0 Resources Unavailable RFCxxxx 594 TBD 0 AII Unreachable RFCxxxx 596 11.2. BGP SAFI 598 IANA needs to allocate a new BGP SAFI for "Psedo Wire routing 599 information" from the L2VPN SAFI registry. 601 12. Full Copyright Statement 603 Copyright (C) The Internet Society (2006). 605 This document is subject to the rights, licenses and restrictions 606 contained in BCP 78, and except as set forth therein, the authors 607 retain all their rights. 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 612 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 613 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 614 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 13. Intellectual Property Statement 619 The IETF takes no position regarding the validity or scope of any 620 Intellectual Property Rights or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; nor does it represent that it has 624 made any independent effort to identify any such rights. Information 625 on the procedures with respect to rights in RFC documents can be 626 found in BCP 78 and BCP 79. 628 Copies of IPR disclosures made to the IETF Secretariat and any 629 assurances of licenses to be made available, or the result of an 630 attempt made to obtain a general license or permission for the use of 631 such proprietary rights by implementers or users of this 632 specification can be obtained from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its attention any 636 copyrights, patents or patent applications, or other proprietary 637 rights that may cover technology that may be required to implement 638 this standard. Please address the information to the IETF at ietf- 639 ipr@ietf.org. 641 14. Normative References 643 [PW-SEG] Martini et.al. "Segmented Pseudo Wire", 644 draft-ietf-pwe3-segmented-pw-00.txt, IETF Work in Progress, 645 July 2005 647 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 648 Services", RFC 2210, September 1997 650 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" 651 draft-ietf-mpls-rfc3036bis-03.txt, IETF Work in Progress, 652 October 2005 654 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al 655 draft-ietf-pwe3-control-protocol-17.txt, ( work in progress ), 656 June 2005. 658 [AII] "Pseudowire Attachment Identifiers for Aggregation and 659 VPN Autodiscovery", Chris M., et al 660 draft-metz-aii-aggregate-01.txt, October 2006 (work in progress) 661 February, 2006 663 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", 664 RFC3212, January 2002. 666 15. Informative References 668 [MS-REQ] Martini et al, "Requirements for Inter-domain Pseudo-Wires", 669 draft-ietf-pwe3-ms-pw-requirements-02, Martini, et al., 670 June 2006 672 [MS-ARCH] Bocci at al, "Architecture for Multi-Segment PWE3", 673 draft-bocci-bryant-pwe3-ms-pw-arch-01.txt, September 2005. 674 ( work in progress ) 676 [L2VPN-SIG] E. Rosen, et Al. "Provisioning, Autodiscovery, 677 and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt, 678 September 2005 ( work in progress ) 680 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 681 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 683 16. Author Information 685 Luca Martini 686 Cisco Systems, Inc. 687 9155 East Nichols Avenue, Suite 400 688 Englewood, CO, 80112 689 e-mail: lmartini@cisco.com 691 Matthew Bocci 692 Alcatel Telecom Ltd, 693 Voyager Place 694 Shoppenhangers Road 695 Maidenhead 696 Berks, UK 697 e-mail: matthew.bocci@alcatel.co.uk 699 Florin Balus 700 Nortel 701 3500 Carling Ave. 702 Ottawa, Ontario, CANADA 703 e-mail: balus@nortel.com 704 Nabil Bitar 705 Verizon 706 40 Sylvan Road 707 Waltham, MA 02145 708 e-mail: nabil.bitar@verizon.com 710 Himanshu Shah 711 Ciena Corp 712 35 Nagog Park, 713 Acton, MA 01720 714 e-mail: hshah@ciena.com 716 Mustapha Aissaoui 717 Alcatel 718 600 March Road 719 Kanata 720 ON, Canada 721 e-mail: mustapha.aissaoui@alcatel.com 723 Jason Rusmisel 724 Alcatel 725 600 March Road 726 Kanata 727 ON, Canada 728 e-mail: Jason.rusmisel@alcatel.com 730 Yetik Serbest 731 SBC Labs 732 9505 Arboretum Blvd. 733 Austin, TX 78759 734 e-mail: Yetik_serbest@labs.sbc.com 736 Andrew G. Malis 737 Tellabs, Inc. 738 2730 Orchard Parkway 739 San Jose, CA, USA 95134 740 e-mail: Andy.Malis@tellabs.com 741 Chris Metz 742 Cisco Systems, Inc. 743 3700 Cisco Way 744 San Jose, Ca. 95134 745 e-mail: chmetz@cisco.com 747 David McDysan 748 MCI 749 22001 Loudoun County Pkwy 750 Ashburn, VA, USA 20147 751 e-mail: dave.mcdysan@mci.com 753 Jeff Sugimoto 754 Nortel 755 3500 Carling Ave. 756 Ottawa, Ontario, CANADA 757 e-mail: sugimoto@nortel.com 759 Mike Duckett 760 Bellsouth 761 Lindbergh Center D481 762 575 Morosgo Dr 763 Atlanta, GA 30324 764 e-mail: mduckett@bellsouth.net 766 Mike Loomis 767 Nortel 768 600, Technology Park Dr 769 Billerica, MA, USA 770 e-mail: mloomis@nortel.com 772 Paul Doolan 773 Mangrove Systems 774 IO Fairfield Blvd 775 Wallingford, CT, USA 06492 776 e-mail: pdoolan@mangrovesystems.com 777 Ping Pan 778 Hammerhead Systems 779 640 Clyde Court 780 Mountain View, CA, USA 94043 781 e-mail: ppan@hammerheadsystems.com 783 Prayson Pate 784 Overture Networks, Inc. 785 507 Airport Blvd, Suite 111 786 Morrisville, NC, USA 27560 787 e-mail: prayson.pate@overturenetworks.com 789 Vasile Radoaca 790 radoaca@hotmail.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