doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4719.txt b/doc/rfc/rfc4719.txt
new file mode 100644
index 0000000..2a434a7
--- /dev/null
+++ b/doc/rfc/rfc4719.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                   R. Aggarwal, Ed.
+Request for Comments: 4719                              Juniper Networks
+Category: Standards Track                               M. Townsley, Ed.
+                                                      M. Dos Santos, Ed.
+                                                           Cisco Systems
+                                                           November 2006
+
+
+                   Transport of Ethernet Frames over
+             Layer 2 Tunneling Protocol Version 3 (L2TPv3)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this 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, Version 3 (L2TPv3).  This includes the
+   transport of Ethernet port-to-port frames as well as the transport of
+   Ethernet VLAN frames.  The mechanism described in this document can
+   be used in the creation of Pseudowires to transport Ethernet frames
+   over an IP network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 1]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Specification of Requirements ..............................2
+      1.2. Abbreviations ..............................................3
+      1.3. L2TPv3 Control Message Types ...............................3
+      1.4. Requirements ...............................................3
+   2. PW Establishment ................................................4
+      2.1. LCCE-LCCE Control Connection Establishment .................4
+      2.2. PW Session Establishment ...................................4
+      2.3. PW Session Monitoring ......................................6
+   3. Packet Processing ...............................................7
+      3.1.  Encapsulation .............................................7
+      3.2.  Sequencing ................................................7
+      3.3.  MTU Handling ..............................................7
+   4. Applicability Statement .........................................8
+   5. Congestion Control .............................................10
+   6. Security Considerations ........................................10
+   7. IANA Considerations ............................................11
+   8. Contributors ...................................................11
+   9. Acknowledgements ...............................................11
+   10. References ....................................................12
+      10.1. Normative References .....................................12
+      10.2. Informative References ...................................12
+
+1.  Introduction
+
+   The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a
+   control protocol and for data encapsulation to set up 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 this document 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 extensions
+   that may or may not necessarily be sanctioned by the IEEE (including
+   such frames as jumbo frames, etc.).  The term "VLAN" in this document
+   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 to be interpreted as described in [RFC2119].
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 2]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+1.2.  Abbreviations
+
+   AC      Attachment Circuit (see [RFC3985])
+   CE      Customer Edge (Typically also the L2TPv3 Remote System)
+   LCCE    L2TP Control Connection Endpoint (see [RFC3931])
+   NSP     Native Service Processing (see [RFC3985])
+   PE      Provider Edge (Typically also the LCCE) (see [RFC3985])
+   PSN     Packet Switched Network (see [RFC3985])
+   PW      Pseudowire (see [RFC3985])
+   PWE3    Pseudowire Emulation Edge to Edge (Working Group)
+
+1.3.  L2TPv3 Control Message Types
+
+   Relevant L2TPv3 control message types (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 message
+   StopCCN 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 message
+
+1.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 within an 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
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 3]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+   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.  Hence, 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, overwriting, 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 L2TP Control Connection has to be set up first between
+   the two LCCEs.  Individual PWs can then be established as L2TP
+   sessions.
+
+2.1.  LCCE-LCCE Control Connection Establishment
+
+   The two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP
+   Control Connection first as described in [RFC3931].  Hence, an
+   Ethernet PW Type must be included in the Pseudowire Capabilities List
+   as defined in [RFC3931].  The type of PW can be either "Ethernet
+   port" or "Ethernet VLAN".  This indicates that the Control Connection
+   can support the establishment of Ethernet PWs.  Note that there are
+   two Ethernet PW Types 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.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].
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 4]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+   Note that an L2TP Outgoing Call is essentially a method of
+   controlling the originating point of 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, OCRP, 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) Pseudowire Type: The type of a Pseudowire can be either "Ethernet
+      port" or "Ethernet VLAN".  Each LCCE signals its Pseudowire type
+      in the Pseudowire Type AVP [RFC3931].  The assigned values for
+      "Ethernet port" and "Ethernet VLAN" Pseudowire types are captured
+      in the "IANA Considerations" of this document.  The Pseudowire
+      Type AVP MUST be present in the ICRQ.
+
+   b) Pseudowire ID: Each PW is associated with a Pseudowire ID.  The
+      two LCCEs of a PW have the same Pseudowire ID for it.  The Remote
+      End Identifier AVP [RFC3931] is used to convey the Pseudowire 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 formats that 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).  An implementation 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.  A
+      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).
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 5]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+2.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.  The Control 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 the Control Connection keep-alive mechanism of L2TPv3,
+   Ethernet PW over L2TP makes use of the Set-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 trigger an SLI message for each PW associated with that Ethernet
+   interface.  This may be one Ethernet port 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, ICRP, and CDN
+   messages that establish and tear 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 reports circuit 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 a 16-bit mask with the two least significant bits
+   defined and the remaining bits reserved for future use.  Reserved
+   bits MUST be set to 0 when 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.
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 6]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+3.  Packet Processing
+
+3.1.  Encapsulation
+
+   The encapsulation described in this section refers to the
+   functionality performed by the PW termination point depicted in
+   Figure 1, unless otherwise indicated.
+
+   The entire Ethernet frame, without the preamble or frame check
+   sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
+   packet by the ingress LCCE.  This is done regardless of whether or
+   not a VLAN tag is present in the Ethernet frame.  For Ethernet port-
+   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 Ethernet VLAN-to-VLAN mode, the remote LCCE MAY
+   rewrite the VLAN tag.  As described in Section 1, the VLAN tag
+   modification is an NSP function.
+
+   The Ethernet PW over L2TP is homogeneous with respect to packet
+   encapsulation, i.e., both ends 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 the PW payload is
+   irrelevant as far as the PW is concerned.  If anything, that value
+   would only be relevant when quantifying the faithfulness of the
+   emulation.
+
+3.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.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:
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 7]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+      L2TP Session Header:
+         Flags, Ver, Res - 4 octets (L2TPv3 over UDP only)
+         Session ID      - 4 octets
+         Cookie Size     - 0, 4, 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 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 in
+   Section 4.1.4.  "PWE3 Fragmentation and Reassembly" [RFC4623]
+   expounds on this 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
+   to fragmentation and reassembly.
+
+4.  Applicability Statement
+
+   The Ethernet PW emulation allows a service provider to offer a
+   "port-to-port"-based Ethernet service across an IP Packet Switched
+   Network (PSN), while the Ethernet VLAN PW emulation allows an "VLAN-
+   to-VLAN"-based Ethernet service across an IP Packet 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 Ethernet port ACs, and Ethernet VLAN PW
+      connects two Ethernet VLAN ACs, which both support bi-directional
+      transport of variable-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 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].
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 8]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+   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 (see Section 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 Section 3.1).
+
+   o  Ethernet port or Ethernet VLAN status notification is provided
+      using the Circuit Status AVP in the SLI message (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.1 of
+      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  The Packet 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 leveraging Quality-of-Service (QoS) features of the
+      LCCEs and the underlying PSN.  For example, for Ethernet 802.1Q
+      [802.1Q] VLAN transport, the ingress LCCE MAY consider the user
+      priority field (i.e., 802.1p) of the VLAN tag for traffic
+      classification and QoS treatments, such as determining the
+      Differentiated 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 the
+      Quality-of-Service model deployed are application specific and are
+      outside the scope of this document.
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                     [Page 9]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+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.  During congestion,
+   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 congestion
+   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 (for example, when enabling
+   sequencing and detecting that the packet loss is higher than a
+   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 manual 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
+   temporary 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].
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                    [Page 10]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+7.  IANA Considerations
+
+   The signaling mechanisms defined in this document rely upon the
+   following Ethernet Pseudowire Types (see Pseudowire Capabilities List
+   as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6
+   of [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
+
+   This RFC evolved from the 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 of "Ethernet Service for Layer Two Tunneling Protocol", for
+   writing the first Ethernet over L2TP document.
+
+   Thanks to Carlos Pignataro for providing a thorough review and
+   helpful input.
+
+
+
+Aggarwal, et al.            Standards Track                    [Page 11]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
+              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4623]  Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
+              Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
+              August 2006.
+
+10.2.  Informative References
+
+   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+              Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41, RFC
+              2914, September 2000.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+              1998.
+
+   [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 Std 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]     Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
+              Friendly Rate Control (TFRC): Protocol Specification", RFC
+              3448, January 2003.
+
+
+
+
+Aggarwal, et al.            Standards Track                    [Page 12]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+Author Information
+
+   Rahul Aggarwal
+   Juniper Networks
+   1194 North Mathilda Avenue
+   Sunnyvale, CA 94089
+
+   EMail: rahul@juniper.net
+
+
+   W. Mark Townsley
+   Cisco Systems
+   7025 Kit Creek Road
+   PO Box 14987
+   Research Triangle Park, NC 27709
+
+   EMail: mark@townsley.net
+
+
+   Maria Alice Dos Santos
+   Cisco Systems
+   170 W Tasman Dr
+   San Jose, CA 95134
+
+   EMail: mariados@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                    [Page 13]
+
+RFC 4719        Transport of Ethernet Frames over L2TPv3   November 2006
+
+
+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 Property
+
+   The 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Aggarwal, et al.            Standards Track                    [Page 14]
+