doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc4905.txt b/doc/rfc/rfc4905.txt
new file mode 100644
index 0000000..86d5456
--- /dev/null
+++ b/doc/rfc/rfc4905.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                    L. Martini, Ed.
+Request for Comments: 4905                                 E. Rosen, Ed.
+Category: Historic                                   Cisco Systems, Inc.
+                                                        N. El-Aawar, Ed.
+                                             Level 3 Communications, LLC
+                                                               June 2007
+
+                Encapsulation Methods for Transport of
+                   Layer 2 Frames over MPLS Networks
+
+Status of This Memo
+
+   This memo defines a Historic Document for the Internet community.  It
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document describes methods for encapsulating the Protocol Data
+   Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous
+   Transfer Mode (ATM), or Ethernet for transport across an MPLS
+   network.  This document describes the so-called "draft-martini"
+   protocol, which has since been superseded by the Pseudowire Emulation
+   Edge to Edge Working Group specifications described in RFC 4447 and
+   related documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 1]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Specification of Requirements ...................................3
+   3. Special Note ....................................................4
+   4. General Encapsulation Method ....................................4
+      4.1. The Control Word ...........................................4
+           4.1.1. Setting the Sequence Number .........................5
+           4.1.2. Processing the Sequence Number ......................6
+      4.2. MTU Requirements ...........................................6
+   5. Protocol-Specific Details .......................................7
+      5.1. Frame Relay ................................................7
+      5.2. ATM ........................................................8
+           5.2.1. ATM AAL5 CPCS-SDU Mode ..............................9
+           5.2.2. ATM Cell Mode ......................................10
+           5.2.3. OAM Cell Support ...................................12
+           5.2.4. CLP bit to Quality of Service Mapping ..............12
+      5.3. Ethernet VLAN .............................................12
+      5.4. Ethernet ..................................................12
+      5.5. High-Level Data Link Control (HDLC) .......................13
+      5.6. PPP .......................................................13
+   6. Using an MPLS Label as the Demultiplexer Field .................13
+      6.1. MPLS Shim EXP Bit Values ..................................14
+      6.2. MPLS Shim S Bit Value .....................................14
+      6.3. MPLS Shim TTL Values ......................................14
+   7. Security Considerations ........................................14
+   8. Normative References ...........................................14
+   9. Informative References .........................................16
+   10. Co-Authors ....................................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 2]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+1.  Introduction
+
+   In an MPLS network, it is possible to use control protocols such as
+   those specified in [RFC4906] to set up "emulated virtual circuits"
+   that carry the Protocol Data Units of layer 2 protocols across the
+   network.  A number of these emulated virtual circuits (VCs) may be
+   carried in a single tunnel.  This requires, of course, that the layer
+   2 PDUs be encapsulated.  We can distinguish three layers of this
+   encapsulation:
+
+      - the "tunnel header", which contains the information needed to
+        transport the PDU across the MPLS network; this header belongs
+        to the tunneling protocol, e.g., MPLS, Generic Routing
+        Encapsulation (GRE), and Layer 2 Tunneling Protocol (L2TP).
+
+      - the "demultiplexer field", which is used to distinguish
+        individual emulated virtual circuits within a single tunnel;
+        this field must be understood by the tunneling protocol as well;
+        it may be, e.g., an MPLS label or a GRE key field.
+
+      - the "emulated VC encapsulation", which contains the information
+        about the enclosed layer 2 PDU that is necessary in order to
+        properly emulate the corresponding layer 2 protocol.
+
+   This document specifies the emulated VC encapsulation for a number of
+   layer 2 protocols.  Although different layer 2 protocols require
+   different information to be carried in this encapsulation, an attempt
+   has been made to make the encapsulation as common as possible for all
+   layer 2 protocols.
+
+   This document also specifies the way in which the demultiplexer field
+   is added to the emulated VC encapsulation when an MPLS label is used
+   as the demultiplexer field.
+
+   Quality of service (QoS)-related issues are not discussed in this
+   document.
+
+   For the purpose of this document, R1 will be defined as the ingress
+   router, and R2 as the egress router.  A layer 2 PDU will be received
+   at R1, encapsulated at R1, transported, decapsulated at R2, and
+   transmitted out of R2.
+
+2.  Specification of Requirements
+
+   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].
+
+
+
+
+Martini, et al.                 Historic                        [Page 3]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+3.  Special Note
+
+   This document describes the so called "draft-martini" protocol, which
+   is used in many deployed implementations.  This document and its
+   contents have since been superseded by the Pseudowire Emulation Edge
+   to Edge Working Group specifications: [RFC4447], [RFC4385],
+   [RFC4448], [RFC4717], [RFC4618], [RFC4619], [RFC4553], [RFC4842], and
+   related documents.  This document serves as documentation of current
+   implementations, and MUST NOT be used for new implementations.  The
+   PWE3 Label Distribution Protocol control protocol document [RFC4447],
+   which is backward compatible with this document, MUST be used for all
+   new implementations of this protocol.
+
+4.  General Encapsulation Method
+
+   In most cases, it is not necessary to transport the layer 2
+   encapsulation across the network; rather, the layer 2 header can be
+   stripped at R1 and reproduced at R2.  This is done using information
+   carried in the control word (see below), as well as information that
+   may already have been signaled from R1 to R2.
+
+4.1.  The Control Word
+
+   There are three requirements that may need to be satisfied when
+   transporting layer 2 protocols over an MPLS backbone:
+
+     -i. Sequentiality may need to be preserved.
+
+    -ii. Small packets may need to be padded in order to be transmitted
+         on a medium where the minimum transport unit is larger than the
+         actual packet size.
+
+   -iii. Control bits carried in the header of the layer 2 frame may
+         need to be transported.
+
+   The control word defined here addresses all three of these
+   requirements.  For some protocols, this word is REQUIRED, and for
+   others OPTIONAL.  For protocols where the control word is OPTIONAL,
+   implementations MUST support sending no control word, and MAY support
+   sending a control word.
+
+   In all cases, the egress router must be aware of whether the ingress
+   router will send a control word over a specific virtual circuit.
+   This may be achieved by configuration of the routers or by signaling,
+   for example, as defined in [RFC4906].
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 4]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   The control word is defined as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Rsvd  | Flags |0 0|   Length  |     Sequence Number           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   In the above diagram, the first 4 bits are reserved for future use.
+   They MUST be set to 0 when transmitting, and MUST be ignored upon
+   receipt.
+
+   The next 4 bits provide space for carrying protocol-specific flags.
+   These are defined in the protocol-specific details below.
+
+   The next 2 bits MUST be set to 0 when transmitting.
+
+   The next 6 bits provide a length field, which is used as follows: If
+   the packet's length (defined as the length of the layer 2 payload
+   plus the length of the control word) is less than 64 bytes, the
+   length field MUST be set to the packet's length.  Otherwise, the
+   length field MUST be set to 0.  The value of the length field, if
+   non-zero, can be used to remove any padding.  When the packet reaches
+   the service provider's egress router, it may be desirable to remove
+   the padding before forwarding the packet.
+
+   The next 16 bits provide a sequence number that can be used to
+   guarantee ordered packet delivery.  The processing of the sequence
+   number field is OPTIONAL.
+
+   The sequence number space is a 16-bit, unsigned circular space.  The
+   sequence number value 0 is used to indicate an unsequenced packet.
+
+4.1.1.  Setting the Sequence Number
+
+   For a given emulated VC, and a pair of routers R1 and R2, if R1
+   supports packet sequencing, then the following procedures should be
+   used:
+
+      - The initial packet transmitted on the emulated VC MUST use
+        sequence number 1.
+
+      - Subsequent packets MUST increment the sequence number by 1 for
+        each packet.
+
+      - When the transmit sequence number reaches the maximum 16 bit
+        value (65535), the sequence number MUST wrap to 1.
+
+
+
+
+Martini, et al.                 Historic                        [Page 5]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   If the transmitting router R1 does not support sequence number
+   processing, then the sequence number field in the control word MUST
+   be set to 0.
+
+4.1.2.  Processing the Sequence Number
+
+   If a router R2 supports receive sequence number processing, then the
+   following procedures should be used:
+
+   When an emulated VC is initially set up, the "expected sequence
+   number" associated with it MUST be initialized to 1.
+
+   When a packet is received on that emulated VC, the sequence number
+   should be processed as follows:
+
+      - If the sequence number on the packet is 0, then the packet
+        passes the sequence number check.
+
+      - Else if the packet sequence number >= the expected sequence
+        number and the packet sequence number - the expected sequence
+        number < 32768, then the packet is in order.
+
+      - Else if the packet sequence number < the expected sequence
+        number and the expected sequence number - the packet sequence
+        number >= 32768, then the packet is in order.
+
+      - Otherwise, the packet is out of order.
+
+   If a packet passes the sequence number check or is in order, then it
+   can be delivered immediately.  If the packet is in order, then the
+   expected sequence number should be set using the algorithm:
+
+   expected_sequence_number := packet_sequence_number + 1 mod 2**16
+   if (expected_sequence_number = 0) then expected_sequence_number := 1;
+
+   Packets that are received out of order MAY be dropped or reordered at
+   the discretion of the receiver.
+
+   If a router R2 does not support receive sequence number processing,
+   then the sequence number field MAY be ignored.
+
+4.2.  MTU Requirements
+
+   The network MUST be configured with an MTU that is sufficient to
+   transport the largest encapsulation frames.  If MPLS is used as the
+   tunneling protocol, for example, this is likely to be 12 or more
+   bytes greater than the largest frame size.  Other tunneling protocols
+   may have longer headers and require larger MTUs.  If the ingress
+
+
+
+Martini, et al.                 Historic                        [Page 6]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   router determines that an encapsulated layer 2 PDU exceeds the MTU of
+   the tunnel through which it must be sent, the PDU MUST be dropped.
+   If an egress router receives an encapsulated layer 2 PDU whose
+   payload length (i.e., the length of the PDU itself without any of the
+   encapsulation headers) exceeds the MTU of the destination layer 2
+   interface, the PDU MUST be dropped.
+
+5.  Protocol-Specific Details
+
+5.1.  Frame Relay
+
+   A Frame Relay PDU is transported without the Frame Relay header or
+   the Frame Check Sequence (FCS).  The control word is REQUIRED;
+   however, its use is optional, although desirable.  Use of the control
+   word means that the ingress and egress Label Switching Routers (LSRs)
+   follow the procedures below.  If an ingress LSR chooses not to use
+   the control word, it MUST set the flags in the control word to 0; if
+   an egress LSR chooses to ignore the control word, it MUST set the
+   Frame Relay control bits to 0.
+
+   The BECN (Backward Explicit Congestion Notification), FECN (Forward
+   Explicit Congestion Notification), DE (Discard Eligibility), and C/R
+   (Command/Response) bits are carried across the network in the control
+   word.  The edge routers that implement this document MAY, when either
+   adding or removing the encapsulation described herein, change the
+   BECN and/or FECN bits from 0 to 1 in order to reflect congestion in
+   the network that is known to the edge routers, and the D/E bit from 0
+   to 1 to reflect marking from edge policing of the Frame Relay
+   Committed Information Rate.  The BECN, FECN, and D/E bits SHOULD NOT
+   be changed from 1 to 0.
+
+   The following is an example of a Frame Relay packet:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Rsvd  |B|F|D|C|    Length     |        Sequence Number        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Frame Relay PDU                          |
+   |                             "                                 |
+   |                             "                                 |
+   |                             "                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 7]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+      * B ( BECN ) Bit
+
+        The ingress router, R1, SHOULD copy the BECN field from the
+        incoming Frame Relay header into this field.  The egress router,
+        R2, MUST generate a new BECN field based on the value of the B
+        bit.
+
+      * F ( FECN ) Bit
+
+        The ingress router, R1, SHOULD copy the FECN field from the
+        incoming Frame Relay header into this field.  The egress router,
+        R2, MUST generate a new FECN field based on the value of the F
+        bit.
+
+      * D ( DE ) Bit
+
+        The ingress router, R1, SHOULD copy the DE field from the
+        incoming Frame Relay header into this field.  The egress router,
+        R2, MUST generate a new DE field based on the value of the D
+        bit.
+
+        If the tunneling protocol provides a field that can be set to
+        specify a Quality of Service, the ingress router, R1, MAY
+        consider the DE bit of the Frame Relay header when determining
+        the value of that field.  The egress router MAY then consider
+        the value of this field when queuing the layer 2 PDU for egress.
+        Note however that frames from the same VC MUST NOT be reordered.
+
+      * C ( C/R ) Bit
+
+        The ingress router, R1, SHOULD copy the C/R bit from the
+        received Frame Relay PDU to the C bit of the control word.  The
+        egress router, R2, MUST copy the C bit into the output frame.
+
+5.2.  ATM
+
+   Two encapsulations are supported for ATM transport: one for ATM
+   Adaption Layer 5 (AAL5) and another for ATM cells.
+
+   The AAL5 Common Part Convergence Sublayer - Service Data Unit
+   (CPCS-SDU) encapsulation consists of the REQUIRED control word and
+   the AAL5 CPCS-SDU.  The ATM cell encapsulation consists of an
+   OPTIONAL control word, a 4-byte ATM cell header, and the ATM cell
+   payload.
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 8]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+5.2.1.  ATM AAL5 CPCS-SDU Mode
+
+   In ATM AAL5 mode, the ingress router is required to reassemble AAL5
+   CPCS-SDUs from the incoming VC and transport each CPCS-SDU as a
+   single packet.  No AAL5 trailer is transported.  The control word is
+   REQUIRED; its use, however, is optional, although desirable.  Use of
+   the control word means that the ingress and egress LSRs follow the
+   procedures below.  If an ingress LSR chooses not to use the control
+   word, it MUST set the flags in the control word to 0; if an egress
+   LSR chooses to ignore the control word, it MUST set the ATM control
+   bits to 0.
+
+   The EFCI (Explicit Forward Congestion Indication) and CLP (Cell Loss
+   Priority) bits are carried across the network in the control word.
+   The edge routers that implement this document MAY, when either adding
+   or removing the encapsulation described herein, change the EFCI bit
+   from 0 to 1 in order to reflect congestion in the network that is
+   known to the edge routers, and the CLP bit from 0 to 1 to reflect
+   marking from edge policing of the ATM Sustained Cell Rate.  The EFCI
+   and CLP bits MUST NOT be changed from 1 to 0.
+
+   The AAL5 CPCS-SDU is prepended by the following header:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Rsvd  |T|E|L|C|    Length     |        Sequence Number        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     ATM  AAL5 CPCS-SDU                        |
+   |                             "                                 |
+   |                             "                                 |
+   |                             "                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      * T (transport type) bit
+
+        Bit (T) of the control word indicates whether the packet
+        contains an ATM cell or an AAL5 CPCS-SDU.  If set, the packet
+        contains an ATM cell, encapsulated according to the ATM cell
+        mode section below; otherwise, it contains an AAL5 CPCS-SDU.
+        The ability to transport an ATM cell in the AAL5 mode is
+        intended to provide a means of enabling Operations and
+        Management (OAM) functionality over the AAL5 VC.
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 9]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+      * E ( EFCI ) Bit
+
+        The ingress router, R1, SHOULD set this bit to 1 if the EFCI bit
+        of the final cell of those that transported the AAL5 CPCS-SDU is
+        set to 1, or if the EFCI bit of the single ATM cell to be
+        transported in the packet is set to 1.  Otherwise, this bit
+        SHOULD be set to 0.  The egress router, R2, SHOULD set the EFCI
+        bit of all cells that transport the AAL5 CPCS-SDU to the value
+        contained in this field.
+
+      * L ( CLP ) Bit
+
+        The ingress router, R1, SHOULD set this bit to 1 if the CLP bit
+        of any of the ATM cells that transported the AAL5 CPCS-SDU is
+        set to 1, or if the CLP bit of the single ATM cell to be
+        transported in the packet is set to 1.  Otherwise, this bit
+        SHOULD be set to 0.  The egress router, R2, SHOULD set the CLP
+        bit of all cells that transport the AAL5 CPCS-SDU to the value
+        contained in this field.
+
+      * C ( Command / Response Field ) Bit
+
+        When FRF.8.1 Frame Relay / ATM PVC Service Interworking
+        [FRF.8.1] traffic is being transported, the CPCS-UU Least
+        Significant Bit (LSB) of the AAL5 CPCS-SDU may contain the Frame
+        Relay C/R bit.  The ingress router, R1, SHOULD copy this bit to
+        the C bit of the control word.  The egress router, R2, SHOULD
+        copy the C bit to the CPCS-UU Least Significant Bit (LSB) of the
+        AAL5 CPCS PDU.
+
+5.2.2.  ATM Cell Mode
+
+   In this encapsulation mode, ATM cells are transported individually
+   without a Segmentation and Reassembly (SAR) process.  The ATM cell
+   encapsulation consists of an OPTIONAL control word, and one or more
+   ATM cells - each consisting of a 4-byte ATM cell header and the 48-
+   byte ATM cell payload.  This ATM cell header is defined in the FAST
+   encapsulation [FAST] section 3.1.1, but without the trailer byte.
+   The length of each frame, without the encapsulation headers, is a
+   multiple of 52 bytes long.  The maximum number of ATM cells that can
+   be fitted in a frame, in this fashion, is limited only by the network
+   MTU and by the ability of the egress router to process them.  The
+   ingress router MUST NOT send more cells than the egress router is
+   willing to receive.  The number of cells that the egress router is
+   willing to receive may either be configured in the ingress router or
+   may be signaled, for example, using the methods described in
+   [RFC4906].  The number of cells encapsulated in a particular frame
+   can be inferred by the frame length.  The control word is OPTIONAL.
+
+
+
+Martini, et al.                 Historic                       [Page 10]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   If the control word is used, then the flag bits in the control word
+   are not used, and MUST be set to 0 when transmitting, and MUST be
+   ignored upon receipt.
+
+   The EFCI and CLP bits are carried across the network in the ATM cell
+   header.  The edge routers that implement this document MAY, when
+   either adding or removing the encapsulation described herein, change
+   the EFCI bit from 0 to 1 in order to reflect congestion in the
+   network that is known to the edge router, and the CLP bit from 0 to 1
+   to reflect marking from edge policing of the ATM Sustained Cell Rate.
+   The EFCI and CLP bits SHOULD NOT be changed from 1 to 0.
+
+   This diagram illustrates an encapsulation of two ATM cells:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Control word ( Optional )                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          VPI          |              VCI              | PTI |C|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  ATM Payload ( 48 bytes )                     |
+   |                          "                                    |
+   |                          "                                    |
+   |                          "                                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          VPI          |              VCI              | PTI |C|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  ATM Payload ( 48 bytes )                     |
+   |                          "                                    |
+   |                          "                                    |
+   |                          "                                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      * VPI (Virtual Path Identifier)
+
+        The ingress router MUST copy the VPI field from the incoming
+        cell into this field.  For particular emulated VCs, the egress
+        router MAY generate a new VPI and ignore the VPI contained in
+        this field.
+
+      * VCI (Virtual Circuit Identifier)
+
+        The ingress router MUST copy the VCI field from the incoming ATM
+        cell header into this field.  For particular emulated VCs, the
+        egress router MAY generate a new VCI.
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 11]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+      * PTI (Payload Type Identifier) & CLP ( C bit )
+
+        The PTI and CLP fields are the PTI and CLP fields of the
+        incoming ATM cells.  The cell headers of the cells within the
+        packet are the ATM headers (without HEC) of the incoming cell.
+
+5.2.3.  OAM Cell Support
+
+   OAM cells MAY be transported on the VC LSP.  An egress router that
+   does not support transport of OAM cells MUST discard frames that
+   contain an ATM cell with the high-order bit of the PTI field set to
+   1.  A router that supports transport of OAM cells MUST follow the
+   procedures outlined in [FAST] section 8 for mode 0 only, in addition
+   to the applicable procedures specified in [RFC4906].
+
+5.2.4.  CLP bit to Quality of Service Mapping
+
+   The ingress router MAY consider the CLP bit when determining the
+   value to be placed in the Quality of Service fields (e.g., the EXP
+   fields of the MPLS label stack) of the encapsulating protocol.  This
+   gives the network visibility of the CLP bit.  Note however that cells
+   from the same VC MUST NOT be reordered.
+
+5.3.  Ethernet VLAN
+
+   For an Ethernet 802.1q VLAN, the entire Ethernet frame without the
+   preamble or FCS is transported as a single packet.  The control word
+   is OPTIONAL.  If the control word is used, then the flag bits in the
+   control word are not used, and MUST be set to 0 when transmitting,
+   and MUST be ignored upon receipt.  The 4-byte VLAN tag is transported
+   as is, and MAY be overwritten by the egress router.
+
+   The ingress router MAY consider the user priority field [IEEE802.3ac]
+   of the VLAN tag header when determining the value to be placed in the
+   Quality of Service field of the encapsulating protocol (e.g., the EXP
+   fields of the MPLS label stack).  In a similar way, the egress router
+   MAY consider the Quality of Service field of the encapsulating
+   protocol when queuing the packet for egress.  Ethernet packets
+   containing hardware-level Cyclic Redundancy Check (CRC) errors,
+   framing errors, or runt packets MUST be discarded on input.
+
+5.4.  Ethernet
+
+   For simple Ethernet port to port transport, the entire Ethernet frame
+   without the preamble or FCS is transported as a single packet.  The
+   control word is OPTIONAL.  If the control word is used, then the flag
+   bits in the control word are not used, and MUST be set to 0 when
+   transmitting, and MUST be ignored upon receipt.  As in the Ethernet
+
+
+
+Martini, et al.                 Historic                       [Page 12]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   VLAN case, Ethernet packets with hardware-level CRC errors, framing
+   errors, and runt packets MUST be discarded on input.
+
+5.5.  High-Level Data Link Control (HDLC)
+
+   HDLC mode provides port to port transport of HDLC-encapsulated
+   traffic.  The HDLC PDU is transported in its entirety, including the
+   HDLC address, control, and protocol fields, but excluding HDLC flags
+   and the FCS.  Bit/byte stuffing is undone.  The control word is
+   OPTIONAL.  If the control word is used, then the flag bits in the
+   control word are not used, and MUST be set to 0 when transmitting,
+   and MUST be ignored upon receipt.
+
+   The HDLC mode is suitable for port to port transport of Frame Relay
+   User-Network Interface (UNI) or Network-Network Interface (NNI)
+   traffic.  It must be noted, however, that this mode is transparent to
+   the FECN, BECN, and DE bits.
+
+5.6.  PPP
+
+   PPP mode provides point to point transport of PPP-encapsulated
+   traffic, as specified in [RFC1661].  The PPP PDU is transported in
+   its entirety, including the protocol field (whether compressed using
+   PFC or not), but excluding any media-specific framing information,
+   such as HDLC address and control fields or FCS.  Since media-specific
+   framing is not carried, the following options will not operate
+   correctly if the PPP peers attempt to negotiate them:
+
+      - Frame Check Sequence (FCS) Alternatives
+      - Address-and-Control-Field-Compression (ACFC)
+      - Asynchronous-Control-Character-Map (ACCM)
+
+   Note also that VC LSP Interface MTU negotiation as specified in
+   [RFC4906] is not affected by PPP Maximum Receive Unit (MRU)
+   advertisement.  Thus, if a PPP peer sends a PDU with a length in
+   excess of that negotiated for the VC LSP, that PDU will be discarded
+   by the ingress router.
+
+   The control word is OPTIONAL.  If the control word is used, then the
+   flag bits in the control word are not used, and MUST be set to 0 when
+   transmitting, and MUST be ignored upon receipt.
+
+6.  Using an MPLS Label as the Demultiplexer Field
+
+   To use an MPLS label as the demultiplexer field, a 32-bit label stack
+   entry [RFC3032] is simply prepended to the emulated VC encapsulation,
+   and hence will appear as the bottom label of an MPLS label stack.
+   This label may be called the "VC label".  The particular emulated VC
+
+
+
+Martini, et al.                 Historic                       [Page 13]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   identified by a particular label value must be agreed by the ingress
+   and egress LSRs, either by signaling (e.g., via the methods of
+   [RFC4906]) or by configuration.  Other fields of the label stack
+   entry are set as follows.
+
+6.1.  MPLS Shim EXP Bit Values
+
+   If it is desired to carry Quality of Service information, the Quality
+   of Service information SHOULD be represented in the EXP field of the
+   VC label.  If more than one MPLS label is imposed by the ingress LSR,
+   the EXP field of any labels higher in the stack SHOULD also carry the
+   same value.
+
+6.2.  MPLS Shim S Bit Value
+
+   The ingress LSR, R1, MUST set the S bit of the VC label to a value of
+   1 to denote that the VC label is at the bottom of the stack.
+
+6.3.  MPLS Shim TTL Values
+
+   The ingress LSR, R1, SHOULD set the TTL field of the VC label to a
+   value of 2.
+
+7.  Security Considerations
+
+   This document specifies only encapsulations, and not the protocols,
+   used to carry the encapsulated packets across the network.  Each such
+   protocol may have its own set of security issues, but those issues
+   are not affected by the encapsulations specified herein.  More
+   detailed security considerations are also described in Section 8 of
+   [RFC4447].
+
+8.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4447]     Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,
+                 and G. Heron, "Pseudowire Setup and Maintenance Using
+                 the Label Distribution Protocol (LDP)", RFC 4447, April
+                 2006.
+
+   [RFC4385]     Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
+                 for Use over an MPLS PSN", RFC 4385, February 2006.
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 14]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   [RFC4842]     Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
+                 "Synchronous Optical Network/Synchronous Digital
+                 Hierarchy (SONET/SDH) Circuit Emulation over Packet
+                 (CEP)", RFC 4842, April 2007.
+
+   [RFC4553]     Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
+                 Agnostic Time Division Multiplexing (TDM) over Packet
+                 (SAToP)", RFC 4553, June 2006.
+
+   [RFC4619]     Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
+                 "Encapsulation Methods for Transport of Frame Relay
+                 over Multiprotocol Label Switching (MPLS) Networks",
+                 RFC 4619, September 2006.
+
+   [RFC4717]     Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
+                 Brayley, J., and G. Koleyni, "Encapsulation Methods for
+                 Transport of Asynchronous Transfer Mode (ATM) over MPLS
+                 Networks", RFC 4717, December 2006.
+
+   [RFC4618]     Martini, L., Rosen, E., Heron, G., and A. Malis,
+                 "Encapsulation Methods for Transport of PPP/High-Level
+                 Data Link Control (HDLC) over MPLS Networks", RFC 4618,
+                 September 2006.
+
+   [RFC4448]     Martini, L., Ed., Rosen, E., El-Aawar, N., and G.
+                 Heron, "Encapsulation Methods for Transport of Ethernet
+                 over MPLS Networks", RFC 4448, April 2006.
+
+   [RFC4906]     Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed.,
+                 "Transport of Layer 2 Frames Over MPLS", RFC 4906, June
+                 2007.
+
+   [RFC3032]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+                 Encoding", RFC 3032, January 2001.
+
+   [FRF.8.1]     Frame Relay Forum, "Frame Relay / ATM PVC Service
+                 Interworking Implementation Agreement", February 2000.
+
+   [FAST]        ATM Forum, "Frame Based ATM over SONET/SDH Transport
+                 (FAST)", af-fbatm-0151.000, July 2000.
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 15]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   [IEEE802.3ac] IEEE 802.3ac-1998, "Information technology -
+                 Telecommunications and information exchange between
+                 systems - Local and metropolitan area networks -
+                 Specific requirements Part 3: Carrier sense multiple
+                 access with collision detection (CSMA/CD) frame
+                 extensions for Virtual Bridged Local Area Networks
+                 (VLAN) tagging on 802.3 networks".
+
+9.  Informative References
+
+   [RFC1661]     Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
+                 STD 51, RFC 1661, July 1994.
+
+10.  Co-Authors
+
+   Giles Heron
+   Tellabs
+   Abbey Place
+   24-28 Easton Street
+   High Wycombe
+   Bucks
+   HP11 1NT
+   UK
+   EMail: giles.heron@tellabs.com
+
+
+   Dimitri Stratton Vlachos
+   Mazu Networks, Inc.
+   125 Cambridgepark Drive
+   Cambridge, MA 02140
+   EMail: d@mazunetworks.com
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   EMail: tappan@cisco.com
+
+
+   Jayakumar Jayakumar
+   Cisco Systems Inc.
+   225, E.Tasman, MS-SJ3/3,
+   San Jose, CA 95134
+   EMail: jjayakum@cisco.com
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 16]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   Alex Hamilton
+   Cisco Systems Inc.
+   285 W. Tasman, MS-SJCI/3/4,
+   San Jose, CA 95134
+   EMail: tahamilt@cisco.com
+
+
+   Steve Vogelsang
+   Laurel Networks, Inc.
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+   EMail: sjv@laurelnetworks.com
+
+
+   John Shirron
+   Laurel Networks, Inc.
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+   EMail: jshirron@laurelnetworks.com
+
+
+   Toby Smith
+   Network Appliance, Inc.
+   800 Cranberry Woods Drive
+   Suite 300
+   Cranberry Township, PA 16066
+   EMail: tob@netapp.com
+
+
+   Andrew G. Malis
+   Tellabs
+   90 Rio Robles Dr.
+   San Jose, CA 95134
+   EMail: Andy.Malis@tellabs.com
+
+
+   Vinai Sirkay
+   Redback Networks
+   300 Holger Way
+   San Jose, CA 95134
+   EMail: vsirkay@redback.com
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 17]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+   Vasile Radoaca
+   Nortel Networks
+   600  Technology Park
+   Billerica MA 01821
+   EMail: vasile@nortelnetworks.com
+
+
+   Chris Liljenstolpe
+   Alcatel
+   11600 Sallie Mae Dr.
+   9th Floor
+   Reston, VA 20193
+   EMail: chris.liljenstolpe@alcatel.com
+
+
+   Dave Cooper
+   Global Crossing
+   960 Hamlin Court
+   Sunnyvale, CA 94089
+   EMail: dcooper@gblx.net
+
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+   EMail: kireeti@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 18]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+Authors' Addresses
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO 80112
+   EMail: lmartini@cisco.com
+
+
+   Nasser El-Aawar
+   Level 3 Communications, LLC.
+   1025 Eldorado Blvd.
+   Broomfield, CO 80021
+   EMail: nna@level3.net
+
+
+   Eric Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   EMail: erosen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 19]
+
+RFC 4905         Encapsulation for L2 Frames over MPLS         June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 20]
+