Internet Engineering Task Force Shahram Davari
INTERNET DRAFT PMC-Sierra Inc.
Expires October 1999
Ram Krishnan
Nexabit Networks
Pasi Vaananen
Nokia
April, 1999
MPLS Support of Differentiated Services over PPP links
<draft-davari-mpls-diff-ppp-00.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.
Abstract
This document proposes a technique for MPLS to support Differentiated
Services (Diff-Serv) over PPP links in non-ECN-capable [ECN] networks.
Briefly, we propose that:
- Packets belonging to the same PHB forwarding class (PFC), as defined
in [DIFF_MPLS_EXT], be transported over the same PPP LSP.
- For a given FEC, a separate PPP LSP should be established for each
PFC, so that multiple PPP LSPs are established in parallel for
support of Diff-Serv.
Davari, et al. [Page 1]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
- Among a set of PHBs transported over the same PPP LSP, the different
PHBs' drop Precedence (DP) be mapped into the EXP field (3 bits) of
the MPLS shim header (note that DP is implicitly a part of DSCP).
The required updates to the current MPLS LDP and MPLS RSVP messages
(for LSP establishment in order to support Diff-Serv over PPP LSRs)
are the same as the ones proposed in [MPLS_DIFF_EXT].
1. Introduction
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 signaling 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.
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. At each transit node,
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 currently
defined Diff-Serv PHBs over a non-ECN-capable PPP MPLS network, i.e.,
an MPLS network implemented using non-ECN-capable PPP routers.
1.1. PHB Forwarding Class
[MPLS_DIFF_EXT] defines a set of PHBs that require no misordering of
packets in a microflow (even if the microflow contains packets for
more than one PHB) as a PHB Forwarding Class (PFC). The mechanisms
described in this draft aim to preserve the correct ordering
relationships for packets that belong to a single PFC.
1.2. LSP Establishment in Diff-Serv over PPP MPLS
Recognizing that:
- MPLS over PPP links requires the use of a Shim Header, which consists
of a label stack with one or more entries [MPLS_ENCAPS];
- The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], which
can not be copied entirely in to the 3-bit long EXP field of the MPLS
shim header;
We propose that:
- All packets belonging to a single PFC and the same Forwarding
Davari, et al. [Page 2]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
Equivalent Class (FEC) should be sent down a single LSP;
- One LSP should be established per <PFC, FEC> pair (rather than
simply one LSP per FEC as in a network that does not support
Diff-Serv);
- Multiple PHBs belonging to the same PFC be granted different Drop
Precedence (DP) values through appropriate coding of the EXP field
of the top label entry of the shim header.
MPLS specifies how LSPs can be established via multiple signaling
protocols. This Internet-Draft assumes the extensions to LDP and
RSVP are those defined in [MPLS_DIFF_EXT], which allow establishment
of one LSP per <PFC, FEC> pair over a PPP link.
1.3. Label Forwarding for Support of Diff-Serv over PPP MPLS
Label forwarding for support of Diff-Serv over PPP MPLS domain can be
broken down into three regions:
- Ingress node
- Egress node
- Interior node
On the other hand the Ingress and Egress links may be one of the
followings:
- Non-MPLS link
- MPLS link of the same hierarchical level
- MPLS link of different hierarchical level
Let us further assume that the upstream and downstream links of an
Interior node are in the same hierarchical level.
1.3.1 Ingress Node Label Forwarding
At the Ingress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR should
identify the PHB of an incoming packet (note that PHB consists of PFC
and DP). It should then determine the outgoing PHB according to some
local policy and/or traffic conditioning function and map it to the
outgoing packet.
The following actions are taken by the Ingress-LSR depending on the
Ingress link type and hierarchical level:
- If the incoming packet is coming through a non-MPLS PPP/ATM/FR link
(unlabeled packet), the Edge-LSR determines the incoming packet's PHB
by looking at its IP DSCP, according to the mappings defined in
[DIFF_HEADER], [DIFF_AF], [DIFF_EF]. It then determines the packet's
outgoing PHB according to some local policy and/or traffic conditioning.
Based on the FEC and PFC of the outgoing packet, the Edge-LSR selects
Davari, et al. [Page 3]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
the LSP among the set of LSPs established for each <FEC, PFC> pair. The
PPP Edge-LSR then inserts a shim header and sets the EXP field of the
top label entry according to the mapping defined below between the
outgoing PHBs and the EXP field + PFCs (section 2.1).
- If the incoming packet is coming through an MPLS PPP link (labeled
packet), which is in the same hierarchical level as the downstream
link, then the Ingress LSR should act like an Interior LSR described in
section 1.3.3.
- If the incoming packet is coming through an MPLS PPP link (labeled
packet), and this is the start of a hierarchical tunnel, the Ingress
Edge-LSR first determines the packet's PFC from the incoming LSP among
the set of LSPs established for the <FEC, PFC> pair. It then determines
the incoming packet's PHB from this PFC and from the EXP field of the
top label entry of the label stack according to the mapping defined
below between the EXP fields + PFCs and the PHBs (section 2.2). It then
deteremines the PHBs for the two levels of hierarchy according to some
local policy and/or traffic conditioning. At each level, based on the
FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP among
the set of LSPs established for each <FEC, PFC>. It then pushes a new
label entry into the label stack and sets the EXP field of the new
label entry and the lower label entry (i.e., the incoming label entry)
according to the mapping defined below between PHBs and the EXP field
+ PFCs (section 2.1). Note that these two labels may have similar or
different EXP fields.
- If the incoming packet is coming through an MPLS ATM/FR link (labeled
packet), which is in the same hierarchical level as the downstream link,
the Ingress first determines the packet's PFC from the incoming LSP
among the set of LSPs established for the <FEC, PFC> pair. It then
determines the incoming packet's PHB from this PFC and from the CLP/DE
bit and/or EXP field of the top label entry of the label stack
according to a mapping between CLP/DE bit and/or EXP field and the PHBs
, which is outside the scope of this document and is yet to be defined.
It then determines the packet's outgoing PHB according to some local
policy and/or traffic conditioning. Based on the FEC and PFC of the
outgoing packet, the Edge-LSR selects the LSP among the set of LSPs
established for each <FEC, PFC>. It then sets the EXP field of the top
label entry, according to the mapping defined below between the outgoing
PHB and EXP field + PFCs (section 2.1).
- If the incoming packet is coming through an MPLS ATM/FR link (labeled
packet) and this is the start of a hierarchical tunnel, the Ingress
Edge-LSR first determines the incoming packet's PFC from the incoming
LSP among the set of LSPs established for the <FEC, PFC> pair. It then
determines the incoming packet's PHB from this PFC and from the CLP/DE
bit and/or EXP field of the top label entry of the label stack
according to a mapping between CLP/DE bit and/or EXP field and the PHBs
, which is outside the scope of this document and is yet to be defined.
It then determines the PHBs for the two levels of hierarchy according
to some local policy and/or traffic conditioning. At each level, based
Davari, et al. [Page 4]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
on the FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP
among the set of LSPs established for each <FEC, PFC>. It then pushes a
new label entry into the label stack and sets the EXP field of the new
label entry and the lower label entry (i.e., the ATM/FR label entry)
according to the mapping defined below between PHBs and the EXP field
+ PFCs (section 2.1). Note that these two labels may have similar or
different EXP fields.
1.3.2 Egress Node Label Forwarding
At the Egress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR first
determines the packet's PFC from the incoming LSP among the set of LSPs
established for the <FEC, PFC> pair. It then determines the incoming
packet's PHB from this PFC and from the EXP field of the top label
entry of the label stack according to the mapping defined below between
the EXP fields + PFCs and the PHBs (section 2.2). It then determines
the packet's outgoing PHB according to some local policy and/or traffic
conditioning and maps that into the outgoing packet depending on egress
link type and hierarchical level as explaind below:
- If the outgoing link is a non-MPLS PPP/ATM/FR link (unlabeled packet)
, the Edge-LSR pops the shim header and sets the IP DSCP of the packet
based on the outgoing PHBs according to the mappings defined in
[DIFF_HEADER], [DIFF_AF], [DIFF_EF].
- If the outgoing packet is labeled and is going through a PPP egress
link, which is in the same hierarchical level as the upstream link,
then the Egress LSR should act as an Interior LSR described in section
1.3.3.
- If the outgoing packet is going through an MPLS PPP link (labeled
packet) and this is the end of a hierarchical tunnel, based on the FEC
and PFC of the outgoing packet, the Edge-LSR selects the LSP among the
set of LSPs established for each <FEC, PFC>. It then pops the top label
entry and sets the EXP field of the lower label entry according the
mapping defined below between PHBs and EXP field + PFCs (section 2.1).
- If the outgoing packet is going through an MPLS ATM/FR link (labeled
packet), which is in the same hierarchical level as the upstream link,
based on the FEC and PFC of the outgoing packet, the Edge-LSR selects
the LSP among the set of LSPs established for each <FEC, PFC>. It then
sets the EXP field of the shim header's top label entry (i.e., ATM/FR
label entry) according to the mapping defined below between PHBs and the
EXP field + PFCs (section 2.1). It also sets the CLP/DE bit according to
the mapping defined in [MPLS_DIFF_EXP] between PHBs and CLP/DE bit.
- If the outgoing packet is going through an MPLS ATM/FR link (labeled
packet) and this is the end of a hierarchical tunnel, based on the FEC
and PFC of the outgoing packet, the Edge-LSR selects the LSP among the
set of LSPs established for each <FEC, PFC>. It then pops the top label
entry and sets the EXP field of the lower label entry according to the
mapping defined below between PHBs and EXP field + PFCs (section 2.1).
Davari, et al. [Page 5]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
It also sets the CLP/DE bit according to the mapping defined in
[MPLS_DIFF_EXP] between PHBs and CLP/DE bit.
1.3.3 Interior Node Label Forwarding
At the Interior of a PPP Diff-Serv MPLS cloud, the Interior-LSR, which
receives and transmits labeled packet on PPP links, which are at the
same heirarchical level, will perform the following action:
- The Interior LSR first determines the packet's PFC from the incoming
LSP among the set of LSPs established for the <FEC, PFC> pair. It then
determines the incoming packet's PHB from this PFC and from the EXP
field of the top label entry of the label stack according to the mapping
defined below between the EXP fields + PFCs and the PHBs (section 2.2).
It then determines the packet's outgoing PHB according to some local
policy and/or traffic conditioning. Based on the FEC and PFC of the
outgoing packet, the Interior LSR selects the LSP among the set of LSPs
established for each <FEC, PFC>. The Interior LSR then sets the EXP
field of the top label entry of the stack according to the mapping
defined below between the PHBs and the EXP field + PFcs (section 2.1).
2. PHB Mapping into PFCs and Selective Discard Mechanism
The mapping from the AF and EF PHBs into the PFCs are the same as
those defined in [MPLS_DIFF_EXT]. While the mapping from PHBs into the
EXP field + PFCs and the mapping from EXP field + PFCs into the PHBs are
described below.
2.1 Mapping PHBs into the EXP Field and PFCs
This section covers the mapping from AF and EF PHBs into the EXP field
of the Shim Header and the PFC.
There are 4 PFCs defined for AF PHBs and within each AF PFC there are
3 drop precedences, which get mapped into the EXP field. There is only
one PFC with one drop precedence defined for the EF PHB and the DF PHB
(Default Forwarding), which gets mapped into the EXP field.
The mapping from AF, EF and DF PHBs into the EXP field of the shim
header and the PFCs is as follows:
PHB EXP Field PFC
AFx1 -----> 000 AFCx
AFx2 -----> 001 AFCx
AFx3 -----> 010 AFCx
EF -----> 000 EFC
DF -----> 000 DFC
The AFCx and EFC per-hop forwarding classes (PFC) are defined in
[MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the
PHB-group Forwarding Class for the DF PHB.
Davari, et al. [Page 6]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
2.2 Mapping EXP field and PFC into the PHBs
The mapping from EXP field of the shim header and PFC into the AF, EF
and DF PHBs is as follows:
EXP Field PHB PFC
000 -----> AFx1 AFCx
001 -----> AFx2 AFCx
010 -----> AFx3 AFCx
000 -----> EF EFC
000 -----> DF DFC
The AFCx and EFC per-hop forwarding classes (PFC) are defined in
[MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the
PHB-group Forwarding Class for the DF PHB.
3 Examples of Local Policies for Determining PHBs
This section gives a few examples of the local policies, which might be
used in determining a packet's PHB.
3.1 Example of Determining an Egress packet's PHB Considering its
Previous PHB when DP Upgrading is not Permitted
In this example an egress packet's PHB is determined by examining the
EXP field of its shim header together with its previous PHB (which
might be determined from the packet's DSCP in case of non-MPLS egress
link or the shim header's lower label entry in case of MPLS egress
link of different hierarchical level), and assuming that no upgrading
of the DP of a packet is permitted.
EXP Field Previous New Comments
PHB PHB
000 AFx1 -----> AFx1 No change
000 AFx2 -----> AFx2 Impossible
000 AFx3 -----> AFx3 Impossible
000 EF -----> EF No change
000 DF -----> DF No change
001 AFx1 -----> AFx2 Downgrade
001 AFx2 -----> AFx2 No change
001 AFx3 -----> AFx3 Impossible
001 EF -----> EF Impossible
001 DF -----> DF Impossible
010 AFx1 -----> AFx3 Downgrade
010 AFx2 -----> AFx3 Downgrade
010 AFx3 -----> AFx3 No change
010 EF -----> EF Impossible
010 DF -----> DF Impossible
The following assumptions has been made in the above table:
Davari, et al. [Page 7]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
- The drop precedence of a Marked packet can not be upgraded.
- the drop precedence of the EF and DF PHB packets can not be
downgraded.
3.2 Example of Determining an Egress Packet's PHB Considering its
Previous PHB when DP Upgrading is Permitted
In this example an egress packet's PHB is determined by examining the
EXP field of its shim header together with its previous PHB (which
might be determined from the packet's DSCP in case of non-MPLS egress
link or the shim header's lower label entry in case of MPLS egress
link of different hierarchical level), and assuming that upgrading of
the DP of a packet is permitted.
EXP Field Previous New Comments
PHB PHB
000 AFx1 -----> AFx1 No change
000 AFx2 -----> AFx1 Upgrade
000 AFx3 -----> AFx1 Upgrade
000 EF -----> EF No change
000 DF -----> DF No change
001 AFx1 -----> AFx2 Downgrade
001 AFx2 -----> AFx2 No change
001 AFx3 -----> AFx2 Upgrade
001 EF -----> EF Impossible
001 DF -----> DF Impossible
010 AFx1 -----> AFx3 Downgrade
010 AFx2 -----> AFx3 Downgrade
010 AFx3 -----> AFx3 No change
010 EF -----> EF Impossible
010 DF -----> DF Impossible
The following assumptions has been made in the above table:
- The drop precedence of a Marked packet can be upgraded.
- the drop precedence of the EF and DF PHB packets can not be
downgraded.
3.3 Example of Determining an Ingress ATM/FR Packet's PHB Considering
its previous PHB and CLP/DE bit when DP Upgrading is not Permitted
In this example an ingress packet's PHB is determined by examining its
CLP/DE bit (or in case of fragmented IP packets the logical "OR" of
CLP/DE bits of all fragments) together with its previous PHB (which
might be determined from the packet's DSCP in case of non-MPLS ingress
link or the shim header's top label entry in case of MPLS ingress link)
, and assuming that no upgrading of DP is permitted.
Davari, et al. [Page 8]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
CLP/DE Previous New
bit EXP(PHB) EXP(PHB) Comments
0 000 (AFx1) -----> 000 (AFx1) No change
0 001 (AFx2) -----> 001 (AFx2) Impossible
0 010 (AFx3) -----> 010 (AFx3) Impossible
0 000 (EF) -----> 000 (EF) No change
0 000 (DF) -----> 000 (DF) No change
1 000 (AFx1) -----> 001 (AFx2) Downgrade
1 001 (AFx2) -----> 001 (AFx2) No change
1 010 (AFx3) -----> 010 (AFx3) No change
1 000 (EF) -----> 000 (EF) Impossible
1 000 (DF) -----> 000 (DF) Impossible
The following assumptions has been made in the above table:
- The drop precedence of a Marked packet can not be upgraded.
- ATM/FR links can downgrade the drop precedence of a packet by only
one level (i.e., AFx1 -> AFx2, not AFx3).
- the drop precedence of the EF and DF PHB packets can not be
downgraded.
3.4 Example of Determining an Ingress ATM/FR Packet's PHB Considering
its previous PHB and CLP/DE bit when DP Upgrading is Permitted
In this example an ingress packet's PHB is determined by examining its
CLP/DE bit (or in case of fragmented IP packets the logical "OR" of
CLP/DE bits of all fragments) together with its previous PHB (which
might be determined from the packet's DSCP in case of non-MPLS ingress
link or the shim header's top label entry in case of MPLS ingress link
), and assuming that upgrading of DP is permitted.
CLP/DE Previous New
bit EXP(PHB) EXP(PHB) Comments
0 000 (AFx1) -----> 000 (AFx1) No change
0 001 (AFx2) -----> 000 (AFx1) Upgrade
0 010 (AFx3) -----> 001 (AFx2) Upgrade
0 000 (EF) -----> 000 (EF) No change
0 000 (DF) -----> 000 (DF) No change
1 000 (AFx1) -----> 001 (AFx2) Downgrade
1 001 (AFx2) -----> 001 (AFx2) No change
1 010 (AFx3) -----> 010 (AFx3) No change
1 000 (EF) -----> 000 (EF) Impossible
1 000 (DF) -----> 000 (DF) Impossible
The following assumptions has been made in the above table:
- The drop precedence of a Marked packet can be upgraded by only one
level (i.e., AFx3 -> AFx2 not AFx1).
- ATM/FR links can downgrade the drop precedence of a packet by only
one level (i.e., AFx1 -> AFx2, not AFx3).
- the drop precedence of the EF and DF PHB packets can not be
downgraded.
Davari, et al. [Page 9]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
3. References
[ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC-2481, January 1999.
[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_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in
progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998.
[] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474,
December 1998.
[MPLS_DIFF_EXT] Wu et al., "MPLS Support of Differentiated Services
by ATM LSRs and Frame Relay LSRs", work in progress, February 1999.
[DIFF_AF] J. Heinanen et al., "Assured Forwarding PHB Group", work in
progress, (draft-ietf-diffserv-af-06.txt), February 1999.
[DIFF-EF] V. Jacobson et al., "An Expedited Forwarding PHB", work in
progress, (draft-ietf-diffserv-phb-ef-02.txt), February 1999.
4. Authors' Addresses
Shahram Davari
PMC-Sierra Inc.
105-8555 Baxter Place
Burnaby, BC V5A 4V7
Canada
E-mail: Shahram_Davari@pmc-sierra.com
Ram Krishnan
Nexabit Networks
200 Nickerson Road,
Marlboro, MA 01752
USA
E-mail: ram@nexabit.com
Pasi Vanannen
Nokia
3 Burlington Woods Drive, Suit 250
Burlington, MA 01803
USA
Email: pasi.vaananen@ntc.nokia.com
Davari, et al. [Page 10]
Internet Draft draft-davari-mpls-diff-ppp-00.txt February 1999
Expires October 1999