Network Working GroupRahul Aggarwal Internet DraftR. Aggarwal, Ed. Request for Comments: 4719 Juniper NetworksExpiration Date: February 2007 W. Mark Townsley Maria A.Category: Standards Track M. Townsley, Ed. M. DosSantosSantos, Ed. Cisco SystemsEditors AugustNovember 2006 Transport of Ethernet Frames overL2TPv3 draft-ietf-l2tpext-pwe3-ethernet-09.txtLayer 2 Tunneling Protocol Version 3 (L2TPv3) Status ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The listthis protocol. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.htmlthis memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol (L2TPv3). This includes the transport of Ethernetport to portport-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation ofPseudo WiresPseudowires to transport Ethernet frames over an IP network.Contributors Following is the complete list of contributors to this document. Rahul Aggarwal Juniper Networks Xipeng Xiao Riverstone Networks W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems Cheng-Yin Lee Alcatel Tissa Senevirathne Consultant Mitsuru Higashiyama Anritsu CorporationTable of ContentsStatus of this Memo.......................................... 11.Introduction.............................................. 3 1.1 Abbreviations......................................... 3 1.2Introduction ....................................................2 1.1. Specification of Requirements ..............................2 1.2. Abbreviations ..............................................3 1.3. L2TPv3 Control MessageTypes.......................... 4 1.3 Requirements.......................................... 4Types ...............................3 1.4. Requirements ...............................................3 2. PWEstablishment.......................................... 5 2.1Establishment ................................................4 2.1. LCCE-LCCE Control ConnectionEstablishment............ 5 2.2Establishment .................4 2.2. PW SessionEstablishment.............................. 5 2.3Establishment ...................................4 2.3. PW SessionMonitoring................................. 6Monitoring ......................................6 3. PacketProcessing......................................... 8 3.1 Encapsulation......................................... 8 3.2 Sequencing............................................ 8 3.3Processing ...............................................7 3.1. Encapsulation .............................................7 3.2. Sequencing ................................................7 3.3. MTUHandling.......................................... 8Handling ..............................................7 4. ApplicabilityStatement................................... 9Statement .........................................8 5. CongestionControl........................................ 11Control .............................................10 6. SecurityConsiderations................................... 12Considerations ........................................10 7. IANAConsiderations....................................... 12Considerations ............................................11 8.Acknowledgements.......................................... 12Contributors ...................................................11 9.References................................................ 12 9.1Acknowledgements ...............................................11 10. References ....................................................12 10.1. NormativeReferences.................................. 12 9.2References .....................................12 10.2. InformativeReferences................................ 13 10. Author Information....................................... 13 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].References ...................................12 1. IntroductionL2TPv3The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a control protocol and for data encapsulation to set upPseudo Wires (PW)Pseudowires (PWs) for transporting layer 2 Packet Data Units across an IP network [RFC3931]. This document describes the transport of Ethernet frames over L2TPv3 including the PW establishment and data encapsulation. The term "Ethernet" in thisdraftdocument is used with the intention to include all such protocols that are reasonably similar in their packet format to IEEE 802.3 [802.3], including variants or extensionswhichthat may or may not necessarily be sanctioned by the IEEE (including suchthingsframes as jumbo frames,etc).etc.). The term "VLAN" in thisdraft is used with the intentiondocument is used with the intention to include all virtual LAN tagging protocols such as IEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are toinclude all virtual LAN tagging protocols suchbe interpreted asIEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc. 1.1described in [RFC2119]. 1.2. Abbreviations AC Attachment Circuit(See(see [RFC3985]) CE Customer Edge (Typically also the L2TPv3 Remote System) LCCE L2TP Control Connection Endpoint(See(see [RFC3931]) NSP Native Service Processing(See(see [RFC3985]) PE Provider Edge (Typically also the LCCE)(See(see [RFC3985]) PSN Packet Switched Network(See(see [RFC3985]) PWPseudo-Wire (SeePseudowire (see [RFC3985]) PWE3Pseudo-WirePseudowire Emulation Edge to Edge (Working Group)1.21.3. L2TPv3 Control Message Types Relevant L2TPv3 control message types(See(see [RFC3931]) are listed for reference. SCCRQ L2TPv3 Start-Control-Connection-Request control message SCCRP L2TPv3 Start-Control-Connection-Reply control message SCCCN L2TPv3 Start-Control-Connection-Connected control messageSTOPCCNStopCCN L2TPv3 Stop-Control-Connection-Notification control message ICRQ L2TPv3 Incoming-Call-Request control message ICRP L2TPv3 Incoming-Call-Reply control message ICCN L2TPv3 Incoming-Call-Connected control message OCRQ L2TPv3 Outgoing-Call-Request control message OCRP L2TPv3 Outgoing-Call-Reply control message OCCN L2TPv3 Outgoing-Call-Connected control message CDN L2TPv3 Call-Disconnect-Notify control message SLI L2TPv3 Set-Link-Info control message1.31.4. Requirements An Ethernet PW emulates a single Ethernet link between exactly two endpoints. The following figure depicts the PW termination relative to the NSP and PSN tunnel withinaan LCCE [RFC3985]. The Ethernet interface may be connected to one or more Remote Systems (an L2TPv3 Remote System is referred to as Customer Edge (CE) in this and associated PWE3 documents). The LCCE may or may not be a PE. +---------------------------------------+ | LCCE | +-+ +-----+ +------+ +------+ +-+ |P| | | |PW ter| | PSN | |P| Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN Interface |y| | | |on | | | |y| +-+ +-----+ +------+ +------+ +-+ | | +---------------------------------------+ Figure 1: PW termination The PW termination point receives untagged (also referred to as 'raw') or tagged Ethernet frames and delivers them unaltered to the PW termination point on the remote LCCE.HenceHence, it can provide untagged or tagged Ethernet link emulation service. The "NSP" function includes packet processing needed to translate the Ethernet frames that arrive at the CE-LCCE interface to/from the Ethernet frames that are applied to the PW termination point. Such functions may include stripping,overwritingoverwriting, or adding VLAN tags. The NSP functionality can be used in conjunction with local provisioning to provide heterogeneous services where the CE-LCCE encapsulations at the two ends may be different. The physical layer between the CE and LCCE, and any adaptation (NSP) functions between it and the PW termination, are outside of the scope of PWE3 and are not defined here. 2. PW Establishment With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3 sessions. An L2TPcontrol connectionControl Connection has to be set up first between the two LCCEs. Individual PWs can then be established as L2TP sessions.2.12.1. LCCE-LCCE Control Connection Establishment The two LCCEs that wish to set up Ethernet PWs MUST establishaan L2TPcontrol connectionControl Connection first as described in [RFC3931].HenceHence, an Ethernet PWtypeType must be included in thePseudo WirePseudowire Capabilities List as defined in [RFC3931]. The type of PW can be either "Ethernet port" or "Ethernet VLAN". This indicates that thecontrol connectionControl Connection can support the establishment of Ethernet PWs. Note that there are two Ethernet PWtypesTypes required. For connecting an Ethernet port to another Ethernet port, the PW Type MUST be "Ethernet port"; for connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type MUST be "Ethernet VLAN".2.22.2. PW Session Establishment The provisioning of an Ethernet port or Ethernet VLAN and its association with a PW triggers the establishment of an L2TP session via the standard Incoming Call three-way handshake described in Section 3.4.1 of [RFC3931]. Note that an L2TP Outgoing Call is essentially a method of controlling the originating point ofan SVC,a Switched Virtual Circuit (SVC), allowing it to be established from any reachable L2TP-enabled device able to perform outgoing calls. The Outgoing Call model and its corresponding OCRQ,OCRPOCRP, and OCCN control messages are mainly used within the dial arena with L2TPv2 today and has not been found applicable for PW applications yet. The following are the signaling elements needed for the Ethernet PW establishment: a)Pseudo WirePseudowire Type: The type of aPseudo WirePseudowire can be either "Ethernet port" or "Ethernet VLAN". Each LCCE signals itsPseudo WirePseudowire type in the Pseudowire Type AVP [RFC3931]. The assigned values for "Ethernet port" and "Ethernet VLAN"Pseudo WirePseudowire types are captured in the "IANA Considerations" of this document. The Pseudowire Type AVP MUST be present in the ICRQ. b)Pseudo WirePseudowire ID: Each PW is associated with aPseudo WirePseudowire ID. The two LCCEs of a PW have the samePseudo WirePseudowire ID for it. The Remote End Identifier AVP [RFC3931] is used to convey thePseudo WirePseudowire ID. The Remote End Identifier AVP MUST be present in the ICRQ in order for the remote LCCE to determine the PW to associate the L2TP session with. An implementation MUST support a Remote End Identifier of four octets known to both LCCEs either by manual configuration or some other means. Additional Remote End Identifier formatswhichthat MAY be supported are outside the scope of this document. c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP to indicate the circuit status of the Ethernet port or Ethernet VLAN. For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the circuit status is for a new circuit (refer to N bit in Section 2.3.3). AnImplementationimplementation MAY send an ICRQ or ICRP before an Ethernet interface is ACTIVE, as long as the Circuit Status AVP (refer to A bit in Section 2.3.3) in the ICRQ or ICRP reflects the correct status of the Ethernet port or Ethernet VLAN link.SubsequentA subsequent circuit status change of the Ethernet port or Ethernet VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI control messages. For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP MUST indicate that the circuit status is for an existing circuit (refer to N bit in Section 2.3.3) and reflect the current status of the link (refer to A bit in Section 2.3.3).2.32.3. PW Session Monitoring 2.3.1. Control Connection Keep-alive The working status of a PW is reflected by the state of the L2TPv3 session. If the corresponding L2TPv3 session is down, the PW associated with it MUST be shut down. Thecontrol connectionControl Connection keep- alive mechanism of L2TPv3 can serve as a link status monitoring mechanism for the set of PWs associated with a Control Connection. 2.3.2. SLI Message In addition to thecontrol connectionControl Connection keep-alive mechanism of L2TPv3, Ethernet PW over L2TP makes use of theSet Link InfoSet-Link-Info (SLI) control message defined in [RFC3931]. The SLI message is used to signal Ethernet link status notifications between LCCEs. This can be useful to indicate Ethernet interface state changes without bringing down the L2TP session. Note that change in the Ethernet interface state will triggeraan SLI message for each PW associated with that Ethernet interface. This may be one EthernetPortport PW or more than one Ethernet VLAN PW. The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exception to this is the initial ICRQ,ICRPICRP, and CDN messageswhichthat establish andteardowntear down the L2TP session itself. The SLI message may be sent from either LCCE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup). 2.3.3. Use of Circuit Status AVP for Ethernet Ethernet PW reportsCircuit Statuscircuit status with the Circuit Status AVP defined in [RFC3931]. For reference, this AVP is shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Value is a16 bit16-bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 whensending,sending and ignored upon receipt. The A (Active) bit indicates whether the Ethernet interface is ACTIVE (1) or INACTIVE (0). The N (New) bit indicates whether the circuit status is for a new (1) Ethernet circuit or an existing (0) Ethernet circuit. 3. Packet Processing3.13.1. Encapsulation The encapsulation described in this section refers to the functionality performed by the PW termination point depicted infigureFigure 1, unless otherwise indicated. The entire Ethernet frame, without the preamble orFCS,frame check sequence (FCS), is encapsulated in L2TPv3 and is sent as a single packet by the ingress LCCE. This is done regardless of whetheranor not a VLAN tag is present in the Ethernetframe or not.frame. For Ethernetport to portport- to-port mode, the remote LCCE simply decapsulates the L2TP payload and sends it out on the appropriate interface without modifying the Ethernet header. For EthernetVLAN to VLANVLAN-to-VLAN mode, the remote LCCE MAY rewrite the VLAN tag. As described insectionSection 1, the VLAN tag modification is an NSP function. The Ethernet PW over L2TP is homogeneous with respect to packetencapsulation i.e.encapsulation, i.e., boththeends of the PW are either untagged or tagged. The Ethernet PW can still be used to provide heterogeneous services using NSP functionality at the ingress and/or egress LCCE. The definition of such NSP functionality is outside the scope of this document. The maximum length of the Ethernet frame carried as thePWEPW payload is irrelevant as far as thePWEPW is concerned. If anything, that value would only be relevant when quantifying the faithfulness of the emulation.3.23.2. Sequencing Data packet sequencing MAY be enabled for Ethernet PWs. The sequencing mechanisms described in [RFC3931] MUST be used for signaling sequencing support.3.33.3. MTU Handling With L2TPv3 as the tunneling protocol, the IP packet resulting from the encapsulation is M + N bytes longer than the Ethernet frame without the preamble or FCS. Here M is the length of the IP header along with associated options and extension headers, and the value of N depends on the following fields: L2TP Session Header: Flags, Ver, Res - 4 octets (L2TPv3 over UDP only) Session ID - 4 octets Cookie Size - 0,44, or 8 octets L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing) Hence the range for N in octets is: N = 4-16, for L2TPv3 data messages over IP; N = 16-28, for L2TPv3 data messages over UDP; (N does not include the IP header). Fragmentation in the PSN can occur when using Ethernet over L2TP, unless proper configuration and management of MTU sizes are in place between the Customer Edge (CE)router,router and Provider Edge (PE) router, and across the PSN. This is not specific only to Ethernet over L2TPv3, and the base L2TPv3 specification [RFC3931] provides general recommendations with respect to fragmentation and reassembly insectionSection 4.1.4. "PWE3 Fragmentation and Reassembly"[L2TPFRAG][RFC4623] expounds on thistopic further,topic, including a fragmentation and reassembly mechanism within L2TP itself in the event that no other option is available. Implementations MUST follow these guidelines with respect toFragmentationfragmentation andReassembly.reassembly. 4. Applicability Statement The Ethernet PW emulation allows a service provider to offer a"port to port""port-to-port"-based Ethernetbasedservice across an IPpacket switched network (PSN)Packet Switched Network (PSN), while the Ethernet VLAN PW emulation allows an "EthernetVLAN to VLAN" basedVLAN-to-VLAN"-based Ethernet service across an IPpacket switched networkPacket Switched Network (PSN). The Ethernet or Ethernet VLAN PW emulation has the following characteristics in relationship to the respective native service: o Ethernet PW connects two EthernetACs whileport ACs, and Ethernet VLAN PW connects two Ethernet VLAN ACs,supportingwhich both support bi-directional transport ofvariable lengthvariable-length Ethernet frames. The ingress LCCE strips the preamble and FCS from the Ethernet frame and transports the frame in its entirety across the PW. This is done regardless of the presence of the VLAN tag in the frame. The egress LCCE receives the Ethernet frame from the PW and regenerates the preamble and FCS before forwarding the frame to the attached Remote System(See(see Section 3.1). Since FCS is not being transported across either Ethernet or Ethernet VLAN PWs, payload integrity transparency may be lost. To achieve payload integrity transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP or L2TP over UDP/IP, the L2TPv3 session can utilize IPsec as specified in Section 4.1.3 of [RFC3931]. o While architecturally [RFC3985] outside the scope of the L2TPv3 PW itself, if VLAN tags are present, the NSP may rewrite VLAN tags on ingress or egress from the PW (seesectionSection 3.1). o The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet frame type across the PW; both ends of the PW must be either tagged or untagged. Heterogeneous frame type support achieved with NSP functionality is outside the scope of this document(See(see Section 3.1). o Ethernet port or Ethernet VLAN status notification is provided using the Circuit Status AVP in the SLI message(See Section 2.3.1).(see Sections 2.3.2 and 2.3.3). Loss of connectivity between LCCEs can be detected by the L2TPv3 keep-alive mechanism (see Section 2.3.1inof this document and Section 4.4 of [RFC3931]). The LCCE can convey these indications back to its attached Remote System. o The maximum frame size that can be supported is limited by the PSN MTU minus the L2TPv3 header size, unless fragmentation and reassembly is used (see Section 3.3 of this document and Section 4.1.4 of [RFC3931]). o Thepacket switched networkPacket Switched Network may reorder, duplicate, or silently drop packets. Sequencing may be enabled in the Ethernet or Ethernet VLAN PW for some or all packets to detect lost, duplicate, or out-of-order packets on a per-session basis (see Section 3.2). o The faithfulness of an Ethernet or Ethernet VLAN PW may be increased by leveragingQuality of ServiceQuality-of-Service (QoS) features of the LCCEs and the underlying PSN. Forexampleexample, for Ethernet 802.1Q [802.1Q] VLAN transport, the ingress LCCE MAY consider the user priority field(i.e. 802.1P)(i.e., 802.1p) of the VLAN tag for traffic classification and QoS treatments, such as determining theDSDifferentiated Services (DS) field [RFC2474] of the encapsulating IP header. Similarly, the egress LCCE MAY consider the DS field of the encapsulating IP header when rewriting the user priority field of the VLAN tag or queuing the Ethernet frame before forwarding the frame to the Remote System. The mapping between the user priority field and the IP header DS field as well as theQuality of ServiceQuality-of-Service model deployed are application specific and are outside the scope of this document. 5. Congestion Control As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, with congestion characteristics depending on PSN type, network architecture, configuration, and loading. Duringcongestioncongestion, the PSN may exhibit packet loss that will impact the service carried by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or Ethernet VLAN PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914] and thus consume more than their fair share. Whenever possible, Ethernet or Ethernet VLAN PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the Ethernet or Ethernet VLAN PW's effects from neighboring streams. LCCEs SHOULD monitor for congestion (by using explicit congestionnotification,notification or by measuring packet loss) in order to ensure that the service using the Ethernet or Ethernet VLAN PW may be maintained. When severe congestion is detected (forexampleexample, when enablingSequencingsequencing and detecting that the packet loss is higher than athreshold)threshold), the Ethernet or Ethernet VLAN PW SHOULD be halted by tearing down the L2TP session via a CDN message. The PW may be restarted by manualintervention,intervention or by automatic means after an appropriate waiting time. Note that the thresholds and time periods for shutdown and possible automatic recovery need to be carefully configured. This is necessary to avoid loss of service due to temporarycongestion,congestion and to prevent oscillation between the congested and halted states. This specification offers no congestion control and is not TCP friendly [TFRC]. Future works for PW congestion control (being studied by the PWE3 Working Group) will provide congestion control for all PW types including Ethernet and Ethernet VLAN PWs. 6. Security Considerations Ethernet over L2TPv3 is subject to all of the general security considerations outlined in [RFC3931]. 7. IANA Considerations The signaling mechanisms defined in this document rely upon theallocation offollowing Ethernet Pseudowire Types (seePseudo WirePseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of[RFC3931])[RFC3931]), which were allocated by the IANA (number space created as part of publication of [RFC3931]): Pseudowire Types ---------------- 0x0004 Ethernet VLAN Pseudowire Type 0x0005 Ethernet Pseudowire Type 8. Contributors The following is the complete list of contributors to this document. Rahul Aggarwal Juniper Networks Xipeng Xiao Riverstone Networks W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems Cheng-Yin Lee Alcatel Tissa Senevirathne Consultant Mitsuru Higashiyama Anritsu Corporation 9. Acknowledgements Thisdraft evolvesRFC evolved from thedraft,document, "Ethernet Pseudo Wire Emulation Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L. Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron for their contribution. We would also like to thank S. Nanji, the author ofthe draft,"Ethernet Service for Layer Two Tunneling Protocol", for writing the first Ethernet over L2TPdraft.document. Thanks to Carlos Pignataro for providing a thorough review and helpful input.9.10. References9.110.1. Normative References [RFC3931]J.Lau,M.J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol(Version 3)", RFC3931,- Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC2119]S.Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[L2TPFRAG] A.[RFC4623] Malis, A. and M. Townsley,"PWE3"Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly",draft-ietf-pwe3-fragmentation-10.txt 9.2RFC 4623, August 2006. 10.2. Informative References [RFC3985]S.Bryant, S. and P. Pate, "Pseudo Wire EmulationEdge-to-EdgeEdge-to- Edge (PWE3) Architecture",RFC3985,RFC 3985, March20052005. [RFC2914]S.Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC2474]K.Nichols,S.K., Blake,F.S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",RFC2474,RFC 2474, December19981998. [802.3] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for Information Technology - Telecommuincations and Information Exchange Between Systems - Local and Metropolitan Area Networks", IEEE Std 802.3-2005/Cor 1-2006 (Corrigendum to IEEE Std 802.3-2005) [802.1Q] IEEE, "IEEE standard for local and metropolitan area networks virtual bridged local area networks", IEEE Std 802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE Std 802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std802.1s-2002)802.1s- 2002) [802.1ad] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE Std 802.1ad-2005 (Amendment to IEEE Std 8021Q-2005) [TFRC]M.Handley,S.M., Floyd,J.S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification",RFC3448,RFC 3448, January2003 10.2003. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089e-mail:EMail: rahul@juniper.net W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709e-mail:EMail: mark@townsley.net Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134e-mail:EMail: mariados@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyStatementThe IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. AcknowledgmentAcknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.