GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4124

Network Working Group F. Le Faucheur, Ed. Request for Comments: 4124 Cisco Systems, Inc. Category: Standards Track June 2005

                Protocol Extensions for Support of
              Diffserv-aware MPLS Traffic Engineering

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document specifies the protocol extensions for support of
 Diffserv-aware MPLS Traffic Engineering (DS-TE).  This includes
 generalization of the semantics of a number of Interior Gateway
 Protocol (IGP) extensions already defined for existing MPLS Traffic
 Engineering in RFC 3630, RFC 3784, and additional IGP extensions
 beyond those.  This also includes extensions to RSVP-TE signaling
 beyond those already specified in RFC 3209 for existing MPLS Traffic
 Engineering.  These extensions address the requirements for DS-TE
 spelled out in RFC 3564.

Table of Contents

 1. Introduction ....................................................3
    1.1. Specification of Requirements ..............................3
 2. Contributing Authors ............................................4
 3. Definitions .....................................................5
 4. Configurable Parameters .........................................5
    4.1. Link Parameters ............................................5
         4.1.1. Bandwidth Constraints (BCs) .........................5
         4.1.2. Overbooking .........................................6
    4.2. LSR Parameters .............................................7
         4.2.1. TE-Class Mapping ....................................7
    4.3. LSP Parameters .............................................8
         4.3.1. Class-Type ..........................................8
         4.3.2. Setup and Holding Preemption Priorities .............8
         4.3.3. Class-Type/Preemption Relationship ..................8

Le Faucheur Standards Track [Page 1] RFC 4124 Protocols for Diffserv-aware TE June 2005

    4.4. Examples of Parameters Configuration .......................9
         4.4.1. Example 1 ...........................................9
         4.4.2. Example 2 ...........................................9
         4.4.3. Example 3 ..........................................10
         4.4.4. Example 4 ..........................................11
         4.4.5. Example 5 ..........................................11
 5. IGP Extensions for DS-TE .......................................12
    5.1. Bandwidth Constraints .....................................12
    5.2. Unreserved Bandwidth ......................................14
 6. RSVP-TE Extensions for DS-TE ...................................15
    6.1. DS-TE-Related RSVP Messages Format ........................15
         6.1.1. Path Message Format ................................16
    6.2. CLASSTYPE Object ..........................................16
         6.2.1. CLASSTYPE object ...................................16
    6.3. Handling CLASSTYPE Object .................................17
    6.4. Non-support of the CLASSTYPE Object .......................20
    6.5. Error Codes for Diffserv-aware TE .........................20
 7. DS-TE Support with MPLS Extensions .............................21
    7.1. DS-TE Support and References to Preemption Priority .......22
    7.2. DS-TE Support and References to Maximum Reservable
         Bandwidth .................................................22
 8. Constraint-Based Routing .......................................22
 9. Diffserv Scheduling ............................................23
 10. Existing TE as a Particular Case of DS-TE .....................23
 11. Computing "Unreserved TE-Class [i]" and Admission
     Control Rules .................................................23
     11.1. Computing "Unreserved TE-Class [i]" .....................23
     11.2. Admission Control Rules .................................24
 12. Security Considerations .......................................24
 13. IANA Considerations ...........................................25
     13.1. A New Name Space for Bandwidth Constraints Model
           Identifiers .............................................25
     13.2. A New Name Space for Error Values under the
           "Diffserv-aware TE ......................................25
     13.3. Assignments Made in This Document .......................26
           13.3.1. Bandwidth Constraints sub-TLV for
                   OSPF Version 2 ..................................26
           13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
           13.3.3. CLASSTYPE Object for RSVP .......................26
           13.3.4. "Diffserv-aware TE Error" Error Code ............27
           13.3.5. Error Values for "Diffserv-aware TE Error" ......27
 14. Acknowledgements ..............................................28
 Appendix A: Prediction for Multiple Path Computation ..............29
 Appendix B: Solution Evaluation ...................................29
 Appendix C: Interoperability with non DS-TE capable LSRs ..........31
 Normative References ..............................................34
 Informative References ............................................35

Le Faucheur Standards Track [Page 2] RFC 4124 Protocols for Diffserv-aware TE June 2005

