PWE3 Working Group Claude Kawa (Editor)
Internet Draft Ðcole Polytechnique
Expires: August 2004 Andrew G. Malis
Tellabs
Luca Martini
Steve Vogelsang Rao Cherukuri
Laurel Networks, Inc. Eric C. Rosen
Daniel Tappan
Cisco Systems, Inc.
Nasser El-Aawar David Sinicrope
Level 3 Communications, LLC Ericsson
Chris Liljenstolpe Prayson Pate
Cable & Wireless Overture Networks, Inc.
Steve Vogelsang
Laurel Networks, Inc
Kireeti Kompella
Juniper Networks
Dimitri Stratton Vlachos
Mazu Networks,Inc.
Giles Heron
PacketExchange Ltd.
Vinai Sirkay
Vivace Networks, Inc.
Ravi Bhat
Nishit Vasavada
Nokia
February 2004
Frame Relay over Pseudo-Wires
draft-ietf-pwe3-frame-relay-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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."
Kawa, et al. [Page 1]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright(C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines frame relay pseudo-wire emulation edge-to-edge.
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 IP and MPLS packet switched network (PSN).
Two mapping modes are defined: One-to-one mapping mode characterized
by a one to one relationship between a frame relay VC and a pair
of MPLS LSPs is defined for MPLS PSN. The other mode is known as port
mode or many-to-one mapping mode and is defined for MPLS PSN and IP
PSN with L2TPv3.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Requirements for Frame Relay Over Pseudo-wires. . . . . . . . 4
5. Reference model and PWE3 protocol layering . . . . . . . . . . 5
6. General encapsulation for the two mapping modes . . . . . . 8
7. Frame Relay over MPLS PSN for the one-to-one mapping mode. . . 9
8. FR SVC and SPVC Signalling between PEs. . . . . . . . . . . . 17
9. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 17
10. Frame relay port mode . . . . . . . .. . . . . . . . . . . . 17
11. Frame relay service over pseudo-wires. . . . . . . . . . . . .22
12. IANA considerations. . . . . . . . . . . . . . . . . . . . . .24
13. Security Considerations. . . . . . . . . . . . . . . . . . . 24
14. Supplement on frame relay frame formats. . . . . . . . . . . .25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
16. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 27
Conventions used in this document
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.
1. Introduction
This document defines frame relay pseudo-wire emulation edge-to-edge.
A frame relay pseudo-wire (PW) is a mechanism that exists between
provider's edge network nodes (PEs) and supports as faithfully as
Kawa, et al. [Page 2]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
possible frame relay services over IP and MPLS packet switched
network (PSN) using MPLS LSP [RFC3031, RFC3032] and L2TPv3 [L2TPv3]
tunnels for multiplexing purposes. L2TPv3 is used only with IP PSN in
this document.
The main functions required to support frame relay PW by a PE
include:
- Encapsulation of frame relay specific information in a suitable
frame relay over pseudo wire (FRoPW) packet,
- Transfer of a FRoPW packet across a PSN for delivery to a peer
PE,
- Extraction of frame relay specific information from a FRoPW
packet by the remote edge node,
- Generation of native frame relay frames for forwarding across an
egress port of the remote edge node,
- Execution of any other operations required to support frame
relay service.
Two mapping modes are defined between FR VCs and FR PWs: The first
one is called "one-to-one" mapping. because there is a one-to-one
correspondence between a FR VC and a pair of unidirectional PWs. The
second mapping is called "many-to-one" mapping or "port mode" because
multiple FR VCs assigned to a port are mapped to one pair of PWs.
One-to-one mapping mode is defined for MPLS PSN only and port mode is
defined for MPLS LSP and IP PSN with L2TPv3.
The main structure of this document is as follows: Section 4 lists
some important frame relay requirements to be met in a PWE3
environment. Section 5 is an overview of PWE3 reference model and PWE3
protocol layers described in [PWE3ARC]. Section 6 describes the generic
frame relay over pseudo-wire (FRoPW) packet format. Section 7
specifies frame relay over MPLS PSN for the one-to-one mapping
Section 8 just indicates that FR SVC and SPVC are not supported in
this document. Section 9 is about FR PVC provisioning. Section 10
describes FR port mode for MPLS PSN and IP PSN with L2TPv3. Finally,
Section 11 discusses the meaning of providing frame relay services in
the native and PWE3 environments and how faithfully/perfectly FR
service should be provided. A supplement on frame relay frame formats
appears in Section 14.
2. Terminology
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.
Kawa, et al. [Page 3]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
PWE3 definitions can be found in [PWE3REQ, PWE3ARC]. This section
defines terms specific to frame relay.
Backward direction: In frame relay it is the direction opposite to
the direction taken by a frame being forwarded
(see also forward direction).
Forward direction: In frame relay the reference used to
determine whether the direction of the traffic
is the forward or backward direction is the
frame being forwarded. The forward direction is
the direction taken by the frame being
forwarded.
3. Acronyms and Abbreviations
Bc Committed burst size
Be Excess burst size
BECN Backward Explicit Congestion Notification
CE Customer Edge
CIR Committed Information Rate
C/R Command/Response
DE Discard Eligibility
DLCI Data Link Connection identifier
FCS Frame Check Sequence
FECN Forward Explicit Congestion Notification
FR Frame Relay
FRoPW Frame Relay over Pseudo Wire
L2TP Layer 2 Tunneling Protocol
FRS Frame Relay Service
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 Pseudo-Wire
PWE3 Pseudo-Wire Emulation Edge to Edge
POS Packet over Sonet/SDH
PVC Permanent Virtual Circuit
QoS Quality of Service
SLA Service Level Agreement
SPVC Switched/Soft permanent virtual circuit
SVC Switched Virtual Circuit
UNI User-Network Interface
VC Virtual Circuit
4. Requirements for Frame Relay Over Pseudo-Wires
The section lists the main frame relay pseudo-wire requirements to
be met by a PE:
Kawa, et al. [Page 4]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
1. Frame Length: Should transport variable length FR frames
without being limited by the PSN MTU.
2. Bidirectional traffic: Must support bidirectional traffic.
3. Frame ordering: Must preserve FR frames order.
4. Transmission errors: Must detect (detectable) transmission
errors,
5. Control bits: Must support the transport of FR Discard
Eligibility (DE), Forward Explicit Congestion Notification
(FECN), Backward Explicit Congestion Notification (BECN) and
Command/Response (C/R) bits [X36, X76].
6. PVC Status Maintenance: Must support the mapping and transport
of frame relay PVC status indications defined in Recommendation
X.36 [X36]. The support of PVC link integrity check should be
provided. Note PVC status maintenance will be addressed in
another IETF draft.
7. Traffic Management: Should be able to map the following FR
traffic management parameters to PWs and tunnel traffic
parameters:
a) CIR (Committed Information Rate) or throughput,
b) Bc (Committed burst size),
c) Be (Excess Burst Size),
e) Maximum frame size.
8. Frame Priority and QoS: Should support the ability to map FR
transfer and discard priorities or QoS service classes defined
in [X36, X76] to appropriately engineered PWs and PSN tunnels.
9. Frame relay VC type: Must support PVC, support of SVC and SPVC
is optional.
5. Reference model and PWE3 protocol layering
5.1. Reference model
Figure 1 shows PWE3 reference model with additional frame relay
concepts. More details on the reference model can be found in
[PWE3REQ, PWE3ARC].
Kawa, et al. [Page 5]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
|<------ Pseudo-wires ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
FR +----+ +----+ FR
UNI or NNI | | PW1 | | UNI or NNI
+-----+ | | |==================| | | +-----+
| |----------| PE1| | PE2|----------| |
| CE1 | | | | | | | | CE2 |
| |----------| | PW2 | |----------| |
+-----+ | | |==================| | | +-----+
^ +----+ +----+ ^
| |
|<------------- Emulated Service ----------------->|
(i.e. FR PVC, SVC or SPVC)
Figure 1 - PWE3 Reference Model
Two mapping modes are defined between FR VCs and pseudo-wires:
- The first one is called "one-to-one" mapping. With one-to-one
mapping, for each frame relay VC, a pair of pseudo-wires (one
for each direction of the traffic) is established between a
pair of PEs.
- The second mapping is called "many-to-one" mapping or "port
mode": With this mapping multiple frame relay VCs related to a
port are assigned to one pair of pseudo-wires.
As specified later in this document, the encapsulation of frame
relay information is slightly different between the two mapping
modes.
5.2. Frame relay over PW and PWE3 protocol layering
This document supports MPLS PSN and IP PSN. With IP PSN, L2TPV3
[L2TPv3] is used for multiplexing purposes of a number of FR VCs
into one L2TPv3 tunnel. In addition, the one-to-one mapping mode
applies to frame relay over MPLS PSN only and the many-to-one
mapping mode applies to both frame relay over MPLS PSN and IP PSN
with L2TPv3. In terms of PWE3 protocol layering defined in [PWE3ARC],
we have the following two protocol stacks:
The first protocol stack is for the one-to-one mapping mode.
Kawa, et al. [Page 6]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+---------------------+
| Payload |
/=====================\
H Payload Convergence H-----------------+
H---------------------H |
H Timing (NIL) H |
H---------------------H |
H Sequencing H------------------------------------+
\=====================/ | |
| PW Demultiplexer |---+ | |
+---------------------+ | | |
| PSN Convergence |-----------------------+----+----+ |
+---------------------+ | | | | | |
| MPLS PSN |-+ | v v v v v
+---------------------+ | | +--------------------------------+
| MAC/Data-link | | | | Flags |Frag| Len |Seq # |
+---------------------+ | | +--------------------------------+
| Physical | | +->| Inner MPLS LSP/PW Label |
+---------------------+ | +--------------------------------+
+--->| Outer MPLS LSP Label |
+--------------------------------+
Control words
Figure 2- FR PWE3 over MPLS PSN for the one-to-one mapping mode
Notes: 1-For the one-to-one mapping mode only MPLS PSN is used in
this document and MPLS LSP labels are used for PW
demultiplexer.
2-The payload is a FR frame information field only with
bit/byte stuffing undone (byte stuffing is used only over
Sonet/SDH transmission facilities [FRF14]).Section 14
contains aa supplement on frame relay frame formats and
the description of the various fields.
3-Control words carrying different protocol control
information are used. They are described in subsequent
sections.
The second protocol stack is for the many-to-one mapping or port
mode.
Kawa, et al. [Page 7]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+---------------------+ +-------------------------+
| Payload |------------>|FR frame less flags & FCS|
/=====================\ +-------------------------+
H Payload Convergence H------------>| Nil |
H---------------------H +-------------------------+
H Timing H------------>| Nil |
H---------------------H +------------+------------+
H Sequencing H------------>| Pseudo-wire protocol |
\=====================/ +------------+------------+
| PW Demultiplexer |------------>| L2TPv3 | MPLS |
+---------------------+ +------------+------------+
| PSN Convergence |------------>| Nil | Nil |
+---------------------+ +------------+------------+
| PSN |------------>| IP | MPLS |
+---------------------+ +------------+------------+
| MAC/Data-link |------------>| MAC/Data-link |
+---------------------+ +-------------------------+
| Physical |------------>| Physical |
+---------------------+ +-------------------------+
Figure 3 - FR PWE3 protocol layers for port mode with IP and MPLS PSNS
Notes: 1-There are actually two instances of the protocol stack:
One for IP PSN and the other for MPLS PSN.
2-With IP PSN, L2TPv3 is used as PW demultiplexer.
3-With MPLS PSN, MPLS is used as PW demultiplexer.
4-The payload is a complete FR frame (see Section 14) with
the exception of HDLC opening and closing flags and the
Frame check sequence (FCS) and with bit/byte stuffing
undone.
5-Sequencing is provided by the PW protocol defined in this
document.
6. General encapsulation for the two mapping modes
The general frame relay over pseudo-wires (FRoPW) packet format
for carrying frame relay information (user's payload and frame
relay control information) between two PEs is shown in Figure 4.
Kawa, et al. [Page 8]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+-------------------------------+
| |
| PSN Delivery Header |
+-------------------------------+
| |
| PW Identifier header |
+-------------------------------+
| FRoPW Header |
| |
+-------------------------------+
| |
| Payload |
+-------------------------------+
| Pad (if requided) |
+-------------------------------+
Figure 4 - General format of FRoPW packet
The FRoPW packet format consits of the following fields: FRoPW Header, Payload and
Pad (if requided) preceded by the PSN delivery header and PW Identifier header.
The meaning of the different fields is as follows:
1. PSN delivery header is a header specific to the PSN and the
tunneling technology used (L2TP or MPLS) This header is used
to switch the FroPW packet through the packet switched core. It
is discussed in the following sub-sections addressing each type
of PSN and tunneling technology.
2. PW identifier header contains an identifier for multiplexing
PWs within a PSN tunnel.
3. FRoPW header contains protocol control information for
providing a frame relay service. Its structure is provided in
the following sections addressing each mapping mode.
4. The contents of the payload field depends on the mapping mode.
The details are provided in the following sections addressing
each mapping mode.
The Pad is used for the following reason: When a pseudo-wire
traverses a link that requires a minimum layer 2 frame length
(for example, Ethernet), padding characters are added at the
end of the FRoPW packet (i.e. after the payload field) to
produce the required minimum length.
7. Frame Relay over MPLS PSN for the one-to-one mapping mode
7.1. MPLS tunnel and VC LSPs
MPLS label switched paths (LSPs) called "Tunnel LSPs" are used
between PEs and within MPLS PSN core for forwarding purposes of
FRoPW packets. A tunnel LSP corresponds to a "PSN tunnel" of
Figure 1.
Several "Virtual Circuit LSPs" (VC LSPs) may be nested inside one
Tunnel LSP. Each VC LSP carries the traffic of a frame relay VC in
one direction. Since LSPs are unidirectional, a pair of VC LSPs
and corresponding tunnel LSPs carrying traffic in opposite
directions will be required.
Kawa, et al. [Page 9]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
In PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW
packets from PE1 to PE2,the corresponding LSP label is not related
to any frame relay VC. When PE1 has to forward a FRoPW packet to
PE2, it first pushes a VC label on its label stack, and then
pushes on a tunnel LSP label. The VC label must be always at the
bottom of the label stack. The VC label is not visible in the core
PSN, only the tunnel LSP label and possibly other labels used in
the core PSN for forwarding purposes until the FRoPW packet
reaches PE2. While the FRoPW packet travels across the MPLS
network, additional labels may be pushed on (and then popped off)
as needed. When PE2 receives a FRoPW packet, it forwards the
packet to the local CE based on the LSP VC label. The processing
is similar in the opposite direction from PE2 to PE1 with the
corresponding LSP used in the PE2 to PE1 forwarding direction.
7.2. Relationship between FR VCs and MPLS VC LSPs
Frame Relay VCs are considered to be bidirectional objects mainly
because of the way they are created and identified. A single frame
relay identifier (DLCI) refers to the two directions of a frame
relay VC and frame relay signalling establishes the two directions
simultaneously with the same message flows. In general each
direction of a frame relay VC may have different traffic and QoS
characteristics. The resource management of a frame relay
implementation treats each direction separately and independently.
MPLS LSPs, on the other hand LSPs are unidirectional and are
established separately. Therefore for each FR VC there will be, in
general, two VC LSPs such that each one will be assigned to carry
the traffic in a different direction from the other.
During the creation of a frame relay VC, a pair of VC LSPs will
have to be established between two PEs. For one end-to-end frame
relay VC two VC LSPs exist: One VC LSP to transport the traffic
from PE1 to PE2 and the other to transport the traffic in the
opposite direction. In the frame relay domain, a DLCI identifies a
frame relay VC and in the MPLS domain, VC LSP labels with possible
different values identify each VC LSP. This mapping between a FR
VC and a pair of MPLS LSPs corresponds to the one-to-one mapping
described in Section 5.
7.3. One-to-one mapping and FRoPW packet format over MPLS PSN
For the one-to-one mapping mode for frame relay over MPLS PSN, the
FRoPW packet format is shown in Figure 5.
Kawa, et al. [Page 10]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+-------------------------------+
| Tunnel LSP label(s) | n words (1 word per label)
+-------------------------------+
| VC LSP label | 1 word
+-------------------------------+
| FRoPW Header |
| (See Figure 6) | 1 word
+-------------------------------+
| Payload |
|(from a frame relay frame |
| information field) | N bytes
| |
+-------------------------------+
| Pad (if required) |
+-------------------------------+
Figure 5 - FR over MPLS packet format for the One-to-one mapping
It consits of the following fields: FRoPW Header, Payload and
Pad (if requided) preceded by the Tunnel LSP label(s) and VC LSP label.
The meaning of the different fields is as follows:
Tunnel LSP label(s):
The Tunnel LSP label(s) corresponds to the PSN delivery header
of Figure 4. The label(s) is/are used by MPLS PSN nodes to
forward a FRoPW packet from one PE to the other.
VC LSP Label:
The VC LSP label identifies one PW (i.e. one LSP) assigned to a
FR VC in one direction. It corresponds to the PW identifier
header of Figure 4. Together the Tunnel LSP label(s) and VC
LSP label form an MPLS label stack [RFC3032].
FRoPW header:
FRoPW header contains protocol control information. Its
structure is shown in Figure 6.
The above three headers were referred as "control words" in Figure 2.
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 |F|B|D|C|B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - FRoPW header structure for one-to-one mapping mode
The meaning of the fields of FRoPW packet header (Figure 6) is as
follows (see also [X36 and X76] for frame relay bits):
Res (bits 0 to 3):
Reserved bits. They are set to zero on transmission and
ignored on reception.
Kawa, et al. [Page 11]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
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 indicates the discard eligibility.
C (bit 7)
FR frame C/R (command/response) bit.
B, E (bits 8 and 9):
B and E are fragmentation bits and their functionality is
specified in [FRAG].
Length (bits 10 to 15):
The length field is used in conjunction with the padding of
short FRoPW packets when the link layer protocol requires a minimum
frame length.
If the total length of the FRoPW packet header plus the Payload
(see Figure 5) is less than 64 bytes, then the length field must be
set to the length of the FRoPW packet header plus the Payload,
otherwise the length field must be set to zero.
Sequence number (Bit 16 to 31):
If it is not used, it is set to zero by the sender and
ignored by the receiver. Otherwise it specifies the sequence
number of a FRoPW packet. A circular list of sequence
numbers is used. A sequence number takes a value from 1 to
65535 (2**16-1). Arithmetic modulo 2**16 is performed to
generate a new sequence number. The value of zero indicates
that the sequence number field is not used.
Payload:
The payload field corresponds to X.36/X.76 frame relay frame
information field with bit/byte stuffing removed. The
default for the number of bytes of the information field
is 262 bytes. It is recommended to support a
size of a least 1600 bytes. The maximum
length of the payload field should be agreed by the two PEs
when the VC LSP is established.
Kawa, et al. [Page 12]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
Pad:
The Pad consists of a number of characters (including zero
character) to bring the FRoPW packet size to the minimum
size required by the link layer protocol. Any 8-bit character
with a decimal value from 0 to 255 may be used as a padding
character.
7.4. FRoPW packet processing
7.4.1. Generation of FRoPW packets
The generation process of a FRoPW packet is initiated when a PE
receives a frame relay frame from one of its frame relay UNI or
NNI. The PE takes the following actions (not necessarily in the
order shown):
- It generates the following fields of FRoPW header 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 FRoPW header.
- Discard eligibility indicator (DE or D): The D bit is
set as follows in the FRoPW header: This bit, if used,
is set to 1 to indicate a request that a frame should
be discarded in preference to other frames in a
congestion situation.
Setting of this bit by a PE is optional. However, no PE
shall clear this bit (set it to 0 if it was received
with the value of 1). A PE that does not provide
discard eligibility notification shall pass this bit
unchanged. Networks are not constrained to discard only
frames with D = 1 in the presence of congestion.
- Forward explicit congestion notification (FECN or F
bit): FECN may be set by a congested PE to notify the
user that congestion avoidance procedures should be
initiated where applicable for traffic in the direction
of the FRoPW packet carrying the FECN.
This bit is set to 1 to indicate to the destination
that the frames it receives have encountered congested
resources. This bit may be used by a destination to
adjust its transmission rate.
While setting this bit by a PE is optional, no PE shall
clear this bit (set it to 0 if it was received with the
value of 1). PEs that do not provide FECN shall pass
this bit unchanged.
Kawa, et al. [Page 12]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
- Backward explicit congestion notification (BECN or B
bit): BECN follows the same processing rules as FECN,
except that it applies to the opposite direction.
- Length: See the following sub-section "Processing of
the Length field by the sender".
- Sequence number: See the sub-section "Processing of the
Sequence number field by the sende
- Payload and Pad:
The payload of the FRoPW 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. Padding characters may follow the
payload field; see the following sub-section on
"Processing of the length field by the sender".
Additional processing is performed by the lower protocol
layers in order to transmit the FroPW packet to its next
destination.
7.4.1.1. Processing of the length field by the sender
The procedure described here is used to determine whether
padding is required or not.
Let:
- Length_FRoPW_packet be the length in bytes of the
FRoPW header and Payload of a FRoPW packet
shown in Figure 5,
Length_field be the contents of the length field of
the FRoPW header,
- Min_length = 64 bytes
- Padding_length be the number (in bytes) of the
padding characters to be added.
The padding procedure is as follows:
If the link layer protocol does not have a minimum
length requirement then Length_field is set to zero
and no padding is required.
Else if Length_FRoPW_packet >= Min_length then
padding is not required; set Length_field to
zero.
Kawa, et al. [Page 13]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
Else padding is required and the following
performed:
Padding_length = Min_length -
Length_FRoPW_packet;
Append Padding-length characters at the end of
the FRoPW packet (after the payload field).
Length_field = length_FRoPW_packet.
End of the padding procedure.
7.4.1.2. Processing of the sequence number field by the sender
The sequence number field is set according to whether the
sequence number is used or not.
If the PE supports the sequence number capability then the
following procedure to number FRoPW packets is used:
- The initial packet transmitted on the frame relay PW
must use sequence number 1.
- For a subsequent packet, the sequence number
corresponds to the sequence number of the preceding
packet incremented by 1 modulo 2**16.
- When the sequence number reaches the maximum value
(65535) the next sequence number wrap to 1 (the value of
0 is skipped).
If the PE does not support sequence number processing,
then the sequence number field must be set to 0.
7.4.2. Reception of FRoPW packets
When a PE receives a FRoPW packet, it processes the different
fields of the FRoPW header in order to synthesize 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 FRoPW packet as follows:
- C/R bit is copied unchanged in the frame relay
header.
Kawa, et al. [Page 14]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
- D bit is copied as follows into the frame relay
header DE bit: If it was set to one in the incoming
FRoPW packet, it must be copied unchanged in the FR
frame header or, depending on the traffic policing
performed by the PE and it state of congestion, the
FRoPW packet may be dropped.
Otherwise if the D bit was set to zero, it may be set
to zero or one, depending on the traffic policing
performed by the PE device. Setting of this bit by a
PE is optional.
- The F bit is copied as follows in the frame relay
header FECN bit: If it was set to one in the incoming
FRoPW packet, it must be copied unchanged in the
frame relay header. Otherwise if it was set to zero,
it may be set to zero or one, depending on the
congestion state of the PE device in the forward
direction. Setting this bit by a PE is optional, if
the PE does not support FECN, it shall pass this bit
unchanged.
- BECN follows the same processing rules as FECN,
except that it applies to the opposite direction.
- It processes the length and sequence field, the
details are in the subsequent sub-sections.
- It generates the frame relay information field from
the contents of the FRoPW packet payload after
removing any padding character and retrieves the
appropriate DLCI.
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. The FR frame is queued for
transmission on the selected frame relay UNI or NNI.
7.4.2.1. Checking the sequence number by the receiving PE
If the receiving PE does not support sequence number
processing, then it will skip the processing of the sequence
number field.
If the receiving PE supports packet sequencing capability,
when a FRoPW packet is received the sequence number is
processed as follows:
- If the sequence number of the packet is 0, then the packet
passes the sequence number check. Note a sequence number
equal to 0 means that the sender does not support the use
of sequence number.
Kawa, et al. [Page 15]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
- Otherwise if the packet sequence number >= the expected
sequence number and the packet sequence number - the
expected sequence number < 32768, then the packet is in
order.
- Otherwise if the packet sequence number < the expected
sequence number and the expected sequence number - the
packet sequence number >= 32768, then the packet is in
order.
- Otherwise the packet is out of order.
If the packet is in order, then it passes the sequence
number check and the expected sequence number is set as per
the following assignment:
expected_sequence_number := packet_sequence_number + 1
mod 2**16. If (expected_sequence_number = 0) then
expected_sequence_number := 1.
FRoPW packets which are received out of order are silently
discarded. As an option, a PE may buffer out of order FRoPW
packets to re-order and deliver them in order.
Re-ordering FRoPW packets is an implementation option but
requires that the sender numbers FRoPW packets.
7.4.2.2. Processing of the length field by the receiver
Any padding character, if present, in a FRoPW packet received must
be removed before forwarding the data to the next destination.
The procedure described here is used to remove padding characters.
Let:
- Length_FRoPW_packet be the total length of the following
packet fields: FRoPW Header, Payload and Pad,
- Length_field be the contents of the length field of
the FRoPW header of the packet received,
- Padding_length be the length of the pad to be removed
from the end of the payload field.
Padding removal procedure:
If Length_field is set to zero then there is no padding
characters following the payload field
Else padding characters are included and their length is
computed as follows:
Kawa, et al. [Page 16]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
Padding_length = Length_FRoPW_packet - Length_field;
Remove Padding-length characters from the end of the
FRoPW payload field.
End of the padding removal procedure.
7.5. Handling of error conditions
If a PE receives a FRoPW packet with errors, it shall discard it
silently.
8. FR SVC and SPVC Signalling between PEs
Not supported in this document.
9. FR PVC provisioning
Provisioning of FR PVCs requires the following actions: The PEs and
CEs are configured independently for each FR UNI or NNI PVC segments.
Some of the configuration parameters may include:
- Outgoing and incoming throughputs (CIR),
- Outgoing and incoming committed burst sizes (Bc),
¹ - Outgoing and incoming excess burst sizes (Be),
- Outgoing and incoming maximum frame lengths,
- The DLCI assigned to the FR PVC locally,
- If used, FR transfer and discard priority class or FR service
class [X36, X76] assigned to the FR VC.
To complete the FR VC, a PW (i.e. a pair VC LSP) is established
between the two PEs. Establishment of FR PW will be addressed in the
future.
10. Frame relay port mode
10.1. General
Frame relay port mode or many-to-one mapping is an optional
capability. It applies to both MPLS and L2TPv3 pseudo-wires.
Figure 7 illustrates the concept of frame relay port mode.
Kawa, et al. [Page 17]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+------+ +-------+
| FR | | FR |
|device| FR UNI/NNI | device|
| [P1]------------------------[P2] |
| | carrying n FR VC | |
+------+ | +-------+
|
[Pn]: A port |
| (a) FR interface between two
| FR devices
|
|
V
|<---------------------------->|
| |
+----+ +----+
+------+ | | One PW pair | | +------+
| | | |==================| | | |
| FR | FR | PE1| carrying n FR VC | PE2| FR | FR |
|device|----------| | | |---------|device|
| CE1 | UNI/NNI | | | | UNI/NNI | CE2 |
+------+ +----+ +----+ +------+
| |
|<----------------------------------------------->|
n FR VC
(b) Pseudo-wires replacing the FR interface
Figure 7 - Concept of frame relay port-to-port mode
Figure 7 (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 7 (b) shows the
replacement of the physical frame relay interface with a pair of
PEs and a pair of PWs (one PW for each traffic direction between
PE1 and PE2). A PW may be an MPLS VC LSP or a L2TPv3 tunnel. 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 (cf. Figure
7 (a)) are mapped now to one pair of PWs, hence with port mode we
have many-to-one mapping between FR VCs and a PW.
FR VCs are not visible individually to a PE, there is no
configuration of individual FR VC in a PE. A PE processes the set
of FR VCs assigned to a port as an aggregate. FR traffic and QoS
parameters listed in Section 9 may be assigned to the aggregate
traffic flowing on an interface between a CE and a PE and not to
individual FR VC and policing may be performed on the aggregate.
FR port mode provides transport between two PEs of a complete FR
frame excluding the opening and closing flags and the Frame check
Kawa, et al. [Page 18]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
sequence (FCS) and with bit/byte stuffing undone.
For more information, on FR frame formats the reader should
consult Section 14 and [X36, X76].
10.2. FRoPW packet format for MPLS port mode
When MPLS PW is used with port mode, the FRoPW packet format is
shown in Figure 8.
+-------------------------------+
| Tunnel LSP label(s) | n words (1 word per label)
+-------------------------------+
| VC LSP label | 1 word
+-------------------------------+
| FRoPW Header |
| | 1 word
+-------------------------------+
| Payload |
| (See Figure 8) | N bytes
| and a Pad (if needed) |
+-------------------------------+
Figure 8- FR over MPLS packet format for the port mode mapping
Tunnel LSP label(s) role is as specified for the one-to-one
mapping.
The VC LSP label identifies one PW (i.e. one LSP) assigned to
one port for a set of FR VCs using that port. There is a pair
of VC LSPs for the two traffic directions.
Kawa, et al. [Page 19]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
FRoPW header: FRoPW header contains protocol control
information. Its structure is shown in Figure 9. Frame relay
control bits (F, B, D and C) are not used and are set to zero.
Note it is possible to apply FECN, BECN and DE bits (bits 4, 5
and 6) to the aggregate traffic but this use of the indicators
requires further study.
The use of the fragmentaiton bits (B and E) 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
not one for each individual FR VC. To compute the FRoPW packet size to
determine whether padding is needed or not, the format of Figure 8 is used.
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|B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - FRoPW header structure for the port mode mapping
The payload field contains a FR frame as shown in Figure 8
extracted from an incoming FR frame received from a CE and
padding characters if needed (see section 6 for the need to
pad).
The two peer PEs must agree on the length of the DLCI field (2
or 4 bytes) and the maximum length of FR frame information
field. These are signaled during Pseudo-Wire setup using two
interface parameters [CONTROL, PWE3IANA]:
0x01 Interface MTU in octets
0x08 Frame-Relay DLCI Length
The default for the number of bytes in a frame relay information
field is 262 bytes. It is recommended to support a size of a least
1600 bytes.
10.3. FRoPW packet format for L2TPv3 port mode
When L2TPv3 PW is used with port mode, the FRoPW packet format
is shown in Figure 10. This format is imported from [L2TPv3
Figure 3.2.2] and is very similar to FRoPW general packet
format of Figure 4.
Kawa, et al. [Page 20]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Delivery Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Tunnel Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunneled L2 Frame (See Figure 9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 - FR over L2TPv3 packet format for the port mode mapping
PSN delivery header:
The PSN delivery header serves the same role as the PSN
delivery header of Figure 4. When the PSN is an IP network,
the PSN delivery header is an IP v4 or v6 datagram header.
L2TP Tunnel header:
L2TP Tunnel header corresponds to the PW identifier header
of Figure 4. There are two formats for L2TP Tunnel header
defined in [L2TPv3]: One when L2TPv3 runs over IP directly
and another one for L2TPv3 over UDP. The two formats are
shown in Figure 11 (a) and (b). The description of the
various fields can be found in [L2TPv3]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
: Cookie (optional, maximum 64 bits) :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) L2TPv3 over IP Tunnel Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (optional, maximum 64 bits)... :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(b) L2TPv3 over UDP Tunnel Header
Figure 11 - L2TPv3 over IP and UDP Tunnel Header
Kawa, et al. [Page 21]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
L2-Specific Sublayer:
L2-Specific Sublayer header shown in Figure 10 is analogous
to FRoPW header of Figure 4. With L2TPv3 the same FRoPW
header defined in Figure 9 for MPLS port mode is used also
with L2TPv3. Although L2TPv3 draft defines a default L2-
Specific Sublayer header, it is advantageous to use the same
FRoPW header structure with the different types of pseudo-
wires and the two mapping modes.
It should be possible to add to the FRoPW header of Figure
10 in the next version of this draft the other fields (P, S
and Offsz) defined in for L2-Specific Sublayer default
header [L2TPv3].
Tunneled L2 Frame:
The Tunneled L2 Frame of Figure 10 corresponds to the
payload of the general FRoPW format shown in Figure 4. This
field is used to carry a FR frame as shown in Figure 8.
Therefore for both MPLS and L2TPv3 used with FR port mode,
the payload of the FRoPW packet is the same and consists of
a frame relay frame, excluding the flags and the FCS, with
bit/byte stuffing undone.
10.4. FRoPW processing for 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 fields shown in Figure 8 are encapsulated in
a FRoPW packet payload to be forwarded to the remote PE. A PE
shall not modify any of the fields shown in Figure 8, they
shall be forwarded to the remote PE as received from the FR
device.
The processing of the length and sequence number fields is the
same as for the one-to-one mapping, with the following
exceptions mentionned earlier: There is one sequence number
counter for the set of FR VCs and not one for each individual
FR VC. To compute the FRoPW packet size to determine whether
padding is needed or not, the format of Figure 8is used.
Upon receiving a FRoPW packet, the remote PE shall extract the
payload field, encapsulate the result in a FR frame for
transmission to the local FR device.
11. Frame relay service over pseudo-wires
Frame relay service (FRS) is defined in terms of a number of
attributes in ITU-T Recommendation [X36]. The most t
wo fundamental aspects of FRS are:
1-The requirement to deliver in order the user's data between
two frame relay service access point,
2-The detection of transmission errors if they are detectable.
Kawa, et al. [Page 22]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
Besides the above two service attributes, FRS is defined by a number
of traffic and QoS attributes in ITU-T Recommendations
[X36 and X76] and in the Frame Relay Forum Implementation
Agreement FRF.13 [FRF13]. The following is a partial list
illustrating some of frame relay service attributes:
- Committed information rate
- Excess information rate
- Committed burst size
- Excess burst size
- transit delay
- Frame delivery ratio
- Service availability
FR service providers use FRS attributes to define Service Level
Agreements (SLA). A frame relay SLA are contractual and binding
agreement describing the FRS service providers offer to their
customers.
An important question to ask is: What does it mean to offer a frame
relay service? It means that the two fundamental attributes of FRS
about in-sequence delivery and error detection must be satisfied by
a network providing a frame relsy service.
The other FRS attributes related to QoS and traffic are a matter of
business decision because a multitude of possibilities are available
to service providers. In one extreme, a service provider may offer a
FRS with very stringent characteristics and in the opposite case, it
will not provide any guarantee and provides just a best effort
service.
If we ask the previous question in the context of PWE3, we must first
observe that PWE3 does not require that pseudo-wires emulate
perfectly or faithfully the characteristics of the native service. In
the case of FRS this means that the requirements to deliver in
sequence the user's data and to detect transmission errors may be
relaxed.
For both the one-to-one mapping mode and many-to-one mapping/port
mode, we have the following emulation possibilities with regard to
the two main attributes of FRS:
- In-sequence delivery of user's data:
1-It is possible to emulate perfectly/faithfully this
requirement. If the PSN does not guarantee in sequence
delivery, the PEs should use the sequence number capability
included in FRoPW packets to number the packets and check
whether they are received in sequence or not.
Kawa, et al. [Page 23]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
2-Alternatively a service provider may elect to drop the
requirement to deliver in-sequence FRoPW packets. This
document does not recommend this practice unless for a
good reason.
- Detection of transmission errors:
This requirement must be supported. PW layer does not have
the capability to detect transmission errors but rely on the
underlying link layer protocol for transmission error
detection.
About FRS traffic and QoS parameters, there is no strict requirements
to meet. Frame relay traffic and QoS attributes defined in the
relevant FR documents allow service providers to offer various
combinations of traffic and QoS parameters without imposing any
strict performance objective. The same thing should be possible in a
PWE3 network environment and it is not relevant to refer to how
faithful/perfect FRS traffic and QoS attributes are provided because
of the wide spectrum of possibilities.
There is one additional note to add about FR port mode. Since the
individual FR VCs are not visible to the PEs individually but only as
an aggregate, the frame relay service, and in particular, the traffic
and QoS parameters, provided to the CEs does not apply to the
individual FR VCs assigned to a port but to their aggregate.
12. IANA considerations
Not applicable to this document.
13. Security considerations
PWE3 provides no means of protecting the contents or delivery of the
FRoPW 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 [PWE3ARC, PWE3REQ].
Kawa, et al. [Page 24]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
14. Supplement on frame relay frame formats
FR frame formats are defined in ITU-T Recommendation X.36 [X36].
Two formats are used in this document. The first one uses 10 bits
for the DLCI (Figure 12-a) and the second one uses 23 bits for the
DLCI (Figure 12-b).
The first and last octets are HDLC opening and closing flags. The
DLCI occupies the second and third octets or the second, third,
fourth and fifth octets as shown in Figure 12. There are various
control fields:
C/R is HDLC command and response bit.
F and B are respectively the forward and backward congestion
notification bits.
DE is the discard eligibility bit.
FCS is the frame check sequence. Two generator polynomials are
used. One produces a 16-bit sequence [X36] and the other a 32-bit
sequence [FRF14].
bit 8 7 6 5 4 3 2 1 bit 8 7 6 5 4 3 2 1
+-------------------------------+ +-------------------------------+
| Flag | | Flag |
| 0 1 1 1 1 1 1 0 | | 0 1 1 1 1 1 1 0 |
+-------------------------------+ +-------------------------------+
| Upper DLCI |C/R| 0 | | Upper DLCI |C/R| 0 |
+------------------------------- +-------------------------------+
| Lower DLCI | F | B | DE| 1 | | DLCI | F | B | DE| 0 |
+-------------------------------+ +-------------------------------+
| | | DLCI | 0 |
:Frame relay information field : +-------------------------------+
: (i.e.payload) : | Lower DLCI | 0 | 1 |
| | +-------------------------------+
+-------------------------------+ | Frame relay information field |
| FCS (2 or 4 octets) | : (i.e. payload) :
| | : :
+-------------------------------+ | |
| Flag | +-------------------------------+
| 0 1 1 1 1 1 1 0 | | FCS (2 or 4 octets) |
+-------------------------------+ : :
+-------------------------------+
| Flag |
| 0 1 1 1 1 1 1 0 |
+-------------------------------+
a-With 10 bits for the DLCI b-With 23 bits for the DLCI
Figure 12 - Frame relay frame formats
Kawa, et al. [Page 25]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
15. References
[CONTROL] Luca Martini, et al., Pseudowire Setup and Maintenance
using LDP, ddraft-ietf-pwe3-control-protocol-05.txt,
June 2004, work in progress.
[DIX] Digital, Intel and Xerox, The Ethernet, a local Area
Network Data Link and Physical layer Specifications
versions 1 and 2.
[I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer
service, Geneva, October 1991.
[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
[FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement,
Frame Relay Forum, January 2000.
[FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement,
Frame Relay Forum, January 2000.
[FRF13] FRF.13, Service Level Definition Implementation
Agreement, Frame Relay Forum, August 1998.
[FRF14] FRF.14, Physical layer Implementation Agreement, Frame
Relay Forum, December 1998.
[FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and
Reassembly, draft-ietf-pwe3-fragmentation-04.txt,
October 2003, work in progress.
[L2TPV3] M. Townsley, et al., Layer Two Tunneling Protocol
(Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp-base-11.txt,
October 2003, work in progress..
[P8021Q] IEEE Std 802.1Q, Virtual bridged local area networks.
[P8023] IEEE Std 802.3, Part 3 Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical
layer specifications.
[PWE3IANA] Luca Martini, et al., IANA Allocations for pseudo
Wire Edge to Edge Emulation (PWE3),
draft-ietf-pwe3-iana-allocation-02.txt, October 2003,
work in progress.
[PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3-
requirements-08.txt, work in progress.
[PWE3ARC] Stewart Bryant, et al.,Internet draft, PWE3 Architecture,
draft-ietf-pwe3-arch-06.txt, work in progress.
Kawa, et al. [Page 26]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
[RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding,
January 2001.
[RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January
2001.
[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.
16. Author's Addresses
Claude Kawa
Ecole Polytechnique Montreal
email: claude.kawa@sympatico.ca
Andrew G. Malis
Tellabs
e-mail: andy.malis@tellabs.com
Rao Cherukuri
Cisco SYstems
email: rcheruku@cisco.com
David Sinicrope
Ericsson IPI
email: david.sinicrope@ericsson.com
Prayson Pate
Overture Networks
P. O. Box 14864
RTP, NC, USA 27709
email: prayson.pate@overturenetworks.com
Ravi Bhat
Nokia
email: ravi.bhat@nokia.com
Kawa, et al. [Page 27]
Internet Draft draft-ietf-pwe3-frame-relay-02.txt February 2004
Nishit Vasavada
Nokia
email: nishit.vasavada@nokia.com
Luca Martini
Cisco Systems Inc.
lmartini@cisco.com
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
e-mail: nna@level3.net
Giles Heron
Tellabs
e-mail: giles.heron@tellabs.com
Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140
e-mail: d@mazunetworks.com
Dan Tappan
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
e-mail: tappan@cisco.com
Eric Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
e-mail: erosen@cisco.com
Steve Vogelsang
Laurel Networks, Inc.
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
e-mail: sjv@laurelnetworks.com
Vinai Sirkay
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
e-mail: sirkay@technologist.com
Chris Liljenstolpe
Cable & Wireless
11700 Plaza America Drive
Reston, VA 20190
e-mail: chris@cw.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net
Kawa, et al. [Page 28]
