idnits 2.17.1 draft-ietf-pwe3-segmented-pw-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2009) is 5539 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- 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-08 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-05 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 2009 Cisco Systems Inc. 5 Intended status: Standards Track 6 Thomas D. Nadeau 7 Matthew Bocci BT 8 Florin Balus 9 Mustapha Aissaoui Mike Duckett 10 Alcatel-Lucent Bellsouth 12 February 18, 2009 14 Segmented Pseudowire 16 draft-ietf-pwe3-segmented-pw-11.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on Expiration Date: August 2009 41 Abstract 43 This document describes how to connect pseudowires (PW) between two 44 distinct PW control planes or PSN domains. The PW control planes may 45 belong to independent autonomous systems, or the PSN technology is 46 heterogeneous, or a PW might need to be aggregated at a specific PSN 47 point. The PW packet data units are simply switched from one PW to 48 another without changing the PW payload. 50 Table of Contents 52 1 Specification of Requirements ........................ 4 53 2 Terminology .......................................... 5 54 3 Introduction ......................................... 5 55 4 General Description .................................. 7 56 5 PW Switching and Attachment Circuit Type ............. 10 57 6 Applicability ........................................ 10 58 7 MPLS-PW to MPLS-PW Control Plane Switching ........... 10 59 7.1 Static Control plane switching ....................... 11 60 7.2 Two LDP control planes using the same FEC type ....... 11 61 7.2.1 FEC 129 Active/Passive T-PE Election Procedure ....... 12 62 7.3 LDP FEC 128 to LDP using the generalized FEC 129 ..... 12 63 7.4 LDP S-PE TLV ......................................... 13 64 7.4.1 PW Switching Point Sub-TLVs .......................... 14 65 7.4.2 Adaptation of Interface Parameters ................... 15 66 7.5 Group ID ............................................. 16 67 7.6 PW Loop Detection .................................... 16 68 8 MPLS-PW to PW-L2TPv3 Control Plane Switching ......... 16 69 8.1 Static MPLS and L2TPv3 PWs ........................... 17 70 8.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 17 71 8.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 17 72 8.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 17 73 8.4.1 Session Establishment ................................ 18 74 8.4.2 Adaptation of PW Status message ...................... 18 75 8.4.3 Session Tear Down .................................... 19 76 8.5 Adaptation of L2TPv3 AVPs to Interface Parameters .... 19 77 8.6 Switching Point TLV in L2TPv3 ........................ 20 78 8.7 L2TPv3 and MPLS PW Data Plane ........................ 20 79 8.7.1 PWE3 Payload Convergence and Sequencing .............. 21 80 8.7.2 Mapping .............................................. 21 81 9 Operation And Management ............................. 22 82 9.1 Extensions to VCCV to Support MS-PWs ................. 22 83 9.2 MPLS-PW to MPLS-PW OAM Data Plane Indication ......... 22 84 9.3 Signaling OAM Capabilities for Switched Pseudowires .. 23 85 9.4 OAM Capability for MS-PWs Demultiplexed using MPLS ... 23 86 9.4.1 MS-PW and VCCV CC Type 1 ............................. 24 87 9.4.2 MS-PW and VCCV CC type 2 ............................. 24 88 9.4.3 MS-PW and VCCV CC type 3 ............................. 24 89 9.5 MS-PW VCCV Operations ................................ 24 90 9.5.1 VCCV Echo Message Processing ......................... 25 91 9.5.1.1 Sending a VCCV Echo Request .......................... 26 92 9.5.1.2 Receiving a VCCV Echo Request ........................ 26 93 9.5.1.3 Receiving a VCCV Echo Reply .......................... 27 94 9.5.2 Detailed VCCV procedures ............................. 27 95 9.5.2.1 End to End Connectivity Verification Between T-PEs ... 27 96 9.5.2.2 Partial Connectivity Verification from T-PE .......... 28 97 9.5.2.3 Partial connectivity verification between S-PEs ...... 28 98 9.5.2.4 MS-PW Path Verification .............................. 29 99 9.5.2.5 MS-PW Path Trace ..................................... 30 100 10 Mapping Switched Pseudowire Status ................... 31 101 10.1 S-PE initiated PW status messages .................... 32 102 10.1.1 Local PW2 transmit direction fault ................... 33 103 10.1.2 Local PW1 transmit direction fault ................... 33 104 10.1.3 Local PW2 receive direction fault .................... 34 105 10.1.4 Local PW1 receive direction fault .................... 34 106 10.1.5 Clearing Faults ...................................... 34 107 10.2 PW status messages and S-PE TLV processing ........... 35 108 10.3 T-PE processing of PW status messages ................ 35 109 10.4 Pseudowire Status Negotiation Procedures ............. 35 110 10.5 Status Dampening ..................................... 35 111 11 Peering Between Autonomous Systems ................... 35 112 12 Security Considerations .............................. 36 113 12.1 Data Plane Security .................................. 36 114 12.1.1 VCCV Security considerations ......................... 36 115 12.2 Control Protocol Security ............................ 36 116 13 IANA Considerations .................................. 37 117 13.1 L2TPv3 AVP ........................................... 37 118 13.2 LDP TLV TYPE ......................................... 38 119 13.3 LDP Status Codes ..................................... 38 120 13.4 L2TPv3 Result Codes .................................. 38 121 13.5 New IANA Registries .................................. 38 122 14 Normative References ................................. 39 123 15 Informative References ............................... 40 124 16 Author's Addresses ................................... 41 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 Pseudowire (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 Pseudowire (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. 157 3. Introduction 159 PWE3 defines the signaling and encapsulation techniques for 160 establishing SS-PWs between a pair of terminating PEs and in the vast 161 majority of cases this will be sufficient. MS-PWs come into play in 162 two general cases: 164 -i. When it is not possible, desirable or feasible to establish 165 a PW control channel between the ultimate source and 166 destination PEs. At a minimum PW control channel 167 establishment requires knowledge of and reachability to the 168 remote (ultimate) PE IP address. The local (ultimate) PE may 169 not have access to this information related to topology, 170 operational or security constraints. 172 An example is the inter-AS L2VPN scenario where the ultimate 173 PEs reside in different provider networks (ASes) and it is 174 the practice to MD5-key all control traffic exchanged 175 between two networks. Technically a SS-PW could be used but 176 this would require MD5-keying on ALL ultimate source and 177 destination PE nodes. An MS-PW allows the providers to 178 confine MD5 key administration to just the PW switching 179 points connecting the two domains. 181 A second example might involve a single AS where the PW 182 setup path between the ultimate PEs is computed by an 183 external entity (i.e. client-layer routing protocol). Assume 184 a full mesh of PWE3 control channels established between 185 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 186 through a PW is required between ultimate PE-A and PE-C. The 187 external entity computes a PW setup path that passes through 188 PE-B. This results in two discrete PW segments being built: 189 one between PE-A and PE-B and one between PE-B and PE-C. The 190 successful client-layer L2 connection between ultimate PE-A 191 and ultimate PE-C requires that PE-B performs the PWE3 192 switching process. 194 A third example involves the use of PWs in hierarchical 195 IP/MPLS networks. Access networks connected to a backbone 196 use PWs to transport customer payloads between customer 197 sites serviced by the same access network and up to the edge 198 of the backbone where they can be terminated or switched 199 onto a succeeding PW segment crossing the backbone. The use 200 of PWE3 switching between the access and backbone networks 201 can potentially reduce the PWE3 control channels and routing 202 information processed by the access network T-PEs. 204 It should be noted that PWE3 switching does not help in any 205 way to reduce the amount of PW state supported by each 206 access network T-PE. 208 -ii. PWE3 signaling and encapsulation protocols are different. 209 The ultimate PEs are connected to networks employing 210 different PW signaling and encapsulation protocols. In this 211 case it is not possible to use a SS-PW. A MS-PW with the 212 appropriate interworking performed at the PW switching 213 points can enable PW connectivity between the ultimate PEs 214 in this scenario. 216 A more detailed discussion of the requirements pertining to MS-PWs 217 can be found in [RFC5254]. 219 There are four different signaling protocols that are defined to 220 signal PWs: 221 -i. Static configuration of the PW (MPLS or L2TPv3). 222 -ii. LDP using FEC 128 223 -iii. LDP using the generalized FEC 129 224 -iv. L2TPv3 226 4. General Description 228 A pseudowire (PW) is a tunnel established between two provider edge 229 (PE) nodes to transport L2 PDUs across a packet switched network 230 (PSN) as described in Figure 1 and in [RFC3985]. Many providers have 231 deployed PWs as a means of migrating existing (or building new) L2VPN 232 services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN. 234 PWs may span multiple autonomous systems of the same or different 235 provider networks. In these scenarios PW control channels (i.e. 236 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 [RFC4364]. 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 |<------Multi-Segment Pseudowire------>| Native 298 Service | PSN PSN | Service 299 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 300 | V V 1 V V 2 V V | 301 | +----+ +-----+ +----+ | 302 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 303 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 304 | CE1| | | | | | | | | |CE2 | 305 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 306 +----+ | | |===========| |==========| | | +----+ 307 ^ +----+ +-----+ +----+ ^ 308 | Provider Edge 1 ^ Provider Edge 2 | 309 | | | 310 | | | 311 | PW switching point | 312 | | 313 |<------------------ Emulated Service --------------->| 315 Figure 3: PW Control Plane Switching Reference Model 317 In Figure 3 SPE1 runs two separate control planes: one toward TPE1, 318 and one Toward TPE2. The PW switching point (S-PE) is configured to 319 connect PW Segment 1 and PW Segement 3 together to complete the 320 multi-hop PW between TPE1 and TPE2. PW Segment 1 and PW Segment 3 321 MUST be of the same PW type, but PSN Tunnel 1 and PSN Tunnel 2 need 322 not be the same technology. In the latter case, if the PW is switched 323 to a different technology, the PEs must adapt the PDU encapsulation 324 between the different PSN technologies. In the case where PSN Tunnel 325 1 and PSN Tunnel 2 are the same technology the PW PDU does not need 326 to be modified, and PDUs are then switched between the pseudowires at 327 the PW label level. 329 It should be noted that it is possible to adapt one PSN technology to 330 a different one, for example MPLS over an IP or GRE [RFC4023] 331 encapsulation, but this is outside the scope of this document. 332 Further, one could perform an interworking function on the PWs 333 themselves at the S-PE, allowing conversion from one PW type to 334 another, but this is also outside the scope of this document. 336 This document describes procedures for building multi-segment 337 pseudowires using manual configuration of the switching point PE2. 338 Other documents may build on this base specification to automate the 339 configuration and selection of PE2. It should also be noted that a PW 340 can traverse multiple PW switching points along it's path, and the 341 edge PEs will not require any specific knowledge of how many S-PEs 342 the PW has traversed (though this may be reported for troubleshooting 343 purposes). 345 In general the approach taken is to connect the individual control 346 planes by passing along any signaling information immediately upon 347 reception. First the S-PE is configured to switch a SS-PW from a 348 specific peer to another SS-PW destined for a different peer. No 349 control messages are exchanged yet as the S-PE PE does not have 350 enough information to actually initiate the PW setup messages. 351 However, if a session does not already exist, a control protocol 352 (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is 353 starting from the T-PE devices. Next once the T-PE is configured it 354 sends the PW control setup messages. These messages are received, and 355 immediately used to form the PW setup messages for the next SS-PW of 356 the MS-PW. If one of the Switching PEs doesn't accept an LDP Label 357 Mapping message then a Label Release message may be sent back to the 358 originator T-PE depending on the cause of the error. LDP liberal 359 label retention mode still applies, hence if a PE is simply not 360 configured yet , the label mapping is stored for future use. A MS-PW 361 is declared UP when all the constituent SS-PWs are UP. 363 5. PW Switching and Attachment Circuit Type 365 The PWs in each PSN are established independently, with each PSN 366 being treated as a separate PWE3 domain. For example, in Figure 2 for 367 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 368 targeted session as described in [RFC4447], and at the same time a 369 separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for 370 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 371 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 373 6. Applicability 375 The general applicability of MS-PWs and their relationship to L2VPNs 376 is described in [MS-PW-ARCH]. The applicability of a PW type, as 377 specified in the relevant RFC for that encapsulation (e.g. [RFC4717] 378 for ATM), applies to each segment. This section describes further 379 applicability considerations. 381 In comon with SS-PWs, the performance of any segment of a MS-PW is 382 equal to the performance of the PSN plus any impairments introduced 383 by the PW layer itself. Therefore it is not possible for the MS-PW to 384 provide better performance than the PSN over which it is transported. 385 Furthermore, the overall performance of an MS-PW is no better than 386 the worst performing segment of that MS-PW. 388 Since different PSN types may be able to achieve different maximum 389 performance objectives, it is necessary to carefully consider which 390 PSN types are used along the path of a MS-PW. 392 7. MPLS-PW to MPLS-PW Control Plane Switching 394 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 395 session as described in [RFC4447], at the same time a separate 396 pseudowire PW3 is setup to PE3. Each PW is configured independently 397 on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3. 398 PDUs are then switched between the pseudowires at the PW label level. 399 Hence the data plane does not need any special knowledge of the 400 specific pseudowire type. A simple standard MPLS label swap operation 401 is sufficient to connect the two PWs, and in this case the PW 402 adaptation function is not used. However when pushing a new PSN label 403 the TTL SHOULD be set to 255, or some other locally configured fixed 404 value. 406 This process can be repeated as many times as necessary, the only 407 limitation to the number of S-PEs traversed is imposed by the TTL 408 field of the PW MPLS Label. The setting of the TTL is a matter of 409 local policy on the originating PE, but SHOULD be set to 255. 411 There are three MPLS to MPLS PW control planes: 412 -i. Static configuration of the PW. 413 -ii. LDP using FEC 128 414 -iii. LDP using the generalized FEC 129 415 This results in four distinct PW switching situations that are 416 significantly different, and must be considered in detail: 417 -i. PW Switching between two static control planes. 418 -ii. Static Control plane switching to LDP dynamic control plane. 419 -iii. Two LDP control planes using the same FEC type 420 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 422 7.1. Static Control plane switching 424 In the case of two static control planes the S-PE MUST be configured 425 to direct the MPLS packets from one PW into the other. There is no 426 control protocol involved in this case. When one of the control 427 planes is a simple static PW configuration and the other control 428 plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static 429 control plane should be considered identical to an attachment circuit 430 (AC) in the reference model of Figure 1. The switching point PE 431 SHOULD signal the proper PW status if it detects a failure in sending 432 or receiving packets over the static PW segment. Because the PW is 433 statically configured, the status communicated to the dynamic LDP PW 434 will be limited to local interface failures. In this case, the S-PE 435 PE behaves in a very similar manner to a T-PE, assuming an active 436 role. This means that the S-PE will immediately send the LDP Label 437 Mapping message if the static PW is deemed to be UP. 439 7.2. Two LDP control planes using the same FEC type 441 As stated in a section above, the S-PE PE should assume an initial 442 passive role. This means that once independent PWs are configured on 443 the switching point, the LSR does not advertise the LDP PW FEC 444 mapping until it has received at least one of the two PW LDP FECs 445 from a remote PE. This is necessary because the switching point LSR 446 does not know a priori what the interface parameter field in the 447 initial FEC advertisement will contain. 449 The PWID is a unique number between each pair of PEs. Hence Each SS- 450 PW that forms an MS-PW may have a different PWID. In the case of The 451 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 452 some, or sometimes all, SS-PWs. 454 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 456 When a MS-PW is signaled using FEC 129, each T-PE might independently 457 start signaling the MS-PW. If the MS-PW path is not statically 458 configured, in certain cases the signaling procedure could result in 459 an attempt to setup each direction of the MS-PW through different 460 paths. To avoid this situation one of the T-PE MUST start the PW 461 signaling (active role), while the other waits to receive the LDP 462 label mapping before sending the respective PW LDP label mapping 463 message. (passive role). When the MS-PW path not statically 464 configured, the Active T-PE (the ST-PE) and the passive T-PE (the 465 TT-PE) MUST be identified before signaling is initiated for a given 466 MS-PW. 468 The determination of which T-PE assume the active role SHOULD be done 469 as follows: 471 The SAII and TAII are compared as unsigned integers, if the SAII is 472 bigger then the T-PE assumes the active role. 474 The selection process to determine which T-PE assumes the active role 475 MAY be superseded by manual provisioning. 477 7.3. LDP FEC 128 to LDP using the generalized FEC 129 479 When a PE is using the generalized FEC 129, there are two distinct 480 roles that a PE can assume: active and passive. A PE that assumes the 481 active role will send the LDP PW setup message, while a passive role 482 PE will simply reply to an incoming LDP PW setup message. The S-PE 483 PE, will always remain passive until a PWID FEC 128 LDP message is 484 received, which will cause the corresponding generalized PW FEC LDP 485 message to be formed and sent. If a generalized FEC PW LDP message is 486 received while the switching point PE is in a passive role, the 487 corresponding PW FEC 128 LDP message 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 S-PE configuration, or by 491 some other means, such as some form of auto discovery. Such other 492 means are outside the scope of this document. 494 7.4. LDP S-PE 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 S-PE TLV. 501 Note that sending the S-PE TLV is OPTIONAL, however the PE or S-PE 502 MUST process the TLV upon reception. The S-PE TLV is appended to the 503 PW FEC at each switching point. Each S-PE can append a PW switching 504 point TLV, and the order of the S-PE TLVs MUST be preserved. The S-PE 505 TLV MUST be sent if VCCV operation is required beyond the first MS-PW 506 segment from a T-PE. 508 The S-PE TLV is 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 S-PE TLV fields 526 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 encoded 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 S-PE. However the 627 following interface parameters MAY be modified as follows: 629 - 0x03 Optional Interface Description string This Interface 630 parameter MAY be modified, or altogether removed from the FEC 631 element depending on local configuration policies. 633 - 0x09 Fragmentation indicator This parameter MAY be inserted in 634 the FEC by the switching point if it is capable of re-assembly of 635 fragmented PW frames according to [RFC4623]. 637 - 0x0C VCCV parameter This Parameter contains the CC type , and CV 638 type bit fields. The CV type bit field MUST be reset to reflect 639 the CV type supported by the S-PE. CC type bit field MUST have 640 bit 1 "Type 2: MPLS Router Alert Label " set to 0. The other bit 641 fields MUST be reset to reflect the CC type supported by the S- 642 PE. 644 7.5. Group ID 646 The Group ID (GR ID) is used to reduce the number of status messages 647 that need to be sent by the PE advertising the PW FEC. The GR ID has 648 local significance only, and therefore MUST be mapped to a unique GR 649 ID allocated by the S-PE PE. 651 7.6. PW Loop Detection 653 A switching point PE SHOULD check the OPTIONAL PW switching Point 654 TLV, to verify if it's own IP address appears in it. If it's IP 655 address appears in a received PW switching Point TLV, the PE SHOULD 656 break the loop, and send a label release message with the following 657 error code: 658 Assignment E Description 659 0x0000003A 0 "PW Loop Detected" 661 [ note: error code pending IANA allocation ] 663 8. MPLS-PW to PW-L2TPv3 Control Plane Switching 665 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 666 four possibilities when switching between L2TPv3 and MPLS. 668 -i. Switching between MPLS and L2TPv3 static control planes. 669 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 670 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 671 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 673 8.1. Static MPLS and L2TPv3 PWs 675 In the case of two static control planes, the S-PE MUST be configured 676 to direct packets from one PW into the other. There is no control 677 protocol involved in this case. The configuration MUST include which 678 MPLS VC Label maps to which L2TPv3 Session ID (and associated Cookie, 679 if present) as well as which MPLS Tunnel Label maps to which PE 680 destination IP address. 682 8.2. Static MPLS PW and Dynamic L2TPv3 PW 684 When a statically configured MPLS PW is switched to a dynamic L2TPv3 685 PW, the static control plane should be considered identical to an 686 attachment circuit (AC) in the reference model of Figure 1. The 687 switching point PE SHOULD signal the proper PW status if it detects a 688 failure in sending or receiving packets over the static PW. Because 689 the PW is statically configured, the status communicated to the 690 dynamic L2TPv3 PW will be limited to local interface failures. In 691 this case, the S-PE PE behaves in a very similar manner to a T-PE, 692 assuming an active role. 694 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 696 When a statically configured L2TPv3 PW is switched to a dynamic 697 LDP/MPLS PW, then the static control plane should be considered 698 identical to an attachment circuit (AC) in the reference model of 699 Figure 1. The switching point PE SHOULD signal the proper PW status 700 (via an L2TPv3 SLI message) if it detects a failure in sending or 701 receiving packets over the static PW. Because the PW is statically 702 configured, the status communicated to the dynamic LDP/MPLS PW will 703 be limited to local interface failures. In this case, the S-PE PE 704 behaves in a very similar manner to a T-PE, assuming an active role. 706 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 708 When switching between dynamic PWs, the switching point always 709 assumes an initial passive role. Thus, it does not initiate an 710 LDP/MPLS or L2TPv3 PW until it has received a connection request 711 (Label Mapping or ICRQ) from one side of the node. Note that while 712 MPLS PWs are made up of two unidirectional LSPs bonded together by 713 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 714 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 715 Establishment, Tear Down, and PW Status signaling are detailed below. 717 8.4.1. Session Establishment 719 When the S-PE receives an L2TPv3 ICRQ message, the identifying AVPs 720 included in the message are mapped to FEC identifiers and sent in an 721 LDP label mapping message. Conversely, if an LDP Label Mapping 722 message is received, it is either mapped to an ICRP message or causes 723 an L2TPv3 session to be initiated by sending an ICRQ. 725 Following are two example exchanges of messages between LDP and 726 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 727 the second is a case where an MPLS T-PE initiates an MS-PW. 729 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 731 AC "Up" 732 L2TPv3 ICRQ ---> 733 LDP Label Mapping ---> 734 AC "UP" 735 <--- LDP Label Mapping 736 <--- L2TPv3 ICRP 737 L2TPv3 ICCN ---> 738 <-------------------- MH PW Established ------------------> 740 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 742 AC "Up" 743 LDP Label Mapping ---> 744 L2TPv3 ICRQ ---> 745 <--- L2TPv3 ICRP 746 <--- LDP Label Mapping 747 L2TPv3 ICCN ---> 748 AC "Up" 749 <-------------------- MH PW Established ------------------> 751 8.4.2. Adaptation of PW Status message 753 L2TPv3 uses the SLI message to indicate a interface status change 754 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 755 PWs either signal this via an LDP Label Withdraw or the PW Status 756 Notification message defined in section 4.4 of [RFC4447]. 758 8.4.3. Session Tear Down 760 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 761 message translates to a Label Withdraw message in LDP. Following are 762 two example exchanges of messages between LDP and L2TPv3. The first 763 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 764 the second is a case where an MPLS T-PE initiates the termination of 765 an MS-PW. 767 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 769 AC "Down" 770 L2TPv3 CDN ---> 771 LDP Label Withdraw ---> 772 AC "Down" 773 <-- LDP Label Release 775 <--------------- MH PW Data Path Down ------------------> 777 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 779 AC "Down" 780 LDP Label Withdraw ---> 781 L2TPv3 CDN --> 782 <-- LDP Label Release 783 AC "Down" 785 <---------------- MH PW Data Path Down ------------------> 787 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 789 [RFC4447] defines several interface parameters which MUST be mapped 790 to the equivalent AVPs in L2TPv3 setup messages. 792 * Interface MTU 794 The Interface MTU parameter is mapped directly to the L2TP 795 Interface MTU AVP defined in [RFC4667] 797 * Max Number of Concatenated ATM cells 799 This interface parameter is mapped directly to the L2TP "ATM 800 Maximum Concatenated Cells AVP" described in section 6 of 801 [RFC4454]. 803 * Optional Interface Description String 805 This string may be carried as the "Call-Information AVP" 806 described in section 2.2 of [L2TP-INFOMSG] 808 * PW Type 810 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 811 Type" AVP defined in [L2TPv3]. 813 * PW ID (FEC 128) 815 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 816 End ID" AVP defined in [L2TPv3]. 818 * Generalized FEC 129 SAI/TAI 820 Section 4.3 of [RFC4667] defines how to encode the SAI and TAI 821 parameters. These can be mapped directly. 823 Other interface parameter mappings will either be defined in a future 824 version of this document, or are unsupported when switching between 825 LDP/MPLS and L2TPv3 PWs. 827 8.6. Switching Point TLV in L2TPv3 829 When translating between LDP and L2TPv3 control messages, the PW 830 Switching Point TLV described earlier in this document is carried in 831 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 832 and optionally in the ICCN message. 834 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 835 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 836 the AVP is 6 plus the length of the series of Switching Point sub- 837 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 838 (the L2TP AVP M-bit MUST be 0). 840 8.7. L2TPv3 and MPLS PW Data Plane 842 When switching between an MPLS and L2TP PW, packets are sent in their 843 entirety from one PW to the other, replacing the MPLS label stack 844 with the L2TPv3 and IP header or vice versa. There are some 845 situations where an additional amount of interworking must be 846 provided between the two data planes at the PW switching node. 848 8.7.1. PWE3 Payload Convergence and Sequencing 850 Section 5.4 of [RFC3985] discusses the purpose of the various shim 851 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 852 For L2TPv3, the Payload Convergence and Sequencing function is 853 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 854 For MPLS, these two functions (together with PSN Convergence) are 855 carried out via the MPLS Control Word. Since these functions are 856 different between MPLS and L2TPv3, interworking between the two may 857 be necessary. 859 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 860 which in some cases are not necessary to be present at all. For 861 example, an Ethernet PW with sequencing disabled will generally not 862 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 863 be present at all. In this case, Ethernet frames are simply sent from 864 one PW to the other without any modification beyond the MPLS and 865 L2TP/IP encapsulation and decapsulation. 867 The following section offers guidelines for how to interwork between 868 L2TP and MPLS for those cases where the Payload Convergence, 869 Sequencing, or PSN Convergence functions are necessary on one or both 870 sides of the switching node. 872 8.7.2. Mapping 874 The MPLS Control Word consists of (from left to right): 876 -i. These bits are always zero in MPLS are not necessary to be 877 mapped to L2TP. 879 -ii. These six bits may be used for Payload Convergence depending 880 on the PW type. For ATM, the first four of these bits are 881 defined in [RFC4717]. These map directly to the bits defined 882 in [RFC4454]. For Frame Relay, these bits indicate how to 883 set the bits in the Frame Relay header which must be 884 regenerated for L2TP as it carries the Frame Relay header 885 intact. 887 -iii. L2TP determines its payload length from IP. Thus, this 888 Length field need not be carried directly to L2TP. This 889 Length field will have to be calculated and inserted for 890 MPLS when necessary. 892 -iv. The Default L2-Specific Sublayer has a sequence number with 893 different semantics than that of the MPLS Control Word. This 894 difference eliminates the possibility of supporting 895 sequencing across the MS-PW by simply carrying the sequence 896 number through the switching point transparently. As such, 897 sequence numbers MAY be supported by checking the sequence 898 numbers of packets arriving at the switching point and 899 regenerating a new sequence number in the proper format for 900 the PW on egress. If this type of sequence interworking at 901 the switching node is not supported, and a T-PE requests 902 sequencing of all packets via the L2TP control channel 903 during session setup, the switching node SHOULD NOT allow 904 the session to be established by sending a CDN message with 905 Result Code set to 17 "sequencing not supported" (subject to 906 IANA Assignment). 908 9. Operation And Management 910 9.1. Extensions to VCCV to Support MS-PWs 912 Single-hop pseudowires are signaled using the Virtual Circuit 913 Connectivity Verification (VCCV) parameter included in the interface 914 parameter field of the PW ID FEC TLV or the sub-TLV interface 915 parameter of the Generalized PW ID FEC TLV as described in [RFC5085]. 916 When a switching point exist between PE nodes, it is required to be 917 able to continue operating VCCV end-to-end across a switching point 918 and to provide the ability to trace the path of the MS-PW over any 919 number of segments. 921 This document provides a method for achieving these two objectives. 922 This method is based on re-using the existing VCCV CW and 923 decrementing the TTL of the PW label at each hop in the path of the 924 MS-PW. 926 9.2. MPLS-PW to MPLS-PW OAM Data Plane Indication 928 As stated above the S-PE MUST perform a standard MPLS label swap 929 operation on the MPLS PW label. By the rules defined in [RFC3032] the 930 PW label TTL MUST be decreased at every S-PE. Once the PW label TTL 931 reaches the value of 0, the packet is sent to the control plane to be 932 processed. Hence, by controlling the PW TTL value of the PW label it 933 is possible to select exactly which hop will respond to the VCCV 934 packet. 936 9.3. Signaling OAM Capabilities for Switched Pseudowires 938 Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV 939 parameter included in the interface parameter field of the PW ID FEC 940 TLV or the sub-TLV interface parameter of the Generalized PW ID FEC 941 TLV as described in [RFC5085]. 943 In Figure 3 T-PE1 uses the VCCV parameter included in the interface 944 parameter field of the PW ID FEC TLV or the sub-TLV interface 945 parameter of the Generalized PW ID FEC TLV to indicate to the far end 946 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 947 parameter as would be used if T-PE1 and T-PE2 were connected 948 directly. S-PE2, which is a PW switching point, as part of the 949 adaptation function for interface parameters, processes locally the 950 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 951 on the path between T-PE1 and T-PE2, each would carry out the same 952 processing, passing along the VCCV parameter. The local processing of 953 the VCCV parameter removes CC Types specified by the originating T-PE 954 that are not supported on the S-PE. For example, if T-PE1 indicates 955 supports CC Types 1,2,3 and the Then the S-PE removes the Router 956 Alert CC Type=2, leaving the rest of the TLV unchanged, and passes 957 the modified VCCV parameter to the next S-PE along the path. 959 The far end T-PE (T-PE2) receives the VCCV parameter indicating only 960 the CC types that are supported by the initial T-PE (T-PE1) and all 961 S-PEs along the PW path. 963 9.4. OAM Capability for MS-PWs Demultiplexed using MPLS 965 The VCCV parameter ID is defined as follows in [RFC4446]: 967 Parameter ID Length Description 968 0x0c 4 VCCV 970 The format of the VCCV parameter field is as follows: 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | 0x0c | 0x04 | CC Types | CV Types | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 0x01 Type 1: PWE3 control word with 0001b as first nibble 979 as defined in [RFC4385]. 980 0x02 Type 2: MPLS Router Alert Label. 981 0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3). 983 9.4.1. MS-PW and VCCV CC Type 1 985 VCCV CC type 1 can be used for MS-PWs. However, if the CW is enabled 986 on user packets, VCCV CC type 1 MUST be used according to the rules 987 in [RFC5085]. When using CC type 1 for MS-PWs the PE transmitting 988 the VCCV packet MUST set the TTL to the appropriate value to reach 989 the destination S-PE. However if the packet is destined for the T-PE, 990 the TTL can be set to any value that is sufficient for the packet to 991 reach the T-PE. 993 9.4.2. MS-PW and VCCV CC type 2 995 VCCV CC type 2 is not supported for MS-PWs and MUST be removed form a 996 VCCV parameter field by the S-PE. 998 9.4.3. MS-PW and VCCV CC type 3 1000 VCCV CC type 3 can be used for MS-PWs, however if the CW is enabled 1001 VCCV type 1 is preferred according to the rules in [RFC5085]. Note 1002 that for using the VCCV type 3, TTL method, the PE will set the PW 1003 label TTL to the appropriate value necessary to reach the target PE, 1004 otherwise the VCCV packet might be forwarded over the AC to the CPE. 1006 9.5. MS-PW VCCV Operations 1008 This document specifies four VCCV operations: 1009 -i. End-to-end MS-PW connectivity verification. This operation 1010 enables the connectivity of the MS-PW to be tested from 1011 source T-PE to destination T-PE. In order to do this, the 1012 sending T-PE must include the FEC used in the last segment 1013 of the MS-PW to the destination T-PE in the VCCV-Ping echo 1014 request. This information is either configured at the 1015 sending T-PE or is obtained by processing the corresponding 1016 sub-TLVs of the optional S-PE TLV, as described below. 1017 -ii. Partial MS-PW connectivity verification. This operation 1018 enables the connectivity of any contiguous subset of the 1019 segments of a MS-PW to be tested from the source T-PE or a 1020 source S-PE to a destination S-PE or T-PE. Again, the FEC 1021 used on the last segment to be tested must be included in 1022 the VCCV-Ping echo request message. This information is 1023 determined by the sending T-PE or S-PE as in (i) above. 1024 -iii. MS-PW path verification. This operation verifies the path of 1025 the MS-PW, as returned by the S-PE TLV, against the actual 1026 data path of the MS-PW. The sending T-PE or S-PE iteratively 1027 sends a VCCV echo request to each S-PE along the MS-PW path, 1028 using the FEC for the corresponding MS-PW segment in the 1029 switching point TLV. If the S-PE TLV information is correct, 1030 then a VCCV echo reply showing that this is a valid router 1031 for the FEC will be received. However, if the switching 1032 point TLV information is incorrect, then this operation 1033 enables the first incorrect switching point to be 1034 determined, but not the actual path of the MS-PW beyond 1035 that. This operation cannot be used when the MS-PW is 1036 statically configured or when the S-PE TLV is not suported. 1037 The processing of the PW switching TLV used for this 1038 operation is described below. This operation is OPTIONAL. 1039 -iv. MS-PW path trace. This operation traces the data path of the 1040 MS-PW using FECs included in the Target FEC stack TLV 1041 [RFC4379] returned by S-PEs or T-PEs in an echo reply 1042 message. The sending T-PE or S-PE uses this information to 1043 recursively test each S-PE along the path of the MS-PW in a 1044 single operation in a similar manner to LSP trace. This 1045 operation is able to determine the actual data path of the 1046 MS-PW, and can be used for both statically configured and 1047 signaled MS-PWs. Support for this operation is OPTIONAL. 1049 Note that the above operations rely on intermediate S-PEs and/or the 1050 destination T-PE to include the switching point TLV as a part of the 1051 MS-PW setup process, or to include the Target FEC stack TLV in the 1052 VCCV echo reply message. For various reasons, e.g. privacy or 1053 security of the S-PE/T-PE, this information may not be available to 1054 the source T-PE. In these cases, manual configuration of the FEC MAY 1055 still be used. 1057 9.5.1. VCCV Echo Message Processing 1059 The challenge for the control plane is to be able to build the VCCV 1060 echo request packet with the necessary information to reach the 1061 desired S-PE or T-PE, for example the target FEC 128 PW sub-TLV of 1062 the downstream PW segment that the packet is destined for. This could 1063 be even more difficult in situations in which the MS-PW spans 1064 different providers and Autonomous Systems. 1066 For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW1, 1067 but it does not readily have the information required to compose the 1068 FEC128 of the following segment, PW3, if a VCCV echo request to be 1069 sent to T-PE2. This can be achieved by the methods described in the 1070 following subsections. 1072 9.5.1.1. Sending a VCCV Echo Request 1074 When performing a partial or end-to-end connectivity or path 1075 verification, the sender of the echo request message requires the FEC 1076 of the last segment to the target S-PE/T-PE node. This information 1077 can either be configured manually or be obtained by inspecting the 1078 corresponding sub-TLV's of the PW switching point TLV. 1080 The necessary S-PE sub-TLVs are : 1082 Type Description 1083 0x01 PW ID of last PW segment traversed 1084 0x03 Local IP address of PW Switching Point 1085 0x04 Remote IP address of last PW Switching Point traversed or 1086 of the T-PE 1088 When performing an OPTIONAL MS-PW path trace operation, the T-PE will 1089 automatically learn the target FEC by probing, one by one, the hops 1090 of the MS-PW path, using the FEC returned in the Target FEC stack of 1091 the previous VCCV echo reply. 1093 9.5.1.2. Receiving a VCCV Echo Request 1095 Upon receiving a VCCV echo request the control plane on S-PEs (or the 1096 target node of each segment of the MS-PW) validates the request and 1097 responds to the request with an echo reply consisting of a return 1098 code of 8 (label switched at stack-depth) indicating that it is an 1099 S-PE and not the egress router for the MS-PW. 1101 S-PEs that wish to reveal their downstream next-hop in a trace 1102 operation should include the FEC of the downstream PW segment in the 1103 Target FEC stack (as per Sections 3.2 and 4.5 of [RFC4379]) of the 1104 echo reply message. FEC128 PWs MUST use the format shown in Section 1105 3.2.09 of [RFC4379] for the sub-TLV in the Target FEC stack, while 1106 FEC129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379] 1107 for the sub-TLV in the Target FEC stack. Note that an S-PE MUST NOT 1108 include this FEC information in the reply if it has been configured 1109 not to do so for administrative reasons, or for reasons explained 1110 previously. 1112 If the node is the T-PE or the egress node of the MS-PW, it responds 1113 to the echo request with an echo reply with a return code of 3 1114 (egress router). 1116 9.5.1.3. Receiving a VCCV Echo Reply 1118 The operation to be taken by the node receiving the echo reply in 1119 response to an echo request depends on the VCCV mode of operation 1120 described above. See Section 9.5.2 for detailed procedures. 1122 9.5.2. Detailed VCCV procedures 1124 9.5.2.1. End to End Connectivity Verification Between T-PEs 1126 In Figure 3, if T-PE1, S-PE and T-PE2 support Control Word , the PW 1127 control plane will automatically negotiate the use of the CW. VCCV CC 1128 type 3 will function correctly whether the CW is enable or not on the 1129 PW. However VCCV type 1 for (which can be use for end to end 1130 verification only), is only supported if the CW is enabled. 1132 At the S-PE the data path operations include an outer label pop, 1133 inner label swap and new outer label push. Note that there is no 1134 requirement for the S-PE to inspect the CW. Thus, the end-to-end 1135 connectivity of the multi-segment pseudowire can be verified by 1136 performing all of the following steps: 1137 -i. T-PE forms a VCCV-ping echo request message with the FEC 1138 matching that of the last segment PW to the destination T- 1139 PE. 1141 -ii. T-PE sets the inner PW label TTL to the exact value to allow 1142 the packet to reach the far end T-PE. ( the value is 1143 determined by counting the number of S-PEs from the control 1144 plane information ) Alternatively, if CC type 1 is supported 1145 the packet can be encapsulated according to CC type 1 in 1146 [RFC5085] 1148 -iii. T-PE sends a VCCV packet that will follow the exact same 1149 data path at each S-PE as that taken by data packets. 1151 -iv. S-PE may performs an outer label pop, if PHP is disabled, 1152 and will perform an inner label swap with TTL decrement, and 1153 new outer label push. 1155 -v. There is no requirement for the S-PE to inspect the CW. 1157 -vi. The VCCV packet is diverted to VCCV control processing at 1158 the destination T-PE. 1160 -vii. Destination T-PE replies using the specified reply mode, 1161 i.e., reverse PW path or IP path. 1163 9.5.2.2. Partial Connectivity Verification from T-PE 1165 In order to trace part of the multi-segment pseudowire, the TTL of 1166 the PW label may be used to force the VCCV message to 'pop out' at an 1167 intermediate node. When the TTL expires, the S-PE can determine that 1168 the packet is a VCCV packet by either checking the control word (CW) 1169 , or if the CW is not in use by checking for a valid IP header with 1170 UDP destination port 3503. The packet should then be diverted to 1171 VCCV processing. 1173 In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW 1174 label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus 1175 verify the first segment of the pseudowire. 1177 The VCCV packet is built according to [RFC4379] section 3.2.9 for FEC 1178 128, or 3.2.10 for a FEC 129 PW. All the information necessary to 1179 build the VCCV LSP ping packet is collected by inspecting the S-PE 1180 TLVs. 1182 Note that this use of the TTL is subject to the caution expressed in 1183 [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and 1184 a T-PE manipulates the PW label TTL, the VCCV message may not emerge 1185 from the MS-PW at the correct S-PE. 1187 9.5.2.3. Partial connectivity verification between S-PEs 1189 Assuming that all nodes along an MS-PW support the Control Word CC 1190 Type 3, VCCV between S-PEs may be accomplished using the PW label TTL 1191 as described above. In Figure 3, the S-PE may verify the path between 1192 it and T-PE2 by sending a VCCV message with the PW label TTL set to 1193 1. Given a more complex network with multiple S-PEs, an S-PE may 1194 verify the connectivity between it and an S-PE two segments away by 1195 sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE 1196 can diagnose connectivity problems by successively increasing the 1197 TTL. All the information needed to build the proper VCCV echo 1198 request packet as described in [RFC4379] section 3.2.9 or 3.2.10 is 1199 obtained automatically from the LDP label mapping that contains S-PE 1200 TLVs. 1202 9.5.2.4. MS-PW Path Verification 1204 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1205 originating from T-PE1 by a single operational command. The following 1206 process ensues: 1207 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1208 containing the pseudowire information of the first segment 1209 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1210 Stack Validation is enabled, the request may also include 1211 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1212 dependent on the type of transport tunnel the segmented PW 1213 is riding on. 1215 -ii. S-PE validates the echo request with the FEC. Since it is a 1216 switching point between the first and second segment it 1217 builds an echo reply with a return code of 8 and sends the 1218 echo reply back to T-PE1. 1220 -iii. T-PE1 builds a second VCCV echo request based on the 1221 infomation obtained from the control plane (S-PE TLV). It 1222 then increments the TTL and sends it out to T-PE2. Note that 1223 the VCCV echo request packet is switched at the S-PE 1224 datapath and forwarded to the next downstream segment 1225 without any involvement from the control plane. 1227 -iv. T-PE2 receives and validates the echo request with the FEC. 1228 Since T-PE2 is the destination node or the egress node of 1229 the MS-PW it replies to T-PE1 with an echo reply with a 1230 return code of 3 (Egress Router). 1232 -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1233 aware that T-PE2 is the destination of the MS-PW because the 1234 echo reply has a return code of is 3. The trace process is 1235 completed. 1237 If no echo reply is received, or an error code is received from a 1238 particular PE, the trace process MUST stop immediately, and no 1239 packets MUST be sent further along the MS-PW. 1241 For more detail on the format of the VCCV echo packet, refer to 1242 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1243 (PW) label TTL. 1245 9.5.2.5. MS-PW Path Trace 1247 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1248 originating from T-PE1 by a single operational command. The following 1249 OPTIONAL process ensues: 1251 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1252 containing the pseudowire information of the first segment 1253 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1254 Stack Validation is enabled, the request may also include 1255 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1256 dependent on the type of transport tunnel the segmented PW 1257 is riding on. 1259 -ii. The S-PE validates the echo request with the FEC. 1261 -iii. The S-PE builds an echo reply with a return code of 8 and 1262 sends the echo reply back to T-PE1, appending the FEC128 1263 information for the next segment along the MS-PW to the VCCV 1264 echo reply packet using the Target FEC stack TLV (as per 1265 Sections 3.2 and 4.5 of [RFC4379]). 1267 -iv. T-PE1 builds a second VCCV echo request based on the 1268 infomation obtained from the FEC stack TLV received in the 1269 previous VCCV echo reply. It then increments the TTL and 1270 sends it out to T-PE2. Note that the VCCV echo request 1271 packet is switched at the S-PE datapath and forwarded to the 1272 next downstream segment without any involvement from the 1273 control plane. 1275 -v. T-PE2 receives and validates the echo request with the FEC. 1276 Since T-PE2 is the destination node or the egress node of 1277 the MS-PW it replies to T-PE1 with an echo reply with a 1278 return code of 3 (Egress Router). 1280 -vi. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1281 aware that T-PE2 is the destination of the MS-PW because the 1282 echo reply has a return code of is 3. The trace process is 1283 completed. 1285 If no echo reply is received, or an error code is received from a 1286 particular PE, the trace process MUST stop immediately, and no 1287 packets MUST be sent further along the MS-PW. 1289 For more detail on the format of the VCCV echo packet, refer to 1290 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1291 (PW) label TTL. 1293 10. Mapping Switched Pseudowire Status 1295 In the PW switching with attachment circuits case (Figure 2), PW 1296 status messages indicating PW or attachment circuit faults MUST be 1297 mapped to fault indications or OAM messages on the connecting AC as 1298 defined in [PW-MSG-MAP]. 1300 In the PW control plane switching case (Figure 3), there is no 1301 attachment circuit at the S-PE, but the two PWs are connected 1302 together. Similarly, the status of the PWs are forwarded unchanged 1303 from one PW to the other by the control plane switching function. 1304 However, it may sometimes be necessary to communicate fault status of 1305 one of the locally attached SS-PW at a S-PE. For LDP this can be 1306 accomplished by sending an LDP notification message containing the PW 1307 status TLV, as well as an OPTIONAL PW switching point TLV as follows: 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 |0| Notification (0x0001) | Message Length | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Message ID | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 |0|1| Status (0x0300) | Length | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 |0|1| Status Code=0x00000028 | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Message ID=0 | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Message Type=0 | PW Status TLV | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | PW Status TLV | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | PW Status TLV | PWId FEC | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | | 1329 | | 1330 | PWId FEC or Generalized ID FEC | 1331 | | 1332 | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Type | Length | Variable Length Value | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 Only one S-PE TLV can be present in this message. This message is 1340 then relayed by each S-PE unchanged. The T-PE decodes the status 1341 message and the included S-PE TLV to detect exactly where the fault 1342 occurred. At the T-PE if there is no S-PE TLV included in the LDP 1343 status notification then the status message can be assumed to have 1344 originated at the remote T-PE. 1346 The merging of the received LDP status and the local status for the 1347 PW segments at an S-PE can be summarized as follows: 1349 -i. When the local status for both PW segments is UP, the S-PE 1350 passes any received AC or PW status bits unchanged, i.e., 1351 the status notification TLV is unchanged but the PWid in the 1352 case of a FEC 128 TLV is set to the value of the PW segment 1353 of the next hop. 1355 -ii. When the local status for any of the PW segments is at 1356 fault, the S-PE always sends the local status bits 1357 regardless if the received status bits from the remote node 1358 indicated that an upstream fault has cleared. AC status bit 1359 are passed along unchanged. 1361 10.1. S-PE initiated PW status messages 1363 The PW fault directions are defined as follows: 1365 +-------+ 1366 ---PW1 receive---->| |-----PW2 Transmit----> 1367 S-PE1 | S-PE2 | S-PE3 1368 <--PW1 Transmit----| |<----PW2 Receive------ 1369 +-------+ 1371 When a local fault is detected by the S-PE, a PW status message is 1372 sent in both directions along the PW. Since there are no attachment 1373 circuits on an S-PE, only the following status messages are relevant: 1375 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1376 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1378 Each S-PE needs to store only two 32-bit PW status words for each 1379 SS-PW: One for local failures , and one for remote failures (normally 1380 received from another PE). The first failure will set the appropriate 1381 bit in the 32-bit status word, and each subsequent failure will be 1382 ORed to the appropriate PW status word. In the case of the PW status 1383 word storing remote failures, this rule has the effect of a logical 1384 OR operation with the first failure received on the particular SS-PW. 1386 It should be noted that remote failures received on an S-PE are just 1387 passed along the MS-PW unchanged while local failures detected an an 1388 S-PE are signalled on both SS-PWs. 1390 A T-PE can receive multiple failures from S-PEs along the MH-PW, 1391 however only the failure from the remote closest S-PE will be stored 1392 (last pw status message received). The PW status word received are 1393 just ORed to any existing remote PW status already stored on the T- 1394 PE. 1396 Given that there are two SS-PW at a particular S-PE for a particular 1397 MH-PW, there are for possible failure cases as follows: 1399 -i. PW2 Transmit direction fault 1400 -ii. PW1 Transmit direction fault 1401 -iii. PW2 Receive direction fault 1402 -iv. PW1 Receive direction fault 1404 Once a PW status notification message is initiated at a S-PE for a 1405 particular PW status bit any further status message, for the same 1406 status bit, received from an upstream neighbor is processed locally 1407 and not forwarded until the S-PE original status error state is 1408 cleared. 1410 Each S-PE along the MS-PW MUST store any PW status messages 1411 transiting it. If more then one status message with the same PW 1412 status bit set is received by a T-PE, or S-PE only the last PW 1413 status message is stored. 1415 10.1.1. Local PW2 transmit direction fault 1417 When this failure occurs the S-PE will take the following actions: 1419 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1420 PSN-facing PW (egress) Transmit Fault" 1421 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1422 PSN-facing PW (ingress) Receive Fault" 1423 * Store 0x00000010 in the local PW status word for the SS-PW toward 1424 S-PE3. 1426 10.1.2. Local PW1 transmit direction fault 1428 When this failure occurs the S-PE will take the following actions: 1430 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1431 PSN-facing PW (egress) Transmit Fault" 1432 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1433 PSN-facing PW (ingress) Receive Fault" 1434 * Store 0x00000010 in the local PW status word for the SS-PW toward 1435 S-PE1. 1437 10.1.3. Local PW2 receive direction fault 1439 When this failure occurs the S-PE will take the following actions: 1440 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1441 PSN-facing PW (ingress) Receive Fault" 1442 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1443 PSN-facing PW (egress) Transmit Fault" 1444 * Store 0x00000008 in the local PW status word for the SS-PW toward 1445 S-PE3. 1447 10.1.4. Local PW1 receive direction fault 1449 When this failure occurs the S-PE will take the following actions: 1450 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1451 PSN-facing PW (ingress) Receive Fault" 1452 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1453 PSN-facing PW (egress) Transmit Fault" 1454 * Store 0x00000008 in the local PW status word for the SS-PW toward 1455 S-PE1. 1457 10.1.5. Clearing Faults 1459 Remote PW status fault clearing messages received by an S-PE will 1460 only be forwarded if there are no corresponding local faults on the 1461 S-PE. (local faults always supersede remote faults) 1463 Once the local fault has cleared, and there is no corresponding (same 1464 PW status bit set) remote fault, a PW status messages is sent out to 1465 the adjacent PEs clearing the fault. 1467 When a PW status fault clearing message is forwarded, the S-PE will 1468 always send the S-PE TLV associated with the PE which cleared the 1469 fault. 1471 10.2. PW status messages and S-PE TLV processing 1473 When a PW status message is received that includes a S-PE TLV, the 1474 S-PE TLV information MAY be stored, along with the contents of the PW 1475 status Word according to the procedures described above. The S-PE TLV 1476 stored is always the S-PE TLV that is associated with the PE that set 1477 that particular last fault. If subsequent PW status message for the 1478 same PW status bit are received the S-PE TLV will overwrite the 1479 previously stored S-PE TLV. 1481 10.3. T-PE processing of PW status messages 1483 The PW switching architecture is based on the concept that the T-PE 1484 should process the PW LDP messages in the same manner as if it was 1485 participating in the setup of a SS-PW. However T-PE participating a 1486 MS-PW, SHOULD be able to process the S-PE TLV. Otherwise the 1487 processing of PW status messages , and other PW setup messages is 1488 exactly as described in [RFC4447]. 1490 10.4. Pseudowire Status Negotiation Procedures 1492 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1493 be transparent to the switching point. 1495 10.5. Status Dampening 1497 When the PW control plane switching methodology is used to cross an 1498 administrative boundary it might be necessary to prevent excessive 1499 status signaling changes from being propagated across the 1500 administrative boundary. This can be achieved by using a similar 1501 method as commonly employed for the BGP protocol route advertisement 1502 dampening. The details of this OPTIONAL algorithm are a matter of 1503 implementation, and are outside the scope of this document. 1505 11. Peering Between Autonomous Systems 1507 The procedures outlined in this document can be employed to provision 1508 and manage MS-PWs crossing AS boundaries. The use of more advanced 1509 mechanisms involving auto-discovery and ordered PWE3 MS-PW signaling 1510 will be covered in a separate document. 1512 12. Security Considerations 1514 This document specifies the LDP and L2TPv3 extensions that are needed 1515 for setting up and maintaining pseudowires. The purpose of setting up 1516 pseudowires is to enable layer 2 frames to be encapsulated and 1517 transmitted from one end of a pseudowire to the other. Therefore we 1518 treat the security considerations for both the data plane and the 1519 control plane. 1521 12.1. Data Plane Security 1523 Data plane security consideration as discussed in [RFC4447], 1524 [L2TPv3], and [RFC3985] apply to this extension without any changes. 1526 12.1.1. VCCV Security considerations 1528 The VCCV technology for MS-PW offers a method for the service 1529 provider to verify the data path of a specific PW. This involves 1530 sending a packet to a specific PE and receiving an answer which 1531 either confirms , or indicates that the information contained in the 1532 packet is incorrect. This is a very similar process to the commonly 1533 used IP ICMP ping , and TTL expired methods for IP networks. It 1534 should be noted that when using VCCV Type 3 for PW when the CW is not 1535 enabled, if a packet is crafted with a TTL greater then the number of 1536 hops along the MS-PW path, or an S-PE along the path mis-processes 1537 the TTL, the packet could mistakenly be forwarded out the attachment 1538 circuit as a native PW packet. This packet would most likely be 1539 treated as an error packet by the CE. However if this possibility is 1540 not acceptable, the CW should be enabled to guarantee that a VCCV 1541 packet will never be mistakenly forwarded to the AC. 1543 12.2. Control Protocol Security 1545 General security considerations with regard to the use of LDP are 1546 specified in section 5 of RFC 3036. Security considerations with 1547 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1548 considerations apply as well to the case where LDP or L2TPv3 is used 1549 to set up PWs. 1551 A Pseudowire connects two attachment circuits. It is important to 1552 make sure that LDP connections are not arbitrarily accepted from 1553 anywhere, or else a local attachment circuit might get connected to 1554 an arbitrary remote attachment circuit. Therefore an incoming session 1555 request MUST NOT be accepted unless its IP source address is known to 1556 be the source of an "eligible" peer. The set of eligible peers could 1557 be pre-configured (either as a list of IP addresses, or as a list of 1558 address/mask combinations), or it could be discovered dynamically via 1559 an auto-discovery protocol which is itself trusted. (Obviously if the 1560 auto-discovery protocol were not trusted, the set of "eligible peers" 1561 it produces could not be trusted.) 1563 Even if a connection request appears to come from an eligible peer, 1564 its source address may have been spoofed. So some means of 1565 preventing source address spoofing must be in place. For example, if 1566 all the eligible peers are in the same network, source address 1567 filtering at the border routers of that network could eliminate the 1568 possibility of source address spoofing. 1570 For a greater degree of security, the LDP MD5 authentication key 1571 option, as described in section 2.9 of RFC 3036, or the Control 1572 Message Authentication option of [L2TPv3] MAY be used. This provides 1573 integrity and authentication for the control messages, and eliminates 1574 the possibility of source address spoofing. Use of the message 1575 authentication option does not provide privacy, but privacy of 1576 control messages are not usually considered to be highly urgent. 1577 Both the LDP and L2TPv3 message authentication options rely on the 1578 configuration of pre-shared keys, making it difficult to deploy when 1579 the set of eligible neighbors is determined by an auto-configuration 1580 protocol. 1582 When the Generalized ID FEC Element is used, it is possible that a 1583 particular peer may be one of the eligible peers, but may not be the 1584 right one to connect to the particular attachment circuit identified 1585 by the particular instance of the Generalized ID FEC element. 1586 However, given that the peer is known to be one of the eligible peers 1587 (as discussed above), this would be the result of a configuration 1588 error, rather than a security problem. Nevertheless, it may be 1589 advisable for a PE to associate each of its local attachment circuits 1590 with a set of eligible peers, rather than having just a single set of 1591 eligible peers associated with the PE as a whole. 1593 13. IANA Considerations 1595 13.1. L2TPv3 AVP 1597 This document uses a ne L2TP parameter, IANA already maintains a 1598 registry of name "Control Message Attribute Value Pair" defined by 1599 [RFC3438]. The following new values are required: 1601 TBA-L2TP-AVP-1 - PW Switching Point AVP 1603 13.2. LDP TLV TYPE 1605 This document uses several new LDP TLV types, IANA already maintains 1606 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1607 following value is suggested for assignment: 1609 TLV type Description 1610 0x096D Pseudowire Switching TLV 1612 13.3. LDP Status Codes 1614 This document uses several new LDP status codes, IANA already 1615 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1616 RFC3036. The following value is suggested for assignment: 1618 Assignment E Description 1619 0x0000003A 0 "PW Loop Detected" 1621 13.4. L2TPv3 Result Codes 1623 This document uses several new L2TPv3 status codes, IANA already 1624 maintains a registry of name "L2TPv3 Result Codes" defined by 1625 RFCxxxx. The following value is suggested for assignment: 1627 Assignment Description 1628 17 "sequencing not supported" 1630 13.5. New IANA Registries 1632 IANA needs to set up a registry of "PW Switching Point TLV Type". 1633 These are 8-bit values. Types value 1 through 3 are defined in this 1634 document. Type values 4 through 64 are to be assigned by IANA using 1635 the "Expert Review" policy defined in RFC5226. Type values 65 through 1636 127, 0 and 255 are to be allocated using the IETF consensus policy 1637 defined in [RFC5226]. Types values 128 through 254 are reserved for 1638 vendor proprietary extensions and are to be assigned by IANA, using 1639 the "First Come First Served" policy defined in RFC5226. 1641 The Type Values are assigned as follows: 1643 Type Length Description 1645 0x01 4 PW ID of last PW segment traversed 1646 0x02 variable PW Switching Point description string 1647 0x03 4/16 Local IP address of PW Switching Point 1648 0x04 4/16 Remote IP address of last PW Switching Point traversed 1649 or of the T-PE 1650 0x05 variable AI of last PW segment traversed 1651 0x06 10 L2 PW address of PW Switching Point 1653 14. Normative References 1655 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1656 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1657 RFC4385, February 2006. 1659 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1660 mulation (PWE3)", L. Martini, RFC4446, April 2006. 1662 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 1663 et al., rfc4447 April 2006. 1665 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, E, 1666 Rekhter, Y., RFC4364, February 2006 1667 October 2004. 1669 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1670 M. Townsley, I. Goyret, RFC3931 1672 [RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1673 Verification (VCCV), A Control Channel for Pseudowires", 1674 RFC5085 December 2007. 1676 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1677 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 1679 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1680 Requirement Levels", BCP 14, RFC 2119, March 1997. 1682 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 1683 Individual Identifier (AII) Types for Aggregation", RFC5003, 1684 September 2007. 1685 [RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol 1686 Label Switched (MPLS) Data Plane Failures", RFC4379, 1687 September 2007 1689 15. Informative References 1691 [RFC3985] Stewart Bryant, et al., PWE3 Architecture, 1692 RFC3985 1694 [RFC4023] "Encapsulating MPLS in IP or Generic 1695 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1696 RFC4023, March 2005. 1698 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture" 1699 Bryant, et al., RFC 3985, March 2005. 1701 [RFC4623] "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation 1702 and Reassembly", A. Malis, W. M. Townsley, RFC 4623, August 2006 1704 [RFC4667] "Layer 2 Virtual Private Network (L2VPN) 1705 Extensions for Layer 2 Tunneling Protocol (L2TP)", Luo, Wei, 1706 RFC4667, W. Luo, September 2006 1708 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1709 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1710 ( work in progress ), July 2004 1712 [RFC4454] "Asynchronous Transfer Mode (ATM) over Layer 2 1713 Tunneling Protocol Version 3 (L2TPv3)", Singh, Townsley, 1714 Pignataro, RFC4454, May 2006 1715 ( work in progress ), March 2004. 1717 [RFC4717] "Encapsulation Methods for Transport of (ATM) 1718 MPLS Networks", Martini et al., RFC4717, December 2006 1720 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1721 (L2TP) Internet" 1723 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1724 draft-ietf-pwe3-oam-msg-map-08.txt, ( work in progress ), 1725 November 2008 1727 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data 1728 Plane Failures", RFC4379, February 2006. 1730 [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001 1732 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire Emulation 1733 Edge-to-Edge", Bocci et al, draft-ietf-pwe3-ms-pw-arch-05.txt 1734 September 2008 1736 [RFC5254] "Requirements for Multi-Segment Pseudowire Emulation 1737 Edge-to-Edge (PWE3)", N. Bitar, M. Bocci, L. Martini, RFC5254, 1738 October 2008 1740 16. Author's Addresses 1742 Luca Martini 1743 Cisco Systems, Inc. 1744 9155 East Nichols Avenue, Suite 400 1745 Englewood, CO, 80112 1746 e-mail: lmartini@cisco.com 1748 Thomas D. Nadeau 1749 BT 1750 BT Centre 1751 81 Newgate Street 1752 London, EC1A 7AJ 1753 United Kingdom 1754 e-mail: tom.nadeau@bt.com 1756 Chris Metz 1757 Cisco Systems, Inc. 1758 e-mail: chmetz@cisco.com 1760 Mike Duckett 1761 Bellsouth 1762 Lindbergh Center 1763 D481 1764 575 Morosgo Dr 1765 Atlanta, GA 30324 1766 e-mail: mduckett@bellsouth.net 1768 Matthew Bocci 1769 Alcatel-Lucent 1770 Grove House, Waltham Road Rd 1771 White Waltham, Berks, UK. SL6 3TN 1772 e-mail: matthew.bocci@alcatel-lucent.co.uk 1773 Florin Balus 1774 Alcatel-Lucent 1775 701 East Middlefield Rd. 1776 Mountain View, CA 94043 1777 e-mail: florin.balus@alcatel-lucent.com 1779 Mustapha Aissaoui 1780 Alcatel-Lucent 1781 600, March Road, 1782 Kanata, ON, Canada 1783 e-mail: mustapha.aissaoui@alcatel-lucent.com 1785 Full Copyright Statement 1787 Copyright (c) 2009 IETF Trust and the persons identified as the 1788 document authors. All rights reserved. 1790 This document is subject to BCP 78 and the IETF Trust's Legal 1791 Provisions Relating to IETF Documents in effect on the date of 1792 publication of this document (http://trustee.ietf.org/licenseinfo). 1793 Please review these documents carefully, as they describe your rights 1794 and restrictions with respect to this document. 1796 This document may contain material from IETF Documents or IETF 1797 Contributions published or made publicly available before November 1798 10, 2008. The person(s) controlling the copyright in some of this 1799 material may not have granted the IETF Trust the right to allow 1800 modifications of such material outside the IETF Standards Process. 1801 Without obtaining an adequate license from the person(s) controlling 1802 the copyright in such materials, this document may not be modified 1803 outside the IETF Standards Process, and derivative works of it may 1804 not be created outside the IETF Standards Process, except to format 1805 it for publication as an RFC or to translate it into languages other 1806 than English. 1808 Acknowledgments 1810 The authors wish to acknowledge the contributions of Satoru 1811 Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, 1812 and Tiberiu Grigoriu. 1814 Expiration Date: August 2009