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.
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;
- 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].
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
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.
- 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.
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].
- 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.
- 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
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.
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