1. Introduction

 [DSTE-REQ] presents the Service Provider requirements for support of
 Differentiated-Service (Diffserv)-aware MPLS Traffic Engineering
 (DS-TE).  This includes the fundamental requirement to be able to
 enforce different bandwidth constraints for different classes of
 traffic.
 This document specifies the IGP and RSVP-TE signaling extensions
 (beyond those already specified for existing MPLS Traffic Engineering
 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements
 spelled out in [DSTE-REQ] including environments relying on
 distributed Constraint-Based Routing (e.g., path computation
 involving head-end Label Switching Routers).
 [DSTE-REQ] provides a definition and examples of Bandwidth
 Constraints models.  The present document does not specify nor assume
 a particular Bandwidth Constraints model.  Specific Bandwidth
 Constraints models are outside the scope of this document.  Although
 the extensions for DS-TE specified in this document may not be
 sufficient to support all the conceivable Bandwidth Constraints
 models, they do support the Russian Dolls Model specified in
 [DSTE-RDM], the Maximum Allocation Model specified in [DSTE-MAM], and
 the Maximum Allocation with Reservation Model specified in
 [DSTE-MAR].
 There may be differences between the quality of service expressed and
 obtained with Diffserv without DS-TE and with DS-TE.  Because DS-TE
 uses Constraint-Based Routing, and because of the type of admission
 control capabilities it adds to Diffserv, DS-TE has capabilities for
 traffic that Diffserv does not:  Diffserv does not indicate
 preemption, by intent, whereas DS-TE describes multiple levels of
 preemption for its Class-Types.  Also, Diffserv does not support any
 means of explicitly controlling overbooking, while DS-TE allows this.
 When considering a complete quality of service environment, with
 Diffserv routers and DS-TE, it is important to consider these
 differences carefully.

1.1. Specification of Requirements

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

Le Faucheur Standards Track [Page 3] RFC 4124 Protocols for Diffserv-aware TE June 2005

2. Contributing Authors

 This document was the collective work of several authors.  The text
 and content were contributed by the editor and the co-authors listed
 below.  (The contact information for the editor appears in the
 Editor's Address section.)
 Jim Boyle                               Kireeti Kompella
 Protocol Driven Networks, Inc.          Juniper Networks, Inc.
 1381 Kildaire Farm Road #288            1194 N. Mathilda Ave.
 Cary, NC 27511, USA                     Sunnyvale, CA 94099
 Phone: (919) 852-5160                   EMail: kireeti@juniper.net
 EMail: jboyle@pdnets.com
 William Townsend                        Thomas D. Nadeau
 Tenor Networks                          Cisco Systems, Inc.
 100 Nagog Park                          250 Apollo Drive
 Acton, MA 01720                         Chelmsford, MA 01824
 Phone: +1-978-264-4900                  Phone: +1-978-244-3051
 EMail: btownsend@tenornetworks.com      EMail: tnadeau@cisco.com
 Darek Skalecki
 Nortel Networks
 3500 Carling Ave,
 Nepean K2H 8E9
 Phone: +1-613-765-2252
 EMail: dareks@nortelnetworks.com

Le Faucheur Standards Track [Page 4] RFC 4124 Protocols for Diffserv-aware TE June 2005

3. Definitions

 For readability, a number of definitions from [DSTE-REQ] are repeated
 here:
 Traffic Trunk:   an aggregation of traffic flows of the same class
                  (i.e., treated equivalently from the DS-TE
                  perspective), which is placed inside a Label
                  Switched Path (LSP).
 Class-Type (CT): the set of Traffic Trunks crossing a link that is
                  governed by a specific set of bandwidth constraints.
                  CT is used for the purposes of link bandwidth
                  allocation, constraint-based routing and admission
                  control.  A given Traffic Trunk belongs to the same
                  CT on all links.
 TE-Class:        A pair of:
                  i.  a Class-Type
                  ii. a preemption priority allowed for that Class-
                  Type.  This means that an LSP transporting a Traffic
                  Trunk from that Class-Type can use that preemption
                  priority as the setup priority, the holding
                  priority, or both.
 Definitions for a number of MPLS terms are not repeated here.  They
 can be found in [MPLS-ARCH].

4. Configurable Parameters

 This section only discusses the differences with the configurable
 parameters supported for MPLS Traffic Engineering as per [TE-REQ],
 [ISIS-TE], [OSPF-TE], and [RSVP-TE].  All other parameters are
 unchanged.

4.1. Link Parameters

4.1.1. Bandwidth Constraints (BCs)

 [DSTE-REQ] states that "Regardless of the Bandwidth Constraints
 Model, the DS-TE solution MUST allow support for up to 8 BCs."
 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter
 is retained, but its semantics is generalized and interpreted as the
 aggregate bandwidth constraint across all Class-Types, so that,
 independently of the Bandwidth Constraints Model in use:

Le Faucheur Standards Track [Page 5] RFC 4124 Protocols for Diffserv-aware TE June 2005

    SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
 where the SUM is across all values of "c" in the range 0 <= c <= 7.
 Additionally, on every link, a DS-TE implementation MUST provide for
 configuration of up to 8 additional link parameters which are the
 eight potential BCs, i.e., BC0, BC1, ... BC7.  The LSR MUST interpret
 these BCs in accordance with the supported Bandwidth Constraints
 Model (i.e., what BC applies to what Class-Type, and how).
 Where the Bandwidth Constraints Model imposes some relationship among
 the values to be configured for these BCs, the LSR MUST enforce those
 at configuration time.  For example, when the Russian Dolls Bandwidth
 Constraints Model ([DSTE-RDM]) is used, the LSR MUST ensure that BCi
 is configured smaller than or equal to BCj, where i is greater than
 j, and ensure that BC0 is equal to the Maximum Reservable Bandwidth.
 As another example, when the Maximum Allocation Model ([DSTE-MAM]) is
 used, the LSR MUST ensure that all BCi are configured smaller or
 equal to the Maximum Reservable Bandwidth.

4.1.2. Overbooking

 DS-TE enables a network administrator to apply different overbooking
 (or underbooking) ratios for different CTs.
 The principal methods to achieve this are the same as those
 historically used in existing TE deployment:
 (i)    To take into account the overbooking/underbooking ratio
        appropriate for the Ordered Aggregate (OA) or CT associated
        with the considered LSP at the time of establishing the
        bandwidth size of a given LSP.  We refer to this method as the
        "LSP Size Overbooking" method.  AND/OR
 (ii)   To take into account the overbooking/underbooking ratio at the
        time of configuring the Maximum Reservable Bandwidth/BCs and
        use values that are larger (overbooking) or smaller
        (underbooking) than those actually supported by the link.  We
        refer to this method as the "Link Size Overbooking" method.
 The "LSP Size Overbooking" and "Link Size Overbooking" methods are
 expected to be sufficient in many DS-TE environments and require no
 additional configurable parameters.  Other overbooking methods may
 involve such additional configurable parameters, but are beyond the
 scope of this document.

Le Faucheur Standards Track [Page 6] RFC 4124 Protocols for Diffserv-aware TE June 2005

4.2. LSR Parameters

4.2.1. TE-Class Mapping

 In line with [DSTE-REQ], the preemption attributes defined in
 [TE-REQ] are retained with DS-TE and applicable within, and across,
 all CTs.  The preemption attributes of setup priority and holding
 priority retain existing semantics, and in particular these semantics
 are not affected by the LSP CT.  This means that if LSP1 contends
 with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher
 setup preemption priority (i.e., lower numerical priority value) than
 LSP2 holding preemption priority, regardless of LSP1 CT and LSP2 CT.
 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the
 Class-Type and preemption level are configured for each of (up to) 8
 TE-Classes.
 This mapping is referred to as :
    TE-Class[i]  <-->  < CTc , preemption p >
 where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
 Two TE-Classes MUST NOT be identical (i.e., have both the same
 Class-Type and the same preemption priority).
 There are no other restrictions on how any of the 8 Class-Types can
 be paired up with any of the 8 preemption priorities to form a TE-
 Class.  In particular, one given preemption priority can be paired up
 with two (or more) different Class-Types to form two (or more) TE-
 Classes.  Similarly, one Class-Type can be paired up with two (or
 more) different preemption priorities to form two (or more) TE-
 Classes.  Also, there is no mandatory ordering relationship between
 the TE-Class index (i.e., "i" above) and the Class-Type (i.e., "c"
 above) or the preemption priority (i.e., "p" above) of the TE-Class.
 Where the network administrator uses less than 8 TE-Classes, the DS-
 TE LSR MUST allow remaining ones to be configured as "Unused".  Note
 that configuring all the 8 TE-Classes as "Unused" effectively results
 in disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor
 even configured, since as described in Section 4.3.3 below, the CT
 and preemption priorities configured for an LSP MUST form one of the
 configured TE-Classes).
 To ensure coherent DS-TE operation, the network administrator MUST
 configure exactly the same TE-Class mapping on all LSRs of the DS-TE
 domain.

Le Faucheur Standards Track [Page 7] RFC 4124 Protocols for Diffserv-aware TE June 2005

 When the TE-Class mapping needs to be modified in the DS-TE domain,
 care ought to be exercised during the transient period of
 reconfiguration during which some DS-TE LSRs may be configured with
 the new TE-Class mapping while others are still configured with the
 old TE-Class mapping.  It is recommended that active tunnels do not
 use any of the TE-Classes that are being modified during such a
 transient reconfiguration period.

4.3. LSP Parameters

4.3.1. Class-Type

 With DS-TE, LSRs MUST support, for every LSP, an additional
 configurable parameter that indicates the Class-Type of the Traffic
 Trunk transported by the LSP.
 There is one and only one Class-Type configured per LSP.
 The configured Class-Type indicates, in accordance with the supported
 Bandwidth Constraints Model, the BCs that MUST be enforced for that
 LSP.

4.3.2. Setup and Holding Preemption Priorities

 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be
 configured with a setup and holding priority, each with a value
 between 0 and 7.

4.3.3. Class-Type/Preemption Relationship

 With DS-TE, the preemption priority configured for the setup priority
 of a given LSP and the Class-Type configured for that LSP MUST be
 such that, together, they form one of the (up to) 8 TE-Classes
 configured in the TE-Class mapping specified in Section 4.2.1 above.
 The preemption priority configured for the holding priority of a
 given LSP and the Class-Type configured for that LSP MUST also be
 such that, together, they form one of the (up to) 8 TE-Classes
 configured in the TE-Class mapping specified in Section 4.2.1 above.
 The LSR MUST enforce these two rules at configuration time.

Le Faucheur Standards Track [Page 8] RFC 4124 Protocols for Diffserv-aware TE June 2005

4.4. Examples of Parameters Configuration

 For illustration purposes, we now present a few examples of how these
 configurable parameters may be used.  All these examples assume that
 different BCs need to be enforced for different sets of Traffic
 Trunks (e.g., for Voice and for Data) so that two or more Class-Types
 need to be used.

4.4.1. Example 1

 The network administrator of a first network using two CTs (CT1 for
 Voice and CT0 for Data) may elect to configure the following TE-Class
 mapping to ensure that Voice LSPs are never driven away from their
 shortest path because of Data LSPs:
      TE-Class[0]  <-->  < CT1 , preemption 0 >
      TE-Class[1]  <-->  < CT0 , preemption 1 >
      TE-Class[i]  <-->  unused, for 2 <= i <= 7
 Voice LSPs would then be configured with:
      CT = CT1, setup priority = 0, holding priority = 0
 Data LSPs would then be configured with:
      CT = CT0, setup priority = 1, holding priority = 1
 A new Voice LSP would then be able to preempt an existing Data LSP in
 case they contend for resources.  A Data LSP would never preempt a
 Voice LSP.  A Voice LSP would never preempt another Voice LSP.  A
 Data LSP would never preempt another Data LSP.

4.4.2. Example 2

 The network administrator of another network may elect to configure
 the following TE-Class mapping in order to optimize global network
 resource utilization by favoring placement of large LSPs closer to
 their shortest path:
      TE-Class[0]  <-->  < CT1 , preemption 0 >
      TE-Class[1]  <-->  < CT0 , preemption 1 >
      TE-Class[2]  <-->  < CT1 , preemption 2 >
      TE-Class[3]  <-->  < CT0 , preemption 3 >
      TE-Class[i]  <-->  unused, for 4 <= i <= 7
 Large-size Voice LSPs could be configured with:
      CT = CT1, setup priority = 0, holding priority = 0
 Large-size Data LSPs could be configured with:
      CT = CT0, setup priority = 1, holding priority = 1

Le Faucheur Standards Track [Page 9] RFC 4124 Protocols for Diffserv-aware TE June 2005

 Small-size Voice LSPs could be configured with:
      CT = CT1, setup priority = 2, holding priority = 2
 Small-size Data LSPs could be configured with:
      CT = CT0, setup priority = 3, holding priority = 3
 A new large-size Voice LSP would then be able to preempt a small-size
 Voice LSP or any Data LSP in case they contend for resources.  A new
 large-size Data LSP would then be able to preempt a small-size Data
 LSP or a small-size Voice LSP in case they contend for resources, but
 it would not be able to preempt a large-size Voice LSP.

4.4.3. Example 3

 The network administrator of another network may elect to configure
 the following TE-Class mapping in order to ensure that Voice LSPs are
 never driven away from their shortest path because of Data LSPs.
 This also achieves some optimization of global network resource
 utilization by favoring placement of large LSPs closer to their
 shortest path:
      TE-Class[0]  <-->  < CT1 , preemption 0 >
      TE-Class[1]  <-->  < CT1 , preemption 1 >
      TE-Class[2]  <-->  < CT0 , preemption 2 >
      TE-Class[3]  <-->  < CT0 , preemption 3 >
      TE-Class[i]  <-->  unused, for 4 <= i <= 7
 Large-size Voice LSPs could be configured with:
      CT = CT1, setup priority = 0, holding priority = 0.
 Small-size Voice LSPs could be configured with:
      CT = CT1, setup priority = 1, holding priority = 1.
 Large-size Data LSPs could be configured with:
      CT = CT0, setup priority = 2, holding priority = 2.
 Small-size Data LSPs could be configured with:
      CT=CT0, setup priority = 3, holding priority = 3.
 A Voice LSP could preempt a Data LSP if they contend for resources.
 A Data LSP would never preempt a Voice LSP.  A large-size Voice LSP
 could preempt a small-size Voice LSP if they contend for resources.
 A large-size Data LSP could preempt a small-size Data LSP if they
 contend for resources.

Le Faucheur Standards Track [Page 10] RFC 4124 Protocols for Diffserv-aware TE June 2005

4.4.4. Example 4

 The network administrator of another network may elect to configure
 the following TE-Class mapping in order to ensure that no preemption
 occurs in the DS-TE domain:
      TE-Class[0]  <-->  < CT1 , preemption 0 >
      TE-Class[1]  <-->  < CT0 , preemption 0 >
      TE-Class[i]  <-->  unused,   for 2 <= i <= 7
 Voice LSPs would then be configured with:
      CT = CT1, setup priority =0, holding priority = 0
 Data LSPs would then be configured with:
      CT = CT0, setup priority = 0, holding priority = 0
 No LSP would then be able to preempt any other LSP.

4.4.5. Example 5

 The network administrator of another network may elect to configure
 the following TE-Class mapping in view of increased network stability
 through a more limited use of preemption:
      TE-Class[0]  <-->  < CT1 , preemption 0 >
      TE-Class[1]  <-->  < CT1 , preemption 1 >
      TE-Class[2]  <-->  < CT0 , preemption 1 >
      TE-Class[3]  <-->  < CT0 , preemption 2 >
      TE-Class[i]  <-->  unused, for 4 <= i <= 7
 Large-size Voice LSPs could be configured with: CT = CT1, setup
      priority = 0, holding priority = 0.
 Small-size Voice LSPs could be configured with: CT = CT1, setup
      priority = 1, holding priority = 0.
 Large-size Data LSPs could be configured with: CT = CT0, setup
      priority = 2, holding priority = 1.
 Small-size Data LSPs could be configured with: CT = CT0, setup
      priority = 2, holding priority = 2.
 A new large-size Voice LSP would be able to preempt a Data LSP in
 case they contend for resources, but it would not be able to preempt
 any Voice LSP even a small-size Voice LSP.

Le Faucheur Standards Track [Page 11] RFC 4124 Protocols for Diffserv-aware TE June 2005

 A new small-size Voice LSP would be able to preempt a small-size Data
 LSP in case they contend for resources, but it would not be able to
 preempt a large-size Data LSP or any Voice LSP.
 A Data LSP would not be able to preempt any other LSP.

5. IGP Extensions for DS-TE

 This section only discusses the differences with the IGP
 advertisement supported for (aggregate) MPLS Traffic Engineering as
 per [OSPF-TE] and [ISIS-TE].  The rest of the IGP advertisement is
 unchanged.

5.1. Bandwidth Constraints

 As detailed above in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7)
 are configurable on any given link.
 With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV
 ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantics so
 that it MUST now be interpreted as the aggregate bandwidth constraint
 across all Class-Types; i.e., SUM (Reserved (CTc)) <= Max Reservable
 Bandwidth, independently of the Bandwidth Constraints Model.
 This document also defines the following new optional sub-TLV to
 advertise the eight potential BCs (BC0 to BC7):
 "Bandwidth Constraints" sub-TLV:
  1. Bandwidth Constraints Model Id (1 octet)
  2. Reserved (3 octets)
  3. Bandwidth Constraints (N x 4 octets)
 Where:
      - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
        sub-TLV type is 17.
  1. With ISIS, the sub-TLV is a sub-TLV of the "extended IS

