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