idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 678. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 2007) is 6129 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 636, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-04 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-rfc3036bis-03 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-05 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-03 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Working Group Luca Martini (Ed.) 2 Internet Draft Cisco Systems Inc. 3 Expires: January 2008 Matthew Bocci (Ed.) 4 Alcatel-Lucent 5 Florin Balus (Ed.) 6 Alcatel-Lucent 8 July 2007 10 Dynamic Placement of Multi Segment Pseudo Wires 12 draft-ietf-pwe3-dynamic-ms-pw-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 There is a requirement for service providers to be able to extend the 39 reach of pseudo wires (PW) across multiple Packet Switched Network 40 domains. A Multi-Segment PW is defined as a set of two or more 41 contiguous PW segments that behave and function as a single point- 42 to-point PW. This document describes extensions to the PW control 43 protocol to dynamically place the segments of the multi segment 44 pseudo wire among a set of Provider Edge (PE) routers. 46 Table of Contents 48 1 Specification of Requirements ........................ 3 49 2 Major Co-authors ..................................... 3 50 3 Acknowledgements ..................................... 3 51 4 Introduction ......................................... 3 52 4.1 Scope ................................................ 3 53 4.2 Terminology .......................................... 4 54 4.3 Architecture Overview ................................ 4 55 5 Applicability ........................................ 6 56 5.1 Requirements Addressed ............................... 6 57 5.2 Changes to Existing PW Signaling ..................... 6 58 6 PW layer 2 addressing ................................ 6 59 6.1 Attachment Circuit Addressing ........................ 7 60 6.2 S-PE addressing ...................................... 7 61 7 Dynamic placement of MS-PWs .......................... 8 62 7.1 Pseudo wire routing procedures ....................... 8 63 7.1.1 AII PW routing table Lookup aggregation rules ........ 8 64 7.1.2 PW Static Route ...................................... 9 65 7.1.3 Dynamic advertisement with BGP ....................... 9 66 7.2 LDP Signaling ........................................ 10 67 7.2.1 MS-PW Bandwidth Signaling ............................ 10 68 7.2.2 Active/Passive T-PE Election Procedure ............... 12 69 7.2.3 Detailed Signaling Procedures ........................ 12 70 7.2.4 Support for Explicit PW Path ......................... 13 71 8 Failure Handling Procedures .......................... 14 72 8.1 PSN Failures ......................................... 14 73 8.2 S-PE Reachability Failures ........................... 14 74 9 Operations and Maintenance (OAM) ..................... 14 75 10 Security Considerations .............................. 15 76 11 IANA Considerations .................................. 15 77 11.1 LDP Status Codes ..................................... 15 78 11.2 BGP SAFI ............................................. 16 79 12 Full Copyright Statement ............................. 16 80 13 Intellectual Property Statement ...................... 16 81 14 Normative References ................................. 17 82 15 Informative References ............................... 17 83 16 Author Information ................................... 18 85 1. Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 2. Major Co-authors 93 The editors gratefully acknowledge the following additional co- 94 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 95 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 96 Sugimoto. 98 3. Acknowledgements 100 The editors also gratefully acknowledge the input of the following 101 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 102 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 104 4. Introduction 106 4.1. Scope 108 [MS-REQ] describes the service provider requirements for extending 109 the reach of pseudo-wires across multiple PSN domains. This is 110 achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is 111 defined as a set of two or more contiguous PW segments that behave 112 and function as a single point-to-point PW. This architecture is 113 described in [MS-ARCH]. 115 The procedures for establishing PWs that extend across a single PWE3 116 domain are described in [RFC4447], while procedures for setting up 117 PWs across multiple domains, or control planes are described in [PW- 118 SEG]. 120 The purpose of this draft is to specify extensions to the PWE3 121 control protocol [RFC4447], and [PW-SEG] procedures, to enable 122 multi-segment PWs to be automatically placed. The proposed procedures 123 follow the guidelines defined in [RFC3036bis] and enable the reuse of 124 existing TLVs, and procedures defined for SS-PWs in [RFC4447]. 126 4.2. Terminology 128 [MS-ARCH] provides terminology for multi-segment pseudo wires. 130 This document defines the following additional terms: 132 - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which 133 assumes the active signaling role and initiates the signaling for 134 multi-segment PW. 135 - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that 136 assumes the passive signaling role. It waits and responds to the 137 multi-segment PW signaling message in the reverse direction. 138 - Forward Direction: ST-PE to TT-PE. 139 - Reverse Direction: TT-PE to ST-PE 140 - Forwarding Direction: Direction of control plane, signaling flow 141 - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs 142 that compose an MS-PW, as well as the automatic selection of S- 143 PEs. 145 4.3. Architecture Overview 147 The following figure describes the reference models which are derived 148 from [MS-ARCH] to support PW emulated services across multi-segment 149 PWs. 151 Native |<-------------Pseudo Wire----------->| Native 152 Service | | Service 153 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 154 | V V V V V V | 155 | +-----+ +-----+ +-----+ 156 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 157 | |-------|.....PW.Seg't1........PW Seg't3......|----------| | 158 | CE1| | | | | | | | | |CE2 | 159 | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | 160 +----+ | | |=========| |=========| | | +----+ 161 ^ +-----+ +-----+ +-----+ ^ 162 | Provider Edge 1 ^ Provider Edge 2 | 163 | | | 164 | | | 165 | PW switching point | 166 | | 167 |<---------------- Emulated Service -------------------->| 169 Figure 1: PW switching Reference Model 171 Figure 1 shows the architecture for a simple multi-segment case. T- 172 PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in 173 different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, 174 and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs 175 are used to connect the attachment circuits (ACs) attached to T-PE1 176 to the corresponding AC attached to T-PE2. A PW on the tunnel across 177 PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to 178 complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 179 is therefore the PW switching point and will be referred to as the 180 switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are 181 segments of the same MS-PW while PW Segment 2 and PW Segment 4 are 182 segments of another MS-PW. PW segments of the same MS-PW (e.g., PW 183 segment 1 and PW segment 3) MUST be of the same PW type, and PSN 184 tunnels (e.g., PSN1 and PSN2) can be the same or different 185 technology. An S-PE switches an MS-PW from one segment to another 186 based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are 187 switched at the S-PE depends on the PSN tunnel technology: in case of 188 an MPLS PSN to another MPLS PSN PW switching the operation is a 189 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. Interactions 200 with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are 201 left for further study. 203 5.1. Requirements Addressed 205 Specifically the following requirements are addressed [MS-REQ]: 206 - Dynamic End-to-end Signaling 207 - Scalability and Inter-domain Signaling and Routing 208 - Minimal number of provisioning touches (provisioning only at the 209 T-PEs) 210 - Same set of T-PEs/S-PEs for both directions of a MS-PWs 211 - QoS Signaling, Call Admission Control 212 - Resiliency 213 - End-to-end negotiation of OAM Capability 215 5.2. Changes to Existing PW Signaling 217 The procedures described in this document make use of existing LDP 218 TLVs and related PW signaling procedures described in [RFC4447] and 219 [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS 220 Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" 221 section for details). 223 6. PW layer 2 addressing 225 Single segment pseudo wires on an MPLS PSN use Attachment circuit 226 identifiers for a PW using FEC 129. In the case of an automatically 227 placed MS-PW, there is a requirement to have individual global 228 addresses assigned to PW attachment circuits, for reachability , and 229 manageability of the PW. Referencing figure 1 above, individual 230 globally unique addresses MUST be allocated to all the ACs , and S- 231 PEs composing an MS-PW. 233 6.1. Attachment Circuit Addressing 235 The attachment circuit addressing is derived from [AII] AII type 2 236 shown here: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | AII Type=02 | Length | Global ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Global ID (contd.) | Prefix | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Prefix (contd.) | AC ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | AC ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Implementations of the following procedure MUST interpret the AII 251 type to determine the meaning of the address format of the AII, 252 irrespective of the number of segments in the MS-PW. 254 A unique combination Global ID, Prefix, and AC ID parts of the AII 255 type 2 will be assigned to each AC. In general the same global ID and 256 prefix will be assigned for all ACs belonging to the same T-PE, 257 however this is not a strict requirement. A particular T-PE might 258 have more than one prefix assigned to it, and likewise a fully 259 qualified AII with the same Global ID/Prefix but different AC IDs 260 might belong to different T-PEs. 262 For the purpose of MS-PW the AII MUST be globally unique across all 263 interconnected PW domains. 265 6.2. S-PE addressing 267 The T-PE may elect to select a known specific path along a set of S- 268 PEs for a specific PW. This requires that each S-PE be uniquely 269 addressable in terms of pseudo wires. For this purpose at least one 270 AI address of the format similar to AII type 2 [AII] composed of the 271 Global ID, and Prefix part only MUST be assigned to each S-PE. 273 7. Dynamic placement of MS-PWs 275 [PW-SEG] describes a procedure for connecting multiple pseudo wires 276 together. This procedure requires each S-PE to be manually configured 277 with the information required to terminate and initiate the SS-PW 278 part of the MS-PW. The procedures in the following sections describe 279 an method to extend [PW-SEG] by allowing the automatic selection of 280 pre-defined S-PEs, and automatically setting up a MS-PW between two 281 T-PEs. 283 7.1. Pseudo wire routing procedures 285 The AII type 2 described above contains a Global ID, Prefix, and AC 286 ID. The TAII is used by S-PEs to determine the next SS-PW destination 287 for LDP signaling. 289 Once an S-PE receives a MS-PW label mapping message containing a TAII 290 with an AII that is not locally present, the S-PE performs a lookup 291 in a local Layer 2 AII PW routing table. If this lookup results in an 292 IP address of the next PE that advertised reachability information 293 for the AII in question, then the S-PE will initiate the necessary 294 LDP messaging procedure for setting up the next PW segment. If the 295 AII PW routing table lookup does not result in a IP address of the 296 next PE, the destination AII has become unreachable, and the PW MUST 297 fail to setup. In this case the next PW segment is considered 298 unprovisioned, and a label release MUST be returned to the T-PE with 299 a status message of "AII Unreachable". 301 If the TAI of a MS-PW label mapping message, received by a PE, 302 contains the prefix of a locally provisioned prefix on that PE, but 303 an AC ID that is not provisioned, then the LDP liberal label 304 retention procedures apply, and the label mapping message is 305 retained. 307 To allow for dynamic end-to-end signaling of MS-PWs, information must 308 be present in S-PEs to support the determination of the next PW 309 signaling hop. Such information can be provisioned (static route 310 equivalent) on each S-PE system or disseminated via regular routing 311 protocols (e.g. BGP). 313 7.1.1. AII PW routing table Lookup aggregation rules 315 All PEs capable of dynamic multi segment pseudowire path selection, 316 must build a PW routing table to be used for PW next hop selection. 318 The PW addressing scheme (AII type 2 in [AII]) consists of a Global 319 Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. 321 An aggregation scheme similar with the one used for classless IPv4 322 addresses can be employed. An (8 bits) length mask is specified as a 323 number ranging from 0 to 96 that indicates which Least Significant 324 Bits (LSB) are ignored in the address field when performing the PW 325 address matching algorithm. 327 0 31 32 63 64 95 (bits) 328 +-----------+--------+--------+ 329 | Global ID | Prefix | AC ID | 330 +-----------+--------+--------+ 332 During the signaling phase, the content of the (fully qualified) TAII 333 type 2 field from the FEC129 TLV is compared against routes from the 334 PW Routing table. Similar with the IPv4 case, the route with the 335 longest match is selected, determining the next signaling hop and 336 implicitly the next PW Segment to be signaled. 338 7.1.2. PW Static Route 340 For the purpose of determining the next signaling hop for a segment 341 of the pseudo wire, the PEs MAY be provisioned with fixed route 342 entries in the PW next hop routing table. The static PW entries will 343 follow all the addressing rules and aggregation rules described in 344 the previous sections. The most common use of PW static provisioned 345 routes is this example of the "default" route entry as follows: 347 Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling 348 Hop = S-PE1 350 7.1.3. Dynamic advertisement with BGP 352 Any suitable routing protocol capable of carrying external routing 353 information may be used to propagate MS-PW path information among S- 354 PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use Boundary 355 Gateway Protocol (BGP) [RFC2858] to propagate PW address information 356 throughout the PSN. 358 In the case of the MS-PW if the Source T-PE knows a priori the 359 address of the Terminating T-PE, there is no need to advertise a 360 "fully qualified" address on a per PW Attachment Circuit. Only the 361 T-PE Global ID, Prefix, and prefix length needs to be advertised as 362 part of well known BGP procedures - see [RFC2858]. 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 to where the first PW segment will be established. Any subsequent S- 367 PEs 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=6 373 (pending IANA allocation)). 375 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 376 an IPv4 address, whenever the length of the NextHop address is 4 377 octets, and as a IPv6 address, whenever the length of the NextHop 378 address is 16 octets. 380 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 381 of 0 to 96 bits encoded as defined in section 4 of [RFC2858]. 383 This prefix is structured as follows: 385 0 31 32 63 64 95 (bits) 386 +-----------+--------+--------+ 387 | Global ID | Prefix | AC ID | 388 +-----------+--------+--------+ 390 Except for the default PW route, which is encoded as a 0 length 391 prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to 392 95 are invalid as the AC ID field cannot be aggregated. 394 7.2. LDP Signaling 396 The LDP signaling procedures are described in [RFC4447] and expanded 397 in [PW-SEG]. No new LDP Signaling components are required for setting 398 up a dynamically placed MS-PW. However some optional signaling 399 extensions are described below. 401 7.2.1. MS-PW Bandwidth Signaling 403 In the SS-PW case the PW QoS requirements may easily be met by 404 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 405 requirements. However in the case of an automatically placed MS-PW 406 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 407 be indicated along with the MS-PW addressing. This is accomplished by 408 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 409 specified as follows: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |1|0| PW BW TLV (0x096E) | TLV Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Forward SENDER_TSPEC | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Reverse SENDER_TSPEC | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The complete definitions of the content of the SENDER_TSPEC objects 422 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 423 the data path in the direction of ST-PE to TT-PE. The reverse 424 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 426 In the forward direction, after a next hop selection is determined, a 427 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 428 an appropriate PSN tunnel towards the next signaling hop. If such a 429 tunnel exists, the MS-PW signaling procedures are invoked with the 430 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 431 tunnel, any tunnel which points to a next hop equivalent to the next 432 hop selected will be included in the search.(The LDP address TLV is 433 used to determine the next hop equivalence) 435 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 436 selected, the S/T-PE MUST request the appropriate resources from the 437 PSN. The resources described in the reverse SENDER_TSPEC are 438 allocated from the PSN toward the originator of the message or 439 previous hop. When resources are allocated from the PSN for a 440 specific PW, then the PSN SHOULD account for the PW usage of the 441 resources. 443 In the case where PSN resources towards the previous hop are not 444 available the following procedure MUST be followed: 445 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 446 the PSN tunnel. 447 -ii. The S-PE MAY attempt to setup another PSN tunnel to 448 accommodate the new PW QoS requirements. 449 -iii. If the S-PE cannot get enough resources to setup the segment 450 in the MS-PW a label release MUST be returned to the 451 previous hop with a status message of "Bandwidth resources 452 unavailable" 454 In the latter case, the T-PE receiving the status message MUST also 455 withdraw the corresponding PW label mapping for the opposite 456 direction if it has already been successfully setup. 458 If an ST-PE receives a label mapping message the following procedure 459 MUST be followed: 461 If the ST-PE has already sent a label mapping message for this PW 462 then the ST-PE must check that this label mapping message originated 463 from the same LDP peer to which the corresponding label mapping 464 message for this particular PW was sent. If it is the same peer, the 465 the PW is established. If it is a different peer, then ST-PE MUST 466 send a label release message, with a status code of "Duplicate AII" 467 to the PE that originate the LDP label mapping message. 469 If the PE has not yet sent a label mapping message for this 470 particular PW , then it MUST send the label mapping message to this 471 same LDP peer, regardless of what the PW TAII routing lookup result 472 is. 474 7.2.2. Active/Passive T-PE Election Procedure 476 When a MS-PW is signaled, Each T-PE might independently start 477 signaling the MS-PW, this could result in a different path selected 478 for each T-PE PW. To avoid this situation one of the T-PE MUST start 479 the PW signaling (active role), while the other waits to receive the 480 LDP label mapping before sending the respective PW LDP label mapping 481 message. (passive role). The Active T-PE (the ST-PE) and the passive 482 T-PE (the TT-PE) MUST be identified before signaling is initiated for 483 a given MS-PW. 485 The determination of which T-PE assume the active role SHOULD be done 486 as follows: the SAII and TAII are compared as unsigned integers, if 487 the SAII is bigger then the T-PE assumes the active role. 489 The selection process to determine which T-PE assumes the active role 490 MAY be superseded by manual provisioning. 492 7.2.3. Detailed Signaling Procedures 494 On receiving a label mapping message, the S-PE MUST inspect the FEC 495 TLV. If the receiving node has no local AII matching the TAII for 496 that label mapping then the S-PE will check if the FEC is already 497 installed for the forward direction: 498 - If it is already installed, and the received mapping was received 499 from the same LDP peer where the forward LDP label mapping was 500 sent, then this label mapping represents signaling in the reverse 501 direction for this MS-PW segment. 503 - Otherwise this represents signaling in the forward direction. 505 For the forward direction: 506 -i. Determine the next hop S-PE or T-PE according to the 507 procedures above. 508 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 509 If no tunnel exists to the next hop S-PE or T-PE the S-PE 510 MAY attempt to setup a PSN tunnel. 511 -iii. Check that a PSN tunnel exists to the previous hop. If no 512 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 513 attempt to setup a PSN tunnel. 514 -iv. If the S-PE cannot get enough PSN resources to setup the 515 segment to the next or previous S-PE or T-PE, a label 516 release MUST be returned to the T-PE with a status message 517 of "Resources Unavailable". 518 -v. If the label mapping message contains a Bandwidth TLV, 519 allocate the required resources on the PSN tunnels in the 520 forward and reverse directions according to the procedures 521 above. 522 -vi. Allocate a new PW label for the forward direction. 523 -vii. Install the FEC for the forward direction. 524 -viii. Send the label mapping message with the new forward label 525 and the FEC to the next hop S-PE/T-PE. 527 For the reverse direction: 528 -i. Install the received FEC for the reverse direction. 529 -ii. Determine the next signaling hop by referencing the LDP 530 sessions used to setup the LSP in the Forward direction. 531 -iii. Allocate a new PW label for the reverse direction. 532 -iv. Install the FEC for the reverse direction. 533 -v. Send the label mapping message with a new label and the FEC 534 to the next hop S-PE/ST-PE. 536 7.2.4. Support for Explicit PW Path 538 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 539 used to signal an explicit path for a MS-PW. An Explicit PW path may 540 be required to provide a simple solution for 1:1 protection with 541 diverse primary and backup path or to enable controlled signaling 542 (strict or loose) for special PWs. Details of its usage to be 543 provided in a future study. 545 8. Failure Handling Procedures 547 8.1. PSN Failures 549 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 550 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 551 follow the procedures defined in Section 8 of [PW-SEG]. 553 8.2. S-PE Reachability Failures 555 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 556 followed. However in general an established MS-PW will not be 557 affected by changes in L2 PW reachability information. 559 T-PEs that receive a label release message with a status of "AII 560 Unreachable" MUST re-attempt to establish the PW immediately. However 561 the T-PE MUST throttle its PW setup message retry attempts with an 562 exponential backoff in situations where PW setup messages are being 563 constantly released. It is also recommended that a T-PE detecting 564 such a situation take action to notify an operator. 566 If there is a change in the L2 PW reachability information in the 567 forward direction only, the T-PE MAY elect to tear down the MS-PW by 568 sending a label withdraw message and re-establish the MS-PW. In the 569 same case, an S-PE MAY do the same by sending a label withdraw 570 message in the forward direction, and a label release message in the 571 opposite direction along the MS-PW. 573 A change in L2 reachability information in the reverse direction has 574 no effect on an MS-PW. 576 9. Operations and Maintenance (OAM) 578 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 579 PW switching point TLV is used [PW-SEG] to record the switching 580 points that the PW traverses. 582 In the case of a MS-PW where the PW Endpoints are identified though 583 using a globally unique, FEC 129-based AII addresses, there is no 584 PWID defined on a per segment basis. Each individual PW segment is 585 identified by the address of adjacent S-PE(s) in conjunction with the 586 SAI and TAI. In this case, the following type MUST be used in place 587 of type 0x01 in the PW switching point TLV: 589 Type Length Description 590 0x06 8 L2 PW address of PW Switching Point 592 The above field MUST be included together with type 0x02 in the TLV 593 once per individual PW Switching Point following the same rules and 594 procedures as described in [PW-SEG]. 596 10. Security Considerations 598 This document specifies only extensions to the protocols already 599 defined in [RFC4447], and [PW-SEG]. Each such protocol may have its 600 own set of security issues, but those issues are not affected by the 601 extensions specified herein. Note that the protocols for dynamically 602 distributing PW Layer 2 reachability information may have their own 603 security issues, however those protocols specifications are outside 604 the scope of this document. 606 11. IANA Considerations 608 This document uses several new LDP TLV types, IANA already maintains 609 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 610 following value is suggested for assignment: 612 TLV type Description 613 0x096E Bandwidth TLV 615 11.1. LDP Status Codes 617 This document uses several new LDP status codes, IANA already 618 maintains a registry of name "STATUS CODE NAME SPACE" defined by 619 RFC3036. The following value are suggested for assignment: 621 Range/Value E Description Reference 622 ------------- ----- ---------------------- --------- 623 0x00000037 0 Bandwidth resources unavailable RFCxxxx 624 0x00000038 0 Resources Unavailable RFCxxxx 625 0x00000039 0 AII Unreachable RFCxxxx 626 0x0000003A 0 PW Loop Detected RFCxxxx 628 11.2. BGP SAFI 630 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 631 Information used for Dynamic Placement of Multi-Segment Pseudiwires" 632 from the L2VPN SAFI registry. The following aloocation is suggested: 634 Value Description Reference 635 ----- ----------- --------- 636 6 Network Layer Reachability Information used [RFCxxxx] 637 for Dynamic Placement of Multi-Segment 638 Pseudowires 640 12. Full Copyright Statement 642 Copyright (C) The IETF Trust (2007). 644 This document is subject to the rights, licenses and restrictions 645 contained in BCP 78, and except as set forth therein, the authors 646 retain all their rights. 648 This document and the information contained herein are provided on an 649 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 650 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 651 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 652 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 653 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 654 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 656 13. Intellectual Property Statement 658 The IETF takes no position regarding the validity or scope of any 659 Intellectual Property Rights or other rights that might be claimed to 660 pertain to the implementation or use of the technology described in 661 this document or the extent to which any license under such rights 662 might or might not be available; nor does it represent that it has 663 made any independent effort to identify any such rights. Information 664 on the procedures with respect to rights in RFC documents can be 665 found in BCP 78 and BCP 79. 667 Copies of IPR disclosures made to the IETF Secretariat and any 668 assurances of licenses to be made available, or the result of an 669 attempt made to obtain a general license or permission for the use of 670 such proprietary rights by implementers or users of this 671 specification can be obtained from the IETF on-line IPR repository at 672 http://www.ietf.org/ipr. 674 The IETF invites any interested party to bring to its attention any 675 copyrights, patents or patent applications, or other proprietary 676 rights that may cover technology that may be required to implement 677 this standard. Please address the information to the IETF at ietf- 678 ipr@ietf.org. 680 14. Normative References 682 [PW-SEG] Martini et.al. "Segmented Pseudo Wire", 683 draft-ietf-pwe3-segmented-pw-04.txt, IETF Work in Progress, 684 February 2007 686 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 687 Services", RFC 2210, September 1997 689 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" 690 draft-ietf-mpls-rfc3036bis-03.txt, IETF Work in Progress, 691 October 2005 693 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 694 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 695 June 2005. 697 [AII] "Pseudowire Attachment Identifiers for Aggregation and VPN 698 Autodiscovery", Metz, et al, 699 draft-ietf-pwe3-aii-aggregate-02.txt, February 2007 701 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", 702 RFC3212, January 2002. 704 15. Informative References 706 [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire 707 Emulation Edge-to-Edge (PWE3)", 708 draft-ietf-pwe3-ms-pw-requirements-05.txt, Martini, et al., 709 March 2007 711 [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 712 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-03.txt, 713 June 2007, IETF work in progress 715 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 716 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 718 16. Author Information 720 Luca Martini 721 Cisco Systems, Inc. 722 9155 East Nichols Avenue, Suite 400 723 Englewood, CO, 80112 724 e-mail: lmartini@cisco.com 726 Matthew Bocci 727 Alcatel-Lucent, 728 Voyager Place 729 Shoppenhangers Road 730 Maidenhead 731 Berks, UK 732 e-mail: matthew.bocci@alcatel-lucent.co.uk 734 Florin Balus 735 Alcatel-Lucent 736 701 E. Middlefield Rd. 737 Mountain View, CA 94043 738 e-mail: florin.balus@alcatel-lucent.com 740 Nabil Bitar 741 Verizon 742 40 Sylvan Road 743 Waltham, MA 02145 744 e-mail: nabil.bitar@verizon.com 746 Himanshu Shah 747 Ciena Corp 748 35 Nagog Park, 749 Acton, MA 01720 750 e-mail: hshah@ciena.com 752 Mustapha Aissaoui 753 Alcatel-Lucent 754 600 March Road 755 Kanata 756 ON, Canada 757 e-mail: mustapha.aissaoui@alcatel-lucent.com 758 Jason Rusmisel 759 Alcatel-Lucent 760 600 March Road 761 Kanata 762 ON, Canada 763 e-mail: Jason.rusmisel@alcatel-lucent.com 765 Yetik Serbest 766 SBC Labs 767 9505 Arboretum Blvd. 768 Austin, TX 78759 769 e-mail: Yetik_serbest@labs.sbc.com 771 Andrew G. Malis 772 Verizon 773 2730 Orchard Parkway 774 San Jose, CA, USA 95134 775 e-mail: Andy.Malis@tellabs.com 777 Chris Metz 778 Cisco Systems, Inc. 779 3700 Cisco Way 780 San Jose, Ca. 95134 781 e-mail: chmetz@cisco.com 783 David McDysan 784 Verizon 785 22001 Loudoun County Pkwy 786 Ashburn, VA, USA 20147 787 e-mail: dave.mcdysan@verizon.com 789 Jeff Sugimoto 790 Nortel 791 3500 Carling Ave. 792 Ottawa, Ontario, CANADA 793 e-mail: sugimoto@nortel.com 794 Mike Duckett 795 Bellsouth 796 Lindbergh Center D481 797 575 Morosgo Dr 798 Atlanta, GA 30324 799 e-mail: mduckett@bellsouth.net 801 Mike Loomis 802 Nortel 803 600, Technology Park Dr 804 Billerica, MA, USA 805 e-mail: mloomis@nortel.com 807 Paul Doolan 808 Mangrove Systems 809 IO Fairfield Blvd 810 Wallingford, CT, USA 06492 811 e-mail: pdoolan@mangrovesystems.com 813 Ping Pan 814 Hammerhead Systems 815 640 Clyde Court 816 Mountain View, CA, USA 94043 817 e-mail: ppan@hammerheadsystems.com 819 Prayson Pate 820 Overture Networks, Inc. 821 507 Airport Blvd, Suite 111 822 Morrisville, NC, USA 27560 823 e-mail: prayson.pate@overturenetworks.com 825 Vasile Radoaca 826 Alcatel-Lucent 827 Optics Divison, Westford, MA, USA 828 email: vasile.radoaca@alcatel-lucent.com 830 Yuichiro Wada 831 NTT Communications 832 3-20-2 Nishi-Shinjuku, Shinjuke-ku 833 Tokyo 163-1421, Japan 834 e-mail: yuichiro.wada@ntt.com 835 Yeongil Seo 836 Korea Telecom Corp. 837 463-1 Jeonmin-dong, Yusung-gu 838 Daejeon, Korea 839 e-mail: syi1@kt.co.kr