idnits 2.17.1 draft-ietf-pwe3-segmented-pw-00.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 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 960. ** 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 283: '...E3. PW1 and PW3 MUST be of the same P...' RFC 2119 keyword, line 325: '... circuits MUST be of the same type e...' RFC 2119 keyword, line 332: '...2 at PE2 and PE3 MUST be configured su...' RFC 2119 keyword, line 351: '...e originating PE, but SHOULD be set to...' RFC 2119 keyword, line 370: '...rol planes the PW switching point MUST...' (28 more instances...) 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 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 (July 2005) is 6859 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: 'PWE3-IANA' is mentioned on line 675, but not defined == Unused Reference: 'BCP68' is defined on line 1034, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 == 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: 5 errors (**), 0 flaws (~~), 10 warnings (==), 9 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: January 2006 Thomas D. Nadeau 5 Cisco Systems Inc. 7 Vasile Radoaca Mike Duckett 8 Nortel Networks Bellsouth 10 Matthew Bocci Florin Balus 11 Alcatel Nortel Networks 13 July 2005 15 Segmented Pseudo Wire 17 draft-ietf-pwe3-segmented-pw-00.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 ......................................... 4 55 4 General Description .................................. 6 56 5 PW Switching with Attachment Circuits ................ 9 57 6 PW-MPLS to PW-MPLS Control Plane Switching ........... 9 58 6.1 MPLS PW Control Plane Switching ...................... 9 59 6.1.1 Static Control plane switching ....................... 10 60 6.1.2 Two LDP control planes using the same FEC type ....... 10 61 6.1.3 LDP using FEC 128 to LDP using the generalized FEC 129 ...10 62 6.1.4 PW switching point TLV ............................... 11 63 6.1.5 Adaptation of Interface Parameters ................... 12 64 6.1.6 Group ID ............................................. 13 65 6.1.7 PW Loop Detection .................................... 13 66 7 PW-MPLS to PW-L2TPv3 Control Plane Switching ......... 13 67 7.1 Static MPLS and L2TPv3 PWs ........................... 13 68 7.2 Static MPLS PW and Dynamic L2TPv3 PW ................. 14 69 7.3 Static L2TPv3 PW and Dynamic LDP/MPLS PW ............. 14 70 7.4 Dynamic LDP/MPLS and L2TPv3 PWs ...................... 14 71 7.4.1 Session Establishment ................................ 14 72 7.4.2 Adaptation of PW Status message ...................... 15 73 7.4.3 Session Teardown ..................................... 15 74 7.5 Adaptation of LDP/L2TPv3 AVPs and Interface Parameters ...16 75 7.6 Switching Point TLV in L2TPv3 ........................ 17 76 7.7 L2TPv3 and MPLS PW Data Plane ........................ 17 77 7.7.1 PWE3 Payload Convergence and Sequencing .............. 18 78 7.7.2 Mapping .............................................. 18 79 8 Operation And Management ............................. 19 80 8.1 Pseudo Wire Status ................................... 19 81 8.2 Pseudowire Status Negotiation Procedures ............. 21 82 8.3 Status Dampening ..................................... 21 83 9 Peering Between Autonomous Systems ................... 21 84 10 Security Considerations .............................. 21 85 10.1 Data Plane Security .................................. 21 86 10.2 Control Protocol Security ............................ 22 87 11 IANA Considerations .................................. 23 88 12 Intellectual Property Statement ...................... 23 89 13 Full Copyright Statement ............................. 23 90 14 Acknowledgments ...................................... 24 91 15 Normative References ................................. 24 92 16 Informative References ............................... 24 93 17 Author Information ................................... 25 95 1. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 101 2. Terminology 103 - Ultimate PE (U-PE). A PE where the customer-facing ACs are bound 104 to a PW forwarder. An ultimate PE is present in the first and 105 last segments of a MH-PW. 107 - Single-Hop PW (SH-PW). A PW set up between two PE devices using 108 standard PWE3 signaling and encapsulation methods. 110 - Multi-hop PW (MH-PW). Static or dynamically configured set of two 111 or more contiguous PW segments (SH-PW) that behave and function 112 as a single point-to-point PW. Each PW segment is setup and 113 managed using standard PWE3 encapsulation and signaling methods. 115 - PW Switching Point. (S-PE)A PE capable of switching the control 116 and data planes of the preceding and succeeding PW segments (SH- 117 PW) in a MH-PW. A PW Switching Point is never the ultimate PE in 118 a MH-PW. A PW switching point runs standard PWE3 protocols to 119 setup and manage PW segments with other PW switching points and 120 ultimate PEs. 122 3. Introduction 124 PWE3 defines the signaling and encapsulation techniques for 125 establishing SH-PWs between a pair of ultimate PEs and in the vast 126 majority of cases this will be sufficient. MH-PWs come into play in 127 two general cases: 129 -i. When it is not possible, desirable or feasible to establish 130 a PW control channel between the ultimate source and 131 destination PEs. At a minimum PW control channel 132 establishment requires knowledge of and reachability to the 133 remote (ultimate) PE IP address. The local (ultimate) PE may 134 not have access to this information related to topology, 135 operational or security constraints. 137 An example is the inter-AS L2VPN scenario where the ultimate 138 PEs reside in different provider networks (ASes) and it is 139 the practice to MD5-key all control traffic exchanged 140 between two networks. Technically a SH-PW could be used but 141 this would require MD5-keying on ALL ultimate source and 142 destination PE nodes. An MH-PW allows the providers to 143 confine MD5 key administration to just the PW switching 144 points connecting the two domains. 146 A second example might involve a single AS where the PW 147 setup path between the ultimate PEs is computed by an 148 external entity (i.e. client-layer routing protocol). Assume 149 a full mesh of PWE3 control channels established between 150 PE-A, PE-B and PE-C. A client-layer L2 connection tunneled 151 through a PW is required between ultimate PE-A and PE-C. The 152 external entity computes a PW setup path that passes through 153 PE-B. This results in two discrete PW segments being built: 154 one between PE-A and PE-B and one between PE-B and PE-C. The 155 successful client-layer L2 connection between ultimate PE-A 156 and ultimate PE-C requires that PE-B performs the PWE3 157 switching process. 159 A third example involves the use of PWs in hierarchical 160 IP/MPLS networks. Access networks connected to a backbone 161 use PWs to transport customer payloads between customer 162 sites serviced by the same access network and up to the edge 163 of the backbone where they can be terminated or switched 164 onto a succeeding PW segment crossing the backbone. The use 165 of PWE3 switching between the access and backbone networks 166 can potentially reduce the PWE3 control channels and routing 167 information processed by the access network U-PEs. 169 It should be noted that PWE3 switching does not help in any 170 way to reduce the amount of PW state supported by each 171 access network U-PE. 173 -ii. PWE3 signaling and encapsulation protocols are different. 174 The ultimate PEs are connected to networks employing 175 different PW signaling and encapsulation protocols. In this 176 case it is not possible to use a SH-PW. A MH-PW with the 177 appropriate interworking performed at the PW switching 178 points can enable PW connectivity between the ultimate PEs 179 in this scenario. 181 There are four different signaling protocols that are defined to 182 signal PWs: 183 -i. Static configuration of the PW (MPLS or L2TPv3). 184 -ii. LDP using FEC 128 186 -iii. LDP using the generalized FEC 129 187 -iv. L2TPv3 189 4. General Description 191 A pseudo-wire (PW) is a tunnel established between two provider edge 192 (PE) nodes to transport L2 PDUs across a packet switched network 193 (PSN) as described in Figure 1 and in [PWE3-ARCH]. Many providers are 194 looking at PWs as a means of migrating existing (or building new) 195 L2VPN services (i.e. Frame-Relay, ATM, Ethernet) on top of a PSN by 196 using PWs. PWs may span multiple autonomous systems of the same or 197 different provider networks. In these scenarios PW control channels 198 (i.e. targeted LDP, L2TPv3) and PWs will cross AS boundaries. 200 Inter-AS L2VPN functionality is currently supported and several 201 techniques employing MPLS encapsulation and LDP signaling have been 202 documented [2547BIS]. It is also straightforward to support the same 203 inter-AS L2VPN functionality employing L2TPv3. In this document we 204 define methodology to switch a PW between two PW control planes. 206 |<-------------- Emulated Service ---------------->| 207 | | 208 | |<------- Pseudo Wire ------>| | 209 | | | | 210 | | |<-- PSN Tunnel -->| | | 211 | V V V V | 212 V AC +----+ +----+ AC V 213 +-----+ | | PE1|==================| PE2| | +-----+ 214 | |----------|............PW1.............|----------| | 215 | CE1 | | | | | | | | CE2 | 216 | |----------|............PW2.............|----------| | 217 +-----+ ^ | | |==================| | | ^ +-----+ 218 ^ | +----+ +----+ | | ^ 219 | | Provider Edge 1 Provider Edge 2 | | 220 | | | | 221 Customer | | Customer 222 Edge 1 | | Edge 2 223 | | 224 native service native service 226 Figure 1: PWE3 Reference Model 228 There are two methods for switching a PW between two PW control 229 planes. In the first method (Figure 2), the two control planes 230 terminate on different PEs. 232 |<------------Emulated Service---------->| 233 | PSN PSN | 234 AC | |<-1->| |<-2->| | AC 235 | V V V V V V | 236 | +----+ +-----+ +----+ +----+ | 237 +----+ | | |=====| | | |=====| | | +----+ 238 | |-------|......PW1.......|--AC1--|......PW2......|-------| | 239 | CE1| | | | | | | | | | | |CE2 | 240 | |-------|......PW3.......|--AC2--|......PW4......|-------| | 241 +----+ | | |=====| | | |=====| | | +----+ 242 ^ +----+ +-----+ +----+ +----+ ^ 243 | PE1 PE2 PE3 PE4 | 244 | ^ ^ | 245 | | | | 246 | PW stitching points | 247 | | 248 | | 249 |<-------------------- Emulated Service ---------------->| 251 Figure 2: PW Switching using ACs Reference Model 253 In Figure 2, pseudo wires in two separate PSNs are stitched together 254 using native service attachment circuits. PE2 and PE3 only run the 255 control plane for the PSN to which they are directly attached. At PE2 256 and PE3, PW1 and PW2 are connected using attachment circuit AC1, 257 while PW3 and PW4 are connected using attachment circuit AC2. 259 Native |<-----------Pseudo Wire----------->| Native 260 Layer2 | | Layer2 261 Service | |<-PSN1-->| |<--PSN2->| | Service 262 (AC) V V V V V V (AC) 263 | +----+ +-----+ +----+ | 264 +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ 265 | |----------|........PW1.........|...PW3........|----------| | 266 | CE1| | | | | | | | | |CE2 | 267 | |----------|........PW2.........|...PW4........|----------| | 268 +----+ | | |=========| |=========| | | +----+ 269 ^ +----+ +-----+ +----+ | ^ 270 | Provider Edge 1 ^ Provider Edge 3 | 271 | (Ultimate PE) | (Ultimate PE) | 272 | | | 273 | PW switching point | 274 | (Optional PW adaptation function) | 275 | | 276 |<------------------- Emulated Service ------------------>| 278 Figure 3: PW Control Plane Switching Reference Model 280 In Figure 3 PE2 runs two separate control planes: one toward PE1, and 281 one Toward PE3. The PW switching point is at PE2 which is configured 282 to connect PW1 and PW3 together to complete the multi-hop PW between 283 PE1 and PE3. PW1 and PW3 MUST be of the same PW type, but PSN1 and 284 PSN2 need not be the same technology. In the latter case, if the PW 285 is switched to a different technology, the PEs must adapt the PDU 286 encapsulation between the different PSN technologies. In the case 287 where PSN1 and PSN2 are the same technology the PW PDU does not need 288 to be modified, and PDUs are then switched between the pseudo-wires 289 at the PW label level. 291 It should be noted that it is possible to adapt one PSN technology to 292 a different one, for example MPLS over an IP or GRE [MPLS-IP-GRE] 293 encapsulation, but this is outside the scope of this document. 294 Further, one could perform an interworking function on the PWs 295 themselves at the PW switching point, allowing conversion from one PW 296 type to another, but this is also outside the scope of this document. 298 The pseudowire switching methodology described in this document 299 assumes manual configuration of the switching point at PE2. It should 300 also be noted that a PW can traverse multiple PW switching points 301 along it's path, and the edge PEs will not require any specific 302 knowledge of how many PW switching points the PW has traversed 303 (though this may be reported for troubleshooting purposes). 305 In general the approach taken is to connect the individual control 306 planes by passing along any signaling information immediately upon 307 reception. First the PW switching point is configured to switch a 308 SH-PW from a specific peer to another SH-PW destined for a different 309 peer. No control messages are exchanged yet as the PW switching point 310 PE does not have enough information to actually initiate the PW setup 311 messages. However, if a session does not already exist, a control 312 protocol (LDP/L2TP) session is setup. In this model the MH-PW setup 313 is starting from the U-PE devices. Next once the U-PE is configured 314 it sends the PW control setup messages. These messages are received, 315 and immediately used to form the PW setup messages for the next SH-PW 316 of the MH-PW. If one of the Switching PEs doesn't accept an LDP Setup 317 message then a Label release message is sent back to the originator 318 U-PE. A MH-PW is declared UP when all the constituent SH-PWs are UP. 320 5. PW Switching with Attachment Circuits 322 In PW switching with attachment circuits, each PSN may be of a 323 different type e.g. MPLS, L2TPv3. However the details of this are 324 outside the scope of this document. The PWs and the attachment 325 circuits MUST be of the same type e.g. ATM, Ethernet, etc. 327 The PWs in each PSN are established independently, with each PSN 328 being treated as a separate PWE3 domain. For example, in Figure 2 for 329 case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP 330 targeted session as described in [PWE3-MPLS], and at the same time a 331 separate pseudo wire, PW2, is setup between PE3 and PE4. The ACs for 332 PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the 333 same native circuit e.g. ATM VCC, Ethernet VLAN, etc. These ACs thus 334 connect the PWs in PSN1 and PSN2 together. 336 6. PW-MPLS to PW-MPLS Control Plane Switching 338 Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted 339 session as described in [PWE3-MPLS], at the same time a separate 340 pseudo wire PW3 is setup to PE3. Each PW is configured independently 341 on the PEs, but on PE2 pseudo wire PW1 is connected to pseudo wire 342 PW3. PDUs are then switched between the pseudo-wires at the PW label 343 level. Hence the data plane does not need any special knowledge of 344 the specific pseudo wire type. A simple standard MPLS label swap 345 operation is sufficient to connect the two PWs, and in this case the 346 PW adaptation function is not used. 348 This process can be repeated as many times as necessary, the only 349 limitation to the number of PW switching points traversed is imposed 350 by the TTL field of the PW MPLS Label. The setting of the TTL is a 351 matter of local policy on the originating PE, but SHOULD be set to 352 255. 354 6.1. MPLS PW Control Plane Switching 356 There are three MPLS to MPLS PW control planes: 357 -i. Static configuration of the PW. 358 -ii. LDP using FEC 128 359 -iii. LDP using the generalized FEC 129 360 This results in four distinct PW switching situations that are 361 significantly different, and must be considered in detail: 363 -i. PW Switching between two static control planes. 364 -ii. Static Control plane switching to LDP dynamic control plane. 365 -iii. Two LDP control planes using the same FEC type 366 -iv. LDP using FEC 128, to LDP using the generalized FEC 129 368 6.1.1. Static Control plane switching 370 In the case of two static control planes the PW switching point MUST 371 be configured to direct the MPLS packets from one PW into the other. 372 There is no control protocol involved in this case. When one of the 373 control planes is a simple static PW configuration and the other 374 control plane is a dynamic LDP FEC 128 or generalized PW FEC, then 375 the static control plane should be considered identical to an 376 attachment circuit (AC) in the reference model of Figure 1. The 377 switching point PE SHOULD signal the proper PW status if it detects a 378 failure in sending or receiving packets over the static PW. Because 379 the PW is statically configured, the status communicated to the 380 dynamic LDP PW will be limited to local interface failures. In this 381 case, the PW switching point PE behaves in a very similar manner to a 382 U-PE, assuming an active role. 384 6.1.2. Two LDP control planes using the same FEC type 386 As stated in a section above, the PW switching point PE should assume 387 an initial passive role. This means that once independent PWs are 388 configured on the switching point, the LSR does not advertise the LDP 389 PW FEC mapping until 391 it has received at least one of the two PW LDP FECs from a remote PE. 392 This is necessary because the switching point LSR does not know a 393 priory what the interface parameter field in in the initial FEC 394 advertisement will contain. 396 The PWID is a unique number between each pair of PEs. Hence Each SH- 397 PW that forms an MH-PW may have a different PWID. In the case of The 398 Generalized PW FEC, the AGI/SAI/TAI may have to also be different for 399 some, or sometimes all, SH-PWs. 401 6.1.3. LDP using FEC 128 to LDP using the generalized FEC 129 403 When a PE is using the generalized FEC 129, there are two distinct 404 roles that a PE can assume: active and passive. A PE that assumes the 405 active role will send the LDP PW setup message, while a passive role 406 PE will simply reply to an incoming LDP PW setup message. The PW 407 switching point PE, will always remain passive until a PWID FEC 128 408 LDP message is received, which will cause the corresponding 409 generalized PW FEC LDP message to be formed and sent. If a 410 generalized FEC PW LDP message is received while the switching point 411 PE is in a passive role, the corresponding PW FEC 128 LDP message 412 will be formed and sent. 414 PWIDs need to be mapped to the corresponding AGI/TAI/SAI and vice 415 versa. This can be accomplished by local PW switching point 416 configuration, or by some other means, such as some form of auto 417 discovery. Such other means are outside the scope of this document. 419 6.1.4. PW switching point TLV 421 The edge to edge PW might traverse several switching points, in 422 separate administrative domains. For management and troubleshooting 423 reasons it is useful to record all the switching points that the PW 424 traverses. This is accomplished by using a PW switching point TLV. 426 The OPTIONAL PW switching point TLV is appended to the PW FEC at each 427 switching point and is encoded as follows: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |1|0| PW sw TLV (0x096B) | PW sw TLV Length | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | Variable Length Value | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Variable Length Value | 437 | " | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 - PW sw TLV Length 442 Specifies the total length of all the following PW switching 443 point TLV fields in octets 445 - Type 447 Encodes how the Value field is to be interpreted. 449 - Length 451 Specifies the length of the Value field in octets. 453 - Value 455 Octet string of Length octets that encodes information to be 456 interpreted as specified by the Type field. 458 Type value 0 is reserved. Type values 1 through 3 are defined in this 459 document. Values 3 through 63 are to be assigned by IANA using the 460 "IETF Consensus" policy defined in RFC2434. Type values values 64 461 through 127 are to be assigned by IANA, using the "First Come First 462 Served" policy defined in RFC2434. Type values 128 through 255 are 463 vendor-specific, and values in this range are not to be assigned by 464 IANA. 466 The Type Values are assigned as follows: 467 Type Length Description 469 0x00 0 Reserved 470 0x01 4 PW ID of last PW traversed 471 0x02 variable PW Switching Point description string 472 0x03 4 IP address of PW Switching Point ( Optional ) 474 The PW switching Point TLV is an OPTIONAL TLV that can appear once 475 for each switching point traversed. 477 6.1.5. Adaptation of Interface Parameters 479 [PWE3-MPLS] defines several interface parameters, which are used by 480 the Network Service Processing (NSP) to adapt the PW to the 481 Attachment Circuit (AC). The interface parameters are only used at 482 the end points, and MUST be passed unchanged across the PW switching 483 point. However the following interface parameters MAY be modified as 484 follows: 486 - 0x03 Optional Interface Description string This Interface 487 parameter MAY be modified, or altogether removed from the FEC 488 element depending on local configuration policies. 490 - 0x09 Fragmentation indicator This parameter MAY be inserted in 491 the FEC by the switching point if it is capable of re-assembly of 492 fragmented PW frames according to [PWE3-FRAG]. 494 - 0x0C VCCV parameter The switching point MAY not be able to 495 inspect the VCCV control channel. In this case the Control 496 Channel Type indicator MUST be modified to reflect the capability 497 of the PE acting as the PW switching point. 499 6.1.6. Group ID 501 The Group ID ( GR ID ) is used to reduce the number of status 502 messages that need to be sent by the PE advertising the PW FEC. The 503 GR ID has local significance only, and therefore MUST be mapped to a 504 unique GR ID allocated by the PW switching point PE. 506 6.1.7. PW Loop Detection 508 A switching point PE SHOULD check the OPTIONAL PW switching Point 509 TLV, to verify if it's own IP address appears in it. If it's IP 510 address appears in a received PW switching Point TLV, the PE SHOULD 511 break the loop, and send a label release message with the following 512 error code: 513 0x0000003A "PW Loop Detected" 515 [ note: error code as defined in [PWE-IANA] pending IANA allocation ] 517 7. PW-MPLS to PW-L2TPv3 Control Plane Switching 519 Both MPLS and L2TPv3 PWs may be static or dynamic. This results in 520 four possibilities when switching between L2TPv3 and MPLS. 522 -i. Switching between MPLS and L2TPv3 static control planes. 523 -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW. 524 -iii. Switching between a static L2TPv3 PW and a dynamic MPLS PW. 525 -iv. Switching between a dynamic MPLS PW and a dynamic L2TPv3 PW. 527 7.1. Static MPLS and L2TPv3 PWs 529 In the case of two static control planes, the PW switching point MUST 530 be configured to direct packets from one PW into the other. There is 531 no control protocol involved in this case. The configuration MUST 532 include which MPLS VC Label maps to which L2TPv3 Session ID (and 533 associated Cookie, if present) as well as which MPLS Tunnel Label 534 maps to which PE destination IP address. 536 7.2. Static MPLS PW and Dynamic L2TPv3 PW 538 When a statically configured MPLS PW is switched to a dynamic L2TPv3 539 PW, the static control plane should be considered identical to an 540 attachment circuit (AC) in the reference model of Figure 1. The 541 switching point PE SHOULD signal the proper PW status if it detects a 542 failure in 544 sending or receiving packets over the static PW. Because the PW is 545 statically configured, the status communicated to the dynamic L2TPv3 546 PW will be limited to local interface failures. In this case, the PW 547 switching point PE behaves in a very similar manner to a U-PE, 548 assuming an active role. 550 7.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 552 When a statically configured L2TPv3 PW is switched to a dynamic 553 LDP/MPLS PW, then the static control plane should be considered 554 identical to an attachment circuit (AC) in the reference model of 555 Figure 1. The switching point PE SHOULD signal the proper PW status 556 (via an L2TPv3 SLI message) if it detects a failure in sending or 557 receiving packets over the static PW. Because the PW is statically 558 configured, the status communicated to the dynamic LDP/MPLS PW will 559 be limited to local interface failures. In this case, the PW 560 switching point PE behaves in a very similar manner to a U-PE, 561 assuming an active role. 563 7.4. Dynamic LDP/MPLS and L2TPv3 PWs 565 When switching between dynamic PWs, the switching point always 566 assumes an initial passive role. Thus, it does not initiate an 567 LDP/MPLS or L2TPv3 PW until it has received a connection request 568 (Label Mapping or ICRQ) from one side of the node. Note that while 569 MPLS PWs are made up of two unidirectional LSPs bonded together by 570 FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a 571 3-message exchange (ICRQ, ICRP and ICCN). Details of Session 572 Establishment, Teardown, and PW Status signalling are detailed below. 574 7.4.1. Session Establishment 576 When the PW switching point receives an L2TPv3 ICRQ message, the 577 identifying AVPs included in the message are mapped to FEC 578 identifiers and sent in an LDP label mapping message. Conversely, if 579 an LDP Label Mapping message is received, it is either mapped to an 580 ICRP message or causes an L2TPv3 session to be initiated by sending 581 an ICRQ. 583 Following are two example exchanges of messages between LDP and 584 L2TPv3. The first is a case where an L2TPv3 U-PE initiates an MH-PW, 585 the second is a case where an MPLS U-PE initiates an MH-PW. 587 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 589 AC "Up" 590 L2TPv3 ICRQ ---> 591 LDP Label Mapping ---> 592 AC "UP" 593 <--- LDP Label Mapping 594 <--- L2TPv3 ICRP 595 L2TPv3 ICCN ---> 596 <-------------------- MH PW Established ------------------> 598 PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3) 600 AC "Up" 601 LDP Label Mapping ---> 602 L2TPv3 ICRQ ---> 603 <--- L2TPv3 ICRP 604 <--- LDP Label Mapping 605 L2TPv3 ICCN ---> 606 AC "Up" 607 <-------------------- MH PW Established ------------------> 609 7.4.2. Adaptation of PW Status message 611 L2TPv3 uses the SLI message to indicate a interface status change 612 (such as the interface transitioning from "Up" or "Down"). MPLS/LDP 613 PWs either signal this via an LDP Label Withdraw or the PW Status 614 message defined in section 5.3.2 of [PWE3-MPLS]. 616 7.4.3. Session Teardown 618 L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN 619 message translates to a Label Withdraw message in LDP. Following are 620 two example exchanges of messages between LDP and L2TPv3. The first 621 is a case where an L2TPv3 U-PE initiates the termination of an MH-PW, 622 the second is a case where an MPLS U-PE initiates the termination of 623 an MH-PW. 625 PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) 627 AC "Down" 628 L2TPv3 CDN ---> 629 LDP Label Withdraw ---> 630 AC "Down" 632 <--------------- MH PW Data Path Down ------------------> 634 <--- LDP Label Withdraw * 636 * This LDP Label Withdraw is not necessary to break the end-to-end 637 MH PW data path. 639 PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3) 641 AC "Down" 642 LDP Label Withdraw ---> 643 L2TPv3 CDN --> 644 AC "Down" 646 <---------------- MH PW Data Path Down ------------------> 648 <--- LDP Label Withdraw * 649 * This LDP Label Withdraw is not necessary to break the end-to-end 650 MH PW data path. 652 7.5. Adaptation of LDP/L2TPv3 AVPs and Interface Parameters 654 [PWE3-MPLS] defines several interface parameters which must be mapped 655 to similar AVPs in L2TPv3 setup messages. 657 * Interface MTU 659 The Interface MTU parameter is mapped directly to the L2TP 660 Interface MTU AVP defined in [L2TP-L2VPN] 662 * Max Number of Concatenated ATM cells 664 This interface parameter is mapped directly to the L2TP "ATM 665 Maximum Concatenated Cells AVP" described in section 6 of [L2TP- 666 ATM]. 668 * Optional Interface Description String 670 This string may be carried as the "Call-Information AVP" 671 described in section 2.2 of [L2TP-INFOMSG] 673 * "PW Type 675 The PW Type defined in [PWE3-IANA] is mapped to the L2TPv3 "PW 676 Type" AVP defined in [L2TPv3]. 678 * PW ID (FEC 128) 680 For FEC 128, the PW ID is mapped directly to the L2TPv3 "Remote 681 End ID" AVP defined in [L2TPv3]. 683 * Generalized FEC 129 SAI/TAI 685 Section 4.3 of [L2TP-L2VPN] defines how to encode the SAI and TAI 686 parameters. These can be mapped directly. 688 Other interface parameter mappings will either be defined in a future 689 version of this document, or are unsupported when switching between 690 LDP/MPLS and L2TPv3 PWs. 692 7.6. Switching Point TLV in L2TPv3 694 When translating between LDP and L2TPv3 control messages, the PW 695 Switching Point TLV described earlier in this document is carried in 696 a single variable length L2TP AVP present in the ICRQ, ICRP messages, 697 and optionally in the ICCN message. 699 The L2TP "Switching Point AVP" is Attribute Type TBA-L2TP-AVP-1. The 700 AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of 701 the AVP is 6 plus the length of the series of Switching Point sub- 702 TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory 703 (the L2TP AVP M-bit MUST be 0). 705 7.7. L2TPv3 and MPLS PW Data Plane 707 When switching between an MPLS and L2TP PW, packets are sent in their 708 entirety from one PW to the other, replacing the MPLS label stack 709 with the L2TPv3 and IP header or vice versa. There are some 710 situations where an additional amount of interworking must be 711 provided between the two data planes at the PW switching node. 713 7.7.1. PWE3 Payload Convergence and Sequencing 715 Section 5.4 of [PWE3-ARCH] discusses the purpose of the various shim 716 headers necessary for enabling a pseudowire over an IP or MPLS PSN. 717 For L2TPv3, the Payload Convergence and Sequencing function is 718 carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. 719 For MPLS, these two functions (together with PSN Convergence) are 720 carried out via the MPLS Control Word. Since these functions are 721 different between MPLS and L2TPv3, interworking between the two may 722 be necessary. 724 The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers 725 which in some cases are not necessary to be present at all. For 726 example, an ethernet PW with sequencing disabled will generally not 727 require an MPLS Control Word or L2TP Default L2-Specific Sublayer to 728 be present at all. In this case, ethernet frames are simply sent from 729 one PW to the other without any modification beyond the MPLS and 730 L2TP/IP encapsulation and decapsulation. 732 The following section offers guidelines for how to interwork between 733 L2TP and MPLS for those cases where the Payload Convergence, 734 Sequencing, or PSN Convergence functions are necessary on one or both 735 sides of the switching node. 737 7.7.2. Mapping 739 The MPLS Control Word consists of (from left to right): 741 -i. These bits are always zero in MPLS are not necessary to be 742 mapped to L2TP. 744 -ii. These six bits may be used for Payload Convergence depending 745 on the PW type. For ATM, the first four of these bits are 746 defined in [PWE3-ATM]. These map directly to the bits 747 defined in [L2TP-ATM]. For Frame Relay, these bits indicate 748 how to set the bits in the Frame Relay header which must be 749 regenerated for L2TP as it carries the Frame Relay header 750 intact. 752 -iii. L2TP determines its payload length from IP. Thus, this 753 Length field need not be carried directly to L2TP. This 754 Length field will have to be calculated and inserted for 755 MPLS when necessary. 757 -iv. The Default L2-Specific Sublayer has a sequence number with 758 different semantics than that of the MPLS Control Word. This 759 difference eliminates the possibility of supporting 760 sequencing across the MH-PW by simply carrying the sequence 761 number through the switching point transparently. As such, 762 sequence numbers MAY be supported by checking the sequence 763 numbers of packets arriving at the switching point and 764 regenerating a new sequence number in the proper format for 765 the PW on egress. If this type of sequence interworking at 766 the switching node is not supported, and a U-PE requests 767 sequencing of all packets via the L2TP control channel 768 during session setup, the switching node SHOULD NOT allow 769 the session to be established by sending a CDN message with 770 Result Code set to 17 "sequencing not supported" (subject to 771 IANA Assignment). 773 8. Operation And Management 775 8.1. Pseudo Wire Status 777 In the PW switching with attachment circuits case (Figure 2), PW 778 status messages indicating PW or attachment circuit faults SHOULD be 779 mapped to fault indications or OAM messages on the connecting AC as 780 defined in [PW-MSG-MAP]. If the AC connecting two PWs crosses an 781 administrative boundary, then the manner in which those OAM messages 782 are treated at the boundary is out of scope of this draft. 784 In the PW control plane switching case (Figure 3), there is no 785 attachment circuit at the PW switching point, but the two PWs are 786 connected together. Similarly, the status of the PWs are forwarded 787 unchanged from one PW to the other by the control plane switching 788 function. However, it may sometimes be necessary to communicate 789 status of one of the locally attached SH-PW at a PW switching point. 790 For LDP this can be accomplished by sending an LDP status 791 notification message containing the PW status TLV, as well as an 792 OPTIONAL PW switching point TLV. 794 0 1 2 3 795 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 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 |0| Notification (0x0001) | Message Length | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Message ID | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |0|1| Status (0x0300) | Length | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 |0|1| Status Code=0x00000028 | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Message ID=0 | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Message Type=0 | PW Status TLV | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | PW Status TLV | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | PW Status TLV | PWId FEC | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | | 816 | | 817 | PWId FEC or Generalized ID FEC | 818 | | 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |1|0| PW sw TLV (0x096B) | PW sw TLV Length | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type | Length | Variable Length Value | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Only one PW switching point TLV can be present in this message. This 827 message is then relayed by each PW switching point unchanged. The U- 828 PE decodes the status message and the included PW switching point TLV 829 to detect where exactly the fault occurred. At the U-PE if there is 830 no PW switching point TLV included in the LDP status notification 831 then the status message can be assumed to have originated at the 832 remote U-PE. It should also be noted that once a PW status 833 notification message is initiated at a PW switching point, any 834 further status message received from an upstream neighbor is 835 processed locally and not forwarded until the PW switching point 836 original status message is cleared. When a PW status event, for a 837 particular PW, occurs at the S-PE, the appropriate PW status 838 notification MUST be send toward both remote S-PEs or U-PEs attached 839 to the PW. 841 8.2. Pseudowire Status Negotiation Procedures 843 Pseudowire Status signaling methodology, defined in [PWE3-MPLS], 844 SHOULD be transparent to the switching point. 846 8.3. Status Dampening 848 When the PW control plane switching methodology is used to cross an 849 administrative boundary it might be necessary to prevent excessive 850 status signaling changes from being propagated across the 851 administrative boundary. This can be achieved by using a similar 852 method as commonly employed for the BGP protocol route advertisement 853 dampening. The details of this OPTIONAL algorithm are a matter of 854 implementation, and are outside the scope of this document. 856 9. Peering Between Autonomous Systems 858 The procedures outlined in this document can be employed to provision 859 and manage MH-PWs crossing AS boundaries. 861 The use of more advanced mechanisms involving auto-discovery and 862 ordered PWE3 MH-PW signaling will be covered ina separate document. 864 10. Security Considerations 866 This document specifies the LDP and L2TPv3 extensions that are needed 867 for setting up and maintaining Pseudowires. The purpose of setting up 868 Pseudowires is to enable layer 2 frames to be encapsulated and 869 transmitted from one end of a Pseudowire to the other. Therefore we 870 treat the security considerations for both the data plane and the 871 control plane. 873 10.1. Data Plane Security 875 Data plane security consideration as discussed in [PWE3-MPLS], 876 [L2TPv3], and [PWE3-ARCH] apply to this extension without any 877 changes. 879 10.2. Control Protocol Security 881 General security considerations with regard to the use of LDP are 882 specified in section 5 of RFC 3036. Security considerations with 883 regard to the L2TPv3 control plane are specified in [L2TPv3]. These 884 considerations apply as well to the case where LDP or L2TPv3 is used 885 to set up PWs. 887 A Pseudowire connects two attachment circuits. It is important to 888 make sure that LDP connections are not arbitrarily accepted from 889 anywhere, or else a local attachment circuit might get connected to 890 an arbitrary remote attachment circuit. Therefore an incoming session 891 request MUST NOT be accepted unless its IP source address is known to 892 be the source of an "eligible" peer. The set of eligible peers could 893 be pre-configured (either as a list of IP addresses, or as a list of 894 address/mask combinations), or it could be discovered dynamically via 895 an auto-discovery protocol which is itself trusted. (Obviously if the 896 auto-discovery protocol were not trusted, the set of "eligible peers" 897 it produces could not be trusted.) 899 Even if a connection request appears to come from an eligible peer, 900 its source address may have been spoofed. So some means of 901 preventing source address spoofing must be in place. For example, if 902 all the eligible peers are in the same network, source address 903 filtering at the border routers of that network could eliminate the 904 possibility of source address spoofing. 906 For a greater degree of security, the LDP MD5 authentication key 907 option, as described in section 2.9 of RFC 3036, or the Control 908 Message Authentication option of [L2TPv3] MAY be used. This provides 909 integrity and authentication for the control messages, and eliminates 910 the possibility of source address spoofing. Use of the message 911 authentication option does not provide privacy, but privacy of 912 control messages are not usually considered to be highly urgent. 913 Both the LDP and L2TPv3 message authentication options rely on the 914 configuration of pre-shared keys, making it difficult to deploy when 915 the set of eligible neighbors is determined by an auto-configuration 916 protocol. 918 When the Generalized ID FEC Element is used, it is possible that a 919 particular peer may be one of the eligible peers, but may not be the 920 right one to connect to the particular attachment circuit identified 921 by the particular instance of the Generalized ID FEC element. 922 However, given that the peer is known to be one of the eligible peers 923 (as discussed above), this would be the result of a configuration 924 error, rather than a security problem. Nevertheless, it may be 925 advisable for a PE to associate each of its local attachment circuits 926 with a set of eligible peers, rather than having just a single set of 927 eligible peers associated with the PE as a whole. 929 11. IANA Considerations 931 This specification requires IANA to define the following L2TP 932 Parameters according to [RFC3438]: 934 Control Message Attribute Value Pairs 936 TBA-L2TP-AVP-1 - PW Switching Point AVP 938 12. Intellectual Property Statement 940 The IETF takes no position regarding the validity or scope of any 941 Intellectual Property Rights or other rights that might be claimed to 942 pertain to the implementation or use of the technology described in 943 this document or the extent to which any license under such rights 944 might or might not be available; nor does it represent that it has 945 made any independent effort to identify any such rights. Information 946 on the procedures with respect to rights in RFC documents can be 947 found in BCP 78 and BCP 79. 949 Copies of IPR disclosures made to the IETF Secretariat and any 950 assurances of licenses to be made available, or the result of an 951 attempt made to obtain a general license or permission for the use of 952 such proprietary rights by implementers or users of this 953 specification can be obtained from the IETF on-line IPR repository at 954 http://www.ietf.org/ipr. 956 The IETF invites any interested party to bring to its attention any 957 copyrights, patents or patent applications, or other proprietary 958 rights that may cover technology that may be required to implement 959 this standard. Please address the information to the IETF at ietf- 960 ipr@ietf.org. 962 13. Full Copyright Statement 964 Copyright (C) The Internet Society (2005). 966 This document is subject to the rights, licenses and restrictions 967 contained in BCP 78, and except as set forth therein, the authors 968 retain all their rights. 970 This document and the information contained herein are provided on an 971 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 972 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 973 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 974 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 975 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 976 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 978 14. Acknowledgments 980 The authors wish to acknowledge the contributions of Wei Luo, and 981 Skip Booth. 983 15. Normative References 985 [PWE3-MPLS] "Transport of Layer 2 Frames Over MPLS", Martini, L., 986 et al.,draft-ietf-pwe3-control-protocol-16.txt, 987 ( work in progress ), May 2005. 989 [2547BIS] "BGP/MPLS IP VPNs", Rosen, E, Rekhter, Y. 990 draft-ietf-l3vpn-rfc2547bis-03.txt ( work in progress ), 991 October 2004. 993 [L2TPv3] "Layer Two Tunneling Protocol (Version 3)", J. Lau, 994 M. Townsley, I. Goyret, RFC3931 996 16. Informative References 998 [MPLS-IP-GRE] "Encapsulating MPLS in IP or Generic 999 Routing Encapsulation (GRE)", Rosen, E, Rekhter, Y. 1000 draft-ietf-mpls-in-ip-or-gre-08.txt, ( work inprogress ), 1001 December 2004. 1003 [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., 1004 draft-ietf-pwe3-arch-07.txt ( workin progress ), June 2003. 1006 [PWE3-FRAG] "PWE3 Fragmentation and Reassembly", A. Malis, 1007 W. M. Townsley, draft-ietf-pwe3-fragmentation-05.txt 1008 ( work in progress ) February 2004 1010 [PWE-IANA] "IANA Allocations for pseudo Wire Edge to 1011 Edge Emulation (PWE3)" Martini, Townsley, 1012 draft-ietf-pwe3-iana-allocation-04.txt (work in progress), 1013 April 2004 1015 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, Wei, 1016 draft-ietf-l2tpext-l2vpn-00.txt, (work in progress), Jan 2004 1018 [L2TP-INFOMSG] "L2TP Call Information Messages", Mistretta, 1019 Goyret, McGill, Townsley, draft-mistretta-l2tp-infomsg-02.txt, 1020 (work in progress), July 2004 1022 [L2TP-ATM] "ATM Pseudo-Wire Extensions for L2TP", Singh, 1023 Townsley, Lau, draft-ietf-l2tpext-pwe3-atm-00.txt, 1024 (work in progress), March 2004. 1026 [PWE3-ATM] "Encapsulation Methods for Transport of ATM 1027 Over IP and MPLS Networks", Martini, Rosen, Bocci, 1028 "draft-ietf-pwe3-atm-encap-05.txt", (work in progress), 1029 April 2004. 1031 [RFC3438] W. M. Townsley, "Layer Two Tunneling Protocol 1032 (L2TP) Internet" 1034 [BCP68] Assigned Numbers Authority (IANA) Considerations 1035 Update", RFC 3438, BCP 68, November 2002. 1037 [PW-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", Nadeau et al, 1038 draft-ietf-pwe3-oam-msg-map-02.txt, (work in progress), February 1039 2005 1041 17. Author Information 1043 Luca Martini 1044 Cisco Systems, Inc. 1045 9155 East Nichols Avenue, Suite 400 1046 Englewood, CO, 80112 1047 e-mail: lmartini@cisco.com 1049 Thomas D. Nadeau 1050 Cisco Systems, Inc. 1051 300 Beaver Brook Road 1052 Boxborough, MA 01719 1053 e-mail: tnadeau@cisco.com 1055 Chris Metz 1056 Cisco Systems, Inc. 1057 e-mail: chmetz@cisco.com 1058 Mike Duckett 1059 Bellsouth 1060 Lindbergh Center 1061 D481 1062 575 Morosgo Dr 1063 Atlanta, GA 30324 1064 e-mail: mduckett@bellsouth.net 1066 Vasile Radoaca 1067 Nortel Networks 1068 600 Technology Park, 1069 Billerica, 01821, MA 1070 e-mail: vasile@nortelnetworks.com 1072 Matthew Bocci 1073 Alcatel 1074 Grove House, Waltham Road Rd 1075 White Waltham, Berks, UK. SL6 3TN 1076 e-mail: matthew.bocci@alcatel.co.uk 1078 Florin Balus 1079 Nortel Networks 1080 3500 Carling Ave. 1081 Ottawa, Ontario, CANADA 1082 e-mail: balus@nortel.com