reachability TLV" and its sub-TLV type is 22.

  1. Bandwidth Constraints Model Id: a 1-octet identifier for the

Bandwidth Constraints Model currently in use by the LSR

        initiating the IGP advertisement.  See the IANA Considerations
        section for assignment of values in this name space.
  1. Reserved: a 3-octet field. This field should be set to zero

by the LSR generating the sub-TLV and should be ignored by the

        LSR receiving the sub-TLV.

Le Faucheur Standards Track [Page 12] RFC 4124 Protocols for Diffserv-aware TE June 2005

  1. Bandwidth Constraints: contains BC0, BC1,… BC(N-1). Each BC

is encoded on 32 bits in IEEE floating point format. The

        units are bytes (not bits!) per second.  Where the configured
        TE-Class mapping and the Bandwidth Constraints model in use
        are such that BCh+1, BCh+2, ...and BC7 are not relevant to any
        of the Class-Types associated with a configured TE-Class, it
        is RECOMMENDED that only the Bandwidth Constraints from BC0 to
        BCh be advertised, in order to minimize the impact on IGP
        scalability.
 All relevant generic TLV encoding rules (including TLV format,
 padding and alignment, as well as IEEE floating point format
 encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this
 new sub-TLV.
 The "Bandwidth Constraints" sub-TLV format is illustrated below:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | BC Model Id   |           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       BC0 value                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       . . .                                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       BCh value                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 A DS-TE LSR MAY optionally advertise BCs.
 A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth
 Constraints" sub-TLV (in addition to the existing Maximum Reservable
 Bandwidth sub-TLV) to do so.  For example, in the case where a
 service provider deploys DS-TE with TE-Classes associated with CT0
 and CT1 only, and where the Bandwidth Constraints Model is such that
 only BC0 and BC1 are relevant to CT0 and CT1, a DS-TE LSR which does
 advertise BCs would include in the IGP advertisement the Maximum
 Reservable Bandwidth sub-TLV, as well as the "Bandwidth Constraints"
 sub-TLV.  The former should contain the aggregate bandwidth
 constraint across all CTs, and the latter should contain BC0 and BC1.
 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
 Bandwidth Constraints Model Id that does not match the Bandwidth
 Constraints Model it currently uses SHOULD generate a warning to the
 operator/management system, reporting the inconsistency between
 Bandwidth Constraints Models used on different links.  Also, in that
 case, if the DS-TE LSR does not support the Bandwidth Constraints

