the "generic encapsulation" method as recommended in [MPLS_FR].
Operations without the "generic encapsulation" are outside the scope
of this specification.
10. IANA Considerations
This document defines a number of objects with implications for IANA.
This document defines in section 5.2 a new RSVP object, the DIFFSERV
object. This object required a number from the space defined in
[RSVP] for those objects which, if not understood, cause the entire
RSVP message to be rejected with an error code of "Unknown Object
Class". Such objects are identified by a zero in the most
significant bit of the class number. Within that space, this object
required a number from the "IETF Consensus" space. "65" has been
allocated by IANA for the DIFFSERV object.
This document defines in section 5.5 a new RSVP error code, "Diffserv
Error". Error code "27" has been assigned by IANA to the "Diffserv
Error". This document defines values 1 through 5 of the value field
to be used within the ERROR_SPEC object for this error code. Future
allocations of values in this space should be handled by IANA using
the First Come First Served policy defined in [IANA].
This document defines in section 6.1 a new LDP TLV, the Diffserv TLV.
The number for this TLV has been assigned by working group consensus
according to the policies defined in [LDP].
This document defines in section 6.2 five new LDP Status Code values
for Diffserv-related error conditions. The values for the Status
Code have been assigned by working group consensus according to the
policies defined in [LDP].
11. Security Considerations
This document does not introduce any new security issues beyond those
inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms
proposed for those technologies.
12. Acknowledgments
This document has benefited from discussions with Eric Rosen, Angela
Chiu and Carol Iturralde. It has also borrowed from the work done by
D. Black regarding Diff-Serv and IP Tunnels interaction.
APPENDIX A. Example Deployment Scenarios
This section does not provide additional specification and is only
here to provide examples of how this flexible approach for Diff-Serv
support over MPLS may be deployed. Pros and cons of various
deployment options for particular environments are beyond the scope
of this document.
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS
Protection
A Service Provider running 8 (or fewer) BAs over MPLS, not performing
Traffic engineering, not using MPLS protection and using MPLS Shim
Header encapsulation in his/her network, may elect to run Diff-Serv
over MPLS using a single E-LSP per FEC established via LDP.
Furthermore the Service Provider may elect to use the preconfigured
`EXP<-->PHB mapping'.
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
(e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (e.g., bandwidth
allocated to AF1) and the dropping behavior for each PHB (e.g.,
drop profile for AF11, AF12, AF13)
- LSRs signal establishment of a single E-LSP per FEC using LDP in
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
Protection
A Service Provider running more than 8 BAs over MPLS, not performing
Traffic Engineering, not using MPLS protection and using MPLS Shim
encapsulation in his/her network may elect to run Diff-Serv over MPLS
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 L-LSP per <FEC,OA> established via LDP for support of the
other BAs.
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).
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering,
Aggregate MPLS Protection
A Service Provider running 8 (or fewer) BAs over MPLS, performing
aggregate Traffic Engineering (i.e., performing a single common path
selection for all BAs), using aggregate MPLS protection (i.e.,
restoring service to all PSCs jointly) and using MPLS Shim Header
encapsulation in his/her network, may elect to run Diff-Serv over
MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE]
or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping.
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
(e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (e.g., bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop
profile for AF11, AF12, AF13)
- LSRs signal establishment of a single E-LSP per FEC which will use
the preconfigured mapping:
* using the RSVP protocol as specified above (i.e., no DIFFSERV
RSVP Object in the PATH message containing the LABEL_REQUEST
Object), OR
* 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 Service Provider running any number of BAs over MPLS, performing
per-OA Traffic Engineering (i.e., performing a separate path
selection for each OA) and performing per-OA MPLS protection (i.e.,
performing protection with potentially different levels of protection
for the different OAs) in his/her network, may elect to run Diff-Serv
over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or
CR-LDP.
Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (e.g., bandwidth
allocated to AF1) and the dropping behavior for each PHB (e.g.,
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
* 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
Protection
A Service Provider running 8 (or fewer) BAs over MPLS, performing
per-OA Traffic Engineering (i.e., performing a separate path
selection for each OA) and performing per-OA MPLS protection (i.e.,
performing protection with potentially different levels of protection
for the different OAs) in his/her network, may elect to run Diff-Serv
over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or
CR-LDP. Furthermore, the Service Provider may elect to use the
preconfigured mapping on all the E-LSPs.
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
(e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (e.g., bandwidth
allocated to AF1) and the dropping behavior for each PHB (eg drop
profile for AF11, AF12, AF13)
- LSRs signal establishment of one E-LSP per <FEC,OA>:
* using the RSVP protocol as specified above to signal that the
LSP is an E-LSP which uses the preconfigured mapping (i.e., no
DIFFSERV RSVP Object in the PATH message containing the
LABEL_REQUEST), OR
* using the CR-LDP protocol as specified above to signal that the
LSP is an E-LSP which uses the preconfigured mapping (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- the Service Provider configures, for each E-LSP, at the head-end
of that E-LSP, a filtering/forwarding criteria so that only the
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
Traffic Engineering/MPLS Protection on other BAs.
A Service Provider not performing Traffic Engineering/MPLS Protection
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:
- 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:
- the Service Provider configures at every LSR the bi-directional
mapping between each PHB and a value of the EXP field for the BAs
supported 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 non-
traffic engineered BAs using LDP as specified above (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other
BAs:
* using the RSVP protocol as specified above to signal the L-LSP
PSC (i.e., DIFFSERV RSVP Object in the PATH message containing
the LABEL_REQUEST Object), 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).
- 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
Protection
A Service Provider running more than 8 BAs over MPLS, not performing
Traffic engineering, not performing MPLS protection and using MPLS
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 using
signaled `EXP<-->PHB mapping'.
Operations can be summarized as follows:
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC (e.g., bandwidth
allocated to AF1) and the dropping behavior for each PHB (e.g.,
drop profile for AF11, AF12, AF13)
- LSRs signal establishment of two E-LSPs per FEC using LDP in
accordance with the specification above (i.e., Diff-Serv TLV in
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
B.1 Scenario 1: No Bandwidth Reservation
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 Shortest Path Routing used for all the Diff-Serv traffic.
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
signaled bandwidth.
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
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,...)
- use L-LSPs
- 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.
The bandwidth signaled at L-LSP establishment would be used by LSRs
to perform admission control at every hop to ensure that the
constraint on availability of bandwidth for the relevant PSC is met.
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
per-PSC Resource Adjustment
Consider the case where a network administrator elects to:
- use L-LSPs
- 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.
- have Diff-Serv resources dynamically adjusted
In that case, L-LSPs would be established with signaled bandwidth.
The bandwidth signaled at L-LSP establishment would be used by LSRs
to attempt to adjust the resources allocated to the relevant PSC
(e.g., scheduling weight) and then perform admission control to
ensure that the constraint on availability of bandwidth for the
relevant PSC is met after the adjustment.
References
[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating
IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992,
802.11c-1998, and P802.12e).
[ATMF_TM] ATM Forum, "Traffic Management Specification Version
4.1", March 1999.
[CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and
R. Dantu, "Constraint-Based LSP Setup using LDP",
RFC3212, January 2002.
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J.
Wroclawski, "Assured Forwarding PHB Group", RFC
2597, June 1999.
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J.,
Benson, K., Boudec, J., Chiu, A., Courtney, W.,
Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam,
K. and D. Stiliadis, "An Expedited Forwarding PHB
(Per-Hop Behavior)", RFC3246, March 2002.
[DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC2474,
December 1998.
[DIFF_NEW] Grossman, D., "New Terminology and Clarifications
for Diffserv", RFC3260, April 2002.
[DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels",
RFC2983, October 2000.
[ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC3168, September 2001.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC2434, October 1998.
[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
Edition (Revision and redesignation of ISO/IEC
10038:98.
[LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC3036,
January 2001.
[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using
LDP and ATM VC Switching", RFC3035, January 2001.
[MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T. and A. Conta, "MPLS Label
Stack Encoding", RFC3032, January 2001.
[MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC3034, January 2001.
[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification
of the Null Service Type", RFC2997, November 2000.
[PHBID] Black, D., Brim, S., Carpenter, B. and F. Le
Faucheur, "Per Hop Behavior Identification Codes"
RFC3140, June 2001.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -
Version 1 Functional Specification", RFC2205,
September 1997.
[RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "Extensions to RSVP
for LSP Tunnels", RFC3209, December 2001.
Authors' Addresses
Francois Le Faucheur
Cisco Systems
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Liwen Wu
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
USA
Phone: +1 (408) 853-4065
EMail: liwwu@cisco.com
Bruce Davie
Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
USA
Phone: +1 (978) 244-8000
EMail: bsd@cisco.com
Shahram Davari
PMC-Sierra Inc.
411 Legget Drive
Kanata, Ontario K2K 3C9
Canada
Phone: +1 (613) 271-4018
EMail: davari@ieee.org
Pasi Vaananen
Nokia
3 Burlington Woods Drive, Suit 250
Burlington, MA 01803
USA
Phone +1 (781) 993-4900
EMail: pasi.vaananen@nokia.com
Ram Krishnan
Axiowave Networks
200 Nickerson Road
Marlboro, MA 01752
EMail: ram@axiowave.com
Pierrick Cheval
Alcatel
5 rue Noel-Pons
92737 Nanterre Cedex
France
EMail: pierrick.cheval@space.alcatel.fr
Juha Heinanen
Song Networks, Inc.
Hallituskatu 16
33200 Tampere, Finland
EMail: jh@song.fi
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.