idnits 2.17.1 draft-ietf-pwe3-segmented-pw-09.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1594. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This FEC information can then be compared to the S-PE TLV information received from the control plane when the PW was first signalled. This FEC information MUST not be sent in the reply if the S-PE is not sending an S-PE TLV for administrative reasons in the same situation as explained previously. -- 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 2008) is 5763 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-05 -- Unexpected draft version: The latest known version of draft-mistretta-l2tp-infomsg is -01, but you're referring to -02. == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-03 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Chris Metz 4 Expiration Date: January 2009 Cisco Systems Inc. 5 Intended status: Standards Track 6 Thomas D. Nadeau 7 Matthew Bocci BT 8 Florin Balus 9 Mustapha Aissaoui Mike Duckett 10 Alcatel-Lucent Bellsouth 12 July 2008 14 Segmented Pseudo Wire 16 draft-ietf-pwe3-segmented-pw-09.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to connect pseudowires (PW) between two 43 distinct PW control planes or PSN domains. The PW control planes may 44 belong to independent autonomous systems, or the PSN technology is 45 heterogeneous, or a PW might need to be aggregated at a specific PSN 46 point. The PW packet data units are simply switched from one PW to 47 another without changing the PW payload. 49 Table of Contents 51 1 Specification of Requirements ........................ 4 52 2 Terminology .......................................... 5 53 3 Introduction ......................................... 5 54 4 General Description .................................. 7 55 5 PW Switching and Attachment Circuit Type ............. 10 56 6 Applicability ........................................ 10 57 7 PW-MPLS to PW-MPLS Control Plane Switching ........... 10 58 7.1 Static Control plane switching ....................... 11 59 7.2 Two LDP control planes using the same FEC type ....... 11 60 7.2.1 FEC 129 Active/Passive T-PE Election Procedure ....... 12 61 7.3 LDP FEC 128 to LDP using the generalized FEC 129 ..... 12 62 7.4 LDP PW switching point TLV ........................... 13 63 7.4.1 PW Switching Point Sub-TLVs .......................... 14 64 7.4.2 Adaptation of Interface Parameters ................... 15 65 7.5 Group ID ............................................. 16 66 7.6 PW Loop Detection .................................... 16 67 8 PW-MPLS to PW-L2TPv3 Control Plane Switching ......... 16 68 8.1 Static MPLS and L2TPv3 PWs ........................... 17 69 8.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 17 70 8.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 17 71 8.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 17 72 8.4.1 Session Establishment ................................ 18 73 8.4.2 Adaptation of PW Status message ...................... 18 74 8.4.3 Session Tear Down .................................... 19 75 8.5 Adaptation of L2TPv3 AVPs to Interface Parameters .... 19 76 8.6 Switching Point TLV in L2TPv3 ........................ 20 77 8.7 L2TPv3 and MPLS PW Data Plane ........................ 20 78 8.7.1 PWE3 Payload Convergence and Sequencing .............. 21 79 8.7.2 Mapping .............................................. 21 80 9 Operation And Management ............................. 22 81 9.1 Extensions to VCCV to Support Switched PWs ........... 22 82 9.2 PW-MPLS to PW-MPLS OAM Data Plane Indication ......... 22 83 9.2.1 Decreasing the PW Label TTL .......................... 22 84 9.3 Signaling OAM Capabilities for Switched Pseudowires .. 23 85 9.4 OAM Capability for MS-PWs Demultiplexed using MPLS ... 23 86 9.4.1 MS-PW and VCCV CC Type 1 ............................. 24 87 9.4.2 MS-PW and VCCV CC type 2 ............................. 24 88 9.4.3 MS-PW and VCCV CC type 3 ............................. 24 89 9.4.4 Detailed VCCV Procedures ............................. 24 90 9.4.4.1 End to End verification between T-PEs ................ 24 91 9.4.4.2 Partial verification from T-PE ....................... 25 92 9.4.4.3 Partial verification between S-PEs ................... 26 93 9.4.5 Optional FEC Reply in VCCV LSP Ping packet ........... 26 94 9.4.6 Processing of an VCCV Echo Message in a MS-PW ........ 27 95 9.4.6.1 Sending a VCCV Echo Request .......................... 27 96 9.4.6.2 Receiving an VCCV Echo Request ....................... 27 97 9.4.7 VCCV Trace Operations ................................ 27 98 9.5 Mapping Switched Pseudowire Status ................... 28 99 9.5.1 S-PE initiated PW status messages .................... 30 100 9.5.1.1 Local PW2 reverse direction fault .................... 31 101 9.5.1.2 Local PW1 reverse direction fault .................... 31 102 9.5.1.3 Local PW2 forward direction fault .................... 32 103 9.5.1.4 Local PW1 forward direction fault .................... 32 104 9.5.1.5 Clearing Faults ...................................... 32 105 9.5.2 PW status messages and S-PE TLV processing ........... 32 106 9.5.3 T-PE processing of PW status messages ................ 33 107 9.6 Pseudowire Status Negotiation Procedures ............. 33 108 9.7 Status Dampening ..................................... 33 109 10 Peering Between Autonomous Systems ................... 33 110 11 Security Considerations .............................. 33 111 11.1 Data Plane Security .................................. 34 112 11.1.1 VCCV Security considerations ......................... 34 113 11.2 Control Protocol Security ............................ 34 114 12 IANA Considerations .................................. 35 115 12.1 L2TPv3 AVP ........................................... 35 116 12.2 LDP TLV TYPE ......................................... 35 117 12.3 LDP Status Codes ..................................... 36 118 12.4 L2TPv3 Result Codes .................................. 36 119 12.5 New IANA Registries .................................. 36 120 13 Intellectual Property Statement ...................... 37 121 14 Full Copyright Statement ............................. 37 122 15 Acknowledgments ...................................... 38 123 16 Normative References ................................. 38 124 17 Informative References ............................... 39 125 18 Author Information ................................... 40 127 1. Specification of Requirements 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Terminology 135 - PW Terminating Provider Edge (T-PE). A PE where the customer- 136 facing attachment circuits (ACs) are bound to a PW forwarder. A 137 Terminating PE is present in the first and last segments of a 138 MS-PW. This incorporates the functionality of a PE as defined in 139 [RFC3985]. 141 - Single-Segment Pseudowire (SS-PW). A PW setup directly between 142 two T-PE devices. Each PW in one direction of a SS-PW traverses 143 one PSN tunnel that connects the two T-PEs. 145 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 146 configured set of two or more contiguous PW segments that behave 147 and function as a single point-to-point PW. Each end of a MS-PW 148 by definition MUST terminate on a T-PE. 150 - PW Segment. A part of a single-segment or multi-segment PW, which 151 is set up between two PE devices, T-PEs and/or S-PEs. 153 - PW Switching Provider Edge (S-PE). A PE capable of switching the 154 control and data planes of the preceding and succeeding PW 155 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 156 preceding and succeeding segments of the MS-PW. It is therefore a 158 - PW switching point for a MS-PW. A PW Switching Point is never the 159 S-PE and the T-PE for the same MS-PW. A PW switching point runs 160 necessary protocols to setup and manage PW segments with other PW 161 switching points and terminating PEs. 163 3. Introduction 165 PWE3 defines the signaling and encapsulation techniques for 166 establishing SS-PWs between a pair of ultimate PEs and in the vast 167 majority of cases this will be sufficient. MS-PWs come into play in 168 two general cases: 170 -i. When it is not possible, desirable or feasible to establish 171 a PW control channel between the ultimate source and 172 destination PEs. At a minimum PW control channel 173 establishment requires knowledge of and reachability to the 174 remote (ultimate) PE IP address. The local (ultimate) PE may 175 not have access to this information related to topology, 176 operational or security constraints. 178 An example is the inter-AS L2VPN scenario where the ultimate 179 PEs reside in different provider networks (ASes) and it is 180 the practice to MD5-key all control traffic exchanged 181 between two networks. Technically a SS-PW could be used but 182 this would require MD5-keying on ALL ultimate source and 183 destination PE nodes. An MS-PW allows the providers to 184 confine MD5 key administration to just the PW switching 185 points connecting the two domains. 187 A second example might involve a single AS where the PW 188 setup path between the ultimate PEs is computed by an 189 external entity (i.e. client-layer routing protocol). Assume 190 a full mesh of PWE3 control channels established between 191 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 192 through a PW is required between ultimate PE-A and PE-C. The 193 external entity computes a PW setup path that passes through 194 PE-B. This results in two discrete PW segments being built: 195 one between PE-A and PE-B and one between PE-B and PE-C. The 196 successful client-layer L2 connection between ultimate PE-A 197 and ultimate PE-C requires that PE-B performs the PWE3 198 switching process. 200 A third example involves the use of PWs in hierarchical 201 IP/MPLS networks. Access networks connected to a backbone 202 use PWs to transport customer payloads between customer 203 sites serviced by the same access network and up to the edge 204 of the backbone where they can be terminated or switched 205 onto a succeeding PW segment crossing the backbone. The use 206 of PWE3 switching between the access and backbone networks 207 can potentially reduce the PWE3 control channels and routing 208 information processed by the access network T-PEs. 210 It should be noted that PWE3 switching does not help in any 211 way to reduce the amount of PW state supported by each 212 access network T-PE. 214 -ii. PWE3 signaling and encapsulation protocols are different. 215 The ultimate PEs are connected to networks employing 216 different PW signaling and encapsulation protocols. In this 217 case it is not possible to use a SS-PW. A MS-PW with the 218 appropriate interworking performed at the PW switching 219 points can enable PW connectivity between the ultimate PEs 220 in this scenario. 222 There are four different signaling protocols that are defined to 223 signal PWs: 225 -i. Static configuration of the PW (MPLS or L2TPv3). 226 -ii. LDP using FEC 128 227 -iii. LDP using the generalized FEC 129 228 -iv. L2TPv3 230 4. General Description 232 A pseudowire (PW) is a tunnel established between two provider edge 233 (PE) nodes to transport L2 PDUs across a packet switched network 234 (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are 235 looking at PWs as a means of migrating existing (or building new) 236 L2VPN services (i.e. Frame-Relay, ATM, Ethernet) on top of a PSN by 237 using PWs. PWs may span multiple autonomous systems of the same or 238 different provider networks. In these scenarios PW control channels 239 (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries. 241 Inter-AS L2VPN functionality is currently supported and several 242 techniques employing MPLS encapsulation and LDP signaling have been 243 documented [2547BIS]. It is also straightforward to support the same 244 inter-AS L2VPN functionality employing L2TPv3. In this document we 245 define methodology to switch a PW between two PW control planes. 247 |<-------------- Emulated Service ---------------->| 248 | | 249 | |<-------- Pseudowire ------>| | 250 | | | | 251 | | |<-- PSN Tunnel -->| | | 252 | V V V V | 253 V AC +----+ +----+ AC V 254 +-----+ | | PE1|==================| PE2| | +-----+ 255 | |----------|............PW1.............|----------| | 256 | CE1 | | | | | | | | CE2 | 257 | |----------|............PW2.............|----------| | 258 +-----+ ^ | | |==================| | | ^ +-----+ 259 ^ | +----+ +----+ | | ^ 260 | | Provider Edge 1 Provider Edge 2 | | 261 | | | | 262 Customer | | Customer 263 Edge 1 | | Edge 2 264 | | 265 native service native service 267 Figure 1: PWE3 Reference Model 269 There are two methods for switching a PW between two PW control 270 planes. In the first method (Figure 2), the two control planes 271 terminate on different PEs. 273 |<------------Emulated Service---------->| 274 | PSN PSN | 275 AC | |<-1->| |<-2->| | AC 276 | V V V V V V | 277 | +----+ +-----+ +----+ +----+ | 278 +----+ | | |=====| | | |=====| | | +----+ 279 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 280 | CE1| | | | | | | | | | | |CE2 | 281 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 282 +----+ | | |=====| | | |=====| | | +----+ 283 ^ +----+ +-----+ +----+ +----+ ^ 284 | PE1 PE2 PE3 PE4 | 285 | ^ ^ | 286 | | | | 287 | PW stitching points | 288 | | 289 | | 290 |<-------------------- Emulated Service ---------------->| 292 Figure 2: PW Switching using ACs Reference Model 294 In Figure 2, pseudowires in two separate PSNs are stitched together 295 using native service attachment circuits. PE2 and PE3 only run the 296 control plane for the PSN to which they are directly attached. At PE2 297 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 298 while PW3 and PW4 are connected using attachment circuit AC2. 300 Native |<-----------Pseudowire------------>| Native 301 Layer2 | | Layer2 302 Service | |<-PSN1-->| |<--PSN2->| | Service 303 (AC) V V V V V V (AC) 304 | +----+ +-----+ +----+ | 305 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 306 | |----------|........PW1.........|...PW3........|----------| | 307 | CE1| | | | | | | | | |CE2 | 308 | |----------|........PW2.........|...PW4........|----------| | 309 +----+ | | |=========| |=========| | | +----+ 310 ^ +----+ +-----+ +----+ | ^ 311 | Provider Edge 1 ^ Provider Edge 3 | 312 | (Terminating PE) | (Terminating PE) | 313 | | | 314 | PW switching point | 315 | (Optional PW adaptation function) | 316 | | 317 |<------------------- Emulated Service ------------------>| 318 Figure 3: PW Control Plane Switching Reference Model 320 In Figure 3 PE2 runs two separate control planes: one toward PE1, and 321 one Toward PE3. The PW switching point is at PE2 which is configured 322 to connect PW1 and PW3 together to complete the multi-hop PW between 323 PE1 and PE3. PW1 and PW3 MUST be of the same PW type, but PSN1 and 324 PSN2 need not be the same technology. In the latter case, if the PW 325 is switched to a different technology, the PEs must adapt the PDU 326 encapsulation between the different PSN technologies. In the case 327 where PSN1 and PSN2 are the same technology the PW PDU does not need 328 to be modified, and PDUs are then switched between the pseudowires at 329 the PW label level. 331 It should be noted that it is possible to adapt one PSN technology to 332 a different one, for example MPLS over an IP or GRE [RFC4023] 333 encapsulation, but this is outside the scope of this document. 334 Further, one could perform an interworking function on the PWs 335 themselves at the PW switching point, allowing conversion from one PW 336 type to another, but this is also outside the scope of this document. 338 This document describes procedures for building multi-segment 339 pseudowires using manual configuration of the switching point PE2. 340 Other documents may build on this base specification to automate the 341 configuration and selection of PE2. It should also be noted that a PW 342 can traverse multiple PW switching points along it's path, and the 343 edge PEs will not require any specific knowledge of how many PW 344 switching points the PW has traversed (though this may be reported 345 for troubleshooting purposes). 347 In general the approach taken is to connect the individual control 348 planes by passing along any signaling information immediately upon 349 reception. First the PW switching point is configured to switch a 350 SS-PW from a specific peer to another SS-PW destined for a different 351 peer. No control messages are exchanged yet as the PW switching point 352 PE does not have enough information to actually initiate the PW setup 353 messages. However, if a session does not already exist, a control 354 protocol (LDP/L2TP) session is setup. In this model the MS-PW setup 355 is starting from the T-PE devices. Next once the T-PE is configured 356 it sends the PW control setup messages. These messages are received, 357 and immediately used to form the PW setup messages for the next SS-PW 358 of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label 359 Mapping message then a Label Release message may be sent back to the 360 originator T-PE depending on the cause of the error. LDP liberal 361 label retention mode still applies, hence if a PE is simply not 362 configured yet , the label mapping is stored for future use. A MS-PW 363 is declared UP when all the constituent SS-PWs are UP. 365 5. PW Switching and Attachment Circuit Type 367 The PWs in each PSN are established independently, with each PSN 368 being treated as a separate PWE3 domain. For example, in Figure 2 for 369 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 370 targeted session as described in [RFC4447], and at the same time a 371 separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for 372 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 373 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 375 6. Applicability 377 The general applicability of MS-PWs and their relationship to L2VPNs 378 is described in [MS-PW-ARCH]. The applicability of a PW type, as 379 specified in the relevant RFC for that encapsulation (e.g. [RFC4717] 380 for ATM), applies to each segment. This section describes further 381 applicability considerations. 383 In comon with SS-PWs, the performance of any segment of a MS-PW is 384 equal to the performance of the PSN plus any impairments introduced 385 by the PW layer itself. Therefore it is not possible for the MS-PW to 386 provide better performance than the PSN over which it is transported. 387 Furthermore, the overall performance of an MS-PW is no better than 388 the worst performing segment of that MS-PW. 390 Since different PSN types may be able to achieve different maximum 391 performance objectives, it is necessary to carefully consider which 392 PSN types are used along the path of a MS-PW. 394 7. PW-MPLS to PW-MPLS Control Plane Switching 396 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 397 session as described in [RFC4447], at the same time a separate 398 pseudowire PW3 is setup to PE3. Each PW is configured independently 399 on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3. 400 PDUs are then switched between the pseudowires at the PW label level. 401 Hence the data plane does not need any special knowledge of the 402 specific pseudowire type. A simple standard MPLS label swap operation 403 is sufficient to connect the two PWs, and in this case the PW 404 adaptation function is not used. However when pushing a new PSN label 405 the TTL SHOULD be set to 255, or some other locally configured fixed 406 value. 408 This process can be repeated as many times as necessary, the only 409 limitation to the number of PW switching points traversed is imposed 410 by the TTL field of the PW MPLS Label. The setting of the TTL is a 411 matter of local policy on the originating PE, but SHOULD be set to 412 255. 414 There are three MPLS to MPLS PW control planes: 415 -i. Static configuration of the PW. 416 -ii. LDP using FEC 128 417 -iii. LDP using the generalized FEC 129 418 This results in four distinct PW switching situations that are 419 significantly different, and must be considered in detail: 420 -i. PW Switching between two static control planes. 421 -ii. Static Control plane switching to LDP dynamic control plane. 422 -iii. Two LDP control planes using the same FEC type 423 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 425 7.1. Static Control plane switching 427 In the case of two static control planes the PW switching point MUST 428 be configured to direct the MPLS packets from one PW into the other. 429 There is no control protocol involved in this case. When one of the 430 control planes is a simple static PW configuration and the other 431 control plane is a dynamic LDP FEC 128 or generalized PW FEC, then 432 the static control plane should be considered identical to an 433 attachment circuit (AC) in the reference model of Figure 1. The 434 switching point PE SHOULD signal the proper PW status if it detects a 435 failure in sending or receiving packets over the static PW. Because 436 the PW is statically configured, the status communicated to the 437 dynamic LDP PW will be limited to local interface failures. In this 438 case, the PW switching point PE behaves in a very similar manner to a 439 T-PE, assuming an active role. This means that the S-PE will 440 immediately send the LDP Label Mapping message if the static PW is 441 deemed to be UP. 443 7.2. Two LDP control planes using the same FEC type 445 As stated in a section above, the PW switching point PE should assume 446 an initial passive role. This means that once independent PWs are 447 configured on the switching point, the LSR does not advertise the LDP 448 PW FEC mapping until it has received at least one of the two PW LDP 449 FECs from a remote PE. This is necessary because the switching point 450 LSR does not know a priori what the interface parameter field in the 451 initial FEC advertisement will contain. 453 The PWID is a unique number between each pair of PEs. Hence Each SS- 454 PW that forms an MS-PW may have a different PWID. In the case of The 455 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 456 some, or sometimes all, SS-PWs. 458 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 460 When a MS-PW is signaled using FEC 129, each T-PE might independently 461 start signaling the MS-PW. If the MS-PW path is not statically 462 configured, in certain cases the signaling procedure could result in 463 an attempt to setup each direction of the MS-PW through different 464 paths. To avoid this situation one of the T-PE MUST start the PW 465 signaling (active role), while the other waits to receive the LDP 466 label mapping before sending the respective PW LDP label mapping 467 message. (passive role). When the MS-PW path not statically 468 configured, the Active T-PE (the ST-PE) and the passive T-PE (the 469 TT-PE) MUST be identified before signaling is initiated for a given 470 MS-PW. 472 The determination of which T-PE assume the active role SHOULD be done 473 as follows: 475 the SAII and TAII are compared as unsigned integers, if the SAII is 476 bigger then the T-PE assumes the active role. 478 The selection process to determine which T-PE assumes the active role 479 MAY be superseded by manual provisioning. 481 7.3. LDP FEC 128 to LDP using the generalized FEC 129 483 When a PE is using the generalized FEC 129, there are two distinct 484 roles that a PE can assume: active and passive. A PE that assumes the 485 active role will send the LDP PW setup message, while a passive role 486 PE will simply reply to an incoming LDP PW setup message. The PW 487 switching point PE, will always remain passive until a PWID FEC 128 488 LDP message is received, which will cause the corresponding 489 generalized PW FEC LDP message to be formed and sent. If a 490 generalized FEC PW LDP message is received while the switching point 491 PE is in a passive role, the corresponding PW FEC 128 LDP message 492 will be formed and sent. 494 PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice 495 versa. This can be accomplished by local PW switching point 496 configuration, or by some other means, such as some form of auto 497 discovery. Such other means are outside the scope of this document. 499 7.4. LDP PW switching point TLV 501 The edge to edge PW might traverse several switching points, in 502 separate administrative domains. For management and troubleshooting 503 reasons it is useful to record information about the switching points 504 that the PW traverses. This is accomplished by using a PW switching 505 point TLV. 507 Note that sending the PW switching point TLV is OPTIONAL, however the 508 PE or S-PE MUST process the TLV upon reception. The PW switching 509 point TLV is appended to the PW FEC at each switching point. Each S- 510 PE can append a PW switching point TLV, and the order of the PW 511 switching point TLVs MUST be preserved. The S-PE TLV MUST be sent if 512 VCCV operation is required beyond the first MS-PW segment from a T- 513 PE. 515 The PW switching point TLV encoded as follows: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type | Length | Variable Length Value | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Variable Length Value | 525 | " | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 [note] LDP TLV type is pending IANA approval. 530 - PW sw TLV Length 532 Specifies the total length of all the following PW switching 533 point TLV fields in octets 535 - Type 537 Encodes how the Value field is to be interpreted. 539 - Length 541 Specifies the length of the Value field in octets. 543 - Value 545 Octet string of Length octets that encodes information to be 546 interpreted as specified by the Type field. 548 PW Switching point TLV Types are assigned by IANA according the the 549 process defined in the "IANA Allocations" section below. 551 The PW switching Point TLV is an OPTIONAL TLV that should appear only 552 once for each switching point traversed. If the S-PE TLV is not 553 present with the required sub-TLVs, VCCV operation will not function. 555 For local policy reasons, a particular S-PE can filter out all S-PE 556 TLVs in a label mapping message that traverses it and not include 557 it's own S-PE TLV. In this case, from any upstream PE, it will 558 appear as if this particular S-PE is the T-PE. This might be 559 necessary , depending on local policy if the S-PE is at the Service 560 provider administrative boundary. 562 7.4.1. PW Switching Point Sub-TLVs 564 Below are details specific to PW Switching Point Sub-TLVs described 565 in this document: 567 - PW ID of last PW segment traversed. This is only applicable if 568 the last PW segment traversed used LDP FEC 128 to signal the PW. 570 This sub-TLV type contains a PW ID in the format of the PWID 571 described in [RFC4447]. This is just a 32 bit unsigned integer 572 number. 574 - PW Switching Point description string. 576 An optional description string of text up to 80 characters long. 578 - Local IP address of PW Switching Point. 580 The Local IP V4 or V6 address of the PW Switching Point. This is 581 an OPTIONAL Sub-TLV. In most cases this will be the local LDP 582 session IP address of the S-PE. 584 - Remote IP address of the last PW Switching Point traversed or of 585 the T-PE 587 The IP V4 or V6 address of the last PW Switching Point traversed 588 or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this 589 will be the remote IP address of the LDP session. This Sub-TLV 590 SHOULD only be included if there are no other S-PE TLV present 591 from other S-PEs, or if the remote ip address of the LDP session 592 does not correspond to the "Local IP address of PW Switching 593 Point" TLV value contained in the last S-PE TLV. 595 - The FEC of last PW segment traversed. 597 This is only applicable if the last PW segment traversed used LDP 598 FEC 129 to signal the PW. 600 The Attachment Identifier of the last PW segment traversed. This 601 is coded in the following format: 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | AGI Type | Length | Value | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 ~ AGI Value (contd.) ~ 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | AII Type | Length | Value | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 ~ SAII Value (contd.) ~ 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | AII Type | Length | Value | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 ~ TAII Value (contd.) ~ 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 - L2 PW address of PW Switching Point (recommended format). 624 This sub-TLV type contains a L2 PW address of PW Switching Point in 625 the format described in [RFC5003]. This includes the AII type field , 626 and length, as well as the L2 PW address. 628 7.4.2. Adaptation of Interface Parameters 630 [RFC4447] defines several interface parameters, which are used by the 631 Network Service Processing (NSP) to adapt the PW to the Attachment 632 Circuit (AC). The interface parameters are only used at the end 633 points, and MUST be passed unchanged across the PW switching point. 634 However the following interface parameters MAY be modified as 635 follows: 637 - 0x03 Optional Interface Description string This Interface 638 parameter MAY be modified, or altogether removed from the FEC 639 element depending on local configuration policies. 641 - 0x09 Fragmentation indicator This parameter MAY be inserted in 642 the FEC by the switching point if it is capable of re-assembly of 643 fragmented PW frames according to [PWE3-FRAG]. 645 - 0x0C VCCV parameter This Parameter contains the CC type , and CV 646 type bit fields. The CV type bit field MUST be reset to reflect 647 the CV type supported by the S-PE. CC type bit field MUST have 648 bit 1 "Type 2: MPLS Router Alert Label " set to 0. The other bit 649 fields MUST be reset to reflect the CC type supported by the S- 650 PE. 652 7.5. Group ID 654 The Group ID (GR ID) is used to reduce the number of status messages 655 that need to be sent by the PE advertising the PW FEC. The GR ID has 656 local significance only, and therefore MUST be mapped to a unique GR 657 ID allocated by the PW switching point PE. 659 7.6. PW Loop Detection 661 A switching point PE SHOULD check the OPTIONAL PW switching Point 662 TLV, to verify if it's own IP address appears in it. If it's IP 663 address appears in a received PW switching Point TLV, the PE SHOULD 664 break the loop, and send a label release message with the following 665 error code: 666 Assignment E Description 667 0x0000003A 0 "PW Loop Detected" 669 [ note: error code pending IANA allocation ] 671 8. PW-MPLS to PW-L2TPv3 Control Plane Switching 673 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 674 four possibilities when switching between L2TPv3 and MPLS. 676 -i. Switching between MPLS and L2TPv3 static control planes. 677 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 678 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 679 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 681 8.1. Static MPLS and L2TPv3 PWs 683 In the case of two static control planes, the PW switching point MUST 684 be configured to direct packets from one PW into the other. There is 685 no control protocol involved in this case. The configuration MUST 686 include which MPLS VC Label maps to which L2TPv3 Session ID (and 687 associated Cookie, if present) as well as which MPLS Tunnel Label 688 maps to which PE destination IP address. 690 8.2. Static MPLS PW and Dynamic L2TPv3 PW 692 When a statically configured MPLS PW is switched to a dynamic L2TPv3 693 PW, the static control plane should be considered identical to an 694 attachment circuit (AC) in the reference model of Figure 1. The 695 switching point PE SHOULD signal the proper PW status if it detects a 696 failure in 698 sending or receiving packets over the static PW. Because the PW is 699 statically configured, the status communicated to the dynamic L2TPv3 700 PW will be limited to local interface failures. In this case, the PW 701 switching point PE behaves in a very similar manner to a T-PE, 702 assuming an active role. 704 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 706 When a statically configured L2TPv3 PW is switched to a dynamic 707 LDP/MPLS PW, then the static control plane should be considered 708 identical to an attachment circuit (AC) in the reference model of 709 Figure 1. The switching point PE SHOULD signal the proper PW status 710 (via an L2TPv3 SLI message) if it detects a failure in sending or 711 receiving packets over the static PW. Because the PW is statically 712 configured, the status communicated to the dynamic LDP/MPLS PW will 713 be limited to local interface failures. In this case, the PW 714 switching point PE behaves in a very similar manner to a T-PE, 715 assuming an active role. 717 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 719 When switching between dynamic PWs, the switching point always 720 assumes an initial passive role. Thus, it does not initiate an 721 LDP/MPLS or L2TPv3 PW until it has received a connection request 722 (Label Mapping or ICRQ) from one side of the node. Note that while 723 MPLS PWs are made up of two unidirectional LSPs bonded together by 724 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 725 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 726 Establishment, Tear Down, and PW Status signaling are detailed below. 728 8.4.1. Session Establishment 730 When the PW switching point receives an L2TPv3 ICRQ message, the 731 identifying AVPs included in the message are mapped to FEC 732 identifiers and sent in an LDP label mapping message. Conversely, if 733 an LDP Label Mapping message is received, it is either mapped to an 734 ICRP message or causes an L2TPv3 session to be initiated by sending 735 an ICRQ. 737 Following are two example exchanges of messages between LDP and 738 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 739 the second is a case where an MPLS T-PE initiates an MS-PW. 741 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 743 AC "Up" 744 L2TPv3 ICRQ ---> 745 LDP Label Mapping ---> 746 AC "UP" 747 <--- LDP Label Mapping 748 <--- L2TPv3 ICRP 749 L2TPv3 ICCN ---> 750 <-------------------- MH PW Established ------------------> 752 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 754 AC "Up" 755 LDP Label Mapping ---> 756 L2TPv3 ICRQ ---> 757 <--- L2TPv3 ICRP 758 <--- LDP Label Mapping 759 L2TPv3 ICCN ---> 760 AC "Up" 761 <-------------------- MH PW Established ------------------> 763 8.4.2. Adaptation of PW Status message 765 L2TPv3 uses the SLI message to indicate a interface status change 766 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 767 PWs either signal this via an LDP Label Withdraw or the PW Status 768 Notification message defined in section 4.4 of [RFC4447]. 770 8.4.3. Session Tear Down 772 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 773 message translates to a Label Withdraw message in LDP. Following are 774 two example exchanges of messages between LDP and L2TPv3. The first 775 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 776 the second is a case where an MPLS T-PE initiates the termination of 777 an MS-PW. 779 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 781 AC "Down" 782 L2TPv3 CDN ---> 783 LDP Label Withdraw ---> 784 AC "Down" 785 <-- LDP Label Release 787 <--------------- MH PW Data Path Down ------------------> 789 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 791 AC "Down" 792 LDP Label Withdraw ---> 793 L2TPv3 CDN --> 794 <-- LDP Label Release 795 AC "Down" 797 <---------------- MH PW Data Path Down ------------------> 799 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 801 [RFC4447] defines several interface parameters which MUST be mapped 802 to the equivalent AVPs in L2TPv3 setup messages. 804 * Interface MTU 806 The Interface MTU parameter is mapped directly to the L2TP 807 Interface MTU AVP defined in [RFC4667] 809 * Max Number of Concatenated ATM cells 811 This interface parameter is mapped directly to the L2TP "ATM 812 Maximum Concatenated Cells AVP" described in section 6 of 813 [RFC4454]. 815 * Optional Interface Description String 817 This string may be carried as the "Call-Information AVP" 818 described in section 2.2 of [L2TP-INFOMSG] 820 * PW Type 822 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 823 Type" AVP defined in [L2TPv3]. 825 * PW ID (FEC 128) 827 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 828 End ID" AVP defined in [L2TPv3]. 830 * Generalized FEC 129 SAI/TAI 832 Section 4.3 of [RFC4667] defines how to encode the SAI and TAI 833 parameters. These can be mapped directly. 835 Other interface parameter mappings will either be defined in a future 836 version of this document, or are unsupported when switching between 837 LDP/MPLS and L2TPv3 PWs. 839 8.6. Switching Point TLV in L2TPv3 841 When translating between LDP and L2TPv3 control messages, the PW 842 Switching Point TLV described earlier in this document is carried in 843 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 844 and optionally in the ICCN message. 846 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 847 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 848 the AVP is 6 plus the length of the series of Switching Point sub- 849 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 850 (the L2TP AVP M-bit MUST be 0). 852 8.7. L2TPv3 and MPLS PW Data Plane 854 When switching between an MPLS and L2TP PW, packets are sent in their 855 entirety from one PW to the other, replacing the MPLS label stack 856 with the L2TPv3 and IP header or vice versa. There are some 857 situations where an additional amount of interworking must be 858 provided between the two data planes at the PW switching node. 860 8.7.1. PWE3 Payload Convergence and Sequencing 862 Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim 863 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 864 For L2TPv3, the Payload Convergence and Sequencing function is 865 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 866 For MPLS, these two functions (together with PSN Convergence) are 867 carried out via the MPLS Control Word. Since these functions are 868 different between MPLS and L2TPv3, interworking between the two may 869 be necessary. 871 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 872 which in some cases are not necessary to be present at all. For 873 example, an Ethernet PW with sequencing disabled will generally not 874 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 875 be present at all. In this case, Ethernet frames are simply sent from 876 one PW to the other without any modification beyond the MPLS and 877 L2TP/IP encapsulation and decapsulation. 879 The following section offers guidelines for how to interwork between 880 L2TP and MPLS for those cases where the Payload Convergence, 881 Sequencing, or PSN Convergence functions are necessary on one or both 882 sides of the switching node. 884 8.7.2. Mapping 886 The MPLS Control Word consists of (from left to right): 888 -i. These bits are always zero in MPLS are not necessary to be 889 mapped to L2TP. 891 -ii. These six bits may be used for Payload Convergence depending 892 on the PW type. For ATM, the first four of these bits are 893 defined in [RFC4717]. These map directly to the bits defined 894 in [RFC4454]. For Frame Relay, these bits indicate how to 895 set the bits in the Frame Relay header which must be 896 regenerated for L2TP as it carries the Frame Relay header 897 intact. 899 -iii. L2TP determines its payload length from IP. Thus, this 900 Length field need not be carried directly to L2TP. This 901 Length field will have to be calculated and inserted for 902 MPLS when necessary. 904 -iv. The Default L2-Specific Sublayer has a sequence number with 905 different semantics than that of the MPLS Control Word. This 906 difference eliminates the possibility of supporting 907 sequencing across the MS-PW by simply carrying the sequence 908 number through the switching point transparently. As such, 909 sequence numbers MAY be supported by checking the sequence 910 numbers of packets arriving at the switching point and 911 regenerating a new sequence number in the proper format for 912 the PW on egress. If this type of sequence interworking at 913 the switching node is not supported, and a T-PE requests 914 sequencing of all packets via the L2TP control channel 915 during session setup, the switching node SHOULD NOT allow 916 the session to be established by sending a CDN message with 917 Result Code set to 17 "sequencing not supported" (subject to 918 IANA Assignment). 920 9. Operation And Management 922 9.1. Extensions to VCCV to Support Switched PWs 924 Single-hop pseudowires are signaled using the Virtual Circuit 925 Connectivity Verification (VCCV) parameter included in the interface 926 parameter field of the PW ID FEC TLV or the sub-TLV interface 927 parameter of the Generalized PW ID FEC TLV as described in [RFC5085]. 928 When a switching point exist between PE nodes, it is required to be 929 able to continue operating VCCV end-to-end across a switching point 930 and to provide the ability to trace the path of the MS-PW over any 931 number of segments. 933 This document provides a method for achieving these two objectives. 934 This method is based on re-using the existing VCCV CW and 935 decrementing the TTL of the PW label at each hop in the path of the 936 MS-PW. 938 9.2. PW-MPLS to PW-MPLS OAM Data Plane Indication 940 9.2.1. Decreasing the PW Label TTL 942 As stated above the S-PE MUST perform a standard MPLS label swap 943 operation on the MPLS PW label. By the rules defined in [RFC3032] the 944 PW label TTL MUST be decreased at every S-PE. Once the PW label TTL 945 reaches the value of 0, the packet is sent to the control plane to be 946 processed. Hence, by controlling the PW TTL value of the PW label it 947 is possible to select exactly which hop will respond to the VCCV 948 packet. 950 9.3. Signaling OAM Capabilities for Switched Pseudowires 952 Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV 953 parameter included in the interface parameter field of the PW ID FEC 954 TLV or the sub-TLV interface parameter of the Generalized PW ID FEC 955 TLV as described in [RFC5085]. 957 In Figure 3 T-PE1 uses the VCCV parameter included in the interface 958 parameter field of the PW ID FEC TLV or the sub-TLV interface 959 parameter of the Generalized PW ID FEC TLV to indicate to the far end 960 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 961 parameter as would be used if T-PE1 and T-PE2 were connected 962 directly. S-PE2, which is a PW switching point, as part of the 963 adaptation function for interface parameters, processes locally the 964 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 965 on the path between T-PE1 and T-PE2, each would carry out the same 966 processing, passing along the VCCV parameter. The local processing of 967 the VCCV parameter removes CC Types specified by the originating T-PE 968 that are not supported on the S-PE. For example, if T-PE1 indicates 969 supports CC Types 1,2,3 and the Then the S-PE removes the Router 970 Alert CC Type=2, leaving the rest of the TLV unchanged, and passes 971 the modified VCCV parameter to the next S-PE along the path. 973 The far end T-PE (T-PE2) receives the VCCV parameter indicating only 974 the CC types that are supported by the initial T-PE (T-PE1) and all 975 S-PEs along the PW path. 977 9.4. OAM Capability for MS-PWs Demultiplexed using MPLS 979 The VCCV parameter ID is defined as follows in [RFC4446]: 981 Parameter ID Length Description 982 0x0c 4 VCCV 984 The format of the VCCV parameter field is as follows: 986 0 1 2 3 987 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 0 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | 0x0c | 0x04 | CC Types | CV Types | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 0x01 Type 1: PWE3 control word with 0001b as first nibble 993 as defined in [RFC4385]. 994 0x02 Type 2: MPLS Router Alert Label. 995 0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3). 997 9.4.1. MS-PW and VCCV CC Type 1 999 VCCV CC type 1 is normally supported between T-PEs, and MAY be 1000 removed by an S-PE as a matter of local security policy. When using 1001 CC type 1 for MS-PWs the PE transmitting the VCCV packet MUST set the 1002 TTL to the appropriate value to reach the destination S-PE. However 1003 if the packet is destined for the T-PE, the TTL can be set to any 1004 value that is sufficient for the packet to reach the T-PE. 1006 9.4.2. MS-PW and VCCV CC type 2 1008 VCCV CC type 2 is not supported for MS-PWs and MUST be removed form a 1009 VCCV parameter field by the S-PE. 1011 9.4.3. MS-PW and VCCV CC type 3 1013 VCCV CC type 3 can be used for MS-PWs, however if the CW is enabled 1014 VCCV type 1 is preferred according to the rules in [RFC5085]. Note 1015 that for using the VCCV type 3, TTL method, the PE will set the PW 1016 label TTL to the appropriate value necessary to reach the target PE, 1017 otherwise the VCCV packet might be forwarded over the AC to the CPE. 1019 9.4.4. Detailed VCCV Procedures 1021 In order to test the end-to-end connectivity of the multi-segment PW, 1022 a S-PE must include the FEC used in the last segment to the 1023 destination T-PE. This information is either configured at the 1024 sending T-PE or is obtained by processing the corresponding sub-TLVs 1025 of the PW switching point TLV. The necessary S-PE sub-TLVs are : 1027 Type Description 1028 0x01 PW ID of last PW segment traversed 1029 0x03 Local IP address of PW Switching Point 1030 0x04 Remote IP address of last PW Switching Point traversed or 1031 of the T-PE 1033 9.4.4.1. End to End verification between T-PEs 1035 In Figure 3, if T-PE1, S-PE and T-PE2 support Control Word , the PW 1036 control plane will automatically negotiate the use of the CW. VCCV CC 1037 type 3 will function correctly whether the CW is enable or not on the 1038 PW. However VCCV type 1 for ( which can be use for end to end 1039 verification only), is only supported if the CW is enabled. 1041 At the S-PE the data path operations include an outer label pop, 1042 inner label swap and new outer label push. Note that there is no 1043 requirement for the S-PE to inspect the CW. Thus, the end-to-end 1044 connectivity of the multi-segment pseudowire can be verified by 1045 performing all of the following steps: 1047 -i. T-PE forms a VCCV-ping echo request message with the FEC 1048 matching that of the last segment PW to the destination T- 1049 PE. 1051 -ii. T-PE sets the inner PW label TTL to the exact value to allow 1052 the packet to reach the far end T-PE. ( the value is 1053 determined by counting the number of S-PEs from the control 1054 plane information ) Alternatively, if CC type 1 is supported 1055 the packet can be encapsulated according to CC type 1 in 1056 [RFC5085] 1058 -iii. T-PE sends a VCCV packet that will follow the exact same 1059 data path at each S-PE as that taken by data packets. 1061 -iv. S-PE may performs an outer label pop, if PHP is disabled, 1062 and will perform an inner label swap with TTL decrement, and 1063 new outer label push. 1065 -v. There is no requirement for the S-PE to inspect the CW. 1067 -vi. The VCCV packet is diverted to VCCV control processing at 1068 the destination T-PE. 1070 -vii. Destination T-PE replies using the specified reply mode, 1071 i.e., reverse PW path or IP path. 1073 9.4.4.2. Partial verification from T-PE 1075 In order to trace part of the multi-segment pseudowire, the TTL of 1076 the PW label may be used to force the VCCV message to 'pop out' at an 1077 intermediate node. When the TTL expires, the S-PE can determine that 1078 the packet is a VCCV packet by either checking the control word (CW) 1079 , or if the CW is not in use by checking for a valid IP header with 1080 UDP destination port 3503. The packet should then be diverted to 1081 VCCV processing. 1083 In Figure 2, if T-PE1 sends a VCCV message with the TTL of the PW 1084 label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus 1085 verify the first segment of the pseudowire. 1087 The VCCV packet is built according to [RFC4379] section 3.2.9 for FEC 1088 128, or 3.2.10 for a FEC 129 PW. All the information necessary to 1089 build the VCCV LSP ping packet is collected by inspecting the S-PE 1090 TLVs. 1092 Note that this use of the TTL is subject to the caution expressed in 1093 [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and 1094 a T-PE manipulates the PW label TTL, the VCCV message may not emerge 1095 from the MS-PW at the correct S-PE. 1097 9.4.4.3. Partial verification between S-PEs 1099 Assuming that all nodes along an MS-PW support the Control Word CC 1100 Type 3, VCCV between S-PEs may be accomplished using the PW label TTL 1101 as described above. In Figure 3, the S-PE may verify the path between 1102 it and T-PE2 by sending a VCCV message with the PW label TTL set to 1103 1. Given a more complex network with multiple S-PEs, an S-PE may 1104 verify the connectivity between it and an S-PE two segments away by 1105 sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE 1106 can diagnose connectivity problems by successively increasing the 1107 TTL. All the information needed to build the proper VCCV echo 1108 request packet as described in [RFC4379] section 3.2.9 or 3.2.10 is 1109 obtained automatically from the LDP label mapping that contains S-PE 1110 TLVs. 1112 9.4.5. Optional FEC Reply in VCCV LSP Ping packet 1114 When A S-PE along the PW path receives an VCCV LSP Ping echo request 1115 packet the following OPTIONAL procedure can be followed in addition 1116 to the procedure described below: 1118 -i. S-PE validates the echo request with the FEC. 1119 -ii. The S-PE build the standard LSP ping reply packet to be sent 1120 back. 1121 -iii. The S-PE appends the FEC128 information for the next segment 1122 along the MS-PW to the LSP PING reply packet. 1124 This FEC information can then be compared to the S-PE TLV information 1125 received from the control plane when the PW was first signalled. This 1126 FEC information MUST not be sent in the reply if the S-PE is not 1127 sending an S-PE TLV for administrative reasons in the same situation 1128 as explained previously. 1130 9.4.6. Processing of an VCCV Echo Message in a MS-PW 1132 The challenge for the control plane is to be able to build the VCCV 1133 echo request packet with the necessary information such as the target 1134 FEC 128 PW sub-TLV (FEC128) of the downstream PW segment which the 1135 packet is destined for. This could be even more difficult in 1136 situations in which the MS-PW spans different providers and 1137 Autonomous Systems. 1139 9.4.6.1. Sending a VCCV Echo Request 1141 When in the "ping" mode of operation, the sender of the echo request 1142 message requires the FEC of the last segment to the target S-PE/T-PE 1143 node. This information can either be configured manually or be 1144 obtained by inspecting the corresponding sub-TLVs of the PW switching 1145 point TLV. However, the PW switching point TLV is optional and there 1146 is no guarantee that all S-PE nodes will populate it with their 1147 system address, the PWid of the last PW segment traversed, and the 1148 last system address of of the last PE traversed by the label mapping 1149 message. If all information is not available, VCCV LSP ping mode will 1150 not function. 1152 9.4.6.2. Receiving an VCCV Echo Request 1154 Upon receiving a VCCV echo request the control plane on S-PEs (or the 1155 target node of each segment of the MS-PW) validates the request and 1156 responds to the request with an echo reply consisting of a return 1157 code of 8 (label switched at stack-depth ) indicating that it is an 1158 S-PE and not the egress router for the MS-PW. 1160 If the node is the T-PE or the egress node of the MS-PW, it responds 1161 to the echo request with an echo reply with a return code of 3 1162 (egress router). 1164 9.4.7. VCCV Trace Operations 1166 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1167 originating from T-PE1 by a single operational command. The following 1168 process ensues: 1169 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1170 containing the pseudowire information of the first segment 1171 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1172 Stack Validation is enabled, the request may also include 1173 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1174 dependent on the type of transport tunnel the segmented PW 1175 is riding on. 1177 -ii. S-PE validates the echo request with the FEC. Since it is a 1178 switching point between the first and second segment it 1179 builds an echo reply with a return code of 8 and sends the 1180 echo reply back to T-PE1. 1182 -iii. T-PE1 builds a second VCCV echo request based on the 1183 infomation obtained from the control plane (S-PE TLV). It 1184 then increments the TTL and sends it out to T-PE2. Note that 1185 the VCCV echo request packet is switched at the S-PE 1186 datapath and forwarded to the next downstream segment 1187 without any involvement from the control plane. 1189 -iv. T-PE2 receives and validates the echo request with the FEC. 1190 Since T-PE2 is the destination node or the egress node of 1191 the MS-PW it replies to T-PE1 with an echo reply with a 1192 return code of 3 (Egress Router). 1194 -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1195 aware that T-PE2 is the destination of the MS-PW because the 1196 echo reply has a return code of is 3. The trace process is 1197 completed. 1199 If no echo reply is received, or an error code is received from a 1200 particular PE, the trace process MUST stop immediately, and no 1201 packets MUST be sent further along the MS-PW. 1203 For more detail on the format of the VCCV echo packet, refer to 1204 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1205 (PW) label TTL. 1207 9.5. Mapping Switched Pseudowire Status 1209 In the PW switching with attachment circuits case (Figure 2), PW 1210 status messages indicating PW or attachment circuit faults SHOULD be 1211 mapped to fault indications or OAM messages on the connecting AC as 1212 defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an 1213 administrative boundary, then the manner in which those OAM messages 1214 are treated at the boundary is out of scope of this draft. 1216 In the PW control plane switching case (Figure 3), there is no 1217 attachment circuit at the PW switching point, but the two PWs are 1218 connected together. Similarly, the status of the PWs are forwarded 1219 unchanged from one PW to the other by the control plane switching 1220 function. However, it may sometimes be necessary to communicate 1221 status of one of the locally attached SS-PW at a PW switching point. 1223 For LDP this can be accomplished by sending an LDP notification 1224 message containing the PW status TLV, as well as an OPTIONAL PW 1225 switching point TLV as follows: 1227 0 1 2 3 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 |0| Notification (0x0001) | Message Length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Message ID | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 |0|1| Status (0x0300) | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 |0|1| Status Code=0x00000028 | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Message ID=0 | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Message Type=0 | PW Status TLV | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | PW Status TLV | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | PW Status TLV | PWId FEC | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | | 1247 | | 1248 | PWId FEC or Generalized ID FEC | 1249 | | 1250 | | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Type | Length | Variable Length Value | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 Only one PW switching point TLV can be present in this message. This 1258 message is then relayed by each PW switching point unchanged. The T- 1259 PE decodes the status message and the included PW switching point TLV 1260 to detect exactly where the fault occurred. At the T-PE if there is 1261 no PW switching point TLV included in the LDP status notification 1262 then the status message can be assumed to have originated at the 1263 remote T-PE. 1265 The merging of the received T-LDP status and the local status for the 1266 PW segments at an S-PE can be summarized as follows: 1268 -i. When the local status for both PW segments is UP, the S-PE 1269 passes any received AC or PW status bits unchanged, i.e., 1270 the status notification TLV is unchanged but the VCid in the 1271 case of a FEC 128 TLV is set to value of the PW segment to 1272 the next hop. 1274 -ii. When the local status for any of the PW segments is Down, 1275 the S-PE always sends "PW Down" status bits regardless if 1276 the received status bits from the remote node indicated "PW 1277 UP/Down". AC status bit are passed along unchanged. 1279 9.5.1. S-PE initiated PW status messages 1281 The PW fault directions are defined as follows: 1283 +-------+ 1284 ---PW1 forward---->| |-----PW2 reverse----> 1285 S-PE1 | S-PE2 | S-PE3 1286 <--PW1 reverse-----| |<----PW2 forward----- 1287 +-------+ 1289 When a local fault is detected by the S-PE, a PW status message is 1290 sent in both directions along the PW. Since there are no attachment 1291 circuits on an S-PE, only the following status messages are relevant: 1293 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1294 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1296 Each S-PE needs to store only two 32-bit PW status words for each 1297 SS-PW: One for local failures , and one for remote failures (normally 1298 received from another PE). The first failure will set the appropriate 1299 bit in the 32-bit status word, and each subsequent failure will be 1300 ORed to the appropriate PW status word. In the case of the PW status 1301 word storing remote failures, this rule has the effect of a logical 1302 OR operation with the first failure received on the particular SS-PW. 1304 It should be noted that remote failures received on an S-PE are just 1305 passed along the MS-PW unchanged while local failures detected an an 1306 S-PE are signalled on both SS-PWs. 1308 A T-PE can receive multiple failures from S-PEs along the MH-PW, 1309 however only the failure from the remote closest S-PE will be stored 1310 (last pw status message received). The PW status word received are 1311 just ORed to any existing remote PW status already stored on the T- 1312 PE. 1314 Given that there are two SS-PW at a particular S-PE for a particular 1315 MH-PW, there are for possible failure cases as follows: 1317 -i. PW2 reverse direction fault 1318 -ii. PW1 reverse direction fault 1319 -iii. PW2 forward direction fault 1320 -iv. PW1 forward direction fault 1322 It should also be noted that once a PW status notification message is 1323 initiated at a PW switching point for a particular PW status bit any 1324 further status message, for the same status bit, received from an 1325 upstream neighbor is processed locally and not forwarded until the PW 1326 switching point original status error state is cleared. 1328 Each S-PE along the MS-PW MUST store any PW status messages 1329 transiting it. If more then one status message with the same PW 1330 status bit set is received by a T-PE only the last PW status message 1331 is stored. 1333 9.5.1.1. Local PW2 reverse direction fault 1335 When this failure occurs the S-PE will take the following actions: 1337 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1338 PSN-facing PW (egress) Transmit Fault" 1339 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1340 PSN-facing PW (ingress) Receive Fault" 1341 * Store 0x00000010 in the local PW status word for the SS-PW toward 1342 S-PE3. 1344 9.5.1.2. Local PW1 reverse direction fault 1346 When this failure occurs the S-PE will take the following actions: 1348 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1349 PSN-facing PW (egress) Transmit Fault" 1350 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1351 PSN-facing PW (ingress) Receive Fault" 1352 * Store 0x00000010 in the local PW status word for the SS-PW toward 1353 S-PE1. 1355 9.5.1.3. Local PW2 forward direction fault 1357 When this failure occurs the S-PE will take the following actions: 1358 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1359 PSN-facing PW (ingress) Receive Fault" 1360 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1361 PSN-facing PW (egress) Transmit Fault" 1362 * Store 0x00000008 in the local PW status word for the SS-PW toward 1363 S-PE3. 1365 9.5.1.4. Local PW1 forward direction fault 1367 When this failure occurs the S-PE will take the following actions: 1368 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1369 PSN-facing PW (ingress) Receive Fault" 1370 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1371 PSN-facing PW (egress) Transmit Fault" 1372 * Store 0x00000008 in the local PW status word for the SS-PW toward 1373 S-PE1. 1375 9.5.1.5. Clearing Faults 1377 Remote PW status fault clearing messages received by an S-PE will 1378 only be forwarded if there are no corresponding local faults on the 1379 S-PE. (local faults always supersede remote faults) 1381 Once the local fault has cleared, and there is no corresponding ( 1382 same PW status bit set ) remote fault, a PW status messages is sent 1383 out to the adjacent PEs clearing the fault. 1385 When a PW status fault clearing message is forwarded, the S-PE will 1386 always send the S-PE TLV associated with the PE which cleared the 1387 fault. 1389 9.5.2. PW status messages and S-PE TLV processing 1391 When a PW status message is received that includes a S-PE TLV, the 1392 S-PE TLV information MAY be stored, along with the contents of the PW 1393 status Word according to the procedures described above. The S-PE TLV 1394 stored is always the S-PE TLV that is associated with the PE that set 1395 that particular last fault. If subsequent PW status message for the 1396 same PW status bit are received the S-PE TLV will overwrite the 1397 previously stored S-PE TLV. 1399 9.5.3. T-PE processing of PW status messages 1401 The PW switching architecture is based on the concept that the T-PE 1402 should process the PW LDP messages in the same manner as if it was 1403 participating in the setup of a SS-PW. However T-PE participating a 1404 MS-PW, SHOULD be able to process the PW switching point TLV. 1405 Otherwise the processing of PW status messages , and other PW setup 1406 messages is exactly as described in [RFC4447]. 1408 9.6. Pseudowire Status Negotiation Procedures 1410 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1411 be transparent to the switching point. 1413 9.7. Status Dampening 1415 When the PW control plane switching methodology is used to cross an 1416 administrative boundary it might be necessary to prevent excessive 1417 status signaling changes from being propagated across the 1418 administrative boundary. This can be achieved by using a similar 1419 method as commonly employed for the BGP protocol route advertisement 1420 dampening. The details of this OPTIONAL algorithm are a matter of 1421 implementation, and are outside the scope of this document. 1423 10. Peering Between Autonomous Systems 1425 The procedures outlined in this document can be employed to provision 1426 and manage MS-PWs crossing AS boundaries. 1428 The use of more advanced mechanisms involving auto-discovery and 1429 ordered PWE3 MS-PW signaling will be covered in a separate document. 1431 11. Security Considerations 1433 This document specifies the LDP and L2TPv3 extensions that are needed 1434 for setting up and maintaining pseudowires. The purpose of setting up 1435 pseudowires is to enable layer 2 frames to be encapsulated and 1436 transmitted from one end of a pseudowire to the other. Therefore we 1437 treat the security considerations for both the data plane and the 1438 control plane. 1440 11.1. Data Plane Security 1442 Data plane security consideration as discussed in [RFC4447], 1443 [L2TPv3], and [PWE3-ARCH] apply to this extension without any 1444 changes. 1446 11.1.1. VCCV Security considerations 1448 The VCCV technology for MS-PW offers a method for the service 1449 provider to verify the data path of a specific PW. This involves 1450 sending a packet to a specific PE and receiving an answer which 1451 either confirms , or indicates that the information contained in the 1452 packet is incorrect. This is a very similar process to the commonly 1453 used IP ICMP ping , and TTL expired methods for IP networks. It 1454 should be noted that when using VCCV Type 3 for PW when the CW is not 1455 enabled, if a packet is crafted with a TTL greater then the number of 1456 hops along the MS-PW path, or an S-PE along the path mis-processes 1457 the TTL, the packet could mistakenly be forwarded out the attachment 1458 circuit as a native PW packet. This packet would most likely be 1459 treated as an error packet by the CE. However if this possibility is 1460 not acceptable, the CW should be enabled to guarantee that a VCCV 1461 packet will never be mistakenly forwarded to the AC. 1463 11.2. Control Protocol Security 1465 General security considerations with regard to the use of LDP are 1466 specified in section 5 of RFC 3036. Security considerations with 1467 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1468 considerations apply as well to the case where LDP or L2TPv3 is used 1469 to set up PWs. 1471 A Pseudowire connects two attachment circuits. It is important to 1472 make sure that LDP connections are not arbitrarily accepted from 1473 anywhere, or else a local attachment circuit might get connected to 1474 an arbitrary remote attachment circuit. Therefore an incoming session 1475 request MUST NOT be accepted unless its IP source address is known to 1476 be the source of an "eligible" peer. The set of eligible peers could 1477 be pre-configured (either as a list of IP addresses, or as a list of 1478 address/mask combinations), or it could be discovered dynamically via 1479 an auto-discovery protocol which is itself trusted. (Obviously if the 1480 auto-discovery protocol were not trusted, the set of "eligible peers" 1481 it produces could not be trusted.) 1483 Even if a connection request appears to come from an eligible peer, 1484 its source address may have been spoofed. So some means of 1485 preventing source address spoofing must be in place. For example, if 1486 all the eligible peers are in the same network, source address 1487 filtering at the border routers of that network could eliminate the 1488 possibility of source address spoofing. 1490 For a greater degree of security, the LDP MD5 authentication key 1491 option, as described in section 2.9 of RFC 3036, or the Control 1492 Message Authentication option of [L2TPv3] MAY be used. This provides 1493 integrity and authentication for the control messages, and eliminates 1494 the possibility of source address spoofing. Use of the message 1495 authentication option does not provide privacy, but privacy of 1496 control messages are not usually considered to be highly urgent. 1497 Both the LDP and L2TPv3 message authentication options rely on the 1498 configuration of pre-shared keys, making it difficult to deploy when 1499 the set of eligible neighbors is determined by an auto-configuration 1500 protocol. 1502 When the Generalized ID FEC Element is used, it is possible that a 1503 particular peer may be one of the eligible peers, but may not be the 1504 right one to connect to the particular attachment circuit identified 1505 by the particular instance of the Generalized ID FEC element. 1506 However, given that the peer is known to be one of the eligible peers 1507 (as discussed above), this would be the result of a configuration 1508 error, rather than a security problem. Nevertheless, it may be 1509 advisable for a PE to associate each of its local attachment circuits 1510 with a set of eligible peers, rather than having just a single set of 1511 eligible peers associated with the PE as a whole. 1513 12. IANA Considerations 1515 12.1. L2TPv3 AVP 1517 This document uses a ne L2TP parameter, IANA already maintains a 1518 registry of name "Control Message Attribute Value Pair" defined by 1519 [RFC3438]. The following new values are required: 1521 TBA-L2TP-AVP-1 - PW Switching Point AVP 1523 12.2. LDP TLV TYPE 1525 This document uses several new LDP TLV types, IANA already maintains 1526 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1527 following value is suggested for assignment: 1529 TLV type Description 1530 0x096D Pseudowire Switching TLV 1532 12.3. LDP Status Codes 1534 This document uses several new LDP status codes, IANA already 1535 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1536 RFC3036. The following value is suggested for assignment: 1538 Assignment E Description 1539 0x0000003A 0 "PW Loop Detected" 1541 12.4. L2TPv3 Result Codes 1543 This document uses several new L2TPv3 status codes, IANA already 1544 maintains a registry of name "L2TPv3 Result Codes" defined by 1545 RFCxxxx. The following value is suggested for assignment: 1547 Assignment Description 1548 17 "sequencing not supported" 1550 12.5. New IANA Registries 1552 IANA needs to set up a registry of "PW Switching Point TLV Type". 1553 These are 8-bit values. Types value 1 through 3 are defined in this 1554 document. Type values 4 through 64 are to be assigned by IANA using 1555 the "Expert Review" policy defined in RFC2434. Type values 65 through 1556 127, 0 and 255 are to be allocated using the IETF consensus policy 1557 defined in [RFC2434]. Types values 128 through 254 are reserved for 1558 vendor proprietary extensions and are to be assigned by IANA, using 1559 the "First Come First Served" policy defined in RFC2434. 1561 The Type Values are assigned as follows: 1562 Type Length Description 1564 0x01 4 PW ID of last PW segment traversed 1565 0x02 variable PW Switching Point description string 1566 0x03 4/16 Local IP address of PW Switching Point 1567 0x04 4/16 Remote IP address of last PW Switching Point traversed 1568 or of the T-PE 1569 0x05 variable AI of last PW segment traversed 1570 0x06 10 L2 PW address of PW Switching Point 1572 13. Intellectual Property Statement 1574 The IETF takes no position regarding the validity or scope of any 1575 Intellectual Property Rights or other rights that might be claimed to 1576 pertain to the implementation or use of the technology described in 1577 this document or the extent to which any license under such rights 1578 might or might not be available; nor does it represent that it has 1579 made any independent effort to identify any such rights. Information 1580 on the procedures with respect to rights in RFC documents can be 1581 found in BCP 78 and BCP 79. 1583 Copies of IPR disclosures made to the IETF Secretariat and any 1584 assurances of licenses to be made available, or the result of an 1585 attempt made to obtain a general license or permission for the use of 1586 such proprietary rights by implementers or users of this 1587 specification can be obtained from the IETF on-line IPR repository at 1588 http://www.ietf.org/ipr. 1590 The IETF invites any interested party to bring to its attention any 1591 copyrights, patents or patent applications, or other proprietary 1592 rights that may cover technology that may be required to implement 1593 this standard. Please address the information to the IETF at ietf- 1594 ipr@ietf.org. 1596 14. Full Copyright Statement 1598 Copyright (C) The IETF Trust (2008). 1600 This document is subject to the rights, licenses and restrictions 1601 contained in BCP 78, and except as set forth therein, the authors 1602 retain all their rights. 1604 This document and the information contained herein are provided on an 1605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1607 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1608 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1609 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1612 15. Acknowledgments 1614 The authors wish to acknowledge the contributions of Satoru 1615 Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, 1616 and Tiberiu Grigoriu. 1618 16. Normative References 1620 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1621 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1622 RFC4385, February 2006. 1624 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1625 mulation (PWE3)", L. Martini, RFC4446, April 2006. 1627 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 1628 et al., rfc4447 April 2006. 1630 [RFC3985] Stewart Bryant, et al., PWE3 Architecture, 1631 RFC3985 1633 [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. 1634 draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ), 1635 October 2004. 1637 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1638 M. Townsley, I. Goyret, RFC3931 1640 [RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1641 Verification (VCCV), A Control Channel for Pseudowires", 1642 RFC5085 December 2007. 1644 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1645 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1646 1998. 1648 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1649 Requirement Levels", BCP 14, RFC 2119, March 1997. 1651 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 1652 Individual Identifier (AII) Types for Aggregati", RFC5003, 1653 September 2007. 1655 17. Informative References 1657 [RFC4023] "Encapsulating MPLS in IP or Generic 1658 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1659 RFC4023, March 2005. 1661 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., 1662 draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003. 1664 [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, 1665 W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt 1666 ( work in progress ) February 2004 1668 [RFC4667] "Layer 2 Virtual Private Network (L2VPN) 1669 Extensions for Layer 2 Tunneling Protocol (L2TP)", Luo, Wei, 1670 RFC4667, W. Luo, September 2006 1672 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1673 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1674 ( work in progress ), July 2004 1676 [RFC4454] "Asynchronous Transfer Mode (ATM) over Layer 2 1677 Tunneling Protocol Version 3 (L2TPv3)", Singh, Townsley, 1678 Pignataro, RFC4454, May 2006 1679 ( work in progress ), March 2004. 1681 [RFC4717] "Encapsulation Methods for Transport of (ATM) 1682 MPLS Networks", Martini et al., RFC4717, December 2006 1684 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1685 (L2TP) Internet" 1687 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1688 draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ), 1689 February 2005 1691 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data 1692 Plane Failures", RFC4379, February 2006. 1694 [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001 1696 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire Emulation 1697 Edge-to-Edge", Bocci et al, draft-ietf-pwe3-ms-pw-arch-03.txt 1698 June 2007 1700 18. Author Information 1702 Luca Martini 1703 Cisco Systems, Inc. 1704 9155 East Nichols Avenue, Suite 400 1705 Englewood, CO, 80112 1706 e-mail: lmartini@cisco.com 1708 Thomas D. Nadeau 1709 BT 1710 BT Centre 1711 81 Newgate Street 1712 London, EC1A 7AJ 1713 United Kingdom 1714 e-mail: tom.nadeau@bt.com 1716 Chris Metz 1717 Cisco Systems, Inc. 1718 e-mail: chmetz@cisco.com 1720 Mike Duckett 1721 Bellsouth 1722 Lindbergh Center 1723 D481 1724 575 Morosgo Dr 1725 Atlanta, GA 30324 1726 e-mail: mduckett@bellsouth.net 1728 Matthew Bocci 1729 Alcatel-Lucent 1730 Grove House, Waltham Road Rd 1731 White Waltham, Berks, UK. SL6 3TN 1732 e-mail: matthew.bocci@alcatel-lucent.co.uk 1734 Florin Balus 1735 Alcatel-Lucent 1736 701 East Middlefield Rd. 1737 Mountain View, CA 94043 1738 e-mail: florin.balus@alcatel-lucent.com 1739 Mustapha Aissaoui 1740 Alcatel-Lucent 1741 600, March Road, 1742 Kanata, ON, Canada 1743 e-mail: mustapha.aissaoui@alcatel-lucent.com