idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-06.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, updated by RFC 4748 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 (November 2007) is 5999 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 640, 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. -------------------------------------------------------------------------------- 2 PWE3 Working Group Luca Martini (Ed.) 3 Internet Draft Cisco Systems Inc. 4 Expires: May 2008 Matthew Bocci (Ed.) 5 Alcatel-Lucent 6 Florin Balus (Ed.) 7 Alcatel-Lucent 9 November 2007 11 Dynamic Placement of Multi Segment Pseudo Wires 13 draft-ietf-pwe3-dynamic-ms-pw-06.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 .......................... 14 73 8.1 PSN Failures ......................................... 14 74 8.2 S-PE Reachability Failures ........................... 14 75 9 Operations and Maintenance (OAM) ..................... 14 76 10 Security Considerations .............................. 15 77 11 IANA Considerations .................................. 15 78 11.1 LDP Status Codes ..................................... 15 79 11.2 BGP SAFI ............................................. 16 80 12 Full Copyright Statement ............................. 16 81 13 Intellectual Property Statement ...................... 16 82 14 Normative References ................................. 17 83 15 Informative References ............................... 17 84 16 Author Information ................................... 18 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 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 MS-PW. PW segments of the same MS-PW (e.g., PW 184 segment 1 and PW segment 3) MUST be of the same PW type, and PSN 185 tunnels (e.g., PSN1 and PSN2) can be the same or different 186 technology. An S-PE switches an MS-PW from one segment to another 187 based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are 188 switched at the S-PE depends on the PSN tunnel technology: in case of 189 an MPLS PSN to another MPLS PSN PW switching the operation is a 190 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. Interactions 201 with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are 202 left for further study. 204 5.1. Requirements Addressed 206 Specifically the following requirements are addressed [MS-REQ]: 207 - Dynamic End-to-end Signaling 208 - Scalability and Inter-domain Signaling and Routing 209 - Minimal number of provisioning touches (provisioning only at the 210 T-PEs) 211 - Same set of T-PEs/S-PEs for both directions of a MS-PWs 212 - QoS Signaling, Call Admission Control 213 - Resiliency 214 - End-to-end negotiation of OAM Capability 216 5.2. Changes to Existing PW Signaling 218 The procedures described in this document make use of existing LDP 219 TLVs and related PW signaling procedures described in [RFC4447] and 220 [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS 221 Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" 222 section for details). 224 6. PW layer 2 addressing 226 Single segment pseudo wires on an MPLS PSN use Attachment circuit 227 identifiers for a PW using FEC 129. In the case of an automatically 228 placed MS-PW, there is a requirement to have individual global 229 addresses assigned to PW attachment circuits, for reachability , and 230 manageability of the PW. Referencing figure 1 above, individual 231 globally unique addresses MUST be allocated to all the ACs , and S- 232 PEs composing an MS-PW. 234 6.1. Attachment Circuit Addressing 236 The attachment circuit addressing is derived from [AII] AII type 2 237 shown here: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | AII Type=02 | Length | Global ID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Global ID (contd.) | Prefix | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Prefix (contd.) | AC ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | AC ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Implementations of the following procedure MUST interpret the AII 252 type to determine the meaning of the address format of the AII, 253 irrespective of the number of segments in the MS-PW. 255 A unique combination Global ID, Prefix, and AC ID parts of the AII 256 type 2 will be assigned to each AC. In general the same global ID and 257 prefix will be assigned for all ACs belonging to the same T-PE, 258 however this is not a strict requirement. A particular T-PE might 259 have more than one prefix assigned to it, and likewise a fully 260 qualified AII with the same Global ID/Prefix but different AC IDs 261 might belong to different T-PEs. 263 For the purpose of MS-PW the AII MUST be globally unique across all 264 interconnected PW domains. 266 6.2. S-PE addressing 268 The T-PE may elect to select a known specific path along a set of S- 269 PEs for a specific PW. This requires that each S-PE be uniquely 270 addressable in terms of pseudo wires. For this purpose at least one 271 AI address of the format similar to AII type 2 [AII] composed of the 272 Global ID, and Prefix part only MUST be assigned to each S-PE. 274 7. Dynamic placement of MS-PWs 276 [PW-SEG] describes a procedure for connecting multiple pseudo wires 277 together. This procedure requires each S-PE to be manually configured 278 with the information required to terminate and initiate the SS-PW 279 part of the MS-PW. The procedures in the following sections describe 280 an method to extend [PW-SEG] by allowing the automatic selection of 281 pre-defined S-PEs, and automatically setting up a MS-PW between two 282 T-PEs. 284 7.1. Pseudo wire routing procedures 286 The AII type 2 described above contains a Global ID, Prefix, and AC 287 ID. The TAII is used by S-PEs to determine the next SS-PW destination 288 for LDP signaling. 290 Once an S-PE receives a MS-PW label mapping message containing a TAII 291 with an AII that is not locally present, the S-PE performs a lookup 292 in a local Layer 2 AII PW routing table. If this lookup results in an 293 IP address of the next PE that advertised reachability information 294 for the AII in question, then the S-PE will initiate the necessary 295 LDP messaging procedure for setting up the next PW segment. If the 296 AII PW routing table lookup does not result in a IP address of the 297 next PE, the destination AII has become unreachable, and the PW MUST 298 fail to setup. In this case the next PW segment is considered 299 unprovisioned, and a label release MUST be returned to the T-PE with 300 a status message of "AII Unreachable". 302 If the TAI of a MS-PW label mapping message, received by a PE, 303 contains the prefix of a locally provisioned prefix on that PE, but 304 an AC ID that is not provisioned, then the LDP liberal label 305 retention procedures apply, and the label mapping message is 306 retained. 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 carrying external routing 354 information may be used to propagate MS-PW path information among S- 355 PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use Boundary 356 Gateway Protocol (BGP) [RFC2858] to propagate PW address information 357 throughout the PSN. 359 Contrary to other l2vpn signaling methods that use BGP [L2- 360 SIGNALING], in the case of the dynamically placed MS-PW if the source 361 T-PE knows a priori (by provisioning) the address of the terminating 362 T-PE. Hence there is no need to advertise a "fully qualified" 96 bit 363 address on a per PW Attachment Circuit basis. Only the T-PE Global 364 ID, Prefix, and prefix length needs to be advertised as part of well 365 known BGP procedures - see [RFC2858]. 367 As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this 368 information to obtain the first S-PE hop (i.e., first BGP next hop) 369 to where the first PW segment will be established. Any subsequent S- 370 PEs will use the same information (i.e. the next BGP next-hop(s)) to 371 obtain the next-signaling-hop(s) on the path to the TT-PE. 373 The PW dynamic path NLRI is advertised in BGP UPDATE messages using 374 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The [AFI, 375 SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6 376 (pending IANA allocation)). 378 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 379 an IPv4 address, whenever the length of the NextHop address is 4 380 octets, and as a IPv6 address, whenever the length of the NextHop 381 address is 16 octets. 383 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 384 of 0 to 96 bits encoded as defined in section 4 of [RFC2858]. 386 This prefix is structured as follows: 388 0 31 32 63 64 95 (bits) 389 +-----------+--------+--------+ 390 | Global ID | Prefix | AC ID | 391 +-----------+--------+--------+ 393 Except for the default PW route, which is encoded as a 0 length 394 prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to 395 95 are invalid as the AC ID field cannot be aggregated. 397 7.2. LDP Signaling 399 The LDP signaling procedures are described in [RFC4447] and expanded 400 in [PW-SEG]. No new LDP Signaling components are required for setting 401 up a dynamically placed MS-PW. However some optional signaling 402 extensions are described below. 404 7.2.1. MS-PW Bandwidth Signaling 406 In the SS-PW case the PW QoS requirements may easily be met by 407 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 408 requirements. However in the case of an automatically placed MS-PW 409 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 410 be indicated along with the MS-PW addressing. This is accomplished by 411 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 412 specified as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |1|0| PW BW TLV (0x096E) | TLV Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Forward SENDER_TSPEC | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Reverse SENDER_TSPEC | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 The complete definitions of the content of the SENDER_TSPEC objects 425 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 426 the data path in the direction of ST-PE to TT-PE. The reverse 427 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 429 In the forward direction, after a next hop selection is determined, a 430 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 431 an appropriate PSN tunnel towards the next signaling hop. If such a 432 tunnel exists, the MS-PW signaling procedures are invoked with the 433 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 434 tunnel, any tunnel which points to a next hop equivalent to the next 435 hop selected will be included in the search.(The LDP address TLV is 436 used to determine the next hop equivalence) 438 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 439 selected, the S/T-PE MUST request the appropriate resources from the 440 PSN. The resources described in the reverse SENDER_TSPEC are 441 allocated from the PSN toward the originator of the message or 442 previous hop. When resources are allocated from the PSN for a 443 specific PW, then the PSN SHOULD account for the PW usage of the 444 resources. 446 In the case where PSN resources towards the previous hop are not 447 available the following procedure MUST be followed: 448 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 449 the PSN tunnel. 450 -ii. The S-PE MAY attempt to setup another PSN tunnel to 451 accommodate the new PW QoS requirements. 452 -iii. If the S-PE cannot get enough resources to setup the segment 453 in the MS-PW a label release MUST be returned to the 454 previous hop with a status message of "Bandwidth resources 455 unavailable" 457 In the latter case, the T-PE receiving the status message MUST also 458 withdraw the corresponding PW label mapping for the opposite 459 direction if it has already been successfully setup. 461 If an ST-PE receives a label mapping message the following procedure 462 MUST be followed: 464 If the ST-PE has already sent a label mapping message for this PW 465 then the ST-PE must check that this label mapping message originated 466 from the same LDP peer to which the corresponding label mapping 467 message for this particular PW was sent. If it is the same peer, the 468 the PW is established. If it is a different peer, then ST-PE MUST 469 send a label release message, with a status code of "Duplicate AII" 470 to the PE that originate the LDP label mapping message. 472 If the PE has not yet sent a label mapping message for this 473 particular PW , then it MUST send the label mapping message to this 474 same LDP peer, regardless of what the PW TAII routing lookup result 475 is. 477 7.2.2. Active/Passive T-PE Election Procedure 479 When a MS-PW is signaled, Each T-PE might independently start 480 signaling the MS-PW, this could result in a different path selected 481 for each T-PE PW. To avoid this situation one of the T-PE MUST start 482 the PW signaling (active role), while the other waits to receive the 483 LDP label mapping before sending the respective PW LDP label mapping 484 message. (passive role). The Active T-PE (the ST-PE) and the passive 485 T-PE (the TT-PE) MUST be identified before signaling is initiated for 486 a given MS-PW. 488 The determination of which T-PE assume the active role SHOULD be done 489 as follows: the SAII and TAII are compared as unsigned integers, if 490 the SAII is bigger then the T-PE assumes the active role. 492 The selection process to determine which T-PE assumes the active role 493 MAY be superseded by manual provisioning. 495 7.2.3. Detailed Signaling Procedures 497 On receiving a label mapping message, the S-PE MUST inspect the FEC 498 TLV. If the receiving node has no local AII matching the TAII for 499 that label mapping then the S-PE will check if the FEC is already 500 installed for the forward direction: 502 - If it is already installed, and the received mapping was received 503 from the same LDP peer where the forward LDP label mapping was 504 sent, then this label mapping represents signaling in the reverse 505 direction for this MS-PW segment. 506 - Otherwise this represents signaling in the forward direction. 508 For the forward direction: 509 -i. Determine the next hop S-PE or T-PE according to the 510 procedures above. 511 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 512 If no tunnel exists to the next hop S-PE or T-PE the S-PE 513 MAY attempt to setup a PSN tunnel. 514 -iii. Check that a PSN tunnel exists to the previous hop. If no 515 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 516 attempt to setup a PSN tunnel. 517 -iv. If the S-PE cannot get enough PSN resources to setup the 518 segment to the next or previous S-PE or T-PE, a label 519 release MUST be returned to the T-PE with a status message 520 of "Resources Unavailable". 521 -v. If the label mapping message contains a Bandwidth TLV, 522 allocate the required resources on the PSN tunnels in the 523 forward and reverse directions according to the procedures 524 above. 525 -vi. Allocate a new PW label for the forward direction. 526 -vii. Install the FEC for the forward direction. 527 -viii. Send the label mapping message with the new forward label 528 and the FEC to the next hop S-PE/T-PE. 530 For the reverse direction: 531 -i. Install the received FEC for the reverse direction. 532 -ii. Determine the next signaling hop by referencing the LDP 533 sessions used to setup the LSP in the Forward direction. 534 -iii. Allocate a new PW label for the reverse direction. 535 -iv. Install the FEC for the reverse direction. 536 -v. Send the label mapping message with a new label and the FEC 537 to the next hop S-PE/ST-PE. 539 7.2.4. Support for Explicit PW Path 541 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 542 used to signal an explicit path for a MS-PW. An Explicit PW path may 543 be required to provide a simple solution for 1:1 protection with 544 diverse primary and backup path or to enable controlled signaling 545 (strict or loose) for special PWs. Details of its usage to be 546 provided in a future study. 548 8. Failure Handling Procedures 550 8.1. PSN Failures 552 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 553 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 554 follow the procedures defined in Section 8 of [PW-SEG]. 556 8.2. S-PE Reachability Failures 558 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 559 followed. However in general an established MS-PW will not be 560 affected by changes in L2 PW reachability information. 562 T-PEs that receive a label release message with a status of "AII 563 Unreachable" MUST re-attempt to establish the PW immediately. However 564 the T-PE MUST throttle its PW setup message retry attempts with an 565 exponential backoff in situations where PW setup messages are being 566 constantly released. It is also recommended that a T-PE detecting 567 such a situation take action to notify an operator. 569 If there is a change in the L2 PW reachability information in the 570 forward direction only, the T-PE MAY elect to tear down the MS-PW by 571 sending a label withdraw message and re-establish the MS-PW. In the 572 same case, an S-PE MAY do the same by sending a label withdraw 573 message in the forward direction, and a label release message in the 574 opposite direction along the MS-PW. 576 A change in L2 reachability information in the reverse direction has 577 no effect on an MS-PW. 579 9. Operations and Maintenance (OAM) 581 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 582 PW switching point TLV is used [PW-SEG] to record the switching 583 points that the PW traverses. 585 In the case of a MS-PW where the PW Endpoints are identified though 586 using a globally unique, FEC 129-based AII addresses, there is no 587 PWID defined on a per segment basis. Each individual PW segment is 588 identified by the address of adjacent S-PE(s) in conjunction with the 589 SAI and TAI. In this case, the following type MUST be used in place 590 of type 0x01 in the PW switching point TLV: 592 Type Length Description 593 0x06 8 L2 PW address of PW Switching Point 595 The above field MUST be included together with type 0x02 in the TLV 596 once per individual PW Switching Point following the same rules and 597 procedures as described in [PW-SEG]. 599 10. Security Considerations 601 This document specifies only extensions to the protocols already 602 defined in [RFC4447], and [PW-SEG]. Each such protocol may have its 603 own set of security issues, but those issues are not affected by the 604 extensions specified herein. Note that the protocols for dynamically 605 distributing PW Layer 2 reachability information may have their own 606 security issues, however those protocols specifications are outside 607 the scope of this document. 609 11. IANA Considerations 611 This document uses several new LDP TLV types, IANA already maintains 612 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 613 following value is suggested for assignment: 615 TLV type Description 616 0x096E Bandwidth TLV 618 11.1. LDP Status Codes 620 This document uses several new LDP status codes, IANA already 621 maintains a registry of name "STATUS CODE NAME SPACE" defined by 622 RFC3036. The following values have been pre-allocated: 624 Range/Value E Description Reference 625 ------------- ----- ---------------------- --------- 626 0x00000037 0 Bandwidth resources unavailable RFCxxxx 627 0x00000038 0 Resources Unavailable RFCxxxx 628 0x00000039 0 AII Unreachable RFCxxxx 629 0x0000003A 0 PW Loop Detected RFCxxxx 631 11.2. BGP SAFI 633 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 634 Information used for Dynamic Placement of Multi-Segment Pseudiwires" 635 from the IANA "Subsequence Address Family Identifiers (SAFI)" 636 registry. The following value has been pre-allocated: 638 Value Description Reference 639 ----- ----------- --------- 640 6 Network Layer Reachability Information used [RFCxxxx] 641 for Dynamic Placement of Multi-Segment 642 Pseudowires 644 12. Full Copyright Statement 646 Copyright (C) The IETF Trust (2007). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 13. Intellectual Property Statement 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at ietf- 682 ipr@ietf.org. 684 14. Normative References 686 [PW-SEG] Martini et.al. "Segmented Pseudo Wire", 687 draft-ietf-pwe3-segmented-pw-04.txt, IETF Work in Progress, 688 February 2007 690 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 691 Services", RFC 2210, September 1997 693 [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" 694 draft-ietf-mpls-rfc3036bis-03.txt, IETF Work in Progress, 695 October 2005 697 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 698 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 699 June 2005. 701 [AII] "Pseudowire Attachment Identifiers for Aggregation and VPN 702 Autodiscovery", Metz, et al, 703 draft-ietf-pwe3-aii-aggregate-02.txt, February 2007 705 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", 706 RFC3212, January 2002. 708 15. Informative References 710 [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire 711 Emulation Edge-to-Edge (PWE3)", 712 draft-ietf-pwe3-ms-pw-requirements-05.txt, Martini, et al., 713 March 2007 715 [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 716 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-03.txt, 717 June 2007, IETF work in progress 719 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 720 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 722 [L2-SIGNALING] E. Rosen, W. Luo, B. Davie, V. Radoaca, 723 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 724 draft-ietf-l2vpn-signaling-08.txt May 3, 2006.(work in progress) 726 16. Author Information 728 Luca Martini 729 Cisco Systems, Inc. 730 9155 East Nichols Avenue, Suite 400 731 Englewood, CO, 80112 732 e-mail: lmartini@cisco.com 734 Matthew Bocci 735 Alcatel-Lucent, 736 Voyager Place 737 Shoppenhangers Road 738 Maidenhead 739 Berks, UK 740 e-mail: matthew.bocci@alcatel-lucent.co.uk 742 Florin Balus 743 Alcatel-Lucent 744 701 E. Middlefield Rd. 745 Mountain View, CA 94043 746 e-mail: florin.balus@alcatel-lucent.com 748 Nabil Bitar 749 Verizon 750 40 Sylvan Road 751 Waltham, MA 02145 752 e-mail: nabil.bitar@verizon.com 754 Himanshu Shah 755 Ciena Corp 756 35 Nagog Park, 757 Acton, MA 01720 758 e-mail: hshah@ciena.com 759 Mustapha Aissaoui 760 Alcatel-Lucent 761 600 March Road 762 Kanata 763 ON, Canada 764 e-mail: mustapha.aissaoui@alcatel-lucent.com 766 Jason Rusmisel 767 Alcatel-Lucent 768 600 March Road 769 Kanata 770 ON, Canada 771 e-mail: Jason.rusmisel@alcatel-lucent.com 773 Yetik Serbest 774 SBC Labs 775 9505 Arboretum Blvd. 776 Austin, TX 78759 777 e-mail: Yetik_serbest@labs.sbc.com 779 Andrew G. Malis 780 Verizon 781 2730 Orchard Parkway 782 San Jose, CA, USA 95134 783 e-mail: Andy.Malis@tellabs.com 785 Chris Metz 786 Cisco Systems, Inc. 787 3700 Cisco Way 788 San Jose, Ca. 95134 789 e-mail: chmetz@cisco.com 791 David McDysan 792 Verizon 793 22001 Loudoun County Pkwy 794 Ashburn, VA, USA 20147 795 e-mail: dave.mcdysan@verizon.com 796 Jeff Sugimoto 797 Nortel 798 3500 Carling Ave. 799 Ottawa, Ontario, CANADA 800 e-mail: sugimoto@nortel.com 802 Mike Duckett 803 Bellsouth 804 Lindbergh Center D481 805 575 Morosgo Dr 806 Atlanta, GA 30324 807 e-mail: mduckett@bellsouth.net 809 Mike Loomis 810 Nortel 811 600, Technology Park Dr 812 Billerica, MA, USA 813 e-mail: mloomis@nortel.com 815 Paul Doolan 816 Mangrove Systems 817 IO Fairfield Blvd 818 Wallingford, CT, USA 06492 819 e-mail: pdoolan@mangrovesystems.com 821 Ping Pan 822 Hammerhead Systems 823 640 Clyde Court 824 Mountain View, CA, USA 94043 825 e-mail: ppan@hammerheadsystems.com 827 Prayson Pate 828 Overture Networks, Inc. 829 507 Airport Blvd, Suite 111 830 Morrisville, NC, USA 27560 831 e-mail: prayson.pate@overturenetworks.com 833 Vasile Radoaca 834 Alcatel-Lucent 835 Optics Divison, Westford, MA, USA 836 email: vasile.radoaca@alcatel-lucent.com 837 Yuichiro Wada 838 NTT Communications 839 3-20-2 Nishi-Shinjuku, Shinjuke-ku 840 Tokyo 163-1421, Japan 841 e-mail: yuichiro.wada@ntt.com 843 Yeongil Seo 844 Korea Telecom Corp. 845 463-1 Jeonmin-dong, Yusung-gu 846 Daejeon, Korea 847 e-mail: syi1@kt.co.kr