idnits 2.17.1 draft-ietf-pwe3-segmented-pw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1196. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6610 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) == Missing Reference: 'RFC3985' is mentioned on line 121, but not defined == Missing Reference: 'PWE3-ADDR' is mentioned on line 573, but not defined == Missing Reference: 'PWE3-IANA' is mentioned on line 769, but not defined == Missing Reference: 'PW-CW' is mentioned on line 1113, but not defined == Missing Reference: 'PWE3IANA' is mentioned on line 924, but not defined == Unused Reference: 'RFC2277' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'BCP78' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'PW-ADDR' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'PWE-IANA' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'BCP68' is defined on line 1294, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'VCCV' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 3978 (ref. 'BCP78') (Obsoleted by RFC 5378) -- Possible downref: Normative reference to a draft: ref. 'PW-ADDR' == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-05 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-04 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-00 -- Unexpected draft version: The latest known version of draft-mistretta-l2tp-infomsg is -01, but you're referring to -02. == Outdated reference: A later version (-04) exists of draft-ietf-l2tpext-pwe3-atm-00 -- Duplicate reference: RFC3438, mentioned in 'BCP68', was also mentioned in 'RFC3438'. == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 Summary: 7 errors (**), 0 flaws (~~), 21 warnings (==), 11 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: September 2006 Thomas D. Nadeau 5 Cisco Systems Inc. 7 Vasile Radoaca Mike Duckett 8 Consultant Bellsouth 10 Matthew Bocci Florin Balus 11 Alcatel Nortel Networks 13 March 2006 15 Segmented Pseudo Wire 17 draft-ietf-pwe3-segmented-pw-02.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document describes how to connect pseudo wires (PW) between two 44 distinct PW control planes or PSN domains. The PW control planes may 45 belong to independent autonomous systems, or the PSN technology is 46 heterogeneous, or a PW might need to be aggregated at a specific PSN 47 point. The PW packet data units are simply switched from one PW to 48 another without changing the PW payload. 50 Table of Contents 52 1 Specification of Requirements ........................ 4 53 2 Terminology .......................................... 4 54 3 Introduction ......................................... 5 55 4 General Description .................................. 6 56 5 PW Switching with Attachment Circuits ................ 9 57 5.1 Aplicability ......................................... 9 58 6 PW-MPLS to PW-MPLS Control Plane Switching ........... 10 59 6.1 MPLS PW Control Plane Switching ...................... 11 60 6.1.1 Static Control plane switching ....................... 11 61 6.1.2 Two LDP control planes using the same FEC type ....... 11 62 6.1.3 LDP using FEC 128 to LDP using the generalized FEC 129 ...12 63 6.1.4 LDP PW switching point TLV ........................... 12 64 6.1.5 PW Switching Point Sub-TLVs .......................... 13 65 6.1.6 Adaptation of Interface Parameters ................... 14 66 6.1.7 Group ID ............................................. 15 67 6.1.8 PW Loop Detection .................................... 15 68 7 PW-MPLS to PW-L2TPv3 Control Plane Switching ......... 15 69 7.1 Static MPLS and L2TPv3 PWs ........................... 16 70 7.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 16 71 7.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 16 72 7.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 16 73 7.4.1 Session Establishment ................................ 17 74 7.4.2 Adaptation of PW Status message ...................... 17 75 7.4.3 Session Teardown ..................................... 18 76 7.5 Adaptation of LDP/L2TPv3 AVPs and Interface Parameters ...18 77 7.6 Switching Point TLV in L2TPv3 ........................ 19 78 7.7 L2TPv3 and MPLS PW Data Plane ........................ 19 79 7.7.1 PWE3 Payload Convergence and Sequencing .............. 20 80 7.7.2 Mapping .............................................. 20 81 8 Operation And Management ............................. 21 82 8.1 Extensions to VCCV to Support Switched PWs ........... 21 83 8.2 PW-MPLS to PW-MPLS OAM Data Plane Indication ......... 21 84 8.3 Signal OAM Capabilities for Switched Pseudo Wires .... 22 85 8.3.1 OAM Capability for MH PWs Demultiplexed using MPLS ... 22 86 8.3.2 OAM Capability for MH PWs Demultiplexed using L2TPv3 . 23 87 8.4 Tracing Switched PW Switch Points Using MH-VCCV ...... 23 88 8.5 Mapping Switched Pseudo Wire Status .................. 23 89 8.6 Pseudowire Status Negotiation Procedures ............. 25 90 8.7 Status Dampening ..................................... 25 91 9 Peering Between Autonomous Systems ................... 25 92 10 Security Considerations .............................. 25 93 10.1 Data Plane Security .................................. 25 94 10.2 Control Protocol Security ............................ 26 95 11 IANA Considerations .................................. 27 96 11.1 Channel .............................................. 27 97 11.2 L2TPv3 AVP ........................................... 27 98 11.3 LDP TLV TYPE ......................................... 27 99 11.4 LDP Status Codes ..................................... 27 100 11.5 L2TPv3 Result Codes .................................. 28 101 11.6 New IANA Registries .................................. 28 102 12 Intellectual Property Statement ...................... 28 103 13 Full Copyright Statement ............................. 29 104 14 Acknowledgments ...................................... 29 105 15 Normative References ................................. 29 106 16 Informative References ............................... 30 107 17 Author Information ................................... 31 109 1. Specification of Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 115 2. Terminology 117 - PW Terminating Provider Edge (T-PE). A PE where the customer- 118 facing attachment circuits (ACs) are bound to a PW forwarder. A 119 Terminating PE is present in the first and last segments of a 120 MS-PW. This incorporates the functionality of a PE as defined in 121 [RFC3985]. 123 - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 124 two T-PE devices. Each PW in one direction of a SS-PW traverses 125 one PSN tunnel that connects the two T-PEs. 127 - Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 128 configured set of two or more contiguous PW segments that behave 129 and function as a single point-to-point PW. Each end of a MS-PW 130 by definition MUST terminate on a T-PE. 132 - PW Segment. A part of a single-segment or multi-segment PW, which 133 is set up between two PE devices, T-PEs and/or S-PEs. 135 - PW Switching Provider Edge (S-PE). A PE capable of switching the 136 control and data planes of the preceding and succeeding PW 137 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 138 preceding and succeeding segments of the MS-PW.It is therefore a 140 - PW switching point for a MS-PW. A PW Switching Point is never the 141 S-PE and the T-PE for the same MS-PW. A PW switching point runs 142 necessary protocols to setup and manage PW segments with other PW 143 switching points and terminating PEs. 145 3. Introduction 147 PWE3 defines the signaling and encapsulation techniques for 148 establishing SS-PWs between a pair of ultimate PEs and in the vast 149 majority of cases this will be sufficient. MS-PWs come into play in 150 two general cases: 152 -i. When it is not possible, desirable or feasible to establish 153 a PW control channel between the ultimate source and 154 destination PEs. At a minimum PW control channel 155 establishment requires knowledge of and reachability to the 156 remote (ultimate) PE IP address. The local (ultimate) PE may 157 not have access to this information related to topology, 158 operational or security constraints. 160 An example is the inter-AS L2VPN scenario where the ultimate 161 PEs reside in different provider networks (ASes) and it is 162 the practice to MD5-key all control traffic exchanged 163 between two networks. Technically a SS-PW could be used but 164 this would require MD5-keying on ALL ultimate source and 165 destination PE nodes. An MS-PW allows the providers to 166 confine MD5 key administration to just the PW switching 167 points connecting the two domains. 169 A second example might involve a single AS where the PW 170 setup path between the ultimate PEs is computed by an 171 external entity (i.e. client-layer routing protocol). Assume 172 a full mesh of PWE3 control channels established between 173 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 174 through a PW is required between ultimate PE-A and PE-C. The 175 external entity computes a PW setup path that passes through 176 PE-B. This results in two discrete PW segments being built: 177 one between PE-A and PE-B and one between PE-B and PE-C. The 178 successful client-layer L2 connection between ultimate PE-A 179 and ultimate PE-C requires that PE-B performs the PWE3 180 switching process. 182 A third example involves the use of PWs in hierarchical 183 IP/MPLS networks. Access networks connected to a backbone 184 use PWs to transport customer payloads between customer 185 sites serviced by the same access network and up to the edge 186 of the backbone where they can be terminated or switched 187 onto a succeeding PW segment crossing the backbone. The use 188 of PWE3 switching between the access and backbone networks 189 can potentially reduce the PWE3 control channels and routing 190 information processed by the access network T-PEs. 192 It should be noted that PWE3 switching does not help in any 193 way to reduce the amount of PW state supported by each 194 access network T-PE. 196 -ii. PWE3 signaling and encapsulation protocols are different. 197 The ultimate PEs are connected to networks employing 198 different PW signaling and encapsulation protocols. In this 199 case it is not possible to use a SS-PW. A MS-PW with the 200 appropriate interworking performed at the PW switching 201 points can enable PW connectivity between the ultimate PEs 202 in this scenario. 204 There are four different signaling protocols that are defined to 205 signal PWs: 206 -i. Static configuration of the PW (MPLS or L2TPv3). 207 -ii. LDP using FEC 128 208 -iii. LDP using the generalized FEC 129 209 -iv. L2TPv3 211 4. General Description 213 A pseudo-wire (PW) is a tunnel established between two provider edge 214 (PE) nodes to transport L2 PDUs across a packet switched network 215 (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are 216 looking at PWs as a means of migrating existing (or building new) 217 L2VPN services (i.e. Frame-Relay, ATM, Ethernet) on top of a PSN by 218 using PWs. PWs may span multiple autonomous systems of the same or 219 different provider networks. In these scenarios PW control channels 220 (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries. 222 Inter-AS L2VPN functionality is currently supported and several 223 techniques employing MPLS encapsulation and LDP signaling have been 224 documented [2547BIS]. It is also straightforward to support the same 225 inter-AS L2VPN functionality employing L2TPv3. In this document we 226 define methodology to switch a PW between two PW control planes. 228 |<-------------- Emulated Service ---------------->| 229 | | 230 | |<------- Pseudo Wire ------>| | 231 | | | | 232 | | |<-- PSN Tunnel -->| | | 233 | V V V V | 234 V AC +----+ +----+ AC V 235 +-----+ | | PE1|==================| PE2| | +-----+ 236 | |----------|............PW1.............|----------| | 237 | CE1 | | | | | | | | CE2 | 238 | |----------|............PW2.............|----------| | 239 +-----+ ^ | | |==================| | | ^ +-----+ 240 ^ | +----+ +----+ | | ^ 241 | | Provider Edge 1 Provider Edge 2 | | 242 | | | | 243 Customer | | Customer 244 Edge 1 | | Edge 2 245 | | 246 native service native service 248 Figure 1: PWE3 Reference Model 250 There are two methods for switching a PW between two PW control 251 planes. In the first method (Figure 2), the two control planes 252 terminate on different PEs. 254 |<------------Emulated Service---------->| 255 | PSN PSN | 256 AC | |<-1->| |<-2->| | AC 257 | V V V V V V | 258 | +----+ +-----+ +----+ +----+ | 259 +----+ | | |=====| | | |=====| | | +----+ 260 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 261 | CE1| | | | | | | | | | | |CE2 | 262 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 263 +----+ | | |=====| | | |=====| | | +----+ 264 ^ +----+ +-----+ +----+ +----+ ^ 265 | PE1 PE2 PE3 PE4 | 266 | ^ ^ | 267 | | | | 268 | PW stitching points | 269 | | 270 | | 271 |<-------------------- Emulated Service ---------------->| 273 Figure 2: PW Switching using ACs Reference Model 275 In Figure 2, pseudo wires in two separate PSNs are stitched together 276 using native service attachment circuits. PE2 and PE3 only run the 277 control plane for the PSN to which they are directly attached. At PE2 278 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 279 while PW3 and PW4 are connected using attachment circuit AC2. 281 Native |<-----------Pseudo Wire----------->| Native 282 Layer2 | | Layer2 283 Service | |<-PSN1-->| |<--PSN2->| | Service 284 (AC) V V V V V V (AC) 285 | +----+ +-----+ +----+ | 286 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 287 | |----------|........PW1.........|...PW3........|----------| | 288 | CE1| | | | | | | | | |CE2 | 289 | |----------|........PW2.........|...PW4........|----------| | 290 +----+ | | |=========| |=========| | | +----+ 291 ^ +----+ +-----+ +----+ | ^ 292 | Provider Edge 1 ^ Provider Edge 3 | 293 | (Ultimate PE) | (Ultimate PE) | 294 | | | 295 | PW switching point | 296 | (Optional PW adaptation function) | 297 | | 298 |<------------------- Emulated Service ------------------>| 300 Figure 3: PW Control Plane Switching Reference Model 302 In Figure 3 PE2 runs two separate control planes: one toward PE1, and 303 one Toward PE3. The PW switching point is at PE2 which is configured 304 to connect PW1 and PW3 together to complete the multi-hop PW between 305 PE1 and PE3. PW1 and PW3 MUST be of the same PW type, but PSN1 and 306 PSN2 need not be the same technology. In the latter case, if the PW 307 is switched to a different technology, the PEs must adapt the PDU 308 encapsulation between the different PSN technologies. In the case 309 where PSN1 and PSN2 are the same technology the PW PDU does not need 310 to be modified, and PDUs are then switched between the pseudo-wires 311 at the PW label level. 313 It should be noted that it is possible to adapt one PSN technology to 314 a different one, for example MPLS over an IP or GRE [MPLS-IP-GRE] 315 encapsulation, but this is outside the scope of this document. 316 Further, one could perform an interworking function on the PWs 317 themselves at the PW switching point, allowing conversion from one PW 318 type to another, but this is also outside the scope of this document. 320 The pseudowire switching methodology described in this document 321 assumes manual configuration of the switching point at PE2. It should 322 also be noted that a PW can traverse multiple PW switching points 323 along it's path, and the edge PEs will not require any specific 324 knowledge of how many PW switching points the PW has traversed 325 (though this may be reported for troubleshooting purposes). 327 In general the approach taken is to connect the individual control 328 planes by passing along any signaling information immediately upon 329 reception. First the PW switching point is configured to switch a 330 SS-PW from a specific peer to another SS-PW destined for a different 331 peer. No control messages are exchanged yet as the PW switching point 332 PE does not have enough information to actually initiate the PW setup 333 messages. However, if a session does not already exist, a control 334 protocol (LDP/L2TP) session is setup. In this model the MS-PW setup 335 is starting from the T-PE devices. Next once the T-PE is configured 336 it sends the PW control setup messages. These messages are received, 337 and immediately used to form the PW setup messages for the next SS-PW 338 of the MS-PW. If one of the Switching PEs doesn't accept an LDP Label 339 Mapping message then a Label Release message is sent back to the 340 originator T-PE. A MS-PW is declared UP when all the constituent SS- 341 PWs are UP. 343 5. PW Switching with Attachment Circuits 345 In PW switching with attachment circuits, each PSN may be of a 346 different type e.g. MPLS, L2TPv3. However the details of this are 347 outside the scope of this document. The PWs and the attachment 348 circuits MUST be of the same type e.g. ATM, Ethernet, etc. 350 The PWs in each PSN are established independently, with each PSN 351 being treated as a separate PWE3 domain. For example, in Figure 2 for 352 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 353 targeted session as described in [PWE3-MPLS], and at the same time a 354 separate pseudo wire, PW2, is setup between PE3 and PE4. The ACs for 355 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 356 same native circuit e.g. ATM VCC, Ethernet VLAN, etc. These ACs thus 357 connect the PWs in PSN1 and PSN2 together. 359 5.1. Aplicability 361 In a client/server (PW/MPLS)relationship the performance of the 362 client layer is equal to the performance of the server layer plus any 363 impairments introduced by the client layer itself. Therefore it is 364 not possible for the client layer to provide better performance than 365 the server layer over which it is transported. 367 Therefore, it is necessary to carefully consider the order in which 368 different layer networks are stacked upon each other within a 369 'network stack' in order to provide the topmost client layer (the 370 'service') with the performance that it requires. This performance 371 inheritance within a client/server relationship is vertical because 372 the client layer is vertically stacked upon its server layer. 374 Note: Due to this vertical performance inheritance and the different 375 performance provided by, and the characteristics of, each networking 376 mode it is generally advisable to stack modes that less efficiently 377 provide dedicated bandwidth/performance on top of modes that more 378 efficiently provide dedicated bandwidth/performance. 380 When performing peer partition interworking the client layer inherits 381 the performance of the server layer partition that provides the worst 382 performance of all the peered server layer partitions over which the 383 client layer is transported. Therefore it is not possible for the 384 client layer to receive (or provide) better performance than the 385 worst performing of the peered server layer partitions over which it 386 is transported. 388 Therefore, it is necessary to carefully consider which server layer 389 modes (and/or technologies) it is appropriate to peer with one 390 another in order to provide the topmost client layer (the 'service') 391 with the performance that it requires. This is a horizontal 392 performance relationship because the server layer partitions are 393 peered with each other horizontally." 395 6. PW-MPLS to PW-MPLS Control Plane Switching 397 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 398 session as described in [PWE3-MPLS], at the same time a separate 399 pseudo wire PW3 is setup to PE3. Each PW is configured independently 400 on the PEs, but on PE2 pseudo wire PW1 is connected to pseudo wire 401 PW3. PDUs are then switched between the pseudo-wires at the PW label 402 level. Hence the data plane does not need any special knowledge of 403 the specific pseudo wire type. A simple standard MPLS label swap 404 operation is sufficient to connect the two PWs, and in this case the 405 PW adaptation function is not used. 407 This process can be repeated as many times as necessary, the only 408 limitation to the number of PW switching points traversed is imposed 409 by the TTL field of the PW MPLS Label. The setting of the TTL is a 410 matter of local policy on the originating PE, but SHOULD be set to 411 255. 413 6.1. MPLS PW Control Plane Switching 415 There are three MPLS to MPLS PW control planes: 416 -i. Static configuration of the PW. 417 -ii. LDP using FEC 128 418 -iii. LDP using the generalized FEC 129 419 This results in four distinct PW switching situations that are 420 significantly different, and must be considered in detail: 421 -i. PW Switching between two static control planes. 422 -ii. Static Control plane switching to LDP dynamic control plane. 423 -iii. Two LDP control planes using the same FEC type 424 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 426 6.1.1. Static Control plane switching 428 In the case of two static control planes the PW switching point MUST 429 be configured to direct the MPLS packets from one PW into the other. 430 There is no control protocol involved in this case. When one of the 431 control planes is a simple static PW configuration and the other 432 control plane is a dynamic LDP FEC 128 or generalized PW FEC, then 433 the static control plane should be considered identical to an 434 attachment circuit (AC) in the reference model of Figure 1. The 435 switching point PE SHOULD signal the proper PW status if it detects a 436 failure in sending or receiving packets over the static PW. Because 437 the PW is statically configured, the status communicated to the 438 dynamic LDP PW will be limited to local interface failures. In this 439 case, the PW switching point PE behaves in a very similar manner to a 440 T-PE, assuming an active role. This means that the S-PE will 441 immediately send the LDP Label Mapping message if the static PW is 442 deemed to be UP. 444 6.1.2. Two LDP control planes using the same FEC type 446 As stated in a section above, the PW switching point PE should assume 447 an initial passive role. This means that once independent PWs are 448 configured on the switching point, the LSR does not advertise the LDP 449 PW FEC mapping until 451 it has received at least one of the two PW LDP FECs from a remote PE. 452 This is necessary because the switching point LSR does not know a 453 priory what the interface parameter field in the initial FEC 454 advertisement will contain. 456 The PWID is a unique number between each pair of PEs. Hence Each SS- 457 PW that forms an MS-PW may have a different PWID. In the case of The 458 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 459 some, or sometimes all, SS-PWs. 461 6.1.3. LDP using FEC 128 to LDP using the generalized FEC 129 463 When a PE is using the generalized FEC 129, there are two distinct 464 roles that a PE can assume: active and passive. A PE that assumes the 465 active role will send the LDP PW setup message, while a passive role 466 PE will simply reply to an incoming LDP PW setup message. The PW 467 switching point PE, will always remain passive until a PWID FEC 128 468 LDP message is received, which will cause the corresponding 469 generalized PW FEC LDP message to be formed and sent. If a 470 generalized FEC PW LDP message is received while the switching point 471 PE is in a passive role, the corresponding PW FEC 128 LDP message 472 will be formed and sent. 474 PWIDs need to be mapped to the corresponding AGI/TAI/SAI and vice 475 versa. This can be accomplished by local PW switching point 476 configuration, or by some other means, such as some form of auto 477 discovery. Such other means are outside the scope of this document. 479 6.1.4. LDP PW switching point TLV 481 The edge to edge PW might traverse several switching points, in 482 separate administrative domains. For management and troubleshooting 483 reasons it is useful to record all the switching points that the PW 484 traverses. This is accomplished by using a PW switching point TLV. 486 The OPTIONAL PW switching point TLV is appended to the PW FEC at each 487 switching point and is encoded as follows: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | Variable Length Value | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Variable Length Value | 497 | " | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 [note] LDP TLV type is pending IANA approval. 502 - PW sw TLV Length 504 Specifies the total length of all the following PW switching 505 point TLV fields in octets 507 - Type 509 Encodes how the Value field is to be interpreted. 511 - Length 513 Specifies the length of the Value field in octets. 515 - Value 517 Octet string of Length octets that encodes information to be 518 interpreted as specified by the Type field. 520 PW Switching point TLV Types are assigned by IANA according the the 521 process defined in the "IANA Allocations" section below. 523 The PW switching Point TLV is an OPTIONAL TLV that can appear once 524 for each switching point traversed. 526 6.1.5. PW Switching Point Sub-TLVs 528 Below are details specific to PW Switching Point Sub-TLVs described 529 in this document: 531 - PW ID of last PW segment traversed. 533 This sub-TLV type conains a PW ID in the format of the PWID 534 described in [PWE3-MPLS] 536 - PW Switching Point description string. 538 An optional description string of text up to 80 characters long. 540 - IP address of PW Switching Point. 542 The IP V4 or V6 address of the PW Switching Point. This is an 543 OPTIONAL Sub-TLV. 544 - MH VCCV Capability Indication. 546 - AI of last PW segment traversed. 548 The Attachment Identifier of the last PW segment traversed. This 549 is coded in the following format: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | AGI Type | Length | Value | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 ~ AGI Value (contd.) ~ 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | AII Type | Length | Value | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 ~ SAII Value (contd.) ~ 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | AII Type | Length | Value | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 ~ TAII Value (contd.) ~ 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 - L2 PW address of PW Switching Point (recomended format) 572 This sub-TLV type conains a L2 PW address of PW Switching Point 573 in the format described in [PWE3-ADDR]. This includes the AII 574 type field , and length, as well as the L2 PW address without the 575 AC ID portion (if aplicable). 577 6.1.6. Adaptation of Interface Parameters 579 [PWE3-MPLS] defines several interface parameters, which are used by 580 the Network Service Processing (NSP) to adapt the PW to the 581 Attachment Circuit (AC). The interface parameters are only used at 582 the end points, and MUST be passed unchanged across the PW switching 583 point. However the following interface parameters MAY be modified as 584 follows: 586 - 0x03 Optional Interface Description string This Interface 587 parameter MAY be modified, or altogether removed from the FEC 588 element depending on local configuration policies. 590 - 0x09 Fragmentation indicator This parameter MAY be inserted in 591 the FEC by the switching point if it is capable of re-assembly of 592 fragmented PW frames according to [PWE3-FRAG]. 594 - 0x0C VCCV parameter The switching point MAY not be able to 595 inspect the VCCV control channel. If the new MH-VCCV sub-TLV is 596 present, the VCCV parameter MUST be ignored in order to avoid 597 conflicts with the new TLV. 599 6.1.7. Group ID 601 The Group ID ( GR ID ) is used to reduce the number of status 602 messages that need to be sent by the PE advertising the PW FEC. The 603 GR ID has local significance only, and therefore MUST be mapped to a 604 unique GR ID allocated by the PW switching point PE. 606 6.1.8. PW Loop Detection 608 A switching point PE SHOULD check the OPTIONAL PW switching Point 609 TLV, to verify if it's own IP address appears in it. If it's IP 610 address appears in a received PW switching Point TLV, the PE SHOULD 611 break the loop, and send a label release message with the following 612 error code: 613 Assignment E Description 614 0x0000003A 0 "PW Loop Detected" 616 [ note: error code pending IANA allocation ] 618 7. PW-MPLS to PW-L2TPv3 Control Plane Switching 620 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 621 four possibilities when switching between L2TPv3 and MPLS. 623 -i. Switching between MPLS and L2TPv3 static control planes. 624 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 625 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 626 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 628 7.1. Static MPLS and L2TPv3 PWs 630 In the case of two static control planes, the PW switching point MUST 631 be configured to direct packets from one PW into the other. There is 632 no control protocol involved in this case. The configuration MUST 633 include which MPLS VC Label maps to which L2TPv3 Session ID (and 634 associated Cookie, if present) as well as which MPLS Tunnel Label 635 maps to which PE destination IP address. 637 7.2. Static MPLS PW and Dynamic L2TPv3 PW 639 When a statically configured MPLS PW is switched to a dynamic L2TPv3 640 PW, the static control plane should be considered identical to an 641 attachment circuit (AC) in the reference model of Figure 1. The 642 switching point PE SHOULD signal the proper PW status if it detects a 643 failure in 645 sending or receiving packets over the static PW. Because the PW is 646 statically configured, the status communicated to the dynamic L2TPv3 647 PW will be limited to local interface failures. In this case, the PW 648 switching point PE behaves in a very similar manner to a T-PE, 649 assuming an active role. 651 7.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 653 When a statically configured L2TPv3 PW is switched to a dynamic 654 LDP/MPLS PW, then the static control plane should be considered 655 identical to an attachment circuit (AC) in the reference model of 656 Figure 1. The switching point PE SHOULD signal the proper PW status 657 (via an L2TPv3 SLI message) if it detects a failure in sending or 658 receiving packets over the static PW. Because the PW is statically 659 configured, the status communicated to the dynamic LDP/MPLS PW will 660 be limited to local interface failures. In this case, the PW 661 switching point PE behaves in a very similar manner to a T-PE, 662 assuming an active role. 664 7.4. Dynamic LDP/MPLS and L2TPv3 PWs 666 When switching between dynamic PWs, the switching point always 667 assumes an initial passive role. Thus, it does not initiate an 668 LDP/MPLS or L2TPv3 PW until it has received a connection request 669 (Label Mapping or ICRQ) from one side of the node. Note that while 670 MPLS PWs are made up of two unidirectional LSPs bonded together by 671 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 672 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 673 Establishment, Teardown, and PW Status signaling are detailed below. 675 7.4.1. Session Establishment 677 When the PW switching point receives an L2TPv3 ICRQ message, the 678 identifying AVPs included in the message are mapped to FEC 679 identifiers and sent in an LDP label mapping message. Conversely, if 680 an LDP Label Mapping message is received, it is either mapped to an 681 ICRP message or causes an L2TPv3 session to be initiated by sending 682 an ICRQ. 684 Following are two example exchanges of messages between LDP and 685 L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW, 686 the second is a case where an MPLS T-PE initiates an MS-PW. 688 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 690 AC "Up" 691 L2TPv3 ICRQ ---> 692 LDP Label Mapping ---> 693 AC "UP" 694 <--- LDP Label Mapping 695 <--- L2TPv3 ICRP 696 L2TPv3 ICCN ---> 697 <-------------------- MH PW Established ------------------> 699 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 701 AC "Up" 702 LDP Label Mapping ---> 703 L2TPv3 ICRQ ---> 704 <--- L2TPv3 ICRP 705 <--- LDP Label Mapping 706 L2TPv3 ICCN ---> 707 AC "Up" 708 <-------------------- MH PW Established ------------------> 710 7.4.2. Adaptation of PW Status message 712 L2TPv3 uses the SLI message to indicate a interface status change 713 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 714 PWs either signal this via an LDP Label Withdraw or the PW Status 715 Notification message defined in section 4.4 of [PWE3-MPLS]. 717 7.4.3. Session Teardown 719 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 720 message translates to a Label Withdraw message in LDP. Following are 721 two example exchanges of messages between LDP and L2TPv3. The first 722 is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, 723 the second is a case where an MPLS T-PE initiates the termination of 724 an MS-PW. 726 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 728 AC "Down" 729 L2TPv3 CDN ---> 730 LDP Label Withdraw ---> 731 AC "Down" 732 <-- LDP Label Release 734 <--------------- MH PW Data Path Down ------------------> 736 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 738 AC "Down" 739 LDP Label Withdraw ---> 740 L2TPv3 CDN --> 741 <-- LDP Label Release 742 AC "Down" 744 <---------------- MH PW Data Path Down ------------------> 746 7.5. Adaptation of LDP/L2TPv3 AVPs and Interface Parameters 748 [PWE3-MPLS] defines several interface parameters which must be mapped 749 to similar AVPs in L2TPv3 setup messages. 751 * Interface MTU 753 The Interface MTU parameter is mapped directly to the L2TP 754 Interface MTU AVP defined in [L2TP-L2VPN] 756 * Max Number of Concatenated ATM cells 758 This interface parameter is mapped directly to the L2TP "ATM 759 Maximum Concatenated Cells AVP" described in section 6 of [L2TP- 760 ATM]. 762 * Optional Interface Description String 764 This string may be carried as the "Call-Information AVP" 765 described in section 2.2 of [L2TP-INFOMSG] 767 * PW Type 769 The PW Type defined in [PWE3-IANA] is mapped to the L2TPv3 "PW 770 Type" AVP defined in [L2TPv3]. 772 * PW ID (FEC 128) 774 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 775 End ID" AVP defined in [L2TPv3]. 777 * Generalized FEC 129 SAI/TAI 779 Section 4.3 of [L2TP-L2VPN] defines how to encode the SAI and TAI 780 parameters. These can be mapped directly. 782 Other interface parameter mappings will either be defined in a future 783 version of this document, or are unsupported when switching between 784 LDP/MPLS and L2TPv3 PWs. 786 7.6. Switching Point TLV in L2TPv3 788 When translating between LDP and L2TPv3 control messages, the PW 789 Switching Point TLV described earlier in this document is carried in 790 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 791 and optionally in the ICCN message. 793 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 794 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 795 the AVP is 6 plus the length of the series of Switching Point sub- 796 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 797 (the L2TP AVP M-bit MUST be 0). 799 7.7. L2TPv3 and MPLS PW Data Plane 801 When switching between an MPLS and L2TP PW, packets are sent in their 802 entirety from one PW to the other, replacing the MPLS label stack 803 with the L2TPv3 and IP header or vice versa. There are some 804 situations where an additional amount of interworking must be 805 provided between the two data planes at the PW switching node. 807 7.7.1. PWE3 Payload Convergence and Sequencing 809 Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim 810 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 811 For L2TPv3, the Payload Convergence and Sequencing function is 812 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 813 For MPLS, these two functions (together with PSN Convergence) are 814 carried out via the MPLS Control Word. Since these functions are 815 different between MPLS and L2TPv3, interworking between the two may 816 be necessary. 818 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 819 which in some cases are not necessary to be present at all. For 820 example, an Ethernet PW with sequencing disabled will generally not 821 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 822 be present at all. In this case, Ethernet frames are simply sent from 823 one PW to the other without any modification beyond the MPLS and 824 L2TP/IP encapsulation and decapsulation. 826 The following section offers guidelines for how to interwork between 827 L2TP and MPLS for those cases where the Payload Convergence, 828 Sequencing, or PSN Convergence functions are necessary on one or both 829 sides of the switching node. 831 7.7.2. Mapping 833 The MPLS Control Word consists of (from left to right): 835 -i. These bits are always zero in MPLS are not necessary to be 836 mapped to L2TP. 838 -ii. These six bits may be used for Payload Convergence depending 839 on the PW type. For ATM, the first four of these bits are 840 defined in [PWE3-ATM]. These map directly to the bits 841 defined in [L2TP-ATM]. For Frame Relay, these bits indicate 842 how to set the bits in the Frame Relay header which must be 843 regenerated for L2TP as it carries the Frame Relay header 844 intact. 846 -iii. L2TP determines its payload length from IP. Thus, this 847 Length field need not be carried directly to L2TP. This 848 Length field will have to be calculated and inserted for 849 MPLS when necessary. 851 -iv. The Default L2-Specific Sublayer has a sequence number with 852 different semantics than that of the MPLS Control Word. This 853 difference eliminates the possibility of supporting 854 sequencing across the MS-PW by simply carrying the sequence 855 number through the switching point transparently. As such, 856 sequence numbers MAY be supported by checking the sequence 857 numbers of packets arriving at the switching point and 858 regenerating a new sequence number in the proper format for 859 the PW on egress. If this type of sequence interworking at 860 the switching node is not supported, and a T-PE requests 861 sequencing of all packets via the L2TP control channel 862 during session setup, the switching node SHOULD NOT allow 863 the session to be established by sending a CDN message with 864 Result Code set to 17 "sequencing not supported" (subject to 865 IANA Assignment). 867 8. Operation And Management 869 8.1. Extensions to VCCV to Support Switched PWs 871 Single-hop pseudowires are signaled using the FEC 128 or FEC 129 872 interface as described in [VCCV]. Although VCCV can be run between 873 each PE device supporting a particular segment, no support is 874 available for VCCV across switching points, nor is there support for 875 signaling this capability in the existing protocol. Further 876 extentions are also possible for switch pseudowire VCCV such as VCCV 877 providing a switch point tracing function. Extensions to the existing 878 protocol are required in order to support switched pseudowires with 879 these capabilities. These extensions are explained below. 881 8.2. PW-MPLS to PW-MPLS OAM Data Plane Indication 883 The [PW-CW] defines an PW Associated Channel, which is specified in 884 [VCCV] as follows for single-hop pseudowires: 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |0 0 0 1|Version| Reserved = 0 | Channel Type = 0 | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Multi-hop pseudowire OAM is indicated using the following PW header: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |0 0 0 1| 0x00 | Reserved = 0 | Channel Type = 0x01 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | MH-TTL | MH-VCCV sub-TLV | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 This header MUST be used for end-to-end VCCV traffic. An operator can 903 then use this header to stimulate multihop VCCV operations as 904 described below. 906 Field Length Description MH-TTL 8 bits Describes the 907 number of switch points. 908 When the field is set to 0, the packet 909 should not be forwarded. 911 ----- note TTL processing needs to be clearly stated. MH-VCCV sub- 912 TLV ------ note what is the above ? 914 8.3. Signal OAM Capabilities for Switched Pseudo Wires 916 A PW Switching Point TLV includes a sub-TLV with type 0x04 in order 917 to indicate multihop OAM capabilities to each switching point. This 918 new sub-TLV MUST be appended to the PW Switching Point TLV to include 919 MH-VCCV capability indication. This sub-TLV MUST be examined by each 920 switching point and modified according to the rules outlined below. 922 8.3.1. OAM Capability for MH PWs Demultiplexed using MPLS 924 The MH-VCCV parameter ID is defined as follows in [PWE3IANA]: 926 Parameter ID Length Description 927 0x0c 4 VCCV 929 The format of the VCCV parameter field is as follows: 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | 0x0c | 0x04 | CC Types | CV Types | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 8.3.2. OAM Capability for MH PWs Demultiplexed using L2TPv3 939 TBD 941 8.4. Tracing Switched PW Switch Points Using MH-VCCV 943 Although the signaling of switched PWs includes functionality to 944 record all switch points traversed by a particular switched 945 pseudowire, this information is limited to the control plane. 946 Specifically, this is the information which is then used to program 947 the actual switching hardware. In an effort to provide explicit 948 diagnostic capability of the data plane used by the switched 949 pseudowire, it is necessary in some cases to compare the control and 950 data planes used by a particular switched pseudowire. In these cases, 951 it is possible to trace the pseudowire switch points by sending 952 single-hop VCCV messages with TTL described above in the MH VCCV 953 header, and increasing TTL values. This algorithm can be used to 954 "walk" across the network of switchpoints until the ultimate PE is 955 reached. 957 8.5. Mapping Switched Pseudo Wire Status 959 In the PW switching with attachment circuits case (Figure 2), PW 960 status messages indicating PW or attachment circuit faults SHOULD be 961 mapped to fault indications or OAM messages on the connecting AC as 962 defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an 963 administrative boundary, then the manner in which those OAM messages 964 are treated at the boundary is out of scope of this draft. 966 In the PW control plane switching case (Figure 3), there is no 967 attachment circuit at the PW switching point, but the two PWs are 968 connected together. Similarly, the status of the PWs are forwarded 969 unchanged from one PW to the other by the control plane switching 970 function. However, it may sometimes be necessary to communicate 971 status of one of the locally attached SS-PW at a PW switching point. 972 For LDP this can be accomplished by sending an LDP notification 973 message containing the PW status TLV, as well as an OPTIONAL PW 974 switching point TLV. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |0| Notification (0x0001) | Message Length | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Message ID | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |0|1| Status (0x0300) | Length | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 |0|1| Status Code=0x00000028 | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Message ID=0 | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Message Type=0 | PW Status TLV | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | PW Status TLV | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | PW Status TLV | PWId FEC | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | | 996 | | 997 | PWId FEC or Generalized ID FEC | 998 | | 999 | | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 |1|0| PW sw TLV (0x096D) | PW sw TLV Length | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Type | Length | Variable Length Value | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Only one PW switching point TLV can be present in this message. This 1007 message is then relayed by each PW switching point unchanged. The T- 1008 PE decodes the status message and the included PW switching point TLV 1009 to detect where exactly the fault occurred. At the T-PE if there is 1010 no PW switching point TLV included in the LDP status notification 1011 then the status message can be assumed to have originated at the 1012 remote T-PE. It should also be noted that once a PW status 1013 notification message is initiated at a PW switching point, any 1014 further status message received from an upstream neighbor is 1015 processed locally and not forwarded until the PW switching point 1016 original status error state is cleared. When a PW status notification 1017 message, for a particular PW, is received at the S-PE, the 1018 appropriate PW status notification MUST be send toward both remote 1019 S-PEs or T-PEs attached to the PW. 1021 8.6. Pseudowire Status Negotiation Procedures 1023 Pseudowire Status signaling methodology, defined in [PWE3-MPLS], 1024 SHOULD be transparent to the switching point. 1026 8.7. Status Dampening 1028 When the PW control plane switching methodology is used to cross an 1029 administrative boundary it might be necessary to prevent excessive 1030 status signaling changes from being propagated across the 1031 administrative boundary. This can be achieved by using a similar 1032 method as commonly employed for the BGP protocol route advertisement 1033 dampening. The details of this OPTIONAL algorithm are a matter of 1034 implementation, and are outside the scope of this document. 1036 9. Peering Between Autonomous Systems 1038 The procedures outlined in this document can be employed to provision 1039 and manage MS-PWs crossing AS boundaries. 1041 The use of more advanced mechanisms involving auto-discovery and 1042 ordered PWE3 MS-PW signaling will be covered in a separate document. 1044 10. Security Considerations 1046 This document specifies the LDP and L2TPv3 extensions that are needed 1047 for setting up and maintaining Pseudowires. The purpose of setting up 1048 Pseudowires is to enable layer 2 frames to be encapsulated and 1049 transmitted from one end of a Pseudowire to the other. Therefore we 1050 treat the security considerations for both the data plane and the 1051 control plane. 1053 10.1. Data Plane Security 1055 Data plane security consideration as discussed in [PWE3-MPLS], 1056 [L2TPv3], and [PWE3-ARCH] apply to this extension without any 1057 changes. 1059 10.2. Control Protocol Security 1061 General security considerations with regard to the use of LDP are 1062 specified in section 5 of RFC 3036. Security considerations with 1063 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 1064 considerations apply as well to the case where LDP or L2TPv3 is used 1065 to set up PWs. 1067 A Pseudowire connects two attachment circuits. It is important to 1068 make sure that LDP connections are not arbitrarily accepted from 1069 anywhere, or else a local attachment circuit might get connected to 1070 an arbitrary remote attachment circuit. Therefore an incoming session 1071 request MUST NOT be accepted unless its IP source address is known to 1072 be the source of an "eligible" peer. The set of eligible peers could 1073 be pre-configured (either as a list of IP addresses, or as a list of 1074 address/mask combinations), or it could be discovered dynamically via 1075 an auto-discovery protocol which is itself trusted. (Obviously if the 1076 auto-discovery protocol were not trusted, the set of "eligible peers" 1077 it produces could not be trusted.) 1079 Even if a connection request appears to come from an eligible peer, 1080 its source address may have been spoofed. So some means of 1081 preventing source address spoofing must be in place. For example, if 1082 all the eligible peers are in the same network, source address 1083 filtering at the border routers of that network could eliminate the 1084 possibility of source address spoofing. 1086 For a greater degree of security, the LDP MD5 authentication key 1087 option, as described in section 2.9 of RFC 3036, or the Control 1088 Message Authentication option of [L2TPv3] MAY be used. This provides 1089 integrity and authentication for the control messages, and eliminates 1090 the possibility of source address spoofing. Use of the message 1091 authentication option does not provide privacy, but privacy of 1092 control messages are not usually considered to be highly urgent. 1093 Both the LDP and L2TPv3 message authentication options rely on the 1094 configuration of pre-shared keys, making it difficult to deploy when 1095 the set of eligible neighbors is determined by an auto-configuration 1096 protocol. 1098 When the Generalized ID FEC Element is used, it is possible that a 1099 particular peer may be one of the eligible peers, but may not be the 1100 right one to connect to the particular attachment circuit identified 1101 by the particular instance of the Generalized ID FEC element. 1102 However, given that the peer is known to be one of the eligible peers 1103 (as discussed above), this would be the result of a configuration 1104 error, rather than a security problem. Nevertheless, it may be 1105 advisable for a PE to associate each of its local attachment circuits 1106 with a set of eligible peers, rather than having just a single set of 1107 eligible peers associated with the PE as a whole. 1109 11. IANA Considerations 1111 11.1. Channel 1113 The Channel Type codepoint is defined in [PW-CW], and an IANA 1114 registry was requested in [VCCV]. This draft further requests the 1115 following code point to be assigned to that registry. 0x01 OAM 1116 Indication For Multihop Pseudowires (MH-VCCV) 1118 11.2. L2TPv3 AVP 1120 This document uses a ne L2TP parameter, IANA already maintains a 1121 registry of name "Control Message Attribute Value Pair" defined by 1122 [RFC3438]. The following new values are required: 1124 TBA-L2TP-AVP-1 - PW Switching Point AVP 1126 11.3. LDP TLV TYPE 1128 This document uses several new LDP TLV types, IANA already maintains 1129 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1130 following value is suggested for assignment: 1132 TLV type Description 1133 0x096D Pseudo Wire Switching TLV 1135 11.4. LDP Status Codes 1137 This document uses several new LDP status codes, IANA already 1138 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1139 RFC3036. The following value is suggested for assignment: 1141 Assignment E Description 1142 0x0000003A 0 "PW Loop Detected" 1144 11.5. L2TPv3 Result Codes 1146 This document uses several new LDP status codes, IANA already 1147 maintains a registry of name "L2TPv3 Result Codes" defined by 1148 RFCxxxx. The following value is suggested for assignment: 1150 Assignment Description 1151 17 "sequencing not supported" 1153 11.6. New IANA Registries 1155 IANA needs to set up a registry of "PW Switching Point TLV Type". 1156 These are 8-bit values. Types value 1 through 3 are defined in this 1157 document. Type values 4 through 64 are to be assigned by IANA using 1158 the "Expert Review" policy defined in RFC2434. AGI Type values 65 1159 through 127, 0 and 255 are to be allocated using the IETF consensus 1160 policy defined in [RFC2434]. AGI types values 128 through 254 are 1161 reserved for vendor proprietary extensions and are to be assigned by 1162 IANA, using the "First Come First Served" policy defined in RFC2434. 1164 The Type Values are assigned as follows: 1165 Type Length Description 1167 0x01 4 PW ID of last PW segment traversed 1168 0x02 variable PW Switching Point description string 1169 0x03 4/16 IP address of PW Switching Point 1170 0x04 variable MH VCCV Capability Indication 1171 0x05 variable AI of last PW segment traversed 1172 0x06 variable L2 PW address of PW Switching Point (recomended format) 1174 12. Intellectual Property Statement 1176 The IETF takes no position regarding the validity or scope of any 1177 Intellectual Property Rights or other rights that might be claimed to 1178 pertain to the implementation or use of the technology described in 1179 this document or the extent to which any license under such rights 1180 might or might not be available; nor does it represent that it has 1181 made any independent effort to identify any such rights. Information 1182 on the procedures with respect to rights in RFC documents can be 1183 found in BCP 78 and BCP 79. 1185 Copies of IPR disclosures made to the IETF Secretariat and any 1186 assurances of licenses to be made available, or the result of an 1187 attempt made to obtain a general license or permission for the use of 1188 such proprietary rights by implementers or users of this 1189 specification can be obtained from the IETF on-line IPR repository at 1190 http://www.ietf.org/ipr. 1192 The IETF invites any interested party to bring to its attention any 1193 copyrights, patents or patent applications, or other proprietary 1194 rights that may cover technology that may be required to implement 1195 this standard. Please address the information to the IETF at ietf- 1196 ipr@ietf.org. 1198 13. Full Copyright Statement 1200 Copyright (C) The Internet Society (2006). 1202 This document is subject to the rights, licenses and restrictions 1203 contained in BCP 78, and except as set forth therein, the authors 1204 retain all their rights. 1206 This document and the information contained herein are provided on an 1207 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1208 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1209 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1210 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1211 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1212 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1214 14. Acknowledgments 1216 The authors wish to acknowledge the contributions of Wei Luo, and 1217 Skip Booth. 1219 15. Normative References 1221 [PWE3-MPLS] "Transport of Layer 2 Frames Over MPLS", Martini, L., 1222 et al.,draft-ietf-pwe3-control-protocol-16.txt, 1223 ( work in progress ), May 2005. 1225 [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. 1226 draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ), 1227 October 2004. 1229 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 1230 M. Townsley, I. Goyret, RFC3931 1232 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1233 Verification (VCCV)", Internet Draft 1234 , October 2005. (work in progress) 1236 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1237 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1238 1998. 1240 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1241 Languages", BCP 18, RFC 2277, January 1998. 1243 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, March 1997. 1246 [BCP79] S. Bradner, Ed., "Intellectual Property Rights in IETF 1247 Technology", BCP 79, RFC 3979, March 2005. 1249 [BCP78] S. Bradner, Ed., "IETF Rights in Contributions", 1250 BCP 78, RFC 3978, March 2005. 1252 [PW-ADDR] C. Metz, L. Martini, F. Balus, J. Sugimoto, "AII Types 1253 for Aggregation" draft-metz-aii-aggregate-01.txt, (work in 1254 progress), October 2005 1256 16. Informative References 1258 [MPLS-IP-GRE] "Encapsulating MPLS in IP or Generic 1259 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1260 draft-ietf-mpls-in-ip-or-gre-08.txt, ( work in progress ), 1261 December 2004. 1263 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., 1264 draft-ietf-pwe3-arch-07.txt ( work in progress ), June 2003. 1266 [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, 1267 W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt 1268 ( work in progress ) February 2004 1270 [PWE-IANA] "IANA Allocations for pseudo Wire Edge to 1271 Edge Emulation (PWE3)" Martini, Townsley, 1272 draft-ietf-pwe3-iana-allocation-04.txt ( work in progress ), 1273 April 2004 1275 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, Wei, 1276 draft-ietf-l2tpext-l2vpn-00.txt, ( work in progress ), Jan 2004 1278 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1279 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1280 ( work in progress ), July 2004 1282 [L2TP-ATM] "ATM Pseudo-Wire Extensions for L2TP", Singh, 1283 Townsley, Lau, draft-ietf-l2tpext-pwe3-atm-00.txt, 1284 ( work in progress ), March 2004. 1286 [PWE3-ATM] "Encapsulation Methods for Transport of ATM 1287 Over IP and MPLS Networks", Martini, Rosen, Bocci, 1288 "draft-ietf-pwe3-atm-encap-05.txt", ( work in progress ), 1289 April 2004. 1291 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1292 (L2TP) Internet" 1294 [BCP68] Assigned Numbers Authority (IANA) Considerations 1295 Update", RFC 3438, BCP 68, November 2002. 1297 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1298 draft-ietf-pwe3-oam-msg-map-02.txt, ( work in progress ), 1299 February 2005 1301 17. Author Information 1303 Luca Martini 1304 Cisco Systems, Inc. 1305 9155 East Nichols Avenue, Suite 400 1306 Englewood, CO, 80112 1307 e-mail: lmartini@cisco.com 1309 Thomas D. Nadeau 1310 Cisco Systems, Inc. 1311 300 Beaver Brook Road 1312 Boxborough, MA 01719 1313 e-mail: tnadeau@cisco.com 1315 Chris Metz 1316 Cisco Systems, Inc. 1317 e-mail: chmetz@cisco.com 1318 Mike Duckett 1319 Bellsouth 1320 Lindbergh Center 1321 D481 1322 575 Morosgo Dr 1323 Atlanta, GA 30324 1324 e-mail: mduckett@bellsouth.net 1326 Vasile Radoaca 1327 e-mail: radoaca@hotmail.com 1329 Matthew Bocci 1330 Alcatel 1331 Grove House, Waltham Road Rd 1332 White Waltham, Berks, UK. SL6 3TN 1333 e-mail: matthew.bocci@alcatel.co.uk 1335 Florin Balus 1336 Nortel Networks 1337 3500 Carling Ave. 1338 Ottawa, Ontario, CANADA 1339 e-mail: balus@nortel.com