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