Le Faucheur Standards Track [Page 13] RFC 4124 Protocols for Diffserv-aware TE June 2005

 Model designated by the Bandwidth Constraints Model Id, or if the
 DS-TE LSR does not support operations with multiple simultaneous
 Bandwidth Constraints Models, the DS-TE LSR MAY discard the
 corresponding TLV.  If the DS-TE LSR does support the Bandwidth
 Constraints Model designated by the Bandwidth Constraints Model Id,
 and if the DS-TE LSR does support operations with multiple
 simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept
 the corresponding TLV and allow operations with different Bandwidth
 Constraints Models used in different parts of the DS-TE domain.

5.2. Unreserved Bandwidth

 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained
 as the only vehicle to advertise dynamic bandwidth information
 necessary for Constraint-Based Routing on head-ends, except that it
 is used with a generalized semantics.  The Unreserved Bandwidth sub-
 TLV still carries eight bandwidth values, but they now correspond to
 the unreserved bandwidth for each of the TE-Classes (instead of for
 each preemption priority, as per existing TE).
 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth
 sub-TLV with a definition that is generalized into the following:
 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
 not yet reserved for each of the eight TE-Classes, in IEEE floating
 point format arranged in increasing order of TE-Class index.
 Unreserved bandwidth for TE-Class [0] occurs at the start of the
 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the
 sub-TLV.  The unreserved bandwidth value for TE-Class [i] ( 0 <= i <=
 7) is referred to as "Unreserved TE-Class [i]".  It indicates the
 bandwidth that is available, for reservation, to an LSP that:
  1. transports a Traffic Trunk from the Class-Type of TE-Class[i], and
  1. has a setup priority corresponding to the preemption priority of

TE-Class[i].

 The units are bytes per second.
 Because the bandwidth values are now ordered by TE-class index and
 thus can relate to different CTs with different BCs and to any
 arbitrary preemption priority, a DS-TE LSR MUST NOT assume any
 ordered relationship among these bandwidth values.
 With existing TE, because all preemption priorities reflect the same
 (and only) BCs and bandwidth values are advertised in preemption
 priority order, the following relationship is always true, and is
 often assumed by TE implementations:

Le Faucheur Standards Track [Page 14] RFC 4124 Protocols for Diffserv-aware TE June 2005

    If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
 With DS-TE, no relationship is to be assumed such that:
    If i < j, then any of the following relationships may be true:
              "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
                  OR
              "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
                  OR
              "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
 Rules for computing "Unreserved TE-Class [i]" are specified in
 Section 11.
 If TE-Class[i] is unused, the value advertised by the IGP in
 "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating
 the IGP advertisement, and MUST be ignored by the LSR receiving the
 IGP advertisement.

6. RSVP-TE Extensions for DS-TE

 In this section, we describe extensions to RSVP-TE for support of
 Diffserv-aware MPLS Traffic Engineering.  These extensions are in
 addition to the extensions to RSVP defined in [RSVP-TE] for support
 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP
 defined in [DIFF-MPLS] for support of Diffserv over MPLS.

6.1. DS-TE-Related RSVP Messages Format

 One new RSVP object is defined in this document: the CLASSTYPE
 object.  Detailed description of this object is provided below.  This
 new object is applicable to Path messages.  This specification only
 defines the use of the CLASSTYPE object in Path messages used to
 establish LSP Tunnels in accordance with [RSVP-TE] and thus
 containing a session object with a CT equal to LSP_TUNNEL_IPv4 and
 containing a LABEL_REQUEST object.
 Restrictions defined in [RSVP-TE] for support of establishment of LSP
 Tunnels via RSVP-TE are also applicable to the establishment of LSP
 Tunnels supporting DS-TE.  For instance, only unicast LSPs are
 supported, and multicast LSPs are for further study.
 This new CLASSTYPE object is optional with respect to RSVP so that
 general RSVP implementations not concerned with MPLS LSP setup do not
 have to support this object.
 An LSR supporting DS-TE MUST support the CLASSTYPE object.

Le Faucheur Standards Track [Page 15] RFC 4124 Protocols for Diffserv-aware TE June 2005

6.1.1. Path Message Format

 The format of the Path message is as follows:
 <Path Message> ::=      <Common Header> [ <INTEGRITY> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <EXPLICIT_ROUTE> ]
                         <LABEL_REQUEST>
                         [ <SESSION_ATTRIBUTE> ]
                         [ <DIFFSERV> ]
                         [ <CLASSTYPE> ]
                         [ <POLICY_DATA> ... ]
                         [ <sender descriptor> ]
 <sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                         [ <ADSPEC> ]
                         [ <RECORD_ROUTE> ]

6.2. CLASSTYPE Object

 The CLASSTYPE object Class Name is CLASSTYPE.  Its Class Number is
 66.  Currently, there is only one defined C-Type which is C-Type 1.
 The CLASSTYPE object format is shown below.

6.2.1. CLASSTYPE object

 Class Number = 66
 Class-Type = 1
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Reserved                                         |  CT |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Reserved: 29 bits
     This field is reserved.  It MUST be set to zero on transmission
     and MUST be ignored on receipt.
 CT: 3 bits
     Indicates the Class-Type.  Values currently allowed are
     1, 2, ... , 7.  Value of 0 is Reserved.

Le Faucheur Standards Track [Page 16] RFC 4124 Protocols for Diffserv-aware TE June 2005

6.3. Handling CLASSTYPE Object

 To establish an LSP tunnel with RSVP, the sender LSR creates a Path
 message with a session type of LSP_Tunnel_IPv4 and with a
 LABEL_REQUEST object as per [RSVP-TE].  The sender LSR may also
 include the DIFFSERV object as per [DIFF-MPLS].
 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT
 include the CLASSTYPE object in the Path message.  This allows
 backward compatibility with non-DSTE-configured or non-DSTE-capable
 LSRs as discussed below in Section 10 and Appendix C.
 If the LSP is associated with Class-Type N (1 <= N <=7), the sender
 LSR MUST include the CLASSTYPE object in the Path message with the
 Class-Type (CT) field set to N.
 If a Path message contains multiple CLASSTYPE objects, only the first
 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
 MUST NOT be forwarded.
 Each LSR along the path MUST record the CLASSTYPE object, when it is
 present, in its path state block.
 If the CLASSTYPE object is not present in the Path message, the LSR
 MUST associate the Class-Type 0 to the LSP.
 The destination LSR responding to the Path message by sending a Resv
 message MUST NOT include a CLASSTYPE object in the Resv message
 (whether or not the Path message contained a CLASSTYPE object).
 During establishment of an LSP corresponding to the Class-Type N, the
 LSR MUST perform admission control over the bandwidth available for
 that particular Class-Type.
 An LSR that recognizes the CLASSTYPE object and that receives a Path
 message that:
  1. contains the CLASSTYPE object, but
  1. does not contain a LABEL_REQUEST object or does not have a

session type of LSP_Tunnel_IPv4,

 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "Unexpected CLASSTYPE
 object".  These codes are defined in Section 6.5.

