doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4619.txt b/doc/rfc/rfc4619.txt
new file mode 100644
index 0000000..cf0aff6
--- /dev/null
+++ b/doc/rfc/rfc4619.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                    L. Martini, Ed.
+Request for Comments: 4619                           Cisco Systems, Inc.
+Category: Standards Track                                   C. Kawa, Ed.
+                                                       Oz Communications
+                                                           A. Malis, Ed.
+                                                                 Tellabs
+                                                          September 2006
+
+
+        Encapsulation Methods for Transport of Frame Relay over
+             Multiprotocol Label Switching (MPLS) Networks
+
+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 Internet Society (2006).
+
+Abstract
+
+   A frame relay pseudowire is a mechanism that exists between a
+   provider's edge network nodes and that supports as faithfully as
+   possible frame relay services over an MPLS packet switched network
+   (PSN).  This document describes the detailed encapsulation necessary
+   to transport frame relay packets over an MPLS network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 1]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification of Requirements ...................................4
+   3. Co-authors ......................................................4
+   4. Acronyms and Abbreviations ......................................5
+   5. Applicability Statement .........................................5
+   6. General Encapsulation Method ....................................6
+   7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
+      7.1. MPLS PSN Tunnel and PW .....................................7
+      7.2. Packet Format over MPLS PSN ................................7
+      7.3. The Control Word ...........................................8
+      7.4. The Martini Legacy Mode Control Word .......................9
+      7.5. PW Packet Processing .......................................9
+           7.5.1. Encapsulation of Frame Relay Frames .................9
+           7.5.2. Setting the Sequence Number ........................10
+      7.6. Decapsulation of PW Packets ...............................11
+           7.6.1. Processing the Sequence Number .....................11
+           7.6.2. Processing of the Length Field by the Receiver .....11
+      7.7. MPLS Shim EXP Bit Values ..................................12
+      7.8. MPLS Shim S Bit Value .....................................12
+      7.9. Control Plane Details for Frame Relay Service .............12
+           7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
+   8. Frame Relay Port Mode ..........................................13
+   9. Congestion Control .............................................13
+   10. Security Considerations .......................................14
+   11. Normative References ..........................................14
+   12. Informative References ........................................15
+
+1.   Introduction
+
+   In an MPLS or IP network, it is possible to use control protocols
+   such as those specified in [RFC4447] to set up "pseudowires" (PWs)
+   that carry the Protocol Data Units of layer 2 protocols across the
+   network.  A number of these emulated PWs may be carried in a single
+   tunnel.  The main functions required to support frame relay PW by a
+   Provider Edge (PE) include:
+
+   - encapsulation of frame relay specific information in a suitable
+     pseudowire (PW) packet;
+
+   - transfer of a PW packet across an MPLS network for delivery to a
+     peer PE;
+
+   - extraction of frame relay specific information from a PW packet by
+     the remote peer PE;
+
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 2]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   - regeneration of native frame relay frames for forwarding across an
+     egress port of the remote peer PE; and
+
+   - execution of any other operations as required to support frame
+     relay service.
+
+   This document specifies the encapsulation for the emulated frame
+   relay VC over an MPLS PSN.  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.  Other layer 2 protocols are described in
+   separate documents.  [ATM] [RFC4448] [RFC4618]
+
+   The following figure describes the reference models that are derived
+   from [RFC3985] to support the frame relay PW emulated services.
+
+         |<-------------- Emulated Service ---------------->|
+         |                                                  |
+         |          |<------- Pseudowire ------->|          |
+         |          |                            |          |
+         |          |    |<-- PSN Tunnel -->|    |          |
+         | PW End   V    V                  V    V  PW End  |
+         V Service  +----+                  +----+  Service V
+   +-----+    |     | PE1|==================| PE2|     |    +-----+
+   |     |----------|............PW1.............|----------|     |
+   | CE1 |    |     |    |                  |    |     |    | CE2 |
+   |     |----------|............PW2.............|----------|     |
+   +-----+  ^ |     |    |==================|    |     | ^  +-----+
+         ^  |       +----+                  +----+     | |  ^
+         |  |   Provider Edge 1         Provider Edge 2  |  |
+         |  |       (PE1)                    (PE2)       |  |
+   Customer |                                            | Customer
+   Edge 1   |                                            | Edge 2
+            |                                            |
+            |                                            |
+    Attachment Circuit (AC)                    Attachment Circuit (AC)
+   native frame relay service                 native frame relay service
+
+   Figure 1.  PWE3 frame relay PVC interface reference configuration
+
+   Two mapping modes can be defined between frame relay VCs and
+   pseudowires: The first one is called "one-to-one" mapping, because
+   there is a one-to-one correspondence between a frame relay VC and one
+   pseudowire.  The second mapping is called "many-to-one" mapping or
+   "port mode" because multiple frame relay VCs assigned to a port are
+   mapped to one pseudowire.  The "port mode" encapsulation is identical
+   to High-Level Data Link Control (HDLC) pseudowire encapsulation,
+   which is described in [RFC4618].
+
+
+
+Martini & Kawa              Standards Track                     [Page 3]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+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 RFC 2119.
+
+   Below are the definitions for the terms used throughout the document.
+   PWE3 definitions can be found in [RFC3916, RFC3985].  This section
+   defines terms specific to frame relay.
+
+   - Forward direction
+
+     The forward direction is the direction taken by the frame being
+     forwarded.
+
+   - Backward direction
+
+     In frame relay, it is the direction opposite to the direction taken
+     by a frame being forwarded (see also forward direction).
+
+3.  Co-authors
+
+   The following are co-authors of this document:
+
+   Nasser El-Aawar           Level 3 Communications, LLC
+   Eric C. Rosen             Cisco Systems
+   Daniel Tappan             Cisco Systems
+   Thomas K. Johnson         Litchfield Communications
+   Kireeti Kompella          Juniper Networks, Inc.
+   Steve Vogelsang           Laurel Networks, Inc.
+   Vinai Sirkay              Reliance Infocomm
+   Ravi Bhat                 Nokia
+   Nishit Vasavada           Nokia
+   Giles Heron               Tellabs
+   Dimitri Stratton Vlachos  Mazu Networks,Inc.
+   Chris Liljenstolpe        Cable & Wireless
+   Prayson Pate              Overture Networks, Inc
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 4]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+4.  Acronyms and Abbreviations
+
+      BECN    Backward Explicit Congestion Notification
+      CE      Customer Edge
+      C/R     Command/Response
+      DE      Discard Eligibility
+      DLCI    Data Link Connection Identifier
+      FCS     Frame Check Sequence
+      FECN    Forward Explicit Congestion Notification
+      FR      Frame Relay
+      LSP     Label Switched Path
+      LSR     Label Switching Router
+      MPLS    Multiprotocol Label Switching
+      MTU     Maximum Transfer Unit
+      NNI     Network-Network Interface
+      PE      Provider Edge
+      PSN     Packet Switched Network
+      PW      Pseudowire
+      PWE3    Pseudowire Emulation Edge to Edge
+      POS     Packet over SONET/SDH
+      PVC     Permanent Virtual Circuit
+      QoS     Quality of Service
+      SVC     Switched Virtual Circuit
+      UNI     User-Network Interface
+      VC      Virtual Circuit
+
+5.  Applicability Statement
+
+   Frame relay over PW service is not intended to emulate the
+   traditional frame relay service perfectly, but it can be used for
+   applications that need frame relay transport service.
+
+   The following are notable differences between traditional frame relay
+   service and the protocol described in this document:
+
+   - Frame ordering can be preserved using the OPTIONAL sequence field
+     in the control word; however, implementations are not required to
+     support this feature.
+
+   - The Quality of Service model for traditional frame relay can be
+     emulated; however, this is outside the scope of this document.
+
+   - A Frame relay port mode PW does not process any frame relay status
+     messages or alarms as described in [Q922] [Q933]
+
+   - The frame relay BECN and FECN bit are transparent to the MPLS
+     network and cannot reflect the status of the MPLS network.
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 5]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   - Support for frame relay SVC and Switched Permanent Virtual Circuit
+     (SPVC) is outside the scope of this document.
+
+   - Frame relay Local Management Interface (LMI) is terminated locally
+     in the PE connected to the frame relay attachment circuit.
+
+   - The support of PVC link integrity check is outside the scope of
+     this document.
+
+6.  General Encapsulation Method
+
+   The general frame relay pseudowire packet format for carrying frame
+   relay information (user's payload and frame relay control
+   information) between two PEs is shown in Figure 2.
+
+              +-------------------------------+
+              |                               |
+              |    MPLS Transport header      |
+              |       (As required)           |
+              +-------------------------------+
+              |   Pseudowire (PW) Header      |
+              +-------------------------------+
+              |        Control Word           |
+              +-------------------------------+
+              |          FR Service           |
+              |           Payload             |
+              +-------------------------------+
+
+    Figure 2.  General format of frame relay encapsulation over PSN
+
+   The PW packet consists of the following fields: Control word and
+   Payload, preceded by the MPLS Transport and pseudowire header.  The
+   meaning of the different fields is as follows:
+
+   -i.    MPLS Transport header is specific to the MPLS network.  This
+          header is used to switch the PW packet through the MPLS core.
+
+   -ii.   PW header contains an identifier for multiplexing PWs within
+          an MPLS tunnel.
+
+   -iii.  Control Word contains protocol control information for
+          providing a frame relay service.  Its structure is provided in
+          the following sections.
+
+   -iv.   The content of the frame relay service payload field depends
+          on the mapping mode.  In general it contains the layer 2 frame
+          relay frame.
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 6]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+7.  Frame Relay over MPLS PSN for the One-to-One Mode
+
+7.1.  MPLS PSN Tunnel and PW
+
+   MPLS label switched paths (LSPs) called "MPLS Tunnels" are used
+   between PEs and are used within the MPLS core network to forward PW
+   packets.  An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.
+
+   Several PWs may be nested inside one MPLS tunnel.  Each PW carries
+   the traffic of a single frame relay VC.  In this case, the PW header
+   is an MPLS label called the PW label.
+
+7.2.  Packet Format over MPLS PSN
+
+   For the one-to-one mapping mode for frame relay over an MPLS network,
+   the PW packet format is as shown in Figure 3.
+
+    +-------------------------------+
+    |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
+    +-------------------------------+
+    |      PW label                 |  4 octets
+    +-------------------------------+
+    |       Control Word            |
+    |      (See Figure 4)           | 4 octets
+    +-------------------------------+
+    |            Payload            |
+    |      (Frame relay frame       |
+    |       information field)      | n octets
+    |                               |
+    +-------------------------------+
+
+          Figure 3.  Frame Relay over MPLS PSN Packet for the
+                     One-to-One Mapping
+
+   The meaning of the different fields is as follows:
+
+   - MPLS Tunnel label(s)
+
+     The MPLS Tunnel label(s) corresponds to the MPLS transport header
+     of Figure 2.  The label(s) is/are used by MPLS LSRs to forward a PW
+     packet from one PE to the other.
+
+   - PW Label
+
+     The PW label identifies one PW (i.e., one LSP) assigned to a frame
+     relay VC in one direction.  It corresponds to the PW header of
+     Figure 2.  Together the MPLS Tunnel label(s) and PW label form an
+     MPLS label stack [RFC3032].
+
+
+
+Martini & Kawa              Standards Track                     [Page 7]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   - Control Word
+
+     The Control Word contains protocol control information.  Its
+     structure is shown in Figure 4.
+
+   - Payload
+
+     The payload field corresponds to X.36/X.76 frame relay frame
+     information field with the following components removed: bit/byte
+     stuffing, frame relay header, and FCS.  It is RECOMMENDED to
+     support a frame size of at least 1600 bytes.  The maximum length of
+     the payload field MUST be agreed upon by the two PEs.  This can be
+     achieved by using the MTU interface parameter when the PW is
+     established.  [RFC4447]
+
+7.3.  The Control Word
+
+   The control word defined below is REQUIRED for frame relay one-to-one
+   mode.  The control word carries certain frame relay specific
+   information that is necessary to regenerate the frame relay frame on
+   the egress PE.  Additionally, the control word also carries a
+   sequence number that can be used to preserve sequentiality when
+   carrying frame relay over an MPLS network.  Its structure is 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 0|F|B|D|C|FRG|  Length   | Sequence Number               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 4.  Control Word structure for the one-to-one mapping mode
+
+   The meaning of the Control Word fields (Figure 4) is as follows (see
+   also [X36 and X76] for frame relay bits):
+
+   - Bits 0 to 3
+
+      In the above diagram, the first 4 bits MUST be set to 0 to
+      indicate PW data.
+
+   - F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
+
+   - B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
+
+   - D (bit 6) FR DE bit (Discard Eligibility) bit.
+
+   - C (bit 7) FR frame C/R (Command/Response) bit.
+
+
+
+Martini & Kawa              Standards Track                     [Page 8]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   - FRG (bits 8 and 9): These bits are defined by [RFC4623].
+
+   - Length (bits 10 to 15)
+
+      If the PW traverses a network link that requires a minimum frame
+      size (a notable example is Ethernet), padding is required to reach
+      its minimum frame size.  If the frame's length (defined as the
+      length of the layer 2 payload plus the length of the control word)
+      is less than 64 octets, the length field MUST be set to the PW
+      payload length.  Otherwise, the length field MUST be set to zero.
+      The value of the length field, if non-zero, is used to remove the
+      padding characters by the egress PE.
+
+   - Sequence number (Bit 16 to 31)
+
+      Sequence numbers provide one possible mechanism to ensure the
+      ordered delivery of PW packets.  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 that the sequence number check algorithm is not used.
+
+7.4.  The Martini Legacy Mode Control Word
+
+   For backward compatibility to existing implementations, the following
+   version of the control word is defined as the "martini mode CW" for
+   frame relay.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0 0 0 0|B|F|D|C|FRG|  Length   | Sequence Number               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 5.  Control Word structure for the frame relay martini mode
+
+   Note that the "B" and "F" bits are reversed.
+
+   This control word format is used for PW type "Frame Relay DLCI (
+   Martini Mode )"
+
+7.5.  PW Packet Processing
+
+7.5.1.  Encapsulation of Frame Relay Frames
+
+   The encapsulation process of a frame relay frame is initiated when a
+   PE receives a frame relay frame from one of its frame relay UNI or
+   NNI [FRF1] [FRF2] interfaces.  The PE generates the following fields
+
+
+
+
+Martini & Kawa              Standards Track                     [Page 9]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   of the control word from the corresponding fields of the frame relay
+   frame as follows:
+
+   - Command/Response (C/R or C) bit: The C bit is copied unchanged in
+     the PW Control Word.
+
+   - The DE bit of the frame relay frame is copied into the D bit field.
+     However, if the D bit is not already set, it MAY be set as a result
+     of ingress frame policing.  If it is not already set by the copy
+     operation, setting of this bit by a PE is OPTIONAL.  The PE MUST
+     NOT clear this bit (set it to 0 if it was received with the value
+     of 1).
+
+   - The FECN bit of the frame relay frame is copied into the F bit
+     field.  However, if the F bit is not already set, it MAY be set to
+     reflect a congestion situation detected by the PE.  If it is not
+     already set by the copy operation, setting of this bit by a PE is
+     OPTIONAL.  The PE MUST NOT clear this bit (set it to 0 if it was
+     received with the value of 1)
+
+   - The BECN bit of the frame relay frame is copied into the B bit
+     field.  However, if the B bit is not already set, it MAY be set to
+     reflect a congestion situation detected by the PE.  If it is not
+     already set by the copy operation, setting of this bit by a PE is
+     OPTIONAL.  The PE MUST NOT clear this bit (set it to 0 if it was
+     received with the value of 1).
+
+   - If the PW packet length (defined as the length of the payload plus
+     the length of the control word) is less than 64 octets, the length
+     field MUST be set to the packet's length.  Otherwise, the length
+     field MUST be set to zero.
+
+   - The sequence number field is processed if the PW uses sequence
+     numbers.  [RFC4385]
+
+   - The payload of the PW packet is the contents of ITU-T
+     Recommendations X.36/X.76 [X36] [X76] frame relay frame information
+     field stripped from any bit or byte stuffing.
+
+7.5.2.  Setting the Sequence Number
+
+   For a given PW and a pair of routers PE1 and PE2, if PE1 supports
+   packet sequencing, then the procedures in [RFC4385], Section 4.1,
+   MUST be followed.
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 10]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+7.6.  Decapsulation of PW Packets
+
+   When a PE receives a PW packet, it processes the different fields of
+   the control word in order to decapsulate the frame relay frame for
+   transmission to a CE on a frame relay UNI or NNI.  The PE performs
+   the following actions (not necessarily in the order shown):
+
+   - It generates the following frame relay frame header fields from the
+     corresponding fields of the PW packet.
+
+   - The C/R bit MUST be copied in the frame relay header.
+
+   - The D bit MUST be copied into the frame relay header DE bit.
+
+   - The F bit MUST be copied into the frame relay header FECN bit.  If
+     the F bit is set to zero, the FECN bit may be set to one, depending
+     on the congestion state of the PE device in the forward direction.
+     Changing the state of this bit by a PE is OPTIONAL.
+
+   - The B bit MUST be copied into the frame relay header BECN bit.  If
+     the B bit is set to zero, the BECN bit may be set to one, depending
+     on the congestion state of the PE device in the backward direction.
+     Changing the state of this bit by a PE is OPTIONAL.
+
+   - It processes the length and sequence field, the details of which
+     are in the following sub-sections.
+
+   - It copies the frame relay information field from the contents of
+     the PW packet payload after removing any padding.
+
+   Once the above fields of a FR frame have been processed, the standard
+   HDLC operations are performed on the frame relay frame: the HDLC
+   header is added, any bit or byte stuffing is added as required, and
+   the FCS is also appended to the frame.  The FR frame is then queued
+   for transmission on the selected frame relay UNI or NNI interface.
+
+7.6.1.  Processing the Sequence Number
+
+   If a router PE2 supports received sequence number processing, then
+   the procedures in [RFC4385], Section 4.2, MUST be used.
+
+7.6.2.  Processing of the Length Field by the Receiver
+
+   Any padding octet, if present, in the payload field of a PW packet
+   received MUST be removed before forwarding the data.
+
+   - If the Length field is set to zero, then there are no padding
+     octets following the payload field.
+
+
+
+Martini & Kawa              Standards Track                    [Page 11]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   - Otherwise, if the payload is longer, then the length specified in
+     the control word padding characters are removed according to the
+     length field.
+
+7.7.  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 Experimental Use
+   Bits (EXP) field of the PW MPLS label [RFC3032].  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.
+
+7.8.  MPLS Shim S Bit Value
+
+   The ingress LSR, PE1, MUST set the S bit of the PW label to a value
+   of 1 to denote that the PW label is at the bottom of the stack.
+
+7.9.  Control Plane Details for Frame Relay Service
+
+   The PE MUST provide frame relay PVC status signaling to the frame
+   relay network.  If the PE detects a service-affecting condition for a
+   particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA
+   FRF1.1, the PE MUST communicate to the remote PE the status of the PW
+   that corresponds to the frame relay DLCI status.  The Egress PE
+   SHOULD generate the corresponding errors and alarms as defined in
+   [Q922] [Q933] on the egress Frame relay PVC.
+
+   There are two frame relay flags to control word bit mappings
+   described below.  The legacy bit ordering scheme will be used for a
+   PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit
+   ordering scheme will be used for a PW of type 0x0019, "Frame Relay
+   DLCI".  The IANA allocation registry of "Pseudowire Type" is defined
+   in [RFC4446] along with initial allocated values.
+
+7.9.1.  Frame Relay Specific Interface Parameter Sub-TLV
+
+   A separate document, [RFC4447], describes the PW control and
+   maintenance protocol in detail, including generic interface parameter
+   sub-TLVs.  The interface parameter information, when applicable, MUST
+   be used to validate that the PEs and the ingress and egress ports at
+   the edges of the circuit have the necessary capabilities to
+   interoperate with each other.  The Interface parameter TLV is defined
+   in [RFC4447], and the IANA registry with initial values for interface
+   parameter sub-TLV types is defined in [RFC4446], but the frame relay
+   specific interface parameter sub-TLV types are specified as follows:
+
+   - 0x08 Frame Relay Header Length Sub-TLV
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 12]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+     An optional 16-bit value indicating the length of the FR Header,
+     expressed in octets.  This OPTIONAL interface parameter Sub-TLV can
+     have value of 2, 3, or 4, the default being 2.  If this Sub-TLV is
+     not present, the default value of 2 is assumed.
+
+8. Frame Relay Port Mode
+
+   The frame relay port mode PW shares the same encapsulation as the
+   HDLC PW and is described in the respective document.  [RFC4618]
+
+9.  Congestion Control
+
+   As explained in [RFC3985], the PSN carrying the PW may be subject to
+   congestion, the characteristics of which depend on PSN type, network
+   architecture, configuration, and loading.  During congestion, the PSN
+   may exhibit packet loss that will impact the service carried by the
+   frame relay PW.  In addition, since frame relay 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].  In the presence of services that reduce transmission
+   rate, frame relay PWs may thus consume more than their fair share and
+   in that case SHOULD be halted.
+
+   Whenever possible, frame relay 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 frame relay
+   PW's effects from neighboring streams.
+
+   Note that when transporting frame relay, DiffServ-enabled domains may
+   use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of
+   EF, in order to place less burden on the network and to gain
+   additional statistical multiplexing advantage.  In particular, if the
+   Committed Information Rate (CIR) of a frame relay VC is zero, then it
+   is equivalent to a best-effort UDP over IP stream regarding
+   congestion:  the network is free to drop frames as necessary.  In
+   this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a
+   diff-serv-TE domain.  Alternatively, if the CIR of a frame relay VC
+   is nonzero and the DE bit is zero in the FR header, then "AF31" would
+   be appropriate to be used, and if the CIR of a frame relay VC is
+   nonzero but the DE bit is on, then "AF32" would be appropriate
+   [RFC3270].
+
+   The PEs SHOULD monitor for congestion (by using explicit congestion
+   notification, [VCCV], or by measuring packet loss) in order to ensure
+   that the service using the frame relay PW may be maintained.  When a
+
+
+
+Martini & Kawa              Standards Track                    [Page 13]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   PE detects significant congestion while receiving the PW PDUs, the
+   BECN bits of the frame relay frame transmitted on the same PW SHOULD
+   be set to notify the remote PE and the remote frame relay switch of
+   the congestion situation.  In addition, the FECN bits SHOULD be set
+   in the FR frames sent out the attachment circuit, to give the FR DTE
+   a chance to adjust its transport layer advertised window, if
+   possible.
+
+   If the PW has been set up using the protocol defined in [RFC4447],
+   then procedures specified in [RFC4447] for status notification can be
+   used to disable packet transmission on the ingress PE from the egress
+   PE.  The PW may be restarted by manual intervention, or by automatic
+   means after an appropriate waiting time.
+
+10.  Security Considerations
+
+   PWE3 provides no means of protecting the contents or delivery of the
+   PW packets on behalf of the native service.  PWE3 may, however,
+   leverage security mechanisms provided by the MPLS Tunnel Layer.  A
+   more detailed discussion of PW security is given in [RFC3985,
+   RFC4447, RFC3916].
+
+11.  Normative References
+
+   [RFC4447] Martini, L., 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.
+
+   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+             Encoding", RFC 3032, January 2001.
+
+   [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+             Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+   [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis,
+             "Encapsulation Methods for Transport of Point to Point
+             Protocol/High-Level Data Link Control (PPP/HDLC) over
+             Multiprotocol Label Switching (MPLS) Networks", RFC 4618,
+             September 2006.
+
+   [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
+             Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August
+             2006.
+
+
+
+Martini & Kawa              Standards Track                    [Page 14]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+12.  Informative References
+
+   [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
+             (PWE3) Architecture", RFC 3985, March 2005.
+
+   [VCCV]    Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection
+             Verification (VCCV)", Work in Progress, October 2005.
+
+   [ATM]     Martini, L., et al., "Encapsulation Methods for Transport
+             of ATM Over MPLS Networks", Work in Progress, April 2005.
+
+   [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+             "Encapsulation Methods for Transport of Ethernet over MPLS
+             Networks", RFC 4448, April 2006.
+
+   [FRF1]    FRF.1.2, Frame relay PVC UNI Implementation Agreement,
+             Frame Relay Forum, April 2000.
+
+   [FRF2]    FRF.2.2, Frame relay PVC UNI Implementation Agreement,
+             Frame Relay Forum, April 2002
+
+   [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
+             Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
+             September 2004.
+
+   [X36]     ITU-T Recommendation X.36, Interface between a DTE and DCE
+             for public data networks providing frame relay, Geneva,
+             2000.
+
+   [X76]     ITU-T Recommendation X.76, Network-to-network interface
+             between public data networks providing frame relay
+             services, Geneva,2000
+
+   [Q922]    ITU-T Recommendation Q.922 Specification for Frame Mode
+             Basic call control, ITU Geneva 1995
+
+   [Q933]    ITU-T Recommendation Q.933 Specification for Frame Mode
+             Basic call control, ITU Geneva 2003
+
+   [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
+             2914, September 2000.
+
+   [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
+             P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
+             Protocol Label Switching (MPLS) Support of Differentiated
+             Services", RFC 3270, May 2002.
+
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 15]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+Contributing Author Information
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+   Giles Heron
+   Tellabs
+   Abbey Place
+   24-28 Easton Street
+   High Wycombe
+   Bucks
+   HP11 1NT
+   UK
+
+   EMail: giles.heron@tellabs.com
+
+
+   Rao Cherukuri
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+
+   Dimitri Stratton Vlachos
+   Mazu Networks, Inc.
+   125 Cambridgepark Drive
+   Cambridge, MA 02140
+
+   EMail: d@mazunetworks.com
+
+
+   Chris Liljenstolpe
+   Alcatel
+   11600 Sallie Mae Dr.
+   9th Floor
+   Reston, VA 20193
+
+   EMail: chris.liljenstolpe@alcatel.com
+
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 16]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   Nasser El-Aawar
+   Level 3 Communications, LLC.
+   1025 Eldorado Blvd.
+   Broomfield, CO, 80021
+
+   EMail: nna@level3.net
+
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: erosen@cisco.com
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: tappan@cisco.com
+
+
+   Prayson Pate
+   Overture Networks, Inc.
+   507 Airport Boulevard
+   Morrisville, NC, USA 27560
+
+   EMail: prayson.pate@overturenetworks.com
+
+
+   David Sinicrope
+   Ericsson IPI
+
+   EMail: david.sinicrope@ericsson.com
+
+
+   Ravi Bhat
+   Nokia
+
+   EMail: ravi.bhat@nokia.com
+
+
+   Nishit Vasavada
+   Nokia
+
+   EMail: nishit.vasavada@nokia.com
+
+
+
+Martini & Kawa              Standards Track                    [Page 17]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+   Steve Vogelsang
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+
+   EMail: stephen.vogelsang@ecitele.com
+
+
+   Vinai Sirkay
+   Redback Networks
+   300 Holger Way,
+   San Jose, CA 95134
+
+   EMail: sirkay@technologist.com
+
+Authors' Addresses
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Claude Kawa
+   OZ Communications
+   Windsor Station
+   1100, de la Gauchetie`re St West
+   Montreal QC Canada
+   H3B 2S2
+
+   EMail: claude.kawa@oz.com
+
+
+   Andrew G. Malis
+   Tellabs
+   1415 West Diehl Road
+   Naperville, IL  60563
+
+   EMail: Andy.Malis@tellabs.com
+
+
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 18]
+
+RFC 4619       Encapsulation for Transport of Frame Relay September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+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 provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Martini & Kawa              Standards Track                    [Page 19]
+