Internet Draft
Liwen Wu
Alcatel, USA
Pierrick Cheval
Alcatel, USA
Pasi Vaananen
Nokia
Francois le Faucheur
Cisco Systems, Inc.
Bruce Davie
Cisco Systems, Inc.
Internet Draft
Expires: December, 1999
Document: draft-ietf-mpls-diff-ext-01.txt June, 1999
MPLS Support of Differentiated Services by ATM LSRs
and Frame Relay LSRs
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.
Abstract
This document proposes a solution for MPLS to support Differentiated
Services (Diff-Serv) over ATM LSRs and Frame Relay LSRs. It proposes
corresponding updates to the current MPLS LDP and MPLS RSVP messages
for LSP establishment.
In brief, we propose to use LSPs where the Behavior Aggregate's
scheduling treatment is inferred by the LSR from the packet's label
value (VCI/DLCI) while the Behavior Aggregate's drop precedence is
indicated in the ATM/FR selective discard CLP/DE field.
1 Introduction
Wu, et. al 1
MPLS Support of DiffServ over ATM/FR June 99
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
common path, a Label Switched Path (LSP) can be established using
MPLS signalling protocols. At the ingress Label Switch Router (LSR),
each packet is assigned a label and is transmitted downstream. At
each LSR along the LSP, the label is used to forward the packet to
the next hop.
[MPLS_ATM] and [MPLS_FR] provides detailed description of how ATM
and FR Switches can be used as MPLS LSRs and how LSPs are
established and used by those ATM LSRS and FR LSRs.
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the
IP packets crossing a link and requiring the same Diff-Serv behavior
are said to constitute a Behavior Aggregate. At the ingress node the
packets are classified and marked with a Diff-Serv Code Point (DSCP)
which corresponds to their Behavior Aggregate [DIFF_HEADER]. At each
transit node, the destination address is used to decide the next hop
while the DSCP is used to select the Per Hop Behavior (PHB) that
determines the queuing treatment and, in some cases, drop
probability for each packet.
This document proposes a solution for supporting the Behavior
Aggregates, whose corresponding PHBs are currently defined (in
[DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS ATM or MPLS Frame
Relay network, i.e., an MPLS network implemented using ATM of Frame
Relay switches.
1.1 Ordering Constraints, "Scheduling Aggregate (SA)" and "Per Hop
Scheduling (PHS)"
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
different packets of the microflow contain different AF codepoints
of the same AF class).
For the sake of generality, we define a set of Behavior Aggregates
which share such an ordering constraint to constitute a "Scheduling
Aggregate" (SA). The mechanisms described in this draft aim, in
particular, to preserve the correct ordering relationships for
packets that belong to a given SA.
We refer to the set of one or more PHBs applied to the set of
Behavior Aggregates forming a given SA, as a "Per Hop Scheduling"
(PHS).
The PHBs currently specified are Default PHB (DF), Class Selector
PHB group (CSx), Assured Forwarding PHB group (AFxy), Expedited
Forwarding PHB (EF).
1.1.1 DF PHS
Wu et. al 2
MPLS Support of DiffServ over ATM/FR June 99
The Default PHB is a single PHB specified in [DIFF_Header]. Thus,
the corresponding PHS comprises a single PHB and thus coincides with
the DF PHB.
1.1.2 CSn PHS
[DIFF_HEADER] defines up to 8 CS Codepoints referred to as CSn,
where 1 <= n <= 8. [DIFF_HEADER] states that "... PHBs selected by
distinct Class Selector Codepoints SHOULD be independently
forwarded; that is, packets marked with different Class Selector
Codepoints MAY be re-ordered". Thus, there is one PHS corresponding
to each CSn PHB. Each CSn PHS comprises a single PHB and thus
coincides with this CSn PHB.
1.1.3 AFCn PHS
As described in [DIFF_AF], the Assured Forwarding (AF) PHB group
provides forwarding of IP packets in N independent AF classes.
Within each AF class, an IP packet is assigned one of M different
levels of drop precedence. An IP packet that belongs to an AF class
i and has drop precedence j is marked with the AF codepoint AFij,
where 1 <= i <= N and 1 <= j <= M. Currently, four classes (N=4)
with three levels of drop precedence in each class (M=3) are
defined for general use.
[DIFF_AF] states that "a DS node does not reorder IP packets of the
same microflow if they belong to the same AF class" (even if
different packets of the microflow contain different AF codepoints
of the same AF class). As noted above, each AF class in the AF PHB
group is the primary example of a PHS. Each PHS comprises 3 PHBs and
coincides with the AF Class. Those PHSs are thus referred to as
AFCn, where 1 <= n <= 4.
1.1.4 EF PHS
[DIFF_EF] defines the Expedited Forwarding (EF) PHB for traffic
requiring forwarding with low loss, low latency, low jitter.
[DIFF_EF] defines a single PHB. Thus, the corresponding PHS
comprises a single PHB and thus coincides with the DF PHB.
1.1.5 Summary list of PHS
The following PHSs have thus been identified:
- DF
- CSn , 1 <= i <= 8
- AFCn, 1 <= i <= 4
- EF
1.2 LSP Establishment for Diff-Serv over ATM/FR MPLS
Recognizing that
Wu et. al 3
MPLS Support of DiffServ over ATM/FR June 99
- the MPLS Header of MPLS switched packets is generally not
visible to ATM and Frame Relay MPLS LSRs since it is encapsulated
"inside" the ATM or FR LSP "connection";
- MPLS Diff-Serv assumes a similar architecture to non-MPLS
Diff-Serv whereby the appropriate forwarding/prioritisation is to be
performed at every hop (ie every MPLS LSR, including ATM LSR and FR
LSR) in accordance to the packet's Behavior Aggregate.
- ATM and Frame Relay switching hardware is generally capable
of selecting different scheduling behaviors (eg. Queues) for
cells/frames belonging to different connections but is generally not
capable of selecting different scheduling behaviors for cells/frames
belonging to the same ATM/Frame Relay connection;
- ATM and Frame Relay switching hardware is capable of
maintaining the order of all packets or cells sent on a single
connection;
- ATM and Frame Relay switching hardware is generally capable
of enforcing different drop priorities within a single connection
via standardized technology-specific selective drop mechanisms (Cell
Loss Priority - CLP- for ATM and Discard Eligible - DE- for Frame
Relay);
we propose that
- all packets belonging to a single SA and the same Forwarding
Equivalence Class (FEC) be sent down a single LSP;
- one LSP be established per pair (rather than simply
one LSP per FEC as in a network that does not support Diff-Serv).
Such an LSP is referred to as a "Label-inferred-PHS" LSP or "L-LSP";
- packets from multiple BAs of a given SA be granted a
different drop precedence through mapping into the layer 2 specific
selective discard indicator (CLP bit with ATM, DE bit with FR).
MPLS specifies how LSPs can be established via multiple signaling
protocols. Those include the Label Distribution Protocol (LDP),
RSVP, BGP and PIM. This Internet-Draft proposes below the required
extensions to LDP and RSVP to allow establishment of one L-LSP per
pair over ATM MPLS and FR MPLS.
For the purpose of meeting some specific Traffic Engineering goals,
we note that:
- SAs supported by separate L-LSPs may be Traffic Engineered
separately. A path is selected independently for each SA (eg by
Constraint Based Routing or by explicit configuration) and the
Wu et. al 4
MPLS Support of DiffServ over ATM/FR June 99
corresponding L-LSPs are then established independently via RSVP or
CR-LDP signaling;
- SAs supported by separate L-LSPs may be Traffic Engineered
jointly. A path is selected for the aggregate of all the considered
SAs and the L-LSPs are then established independently along the same
common path via RSVP or CR-LDP signaling;
1.3 Explicit Congestion Notification
Explicit Congestion Notification is described in [ECN] and is
proposed as an Experimental extension to the IP protocol. Because
ECN is still at the Experimental stage and its impact and
interactions with Diff-Serv have not yet been specified, this
Internet-Draft does not discuss ECN operations. Support for
simultaneous Diff-Serv and ECN over MPLS is left for further study.
1.4 Label Forwarding for Diff-Serv over ATM/FR MPLS
In order to describe Label Forwarding by Diff-Serv LSRs, we propose
to model a Diff-Serv label switching behavior as comprising three
stages:
-A- incoming PHB and FEC determination
-B- Optional outgoing PHB determination via Local Policy and
Traffic Conditioning
-C- Outgoing EXP field and label determination
The Diff-Serv LSR SHALL apply the scheduling/dropping behavior
corresponding to the "Outgoing PHB" in compliance with the
corresponding Diff-Serv PHB specification.
With such a model, we expect that "Diff-Serv over MPLS" label
forwarding can be specified (from the Diff-Serv viewpoint)
separately for each method (eg. Diff-Serv over MPLS over ATM/FR,
Diff-Serv over MPLS over PPP using L-LSPs [MPLS_DIFF_PPP], Diff-Serv
over MPLS over PPP using E-LSPs [MPLS_DIFF_PPP]) by specifying -A-
and -C- for the considered method without having to specify the
complete label switching behavior (A+B+C) for every possible
incoming/outgoing combination.
This model is used below for specifying LSR Label Forwarding over
ATM/FR using L-LSPs for Diff-Serv support over MPLS.
1.5 Relationship with [MPLS_DIFF_PPP]
The procedures described in this Internet Draft to establish and use
L-LSPs to achieve support of Diff-Serv over MPLS over ATM and FR,
are identical to the procedures described in [MPLS_DIFF_PPP] for L-
LSPs as one method to achieve support of Diff-Serv over MPLS over
PPP.
Note that a single method (based on L-LSPs) is proposed in this
Internet Draft for support of Diff-Serv over MPLS over ATM/FR while
Wu et. al 5
MPLS Support of DiffServ over ATM/FR June 99
[MPLS_DIFF_PPP] defines two methods for support of Diff-Serv over
MPLS over PPP. The other method described in [MPLS_DIFF_PPP] to
achieve support of Diff-Serv over MPLS over PPP relies on E-LSPs. E-
LSPs require that different packets of the same LSP be given
different scheduling treatment by the LSR which is generally
incompatible with existing ATM/FR hardware capabilities.
2. Label Forwarding for Diff-Serv over ATM/FR MPLS
2.2.1 Incoming PHB and FEC Determination On Ingress ATM/FR L-LSP
When receiving an ATM/FR call/frame containing a labeled packet over
an L-LSP of an MPLS ATM ingress interface:
If the LSR is a Frame LSR (ie Egress Edge of the ATM/FR MPLS cloud),
the LSR:
- determines the FEC based on the incoming label
- determines the PHS from the incoming label among the set of
LSPs established for that FEC
- determines the incoming PHB from the PHS and the EXP field of
the top level label entry of the encapsulated label stack in
accordance with the PHS/EXP-->PHB mapping defined in section 2.3 of
[MPLS_DIFF_PPP]
If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
ATM/FR MPLS cloud), the LSR:
- determines the FEC based on the incoming VCI/DLCI
- determines the PHS from the incoming VCI/DLCI among the set
of LSPs established for that FEC
- determines the "incoming" drop precedence to be applied on
the packet based on the CLP/DE field.
2.2.2 Optional Outgoing PHB Determination Via Local Policy And Traffic
Conditioning
This stage of Diff-Serv label switching is optional and may be used
on a Frame LSR to perform Behavior Aggregate demotion or promotion
inside an MPLS Diff-Serv domain. For the purpose of specifying a
Diff-Serv over MPLS method, we simply note that the PHB to be
actually enforced by an LSR (referred to as "outgoing PHB") may be
different to the PHB which had been associated with the packet at
the previous LSR (referred to as "incoming PHB").
This stage of Diff-Serv label switching is optional and may be used
on Frame LSRs with ATM/FR interfaces.
In the case of ATM/FR LSRs, it is expected that this optional stage
of Diff-Serv label switching, if supported, would be limited to
CLP/DE remarking (ie remarking the "incoming CLP/DE" to a different
value in the "outgoing CLP/DE")
Wu et. al 6
MPLS Support of DiffServ over ATM/FR June 99
2.2.3 Outgoing CLP/DE Field and Label Determination on Egress ATM/FR
L-LSP
If the LSR is a Frame LSR (ie Ingress Edge of the ATM/FR MPLS
cloud):
Once the outgoing PHB has been determined by the LSR as a function
of the incoming PHB and of the optional Local Policy and Traffic
Conditioning, the LSR:
- determines the "outgoing" PHS by performing the "outgoing"
PHB--> PHS/CLP-DE mapping defined below in section 3.
- determines the egress L-LSP label from the packet's FEC and
PHS
- encodes the EXP field of the top level label entry shim
header of the label stack (which is encapsulated in the ATM /FR LSP)
in accordance with the PHB --> PHS/EXP Mapping defined in section
2.4 of [MPLS_DIFF_PPP].
- determines the value to be written in the CLP/DE field of the
outgoing cell/frame by performing the outgoing PHB--> PHS/CLP-DE
mapping defined below in section 3.
- applies a scheduling/dropping behavior corresponding to the
"outgoing" PHB in compliance with the corresponding Diff-Serv PHB
specification.
If the LSR is an ATM/FR LSR (ie ATM/FR LSR in the middle of the
ATM/FR MPLS cloud):
Once the "outgoing" drop precedence (CLP/DE) has been determined by
the LSR as a function of the "incoming" drop precedence (CLP/DE) and
of the optional Local Policy and Traffic Conditioning, the LSR:
- determines the outgoing interface, the outgoing VCI/DLCI and
the output scheduling queue from the incoming VCI/DLCI
- applies a scheduling treatment corresponding to the
VCI/DLCI/label's PHS in compliance with the corresponding Diff-Serv
PHB specification
- writes the "outgoing" CLP/DE value into the outgoing
cell/frame
- applies the drop precedence corresponding to the "outgoing"
CLP/DE.
2.2.4 Simplified Forwarding on an ATM/FR LSR
When Local Policy and Traffic Conditioning are not to be performed
by the LSR, the Forwarding operation of an ATM/FR LSR is "reduced"
to traditional ATM/FR switching since:
- the LSR only looks at the incoming VCI/DLCI of an incoming
ATM cell/FR Frame to determine the output interface, the outgoing
VCI/DLCI and the output scheduling queue,
- the LSR only looks at the incoming CLP/DE field to determine
the drop precedence to be applied on the cell/frame,
- the MPLS Shim Header encapsulated in the ATM/FR connection
does not need to be looked at nor modified.
Wu et. al 7
MPLS Support of DiffServ over ATM/FR June 99
2.2.5 Number of Drop Precedence Levels
Because the underlying standardized ATM and Frame Relay Selective
Discard mechanisms (CLP/DE) only support two levels of Drop
Precedence, the proposed solution is limited to two levels of Drop
Precedence per PHS in an ATM MPLS or FR MPLS cloud.
However, the label stack encapsulated in the ATM LSP or FR LSP is
expected to include a shim header for the top label entry with a
meaningful EXP field, which can thus be used to encode all levels of
Drop Precedence within a PHS as defined in [MPLS_DIFF_PPP].
Consequently, even if only two levels of Drop Precedence are
achieved in the ATM/FR MPLS cloud, all Drop Precedence levels (eg
the three levels of an AF Class) can be supported in PPP MPLS clouds
surrounding an ATM/FR MPLS cloud.
3. PHB Mapping into PHS and Selective Discard Mechanism
3.1 PHB-->PHS/CLP Mapping
The mapping from PHBs into the L-LSP PHS and the Cell Loss Priority
(CLP) field of the ATM header is as follows:
PHB CLP PHS
DF -----> 0 DF
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
3.2 PHB-->PHS/DE Mapping
The mapping from PHBs into the L-LSP PHS and the Discard Eligible
(DE) field of the Frame Relay header is as follows:
PHB DE PHS
DF -----> 0 DF
CSn -----> 0 CSn
AFn1 -----> 0 AFCn
AFn2 -----> 1 AFCn
AFn3 -----> 1 AFCn
EF -----> 0 EF
3.3 Signaled PHS for Class Selector
As described in [DIFF_HEADER], "the Class Selector PHB Group
identifies 8 PHBs defined via the relative probability of timely
Wu et. al 8
MPLS Support of DiffServ over ATM/FR June 99
forwarding that they respectively offer to packets. For backwards
compatibility purposes, the Class Selector PHB Requirements are
specified as the minimum requirements compatible with most of the
deployed forwarding treatments selected by the IP Precedence field".
Quoting again from [DIFF_HEADER]:
"In addition, we give a set of codepoints that MUST map to PHBs
meeting these minimum requirements. The PHBs mapped to by these
codepoints MAY have a more detailed list of specifications in
addition to the required ones stated here".
Considering that:
- this document defines how ATM/FR LSRs support some
"specific/restrictive" PHB groups using their existing hardware
capabilities (including AF PHB Group and EF PHB).
- ATM/FR LSRs do not have some legacy PHBs complying with Class
Selector PHB requirements as defined in [DIFF_HEADER] paragraph
4.2.2.2 which are "less specific/restrictive" than the PHBs
addressed in this document.
- as specified in [DIFF_HEADER], Class Selector Codepoints can
be supported by "more specific PHBs" such as the other ones
addressed in this document
we propose that:
- a Behavior Aggregate corresponding to a Class Selector
Codepoint CSn may be mapped onto a CSn specific L-LSP with its CSn
PHS signaled at label set-up, OR
- a Behavior Aggregate corresponding to a Class Selector
Codepoint CSn may be mapped onto an L-LSP whose signaled PHS
corresponds to a "more specific/restrictive" PHB than CSn (eg AFn,
EF).
4. LSP Establishment and Message Format
4.1. Signaling extension during L-LSP establishment
To support Diff-Serv in MPLS over ATM and Frame Relay, the PHS must
be signaled in the MPLS label request messages and MPLS label
binding messages. The detailed format of the corresponding message
extension is described below when the signaling protocol used is LDP
or RSVP. The MPLS control application on each ATM LSR or Frame Relay
LSR along the L-LSP will process the new PHS attribute and install
the corresponding scheduling behavior for that L-LSP (eg. map the
LSP into an output queue associated with the PHS).
4.2. Merging
Wu et. al 9
MPLS Support of DiffServ over ATM/FR June 99
In an MPLS domain, two or more LSPs can be merged into one LSP at
one LSR. The proposed support of Diff-Serv in MPLS over ATM and
Frame Relay is compatible with LSP Merging under the following
condition:
L-LSPs can only be merged into one LSP if they are associated with
the same PHS.
Note that, when L-LSPs merge, the bandwidth that is available for
the PHS downstream of the merge point must be sufficient to carry
the sum of the merged traffic. This is particularly important in the
case of EF traffic.
4.3 New RSVP Object Format
This section defines a new RSVP object class and a new RSVP object
within that class for support of Diff-Serv in MPLS over ATM/FR when
L-LSPs are established via RSVP [MPLS_RSVP].
The new object Class is defined as the "Class Of Service" Class (COS
Class). Its Class-Num is [TBD].
The new RSVP DIFFSERV_PHS object is defined within the COS Class to
carry the PHS of the traffic to be transported on the corresponding
LSP. Its C-Type is 1.
DIFFSERV_PHS object Class = [TBD], C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4 | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We propose that the 16-bit PHS be encoded as specified in section 2
of [PHBID]. In particular, we propose that the encoding for a PHS be
the smallest numerical value of the encodings for the various PHBs
in the PHS. In turn, the encoding of a single PHB defined by
standards action is the recommended DSCP value for this PHB, left-
justified in the 16 bit field, with bits 6 through 15 set to zero.
For instance, the encoding of the AFC1 PHS is the encoding of the
AF11 PHB.
This object may be carried in a PATH message that contains the
LABEL_REQUEST object to indicate the PHS for which a label is
required. The object may also be carried in a RESV message that
Wu et. al 10
MPLS Support of DiffServ over ATM/FR June 99
contains a LABEL object indicating the PHS for which the label is to
be used.
As described in [MPLS_RSVP], bandwidth information may also be
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the SENDER_TSPEC Object (in the Path message) and
the FLOWSPEC Object (in the Resv message).
4.4. New LDP TLV
This section defines a new LDP TLV necessary for support of Diff-
Serv in MPLS over ATM/FR when L-LSPs are established via LDP
[MPLS_LDP] or CR-LDP [MPLS CR-LDP]. We define a new PHS TLV to
signal the PHS in a label request or label binding as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PHS | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the TLV is [TBD].
Encoding of the PHS field is the same as encoding of the PHS in
RSVP, as specified in 4.3.
We propose that the COS TLV which was specified in [LDP_03] (and
removed in later version of the LDP specifications) be
reincorporated into LDP and used to encode the PHS TLV as a nested
TLV (ie encode the PHS TLV in the COS value of the COS TLV).
Encoding the PHS TLV as a nested TLV of the COS TLV is proposed for
flexibility so that if additional TLVs need to be defined in the
future for support of Diff-Serv over MPLS, those TLVs could be
logically grouped inside the COS TLV.
Alternatively, the PHS TLV could be included in the LDP messages as
an independent TLV (ie not nested in the COS TLV).
As described in [MPLS_CR-LDP], bandwidth information may also be
signaled at LSP establishment time, for the purpose of Traffic
Engineering, using the Traffic Parameters TLV.
5. Security Considerations
This document does not introduce any new security issues beyond
those inherent in Diff-Serv, MPLS and RSVP, and may use the same
mechanisms proposed for those technologies.
6. Acknowledgments
Wu et. al 11
MPLS Support of DiffServ over ATM/FR June 99
This document has benefited from discussions with Dan Tappan, Yakov
Rekhter, George Swallow, Eric Rosen, and Emmanuel Desmet.
7. References
[MPLS_ARCH] Rosen et al., "Multiprotocol label switching
Architecture", work in progress, (draft-ietf-mpls-arch-04.txt),
February 1999.
[DIFF_ARCH] Blake et al., "An architecture for Differentiated
Services", RFC-2475, December 1998.
[MPLS_DIFF_PPP] Le Faucheur et al, "MPLS Support of Differentiated
Services over PPP links", draft-lefaucheur-mpls-diff-ppp-00.txt,
June 99.
[DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597,
June 1999.
[DIFF_EF] Jacobson et al., "An Expedited Forwarding PHB", RFC-2598,
June 1999.
[DIFF_HEADER] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
December 1998.
[MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching",
draft-ietf-mpls-atm-02.txt, April 1999.
[MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay
Networks", draft-ietf-mpls-fr-03.txt, November 1999.
[ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC-2481, January 1999.
[LDP_03] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
03.txt, January 99
[LDP_04] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp-
04.txt, April 99
[MPLS_RSVP] Awduche et al, "Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999
[MPLS CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using
LDP", draft-ietf-mpls-cr-ldp-01.txt, February 1999
[PHBID] Brim and Carpenter, "Per Hop Behavior Identification Codes",
draft-brim-diffserv-phbid-00.txt, April 99
Wu et. al 12
MPLS Support of DiffServ over ATM/FR June 99
8. Author's Addresses
Liwen Wu
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA
E-mail liwen.wu@adn.alcatel.com
Pierrick Cheval
Alcatel USA
44983 Knoll Square
Ashburn, VA 20147
USA
E-mail pierrick.cheval@adn.alcatel.com
Pasi Vaananen
Nokia
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803
USA
E-mail pasi.vaananen@ntc.nokia.com
Francois le Faucheur
Cisco Systems, Inc.
Les Lucioles - 291, rue Albert Caquot
06560 Valbonne
France
E-mail flefauch@cisco.com
Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
USA
E-mail bsd@cisco.com
Wu et. al 13