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