idnits 2.17.1 draft-ietf-pwe3-dynamic-ms-pw-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2010) is 5030 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 639, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-15 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini (Ed.) 3 Internet Draft Matthew Bocci (Ed.) 4 Expiration Date: January 2011 Cisco Systems Inc. 5 Intended status: Standards Track 6 Florin Balus (Ed.) 7 Alcatel-Lucent 9 July 11, 2010 11 Dynamic Placement of Multi Segment Pseudo Wires 13 draft-ietf-pwe3-dynamic-ms-pw-11.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 11, 2010 38 Abstract 40 There is a requirement for service providers to be able to extend the 41 reach of pseudo wires (PW) across multiple Packet Switched Network 42 domains. A Multi-Segment PW is defined as a set of two or more 43 contiguous PW segments that behave and function as a single point- 44 to-point PW. This document describes extensions to the PW control 45 protocol to dynamically place the segments of the multi segment 46 pseudo wire among a set of Provider Edge (PE) routers. 48 Table of Contents 50 1 Major Co-authors ..................................... 3 51 2 Acknowledgements ..................................... 3 52 3 Introduction ......................................... 3 53 3.1 Scope ................................................ 3 54 3.2 Specification of Requirements ........................ 3 55 3.3 Terminology .......................................... 4 56 3.4 Architecture Overview ................................ 4 57 4 Applicability ........................................ 6 58 4.1 Requirements Addressed ............................... 6 59 4.2 Changes to Existing PW Signaling ..................... 6 60 5 PW layer 2 addressing ................................ 6 61 5.1 Attachment Circuit Addressing ........................ 7 62 5.2 S-PE addressing ...................................... 7 63 6 Dynamic placement of MS-PWs .......................... 8 64 6.1 Pseudo wire routing procedures ....................... 8 65 6.1.1 AII PW routing table Lookup aggregation rules ........ 8 66 6.1.2 PW Static Route ...................................... 9 67 6.1.3 Dynamic advertisement with BGP ....................... 9 68 6.2 LDP Signaling ........................................ 10 69 6.2.1 MS-PW Bandwidth Signaling ............................ 10 70 6.2.2 Active/Passive T-PE Election Procedure ............... 12 71 6.2.3 Detailed Signaling Procedures ........................ 12 72 6.2.4 Support for Explicit PW Path ......................... 13 73 7 Failure Handling Procedures .......................... 14 74 7.1 PSN Failures ......................................... 14 75 7.2 S-PE Reachability Failures ........................... 14 76 8 Operations and Maintenance (OAM) ..................... 14 77 9 Security Considerations .............................. 15 78 10 IANA Considerations .................................. 15 79 10.1 LDP Status Codes ..................................... 15 80 10.2 BGP SAFI ............................................. 16 81 11 Normative References ................................. 16 82 12 Informative References ............................... 16 83 13 Author's Addresses ................................... 17 85 1. Major Co-authors 87 The editors gratefully acknowledge the following additional co- 88 authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, 89 Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff 90 Sugimoto. 92 2. Acknowledgements 94 The editors also gratefully acknowledge the input of the following 95 people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile 96 Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 98 3. Introduction 100 3.1. Scope 102 [MS-REQ] describes the service provider requirements for extending 103 the reach of pseudo-wires across multiple PSN domains. This is 104 achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is 105 defined as a set of two or more contiguous PW segments that behave 106 and function as a single point-to-point PW. This architecture is 107 described in [MS-ARCH]. 109 The procedures for establishing PWs that extend across a single PWE3 110 domain are described in [RFC4447], while procedures for setting up 111 PWs across multiple domains, or control planes are described in [PW- 112 SEG]. 114 The purpose of this draft is to specify extensions to the PWE3 115 control protocol [RFC4447], and [PW-SEG] procedures, to enable 116 multi-segment PWs to be automatically placed. The proposed procedures 117 follow the guidelines defined in [RFC5036] and enable the reuse of 118 existing TLVs, and procedures defined for SS-PWs in [RFC4447]. 120 3.2. Specification of Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119. 126 3.3. 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 3.4. 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 4. 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 4.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 4.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 5. 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 5.1. Attachment Circuit Addressing 235 The attachment circuit addressing is derived from [RFC5003] AII type 236 2 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 5.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 [RFC5003] composed of 271 the Global ID, and Prefix part only MUST be assigned to each S-PE. 273 6. 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 6.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 6.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 [RFC5003]) consists of a 319 Global 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 Most Significant 324 Bits (MSB) are relevant 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 6.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 6.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) [RFC4760] to propagate PW address information 356 throughout the PSN. 358 Contrary to other l2vpn signaling methods that use BGP [L2- 359 SIGNALING], in the case of the dynamically placed MS-PW if the source 360 T-PE knows a priori (by provisioning) the address of the terminating 361 T-PE. Hence there is no need to advertise a "fully qualified" 96 bit 362 address on a per PW Attachment Circuit basis. Only the T-PE Global 363 ID, Prefix, and prefix length needs to be advertised as part of well 364 known BGP procedures - see [RFC4760]. 366 As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this 367 information to obtain the first S-PE hop (i.e., first BGP next hop) 368 to where the first PW segment will be established. Any subsequent S- 369 PEs will use the same information (i.e. the next BGP next-hop(s)) to 370 obtain the next-signaling-hop(s) on the path to the TT-PE. 372 The PW dynamic path NLRI is advertised in BGP UPDATE messages using 373 the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, 374 SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6 375 (pending IANA allocation)). 377 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 378 an IPv4 address, whenever the length of the NextHop address is 4 379 octets, and as a IPv6 address, whenever the length of the NextHop 380 address is 16 octets. 382 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 383 of 0 to 96 bits encoded as defined in section 4 of [RFC4760]. 385 This prefix is structured as follows: 387 0 31 32 63 64 95 (bits) 388 +-----------+--------+--------+ 389 | Global ID | Prefix | AC ID | 390 +-----------+--------+--------+ 392 Except for the default PW route, which is encoded as a 0 length 393 prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to 394 95 are invalid as the AC ID field cannot be aggregated. 396 6.2. LDP Signaling 398 The LDP signaling procedures are described in [RFC4447] and expanded 399 in [PW-SEG]. No new LDP Signaling components are required for setting 400 up a dynamically placed MS-PW. However some optional signaling 401 extensions are described below. 403 6.2.1. MS-PW Bandwidth Signaling 405 In the SS-PW case the PW QoS requirements may easily be met by 406 selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS 407 requirements. However in the case of an automatically placed MS-PW 408 the QoS requirements for a SS-PW not initiating on a T-PE MAY need to 409 be indicated along with the MS-PW addressing. This is accomplished by 410 including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is 411 specified as follows: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |1|0| PW BW TLV (0x096E) | TLV Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Forward SENDER_TSPEC | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Reverse SENDER_TSPEC | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 The complete definitions of the content of the SENDER_TSPEC objects 424 are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to 425 the data path in the direction of ST-PE to TT-PE. The reverse 426 SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. 428 In the forward direction, after a next hop selection is determined, a 429 T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine 430 an appropriate PSN tunnel towards the next signaling hop. If such a 431 tunnel exists, the MS-PW signaling procedures are invoked with the 432 inclusion of the PW Bandwidth TLV. When the PE searches for a PSN 433 tunnel, any tunnel which points to a next hop equivalent to the next 434 hop selected will be included in the search.(The LDP address TLV is 435 used to determine the next hop equivalence) 437 When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is 438 selected, the S/T-PE MUST request the appropriate resources from the 439 PSN. The resources described in the reverse SENDER_TSPEC are 440 allocated from the PSN toward the originator of the message or 441 previous hop. When resources are allocated from the PSN for a 442 specific PW, then the PSN SHOULD account for the PW usage of the 443 resources. 445 In the case where PSN resources towards the previous hop are not 446 available the following procedure MUST be followed: 447 -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to 448 the PSN tunnel. 449 -ii. The S-PE MAY attempt to setup another PSN tunnel to 450 accommodate the new PW QoS requirements. 451 -iii. If the S-PE cannot get enough resources to setup the segment 452 in the MS-PW a label release MUST be returned to the 453 previous hop with a status message of "Bandwidth resources 454 unavailable" 456 In the latter case, the T-PE receiving the status message MUST also 457 withdraw the corresponding PW label mapping for the opposite 458 direction if it has already been successfully setup. 460 If an ST-PE receives a label mapping message the following procedure 461 MUST be followed: 463 If the ST-PE has already sent a label mapping message for this PW 464 then the ST-PE must check that this label mapping message originated 465 from the same LDP peer to which the corresponding label mapping 466 message for this particular PW was sent. If it is the same peer, the 467 PW is established. If it is a different peer, then ST-PE MUST send a 468 label release message, with a status code of "Duplicate AII" to the 469 PE that originate the LDP label mapping message. 471 If the PE has not yet sent a label mapping message for this 472 particular PW , then it MUST send the label mapping message to this 473 same LDP peer, regardless of what the PW TAII routing lookup result 474 is. 476 6.2.2. Active/Passive T-PE Election Procedure 478 When a MS-PW is signaled, Each T-PE might independently start 479 signaling the MS-PW, this could result in a different path selected 480 for each T-PE PW. To avoid this situation one of the T-PE MUST start 481 the PW signaling (active role), while the other waits to receive the 482 LDP label mapping before sending the respective PW LDP label mapping 483 message. (passive role). The Active T-PE (the ST-PE) and the passive 484 T-PE (the TT-PE) MUST be identified before signaling is initiated for 485 a given MS-PW. 487 The determination of which T-PE assume the active role SHOULD be done 488 as follows: the SAII and TAII are compared as unsigned integers, if 489 the SAII is bigger then the T-PE assumes the active role. 491 The selection process to determine which T-PE assumes the active role 492 MAY be superseded by manual provisioning. 494 6.2.3. Detailed Signaling Procedures 496 On receiving a label mapping message, the S-PE MUST inspect the FEC 497 TLV. If the receiving node has no local AII matching the TAII for 498 that label mapping then the S-PE will check if the FEC is already 499 installed for the forward direction: 501 - If it is already installed, and the received mapping was received 502 from the same LDP peer where the forward LDP label mapping was 503 sent, then this label mapping represents signaling in the reverse 504 direction for this MS-PW segment. 505 - Otherwise this represents signaling in the forward direction. 507 For the forward direction: 508 -i. Determine the next hop S-PE or T-PE according to the 509 procedures above. 510 -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. 511 If no tunnel exists to the next hop S-PE or T-PE the S-PE 512 MAY attempt to setup a PSN tunnel. 513 -iii. Check that a PSN tunnel exists to the previous hop. If no 514 tunnel exists to the previous hop S-PE or T-PE the S-PE MAY 515 attempt to setup a PSN tunnel. 516 -iv. If the S-PE cannot get enough PSN resources to setup the 517 segment to the next or previous S-PE or T-PE, a label 518 release MUST be returned to the T-PE with a status message 519 of "Resources Unavailable". 520 -v. If the label mapping message contains a Bandwidth TLV, 521 allocate the required resources on the PSN tunnels in the 522 forward and reverse directions according to the procedures 523 above. 524 -vi. Allocate a new PW label for the forward direction. 525 -vii. Install the FEC for the forward direction. 526 -viii. Send the label mapping message with the new forward label 527 and the FEC to the next hop S-PE/T-PE. 529 For the reverse direction: 530 -i. Install the received FEC for the reverse direction. 531 -ii. Determine the next signaling hop by referencing the LDP 532 sessions used to setup the LSP in the Forward direction. 533 -iii. Allocate a new PW label for the reverse direction. 534 -iv. Install the FEC for the reverse direction. 535 -v. Send the label mapping message with a new label and the FEC 536 to the next hop S-PE/ST-PE. 538 6.2.4. Support for Explicit PW Path 540 The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be 541 used to signal an explicit path for a MS-PW. An Explicit PW path may 542 be required to provide a simple solution for 1:1 protection with 543 diverse primary and backup path or to enable controlled signaling 544 (strict or loose) for special PWs. Details of its usage to be 545 provided in a future study. 547 7. Failure Handling Procedures 549 7.1. PSN Failures 551 Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the 552 PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD 553 follow the procedures defined in Section 8 of [PW-SEG]. 555 7.2. S-PE Reachability Failures 557 For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be 558 followed. However in general an established MS-PW will not be 559 affected by changes in L2 PW reachability information. 561 T-PEs that receive a label release message with a status of "AII 562 Unreachable" MUST re-attempt to establish the PW immediately. However 563 the T-PE MUST throttle its PW setup message retry attempts with an 564 exponential backoff in situations where PW setup messages are being 565 constantly released. It is also recommended that a T-PE detecting 566 such a situation take action to notify an operator. 568 If there is a change in the L2 PW reachability information in the 569 forward direction only, the T-PE MAY elect to tear down the MS-PW by 570 sending a label withdraw message and re-establish the MS-PW. In the 571 same case, an S-PE MAY do the same by sending a label withdraw 572 message in the forward direction, and a label release message in the 573 opposite direction along the MS-PW. 575 A change in L2 reachability information in the reverse direction has 576 no effect on an MS-PW. 578 8. Operations and Maintenance (OAM) 580 The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A 581 PW switching point TLV is used [PW-SEG] to record the switching 582 points that the PW traverses. 584 In the case of a MS-PW where the PW Endpoints are identified though 585 using a globally unique, FEC 129-based AII addresses, there is no 586 PWID defined on a per segment basis. Each individual PW segment is 587 identified by the address of adjacent S-PE(s) in conjunction with the 588 SAI and TAI. In this case, the following type MUST be used in place 589 of type 0x01 in the PW switching point TLV: 591 Type Length Description 592 0x06 12 L2 PW address of PW Switching Point 594 The above field MUST be included together with type 0x02 in the TLV 595 once per individual PW Switching Point following the same rules and 596 procedures as described in [PW-SEG]. 598 9. Security Considerations 600 This document specifies only extensions to the protocols already 601 defined in [RFC4447], and [PW-SEG]. Each such protocol may have its 602 own set of security issues, but those issues are not affected by the 603 extensions specified herein. Note that the protocols for dynamically 604 distributing PW Layer 2 reachability information may have their own 605 security issues, however those protocols specifications are outside 606 the scope of this document. 608 10. IANA Considerations 610 This document uses several new LDP TLV types, IANA already maintains 611 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 612 following value is suggested for assignment: 614 TLV type Description 615 0x096E Bandwidth TLV 617 10.1. LDP Status Codes 619 This document uses several new LDP status codes, IANA already 620 maintains a registry of name "STATUS CODE NAME SPACE" defined by 621 RFC3036. The following values have been pre-allocated: 623 Range/Value E Description Reference 624 ------------- ----- ---------------------- --------- 625 0x00000037 0 Bandwidth resources unavailable RFCxxxx 626 0x00000038 0 Resources Unavailable RFCxxxx 627 0x00000039 0 AII Unreachable RFCxxxx 628 0x0000003A 0 PW Loop Detected RFCxxxx 630 10.2. BGP SAFI 632 IANA needs to allocate a new BGP SAFI for "Network Layer Reachability 633 Information used for Dynamic Placement of Multi-Segment Pseudiwires" 634 from the IANA "Subsequence Address Family Identifiers (SAFI)" 635 registry. The following value has been pre-allocated: 637 Value Description Reference 638 ----- ----------- --------- 639 6 Network Layer Reachability Information used [RFCxxxx] 640 for Dynamic Placement of Multi-Segment 641 Pseudowires 643 11. Normative References 645 [PW-SEG] Martini et.al. "Segmented Pseudo Wire", 646 draft-ietf-pwe3-segmented-pw-15.txt, IETF Work in Progress, 647 June 2010 649 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated 650 Services", RFC 2210, September 1997 652 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" 653 RFC5036, October 2007 655 [RFC4447] "Pseudowire Setup and Maintenance Using the Label 656 Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, 657 June 2005. 659 [RFC5003] "Attachment Individual Identifier (AII) Types for 660 Aggregation", Metz, et al, RFC5003, September 2007 662 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", 663 RFC3212, January 2002. 665 12. Informative References 667 [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire 668 Emulation Edge-to-Edge (PWE3)", 669 RFC5023, Bitar, Martini, Bocci, October 2008 671 [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire 672 Emulation Edge-to-Edge", RFC5659,October 2009. 674 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 675 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 677 [L2-SIGNALING] E. Rosen, W. Luo, B. Davie, V. Radoaca, 678 "Provisioning, Autodiscovery, and Signaling in L2VPNs", 679 draft-ietf-l2vpn-signaling-08.txt May 3, 2006.(work in progress) 681 13. Author's Addresses 683 Luca Martini 684 Cisco Systems, Inc. 685 9155 East Nichols Avenue, Suite 400 686 Englewood, CO, 80112 687 e-mail: lmartini@cisco.com 689 Matthew Bocci 690 Alcatel-Lucent, 691 Voyager Place 692 Shoppenhangers Road 693 Maidenhead 694 Berks, UK 695 e-mail: matthew.bocci@alcatel-lucent.co.uk 697 Florin Balus 698 Alcatel-Lucent 699 701 E. Middlefield Rd. 700 Mountain View, CA 94043 701 e-mail: florin.balus@alcatel-lucent.com 703 Nabil Bitar 704 Verizon 705 40 Sylvan Road 706 Waltham, MA 02145 707 e-mail: nabil.bitar@verizon.com 709 Himanshu Shah 710 Ciena Corp 711 35 Nagog Park, 712 Acton, MA 01720 713 e-mail: hshah@ciena.com 714 Mustapha Aissaoui 715 Alcatel-Lucent 716 600 March Road 717 Kanata 718 ON, Canada 719 e-mail: mustapha.aissaoui@alcatel-lucent.com 721 Jason Rusmisel 722 Alcatel-Lucent 723 600 March Road 724 Kanata 725 ON, Canada 726 e-mail: Jason.rusmisel@alcatel-lucent.com 728 Yetik Serbest 729 SBC Labs 730 9505 Arboretum Blvd. 731 Austin, TX 78759 732 e-mail: Yetik_serbest@labs.sbc.com 734 Andrew G. Malis 735 Verizon 736 117 West St. 737 Waltham, MA 02451 738 e-mail: andrew.g.malis@verizon.com 740 Chris Metz 741 Cisco Systems, Inc. 742 3700 Cisco Way 743 San Jose, Ca. 95134 744 e-mail: chmetz@cisco.com 746 David McDysan 747 Verizon 748 22001 Loudoun County Pkwy 749 Ashburn, VA, USA 20147 750 e-mail: dave.mcdysan@verizon.com 751 Jeff Sugimoto 752 Nortel 753 3500 Carling Ave. 754 Ottawa, Ontario, CANADA 755 e-mail: sugimoto@nortel.com 757 Mike Duckett 758 Bellsouth 759 Lindbergh Center D481 760 575 Morosgo Dr 761 Atlanta, GA 30324 762 e-mail: mduckett@bellsouth.net 764 Mike Loomis 765 Nortel 766 600, Technology Park Dr 767 Billerica, MA, USA 768 e-mail: mloomis@nortel.com 770 Paul Doolan 771 Mangrove Systems 772 IO Fairfield Blvd 773 Wallingford, CT, USA 06492 774 e-mail: pdoolan@mangrovesystems.com 776 Ping Pan 777 Hammerhead Systems 778 640 Clyde Court 779 Mountain View, CA, USA 94043 780 e-mail: ppan@hammerheadsystems.com 782 Prayson Pate 783 Overture Networks, Inc. 784 507 Airport Blvd, Suite 111 785 Morrisville, NC, USA 27560 786 e-mail: prayson.pate@overturenetworks.com 788 Vasile Radoaca 789 Alcatel-Lucent 790 Optics Divison, Westford, MA, USA 791 email: vasile.radoaca@alcatel-lucent.com 792 Yuichiro Wada 793 NTT Communications 794 3-20-2 Nishi-Shinjuku, Shinjuke-ku 795 Tokyo 163-1421, Japan 796 e-mail: yuichiro.wada@ntt.com 798 Yeongil Seo 799 Korea Telecom Corp. 800 463-1 Jeonmin-dong, Yusung-gu 801 Daejeon, Korea 802 e-mail: syi1@kt.co.kr 804 Copyright Notice 806 Copyright (c) 2010 IETF Trust and the persons identified as the 807 document authors. All rights reserved. 809 This document is subject to BCP 78 and the IETF Trust's Legal 810 Provisions Relating to IETF Documents 811 (http://trustee.ietf.org/license-info) in effect on the date of 812 publication of this document. Please review these documents 813 carefully, as they describe your rights and restrictions with respect 814 to this document. Code Components extracted from this document must 815 include Simplified BSD License text as described in Section 4.e of 816 the Trust Legal Provisions and are provided without warranty as 817 described in the Simplified BSD License. 819 This document may contain material from IETF Documents or IETF 820 Contributions published or made publicly available before November 821 10, 2008. The person(s) controlling the copyright in some of this 822 material may not have granted the IETF Trust the right to allow 823 modifications of such material outside the IETF Standards Process. 824 Without obtaining an adequate license from the person(s) controlling 825 the copyright in such materials, this document may not be modified 826 outside the IETF Standards Process, and derivative works of it may 827 not be created outside the IETF Standards Process, except to format 828 it for publication as an RFC or to translate it into languages other 829 than English. 831 Expiration Date: January 2011