Le Faucheur Standards Track [Page 17] RFC 4124 Protocols for Diffserv-aware TE June 2005

 An LSR receiving a Path message with the CLASSTYPE object that:
  1. recognizes the CLASSTYPE object, but
  1. does not support the particular Class-Type,
 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "Unsupported Class-
 Type".  These codes are defined in Section 6.5.
 An LSR receiving a Path message with the CLASSTYPE object that:
  1. recognizes the CLASSTYPE object, but
  1. determines that the Class-Type value is not valid (i.e.,

Class-Type value 0),

 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "Invalid Class-Type
 value".  These codes are defined in Section 6.5.
 An LSR receiving a Path message with the CLASSTYPE object, which:
  1. recognizes the CLASSTYPE object and
  1. supports the particular Class-Type, but
  1. determines that the tuple formed by (i) this Class-Type and

(ii) the setup priority signaled in the same Path message, is

         not one of the eight TE-Classes configured in the TE-class
         mapping,
 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "CT and setup
 priority do not form a configured TE-Class".  These codes are defined
 in Section 6.5.
 An LSR receiving a Path message with the CLASSTYPE object that:
  1. recognizes the CLASSTYPE object and
  1. supports the particular Class-Type, but
  1. determines that the tuple formed by (i) this Class-Type and

(ii) the holding priority signaled in the same Path message,

         is not one of the eight TE-Classes configured in the TE-class
         mapping,

Le Faucheur Standards Track [Page 18] RFC 4124 Protocols for Diffserv-aware TE June 2005

 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "CT and holding
 priority do not form a configured TE-Class".  These codes are defined
 in Section 6.5.
 An LSR receiving a Path message with the CLASSTYPE object that:
  1. recognizes the CLASSTYPE object and
  1. supports the particular Class-Type, but
  1. determines that the tuple formed by (i) this Class-Type and

(ii) the setup priority signaled in the same Path message, is

         not one of the eight TE-Classes configured in the TE-class
         mapping, AND
  1. determines that the tuple formed by (i) this Class-Type and

(ii) the holding priority signaled in the same Path message,

         is not one of the eight TE-Classes configured in the TE-class
         mapping
 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "CT and setup
 priority do not form a configured TE-Class AND CT and holding
 priority do not form a configured TE-Class".  These codes are defined
 in Section 6.5.
 An LSR receiving a Path message with the CLASSTYPE object and with
 the DIFFSERV object for an L-LSP that:
  1. recognizes the CLASSTYPE object,
  1. has local knowledge of the relationship between Class-Types

and Per Hop Behavior (PHB) Scheduling Class, e.g., via

         configuration, and
  1. determines, based on this local knowledge, that the PHB

Scheduling Class (PSC) signaled in the DIFFSERV object is

         inconsistent with the Class-Type signaled in the CLASSTYPE
         object,
 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "Inconsistency
 between signaled PSC and signaled CT".  These codes are defined below
 in Section 6.5.

Le Faucheur Standards Track [Page 19] RFC 4124 Protocols for Diffserv-aware TE June 2005

 An LSR receiving a Path message with the CLASSTYPE object and with
 the DIFFSERV object for an E-LSP that:
  1. recognizes the CLASSTYPE object,
  1. has local knowledge of the relationship between Class-Types

and PHBs (e.g., via configuration)

  1. determines, based on this local knowledge, that the PHBs

signaled in the MAP entries of the DIFFSERV object are

         inconsistent with the Class-Type signaled in the CLASSTYPE
         object,
 MUST send a PathErr towards the sender with the error code
 "Diffserv-aware TE Error" and an error value of "Inconsistency
 between signaled PHBs and signaled CT".  These codes are defined in
 Section 6.5.
 An LSR MUST handle situations in which the LSP cannot be accepted for
 reasons other than those already discussed in this section, in
 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g., a reservation is
 rejected by admission control, and a label cannot be associated).

6.4. Non-support of the CLASSTYPE Object

 An LSR that does not recognize the CLASSTYPE object Class-Num MUST
 behave in accordance with the procedures specified in [RSVP] for an
 unknown Class-Num whose format is 0bbbbbbb (i.e., it MUST send a
 PathErr with the error code "Unknown object class" toward the
 sender).
 An LSR that recognizes the CLASSTYPE object Class-Num but that does
 not recognize the CLASSTYPE object C-Type, MUST behave in accordance
 with 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"
 toward the sender).
 Both of the above situations cause the path setup to fail.  The
 sender SHOULD notify the operator/management system that an LSP
 cannot be established and might take action to retry reservation
 establishment without the CLASSTYPE object.

6.5. Error Codes for Diffserv-aware TE

 In the procedures described above, certain errors are reported as a
 "Diffserv-aware TE Error".  The value of the "Diffserv-aware TE
 Error" error code is 28.

Le Faucheur Standards Track [Page 20] RFC 4124 Protocols for Diffserv-aware TE June 2005

 The following table defines error values for the Diffserv-aware TE
 Error:
    Value     Error
    1      Unexpected CLASSTYPE object
    2      Unsupported Class-Type
    3      Invalid Class-Type value
    4      Class-Type and setup priority do not form a configured
              TE-Class
    5      Class-Type and holding priority do not form a
              configured TE-Class
    6      Class-Type and setup priority do not form a configured
              TE-Class AND Class-Type and holding priority do not form
           a configured TE-Class
    7      Inconsistency between signaled PSC and signaled
              Class-Type
    8      Inconsistency between signaled PHBs and signaled
              Class-Type
 See the IANA Considerations section for allocation of additional
 values.

7. DS-TE Support with MPLS Extensions

 There are a number of extensions to the initial base specification
 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].
 Those include enhancements for generalization ([GMPLS-SIG] and
 [GMPLS-ROUTE]), as well as for additional functionality, such as LSP
 hierarchy [HIERARCHY], link bundling [BUNDLE], and fast restoration
 [REROUTE].  These specifications may reference how to encode
 information associated with certain preemption priorities, how to
 treat LSPs at different preemption priorities, or they may otherwise
 specify encodings or behavior that have a different meaning for a
 DS-TE router.
 In order for an implementation to support both this specification for
 Diffserv-aware TE and a given MPLS enhancement, such as those listed
 above (but not limited to those), it MUST treat references to
 "preemption priority" and to "Maximum Reservable Bandwidth" in a
 generalized manner, i.e., the manner in which this specification uses
 those terms.
 Additionally, current and future MPLS enhancements may include more
 precise specification for how they interact with Diffserv-aware TE.

Le Faucheur Standards Track [Page 21] RFC 4124 Protocols for Diffserv-aware TE June 2005

7.1. DS-TE Support and References to Preemption Priority

 When a router supports both Diffserv-aware TE and one of the MPLS
 protocol extensions such as those mentioned above, encoding of values
 of preemption priority in signaling or encoding of information
 associated with preemption priorities in IGP defined for the MPLS
 extension, MUST be considered an encoding of the same information for
 the corresponding TE-Class.  For instance, if an MPLS enhancement
 specifies advertisement in IGP of a parameter for routing information
 at preemption priority N, in a DS-TE environment it MUST actually be
 interpreted as specifying advertisement of the same routing
 information but for TE-Class [N].  On receipt, DS-TE routers MUST
 also interpret it as such.
 When there is discussion on how to comparatively treat LSPs of
 different preemption priority, a DS-TE LSR MUST treat the preemption
 priorities in this context as those associated with the TE-Classes of
 the LSPs in question.

7.2. DS-TE Support and References to Maximum Reservable Bandwidth

 When a router supports both Diffserv-aware TE and MPLS protocol
 extensions such as those mentioned above, advertisements of Maximum
 Reservable Bandwidth MUST be done with the generalized interpretation
 defined in Section 4.1.1 as the aggregate bandwidth constraint across
 all Class-Types.  It MAY also allow the optional advertisement of all
 BCs.

