idnits 2.17.1 draft-ietf-pwe3-segmented-pw-07.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 1598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1582. 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 -- 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 (February 2008) is 5915 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 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-00 -- 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 (-04) exists of draft-ietf-l2tpext-pwe3-atm-00 == 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) 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: August 2008 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 February 2008 14 Segmented Pseudo Wire 16 draft-ietf-pwe3-segmented-pw-07.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 pseudo wires (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 ........... 11 58 7.1 Static Control plane switching ....................... 11 59 7.2 Two LDP control planes using the same FEC type ....... 12 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 ........................... 16 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 ................................ 17 73 8.4.2 Adaptation of PW Status message ...................... 18 74 8.4.3 Session Tear Down .................................... 18 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 .............. 20 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 Pseudo Wires . 23 85 9.3.1 OAM Capability for MH PWs Demultiplexed using MPLS ... 23 86 9.4 Detailed MH-VCCV Procedures .......................... 24 87 9.4.1 PW Label TTL ......................................... 24 88 9.4.2 Partial tracing from T-PE ............................ 25 89 9.4.3 Partial Tracing between S-PEs ........................ 25 90 9.4.4 Automated VCCV Trace from T-PE ....................... 26 91 9.5 Processing of an VCCV Echo Message in a MS-PW ........ 26 92 9.5.1 Sending a VCCV Echo Request .......................... 26 93 9.5.2 Receiving an VCCV Echo Request ....................... 27 94 9.5.3 Receiving an VCCV Echo Reply ......................... 27 95 9.6 VCCV Trace Operations ................................ 27 96 9.7 Tracing Switched PW Switch Points Using MH-VCCV ...... 28 97 9.8 Mapping Switched Pseudo Wire Status .................. 29 98 9.8.1 S-PE initiated PW status messages .................... 31 99 9.8.1.1 Local PW2 reverse direction fault .................... 32 100 9.8.1.2 Local PW1 reverse direction fault .................... 32 101 9.8.1.3 Local PW2 forward direction fault .................... 32 102 9.8.1.4 Local PW1 forward direction fault .................... 33 103 9.8.1.5 Clearing Faults ...................................... 33 104 9.8.2 PW status messages and S-PE TLV processing ........... 33 105 9.8.3 T-PE processing of PW status messages ................ 33 106 9.9 Pseudowire Status Negotiation Procedures ............. 34 107 9.10 Status Dampening ..................................... 34 108 10 Peering Between Autonomous Systems ................... 34 109 11 Security Considerations .............................. 34 110 11.1 Data Plane Security .................................. 34 111 11.2 Control Protocol Security ............................ 35 112 12 IANA Considerations .................................. 36 113 12.1 Channel Type ......................................... 36 114 12.2 L2TPv3 AVP ........................................... 36 115 12.3 LDP TLV TYPE ......................................... 36 116 12.4 LDP Status Codes ..................................... 36 117 12.5 L2TPv3 Result Codes .................................. 37 118 12.6 New IANA Registries .................................. 37 119 13 Intellectual Property Statement ...................... 37 120 14 Full Copyright Statement ............................. 38 121 15 Acknowledgments ...................................... 38 122 16 Normative References ................................. 38 123 17 Informative References ............................... 39 124 18 Author Information ................................... 40 126 1. Specification of Requirements 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Terminology 134 - PW Terminating Provider Edge (T-PE). A PE where the customer- 135 facing attachment circuits (ACs) are bound to a PW forwarder. A 136 Terminating PE is present in the first and last segments of a 137 MS-PW. This incorporates the functionality of a PE as defined in 138 [RFC3985]. 140 - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 141 two T-PE devices. Each PW in one direction of a SS-PW traverses 142 one PSN tunnel that connects the two T-PEs. 144 - Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 145 configured set of two or more contiguous PW segments that behave 146 and function as a single point-to-point PW. Each end of a MS-PW 147 by definition MUST terminate on a T-PE. 149 - PW Segment. A part of a single-segment or multi-segment PW, which 150 is set up between two PE devices, T-PEs and/or S-PEs. 152 - PW Switching Provider Edge (S-PE). A PE capable of switching the 153 control and data planes of the preceding and succeeding PW 154 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 155 preceding and succeeding segments of the MS-PW. It is therefore a 157 - PW switching point for a MS-PW. A PW Switching Point is never the 158 S-PE and the T-PE for the same MS-PW. A PW switching point runs 159 necessary protocols to setup and manage PW segments with other PW 160 switching points and terminating PEs. 162 3. Introduction 164 PWE3 defines the signaling and encapsulation techniques for 165 establishing SS-PWs between a pair of ultimate PEs and in the vast 166 majority of cases this will be sufficient. MS-PWs come into play in 167 two general cases: 169 -i. When it is not possible, desirable or feasible to establish 170 a PW control channel between the ultimate source and 171 destination PEs. At a minimum PW control channel 172 establishment requires knowledge of and reachability to the 173 remote (ultimate) PE IP address. The local (ultimate) PE may 174 not have access to this information related to topology, 175 operational or security constraints. 177 An example is the inter-AS L2VPN scenario where the ultimate 178 PEs reside in different provider networks (ASes) and it is 179 the practice to MD5-key all control traffic exchanged 180 between two networks. Technically a SS-PW could be used but 181 this would require MD5-keying on ALL ultimate source and 182 destination PE nodes. An MS-PW allows the providers to 183 confine MD5 key administration to just the PW switching 184 points connecting the two domains. 186 A second example might involve a single AS where the PW 187 setup path between the ultimate PEs is computed by an 188 external entity (i.e. client-layer routing protocol). Assume 189 a full mesh of PWE3 control channels established between 190 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 191 through a PW is required between ultimate PE-A and PE-C. The 192 external entity computes a PW setup path that passes through 193 PE-B. This results in two discrete PW segments being built: 194 one between PE-A and PE-B and one between PE-B and PE-C. The 195 successful client-layer L2 connection between ultimate PE-A 196 and ultimate PE-C requires that PE-B performs the PWE3 197 switching process. 199 A third example involves the use of PWs in hierarchical 200 IP/MPLS networks. Access networks connected to a backbone 201 use PWs to transport customer payloads between customer 202 sites serviced by the same access network and up to the edge 203 of the backbone where they can be terminated or switched 204 onto a succeeding PW segment crossing the backbone. The use 205 of PWE3 switching between the access and backbone networks 206 can potentially reduce the PWE3 control channels and routing 207 information processed by the access network T-PEs. 209 It should be noted that PWE3 switching does not help in any 210 way to reduce the amount of PW state supported by each 211 access network T-PE. 213 -ii. PWE3 signaling and encapsulation protocols are different. 214 The ultimate PEs are connected to networks employing 215 different PW signaling and encapsulation protocols. In this 216 case it is not possible to use a SS-PW. A MS-PW with the 217 appropriate interworking performed at the PW switching 218 points can enable PW connectivity between the ultimate PEs 219 in this scenario. 221 There are four different signaling protocols that are defined to 222 signal PWs: 224 -i. Static configuration of the PW (MPLS or L2TPv3). 225 -ii. LDP using FEC 128 226 -iii. LDP using the generalized FEC 129 227 -iv. L2TPv3 229 4. General Description 231 A pseudo-wire (PW) is a tunnel established between two provider edge 232 (PE) nodes to transport L2 PDUs across a packet switched network 233 (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are 234 looking at PWs as a means of migrating existing (or building new) 235 L2VPN services (i.e. Frame-Relay, ATM, Ethernet) on top of a PSN by 236 using PWs. PWs may span multiple autonomous systems of the same or 237 different provider networks. In these scenarios PW control channels 238 (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries. 240 Inter-AS L2VPN functionality is currently supported and several 241 techniques employing MPLS encapsulation and LDP signaling have been 242 documented [2547BIS]. It is also straightforward to support the same 243 inter-AS L2VPN functionality employing L2TPv3. In this document we 244 define methodology to switch a PW between two PW control planes. 246 |<-------------- Emulated Service ---------------->| 247 | | 248 | |<------- Pseudo Wire ------>| | 249 | | | | 250 | | |<-- PSN Tunnel -->| | | 251 | V V V V | 252 V AC +----+ +----+ AC V 253 +-----+ | | PE1|==================| PE2| | +-----+ 254 | |----------|............PW1.............|----------| | 255 | CE1 | | | | | | | | CE2 | 256 | |----------|............PW2.............|----------| | 257 +-----+ ^ | | |==================| | | ^ +-----+ 258 ^ | +----+ +----+ | | ^ 259 | | Provider Edge 1 Provider Edge 2 | | 260 | | | | 261 Customer | | Customer 262 Edge 1 | | Edge 2 263 | | 264 native service native service 266 Figure 1: PWE3 Reference Model 268 There are two methods for switching a PW between two PW control 269 planes. In the first method (Figure 2), the two control planes 270 terminate on different PEs. 272 |<------------Emulated Service---------->| 273 | PSN PSN | 274 AC | |<-1->| |<-2->| | AC 275 | V V V V V V | 276 | +----+ +-----+ +----+ +----+ | 277 +----+ | | |=====| | | |=====| | | +----+ 278 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 279 | CE1| | | | | | | | | | | |CE2 | 280 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 281 +----+ | | |=====| | | |=====| | | +----+ 282 ^ +----+ +-----+ +----+ +----+ ^ 283 | PE1 PE2 PE3 PE4 | 284 | ^ ^ | 285 | | | | 286 | PW stitching points | 287 | | 288 | | 289 |<-------------------- Emulated Service ---------------->| 291 Figure 2: PW Switching using ACs Reference Model 293 In Figure 2, pseudo wires in two separate PSNs are stitched together 294 using native service attachment circuits. PE2 and PE3 only run the 295 control plane for the PSN to which they are directly attached. At PE2 296 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 297 while PW3 and PW4 are connected using attachment circuit AC2. 299 Native |<-----------Pseudo Wire----------->| Native 300 Layer2 | | Layer2 301 Service | |<-PSN1-->| |<--PSN2->| | Service 302 (AC) V V V V V V (AC) 303 | +----+ +-----+ +----+ | 304 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 305 | |----------|........PW1.........|...PW3........|----------| | 306 | CE1| | | | | | | | | |CE2 | 307 | |----------|........PW2.........|...PW4........|----------| | 308 +----+ | | |=========| |=========| | | +----+ 309 ^ +----+ +-----+ +----+ | ^ 310 | Provider Edge 1 ^ Provider Edge 3 | 311 | (Terminating PE) | (Terminating PE) | 312 | | | 313 | PW switching point | 314 | (Optional PW adaptation function) | 315 | | 316 |<------------------- Emulated Service ------------------>| 317 Figure 3: PW Control Plane Switching Reference Model 319 In Figure 3 PE2 runs two separate control planes: one toward PE1, and 320 one Toward PE3. The PW switching point is at PE2 which is configured 321 to connect PW1 and PW3 together to complete the multi-hop PW between 322 PE1 and PE3. PW1 and PW3 MUST be of the same PW type, but PSN1 and 323 PSN2 need not be the same technology. In the latter case, if the PW 324 is switched to a different technology, the PEs must adapt the PDU 325 encapsulation between the different PSN technologies. In the case 326 where PSN1 and PSN2 are the same technology the PW PDU does not need 327 to be modified, and PDUs are then switched between the pseudo-wires 328 at the PW label level. 330 It should be noted that it is possible to adapt one PSN technology to 331 a different one, for example MPLS over an IP or GRE [RFC4023] 332 encapsulation, but this is outside the scope of this document. 333 Further, one could perform an interworking function on the PWs 334 themselves at the PW switching point, allowing conversion from one PW 335 type to another, but this is also outside the scope of this document. 337 This document describes procedures for building multi-segment 338 pseudowires using manual configuration of the switching point PE2. 339 Other documents may build on this base specification to automate the 340 configuration and selection of PE2. It should also be noted that a PW 341 can traverse multiple PW switching points along it's path, and the 342 edge PEs will not require any specific knowledge of how many PW 343 switching points the PW has traversed (though this may be reported 344 for troubleshooting purposes). 346 In general the approach taken is to connect the individual control 347 planes by passing along any signaling information immediately upon 348 reception. First the PW switching point is configured to switch a 349 SS-PW from a specific peer to another SS-PW destined for a different 350 peer. No control messages are exchanged yet as the PW switching point 351 PE does not have enough information to actually initiate the PW setup 352 messages. However, if a session does not already exist, a control 353 protocol (LDP/L2TP) session is setup. In this model the MS-PW setup 354 is starting from the T-PE devices. Next once the T-PE is configured 355 it sends the PW control setup messages. These messages are received, 356 and immediately used to form the PW setup messages for the next SS-PW 357 of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label 358 Mapping message then a Label Release message is sent back to the 359 originator T-PE. A MS-PW is declared UP when all the constituent SS- 360 PWs are UP. 362 5. PW Switching and Attachment Circuit Type 364 The PWs in each PSN are established independently, with each PSN 365 being treated as a separate PWE3 domain. For example, in Figure 2 for 366 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 367 targeted session as described in [RFC4447], and at the same time a 368 separate pseudo wire, PW2, is setup between PE3 and PE4. The ACs for 369 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 370 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 372 6. Applicability 374 When using a PSN to transport a PW, the performance of the PW is 375 equal to the performance of the PSN plus any impairments introduced 376 by the PW layer itself. Therefore it is not possible for the PW to 377 provide better performance than the PSN over which it is transported. 379 Therefore, it is necessary to carefully consider the order in which 380 different layer networks are stacked upon each other within a 381 'network stack' in order to provide the topmost service with the 382 performance that it requires. This performance inheritance within a 383 PW/PSN relationship is vertical because the PW is vertically stacked 384 upon its PSN. 386 Note: Due to this vertical performance inheritance and the different 387 performance provided by, and the characteristics of, each networking 388 mode it is generally advisable to stack modes that less efficiently 389 provide dedicated bandwidth/performance on top of modes that more 390 efficiently provide dedicated bandwidth/performance. 392 When performing peer partition interworking the PW inherits the 393 performance of the PSN partition that provides the worst performance 394 of all the peered PSN partitions over which the PW is transported. 395 Therefore it is not possible for the PW to receive (or provide) 396 better performance than the worst performing of the peered PSN 397 partitions over which it is transported. 399 Therefore, it is necessary to carefully consider which PSN modes 400 (and/or technologies) it is appropriate to peer with one another in 401 order to provide the service with the performance that it requires. 402 This is a horizontal performance relationship because the server 403 layer partitions are peered with each other horizontally. 405 7. PW-MPLS to PW-MPLS Control Plane Switching 407 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 408 session as described in [RFC4447], at the same time a separate pseudo 409 wire PW3 is setup to PE3. Each PW is configured independently on the 410 PEs, but on PE2 pseudo wire PW1 is connected to pseudo wire PW3. PDUs 411 are then switched between the pseudo-wires at the PW label level. 412 Hence the data plane does not need any special knowledge of the 413 specific pseudo wire type. A simple standard MPLS label swap 414 operation is sufficient to connect the two PWs, and in this case the 415 PW adaptation function is not used. 417 This process can be repeated as many times as necessary, the only 418 limitation to the number of PW switching points traversed is imposed 419 by the TTL field of the PW MPLS Label. The setting of the TTL is a 420 matter of local policy on the originating PE, but SHOULD be set to 421 255. 423 There are three MPLS to MPLS PW control planes: 424 -i. Static configuration of the PW. 425 -ii. LDP using FEC 128 426 -iii. LDP using the generalized FEC 129 427 This results in four distinct PW switching situations that are 428 significantly different, and must be considered in detail: 429 -i. PW Switching between two static control planes. 430 -ii. Static Control plane switching to LDP dynamic control plane. 431 -iii. Two LDP control planes using the same FEC type 432 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 434 7.1. Static Control plane switching 436 In the case of two static control planes the PW switching point MUST 437 be configured to direct the MPLS packets from one PW into the other. 438 There is no control protocol involved in this case. When one of the 439 control planes is a simple static PW configuration and the other 440 control plane is a dynamic LDP FEC 128 or generalized PW FEC, then 441 the static control plane should be considered identical to an 442 attachment circuit (AC) in the reference model of Figure 1. The 443 switching point PE SHOULD signal the proper PW status if it detects a 444 failure in sending or receiving packets over the static PW. Because 445 the PW is statically configured, the status communicated to the 446 dynamic LDP PW will be limited to local interface failures. In this 447 case, the PW switching point PE behaves in a very similar manner to a 448 T-PE, assuming an active role. This means that the S-PE will 449 immediately send the LDP Label Mapping message if the static PW is 450 deemed to be UP. 452 7.2. Two LDP control planes using the same FEC type 454 As stated in a section above, the PW switching point PE should assume 455 an initial passive role. This means that once independent PWs are 456 configured on the switching point, the LSR does not advertise the LDP 457 PW FEC mapping until it has received at least one of the two PW LDP 458 FECs from a remote PE. This is necessary because the switching point 459 LSR does not know a priori what the interface parameter field in the 460 initial FEC advertisement will contain. 462 The PWID is a unique number between each pair of PEs. Hence Each SS- 463 PW that forms an MS-PW may have a different PWID. In the case of The 464 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 465 some, or sometimes all, SS-PWs. 467 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 469 When a MS-PW is signaled using FEC 129, each T-PE might independently 470 start signaling the MS-PW. If the MS-PW path is not statically 471 configured, in certain cases the signaling procedure could result in 472 an attempt to setup each direction of the MS-PW through different 473 paths. To avoid this situation one of the T-PE MUST start the PW 474 signaling (active role), while the other waits to receive the LDP 475 label mapping before sending the respective PW LDP label mapping 476 message. (passive role). When the MS-PW path not statically 477 configured, the Active T-PE (the ST-PE) and the passive T-PE (the 478 TT-PE) MUST be identified before signaling is initiated for a given 479 MS-PW. 481 The determination of which T-PE assume the active role SHOULD be done 482 as follows: 484 the SAII and TAII are compared as unsigned integers, if the SAII is 485 bigger then the T-PE assumes the active role. 487 The selection process to determine which T-PE assumes the active role 488 MAY be superseded by manual provisioning. 490 7.3. LDP FEC 128 to LDP using the generalized FEC 129 492 When a PE is using the generalized FEC 129, there are two distinct 493 roles that a PE can assume: active and passive. A PE that assumes the 494 active role will send the LDP PW setup message, while a passive role 495 PE will simply reply to an incoming LDP PW setup message. The PW 496 switching point PE, will always remain passive until a PWID FEC 128 497 LDP message is received, which will cause the corresponding 498 generalized PW FEC LDP message to be formed and sent. If a 499 generalized FEC PW LDP message is received while the switching point 500 PE is in a passive role, the corresponding PW FEC 128 LDP message 501 will be formed and sent. 503 PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice 504 versa. This can be accomplished by local PW switching point 505 configuration, or by some other means, such as some form of auto 506 discovery. Such other means are outside the scope of this document. 508 7.4. LDP PW switching point TLV 510 The edge to edge PW might traverse several switching points, in 511 separate administrative domains. For management and troubleshooting 512 reasons it is useful to record information about the switching points 513 that the PW traverses. This is accomplished by using a PW switching 514 point TLV. 516 Note that sending the PW switching point TLV is OPTIONAL, however the 517 PE or SPE MUST process the TLV upon reception. The PW switching point 518 TLV is appended to the PW FEC at each switching point and is encoded 519 as follows: 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Length | Variable Length Value | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Variable Length Value | 529 | " | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 [note] LDP TLV type is pending IANA approval. 534 - PW sw TLV Length 536 Specifies the total length of all the following PW switching 537 point TLV fields in octets 539 - Type 541 Encodes how the Value field is to be interpreted. 543 - Length 545 Specifies the length of the Value field in octets. 547 - Value 549 Octet string of Length octets that encodes information to be 550 interpreted as specified by the Type field. 552 PW Switching point TLV Types are assigned by IANA according the the 553 process defined in the "IANA Allocations" section below. 555 The PW switching Point TLV is an OPTIONAL TLV that can appear once 556 for each switching point traversed. 558 7.4.1. PW Switching Point Sub-TLVs 560 Below are details specific to PW Switching Point Sub-TLVs described 561 in this document: 563 - PW ID of last PW segment traversed. 565 This sub-TLV type contains a PW ID in the format of the PWID 566 described in [RFC4447] 568 - PW Switching Point description string. 570 An optional description string of text up to 80 characters long. 572 - IP address of PW Switching Point. 574 The IP V4 or V6 address of the PW Switching Point. This is an 575 OPTIONAL Sub-TLV. 576 - MH Virtual Ciscuit Connectivity Verification (VCCV) Capability 577 Indication. 579 - The FEC of last PW segment traversed. 581 The Attachment Identifier of the last PW segment traversed. This 582 is coded in the following format: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | AGI Type | Length | Value | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 ~ AGI Value (contd.) ~ 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | AII Type | Length | Value | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 ~ SAII Value (contd.) ~ 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | AII Type | Length | Value | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 ~ TAII Value (contd.) ~ 600 | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 - L2 PW address of PW Switching Point (recommended format) 605 This sub-TLV type contains a L2 PW address of PW Switching Point in 606 the format described in [RFC5003]. This includes the AII type field , 607 and length, as well as the L2 PW address without the AC ID portion 608 (if applicable). 610 7.4.2. Adaptation of Interface Parameters 612 [RFC4447] defines several interface parameters, which are used by the 613 Network Service Processing (NSP) to adapt the PW to the Attachment 614 Circuit (AC). The interface parameters are only used at the end 615 points, and MUST be passed unchanged across the PW switching point. 616 However the following interface parameters MAY be modified as 617 follows: 619 - 0x03 Optional Interface Description string This Interface 620 parameter MAY be modified, or altogether removed from the FEC 621 element depending on local configuration policies. 623 - 0x09 Fragmentation indicator This parameter MAY be inserted in 624 the FEC by the switching point if it is capable of re-assembly of 625 fragmented PW frames according to [PWE3-FRAG]. 627 - 0x0C VCCV parameter The switching point MAY not be able to 628 inspect the VCCV control channel. If the new MH-VCCV sub-TLV is 629 present, the VCCV parameter MUST be ignored in order to avoid 630 conflicts with the new TLV. 632 7.5. Group ID 634 The Group ID (GR ID) is used to reduce the number of status messages 635 that need to be sent by the PE advertising the PW FEC. The GR ID has 636 local significance only, and therefore MUST be mapped to a unique GR 637 ID allocated by the PW switching point PE. 639 7.6. PW Loop Detection 641 A switching point PE SHOULD check the OPTIONAL PW switching Point 642 TLV, to verify if it's own IP address appears in it. If it's IP 643 address appears in a received PW switching Point TLV, the PE SHOULD 644 break the loop, and send a label release message with the following 645 error code: 646 Assignment E Description 647 0x0000003A 0 "PW Loop Detected" 649 [ note: error code pending IANA allocation ] 651 8. PW-MPLS to PW-L2TPv3 Control Plane Switching 653 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 654 four possibilities when switching between L2TPv3 and MPLS. 656 -i. Switching between MPLS and L2TPv3 static control planes. 657 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 658 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 659 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 661 8.1. Static MPLS and L2TPv3 PWs 663 In the case of two static control planes, the PW switching point MUST 664 be configured to direct packets from one PW into the other. There is 665 no control protocol involved in this case. The configuration MUST 666 include which MPLS VC Label maps to which L2TPv3 Session ID (and 667 associated Cookie, if present) as well as which MPLS Tunnel Label 668 maps to which PE destination IP address. 670 8.2. Static MPLS PW and Dynamic L2TPv3 PW 672 When a statically configured MPLS PW is switched to a dynamic L2TPv3 673 PW, the static control plane should be considered identical to an 674 attachment circuit (AC) in the reference model of Figure 1. The 675 switching point PE SHOULD signal the proper PW status if it detects a 676 failure in 678 sending or receiving packets over the static PW. Because the PW is 679 statically configured, the status communicated to the dynamic L2TPv3 680 PW will be limited to local interface failures. In this case, the PW 681 switching point PE behaves in a very similar manner to a T-PE, 682 assuming an active role. 684 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 686 When a statically configured L2TPv3 PW is switched to a dynamic 687 LDP/MPLS PW, then the static control plane should be considered 688 identical to an attachment circuit (AC) in the reference model of 689 Figure 1. The switching point PE SHOULD signal the proper PW status 690 (via an L2TPv3 SLI message) if it detects a failure in sending or 691 receiving packets over the static PW. Because the PW is statically 692 configured, the status communicated to the dynamic LDP/MPLS PW will 693 be limited to local interface failures. In this case, the PW 694 switching point PE behaves in a very similar manner to a T-PE, 695 assuming an active role. 697 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 699 When switching between dynamic PWs, the switching point always 700 assumes an initial passive role. Thus, it does not initiate an 701 LDP/MPLS or L2TPv3 PW until it has received a connection request 702 (Label Mapping or ICRQ) from one side of the node. Note that while 703 MPLS PWs are made up of two unidirectional LSPs bonded together by 704 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 705 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 706 Establishment, Tear Down, and PW Status signaling are detailed below. 708 8.4.1. Session Establishment 710 When the PW switching point receives an L2TPv3 ICRQ message, the 711 identifying AVPs included in the message are mapped to FEC 712 identifiers and sent in an LDP label mapping message. Conversely, if 713 an LDP Label Mapping message is received, it is either mapped to an 714 ICRP message or causes an L2TPv3 session to be initiated by sending 715 an ICRQ. 717 Following are two example exchanges of messages between LDP and 718 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 719 the second is a case where an MPLS T-PE initiates an MS-PW. 721 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 723 AC "Up" 724 L2TPv3 ICRQ ---> 725 LDP Label Mapping ---> 726 AC "UP" 727 <--- LDP Label Mapping 728 <--- L2TPv3 ICRP 729 L2TPv3 ICCN ---> 730 <-------------------- MH PW Established ------------------> 732 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 734 AC "Up" 735 LDP Label Mapping ---> 736 L2TPv3 ICRQ ---> 737 <--- L2TPv3 ICRP 738 <--- LDP Label Mapping 739 L2TPv3 ICCN ---> 740 AC "Up" 741 <-------------------- MH PW Established ------------------> 743 8.4.2. Adaptation of PW Status message 745 L2TPv3 uses the SLI message to indicate a interface status change 746 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 747 PWs either signal this via an LDP Label Withdraw or the PW Status 748 Notification message defined in section 4.4 of [RFC4447]. 750 8.4.3. Session Tear Down 752 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 753 message translates to a Label Withdraw message in LDP. Following are 754 two example exchanges of messages between LDP and L2TPv3. The first 755 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 756 the second is a case where an MPLS T-PE initiates the termination of 757 an MS-PW. 759 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 761 AC "Down" 762 L2TPv3 CDN ---> 763 LDP Label Withdraw ---> 764 AC "Down" 765 <-- LDP Label Release 767 <--------------- MH PW Data Path Down ------------------> 769 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 771 AC "Down" 772 LDP Label Withdraw ---> 773 L2TPv3 CDN --> 774 <-- LDP Label Release 775 AC "Down" 777 <---------------- MH PW Data Path Down ------------------> 779 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 781 [RFC4447] defines several interface parameters which MUST be mapped 782 to the equivalent AVPs in L2TPv3 setup messages. 784 * Interface MTU 786 The Interface MTU parameter is mapped directly to the L2TP 787 Interface MTU AVP defined in [L2TP-L2VPN] 789 * Max Number of Concatenated ATM cells 791 This interface parameter is mapped directly to the L2TP "ATM 792 Maximum Concatenated Cells AVP" described in section 6 of [L2TP- 793 ATM]. 795 * Optional Interface Description String 797 This string may be carried as the "Call-Information AVP" 798 described in section 2.2 of [L2TP-INFOMSG] 800 * PW Type 802 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 803 Type" AVP defined in [L2TPv3]. 805 * PW ID (FEC 128) 807 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 808 End ID" AVP defined in [L2TPv3]. 810 * Generalized FEC 129 SAI/TAI 812 Section 4.3 of [L2TP-L2VPN] defines how to encode the SAI and TAI 813 parameters. These can be mapped directly. 815 Other interface parameter mappings will either be defined in a future 816 version of this document, or are unsupported when switching between 817 LDP/MPLS and L2TPv3 PWs. 819 8.6. Switching Point TLV in L2TPv3 821 When translating between LDP and L2TPv3 control messages, the PW 822 Switching Point TLV described earlier in this document is carried in 823 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 824 and optionally in the ICCN message. 826 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 827 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 828 the AVP is 6 plus the length of the series of Switching Point sub- 829 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 830 (the L2TP AVP M-bit MUST be 0). 832 8.7. L2TPv3 and MPLS PW Data Plane 834 When switching between an MPLS and L2TP PW, packets are sent in their 835 entirety from one PW to the other, replacing the MPLS label stack 836 with the L2TPv3 and IP header or vice versa. There are some 837 situations where an additional amount of interworking must be 838 provided between the two data planes at the PW switching node. 840 8.7.1. PWE3 Payload Convergence and Sequencing 842 Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim 843 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 844 For L2TPv3, the Payload Convergence and Sequencing function is 845 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 846 For MPLS, these two functions (together with PSN Convergence) are 847 carried out via the MPLS Control Word. Since these functions are 848 different between MPLS and L2TPv3, interworking between the two may 849 be necessary. 851 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 852 which in some cases are not necessary to be present at all. For 853 example, an Ethernet PW with sequencing disabled will generally not 854 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 855 be present at all. In this case, Ethernet frames are simply sent from 856 one PW to the other without any modification beyond the MPLS and 857 L2TP/IP encapsulation and decapsulation. 859 The following section offers guidelines for how to interwork between 860 L2TP and MPLS for those cases where the Payload Convergence, 861 Sequencing, or PSN Convergence functions are necessary on one or both 862 sides of the switching node. 864 8.7.2. Mapping 866 The MPLS Control Word consists of (from left to right): 868 -i. These bits are always zero in MPLS are not necessary to be 869 mapped to L2TP. 871 -ii. These six bits may be used for Payload Convergence depending 872 on the PW type. For ATM, the first four of these bits are 873 defined in [PWE3-ATM]. These map directly to the bits 874 defined in [L2TP-ATM]. For Frame Relay, these bits indicate 875 how to set the bits in the Frame Relay header which must be 876 regenerated for L2TP as it carries the Frame Relay header 877 intact. 879 -iii. L2TP determines its payload length from IP. Thus, this 880 Length field need not be carried directly to L2TP. This 881 Length field will have to be calculated and inserted for 882 MPLS when necessary. 884 -iv. The Default L2-Specific Sublayer has a sequence number with 885 different semantics than that of the MPLS Control Word. This 886 difference eliminates the possibility of supporting 887 sequencing across the MS-PW by simply carrying the sequence 888 number through the switching point transparently. As such, 889 sequence numbers MAY be supported by checking the sequence 890 numbers of packets arriving at the switching point and 891 regenerating a new sequence number in the proper format for 892 the PW on egress. If this type of sequence interworking at 893 the switching node is not supported, and a T-PE requests 894 sequencing of all packets via the L2TP control channel 895 during session setup, the switching node SHOULD NOT allow 896 the session to be established by sending a CDN message with 897 Result Code set to 17 "sequencing not supported" (subject to 898 IANA Assignment). 900 9. Operation And Management 902 9.1. Extensions to VCCV to Support Switched PWs 904 Single-hop pseudowires are signaled using the Virtual Circuit 905 Connectivity Verification (VCCV) parameter included in the interface 906 parameter field of the PW ID FEC TLV or the sub-TLV interface 907 parameter of the Generalized PW ID FEC TLV as described in [RFC5085]. 908 When a switching point exist between PE nodes, it is required to be 909 able to continue operating VCCV end-to-end across a switching point 910 and to provide the ability to trace the path of the MS-PW over any 911 number of segments. 913 This document provides a method for achieving these two objectives. 914 This method is based on re-using the existing VCCV CW and 915 decrementing the TTL of the PW label at each hop in the path of the 916 MS-PW. 918 9.2. PW-MPLS to PW-MPLS OAM Data Plane Indication 920 9.2.1. Decreasing the PW Label TTL 922 This method reuses the SS-PW control word as described in [RFC5085]. 923 VCCV control packets are indicated using the following CW in the 924 packet header: 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 |0 0 0 1|Version| Reserved = 0 | Channel Type | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Where: 932 Version = 0 933 Channel Type = IPv4,IPV6, or no IP header (0x21,0x57,0x07) 935 By the rules defined in [RFC3032] the PW label TTL MUST be decreased 936 at every S-PE. Once the PW label TTL reaches the value of 0 , the 937 packet is sent to the control plane to be processed. Hence , by 938 controling the PW TTL value of the PW label it is possible to select 939 exactly which hop will respond to the VCCV packet. 941 9.3. Signaling OAM Capabilities for Switched Pseudo Wires 943 Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV 944 parameter included in the interface parameter field of the PW ID FEC 945 TLV or the sub-TLV interface parameter of the Generalized PW ID FEC 946 TLV as described in [RFC5085]. The new MH-VCCV CW is indicated using 947 a new CC type in the VCCV capability parameter field. 949 In Figure 2 T-PE1 uses the VCCV parameter included in the interface 950 parameter field of the PW ID FEC TLV or the sub-TLV interface 951 parameter of the Generalized PW ID FEC TLV to indicate to the far end 952 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 953 parameter as would be used if T-PE1 and T-PE2 were connected 954 directly. S-PE2, which is a PW switching point, as part of the 955 adaptation function for interface parameters, processes locally the 956 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 957 on the path between T-PE1 and T-PE2, each would carry out the same 958 processing, passing along the VCCV parameter. The local processing of 959 the VCCV parameter removes CC Types specified by the originating T-PE 960 that are not supported on the S-PE. For example, if T-PE1 indicates 961 as supported CC Types both Control Word and Router Alert and the S-PE 962 only supports Control Word CC type. Then the S-PE removes the Router 963 Alert CC Type, leaving Control Word unchanged, and passes the 964 modified VCCV parameter to the next S-PE along the path. 966 The far end T-PE (T-PE2) receives the VCCV parameter indicating that 967 one or both Control Word CC types only if they are supported by the 968 initial T-PE (T-PE1) and all S-PEs along the PW path. If the VCCV 969 parameter indicates both the CW CC type and the new MH-VCCV CW CC 970 types are supported, then the T-PE1 is indicating it can receive both 971 types. If T-PE2 also supports both types, T-PE2 uses the CW CC type 972 in preference. 974 9.3.1. OAM Capability for MH PWs Demultiplexed using MPLS 976 The MH-VCCV parameter ID is defined as follows in [RFC4446]: 978 Parameter ID Length Description 979 0x0c 4 VCCV 981 The format of the VCCV parameter field is as follows: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | 0x0c | 0x04 | CC Types | CV Types | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 0x01 Type 1: PWE3 control word with 0001b as first nibble 990 as defined in [RFC4385]. 991 0x02 Type 2: MPLS Router Alert Label. 992 0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3). 994 When using the PW label TTL method, the T-PE signals CC type 1. When 995 using the MH-VCCV CW method, the T-PE signal CC type 4. 997 9.4. Detailed MH-VCCV Procedures 999 In order to test the end-to-end connectivity of the multi-segment PW, 1000 a T-PE must include the FEC used in the last segment to the 1001 destination T-PE. This information is either configured at the 1002 sending T-PE or is obtained by processing the corresponding sub-TLV's 1003 of the PW switching point TLV. 1005 9.4.1. PW Label TTL 1007 In Figure 2, if T-PE1, S-PE and T-PE2 support Control Word for VCCV, 1008 then as described in the previous section the control plane 1009 negotiates the common use of Control Word for VCCV end to end. 1011 At the S-PE the data path operations include an outer label pop, 1012 inner label swap and new outer label push. Note that there is no 1013 requirement for the S-PE to inspect the CW. 1015 Thus, the end-to-end connectivity of the multi-segment pseudowire can 1016 be verified by performing all of the following steps: 1018 -i. T-PE forms a VCCV-ping echo request message with the FEC 1019 matching that of the last segment PW to the destination T- 1020 PE. 1022 -ii. T-PE sets the inner PW label TTL to a large enough value to 1023 allow the packet to reach the far end T-PE. 1025 -iii. T-PE sends a VCCV packet that will follow the exact same 1026 data path at each S-PE as that taken by data packets. 1028 -iv. S-PE performs an outer label pop, an inner label swap with 1029 TTL decrement, and new outer label push. 1031 -v. There is no requirement for the S-PE to inspect the CW. 1033 -vi. The VCCV packet is diverted to VCCV control processing at 1034 the destination T-PE. 1036 -vii. Destination T-PE replies using the specified reply mode, 1037 i.e., reverse PW path or IP path. 1039 9.4.2. Partial tracing from T-PE 1041 In order to trace part of the multi-segment pseudowire, the TTL of 1042 the PW label may be used to force the VCCV message to 'pop out' at an 1043 intermediate node. When the TTL expires, the S-PE can determine that 1044 the packet is a VCCV packet by checking the control word. If the 1045 control word format matches that specified in [RFC5085], the packet 1046 should be diverted to VCCV processing. 1048 In Figure 2, if T-PE1 sends a VCCV message with the TTL of the PW 1049 label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus 1050 verify the first segment of the pseudo wire. 1052 Note that this use of the TTL is subject to the caution expressed in 1053 [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and 1054 a T-PE manipulates the PW label TTL, the VCCV message may not emerge 1055 from the MS-PW at the correct S-PE. 1057 9.4.3. Partial Tracing between S-PEs 1059 Assuming that all nodes along an MS-PW support the Control Word CC 1060 Type, VCCV between S-PEs may be accomplished using the PW label TTL 1061 as in section 3.3. In Figure-1, the S-PE may verify the path between 1062 it and T-PE2 by sending a VCCV message with the PW label TTL set to 1063 1. Given a more complex network with multiple S-PEs, an S-PE may 1064 verify the connectivity between it and an S-PE two segments away by 1065 sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE 1066 can diagnose connectivity problems by successively increasing the 1067 TTL. 1069 9.4.4. Automated VCCV Trace from T-PE 1071 Although tracing of the MS-PW path is possible using the methods 1072 explained in sections 3.3. and 3.4. , these require multiple manual 1073 iterations and that the FEC of the last PW segment to the target T- 1074 PE/S-PE be known a priori at the node originating the echo request 1075 message for each iteration. This mode of operation will be referred 1076 to as the "ping" mode. 1078 A full automated path tracing capability that iteratively probes the 1079 segments the MS-PW to learn the target FEC information is required. 1080 This will be referred to as the "trace" mode of operation. The 1081 details of this method are described in a later section. 1083 9.5. Processing of an VCCV Echo Message in a MS-PW 1085 The challenge for the control plane is to be able to build the VCCV 1086 echo request packet with the necessary information such as the target 1087 FEC 128 PW sub-TLV (FEC128) of the downstream PW segment which the 1088 packet is destined for. This could be even more difficult in 1089 situations in which the MS-PW spans different providers and 1090 Autonomous Systems. 1092 For example, in Figure 2, T-PE1 has the required information to 1093 compose the FEC128 of the PW1 segment but it does not readily have 1094 the information required to compose the FEC128 of the PW3 segment if 1095 a VCCV echo request is supposed to be destined to T-PE2. 1097 9.5.1. Sending a VCCV Echo Request 1099 When in the "ping" mode of operation, the sender of the echo request 1100 message requires the FEC of the last segment to the target S-PE/T-PE 1101 node. This information can either be configured manually or be 1102 obtained by inspecting the corresponding sub-TLV's of the PW 1103 switching point TLV. However, the PW switching point TLV is optional 1104 and there is no guarantee that all S-PE nodes will populate it with 1105 their system address and the PWid of the last PW segment traversed by 1106 the label mapping message. Thus a manual configuration is always 1107 preferred. 1109 When in the "trace" mode operation, the T-PE will automatically learn 1110 the target FEC by probing one by one the hops of the MS-PW path. Each 1111 S-PE node includes the FEC to the downstream node in the echo reply 1112 message in a similar way that LSP trace will have the probed node 1113 return the downstream interface and label stack in the echo reply 1114 message. The details of this method are described in the following 1115 sections. 1117 9.5.2. Receiving an VCCV Echo Request 1119 Upon receiving a VCCV echo request the control plane on S-PEs (or the 1120 target node of each segment of the MS-PW) validates the request and 1121 responds to the request with an echo reply consisting of the FEC128 1122 of the next downstream segment and a return code of 8 (label switched 1123 at stack-depth) indicating that it is an S-PE and not the egress 1124 router for the MS-PW. 1126 If the node is the T-PE or the egress node of the MS-PW, it responds 1127 to the echo request with an echo reply with a return code of 3 1128 (egress router) and no FEC128 is included. 1130 9.5.3. Receiving an VCCV Echo Reply 1132 The operation to be taken by the node that receives the echo reply in 1133 response to its echo request depends on its current mode of operation 1134 such as "ping" or "trace". 1136 In "ping" mode, the node may choose to ignore the target FEC128 in 1137 the echo reply and report only the return code to the operator. 1139 However, in "trace" mode, the node builds and sends the subsequent 1140 VCCV echo request with a incrementing TTL and the information (such 1141 as the downstream FEC128) it received in the echo request to the next 1142 downstream PW segment. 1144 9.6. VCCV Trace Operations 1146 As an example, in Figure 2, VCCV trace can be performed on the MS-PW 1147 originating from T-PE1 by a single operational command. The following 1148 process ensues: 1149 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a 1150 FEC128 containing the pseudo-wire information of the first 1151 segment (PW1 between T-PE1 and S-PE) to S-PE for validation. 1152 If FEC Stack Validation is enabled, the request may also 1153 include additional subTLV such as LDP Prefix and/or RSVP LSP 1154 dependent on the type of transport tunnel the segmented PW 1155 is riding on. 1157 -ii. S-PE validates the echo request with the FEC128. Since it is 1158 a switching point between the first and second segment it 1159 builds an echo reply with a return code of 8 and includes 1160 the FEC128 of the second segment (PW3 between S-PE and T- 1161 PE2) and sends the echo reply back to T-PE1. If FEC stack 1162 validation is requested the S-PE validates the received FEC 1163 stack and builds the echo reply with the downstream target 1164 FEC stack which includes FEC128 subTLV and any addition 1165 target FEC stack subTLVs required for the next hop FEC stack 1166 validation. 1168 -iii. T-PE1 builds a second VCCV echo request based on the target 1169 FEC stack in the echo reply from the S-PE. It increments the 1170 TTL and sends the next echo request out to T-PE2. Note that 1171 the VCCV echo request packet is switched at the S-PE 1172 datapath and forwarded to the next downstream segment 1173 without any involvement from the control plane. 1175 -iv. T-PE2 receives and validates the echo request with the 1176 FEC128, or the target FEC stack if the FEC stack validation 1177 is required, of the PW3 from T-PE1. Since T-PE2 is the 1178 destination node or the egress node of the MS-PW it replies 1179 to T-PE1 with an echo reply with a return code of 3 (Egress 1180 Router) and no FEC128 is included. 1182 -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1183 aware that T-PE2 is the destination of the MS-PW because the 1184 echo reply does not contain the FEC128 and because its 1185 return code is 3. The trace process is completed. 1187 Note that the above example assumes only FEC128 sub-TLV is exchanged 1188 but it is possible that the exchanged information could also involve 1189 other TLV or Target FEC sub-TLVs (such as FEC129, LDP Prefix or RSVP 1190 LSP). For more detail on the format of the VCCV echo packet, refer to 1191 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1192 (VC) label TTL. 1194 9.7. Tracing Switched PW Switch Points Using MH-VCCV 1196 Although the signaling of switched PWs includes functionality to 1197 record all switch points traversed by a particular switched 1198 pseudowire, this information is limited to the control plane. 1199 Specifically, this is the information which is then used to program 1200 the actual switching hardware. In an effort to provide explicit 1201 diagnostic capability of the data plane used by the switched 1202 pseudowire, it is necessary in some cases to compare the control and 1203 data planes used by a particular switched pseudowire. In these cases, 1204 it is possible to trace the pseudowire switch points by sending 1205 single-hop VCCV messages with TTL described above in the MH VCCV 1206 header, and increasing TTL values. This algorithm can be used to 1207 "walk" across the network of switching points until the ultimate PE 1208 is reached. 1210 Details of the operation for both methods will be provided in a 1211 future version of the document 1213 9.8. Mapping Switched Pseudo Wire Status 1215 In the PW switching with attachment circuits case (Figure 2), PW 1216 status messages indicating PW or attachment circuit faults SHOULD be 1217 mapped to fault indications or OAM messages on the connecting AC as 1218 defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an 1219 administrative boundary, then the manner in which those OAM messages 1220 are treated at the boundary is out of scope of this draft. 1222 In the PW control plane switching case (Figure 3), there is no 1223 attachment circuit at the PW switching point, but the two PWs are 1224 connected together. Similarly, the status of the PWs are forwarded 1225 unchanged from one PW to the other by the control plane switching 1226 function. However, it may sometimes be necessary to communicate 1227 status of one of the locally attached SS-PW at a PW switching point. 1228 For LDP this can be accomplished by sending an LDP notification 1229 message containing the PW status TLV, as well as an OPTIONAL PW 1230 switching point TLV as follows: 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 |0| Notification (0x0001) | Message Length | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Message ID | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 |0|1| Status (0x0300) | Length | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 |0|1| Status Code=0x00000028 | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Message ID=0 | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Message Type=0 | PW Status TLV | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | PW Status TLV | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | PW Status TLV | PWId FEC | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | | 1252 | | 1253 | PWId FEC or Generalized ID FEC | 1254 | | 1255 | | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Type | Length | Variable Length Value | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 Only one PW switching point TLV can be present in this message. This 1263 message is then relayed by each PW switching point unchanged. The T- 1264 PE decodes the status message and the included PW switching point TLV 1265 to detect exactly where the fault occurred. At the T-PE if there is 1266 no PW switching point TLV included in the LDP status notification 1267 then the status message can be assumed to have originated at the 1268 remote T-PE. 1270 The merging of the received T-LDP status and the local status for the 1271 PW segments at an S-PE can be summarized as follows: 1273 -i. When the local status for both PW segments is UP, the S-PE 1274 passes any received AC or PW status bits unchanged, i.e., 1275 the status notification TLV is unchanged but the VCid in the 1276 case of a FEC 128 TLV is set to value of the PW segment to 1277 the next hop. 1279 -ii. When the local status for any of the PW segments is Down, 1280 the S-PE always sends "PW Down" status bits regardless if 1281 the received status bits from the remote node indicated AC 1282 UP/Down or PW UP/Down." 1284 9.8.1. S-PE initiated PW status messages 1286 The PW fault directions are defined as follows: 1288 +-------+ 1289 ---PW1 forward---->| |-----PW2 reverse----> 1290 S-PE1 | S-PE2 | S-PE3 1291 <--PW1 reverse-----| |<----PW2 forward----- 1292 +-------+ 1294 When a local fault is detected by the S-PE, a PW status message is 1295 sent in both directions along the PW. Since there are no attachment 1296 circuits on an S-PE, only the following status messages are relevant: 1298 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1299 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1301 Each S-PE needs to store only two 32-bit PW status words for each 1302 SS-PW: One for local failures , and one for remote failures (normally 1303 received from another PE). The first failure will set the appropriate 1304 bit in the 32-bit status word, and each subsequent failure will be 1305 ORed to the appropriate PW status word. In the case of the PW status 1306 word storing remote failures, this rule has the effect of a logical 1307 OR operation with the first failure received on the particular SS-PW. 1309 It should be noted that remote failures received on an S-PE are just 1310 passed along the MS-PW unchanged while local failures detected an an 1311 S-PE are signalled on both SS-PWs. 1313 A T-PE can receive multiple failures from S-PEs along the MH-PW, 1314 however only the failure from the remote closest S-PE will be stored. 1315 The PW status word received are just ORed to any existing remote PW 1316 status already stored on the T-PE. 1318 Given that there are two SS-PW at a particular S-PE for a particular 1319 MH-PW, there are for possible failure cases as follows: 1321 -i. PW2 reverse direction fault 1322 -ii. PW1 reverse direction fault 1323 -iii. PW2 forward direction fault 1324 -iv. PW1 forward direction fault 1326 It should also be noted that once a PW status notification message is 1327 initiated at a PW switching point for a partucular pw status bit any 1328 further status message, for the same status bit, received from an 1329 upstream neighbor is processed locally and not forwarded until the PW 1330 switching point original status error state is cleared. 1332 Each S-PE along the MS-PW MUST store any PW status messages 1333 transiting it. If more then one status message with the same PW 1334 status bit set is received by a T-PE only the last PW status message 1335 is stored. 1337 9.8.1.1. Local PW2 reverse direction fault 1339 When this failure occurs the S-PE will take the following actions: 1341 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1342 PSN-facing PW (egress) Transmit Fault" 1343 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1344 PSN-facing PW (ingress) Receive Fault" 1345 * Store 0x00000010 in the local PW status word for the SS-PW toward 1346 S-PE3. 1348 9.8.1.2. Local PW1 reverse direction fault 1350 When this failure occurs the S-PE will take the following actions: 1352 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1353 PSN-facing PW (egress) Transmit Fault" 1354 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1355 PSN-facing PW (ingress) Receive Fault" 1356 * Store 0x00000010 in the local PW status word for the SS-PW toward 1357 S-PE1. 1359 9.8.1.3. Local PW2 forward direction fault 1361 When this failure occurs the S-PE will take the following actions: 1362 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1363 PSN-facing PW (ingress) Receive Fault" 1365 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1366 PSN-facing PW (egress) Transmit Fault" 1367 * Store 0x00000008 in the local PW status word for the SS-PW toward 1368 S-PE3. 1370 9.8.1.4. Local PW1 forward direction fault 1372 When this failure occurs the S-PE will take the following actions: 1373 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1374 PSN-facing PW (ingress) Receive Fault" 1375 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1376 PSN-facing PW (egress) Transmit Fault" 1377 * Store 0x00000008 in the local PW status word for the SS-PW toward 1378 S-PE1. 1380 9.8.1.5. Clearing Faults 1382 Remote PW status fault clearing messages received by an S-PE will 1383 only be forwarded if there are no corresponding local faults on the 1384 S-PE. ( local faults always supersede remote faults ) 1386 Once the local fault has cleared, and there is no corresponding ( 1387 same PW status bit set ) remote fault, a PW status messages is sent 1388 out to the adjacent PEs clearing the fault. 1390 9.8.2. PW status messages and S-PE TLV processing 1392 When a PW status message is received that includes a S-PE TLV, the 1393 S-PE TLV information MAY be stored, along with the contents of the PW 1394 status Word according to the procedures described above. If 1395 subsequent PW status message for the same pw status bit are received 1396 the S-PE TLV will overwrite the previously stored S-PE TLV. 1398 9.8.3. T-PE processing of PW status messages 1400 The PW switching architecture is based on the concept that the T-PE 1401 should process the PW LDP messages in the same manner as if it was 1402 participating in the setup of a SS-PW. However T-PE participating a 1403 MS-PW, SHOULD be able to process the PW switching point TLV. 1404 Otherwise the processing of PW status messages , and other PW setup 1405 messages is exactly as described in [RFC4447]. 1407 9.9. Pseudowire Status Negotiation Procedures 1409 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1410 be transparent to the switching point. 1412 9.10. Status Dampening 1414 When the PW control plane switching methodology is used to cross an 1415 administrative boundary it might be necessary to prevent excessive 1416 status signaling changes from being propagated across the 1417 administrative boundary. This can be achieved by using a similar 1418 method as commonly employed for the BGP protocol route advertisement 1419 dampening. The details of this OPTIONAL algorithm are a matter of 1420 implementation, and are outside the scope of this document. 1422 10. Peering Between Autonomous Systems 1424 The procedures outlined in this document can be employed to provision 1425 and manage MS-PWs crossing AS boundaries. 1427 The use of more advanced mechanisms involving auto-discovery and 1428 ordered PWE3 MS-PW signaling will be covered in a separate document. 1430 11. Security Considerations 1432 This document specifies the LDP and L2TPv3 extensions that are needed 1433 for setting up and maintaining pseudowires. The purpose of setting up 1434 pseudowires is to enable layer 2 frames to be encapsulated and 1435 transmitted from one end of a pseudowire to the other. Therefore we 1436 treat the security considerations for both the data plane and the 1437 control plane. 1439 11.1. Data Plane Security 1441 Data plane security consideration as discussed in [RFC4447], 1442 [L2TPv3], and [PWE3-ARCH] apply to this extension without any 1443 changes. 1445 11.2. Control Protocol Security 1447 General security considerations with regard to the use of LDP are 1448 specified in section 5 of RFC 3036. Security considerations with 1449 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1450 considerations apply as well to the case where LDP or L2TPv3 is used 1451 to set up PWs. 1453 A Pseudowire connects two attachment circuits. It is important to 1454 make sure that LDP connections are not arbitrarily accepted from 1455 anywhere, or else a local attachment circuit might get connected to 1456 an arbitrary remote attachment circuit. Therefore an incoming session 1457 request MUST NOT be accepted unless its IP source address is known to 1458 be the source of an "eligible" peer. The set of eligible peers could 1459 be pre-configured (either as a list of IP addresses, or as a list of 1460 address/mask combinations), or it could be discovered dynamically via 1461 an auto-discovery protocol which is itself trusted. (Obviously if the 1462 auto-discovery protocol were not trusted, the set of "eligible peers" 1463 it produces could not be trusted.) 1465 Even if a connection request appears to come from an eligible peer, 1466 its source address may have been spoofed. So some means of 1467 preventing source address spoofing must be in place. For example, if 1468 all the eligible peers are in the same network, source address 1469 filtering at the border routers of that network could eliminate the 1470 possibility of source address spoofing. 1472 For a greater degree of security, the LDP MD5 authentication key 1473 option, as described in section 2.9 of RFC 3036, or the Control 1474 Message Authentication option of [L2TPv3] MAY be used. This provides 1475 integrity and authentication for the control messages, and eliminates 1476 the possibility of source address spoofing. Use of the message 1477 authentication option does not provide privacy, but privacy of 1478 control messages are not usually considered to be highly urgent. 1479 Both the LDP and L2TPv3 message authentication options rely on the 1480 configuration of pre-shared keys, making it difficult to deploy when 1481 the set of eligible neighbors is determined by an auto-configuration 1482 protocol. 1484 When the Generalized ID FEC Element is used, it is possible that a 1485 particular peer may be one of the eligible peers, but may not be the 1486 right one to connect to the particular attachment circuit identified 1487 by the particular instance of the Generalized ID FEC element. 1488 However, given that the peer is known to be one of the eligible peers 1489 (as discussed above), this would be the result of a configuration 1490 error, rather than a security problem. Nevertheless, it may be 1491 advisable for a PE to associate each of its local attachment circuits 1492 with a set of eligible peers, rather than having just a single set of 1493 eligible peers associated with the PE as a whole. 1495 12. IANA Considerations 1497 12.1. Channel Type 1499 The Channel Type code point is defined in [RFC4385], and an IANA 1500 registry was requested in [RFC5085]. This draft further requests the 1501 following code point to be assigned to that registry. 0x01 OAM 1502 Indication For Multi Segment Pseudowires (MH-VCCV) 1504 12.2. L2TPv3 AVP 1506 This document uses a ne L2TP parameter, IANA already maintains a 1507 registry of name "Control Message Attribute Value Pair" defined by 1508 [RFC3438]. The following new values are required: 1510 TBA-L2TP-AVP-1 - PW Switching Point AVP 1512 12.3. LDP TLV TYPE 1514 This document uses several new LDP TLV types, IANA already maintains 1515 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1516 following value is suggested for assignment: 1518 TLV type Description 1519 0x096D Pseudo Wire Switching TLV 1521 12.4. LDP Status Codes 1523 This document uses several new LDP status codes, IANA already 1524 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1525 RFC3036. The following value is suggested for assignment: 1527 Assignment E Description 1528 0x0000003A 0 "PW Loop Detected" 1530 12.5. L2TPv3 Result Codes 1532 This document uses several new L2TPv3 status codes, IANA already 1533 maintains a registry of name "L2TPv3 Result Codes" defined by 1534 RFCxxxx. The following value is suggested for assignment: 1536 Assignment Description 1537 17 "sequencing not supported" 1539 12.6. New IANA Registries 1541 IANA needs to set up a registry of "PW Switching Point TLV Type". 1542 These are 8-bit values. Types value 1 through 3 are defined in this 1543 document. Type values 4 through 64 are to be assigned by IANA using 1544 the "Expert Review" policy defined in RFC2434. Type values 65 through 1545 127, 0 and 255 are to be allocated using the IETF consensus policy 1546 defined in [RFC2434]. Types values 128 through 254 are reserved for 1547 vendor proprietary extensions and are to be assigned by IANA, using 1548 the "First Come First Served" policy defined in RFC2434. 1550 The Type Values are assigned as follows: 1551 Type Length Description 1553 0x01 4 PW ID of last PW segment traversed 1554 0x02 variable PW Switching Point description string 1555 0x03 4/16 IP address of PW Switching Point 1556 0x04 variable MH VCCV Capability Indication 1557 0x05 variable AI of last PW segment traversed 1558 0x06 variable L2 PW address of PW Switching Point 1560 13. Intellectual Property Statement 1562 The IETF takes no position regarding the validity or scope of any 1563 Intellectual Property Rights or other rights that might be claimed to 1564 pertain to the implementation or use of the technology described in 1565 this document or the extent to which any license under such rights 1566 might or might not be available; nor does it represent that it has 1567 made any independent effort to identify any such rights. Information 1568 on the procedures with respect to rights in RFC documents can be 1569 found in BCP 78 and BCP 79. 1571 Copies of IPR disclosures made to the IETF Secretariat and any 1572 assurances of licenses to be made available, or the result of an 1573 attempt made to obtain a general license or permission for the use of 1574 such proprietary rights by implementers or users of this 1575 specification can be obtained from the IETF on-line IPR repository at 1576 http://www.ietf.org/ipr. 1578 The IETF invites any interested party to bring to its attention any 1579 copyrights, patents or patent applications, or other proprietary 1580 rights that may cover technology that may be required to implement 1581 this standard. Please address the information to the IETF at ietf- 1582 ipr@ietf.org. 1584 14. Full Copyright Statement 1586 Copyright (C) The IETF Trust (2008). 1588 This document is subject to the rights, licenses and restrictions 1589 contained in BCP 78, and except as set forth therein, the authors 1590 retain all their rights. 1592 This document and the information contained herein are provided on an 1593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1600 15. Acknowledgments 1602 The authors wish to acknowledge the contributions of Wei Luo, Skip 1603 Booth, Neil Hart, Michael Hua, and Tiberiu Grigoriu. 1605 16. Normative References 1607 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1608 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1609 RFC4385, February 2006. 1611 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1612 mulation (PWE3)", L. Martini, RFC4446, April 2006. 1614 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 1615 et al., rfc4447 April 2006. 1617 [RFC3985] Stewart Bryant, et al., PWE3 Architecture, 1618 RFC3985 1620 [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. 1621 draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ), 1622 October 2004. 1624 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1625 M. Townsley, I. Goyret, RFC3931 1627 [RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1628 Verification (VCCV), A Control Channel for Pseudowires", 1629 RFC5085 December 2007. 1631 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1632 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1633 1998. 1635 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1636 Requirement Levels", BCP 14, RFC 2119, March 1997. 1638 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 1639 Individual Identifier (AII) Types for Aggregati", RFC5003, 1640 September 2007. 1642 17. Informative References 1644 [RFC4023] "Encapsulating MPLS in IP or Generic 1645 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1646 RFC4023, March 2005. 1648 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., 1649 draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003. 1651 [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, 1652 W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt 1653 ( work in progress ) February 2004 1655 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, Wei, 1656 draft-ietf-l2tpext-l2vpn-00.txt, ( work in progress ), Jan 2004 1658 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1659 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1660 ( work in progress ), July 2004 1662 [L2TP-ATM] "ATM Pseudo-Wire Extensions for L2TP", Singh, 1663 Townsley, Lau, draft-ietf-l2tpext-pwe3-atm-00.txt, 1664 ( work in progress ), March 2004. 1666 [PWE3-ATM] "Encapsulation Methods for Transport of ATM 1667 Over IP and MPLS Networks", Martini, Rosen, Bocci, 1668 "draft-ietf-pwe3-atm-encap-05.txt", ( work in progress ), 1669 April 2004. 1671 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1672 (L2TP) Internet" 1674 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1675 draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ), 1676 February 2005 1678 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data 1679 Plane Failures", RFC4379, February 2006. 1681 [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001 1683 18. Author Information 1685 Luca Martini 1686 Cisco Systems, Inc. 1687 9155 East Nichols Avenue, Suite 400 1688 Englewood, CO, 80112 1689 e-mail: lmartini@cisco.com 1691 Thomas D. Nadeau 1692 BT 1693 BT Centre 1694 81 Newgate Street 1695 London, EC1A 7AJ 1696 United Kingdom 1697 e-mail: tom.nadeau@bt.com 1699 Chris Metz 1700 Cisco Systems, Inc. 1701 e-mail: chmetz@cisco.com 1703 Mike Duckett 1704 Bellsouth 1705 Lindbergh Center 1706 D481 1707 575 Morosgo Dr 1708 Atlanta, GA 30324 1709 e-mail: mduckett@bellsouth.net 1710 Matthew Bocci 1711 Alcatel-Lucent 1712 Grove House, Waltham Road Rd 1713 White Waltham, Berks, UK. SL6 3TN 1714 e-mail: matthew.bocci@alcatel-lucent.co.uk 1716 Florin Balus 1717 Alcatel-Lucent 1718 701 East Middlefield Rd. 1719 Mountain View, CA 94043 1720 e-mail: florin.balus@alcatel-lucent.com 1722 Mustapha Aissaoui 1723 Alcatel-Lucent 1724 600, March Road, 1725 Kanata, ON, Canada 1726 e-mail: mustapha.aissaoui@alcatel-lucent.com