One document matched: draft-ietf-pwe3-frame-relay-03.txt
Differences from draft-ietf-pwe3-frame-relay-02.txt
PWE3 Working Group Claude Kawa
Internet Draft Ðcole Polytechnique
Expires: January 2005 Rao Cherukuri
Cisco Systems, Inc.
(Editors)
Andrew G. Malis
Tellabs
Luca Martini
Cisco Systems, Inc.
David Sinicrope
Ericsson
August 2004
Frame Relay over Pseudo-Wires
draft-ietf-pwe3-frame-relay-03.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."
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 (2004). All Rights Reserved.
Kawa, et al. [Page 1]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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. 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, and is defined for MPLS PSN only. The second mode
is known as port mode or many-to-one mapping mode and is defined for both
MPLS PSNs and IP PSNs with L2TPv3.
Co-authors
The following are co-authors of this document:
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
Nasser El-Aawar Level 3 Communications, LLC
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Requirements for Frame Relay Over Pseudo-wires. . . . . . . . 5
5. Reference model and PWE3 protocol layering . . . . . . . . . . 5
6. General encapsulation for the two mapping modes . . . . . . 7
7. Frame Relay over MPLS PSN for the one-to-one mapping mode. . . 8
8. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 16
9. Traffic management aspects 16
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. . . . . . . . . . . .24
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 27
Kawa, et al. [Page 2]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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
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.
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 addresses FR PVC provisioning. Section 9 covers the traffic
management aspects. Section 10 describes FR port mode for MPLS PSN and
IP PSN with L2TPv3. 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.
Kawa, et al. [Page 3]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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.
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
Kawa, et al. [Page 4]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
4. Requirements for Frame Relay Over Pseudo-Wires
The section lists the main frame relay pseudo-wire requirements to
be met by a PE:
1. Frame Length: MUST be able to transport variable length FR
frames and SHOULD be able to transport FR frames without being
limited by the PSN MTU through the use of PW fragmentation [FRAG].
2. Bidirectional traffic: MUST support bidirectional traffic.
3. Frame ordering: MUST deliver frame relay frames in the order.
as they were transmitted.
4. 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].
5. PVC Status Maintenance: MUST support the mapping and transport
of frame relay PVC status indications defined in ITU-T
Recommendation X.36 [X36]. Note PVC status signaling will be
addressed in another IETF draft.
6. Traffic Management: SHOULD be able to map the following FR
traffic management parameters to PWs and tunnel traffic
parameters:
a) Committed Information Rate (CIR) or throughput,
b) Committed burst size (Bc),
c) Excess Burst Size (Be),
d) Maximum frame size.
7. 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.
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-03.txt August 2004
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
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, 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.
One-to-one mapping mode is defined for MPLS PSNs only and port mode is
defined for both MPLS PSN and IP PSN with L2TPv3.
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 PSNs and IP PSNs. With IP PSNs, 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 PSNs and IP PSNs
with L2TPv3. In terms of PWE3 protocol layering defined in [PWE3ARC],
this specification utilizes the protocol stack shown in Figure 2.
Kawa, et al. [Page 6]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
+-------------+ +-------------+
| Emulated | | Emulated |
| Frame Relay | Emulated Service | Frame Relay |
| Services |<==============================>| Services |
| | | |
+-------------+ Pseudo Wire +-------------+
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS or IP |<==============================>| MPLS or IP |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
PE1 PE2
Figure 2: Frame Relay PWE3 Protocol Stack Reference Model
For the purpose of this document, PE1 is defined as the ingress
router, and PE2 as the egress router. A layer 2 PDU received
at PE1, will be encapsulated at PE1, transported, decapsulated at PE2,
and transmitted out of PE2.
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 3.
+-------------------------------+
| |
| PSN Transport header |
| (As required) |
+-------------------------------+
| Pseudo Wire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
| Pad (if required) |
+-------------------------------+
Figure 3 - General format of FR encapsulation over PSN
Kawa, et al. [Page 7]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
The FRoPW 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:
1. PSN Transport header is 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 described
in the following sub-sections addressing each type of PSN and
tunneling technology.
2. PW header contains an identifier for multiplexing PWs within a
PSN tunnel.
3. Control Word 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 FR service 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 octets 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 the MPLS PSN core network for forwarding purposes
of FRoPW packets. A tunnel LSP corresponds to "PSN transport" 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, and frame relay VCs are
bidirectional, a pair of VC LSPs and corresponding tunnel LSPs carrying
traffic in opposite directions will be required.
Kawa, et al. [Page 8]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
In the PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW
packets from PE1 to PE2, and the tunnel LSP label is not related
to any particular 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 is at the bottom of
the label stack. As with the other PWE3 encapsulations, 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 signaling establishes the two directions
simultaneously with a single set of control messages 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 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 single direction.
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 4.
Kawa, et al. [Page 9]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
+-------------------------------+
| Tunnel LSP label(s) | n*4 octets (four octets per label)
+-------------------------------+
| VC LSP label | 4 octets
+-------------------------------+
| Control Word |
| (See Figure 5) | 4 octets
+-------------------------------+
| Payload |
| (Frame relay frame |
| information field) | n octets
| |
+-------------------------------+
| Pad (if required) |
+-------------------------------+
Figure 4 - FR Over MPLS Packet Format for the One-to-One Mapping
The encapsulation consists of the following fields: Control Word,
Payload and Pad (if required), 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 transport header
of Figure 3. 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
header of Figure 3. Together the Tunnel LSP label(s) and VC
LSP label form an MPLS label stack [RFC3032].
Control Word:
Control Word contains protocol control information. Its
structure is shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F|B|D|C|I|L| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Control Word structure for the one-to-one mapping mode
Kawa, et al. [Page 10]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
The meaning of the Control Word fields (Figure 5) is as
follows (see also [X36 and X76] for frame relay bits):
MBZ (bits 0 to 3):
Reserved bits. They are set to zero on transmission and
ignored on reception.
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.
I, L (bits 8 and 9):
I and L are the Initial and Last fragmentation bits and their
functionality is specified in [FRAG].
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 total length of FRoPW payload, which is the sum of the
lengths of the control word and Payload fields is less than 64 octets,
then padding has to be performed. In this case length field MUST be
set to the FRoPW 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 ingress PE.
Sequence number (Bit 16 to 31):
Sequence numbers provide one possible mechanism to ensure the
ordered delivery of FRoPW packets. A circular list
of sequence numbers is used, skipping the value zero. The value of
zero indicates that the sequence number field is not used. See
section 7.4 for the sequence number generation and checking
algorithms.
Kawa, et al. [Page 11]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
Note: The use of sequence numbers may not be required if the network
itself ensures ordered delivery of FRoPW packets.
Payload:
The payload field corresponds to X.36/X.76 frame relay frame
information field with bit/byte stuffing and frame relay header
(DLCI)removed.
It is RECOMMENDED to support a frame size of at least 1600 bytes.
The maximum length of the payload field MUST be agreed by the two
PEs when the VC LSP is established.
Pad:
The Pad consists of a number of octets (including zero
octet) required to guarantee that the FRoPW packet size
is not less than 64 packets. Any octet with a decimal
value from 0 to 255 may be used as a padding character.
Note: The limit of 64 octets for the packet length below which
padding is required, aligns with the minimum Ethernet
frame size.
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 interfaces. The PE takes the following actions (not necessarily
in the order shown):
- It 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 FRoPW Control Word.
- Discard eligibility indicator (DE or D): The D bit is
set as follows in the Control Word: 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. This bit is often set as a result of
ingress frame policing.
Setting of this bit by a PE is OPTIONAL. However, no PE
SHALL ever 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.
- 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 Control Word carrying the FECN.
Kawa, et al. [Page 12]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
While setting this bit by a PE is OPTIONAL, PE MUST not
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.
- Backward explicit congestion notification (BECN or B
bit): BECN follows the same processing rules as FECN,
except that it applies to the backward direction.
- Length: If the FRoPW 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
and padding has to be performed. Otherwise the length field
MUST be set to zero.
- Sequence number: The sequence number field is set if the FR PW
uses sequence numbers.
If the ingress PE supports the sequence number capability then
the following procedure to number FRoPW packets is used:
- The initial FRoPW packet transmitted MUST use sequence
number 1,
- For a subsequent frame, the sequence number corresponds
to the sequence number of the preceding frame incremented
by 1 up to the maximum value of 65535,
- When the sequence number reaches the maximum 16 bit value
(65535) the next sequence number wraps to 1 (the value of
0 is skipped).
If the FR PW uses sequence numbers do not support sequence
number processing, then the sequence number field must be set
to 0.
- 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.
Additional processing is performed by the lower protocol layers in
order to transmit the FRoPW packet to its next destination.
Kawa, et al. [Page 13]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
7.4.2. Reception of FRoPW packets
When a PE receives a FRoPW packet, it processes the different
fields of the control word 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.
- D bit is copied unchanged into the frame relay
header DE bit.
- The F bit is processed as follows: If it was set
to one in the incoming FRoPW packet, it must be
copied unchanged into the FECN bit in the frame relay
header.
Otherwise if it was set to zero, the FECN bit may be
set to one, depending on the congestion state of the PE
device in the forward direction. Setting this bit by a
PE is OPTIONAL.
- BECN follows the same processing rules as FECN,
except that it applies to the backward direction.
- 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 FRoPW 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.
7.4.2.1. Checking the Sequence Number by the Receiving PE
When an emulated VC is initially set up, the "expected sequence
number" associated with it MUST be initialized to 1.
When a FRoPW packet is received the sequence number is processed
as follows:
Kawa, et al. [Page 14]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
- 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 sequence
numbers are not used. Through management or signaling,
the two PEs determine whether sequence numbers are used
or not.
- 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, up to a
maximum of 65535 after which it skips zero and wraps from 6553 to
1.
If (expected_sequence_number = 0) then expected_sequence_number
:= 1.
FRoPW packets that are received out of order should be dropped
unless they can be re-ordered without introducing significant
delays.
If an egress PE receives an excessive number of out-of-sequence
FroPW packets, it SHOULD inform the management plane responsible
for FRoPW in the PE and take the appropriate actions. The
threshold for declaring that out-of-sequence FRoPW packets are
excessive is not defined in this document.
Note: Excessive out-of-sequence FRoPW packets has an effect
similar to excessive packet loss on a frame relay VC.
7.4.2.2. Processing of the Length Field by the Receiver
Any padding octet, if present, in the payload field of a
FroPW packet received MUST be removed before forwarding the
data.
Kawa, et al. [Page 15]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
The procedure described here is used to remove padding
characters.
If the Length field is set to zero then there are no padding
Characters following the payload field.
Else padding characters are removed based on the Length field.
7.5. Handling of error conditions
If a PE receives a FRoPW packet with a header containing invalid
contents, it shall be discarded. For example:
- An invalid or unassigned tunnel or VC label,
- A value different than zero for the first four bits of the
Control Word,
- A length field with a content greater or equal to 64,
- Inconsistencies between the content of the length field and the
actual size of the FRoPW packet.
- If fragmentation is not used a value different than zero for the
two fragmentation bits(bits 8 and 9 of the FRoPW header).
8. 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 the FR PW is addressed in [CONTROL].
9. Traffic management aspects
In ITU-T Recommendations X.36 and X.146, a number of different traffic
parameters and Quality of Service (QoS) classes are defined. When a
tunnel LSP is used to carry either a single frame relay VC or
multiple frame relay VCs with different combinations of traffic
parameters and QoS classes, the tunnel LSP shall be capable of
providing the required QoS for the encapsulated frame relay VCs.
In an MPLS network that does only support QoS differentiation on a
per LSP basis, the tunnel LSP shall meet the most stringent QoS
requirements of the frame relay VCs carried by that tunnel LSP.
Kawa, et al. [Page 16]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
9.1. Use of Differentiated Services for Frame relay over MPLS:
If the MPLS network supports Differentiated Services (DiffServ)
Behavior Aggregates defined in informational RFCs 2475 and 3260,
MPLS packets can be treated with different priorities on a Per Hop
Behavior (PHB). In this case, two different types of LSPs are defined
in RFC 3270 which can both be used for the tunnel LSP:
- Label-Only-Inferred-PSC LSPs (L-LSP);
- EXP-Inferred-PSC LSPs (E-LSP).
If a L-LSP is used as a tunnel LSP, the PHB scheduling class of each
packet is inferred from the label without any other information
(e.g., regardless of the EXP field value). In that case, the LSP shall
meet the most stringent QoS requirements of the frame relay VCs tunneled
by the LSP.
If an E-LSP is used as a tunnel LSP, the EXP field of the tunnel label
is used to determine the PHB to be applied to each packet, i.e.,
different packets in one LSP may receive a different QoS. The 3-bit EXP
field of the tunnel label can represent eight different combinations of
Per Hop Behaviour (PHB) and drop precedence levels. The mapping of the
PHB to EXP fields is either explicitly signaled at label set-up or
relies on a pre-configured mapping.
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 6 illustrates the concept of frame relay port mode.
Figure 6 (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 6 (b) shows the replacement of the physical frame relay interface
with a pair of PEs and a PW between them. 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 which
are controlled by the same signaling channel using DLCI=0 (cf. Figure
7 (a)), are mapped into one PW. Hence with port mode we have many-to-one
mapping between FR VCs and a PW.
Kawa, et al. [Page 17]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
+------+ +-------+
| FR | | FR |
|device| FR UNI/NNI | device|
| [P1]------------------------[P2] |
| | carrying n FR VCs | |
+------+ | +-------+
|
[Pn]: A port |
| (a) FR interface between two
| FR devices
|
V
|<---------------------------->|
| |
+----+ +----+
+------+ | | One PW pair | | +------+
| | | |==================| | | |
| FR | FR | PE1| carrying n FR VCs| PE2| FR | FR |
|device|----------| | | |---------|device|
| CE1 | UNI/NNI | | | | UNI/NNI | CE2 |
+------+ +----+ +----+ +------+
| |
|<----------------------------------------------->|
n FR VCs
(b) Pseudo-wires replacing the FR interface
Figure 6 - Concept of frame relay port-to-port mode
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 8 may be assigned to the aggregate
traffic flowing on an interface between a CE and a PE and not to
individual FR VCs 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
Sequence (FCS) and with bit/byte stuffing undone.
For more information on FR frame formats the reader should
consult Section 14 and [X36, X76].
Kawa, et al. [Page 18]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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 7.
+-------------------------------+
| Tunnel LSP label(s) | n*4 octets (four octets per label)
+-------------------------------+
| VC LSP label | 4 octets
+-------------------------------+
| Control Word |
| (see Figure 8) | 4 octets
+-------------------------------+
| Payload |
| (FR Address plus |
| information field) | N octets
| and a Pad (if needed) |
+-------------------------------+
Figure 7- 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 the PW assigned to the port for a set
of FR VCs using that port. There is a pair of VC LSPs for the two
traffic directions.
Control Word: The Control Word contains protocol control
information. Its structure is shown in Figure 8. Frame relay
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. 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|I|L| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 - Control Word structure for the port mode mapping
Kawa, et al. [Page 19]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
The payload field contains a FR frame received from a CE consists of
the address field (including the DLCI and the control bits) and
information field, with the opening and closing flags, bit/byte
stuffing and FCS 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. These are signaled during Pseudo-Wire setup using two
interface parameters [CONTROL, PWE3IANA]:
10.3. FRoPW packet format for L2TPv3 port mode
When an L2TPv3 PW is used with port mode, the FRoPW packet format
is shown in Figure 9. This format is imported from [L2TPv3
Figure 3.2.2] and is very similar to the packet format of Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN transport Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Tunnel Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunneled L2 Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - FR over L2TPv3 packet format for the port mode mapping
PSN transport header:
The PSN transport header is the PSN transport header of Figure 3.
When the PSN is an IP network, this header is an IP v4 or v6
datagram header.
L2TP Tunnel header:
L2TP Tunnel header corresponds to the PW header
of Figure 3. 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 9 (a) and (b). The description of the
various fields can be found in [L2TPv3].
Kawa, et al. [Page 20]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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 10 - L2TPv3 over IP and UDP Tunnel Header
L2-Specific Sublayer:
L2-Specific Sublayer header shown in Figure 9 is analogous
to the Control Word of Figure 3. With L2TPv3 the same Control Word
defined in Figure 8 for MPLS port mode is used also
with L2TPv3.
Tunneled L2 Frame:
The Tunneled L2 Frame of Figure 9 corresponds to the
payload of the general FRoPW format shown in Figure 3. 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.
Kawa, et al. [Page 21]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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 frame (excluding the flags and the FCS) is
encapsulated in a FRoPW packet payload 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 FRoPW packet, the remote PE shall extract the
FRoPW 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 two 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.
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.
Kawa, et al. [Page 22]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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 relay service.
The other FRS attributes related to QoS and traffic are a matter of
business decisions 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.
2-Alternatively a service provider MAY elect to drop the
requirement to deliver in-sequence FRoPW packets. In general,
this practice is NOT RECOMMENDED, since it may adversely affect
the applications in the CEs
- Detection of transmission errors:
This requirement MUST be supported. The PW layer does not have
the capability to detect transmission errors but relies on the
underlying link layer protocol for transmission error
detection.
Regarding 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 objectives. 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.
Kawa, et al. [Page 23]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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
No IANA actions are required in 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].
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 11-a) and the second one uses 23 bits for the
DLCI (Figure 11-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 11. 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].
Kawa, et al. [Page 24]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
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 11 - Frame relay frame formats
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.
Kawa, et al. [Page 25]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
[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-07.txt, work in progress.
[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.
Kawa, et al. [Page 26]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
16. Author's Addresses
Claude Kawa
Ecole Polytechnique Montreal
claude.kawa@sympatico.ca
Andrew G. Malis
Tellabs
andy.malis@tellabs.com
Rao Cherukuri
Cisco Systems
rcheruku@cisco.com
David Sinicrope
Ericsson IPI
david.sinicrope@ericsson.com
Prayson Pate
Overture Networks
prayson.pate@overturenetworks.com
Ravi Bhat
Nokia
ravi.bhat@nokia.com
Nishit Vasavada
Nokia
nishit.vasavada@nokia.com
Luca Martini
Cisco Systems Inc.
lmartini@cisco.com
Nasser El-Aawar
Level 3 Communications, LLC.
nna@level3.net
Giles Heron
Tellabs
giles.heron@tellabs.com
Dimitri Stratton Vlachos
Mazu Networks, Inc.
d@mazunetworks.com
Dan Tappan
Cisco Systems, Inc.
tappan@cisco.com
Kawa, et al. [Page 27]
Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004
Eric Rosen
Cisco Systems, Inc.
erosen@cisco.com
Steve Vogelsang
Laurel Networks, Inc.
sjv@laurelnetworks.com
Vinai Sirkay
Reliance Infocomm
vinai@sirkay.com
Chris Liljenstolpe
Cable & Wireless
chris@cw.net
Kireeti Kompella
Juniper Networks
kireeti@juniper.net
Kawa, et al. [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-21 11:03:11 |