doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc4906.txt b/doc/rfc/rfc4906.txt
new file mode 100644
index 0000000..10a6ba4
--- /dev/null
+++ b/doc/rfc/rfc4906.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                    L. Martini, Ed.
+Request for Comments: 4906                                 E. Rosen, Ed.
+Category: Historic                                   Cisco Systems, Inc.
+                                                        N. El-Aawar, Ed.
+                                             Level 3 Communications, LLC
+                                                               June 2007
+
+
+                 Transport of Layer 2 Frames Over MPLS
+
+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 transporting the Protocol Data
+   Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous
+   Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for
+   providing a Synchronized Optical Network (SONET) circuit emulation
+   service 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 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Specification of Requirements ...................................3
+   3. Special Note ....................................................3
+   4. Tunnel Labels and Virtual Circuit (VC) Labels ...................4
+   5. Protocol-Specific Details .......................................5
+      5.1. Frame Relay ................................................5
+      5.2. ATM ........................................................6
+           5.2.1. ATM AAL5 VCC Transport ..............................6
+           5.2.2. ATM Transparent Cell Transport ......................6
+           5.2.3. ATM VCC and VPC Cell Transport ......................6
+           5.2.4. OAM Cell Support ....................................6
+           5.2.5. ILMI Support ........................................7
+      5.3. Ethernet VLAN ..............................................7
+      5.4. Ethernet ...................................................8
+      5.5. HDLC .......................................................8
+      5.6. PPP ........................................................8
+   6. LDP .............................................................8
+      6.1. Interface Parameters Field ................................10
+      6.2. C Bit Handling Procedures .................................12
+           6.2.1. VC Types for Which the Control Word is REQUIRED ....12
+           6.2.2. VC Types for Which the Control Word is NOT
+                  Mandatory ..........................................12
+           6.2.3. Status Codes .......................................15
+      6.3. LDP Label Withdrawal Procedures ...........................15
+      6.4. Sequencing Considerations .................................15
+           6.4.1. Label Mapping Advertisements .......................15
+           6.4.2. Label Mapping Release ..............................16
+   7. IANA Considerations ............................................16
+   8. Security Considerations ........................................16
+   9. Normative References ...........................................17
+   10. Informative References ........................................18
+   11. Co-Authors ....................................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 2]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+1.  Introduction
+
+   In an MPLS network, it is possible to carry the Protocol Data Units
+   (PDUs) of layer 2 protocols by prepending an MPLS label stack to
+   these PDUs.  This document specifies the necessary label distribution
+   procedures for accomplishing this using the encapsulation methods in
+   [RFC4905].  We restrict discussion to the case of point-to-point
+   transport.  Quality of service (QoS)-related issues are not discussed
+   in this document.  This document describes methods for transporting a
+   number of protocols; in some cases, transporting a particular
+   protocol may have several modes of operation.  Each of these
+   protocols and/or modes may be implemented independently.
+
+   An accompanying document [CEM] also describes a method for
+   transporting time division multiplexed (TDM) digital signals (TDM
+   circuit emulation) over a packet-oriented MPLS network.  The
+   transmission system for circuit-oriented TDM signals is the
+   Synchronous Optical Network (SONET) [ANSI.T1.105] / Synchronous
+   Digital Hierarchy (SDH) [ITU.G.707].  To support TDM traffic, which
+   includes voice, data, and private leased line service, the MPLS
+   network must emulate the circuit characteristics of SONET/SDH
+   payloads.  MPLS labels and a new circuit emulation header are used to
+   encapsulate TDM signals and provide the Circuit Emulation Service
+   over MPLS (CEM).
+
+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].
+
+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 a documentation of
+   current implementations, and MUST NOT be used for new
+   implementations.  The PWE3 Label Distribution Protocol (LDP) control
+   document [RFC4447], which is backward compatible with this document,
+   MUST be used for all new implementations of this protocol.
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 3]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+4.  Tunnel Labels and Virtual Circuit (VC) Labels
+
+   Suppose it is desired to transport layer 2 PDUs from ingress Label
+   Switching Router (LSR) R1 to egress LSR R2, across an intervening
+   MPLS network.  We assume that there is a Label Switched Path (LSP)
+   from R1 to R2.  That is, we assume that R1 can cause a packet to be
+   delivered to R2 by pushing some label onto the packet and sending the
+   result to one of its adjacencies.  Call this label the "tunnel
+   label", and the corresponding LSP the "tunnel LSP".
+
+   The tunnel LSP merely gets packets from R1 to R2; the corresponding
+   label doesn't tell R2 what to do with the payload.  In fact, if
+   penultimate hop popping is used, R2 may never even see the
+   corresponding label.  (If R1 itself is the penultimate hop, a tunnel
+   label may not even get pushed on.)  Thus, if the payload is not an IP
+   packet, there must be a label, which becomes visible to R2, that
+   tells R2 how to treat the received packet.  Call this label the "VC
+   label".
+
+   So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on
+   its label stack, and then (if R1 is not adjacent to R2) pushes on a
+   tunnel label.  The tunnel label gets the MPLS packet from R1 to R2;
+   the VC label is not visible until the MPLS packet reaches R2.  R2's
+   disposition of the packet is based on the VC label.
+
+   Note that the tunnel could be a Generic Routing Encapsulation (GRE)-
+   encapsulated MPLS tunnel between R1 and R2.  In this case, R1 would
+   be adjacent to R2, and only the VC label would be used, and the
+   intervening network need only carry IP packets.
+
+   If the payload of the MPLS packet is, for example, an ATM AAL5 PDU,
+   the VC label will generally correspond to a particular ATM VC at R2.
+   That is, R2 needs to be able to infer from the VC label the outgoing
+   interface and the VPI/VCI (Virtual Path Identifier / Virtual Circuit
+   Identifier) value for the AAL5 PDU.  If the payload is a Frame Relay
+   PDU, then R2 needs to be able to infer from the VC label the outgoing
+   interface and the DLCI (Data Link Connection Identifier) value.  If
+   the payload is an Ethernet frame, then R2 needs to be able to infer
+   from the VC label the outgoing interface, and perhaps the VLAN
+   identifier.  This process is unidirectional, and will be repeated
+   independently for bidirectional operation.  It is REQUIRED to assign
+   the same VC ID, and VC type for a given circuit in both directions.
+   The group ID (see below) MUST NOT be required to match in both
+   directions.  The transported frame MAY be modified when it reaches
+   the egress router.  If the header of the transported layer 2 frame is
+   modified, this MUST be done at the egress LSR only.
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 4]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   Note that the VC label must always be at the bottom of the label
+   stack, and the tunnel label, if present, must be immediately above
+   the VC label.  Of course, as the packet is transported across the
+   MPLS network, additional labels may be pushed on (and then popped
+   off) as needed.  Even R1 itself may push on additional labels above
+   the tunnel label.  If R1 and R2 are directly adjacent LSRs, then it
+   may not be necessary to use a tunnel label at all.
+
+   This document does not specify a method for distributing the tunnel
+   label or any other labels that may appear above the VC label on the
+   stack.  Any acceptable method of MPLS label distribution will do.
+
+   This document does specify a method for assigning and distributing
+   the VC label.  Static label assignment MAY be used, and
+   implementations SHOULD provide support for this.  When signaling is
+   used, the VC label MUST be distributed from R2 to R1 using LDP in the
+   downstream unsolicited mode; this requires that an LDP session be
+   created between R1 and R2.  It should be noted that this LDP session
+   is not necessarily transported along the same path as the Layer 2
+   PDUs [RFC3036].  In addition, when using LDP to distribute the VC
+   label, liberal label retention mode SHOULD be used.  However, as
+   required in [RFC3036], the label request operation (mainly used by
+   conservative label retention mode) MUST be implemented.  VC labels
+   MUST be allocated from the per-platform label space.
+
+   Note that this technique allows an unbounded number of layer 2 "VCs"
+   to be carried together in a single "tunnel".  Thus, it scales quite
+   well in the network backbone.
+
+   While this document currently defines the emulation of Frame Relay
+   and ATM Permanent Virtual Circuit (PVC) services, it specifically
+   does not preclude future enhancements to support switched service
+   (Switched Virtual Circuit (SVC) and Switched Permanent Virtual
+   Circuit (SPVC)) emulation.
+
+5.  Protocol-Specific Details
+
+5.1.  Frame Relay
+
+   The Frame Relay PDUs are encapsulated according to the procedures
+   defined in [RFC4905].  The MPLS edge LSR MUST provide Frame Relay PVC
+   status signaling to the Frame Relay network.  If the MPLS edge LSR
+   detects a service affecting condition, as defined in [Q.933] Annex
+   A.5 cited in Implementation Agreement FRF.1.1, it MUST withdraw the
+   label that corresponds to the frame relay DLCI.  The egress LSR
+   SHOULD generate the corresponding errors and alarms as defined in
+   [Q.933] on the egress Frame relay VC.
+
+
+
+
+Martini, et al.                 Historic                        [Page 5]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+5.2.  ATM
+
+5.2.1.  ATM AAL5 VCC Transport
+
+   ATM AAL5 Common Part Convergence Sublayer - Service Data Units
+   (CPCS-SDUs) are encapsulated according to [RFC4905] ATM AAL5 CPCS-SDU
+   mode.  This mode allows the transport of ATM AAL5 CSPS-SDUs traveling
+   on a particular ATM PVC across the MPLS network to another ATM PVC.
+
+5.2.2.  ATM Transparent Cell Transport
+
+   This mode is similar to the Ethernet port mode.  Every cell that is
+   received at the ingress ATM port on the ingress LSR, R1, is
+   encapsulated according to [RFC4905], ATM cell mode, and sent across
+   the LSP to the egress LSR, R2.  This mode allows an ATM port to be
+   connected to only one other ATM port.  [RFC4905] allows for grouping
+   of multiple cells into a single MPLS frame.  Grouping of ATM cells is
+   OPTIONAL for transmission at the ingress LSR, R1.  If the Egress LSR
+   R2 supports cell concatenation, the ingress LSR, R1, should only
+   concatenate cells up to the "Maximum Number of concatenated ATM
+   cells" parameter received as part of the FEC element.
+
+5.2.3.  ATM VCC and VPC Cell Transport
+
+   This mode is similar to the ATM AAL5 Virtual Channel Connection (VCC)
+   transport except that cells are transported.  Every cell that is
+   received on a pre-defined ATM PVC or ATM Permanent Virtual Path
+   (PVP), at the ingress ATM port on the ingress LSR, R1, is
+   encapsulated according to [RFC4905], ATM cell mode, and sent across
+   the LSP to the egress LSR R2.  Grouping of ATM cells is OPTIONAL for
+   transmission at the ingress LSR, R1.  If the egress LSR R2 supports
+   cell concatenation, the ingress LSR, R1, MUST only concatenate cells
+   up to the "Maximum Number of concatenated ATM cells in a frame"
+   parameter received as part of the FEC element.
+
+5.2.4.  OAM Cell Support
+
+   Operations and Management (OAM) cells MAY be transported on the VC
+   LSP.  When the LSR is operating in AAL5 CPCS-SDU transport mode, if
+   it does not support transport of ATM cells, the LSR MUST discard
+   incoming MPLS frames on an ATM VC LSP that contain a VC label with
+   the T bit set [RFC4905].  When operating in AAL5 SDU transport mode,
+   an LSR that supports transport of OAM cells using the T bit defined
+   in [RFC4905], or an LSR operating in any of the three cell transport
+   modes, MUST follow the procedures outlined in [FAST] Section 8 for
+   mode 0 only, in addition to the applicable procedures specified in
+   [ITU.G.707].
+
+
+
+
+Martini, et al.                 Historic                        [Page 6]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+5.2.4.1.  OAM Cell Emulation Mode
+
+   AN LSR that does not support transport of OAM cells across an LSP MAY
+   provide OAM support on ATM PVCs using the following procedures:
+
+   A pair of LSRs MAY emulate a bidirectional ATM VC by two
+   unidirectional LSPs.  If an F5 end-to-end OAM cell is received from a
+   ATM VC, by either LSR that is transporting this ATM VC, with a
+   loopback indication value of 1, and the LSR has a label mapping for
+   the ATM VC, then the LSR MUST decrement the loopback indication value
+   and loop back the cell on the ATM VC.  Otherwise, the loopback cell
+   MUST be discarded by the LSR.
+
+   The ingress LSR, R1, may also optionally be configured to
+   periodically generate F5 end-to-end loopback OAM cells on a VC.  If
+   the LSR fails to receive a response to an F5 end-to-end loopback OAM
+   cell for a pre-defined period of time it MUST withdraw the label
+   mapping for the VC.
+
+   If an ingress LSR, R1, receives an AIS (Alarm Indication Signal) F5
+   OAM cell, or R1 fails to receive a pre-defined number of the End-to-
+   End loop OAM cells, or a physical interface goes down, it MUST
+   withdraw the label mappings for all VCs associated with the failure.
+   When a VC label mapping is withdrawn, the egress LSR, R2, MUST
+   generate AIS F5 OAM cells on the VC associated with the withdrawn
+   label mapping.  In this mode it is very useful to apply a unique
+   group ID to each interface.  In the case where a physical interface
+   goes down, a wild card label withdraw can be sent to all LDP
+   neighbors, greatly reducing the signaling response time.
+
+5.2.5.  ILMI Support
+
+   An MPLS edge LSR MAY provide an ATM Integrated Local Management
+   Interface (ILMI) to the ATM edge switch.  If an ingress LSR receives
+   an ILMI message indicating that the ATM edge switch has deleted a VC,
+   or if the physical interface goes down, it MUST withdraw the label
+   mappings for all VCs associated with the failure.  When a VC label
+   mapping is withdrawn, the egress LSR SHOULD notify its client of this
+   failure by deleting the VC using ILMI.
+
+5.3.  Ethernet VLAN
+
+   The Ethernet frame will be encapsulated according to the procedures
+   in [RFC4905].  It should be noted that if the VLAN identifier is
+   modified by the egress LSR, according to the procedures outlined
+   above, the Ethernet spanning tree protocol might fail to work
+   properly.  If the LSR detects a failure on the Ethernet physical
+
+
+
+
+Martini, et al.                 Historic                        [Page 7]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   port, or the port is administratively disabled, it MUST withdraw the
+   label mappings for all VCs associated with the port.
+
+5.4.  Ethernet
+
+   The Ethernet frame will be encapsulated according to the procedures
+   in [RFC4905].  If the LSR detects a failure on the Ethernet physical
+   port, or the port is administratively disabled, the corresponding VC
+   label mapping MUST be withdrawn.
+
+5.5.  HDLC
+
+   HDLC (High-Level Data Link Control) frames are encapsulated according
+   to the procedures in [RFC4905].  If the MPLS edge LSR detects that
+   the physical link has failed, or the port is administratively
+   disabled, it MUST withdraw the label mapping that corresponds to the
+   HDLC link.
+
+5.6.  PPP
+
+   PPP frames are encapsulated according to the procedures in [RFC4905].
+   If the MPLS edge LSR detects that the physical link has failed, or
+   the port is administratively disabled, it MUST withdraw the label
+   mapping that corresponds to the PPP link.
+
+6.  LDP
+
+   The VC label bindings are distributed using the LDP downstream
+   unsolicited mode described in [RFC3036].  The LSRs will establish an
+   LDP session using the Extended Discovery mechanism described in
+   sections 2.4.2 and 2.5 of [RFC3036]; for this purpose, a new type of
+   FEC element is defined.  The FEC element type is 128.  Only a single
+   VC FEC element MUST be advertised per LDP VC label.  The Virtual
+   Circuit FEC element 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    VC tlv     |C|         VC Type             |VC info Length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Group ID                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        VC ID                                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Interface parameters                    |
+   |                              "                                |
+   |                              "                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Martini, et al.                 Historic                        [Page 8]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+      - VC Type
+
+        A 15-bit quantity containing a value that represents the type of
+        VC.  Assigned values are:
+
+                VC Type  Description
+
+                0x0001   Frame Relay DLCI
+                0x0002   ATM AAL5 VCC transport
+                0x0003   ATM transparent cell transport
+                0x0004   Ethernet VLAN
+                0x0005   Ethernet
+                0x0006   HDLC
+                0x0007   PPP
+                0x8008   CEM [CEM]
+                0x0009   ATM VCC cell transport
+                0x000A   ATM VPC cell transport
+
+      - Control word bit (C)
+
+        The highest order bit (C) of the VC type is used to flag the
+        presence of a control word (defined in [RFC4905]) as follows:
+
+                bit 15 = 1 control word present on this VC.
+                bit 15 = 0 no control word present on this VC.
+
+        Please see Section 6.2, "C Bit Handling Procedures", for further
+        explanation.
+
+      - VC information length
+
+        Length of the VC ID field and the interface parameters field in
+        octets.  If this value is 0, then it references all VCs using
+        the specified group ID, and there is no VC ID present, nor any
+        interface parameters.
+
+      - Group ID
+
+        An arbitrary 32-bit value, which represents a group of VCs that
+        is used to create groups in the VC space.  The group ID is
+        intended to be used as a port index, or a virtual tunnel index.
+        To simplify configuration, a particular VC ID at ingress could
+        be part of the virtual tunnel for transport to the egress
+        router.  The group ID is very useful to send wild card label
+        withdrawals to remote LSRs upon physical port failure.
+
+
+
+
+
+
+Martini, et al.                 Historic                        [Page 9]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+      - VC ID
+
+        A non-zero 32-bit connection ID that, together with the VC type,
+        identifies a particular VC.
+
+      - Interface parameters
+
+        This variable length field is used to provide interface-specific
+        parameters, such as interface MTU.
+
+6.1.  Interface Parameters Field
+
+   This field specifies interface-specific parameters.  When applicable,
+   it MUST be used to validate that the LSRs, and the ingress and egress
+   ports at the edges of the circuit, have the necessary capabilities to
+   interoperate with each other.  The field structure 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Parameter ID |    Length     |    Variable Length Value      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Variable Length Value                 |
+   |                             "                                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The parameter ID is defined as follows:
+
+   Parameter   ID Length    Description
+
+       0x01         4       Interface MTU in octets.
+       0x02         4       Maximum Number of concatenated ATM cells.
+       0x03   up to 82      Optional Interface Description string.
+       0x04         4       CEM [CEM] Payload Bytes.
+       0x05         4       CEM options.
+
+   The Length field is defined as the length of the interface parameter
+   including the Parameter ID and Length field itself.  Processing of
+   the interface parameters should continue when encountering unknown
+   interface parameters, and they MUST be silently ignored.
+
+      - Interface MTU
+
+        A 2-octet value indicating the MTU in octets.  This is the
+        Maximum Transmission Unit, excluding encapsulation overhead, of
+        the egress packet interface that will be transmitting the
+        decapsulated PDU that is received from the MPLS network.  This
+
+
+
+Martini, et al.                 Historic                       [Page 10]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+        parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7,
+        and is REQUIRED for these VC types.  If this parameter does not
+        match in both directions of a specific VC, that VC MUST NOT be
+        enabled.
+
+      - Maximum Number of concatenated ATM cells
+
+        A 2-octet value specifying the maximum number of concatenated
+        ATM cells that can be processed as a single PDU by the egress
+        LSR.  An ingress LSR transmitting concatenated cells on this VC
+        can concatenate a number of cells up to the value of this
+        parameter, but MUST NOT exceed it.  This parameter is applicable
+        only to VC types 3, 9, and 0x0a, and is REQUIRED for these VC
+        types.  This parameter does not need to match in both directions
+        of a specific VC.
+
+      - Optional Interface Description string
+
+        This arbitrary, OPTIONAL interface description string can be
+        used to send an administrative description text string to the
+        remote LSR.  This parameter is OPTIONAL, and is applicable to
+        all VC types.  The interface description parameter string length
+        is variable, and can be from 0 to 80 octets.
+
+      - Payload Bytes
+
+        A 2-octet value indicating the number of TDM payload octets
+        contained in all packets on the CEM stream from 48 to 1,023
+        octets.  All of the packets in a given CEM stream have the same
+        number of payload bytes.  Note that there is a possibility that
+        the packet size may exceed the Synchronous Payload Envelope
+        (SPE) size in the case of an STS-1 SPE, which could cause two
+        pointers to be needed in the CEM header, since the payload may
+        contain two J1 bytes for consecutive SPEs.  For this reason, the
+        number of payload bytes must be less than or equal to 783 for
+        STS-1 SPEs.
+
+      - CEM Options
+
+        An optional 16-bit value of CEM flags.  See [CEM] for the
+        definition of the bit values.
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 11]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+6.2.  C Bit Handling Procedures
+
+6.2.1.  VC Types for Which the Control Word is REQUIRED
+
+   The Label Mapping messages which are sent in order to set up these
+   VCs MUST have c=1.  When a Label Mapping message for a VC of one of
+   these types is received, and c=0, a Label Release MUST be sent, with
+   an "Illegal C-bit" status code.  In this case, the VC will not come
+   up.
+
+6.2.2.  VC Types for Which the Control Word is NOT Mandatory
+
+   If a system is capable of sending and receiving the control word on
+   VC types for which the control word is not mandatory, then each such
+   VC endpoint MUST be configurable with a parameter that specifies
+   whether the use of the control word is PREFERRED or NOT PREFERRED.
+   For each VC, there MUST be a default value of this parameter.  This
+   specification does NOT state what the default value should be.
+
+   If a system is NOT capable of sending and receiving the control word
+   on VC types for which the control word is not mandatory, then it
+   behaves exactly as if it were configured for the use of the control
+   word to be NOT PREFERRED.
+
+   If a Label Mapping message for the VC has already been received, but
+   no Label Mapping message for the VC has yet been sent, then the
+   procedure is the following:
+
+     -i. If the received Label Mapping message has c=0, send a Label
+         Mapping message with c=0, and the control word is not used.
+
+    -ii. If the received Label Mapping message has c=1, and the VC is
+         locally configured such that the use of the control word is
+         preferred, then send a Label Mapping message with c=1, and the
+         control word is used.
+
+   -iii. If the received Label Mapping message has c=1, and the VC is
+         locally configured such that the use of the control word is not
+         preferred or the control word is not supported, then act as if
+         no Label Mapping message for the VC had been received (i.e.,
+         proceed to the next paragraph).
+
+   If a Label Mapping message for the VC has not already been received
+   (or if the received Label Mapping message had c=1, and either local
+   configuration says that the use of the control word is not preferred
+   or the control word is not supported), then send a Label Mapping
+   message in which the c bit is set to correspond to the locally
+   configured preference for use of the control word.  (That is, set c=1
+
+
+
+Martini, et al.                 Historic                       [Page 12]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   if locally configured to prefer the control word, set c=0 if locally
+   configured to prefer not to use the control word or if the control
+   word is not supported).
+
+   The next action depends on what control message is next received for
+   that VC.  The possibilities are:
+
+     -i. A Label Mapping message with the same c bit value as specified
+         in the Label Mapping message that was sent.  VC setup is now
+         complete, and the control word is used if c=1 but not used if
+         c=0.
+
+    -ii. A Label Mapping message with c=1, but the Label Mapping message
+         that was sent has c=0.  In this case, ignore the received Label
+         Mapping message, and continue to wait for the next control
+         message for the VC.
+
+   -iii. A Label Mapping message with c=0, but the Label Mapping message
+         that was sent has c=1.  In this case, send a Label Withdraw
+         message with a "Wrong C-bit" status code, followed by a Label
+         Mapping message that has c=0.  VC setup is now complete, and
+         the control word is not used.
+
+    -iv. A Label Withdraw message with the "Wrong C-bit" status code.
+         Treat as a normal Label Withdraw, but do not respond.  Continue
+         to wait for the next control message for the VC.
+
+   If, at any time after a Label Mapping message has been received, a
+   corresponding Label Withdraw or Release is received, the action taken
+   is the same as for any Label Withdraw or Release that might be
+   received at any time.
+
+   If both endpoints prefer the use of the control word, this procedure
+   will cause it to be used.  If either endpoint prefers not to use the
+   control word, or does not support the control word, this procedure
+   will cause it not to be used.  If one endpoint prefers to use the
+   control word but the other does not, the one that prefers not to use
+   it is has no extra protocol to execute; it just waits for a Label
+   Mapping message that has c=0.
+
+   The following diagram illustrates the above procedures:
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 13]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+                   ------------------
+               Y   | Received Label |       N
+            -------|  Mapping Msg?  |--------------
+            |      ------------------             |
+            |                                     |
+        --------------                            |
+        |            |                            |
+        |            |                            |
+     -------      -------                         |
+     | C=0 |      | C=1 |                         |
+     -------      -------                         |
+        |            |                            |
+        |            |                            |
+        |    ----------------                     |
+        |    | Control Word |     N               |
+        |    |    Capable?  |-----------          |
+        |    ----------------          |          |
+        |          Y |                 |          |
+        |            |                 |          |
+        |   ----------------           |          |
+        |   | Control Word |  N        |          |
+        |   |  Preferred?  |----       |          |
+        |   ----------------   |       |          |
+        |          Y |         |       |          |
+        |            |         |       |   ----------------
+        |            |         |       |   | Control Word |
+        |            |         |       |   |  Preferred?  |
+        |            |         |       |   ----------------
+        |            |         |       |     N |     Y |
+        |            |         |       |       |       |
+      Send         Send      Send    Send    Send    Send
+       C=0          C=1       C=0     C=0     C=0     C=1
+                               |       |       |       |
+                            ----------------------------------
+                            | If receive the same as sent,   |
+                            | VC setup is complete.  If not: |
+                            ----------------------------------
+                               |       |       |       |
+                              ------------------- -----------
+                              |     Receive     | | Receive |
+                              |       C=1       | |   C=0   |
+                              ------------------- -----------
+                                       |               |
+                                 Wait for the        Send
+                                 next message     Wrong C-Bit
+                                                       |
+                                              Send Label Mapping
+                                               Message with C=0
+
+
+
+Martini, et al.                 Historic                       [Page 14]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+6.2.3.  Status Codes
+
+   RFC 3036 has a range of Status Code values, which are assigned by
+   IANA on a First Come, First Served basis.  These are in the range
+   0x20000000-0x3effffff.  The following new status codes are defined:
+
+           0x20000001 "Illegal C-Bit"
+           0x20000002 "Wrong C-Bit"
+
+6.3.  LDP Label Withdrawal Procedures
+
+   As mentioned above, the Group ID field can be used to withdraw all VC
+   labels associated with a particular group ID.  This procedure is
+   OPTIONAL, and if it is implemented, the LDP label withdraw message
+   should be as follows: the VC information length field is set to 0,
+   the VC ID field is not present, and the interface parameters field is
+   not present.  For the purpose of this document, this is called the
+   "wild card withdraw procedure", and all LSRs implementing this design
+   are REQUIRED to accept such a withdraw message, but are not required
+   to send it.
+
+   The interface parameters field MUST NOT be present in any LDP VC
+   label withdrawal message or release message.  A wild card release
+   message MUST include only the group ID.  A Label Release message
+   initiated from the imposition router must always include the VC ID.
+
+6.4.  Sequencing Considerations
+
+   In the case where the router considers the sequence number field in
+   the control word, it is important to note the following when
+   advertising labels.
+
+6.4.1.  Label Mapping Advertisements
+
+   After a label has been withdrawn by the disposition router and/or
+   released by the imposition router, care must be taken to not re-
+   advertise (reuse) the released label until the disposition router can
+   be reasonably certain that old packets containing the released label
+   no longer persist in the MPLS network.
+
+   This precaution is required to prevent the imposition router from
+   restarting packet forwarding with sequence number of 1 when it
+   receives the same label mapping if there are still older packets
+   persisting in the network with sequence number between 1 and 32768.
+   For example, if there is a packet with sequence number=n where n is
+   in the interval[1,32768] traveling through the network, it would be
+   possible for the disposition router to receive that packet after it
+   re-advertises the label.  Since the label has been released by the
+
+
+
+Martini, et al.                 Historic                       [Page 15]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   imposition router, the disposition router SHOULD be expecting the
+   next packet to arrive with sequence number of 1.  Receipt of a packet
+   with sequence number equal to n will result in n packets potentially
+   being rejected by the disposition router until the imposition router
+   imposes a sequence number of n+1 into a packet.  Possible methods to
+   avoid this are for the disposition router to always advertise a
+   different VC label, or for the disposition router to wait for a
+   sufficient time before attempting to re-advertise a recently released
+   label.  This is only an issue when sequence number processing at the
+   disposition router is enabled.
+
+6.4.2.  Label Mapping Release
+
+   In situations where the imposition router wants to restart forwarding
+   of packets with sequence number 1, the router shall 1) send a label
+   mapping release to the disposition router, and 2) send a label
+   mapping request to the disposition router.  When sequencing is
+   supported, advertisement of a VC label in response to a label mapping
+   request MUST also consider the issues discussed in Section 6.4.1.
+
+7.  IANA Considerations
+
+   As specified in this document, a Virtual Circuit FEC element contains
+   the VC Type field.  VC Type value 0 is reserved.  VC Type values 1
+   through 10 are defined in this document.  VC Type values 11 through
+   63 are to be assigned by IANA using the "IETF Consensus" policy
+   defined in RFC 2434.  VC Type values 64 through 127 are to be
+   assigned by IANA, using the "First Come First Served" policy defined
+   in RFC 2434.  VC Type values 128 through 32767 are vendor-specific,
+   and values in this range are not to be assigned by IANA.
+
+   As specified in this document, a Virtual Circuit FEC element contains
+   the Interface Parameters field, which is a list of one or more
+   parameters, and each parameter is identified by the Parameter ID
+   field.  Parameter ID value 0 is reserved.  Parameter ID values 1
+   through 5 are defined in this document.  Parameter ID values 6
+   through 63 are to be assigned by IANA using the "IETF Consensus"
+   policy defined in RFC 2434.  Parameter ID values 64 through 127 are
+   to be assigned by IANA, using the "First Come First Served" policy
+   defined in RFC 2434.  Parameter ID values 128 through 255 are
+   vendor-specific, and values in this range are not to be assigned by
+   IANA.
+
+8.  Security Considerations
+
+   This document does not affect the underlying security issues of MPLS,
+   described in [RFC3032].  More detailed security considerations are
+   also described in Section 8 of [RFC4447].
+
+
+
+Martini, et al.                 Historic                       [Page 16]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+9.  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.
+
+   [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.
+
+   [RFC3036]     Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
+                 and B. Thomas, "LDP Specification", RFC 3036, January
+                 2001.
+
+   [Q.933]       ITU-T Recommendation Q.933, and Q.922 Specification for
+                 Frame Mode Basic call control, ITU Geneva 1995.
+
+
+
+Martini, et al.                 Historic                       [Page 17]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         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.
+
+   [ANSI.T1.105] American National Standards Institute, "Synchronous
+                 Optical Network Formats," ANSI T1.105-1995.
+
+   [ITU.G.707]   ITU Recommendation G.707, "Network Node Interface For
+                 The Synchronous Digital Hierarchy", 1996.
+
+   [RFC4905]     Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed.,
+                 "Encapsulation Methods for Transport of Layer 2 Frames
+                 over MPLS Networks", RFC 4905, June 2007.
+
+10.  Informative References
+
+   [CEM]         Malis, A., Brayley, J., Vogelsang., S., Shirron, J.,
+                 and L. Martini, "SONET/SDH Circuit Emulation Service
+                 Over MPLS (CEM) Encapsulation", Work in Progress, June
+                 2007.
+
+   [FAST]        ATM Forum, "Frame Based ATM over SONET/SDH Transport
+                 (FAST)", af-fbatm-0151.000, July 2000.
+
+11.  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
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 18]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA 01824
+   EMail: tappan@cisco.com
+
+
+   Jayakumar Jayakumar,
+   Cisco Systems Inc.
+   225, E.Tasman, MS-SJ3/3,
+   San Jose, CA 95134
+   EMail: jjayakum@cisco.com
+
+
+   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
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 19]
+
+RFC 4906         Transport of Layer 2 Frames Over MPLS         June 2007
+
+
+   Andrew G. Malis
+   Tellabs
+   90 Rio Robles Dr.
+   San Jose, CA 95134
+   EMail: Andy.Malis@tellabs.com
+
+
+   Vinai Sirkay
+   Reliance Infocomm
+   Dhirubai Ambani Knowledge City
+   Navi Mumbai 400 709
+   India
+   EMail: vinai@sirkay.com
+
+
+   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 20]
+
+RFC 4906         Transport of Layer 2 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.
+   250 Apollo Drive
+   Chelmsford, MA 01824
+   EMail: erosen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.                 Historic                       [Page 21]
+
+RFC 4906         Transport of Layer 2 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 22]
+