draft-ietf-mpls-diff-ext-09.txt   rfc3270.txt 
Francois Le Faucheur Network Working Group F. Le Faucheur, Editor
Liwen Wu Request for Comments: 3270 L. Wu
Bruce Davie Category: Standards Track B. Davie
Cisco Systems Cisco Systems
S. Davari
Shahram Davari
PMC-Sierra Inc. PMC-Sierra Inc.
P. Vaananen
Pasi Vaananen
Nokia Nokia
R. Krishnan
Ram Krishnan
Axiowave Networks Axiowave Networks
P. Cheval
Pierrick Cheval
Alcatel Alcatel
J. Heinanen
Song Networks
May 2002
Juha Heinanen Multi-Protocol Label Switching (MPLS)
Telia Finland Support of Differentiated Services
IETF Internet Draft
Expires: September, 2001
Document: draft-ietf-mpls-diff-ext-09.txt April, 2001
MPLS Support of Differentiated Services
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are Working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2002). All Rights Reserved.
http://www.ietf.org/shadow.html.
Le Faucheur, et. al 1
Abstract Abstract
This document defines a flexible solution for support of This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label Differentiated Services (Diff-Serv) over Multi-Protocol Label
Switching (MPLS) networks. Switching (MPLS) networks.
This solution allows the MPLS network administrator to select how This solution allows the MPLS network administrator to select how
Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched
Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic
Engineering and protection objectives within his/her particular Engineering and protection objectives within his/her particular
network. For instance, this solution allows the network network. For instance, this solution allows the network
administrator to decide whether different sets of BAs are to be administrator to decide whether different sets of BAs are to be
mapped onto the same LSP or mapped onto separate LSPs. mapped onto the same LSP or mapped onto separate LSPs.
This solution relies on combined use of two types of LSPs: Table of Contents
- LSPs which can transport multiple Ordered Aggregates, so that
the EXP field of the MPLS Shim Header conveys to the LSR the PHB 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
to be applied to the packet (covering both information about the 1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
packet's scheduling treatment and its drop precedence). 1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
- LSPs which only transport a single Ordered Aggregate, so that 1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
the packet's scheduling treatment is inferred by the LSR 1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
exclusively from the packet's label value while the packet's 1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
drop precedence is conveyed in the EXP field of the MPLS Shim 1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
Header or in the encapsulating link layer specific selective 2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
drop mechanism (ATM, Frame Relay, 802.1). 2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer On
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer on
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64
1. Introduction 1. Introduction
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a In an MPLS domain [MPLS_ARCH], when a stream of data traverses a
common path, a Label Switched Path (LSP) can be established using common path, a Label Switched Path (LSP) can be established using
MPLS signaling protocols. At the ingress Label Switch Router (LSR), MPLS signaling protocols. At the ingress Label Switch Router (LSR),
each packet is assigned a label and is transmitted downstream. At 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 each LSR along the LSP, the label is used to forward the packet to
the next hop. the next hop.
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP
IP packets crossing a link and requiring the same Diff-Serv behavior packets crossing a link and requiring the same Diff-Serv behavior are
are said to constitute a Behavior Aggregate (BA). At the ingress said to constitute a Behavior Aggregate (BA). At the ingress node of
node of the Diff-Serv domain the packets are classified and marked the Diff-Serv domain, the packets are classified and marked with a
with a Diff-Serv Code Point (DSCP) which corresponds to their Diff-Serv Code Point (DSCP) which corresponds to their Behavior
Behavior Aggregate. At each transit node, the DSCP is used to select Aggregate. At each transit node, the DSCP is used to select the Per
the Per Hop Behavior (PHB) that determines the scheduling treatment Hop Behavior (PHB) that determines the scheduling treatment and, in
and, in some cases, drop probability for each packet. some cases, drop probability for each packet.
This document specifies a solution for supporting the Diff-Serv This document specifies a solution for supporting the Diff-Serv
Behavior Aggregates whose corresponding PHBs are currently defined Behavior Aggregates whose corresponding PHBs are currently defined
(in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This
solution also offers flexibility for easy support of PHBs that may solution also offers flexibility for easy support of PHBs that may be
be defined in the future. defined in the future.
As mentioned in [DIFF_HEADER], "Service providers are not required This solution relies on the combined use of two types of LSPs:
Le Faucheur et. al 2 - LSPs which can transport multiple Ordered Aggregates, so that the
to use the same node mechanisms or configurations to enable service EXP field of the MPLS Shim Header conveys to the LSR the PHB to be
applied to the packet (covering both information about the
packet's scheduling treatment and its drop precedence).
- LSPs which only transport a single Ordered Aggregate, so that the
packet's scheduling treatment is inferred by the LSR exclusively
from the packet's label value while the packet's drop precedence
is conveyed in the EXP field of the MPLS Shim Header or in the
encapsulating link layer specific selective drop mechanism (ATM,
Frame Relay, 802.1).
As mentioned in [DIFF_HEADER], "Service providers are not required to
use the same node mechanisms or configurations to enable service
differentiation within their networks, and are free to configure the differentiation within their networks, and are free to configure the
node parameters in whatever way that is appropriate for their node parameters in whatever way that is appropriate for their service
service offerings and traffic engineering objectives". Thus, the offerings and traffic engineering objectives". Thus, the solution
solution defined in this document gives Service Providers defined in this document gives Service Providers flexibility in
flexibility in selecting how Diff-Serv classes of service are Routed selecting how Diff-Serv classes of service are Routed or Traffic
or Traffic Engineered within their domain (e.g. separate classes of Engineered within their domain (e.g., separate classes of services
services supported via separate LSPs and Routed separately, all supported via separate LSPs and Routed separately, all classes of
classes of service supported on the same LSP and Routed together). service supported on the same LSP and Routed together).
Because MPLS is path-oriented it can potentially provide faster and Because MPLS is path-oriented it can potentially provide faster and
more predictable protection and restoration capabilities in the face more predictable protection and restoration capabilities in the face
of topology changes than conventional hop by hop routed IP systems. of topology changes than conventional hop by hop routed IP systems.
In this document we refer to such capabilities as "MPLS protection". In this document we refer to such capabilities as "MPLS protection".
Although such capabilities and associated mechanisms are outside the Although such capabilities and associated mechanisms are outside the
scope of this specification, we note that they may offer different scope of this specification, we note that they may offer different
levels of protection to different LSPs. Since the solution presented levels of protection to different LSPs. Since the solution presented
here allow Service Providers to choose how Diff-Serv classes of here allow Service Providers to choose how Diff-Serv classes of
services are mapped onto LSPs, the solution also gives Service services are mapped onto LSPs, the solution also gives Service
Providers flexibility in the level of protection provided to Providers flexibility in the level of protection provided to
different Diff-Serv classes of service (e.g. some classes of service different Diff-Serv classes of service (e.g., some classes of service
can be supported by LSPs which are protected while some other can be supported by LSPs which are protected while some other classes
classes of service are supported by LSPs which are not protected). of service are supported by LSPs which are not protected).
Furthermore, the solution specified in this document achieves label Furthermore, the solution specified in this document achieves label
space conservation and reduces the volume of label set-up/tear-down space conservation and reduces the volume of label set-up/tear-down
signaling where possible by only resorting to multiple LSPs for a signaling where possible by only resorting to multiple LSPs for a
given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or
required. required.
This specification allows support of Differentiated Services for This specification allows support of Differentiated Services for both
both IPv4 and IPv6 traffic transported over an MPLS network. IPv4 and IPv6 traffic transported over an MPLS network. This
This document only describes operations for unicast. Multicast document only describes operations for unicast. Multicast support is
support is for future study. for future study.
The solution described in this document does not preclude the The solution described in this document does not preclude the
signaled or configured use of the EXP bits to support Explicit signaled or configured use of the EXP bits to support Explicit
Congestion Notification [ECN] simultaneously with Diff-Serv over Congestion Notification [ECN] simultaneously with Diff-Serv over
MPLS. However, techniques for supporting ECN in an MPLS environment MPLS. However, techniques for supporting ECN in an MPLS environment
are outside the scope of this document. are outside the scope of this document.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
The reader is assumed to be familiar with the terminology of The reader is assumed to be familiar with the terminology of
[MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM] and [MPLS_FR] including the [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the
following: following:
EXP EXPerimental (bits) FEC Forwarding Equivalency Class
Le Faucheur et. al 3
FEC Forwarding Equivalency Class
FTN FEC-To-NHLFE Map FTN FEC-To-NHLFE Map
ILM Incoming Label Map ILM Incoming Label Map
LC-ATM Label Switching Controlled-ATM (interface) LC-ATM Label Switching Controlled-ATM (interface)
LC-FR Label Switching Controlled-Frame Relay (interface) LC-FR Label Switching Controlled-Frame Relay (interface)
LSP Label Switched Path LSP Label Switched Path
LSR Label Switch Router LSR Label Switch Router
MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching
NHLFE Next Hop Label Forwarding Entry NHLFE Next Hop Label Forwarding Entry
The reader is assumed to be familiar with the terminology of The reader is assumed to be familiar with the terminology of
[DIFF_ARCH], [DIFF_HEADER], [DIFF_AF] and [DIFF_EF] including the [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the
following: following:
AF Assured Forwarding AF Assured Forwarding
BA Behavior Aggregate BA Behavior Aggregate
CS Class Selector CS Class Selector
DF Default Forwarding DF Default Forwarding
DSCP Differentiated Services Code Point DSCP Differentiated Services Code Point
EF Expedited Forwarding EF Expedited Forwarding
PHB Per Hop Behavior PHB Per Hop Behavior
The reader is assumed to be familiar with the terminology of The reader is assumed to be familiar with the terminology of
[DIFF_NEW] including the following: [DIFF_NEW], including the following:
OA Ordered Aggregate. The set of Behavior Aggregates which OA Ordered Aggregate. The set of Behavior Aggregates which
share an ordering constraint. share an ordering constraint.
PSC PHB Scheduling Class. The set of one or more PHB(s) that PSC PHB Scheduling Class. The set of one or more PHB(s)
are applied to the Behavior Aggregate(s) belonging to a that are applied to the Behavior Aggregate(s) belonging
given OA. For example, AF1x is a PSC comprising the to a given OA. For example, AF1x is a PSC comprising
AF11, AF12 and AF13 PHBs. EF is an example of PSC the AF11, AF12 and AF13 PHBs. EF is an example of PSC
comprising a single PHB, the EF PHB. comprising a single PHB, the EF PHB.
The following acronyms are also used: The following acronyms are also used:
CLP Cell Loss Priority CLP Cell Loss Priority
Le Faucheur et. al 4 DE Discard Eligibility
DE Discard Eligibility
SNMP Simple Network Management Protocol SNMP Simple Network Management Protocol
Finally, the following acronyms are defined in this specification: Finally, the following acronyms are defined in this specification:
E-LSP EXP-Inferred-PSC LSP E-LSP EXP-Inferred-PSC LSP
L-LSP Label-Only-Inferred-PSC LSP L-LSP Label-Only-Inferred-PSC LSP
1.2 EXP-Inferred-PSC LSPs (E-LSP) 1.2 EXP-Inferred-PSC LSPs (E-LSP)
A single LSP can be used to support one or more OAs. Such LSPs can A single LSP can be used to support one or more OAs. Such LSPs can
support up to eight BAs of a given FEC, regardless of how many OAs support up to eight BAs of a given FEC, regardless of how many OAs
these BAs span. With such LSPs, the EXP field of the MPLS Shim these BAs span. With such LSPs, the EXP field of the MPLS Shim
Header is used by the LSR to determine the PHB to be applied to the Header is used by the LSR to determine the PHB to be applied to the
packet. This includes both the PSC and the drop preference. packet. This includes both the PSC and the drop preference.
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the
PSC of a packet transported on this LSP depends on the EXP field PSC of a packet transported on this LSP depends on the EXP field
value for that packet. value for that packet.
The mapping from EXP field to PHB (ie to PSC and drop precedence) The mapping from the EXP field to the PHB (i.e., to PSC and drop
for a given such LSP, is either explicitly signaled at label set-up precedence) for a given such LSP, is either explicitly signaled at
or relies on a pre-configured mapping. label set-up or relies on a pre-configured mapping.
Detailed operations of E-LSPs are specified in section 3 below. Detailed operations of E-LSPs are specified in section 3 below.
1.3 Label-Only-Inferred-PSC LSPs (L-LSP) 1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
A separate LSP can be established for a single <FEC, OA> pair. A separate LSP can be established for a single <FEC, OA> pair. With
With such LSPs, the PSC is explicitly signaled at label such LSPs, the PSC is explicitly signaled at the time of label
establishment time so that, after label establishment, the LSR can establishment, so that after label establishment, the LSR can infer
infer exclusively from the label value the PSC to be applied to a exclusively from the label value the PSC to be applied to a labeled
labeled packet. When the Shim Header is used, the Drop Precedence to packet. When the Shim Header is used, the Drop Precedence to be
be applied by the LSR to the labeled packet, is conveyed inside the applied by the LSR to the labeled packet, is conveyed inside the
labeled packet MPLS Shim Header using the EXP field. When the Shim labeled packet MPLS Shim Header using the EXP field. When the Shim
Header is not used (e.g. MPLS Over ATM), the Drop Precedence to be Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be
applied by the LSR to the labeled packet is conveyed inside the link applied by the LSR to the labeled packet is conveyed inside the link
layer header encapsulation using link layer specific drop precedence layer header encapsulation using link layer specific drop precedence
fields (e.g. ATM CLP). fields (e.g., ATM CLP).
We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since
since the PSC can be fully inferred from the label without any other the PSC can be fully inferred from the label without any other
information (e.g. regardless of the EXP field value). Detailed information (e.g., regardless of the EXP field value). Detailed
operations of L-LSPs are specified in section 4 below. operations of L-LSPs are specified in section 4 below.
1.4 Overall Operations 1.4 Overall Operations
For a given FEC, and unless media specific restrictions apply as For a given FEC, and unless media specific restrictions apply as
identified in the sections 7, 8 and 9 below, this specification identified in the sections 7, 8 and 9 below, this specification
allows any one of the following combinations within an MPLS Diff-Serv
domain:
Le Faucheur et. al 5 - zero or any number of E-LSPs, and
allows any one of the following combinations within an MPLS Diff-
Serv domain:
- zero or any number of E-LSPs, and
- zero or any number of L-LSPs.
The network administrator selects the actual combination of LSPs - zero or any number of L-LSPs.
from the set of allowed combinations and selects how the Behavior
Aggregates are actually transported over this combination of LSPs,
in order to best match his/her environment and objectives in terms
of Diff-Serv support, Traffic Engineering and MPLS Protection.
Criteria for selecting such a combination are outside the scope of
this specification.
For a given FEC, there may be more than one LSP carrying the same The network administrator selects the actual combination of LSPs from
OA, for example for purposes of load balancing of the OA; However in the set of allowed combinations and selects how the Behavior
Aggregates are actually transported over this combination of LSPs, in
order to best match his/her environment and objectives in terms of
Diff-Serv support, Traffic Engineering and MPLS Protection. Criteria
for selecting such a combination are outside the scope of this
specification.
For a given FEC, there may be more than one LSP carrying the same OA,
for example for purposes of load balancing of the OA; However in
order to respect ordering constraints, all packets of a given order to respect ordering constraints, all packets of a given
microflow, possibly spanning multiple BAs of a given Ordered microflow, possibly spanning multiple BAs of a given Ordered
Aggregate, MUST be transported over the same LSP. Conversely, each Aggregate, MUST be transported over the same LSP. Conversely, each
LSP MUST be capable of supporting all the (active) BAs of a given LSP MUST be capable of supporting all the (active) BAs of a given OA.
OA.
Examples of deployment scenarios are provided for information in Examples of deployment scenarios are provided for information in
APPENPIX A. APPENDIX A.
1.5 Relationship between Label and FEC 1.5 Relationship between Label and FEC
[MPLS_ARCH] states in section `2.1. Overview' that: [MPLS_ARCH] states in section `2.1. Overview' that: `Some routers
`Some routers analyze a packet's network layer header not merely to analyze a packet's network layer header not merely to choose the
choose the packet's next hop, but also to determine a packet's packet's next hop, but also to determine a packet's "precedence" or
"precedence" or "class of service". They may then apply different "class of service". They may then apply different discard thresholds
discard thresholds or scheduling disciplines to different packets. or scheduling disciplines to different packets. MPLS allows (but
MPLS allows (but does not require) the precedence or class of does not require) the precedence or class of service to be fully or
service to be fully or partially inferred from the label. In this partially inferred from the label. In this case, one may say that
case, one may say that the label represents the combination of a FEC the label represents the combination of a FEC and a precedence or
and a precedence or class of service.' class of service.'
In line with this, we observe that: In line with this, we observe that:
- With E-LSPs, the label represents the combination of a FEC and
the set of BAs transported over the E-LSP). Where all the - With E-LSPs, the label represents the combination of a FEC and the
supported BAs are transported over an E-LSP, the label then set of BAs transported over the E-LSP. Where all the supported
represents the complete FEC. BAs are transported over an E-LSP, the label then represents the
- With L-LSPs, the label represents the combination of a FEC and complete FEC.
an OA.
- With L-LSPs, the label represents the combination of a FEC and an
OA.
1.6 Bandwidth Reservation for E-LSPs and L-LSPs 1.6 Bandwidth Reservation for E-LSPs and L-LSPs
Regardless of which label binding protocol is used, E-LSPs and Regardless of which label binding protocol is used, E-LSPs and L-LSPs
L-LSPs may be established without bandwidth reservation or with may be established with or without bandwidth reservation.
bandwidth reservation.
Establishing an E-LSP or L-LSP with bandwidth reservation means that Establishing an E-LSP or L-LSP with bandwidth reservation means that
bandwidth requirements for the LSP are signaled at LSP establishment bandwidth requirements for the LSP are signaled at LSP establishment
time. Such signaled bandwidth requirements may be used by LSRs at
Le Faucheur et. al 6
time. Such signaled bandwidth requirements may be used by LSRs at
establishment time to perform admission control of the signaled LSP establishment time to perform admission control of the signaled LSP
over the Diff-Serv resources provisioned (e.g. via configuration, over the Diff-Serv resources provisioned (e.g., via configuration,
SNMP or policy protocols) for the relevant PSC(s). Such signaled SNMP or policy protocols) for the relevant PSC(s). Such signaled
bandwidth requirements may also be used by LSRs at establishment bandwidth requirements may also be used by LSRs at establishment time
time to perform adjustment to the Diff-Serv resources associated to perform adjustment to the Diff-Serv resources associated with the
with the relevant PSC(s) (e.g. adjust PSC scheduling weight). relevant PSC(s) (e.g., adjust PSC scheduling weight).
Note that establishing an E-LSP or L-LSP with bandwidth reservation Note that establishing an E-LSP or L-LSP with bandwidth reservation
does not mean that per-LSP scheduling is required. Since E-LSPs and does not mean that per-LSP scheduling is required. Since E-LSPs and
L-LSPs are specified in this document for support of Differentiated L-LSPs are specified in this document for support of Differentiated
Services, the required forwarding treatment (scheduling and drop Services, the required forwarding treatment (scheduling and drop
policy) is defined by the appropriate Diff-Serv PHB. This forwarding policy) is defined by the appropriate Diff-Serv PHB. This forwarding
treatment MUST be applied by the LSR at the granularity of the BA treatment MUST be applied by the LSR at the granularity of the BA and
and MUST be compliant with the relevant PHB specification. MUST be compliant with the relevant PHB specification.
When bandwidth requirements are signaled at establishment of an When bandwidth requirements are signaled at the establishment of an
L-LSP, the signaled bandwidth is obviously associated with the L-LSP, the signaled bandwidth is obviously associated with the L-
L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform
admission control may perform admission control over Diff-Serv admission control may perform admission control over Diff-Serv
resources which are dedicated to the PSC (e.g. over the bandwidth resources, which are dedicated to the PSC (e.g., over the bandwidth
guaranteed to the PSC through its scheduling weight). guaranteed to the PSC through its scheduling weight).
When bandwidth requirements are signaled at establishment of an When bandwidth requirements are signaled at the establishment of an
E-LSP, the signaled bandwidth is associated collectively to the E-LSP, the signaled bandwidth is associated collectively with the
whole LSP and therefore to the set of transported PSCs. Thus, LSRs whole LSP and therefore with the set of transported PSCs. Thus, LSRs
which use the signaled bandwidth to perform admission control may which use the signaled bandwidth to perform admission control may
perform admission control over global resources which are shared by perform admission control over global resources, which are shared by
the set of PSCs (e.g. over the total bandwidth of the link). the set of PSCs (e.g., over the total bandwidth of the link).
Examples of scenarios where bandwidth reservation is not used and Examples of scenarios where bandwidth reservation is not used and
scenarios where bandwidth reservation is used are provided for scenarios where bandwidth reservation is used are provided for
information in APPENDIX B. information in APPENDIX B.
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models 2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models
2.1 Label Forwarding Model for Diff-Serv LSRs 2.1 Label Forwarding Model for Diff-Serv LSRs
Since different Ordered Aggregates of a given FEC may be transported Since different Ordered Aggregates of a given FEC may be transported
over different LSPs, the label swapping decision of a Diff-Serv LSR over different LSPs, the label swapping decision of a Diff-Serv LSR
clearly depends on the forwarded packet's Behavior Aggregate. Also, clearly depends on the forwarded packet's Behavior Aggregate. Also,
since the IP DS field of a forwarded packet may not be directly since the IP DS field of a forwarded packet may not be directly
visible to an LSR, the way to determine the PHB to be applied to a visible to an LSR, the way to determine the PHB to be applied to a
received packet and to encode the PHB into a transmitted packet is received packet and to encode the PHB into a transmitted packet, is
different than a non-MPLS Diff-Serv Router. different than a non-MPLS Diff-Serv Router.
Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we
model the LSR Diff-Serv label switching behavior as comprising four model the LSR Diff-Serv label switching behavior, comprised of four
stages: stages:
- Incoming PHB Determination (A)
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
Le Faucheur et. al 7 - Incoming PHB Determination (A)
- Label Forwarding (C)
- Encoding of Diff-Serv information into Encapsulation Layer (EXP,
CLP, DE, User_Priority) (D)
Each stage is described in more details in the following sections. - Outgoing PHB Determination with Optional Traffic Conditioning(B)
- Label Forwarding (C)
- Encoding of Diff-Serv information into Encapsulation Layer (EXP,
CLP, DE, User_Priority) (D)
Each stage is described in more detail in the following sections.
Obviously, to enforce the Diff-Serv service differentiation the LSR Obviously, to enforce the Diff-Serv service differentiation the LSR
MUST also apply the forwarding treatment corresponding to the MUST also apply the forwarding treatment corresponding to the
Outgoing PHB. Outgoing PHB.
This model is illustrated below: This model is illustrated below:
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)--> --Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \ \ I I \
\---->I===I I C I \-->I===I--Encaps-> \---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&) I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I -Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+ (*) I===I \--------+
\----Forwarding--> \----Forwarding-->
Treatment Treatment
(PHB) (PHB)
"Encaps" designates the Diff-Serv related information encoded in the "Encaps" designates the Diff-Serv related information encoded in the
MPLS Encapsulation layer (eg EXP field, ATM CLP, Frame Relay DE, MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE,
802.1 User_Priority) 802.1 User_Priority)
(*) when the LSR behaves as an MPLS ingress node, the incoming (*) when the LSR behaves as an MPLS ingress node, the incoming packet
packet may be received unlabelled. may be received unlabelled.
(&) when the LSR behaves as an MPLS egress node, the outgoing packet (&) when the LSR behaves as an MPLS egress node, the outgoing packet
may be transmitted unlabelled. may be transmitted unlabelled.
This model is presented here to describe the functional operations This model is presented here to describe the functional operations of
of Diff-Serv LSRs and does not constrain actual implementation. Diff-Serv LSRs and does not constrain actual implementation.
2.2 Incoming PHB Determination 2.2 Incoming PHB Determination
This stage determines which Behavior Aggregate the received packet This stage determines which Behavior Aggregate the received packet
belongs to. belongs to.
2.2.1 Incoming PHB Determination Considering a Label Stack Entry 2.2.1 Incoming PHB Determination Considering a Label Stack Entry
Sections 3.3 and 4.3 provide the details on how to perform incoming Sections 3.3 and 4.3 provide the details on how to perform incoming
PHB Determination considering a given received label stack entry PHB Determination considering a given received label stack entry
and/or received incoming MPLS encapsulation information depending on and/or received incoming MPLS encapsulation information depending on
the incoming LSP type and depending on the incoming MPLS the incoming LSP type and depending on the incoming MPLS
encapsulation. encapsulation.
Section 2.6 provides the details of which label stack entry to Section 2.6 provides the details of which label stack entry to
consider for the Incoming PHB Determination depending on the consider for the Incoming PHB Determination depending on the
supported Diff-Serv tunneling mode. supported Diff-Serv tunneling mode.
Le Faucheur et. al 8
2.2.2 Incoming PHB Determination Considering IP Header 2.2.2 Incoming PHB Determination Considering IP Header
Section 2.6 provides the details of when the IP Header is to be Section 2.6 provides the details of when the IP Header is to be
considered for incoming PHB determination depending on the supported considered for incoming PHB determination, depending on the supported
Diff-Serv tunneling model. In those cases where the IP header is to Diff-Serv tunneling model. In those cases where the IP header is to
be used, this stage operates exactly as with a non-MPLS IP Diff-Serv be used, this stage operates exactly as with a non-MPLS IP Diff-Serv
Router and uses the DS field to determine incoming PHB. Router and uses the DS field to determine the incoming PHB.
2.3 Outgoing PHB Determination With Optional Traffic Conditioning 2.3 Outgoing PHB Determination With Optional Traffic Conditioning
The traffic conditioning stage is optional and may be used on an LSR The traffic conditioning stage is optional and may be used on an LSR
to perform traffic conditioning including Behavior Aggregate to perform traffic conditioning including Behavior Aggregate demotion
demotion or promotion. It is outside the scope of this or promotion. It is outside the scope of this specification. For
specification. For the purpose of specifying Diff-Serv over MPLS the purpose of specifying Diff-Serv over MPLS forwarding, we simply
forwarding, we simply note that the PHB to be actually enforced, and note that the PHB to be actually enforced and conveyed to downstream
conveyed to downstream LSRs, by an LSR (referred to as "outgoing LSRs by an LSR (referred to as "outgoing PHB"), may be different to
PHB") may be different to the PHB which had been associated with the the PHB which had been associated with the packet by the previous LSR
packet by the previous LSR (referred to as "incoming PHB"). (referred to as "incoming PHB").
When the traffic conditioning stage is not present, the "outgoing When the traffic conditioning stage is not present, the "outgoing
PHB" is simply identical to the "incoming PHB". PHB" is simply identical to the "incoming PHB".
2.4 Label Forwarding 2.4 Label Forwarding
[MPLS_ARCH] describes how label swapping is performed by LSRs on [MPLS_ARCH] describes how label swapping is performed by LSRs on
incoming labeled packets using an Incoming Label Map (ILM), where incoming labeled packets using an Incoming Label Map (ILM), where
each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH]
also describes how label imposition is performed by LSRs on incoming also describes how label imposition is performed by LSRs on incoming
unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each
incoming FEC is mapped to one or multiple NHLFEs. incoming FEC is mapped to one or multiple NHLFEs.
A Diff-Serv Context for a label is defined as comprising: A Diff-Serv Context for a label is comprised of:
- `LSP type (ie E-LSP or L-LSP)'
- `supported PHBs' - `LSP type (i.e., E-LSP or L-LSP)'
- `Encaps-->PHB mapping' for an incoming label
- `Set of PHB-->Encaps mappings' for an outgoing label - `supported PHBs'
- `Encaps-->PHB mapping' for an incoming label
- `Set of PHB-->Encaps mappings' for an outgoing label
The present specification defines that a Diff-Serv Context is stored The present specification defines that a Diff-Serv Context is stored
in the ILM for each incoming label. in the ILM for each incoming label.
[MPLS_ARCH] states that the `NHLFE may also contain any other [MPLS_ARCH] states that the `NHLFE may also contain any other
information needed in order to properly dispose of the packet'. In information needed in order to properly dispose of the packet'. In
accordance with this, the present specification defines that a Diff- accordance with this, the present specification defines that a Diff-
Serv Context is stored in the NHLFE for each outgoing label which is Serv Context is stored in the NHLFE for each outgoing label that is
swapped or pushed. swapped or pushed.
This Diff-Serv Context information is populated into the ILM and the This Diff-Serv Context information is populated into the ILM and the
FTN at label establishment time. FTN at label establishment time.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping If the label corresponds to an E-LSP for which no `EXP<-->PHB
has been explicitly signaled at LSP setup, the `supported PHBs' is mapping' has been explicitly signaled at LSP setup, the `supported
PHBs' is populated with the set of PHBs of the preconfigured
Le Faucheur et. al 9 `EXP<-->PHB mapping', which is discussed below in section 3.2.1.
populated with the set of PHBs of the preconfigured
EXP<-->PHB Mapping, which is discussed below in section 3.2.1.
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping If the label corresponds to an E-LSP for which an `EXP<-->PHB
has been explicitly signaled at LSP setup, the `supported PHBs' is mapping' has been explicitly signaled at LSP setup, the `supported
populated with the set of PHBs of the signaled EXP<-->PHB mapping. PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB
mapping'.
If the label corresponds to an L-LSP, the `supported PHBs' is If the label corresponds to an L-LSP, the `supported PHBs' is
populated with the set of PHBs forming the PSC that is signaled at populated with the set of PHBs forming the PSC that is signaled at
LSP set-up. LSP set-up.
The details of how the `Encaps-->PHB mapping' or `Set of The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps
PHB-->Encaps mappings' are populated are defined below in sections 3 mappings' are populated are defined below in sections 3 and 4.
and 4.
[MPLS_ARCH] also states that: [MPLS_ARCH] also states that:
"If the ILM [respectively, FTN] maps a particular label to a set of "If the ILM [respectively, FTN] maps a particular label to a set of
NHLFEs that contains more than one element, exactly one element of NHLFEs that contain more than one element, exactly one element of the
the set must be chosen before the packet is forwarded. The set must be chosen before the packet is forwarded. The procedures
procedures for choosing an element from the set are beyond the scope for choosing an element from the set are beyond the scope of this
of this document. Having the ILM [respectively, FTN] map a label document. Having the ILM [respectively, FTN] map a label
[respectively, a FEC] to a set containing more than one NHLFE may be [respectively, a FEC] to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths." equal-cost paths."
In accordance with this, the present specification allows that an In accordance with this, the present specification allows that an
incoming label [respectively FEC] may be mapped, for Diff-Serv incoming label [respectively FEC] may be mapped, for Diff-Serv
purposes, to multiple NHLFEs (for instance where different NHLFEs purposes, to multiple NHLFEs (for instance where different NHLFEs
correspond to egress labels supporting different sets of PHBs). When correspond to egress labels supporting different sets of PHBs). When
a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR
LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates MUST choose one of the NHLFEs whose Diff-Serv Context indicates that
that it supports the Outgoing PHB of the forwarded packet. it supports the Outgoing PHB of the forwarded packet.
When a label [respectively FEC] maps to multiple NHLFEs which When a label [respectively FEC] maps to multiple NHLFEs which support
supports the Outgoing PHB, the procedure for choosing one among the Outgoing PHB, the procedure for choosing one among those is
those is outside the scope of this document. This situation may be outside the scope of this document. This situation may be
encountered where it is desired to do load balancing of a Behavior encountered where it is desired to do load balancing of a Behavior
Aggregate over multiple LSPs. In such situations, in order to Aggregate over multiple LSPs. In such situations, in order to
respect ordering constraints, all packets of a given microflow MUST respect ordering constraints, all packets of a given microflow MUST
be transported over the same LSP. be transported over the same LSP.
2.5 Encoding Diff-Serv Information Into Encapsulation Layer 2.5 Encoding Diff-Serv Information Into Encapsulation Layer
This stage determines how to encode the fields which convey Diff- This stage determines how to encode the fields which convey Diff-Serv
Serv information in the transmitted packet (e.g. MPLS Shim EXP, ATM information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP,
CLP, Frame Relay DE, 802.1 User_Priority). Frame Relay DE, 802.1 User_Priority).
2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry 2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry
Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv
information encoding into a given transmitted label stack entry information encoding into a given transmitted label stack entry
and/or transmitted MPLS encapsulation information depending on the and/or transmitted MPLS encapsulation information depending on the
Le Faucheur et. al 10
corresponding outgoing LSP type and depending on the MPLS corresponding outgoing LSP type and depending on the MPLS
encapsulation. encapsulation.
Section 2.6 provides the details of which label stack entry to Section 2.6 provides the details in which label stack entry to
perform Diff-Serv information encoding into depending on the perform Diff-Serv information encoding into depending on the
supported Diff-Serv tunneling mode. supported Diff-Serv tunneling mode.
2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header 2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header
To perform Diff-Serv Information Encoding into the transmitted To perform Diff-Serv Information Encoding into the transmitted packet
packet IP header, this stage operates exactly as with a non-MPLS IP IP header, this stage operates exactly as with a non-MPLS IP Diff-
Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the Serv Router and encodes the DSCP of the Outgoing PHB into the DS
DS field. field.
Section 2.6 provides the details of when Diff-Serv Information Section 2.6 provides the details of when Diff-Serv Information
Encoding is to be performed into transmitted IP header depending on Encoding is to be performed into transmitted IP header depending on
the supported Diff-Serv tunneling mode. the supported Diff-Serv tunneling mode.
2.6 Diff-Serv Tunneling Models over MPLS 2.6 Diff-Serv Tunneling Models over MPLS
2.6.1 Diff-Serv Tunneling Models 2.6.1 Diff-Serv Tunneling Models
[DIFF_TUNNEL] considers the interaction of Differentiated Services [DIFF_TUNNEL] considers the interaction of Differentiated Services
with IP tunnels of various forms. MPLS LSPs are not a form of "IP with IP tunnels of various forms. MPLS LSPs are not a form of "IP
tunnels" since the MPLS encapsulating header does not contain an IP tunnels" since the MPLS encapsulating header does not contain an IP
header and thus MPLS LSPs are not considered in [DIFF_TUNNEL]. header and thus MPLS LSPs are not considered in [DIFF_TUNNEL].
However, although not a form of "IP tunnel", MPLS LSPs are a form of However, although not a form of "IP tunnel", MPLS LSPs are a form of
"tunnel". "tunnel".
From the Diff-Serv standpoint, LSPs share a lot of characteristics From the Diff-Serv standpoint, LSPs share a number of common
with IP Tunnels: characteristics with IP Tunnels:
- Intermediate nodes (i.e. Nodes somewhere along the LSP span)
only see and operate on the "outer" Diff-Serv information.
- LSPs are unidirectional.
- The "outer" Diff-Serv information can be modified at any
intermediate nodes.
However, from the Diff-Serv standpoint, LSPs also have a - Intermediate nodes (i.e., Nodes somewhere along the LSP span) only
distinctive property compared to IP Tunnels: see and operate on the "outer" Diff-Serv information.
- There is generally no behavior analogous to Penultimate Hop
Popping (PHP) used with IP Tunnels. Furthermore, PHP results in - LSPs are unidirectional.
the "outer" Diff-Serv information associated with the LSP not
being visible to the LSP egress. In situations where this - The "outer" Diff-Serv information can be modified at any of the
information is not meaningful at the LSP Egress, this is intermediate nodes.
obviously not an issue at all. In situations where this
information is meaningful at the LSP Egress, then it must However, from the Diff-Serv standpoint, LSPs also have a distinctive
somehow be carried in some other means. property compared to IP Tunnels:
- There is generally no behavior analogous to Penultimate Hop
Popping (PHP) used with IP Tunnels. Furthermore, PHP results in
the "outer" Diff-Serv information associated with the LSP not
being visible to the LSP egress. In situations where this
information is not meaningful at the LSP Egress, this is obviously
not an issue at all. In situations where this information is
meaningful at the LSP Egress, then it must somehow be carried in
some other means.
The two conceptual models for Diff-Serv tunneling over IP Tunnels The two conceptual models for Diff-Serv tunneling over IP Tunnels
defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over
MPLS but their respective detailed operations is somewhat different MPLS but their respective detailed operations is somewhat different
over MPLS. These two models are the Pipe Model and the Uniform over MPLS. These two models are the Pipe Model and the Uniform
Model. Their operations over MPLS are specified in the following
Le Faucheur et. al 11 sections. Discussion and definition of alternative tunneling models
Model. Their operations over MPLS are specified in the following
sections. Discussion and definition of alternative tunneling models
are outside the scope of this specification. are outside the scope of this specification.
2.6.2 Pipe Model 2.6.2 Pipe Model
With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the
intermediate MPLS nodes between LSP Ingress and Egress from the intermediate MPLS nodes between LSP Ingress and Egress from the
Diff-Serv perspective. Diff-Serv perspective.
In this model, tunneled packets must convey two meaningful pieces of In this model, tunneled packets must convey two meaningful pieces of
Diff-Serv information: Diff-Serv information:
- the Diff-Serv information which is meaningful to intermediate
nodes along the LSP span including the LSP Egress (which we - the Diff-Serv information which is meaningful to intermediate
refer to as the "LSP Diff-Serv Information"). This LSP Diff-Serv nodes along the LSP span including the LSP Egress (which we refer
Information is not meaningful beyond the LSP Egress: Whether to as the "LSP Diff-Serv Information"). This LSP Diff-Serv
Traffic Conditioning at intermediate nodes on the LSP span Information is not meaningful beyond the LSP Egress: Whether
affects the LSP Diff-Serv information or not, this updated Diff- Traffic Conditioning at intermediate nodes on the LSP span affects
Serv information is not considered meaningful beyond the LSP the LSP Diff-Serv information or not, this updated Diff-Serv
Egress and is ignored. information is not considered meaningful beyond the LSP Egress and
- the Diff-Serv information which is meaningful beyond the LSP is ignored.
Egress (which we refer to as the "Tunneled Diff-Serv
Information"). This information is to be conveyed by the LSP - the Diff-Serv information which is meaningful beyond the LSP
Ingress to the LSP Egress. This Diff-Serv information is not Egress (which we refer to as the "Tunneled Diff-Serv
meaningful to the intermediate nodes on the LSP span. Information"). This information is to be conveyed by the LSP
Ingress to the LSP Egress. This Diff-Serv information is not
meaningful to the intermediate nodes on the LSP span.
Operation of the Pipe Model without PHP is illustrated below: Operation of the Pipe Model without PHP is illustrated below:
========== LSP =============================> ========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap---- ---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \ / (outer header) \
(M) (M) (M) (M)
/ \ / \
>--(m)-Push.................(m).....................Pop--(m)--> >--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*) I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information" (M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information" (m) represents the "Tunneled Diff-Serv information"
(*) The LSP Egress considers the LSP Diff-Serv information received (*) The LSP Egress considers the LSP Diff-Serv information received
in the outer header (i.e. before the pop) in order to apply its in the outer header (i.e., before the pop) in order to apply its
Diff-Serv forwarding treatment (i.e. actual PHB) Diff-Serv forwarding treatment (i.e., actual PHB)
I represents the LSP ingress node I represents the LSP ingress node
E represents the LSP egress node E represents the LSP egress node
With the Pipe Model, the "LSP Diff-Serv Information" needs to be With the Pipe Model, the "LSP Diff-Serv Information" needs to be
conveyed to LSP Egress so that it applies its forwarding treatment conveyed to the LSP Egress so that it applies its forwarding
based on it. The "Tunneled Diff-Serv information" also needs to be treatment based on it. The "Tunneled Diff-Serv information" also
conveyed to the LSP Egress so it can be conveyed further downstream. needs to be conveyed to the LSP Egress so it can be conveyed further
downstream.
Le Faucheur et. al 12 Since both require that Diff-Serv information be conveyed to the LSP
Since both Diff-Serv information need to be conveyed to the LSP
Egress, the Pipe Model operates only without PHP. Egress, the Pipe Model operates only without PHP.
The Pipe Model is particularly appropriate to environments in which: The Pipe Model is particularly appropriate for environments in which:
- the cloud upstream of the incoming interface of the LSP Ingress
and the cloud downstream of the outgoing interface of the LSP
Egress are in Diff-Serv domains which use a common set of Diff-
Serv service provisioning policies and PHB definitions, while
the LSP spans one (or more) Diff-Serv domain(s) which use(s) a
different set of Diff-Serv service provisioning policies and PHB
definitions
- the outgoing interface of the LSP Egress is in the (last) Diff-
Serv domain spanned by the LSP.
As an example, consider the case where a service provider is - the cloud upstream of the incoming interface of the LSP Ingress
offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS and the cloud downstream of the outgoing interface of the LSP
VPN architecture) including Diff-Serv differentiation. Say that a Egress are in Diff-Serv domains which use a common set of Diff-
collection of sites are interconnected via such an MPLS VPN service. Serv service provisioning policies and PHB definitions, while the
Now say that this collection of sites are managed under a common LSP spans one (or more) Diff-Serv domain(s) which use(s) a
administration and are also supporting Diff-Serv service different set of Diff-Serv service provisioning policies and PHB
differentiation. If the VPN site administration and the Service definitions
- the outgoing interface of the LSP Egress is in the (last) Diff-
Serv domain spanned by the LSP.
As an example, consider the case where a service provider is offering
an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN
architecture) including Diff-Serv differentiation. Say that a
collection of sites is interconnected via such an MPLS VPN service.
Now say that this collection of sites is managed under a common
administration and is also supporting Diff-Serv service
differentiation. If the VPN site administration and the Service
Provider are not sharing the exact same Diff-Serv policy (for Provider are not sharing the exact same Diff-Serv policy (for
instance not supporting the same number of PHBs), then operation of instance not supporting the same number of PHBs), then operation of
Diff-Serv in the Pipe Model over the MPLS VPN service would allow Diff-Serv in the Pipe Model over the MPLS VPN service would allow the
the VPN Sites Diff-Serv policy to operate consistently throughout VPN Sites Diff-Serv policy to operate consistently throughout the
the ingress VPN Site and Egress VPN Site and transparently over the ingress VPN Site and Egress VPN Site and transparently over the
Service Provider Diff-Serv domain. It may be useful to view such Service Provider Diff-Serv domain. It may be useful to view such
LSPs as linking the Diff-Serv domains at their endpoints into a LSPs as linking the Diff-Serv domains at their endpoints into a
single Diff-Serv region by making these endpoints virtually single Diff-Serv region by making these endpoints virtually
contiguous even though they may be physically separated by contiguous even though they may be physically separated by
intermediate network nodes. intermediate network nodes.
The Pipe Model MUST be supported. The Pipe Model MUST be supported.
For support of the Pipe Model over a given LSP without PHP, an LSR For support of the Pipe Model over a given LSP without PHP, an LSR
performs the Incoming PHB Determination and the Diff-Serv performs the Incoming PHB Determination and the Diff-Serv information
information Encoding in the following manner: Encoding in the following manner:
- when receiving an unlabelled packet, the LSR performs Incoming
PHB Determination considering the received IP Header.
- when receiving a labeled packet, the LSR performs Incoming PHB
Determination considering the outer label entry in the received
label stack. In particular, when a pop operation is to be
performed for the considered LSP, the LSR performs Incoming PHB
Determination BEFORE the pop.
- when performing a push operation for the considered LSP, the
LSR:
o encodes Diff-Serv Information corresponding to the
OUTGOING PHB in the transmitted label entry corresponding
to the pushed label.
o encodes Diff-Serv Information corresponding to the
INCOMING PHB in the encapsulated header (swapped label
entry or IP header).
Le Faucheur et. al 13 - when receiving an unlabelled packet, the LSR performs Incoming PHB
- when performing a swap-only operation for the considered LSP, Determination considering the received IP Header.
the LSR encodes Diff-Serv Information in the transmitted label
entry that contains the swapped label - when receiving a labeled packet, the LSR performs Incoming PHB
- when performing a pop operation for the considered LSP, the LSR Determination considering the outer label entry in the received
does not perform Encoding of Diff-Serv Information into the label stack. In particular, when a pop operation is to be
header exposed by the pop operation (i.e. the LSR leaves the performed for the considered LSP, the LSR performs Incoming PHB
exposed header "as is"). Determination BEFORE the pop.
- when performing a push operation for the considered LSP, the LSR:
o encodes Diff-Serv Information corresponding to the OUTGOING PHB
in the transmitted label entry corresponding to the pushed
label.
o encodes Diff-Serv Information corresponding to the INCOMING PHB
in the encapsulated header (swapped label entry or IP header).
- when performing a swap-only operation for the considered LSP, the
LSR encodes Diff-Serv Information in the transmitted label entry
that contains the swapped label
- when performing a pop operation for the considered LSP, the LSR
does not perform Encoding of Diff-Serv Information into the header
exposed by the pop operation (i.e., the LSR leaves the exposed
header "as is").
2.6.2.1 Short Pipe Model 2.6.2.1 Short Pipe Model
The Short Pipe Model is an optional variation over the Pipe Model The Short Pipe Model is an optional variation of the Pipe Model
described above. The only difference is that, with the Short Pipe described above. The only difference is that, with the Short Pipe
Model, the Diff-Serv forwarding treatment at the LSP Egress is Model, the Diff-Serv forwarding treatment at the LSP Egress is
applied based on the "Tunneled Diff-Serv Information" (i.e. Diff- applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-
Serv information conveyed in the encapsulated header) rather than on Serv information conveyed in the encapsulated header) rather than on
the "LSP Diff-Serv information" (i.e. Diff-Serv information conveyed the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed
in the encapsulating header). in the encapsulating header).
Operation of the Short Pipe Model without PHP is illustrated below: Operation of the Short Pipe Model without PHP is illustrated below:
========== LSP =============================> ========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap---- ---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \ / (outer header) \
(M) (M) (M) (M)
/ \ / \
>--(m)-Push.................(m).....................Pop--(m)--> >--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E I (inner header) E
(M) represents the "LSP Diff-Serv information" (M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information" (m) represents the "Tunneled Diff-Serv information"
I represents the LSP ingress node I represents the LSP ingress node
E represents the LSP egress node E represents the LSP egress node
Since the LSP Egress applies its forwarding treatment based on the Since the LSP Egress applies its forwarding treatment based on the
"Tunneled Diff-Serv Information", the "LSP Diff-Serv information" "Tunneled Diff-Serv Information", the "LSP Diff-Serv information"
does not need to be conveyed by the penultimate node to the LSP does not need to be conveyed by the penultimate node to the LSP
Egress. Thus the Short Pipe Model can also operate with PHP. Egress. Thus the Short Pipe Model can also operate with PHP.
Operation of the Short Pipe Model with PHP is illustrated below: Operation of the Short Pipe Model with PHP is illustrated below:
=========== LSP ============================> =========== LSP ============================>
---Swap--(M)--...--Swap------ ---Swap--(M)--...--Swap------
/ (outer header) \ / (outer header) \
(M) (M) (M) (M)
/ \ / \
>--(m)-Push.................(m).............Pop-(m)--E--(m)--> >--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*) I (inner header) P (M*)
Le Faucheur et. al 14
(M) represents the "LSP Diff-Serv information" (M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information" (m) represents the "Tunneled Diff-Serv information"
(*) The Penultimate LSR considers the LSP Diff-Serv information (*) The Penultimate LSR considers the LSP Diff-Serv information
received in the outer header (i.e. before the pop) in order to received in the outer header (i.e., before the pop) in order to
apply its Diff-Serv forwarding treatment (i.e. actual PHB) apply its Diff-Serv forwarding treatment (i.e., actual PHB)
I represents the LSP ingress node I represents the LSP ingress node
P represents the LSP penultimate node P represents the LSP penultimate node
E represents the LSP egress node E represents the LSP egress node
The Short Pipe Model is particularly appropriate to environments in The Short Pipe Model is particularly appropriate for environments in
which: which:
- the cloud upstream of the incoming interface of the LSP Ingress
and the cloud downstream of the outgoing interface of the LSP - the cloud upstream of the incoming interface of the LSP Ingress
Egress are in Diff-Serv domains which use a common set of Diff- and the cloud downstream of the outgoing interface of the LSP
Serv service provisioning policies and PHB definitions, while Egress are in Diff-Serv domains which use a common set of Diff-
the LSP spans one (or more) Diff-Serv domain(s) which use(s) a Serv service provisioning policies and PHB definitions, while the
different set of Diff-Serv service provisioning policies and PHB LSP spans one (or more) Diff-Serv domain(s) which use(s) a
definitions different set of Diff-Serv service provisioning policies and PHB
- the outgoing interface of the LSP Egress is in the same Diff- definitions
Serv domain as the cloud downstream of it.
- the outgoing interface of the LSP Egress is in the same Diff-Serv
domain as the cloud downstream of it.
Since each outgoing interface of the LSP Egress is in the same Diff- Since each outgoing interface of the LSP Egress is in the same Diff-
Serv domain as the cloud downstream of it, each outgoing interface Serv domain as the cloud downstream of it, each outgoing interface
may potentially be in a different Diff-Serv domain, and the LSP may potentially be in a different Diff-Serv domain, and the LSP
Egress needs to be configured with awareness of every corresponding Egress needs to be configured with awareness of every corresponding
Diff-Serv policy. This operational overhead is justified in some Diff-Serv policy. This operational overhead is justified in some
situations where the respective downstream Diff-Serv policies are situations where the respective downstream Diff-Serv policies are
better suited to offering service differentiation over each egress better suited to offering service differentiation over each egress
interface than the common Diff-Serv policy used on the LSP span. An interface than the common Diff-Serv policy used on the LSP span. An
example of such a situation is where a Service Provider offers an example of such a situation is where a Service Provider offers an
MPLS VPN service and where some VPN users request that their own VPN MPLS VPN service and where some VPN users request that their own VPN
Diff-Serv policy be applied to control service differentiation on Diff-Serv policy be applied to control service differentiation on the
the dedicated link from the LSP Egress to the destination VPN site, dedicated link from the LSP Egress to the destination VPN site,
rather than the Service Provider's Diff-Serv policy. rather than the Service Provider's Diff-Serv policy.
The Short Pipe Model MAY be supported. The Short Pipe Model MAY be supported.
For support of the Short Pipe Model over a given LSP without PHP, an For support of the Short Pipe Model over a given LSP without PHP, an
LSR performs the Incoming PHB Determination and the Diff-Serv LSR performs the Incoming PHB Determination and the Diff-Serv
information Encoding in the same manner as with the Pipe Model with information Encoding in the same manner as with the Pipe Model with
the following exception: the following exception:
- when receiving a labeled packet, the LSR performs Incoming PHB
Determination considering the header (label entry or IP header)
which is used to do the actual forwarding. In particular, when a
pop operation is to be performed for the considered LSP, the LSR
performs Incoming PHB Determination AFTER the pop.
For support of the Short Pipe Model over a given LSP with PHP, an - when receiving a labeled packet, the LSR performs Incoming PHB
LSR performs Incoming PHB Determination and Diff-Serv information Determination considering the header (label entry or IP header)
which is used to do the actual forwarding. In particular, when a
pop operation is to be performed for the considered LSP, the LSR
performs Incoming PHB Determination AFTER the pop.
For support of the Short Pipe Model over a given LSP with PHP, an LSR
performs Incoming PHB Determination and Diff-Serv information
Encoding in the same manner as without PHP with the following Encoding in the same manner as without PHP with the following
exceptions: exceptions:
Le Faucheur et. al 15 - the Penultimate LSR performs Incoming PHB Determination
- the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In
considering the outer label entry in the received label stack. other words, when a pop operation is to be performed for the
In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB
considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop.
Determination BEFORE the pop.
Note that the behavior of the Penultimate LSR in the Short Pipe Mode Note that the behavior of the Penultimate LSR in the Short Pipe Mode
with PHP, is identical to the behavior of the LSP Egress in the Pipe with PHP, is identical to the behavior of the LSP Egress in the Pipe
Mode (necessarily without PHP). Mode (necessarily without PHP).
2.6.3 Uniform Model 2.6.3 Uniform Model
With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as
artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS
Tunnels may be used for forwarding purposes but have no significant Tunnels may be used for forwarding purposes but have no significant
impact on Diff-Serv. In this model, any packet contains exactly one impact on Diff-Serv. In this model, any packet contains exactly one
piece of Diff-Serv information which is meaningful and is always piece of Diff-Serv information which is meaningful and is always
encoded in the outer most label entry (or in the IP DSCP where the encoded in the outer most label entry (or in the IP DSCP where the IP
IP packet is transmitted unlabelled for instance at the egress of packet is transmitted unlabelled for instance at the egress of the
the LSP). Any Diff-Serv information encoded somewhere else (e.g. in LSP). Any Diff-Serv information encoded somewhere else (e.g., in
deeper label entries) is of no significance to intermediate nodes or deeper label entries) is of no significance to intermediate nodes or
to the tunnel egress and is ignored. If Traffic Conditioning at to the tunnel egress and is ignored. If Traffic Conditioning at
intermediate nodes on the LSP span affects the "outer" Diff-Serv intermediate nodes on the LSP span affects the "outer" Diff-Serv
information, the updated Diff-Serv information is the one considered information, the updated Diff-Serv information is the one considered
meaningful at the egress of the LSP. meaningful at the egress of the LSP.
Operation of the Uniform Model without PHP is illustrated below: Operation of the Uniform Model without PHP is illustrated below:
========== LSP =============================> ========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap---- ---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \ / (outer header) \
(M) (M) (M) (M)
/ \ / \
>--(M)--Push...............(x).......................Pop--(M)-> >--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E I (inner header) E
(M) represents the Meaningful Diff-Serv information encoded in the (M) represents the Meaningful Diff-Serv information encoded in the
corresponding header. corresponding header.
(x) represents non-meaningful Diff-Serv information. (x) represents non-meaningful Diff-Serv information.
I represents the LSP ingress node I represents the LSP ingress node
E represents the LSP egress node E represents the LSP egress node
Operation of the Uniform Model with PHP is illustrated below : Operation of the Uniform Model with PHP is illustrated below:
========== LSP =========================> ========== LSP =========================>
---Swap-(M)-...-Swap------ ---Swap-(M)-...-Swap------
/ (outer header) \ / (outer header) \
(M) (M) (M) (M)
/ \ / \
Le Faucheur et. al 16
>--(M)--Push..............(x)............Pop-(M)--E--(M)-> >--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P I (inner header) P
(M) represents the Meaningful Diff-Serv information encoded in the (M) represents the Meaningful Diff-Serv information encoded in the
corresponding header. corresponding header.
(x) represents non-meaningful Diff-Serv information. (x) represents non-meaningful Diff-Serv information.
I represents the LSP ingress node I represents the LSP ingress node
P represents the LSP penultimate node P represents the LSP penultimate node
E represents the LSP egress node E represents the LSP egress node
The Uniform Model for Diff-Serv over MPLS is such that, from the The Uniform Model for Diff-Serv over MPLS is such that, from the
Diff-Serv perspective, operations are exactly identical to the Diff-Serv perspective, operations are exactly identical to the
operations if MPLS was not used. In other words, MPLS is entirely operations if MPLS was not used. In other words, MPLS is entirely
transparent to the Diff-Serv operations. transparent to the Diff-Serv operations.
Use of the Uniform Model allows LSPs to span Diff-Serv domain Use of the Uniform Model allows LSPs to span Diff-Serv domain
boundaries without any other measure in place than an inter-domain boundaries without any other measure in place than an inter-domain
Traffic Conditioning Agreement at the physical boundary between the Traffic Conditioning Agreement at the physical boundary between the
Diff-Serv domains and operating exclusively on the "outer" header, Diff-Serv domains and operating exclusively on the "outer" header,
since the meaningful Diff-Serv information is always visible and since the meaningful Diff-Serv information is always visible and
modifiable in the outmost label entry. modifiable in the outmost label entry.
The Uniform Model MAY be supported. The Uniform Model MAY be supported.
For support of the Uniform Model over a given LSP, an LSR performs For support of the Uniform Model over a given LSP, an LSR performs
Incoming PHB Determination and Diff-Serv information Encoding in the Incoming PHB Determination and Diff-Serv information Encoding in the
following manner: following manner:
- when receiving an unlabelled packet, the LSR performs Incoming
PHB Determination considering the received IP Header.
- when receiving a labeled packet, the LSR performs Incoming PHB
Determination considering the outer label entry in the received
label stack. In particular, when a pop operation is to be
performed for the considered LSP, the LSR performs Incoming PHB
Determination BEFORE the pop.
- when performing a push operation for the considered LSP, the LSR
encodes Diff-Serv Information in the transmitted label entry
corresponding to the pushed label. The Diff-Serv Information
encoded in the encapsulated header (swapped label entry or IP
Header) is of no importance.
- when performing a swap-only operation for the considered LSP,
the LSR encodes Diff-Serv Information in the transmitted label
entry that contains the swapped label.
- when PHP is used, the Penultimate LSR needs to be aware of the
"Set of PHB-->Encaps mappings" for the label corresponding to
the exposed header (or the PHB-->DSCP mapping) in order to
perform Diff-Serv Information Encoding. Methods for providing
this mapping awareness are outside the scope of this
specification. As an example, the "PHB-->DSCP mapping" may be
locally configured. As another example, in some environments, it
may be appropriate for the Penultimate LSR to assume that the
"Set of PHB-->Encaps mappings" to be used for the outgoing label
Le Faucheur et. al 17 - when receiving an unlabelled packet, the LSR performs Incoming PHB
in the exposed header is the "Set of PHB-->Encaps mappings" that Determination considering the received IP Header.
would be used by the LSR if the LSR was not doing PHP.
Note also that this specification assumes that the Penultimate
LSR does not perform label swapping over the label entry exposed
by the pop operation (and in fact that it does not even look at
the exposed label). Consequently, restrictions may apply to the
Diff-Serv Information Encoding that can be performed by the
Penultimate LSR. For example, this specification does not allow
situations where the Penultimate LSR pops a label corresponding
to an E-LSP supporting two PSCs, while the header exposed by the
pop contains label values for two L-LSPs each supporting one
PSC, since the Diff-Serv Information Encoding would require
selecting one label or the other.
Note that LSR behaviors for the Pipe , the Short Pipe and the - when receiving a labeled packet, the LSR performs Incoming PHB
Uniform Model only differ when doing a push or a pop. Thus, Determination considering the outer label entry in the received
Intermediate LSRs which perform swap only operations for an LSP, label stack. In particular, when a pop operation is to be
behave exactly in the same way regardless of whether they are performed for the considered LSP, the LSR performs Incoming PHB
behaving in the Pipe, Short Pipe or the Uniform model. With a Diff- Determination BEFORE the pop.
Serv implementation supporting multiple Tunneling Models, only LSRs
behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be - when performing a push operation for the considered LSP, the LSR
configured to operate in a particular Model. Signaling to associate encodes Diff-Serv Information in the transmitted label entry
a Diff-Serv tunneling model on a per-LSP basis is out of the scope corresponding to the pushed label. The Diff-Serv Information
of this specification. encoded in the encapsulated header (swapped label entry or IP
Header) is of no importance.
- when performing a swap-only operation for the considered LSP, the
LSR encodes Diff-Serv Information in the transmitted label entry
that contains the swapped label.
- when PHP is used, the Penultimate LSR needs to be aware of the
"Set of PHB-->Encaps mappings" for the label corresponding to the
exposed header (or the `PHB-->DSCP mapping') in order to perform
Diff-Serv Information Encoding. Methods for providing this
mapping awareness are outside the scope of this specification. As
an example, the "PHB-->DSCP mapping" may be locally configured.
As another example, in some environments, it may be appropriate
for the Penultimate LSR to assume that the "Set of PHB-->Encaps
mappings" to be used for the outgoing label in the exposed header
is the "Set of PHB-->Encaps mappings" that would be used by the
LSR if the LSR was not doing PHP. Note also that this
specification assumes that the Penultimate LSR does not perform
label swapping over the label entry exposed by the pop operation
(and in fact that it does not even look at the exposed label).
Consequently, restrictions may apply to the Diff-Serv Information
Encoding that can be performed by the Penultimate LSR. For
example, this specification does not allow situations where the
Penultimate LSR pops a label corresponding to an E-LSP supporting
two PSCs, while the header exposed by the pop contains label
values for two L-LSPs each supporting one PSC, since the Diff-Serv
Information Encoding would require selecting one label or the
other.
Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform
Model only differ when doing a push or a pop. Thus, Intermediate
LSRs which perform swap only operations for an LSP, behave in exactly
the same way, regardless of whether they are behaving in the Pipe,
Short Pipe or the Uniform model. With a Diff-Serv implementation
supporting multiple Tunneling Models, only LSRs behaving as LSP
Ingress, Penultimate LSR or LSP Egress need to be configured to
operate in a particular Model. Signaling to associate a Diff-Serv
tunneling model on a per-LSP basis is not within the scope of this
specification.
2.6.4 Hierarchy 2.6.4 Hierarchy
Through the label stack mechanism, MPLS allows LSP tunneling to nest Through the label stack mechanism, MPLS allows LSP tunneling to nest
to any depth. We observe that with such nesting, the push of level to any depth. We observe that with such nesting, the push of level
N+1 takes place on a subsequent (or the same) LSR to the LSR doing N+1 takes place on a subsequent (or the same) LSR to the LSR doing
the push for level N, while the pop of level N+1 takes place on a the push for level N, while the pop of level N+1 takes place on a
previous (or the same) LSR to the LSR doing the pop of level N. For previous (or the same) LSR to the LSR doing the pop of level N. For
a given level N LSP, the Ingress LSR doing the push and the LSR a given level N LSP, the Ingress LSR doing the push and the LSR doing
doing the pop (Penultimate LSR or LSP Egress) must operate in the the pop (Penultimate LSR or LSP Egress) must operate in the same
same Tunneling Model (i.e. Pipe, Short Pipe or Uniform). However, Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However, there
there is no requirement for consistent tunneling models across is no requirement for consistent tunneling models across levels so
levels so that LSPs at different levels may be operating in that LSPs at different levels may be operating in different Tunneling
different Tunneling Models. Models.
Hierarchical operations is illustrated below in the case of two Hierarchical operations are illustrated below in the case of two
levels of tunnels: levels of tunnels:
+--------Swap--...---+ +--------Swap--...---+
/ (outmost header) \ / (outmost header) \
/ \ / \
Push(2).................(2)Pop Push(2).................(2)Pop
/ (outer header) \ / (outer header) \
/ \ / \
>>---Push(1)........................(1)Pop-->> >>---Push(1)........................(1)Pop-->>
(inner header) (inner header)
(1) Tunneling Model 1 (1) Tunneling Model 1
Le Faucheur et. al 18
(2) Tunneling Model 2 (2) Tunneling Model 2
Tunneling Model 2 may be the same as or may be different to
Tunneling Model 2 may be the same as or may be different from
Tunneling Model 1. Tunneling Model 1.
For a given LSP of level N, the LSR must perform the Incoming PHB For a given LSP of level N, the LSR must perform the Incoming PHB
Determination and the Diff-Serv information Encoding as specified in Determination and the Diff-Serv information Encoding as specified in
section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of
this level N LSP and independently of the Tunneling Model of other this level N LSP and independently of the Tunneling Model of other
level LSPs. level LSPs.
3. Detailed Operations of E-LSPs 3. Detailed Operations of E-LSPs
3.1 E-LSP Definition 3.1 E-LSP Definition
E-LSPs are defined in section 1.2. E-LSPs are defined in section 1.2.
Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
pre-configured mapping are capable of transporting the same common pre-configured mapping are capable of transporting the same common
set of 8, or fewer, BAs. Each of those E-LSPs may actually transport set of 8, or fewer, BAs. Each of those E-LSPs may actually transport
this full set of BAs or any arbitrary subset of it. this full set of BAs or any arbitrary subset of it.
For a given FEC, two given E-LSPs using signaled EXP<-->PHB mapping For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB
can support the same or different sets of Ordered Aggregates. mapping' can support the same or different sets of Ordered
Aggregates.
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP 3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
Context is populated for an incoming E-LSP in order to allow Context is populated for an incoming E-LSP in order to allow Incoming
Incoming PHB determination. PHB determination.
The `Encaps-->PHB mapping' for an E-LSP is always of the form The `Encaps-->PHB mapping' for an E-LSP is always of the form
`EXP-->PHB mapping'. `EXP-->PHB mapping'.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping If the label corresponds to an E-LSP for which no `EXP<-->PHB
has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB
is populated based on the Preconfigured EXP<-->PHB Mapping which is mapping' is populated based on the Preconfigured `EXP<-->PHB mapping'
discussed below in section 3.2.1. which is discussed below in section 3.2.1.
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping If the label corresponds to an E-LSP for which an `EXP<-->PHB
has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB
is populated as per the signaled EXP<-->PHB mapping. mapping' is populated as per the signaled `EXP<-->PHB mapping'.
3.2.1 Preconfigured EXP<-->PHB mapping 3.2.1 Preconfigured `EXP<-->PHB mapping'
LSRs supporting E-LSPs which use the preconfigured EXP<-->PHB LSRs supporting E-LSPs which use the preconfigured `EXP<-->PHB
mapping must allow local configuration of this EXP<-->PHB mapping. mapping' must allow local configuration of this `EXP<-->PHB mapping'.
This mapping applies to all the E-LSPs established on this LSR This mapping applies to all the E-LSPs established on this LSR
without a mapping explicitly signaled at set-up time. without a mapping explicitly signaled at set-up time.
Le Faucheur et. al 19 The preconfigured `EXP<-->PHB mapping' must either be consistent at
The preconfigured EXP<-->PHB mapping must either be consistent at
every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the
LSP or appropriate remarking of the EXP field must be performed by LSP or appropriate remarking of the EXP field must be performed by
the LSR whenever a different preconfigured mapping is used on the the LSR whenever a different preconfigured mapping is used on the
ingress and egress interfaces. ingress and egress interfaces.
In case, the preconfigured EXP<-->PHB mapping has not actually been In case, the preconfigured `EXP<-->PHB mapping' has not actually been
configured by the Network Administrator, the LSR should use a configured by the Network Administrator, the LSR should use a default
default preconfigured EXP<-->PHB mapping which maps all EXP values preconfigured `EXP<-->PHB mapping' which maps all EXP values to the
to the Default PHB. Default PHB.
3.3 Incoming PHB Determination On Incoming E-LSP 3.3 Incoming PHB Determination On Incoming E-LSP
This section defines how Incoming PHB Determination is carried out This section defines how Incoming PHB Determination is carried out
when the considered label entry in the received label stack when the considered label entry in the received label stack
corresponds to an E-LSP. This requires that the `Encaps-->PHB corresponds to an E-LSP. This requires that the `Encaps-->PHB
mapping' is populated as defined in section 3.2. mapping' is populated as defined in section 3.2.
When considering a label entry corresponding to an incoming E-LSP When considering a label entry corresponding to an incoming E-LSP for
for Incoming PHB Determination, the LSR: Incoming PHB Determination, the LSR:
- determines the EXP-->PHB mapping by looking up the
`Encaps-->PHB mapping' of the Diff-Serv Context associated in - determines the `EXP-->PHB mapping' by looking up the `Encaps-->PHB
the ILM with the considered incoming E-LSP label. mapping' of the Diff-Serv Context associated in the ILM with the
- determines the incoming PHB by looking up the EXP field of the considered incoming E-LSP label.
considered label entry in the EXP-->PHB mapping table.
- determines the incoming PHB by looking up the EXP field of the
considered label entry in the `EXP-->PHB mapping' table.
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP 3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP
This section defines how the `Set of PHB-->Encaps mappings' of the This section defines how the `Set of PHB-->Encaps mappings' of the
Diff-Serv Context is populated at label setup for an outgoing E-LSP Diff-Serv Context is populated at label setup for an outgoing E-LSP
in order to allow Encoding of Diff-Serv information in the in order to allow Encoding of Diff-Serv information in the
Encapsulation Layer. Encapsulation Layer.
3.4.1 `PHB-->EXP mapping' 3.4.1 `PHB-->EXP mapping'
An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of
the `Set of PHB-->Encaps mappings' of its Diff-Serv Context. the `Set of PHB-->Encaps mappings' of its Diff-Serv Context.
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping If the label corresponds to an E-LSP for which no `EXP<-->PHB
has been explicitly signaled at LSP setup, this `PHB-->EXP mapping' mapping' has been explicitly signaled at LSP setup, this `PHB-->EXP
is populated based on the Preconfigured EXP<-->PHB Mapping which is mapping' is populated based on the Preconfigured `EXP<-->PHB mapping'
discussed above in section 3.2.1. which is discussed above in section 3.2.1.
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping If the label corresponds to an E-LSP for which an `EXP<-->PHB
has been explicitly signaled at LSP setup, the `PHB-->EXP mapping' mapping' has been explicitly signaled at LSP setup, the `PHB-->EXP
is populated as per the signaled EXP<-->PHB mapping. mapping' is populated as per the signaled `EXP<-->PHB mapping'.
3.4.2 `PHB-->CLP mapping' 3.4.2 `PHB-->CLP mapping'
If the LSP is egressing over an ATM interface which is not label If the LSP is egressing over an ATM interface which is not label
switching controlled, then one `PHB-->CLP mapping' is added to the switching controlled, then one `PHB-->CLP mapping' is added to the
`Set of PHB-->Encaps mappings' for this outgoing LSP. This
Le Faucheur et. al 20
`Set of PHB-->Encaps mappings' for this outgoing LSP. This
`PHB-->CLP mapping' is populated in the following way: `PHB-->CLP mapping' is populated in the following way:
- it is a function of the PHBs supported on this LSP, and may use
the relevant mapping entries for these PHBs from the - it is a function of the PHBs supported on this LSP, and may use
Default PHB-->CLP Mapping defined in section 3.4.2.1. Other the relevant mapping entries for these PHBs from the Default
mappings than the one defined in section 3.4.2.1 may be used. In `PHB-->CLP mapping' defined in section 3.4.2.1. Mappings other
particular, if a mapping from PHBs to CLP is standardized in the than the one defined in section 3.4.2.1 may be used. In
future for operations of Diff-Serv over ATM, such standardized particular, if a mapping from PHBs to CLP is standardized in the
mapping may then be used. future for operations of Diff-Serv over ATM, such a standardized
mapping may then be used.
For example if the outgoing label corresponds to an LSP supporting For example if the outgoing label corresponds to an LSP supporting
the AF1 PSC , then the `PHB-->CLP mapping' may be populated with: the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
PHB CLP Field PHB CLP Field
AF11 ----> 0 AF11 ----> 0
AF12 ----> 1 AF12 ----> 1
AF13 ----> 1 AF13 ----> 1
EF ----> 0 EF ----> 0
Notice that in this case the `Set of PHB-->Encaps mappings' contains Notice that in this case the `Set of PHB-->Encaps mappings' contains
both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.
3.4.2.1 Default PHB-->CLP Mapping 3.4.2.1 Default `PHB-->CLP mapping'
PHB CLP Bit PHB CLP Bit
DF ----> 0 DF ----> 0
CSn ----> 0 CSn ----> 0
AFn1 ----> 0 AFn1 ----> 0
AFn2 ----> 1 AFn2 ----> 1
AFn3 ----> 1 AFn3 ----> 1
EF ----> 0 EF ----> 0
3.4.3 `PHB-->DE mapping' 3.4.3 `PHB-->DE mapping'
If the LSP is egressing over a Frame Relay interface which is not If the LSP is egressing over a Frame Relay interface which is not
label switching controlled, one `PHB-->DE mapping' is added to the label switching controlled, one `PHB-->DE mapping' is added to the
`Set of PHB-->Encaps mappings' for this outgoing LSP and is `Set of PHB-->Encaps mappings' for this outgoing LSP and is populated
populated in the following way: in the following way:
- it is a function of the PHBs supported on this LSP, and may use
the relevant mapping entries for these PHBs from the Default - it is a function of the PHBs supported on this LSP, and may use
PHB-->DE Mapping defined in section 3.4.3.1. Other mappings than the relevant mapping entries for these PHBs from the Default
the one defined in section 3.4.3.1 may be used. In particular, `PHB-->DE mapping' defined in section 3.4.3.1. Mappings other
if a mapping from PHBs to DE is standardized in the future for than the one defined in section 3.4.3.1 may be used. In
operations of Diff-Serv over Frame Relay, such standardized particular, if a mapping from PHBs to DE is standardized in the
mapping may then be used. future for operations of Diff-Serv over Frame Relay, such a
standardized mapping may then be used.
Notice that in this case the `Set of PHB-->Encaps mappings' contains Notice that in this case the `Set of PHB-->Encaps mappings' contains
both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
3.4.3.1 Default PHB-->DE Mapping 3.4.3.1 `Default PHB-->DE mapping'
Le Faucheur et. al 21 PHB DE Bit
PHB DE Bit
DF ----> 0 DF ----> 0
CSn ----> 0 CSn ----> 0
AFn1 ----> 0 AFn1 ----> 0
AFn2 ----> 1 AFn2 ----> 1
AFn3 ----> 1 AFn3 ----> 1
EF ----> 0 EF ----> 0
3.4.4 `PHB-->802.1 mapping' 3.4.4 `PHB-->802.1 mapping'
If the LSP is egressing over a LAN interface on which multiple 802.1 If the LSP is egressing over a LAN interface on which multiple 802.1
Traffic Classes are supported as per [IEEE_802.1], then one Traffic Classes are supported as per [IEEE_802.1], then one
`PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings'
for this outgoing LSP. This `PHB-->802.1 mapping' is populated in for this outgoing LSP. This `PHB-->802.1 mapping' is populated in
the following way: the following way:
- it is a function of the PHBs supported on this LSP, an uses the
relevant mapping entries for these PHBs from the Preconfigured - it is a function of the PHBs supported on this LSP, and uses the
PHB-->802.1 Mapping defined in section 3.4.4.1. relevant mapping entries for these PHBs from the Preconfigured
`PHB-->802.1 mapping' defined in section 3.4.4.1.
Notice that the `Set of PHB-->Encaps mappings' then contains both a Notice that the `Set of PHB-->Encaps mappings' then contains both a
`PHB-->EXP mapping' and a `PHB-->802.1 mapping'. `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
3.4.4.1 Preconfigured `PHB-->802.1 Mapping' 3.4.4.1 Preconfigured `PHB-->802.1 Mapping'
At the time of producing this specification, there are no At the time of producing this specification, there are no
standardized mapping from PHBs to 802.1 Traffic Classes. standardized mapping from PHBs to 802.1 Traffic Classes.
Consequently, an LSR supporting multiple 802.1 Traffic Classes over Consequently, an LSR supporting multiple 802.1 Traffic Classes over
LAN interfaces must allow local configuration of a `PHB-->802.1 LAN interfaces must allow local configuration of a `PHB-->802.1
Mapping'. This mapping applies to all the outgoing LSPs established mapping'. This mapping applies to all the outgoing LSPs established
by the LSR on such LAN interfaces. by the LSR on such LAN interfaces.
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing 3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP E-LSP
This section defines how to encode Diff-Serv information into the This section defines how to encode Diff-Serv information into the
MPLS encapsulation Layer for a given transmitted label entry MPLS encapsulation Layer for a given transmitted label entry
corresponding to an outgoing E-LSP. This requires that the `Set of corresponding to an outgoing E-LSP. This requires that the `Set of
PHB-->Encaps mappings' is populated as defined in section 3.4. PHB-->Encaps mappings' be populated as defined in section 3.4.
The LSR first determines the `Set of PHB-->Encaps mappings' of the The LSR first determines the `Set of PHB-->Encaps mappings' of the
Diff-Serv Context associated with the corresponding label in the Diff-Serv Context associated with the corresponding label in the
NHLFE. NHLFE.
3.5.1 `PHB-->EXP mapping' 3.5.1 `PHB-->EXP mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form If the `Set of PHB-->Encaps mappings' contains a mapping of the form
`PHB-->EXP mapping', then the LSR: `PHB-->EXP mapping', then the LSR:
- determines the value to be written in the EXP field of the
corresponding level label entry by looking up the "outgoing PHB"
in this PHB-->EXP mapping table.
Le Faucheur et. al 22 - determines the value to be written in the EXP field of the
corresponding level label entry by looking up the "outgoing PHB"
in this `PHB-->EXP mapping' table.
3.5.2 `PHB-->CLP mapping' 3.5.2 `PHB-->CLP mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form If the `Set of PHB-->Encaps mappings' contains a mapping of the form
`PHB-->CLP mapping', then the LSR: `PHB-->CLP mapping', then the LSR:
- determines the value to be written in the CLP field of the ATM
encapsulation header, by looking up the "outgoing PHB" in this - determines the value to be written in the CLP field of the ATM
PHB-->CLP mapping table. encapsulation header, by looking up the "outgoing PHB" in this
`PHB-->CLP mapping' table.
3.5.3 `PHB-->DE mapping' 3.5.3 `PHB-->DE mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form If the `Set of PHB-->Encaps mappings' contains a mapping of the form
`PHB-->DE mapping', then the LSR: `PHB-->DE mapping', then the LSR:
- determines the value to be written in the DE field of the Frame
Relay encapsulation header, by looking up the "outgoing PHB" in - determines the value to be written in the DE field of the Frame
this PHB-->DE mapping table. Relay encapsulation header, by looking up the "outgoing PHB" in
this `PHB-->DE mapping' table.
3.5.4 `PHB-->802.1 mapping' 3.5.4 `PHB-->802.1 mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form If the `Set of PHB-->Encaps mappings' contains a mapping of the form
`PHB-->802.1 mapping', then the LSR: `PHB-->802.1 mapping', then the LSR:
- determines the value to be written in the User_Priority field of
the Tag Control Information of the 802.1 encapsulation header - determines the value to be written in the User_Priority field of
[IEEE_802.1], by looking up the "outgoing PHB" in this the Tag Control Information of the 802.1 encapsulation header
PHB-->802.1 mapping table. [IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB--
>802.1 mapping' table.
3.6 E-LSP Merging 3.6 E-LSP Merging
In an MPLS domain, two or more LSPs can be merged into one LSP at In an MPLS domain, two or more LSPs can be merged into one LSP at one
one LSR. E-LSPs are compatible with LSP Merging under the following LSR. E-LSPs are compatible with LSP Merging under the following
condition: condition:
E-LSPs can only be merged into one LSP if they support the E-LSPs can only be merged into one LSP if they support the exact
exact same set of BAs. same set of BAs.
For E-LSPs using signaled EXP<-->PHB mapping, the above merge For E-LSPs using a signaled `EXP<-->PHB mapping', the above merge
condition MUST be enforced by LSRs through explicit checking at condition MUST be enforced by LSRs through explicit checking at label
label setup that the exact same set of PHBs is supported on the setup that the exact same set of PHBs is supported on the merged
merged LSPs. LSPs.
For E-LSPs using the preconfigured EXP<-->PHB mapping, since the For E-LSPs using the preconfigured `EXP<-->PHB mapping', since the
PHBs supported over an E-LSP is not signaled at establishment time, PHBs supported over an E-LSP is not signaled at establishment time,
an LSR can not rely on signaling information to enforce the above an LSR can not rely on signaling information to enforce the above
merge. However all E-LSPs using the preconfigured EXP<-->PHB mapping merge. However all E-LSPs using the preconfigured `EXP<-->PHB
are required to support the same set of Behavior Aggregates within a mapping' are required to support the same set of Behavior Aggregates
given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs using
preconfigured EXP<-->PHB mapping is allowed within a given MPLS the preconfigured `EXP<-->PHB mapping' is allowed within a given MPLS
Diff-Serv domain. Diff-Serv domain.
4. Detailed Operation of L-LSPs 4. Detailed Operation of L-LSPs
Le Faucheur et. al 23
4.1 L-LSP Definition 4.1 L-LSP Definition
L-LSPs are defined in section 1.3. L-LSPs are defined in section 1.3.
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP 4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv This section defines how the `Encaps-->PHB mapping' of the Diff-Serv
Context is populated at label setup for an incoming L-LSP in order Context is populated at label setup for an incoming L-LSP in order to
to allow Incoming PHB determination. allow Incoming PHB determination.
4.2.1 `EXP-->PHB mapping' 4.2.1 `EXP-->PHB mapping'
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP If the LSR terminates the MPLS Shim Layer over this incoming L-LSP
and the L-LSP ingresses on an interface which is not ATM nor Frame and the L-LSP ingresses on an interface which is not ATM nor Frame
Relay, then the `Encaps-->PHB mapping' is populated in the following Relay, then the `Encaps-->PHB mapping' is populated in the following
way: way:
- it is actually a `EXP-->PHB mapping'
- this mapping is a function of the PSC which is carried on this - it is actually a `EXP-->PHB mapping'
LSP, and must use the relevant mapping entries for this PSC from
the Mandatory EXP/PSC-->PHB Mapping defined in Section 4.2.1.1. - this mapping is a function of the PSC which is carried on this
LSP, and must use the relevant mapping entries for this PSC from
the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
For example if the incoming label corresponds to an L-LSP supporting For example if the incoming label corresponds to an L-LSP supporting
the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with: the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
EXP Field PHB EXP Field PHB
001 ----> AF11 001 ----> AF11
010 ----> AF12 010 ----> AF12
011 ----> AF13 011 ----> AF13
An LSR supporting L-LSPs over PPP interfaces and LAN interfaces is An LSR, supporting L-LSPs over PPP interfaces and LAN interfaces, is
an example of LSR terminating the Shim layer over ingress interfaces an example of an LSR terminating the Shim layer over ingress
which are not ATM nor Frame Relay. interfaces which are not ATM nor Frame Relay.
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP If the LSR terminates the MPLS Shim Layer over this incoming L-LSP
and the L-LSP ingresses on an ATM or Frame Relay interface, then the and the L-LSP ingresses on an ATM or Frame Relay interface, then the
`Encaps-->PHB mapping' is populated in the following way: `Encaps-->PHB mapping' is populated in the following way:
- it should actually be a `EXP-->PHB mapping'. Alternative
optional ways of populating the `Encaps-->PHB mapping' might be - it should actually be a `EXP-->PHB mapping'. Alternative optional
defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or ways of populating the `Encaps-->PHB mapping' might be defined in
a 'DE/EXP-->PHB mapping') but are outside the scope of this the future (e.g., using a 'CLP/EXP--> PHB mapping' or a
document. 'DE/EXP-->PHB mapping') but are outside the scope of this
- when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this document.
`EXP-->PHB mapping' mapping is a function of the PSC which is
carried on the L-LSP, and must use the relevant mapping entries - when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this
for this PSC from the Mandatory EXP/PSC-->PHB Mapping defined in `EXP-->PHB mapping' mapping is a function of the PSC which is
Section 4.2.1.1. carried on the L-LSP, and must use the relevant mapping entries
for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in
Section 4.2.1.1.
An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an
example of LSR terminating the shim layer over an ingress ATM/FR example of an LSR terminating the shim layer over an ingress ATM/FR
interface. interface.
Le Faucheur et. al 24 4.2.1.1 Mandatory `EXP/PSC --> PHB mapping'
4.2.1.1 Mandatory EXP/PSC --> PHB mapping
EXP Field PSC PHB EXP Field PSC PHB
000 DF ----> DF 000 DF ----> DF
000 CSn ----> CSn 000 CSn ----> CSn
001 AFn ----> AFn1 001 AFn ----> AFn1
010 AFn ----> AFn2 010 AFn ----> AFn2
011 AFn ----> AFn3 011 AFn ----> AFn3
000 EF ----> EF 000 EF ----> EF
4.2.2 `CLP-->PHB mapping' 4.2.2 `CLP-->PHB mapping'
If the LSR does not terminate an MPLS Shim Layer over this incoming If the LSR does not terminate an MPLS Shim Layer over this incoming
label and uses ATM encapsulation (i.e. it is an ATM-LSR), then the label and uses ATM encapsulation (i.e., it is an ATM-LSR), then the
`Encaps-->PHB mapping' for this incoming L-LSP is populated in the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the
following way: following way:
- it is actually a `CLP-->PHB mapping'
- the mapping is a function of the PSC which is carried on this - it is actually a `CLP-->PHB mapping'
LSP, and should use the relevant mapping entries for this PSC
from the Default CLP/PSC-->PHB Mapping defined in Section - the mapping is a function of the PSC, which is carried on this
4.2.2.1. LSP, and should use the relevant mapping entries for this PSC from
the Default `CLP/PSC-->PHB mapping' defined in Section 4.2.2.1.
For example if the incoming label corresponds to an L-LSP supporting For example if the incoming label corresponds to an L-LSP supporting
the AF1 PSC, then the `Encaps-->PHB mapping' should be populated the AF1 PSC, then the `Encaps-->PHB mapping' should be populated
with: with:
CLP Field PHB CLP Field PHB
0 ----> AF11 0 ----> AF11
1 ----> AF12 1 ----> AF12
4.2.2.1 Default CLP/PSC --> PHB Mapping 4.2.2.1 Default `CLP/PSC --> PHB mapping'
CLP Bit PSC PHB CLP Bit PSC PHB
0 DF ----> DF 0 DF ----> DF
0 CSn ----> CSn 0 CSn ----> CSn
0 AFn ----> AFn1 0 AFn ----> AFn1
1 AFn ----> AFn2 1 AFn ----> AFn2
0 EF ----> EF 0 EF ----> EF
4.2.3 `DE-->PHB mapping' 4.2.3 `DE-->PHB mapping'
If the LSR does not terminate an MPLS Shim Layer over this incoming If the LSR does not terminate an MPLS Shim Layer over this incoming
label and uses Frame Relay encapsulation (i.e. it is a FR-LSR), then label and uses Frame Relay encapsulation (i.e., it is a FR-LSR), then
the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the `Encaps-->PHB mapping' for this incoming L-LSP is populated in
the following way: the following way:
- it is actually a `DE-->PHB mapping'
- the mapping is a function of the PSC which is carried on this
LSP, and should use the relevant mapping entries for this PSC
Le Faucheur et. al 25 - it is actually a `DE-->PHB mapping'
from the Default DE/PSC-->PHB Mapping defined in Section
4.2.3.1.
4.2.3.1 Default DE/PSC --> PHB Mapping - the mapping is a function of the PSC which is carried on this LSP,
and should use the relevant mapping entries for this PSC from the
Default `DE/PSC-->PHB mapping' defined in Section 4.2.3.1.
4.2.3.1 Default `DE/PSC --> PHB mapping'
DE Bit PSC PHB DE Bit PSC PHB
0 DF ----> DF 0 DF ----> DF
0 CSn ----> CSn 0 CSn ----> CSn
0 AFn ----> AFn1 0 AFn ----> AFn1
1 AFn ----> AFn2 1 AFn ----> AFn2
0 EF ----> EF 0 EF ----> EF
4.3 Incoming PHB Determination On Incoming L-LSP 4.3 Incoming PHB Determination On Incoming L-LSP
This section defines how Incoming PHB determination is carried out This section defines how Incoming PHB determination is carried out
when the considered label entry in the received label stack when the considered label entry in the received label stack
corresponds to an L-LSP. This requires that the `Encaps-->PHB corresponds to an L-LSP. This requires that the `Encaps-->PHB
mapping' is populated as defined in section 4.2. mapping' is populated as defined in section 4.2.
When considering a label entry corresponding to an incoming L-LSP When considering a label entry corresponding to an incoming L-LSP
for Incoming PHB Determination, the LSR first determines the for Incoming PHB Determination, the LSR first determines the
`Encaps-->PHB mapping' associated with -corresponding label. `Encaps-->PHB mapping' associated with the corresponding label.
4.3.1 `EXP-->PHB mapping' 4.3.1 `EXP-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping',
then the LSR: then the LSR:
- determines the incoming PHB by looking at the EXP field of the
considered label entry and by using the EXP-->PHB mapping. - determines the incoming PHB by looking at the EXP field of the
considered label entry and using the `EXP-->PHB mapping'.
4.3.2 `CLP-->PHB mapping' 4.3.2 `CLP-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping',
then the LSR: then the LSR:
- determines the incoming PHB by looking at the CLP field of the
ATM Layer encapsulation and by using the CLP-->PHB mapping. - determines the incoming PHB by looking at the CLP field of the
ATM Layer encapsulation and using the `CLP-->PHB mapping'.
4.3.3 `DE-->PHB mapping' 4.3.3 `DE-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping',
then the LSR: then the LSR:
- determines the incoming PHB by looking at the DE field of the
Frame Relay encapsulation and by using the DE-->PHB mapping. - determines the incoming PHB by looking at the DE field of the
Frame Relay encapsulation and by using the `DE-->PHB mapping'.
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP 4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP
This section defines how the `Set of PHB-->Encaps mappings' of the This section defines how the `Set of PHB-->Encaps mappings' of the
Diff-Serv Context is populated at label setup for an outgoing L-LSP Diff-Serv Context is populated at label setup for an outgoing L-LSP
in order to allow Encoding of Diff-Serv Information. in order to allow Encoding of Diff-Serv Information.
4.4.1 `PHB-->EXP mapping' 4.4.1 `PHB-->EXP mapping'
Le Faucheur et. al 26
If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then
one `PHB-->EXP mapping' is added to the `Set of one `PHB-->EXP mapping' is added to the `Set of
PHB-->Encaps mappings' for this outgoing PHB-->Encaps mappings' for this outgoing
L-LSP. This `PHB-->EXP mapping' is populated in the following way: L-LSP. This `PHB-->EXP mapping' is populated in the following way:
- it is a function of the PSC supported on this LSP, and must use
the mapping entries relevant for this PSC from the Mandatory
PHB-->EXP Mapping defined in section 4.4.1.1.
For example if the outgoing label corresponds to an L-LSP supporting - it is a function of the PSC supported on this LSP, and must use
the mapping entries relevant for this PSC from the Mandatory
`PHB-->EXP mapping' defined in section 4.4.1.1.
For example, if the outgoing label corresponds to an L-LSP supporting
the AF1 PSC, then the following `PHB-->EXP mapping' is added into the AF1 PSC, then the following `PHB-->EXP mapping' is added into
the `Set of PHB-->Encaps mappings': the `Set of PHB-->Encaps mappings':
PHB EXP Field PHB EXP Field
AF11 ----> 001 AF11 ----> 001
AF12 ----> 010 AF12 ----> 010
AF13 ----> 011 AF13 ----> 011
4.4.1.1 Mandatory PHB-->EXP Mapping 4.4.1.1 Mandatory `PHB-->EXP mapping'
PHB EXP Field PHB EXP Field
DF ----> 000 DF ----> 000
CSn ----> 000 CSn ----> 000
AFn1 ----> 001 AFn1 ----> 001
AFn2 ----> 010 AFn2 ----> 010
AFn3 ----> 011 AFn3 ----> 011
EF ----> 000 EF ----> 000
4.4.2 `PHB-->CLP mapping' 4.4.2 `PHB-->CLP mapping'
If the L-LSP is egressing on an ATM interface (i.e. it is an ATM-LSR If the L-LSP is egressing on an ATM interface (i.e., it is an ATM-LSR
or it is a frame-based LSR sending packets on an LC-ATM interface or or it is a frame-based LSR sending packets on an LC-ATM interface or
on an ATM interface which is not label switching controlled), then on an ATM interface which is not label switching controlled), then
one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps
mappings' for this outgoing L-LSP. mappings' for this outgoing L-LSP.
If the L-LSP is egressing over an ATM interface which is not label- If the L-LSP is egressing over an ATM interface which is not label-
controlled, the `PHB-->CLP mapping' is populated as per section controlled, the `PHB-->CLP mapping' is populated as per section
3.4.2. 3.4.2.
If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP
mapping' is populated in the following way: mapping' is populated in the following way:
- it is a function of the PSC supported on this LSP, and should
use the relevant mapping entries for this PSC from the Default - it is a function of the PSC supported on this LSP, and should use
PHB-->CLP Mapping defined in section 3.4.2.1. the relevant mapping entries for this PSC from the Default
`PHB-->CLP mapping' defined in section 3.4.2.1.
Notice that if the LSR is a frame-based LSR supporting an L-LSP Notice that if the LSR is a frame-based LSR supporting an L-LSP
egressing over an ATM interface, then the `Set of PHB-->Encaps egressing over an ATM interface, then the `Set of PHB-->Encaps
mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP
mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the
Le Faucheur et. al 27
mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the
`Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'. `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.
4.4.3 `PHB-->DE mapping' 4.4.3 `PHB-->DE mapping'
If the L-LSP is egressing over a Frame Relay interface (i.e. it is If the L-LSP is egressing over a Frame Relay interface (i.e., it is
an LSR sending packets on an LC-FR interface or on a Frame Relay an LSR sending packets on an LC-FR interface or on a Frame Relay
interface which is not label switching controlled), one `PHB-->DE interface which is not label switching controlled), one `PHB-->DE
mapping' is added to the `Set of PHB-->Encaps mappings' for this mapping' is added to the `Set of PHB-->Encaps mappings' for this
outgoing L-LSP. outgoing L-LSP.
If the L-LSP is egressing over a FR interface which is not label If the L-LSP is egressing over a FR interface which is not label
switching controlled, the `PHB-->DE mapping' is populated as per switching controlled, the `PHB-->DE mapping' is populated as per
section 3.4.3. section 3.4.3.
If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE
mapping' is populated in the following way: mapping' is populated in the following way:
- it is a function of the PSC supported on this LSP, and should
use the relevant mapping entries for this PSC from the Default - it is a function of the PSC supported on this LSP, and should use
PHB-->DE Mapping defined in section 3.4.3.1. the relevant mapping entries for this PSC from the Default
`PHB-->DE mapping' defined in section 3.4.3.1.
Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing
over a LC-FR interface, then the `Set of PHB-->Encaps mappings' over a LC-FR interface, then the `Set of PHB-->Encaps mappings'
contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the
LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps
mappings' only contains a `PHB-->DE mapping'. mappings' only contains a `PHB-->DE mapping'.
4.4.4 `PHB-->802.1 mapping' 4.4.4 `PHB-->802.1 mapping'
If the LSP is egressing over a LAN interface on which multiple 802.1 If the LSP is egressing over a LAN interface on which multiple 802.1
Traffic Classes are supported as defined in [IEEE_802.1], then one Traffic Classes are supported, as defined in [IEEE_802.1], then one
`PHB-->802.1 mapping' is added as per section 3.4.4. `PHB-->802.1 mapping' is added as per section 3.4.4.
4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing 4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing
L-LSP L-LSP
This section defines how to encode Diff-Serv information into the This section defines how to encode Diff-Serv information into the
MPLS encapsulation Layer for a transmitted label entry corresponding MPLS encapsulation Layer for a transmitted label entry corresponding
to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps
mappings' is populated as defined in section 4.4. mappings' is populated as defined in section 4.4.
The LSR first determines the `Set of PHB-->Encaps mappings' of the The LSR first determines the `Set of PHB-->Encaps mappings' of the
Diff-Serv Context associated with the corresponding label in the Diff-Serv Context associated with the corresponding label in the
NHLFE and then performs corresponding encoding as specified in NHLFE and then performs corresponding encoding as specified in
sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4. sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4.
4.6 L-LSP Merging 4.6 L-LSP Merging
In an MPLS domain, two or more LSPs can be merged into one LSP at In an MPLS domain, two or more LSPs can be merged into one LSP at one
one LSR. L-LSPs are compatible with LSP Merging under the following LSR. L-LSPs are compatible with LSP Merging under the following
condition: condition:
Le Faucheur et. al 28 L-LSPs can only be merged into one L-LSP if they support the same
L-LSPs can only be merged into one L-LSP if they support the PSC.
same PSC.
The above merge condition MUST be enforced by LSRs through explicit The above merge condition MUST be enforced by LSRs, through explicit
checking at label setup that the same PSC is supported on the merged checking at label setup, that the same PSC is supported on the merged
LSPs. LSPs.
Note that when L-LSPs merge, the bandwidth that is available for the Note that when L-LSPs merge, the bandwidth that is available for the
PSC downstream of the merge point must be sufficient to carry the PSC downstream of the merge point must be sufficient to carry the sum
sum of the merged traffic. This is particularly important in the of the merged traffic. This is particularly important in the case of
case of EF traffic. This can be ensured in multiple ways (for EF traffic. This can be ensured in multiple ways (for instance via
instance via provisioning, or via bandwidth signaling and explicit provisioning, or via bandwidth signaling and explicit admission
admission control). control).
5. RSVP Extension for Diff-Serv Support 5. RSVP Extension for Diff-Serv Support
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. [RSVP_MPLS_TE] defines the extension to RSVP for protocol. [RSVP_MPLS_TE] defines the extension to RSVP for
establishing label switched paths (LSPs) in MPLS networks. This establishing LSPs in MPLS networks. This section specifies the
section specifies the extensions to RSVP, beyond those defined in extensions to RSVP, beyond those defined in [RSVP_MPLS_TE], to
[RSVP_MPLS_TE], to establish label switched path (LSPs) supporting establish LSPs supporting Differentiated Services in MPLS networks.
Differentiated Services in MPLS networks.
5.1 Diff-Serv related RSVP Messages Format 5.1 Diff-Serv related RSVP Messages Format
One new RSVP Object is defined in this document: the DIFFSERV One new RSVP Object is defined in this document: the DIFFSERV Object.
Object. Detailed description of this Object is provided below. This Detailed description of this Object is provided below. This new
new Object is applicable to Path messages. This specification only Object is applicable to Path messages. This specification only
defines the use of the DIFFSERV Object in Path messages used to defines the use of the DIFFSERV Object in Path messages used to
establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus
containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
and containing a LABEL_REQUEST object. and containing a LABEL_REQUEST object.
Restrictions defined in [RSVP_MPLS_TE] for support of establishment Restrictions defined in [RSVP_MPLS_TE] for support of the
of LSP Tunnels via RSVP are also applicable to the establishment of establishment of LSP Tunnels via RSVP are also applicable to the
LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs establishment of LSP Tunnels supporting Diff-Serv: for instance, only
are supported and Multicast LSPs are for further study. unicast LSPs are supported and Multicast LSPs are for further study.
This new DIFFSERV object is optional with respect to RSVP so that This new DIFFSERV object is optional with respect to RSVP so that
general RSVP implementations not concerned with MPLS LSP set up do general RSVP implementations not concerned with MPLS LSP set up do
not have to support this object. not have to support this object.
The DIFFSERV Object is optional for support of LSP Tunnels as The DIFFSERV Object is optional for support of LSP Tunnels as defined
defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs using
using the preconfigured EXP<-->PHB mapping in compliance with this the preconfigured `EXP<-->PHB mapping' in compliance with this
specification MAY support the DIFFSERV Object. A Diff-Serv capable specification MAY support the DIFFSERV Object. A Diff-Serv capable
LSR supporting E-LSPs using a signaled EXP<-->PHB mapping in LSR supporting E-LSPs using a signaled `EXP<-->PHB mapping' in
compliance with this specification MUST support the DIFFSERV Object. compliance with this specification MUST support the DIFFSERV Object.
A Diff-Serv capable LSR supporting L-LSPs in compliance with this A Diff-Serv capable LSR supporting L-LSPs in compliance with this
specification MUST support the DIFFSERV Object. specification MUST support the DIFFSERV Object.
Le Faucheur et. al 29
5.1.1 Path Message Format 5.1.1 Path Message Format
The format of the Path message is as follows: The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ] [ <DIFFSERV> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
[ <sender descriptor> ] [ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
5.2 DIFFSERV Object 5.2 DIFFSERV Object
The DIFFSERV object formats are shown below. Currently there are two The DIFFSERV object formats are shown below. Currently there are two
possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2
is a DIFFSERV object for an L-LSP. is a DIFFSERV object for an L-LSP.
5.2.1. DIFFSERV object for an E-LSP: 5.2.1. DIFFSERV object for an E-LSP:
class = TBD, C_Type = 1 (need to get an official class num from the class = 65, C_Type = 1
IANA with the form 0bbbbbbb)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits 0 1 2 3
This field is reserved. It must be set to zero on transmission 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
and must be ignored on receipt. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAPnb : 4 bits Reserved : 28 bits
Indicates the number of MAP entries included in the DIFFSERV This field is reserved. It must be set to zero on transmission
Object. This can be set to any value from 0 to 8. and must be ignored on receipt.
MAP : 32 bits MAPnb : 4 bits
Indicates the number of MAP entries included in the DIFFSERV
Object. This can be set to any value from 0 to 8.
Le Faucheur et. al 30 MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format: and one PHB. The MAP entry has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID | | Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits Reserved : 13 bits
This field is reserved. It must be set to zero on This field is reserved. It must be set to zero on transmission
transmission and must be ignored on receipt. and must be ignored on receipt.
EXP : 3 bits EXP : 3 bits
This field contains the value of the EXP field for the This field contains the value of the EXP field for the
EXP<-->PHB mapping defined in this MAP entry. `EXP<-->PHB mapping' defined in this MAP entry.
PHBID : 16 bits PHBID : 16 bits
This field contains the PHBID of the PHB for the This field contains the PHBID of the PHB for the `EXP<-->PHB
EXP<-->PHB mapping defined in this MAP entry. The PHBID mapping' defined in this MAP entry. The PHBID is encoded as
is encoded as specified in [PHBID]. specified in [PHBID].
5.2.2 DIFFSERV object for an L-LSP: 5.2.2 DIFFSERV object for an L-LSP:
class = TBD, C_Type = 2 (class num is the same as DIFFSERV object class = 65, C_Type = 2
for E-LSP))
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PSC | | Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 16 bits Reserved : 16 bits
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and must be ignored on receipt. and must be ignored on receipt.
PSC : 16 bits PSC : 16 bits
The PSC indicates a PHB Scheduling Class to be supported by the The PSC indicates a PHB Scheduling Class to be supported by the
LSP. The PSC is encoded as specified in [PHBID]. LSP. The PSC is encoded as specified in [PHBID].
5.3 Handling DIFFSERV Object 5.3 Handling DIFFSERV Object
To establish an LSP tunnel with RSVP, the sender creates a Path To establish an LSP tunnel with RSVP, the sender creates a Path
message with a session type of LSP_Tunnel_IPv4 and with a message with a session type of LSP_Tunnel_IPv4 and with a
LABEL_REQUEST object as per [RSVP_MPLS_TE]. LABEL_REQUEST object as per [RSVP_MPLS_TE].
To establish with RSVP an E-LSP tunnel which uses the Preconfigured To establish an E-LSP tunnel with RSVP, which uses the Preconfigured
EXP<-->PHB mapping, the sender creates a Path message: `EXP<-->PHB mapping', the sender creates a Path message:
- with a session type of LSP_Tunnel_IPv4,
- with the LABEL_REQUEST object, and
- without the DIFFSERV object.
Le Faucheur et. al 31 - with a session type of LSP_Tunnel_IPv4,
To establish with RSVP an E-LSP tunnel which uses the Preconfigured
EXP<-->PHB mapping, the sender MAY alternatively create a Path - with the LABEL_REQUEST object, and
- without the DIFFSERV object.
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured
`EXP<-->PHB mapping', the sender MAY alternatively create a Path
message: message:
- with a session type of LSP_Tunnel_IPv4,
- with the LABEL_REQUEST object, and
- with the DIFFSERV object for an E-LSP containing no MAP entries.
To establish with RSVP an E-LSP tunnel which uses a signaled - with a session type of LSP_Tunnel_IPv4,
EXP<-->PHB mapping, the sender creates a Path message :
- with a session type of LSP_Tunnel_IPv4, - with the LABEL_REQUEST object, and
- with the LABEL_REQUEST object,
- with the DIFFSERV object for an E-LSP containing one MAP entry - with the DIFFSERV object for an E-LSP containing no MAP entries.
for each EXP value to be supported on this E-LSP.
To establish an E-LSP tunnel with RSVP, which uses a signaled
`EXP<-->PHB mapping', the sender creates a Path message:
- with a session type of LSP_Tunnel_IPv4,
- with the LABEL_REQUEST object,
- with the DIFFSERV object for an E-LSP containing one MAP entry for
each EXP value to be supported on this E-LSP.
To establish with RSVP an L-LSP tunnel, the sender creates a Path To establish with RSVP an L-LSP tunnel, the sender creates a Path
message: message:
- with a session type of LSP_Tunnel_IPv4,
- with the LABEL_REQUEST object, - with a session type of LSP_Tunnel_IPv4,
- with the DIFFSERV object for an L-LSP containing the PHB
Scheduling Class (PSC) supported on this L-LSP. - with the LABEL_REQUEST object,
- with the DIFFSERV object for an L-LSP containing the PHB
Scheduling Class (PSC) supported on this L-LSP.
If a path message contains multiple DIFFSERV objects, only the first If a path message contains multiple DIFFSERV objects, only the first
one is meaningful; subsequent DIFFSERV object(s) must be ignored and one is meaningful; subsequent DIFFSERV object(s) must be ignored and
not forwarded. not forwarded.
Each LSR along the path records the DIFFSERV object, when present, Each LSR along the path records the DIFFSERV object, when present, in
in its path state block. its path state block.
If a DIFFSERV object is not present in the Path message, the LSR If a DIFFSERV object is not present in the Path message, the LSR
SHOULD interpret this as a request for an E-LSP using the SHOULD interpret this as a request for an E-LSP using the
Preconfigured EXP<-->PHB Mapping. However, for backward Preconfigured `EXP<-->PHB mapping'. However, for backward
compatibility purposes with other non-Diff-Serv Quality of Service compatibility purposes, with other non-Diff-Serv Quality of Service
options allowed by [RSVP_MPLS_TE] such as Integrated Services options allowed by [RSVP_MPLS_TE] such as Integrated Services
Controlled Load or Guaranteed Services, the LSR MAY support a Controlled Load or Guaranteed Services, the LSR MAY support a
configurable "override option". When this "override option" is configurable "override option". When this "override option" is
configured, the LSR interprets a path message without a Diff-Serv configured, the LSR interprets a path message without a Diff-Serv
object as a request for an LSP with such non-Diff-Serv Quality of object as a request for an LSP with such non-Diff-Serv Quality of
Service. Service.
If a DIFFSERV object for an E-LSP containing no MAP entry is present If a DIFFSERV object for an E-LSP containing no MAP entry is present
in the Path message, the LSR MUST interpret this as a request for an in the Path message, the LSR MUST interpret this as a request for an
E-LSP using the Preconfigured EXP<-->PHB Mapping. In particular, E-LSP using the Preconfigured `EXP<-->PHB mapping'. In particular,
this allows an LSR with the "override option" configured to support this allows an LSR with the "override option" configured to support
E-LSPs with Preconfigured EXP<-->PHB Mapping simultaneously with E-LSPs with Preconfigured `EXP<-->PHB mapping', simultaneously with
LSPs with non-Diff-Serv Quality of Service. LSPs with non-Diff-Serv Quality of Service.
If a DIFFSERV object for an E-LSP containing at least one MAP entry If a DIFFSERV object for an E-LSP containing at least one MAP entry
is present in the Path message, the LSR MUST interpret this as a is present in the Path message, the LSR MUST interpret this as a
request for an E-LSP with signaled EXP<-->PHB Mapping. request for an E-LSP with signaled `EXP<-->PHB mapping'.
Le Faucheur et. al 32 If a DIFFSERV object for an L-LSP is present in the Path message, the
If a DIFFSERV object for an L-LSP is present in the Path message, LSR MUST interpret this as a request for an L-LSP.
the LSR MUST interpret this as a request for an L-LSP.
The destination LSR of an E-LSP or L-LSP responds to the Path The destination LSR of an E-LSP or L-LSP responds to the Path message
message containing the LABEL_REQUEST object by sending a Resv containing the LABEL_REQUEST object by sending a Resv message:
message:
- with the LABEL object - with the LABEL object
- without a DIFFSERV object.
- without a DIFFSERV object.
Assuming the label request is accepted and a label is allocated, the Assuming the label request is accepted and a label is allocated, the
Diff-Serv LSRs (sender, destination, intermediate nodes) must: Diff-Serv LSRs (sender, destination, intermediate nodes) must:
- update the Diff-Serv Context associated with the established
LSPs in their ILM/FTN as specified in previous sections - update the Diff-Serv Context associated with the established LSPs
(incoming and outgoing label), in their ILM/FTN as specified in previous sections (incoming and
- install the required Diff-Serv forwarding treatment (scheduling outgoing label),
and dropping behavior) for this NHLFE (outgoing label).
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
An LSR that recognizes the DIFFSERV object and that receives a path An LSR that recognizes the DIFFSERV object and that receives a path
message which contains the DIFFSERV object but which does not message which contains the DIFFSERV object but which does not contain
contain a LABEL_REQUEST object or which does not have a session type a LABEL_REQUEST object or which does not have a session type of
of LSP_Tunnel_IPv4, sends a PathErr towards the sender with the LSP_Tunnel_IPv4, sends a PathErr towards the sender with the error
error code `Diff-Serv Error' and an error value of `Unexpected code `Diff-Serv Error' and an error value of `Unexpected DIFFSERV
DIFFSERV object'. Those are defined below in section 5.5. object'. Those are defined below in section 5.5.
An LSR receiving a Path message with the DIFFSERV object for E-LSP, An LSR receiving a Path message with the DIFFSERV object for E-LSP,
which recognizes the DIFFSERV object but does not support the which recognizes the DIFFSERV object but does not support the
particular PHB encoded in one, or more, of the MAP entries, sends a particular PHB encoded in one, or more, of the MAP entries, sends a
PathErr towards the sender with the error code `Diff-Serv Error' and PathErr towards the sender with the error code `Diff-Serv Error' and
an error value of `Unsupported PHB'. Those are defined below in an error value of `Unsupported PHB'. Those are defined below in
section 5.5. section 5.5.
An LSR receiving a Path message with the DIFFSERV object for E-LSP, An LSR receiving a Path message with the DIFFSERV object for E-LSP,
which recognizes the DIFFSERV object but determines that the which recognizes the DIFFSERV object but determines that the signaled
signaled EXP<-->PHB mapping is invalid, sends a PathErr towards the `EXP<-->PHB mapping' is invalid, sends a PathErr towards the sender
sender with the error code `Diff-Serv Error' and an error value of with the error code `Diff-Serv Error' and an error value of Invalid
`Invalid EXP<-->PHB mapping'. Those are defined below in section `EXP<-->PHB mapping'. Those are defined below in section 5.5. `The
5.5. The EXP<-->PHB mapping signaled in the DIFFSERV Object for an EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is
E-LSP is invalid when: invalid when:
- the MAPnb field is not within the range 0 to 8 or
- a given EXP value appears in more than one MAP entry, or - the MAPnb field is not within the range 0 to 8 or
- the PHBID encoding is invalid.
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid.
An LSR receiving a Path message with the DIFFSERV object for L-LSP, An LSR receiving a Path message with the DIFFSERV object for L-LSP,
which recognizes the DIFFSERV object but does not support the which recognizes the DIFFSERV object but does not support the
particular PSC encoded in the PSC field, sends a PathErr towards the particular PSC encoded in the PSC field, sends a PathErr towards the
sender with the error code `Diff-Serv Error' and an error value of sender with the error code `Diff-Serv Error' and an error value of
`Unsupported PSC'. Those are defined below in section 5.5. `Unsupported PSC'. Those are defined below in section 5.5.
An LSR receiving a Path message with the DIFFSERV object, which An LSR receiving a Path message with the DIFFSERV object, which
recognizes the DIFFSERV object but that is unable to allocate the recognizes the DIFFSERV object but that is unable to allocate the
required per-LSP Diff-Serv context sends a PathErr with the error required per-LSP Diff-Serv context sends a PathErr with the error
Le Faucheur et. al 33
code "Diff-Serv Error" and the error value "Per-LSP context code "Diff-Serv Error" and the error value "Per-LSP context
allocation failure". Those are defined below in section 5.5. allocation failure". Those are defined below in section 5.5.
A Diff-Serv LSR MUST handle the situations where the label request A Diff-Serv LSR MUST handle the situations where the label request
can not be accepted for other reasons than those already discussed can not be accepted for reasons other than those already discussed in
in this section, in accordance with [RSVP_MPLS_TE] (e.g. reservation this section, in accordance with [RSVP_MPLS_TE] (e.g., reservation
rejected by admission control, a label can not be associated). rejected by admission control, a label can not be associated).
5.4 Non-support of the DIFFSERV Object 5.4 Non-support of the DIFFSERV Object
An LSR that does not recognize the DIFFSERV object Class-Num must An LSR that does not recognize the DIFFSERV object Class-Num MUST
behave in accordance with the procedures specified in [RSVP] for an behave in accordance with the procedures specified in [RSVP] for an
unknown Class-Num whose format is 0bbbbbbb i.e. it must send a unknown Class-Num whose format is 0bbbbbbb i.e., it must send a
PathErr with the error code `Unknown object class' toward the PathErr with the error code `Unknown object class' toward the sender.
sender.
An LSR that recognize the DIFFSERV object Class-Num but does not An LSR that recognize the DIFFSERV object Class-Num but does not
recognize the DIFFSERV object C-Type, must behave in accordance with recognize the DIFFSERV object C-Type, must behave in accordance with
the procedures specified in [RSVP] for an unknown C-type i.e. It the procedures specified in [RSVP] for an unknown C-type i.e., it
must send a PathErr with the error code `Unknown object C-Type' must send a PathErr with the error code `Unknown object C-Type'
toward the sender. toward the sender.
In both situations, this causes the path set-up to fail. The sender In both situations, this causes the path set-up to fail. The sender
should notify management that a L-LSP cannot be established and should notify management that a L-LSP cannot be established and
possibly take action to retry LSP establishment without the DIFFSERV should possibly take action to retry LSP establishment without the
object (e.g. attempt to use E-LSPs with Preconfigured EXP<-->PHB DIFFSERV object (e.g., attempt to use E-LSPs with Preconfigured
mapping as a fall-back strategy). `EXP<-->PHB mapping' as a fall-back strategy).
5.5 Error Codes For Diff-Serv 5.5 Error Codes For Diff-Serv
In the procedures described above, certain errors must be reported In the procedures described above, certain errors must be reported as
as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error a `Diff-Serv Error'. The value of the `Diff-Serv Error' error code
code is TBD (number to be allocated by IANA)). is 27.
The following defines error values for the Diff-Serv Error: The following defines error values for the Diff-Serv Error:
Value Error Value Error
1 Unexpected DIFFSERV object 1 Unexpected DIFFSERV object
2 Unsupported PHB 2 Unsupported PHB
3 Invalid EXP<-->PHB mapping 3 Invalid `EXP<-->PHB mapping'
4 Unsupported PSC 4 Unsupported PSC
5 Per-LSP context allocation failure 5 Per-LSP context allocation failure
5.6 Intserv Service Type 5.6 Intserv Service Type
Both E-LSPs and L-LSPs can be established with bandwidth reservation Both E-LSPs and L-LSPs can be established with or without bandwidth
or without bandwidth reservation. reservation.
As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP
with bandwidth reservation, Int-Serv's Controlled Load service (or with bandwidth reservation, Int-Serv's Controlled Load service (or
possibly Guaranteed Service) is used and the bandwidth is signaled possibly Guaranteed Service) is used and the bandwidth is signaled in
the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively
Le Faucheur et. al 34 Resv) message.
in the SENDER_TSPEC (respectively FLOWSPEC) of the path
(respectively Resv) message.
As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP
without bandwidth reservation, the Null Service specified in [NULL] without bandwidth reservation, the Null Service specified in [NULL]
is used. is used.
Note that this specification defines usage of E-LSPs and L-LSPs Note that this specification defines usage of E-LSPs and L-LSPs for
for support of the Diff-Serv service only. Regardless of the Intserv support of the Diff-Serv service only. Regardless of the Intserv
service (Controlled Load, Null Service, Guaranteed Service,...) and service (Controlled Load, Null Service, Guaranteed Service,...) and
regardless of whether the reservation is with or without bandwidth regardless of whether the reservation is with or without bandwidth
reservation, E-LSPs and L-LSPs are defined here for support of Diff- reservation, E-LSPs and L-LSPs are defined here for support of Diff-
Serv services. Support of Int-Serv services over an MPLS Diff-Serv Serv services. Support of Int-Serv services over an MPLS Diff-Serv
backbone is outside the scope of this specification. backbone is outside the scope of this specification.
Note also that this specification does not concern itself with the Note also that this specification does not concern itself with the
DCLASS object defined in [DCLASS], since this object conveys DCLASS object defined in [DCLASS], since this object conveys
information on DSCP values, which are not relevant inside the MPLS information on DSCP values, which are not relevant inside the MPLS
network. network.
6. LDP Extensions for Diff-Serv Support 6. LDP Extensions for Diff-Serv Support
The MPLS architecture does not assume a single label distribution The MPLS architecture does not assume a single label distribution
protocol. [LDP] defines the Label Distribution Protocol and its protocol. [LDP] defines the Label Distribution Protocol and its
usage for establishment of label switched paths (LSPs) in MPLS usage for establishment of label switched paths (LSPs) in MPLS
networks. This section specifies the extensions to LDP to establish networks. This section specifies the extensions to LDP to establish
label switched path (LSPs) supporting Differentiated Services in LSPs supporting Differentiated Services in MPLS networks.
MPLS networks.
One new LDP TLV is defined in this document: One new LDP TLV is defined in this document:
- the Diff-Serv TLV
- the Diff-Serv TLV
Detailed description of this TLV is provided below. Detailed description of this TLV is provided below.
The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv
capable LSR supporting E-LSPs which uses the Preconfigured capable LSR supporting E-LSPs which uses the Preconfigured `EXP<--
EXP<-->PHB mapping in compliance with this specification MAY support >PHB mapping' in compliance with this specification MAY support the
the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which uses
uses the signaled EXP<-->PHB mapping in compliance with this the signaled `EXP<-->PHB mapping' in compliance with this
specification MUST support the Diff-Serv TLV. A Diff-Serv capable specification MUST support the Diff-Serv TLV. A Diff-Serv capable
LSR supporting L-LSPs in compliance with this specification MUST LSR supporting L-LSPs in compliance with this specification MUST
support the Diff-Serv TLV. support the Diff-Serv TLV.
6.1 Diff-Serv TLV 6.1 Diff-Serv TLV
The Diff-Serv TLV has the following formats: The Diff-Serv TLV has the following formats:
Diff-Serv TLV for an E-LSP:
0 1 2 3 Diff-Serv TLV for an E-LSP:
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| Diff-Serv (0x901) | Length |
Le Faucheur et. al 35 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| Reserved | MAPnb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Diff-Serv (0x0901) | Length |
| MAP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Reserved | MAPnb |
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) | | MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit T:1 bit
LSP Type. This is set to 0 for an E-LSP LSP Type. This is set to 0 for an E-LSP
Reserved : 27 bits Reserved : 27 bits
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and must be ignored on receipt. and must be ignored on receipt.
MAPnb : 4 bits MAPnb : 4 bits
Indicates the number of MAP entries included in the DIFFSERV Indicates the number of MAP entries included in the DIFFSERV
Object. This can be set to any value from 1 to 8. Object. This can be set to any value from 1 to 8.
MAP : 32 bits MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format: and one PHB. The MAP entry has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID | | Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits Reserved : 13 bits
This field is reserved. It must be set to zero on This field is reserved. It must be set to zero on transmission
transmission and must be ignored on receipt. and must be ignored on receipt.
EXP : 3 bits EXP : 3 bits
This field contains the value of the EXP field for the This field contains the value of the EXP field for the
EXP<-->PHB mapping defined in this MAP entry. `EXP<-->PHB mapping' defined in this MAP entry.
PHBID : 16 bits PHBID : 16 bits
This field contains the PHBID of the PHB for the This field contains the PHBID of the PHB for the `EXP<-->PHB
EXP<-->PHB mapping defined in this MAP entry. The PHBID mapping' defined in this MAP entry. The PHBID is encoded as
is encoded as specified in [PHBID]. specified in [PHBID].
Diff-Serv TLV for an L-LSP: Diff-Serv TLV for an L-LSP:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 = PSC (0x901) | Length | |U|F| Type = PSC (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 36 |T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit T:1 bit
LSP Type. This is set to 1 for an L-LSP LSP Type. This is set to 1 for an L-LSP
Reserved : 15 bits Reserved : 15 bits
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
and must be ignored on receipt. and must be ignored on receipt.
PSC : 16 bits PSC : 16 bits
The PSC indicates a PHB Scheduling Class to be supported by the The PSC indicates a PHB Scheduling Class to be supported by the
LSP. The PSC is encoded as specified in [PHBID]. LSP. The PSC is encoded as specified in [PHBID].
6.2 Diff-Serv Status Code Values 6.2 Diff-Serv Status Code Values
The following values are defined for the Status Code field of the The following values are defined for the Status Code field of the
Status TLV: Status TLV:
Status Code E Status Data Status Code E Status Data
Unexpected Diff-Serv TLV 0 0x01000001 Unexpected Diff-Serv TLV 0 0x01000001
Unsupported PHB 0 0x01000002 Unsupported PHB 0 0x01000002
Invalid EXP<-->PHB mapping 0 0x01000003 Invalid `EXP<-->PHB mapping' 0 0x01000003
Unsupported PSC 0 0x01000004 Unsupported PSC 0 0x01000004
Per-LSP context allocation failure 0 0x01000005 Per-LSP context allocation failure 0 0x01000005
6.3 Diff-Serv Related LDP Messages 6.3 Diff-Serv Related LDP Messages
6.3.1 Label Request Message 6.3.1 Label Request Message
The format of the Label Request message is extended as follows, to The format of the Label Request message is extended as follows, to
optionally include the Diff-Serv TLV: optionally include the Diff-Serv TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
skipping to change at line 1954 skipping to change at page 45, line 10
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) | | Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.2 Label Mapping Message 6.3.2 Label Mapping Message
The format of the Label Mapping message is extended as follows, to The format of the Label Mapping message is extended as follows, to
optionally include the Diff-Serv TLV: optionally include the Diff-Serv TLV:
Le Faucheur et. al 37
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length | |0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV | | FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV | | Label TLV |
skipping to change at line 2007 skipping to change at page 46, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV | | Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters | | Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) | | Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 38
6.4 Handling of the Diff-Serv TLV 6.4 Handling of the Diff-Serv TLV
6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode 6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode
This section describes operations when the Downstream Unsolicited This section describes operations when the Downstream Unsolicited
Mode is used. Mode is used.
When allocating a label for an E-LSP which is to use the When allocating a label for an E-LSP which is to use the
preconfigured EXP<-->PHB mapping, a downstream Diff-Serv LSR issues preconfigured `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues
a Label Mapping message without the Diff-Serv TLV. a Label Mapping message without the Diff-Serv TLV.
When allocating a label for an E-LSP which is to use a signaled When allocating a label for an E-LSP which is to use a signaled
EXP<-->PHB mapping, a downstream Diff-Serv LSR issues a Label `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label
Mapping message with the Diff-Serv TLV for an E-LSP which contains Mapping message with the Diff-Serv TLV for an E-LSP which contains
one MAP entry for each EXP value to be supported on this E-LSP. one MAP entry for each EXP value to be supported on this E-LSP.
When allocating a label for an L-LSP, a downstream Diff-Serv LSR When allocating a label for an L-LSP, a downstream Diff-Serv LSR
issues a Label Mapping message with the Diff-Serv TLV for an L-LSP issues a Label Mapping message with the Diff-Serv TLV for an L-LSP
which contains the PHB Scheduling Class (PSC) to be supported on which contains the PHB Scheduling Class (PSC) to be supported on this
this L-LSP. L-LSP.
Assuming the label set-up is successful, the downstream and upstream Assuming the label set-up is successful, the downstream and upstream
LSRs must: LSRs must:
- update the Diff-Serv Context associated with the established
LSPs in their ILM/FTN as specified in previous sections - update the Diff-Serv Context associated with the established LSPs
(incoming and outgoing label), in their ILM/FTN as specified in previous sections (incoming and
- install the required Diff-Serv forwarding treatment (scheduling outgoing label),
and dropping behavior) for this NHLFE (outgoing label).
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
An upstream Diff-Serv LSR receiving a Label Mapping message with An upstream Diff-Serv LSR receiving a Label Mapping message with
multiple Diff-Serv TLVs only considers the first one as meaningful. multiple Diff-Serv TLVs only considers the first one as meaningful.
The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
An upstream Diff-Serv LSR which receives a Label Mapping message An upstream Diff-Serv LSR which receives a Label Mapping message,
with the Diff-Serv TLV for an E-LSP and does not support the with the Diff-Serv TLV for an E-LSP and does not support the
particular PHB encoded in one, or more, of the MAP entries, must particular PHB encoded in one or more of the MAP entries, must reject
reject the mapping by sending a Label Release message which includes the mapping by sending a Label Release message which includes the
the Label TLV and the Status TLV with a Status Code of `Unsupported Label TLV and the Status TLV with a Status Code of `Unsupported PHB'.
PHB'.
An upstream Diff-Serv LSR receiving a Label Mapping message with the An upstream Diff-Serv LSR receiving a Label Mapping message with the
Diff-Serv TLV for an E-LSP and determining that the signaled Diff-Serv TLV for an E-LSP and determining that the signaled
EXP<-->PHB mapping is invalid, must reject the mapping by sending a `EXP<-->PHB mapping' is invalid, must reject the mapping by sending a
Label Release message which includes the Label TLV and the Status Label Release message which includes the Label TLV and the Status TLV
TLV with a Status Code of `Invalid EXP<-->PHB Mapping'. The with a Status Code of Invalid `EXP<-->PHB mapping'. The
EXP<-->PHB mapping signaled in the DIFFSERV Object for an E-LSP is `EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is
invalid when: invalid when:
- the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
Le Faucheur et. al 39 - the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
An upstream Diff-Serv LSR receiving a Label Mapping message with the An upstream Diff-Serv LSR receiving a Label Mapping message with the
Diff-Serv TLV for an L-LSP containing a PSC value which is not Diff-Serv TLV for an L-LSP containing a PSC value which is not
supported, must reject the mapping by sending a Label Release supported, must reject the mapping by sending a Label Release message
message which includes the Label TLV and the Status TLV with a which includes the Label TLV and the Status TLV with a Status Code of
Status Code of `Unsupported PSC'. `Unsupported PSC'.
6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode 6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode
This section describes operations when the Downstream on Demand Mode This section describes operations when the Downstream on Demand Mode
is used. is used.
When requesting a label for an E-LSP which is to use the When requesting a label for an E-LSP which is to use the
preconfigured EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a preconfigured `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a
Label Request message without the Diff-Serv TLV. Label Request message without the Diff-Serv TLV.
When requesting a label for an E-LSP which is to use a signaled When requesting a label for an E-LSP which is to use a signaled
EXP<-->PHB mapping, an upstream Diff-Serv LSR sends a Label Request `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request
message with the Diff-Serv TLV for an E-LSP which contains one MAP message with the Diff-Serv TLV for an E-LSP which contains one MAP
entry for each EXP value to be supported on this E-LSP. entry for each EXP value to be supported on this E-LSP.
When requesting a label for an L-LSP, an upstream Diff-Serv LSR When requesting a label for an L-LSP, an upstream Diff-Serv LSR sends
sends a Label Request message with the Diff-Serv TLV for an L-LSP a Label Request message with the Diff-Serv TLV for an L-LSP which
which contains the PSC to be supported on this L-LSP. contains the PSC to be supported on this L-LSP.
A downstream Diff-Serv LSR sending a Label Mapping message in A downstream Diff-Serv LSR sending a Label Mapping message in
response to a Label Request message for an E-LSP or an L-LSP must response to a Label Request message for an E-LSP or an L-LSP must not
not include a Diff-Serv TLV in this Label Mapping message. include a Diff-Serv TLV in this Label Mapping message. Assuming the
Assuming the label set-up is successful, the downstream and upstream label set-up is successful, the downstream and upstream LSRs must:
LSRs must:
- update the Diff-Serv Context associated with the established - update the Diff-Serv Context associated with the established LSPs
LSPs in their ILM/FTN as specified in previous sections in their ILM/FTN as specified in previous sections (incoming and
(incoming and outgoing label), outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label). - install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
An upstream Diff-Serv LSR receiving a Label Mapping message An upstream Diff-Serv LSR receiving a Label Mapping message
containing a Diff-Serv TLV in response to its Label Request message, containing a Diff-Serv TLV in response to its Label Request message,
must reject the label mapping by sending a Label Release message must reject the label mapping by sending a Label Release message
which includes the Label TLV and the Status TLV with a Status Code which includes the Label TLV and the Status TLV with a Status Code of
of `Unexpected Diff-Serv TLV'. `Unexpected Diff-Serv TLV'.
A downstream Diff-Serv LSR receiving a Label Request message with A downstream Diff-Serv LSR receiving a Label Request message with
multiple Diff-Serv TLVs only considers the first one as meaningful. multiple Diff-Serv TLVs only considers the first one as meaningful.
The LSR must ignore and not forward the subsequent Diff-Serv TLV(s). The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
A downstream Diff-Serv LSR which receives a Label Request message A downstream Diff-Serv LSR which receives a Label Request message
with the Diff-Serv TLV for an E-LSP and does not support the with the Diff-Serv TLV for an E-LSP and does not support the
particular PHB encoded in one (or more) of the MAP entries, must particular PHB encoded in one (or more) of the MAP entries, must
reject the request by sending a Notification message which includes reject the request by sending a Notification message which includes
the Status TLV with a Status Code of `Unsupported PHB'. the Status TLV with a Status Code of `Unsupported PHB'.
Le Faucheur et. al 40 A downstream Diff-Serv LSR receiving a Label Request message with the
A downstream Diff-Serv LSR receiving a Label Request message with Diff-Serv TLV for an E-LSP and determining that the signaled
the Diff-Serv TLV for an E-LSP and determining that the signaled `EXP<-->PHB mapping' is invalid, must reject the request by sending a
EXP<-->PHB mapping is invalid, must reject the request by sending a Notification message which includes the Status TLV with a Status Code
Notification message which includes the Status TLV with a Status of Invalid `EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled
Code of `Invalid EXP<-->PHB Mapping'. The EXP<-->PHB mapping in the DIFFSERV TLV for an E-LSP is invalid when:
signaled in the DIFFSERV TLV for an E-LSP is invalid when:
- the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
A downstream Diff-Serv LSR receiving a Label Request message with - the MAPnb field is not within the range 1 to 8, or
the Diff-Serv TLV for an L-LSP containing a PSC value which is not
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
A downstream Diff-Serv LSR receiving a Label Request message with the
Diff-Serv TLV for an L-LSP containing a PSC value which is not
supported, must reject the request by sending a Notification message supported, must reject the request by sending a Notification message
which includes the Status TLV with a Status Code of `Unsupported which includes the Status TLV with a Status Code of `Unsupported
PSC'. PSC'.
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in
a Label Request message but is unable to allocate the required a Label Request message but is unable to allocate the required per-
per-LSP context information, must reject the request sending a LSP context information, must reject the request sending a
Notification message which includes the Status TLV with a Status Notification message which includes the Status TLV with a Status Code
Code of `Per-LSP context allocation failure'. of `Per-LSP context allocation failure'.
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in
a Label Request message and supports the requested PSC but is not a Label Request message and supports the requested PSC but is not
able to satisfy the label request for other reasons (e.g. no label able to satisfy the label request for other reasons (e.g., no label
available), must send a Notification message in accordance with available), must send a Notification message in accordance with
existing LDP procedures [LDP] (e.g. with a `No Label Resource' existing LDP procedures [LDP] (e.g., with a `No Label Resource'
Status Code). This Notification message must include the requested Status Code). This Notification message must include the requested
Diff-Serv TLV. Diff-Serv TLV.
6.5 Non-Handling of the Diff-Serv TLV 6.5 Non-Handling of the Diff-Serv TLV
An LSR that does not recognize the Diff-Serv TLV Type, on receipt of An LSR that does not recognize the Diff-Serv TLV Type, on receipt of
a Label Request message or a Label Mapping message containing the a Label Request message or a Label Mapping message containing the
Diff-Serv TLV, must behave in accordance with the procedures Diff-Serv TLV, must behave in accordance with the procedures
specified in [LDP] for an unknown TLV whose U Bit and F Bit are set specified in [LDP] for an unknown TLV whose U Bit and F Bit are set
to 0 i.e. it must ignore the message, return a Notification message to 0 i.e., it must ignore the message, return a Notification message
with `Unknown TLV' Status. with `Unknown TLV' Status.
6.6 Bandwidth Information 6.6 Bandwidth Information
Bandwidth information may also be signaled at establishment time of Bandwidth information may also be signaled at the establishment time
E-LSP and L-LSP, for instance for the purpose of Traffic of E-LSP and L-LSP, for instance for the purpose of Traffic
Engineering, using the Traffic Parameters TLV as described in Engineering, using the Traffic Parameters TLV as described in [MPLS
[MPLS CR LDP]. CR LDP].
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR 7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR
Interfaces Interfaces
The general operations for MPLS support of Diff-Serv, including
label forwarding and LSP setup operations are specified in the
Le Faucheur et. al 41 The general operations for MPLS support of Diff-Serv, including label
previous sections. This section describes the specific operations forwarding and LSP setup operations are specified in the previous
required for MPLS support of Diff-Serv over PPP interfaces, LAN sections. This section describes the specific operations required
interfaces, ATM Interfaces which are not label controlled and Frame for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces,
Relay interfaces which are not label controlled. ATM Interfaces which are not label controlled and Frame Relay
interfaces which are not label controlled.
On these interfaces, this specification allows any of the following On these interfaces, this specification allows any of the following
LSP combinations per FEC: LSP combinations per FEC:
- Zero or any number of E-LSP, and - Zero or any number of E-LSP, and
- Zero or any number of L-LSPs.
A Diff-Serv capable LSR MUST support E-LSPs which use pre-configured - Zero or any number of L-LSPs.
EXP<-->PHB mapping over these interfaces.
A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured
`EXP<-->PHB mapping' over these interfaces.
A Diff-Serv capable LSR MAY support E-LSPs which use signaled A Diff-Serv capable LSR MAY support E-LSPs which use signaled
EXP<-->PHB mapping and L-LSPs over these interfaces. `EXP<-->PHB mapping' and L-LSPs over these interfaces.
8. MPLS Support of Diff-Serv over LC-ATM Interfaces 8. MPLS Support of Diff-Serv over LC-ATM Interfaces
This section describes the specific operations required for MPLS This section describes the specific operations required for MPLS
support of Diff-Serv over label switching controlled ATM (LC-ATM) support of Diff-Serv over label switching controlled ATM (LC-ATM)
interfaces. interfaces.
This document allows any number of L-LSPs per FEC within an MPLS ATM This document allows any number of L-LSPs per FEC within an MPLS ATM
Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces. Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms 8.1 Use of ATM Traffic Classes and Traffic Management mechanisms
The use of the "ATM service categories" specified by the ATM Forum, The use of the "ATM service categories" specified by the ATM Forum,
of the "ATM Transfer Capabilities" specified by the ITU-T or of of the "ATM Transfer Capabilities" specified by the ITU-T or of
vendor specific ATM traffic classes is outside of the scope of this vendor specific ATM traffic classes is outside of the scope of this
specification. The only requirement for compliant implementation is specification. The only requirement for compliant implementation is
that the forwarding behavior experienced by a Behavior Aggregate that the forwarding behavior experienced by a Behavior Aggregate
forwarded over an L-LSP by the ATM LSR MUST be compliant with the forwarded over an L-LSP by the ATM LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications. corresponding Diff-Serv PHB specifications.
Since there is only one bit (CLP) for encoding the PHB drop Since there is only one bit (CLP) for encoding the PHB drop
precedence value over ATM links, only two different drop precedence precedence value over ATM links, only two different drop precedence
levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define
how the three drop precedence levels of the AFn Ordered Aggregates how the three drop precedence levels of the AFn Ordered Aggregates
are mapped to these two ATM drop precedence levels. This mapping is are mapped to these two ATM drop precedence levels. This mapping is
in accordance with the requirements specified in [DIFF_AF] for the in accordance with the requirements specified in [DIFF_AF] for the
case when only two drop precedence levels are supported. case when only two drop precedence levels are supported.
To avoid discarding parts of the packets, frame discard mechanisms, To avoid discarding parts of the packets, frame discard mechanisms,
such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled
in the ATM-LSRs for all PHBs described in this document. in the ATM-LSRs for all PHBs described in this document.
8.2 LSR Implementation With LC-ATM Interfaces 8.2 LSR Implementation With LC-ATM Interfaces
A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces.
Le Faucheur et. al 42
This specification assumes that Edge-LSRs of the ATM-LSR domain use This specification assumes that Edge-LSRs of the ATM-LSR domain use
the "shim header" encapsulation method defined in [MPLS_ATM]. the "shim header" encapsulation method defined in [MPLS_ATM].
Operations without the "shim header" encapsulation is outside the Operations without the "shim header" encapsulation are outside the
scope of this specification. scope of this specification.
9. MPLS Support of Diff-Serv over LC-FR Interfaces 9. MPLS Support of Diff-Serv over LC-FR Interfaces
This section describes the specific operations required for MPLS This section describes the specific operations required for MPLS
support of Diff-Serv over label switching controlled Frame Relay support of Diff-Serv over label switching controlled Frame Relay
(LC-FR) interfaces. (LC-FR) interfaces.
This document allows any number of L-LSPs per FEC within an MPLS This document allows any number of L-LSPs per FEC within an MPLS
Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR
interfaces. interfaces.
9.1 Use of Frame Relay Traffic parameters and Traffic Management 9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms mechanisms
The use of the Frame Relay traffic parameters as specified by ITU-T The use of the Frame Relay traffic parameters as specified by ITU-T
and Frame Relay-Forum or of vendor specific Frame Relay traffic and Frame Relay-Forum or of vendor specific Frame Relay traffic
management mechanisms is outside of the scope of this specification. management mechanisms is outside of the scope of this specification.
The only requirement for compliant implementation is that the The only requirement for compliant implementation is that the
forwarding behavior experienced by a Behavior Aggregate forwarded forwarding behavior experienced by a Behavior Aggregate forwarded
over an L-LSP by the Frame Relay LSR MUST be compliant with the over an L-LSP by the Frame Relay LSR MUST be compliant with the
corresponding Diff-Serv PHB specifications. corresponding Diff-Serv PHB specifications.
Since there is only one bit (DE) for encoding the PHB drop Since there is only one bit (DE) for encoding the PHB drop precedence
precedence value over Frame Relay links, only two different drop value over Frame Relay links, only two different drop precedence
precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3
and 4.4.3 define how the three drop precedence levels of the AFn define how the three drop precedence levels of the AFn Ordered
Ordered Aggregates are mapped to these two Frame Relay drop Aggregates are mapped to these two Frame Relay drop precedence
precedence levels. This mapping is in accordance with the levels. This mapping is in accordance with the requirements
requirements specified in [DIFF_AF] for the case when only two drop specified in [DIFF_AF] for the case when only two drop precedence
precedence levels are supported. levels are supported.
9.2 LSR Implementation With LC-FR Interfaces 9.2 LSR Implementation With LC-FR Interfaces
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay
interfaces. interfaces.
This specification assumes that Edge-LSRs of the FR-LSR domain use This specification assumes that Edge-LSRs of the FR-LSR domain use
the "generic encapsulation" method as recommended in [MPLS_FR]. the "generic encapsulation" method as recommended in [MPLS_FR].
Operations without the "generic encapsulation" is outside the scope Operations without the "generic encapsulation" are outside the scope
of this specification. of this specification.
10. IANA Considerations. 10. IANA Considerations
This document defines a number of objects with implications for This document defines a number of objects with implications for IANA.
IANA.
Le Faucheur et. al 43 This document defines in section 5.2 a new RSVP object, the DIFFSERV
This document defines in section 5.2 a new RSVP object, the Diffserv object. This object required a number from the space defined in
object. This object requires a number to be assigned from the space [RSVP] for those objects which, if not understood, cause the entire
defined in [RSVP] for those objects which, if not understood, cause RSVP message to be rejected with an error code of "Unknown Object
the entire RSVP message to be rejected with an error code of Class". Such objects are identified by a zero in the most
"Unknown Object Class". Such objects are identified by a zero in the significant bit of the class number. Within that space, this object
most significant bit of the class number. Within that space, this required a number from the "IETF Consensus" space. "65" has been
object should be assigned a number from the "IETF Consensus" space. allocated by IANA for the DIFFSERV object.
This document defines in section 5.5 a new RSVP error code, This document defines in section 5.5 a new RSVP error code, "Diffserv
"Diffserv Error". This error code should be assigned by IANA. This Error". Error code "27" has been assigned by IANA to the "Diffserv
document defines values 1 through 5 of the value field to be used Error". This document defines values 1 through 5 of the value field
within the ERROR_SPEC object for this error code. Future allocations to be used within the ERROR_SPEC object for this error code. Future
of values in this space should be handled by IANA using the First allocations of values in this space should be handled by IANA using
Come First Served policy defined in [IANA]. the First Come First Served policy defined in [IANA].
This document defines in section 6.1 a new LDP TLV, the Diffserv This document defines in section 6.1 a new LDP TLV, the Diffserv TLV.
TLV. The number for this TLV has been assigned by working group The number for this TLV has been assigned by working group consensus
consensus according to the policies defined in [LDP]. according to the policies defined in [LDP].
This document defines in section 6.2 five new LDP Status Code values This document defines in section 6.2 five new LDP Status Code values
for Diffserv-related error conditions. The values for the Status for Diffserv-related error conditions. The values for the Status
Code have been assigned by working group consensus according to the Code have been assigned by working group consensus according to the
policies defined in [LDP]. policies defined in [LDP].
11. Security Considerations 11. Security Considerations
This document does not introduce any new security issues beyond This document does not introduce any new security issues beyond those
those inherent in Diff-Serv, MPLS and RSVP, and may use the same inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms
mechanisms proposed for those technologies. proposed for those technologies.
12. Acknowledgments 12. Acknowledgments
This document has benefited from discussions with Eric Rosen, Angela This document has benefited from discussions with Eric Rosen, Angela
Chiu and Carol Iturralde. It has also borrowed from the work done by Chiu and Carol Iturralde. It has also borrowed from the work done by
D. Black regarding Diff-Serv and IP Tunnels interaction. D. Black regarding Diff-Serv and IP Tunnels interaction.
APPENDIX A. Example Deployment Scenarios APPENDIX A. Example Deployment Scenarios
This section does not provide additional specification and is only This section does not provide additional specification and is only
here to provide examples of how this flexible approach for Diff-Serv here to provide examples of how this flexible approach for Diff-Serv
support over MPLS may be deployed. Pros and cons of various support over MPLS may be deployed. Pros and cons of various
deployment options for particular environments are beyond the scope deployment options for particular environments are beyond the scope
of this document. of this document.
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS
Protection Protection
Le Faucheur et. al 44 A Service Provider running 8 (or fewer) BAs over MPLS, not performing
A Service Provider running 8 (or fewer) BAs over MPLS, not Traffic engineering, not using MPLS protection and using MPLS Shim
performing Traffic engineering, not using MPLS protection and using Header encapsulation in his/her network, may elect to run Diff-Serv
MPLS Shim Header encapsulation in his/her network, may elect to run over MPLS using a single E-LSP per FEC established via LDP.
Diff-Serv over MPLS using a single E-LSP per FEC established via Furthermore the Service Provider may elect to use the preconfigured
LDP. Furthermore the Service Provider may elect to use the `EXP<-->PHB mapping'.
preconfigured EXP<-->PHB mapping.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field - the Service Provider configures at every LSR, the bi-directional
(e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13) mapping between each PHB and a value of the EXP field
- the Service Provider configures at every LSR, and for every (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (e.g. - the Service Provider configures at every LSR, and for every
drop profile for AF11, AF12, AF13) interface, the scheduling behavior for each PSC (e.g., bandwidth
- LSRs signal establishment of a single E-LSP per FEC using LDP in allocated to AF1) and the dropping behavior for each PHB (e.g.,
accordance with the specification above (i.e. no Diff-Serv TLV drop profile for AF11, AF12, AF13)
in LDP Label Request/Label Mapping messages to implicitly
indicate that the LSP is an E-LSP and that it uses the - LSRs signal establishment of a single E-LSP per FEC using LDP in
preconfigured mapping) accordance with the specification above (i.e., no Diff-Serv TLV in
LDP Label Request/Label Mapping messages to implicitly indicate
that the LSP is an E-LSP and that it uses the preconfigured
mapping)
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS
Protection Protection
A Service Provider running more than 8 BAs over MPLS, not performing A Service Provider running more than 8 BAs over MPLS, not performing
Traffic Engineering, not using MPLS protection and using MPLS Shim Traffic Engineering, not using MPLS protection and using MPLS Shim
encapsulation in his/her network may elect to run Diff-Serv over encapsulation in his/her network may elect to run Diff-Serv over MPLS
MPLS using for each FEC: using for each FEC:
- one E-LSP established via LDP and using the preconfigured
mapping to support a set of 8 (or less) BAs, AND - one E-LSP established via LDP and using the preconfigured mapping
- one L-LSP per <FEC,OA> established via LDP for support of the to support a set of 8 (or less) BAs, AND
other BAs.
- one L-LSP per <FEC,OA> established via LDP for support of the
other BAs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field for the
BAs transported over the E-LSP
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over
the E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over
the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of a single E-LSP per FEC for the set
of E-LSP transported BAs using LDP as specified above (i.e. no
Diff-Serv TLV in LDP Label Request/Label Mapping messages to
implicitly indicate that the LSP is an E-LSP and that it uses
the preconfigured mapping)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the
other BAs using LDP as specified above (i.e. Diff-Serv TLV in
LDP Label Request/Label Mapping messages to indicate the L-LSP's
PSC).
Le Faucheur et. al 45 - the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field for the BAs
transported over the E-LSP
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the
E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the
L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of a single E-LSP per FEC for the set of
E-LSP transported BAs using LDP as specified above (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages to
implicitly indicate that the LSP is an E-LSP and that it uses the
preconfigured mapping)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other
BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label
Request/Label Mapping messages to indicate the L-LSP's PSC).
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering,
Aggregate MPLS Protection Aggregate MPLS Protection
A Service Provider running 8 (or fewer) BAs over MPLS, performing A Service Provider running 8 (or fewer) BAs over MPLS, performing
aggregate Traffic Engineering (i.e. performing a single common path aggregate Traffic Engineering (i.e., performing a single common path
selection for all BAs), using aggregate MPLS protection (i.e. selection for all BAs), using aggregate MPLS protection (i.e.,
restoring service to all PSCs jointly) and using MPLS Shim Header restoring service to all PSCs jointly) and using MPLS Shim Header
encapsulation in his/her network, may elect to run Diff-Serv over encapsulation in his/her network, may elect to run Diff-Serv over
MPLS using a single E-LSP per FEC established via RSVP MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE]
[RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping.
preconfigured mapping.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field - the Service Provider configures at every LSR the bi-directional
(e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13) mapping between each PHB and a value of the EXP field
- the Service Provider configures at every LSR, and for every (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg - the Service Provider configures at every LSR, and for every
drop profile for AF11, AF12, AF13) interface, the scheduling behavior for each PSC (e.g., bandwidth
- LSRs signal establishment of a single E-LSP per FEC which will allocated to AF1) and the dropping behavior for each PHB (eg drop
use the preconfigured mapping: profile for AF11, AF12, AF13)
* using the RSVP protocol as specified above (i.e. no
DIFFSERV RSVP Object in the PATH message containing the - LSRs signal establishment of a single E-LSP per FEC which will use
LABEL_REQUEST Object), OR the preconfigured mapping:
* using the CR-LDP protocol as specified above (i.e. no
Diff-Serv TLV in LDP Label Request/Label Mapping messages). * using the RSVP protocol as specified above (i.e., no DIFFSERV
- protection is activated on all the E-LSPs in order to achieve RSVP Object in the PATH message containing the LABEL_REQUEST
MPLS protection via mechanisms outside the scope of this Object), OR
document.
* using the CR-LDP protocol as specified above (i.e., no Diff-
Serv TLV in LDP Label Request/Label Mapping messages).
- protection is activated on all the E-LSPs in order to achieve MPLS
protection via mechanisms outside the scope of this document.
A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection
A Service Provider running any number of BAs over MPLS, performing A Service Provider running any number of BAs over MPLS, performing
per-OA Traffic Engineering (i.e. performing a separate path per-OA Traffic Engineering (i.e., performing a separate path
selection for each OA) and performing per-OA MPLS protection (i.e. selection for each OA) and performing per-OA MPLS protection (i.e.,
performing protection with potentially different levels of performing protection with potentially different levels of protection
protection for the different OAs) in his/her network, may elect to for the different OAs) in his/her network, may elect to run Diff-Serv
run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or
established via RSVP or CR-LDP. CR-LDP.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg
drop profile for AF11, AF12, AF13)
- LSRs signal establishment of one L-LSP per <FEC,OA>:
* using the RSVP as specified above to signal the
L-LSP's PSC (i.e. DIFFSERV RSVP Object in the PATH message
containing the LABEL_REQUEST), OR
Le Faucheur et. al 46 - the Service Provider configures at every LSR, and for every
* using the CR-LDP protocol as specified above to interface, the scheduling behavior for each PSC (e.g., bandwidth
signal the L-LSP PSC (i.e. Diff-Serv TLV in LDP Label allocated to AF1) and the dropping behavior for each PHB (e.g.,
Request/Label Mapping messages). drop profile for AF11, AF12, AF13)
- the appropriate level of protection is activated on the
different L-LSPs (potentially with a different level of - LSRs signal establishment of one L-LSP per <FEC,OA>:
protection for each PSC)_via mechanisms outside the scope of
this document. * using the RSVP as specified above to signal the L-LSP's PSC
(i.e., DIFFSERV RSVP Object in the PATH message containing the
LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to signal the L-
LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping
messages).
- the appropriate level of protection is activated on the different
L-LSPs (potentially with a different level of protection for each
PSC) via mechanisms outside the scope of this document.
A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS
Protection Protection
A Service Provider running 8 (or fewer) 8 BAs over MPLS, performing A Service Provider running 8 (or fewer) BAs over MPLS, performing
per-OA Traffic Engineering (i.e. performing a separate path per-OA Traffic Engineering (i.e., performing a separate path
selection for each OA) and performing per-OA MPLS protection (i.e. selection for each OA) and performing per-OA MPLS protection (i.e.,
performing protection with potentially different levels of performing protection with potentially different levels of protection
protection for the different OAs) in his/her network, may elect to for the different OAs) in his/her network, may elect to run Diff-Serv
run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or
established via RSVP or CR-LDP. Furthermore, the Service Provider CR-LDP. Furthermore, the Service Provider may elect to use the
may elect to use the preconfigured mapping on all the E-LSPs. preconfigured mapping on all the E-LSPs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field - the Service Provider configures at every LSR the bi-directional
(e.g. 000<-->AF11, 001<-->AF12, 010<-->AF13) mapping between each PHB and a value of the EXP field
- the Service Provider configures at every LSR, and for every (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg - the Service Provider configures at every LSR, and for every
drop profile for AF11, AF12, AF13) interface, the scheduling behavior for each PSC (e.g., bandwidth
- LSRs signal establishment of one E-LSP per <FEC,OA>: allocated to AF1) and the dropping behavior for each PHB (eg drop
* using the RSVP protocol as specified above to signal profile for AF11, AF12, AF13)
that the LSP is an E-LSP which uses the preconfigured mapping
(i.e. no DIFFSERV RSVP Object in the PATH message containing the - LSRs signal establishment of one E-LSP per <FEC,OA>:
LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to * using the RSVP protocol as specified above to signal that the
signal that the LSP is an E-LSP which uses the preconfigured LSP is an E-LSP which uses the preconfigured mapping (i.e., no
mapping (i.e. no Diff-Serv TLV in LDP Label Request/Label DIFFSERV RSVP Object in the PATH message containing the
Mapping messages) LABEL_REQUEST), OR
- the Service Provider configures, for each E-LSP, at the head-end
of that E-LSP, a filtering/forwarding criteria so that only the * using the CR-LDP protocol as specified above to signal that the
packets belonging to a given OA are forwarded on the E-LSP LSP is an E-LSP which uses the preconfigured mapping (i.e., no
established for the corresponding FEC and corresponding OA. Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- the appropriate level of protection is activated on the
different E-LSPs (potentially with a different level of - the Service Provider configures, for each E-LSP, at the head-end
protection depending on the PSC actually transported over each of that E-LSP, a filtering/forwarding criteria so that only the
E-LSP)_via mechanisms outside the scope of this document. packets belonging to a given OA are forwarded on the E-LSP
established for the corresponding FEC and corresponding OA.
- the appropriate level of protection is activated on the different
E-LSPs (potentially with a different level of protection depending
on the PSC actually transported over each E-LSP) via mechanisms
outside the scope of this document.
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA
Traffic Engineering/MPLS Protection on other BAs. Traffic Engineering/MPLS Protection on other BAs.
A Service Provider not performing Traffic Engineering/MPLS A Service Provider not performing Traffic Engineering/MPLS Protection
Protection on 8 (or fewer) BAs, performing per-OA Traffic on 8 (or fewer) BAs, performing per-OA Traffic Engineering/MPLS
Protection on the other BAs (i.e., performing a separate path
selection for each OA corresponding to the other BAs and performing
MPLS Protection with a potentially different policy for each of these
OA) and using the MPLS Shim encapsulation in his/her network may
elect to run Diff-Serv over MPLS, using for each FEC:
Le Faucheur et. al 47 - one E-LSP using the preconfigured mapping established via LDP to
Engineering/MPLS Protection on the other BAs (i.e. performing a support the set of 8 (or fewer) non-traffic-engineered/non-
separate path selection for each OA corresponding to the other BAs protected BAs, AND
and performing MPLS Protection with a potentially different policy
for each of these OA) and using the MPLS Shim encapsulation in - one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for
his/her network may elect to run Diff-Serv over MPLS, using for each support of the other BAs.
FEC:
- one E-LSP using the preconfigured mapping established via LDP to
support the set of 8 (or fewer) non-traffic-engineered/non-
protected BAs, AND
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for
support of the other BAs.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field for the - the Service Provider configures at every LSR the bi-directional
BAs supported over the E-LSP mapping between each PHB and a value of the EXP field for the BAs
- the Service Provider configures at every LSR, and for every supported over the E-LSP
interface, the scheduling behavior for each PSC supported over
the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the
interface, the scheduling behavior for each PSC supported over E-LSP and the dropping behavior for each corresponding PHB
the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of a single E-LSP per FEC for the non- - the Service Provider configures at every LSR, and for every
traffic engineered BAs using LDP as specified above (i.e. no interface, the scheduling behavior for each PSC supported over the
Diff-Serv TLV in LDP Label Request/Label Mapping messages) L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal establishment of one L-LSP per <FEC,OA> for the
other BAs: - LSRs signal establishment of a single E-LSP per FEC for the non-
* using the RSVP protocol as specified above to signal traffic engineered BAs using LDP as specified above (i.e., no
the L-LSP PSC (i.e. DIFFSERV RSVP Object in the PATH message Diff-Serv TLV in LDP Label Request/Label Mapping messages)
containing the LABEL_REQUEST Object), OR
* using the CR-LDP protocol as specified above to - LSRs signal establishment of one L-LSP per <FEC,OA> for the other
signal the L-LSP PSC (i.e. Diff-Serv TLV in LDP Label BAs:
Request/Label Mapping messages).
- protection is not activated on the E-LSPs. * using the RSVP protocol as specified above to signal the L-LSP
- the appropriate level of protection is activated on the PSC (i.e., DIFFSERV RSVP Object in the PATH message containing
different L-LSPs (potentially with a different level of the LABEL_REQUEST Object), OR
protection depending on the L-LSP's PSC)_via mechanisms outside
the scope of this document. * using the CR-LDP protocol as specified above to signal the L-
LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping
messages).
- protection is not activated on the E-LSPs.
- the appropriate level of protection is activated on the different
L-LSPs (potentially with a different level of protection depending
on the L-LSP's PSC) via mechanisms outside the scope of this
document.
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS
Protection Protection
A Service Provider running more than 8 BAs over MPLS, not performing A Service Provider running more than 8 BAs over MPLS, not performing
Traffic engineering, not performing MPLS protection and using MPLS Traffic engineering, not performing MPLS protection and using MPLS
Shim Header encapsulation in his/her network, may elect to run Diff- Shim Header encapsulation in his/her network, may elect to run Diff-
Serv over MPLS using two E-LSPs per FEC established via LDP and Serv over MPLS using two E-LSPs per FEC established via LDP and using
using signaled EXP<-->PHB mapping. signaled `EXP<-->PHB mapping'.
Operations can be summarized as follows: Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (eg bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg
drop profile for AF11, AF12, AF13)
Le Faucheur et. al 48 - the Service Provider configures at every LSR, and for every
- LSRs signal establishment of two E-LSPs per FEC using LDP in interface, the scheduling behavior for each PSC (e.g., bandwidth
accordance with the specification above (i.e. Diff-Serv TLV in allocated to AF1) and the dropping behavior for each PHB (e.g.,
LDP Label Request/Label Mapping messages to explicitly indicate drop profile for AF11, AF12, AF13)
that the LSP is an E-LSP and its EXP<--> mapping). The signaled
mapping will indicate the subset of 8 (or less) BAs to be - LSRs signal establishment of two E-LSPs per FEC using LDP in
transported on each E-LSP and what EXP values are mapped to each accordance with the specification above (i.e., Diff-Serv TLV in
BA on each E-LSP. LDP Label Request/Label Mapping messages to explicitly indicate
that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The
signaled mapping will indicate the subset of 8 (or less) BAs to be
transported on each E-LSP and what EXP values are mapped to each
BA on each E-LSP.
APPENDIX B. Example Bandwidth Reservation Scenarios APPENDIX B. Example Bandwidth Reservation Scenarios
B.1 Scenario 1: No Bandwidth Reservation B.1 Scenario 1: No Bandwidth Reservation
Consider the case where a network administrator elects to: Consider the case where a network administrator elects to:
- have Diff-Serv resources entirely provisioned off-line (e.g. via
Command Line Interface, via SNMP, via COPS,...) - have Diff-Serv resources entirely provisioned off-line (e.g., via
- have Shortest Path Routing used for all the Diff-Serv traffic. Command Line Interface, via SNMP, via COPS,...)
- have Shortest Path Routing used for all the Diff-Serv traffic.
This is the closest model to provisioned Diff-Serv over non-MPLS IP. This is the closest model to provisioned Diff-Serv over non-MPLS IP.
In that case, E-LSPs and/or L-LSPs would be established without In that case, E-LSPs and/or L-LSPs would be established without
signaled bandwidth. signaled bandwidth.
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
Consider the case where a network administrator elects to: Consider the case where a network administrator elects to:
- have Diff-Serv resources entirely provisioned off-line (e.g. via
Command Line Interface, via SNMP, via COPS,...) - have Diff-Serv resources entirely provisioned off-line (e.g., via
- use L-LSPs Command Line Interface, via SNMP, via COPS,...)
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from - use L-LSPs
the bandwidth allocated to the relevant PSC.
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from the
bandwidth allocated to the relevant PSC.
In that case, L-LSPs would be established with signaled bandwidth. In that case, L-LSPs would be established with signaled bandwidth.
The bandwidth signaled at L-LSP establishment would be used by LSRs The bandwidth signaled at L-LSP establishment would be used by LSRs
to perform admission control at every hop to ensure that the to perform admission control at every hop to ensure that the
constraint on availability of bandwidth for the relevant PSC is met. constraint on availability of bandwidth for the relevant PSC is met.
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
per-PSC Resource Adjustment per-PSC Resource Adjustment
Consider the case where a network administrator elects to: Consider the case where a network administrator elects to:
- use L-LSPs
- have Constraint Based Routing performed separately for each PSC, - use L-LSPs
where one of the constraints is availability of bandwidth from
the bandwidth allocated to the relevant PSC. - have Constraint Based Routing performed separately for each PSC,
- have Diff-Serv resources dynamically adjusted where one of the constraints is availability of bandwidth from the
bandwidth allocated to the relevant PSC.
- have Diff-Serv resources dynamically adjusted
In that case, L-LSPs would be established with signaled bandwidth. In that case, L-LSPs would be established with signaled bandwidth.
The bandwidth signaled at L-LSP establishment would be used by LSRs The bandwidth signaled at L-LSP establishment would be used by LSRs
to attempt to adjust the resources allocated to the relevant PSC to attempt to adjust the resources allocated to the relevant PSC
(e.g. scheduling weight) and then perform admission control to (e.g., scheduling weight) and then perform admission control to
Le Faucheur et. al 49
ensure that the constraint on availability of bandwidth for the ensure that the constraint on availability of bandwidth for the
relevant PSC is met after the adjustment. relevant PSC is met after the adjustment.
References References
[MPLS_ARCH] Rosen et al., "Multiprotocol label switching [ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating
Architecture", RFC-3031, January 2001. IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992,
802.11c-1998, and P802.12e).
[MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", RFC-3032,
January 2001.
[MPLS_ATM] Davie et al., "MPLS using LDP and ATM VC Switching", RFC- [ATMF_TM] ATM Forum, "Traffic Management Specification Version
3035, January 2001. 4.1", March 1999.
[MPLS_FR] Conta et al., "Use of Label Switching on Frame Relay [CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and
Networks Specification", RFC-3034, January 2001. R. Dantu, "Constraint-Based LSP Setup using LDP",
RFC 3212, January 2002.
[DIFF_ARCH] Blake et al., "An architecture for Differentiated [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
Services", RFC-2475, December 1998. 2996, November 2000.
[DIFF_AF] Heinanen et al., "Assured Forwarding PHB Group", RFC-2597, [DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J.
June 1999. Wroclawski, "Assured Forwarding PHB Group", RFC
2597, June 1999.
[DIFF_EF] Davie et al., "An Expedited Forwarding PHB", draft-ietf- [DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
diffserv-rfc2598bis-01.txt, April 2001. Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DIFF_HEADER] Nichols et al., "Definition of the Differentiated [DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J.,
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, Benson, K., Boudec, J., Chiu, A., Courtney, W.,
December 1998. Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam,
K. and D. Stiliadis, "An Expedited Forwarding PHB
(Per-Hop Behavior)", RFC 3246, March 2002.
[ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion [DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black,
Notification (ECN) to IP", RFC-2481, January 1999. "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[LDP] Andersson et al., "LDP Specification", RFC-3036, January 2001. [DIFF_NEW] Grossman, D., "New Terminology and Clarifications
for Diffserv", RFC 3260, April 2002.
[RSVP_MPLS_TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", [DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels",
work in progress, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February RFC 2983, October 2000.
2001.
[CR-LDP_MPLS_TE] Jamoussi et al., "Constraint-Based LSP Setup using [ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The
LDP", work in progress, draft-ietf-mpls-cr-ldp-05.txt, February Addition of Explicit Congestion Notification (ECN)
2001. to IP", RFC 3168, September 2001.
[PHBID] Brim et al., "Per Hop Behavior Identification Codes" [IANA] Narten, T. and H. Alvestrand, "Guidelines for
draft-ietf-diffserv-2836bis-01.txt, February 2001. Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998.
[DIFF_NEW] Grossman, "New Terminology for Diffserv", work in [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
progress, draft-ietf-diffserv-new-terms-04.txt, March 2001. Edition (Revision and redesignation of ISO/IEC
10038:98.
[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 [LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A.
Edition (Revision and redesignation of ISO/IEC 10038:98. and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
Le Faucheur et. al 50 [MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[ANSI/IEEE Std 802.1D, 1993 Edition], incorporating IEEE [MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using
P802.12e). LDP and ATM VC Switching", RFC 3035, January 2001.
[DIFF_TUNNEL] Black, "Differentiated Services and Tunnels", [MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
RFC-2983, October 2000. Farinacci, D., Li, T. and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[MPLS_VPN] Rosen et al., "BGP/MPLS VPNs", work in progress, draft- [MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label
rosen-rfc2547bis-03.txt, February 2001. Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[RSVP] Braden et al., "Resource ReSerVation Protocol (RSVP) - [MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
Version 1 Functional Specification", RFC-2205, September 1997.
[IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [NULL] Bernet, Y., Smith, A. and B. Davie, "Specification
Considerations Section in RFCs", RFC 2434, October 1998. of the Null Service Type", RFC 2997, November 2000.
[NULL] Bernet et al., "Specification of the Null Service Type", RFC [PHBID] Black, D., Brim, S., Carpenter, B. and F. Le
2997, November 2000. Faucheur, "Per Hop Behavior Identification Codes"
RFC 3140, June 2001.
[DCLASS] Bernet, "Format of the RSVP DCLASS Object", RFC 2996, [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
November 2000. Jamin, "Resource ReSerVation Protocol (RSVP) -
Version 1 Functional Specification", RFC 2205,
September 1997.
[ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", [RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T.,
March 1999. Srinivasan, V. and G. Swallow, "Extensions to RSVP
for LSP Tunnels", RFC 3209, December 2001.
Authors' Address: Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
06410 Biot-Sophia Antipolis 06410 Biot-Sophia Antipolis
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com EMail: flefauch@cisco.com
Liwen Wu Liwen Wu
Cisco Systems Cisco Systems
3550 Cisco Way 3550 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 853-4065 Phone: +1 (408) 853-4065
Email: liwwu@cisco.com EMail: liwwu@cisco.com
Bruce Davie Bruce Davie
Cisco Systems Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824 250 Apollo Drive, Chelmsford, MA 01824
USA USA
Phone: +1 (978) 244-8000
Le Faucheur et. al 51 Phone: +1 (978) 244-8000
Email: bsd@cisco.com EMail: bsd@cisco.com
Shahram Davari Shahram Davari
PMC-Sierra Inc. PMC-Sierra Inc.
411 Legget Drive 411 Legget Drive
Kanata, Ontario K2K 3C9 Kanata, Ontario K2K 3C9
Canada Canada
Phone: +1 (613) 271-4018
Email: davari@ieee.org
Phone: +1 (613) 271-4018
EMail: davari@ieee.org
Pasi Vaananen Pasi Vaananen
Nokia Nokia
3 Burlington Woods Drive, Suit 250 3 Burlington Woods Drive, Suit 250
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone +1 (781) 238-4981
Email: pasi.vaananen@nokia.com Phone +1 (781) 993-4900
EMail: pasi.vaananen@nokia.com
Ram Krishnan Ram Krishnan
Axiowave Networks Axiowave Networks
100 Nickerson Road 200 Nickerson Road
Marlboro, MA 01752 Marlboro, MA 01752
ram@axiowave.com
EMail: ram@axiowave.com
Pierrick Cheval Pierrick Cheval
Alcatel Alcatel
5 rue Noel-Pons 5 rue Noel-Pons
92734 Nanterre Cedex 92737 Nanterre Cedex
France France
E-mail:pierrick.cheval@alcatel.fr EMail: pierrick.cheval@space.alcatel.fr
Juha Heinanen Juha Heinanen
Telia Finland Song Networks, Inc.
E-mail: jh@lohi.eng.telia.fi Hallituskatu 16
33200 Tampere, Finland
EMail: jh@song.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
Le Faucheur et. al 52
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Le Faucheur et. al 53 Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 428 change blocks. 
1315 lines changed or deleted 1433 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/