8. Constraint-Based Routing

 Let us consider the case where a path needs to be computed for an LSP
 whose Class-Type is configured to CTc and whose setup preemption
 priority is configured to p.
 Then the pair of CTc and p will map to one of the TE-Classes defined
 in the TE-Class mapping.  Let us refer to this TE-Class as TE-
 Class[i].
 The Constraint-Based Routing algorithm of a DS-TE LSR is still only
 required to perform path computation satisfying a single BC which is
 to fit in "Unreserved TE-Class [i]" as advertised by the IGP for
 every link.  Thus, no changes to the existing TE Constraint-Based
 Routing algorithm itself are required.
 The Constraint-Based Routing algorithm MAY also take into account,
 when used, the optional additional information advertised in IGP such
 as the BCs and the Maximum Reservable Bandwidth.  For example, the

Le Faucheur Standards Track [Page 22] RFC 4124 Protocols for Diffserv-aware TE June 2005

 BCs MIGHT be used as tie-breaker criteria in situations where
 multiple paths, otherwise equally attractive, are possible.

9. Diffserv Scheduling

 The Class-Type signaled at LSP establishment MAY optionally be used
 by DS-TE LSRs to dynamically adjust the resources allocated to the
 Class-Type by the Diffserv scheduler.  In addition, the Diffserv
 information (i.e., the PSC) signaled by the TE-LSP signaling
 protocols as specified in [DIFF-MPLS], if used, MAY optionally be
 used by DS-TE LSRs to dynamically adjust the resources allocated by
 the Diffserv scheduler to a PSC/OA within a CT.

10. Existing TE as a Particular Case of DS-TE

 We observe that existing TE can be viewed as a particular case of
 DS-TE where:
    (i)   a single Class-Type is used,
    (ii)  all 8 preemption priorities are allowed for that Class-Type,
          and
    (iii) the following TE-Class mapping is used:
                TE-Class[i]  <-->  < CT0 , preemption i >
                Where 0 <= i <= 7.
 In that case, DS-TE behaves as existing TE.
 As with existing TE, the IGP advertises:
      - Unreserved Bandwidth for each of the 8 preemption priorities.
 As with existing TE, the IGP may advertise:
      - Maximum Reservable Bandwidth containing a BC applying across
        all LSPs .
 Because all LSPs transport traffic from CT0, RSVP-TE signaling is
 done without explicit signaling of the Class-Type (which is only used
 for Class-Types other than CT0, as explained in Section 6) as with
 existing TE.

11. Computing "Unreserved TE-Class [i]" and Admission Control Rules

11.1. Computing "Unreserved TE-Class [i]"

 We first observe that, for existing TE, details on admission control
 algorithms for TE LSPs, and consequently details on formulas for
 computing the unreserved bandwidth, are outside the scope of the
 current IETF work.  This is left for vendor differentiation.  Note
 that this does not compromise interoperability across various

Le Faucheur Standards Track [Page 23] RFC 4124 Protocols for Diffserv-aware TE June 2005

 implementations because the TE schemes rely on LSRs to advertise
 their local view of the world in terms of Unreserved Bw to other
 LSRs.  This way, regardless of the actual local admission control
 algorithm used on one given LSR, Constraint-Based Routing on other
 LSRs can rely on advertised information to determine whether an
 additional LSP will be accepted or rejected by the given LSR.  The
 only requirement is that an LSR advertises unreserved bandwidth
 values that are consistent with its specific local admission control
 algorithm and take into account the holding preemption priority of
 established LSPs.
 In the context of DS-TE, again, details on admission control
 algorithms are left for vendor differentiation, and formulas for
 computing the unreserved bandwidth for TE-Class[i] are outside the
 scope of this specification.  However, DS-TE places the additional
 requirement on the LSR that the unreserved bandwidth values
 advertised MUST reflect all the BCs relevant to the CT associated
 with TE-Class[i] in accordance with the Bandwidth Constraints Model.
 Thus, formulas for computing "Unreserved TE-Class [i]" depend on the
 Bandwidth Constraints Model in use and MUST reflect how BCs apply to
 CTs.  Example formulas for computing "Unreserved TE-Class [i]" Model
 are provided for the Russian Dolls Model and Maximum Allocation Model
 respectively in [DSTE-RDM] and [DSTE-MAM].
 As with existing TE, DS-TE LSRs MUST consider the holding preemption
 priority of established LSPs (as opposed to their setup preemption
 priority) for the purpose of computing the unreserved bandwidth for
 TE-Class [i].

11.2. Admission Control Rules

 A DS-TE LSR MUST support the following admission control rule:
 Regardless of how the admission control algorithm actually computes
 the unreserved bandwidth for TE-Class[i] for one of its local links,
 an LSP of bandwidth B, of setup preemption priority p and of Class-
 Type CTc is admissible on that link if, and only if,:
      B <= Unreserved Bandwidth for TE-Class[i]
 where TE-Class [i] maps to  < CTc , p > in the TE-Class mapping
 configured on the LSR.

12. Security Considerations

 This document does not introduce additional security threats beyond
 those described for Diffserv ([DIFF-ARCH]) and MPLS Traffic
 Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same

Le Faucheur Standards Track [Page 24] RFC 4124 Protocols for Diffserv-aware TE June 2005

 security measures and procedures described in these documents apply
 here.  For example, the approach for defense against theft- and
 denial-of-service attacks discussed in [DIFF-ARCH], which consists of
 the combination of traffic conditioning at DS boundary nodes along
 with security and integrity of the network infrastructure within a
 Diffserv domain, may be followed when DS-TE is in use.  Also, as
 stated in [TE-REQ], it is specifically important that manipulation of
 administratively configurable parameters (such as those related to
 DS-TE LSPs) be executed in a secure manner by authorized entities.

13. IANA Considerations

 This document creates two new name spaces that are to be managed by
 IANA.  Also, a number of assignments from existing name spaces have
 been made by IANA in this document.  They are discussed below.

13.1. A New Name Space for Bandwidth Constraints Model Identifiers

 This document defines in Section 5.1 a "Bandwidth Constraints Model
 Id" field (name space) within the "Bandwidth Constraints" sub-TLV,
 both for OSPF and ISIS.  The new name space has been created by the
 IANA and they will maintain this new name space.  The field for this
 namespace is 1 octet, and IANA guidelines for assignments for this
 field are as follows:
       o values in the range 0-239 are to be assigned according to the
         "Specification Required" policy defined in [IANA-CONS].
       o values in the range 240-255 are reserved for "Private Use" as
         defined in [IANA-CONS].

13.2. A New Name Space for Error Values under the "Diffserv-aware TE

     Error"
 An Error Code is an 8-bit quantity defined in [RSVP] that appears in
 an ERROR_SPEC object to define an error condition broadly.  With each
 Error Code there may be a 16-bit Error Value (which depends on the
 Error Code) that further specifies the cause of the error.
 This document defines in Section 6.5 a new RSVP error code, the
 "Diffserv-aware TE Error" (see Section 13.3.4).  The Error Values for
 the "Diffserv-aware TE Error" constitute a new name space to be
 managed by IANA.
 This document defines, in Section 6.5, values 1 through 7 in that
 name space (see Section 13.3.5).

Le Faucheur Standards Track [Page 25] RFC 4124 Protocols for Diffserv-aware TE June 2005

 Future allocations of values in this name space are to be assigned by
 IANA using the "Specification Required" policy defined in
 [IANA-CONS].

13.3. Assignments Made in This Document

13.3.1. Bandwidth Constraints sub-TLV for OSPF Version 2

 [OSPF-TE] creates a name space for the sub-TLV types within the "Link
 TLV" of the Traffic Engineering Link State Advertisement (LSA) and
 rules for management of this name space by IANA.
 This document defines in Section 5.1 a new sub-TLV, the "Bandwidth
 Constraints" sub-TLV, for the OSPF "Link" TLV.  In accordance with
 the IANA considerations provided in [OSPF-TE], a sub-TLV type in the
 range 10 to 32767 was requested, and the value 17 has been assigned
 by IANA for the "Bandwidth Constraints" sub-TLV.

