summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4619.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4619.txt')
-rw-r--r--doc/rfc/rfc4619.txt1067
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]
+