idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-00.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 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. ** 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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 2005) is 6707 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: 'RFC3212' is mentioned on line 510, but not defined == Missing Reference: 'IANA' is mentioned on line 610, but not defined == Unused Reference: 'PWE3-IANA' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC3270' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'BRADNER' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC3985' is defined on line 690, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-06 == 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-01 -- Possible downref: Normative reference to a draft: ref. 'AII' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-00 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-06 -- Obsolete informational reference (is this intentional?): RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group Florin Balus (Ed.) 3 Internet Draft Nortel 4 Expires: June 2006 Luca Martini (Ed.) 5 Cisco Systems Inc. 6 Matthew Bocci (Ed.) 7 Alcatel 9 December 2005 11 Dynamic Placement of Multi Segment Pseudo Wires 13 draft-ietf-pwe3-dynamic-ms-pw-00.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 Public 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 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 5.3 PW layer 2 addressing ................................ 6 60 5.3.1 Attachment Circuit Addressing ........................ 7 61 5.3.2 S-PE addressing ...................................... 7 62 6 Dynamic placement of MS-PWs .......................... 8 63 6.1 LDP Signaling ........................................ 8 64 6.1.1 MS-PW Next Hop Bandwidth Signaling ................... 8 65 6.2 Path selection and next hop determination ............ 9 66 6.2.1 AII PW routing table Lookup aggregation rules ........ 10 67 6.2.2 PW Static Route ...................................... 10 68 6.2.3 Dynamic advertisement with BGP ....................... 11 69 6.3 Active/Passive T-PE Election Procedure ............... 11 70 6.4 Detailed Signaling Procedures ........................ 11 71 7 Failure Handling Procedures .......................... 12 72 7.1 PSN Failures ......................................... 13 73 7.2 S-PE Failures ........................................ 13 74 8 Support for Explicit PW Path ......................... 13 75 9 Operations and Maintenance (OAM) ..................... 13 76 10 Use of FEC 128 ....................................... 14 77 11 Security Considerations .............................. 14 78 12 IANA Considerations .................................. 15 79 12.1 LDP Status Codes ..................................... 15 80 12.2 Interface Parameter Sub-TLV type ..................... 15 81 13 Full Copyright Statement ............................. 15 82 14 Intellectual Property Statement ...................... 16 83 15 Normative References ................................. 16 84 16 Informative References ............................... 17 85 17 Author Information ................................... 17 87 1. Specification of Requirements 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 93 2. Major Co-authors 95 The editors gratefully acknowledge the following additional co- 96 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 97 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 98 Sugimoto. 100 3. Acknowledgements 102 The editors also gratefully acknowledge the input of the following 103 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 104 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 106 4. Introduction 108 4.1. Scope 110 [MS-REQ] describes the service provider requirements for extending 111 the reach of pseudo-wires across multiple PSN domains. This is 112 achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is 113 defined as a set of two or more contiguous PW segments that behave 114 and function as a single point-to-point PW. This architecture is 115 described in [MS-ARCH]. 117 The procedures for establishing PWs that extend across a single PWE3 118 domain are described in [PWE3-CTRL], while procedures for setting up 119 PWs across multiple domains, or control planes are described in [PW- 120 SEG]. 122 The purpose of this draft is to specify extensions to the PWE3 123 control protocol [PWE3-CTRL], and [PW-SEG] procedures, to enable 124 multi-segment PWs to be automatically placed. The proposed procedures 125 follow the guidelines defined in [RFC3036bis] and enable the reuse of 126 existing TLVs, and procedures defined for SS-PWs in [PWE3-CTRL]. 128 4.2. Terminology 130 [MS-ARCH] provides terminology for multi-segment pseudo wires. 132 This document defines the following additional terms: 134 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 135 assumes the active signaling role and initiates the signaling for 136 multi-segment PW. 137 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 138 assumes the passive signaling role. It waits and responds to the 139 multi-segment PW signaling message in the reverse direction. 140 - Forward Direction: ST-PE to TT-PE. 141 - Reverse Direction: TT-PE to ST-PE 142 - Forwarding Direction: Direction of control plane, signaling flow 143 - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs 144 that compose an MS-PW, as well as the automatic selection of S- 145 PEs. 147 4.3. Architecture Overview 149 The following figure describes the reference models which are derived 150 from [MS-ARCH] to support PW emulated services across multi-segment 151 PWs. 153 Native |<-------------Pseudo Wire----------->| Native 154 Service | | Service 155 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 156 | V V V V V V | 157 | +-----+ +-----+ +-----+ 158 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 159 | |-------|.....PW.Seg't1........PW Seg't3......|----------| | 160 | CE1| | | | | | | | | |CE2 | 161 | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | 162 +----+ | | |=========| |=========| | | +----+ 163 ^ +-----+ +-----+ +-----+ ^ 164 | Provider Edge 1 ^ Provider Edge 2 | 165 | | | 166 | | | 167 | PW switching point | 168 | | 169 |<------------------- Emulated Service -------------------->| 171 Figure 1: PW switching Reference Model 173 Figure 1 shows the architecture for a simple multi-segment case. T- 174 PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in 175 different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, 176 and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs 177 are used to connect the attachment circuits (ACs) attached to T-PE1 178 to the corresponding AC attached to T-PE2. A PW on the tunnel across 179 PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to 180 complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 181 is therefore the PW switching point and will be referred to as the PW 182 switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are 183 segments of the same MS-PW while PW Segment 2 and PW Segment 4 are 184 segments of another pseudo-wire. PW segments of the same MS-PW (e.g., 185 PW1 and PW3) MUST be of the same PW type, and PSN tunnels (e.g., PSN1 186 and PSN2) can be the same or different technology. An S-PE switches 187 an MS-PW from one segment to another based on the PW identifiers. ( 188 PWid , or AII ) How the Pw PDUs are switched at the S-PE depends on 189 the PSN tunnel technology: in case of an MPLS PSN to another MPLS PSN 190 PW switching the operation is a standard MPLs label switch operation. 192 Note that although Figure 1 only shows a single S-PE, a PW may 193 transit more one S-PE along its path. For instance, in the multi- 194 provider case, there can be an S-PE at the border of one provider 195 domain and another S-PE at the border of the other provider domain. 197 5. Applicability 199 In this document we describe the case where the PSNs carrying the 200 SS-PW are only MPLS PSNs using the generalized FEC 129. Furthermore, 201 we consider the case of a ST-PE and/or TT-PE supporting FEC 128 only 202 and which establish a MS-PW through a network of FEC 129 S-PEs. 203 Interactions with an IP PSN using L2TPv3 as described in [PW-SEG] 204 section 7.4 are left for further study. 206 5.1. Requirements Addressed 208 Specifically the following requirements are addressed - see [MS-REQ]: 209 - Dynamic End-to-end Signaling 210 - Scalability and Inter-domain Signaling and Routing 211 - Minimal number of provisioning touches (provisioning only at the 212 T-PEs) 213 - Same set of T-PEs/S-PEs for both directions of a MS-PWs 214 - QoS Signaling, Call Admission Control 215 - Resiliency 216 - End-to-end negotiation of OAM Capability 218 5.2. Changes to Existing PW Signaling 220 The procedures described in this document make use of existing LDP 221 TLVs and related PW signaling procedures described in [PWE3-CTRL] and 222 [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS 223 Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" 224 section for details). 226 5.3. PW layer 2 addressing 228 Single segment pseudo wires on an MPLS PSN use the PWID for 229 addressing a PW using FEC 128, and Attachment circuit identifiers for 230 a PW using FEC 129. In the case of an automatically placed MS-PW, 231 there is a requirement to have individual global addresses assigned 232 to PW attachment circuits, for reachability , and manageability of 233 the PW. Referencing figure 1 above, individual globally unique 234 addresses MUST be allocated to all the ACs , and S-PEs composing an 235 MS-PW. 237 5.3.1. Attachment Circuit Addressing 239 The attachment circuit addressing is derived from [AII] AII type 2 240 shown here: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | AII Type=02 | Length | Global ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Global ID (contd.) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Prefix | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | AC ID | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Implementations of the following procedure MUST interpret the AII 255 type to determine the meaning the address format of the AII, 256 irrespective of the number of segments in the MS-PW. 258 A unique combination Global ID, Prefix, and AC ID parts of the AII 259 type 2 will be assigned to each AC. In general the same global ID and 260 prefix will be assigned for all ACs belonging to the same T-PE, 261 however this is not a strict requirement. A particular T-PE might 262 have more than one prefix assigned to it, and likewise a fully 263 qualified AII with the same Global ID/Prefix but different AC IDs 264 might belong to different T-PEs. 266 For the purpose of MS-PW the AII MUST be globally unique across all 267 interconnected PW domains. 269 5.3.2. S-PE addressing 271 The T-PE may elect to select a known specific path along a set of S- 272 PEs for a specific PW. This requires that each S-PE be uniquely 273 addressable in terms of pseudo wires. For this purpose at least one 274 AI address of the format similar to AII type 2 [AII] composed of the 275 Global ID, and Prefix part only MUST be assigned to each S-PE. 277 6. Dynamic placement of MS-PWs 279 [PW-SEG] describes a procedure for connecting multiple pseudo wires 280 together. This procedure requires each S-PE to be manually configured 281 with the information required to terminate and initiate the SS-PW 282 part of the MS-PW. The procedures in the following sections describe 283 an method to extend [PW-SEG] by allowing the automatic selection of 284 pre-defined S-PEs, and automatically setting up a MS-PW between two 285 T-PEs. 287 In this document we consider the case where the PSNs carrying the 288 SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions 289 with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are 290 left for further study. 292 6.1. LDP Signaling 294 The LDP signaling procedures are described in [PWE3-CTRL] and 295 expanded in [PW-SEG]. No new LDP Signaling components are required 296 for setting up a basic automatically placed MS-PW. However some 297 optional signaling extensions are described below. 299 6.1.1. MS-PW Next Hop Bandwidth Signaling 301 In the SS-PW case the PW QoS requirements may easily be met by 302 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 303 requirements. However in the case of an automatically placed MS-PW 304 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 305 be indicated along with the MS-PW addressing. This is accomplished by 306 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 307 specified as follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |1|0| PW BW TLV (0x096E) | TLV Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Forward SENDER_TSPEC | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Reverse SENDER_TSPEC | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 The complete definitions of the content of the SENDER_TSPEC objects 320 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 321 the datapath in the direction of ST-PE to TT-PE. The reverse 322 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 324 In the forward direction, after a next hop selection is determined, a 325 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 326 an appropriate PSN tunnel towards the next signaling hop. If such a 327 tunnel exists, the MS-PW signaling procedures are invoked with the 328 inclusion of the PW Bandwidth TLV. 330 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 331 selected, the S/T-PE MUST request the appropriate resources from the 332 PSN. The resources described in the reverse SENDER_TSPEC are 333 allocated from the PSN toward the originator of the message or 334 previous hop. When resources are allocated from the PSN for a 335 specific PW, then the PSN SHOULD account for the PW usage of the 336 resources. 338 In the case where PSN resources towards the previous hop are not 339 available the following procedure MUST be followed: 340 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 341 the PSN tunnel. 342 -ii. The S-PE MAY attempt to setup another PSN tunnel to 343 accommodate the new PW QoS requirements. 344 -iii. If the S-PE cannot get enough resources to setup the segment 345 in the MS-PW a label release MUST be returned to the 346 previous hop with a status message of "Bandwidth resources 347 unavailable" 349 In the latter case, the T-PE receiving the status message MUST also 350 withdraw the corresponding PW label mapping for the opposite 351 direction if it has already been successfully setup. 353 6.2. Path selection and next hop determination 355 The AII type 2 described above contains a Global ID, Prefix, and AC 356 ID. The global ID , and the Prefix are used by S-PEs to determine the 357 next SS-PW destination for LDP signaling. 359 Once an S-PE receives a PW Setup message containing a TAII with an 360 AII that is not locally present, the S-PE performs a lookup in a 361 local Layer 2 AII PW routing table. If this lookup results in an IP 362 address of the next PE that advertised reachability information for 363 the AII in question, then the S-PE will initiate the necessary LDP 364 messaging procedure for setting up the next PW segment. If the AII PW 365 routing table lookup does not result in a IP address of the next PE, 366 the destination AII has become unreachable, and the PW MUST fail to 367 setup. In this case a label release MUST be returned to the T-PE with 368 a status message of "AII Unreachable". 370 To allow for dynamic end-to-end signaling of MS-PWs, information must 371 be present in S-PEs to support the determination of the next PW 372 signaling hop. Such information can be provisioned (static route 373 equivalent) on each S-PE system or disseminated via regular routing 374 protocols (e.g. BGP). 376 6.2.1. AII PW routing table Lookup aggregation rules 378 All PEs capable of dynamic multi segment pseudowire path selection, 379 must build a PW routing table to be used for PW next hop selection. 381 The PW addressing scheme (AII type 2 in [AII]) consists of a Global 382 Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. 384 An aggregation scheme similar with the one used for classless IPv4 385 addresses can be employed. An (8 bits) length mask is specified as a 386 number ranging from 0 to 112 that indicates which Least Significant 387 Bits (LSB) are ignored in the address field when performing the PW 388 address matching algorithm. 390 0 47 48 79 80 111 (bits) 391 +------------+--------+--------+ 392 | Global ID | Prefix | AC ID | 393 +------------+--------+--------+ 395 During the signaling phase, the content of the (fully qualified) TAII 396 type 2 field from the FEC129 TLV is compared against routes from the 397 PW Routing table. Similar with the IPv4 case, the route with the 398 longest match is selected, determining the next signaling hop and 399 implicitly the next PW Segment to be signaled. 401 6.2.2. PW Static Route 403 For the purpose of determining the next signaling hop for a segment 404 of the pseudo wire, the PEs MAY be provisioned with fixed route 405 entries in the PW next hop routing table. The static PW entries will 406 follow all the addressing rules and aggregation rules described in 407 the previous sections. The most common use of PW static provisioned 408 routes is the "default" route entry as follows: 410 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 411 Hop = S-PE1 413 6.2.3. Dynamic advertisement with BGP 415 T-PE, And S-PEs, MAY choose to use [MP-BGP] to propagate PW address 416 information throughout the PSN. 418 In the case of the MS-PW if the Source T-PE knows apriori the address 419 of the Terminating T-PE, there is no need to advertise a "fully 420 qualified" address on a per PW Attachment Circuit. Only the T-PE 421 Global ID, Prefix, and prefix length needs to be advertised as part 422 of well known BGP procedures - see [MP-BGP], [L2VPN-SIG]. The 423 specific details, and encoding of the PW routing information in BGP 424 are outside the scope of this document. 426 As PW Endpoints are provisioned in the T-PEs, the ST-PE will use this 427 information to obtain the first S-PE hop (i.e., first BGP next hop) 428 where the first PW segment will be established and subsequent S-PEs 429 will use the same information (i.e. the next BGP next-hop(s)) to 430 obtain the next-signaling-hop(s) on the path to the TT-PE. 432 6.3. Active/Passive T-PE Election Procedure 434 When a MS-PW is signaled, Each T-PE might independently start 435 signaling the MS-PW, this could result in a different path selected 436 for each T-PE PW. To avoid this situation one of the T-PE MUST start 437 the PW signaling ( active role ), while the other waits to receive 438 the LDP label mapping before sending the respective PW LDP label 439 mapping message. ( passive role ). The Active T-PE (the ST-PE) and 440 the passive T-PE (the TT-PE) MUST be identified before signaling is 441 initiated for a given MS-PW. The determination of which T-PE assume 442 the active role SHOULD be done as follows: the SAII and TAII are 443 compared as unsigned integers, if the SAII is bigger then the T-PE 444 assumes the active role. 446 The selection selection process to determine which T-PE assumes the 447 active role MAY be superseded by manual provisioning. 449 6.4. Detailed Signaling Procedures 451 On receiving a label mapping message, the S-PE MUST inspect the FEC 452 TLV. 454 If the receiving node has no local AII matching the TAII for that 455 label mapping then the S-PE will check if the FEC is already 456 installed for the forward direction: 458 - If it is already installed, and the received mapping was received 459 from the same LDP peer where the forward LDP label mapping was 460 sent, then this label mapping represents signaling in the reverse 461 direction for this MS-PW segment. 462 - Otherwise this represents signaling in the forward direction. 464 For the forward direction: 465 -i. Determine the next hop S-PE or T-PE according to the 466 procedures above. 467 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 468 If no tunnel exists to the next hop S-PE or T-PE the S-PE 469 MAY attempt to setup a PSN tunnel. 470 -iii. Check that a PSN tunnel exists to the previous hop. If no 471 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 472 attempt to setup a PSN tunnel. 473 -iv. If the S-PE cannot get enough PSN resources to setup the 474 segment to the next or previous S-PE or T-PE, a label 475 withdraw MUST be returned to the T-PE with a status message 476 of "Resources Unavailable". 477 -v. If the label mapping message contains a Bandwidth TLV, 478 allocate the required resources on the PSN tunnels in the 479 forward and reverse directions according to the procedures 480 above. 481 -vi. Install the FEC for the forward direction. 482 -vii. Allocate a new PW label for the forward direction. 483 -viii. Send the label mapping message with the new forward label 484 and the FEC to the next hop S-PE/T-PE. 486 For the reverse direction: 487 -i. Install the FEC for the reverse direction. 488 -ii. Determine the next signaling hop by referencing the LDP 489 sessions used to setup the LSP in the Forward direction. 490 -iii. Install the FEC for the reverse direction. 491 -iv. Allocate a new PW label for the reverse direction. 492 -v. Send the label mapping message with a new label and the FEC 493 to the next hop S-PE/ST-PE. 495 7. Failure Handling Procedures 496 7.1. PSN Failures 498 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 499 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 500 follow the procedures defined in Section 8 of [PW-SEG]. 502 7.2. S-PE Failures 504 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 505 followed. However the ST-PE MAY re-signal the PW if an alternate 506 path is available. 508 8. Support for Explicit PW Path 510 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 511 used to signal an explicit path for a MS-PW. An Explicit PW path may 512 be required to provide a simple solution for 1:1 protection with 513 diverse primary and backup path or to enable controlled signaling 514 (strict or loose) for special PWs. Details of its usage to be 515 provided in a future version. 517 9. Operations and Maintenance (OAM) 519 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 520 PW switching point TLV is used [PW-SEG] to record the switching 521 points that the PW traverses. 523 In the case of a MS-PW where the PW Endpoints are identified though 524 using a globally unique, FEC 129-based AII addresses, there is no 525 PWID defined on a per segment basis. Each individual PW segment is 526 identified by the address of adjacent S-PE(s) in conjunction with the 527 SAII and TAII. 529 In this case, the following type MUST be used in place of type 0x01 530 in the PW switching point TLV: 532 Type Length Description 533 0x04 10 Global ID/Prefix of the S-PE 535 The above field MUST be included together with type 0x02 in the TLV 536 once per individual PW Switching Point following the same rules and 537 procedures as described in [PW-SEG]. 539 10. Use of FEC 128 541 FEC 128 is defined in [PWE3-CTRL] for signaling single segment PWs. 543 Where the first segment or last of a MS-PW uses FEC 128, and 544 intermediate segments use FEC 129, the procedures in Section 6.1.3 of 545 [PW-SEG] must be followed with the extensions described below. The 546 interface parameters of the FEC 128 segment MUST include the global 547 ID, prefix and AC ID for the TT-PE. These are contained in the FEC 548 128 Interface Parameters Sub-TLV and used to signal the first FEC 129 549 MS-PW segment at the S-PE. 551 The interface parameter Sub-TLV type "TT-PE TAII" is defined of value 552 TBD. 554 The format of these interface parameter sub TLVs is as follows: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Sub-TLV Type | Length | Global ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Global ID (contd.) | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Prefix | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | AC ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 The first S-PE along the MS-PW path will then use globally unique AII 569 as the SAII for this MS-PW. The allocation of this AII is achieved as 570 follows: 571 -i. The Gloabal ID is provisioned on the local S-PE. 572 -ii. The Remote FEC 128 LDP peer LDP router Id is used as the 573 Prefix field of the AII. 574 -iii. The Fec 128 PW ID is used as the AC ID field of the AII. 576 11. Security Considerations 578 This document specifies only extensions to the protocols already 579 defined in [PWE3-CTRL], and [PW-SEG]. Each such protocol may have 580 its own set of security issues, but those issues are not affected by 581 the extensions specified herein. Note that the protocols for 582 dynamically distributing PW Layer 2 reachability information may have 583 their own security issues, however those protocols specifications are 584 outside the scope of this document. 586 12. IANA Considerations 588 This document uses several new LDP TLV types, IANA already maintains 589 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 590 following value is suggested for assignment: 592 TLV type Description 593 0x096E Bandwidth TLV 595 12.1. LDP Status Codes 597 This document uses several new LDP status codes, IANA already 598 maintains a registry of name "STATUS CODE NAME SPACE" defined by 599 RFC3036. The following value is suggested for assignment: 601 Assignment E Description 602 TBD 0 "Bandwidth resources unavailable" 603 TBD 0 "Resources Unavailable" 604 TBD 0 "AII Unreachable" 606 12.2. Interface Parameter Sub-TLV type 608 This document uses a new Interface Parameter Sub-TLV type, IANA 609 already maintains a registry of name "Interface Parameter Sub-TLV 610 type" defined by [IANA]. The following value is suggested for 611 assignment: 612 Assignment Description 613 TBD "TT-PE TAII" 615 13. Full Copyright Statement 617 Copyright (C) The Internet Society (2005). 619 This document is subject to the rights, licenses and restrictions 620 contained in BCP 78, and except as set forth therein, the authors 621 retain all their rights. 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 626 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 627 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 628 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 14. Intellectual Property Statement 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at ietf- 653 ipr@ietf.org. 655 15. Normative References 657 [PWE3-IANA] Martini et. Al., "IANA Allocations for pseudo Wire Edge 658 to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-06.txt, 659 September 2004 (work in progress) 661 [PW-SEG] Martini et.al. " Segmented Pseudo Wire", 662 draft-ietf-pwe3-segmented-pw-00.txt, IETF Work in Progress, July 663 2005 665 [RFC3270] Le Faucheur, et. al. "MPLS Support of Differentiated 666 Services", RFC 3270, May 2002 668 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 669 Services", RFC 2210, September 1997 671 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" 672 draft-ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress, 673 November 2004 675 [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", Martini L.,et al 676 draft-ietf-pwe3-control-protocol-17.txt, ( work in progress ), 677 June 2005. 679 [AII] "AII Types for Aggregation", Chris M., et al 680 draft-metz-aii-aggregate-01.txt, October 2006 (work in progress) 682 16. Informative References 684 [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [MS-REQ] Martini et al, "Requirements for Inter-domain Pseudo-Wires", 688 draft-ietf-pwe3-ms-pw-requirements-00, Martini, et al.,June 2005 690 [RFC3985] Bryant, et al., "PWE3 Architecture", RFC3985. 692 [MS-ARCH] Bocci at al, "Architecture for Multi-Segment PWE3", 693 draft-bocci-bryant-pwe3-ms-pw-arch-01.txt, September 2005. 694 ( work in progress ) 696 [L2VPN-SIG] E. Rosen, et Al. "Provisioning, Autodiscovery, 697 and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-06.txt, 698 September 2005 ( work in progress ) 700 [MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 701 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 703 17. Author Information 705 Luca Martini 706 Cisco Systems, Inc. 707 9155 East Nichols Avenue, Suite 400 708 Englewood, CO, 80112 709 e-mail: lmartini@cisco.com 711 Matthew Bocci 712 Alcatel Telecom Ltd, 713 Voyager Place 714 Shoppenhangers Road 715 Maidenhead 716 Berks, UK 717 e-mail: matthew.bocci@alcatel.co.uk 718 Florin Balus 719 Nortel 720 3500 Carling Ave. 721 Ottawa, Ontario, CANADA 722 e-mail: balus@nortel.com 724 Nabil Bitar 725 Verizon 726 40 Sylvan Road 727 Waltham, MA 02145 728 e-mail: nabil.bitar@verizon.com 730 Himanshu Shah 731 Ciena Corp 732 35 Nagog Park, 733 Acton, MA 01720 734 e-mail: hshah@ciena.com 736 Mustapha Aissaoui 737 Alcatel 738 600 March Road 739 Kanata 740 ON, Canada 741 e-mail: mustapha.aissaoui@alcatel.com 743 Jason Rusmisel 744 Alcatel 745 600 March Road 746 Kanata 747 ON, Canada 748 e-mail: Jason.rusmisel@alcatel.com 750 Yetik Serbest 751 SBC Labs 752 9505 Arboretum Blvd. 753 Austin, TX 78759 754 e-mail: Yetik_serbest@labs.sbc.com 755 Andrew G. Malis 756 Tellabs, Inc. 757 2730 Orchard Parkway 758 San Jose, CA, USA 95134 759 e-mail: Andy.Malis@tellabs.com 761 Chris Metz 762 Cisco Systems, Inc. 763 3700 Cisco Way 764 San Jose, Ca. 95134 765 e-mail: chmetz@cisco.com 767 David McDysan 768 MCI 769 22001 Loudoun County Pkwy 770 Ashburn, VA, USA 20147 771 e-mail: dave.mcdysan@mci.com 773 Jeff Sugimoto 774 Nortel 775 3500 Carling Ave. 776 Ottawa, Ontario, CANADA 777 e-mail: sugimoto@nortel.com 779 Mike Duckett 780 Bellsouth 781 Lindbergh Center D481 782 575 Morosgo Dr 783 Atlanta, GA 30324 784 e-mail: mduckett@bellsouth.net 786 Mike Loomis 787 Nortel 788 600, Technology Park Dr 789 Billerica, MA, USA 790 e-mail: mloomis@nortel.com 791 Paul Doolan 792 Mangrove Systems 793 IO Fairfield Blvd 794 Wallingford, CT, USA 06492 795 e-mail: pdoolan@mangrovesystems.com 797 Ping Pan 798 Hammerhead Systems 799 640 Clyde Court 800 Mountain View, CA, USA 94043 801 e-mail: ppan@hammerheadsystems.com 803 Prayson Pate 804 Overture Networks, Inc. 805 507 Airport Blvd, Suite 111 806 Morrisville, NC, USA 27560 807 e-mail: prayson.pate@overturenetworks.com 809 Vasile Radoaca 810 radoaca@hotmail.com 812 Yuichiro Wada 813 NTT Communications 814 3-20-2 Nishi-Shinjuku, Shinjuke-ku 815 Tokyo 163-1421, Japan 816 e-mail: yuichiro.wada@ntt.com 818 Yeongil Seo 819 Korea Telecom Corp. 820 463-1 Jeonmin-dong, Yusung-gu 821 Daejeon, Korea 822 e-mail: syi1@kt.co.kr