13.3.2. Bandwidth Constraints sub-TLV for ISIS

 [ISIS-TE] creates a name space for the sub-TLV types within the ISIS
 "Extended IS Reachability" TLV and rules for management of this name
 space by IANA.
 This document defines in Section 5.1 a new sub-TLV, the "Bandwidth
 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV.
 In accordance with the IANA considerations provided in [ISIS-TE], a
 sub-TLV type was requested, and the value 22 has been assigned by
 IANA for the "Bandwidth Constraints" sub-TLV.

13.3.3. CLASSTYPE Object for RSVP

 [RSVP] defines the Class Number name space for RSVP object, which is
 managed by IANA.  Currently allocated Class Numbers are listed at
 http://www.iana.org/assignments/rsvp-parameters.
 This document defines in Section 6.2.1 a new RSVP object, the
 CLASSTYPE object.  IANA has assigned a Class Number for this RSVP
 object from the range defined in Section 3.10 of [RSVP] for objects
 that, 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
 (i.e., Class-Num = 0bbbbbbb).
 IANA assigned Class-Number 66 to the CLASSTYPE object.  C_Type 1 is
 defined in this document for the CLASSTYPE object.

Le Faucheur Standards Track [Page 26] RFC 4124 Protocols for Diffserv-aware TE June 2005

13.3.4. "Diffserv-aware TE Error" Error Code

 [RSVP] defines the Error Code name space and rules for management of
 this name space by IANA.  Currently allocated Error Codes are listed
 at http://www.iana.org/assignments/rsvp-parameters.
 This document defines in Section 6.5 a new RSVP Error Code, the
 "Diffserv-aware TE Error".  In accordance with the IANA
 considerations provided in [RSVP], Error Code 28 was assigned by IANA
 to the "Diffserv-aware TE Error".

13.3.5. Error Values for "Diffserv-aware TE Error"

 An Error Code is an 8-bit quantity defined in [RSVP] that appears in
 an ERROR_SPEC object to define an error condition broadly.  With each
 Error Code there may be a 16-bit Error Value (which depends on the
 Error Code) that further specifies the cause of the error.
 This document defines in Section 6.5 a new RSVP error code, the
 "Diffserv-aware TE Error" (see Section 13.3.4).  The Error Values for
 the "Diffserv-aware TE Error" constitute a new name space to be
 managed by IANA.
 This document defines, in Section 6.5, the following Error Values for
 the "Diffserv-aware TE Error":
    Value     Error
    1      Unexpected CLASSTYPE object
    2      Unsupported Class-Type
    3      Invalid Class-Type value
    4      Class-Type and setup priority do not form a configured
              TE-Class
    5      Class-Type and holding priority do not form a configured
              TE-Class
    6      Class-Type and setup priority do not form a configured
              TE-Class AND Class-Type and holding priority do not
              form a configured TE-Class
    7      Inconsistency between signaled PSC and signaled
              Class-Type
    8      Inconsistency between signaled PHBs and signaled
              Class-Type
 See Section 13.2 for allocation of other values in that name space.

Le Faucheur Standards Track [Page 27] RFC 4124 Protocols for Diffserv-aware TE June 2005

14. Acknowledgements

 We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier
 contribution in this work.  We also thank Sanjaya Choudhury for his
 thorough review and suggestions.

Le Faucheur Standards Track [Page 28] RFC 4124 Protocols for Diffserv-aware TE June 2005

Appendix A: Prediction for Multiple Path Computation

 There are situations where a head-end needs to compute paths for
 multiple LSPs over a short period of time.  There are potential
 advantages for the head-end in trying to predict the impact of the
 n-th LSP on the unreserved bandwidth when computing the path for the
 (n+1)-th LSP, before receiving updated IGP information.  For example,
 better load-distribution of the multiple LSPs would be performed
 across multiple paths.  Also, when the (n+1)-th LSP would no longer
 fit on a link after establishment of the n-th LSP, the head-end would
 avoid Connection Admission Control (CAC) rejection.  Although there
 are a number of conceivable scenarios where worse situations might
 result, doing such predictions is more likely to improve situations.
 As a matter of fact, a number of network administrators have elected
 to use such predictions when deploying existing TE.
 Such predictions are local matters, are optional, and are outside the
 scope of this specification.
 Where such predictions are not used, the optional BC sub-TLV and the
 optional Maximum Reservable Bandwidth sub-TLV need not be advertised
 in IGP for the purpose of path computation, since the information
 contained in the Unreserved Bw sub-TLV is all that is required by
 Head-Ends to perform Constraint-Based Routing.
 Where such predictions are used on head-ends, the optional BCs sub-
 TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be
 advertised in IGP.  This is in order for the head-ends to predict as
 accurately as possible how an LSP affects unreserved bandwidth values
 for subsequent LSPs.
 Remembering that actual admission control algorithms are left for
 vendor differentiation, we observe that predictions can only be
 performed effectively when the head-end LSR predictions are based on
 the same (or a very close) admission control algorithm as that used
 by other LSRs.

Appendix B: Solution Evaluation

B.1. Satisfying Detailed Requirements

 This DS-TE Solution addresses all the scenarios presented in
 [DSTE-REQ].
 It also satisfies all the detailed requirements presented in
 [DSTE-REQ].

Le Faucheur Standards Track [Page 29] RFC 4124 Protocols for Diffserv-aware TE June 2005

 The objective set out in the last paragraph of Section 4.7 of
 [DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE
 solution.  Through support of the "LSP size Overbooking" and "Link
 Size Overbooking" methods, this DS-TE solution effectively allows CTs
 to have different overbooking ratios and simultaneously allows
 overbooking to be tweaked differently (collectively across all CTs)
 on different links.  But, in a general sense, it does not allow the
 effective overbooking ratio of every CT to be tweaked differently in
 different parts of the network independently of other CTs, while
 maintaining accurate bandwidth accounting of how different CTs
 mutually affect each other through shared BCs (such as the Maximum
 Reservable Bandwidth).

B.2. Flexibility

 This DS-TE solution supports 8 CTs.  It is entirely flexible as to
 how Traffic Trunks are grouped together into a CT.

B.3. Extendibility

 A maximum of 8 CTs is considered more than comfortable by the authors
 of this document.  A maximum of 8 TE-Classes is considered sufficient
 by the authors of this document.  However, this solution could be
 extended to support more CTs or more TE-Classes if deemed necessary
 in the future; this would necessitate additional IGP extensions
 beyond those specified in this document.
 Although the prime objective of this solution is support of
 Diffserv-aware Traffic Engineering, its mechanisms are not tightly
 coupled with Diffserv.  This makes the solution amenable, or more
 easily extendable, for support of potential other future Traffic
 Engineering applications.

B.4. Scalability

 This DS-TE solution is expected to have a very small scalability
 impact compared to that of existing TE.
 From an IGP viewpoint, the amount of mandatory information to be
 advertised is identical to that of existing TE.  One additional sub-
 TLV has been specified, but its use is optional, and it only contains
 a limited amount of static information (at most 8 BCs).
 We expect no noticeable impact on LSP Path computation because, as
 with existing TE, this solution only requires Constrained Shortest
 Path First (CSPF) to consider a single unreserved bandwidth value for
 any given LSP.

Le Faucheur Standards Track [Page 30] RFC 4124 Protocols for Diffserv-aware TE June 2005

 From a signaling viewpoint, we expect no significant impact due to
 this solution because it only requires processing of one additional
 item of information (the Class-Type) and does not significantly
 increase the likelihood of CAC rejection.  Note that DS-TE has some
 inherent impact on LSP signaling in that it assumes that different
 classes of traffic are split over different LSPs so that more LSPs
 need to be signaled.  However, this is due to the DS-TE concept
 itself and not to the actual DS-TE solution discussed here.

B.5. Backward Compatibility/Migration

 This solution is expected to allow smooth migration from existing TE
 to DS-TE.  This is because existing TE can be supported as a
 particular configuration of DS-TE.  This means that an "upgraded" LSR
 with a DS-TE implementation can directly interwork with an "old" LSR
 supporting existing TE only.
 This solution is expected to allow smooth migration when the number
 of CTs actually deployed is increased, as it only requires
 configuration changes.  However, these changes need to be performed
 in a coordinated manner across the DS-TE domain.

Appendix C: Interoperability with Non-DS-TE Capable LSRs

 This DSTE solution allows operations in a hybrid network where some
 LSRs are DS-TE capable and some are not, as may occur during
 migration phases.  This appendix discusses the constraints and
 operations in such hybrid networks.
 We refer to the set of DS-TE-capable LSRs as the DS-TE domain.  We
 refer to the set of non-DS-TE-capable (but TE-capable) LSRs as the
 TE-domain.
 Hybrid operations require that the TE-Class mapping in the DS-TE
 domain be configured so that:
  1. a TE-Class exists for CT0 for every preemption priority

actually used in the TE domain, and

  1. the index in the TE-class mapping for each of these TE-

Classes is equal to the preemption priority.

Le Faucheur Standards Track [Page 31] RFC 4124 Protocols for Diffserv-aware TE June 2005

 For example, imagine the TE domain uses preemption 2 and 3.  Then,
 DS-TE can be deployed in the same network by including the following
 TE-Classes in the TE-Class mapping:
         i   <--->       CT      preemption
       ====================================
         2               CT0     2
         3               CT0     3
 Another way to look at this is to say that although the whole TE-
 class mapping does not have to be consistent with the TE domain, the
 subset of this TE-Class mapping applicable to CT0 effectively has to
 be consistent with the TE domain.
 Hybrid operations also require that:
  1. non-DS-TE-capable LSRs be configured to advertise the Maximum

Reservable Bandwidth, and

  1. DS-TE-capable LSRs be configured to advertise BCs (using the

Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV,

         as specified in Section 5.1).
 This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs
 unambiguously.
 Finally, hybrid operations require that non-DS-TE-capable LSRs be
 able to accept Unreserved Bw sub-TLVs containing non decreasing
 bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p <
 q).
 In such hybrid networks, the following apply:
  1. CT0 LSPs can be established by both DS-TE-capable LSRs and

