idnits 2.17.1 draft-ietf-pwe3-segmented-pw-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (September 16, 2010) is 4963 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-12 Summary: 3 errors (**), 0 flaws (~~), 2 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: March 2011 Cisco Systems Inc. 5 Intended status: Standards Track 6 Thomas D. Nadeau 7 LucidVision 9 Matthew Bocci 10 Mustapha Aissaoui 11 Alcatel-Lucent 13 September 16, 2010 15 Segmented Pseudowire 17 draft-ietf-pwe3-segmented-pw-18.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on Expiration Date: March 2011 42 Abstract 44 This document describes how to connect pseudowires (PW) between 45 different Packet Switched Network (PSN) domains or betweeb two or 46 more distinct PW control plane domains, where a control plane domain 47 uses a common control plane protocol or instance of that protocol for 48 a given PW. The different PW control plane domains may belong to 49 independent autonomous systems, or the PSN technology is 50 heterogeneous, or a PW might need to be aggregated at a specific PSN 51 point. The PW packet data units are simply switched from one PW to 52 another without changing the PW payload. 54 Table of Contents 56 1 Introduction ......................................... 4 57 2 Specification of Requirements ........................ 6 58 3 Terminology .......................................... 6 59 4 General Description .................................. 7 60 5 PW Switching and Attachment Circuit Type ............. 10 61 6 Applicability ........................................ 10 62 7 MPLS-PW to MPLS-PW Switching ......................... 10 63 7.1 Static Control plane switching ....................... 11 64 7.2 Two LDP control planes using the same FEC type ....... 11 65 7.2.1 FEC 129 Active/Passive T-PE Election Procedure ....... 12 66 7.3 LDP FEC 128 to LDP using the generalized FEC 129 ..... 12 67 7.4 LDP Switching Point PE TLV ........................... 13 68 7.4.1 PW Switching Point Sub-TLVs .......................... 14 69 7.4.2 Adaptation of Interface Parameters ................... 16 70 7.5 Group ID ............................................. 16 71 7.6 PW Loop Detection .................................... 16 72 8 MPLS-PW to L2TPv3-PW Control Plane Switching ......... 17 73 8.1 Static MPLS and L2TPv3 PWs ........................... 17 74 8.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 17 75 8.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 18 76 8.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 18 77 8.4.1 Session Establishment ................................ 18 78 8.4.2 Adaptation of PW Status message ...................... 19 79 8.4.3 Session Tear Down .................................... 19 80 8.5 Adaptation of L2TPv3 AVPs to Interface Parameters .... 20 81 8.6 Switching Point TLV in L2TPv3 ........................ 21 82 8.7 L2TPv3 and MPLS PW Data Plane ........................ 21 83 8.7.1 Mapping the MPLS Control Word to L2TP ................ 22 84 9 Operation And Management ............................. 23 85 9.1 Extensions to VCCV to Support MS-PWs ................. 23 86 9.2 MPLS PW to L2TPv3 PW OAM ............................. 23 87 9.3 MPLS PW to MPLS PW OAM Data Plane Indication ......... 23 88 9.4 Signaling OAM Capabilities for Switched Pseudowires .. 24 89 9.5 OAM Capability for MS-PWs Demultiplexed using MPLS ... 24 90 9.5.1 MS-PW and VCCV CC Type 1 ............................. 25 91 9.5.2 MS-PW and VCCV CC type 2 ............................. 25 92 9.5.3 MS-PW and VCCV CC type 3 ............................. 25 93 9.6 MS-PW VCCV Operations ................................ 25 94 9.6.1 VCCV Echo Message Processing ......................... 27 95 9.6.1.1 Sending a VCCV Echo Request .......................... 27 96 9.6.1.2 Receiving a VCCV Echo Request ........................ 27 97 9.6.1.3 Receiving a VCCV Echo Reply .......................... 28 98 9.6.2 Detailed VCCV procedures ............................. 28 99 9.6.2.1 End to End Connectivity Verification Between T-PEs ... 28 100 9.6.2.2 Partial Connectivity Verification from T-PE .......... 29 101 9.6.2.3 Partial connectivity verification between S-PEs ...... 30 102 9.6.2.4 MS-PW Path Verification .............................. 30 103 9.6.2.5 MS-PW Path Trace ..................................... 31 104 10 Mapping Switched Pseudowire Status ................... 32 105 10.1 S-PE initiated PW status messages .................... 34 106 10.1.1 Local PW2 transmit direction fault ................... 35 107 10.1.2 Local PW1 transmit direction fault ................... 35 108 10.1.3 Local PW2 receive direction fault .................... 36 109 10.1.4 Local PW1 receive direction fault .................... 36 110 10.1.5 Clearing Faults ...................................... 36 111 10.2 PW status messages and S-PE TLV processing ........... 36 112 10.3 T-PE processing of PW status messages ................ 37 113 10.4 Pseudowire Status Negotiation Procedures ............. 37 114 10.5 Status Dampening ..................................... 37 115 11 Peering Between Autonomous Systems ................... 37 116 12 Congestion Considerations ............................ 37 117 13 Security Considerations .............................. 38 118 13.1 Data Plane Security .................................. 38 119 13.1.1 VCCV Security considerations ......................... 38 120 13.2 Control Protocol Security ............................ 38 121 14 IANA Considerations .................................. 40 122 14.1 L2TPv3 AVP ........................................... 40 123 14.2 LDP TLV TYPE ......................................... 40 124 14.3 LDP Status Codes ..................................... 40 125 14.4 L2TPv3 Result Codes .................................. 40 126 14.5 New IANA Registries .................................. 41 127 15 Normative References ................................. 41 128 16 Informative References ............................... 42 129 17 Author's Addresses ................................... 43 130 18 Additional Authors ................................... 44 132 1. Introduction 134 The PWE3 Architecture [RFC3985], defines the signaling and 135 encapsulation techniques for establishing SS-PWs between a pair of 136 terminating PEs. MS-PWs are most useful in two general cases: 138 -i. In some cases it is not possible, desirable or feasible to 139 establish a PW control channel between the terminating 140 source and destination PEs. At a minimum PW control channel 141 establishment requires knowledge of and reachability to the 142 remote (terminating) PE IP address. The local (terminating) 143 PE may not have access to this information related to 144 topology, operational or security constraints. 146 An example is the inter-AS L2VPN scenario where the 147 terminating PEs reside in different provider networks (ASes) 148 and it is the practice to cryptographically sign all control 149 traffic exchanged between two networks. Technically a SS-PW 150 could be used but this would require to cryptographically 151 sign on ALL terminating source and destination PE nodes. An 152 MS-PW allows the providers to confine key administration to 153 just the PW switching points connecting the two domains. 155 A second example might involve a single AS where the PW 156 setup path between the terminating PEs is computed by an 157 external entity. Assume a full mesh of PWE3 control channels 158 established between PE-A, PE-B and PE-C. A client-layer L2 159 connection tunneled through a PW is required between 160 terminating PE-A and PE-C. The external entity computes a PW 161 setup path that passes through PE-B. This results in two 162 discrete PW segments being built: one between PE-A and PE-B 163 and one between PE-B and PE-C. The successful client-layer 164 L2 connection between terminating PE-A and terminating PE-C 165 requires that PE-B performs the PWE3 switching process. 167 A third example involves the use of PWs in hierarchical 168 IP/MPLS networks. Access networks connected to a backbone 169 use PWs to transport customer payloads between customer 170 sites serviced by the same access network and up to the edge 171 of the backbone where they can be terminated or switched 172 onto a succeeding PW segment crossing the backbone. The use 173 of PWE3 switching between the access and backbone networks 174 can potentially reduce the PWE3 control channels and routing 175 information processed by the access network T-PEs. 177 It should be noted that PWE3 switching does not help in any 178 way to reduce the amount of PW state supported by each 179 access network T-PE. 181 -ii. In some applications PWE3 edge to edge signaling and 182 encapsulation protocols are different. The terminating PEs 183 are connected to networks employing different PW signaling 184 and encapsulation protocols. In this case it is not possible 185 to use a SS-PW. A MS-PW with the appropriate interworking 186 performed at the PW switching points can enable PW 187 connectivity between the terminating PEs in this scenario. 189 A more detailed discussion of the requirements pertaining to MS-PWs 190 can be found in [RFC5254]. 192 There are four different mechanisms to establish PWs: 193 -i. Static configuration of the PW (MPLS or L2TPv3). 194 -ii. LDP using FEC 128 195 -iii. LDP using the generalized FEC 129 196 -iv. L2TPv3 198 While MS-PW are composed of PW segments, each PW segment cannot 199 function independently, as the PW service is always instantiated 200 across the complete MS-PW. Hence no PW segments, can be signaled, or 201 be operational without the complete MS-PW being signaled at once. 203 2. Specification of Requirements 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 3. Terminology 211 - PW Terminating Provider Edge (T-PE). A PE where the customer- 212 facing attachment circuits (ACs) are bound to a PW forwarder. A 213 Terminating PE is present in the first and last segments of a 214 MS-PW. This incorporates the functionality of a PE as defined in 215 [RFC3985]. 217 - Single-Segment Pseudowire (SS-PW). A PW set up directly between 218 two T-PE devices. The PW label is unchanged between the 219 originating and terminating T-PEs. 221 - Multi-Segment Pseudowire (MS-PW). A static or dynamically 222 configured set of two or more contiguous PW segments that behave 223 and function as a single point-to-point PW. Each end of a MS-PW 224 by definition MUST terminate on a T-PE. 226 - PW Segment. A part of a single-segment or multi-segment PW, which 227 traverses one PSN tunnel in each direction between two PE 228 devices, T-PEs and/or S-PEs (switching PE). 230 - PW Switching Provider Edge (S-PE). A PE capable of switching the 231 control and data planes of the preceding and succeeding PW 232 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 233 preceding and succeeding segments of the MS-PW. It therefore 234 includes a PW switching point for an MS-PW. A PW switching point 235 is never the S-PE and the T-PE for the same MS-PW. A PW switching 236 point runs necessary protocols to set up and manage PW segments 237 with other PW switching points and terminating PEs. An S-PE can 238 exist anywhere a PW must be processed or policy applied. It is 239 therefore not limited to the edge of a provider network. 241 - MS-PW path. The set of S-PEs that will be traversed in sequence 242 to form the MS-PW. 244 4. General Description 246 A pseudowire (PW) is a mechanism that carries the essential elements 247 of an emulated service from one PE to one or more other PEs over a 248 PSN as described in Figure 1 and in [RFC3985]. Many providers have 249 deployed PWs as a means of migrating existing (or building new) L2VPN 250 services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN. 252 PWs may span multiple domains of the same or different provider 253 networks. In these scenarios PW control channels (i.e. targeted LDP, 254 L2TPv3) and PWs will cross AS boundaries. 256 Inter-AS L2VPN functionality is currently supported and several 257 techniques employing MPLS encapsulation and LDP signaling have been 258 documented [RFC4364]. It is also straightforward to support the same 259 inter-AS L2VPN functionality employing L2TPv3. In this document we 260 define methodology to switch a PW between different Packet Switched 261 Network (PSN) domains or between two or more distinct PW control 262 plane domains 264 |<-------------- Emulated Service ---------------->| 265 | | 266 | |<-------- Pseudowire ------>| | 267 | | | | 268 | | |<-- PSN Tunnel -->| | | 269 | V V V V | 270 V AC +----+ +----+ AC V 271 +-----+ | | PE1|==================| PE2| | +-----+ 272 | |----------|............PW1.............|----------| | 273 | CE1 | | | | | | | | CE2 | 274 | |----------|............PW2.............|----------| | 275 +-----+ ^ | | |==================| | | ^ +-----+ 276 ^ | +----+ +----+ | | ^ 277 | | Provider Edge 1 Provider Edge 2 | | 278 | | | | 279 Customer | | Customer 280 Edge 1 | | Edge 2 281 | | 282 native service native service 284 Figure 1: PWE3 Reference Model 286 There are two methods for switching a PW between two PW domains. In 287 the first method (Figure 2), the two separate control plane domains 288 terminate on different PEs. 290 |<-------Multi-Segment Pseudowire------->| 291 | PSN PSN | 292 AC | |<-1->| |<-2->| | AC 293 | V V V V V V | 294 | +----+ +-----+ +----+ +----+ | 295 +----+ | | |=====| | | |=====| | | +----+ 296 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 297 | CE1| | | | | | | | | | | |CE2 | 298 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 299 +----+ | | |=====| | | |=====| | | +----+ 300 ^ +----+ +-----+ +----+ +----+ ^ 301 | PE1 PE2 PE3 PE4 | 302 | ^ ^ | 303 | | | | 304 | PW stitching points | 305 | | 306 | | 307 |<-------------------- Emulated Service ---------------->| 309 Figure 2: PW Switching using ACs Reference Model 311 In Figure 2, pseudowires in two separate PSNs are stitched together 312 using native service attachment circuits. PE2 and PE3 only run the 313 control plane for the PSN to which they are directly attached. At PE2 314 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 315 while PW3 and PW4 are connected using attachment circuit AC2. 317 Native |<-----Multi-Segment Pseudowire------>| Native 318 Service | PSN PSN | Service 319 (AC) | |<-Tunnel->| |<-Tunnel->| | (AC) 320 | V V 1 V V 2 V V | 321 | +----+ +-----+ +----+ | 322 +----+ | |TPE1|==========|SPE1 |==========|TPE2| | +----+ 323 | |------|.....PW.Seg't1....X....PW.Seg't3.....|-------| | 324 | CE1| | | | | | | | | |CE2 | 325 | |------|.....PW.Seg't2....X....PW.Seg't4.....|-------| | 326 +----+ | | |==========| |==========| | | +----+ 327 ^ +----+ +-----+ +----+ ^ 328 | Provider Edge 1 ^ Provider Edge 2 | 329 | | | 330 | | | 331 | PW switching point | 332 | | 333 |<----------------- Emulated Service --------------->| 334 Figure 3: MS-PW Reference Model 336 In Figure 3 SPE1 runs two separate control planes: one toward TPE1, 337 and one Toward TPE2. The PW switching point (S-PE) is configured to 338 connect PW Segment 1 and PW Segment 3 together to complete the 339 Multi-Segment PW between TPE1 and TPE2. PW Segment 1 and PW Segment 3 340 MUST be of the same PW type, but PSN Tunnel 1 and PSN Tunnel 2 need 341 not be the same technology. In the latter case, if the PW is switched 342 to a different technology, the PEs must adapt the PDU encapsulation 343 between the different PSN technologies. In the case where PSN Tunnel 344 1 and PSN Tunnel 2 are the same technology the PW PDU does not need 345 to be modified, and PDUs are then switched between the pseudowires at 346 the PW label level. 348 It should be noted that it is possible to adapt one PSN technology to 349 a different one, for example MPLS over an IP or GRE [RFC4023] 350 encapsulation, but this is outside the scope of this document. 351 Further, one could perform an interworking function on the PWs 352 themselves at the S-PE, allowing conversion from one PW type to 353 another, but this is also outside the scope of this document. 355 This document describes procedures for building multi-segment 356 pseudowires using manual configuration of the switching point PE1. 357 Other documents may build on this base specification to automate the 358 configuration and selection of S-PE1. All elements of the 359 establishment of end-to-end MS-PWs including routing and signaling 360 are out of scope of this document and any discussion in this document 361 serve purely as examples. It should also be noted that a PW can 362 traverse multiple PW switching points along it's path, and the edge 363 PEs will not require any specific knowledge of how many S-PEs the PW 364 has traversed (though this may be reported for troubleshooting 365 purposes). 367 The general approach taken for MS-PWs is to connect the individual 368 control planes by passing along any signaling information immediately 369 upon reception. First the S-PE is configured to switch a PW segment 370 from a specific peer to another PW segment destined for a different 371 peer. No control messages are exchanged yet as the S-PE does not have 372 enough information to actually initiate the PW setup messages. 373 However, if a session does not already exist, a control protocol 374 (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is 375 starting from the T-PE devices. Once the T-PE is configured it sends 376 the PW control setup messages. These messages are received by the S- 377 PE, and immediately used to form the PW setup messages for the next 378 SS-PW of the MS-PW. 380 5. PW Switching and Attachment Circuit Type 382 The PWs in each PSN are established independently, with each PSN 383 being treated as a separate PW domain. For example, in Figure 2 for 384 the case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 385 targeted session as described in [RFC4447], and at the same time a 386 separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for 387 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 388 same PW type e.g. ATM VCC, Ethernet VLAN, etc. 390 6. Applicability 392 The general applicability of MS-PWs and their relationship to L2VPNs 393 is described in [RFC5659]. The applicability of a PW type, as 394 specified in the relevant RFC for that encapsulation (e.g. [RFC4717] 395 for ATM), applies to each segment. This section describes further 396 applicability considerations. 398 As with SS-PWs, the performance of any segment will be limited by the 399 performance of the underlying PSN. The performance may be further 400 degraded by the emulation process, and performance degradation may be 401 further increased by traversing multiple PW segments. Furthermore, 402 the overall performance of an MS-PW is no better than the worst 403 performing segment of that MS-PW. 405 Since different PSN types may be able to achieve different maximum 406 performance objectives, it is necessary to carefully consider which 407 PSN types are used along the path of a MS-PW. 409 7. MPLS-PW to MPLS-PW Switching 411 Referencing Figure 3, T-PE1 set up PW segment 1 using the LDP 412 targeted session as described in [RFC4447], at the same time a 413 separate pseudowire PW segment 3 is setup to T-PE2. Each PW is 414 configured independently on the PEs, but on S-PE1 pseudowire PW 415 segment 1 is connected to pseudowire PW segment 3. PDUs are then 416 switched between the pseudowires at the PW label level. Hence the 417 data plane does not need any special knowledge of the specific 418 pseudowire type. A simple standard MPLS label swap operation is 419 sufficient to connect the two PWs, and in this case the PW adaptation 420 function cannot be used. However when pushing a new PSN label the TTL 421 SHOULD be set to 255, or some other locally configured fixed value. 423 This process can be repeated as many times as necessary, the only 424 limitation to the number of S-PEs traversed is imposed by the TTL 425 field of the PW MPLS Label. The setting of the TTL of the PW MPLS 426 label is a matter of local policy on the originating PE, but SHOULD 427 be set to 255. However if the PW PDU contains an OAM packet then the 428 TTL can be set to the required value as explained later in this 429 document. 431 There are three different MPLS to MPLS PW setup mechanisms: 432 -i. Static configuration of the PW. 433 -ii. LDP using FEC 128 434 -iii. LDP using the generalized FEC 129 435 This results in four distinct PW switching situations that are 436 significantly different, and must be considered in detail: 437 -i. PW Switching between two static control planes. 438 -ii. Static Control plane switching to LDP dynamic control plane. 439 -iii. Two LDP control planes using the same FEC type 440 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 442 7.1. Static Control plane switching 444 In the case of two static control planes the S-PE MUST be configured 445 to direct the MPLS packets from one PW into the other. There is no 446 control protocol involved in this case. When one of the control 447 planes is a simple static PW configuration and the other control 448 plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static 449 control plane should be considered similar to an attachment circuit 450 (AC) in the reference model of Figure 1. The switching point PE 451 SHOULD signal the appropriate PW status if it detects a failure in 452 sending or receiving packets over the static PW segment. In the 453 absence of a PW status communication mechanism when the PW is 454 statically configured, the status communicated to the dynamic LDP PW 455 will be limited to local interface failures. In this case, the S-PE 456 PE behaves in a very similar manner to a T-PE, assuming an active 457 signaling role. This means that the S-PE will immediately send the 458 LDP Label Mapping message if the static PW is deemed to be UP. 460 7.2. Two LDP control planes using the same FEC type 462 The S-PE SHOULD assume an initial passive role. This means that when 463 independent PWs are configured on the switching point, the LSR does 464 not advertise the LDP PW FEC mapping until it has received at least 465 one of the two PW LDP FECs from a remote PE. This is necessary 466 because the switching point LSR does not know a priori what the 467 interface parameter field in the initial FEC advertisement will 468 contain. 470 If one of the S-PEs doesn't accept an LDP Label Mapping message then 471 a Label Release message may be sent back to the originator T-PE 472 depending on the cause of the error. LDP liberal label retention mode 473 still applies, hence if a PE is simply not configured yet, the label 474 mapping is stored for future use. A MS-PW is declared UP only when 475 all the constituent SS-PWs are UP. 477 The Pseudowire Identifier (PWID), as defined in [RFC4447] is a unique 478 number between each pair of PEs. Hence Each SS-PW that forms an MS-PW 479 may have a different PWID. In the case of The Generalized PW FEC, the 480 AGI/SAI/TAI may have to also be different for some, or sometimes all, 481 SS-PWs. 483 7.2.1. FEC 129 Active/Passive T-PE Election Procedure 485 When a MS-PW is signaled using FEC 129, each T-PE might independently 486 start signaling the MS-PW. If the MS-PW path is not statically 487 configured, in certain cases the signaling procedure could result in 488 an attempt to setup each direction of the MS-PW through different S- 489 PEs. If an operator wishes to avoid this situation one of the T-PE 490 MUST start the PW signaling (active role), while the other waits to 491 receive the LDP label mapping before sending the respective PW LDP 492 label mapping message. (passive role). When the MS-PW path not 493 statically configured, the Active T-PE (the ST-PE) and the passive 494 T-PE (the TT-PE) MUST be identified before signaling is initiated for 495 a given MS-PW. 497 The determination of which T-PE assume the active role SHOULD be done 498 as follows: 500 The SAII and TAII are compared as unsigned integers, if the SAII is 501 larger, then the T-PE assumes the active role. 503 The selection process to determine which T-PE assumes the active role 504 MAY be superseded by manual provisioning. In this case one of the T- 505 PEs MUST be set to active role, and the other one MUST be set to 506 passive role. 508 7.3. LDP FEC 128 to LDP using the generalized FEC 129 510 When a PE is using the generalized FEC 129, there are two distinct 511 roles that a PE can assume: active and passive. A PE that assumes the 512 active role will send the LDP PW setup message, while a passive role 513 PE will simply reply to an incoming LDP PW setup message. The S-PE 514 PE, will always remain passive until a PWID FEC 128 LDP message is 515 received, which will cause the corresponding generalized PW FEC LDP 516 message to be formed and sent. If a generalized FEC PW LDP message is 517 received while the switching point PE is in a passive role, the 518 corresponding PW FEC 128 LDP message will be formed and sent. 520 PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice 521 versa. This can be accomplished by local S-PE configuration, or by 522 some other means, such as some form of auto discovery. Such other 523 means are outside the scope of this document. 525 7.4. LDP Switching Point PE TLV 527 The edge to edge PW might traverse several switching points, in 528 separate administrative domains. For management and troubleshooting 529 reasons it is useful to record information about the switching points 530 that the PW traverses. This is accomplished by using a PW switching 531 Point TLV. 533 Sending the PW switching Point TLV (S-PE TLV) is OPTIONAL, however 534 the PE or S-PE MUST process the TLV upon reception. The "U" bit MUST 535 be set for backward compatibility with T-PEs that do not support the 536 MS-PW extensions described in the document. The S-PE TLV MAY appear 537 only once for each switching point traversed, and it cannot be of 538 length zero. The S-PE TLV is appended to the PW FEC at each switching 539 point, and the order of the S-PE TLVs in the LDP message MUST be 540 preserved. The S-PE TLV is necessary to support some of the VCCV 541 functions for MS-PWs. See Section 9.5 for more details. The S-PE TLV 542 is encoded as follows: 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |1|0| S-PE TLV (0x096D) | S-PE TLV Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Sub-TLV Type | Length | Variable Length Value | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Variable Length Value | 552 | " " " | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 [note] LDP TLV type is pending IANA approval. 557 - S-PE TLV Length 559 Specifies the total length of all the following S-PE TLV fields 560 in octets 562 - Sub-TLV Type 564 Encodes how the Value field is to be interpreted. 566 - Length 568 Specifies the length of the Value field in octets. 570 - Value 572 Octet string of Length octets that encodes information to be 573 interpreted as specified by the Type field. 575 PW Switching point sub-TLV Types are assigned by IANA according the 576 process defined in the "IANA Allocations" section below. 578 For local policy reasons, a particular S-PE can filter out all S-PE 579 TLVs in a label mapping message that traverses it and not include 580 it's own S-PE TLV. In this case, from any upstream PE, it will 581 appear as if this particular S-PE is the T-PE. This might be 582 necessary, depending on local policy if the S-PE is at the service 583 provider administrative boundary. It should also be noted that 584 because there are no S-PE TLVs describing the path beyond the S-PE 585 that removed them, VCCV will only work as far as that S-PE . 587 7.4.1. PW Switching Point Sub-TLVs 589 The S-PE TLV contains sub-TLVs that describe various characteristics 590 of the S-PE traversed. The S-PE TLV MUST contain the appropriate 591 mandatory sub-TLVs specified below. Below are the definitions of PW 592 Switching Point Sub-TLVs defined in this document: 594 - PW ID of last PW segment traversed. 596 This is only applicable if the last PW segment traversed used LDP 597 FEC 128 to signal the PW. This sub-TLV type contains a PW ID in 598 the format of the PWID described in [RFC4447]. This is just a 32 599 bit unsigned integer number. 601 - PW Switching Point description string. 603 An OPTIONAL description string of text up to 80 characters long. 604 Human-readable text MUST be provided in the UTF-8 character set 605 using the Default Language [RFC2277]. 607 - Local IP address of PW Switching Point. 609 The Local IP V4 or V6 address of the PW Switching Point. This is 610 an OPTIONAL Sub-TLV. In most cases this will be the local LDP 611 session IP address of the S-PE. 613 - Remote IP address of the last PW Switching Point traversed or of 614 the T-PE 616 The IP V4 or V6 address of the last PW Switching Point traversed 617 or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this 618 will be the remote IP address of the LDP session. This Sub-TLV 619 SHOULD only be included if there are no other S-PE TLV present 620 from other S-PEs, or if the remote ip address of the LDP session 621 does not correspond to the "Local IP address of PW Switching 622 Point" TLV value contained in the last S-PE TLV. 624 - The FEC element of last PW segment traversed. 626 This is only applicable if the last PW segment traversed used LDP 627 FEC 129 to signal the PW. 629 The FEC element of the last PW segment traversed. This is encoded 630 in the following format: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | AGI Type | Length | Value | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 ~ AGI Value (contd.) ~ 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | AII Type | Length | Value | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 ~ SAII Value (contd.) ~ 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | AII Type | Length | Value | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 ~ TAII Value (contd.) ~ 648 | | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 - L2 PW address of PW Switching Point (recommended format). 653 This sub-TLV type contains a L2 PW address of PW Switching Point in 654 the format described in Section 3.2 of [RFC5003]. This includes the 655 AII type field, and length, as well as the L2 PW address with the AC 656 ID field set to zero. 658 7.4.2. Adaptation of Interface Parameters 660 [RFC4447] defines several interface parameters, which are used by the 661 Network Service Processing (NSP) to adapt the PW to the Attachment 662 Circuit (AC). The interface parameters are only used at the end 663 points, and MUST be passed unchanged across the S-PE. However the 664 following interface parameters MAY be modified as follows: 666 - 0x03 Optional Interface Description string This Interface 667 parameter MAY be modified, or altogether removed from the FEC 668 element depending on local configuration policies. 670 - 0x09 Fragmentation indicator This parameter MAY be inserted in 671 the FEC by the switching point if it is capable of re-assembly of 672 fragmented PW frames according to [RFC4623]. 674 - 0x0C VCCV parameter This Parameter contains the CC type, and CV 675 type bit fields. The CV type bit field MUST be reset to reflect 676 the CV type supported by the S-PE. CC type bit field MUST have 677 bit 1 "Type 2: MPLS Router Alert Label " set to 0. The other bit 678 fields MUST be reset to reflect the CC type supported by the S- 679 PE. 681 7.5. Group ID 683 The Group ID (GR ID) is used to reduce the number of status messages 684 that need to be sent by the PE advertising the PW FEC. The GR ID has 685 local significance only, and therefore MUST be mapped to a unique GR 686 ID allocated by the S-PE PE. 688 7.6. PW Loop Detection 690 A switching point PE SHOULD inspect the PW switching Point TLV, to 691 verify that it's own IP address does not appears in it. If the PE's 692 IP address appears in a received PW switching Point TLV, the PE 693 SHOULD break the loop, and send a label release message with the 694 following error code: 695 Assignment E Description 696 0x0000003A 0 "PW Loop Detected" 698 [ note: error code pending IANA allocation ] 699 If an S-PE along the MS-PW removed all S-PE TLVs, as mentioned above, 700 this loop detection method will fail. 702 8. MPLS-PW to L2TPv3-PW Control Plane Switching 704 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 705 four possibilities when switching between L2TPv3 and MPLS. 707 -i. Switching between MPLS and L2TPv3 static control planes. 708 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 709 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 710 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 712 8.1. Static MPLS and L2TPv3 PWs 714 In the case of two static control planes, the S-PE MUST be configured 715 to direct packets from one PW into the other. There is no control 716 protocol involved in this case. The configuration MUST include which 717 MPLS PW Label maps to which L2TPv3 Session ID (and associated Cookie, 718 if present) as well as which MPLS Tunnel Label maps to which PE 719 destination IP address. 721 8.2. Static MPLS PW and Dynamic L2TPv3 PW 723 When a statically configured MPLS PW is switched to a dynamic L2TPv3 724 PW, the static control plane should be considered identical to an 725 attachment circuit (AC) in the reference model of Figure 1. The 726 switching point PE SHOULD signal the appropriate PW status if it 727 detects a failure in sending or receiving packets over the static PW. 728 Because the PW is statically configured, the status communicated to 729 the dynamic L2TPv3 PW will be limited to local interface failures. In 730 this case, the S-PE PE behaves in a very similar manner to a T-PE, 731 assuming an active role. 733 8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 735 When a statically configured L2TPv3 PW is switched to a dynamic 736 LDP/MPLS PW, then the static control plane should be considered 737 identical to an attachment circuit (AC) in the reference model of 738 Figure 1. The switching point PE SHOULD signal the appropriate PW 739 status (via an L2TPv3 SLI message) if it detects a failure in sending 740 or receiving packets over the static PW. Because the PW is 741 statically configured, the status communicated to the dynamic 742 LDP/MPLS PW will be limited to local interface failures. In this 743 case, the S-PE PE behaves in a very similar manner to a T-PE, 744 assuming an active role. 746 8.4. Dynamic LDP/MPLS and L2TPv3 PWs 748 When switching between dynamic PWs, the switching point always 749 assumes an initial passive role. Thus, it does not initiate an 750 LDP/MPLS or L2TPv3 PW until it has received a connection request 751 (Label Mapping or ICRQ) from one side of the node. Note that while 752 MPLS PWs are made up of two unidirectional LSPs bonded together by 753 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 754 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 755 Establishment, Tear Down, and PW Status signaling are detailed below. 757 8.4.1. Session Establishment 759 When the S-PE receives an L2TPv3 ICRQ message, the identifying AVPs 760 included in the message are mapped to FEC identifiers and sent in an 761 LDP label mapping message. Conversely, if an LDP Label Mapping 762 message is received, it is either mapped to an ICRP message or causes 763 an L2TPv3 session to be initiated by sending an ICRQ. 765 Following are two example exchanges of messages between LDP and 766 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 767 the second is a case where an MPLS T-PE initiates an MS-PW. 769 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 771 AC "Up" 772 L2TPv3 ICRQ ---> 773 LDP Label Mapping ---> 774 AC "Up" 775 <--- LDP Label Mapping 776 <--- L2TPv3 ICRP 777 L2TPv3 ICCN ---> 778 <-------------------- MS-PW Established ------------------> 779 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 781 AC "Up" 782 LDP Label Mapping ---> 783 L2TPv3 ICRQ ---> 784 <--- L2TPv3 ICRP 785 <--- LDP Label Mapping 786 L2TPv3 ICCN ---> 787 AC "Up" 788 <-------------------- MS-PW Established ------------------> 790 8.4.2. Adaptation of PW Status message 792 L2TPv3 uses the SLI message to indicate a interface status change 793 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 794 PWs either signal this via an LDP Label Withdraw or the PW Status 795 Notification message defined in section 4.4 of [RFC4447]. The LDP 796 status TLV bit SHOULD be mapped to the L2TPv3 equivalent Extended 797 Circuit Status Values TLV specified in [RFC5641]. 799 8.4.3. Session Tear Down 801 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 802 message translates to a Label Withdraw message in LDP. Following are 803 two example exchanges of messages between LDP and L2TPv3. The first 804 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 805 the second is a case where an MPLS T-PE initiates the termination of 806 an MS-PW. 808 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 810 AC "Down" 811 L2TPv3 CDN ---> 812 LDP Label Withdraw ---> 813 AC "Down" 814 <-- LDP Label Release 816 <--------------- MS-PW Data Path Down ------------------> 817 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 819 AC "Down" 820 LDP Label Withdraw ---> 821 L2TPv3 CDN --> 822 <-- LDP Label Release 823 AC "Down" 825 <---------------- MS-PW Data Path Down ------------------> 827 8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 829 [RFC4447] defines several interface parameters which MUST be mapped 830 to the equivalent AVPs in L2TPv3 setup messages. 832 * Interface MTU 834 The Interface MTU parameter is mapped directly to the L2TP 835 Interface MTU AVP defined in [RFC4667] 837 * Max Number of Concatenated ATM cells 839 This interface parameter is mapped directly to the L2TP "ATM 840 Maximum Concatenated Cells AVP" described in section 6 of 841 [RFC4454]. 843 * PW Type 845 The PW Type defined in [RFC4446] is mapped to the L2TPv3 "PW 846 Type" AVP defined in [RFC3931]. 848 * PW ID (FEC 128) 850 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 851 End ID" AVP defined in [RFC3931]. 853 * Generalized FEC 129 SAI/TAI 855 Section 4.3 of [RFC4667] defines how to encode the SAI and TAI 856 parameters. These can be mapped directly. 858 Other interface parameter mappings are unsupported when switching 859 between LDP/MPLS and L2TPv3 PWs. 861 8.6. Switching Point TLV in L2TPv3 863 When translating between LDP and L2TPv3 control messages, the PW 864 Switching Point TLV described earlier in this document is carried in 865 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 866 and optionally in the ICCN message. 868 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 869 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 870 the AVP is 6 plus the length of the series of Switching Point sub- 871 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 872 (the L2TP AVP M-bit MUST be 0). 874 8.7. L2TPv3 and MPLS PW Data Plane 876 When switching between an MPLS and L2TP PW, packets are sent in their 877 entirety from one PW to the other, replacing the MPLS label stack 878 with the L2TPv3 and IP header or vice versa. 880 Section 5.4 of [RFC3985] discusses the purpose of the various shim 881 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 882 For L2TPv3, the Payload Convergence and Sequencing function is 883 carried out via the Default L2-Specific Sublayer defined in 884 [RFC3931]. For MPLS, these two functions (together with PSN 885 Convergence) are carried out via the MPLS Control Word. Since these 886 functions are different between MPLS and L2TPv3, interworking between 887 the two may be necessary. 889 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 890 which in some cases are not necessary to be present at all. For 891 example, an Ethernet PW with sequencing disabled will generally not 892 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 893 be present at all. In this case, Ethernet frames are simply sent from 894 one PW to the other without any modification beyond the MPLS and 895 L2TP/IP encapsulation and decapsulation. 897 The following section offers guidelines for how to interwork between 898 L2TP and MPLS for those cases where the Payload Convergence, 899 Sequencing, or PSN Convergence functions are necessary on one or both 900 sides of the switching node. 902 8.7.1. Mapping the MPLS Control Word to L2TP 904 The MPLS Control Word consists of (from left to right): 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |0 0 0 0| Reserved | Length | Sequence Number | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 -i. These bits are always zero in an MPLS PW PDU. It is not 913 necessary map them to L2TP. 915 -ii. These six bits may be used for Payload Convergence depending 916 on the PW type. For ATM, the first four of these bits are 917 defined in [RFC4717]. These map directly to the bits defined 918 in [RFC4454]. For Frame Relay, these bits indicate how to 919 set the bits in the Frame Relay header which must be 920 regenerated for L2TP as it carries the Frame Relay header 921 intact. 923 -iii. L2TP determines its payload length from IP. Thus, this 924 Length field need not be carried directly to L2TP. This 925 Length field will have to be calculated and inserted for 926 MPLS when necessary. 928 -iv. The Default L2-Specific Sublayer has a sequence number with 929 different semantics than that of the MPLS Control Word. This 930 difference eliminates the possibility of supporting 931 sequencing across the MS-PW by simply carrying the sequence 932 number through the switching point transparently. As such, 933 sequence numbers MAY be supported by checking the sequence 934 numbers of packets arriving at the switching point and 935 regenerating a new sequence number in the appropriate format 936 for the PW on egress. If this type of sequence interworking 937 at the switching node is not supported, and a T-PE requests 938 sequencing of all packets via the L2TP control channel 939 during session setup, the switching node SHOULD NOT allow 940 the session to be established by sending a CDN message with 941 Result Code set to 17 "sequencing not supported" (subject to 942 IANA Assignment). 944 9. Operation And Management 946 9.1. Extensions to VCCV to Support MS-PWs 948 Single-segment pseudowires are signaled using the Virtual Circuit 949 Connectivity Verification (VCCV) parameter included in the interface 950 parameter field of the PW ID FEC TLV or the interface parameter sub- 951 TLV of the Generalized PW ID FEC TLV as described in [RFC5085]. When 952 a switching point exist between PE nodes, it is required to be able 953 to continue operating VCCV end-to-end across a switching point and to 954 provide the ability to trace the path of the MS-PW over any number of 955 segments. 957 This document provides a method for achieving these two objectives. 958 This method is based on re-using the existing VCCV CW and 959 decrementing the TTL of the PW label at each S-PE in the path of the 960 MS-PW. 962 9.2. MPLS PW to L2TPv3 PW OAM 964 When an MS-PW includes SS-PWs that use the L2TPv3 the MPLS PW OAM 965 MUST, be terminated at the S-PE connecting the L2TPv3 and MPLS 966 segments. Status information received in a particular PW segment can 967 then be used to generate the appropriate status messages on on the 968 following PW segment. In the case of L2TPV3 the status bits in the 969 circuit status AVP defined in section 5.4.5 of [RFC3931] and Extended 970 Circuit Status Values defined in [RFC5641] can be directly be mapped 971 to the PW status bits defined in [RFC4447] section 5.4.3. 973 VCCV messages are specific to the MPLS data plane, and cannot be used 974 for an L2TPv3 PW segment. Therefore, the S-PE MUST NOT send the VCCV 975 parameter included in the interface parameter field of the PW ID FEC 976 TLV or the sub-TLV interface parameter of the Generalized PW ID FEC 977 TLV. It might be possible to translate VCCV messages from L2TPv3 PW 978 segments to MPLS PW segments and vice verso, however this topic is 979 left for further study. 981 9.3. MPLS PW to MPLS PW OAM Data Plane Indication 983 As stated above the S-PE MUST perform a standard MPLS label swap 984 operation on the MPLS PW label. By the rules defined in [RFC3032] the 985 PW label TTL MUST be decreased at every S-PE. Once the PW label TTL 986 reaches the value of 0, the packet is sent to the control plane to be 987 processed. Hence, by controlling the PW TTL value of the PW label it 988 is possible to select exactly which S-PE will respond to the VCCV 989 packet. 991 9.4. Signaling OAM Capabilities for Switched Pseudowires 993 Similarly to SS-PW, MS-PW VCCV capabilities are signaled using the 994 VCCV parameter included in the interface parameter field of the PW ID 995 FEC TLV or the sub-TLV interface parameter of the Generalized PW ID 996 FEC TLV as described in [RFC5085]. 998 In Figure 3 T-PE1 uses the VCCV parameter included in the interface 999 parameter field of the PW ID FEC TLV or the sub-TLV interface 1000 parameter of the Generalized PW ID FEC TLV to indicate to the far end 1001 T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV 1002 parameter as would be used if T-PE1 and T-PE2 were connected 1003 directly. S-PE2, which is a PW switching point, as part of the 1004 adaptation function for interface parameters, processes locally the 1005 VCCV parameter then passes it to T-PE2. If there were multiple S-PEs 1006 on the path between T-PE1 and T-PE2, each would carry out the same 1007 processing, passing along the VCCV parameter. The local processing of 1008 the VCCV parameter removes CC Types specified by the originating T-PE 1009 that are not supported on the S-PE. For example, if T-PE1 indicates 1010 supports CC Types 1,2,3 and the Then the S-PE removes the Router 1011 Alert CC Type=2, leaving the rest of the TLV unchanged, and passes 1012 the modified VCCV parameter to the next S-PE along the path. 1014 The far end T-PE (T-PE2) receives the VCCV parameter indicating only 1015 the CC types that are supported by the initial T-PE (T-PE1) and all 1016 S-PEs along the PW path. 1018 9.5. OAM Capability for MS-PWs Demultiplexed using MPLS 1020 The VCCV parameter ID is defined as follows in [RFC4446]: 1022 Parameter ID Length Description 1023 0x0c 4 VCCV 1025 The format of the VCCV parameter field is as follows: 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | 0x0c | 0x04 | CC Types | CV Types | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 0x01 Type 1: PWE3 control word with 0001b as first nibble 1034 as defined in [RFC4385]. 1035 0x02 Type 2: MPLS Router Alert Label. 1036 0x04 Type 3: MPLS PW Demultiplexor Label TTL = 1 (Type 3). 1038 9.5.1. MS-PW and VCCV CC Type 1 1040 VCCV CC type 1 can be used for MS-PWs. However, if the CW is enabled 1041 on user packets, VCCV CC type 1 MUST be used according to the rules 1042 in [RFC5085]. When using CC type 1 for MS-PWs the PE transmitting 1043 the VCCV packet MUST set the TTL to the appropriate value to reach 1044 the destination S-PE. However if the packet is destined for the T-PE, 1045 the TTL can be set to any value that is sufficient for the packet to 1046 reach the T-PE. 1048 9.5.2. MS-PW and VCCV CC type 2 1050 VCCV CC type 2 is not supported for MS-PWs and MUST be removed from a 1051 VCCV parameter field by the S-PE. 1053 9.5.3. MS-PW and VCCV CC type 3 1055 VCCV CC type 3 can be used for MS-PWs, however if the CW is enabled 1056 VCCV type 1 is preferred according to the rules in [RFC5085]. Note 1057 that for using the VCCV type 3, TTL method, the PE will set the PW 1058 label TTL to the appropriate value necessary to reach the target PE, 1059 otherwise the VCCV packet might be forwarded over the AC to the CPE. 1061 9.6. MS-PW VCCV Operations 1063 This document specifies four VCCV operations: 1064 -i. End-to-end MS-PW connectivity verification. This operation 1065 enables the connectivity of the MS-PW to be tested from 1066 source T-PE to destination T-PE. In order to do this, the 1067 sending T-PE must include the FEC used in the last segment 1068 of the MS-PW to the destination T-PE in the VCCV-Ping echo 1069 request. This information is either configured at the 1070 sending T-PE or is obtained by processing the corresponding 1071 sub-TLVs of the optional S-PE TLV, as described below. 1072 -ii. Partial MS-PW connectivity verification. This operation 1073 enables the connectivity of any contiguous subset of the 1074 segments of a MS-PW to be tested from the source T-PE or a 1075 source S-PE to a destination S-PE or T-PE. Again, the FEC 1076 used on the last segment to be tested must be included in 1077 the VCCV-Ping echo request message. This information is 1078 determined by the sending T-PE or S-PE as in (i) above. 1079 -iii. MS-PW path verification. This operation verifies the path of 1080 the MS-PW, as returned by the S-PE TLV, against the actual 1081 data path of the MS-PW. The sending T-PE or S-PE iteratively 1082 sends a VCCV echo request to each S-PE along the MS-PW path, 1083 using the FEC for the corresponding MS-PW segment in the 1084 switching point TLV. If the S-PE TLV information is correct, 1085 then a VCCV echo reply showing that this is a valid router 1086 for the FEC will be received. However, if the switching 1087 point TLV information is incorrect, then this operation 1088 enables the first incorrect switching point to be 1089 determined, but not the actual path of the MS-PW beyond 1090 that. This operation cannot be used when the MS-PW is 1091 statically configured or when the S-PE TLV is not supported. 1092 The processing of the PW switching TLV used for this 1093 operation is described below. This operation is OPTIONAL. 1094 -iv. MS-PW path trace. This operation traces the data path of the 1095 MS-PW using FECs included in the Target FEC stack TLV 1096 [RFC4379] returned by S-PEs or T-PEs in an echo reply 1097 message. The sending T-PE or S-PE uses this information to 1098 recursively test each S-PE along the path of the MS-PW in a 1099 single operation in a similar manner to LSP trace. This 1100 operation is able to determine the actual data path of the 1101 MS-PW, and can be used for both statically configured and 1102 signaled MS-PWs. Support for this operation is OPTIONAL. 1104 Note that the above operations rely on intermediate S-PEs and/or the 1105 destination T-PE to include the switching point TLV as a part of the 1106 MS-PW setup process, or to include the Target FEC stack TLV in the 1107 VCCV echo reply message. For various reasons, e.g. privacy or 1108 security of the S-PE/T-PE, this information may not be available to 1109 the source T-PE. In these cases, manual configuration of the FEC MAY 1110 still be used. 1112 9.6.1. VCCV Echo Message Processing 1114 The challenge for the control plane is to be able to build the VCCV 1115 echo request packet with the necessary information to reach the 1116 desired S-PE or T-PE, for example the target FEC 128 PW sub-TLV of 1117 the downstream PW segment that the packet is destined for. This could 1118 be even more difficult in situations in which the MS-PW spans 1119 different providers and Autonomous Systems. 1121 For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW 1122 segment 1, but it does not readily have the information required to 1123 compose the FEC128 of the following segment, PW segment 3, if a VCCV 1124 echo request to be sent to T-PE2. This can be achieved by the methods 1125 described in the following subsections. 1127 9.6.1.1. Sending a VCCV Echo Request 1129 When performing a partial or end-to-end connectivity or path 1130 verification, the sender of the echo request message requires the FEC 1131 of the last segment to the target S-PE/T-PE node. This information 1132 can either be configured manually or be obtained by inspecting the 1133 corresponding sub-TLVs of the PW switching point TLV. 1135 The necessary S-PE sub-TLVs are : 1137 Type Description 1138 0x01 PW ID of last PW segment traversed 1139 0x03 Local IP address of PW Switching Point 1140 0x04 Remote IP address of last PW Switching Point traversed or 1141 of the T-PE 1143 When performing an OPTIONAL MS-PW path trace operation, the T-PE will 1144 automatically learn the target FEC by probing, one by one, the S-PEs 1145 of the MS-PW path, using the FEC returned in the Target FEC stack of 1146 the previous VCCV echo reply. 1148 9.6.1.2. Receiving a VCCV Echo Request 1150 Upon receiving a VCCV echo request the control plane on S-PEs (or the 1151 target node of each segment of the MS-PW) validates the request and 1152 responds to the request with an echo reply consisting of a return 1153 code of 8 (label switched at stack-depth) indicating that it is an 1154 S-PE and not the egress router for the MS-PW. 1156 S-PEs that wish to reveal their downstream next-hop in a trace 1157 operation should include the FEC of the downstream PW segment in the 1158 Target FEC stack (as per Sections 3.2 and 4.5 of [RFC4379]) of the 1159 echo reply message. FEC128 PWs MUST use the format shown in Section 1160 3.2.09 of [RFC4379] for the sub-TLV in the Target FEC stack, while 1161 FEC129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379] 1162 for the sub-TLV in the Target FEC stack. Note that an S-PE MUST NOT 1163 include this FEC information in the reply if it has been configured 1164 not to do so for administrative reasons, or for reasons explained 1165 previously. 1167 If the node is the T-PE or the egress node of the MS-PW, it responds 1168 to the echo request with an echo reply with a return code of 3 1169 (egress router). 1171 9.6.1.3. Receiving a VCCV Echo Reply 1173 The operation to be taken by the node receiving the echo reply in 1174 response to an echo request depends on the VCCV mode of operation 1175 described above. See Section 9.5.2 for detailed procedures. 1177 9.6.2. Detailed VCCV procedures 1179 There are two similar methods of verifying the MS-PW path: Path 1180 Trace, and Path Verification. Path Trace does not use the LDP control 1181 plane to obtain information on the path to verify, so this method is 1182 well suited if portions of the MS-PW are statically configured SS- 1183 PWs. The Path Verification method relies on information obtained from 1184 the LDP control plane, and hence offers better verification of the 1185 current forwarding behavior compared to the LDP signaled forwarding 1186 information of the MS-PW path. However in the case where there are 1187 statically signaled SS-PW in the MS-PW path, the path information is 1188 unavailable and must be programmed manually. 1190 9.6.2.1. End to End Connectivity Verification Between T-PEs 1192 In Figure 3, if T-PE1, S-PE and T-PE2 support Control Word, the PW 1193 control plane will automatically negotiate the use of the CW. VCCV CC 1194 type 3 will function correctly whether the CW is enable or not on the 1195 PW. However VCCV type 1 for (which can be use for end to end 1196 verification only), is only supported if the CW is enabled. 1198 At the S-PE the data path operations include an outer label pop, 1199 inner label swap and new outer label push. Note that there is no 1200 requirement for the S-PE to inspect the CW. Thus, the end-to-end 1201 connectivity of the multi-segment pseudowire can be verified by 1202 performing all of the following steps: 1203 -i. T-PE forms a VCCV-ping echo request message with the FEC 1204 matching that of the last segment PW to the destination T- 1205 PE. 1207 -ii. T-PE sets the inner PW label TTL to the exact value to allow 1208 the packet to reach the far end T-PE. ( the value is 1209 determined by counting the number of S-PEs from the control 1210 plane information ) Alternatively, if CC type 1 is supported 1211 the packet can be encapsulated according to CC type 1 in 1212 [RFC5085] 1214 -iii. T-PE sends a VCCV packet that will follow the exact same 1215 data path at each S-PE as that taken by data packets. 1217 -iv. S-PE may performs an outer label pop, if PHP is disabled, 1218 and will perform an inner label swap with TTL decrement, and 1219 new outer label push. 1221 -v. There is no requirement for the S-PE to inspect the CW. 1223 -vi. The VCCV packet is diverted to VCCV control processing at 1224 the destination T-PE. 1226 -vii. Destination T-PE replies using the specified reply mode, 1227 i.e., reverse PW path or IP path. 1229 9.6.2.2. Partial Connectivity Verification from T-PE 1231 In order to trace part of the multi-segment pseudowire, the TTL of 1232 the PW label may be used to force the VCCV message to 'pop out' at an 1233 intermediate node. When the TTL expires, the S-PE can determine that 1234 the packet is a VCCV packet by either checking the control word (CW), 1235 or if the CW is not in use by checking for a valid IP header with UDP 1236 destination port 3503. The packet should then be diverted to VCCV 1237 processing. 1239 In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW 1240 label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus 1241 verify the first segment of the pseudowire. 1243 The VCCV packet is built according to [RFC4379] section 3.2.9 for FEC 1244 128, or 3.2.10 for a FEC 129 PW. All the information necessary to 1245 build the VCCV LSP ping packet is collected by inspecting the S-PE 1246 TLVs. 1248 Note that this use of the TTL is subject to the caution expressed in 1250 [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and 1251 a T-PE manipulates the PW label TTL, the VCCV message may not emerge 1252 from the MS-PW at the correct S-PE. 1254 9.6.2.3. Partial connectivity verification between S-PEs 1256 Assuming that all nodes along an MS-PW support the Control Word CC 1257 Type 3, VCCV between S-PEs may be accomplished using the PW label TTL 1258 as described above. In Figure 3, the S-PE may verify the path between 1259 it and T-PE2 by sending a VCCV message with the PW label TTL set to 1260 1. Given a more complex network with multiple S-PEs, an S-PE may 1261 verify the connectivity between it and an S-PE two segments away by 1262 sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE 1263 can diagnose connectivity problems by successively increasing the 1264 TTL. All the information needed to build the proper VCCV echo 1265 request packet as described in [RFC4379] section 3.2.9 or 3.2.10 is 1266 obtained automatically from the LDP label mapping that contains S-PE 1267 TLVs. 1269 9.6.2.4. MS-PW Path Verification 1271 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1272 originating from T-PE1 by a single operational command. The following 1273 process ensues: 1274 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1275 containing the pseudowire information of the first segment 1276 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1277 Stack Validation is enabled, the request may also include 1278 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1279 dependent on the type of transport tunnel the segmented PW 1280 is riding on. 1282 -ii. S-PE validates the echo request with the FEC. Since it is a 1283 switching point between the first and second segment it 1284 builds an echo reply with a return code of 8 and sends the 1285 echo reply back to T-PE1. 1287 -iii. T-PE1 builds a second VCCV echo request based on the 1288 information obtained from the control plane (S-PE TLV). It 1289 then increments the TTL and sends it out to T-PE2. Note that 1290 the VCCV echo request packet is switched at the S-PE data 1291 path and forwarded to the next downstream segment without 1292 any involvement from the control plane. 1294 -iv. T-PE2 receives and validates the echo request with the FEC. 1295 Since T-PE2 is the destination node or the egress node of 1296 the MS-PW it replies to T-PE1 with an echo reply with a 1297 return code of 3 (Egress Router). 1299 -v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1300 aware that T-PE2 is the destination of the MS-PW because the 1301 echo reply has a return code of is 3. The trace process is 1302 completed. 1304 If no echo reply is received, or an error code is received from a 1305 particular PE, the trace process MUST stop immediately, and packets 1306 MUST NOT be sent further along the MS-PW. 1308 For more detail on the format of the VCCV echo packet, refer to 1309 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1310 (PW) label TTL. 1312 9.6.2.5. MS-PW Path Trace 1314 As an example, in Figure 3, VCCV trace can be performed on the MS-PW 1315 originating from T-PE1 by a single operational command. The following 1316 OPTIONAL process ensues: 1318 -i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC 1319 containing the pseudowire information of the first segment 1320 (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC 1321 Stack Validation is enabled, the request may also include 1322 additional sub-TLV such as LDP Prefix and/or RSVP LSP 1323 dependent on the type of transport tunnel the segmented PW 1324 is riding on. 1326 -ii. The S-PE validates the echo request with the FEC. 1328 -iii. The S-PE builds an echo reply with a return code of 8 and 1329 sends the echo reply back to T-PE1, appending the FEC128 1330 information for the next segment along the MS-PW to the VCCV 1331 echo reply packet using the Target FEC stack TLV (as per 1332 Sections 3.2 and 4.5 of [RFC4379]). 1334 -iv. T-PE1 builds a second VCCV echo request based on the 1335 information obtained from the FEC stack TLV received in the 1336 previous VCCV echo reply. It then increments the TTL and 1337 sends it out to T-PE2. Note that the VCCV echo request 1338 packet is switched at the S-PE data path and forwarded to 1339 the next downstream segment without any involvement from the 1340 control plane. 1342 -v. T-PE2 receives and validates the echo request with the FEC. 1343 Since T-PE2 is the destination node or the egress node of 1344 the MS-PW it replies to T-PE1 with an echo reply with a 1345 return code of 3 (Egress Router). 1347 -vi. T-PE1 receives the echo reply from T-PE2. T-PE1 is made 1348 aware that T-PE2 is the destination of the MS-PW because the 1349 echo reply has a return code of is 3. The trace process is 1350 completed. 1352 If no echo reply is received, or an error code is received from a 1353 particular PE, the trace process MUST stop immediately, and packets 1354 MUST NOT be sent further along the MS-PW. 1356 For more detail on the format of the VCCV echo packet, refer to 1357 [RFC5085] and [RFC4379]. The TTL here refers to that of the inner 1358 (PW) label TTL. 1360 10. Mapping Switched Pseudowire Status 1362 In the PW switching with attachment circuits case (Figure 2), PW 1363 status messages indicating PW or attachment circuit faults MUST be 1364 mapped to fault indications or OAM messages on the connecting AC as 1365 defined in [PW-MSG-MAP]. 1367 In the PW control plane switching case (Figure 3), there is no 1368 attachment circuit at the S-PE, but the two PWs are connected 1369 together. Similarly, the status of the PWs are forwarded unchanged 1370 from one PW to the other by the control plane switching function. 1371 However, it may sometimes be necessary to communicate fault status of 1372 one of the locally attached PW segments at a S-PE. For LDP this can 1373 be accomplished by sending an LDP notification message containing the 1374 PW status TLV, as well as an OPTIONAL PW switching point TLV as 1375 follows: 1377 0 1 2 3 1378 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 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 |0| Notification (0x0001) | Message Length | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Message ID | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 |0|1| Status (0x0300) | Length | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 |0|1| Status Code=0x00000028 | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Message ID=0 | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Message Type=0 | PW Status TLV | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | PW Status TLV | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | PW Status TLV | PWId FEC | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | | 1397 | | 1398 | PWId FEC or Generalized ID FEC | 1399 | | 1400 | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 |1|0| S-PE TLV (0x096D) | S-PE TLV Length | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Type | Length | Variable Length Value | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Only one S-PE TLV can be present in this message. This message is 1408 then relayed by each S-PE unchanged. The T-PE decodes the status 1409 message and the included S-PE TLV to detect exactly where the fault 1410 occurred. At the T-PE if there is no S-PE TLV included in the LDP 1411 status notification then the status message can be assumed to have 1412 originated at the remote T-PE. 1414 The merging of the received LDP status and the local status for the 1415 PW segments at an S-PE can be summarized as follows: 1417 -i. When the local status for both PW segments is UP, the S-PE 1418 passes any received AC or PW status bits unchanged, i.e., 1419 the status notification TLV is unchanged but the PWid in the 1420 case of a FEC 128 TLV is set to the value of the PW segment 1421 of the next hop. 1423 -ii. When the local status for any of the PW segments is at 1424 fault, the S-PE always sends the local status bits 1425 regardless if the received status bits from the remote node 1426 indicated that an upstream fault has cleared. AC status bit 1427 are passed along unchanged. 1429 10.1. S-PE initiated PW status messages 1431 The PW fault directions are defined as follows: 1433 +-------+ 1434 ---PW1 receive---->| |-----PW2 Transmit----> 1435 S-PE1 | S-PE2 | S-PE3 1436 <--PW1 Transmit----| |<----PW2 Receive------ 1437 +-------+ 1438 Figure 4. S-PE and PW tx/rx directions. 1440 When a local fault is detected by the S-PE, a PW status message is 1441 sent in both directions along the PW. Since there are no attachment 1442 circuits on an S-PE, only the following status messages are relevant: 1444 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 1445 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 1447 Each S-PE needs to store only two 32-bit PW status words for each PW 1448 segment: One for local failures, and one for remote failures 1449 (normally received from another PE). The first failure will set the 1450 appropriate bit in the 32-bit status word, and each subsequent 1451 failure will be ORed to the appropriate PW status word. In the case 1452 of the PW status word storing remote failures, this rule has the 1453 effect of a logical OR operation with the first failure received on 1454 the particular PW segment. 1456 It should be noted that remote failures received on an S-PE are just 1457 passed along the MS-PW unchanged while local failures detected an S- 1458 PE are signalled on both PW segments. 1460 A T-PE can receive multiple failures from S-PEs along the MS-PW, 1461 however only the failure from the remote closest S-PE will be stored 1462 (last pw status message received). The PW status word received are 1463 just ORed to any existing remote PW status already stored on the T- 1464 PE. 1466 Given that there are two PW segments at a particular S-PE for a 1467 particular MS-PW, referring to figure 4, there are four possible 1468 failure cases as follows: 1470 -i. PW2 Transmit direction fault 1471 -ii. PW1 Transmit direction fault 1472 -iii. PW2 Receive direction fault 1473 -iv. PW1 Receive direction fault 1475 Once a PW status notification message is initiated at a S-PE for a 1476 particular PW status bit any further status message, for the same 1477 status bit, received from an upstream neighbor is processed locally 1478 and not forwarded until the S-PE original status error state is 1479 cleared. 1481 Each S-PE along the MS-PW MUST store any PW status messages 1482 transiting it. If more than one status message with the same PW 1483 status bit set is received by a T-PE, or S-PE only the last PW 1484 status message is stored. 1486 10.1.1. Local PW2 transmit direction fault 1488 When this failure occurs the S-PE will take the following actions: 1490 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1491 PSN-facing PW (egress) Transmit Fault" 1492 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1493 PSN-facing PW (ingress) Receive Fault" 1494 * Store 0x00000010 in the local PW status word for the PW segment 1495 toward S-PE3. 1497 10.1.2. Local PW1 transmit direction fault 1499 When this failure occurs the S-PE will take the following actions: 1501 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1502 PSN-facing PW (egress) Transmit Fault" 1503 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1504 PSN-facing PW (ingress) Receive Fault" 1505 * Store 0x00000010 in the local PW status word for the PW segment 1506 toward S-PE1. 1508 10.1.3. Local PW2 receive direction fault 1510 When this failure occurs the S-PE will take the following actions: 1511 * Send a PW status message to S-PE3 containing "0x00000008 - Local 1512 PSN-facing PW (ingress) Receive Fault" 1513 * Send a PW status message to S-PE1 containing "0x00000010 - Local 1514 PSN-facing PW (egress) Transmit Fault" 1515 * Store 0x00000008 in the local PW status word for the PW segment 1516 toward S-PE3. 1518 10.1.4. Local PW1 receive direction fault 1520 When this failure occurs the S-PE will take the following actions: 1521 * Send a PW status message to S-PE1 containing "0x00000008 - Local 1522 PSN-facing PW (ingress) Receive Fault" 1523 * Send a PW status message to S-PE3 containing "0x00000010 - Local 1524 PSN-facing PW (egress) Transmit Fault" 1525 * Store 0x00000008 in the local PW status word for the PW segment 1526 toward S-PE1. 1528 10.1.5. Clearing Faults 1530 Remote PW status fault clearing messages received by an S-PE will 1531 only be forwarded if there are no corresponding local faults on the 1532 S-PE. (local faults always supersede remote faults) 1534 Once the local fault has cleared, and there is no corresponding (same 1535 PW status bit set) remote fault, a PW status messages is sent out to 1536 the adjacent PEs clearing the fault. 1538 When a PW status fault clearing message is forwarded, the S-PE will 1539 always send the S-PE TLV associated with the PE which cleared the 1540 fault. 1542 10.2. PW status messages and S-PE TLV processing 1544 When a PW status message is received that includes a S-PE TLV, the 1545 S-PE TLV information MAY be stored, along with the contents of the PW 1546 status Word according to the procedures described above. The S-PE TLV 1547 stored is always the S-PE TLV that is associated with the PE that set 1548 that particular last fault. If subsequent PW status message for the 1549 same PW status bit are received the S-PE TLV will overwrite the 1550 previously stored S-PE TLV. 1552 10.3. T-PE processing of PW status messages 1554 The PW switching architecture is based on the concept that the T-PE 1555 should process the PW LDP messages in the same manner as if it was 1556 participating in the setup of a PW segment. However T-PE 1557 participating a MS-PW, SHOULD be able to process the S-PE TLV. 1558 Otherwise the processing of PW status messages, and other PW setup 1559 messages is exactly as described in [RFC4447]. 1561 10.4. Pseudowire Status Negotiation Procedures 1563 Pseudowire Status signaling methodology, defined in [RFC4447], SHOULD 1564 be transparent to the switching point. 1566 10.5. Status Dampening 1568 When the PW control plane switching methodology is used to cross an 1569 administrative boundary it might be necessary to prevent excessive 1570 status signaling changes from being propagated across the 1571 administrative boundary. This can be achieved by using a similar 1572 method as commonly employed for the BGP protocol route advertisement 1573 dampening. The details of this OPTIONAL algorithm are a matter of 1574 implementation, and are outside the scope of this document. 1576 11. Peering Between Autonomous Systems 1578 The procedures outlined in this document can be employed to provision 1579 and manage MS-PWs crossing AS boundaries. The use of more advanced 1580 mechanisms involving auto-discovery and ordered PWE3 MS-PW signaling 1581 will be covered in a separate document. 1583 12. Congestion Considerations 1585 Each PSN carrying the PW may be subject to congestion. The Congestion 1586 considerations in [RFC3985] apply to PW segments as well. Each PW 1587 segment will handle any congestion experienced by the PW traffic 1588 independently of the other MS-PW segments. It is possible that 1589 passing knowledge of congestion between segments, and to the T-PEs 1590 can result in more efficient edge to edge congestion mitigation 1591 systems. However any specific methods of congestion mitigation are 1592 outside the scope of this document and left for further study. 1594 13. Security Considerations 1596 This document specifies the LDP, L2TPv3, and VCCV extensions that are 1597 needed for setting up and maintaining pseudowires. The purpose of 1598 setting up pseudowires is to enable layer 2 frames to be encapsulated 1599 and transmitted from one end of a pseudowire to the other. Therefore 1600 we discuss the security considerations for both the data plane and 1601 the control plane in the following sections. The guidelines, and 1602 security considerations specified in [RFC5920], also apply to MS-PW 1603 when the PSN is MPLS. 1605 13.1. Data Plane Security 1607 Data plane security consideration as discussed in [RFC4447], 1608 [RFC3931], and [RFC3985] apply to this extension without any changes. 1610 13.1.1. VCCV Security considerations 1612 The VCCV technology for MS-PW offers a method for the service 1613 provider to verify the data path of a specific PW. This involves 1614 sending a packet to a specific PE and receiving an answer which 1615 either confirms, or indicates that the information contained in the 1616 packet is incorrect. This is a very similar process to the commonly 1617 used IP ICMP ping, and TTL expired methods for IP networks. It should 1618 be noted that when using VCCV Type 3 for PW when the CW is not 1619 enabled, if a packet is crafted with a TTL greater then the number of 1620 hops along the MS-PW path, or an S-PE along the path mis-processes 1621 the TTL, the packet could mistakenly be forwarded out the attachment 1622 circuit as a native PW packet. This packet would most likely be 1623 treated as an error packet by the CE. However if this possibility is 1624 not acceptable, the CW should be enabled to guarantee that a VCCV 1625 packet will never be mistakenly forwarded to the AC. 1627 13.2. Control Protocol Security 1629 General security considerations with regard to the use of LDP are 1630 specified in section 5 of RFC 5036. Security considerations with 1631 regard to the L2TPv3 control plane are specified in [RFC3931]. These 1632 considerations apply as well to the case where LDP or L2TPv3 is used 1633 to set up PWs. 1635 A Pseudowire connects two attachment circuits. It is important to 1636 make sure that LDP connections are not arbitrarily accepted from 1637 anywhere, or else a local attachment circuit might get connected to 1638 an arbitrary remote attachment circuit. Therefore an incoming session 1639 request MUST NOT be accepted unless its IP source address is known to 1640 be the source of an "eligible" peer. The set of eligible peers could 1641 be pre-configured (either as a list of IP addresses, or as a list of 1642 address/mask combinations), or it could be discovered dynamically via 1643 an auto-discovery protocol which is itself trusted. (Note that if the 1644 auto-discovery protocol were not trusted, the set of "eligible peers" 1645 it produces could not be trusted.) 1647 Even if a connection request appears to come from an eligible peer, 1648 its source address may have been spoofed. So some means of 1649 preventing source address spoofing must be in place. For example, if 1650 all the eligible peers are in the same network, source address 1651 filtering at the border routers of that network could eliminate the 1652 possibility of source address spoofing. 1654 For a greater degree of security, the LDP authentication option, as 1655 described in section 2.9 of [RFC5036], or the Control Message 1656 Authentication option of [RFC3931] MAY be used. This provides 1657 integrity and authentication for the control messages, and eliminates 1658 the possibility of source address spoofing. Use of the message 1659 authentication option does not provide privacy, but privacy of 1660 control messages are not usually considered to be highly important. 1661 Both the LDP and L2TPv3 message authentication options rely on the 1662 configuration of pre-shared keys, making it difficult to deploy when 1663 the set of eligible neighbors is determined by an auto-configuration 1664 protocol. 1666 The protocol described in this document relies on the LDP MD5 1667 authentication key option, as described in section 2.9 of [RFC5036], 1668 to provide integrity and authentication for the LDP messages and 1669 protect against source address spoofing. This mechanism relies on the 1670 configuration of pre-shared keys, which typically introduces some 1671 fragility. In the specific case of MS-PW, the number of links that 1672 leave an organization will be limited in practice, so the reliance on 1673 pre-shared keys should be manageable. 1675 When the Generalized ID FEC Element is used, it is possible that a 1676 particular peer may be one of the eligible peers, but may not be the 1677 right one to connect to the particular attachment circuit identified 1678 by the particular instance of the Generalized ID FEC element. 1679 However, given that the peer is known to be one of the eligible peers 1680 (as discussed above), this would be the result of a configuration 1681 error, rather than a security problem. Nevertheless, it may be 1682 advisable for a PE to associate each of its local attachment circuits 1683 with a set of eligible peers, rather than having just a single set of 1684 eligible peers associated with the PE as a whole. 1686 14. IANA Considerations 1688 14.1. L2TPv3 AVP 1690 This document uses a new L2TP parameter, IANA already maintains a 1691 registry of name "Control Message Attribute Value Pair" defined by 1692 [RFC3438]. The following new value is required: 1694 TBA-L2TP-AVP-1 - PW Switching Point AVP 1696 14.2. LDP TLV TYPE 1698 This document uses a new LDP TLV types, IANA already maintains a 1699 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 1700 following value is suggested for assignment: 1702 TLV type Description 1703 0x096D Pseudowire Switching Point PE TLV 1705 14.3. LDP Status Codes 1707 This document uses a new LDP status codes, IANA already maintains a 1708 registry of name "STATUS CODE NAME SPACE" defined by RFC5036. The 1709 following value is suggested for assignment: 1711 Assignment E Description 1712 0x0000003A 0 "PW Loop Detected" 1714 14.4. L2TPv3 Result Codes 1716 This document uses a new L2TPv3 Result Code for the CDN message, to 1717 be assigned IANA in the "Result Code AVP (Attribute Type 1) Values" 1718 registry as follows: 1720 Registry Name: Result Code AVP (Attribute Type 1) Values Defined 1721 Result Code values for the CDN message are: 1722 Assignment Description 1723 TBD Sequencing not supported 1725 14.5. New IANA Registries 1727 IANA needs to set up a registry of "Pseudowire Switching Point PE 1728 sub-TLV Type". These are 8-bit values. Type value 1 through 6 are 1729 defined in this document. Type values 7 through 64 are to be assigned 1730 by IANA using the "Expert Review" policy defined in RFC5226. Type 1731 values 65 through 127, 0 and 255 are to be allocated using the IETF 1732 consensus policy defined in [RFC5226]. Type values 128 through 254 1733 are reserved for vendor proprietary extensions and are to be assigned 1734 by IANA, using the "First Come First Served" policy defined in 1735 RFC5226. 1737 The Type Values are assigned as follows: 1738 Type Length Description 1740 0x01 4 PW ID of last PW segment traversed 1741 0x02 variable PW Switching Point description string 1742 0x03 4/16 Local IP address of PW Switching Point 1743 0x04 4/16 Remote IP address of last PW Switching Point traversed 1744 or of the T-PE 1745 0x05 variable FEC Element of last PW segment traversed 1746 0x06 12 L2 PW address of PW Switching Point 1748 15. Normative References 1750 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 1751 Control Word for Use over an MPLS PSN", S. Bryant, et al., 1752 RFC4385, February 2006. 1754 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge 1755 Emulation (PWE3)", L. Martini, RFC4446, April 2006. 1757 [RFC4447] "Pseudowire Setup and Maintenance Using the 1758 Label Distribution Protocol (LDP)", Martini, L., 1759 et al., rfc4447 April 2006. 1761 [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, E, 1762 Rekhter, Y., RFC4364, February 2006 1763 October 2004. 1765 [RFC3931] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1766 M. Townsley, I. Goyret, RFC3931 1768 [RFC5085] Nadeau, T., et al. "Pseudo Wire Virtual Circuit Connection 1769 Verification (VCCV), A Control Channel for Pseudowires", 1770 RFC5085 December 2007. 1772 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1773 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 1775 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1776 Requirement Levels", BCP 14, RFC 2119, March 1997. 1778 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 1779 Individual Identifier (AII) Types for Aggregation", RFC5003, 1780 September 2007. 1782 [RFC4379] K. Kompella, G. Swallow, "Detecting Multi-Protocol 1783 Label Switched (MPLS) Data Plane Failures", RFC4379, 1784 September 2007 1786 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1787 Specification", RFC 5036, October 2007. 1789 [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and 1790 Languages", RFC 2277, January 1998 1792 [RFC5641] N. McGill, C. Pignataro, "Layer 2 Tunneling Protocol 1793 Version 3 (L2TPv3) Extended Circuit Status Values", August 2009 1795 16. Informative References 1797 [RFC4023] "Encapsulating MPLS in IP or Generic 1798 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1799 RFC4023, March 2005. 1801 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture" 1802 Bryant, et al., RFC 3985, March 2005. 1804 [RFC4623] "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation 1805 and Reassembly", A. Malis, W. M. Townsley, RFC 4623, August 2006 1807 [RFC4667] "Layer 2 Virtual Private Network (L2VPN) 1808 Extensions for Layer 2 Tunneling Protocol (L2TP)", Luo, Wei, 1809 RFC4667, W. Luo, September 2006 1811 [RFC4454] "Asynchronous Transfer Mode (ATM) over Layer 2 1812 Tunneling Protocol Version 3 (L2TPv3)", Singh, Townsley, 1813 Pignataro, RFC4454, May 2006 1814 ( work in progress ), March 2004. 1816 [RFC4717] "Encapsulation Methods for Transport of (ATM) 1817 MPLS Networks", Martini et al., RFC4717, December 2006 1819 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1820 (L2TP) Internet Assigned Numbers Authority (IANA) 1821 Considerations Update", December 2002, RFC3438 1823 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1824 draft-ietf-pwe3-oam-msg-map-12.txt, (work in progress), 1825 March 2010 1827 [RFC3032] "MPLS Label Stack Encoding", RFC3032, January 2001 1829 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation 1830 Edge-to-Edge", Bocci et al, RFC5659, October 2009. 1832 [RFC5254] "Requirements for Multi-Segment Pseudowire Emulation 1833 Edge-to-Edge (PWE3)", N. Bitar, M. Bocci, L. Martini, RFC5254, 1834 October 2008 1836 [RFC5920] Luyuan Fang, Ed., "Security Framework for MPLS and GMPLS 1837 Networks", RFC5920, July 2010 1839 17. Author's Addresses 1841 Luca Martini 1842 Cisco Systems, Inc. 1843 9155 East Nichols Avenue, Suite 400 1844 Englewood, CO, 80112 1845 e-mail: lmartini@cisco.com 1847 Thomas D. Nadeau 1848 e-mail: tnadeau@lucidvision.com 1850 Chris Metz 1851 Cisco Systems, Inc. 1852 e-mail: chmetz@cisco.com 1854 Matthew Bocci 1855 Alcatel-Lucent 1856 Grove House, Waltham Road Rd 1857 White Waltham, Berks, UK. SL6 3TN 1858 e-mail: matthew.bocci@alcatel-lucent.co.uk 1859 Mustapha Aissaoui 1860 Alcatel-Lucent 1861 600, March Road, 1862 Kanata, ON, Canada 1863 e-mail: mustapha.aissaoui@alcatel-lucent.com 1865 18. Additional Authors 1867 The following people also contributed text to this document: 1869 Florin Balus 1870 Alcatel-Lucent 1871 701 East Middlefield Rd. 1872 Mountain View, CA 94043 1873 e-mail: florin.balus@alcatel-lucent.com 1875 Mike Duckett 1876 Bellsouth 1877 Lindbergh Center 1878 D481 1879 575 Morosgo Dr 1880 Atlanta, GA 30324 1881 e-mail: mduckett@bellsouth.net 1883 Copyright Notice 1885 Copyright (c) 2010 IETF Trust and the persons identified as the 1886 document authors. All rights reserved. 1888 This document is subject to BCP 78 and the IETF Trust's Legal 1889 Provisions Relating to IETF Documents 1890 (http://trustee.ietf.org/license-info) in effect on the date of 1891 publication of this document. Please review these documents 1892 carefully, as they describe your rights and restrictions with respect 1893 to this document. Code Components extracted from this document must 1894 include Simplified BSD License text as described in Section 4.e of 1895 the Trust Legal Provisions and are provided without warranty as 1896 described in the Simplified BSD License. 1898 This document may contain material from IETF Documents or IETF 1899 Contributions published or made publicly available before November 1900 10, 2008. The person(s) controlling the copyright in some of this 1901 material may not have granted the IETF Trust the right to allow 1902 modifications of such material outside the IETF Standards Process. 1903 Without obtaining an adequate license from the person(s) controlling 1904 the copyright in such materials, this document may not be modified 1905 outside the IETF Standards Process, and derivative works of it may 1906 not be created outside the IETF Standards Process, except to format 1907 it for publication as an RFC or to translate it into languages other 1908 than English. 1910 Acknowledgments 1912 The authors wish to acknowledge the contributions of Satoru 1913 Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, 1914 and Tiberiu Grigoriu. 1916 Expiration Date: March 2011