idnits 2.17.1 draft-ietf-pwe3-segmented-pw-13.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (August 14, 2009) is 5361 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) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-10 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-06 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Chris Metz 4 Expiration Date: February 2010 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 August 14, 2009 14 Segmented Pseudowire 16 draft-ietf-pwe3-segmented-pw-13.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: February 2010 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 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 Switching Point 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 L2TPv3-PW 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 Mapping the MPLS Control Word to L2TP ................ 21 80 9 Operation And Management ............................. 22 81 9.1 Extensions to VCCV to Support MS-PWs ................. 22 82 9.2 MPLS-PW to MPLS-PW OAM Data Plane Indication ......... 22 83 9.3 Signaling OAM Capabilities for Switched Pseudowires .. 23 84 9.4 OAM Capability for MS-PWs Demultiplexed using MPLS ... 23 85 9.4.1 MS-PW and VCCV CC Type 1 ............................. 24 86 9.4.2 MS-PW and VCCV CC type 2 ............................. 24 87 9.4.3 MS-PW and VCCV CC type 3 ............................. 24 88 9.5 MS-PW VCCV Operations ................................ 24 89 9.5.1 VCCV Echo Message Processing ......................... 25 90 9.5.1.1 Sending a VCCV Echo Request .......................... 26 91 9.5.1.2 Receiving a VCCV Echo Request ........................ 26 92 9.5.1.3 Receiving a VCCV Echo Reply .......................... 27 93 9.5.2 Detailed VCCV procedures ............................. 27 94 9.5.2.1 End to End Connectivity Verification Between T-PEs ... 27 95 9.5.2.2 Partial Connectivity Verification from T-PE .......... 28 96 9.5.2.3 Partial connectivity verification between S-PEs ...... 28 97 9.5.2.4 MS-PW Path Verification .............................. 29 98 9.5.2.5 MS-PW Path Trace ..................................... 30 99 10 Mapping Switched Pseudowire Status ................... 31 100 10.1 S-PE initiated PW status messages .................... 32 101 10.1.1 Local PW2 transmit direction fault ................... 33 102 10.1.2 Local PW1 transmit direction fault ................... 34 103 10.1.3 Local PW2 receive direction fault .................... 34 104 10.1.4 Local PW1 receive direction fault .................... 34 105 10.1.5 Clearing Faults ...................................... 34 106 10.2 PW status messages and S-PE TLV processing ........... 35 107 10.3 T-PE processing of PW status messages ................ 35 108 10.4 Pseudowire Status Negotiation Procedures ............. 35 109 10.5 Status Dampening ..................................... 35 110 11 Peering Between Autonomous Systems ................... 35 111 12 Security Considerations .............................. 36 112 12.1 Data Plane Security .................................. 36 113 12.1.1 VCCV Security considerations ......................... 36 114 12.2 Control Protocol Security ............................ 36 115 13 IANA Considerations .................................. 37 116 13.1 L2TPv3 AVP ........................................... 37 117 13.2 LDP TLV TYPE ......................................... 38 118 13.3 LDP Status Codes ..................................... 38 119 13.4 L2TPv3 Result Codes .................................. 38 120 13.5 New IANA Registries .................................. 38 121 14 Normative References ................................. 39 122 15 Informative References ............................... 40 123 16 Author's Addresses ................................... 41 125 1. Specification of Requirements 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. Terminology 133 - PW Terminating Provider Edge (T-PE). A PE where the customer- 134 facing attachment circuits (ACs) are bound to a PW forwarder. A 135 Terminating PE is present in the first and last segments of a 136 MS-PW. This incorporates the functionality of a PE as defined in 137 [RFC3985]. 139 - Single-Segment Pseudowire (SS-PW). A PW setup directly between 140 two T-PE devices. Each PW in one direction of a SS-PW traverses 141 one PSN tunnel that connects the two T-PEs. 143 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 144 configured set of two or more contiguous PW segments that behave 145 and function as a single point-to-point PW. Each end of a MS-PW 146 by definition MUST terminate on a T-PE. 148 - PW Segment. A part of a single-segment or multi-segment PW, which 149 traverses one PSN tunnel in each direction between two PE 150 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 The PWE3 Architecture [RFC3985], defines the signaling and 160 encapsulation techniques for establishing SS-PWs between a pair of 161 terminating PEs and in the vast majority of cases this will be 162 sufficient. MS-PWs are most useful in two general cases: 164 -i. When it is not possible, desirable or feasible to establish 165 a PW control channel between the terminating source and 166 destination PEs. At a minimum PW control channel 167 establishment requires knowledge of and reachability to the 168 remote (terminating) PE IP address. The local (terminating) 169 PE may not have access to this information related to 170 topology, operational or security constraints. 172 An example is the inter-AS L2VPN scenario where the 173 terminating PEs reside in different provider networks (ASes) 174 and it is the practice to cryptogtaphiclly sign all control 175 traffic exchanged between two networks. Technically a SS-PW 176 could be used but this would require tp cryptogtaphiclly 177 sign on ALL terminating source and destination PE nodes. An 178 MS-PW allows the providers to confine MD5 key administration 179 to just the PW switching points connecting the two domains. 181 A second example might involve a single AS where the PW 182 setup path between the terminating 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 terminating PE-A and PE-C. 187 The external entity computes a PW setup path that passes 188 through PE-B. This results in two discrete PW segments being 189 built: one between PE-A and PE-B and one between PE-B and 190 PE-C. The successful client-layer L2 connection between 191 terminating PE-A and terminating PE-C requires that PE-B 192 performs the PWE3 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 terminating 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 terminating 214 PEs 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 224 -iii. LDP using the generalized FEC 129 225 -iv. L2TPv3 227 4. General Description 229 A pseudowire (PW) is a mechanism that carries the essential elements 230 of an emulated service from one PE to one or more other PEs over a 231 PSN as described in Figure 1 and in [RFC3985]. Many providers have 232 deployed PWs as a means of migrating existing (or building new) L2VPN 233 services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN. 235 PWs may span multiple autonomous systems of the same or different 236 provider networks. In these scenarios PW control channels (i.e. 237 targeted LDP, L2TPv3) and PWs will cross AS boundaries. 239 Inter-AS L2VPN functionality is currently supported and several 240 techniques employing MPLS encapsulation and LDP signaling have been 241 documented [RFC4364]. It is also straightforward to support the same 242 inter-AS L2VPN functionality employing L2TPv3. In this document we 243 define methodology to switch a PW between two PW control planes. 245 |<-------------- Emulated Service ---------------->| 246 | | 247 | |<-------- Pseudowire ------>| | 248 | | | | 249 | | |<-- PSN Tunnel -->| | | 250 | V V V V | 251 V AC +----+ +----+ AC V 252 +-----+ | | PE1|==================| PE2| | +-----+ 253 | |----------|............PW1.............|----------| | 254 | CE1 | | | | | | | | CE2 | 255 | |----------|............PW2.............|----------| | 256 +-----+ ^ | | |==================| | | ^ +-----+ 257 ^ | +----+ +----+ | | ^ 258 | | Provider Edge 1 Provider Edge 2 | | 259 | | | | 260 Customer | | Customer 261 Edge 1 | | Edge 2 262 | | 263 native service native service 265 Figure 1: PWE3 Reference Model 267 There are two methods for switching a PW between two PW control 268 planes. In the first method (Figure 2), the two control planes 269 terminate on different PEs. 271 |<-------Multi-Segment Pseudowire------->| 272 | PSN PSN | 273 AC | |<-1->| |<-2->| | AC 274 | V V V V V V | 275 | +----+ +-----+ +----+ +----+ | 276 +----+ | | |=====| | | |=====| | | +----+ 277 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 278 | CE1| | | | | | | | | | | |CE2 | 279 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 280 +----+ | | |=====| | | |=====| | | +----+ 281 ^ +----+ +-----+ +----+ +----+ ^ 282 | PE1 PE2 PE3 PE4 | 283 | ^ ^ | 284 | | | | 285 | PW stitching points | 286 | | 287 | | 288 |<-------------------- Emulated Service ---------------->| 290 Figure 2: PW Switching using ACs Reference Model 292 In Figure 2, pseudowires in two separate PSNs are stitched together 293 using native service attachment circuits. PE2 and PE3 only run the 294 control plane for the PSN to which they are directly attached. At PE2 295 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 296 while PW3 and PW4 are connected using attachment circuit AC2. 298 Native |<------Multi-Segment Pseudowire------>| Native 299 Service | PSN PSN | Service 300 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 301 | V V 1 V V 2 V V | 302 | +----+ +-----+ +----+ | 303 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 304 | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| | 305 | CE1| | | | | | | | | |CE2 | 306 | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| | 307 +----+ | | |===========| |==========| | | +----+ 308 ^ +----+ +-----+ +----+ ^ 309 | Provider Edge 1 ^ Provider Edge 2 | 310 | | | 311 | | | 312 | PW switching point | 313 | | 314 |<------------------ Emulated Service --------------->| 316 Figure 3: PW Control Plane Switching Reference Model 318 In Figure 3 SPE1 runs two separate control planes: one toward TPE1, 319 and one Toward TPE2. The PW switching point (S-PE) is configured to 320 connect PW Segment 1 and PW Segement 3 together to complete the 321 multi-hop PW between TPE1 and TPE2. PW Segment 1 and PW Segment 3 322 MUST be of the same PW type, but PSN Tunnel 1 and PSN Tunnel 2 need 323 not be the same technology. In the latter case, if the PW is switched 324 to a different technology, the PEs must adapt the PDU encapsulation 325 between the different PSN technologies. In the case where PSN Tunnel 326 1 and PSN Tunnel 2 are the same technology the PW PDU does not need 327 to be modified, and PDUs are then switched between the pseudowires at 328 the PW label level. 330 It should be noted that it is possible to adapt one PSN technology to 331 a different one, for example MPLS over an IP or GRE [RFC4023] 332 encapsulation, but this is outside the scope of this document. 333 Further, one could perform an interworking function on the PWs 334 themselves at the S-PE, allowing conversion from one PW type to 335 another, but this is also outside the scope of this document. 337 This document describes procedures for building multi-segment 338 pseudowires using manual configuration of the switching point PE1. 339 Other documents may build on this base specification to automate the 340 configuration and selection of S-PE1. It should also be noted that a 341 PW can traverse multiple PW switching points along it's path, and the 342 edge PEs will not require any specific knowledge of how many S-PEs 343 the PW has traversed (though this may be reported for troubleshooting 344 purposes). 346 The general approach taken for MS-PWs is to connect the individual 347 control planes by passing along any signaling information immediately 348 upon reception. First the S-PE is configured to switch a PW segment 349 from a specific peer to another PW segment destined for a different 350 peer. No control messages are exchanged yet as the S-PE does not have 351 enough information to actually initiate the PW setup messages. 352 However, if a session does not already exist, a control protocol 353 (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is 354 starting from the T-PE devices. Next once the T-PE is configured it 355 sends the PW control setup messages. These messages are received by 356 the S-PE, and immediately used to form the PW setup messages for the 357 next SS-PW of the MS-PW. If one of the S-PEs doesn't accept an LDP 358 Label Mapping message then a Label Release message may be sent back 359 to the originator T-PE depending on the cause of the error. LDP 360 liberal label retention mode still applies, hence if a PE is simply 361 not configured yet , the label mapping is stored for future use. A 362 MS-PW is declared UP only when all the constituent SS-PWs are UP. 364 5. PW Switching and Attachment Circuit Type 366 The PWs in each PSN are established independently, with each PSN 367 being treated as a separate PW domain. For example, in Figure 2 for 368 the case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 369 targeted session as described in [RFC4447], and at the same time a 370 separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for 371 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 372 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 374 6. Applicability 376 The general applicability of MS-PWs and their relationship to L2VPNs 377 is described in [MS-PW-ARCH]. The applicability of a PW type, as 378 specified in the relevant RFC for that encapsulation (e.g. [RFC4717] 379 for ATM), applies to each segment. This section describes further 380 applicability considerations. 382 As with SS-PWs, the performance of any segment will be limited by the 383 performance of the underlying PSN. The performance may be further 384 degraded by the emulation process, and performance degradation may be 385 further degraded by traversing multiple PW segments. Furthermore, the 386 overall performance of an MS-PW is no better than the worst 387 performing segment of that MS-PW. 389 Since different PSN types may be able to achieve different maximum 390 performance objectives, it is necessary to carefully consider which 391 PSN types are used along the path of a MS-PW. 393 7. MPLS-PW to MPLS-PW Switching 395 Referencing Figure 3, T-PE1 set up PW segment 1 using the LDP 396 targeted session as described in [RFC4447], at the same time a 397 separate pseudowire PW segment 3 is setup to T-PE2. Each PW is 398 configured independently on the PEs, but on S-PE1 pseudowire PW 399 segment 1 is connected to pseudowire PW segment 3. PDUs are then 400 switched between the pseudowires at the PW label level. Hence the 401 data plane does not need any special knowledge of the specific 402 pseudowire type. A simple standard MPLS label swap operation is 403 sufficient to connect the two PWs, and in this case the PW adaptation 404 function cannot be used. However when pushing a new PSN label the TTL 405 SHOULD be set to 255, or some other locally configured fixed value. 407 This process can be repeated as many times as necessary, the only 408 limitation to the number of S-PEs traversed is imposed by the TTL 409 field of the PW MPLS Label. The setting of the TTL of the PW MPLS 410 label is a matter of local policy on the originating PE, but SHOULD 411 be set to 255. However if the PW PDU contains an OAM packet then the 412 TTL can be set to the required value as explained later in this 413 document. 415 There are three MPLS to MPLS PW control planes: 416 -i. Static configuration of the PW. 417 -ii. LDP using FEC 128 418 -iii. LDP using the generalized FEC 129 419 This results in four distinct PW switching situations that are 420 significantly different, and must be considered in detail: 421 -i. PW Switching between two static control planes. 422 -ii. Static Control plane switching to LDP dynamic control plane. 423 -iii. Two LDP control planes using the same FEC type 424 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 426 7.1. Static Control plane switching 428 In the case of two static control planes the S-PE MUST be configured 429 to direct the MPLS packets from one PW into the other. There is no 430 control protocol involved in this case. When one of the control 431 planes is a simple static PW configuration and the other control 432 plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static 433 control plane should be considered identical to an attachment circuit 434 (AC) in the reference model of Figure 1. The switching point PE 435 SHOULD signal the appropriate PW status if it detects a failure in 436 sending or receiving packets over the static PW segment. Because the 437 PW is statically configured, the status communicated to the dynamic 438 LDP PW will be limited to local interface failures. In this case, the 439 S-PE PE behaves in a very similar manner to a T-PE, assuming an 440 active signaling role. This means that the S-PE will immediately send 441 the LDP Label Mapping message if the static PW is deemed to be UP. 443 7.2. Two LDP control planes using the same FEC type 445 The S-PE SHOULD assume an initial passive role. This means that when 446 independent PWs are configured on the switching point, the LSR does 447 not advertise the LDP PW FEC mapping until it has received at least 448 one of the two PW LDP FECs from a remote PE. This is necessary 449 because the switching point LSR does not know a priori what the 450 interface parameter field in the initial FEC advertisement will 451 contain. 453 The Pseudowire Identifier (PWID) , as defined in [RFC4447] is a 454 unique number between each pair of PEs. Hence Each SS-PW that forms 455 an MS-PW may have a different PWID. In the case of The Generalized PW 456 FEC, the AGI/SAI/TAI may have to also be different for some, or 457 sometimes all, SS-PWs. 459 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 461 When a MS-PW is signaled using FEC 129, each T-PE might independently 462 start signaling the MS-PW. If the MS-PW path is not statically 463 configured, in certain cases the signaling procedure could result in 464 an attempt to setup each direction of the MS-PW through different S- 465 PEs. To avoid this situation one of the T-PE MUST start the PW 466 signaling (active role), while the other waits to receive the LDP 467 label mapping before sending the respective PW LDP label mapping 468 message. (passive role). When the MS-PW path not statically 469 configured, the Active T-PE (the ST-PE) and the passive T-PE (the 470 TT-PE) MUST be identified before signaling is initiated for a given 471 MS-PW. 473 The determination of which T-PE assume the active role SHOULD be done 474 as follows: 476 The SAII and TAII are compared as unsigned integers, if the SAII is 477 larger, then the T-PE assumes the active role. 479 The selection process to determine which T-PE assumes the active role 480 MAY be superseded by manual provisioning. In this case one of the T- 481 PEs MUST be set to active role, and the other one MUST be set to 482 passive role. 484 7.3. LDP FEC 128 to LDP using the generalized FEC 129 486 When a PE is using the generalized FEC 129, there are two distinct 487 roles that a PE can assume: active and passive. A PE that assumes the 488 active role will send the LDP PW setup message, while a passive role 489 PE will simply reply to an incoming LDP PW setup message. The S-PE 490 PE, will always remain passive until a PWID FEC 128 LDP message is 491 received, which will cause the corresponding generalized PW FEC LDP 492 message to be formed and sent. If a generalized FEC PW LDP message is 493 received while the switching point PE is in a passive role, the 494 corresponding PW FEC 128 LDP message will be formed and sent. 496 PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice 497 versa. This can be accomplished by local S-PE configuration, or by 498 some other means, such as some form of auto discovery. Such other 499 means are outside the scope of this document. 501 7.4. LDP Switching Point PE TLV 503 The edge to edge PW might traverse several switching points, in 504 separate administrative domains. For management and troubleshooting 505 reasons it is useful to record information about the switching points 506 that the PW traverses. This is accomplished by using a PW switching 507 Point TLV. 509 Sending the PW switching Point TLV (S-PE TLV) is OPTIONAL, however 510 the PE or S-PE MUST process the TLV upon reception. The "U" bit MUST 511 be set for backward compatibility with T-PEs that do not support the 512 MS-PW extensions described in the document. The S-PE TLV MAY appear 513 only once for each switching point traversed. The S-PE TLV is 514 appended to the PW FEC at each switching point, and the order of the 515 S-PE TLVs in the LDP message MUST be preserved. The S-PE TLV MUST be 516 sent if VCCV operation is required beyond the first MS-PW segment 517 from a T-PE. 519 The S-PE TLV is encoded as follows: 521 0 1 2 3 522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |1|0| S-PE TLV (0x096D) | S-PE TLV Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Length | Variable Length Value | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Variable Length Value | 529 | " " " | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 [note] LDP TLV type is pending IANA approval. 534 - S-PE TLV Length 536 Specifies the total length of all the following S-PE TLV fields 537 in octets 539 - Type 541 Encodes how the Value field is to be interpreted. 543 - Length 545 Specifies the length of the Value field in octets. 547 - Value 549 Octet string of Length octets that encodes information to be 550 interpreted as specified by the Type field. 552 PW Switching point TLV Types are assigned by IANA according the 553 process defined in the "IANA Allocations" section below. 555 For local policy reasons, a particular S-PE can filter out all S-PE 556 TLVs in a label mapping message that traverses it and not include 557 it's own S-PE TLV. In this case, from any upstream PE, it will 558 appear as if this particular S-PE is the T-PE. This might be 559 necessary , depending on local policy if the S-PE is at the service 560 provider administrative boundary. It should also be noted that 561 because there are no S-PE TLVs describing the path beyond the S-PE 562 that removed them, VCCV will only work as far as that S-PE . 564 7.4.1. PW Switching Point Sub-TLVs 566 The S-PE TLV contains sub-TLVs that describe various characteristics 567 of the S-PE traversed. Below are the definitions of PW Switching 568 Point Sub-TLVs defined in this document: 570 - PW ID of last PW segment traversed. 572 This is only applicable if the last PW segment traversed used LDP 573 FEC 128 to signal the PW. This sub-TLV type contains a PW ID in 574 the format of the PWID described in [RFC4447]. This is just a 32 575 bit unsigned integer number. 577 - PW Switching Point description string. 579 An optional description string of text up to 80 characters long. 581 - Local IP address of PW Switching Point. 583 The Local IP V4 or V6 address of the PW Switching Point. This is 584 an OPTIONAL Sub-TLV. In most cases this will be the local LDP 585 session IP address of the S-PE. 587 - Remote IP address of the last PW Switching Point traversed or of 588 the T-PE 590 The IP V4 or V6 address of the last PW Switching Point traversed 591 or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this 592 will be the remote IP address of the LDP session. This Sub-TLV 593 SHOULD only be included if there are no other S-PE TLV present 594 from other S-PEs, or if the remote ip address of the LDP session 595 does not correspond to the "Local IP address of PW Switching 596 Point" TLV value contained in the last S-PE TLV. 598 - The FEC element of last PW segment traversed. 600 This is only applicable if the last PW segment traversed used LDP 601 FEC 129 to signal the PW. 603 The FEC element of the last PW segment traversed. This is encoded 604 in the following format: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | AGI Type | Length | Value | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 ~ AGI Value (contd.) ~ 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | AII Type | Length | Value | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 ~ SAII Value (contd.) ~ 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | AII Type | Length | Value | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 ~ TAII Value (contd.) ~ 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 - L2 PW address of PW Switching Point (recommended format). 627 This sub-TLV type contains a L2 PW address of PW Switching Point in 628 the format described in Section 3.2 of [RFC5003]. This includes the 629 AII type field, and length, as well as the L2 PW address with the AC 630 ID field set to zero. 632 7.4.2. Adaptation of Interface Parameters 634 [RFC4447] defines several interface parameters, which are used by the 635 Network Service Processing (NSP) to adapt the PW to the Attachment 636 Circuit (AC). The interface parameters are only used at the end 637 points, and MUST be passed unchanged across the S-PE. However the 638 following interface parameters MAY be modified as follows: 640 - 0x03 Optional Interface Description string This Interface 641 parameter MAY be modified, or altogether removed from the FEC 642 element depending on local configuration policies. 644 - 0x09 Fragmentation indicator This parameter MAY be inserted in 645 the FEC by the switching point if it is capable of re-assembly of 646 fragmented PW frames according to [RFC4623]. 648 - 0x0C VCCV parameter This Parameter contains the CC type , and CV 649 type bit fields. The CV type bit field MUST be reset to reflect 650 the CV type supported by the S-PE. CC type bit field MUST have 651 bit 1 "Type 2: MPLS Router Alert Label " set to 0. The other bit 652 fields MUST be reset to reflect the CC type supported by the S- 653 PE. 655 7.5. Group ID 657 The Group ID (GR ID) is used to reduce the number of status messages 658 that need to be sent by the PE advertising the PW FEC. The GR ID has 659 local significance only, and therefore MUST be mapped to a unique GR 660 ID allocated by the S-PE PE. 662 7.6. PW Loop Detection 664 A switching point PE SHOULD inspect the PW switching Point TLV, to 665 verify that it's own IP address does not appears in it. If the PE's 666 IP address appears in a received PW switching Point TLV, the PE 667 SHOULD break the loop, and send a label release message with the 668 following error code: 669 Assignment E Description 670 0x0000003A 0 "PW Loop Detected" 672 [ note: error code pending IANA allocation ] 674 8. MPLS-PW to L2TPv3-PW Control Plane Switching 676 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 677 four possibilities when switching between L2TPv3 and MPLS. 679 -i. Switching between MPLS and L2TPv3 static control planes. 680 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 681 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 683 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 685 8.1. Static MPLS and L2TPv3 PWs 687 In the case of two static control planes, the S-PE MUST be configured 688 to direct packets from one PW into the other. There is no control 689 protocol involved in this case. The configuration MUST include which 690 MPLS PW Label maps to which L2TPv3 Session ID (and associated Cookie, 691 if present) as well as which MPLS Tunnel Label maps to which PE 692 destination IP address. 694 8.2. Static MPLS PW and Dynamic L2TPv3 PW 696 When a statically configured MPLS PW is switched to a dynamic L2TPv3 697 PW, the static control plane should be considered identical to an 698 attachment circuit (AC) in the reference model of Figure 1. The 699 switching point PE SHOULD signal the appropriate PW status if it 700 detects a failure in sending or receiving packets over the static PW. 701 Because the PW is statically configured, the status communicated to 702 the dynamic L2TPv3 PW will be limited to local interface failures. In 703 this case, the S-PE PE behaves in a very similar manner to a T-PE, 704 assuming an active role. 706 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 708 When a statically configured L2TPv3 PW is switched to a dynamic 709 LDP/MPLS PW, then the static control plane should be considered 710 identical to an attachment circuit (AC) in the reference model of 711 Figure 1. The switching point PE SHOULD signal the appropriate PW 712 status (via an L2TPv3 SLI message) if it detects a failure in sending 713 or receiving packets over the static PW. Because the PW is 714 statically configured, the status communicated to the dynamic 715 LDP/MPLS PW will be limited to local interface failures. In this 716 case, the S-PE PE behaves in a very similar manner to a T-PE, 717 assuming an active role. 719 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 721 When switching between dynamic PWs, the switching point always 722 assumes an initial passive role. Thus, it does not initiate an 723 LDP/MPLS or L2TPv3 PW until it has received a connection request 724 (Label Mapping or ICRQ) from one side of the node. Note that while 725 MPLS PWs are made up of two unidirectional LSPs bonded together by 726 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 727 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 728 Establishment, Tear Down, and PW Status signaling are detailed below. 730 8.4.1. Session Establishment 732 When the S-PE receives an L2TPv3 ICRQ message, the identifying AVPs 733 included in the message are mapped to FEC identifiers and sent in an 734 LDP label mapping message. Conversely, if an LDP Label Mapping 735 message is received, it is either mapped to an ICRP message or causes 736 an L2TPv3 session to be initiated by sending an ICRQ. 738 Following are two example exchanges of messages between LDP and 739 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 740 the second is a case where an MPLS T-PE initiates an MS-PW. 742 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 744 AC "Up" 745 L2TPv3 ICRQ ---> 746 LDP Label Mapping ---> 747 AC "UP" 748 <--- LDP Label Mapping 749 <--- L2TPv3 ICRP 750 L2TPv3 ICCN ---> 751 <-------------------- MH PW Established ------------------> 753 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 755 AC "Up" 756 LDP Label Mapping ---> 757 L2TPv3 ICRQ ---> 758 <--- L2TPv3 ICRP 759 <--- LDP Label Mapping 760 L2TPv3 ICCN ---> 761 AC "Up" 762 <-------------------- MH PW Established ------------------> 764 8.4.2. Adaptation of PW Status message 766 L2TPv3 uses the SLI message to indicate a interface status change 767 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 768 PWs either signal this via an LDP Label Withdraw or the PW Status 769 Notification message defined in section 4.4 of [RFC4447]. 771 8.4.3. Session Tear Down 773 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 774 message translates to a Label Withdraw message in LDP. Following are 775 two example exchanges of messages between LDP and L2TPv3. The first 776 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 777 the second is a case where an MPLS T-PE initiates the termination of 778 an MS-PW. 780 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 782 AC "Down" 783 L2TPv3 CDN ---> 784 LDP Label Withdraw ---> 785 AC "Down" 786 <-- LDP Label Release 788 <--------------- MH PW Data Path Down ------------------> 790 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 792 AC "Down" 793 LDP Label Withdraw ---> 794 L2TPv3 CDN --> 795 <-- LDP Label Release 796 AC "Down" 798 <---------------- MH PW Data Path Down ------------------> 800 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 802 [RFC4447] defines several interface parameters which MUST be mapped 803 to the equivalent AVPs in L2TPv3 setup messages. 805 * Interface MTU 807 The Interface MTU parameter is mapped directly to the L2TP 808 Interface MTU AVP defined in [RFC4667] 810 * Max Number of Concatenated ATM cells 812 This interface parameter is mapped directly to the L2TP "ATM 813 Maximum Concatenated Cells AVP" described in section 6 of 814 [RFC4454]. 816 * Optional Interface Description String 818 This string may be carried as the "Call-Information AVP" 819 described in section 2.2 of [L2TP-INFOMSG] 821 * PW Type 823 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 824 Type" AVP defined in [L2TPv3]. 826 * PW ID (FEC 128) 828 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 829 End ID" AVP defined in [L2TPv3]. 831 * Generalized FEC 129 SAI/TAI 833 Section 4.3 of [RFC4667] defines how to encode the SAI and TAI 834 parameters. These can be mapped directly. 836 Other interface parameter mappings are unsupported when switching 837 between LDP/MPLS and L2TPv3 PWs. 839 8.6. Switching Point TLV in L2TPv3 841 When translating between LDP and L2TPv3 control messages, the PW 842 Switching Point TLV described earlier in this document is carried in 843 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 844 and optionally in the ICCN message. 846 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 847 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 848 the AVP is 6 plus the length of the series of Switching Point sub- 849 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 850 (the L2TP AVP M-bit MUST be 0). 852 8.7. L2TPv3 and MPLS PW Data Plane 854 When switching between an MPLS and L2TP PW, packets are sent in their 855 entirety from one PW to the other, replacing the MPLS label stack 856 with the L2TPv3 and IP header or vice versa. There are some 857 situations where an additional amount of interworking must be 858 provided between the two data planes at the S-PE, however this is 859 outside the scope of this document. 861 Section 5.4 of [RFC3985] discusses the purpose of the various shim 862 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 863 For L2TPv3, the Payload Convergence and Sequencing function is 864 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 865 For MPLS, these two functions (together with PSN Convergence) are 866 carried out via the MPLS Control Word. Since these functions are 867 different between MPLS and L2TPv3, interworking between the two may 868 be necessary. 870 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 871 which in some cases are not necessary to be present at all. For 872 example, an Ethernet PW with sequencing disabled will generally not 873 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 874 be present at all. In this case, Ethernet frames are simply sent from 875 one PW to the other without any modification beyond the MPLS and 876 L2TP/IP encapsulation and decapsulation. 878 The following section offers guidelines for how to interwork between 879 L2TP and MPLS for those cases where the Payload Convergence, 880 Sequencing, or PSN Convergence functions are necessary on one or both 881 sides of the switching node. 883 8.7.1. Mapping the MPLS Control Word to L2TP 885 The MPLS Control Word consists of (from left to right): 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 |0 0 0 0| Reserved | Length | Sequence Number | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 -i. These bits are always zero in MPLS are not necessary to be 894 mapped to L2TP. 896 -ii. These six bits may be used for Payload Convergence depending 897 on the PW type. For ATM, the first four of these bits are 898 defined in [RFC4717]. These map directly to the bits defined 899 in [RFC4454]. For Frame Relay, these bits indicate how to 900 set the bits in the Frame Relay header which must be 901 regenerated for L2TP as it carries the Frame Relay header 902 intact. 904 -iii. L2TP determines its payload length from IP. Thus, this 905 Length field need not be carried directly to L2TP. This 906 Length field will have to be calculated and inserted for 907 MPLS when necessary. 909 -iv. The Default L2-Specific Sublayer has a sequence number with 910 different semantics than that of the MPLS Control Word. This 911 difference eliminates the possibility of supporting 912 sequencing across the MS-PW by simply carrying the sequence 913 number through the switching point transparently. As such, 914 sequence numbers MAY be supported by checking the sequence 915 numbers of packets arriving at the switching point and 916 regenerating a new sequence number in the appropriate format 917 for the PW on egress. If this type of sequence interworking 918 at the switching node is not supported, and a T-PE requests 919 sequencing of all packets via the L2TP control channel 920 during session setup, the switching node SHOULD NOT allow 921 the session to be established by sending a CDN message with 922 Result Code set to 17 "sequencing not supported" (subject to 923 IANA Assignment). 925 9. Operation And Management 927 9.1. Extensions to VCCV to Support MS-PWs 929 Single-hop pseudowires are signaled using the Virtual Circuit 930 Connectivity Verification (VCCV) parameter included in the interface 931 parameter field of the PW ID FEC TLV or the interface parameter sub- 932 TLV of the Generalized PW ID FEC TLV as described in [RFC5085]. When 933 a switching point exist between PE nodes, it is required to be able 934 to continue operating VCCV end-to-end across a switching point and to 935 provide the ability to trace the path of the MS-PW over any number of 936 segments. 938 This document provides a method for achieving these two objectives. 939 This method is based on re-using the existing VCCV CW and 940 decrementing the TTL of the PW label at each hop in the path of the 941 MS-PW. 943 9.2. MPLS-PW to MPLS-PW OAM Data Plane Indication 945 As stated above the S-PE MUST perform a standard MPLS label swap 946 operation on the MPLS PW label. By the rules defined in [RFC3032] the 947 PW label TTL MUST be decreased at every S-PE. Once the PW label TTL 948 reaches the value of 0, the packet is sent to the control plane to be 949 processed. Hence, by controlling the PW TTL value of the PW label it 950 is possible to select exactly which hop will respond to the VCCV 951 packet. 953 9.3. Signaling OAM Capabilities for Switched Pseudowires 955 Similarly to SS-PW, MS-PW VCCV capabilities are signaled using the 956 VCCV parameter included in the interface parameter field of the PW ID 957 FEC TLV or the sub-TLV interface parameter of the Generalized PW ID 958 FEC TLV as described in [RFC5085]. 960 In Figure 3 T-PE1 uses the VCCV parameter included in the interface 961 parameter field of the PW ID FEC TLV or the sub-TLV interface 962 parameter of the Generalized PW ID FEC TLV to indicate to the far end 963 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 964 parameter as would be used if T-PE1 and T-PE2 were connected 965 directly. S-PE2, which is a PW switching point, as part of the 966 adaptation function for interface parameters, processes locally the 967 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 968 on the path between T-PE1 and T-PE2, each would carry out the same 969 processing, passing along the VCCV parameter. The local processing of 970 the VCCV parameter removes CC Types specified by the originating T-PE 971 that are not supported on the S-PE. For example, if T-PE1 indicates 972 supports CC Types 1,2,3 and the Then the S-PE removes the Router 973 Alert CC Type=2, leaving the rest of the TLV unchanged, and passes 974 the modified VCCV parameter to the next S-PE along the path. 976 The far end T-PE (T-PE2) receives the VCCV parameter indicating only 977 the CC types that are supported by the initial T-PE (T-PE1) and all 978 S-PEs along the PW path. 980 9.4. OAM Capability for MS-PWs Demultiplexed using MPLS 982 The VCCV parameter ID is defined as follows in [RFC4446]: 984 Parameter ID Length Description 985 0x0c 4 VCCV 987 The format of the VCCV parameter field is as follows: 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | 0x0c | 0x04 | CC Types | CV Types | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 0x01 Type 1: PWE3 control word with 0001b as first nibble 996 as defined in [RFC4385]. 997 0x02 Type 2: MPLS Router Alert Label. 998 0x04 Type 3: MPLS PW De-multiplexor Label TTL = 1 (Type 3). 1000 9.4.1. MS-PW and VCCV CC Type 1 1002 VCCV CC type 1 can be used for MS-PWs. However, if the CW is enabled 1003 on user packets, VCCV CC type 1 MUST be used according to the rules 1004 in [RFC5085]. When using CC type 1 for MS-PWs the PE transmitting 1005 the VCCV packet MUST set the TTL to the appropriate value to reach 1006 the destination S-PE. However if the packet is destined for the T-PE, 1007 the TTL can be set to any value that is sufficient for the packet to 1008 reach the T-PE. 1010 9.4.2. MS-PW and VCCV CC type 2 1012 VCCV CC type 2 is not supported for MS-PWs and MUST be removed from a 1013 VCCV parameter field by the S-PE. 1015 9.4.3. MS-PW and VCCV CC type 3 1017 VCCV CC type 3 can be used for MS-PWs, however if the CW is enabled 1018 VCCV type 1 is preferred according to the rules in [RFC5085]. Note 1019 that for using the VCCV type 3, TTL method, the PE will set the PW 1020 label TTL to the appropriate value necessary to reach the target PE, 1021 otherwise the VCCV packet might be forwarded over the AC to the CPE. 1023 9.5. MS-PW VCCV Operations 1025 This document specifies four VCCV operations: 1026 -i. End-to-end MS-PW connectivity verification. This operation 1027 enables the connectivity of the MS-PW to be tested from 1028 source T-PE to destination T-PE. In order to do this, the 1029 sending T-PE must include the FEC used in the last segment 1030 of the MS-PW to the destination T-PE in the VCCV-Ping echo 1031 request. This information is either configured at the 1032 sending T-PE or is obtained by processing the corresponding 1033 sub-TLVs of the optional S-PE TLV, as described below. 1034 -ii. Partial MS-PW connectivity verification. This operation 1035 enables the connectivity of any contiguous subset of the 1036 segments of a MS-PW to be tested from the source T-PE or a 1037 source S-PE to a destination S-PE or T-PE. Again, the FEC 1038 used on the last segment to be tested must be included in 1039 the VCCV-Ping echo request message. This information is 1040 determined by the sending T-PE or S-PE as in (i) above. 1041 -iii. MS-PW path verification. This operation verifies the path of 1042 the MS-PW, as returned by the S-PE TLV, against the actual 1043 data path of the MS-PW. The sending T-PE or S-PE iteratively 1044 sends a VCCV echo request to each S-PE along the MS-PW path, 1045 using the FEC for the corresponding MS-PW segment in the 1046 switching point TLV. If the S-PE TLV information is correct, 1047 then a VCCV echo reply showing that this is a valid router 1048 for the FEC will be received. However, if the switching 1049 point TLV information is incorrect, then this operation 1050 enables the first incorrect switching point to be 1051 determined, but not the actual path of the MS-PW beyond 1052 that. This operation cannot be used when the MS-PW is 1053 statically configured or when the S-PE TLV is not suported. 1054 The processing of the PW switching TLV used for this 1055 operation is described below. This operation is OPTIONAL. 1056 -iv. MS-PW path trace. This operation traces the data path of the 1057 MS-PW using FECs included in the Target FEC stack TLV 1058 [RFC4379] returned by S-PEs or T-PEs in an echo reply 1059 message. The sending T-PE or S-PE uses this information to 1060 recursively test each S-PE along the path of the MS-PW in a 1061 single operation in a similar manner to LSP trace. This 1062 operation is able to determine the actual data path of the 1063 MS-PW, and can be used for both statically configured and 1064 signaled MS-PWs. Support for this operation is OPTIONAL. 1066 Note that the above operations rely on intermediate S-PEs and/or the 1067 destination T-PE to include the switching point TLV as a part of the 1068 MS-PW setup process, or to include the Target FEC stack TLV in the 1069 VCCV echo reply message. For various reasons, e.g. privacy or 1070 security of the S-PE/T-PE, this information may not be available to 1071 the source T-PE. In these cases, manual configuration of the FEC MAY 1072 still be used. 1074 9.5.1. VCCV Echo Message Processing 1076 The challenge for the control plane is to be able to build the VCCV 1077 echo request packet with the necessary information to reach the 1078 desired S-PE or T-PE, for example the target FEC 128 PW sub-TLV of 1079 the downstream PW segment that the packet is destined for. This could 1080 be even more difficult in situations in which the MS-PW spans 1081 different providers and Autonomous Systems. 1083 For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW 1084 segment 1, but it does not readily have the information required to 1085 compose the FEC128 of the following segment, PW segment 3, if a VCCV 1086 echo request to be sent to T-PE2. This can be achieved by the methods 1087 described in the following subsections. 1089 9.5.1.1. Sending a VCCV Echo Request 1091 When performing a partial or end-to-end connectivity or path 1092 verification, the sender of the echo request message requires the FEC 1093 of the last segment to the target S-PE/T-PE node. This information 1094 can either be configured manually or be obtained by inspecting the 1095 corresponding sub-TLV's of the PW switching point TLV. 1097 The necessary S-PE sub-TLVs are : 1099 Type Description 1100 0x01 PW ID of last PW segment traversed 1101 0x03 Local IP address of PW Switching Point 1102 0x04 Remote IP address of last PW Switching Point traversed or 1103 of the T-PE 1105 When performing an OPTIONAL MS-PW path trace operation, the T-PE will 1106 automatically learn the target FEC by probing, one by one, the hops 1107 of the MS-PW path, using the FEC returned in the Target FEC stack of 1108 the previous VCCV echo reply. 1110 9.5.1.2. Receiving a VCCV Echo Request 1112 Upon receiving a VCCV echo request the control plane on S-PEs (or the 1113 target node of each segment of the MS-PW) validates the request and 1114 responds to the request with an echo reply consisting of a return 1115 code of 8 (label switched at stack-depth) indicating that it is an 1116 S-PE and not the egress router for the MS-PW. 1118 S-PEs that wish to reveal their downstream next-hop in a trace 1119 operation should include the FEC of the downstream PW segment in the 1120 Target FEC stack (as per Sections 3.2 and 4.5 of [RFC4379]) of the 1121 echo reply message. FEC128 PWs MUST use the format shown in Section 1122 3.2.09 of [RFC4379] for the sub-TLV in the Target FEC stack, while 1123 FEC129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379] 1124 for the sub-TLV in the Target FEC stack. Note that an S-PE MUST NOT 1125 include this FEC information in the reply if it has been configured 1126 not to do so for administrative reasons, or for reasons explained 1127 previously. 1129 If the node is the T-PE or the egress node of the MS-PW, it responds 1130 to the echo request with an echo reply with a return code of 3 1131 (egress router). 1133 9.5.1.3. Receiving a VCCV Echo Reply 1135 The operation to be taken by the node receiving the echo reply in 1136 response to an echo request depends on the VCCV mode of operation 1137 described above. See Section 9.5.2 for detailed procedures. 1139 9.5.2. Detailed VCCV procedures 1141 9.5.2.1. End to End Connectivity Verification Between T-PEs 1143 In Figure 3, if T-PE1, S-PE and T-PE2 support Control Word , the PW 1144 control plane will automatically negotiate the use of the CW. VCCV CC 1145 type 3 will function correctly whether the CW is enable or not on the 1146 PW. However VCCV type 1 for (which can be use for end to end 1147 verification only), is only supported if the CW is enabled. 1149 At the S-PE the data path operations include an outer label pop, 1150 inner label swap and new outer label push. Note that there is no 1151 requirement for the S-PE to inspect the CW. Thus, the end-to-end 1152 connectivity of the multi-segment pseudowire can be verified by 1153 performing all of the following steps: 1154 -i. T-PE forms a VCCV-ping echo request message with the FEC 1155 matching that of the last segment PW to the destination T- 1156 PE. 1158 -ii. T-PE sets the inner PW label TTL to the exact value to allow 1159 the packet to reach the far end T-PE. ( the value is 1160 determined by counting the number of S-PEs from the control 1161 plane information ) Alternatively, if CC type 1 is supported 1162 the packet can be encapsulated according to CC type 1 in 1163 [RFC5085] 1165 -iii. T-PE sends a VCCV packet that will follow the exact same 1166 data path at each S-PE as that taken by data packets. 1168 -iv. S-PE may performs an outer label pop, if PHP is disabled, 1169 and will perform an inner label swap with TTL decrement, and 1170 new outer label push. 1172 -v. There is no requirement for the S-PE to inspect the CW. 1174 -vi. The VCCV packet is diverted to VCCV control processing at 1175 the destination T-PE. 1177 -vii. Destination T-PE replies using the specified reply mode, 1178 i.e., reverse PW path or IP path. 1180 9.5.2.2. Partial Connectivity Verification from T-PE 1182 In order to trace part of the multi-segment pseudowire, the TTL of 1183 the PW label may be used to force the VCCV message to 'pop out' at an 1184 intermediate node. When the TTL expires, the S-PE can determine that 1185 the packet is a VCCV packet by either checking the control word (CW) 1186 , or if the CW is not in use by checking for a valid IP header with 1187 UDP destination port 3503. The packet should then be diverted to 1188 VCCV processing. 1190 In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW 1191 label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus 1192 verify the first segment of the pseudowire. 1194 The VCCV packet is built according to [RFC4379] section 3.2.9 for FEC 1195 128, or 3.2.10 for a FEC 129 PW. All the information necessary to 1196 build the VCCV LSP ping packet is collected by inspecting the S-PE 1197 TLVs. 1199 Note that this use of the TTL is subject to the caution expressed in 1200 [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and 1201 a T-PE manipulates the PW label TTL, the VCCV message may not emerge 1202 from the MS-PW at the correct S-PE. 1204 9.5.2.3. Partial connectivity verification between S-PEs 1206 Assuming that all nodes along an MS-PW support the Control Word CC 1207 Type 3, VCCV between S-PEs may be accomplished using the PW label TTL 1208 as described above. In Figure 3, the S-PE may verify the path between 1209 it and T-PE2 by sending a VCCV message with the PW label TTL set to 1210 1. Given a more complex network with multiple S-PEs, an S-PE may 1211 verify the connectivity between it and an S-PE two segments away by 1212 sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE 1213 can diagnose connectivity problems by successively increasing the 1214 TTL. All the information needed to build the proper VCCV echo 1215 request packet as described in [RFC4379] section 3.2.9 or 3.2.10 is 1216 obtained automatically from the LDP label mapping that contains S-PE 1217 TLVs. 1219 9.5.2.4. MS-PW Path Verification 1221 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1222 originating from T-PE1 by a single operational command. The following 1223 process ensues: 1224 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1225 containing the pseudowire information of the first segment 1226 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1227 Stack Validation is enabled, the request may also include 1228 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1229 dependent on the type of transport tunnel the segmented PW 1230 is riding on. 1232 -ii. S-PE validates the echo request with the FEC. Since it is a 1233 switching point between the first and second segment it 1234 builds an echo reply with a return code of 8 and sends the 1235 echo reply back to T-PE1. 1237 -iii. T-PE1 builds a second VCCV echo request based on the 1238 infomation obtained from the control plane (S-PE TLV). It 1239 then increments the TTL and sends it out to T-PE2. Note that 1240 the VCCV echo request packet is switched at the S-PE 1241 datapath and forwarded to the next downstream segment 1242 without any involvement from the control plane. 1244 -iv. T-PE2 receives and validates the echo request with the FEC. 1245 Since T-PE2 is the destination node or the egress node of 1246 the MS-PW it replies to T-PE1 with an echo reply with a 1247 return code of 3 (Egress Router). 1249 -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1250 aware that T-PE2 is the destination of the MS-PW because the 1251 echo reply has a return code of is 3. The trace process is 1252 completed. 1254 If no echo reply is received, or an error code is received from a 1255 particular PE, the trace process MUST stop immediately, and packets 1256 MUST NOT be sent further along the MS-PW. 1258 For more detail on the format of the VCCV echo packet, refer to 1259 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1260 (PW) label TTL. 1262 9.5.2.5. MS-PW Path Trace 1264 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1265 originating from T-PE1 by a single operational command. The following 1266 OPTIONAL process ensues: 1268 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1269 containing the pseudowire information of the first segment 1270 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1271 Stack Validation is enabled, the request may also include 1272 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1273 dependent on the type of transport tunnel the segmented PW 1274 is riding on. 1276 -ii. The S-PE validates the echo request with the FEC. 1278 -iii. The S-PE builds an echo reply with a return code of 8 and 1279 sends the echo reply back to T-PE1, appending the FEC128 1280 information for the next segment along the MS-PW to the VCCV 1281 echo reply packet using the Target FEC stack TLV (as per 1282 Sections 3.2 and 4.5 of [RFC4379]). 1284 -iv. T-PE1 builds a second VCCV echo request based on the 1285 infomation obtained from the FEC stack TLV received in the 1286 previous VCCV echo reply. It then increments the TTL and 1287 sends it out to T-PE2. Note that the VCCV echo request 1288 packet is switched at the S-PE datapath and forwarded to the 1289 next downstream segment without any involvement from the 1290 control plane. 1292 -v. T-PE2 receives and validates the echo request with the FEC. 1293 Since T-PE2 is the destination node or the egress node of 1294 the MS-PW it replies to T-PE1 with an echo reply with a 1295 return code of 3 (Egress Router). 1297 -vi. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1298 aware that T-PE2 is the destination of the MS-PW because the 1299 echo reply has a return code of is 3. The trace process is 1300 completed. 1302 If no echo reply is received, or an error code is received from a 1303 particular PE, the trace process MUST stop immediately, and packets 1304 MUST NOT be sent further along the MS-PW. 1306 For more detail on the format of the VCCV echo packet, refer to 1307 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1308 (PW) label TTL. 1310 10. Mapping Switched Pseudowire Status 1312 In the PW switching with attachment circuits case (Figure 2), PW 1313 status messages indicating PW or attachment circuit faults MUST be 1314 mapped to fault indications or OAM messages on the connecting AC as 1315 defined in [PW-MSG-MAP]. 1317 In the PW control plane switching case (Figure 3), there is no 1318 attachment circuit at the S-PE, but the two PWs are connected 1319 together. Similarly, the status of the PWs are forwarded unchanged 1320 from one PW to the other by the control plane switching function. 1321 However, it may sometimes be necessary to communicate fault status of 1322 one of the locally attached PW segments at a S-PE. For LDP this can 1323 be accomplished by sending an LDP notification message containing the 1324 PW status TLV, as well as an OPTIONAL PW switching point TLV as 1325 follows: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 |0| Notification (0x0001) | Message Length | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Message ID | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 |0|1| Status (0x0300) | Length | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 |0|1| Status Code=0x00000028 | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Message ID=0 | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Message Type=0 | PW Status TLV | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | PW Status TLV | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | PW Status TLV | PWId FEC | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | | 1347 | | 1348 | PWId FEC or Generalized ID FEC | 1349 | | 1350 | | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 |1|0| S-PE TLV (0x096D) | S-PE TLV Length | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Type | Length | Variable Length Value | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Only one S-PE TLV can be present in this message. This message is 1357 then relayed by each S-PE unchanged. The T-PE decodes the status 1358 message and the included S-PE TLV to detect exactly where the fault 1359 occurred. At the T-PE if there is no S-PE TLV included in the LDP 1360 status notification then the status message can be assumed to have 1361 originated at the remote T-PE. 1363 The merging of the received LDP status and the local status for the 1364 PW segments at an S-PE can be summarized as follows: 1366 -i. When the local status for both PW segments is UP, the S-PE 1367 passes any received AC or PW status bits unchanged, i.e., 1368 the status notification TLV is unchanged but the PWid in the 1369 case of a FEC 128 TLV is set to the value of the PW segment 1370 of the next hop. 1372 -ii. When the local status for any of the PW segments is at 1373 fault, the S-PE always sends the local status bits 1374 regardless if the received status bits from the remote node 1375 indicated that an upstream fault has cleared. AC status bit 1376 are passed along unchanged. 1378 10.1. S-PE initiated PW status messages 1380 The PW fault directions are defined as follows: 1382 +-------+ 1383 ---PW1 receive---->| |-----PW2 Transmit----> 1384 S-PE1 | S-PE2 | S-PE3 1385 <--PW1 Transmit----| |<----PW2 Receive------ 1386 +-------+ 1387 Figure 4. S-PE and PW tx/rx directions. 1389 When a local fault is detected by the S-PE, a PW status message is 1390 sent in both directions along the PW. Since there are no attachment 1391 circuits on an S-PE, only the following status messages are relevant: 1393 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1394 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1396 Each S-PE needs to store only two 32-bit PW status words for each PW 1397 segment: One for local failures , and one for remote failures 1398 (normally received from another PE). The first failure will set the 1399 appropriate bit in the 32-bit status word, and each subsequent 1400 failure will be ORed to the appropriate PW status word. In the case 1401 of the PW status word storing remote failures, this rule has the 1402 effect of a logical OR operation with the first failure received on 1403 the particular PW segment. 1405 It should be noted that remote failures received on an S-PE are just 1406 passed along the MS-PW unchanged while local failures detected an S- 1407 PE are signalled on both PW segments. 1409 A T-PE can receive multiple failures from S-PEs along the MS-PW, 1410 however only the failure from the remote closest S-PE will be stored 1411 (last pw status message received). The PW status word received are 1412 just ORed to any existing remote PW status already stored on the T- 1413 PE. 1415 Given that there are two PW segments at a particular S-PE for a 1416 particular MS-PW, referring to figure 4, there are four possible 1417 failure cases as follows: 1419 -i. PW2 Transmit direction fault 1420 -ii. PW1 Transmit direction fault 1421 -iii. PW2 Receive direction fault 1422 -iv. PW1 Receive direction fault 1424 Once a PW status notification message is initiated at a S-PE for a 1425 particular PW status bit any further status message, for the same 1426 status bit, received from an upstream neighbor is processed locally 1427 and not forwarded until the S-PE original status error state is 1428 cleared. 1430 Each S-PE along the MS-PW MUST store any PW status messages 1431 transiting it. If more than one status message with the same PW 1432 status bit set is received by a T-PE, or S-PE only the last PW 1433 status message is stored. 1435 10.1.1. Local PW2 transmit direction fault 1437 When this failure occurs the S-PE will take the following actions: 1439 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1440 PSN-facing PW (egress) Transmit Fault" 1441 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1442 PSN-facing PW (ingress) Receive Fault" 1443 * Store 0x00000010 in the local PW status word for the PW segment 1444 toward S-PE3. 1446 10.1.2. Local PW1 transmit direction fault 1448 When this failure occurs the S-PE will take the following actions: 1450 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1451 PSN-facing PW (egress) Transmit Fault" 1452 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1453 PSN-facing PW (ingress) Receive Fault" 1454 * Store 0x00000010 in the local PW status word for the PW segment 1455 toward S-PE1. 1457 10.1.3. Local PW2 receive direction fault 1459 When this failure occurs the S-PE will take the following actions: 1460 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1461 PSN-facing PW (ingress) Receive Fault" 1462 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1463 PSN-facing PW (egress) Transmit Fault" 1464 * Store 0x00000008 in the local PW status word for the PW segment 1465 toward S-PE3. 1467 10.1.4. Local PW1 receive direction fault 1469 When this failure occurs the S-PE will take the following actions: 1470 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1471 PSN-facing PW (ingress) Receive Fault" 1472 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1473 PSN-facing PW (egress) Transmit Fault" 1474 * Store 0x00000008 in the local PW status word for the PW segment 1475 toward S-PE1. 1477 10.1.5. Clearing Faults 1479 Remote PW status fault clearing messages received by an S-PE will 1480 only be forwarded if there are no corresponding local faults on the 1481 S-PE. (local faults always supersede remote faults) 1483 Once the local fault has cleared, and there is no corresponding (same 1484 PW status bit set) remote fault, a PW status messages is sent out to 1485 the adjacent PEs clearing the fault. 1487 When a PW status fault clearing message is forwarded, the S-PE will 1488 always send the S-PE TLV associated with the PE which cleared the 1489 fault. 1491 10.2. PW status messages and S-PE TLV processing 1493 When a PW status message is received that includes a S-PE TLV, the 1494 S-PE TLV information MAY be stored, along with the contents of the PW 1495 status Word according to the procedures described above. The S-PE TLV 1496 stored is always the S-PE TLV that is associated with the PE that set 1497 that particular last fault. If subsequent PW status message for the 1498 same PW status bit are received the S-PE TLV will overwrite the 1499 previously stored S-PE TLV. 1501 10.3. T-PE processing of PW status messages 1503 The PW switching architecture is based on the concept that the T-PE 1504 should process the PW LDP messages in the same manner as if it was 1505 participating in the setup of a PW segment. However T-PE 1506 participating a MS-PW, SHOULD be able to process the S-PE TLV. 1507 Otherwise the processing of PW status messages , and other PW setup 1508 messages is exactly as described in [RFC4447]. 1510 10.4. Pseudowire Status Negotiation Procedures 1512 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1513 be transparent to the switching point. 1515 10.5. Status Dampening 1517 When the PW control plane switching methodology is used to cross an 1518 administrative boundary it might be necessary to prevent excessive 1519 status signaling changes from being propagated across the 1520 administrative boundary. This can be achieved by using a similar 1521 method as commonly employed for the BGP protocol route advertisement 1522 dampening. The details of this OPTIONAL algorithm are a matter of 1523 implementation, and are outside the scope of this document. 1525 11. Peering Between Autonomous Systems 1527 The procedures outlined in this document can be employed to provision 1528 and manage MS-PWs crossing AS boundaries. The use of more advanced 1529 mechanisms involving auto-discovery and ordered PWE3 MS-PW signaling 1530 will be covered in a separate document. 1532 12. Security Considerations 1534 This document specifies the LDP, L2TPv3, and VCCV extensions that are 1535 needed for setting up and maintaining pseudowires. The purpose of 1536 setting up pseudowires is to enable layer 2 frames to be encapsulated 1537 and transmitted from one end of a pseudowire to the other. Therefore 1538 we discuss the security considerations for both the data plane and 1539 the control plane in the following sections. 1541 12.1. Data Plane Security 1543 Data plane security consideration as discussed in [RFC4447], 1544 [L2TPv3], and [RFC3985] apply to this extension without any changes. 1546 12.1.1. VCCV Security considerations 1548 The VCCV technology for MS-PW offers a method for the service 1549 provider to verify the data path of a specific PW. This involves 1550 sending a packet to a specific PE and receiving an answer which 1551 either confirms , or indicates that the information contained in the 1552 packet is incorrect. This is a very similar process to the commonly 1553 used IP ICMP ping , and TTL expired methods for IP networks. It 1554 should be noted that when using VCCV Type 3 for PW when the CW is not 1555 enabled, if a packet is crafted with a TTL greater then the number of 1556 hops along the MS-PW path, or an S-PE along the path mis-processes 1557 the TTL, the packet could mistakenly be forwarded out the attachment 1558 circuit as a native PW packet. This packet would most likely be 1559 treated as an error packet by the CE. However if this possibility is 1560 not acceptable, the CW should be enabled to guarantee that a VCCV 1561 packet will never be mistakenly forwarded to the AC. 1563 12.2. Control Protocol Security 1565 General security considerations with regard to the use of LDP are 1566 specified in section 5 of RFC 3036. Security considerations with 1567 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1568 considerations apply as well to the case where LDP or L2TPv3 is used 1569 to set up PWs. 1571 A Pseudowire connects two attachment circuits. It is important to 1572 make sure that LDP connections are not arbitrarily accepted from 1573 anywhere, or else a local attachment circuit might get connected to 1574 an arbitrary remote attachment circuit. Therefore an incoming session 1575 request MUST NOT be accepted unless its IP source address is known to 1576 be the source of an "eligible" peer. The set of eligible peers could 1577 be pre-configured (either as a list of IP addresses, or as a list of 1578 address/mask combinations), or it could be discovered dynamically via 1579 an auto-discovery protocol which is itself trusted. (Note that if the 1580 auto-discovery protocol were not trusted, the set of "eligible peers" 1581 it produces could not be trusted.) 1583 Even if a connection request appears to come from an eligible peer, 1584 its source address may have been spoofed. So some means of 1585 preventing source address spoofing must be in place. For example, if 1586 all the eligible peers are in the same network, source address 1587 filtering at the border routers of that network could eliminate the 1588 possibility of source address spoofing. 1590 For a greater degree of security, the LDP authentication option, as 1591 described in section 2.9 of [RFC5036], or the Control Message 1592 Authentication option of [L2TPv3] MAY be used. This provides 1593 integrity and authentication for the control messages, and eliminates 1594 the possibility of source address spoofing. Use of the message 1595 authentication option does not provide privacy, but privacy of 1596 control messages are not usually considered to be highly important. 1597 Both the LDP and L2TPv3 message authentication options rely on the 1598 configuration of pre-shared keys, making it difficult to deploy when 1599 the set of eligible neighbors is determined by an auto-configuration 1600 protocol. 1602 When the Generalized ID FEC Element is used, it is possible that a 1603 particular peer may be one of the eligible peers, but may not be the 1604 right one to connect to the particular attachment circuit identified 1605 by the particular instance of the Generalized ID FEC element. 1606 However, given that the peer is known to be one of the eligible peers 1607 (as discussed above), this would be the result of a configuration 1608 error, rather than a security problem. Nevertheless, it may be 1609 advisable for a PE to associate each of its local attachment circuits 1610 with a set of eligible peers, rather than having just a single set of 1611 eligible peers associated with the PE as a whole. 1613 13. IANA Considerations 1615 13.1. L2TPv3 AVP 1617 This document uses a new L2TP parameter, IANA already maintains a 1618 registry of name "Control Message Attribute Value Pair" defined by 1619 [RFC3438]. The following new value is required: 1621 TBA-L2TP-AVP-1 - PW Switching Point AVP 1623 13.2. LDP TLV TYPE 1625 This document uses a new LDP TLV types, IANA already maintains a 1626 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 1627 following value is suggested for assignment: 1629 TLV type Description 1630 0x096D Pseudowire Switching Point PE TLV 1632 13.3. LDP Status Codes 1634 This document uses a new LDP status codes, IANA already maintains a 1635 registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The 1636 following value is suggested for assignment: 1638 Assignment E Description 1639 0x0000003A 0 "PW Loop Detected" 1641 13.4. L2TPv3 Result Codes 1643 This document uses a new L2TPv3 status codes, IANA already maintains 1644 a registry of name "L2TPv3 Result Codes". The following value is 1645 suggested for assignment: 1647 Assignment Description 1648 TBD "sequencing not supported" 1650 13.5. New IANA Registries 1652 IANA needs to set up a registry of "Pseudowire Switching Point PE TLV 1653 Type". These are 8-bit values. Types value 1 through 6 are defined 1654 in this document. Type values 7 through 64 are to be assigned by IANA 1655 using the "Expert Review" policy defined in RFC5226. Type values 65 1656 through 127, 0 and 255 are to be allocated using the IETF consensus 1657 policy defined in [RFC5226]. Types values 128 through 254 are 1658 reserved for vendor proprietary extensions and are to be assigned by 1659 IANA, using the "First Come First Served" policy defined in RFC5226. 1661 The Type Values are assigned as follows: 1663 Type Length Description 1665 0x01 4 PW ID of last PW segment traversed 1666 0x02 variable PW Switching Point description string 1667 0x03 4/16 Local IP address of PW Switching Point 1668 0x04 4/16 Remote IP address of last PW Switching Point traversed 1669 or of the T-PE 1670 0x05 variable FEC Element of last PW segment traversed 1671 0x06 10 L2 PW address of PW Switching Point 1673 14. Normative References 1675 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1676 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1677 RFC4385, February 2006. 1679 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1680 mulation (PWE3)", L. Martini, RFC4446, April 2006. 1682 [RFC4447] "Pseudowire Setup and Maintenance Using the 1683 Label Distribution Protocol (LDP)", Martini, L., 1684 et al., rfc4447 April 2006. 1686 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, E, 1687 Rekhter, Y., RFC4364, February 2006 1688 October 2004. 1690 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1691 M. Townsley, I. Goyret, RFC3931 1693 [RFC5085] Nadeau, T., et al. "Pseudo Wire Virtual Circuit Connection 1694 Verification (VCCV), A Control Channel for Pseudowires", 1695 RFC5085 December 2007. 1697 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1698 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 1700 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1701 Requirement Levels", BCP 14, RFC 2119, March 1997. 1703 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 1704 Individual Identifier (AII) Types for Aggregation", RFC5003, 1705 September 2007. 1707 [RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol 1708 Label Switched (MPLS) Data Plane Failures", RFC4379, 1709 September 2007 1711 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1712 Specification", RFC 5036, October 2007. 1714 15. Informative References 1716 [RFC4023] "Encapsulating MPLS in IP or Generic 1717 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1718 RFC4023, March 2005. 1720 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture" 1721 Bryant, et al., RFC 3985, March 2005. 1723 [RFC4623] "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation 1724 and Reassembly", A. Malis, W. M. Townsley, RFC 4623, August 2006 1726 [RFC4667] "Layer 2 Virtual Private Network (L2VPN) 1727 Extensions for Layer 2 Tunneling Protocol (L2TP)", Luo, Wei, 1728 RFC4667, W. Luo, September 2006 1730 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1731 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-01.txt, 1732 ( work in progress ), July 2004 1734 [RFC4454] "Asynchronous Transfer Mode (ATM) over Layer 2 1735 Tunneling Protocol Version 3 (L2TPv3)", Singh, Townsley, 1736 Pignataro, RFC4454, May 2006 1737 ( work in progress ), March 2004. 1739 [RFC4717] "Encapsulation Methods for Transport of (ATM) 1740 MPLS Networks", Martini et al., RFC4717, December 2006 1742 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1743 (L2TP) Internet Assigned Numbers Authority (IANA) 1744 Considerations Update", December 2002, RFC3438 1746 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1747 draft-ietf-pwe3-oam-msg-map-10.txt, ( work in progress ), 1748 April 2009 1750 [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001 1752 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire Emulation 1753 Edge-to-Edge", Bocci et al, draft-ietf-pwe3-ms-pw-arch-06.txt 1754 February 2009 1756 [RFC5254] "Requirements for Multi-Segment Pseudowire Emulation 1757 Edge-to-Edge (PWE3)", N. Bitar, M. Bocci, L. Martini, RFC5254, 1758 October 2008 1760 16. Author's Addresses 1762 Luca Martini 1763 Cisco Systems, Inc. 1764 9155 East Nichols Avenue, Suite 400 1765 Englewood, CO, 80112 1766 e-mail: lmartini@cisco.com 1768 Thomas D. Nadeau 1769 BT 1770 BT Centre 1771 81 Newgate Street 1772 London, EC1A 7AJ 1773 United Kingdom 1774 e-mail: tom.nadeau@bt.com 1776 Chris Metz 1777 Cisco Systems, Inc. 1778 e-mail: chmetz@cisco.com 1780 Mike Duckett 1781 Bellsouth 1782 Lindbergh Center 1783 D481 1784 575 Morosgo Dr 1785 Atlanta, GA 30324 1786 e-mail: mduckett@bellsouth.net 1788 Matthew Bocci 1789 Alcatel-Lucent 1790 Grove House, Waltham Road Rd 1791 White Waltham, Berks, UK. SL6 3TN 1792 e-mail: matthew.bocci@alcatel-lucent.co.uk 1793 Florin Balus 1794 Alcatel-Lucent 1795 701 East Middlefield Rd. 1796 Mountain View, CA 94043 1797 e-mail: florin.balus@alcatel-lucent.com 1799 Mustapha Aissaoui 1800 Alcatel-Lucent 1801 600, March Road, 1802 Kanata, ON, Canada 1803 e-mail: mustapha.aissaoui@alcatel-lucent.com 1805 Full Copyright Statement 1807 Copyright (c) 2009 IETF Trust and the persons identified as the 1808 document authors. All rights reserved. 1810 This document is subject to BCP 78 and the IETF Trust's Legal 1811 Provisions Relating to IETF Documents in effect on the date of 1812 publication of this document (http://trustee.ietf.org/license-info). 1813 Please review these documents carefully, as they describe your rights 1814 and restrictions with respect to this document. 1816 This document may contain material from IETF Documents or IETF 1817 Contributions published or made publicly available before November 1818 10, 2008. The person(s) controlling the copyright in some of this 1819 material may not have granted the IETF Trust the right to allow 1820 modifications of such material outside the IETF Standards Process. 1821 Without obtaining an adequate license from the person(s) controlling 1822 the copyright in such materials, this document may not be modified 1823 outside the IETF Standards Process, and derivative works of it may 1824 not be created outside the IETF Standards Process, except to format 1825 it for publication as an RFC or to translate it into languages other 1826 than English. 1828 Acknowledgments 1830 The authors wish to acknowledge the contributions of Satoru 1831 Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, 1832 and Tiberiu Grigoriu. 1834 Expiration Date: February 2010