Network Working Group Luca Martini
Internet Draft Cisco Systems, Inc.
Expiration Date: August 2005 Claude Kawa
Andrew Malis Oz Communications
Tellabs
February 2005
Encapsulation Methods for Transport of Frame Relay Over MPLS Networksdraft-ietf-pwe3-frame-relay-04.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
A frame relay pseudo-wire is a mechanism that exists between a
provider's edge network nodes and support as faithfully as possible
frame relay services over MPLS packet switched network (PSN). Two
mapping modes are defined. The first, one-to-one mapping mode, is
characterized by a one to one relationship between a frame relay VC
and a pair of MPLS LSPs. The second mode is known as port mode or
Martini, et al. [Page 1]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 2005
Figure 1: PWE3 frame relay PVC Interface Reference Configuration
Two mapping modes are defined between FR VCs and pseudo-wires: The
first one is called "one-to-one" mapping, because there is a one-to-
one correspondence between a FR VC and one Pseudo Wire. The second
mapping is called "many-to-one" mapping or "port mode" Because
multiple FR VCs assigned to a port are mapped to one Pseudo Wire. As
specified later in this document, the encapsulation of frame relay
information is slightly different between the two mapping modes.
5. General encapsulation method
The general frame relay pseudo wire packet format for carrying frame
relay information (user's payload and frame relay control
information) between two PEs is shown in Figure 2.
+-------------------------------+
| |
| PSN Transport header |
| (As required) |
+-------------------------------+
| Pseudo Wire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
Figure 2 - General format of FR encapsulation over PSN
The PW packet consists of the following fields: Control word, Payload
and Pad (if required) preceded by PSN Transport and pseudo-wire
header. The meaning of the different fields is as follows:
-i. PSN Transport header is specific to the PSN, in this case
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
a PSN tunnel.
-iii. Control Word contains protocol control information for
providing a frame relay service. Its structure is provided
in the following sections addressing each mapping mode.
Martini, et al. [Page 6]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 2005
-iv. The contents of the FR service payload field depends on the
mapping mode. The details are provided in the following
sections addressing each mapping mode.
6. Frame Relay over MPLS PSN for the One-to-One Mode6.1. MPLS PSN Tunnel and PW
MPLS label switched paths (LSPs) called "PSN Tunnels" are used
between PEs and within the MPLS PSN core network for forwarding
purposes of PW packets. A MPLS tunnel corresponds to "PSN transport"
of Figure 1.
Several "Pseudo-Wires" may be nested inside one PSN tunnel. Each PW
carries the traffic of a single frame relay VC.
7. Details Specific to Particular Emulated Services7.1. Frame Relay
When emulating a frame relay service, the Frame Relay PDUs are
encapsulated according to the procedures defined herein. 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 [ITUQ] 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 [ITUQ] 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)", while 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 [IANA] along with initial allocated
values.
7.2. Frame-Relay Specific Interface Parameters
This field specifies interface specific parameters. When applicable,
it 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 [CONTROL], the IANA registry with initial values for interface
parameter types is defined in [IANA], but the frame relay specific
Martini, et al. [Page 7]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 2005
- D (bit 6) FR DE bit (Discard Eligibility) bit.
- C (bit 7) FR frame C/R (Command/Response) bit.
- Res (bits 8 and 9): These bits are reserved and MUST be set to
0 upon transmission and ignored upon reception.
- Length (bits 10 to 15)
If the Pseudo Wire 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.5. 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|Res| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the "B" and "F" bits are reversed.
Martini, et al. [Page 10]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 20057.6. PW packet processing7.6.1. Generation of PW packets
The generation process of a PW packet is initiated when a PE receives
a frame relay frame from one of its frame relay UNI or NNI
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 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 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 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 FR PW uses sequence
numbers.
- 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.6.2. Setting the sequence number
For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
frame sequencing then the following procedures should be used:
Martini, et al. [Page 11]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 2005
- the initial frame transmitted on the PW MUST use sequence number
1
- subsequent frames MUST increment the sequence number by one for
each frame
- when the transmit sequence number reaches the maximum 16 bit
value (65535) the sequence number MUST wrap to 1
If the transmitting router PE1 does not support sequence number
processing, then the sequence number field in the control word MUST
be set to 0.
7.7. Reception of PW packets
When a PE receives a PW packet, it processes the different fields of
the control word in order to generate a new frame relay frame for
transmission to a CE on a FR UNI or NNI. The PE performs the
following actions (not necessarily in the order shown):
- It generates the following FR frame header fields from the
corresponding fields of the PW packet.
- The C/R bit is copied in the frame relay header.
- The D bit is copied into the frame relay header DE bit.
- The F bit is 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 is 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 subsequent sub-sections.
- It generates 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 generated, the FCS
has to be computed, HDLC flags have to be added and any bit or
byte stuffing has been performed (these final actions typically
take place in a hardware framer). The FR frame is queued for
transmission on the selected frame relay UNI or NNI interface.
Martini, et al. [Page 12]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 20057.7.1. Processing the sequence number
If a router PE2 supports receive sequence number processing, then the
following procedures should be used:
When a PW is initially set up, the "expected sequence number"
associated with it MUST be initialized to 1.
When a frame is received on that PW, the sequence number should be
processed as follows:
- if the sequence number on the frame is 0, then the sequence
number check is skipped. ( sequence check disabled )
- otherwise if the frame sequence number >= the expected sequence
number and the frame sequence number - the expected sequence
number < 32768, then the frame is in order.
- otherwise if the frame sequence number < the expected sequence
number and the expected sequence number - the frame sequence
number >= 32768, then the frame is in order.
- otherwise the frame is out of order.
If a frame passes the sequence number check, or is in order then, it
can be delivered immediately. If the frame is in order, then the
expected sequence number should be set using the algorithm:
expected_sequence_number := frame_sequence_number + 1 mod 2**16
if (expected_sequence_number = 0) then expected_sequence_number := 1;
Packets which are received out of order MAY be dropped or reordered
at the discretion of the receiver.
If a PE router negotiated not to use receive sequence number
processing, and it received a non zero sequence number, then it
SHOULD send a PW status message indicating a receive fault, and
disable the PW.
If an egress PE receives an excessive number of out-of-sequence PW
packets, it SHOULD inform the management plane responsible for PW
setup/maintenance, and take the appropriate actions. The threshold
for declaring that out-of-sequence PW packets are excessive is not
defined in this document.
Martini, et al. [Page 13]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 20057.7.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
Characters following the payload field.
- Else if the payload is longer then the length specified in the
control word padding characters are removed based on the length
field.
8. Frame Relay Port Mode8.1. General Description
Editor's note: Frame relay port mode will be removed from this
document in the next revision.
Figure 5 illustrates the concept of frame relay port mode or many-
to-one mapping which is an OPTIONAL capability.
Figure 5 (a) shows two frame relay devices physically connected with
a frame relay UNI or NNI. Between their two ports P1 and P2, n frame
relay VCs are configured.
Figure 5 (b) shows the replacement of the physical frame relay
interface with a pair of PEs and a PW between them. The interface
between a FR device and a PE is either a FR UNI or NNI. The set of n
FR VCs between the two FR ports P1 and P2 which are controlled by the
same signaling channel using DLCI=0, are mapped into one PW. Hence
with port mode we have many-to-one mapping between FR VCs and a PW.
Martini, et al. [Page 14]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 2005
+-------------------------------+
| MPLS Tunnel label(s) | n*4 octets (four octets per label)
+-------------------------------+
| PW label | 4 octets
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| Payload |
| (FR Address plus |
| information field) | N octets
| and a Pad (if needed) |
+-------------------------------+
Figure 6- PW packet format for frame relay port mode.
The OPTIONAL Control Word for frame relay port mode is show below.
Control bits 4 to 7 (F, B, D and C) are not used and are set to zero.
The use of the fragmentation bits (I and L) is the same as for the
one-to-one mapping. The use of the length and sequence number fields
is the same as for the one-to-one mapping, with the following
exceptions: There is one sequence number counter for the set of FR
VCs and not one for each individual FR VC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res |0|0|0|0|Res| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload field of a frame relay port mode PW contains a FR frame
which consists of the address field (including the DLCI and the
control bits) and information field. The HDLC opening and closing
flags, bit/byte stuffing and FCS are removed.
The two peer PEs MUST agree on the length of the DLCI field (2 or 4
octets) and the maximum length of FR frame information field. The
DLCI can be negotiated by a signaling protocol as in [CONTROL].
Martini, et al. [Page 16]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 20058.3. PW packet processing for frame relay port mode
When a PE receives a FR frame from a FR device (a CE), it shall
remove the flags, undo bit/byte stuffing and check the FCS field to
determine whether transmission errors occurred or not. If
transmission errors occurred, the frame is discarded. Otherwise, the
FR frame (excluding the flags and the FCS) is encapsulated in a PW
packet to be forwarded to the remote PE.
The processing of the length and sequence number fields is the same
as for the one-to-one mapping, with the following exceptions
mentioned earlier: There is one sequence number counter for the set
of FR VCs and not one for each individual FR VC.
Upon receiving a PW packet, the remote PE shall extract the PW
payload field, encapsulate the result in a HDLC frame for
transmission to the local FR (CE) device.
8.4. MPLS Shim EXP Bit Values
If it is desired to carry Quality of Service information, the Quality
of Service information SHOULD be represented in the EXP field of the
PW MPLS label. If more than one MPLS label is imposed by the ingress
LSR, the EXP field of any labels higher in the stack SHOULD also
carry the same value.
8.5. 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.
9. IANA Considerations
This document has no IANA Actions.
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 PSN Tunnel Layer. A more
detailed discussion of PW security is give in [RFC3985, PWE3REQ].
Martini, et al. [Page 17]

Internet Draft draft-ietf-pwe3-frame-relay-04.txt February 200511. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
12. Intellectual Property Statement
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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Martini, et al. [Page 18]