idnits 2.17.1 draft-ietf-l2tpext-pwe3-ethernet-09.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 2006) is 6435 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3448 (ref. 'TFRC') (Obsoleted by RFC 5348) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Rahul Aggarwal 3 Internet Draft Juniper Networks 4 Expiration Date: February 2007 W. Mark Townsley 5 Maria A. Dos Santos 6 Cisco Systems 7 Editors 8 August 2006 10 Transport of Ethernet Frames over L2TPv3 12 draft-ietf-l2tpext-pwe3-ethernet-09.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This document describes the transport of Ethernet frames over Layer 2 40 Tunneling Protocol (L2TPv3). This includes the transport of Ethernet 41 port to port frames as well as the transport of Ethernet VLAN frames. 42 The mechanism described in this document can be used in the creation 43 of Pseudo Wires to transport Ethernet frames over an IP network. 45 Contributors 47 Following is the complete list of contributors to this document. 49 Rahul Aggarwal 50 Juniper Networks 52 Xipeng Xiao 53 Riverstone Networks 55 W. Mark Townsley 56 Stewart Bryant 57 Maria Alice Dos Santos 58 Cisco Systems 60 Cheng-Yin Lee 61 Alcatel 63 Tissa Senevirathne 64 Consultant 66 Mitsuru Higashiyama 67 Anritsu Corporation 69 Table of Contents 71 Status of this Memo.......................................... 1 73 1. Introduction.............................................. 3 74 1.1 Abbreviations......................................... 3 75 1.2 L2TPv3 Control Message Types.......................... 4 76 1.3 Requirements.......................................... 4 78 2. PW Establishment.......................................... 5 79 2.1 LCCE-LCCE Control Connection Establishment............ 5 80 2.2 PW Session Establishment.............................. 5 81 2.3 PW Session Monitoring................................. 6 83 3. Packet Processing......................................... 8 84 3.1 Encapsulation......................................... 8 85 3.2 Sequencing............................................ 8 86 3.3 MTU Handling.......................................... 8 88 4. Applicability Statement................................... 9 90 5. Congestion Control........................................ 11 91 6. Security Considerations................................... 12 93 7. IANA Considerations....................................... 12 95 8. Acknowledgements.......................................... 12 97 9. References................................................ 12 98 9.1 Normative References.................................. 12 99 9.2 Informative References................................ 13 101 10. Author Information....................................... 13 103 Specification of Requirements 105 In this document, several words are used to signify the requirements 106 of the specification. These words are often capitalized. The key 107 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 108 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 109 are to be interpreted as described in [RFC2119]. 111 1. Introduction 113 L2TPv3 can be used as a control protocol and for data encapsulation 114 to set up Pseudo Wires (PW) for transporting layer 2 Packet Data 115 Units across an IP network [RFC3931]. This document describes the 116 transport of Ethernet frames over L2TPv3 including the PW 117 establishment and data encapsulation. 119 The term "Ethernet" in this draft is used with the intention to 120 include all such protocols that are reasonably similar in their 121 packet format to IEEE 802.3 [802.3], including variants or extensions 122 which may or may not necessarily be sanctioned by IEEE (including 123 such things as jumbo frames, etc). The term "VLAN" in this draft is 124 used with the intention to include all virtual LAN tagging protocols 125 such as IEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc. 127 1.1 Abbreviations 129 AC Attachment Circuit (See [RFC3985]) 130 CE Customer Edge (Typically also the L2TPv3 Remote System) 131 LCCE L2TP Control Connection Endpoint (See [RFC3931]) 132 NSP Native Service Processing (See [RFC3985]) 133 PE Provider Edge (Typically also the LCCE) (See [RFC3985]) 134 PSN Packet Switched Network (See [RFC3985]) 135 PW Pseudo-Wire (See [RFC3985]) 136 PWE3 Pseudo-Wire Emulation Edge to Edge (Working Group) 138 1.2 L2TPv3 Control Message Types 140 Relevant L2TPv3 control message types (See [RFC3931]) are listed for 141 reference. 143 SCCRQ L2TPv3 Start-Control-Connection-Request control message 144 SCCRP L2TPv3 Start-Control-Connection-Reply control message 145 SCCCN L2TPv3 Start-Control-Connection-Connected control message 146 STOPCCN L2TPv3 Stop-Control-Connection-Notification control message 147 ICRQ L2TPv3 Incoming-Call-Request control message 148 ICRP L2TPv3 Incoming-Call-Reply control message 149 ICCN L2TPv3 Incoming-Call-Connected control message 150 OCRQ L2TPv3 Outgoing-Call-Request control message 151 OCRP L2TPv3 Outgoing-Call-Reply control message 152 OCCN L2TPv3 Outgoing-Call-Connected control message 153 CDN L2TPv3 Call-Disconnect-Notify control message 154 SLI L2TPv3 Set-Link-Info control message 156 1.3 Requirements 158 An Ethernet PW emulates a single Ethernet link between exactly two 159 endpoints. The following figure depicts the PW termination relative 160 to the NSP and PSN tunnel within a LCCE [RFC3985]. The Ethernet 161 interface may be connected to one or more Remote Systems (an L2TPv3 162 Remote System is referred to as Customer Edge (CE) in this and 163 associated PWE3 documents). The LCCE may or may not be a PE. 165 +---------------------------------------+ 166 | LCCE | 167 +-+ +-----+ +------+ +------+ +-+ 168 |P| | | |PW ter| | PSN | |P| 169 Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN 170 Interface |y| | | |on | | | |y| 171 +-+ +-----+ +------+ +------+ +-+ 172 | | 173 +---------------------------------------+ 174 Figure 1: PW termination 176 The PW termination point receives untagged (also referred to as 177 'raw') or tagged Ethernet frames and delivers them unaltered to the 178 PW termination point on the remote LCCE. Hence it can provide 179 untagged or tagged Ethernet link emulation service. 181 The "NSP" function includes packet processing needed to translate the 182 Ethernet frames that arrive at the CE-LCCE interface to/from the 183 Ethernet frames that are applied to the PW termination point. Such 184 functions may include stripping, overwriting or adding VLAN tags. 185 The NSP functionality can be used in conjunction with local 186 provisioning to provide heterogeneous services where the CE-LCCE 187 encapsulations at the two ends may be different. 189 The physical layer between the CE and LCCE, and any adaptation (NSP) 190 functions between it and the PW termination, are outside of the scope 191 of PWE3 and are not defined here. 193 2. PW Establishment 195 With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3 196 sessions. An L2TP control connection has to be set up first between 197 the two LCCEs. Individual PWs can then be established as L2TP 198 sessions. 200 2.1 LCCE-LCCE Control Connection Establishment 202 The two LCCEs that wish to set up Ethernet PWs MUST establish a L2TP 203 control connection first as described in [RFC3931]. Hence an Ethernet 204 PW type must be included in the Pseudo Wire Capabilities List as 205 defined in [RFC3931]. The type of PW can be either "Ethernet port" or 206 "Ethernet VLAN". This indicates that the control connection can 207 support the establishment of Ethernet PWs. Note that there are two 208 Ethernet PW types required. For connecting an Ethernet port to 209 another Ethernet port, the PW Type MUST be "Ethernet port"; for 210 connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type 211 MUST be "Ethernet VLAN". 213 2.2 PW Session Establishment 215 The provisioning of an Ethernet port or Ethernet VLAN and its 216 association with a PW triggers the establishment of an L2TP session 217 via the standard Incoming Call three-way handshake described in 218 Section 3.4.1 of [RFC3931]. 220 Note that an L2TP Outgoing Call is essentially a method of 221 controlling the originating point of an SVC, allowing it to be 222 established from any reachable L2TP-enabled device able to perform 223 outgoing calls. The Outgoing Call model and its corresponding OCRQ, 224 OCRP and OCCN control messages are mainly used within the dial arena 225 with L2TPv2 today and has not been found applicable for PW 226 applications yet. 228 The following are the signaling elements needed for the Ethernet PW 229 establishment: 231 a) Pseudo Wire Type: The type of a Pseudo Wire can be either 232 "Ethernet port" or "Ethernet VLAN". Each LCCE signals its Pseudo Wire 233 type in the Pseudowire Type AVP [RFC3931]. The assigned values for 234 "Ethernet port" and "Ethernet VLAN" Pseudo Wire types are captured in 235 the "IANA Considerations" of this document. The Pseudowire Type AVP 236 MUST be present in the ICRQ. 238 b) Pseudo Wire ID: Each PW is associated with a Pseudo Wire ID. The 239 two LCCEs of a PW have the same Pseudo Wire ID for it. The Remote End 240 Identifier AVP [RFC3931] is used to convey the Pseudo Wire ID. The 241 Remote End Identifier AVP MUST be present in the ICRQ in order for 242 the remote LCCE to determine the PW to associate the L2TP session 243 with. An implementation MUST support a Remote End Identifier of four 244 octets known to both LCCEs either by manual configuration or some 245 other means. Additional Remote End Identifier formats which MAY be 246 supported are outside the scope of this document. 248 c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP 249 to indicate the circuit status of the Ethernet port or Ethernet VLAN. 250 For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the 251 circuit status is for a new circuit (refer to N bit in Section 252 2.3.3). An Implementation MAY send an ICRQ or ICRP before an 253 Ethernet interface is ACTIVE, as long as the Circuit Status AVP 254 (refer to A bit in Section 2.3.3) in the ICRQ or ICRP reflects the 255 correct status of the Ethernet port or Ethernet VLAN link. Subsequent 256 circuit status change of the Ethernet port or Ethernet VLAN MUST be 257 conveyed in the Circuit Status AVP in ICCN or SLI control messages. 258 For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP 259 MUST indicate that the circuit status is for an existing circuit 260 (refer to N bit in Section 2.3.3) and reflect the current status of 261 the link (refer to A bit in Section 2.3.3). 263 2.3 PW Session Monitoring 264 2.3.1. Control Connection Keep-alive 266 The working status of a PW is reflected by the state of the L2TPv3 267 session. If the corresponding L2TPv3 session is down, the PW 268 associated with it MUST be shut down. The control connection keep- 269 alive mechanism of L2TPv3 can serve as a link status monitoring 270 mechanism for the set of PWs associated with a Control Connection. 272 2.3.2. SLI Message 274 In addition to the control connection keep-alive mechanism of L2TPv3, 275 Ethernet PW over L2TP makes use of the Set Link Info (SLI) control 276 message defined in [RFC3931]. The SLI message is used to signal 277 Ethernet link status notifications between LCCEs. This can be useful 278 to indicate Ethernet interface state changes without bringing down 279 the L2TP session. Note that change in the Ethernet interface state 280 will trigger a SLI message for each PW associated with that Ethernet 281 interface. This may be one Ethernet Port PW or more than one 282 Ethernet VLAN PW. The SLI message MUST be sent any time there is a 283 status change of any values identified in the Circuit Status AVP. The 284 only exception to this is the initial ICRQ, ICRP and CDN messages 285 which establish and teardown the L2TP session itself. The SLI 286 message may be sent from either LCCE at any time after the first ICRQ 287 is sent (and perhaps before an ICRP is received, requiring the peer 288 to perform a reverse Session ID lookup). 290 2.3.3. Use of Circuit Status AVP for Ethernet 292 Ethernet PW reports Circuit Status with the Circuit Status AVP 293 defined in [RFC3931]. For reference, this AVP is shown below: 295 0 1 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Reserved |N|A| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 The Value is a 16 bit mask with the two least significant bits 302 defined and the remaining bits reserved for future use. Reserved bits 303 MUST be set to 0 when sending, and ignored upon receipt. 305 The A (Active) bit indicates whether the Ethernet interface is ACTIVE 306 (1) or INACTIVE (0). 308 The N (New) bit indicates whether the circuit status is for a new (1) 309 Ethernet circuit or an existing (0) Ethernet circuit. 311 3. Packet Processing 313 3.1 Encapsulation 315 The encapsulation described in this section refers to the 316 functionality performed by the PW termination point depicted in 317 figure 1, unless otherwise indicated. 319 The entire Ethernet frame, without the preamble or FCS, is 320 encapsulated in L2TPv3 and is sent as a single packet by the ingress 321 LCCE. This is done regardless of whether an VLAN tag is present in 322 the Ethernet frame or not. For Ethernet port to port mode, the remote 323 LCCE simply decapsulates the L2TP payload and sends it out on the 324 appropriate interface without modifying the Ethernet header. For 325 Ethernet VLAN to VLAN mode, the remote LCCE MAY rewrite the VLAN tag. 326 As described in section 1, the VLAN tag modification is an NSP 327 function. 329 The Ethernet PW over L2TP is homogeneous with respect to packet 330 encapsulation i.e. both the ends of the PW are either untagged or 331 tagged. The Ethernet PW can still be used to provide heterogeneous 332 services using NSP functionality at the ingress and/or egress LCCE. 333 The definition of such NSP functionality is outside the scope of this 334 document. 336 The maximum length of the Ethernet frame carried as the PWE payload 337 is irrelevant as far as the PWE is concerned. If anything, that value 338 would only be relevant when quantifying the faithfulness of the 339 emulation. 341 3.2 Sequencing 343 Data packet sequencing MAY be enabled for Ethernet PWs. The 344 sequencing mechanisms described in [RFC3931] MUST be used for 345 signaling sequencing support. 347 3.3 MTU Handling 349 With L2TPv3 as the tunneling protocol, the IP packet resulting from 350 the encapsulation is M + N bytes longer than Ethernet frame without 351 the preamble or FCS. Here M is the length of the IP header along with 352 associated options and extension headers, and the value of N depends 353 on the following fields: 355 L2TP Session Header: 357 Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) 358 Session ID - 4 octets 359 Cookie Size - 0, 4 or 8 octets 360 L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) 362 Hence the range for N in octets is: 364 N = 4-16, for L2TPv3 data messages over IP; 365 N = 16-28, for L2TPv3 data messages over UDP; 366 (N does not include the IP header). 368 Fragmentation in the PSN can occur when using Ethernet over L2TP, 369 unless proper configuration and management of MTU sizes are in place 370 between the Customer Edge (CE) router, Provider Edge (PE) router, and 371 across the PSN. This is not specific only to Ethernet over L2TPv3, 372 and the base L2TPv3 specification [RFC3931] provides general 373 recommendations with respect to fragmentation and reassembly in 374 section 4.1.4. "PWE3 Fragmentation and Reassembly" [L2TPFRAG] 375 expounds on this topic further, including a fragmentation and 376 reassembly mechanism within L2TP itself in the event that no other 377 option is available. Implementations MUST follow these guidelines 378 with respect to Fragmentation and Reassembly. 380 4. Applicability Statement 382 The Ethernet PW emulation allows a service provider to offer a "port 383 to port" Ethernet based service across an IP packet switched network 384 (PSN) while the Ethernet VLAN PW emulation allows an "Ethernet VLAN 385 to VLAN" based service across an IP packet switched network (PSN). 387 The Ethernet or Ethernet VLAN PW emulation has the following 388 characteristics in relationship to the respective native service: 390 o Ethernet PW connects two Ethernet ACs while Ethernet VLAN PW 391 connects two Ethernet VLAN ACs, supporting bi-directional 392 transport of variable length Ethernet frames. The ingress LCCE 393 strips the preamble and FCS from the Ethernet frame and transports 394 the frame in its entirety across the PW. This is done regardless 395 of the presence of the VLAN tag in the frame. The egress LCCE 396 receives the Ethernet frame from the PW and regenerates the 397 preamble and FCS before forwarding the frame to the attached Remote 398 System (See Section 3.1). Since FCS is not being transported 399 across either Ethernet or Ethernet VLAN PWs, payload integrity 400 transparency may be lost. To achieve payload integrity 401 transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP 402 or L2TP over UDP/IP, the L2TPv3 session can utilize IPsec as 403 specified in Section 4.1.3 of [RFC3931]. 405 o While architecturally [RFC3985] outside the scope of the L2TPv3 PW 406 itself, if VLAN tags are present, the NSP may rewrite VLAN tags on 407 ingress or egress from the PW (see section 3.1). 409 o The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet 410 frame type across the PW; both ends of the PW must be either tagged 411 or untagged. Heterogeneous frame type support achieved with NSP 412 functionality is outside the scope of this document (See Section 413 3.1). 415 o Ethernet port or Ethernet VLAN status notification is provided 416 using the Circuit Status AVP in SLI message (See Section 2.3.1). 417 Loss of connectivity between LCCEs can be detected by the L2TPv3 418 keep-alive mechanism (see Section 2.3.1 in [RFC3931]). The LCCE 419 can convey these indications back to its attached Remote System. 421 o The maximum frame size that can be supported is limited by the PSN 422 MTU minus the L2TPv3 header size, unless fragmentation and 423 reassembly is used (see Section 3.3 and Section 4.1.4 of 424 [RFC3931]). 426 o The packet switched network may reorder, duplicate, or silently 427 drop packets. Sequencing may be enabled in the Ethernet or 428 Ethernet VLAN PW for some or all packets to detect lost, 429 duplicate, or out-of-order packets on a per-session basis 430 (see Section 3.2). 432 o The faithfulness of an Ethernet or Ethernet VLAN PW may be 433 increased by leveraging Quality of Service features of the LCCEs 434 and the underlying PSN. For example for Ethernet 802.1Q [802.1Q] 435 VLAN transport, the ingress LCCE MAY consider the user priority 436 field (i.e. 802.1P) of the VLAN tag for traffic classification 437 and QoS treatments, such as determining the DS field [RFC2474] of 438 the encapsulating IP header. Similarly, the egress LCCE MAY 439 consider the DS field of the encapsulating IP header when 440 rewriting the user priority field of the VLAN tag or queuing the 441 Ethernet frame before forwarding the frame to the Remote System. 442 The mapping between the user priority field and the IP header DS 443 field as well as the Quality of Service model deployed are 444 application specific and are outside the scope of this document. 446 5. Congestion Control 448 As explained in [RFC3985], the PSN carrying the PW may be subject to 449 congestion, with congestion characteristics depending on PSN type, 450 network architecture, configuration, and loading. During congestion 451 the PSN may exhibit packet loss that will impact the service carried 452 by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or 453 Ethernet VLAN PWs carry a variety of services across the PSN, 454 including but not restricted to TCP/IP, they may or may not behave in 455 a TCP-friendly manner prescribed by [RFC2914] and thus consume more 456 than their fair share. 458 Whenever possible, Ethernet or Ethernet VLAN PWs should be run over 459 traffic-engineered PSNs providing bandwidth allocation and admission 460 control mechanisms. IntServ-enabled domains providing the Guaranteed 461 Service (GS) or DiffServ-enabled domains using EF (expedited 462 forwarding) are examples of traffic-engineered PSNs. Such PSNs will 463 minimize loss and delay while providing some degree of isolation of 464 the Ethernet or Ethernet VLAN PW's effects from neighboring streams. 466 LCCEs SHOULD monitor for congestion (by using explicit congestion 467 notification, or by measuring packet loss) in order to ensure that 468 the service using the Ethernet or Ethernet VLAN PW may be maintained. 469 When severe congestion is detected (for example when enabling 470 Sequencing and detecting that the packet loss is higher than a 471 threshold) the Ethernet or Ethernet VLAN PW SHOULD be halted by 472 tearing down the L2TP session via a CDN message. The PW may be 473 restarted by manual intervention, or by automatic means after an 474 appropriate waiting time. Note that the thresholds and time periods 475 for shutdown and possible automatic recovery need to be carefully 476 configured. This is necessary to avoid loss of service due to 477 temporary congestion, and to prevent oscillation between the 478 congested and halted states. 480 This specification offers no congestion control and is not TCP 481 friendly [TFRC]. Future works for PW congestion control (being 482 studied by the PWE3 Working Group) will provide congestion control 483 for all PW types including Ethernet and Ethernet VLAN PWs. 485 6. Security Considerations 487 Ethernet over L2TPv3 is subject to all of the general security 488 considerations outlined in [RFC3931]. 490 7. IANA Considerations 492 The signaling mechanisms defined in this document rely upon the 493 allocation of following Ethernet Pseudowire Types (see Pseudo Wire 494 Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 495 Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space 496 created as part of publication of [RFC3931]): 498 Pseudowire Types 499 ---------------- 501 0x0004 Ethernet VLAN Pseudowire Type 502 0x0005 Ethernet Pseudowire Type 504 8. Acknowledgements 506 This draft evolves from the draft, "Ethernet Pseudo Wire Emulation 507 Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L. 508 Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron 509 for their contribution. We would also like to thank S. Nanji, the 510 author of the draft, "Ethernet Service for Layer Two Tunneling 511 Protocol", for writing the first Ethernet over L2TP draft. 513 Thanks to Carlos Pignataro for providing a thorough review and 514 helpful input. 516 9. References 518 9.1 Normative References 520 [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 521 Protocol (Version 3)", RFC3931, March 2005. 523 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [L2TPFRAG] A. Malis, M. Townsley, "PWE3 Fragmentation and 527 Reassembly", draft-ietf-pwe3-fragmentation-10.txt 529 9.2 Informative References 531 [RFC3985] S. Bryant, P. Pate, "Pseudo Wire Emulation Edge-to-Edge 532 (PWE3) Architecture", RFC3985, March 2005 534 [RFC2914] S. Floyd, "Congestion Control Principles", BCP 41, 535 RFC 2914, September 2000. 537 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 538 the Differentiated Services Field (DS Field) in the IPv4 539 and IPv6 Headers", RFC2474, December 1998 541 [802.3] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for 542 Information Technology - Telecommuincations and 543 Information Exchange Between Systems - Local and 544 Metropolitan Area Networks", IEEE Std 802.3-2005/Cor 545 1-2006 (Corrigendum to IEEE Std 802.3-2005) 547 [802.1Q] IEEE, "IEEE standard for local and metropolitan area 548 networks virtual bridged local area networks", IEEE 549 Std 802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE 550 Std 802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 551 802.1s-2002) 553 [802.1ad] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local 554 and metropolitan area networks - virtual Bridged Local 555 Area Networks, Amendment 4: Provider Bridges", IEEE 556 Std 802.1ad-2005 (Amendment to IEEE Std 8021Q-2005) 558 [TFRC] M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP 559 Friendly Rate Control (TFRC): Protocol Specification", 560 RFC3448, January 2003 562 10. Author Information 564 Rahul Aggarwal 565 Juniper Networks 566 1194 North Mathilda Avenue 567 Sunnyvale, CA 94089 568 e-mail: rahul@juniper.net 570 W. Mark Townsley 571 Cisco Systems 572 7025 Kit Creek Road 573 PO Box 14987 574 Research Triangle Park, NC 27709 575 e-mail: mark@townsley.net 577 Maria Alice Dos Santos 578 Cisco Systems 579 170 W Tasman Dr 580 San Jose, CA 95134 581 e-mail: mariados@cisco.com 583 Intellectual Property Statement 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org. 607 Disclaimer of Validity 609 This document and the information contained herein are provided on 610 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 611 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 612 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 613 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 614 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Copyright Statement 619 Copyright (C) The Internet Society (2006). 621 This document is subject to the rights, licenses and restrictions 622 contained in BCP 78, and except as set forth therein, the authors 623 retain all their rights. 625 Acknowledgment 627 Funding for the RFC Editor function is currently provided by the 628 Internet Society.