non-DS-TE-capable LSRs.

  1. CT0 LSPs can transit via (or terminate at) both DS-TE-capable

LSRs and non-DS-TE-capable LSRs.

  1. LSPs from other CTs can only be established by DS-TE-capable

LSRs.

  1. LSPs from other CTs can only transit via (or terminate at)

DS-TE-capable LSRs.

Le Faucheur Standards Track [Page 32] RFC 4124 Protocols for Diffserv-aware TE June 2005

 Let us consider the following example to illustrate operations:
    LSR0--------LSR1----------LSR2
         Link01       Link12
    where:
       LSR0 is a non-DS-TE-capable LSR
       LSR1 and LSR2 are DS-TE-capable LSRs
 Let's assume again that preemptions 2 and 3 are used in the TE-domain
 and that the following TE-Class mapping is configured on LSR1 and
 LSR2:
         i   <--->       CT      preemption
       ====================================
         0               CT1     0
         1               CT1     1
         2               CT0     2
         3               CT0     3
         rest            unused
 LSR0 is configured with a Max Reservable Bandwidth = m01 for Link01.
 LSR1 is configured with a BC0 = x0, a BC1 = x1 (possibly = 0), and a
 Max Reservable Bandwidth = m10 (possibly = m01) for Link01.
 In IGP for Link01, LSR0 will advertise:
  1. Max Reservable Bw sub-TLV = <m01>
  1. Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4,

CT0/5, CT0/6, CT0/7>

 On receipt of such advertisement, LSR1 will:
  1. understand that LSR0 is not DS-TE-capable because it

advertised a Max Reservable Bw sub-TLV and no Bandwidth

         Constraints sub-TLV, and
  1. conclude that only CT0 LSPs can transit via LSR0 and that

only the values CT0/2 and CT0/3 are meaningful in the

         Unreserved Bw sub-TLV.  LSR1 may effectively behave as if the
         six other values contained in the Unreserved Bw sub-TLV were
         set to zero.

Le Faucheur Standards Track [Page 33] RFC 4124 Protocols for Diffserv-aware TE June 2005

 In IGP for Link01, LSR1 will advertise:
  1. Max Reservable Bw sub-TLV = <m10>
  1. Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
  1. Unreserved Bw sub-TLV =

<CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>

 On receipt of such advertisement, LSR0 will:
  1. ignore the Bandwidth Constraints sub-TLV (unrecognized)
  1. correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-

TLV and use these values for CTO LSP establishment

  1. incorrectly believe that the other values contained in the

Unreserved Bw sub-TLV relate to other preemption priorities

         for CT0; but it will actually never use those since we assume
         that only preemptions 2 and 3 are used in the TE domain.

Normative References

 [DSTE-REQ]    Le Faucheur, F. and W. Lai, "Requirements for Support
               of Differentiated Services-aware MPLS Traffic
               Engineering", RFC 3564, July 2003.
 [MPLS-ARCH]   Rosen, E., Viswanathan, A. and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.
 [TE-REQ]      Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and
               J. McManus, "Requirements for Traffic Engineering Over
               MPLS", RFC 2702, September 1999.
 [OSPF-TE]     Katz, D., Kompella, K. and D. Yeung, "Traffic
               Engineering (TE) Extensions to OSPF Version 2", RFC
               3630, September 2003.
 [ISIS-TE]     Smit, H. and T. Li, "Intermediate System to
               Intermediate System (IS-IS) Extensions for Traffic
               Engineering (TE)", RFC 3784, June 2004.
 [RSVP-TE]     Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
               V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

Le Faucheur Standards Track [Page 34] RFC 4124 Protocols for Diffserv-aware TE June 2005

 [RSVP]        Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
               1 Functional Specification", RFC 2205, September 1997.
 [DIFF-MPLS]   Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
               Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
               "Multi-Protocol Label Switching (MPLS) Support of
               Differentiated Services", RFC 3270, May 2002.
 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [IANA-CONS]   Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26, RFC
               2434, October 1998.

Informative References

 [DIFF-ARCH]   Blake, S., Black, D., Carlson, M., Davies, E., Wang,
               Z., and W. Weiss, "An Architecture for Differentiated
               Service", RFC 2475, December 1998.
 [DSTE-RDM]    Le Faucheur,F., Ed., "Russian Dolls Bandwidth
               Constraints Model for Diffserv-aware MPLS Traffic
               Engineering", RFC 4127, June 2005.
 [DSTE-MAM]    Le Faucheur, F. and W. Lai, "Maximum Allocation
               Bandwidth Constraints Model for Diffserv-aware Traffice
               Engineering", RFC 4125, June 2005.
 [DSTE-MAR]    Ash, J., "Max Allocation with Reservation Bandwidth
               Constraints Model for DiffServ-aware MPLS Traffic
               Engineering & Performance Comparisons", RFC 4126, June
               2005.
 [GMPLS-SIG]   Berger, L., "Generalized Multi-Protocol Label Switching
               (GMPLS) Signaling Functional Description", RFC 3471,
               January 2003.
 [GMPLS-ROUTE] Kompella, et al., "Routing Extensions in Support of
               Generalized MPLS", Work in Progress.
 [BUNDLE]      Kompella, Rekhter, Berger, "Link Bundling in MPLS
               Traffic Engineering", Work in Progress.
 [HIERARCHY]   Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
               TE", Work in Progress.

Le Faucheur Standards Track [Page 35] RFC 4124 Protocols for Diffserv-aware TE June 2005

 [REROUTE]     Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
               Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
               2005.

Editor's Address

 Francois Le Faucheur
 Cisco Systems, Inc.
 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

Le Faucheur Standards Track [Page 36] RFC 4124 Protocols for Diffserv-aware TE June 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Le Faucheur Standards Track [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4124.txt · Last modified: 2005/06/27 18:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki