One document matched: draft-ietf-tewg-diff-te-proto-05.txt
Differences from draft-ietf-tewg-diff-te-proto-04.txt
Francois Le Faucheur, Editor
Cisco Systems, Inc.
IETF Internet Draft
Expires: March, 2004
Document: draft-ietf-tewg-diff-te-proto-05.txt September, 2003
Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies the IGP and RSVP-TE signaling extensions
(beyond those already specified for existing MPLS Traffic
Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering
(DS-TE). These extensions address the Requirements for DS-TE spelt
out in [DSTE-REQ].
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
draft-ietf-tewg-diff-te-reqts-07.txt
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is a Working Group document of the TE Working Group.
WHY IS IT TARGETED AT THIS WG(s)
Le Faucheur, et. al 1
Protocols for Diff-Serv-aware TE September 2003
TEWG is responsible for specifying protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering.
JUSTIFICATION
The TEWG charter states that "This will entail verification and
review of the Diffserv requirements in the WG Framework document and
initial specification of how these requirements can be met through
use and potentially expansion of existing protocols."
In line with this, the TEWG is progressing this Working Group
document specifying protocol extensions for Diff-Serv-aware MPLS
Traffic Engineering.
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].
1. Introduction
[DSTE-REQ] presents the Service Providers requirements for support of
Diff-Serv-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
spelt out in [DSTE-REQ] including environments relying on distributed
Constraint Based Routing (e.g. path computation involving Head-end
LSRs).
[DSTE-REQ] provides a definition and examples of Bandwidth Constraint
Models. The present document does not specify nor assume a particular
Bandwidth Constraints model. Specific Bandwidth Constraints model are
outside the scope of this document. While 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] and the "Maximum
Allocation" Model specified in [DSTE-MAM].
2. Contributing Authors
This document was the collective work of several. The text and
content of this document was contributed by the editor and the co-
authors listed below. (The contact information for the editor appears
in Section 17, and is not repeated below.)
Le Faucheur et. al 2
Protocols for Diff-Serv-aware TE September 2003
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: Email: tnadeau@cisco.com
btownsend@tenornetworks.com
Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9
Phone: +1-613-765-2252
Email: dareks@nortelnetworks.com
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. which are to be treated equivalently from the DS-TE
perspective] which are placed inside a Label Switched Path.
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
set-up priority, as the holding priority or both.
Definitions for a number of MPLS terms are not repeated here. Those
can be found in [MPLS-ARCH].
4. Configurable Parameters
Le Faucheur et. al 3
Protocols for Diff-Serv-aware TE September 2003
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 Constraint 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 semantic is generalized and interpreted as the
aggregate bandwidth constraints across all Class-Types, so that,
independently of the Bandwidth Constraint Model in use:
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 Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The
LSR MUST interpret these Bandwidth Constraints in accordance with the
supported Bandwidth Constraint Model (i.e. what bandwidth constraint
applies to what Class-Type and how).
Where the Bandwidth Constraint Model imposes some relationship among
the values to be configured for these Bandwidth Constraints, the LSR
MUST enforce those at configuration time. For example, when the
"Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the
LSR must ensure that BCi is configured smaller 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 historically
used in existing TE deployment, which are :
(i) To take into account the overbooking/underbooking ratio
appropriate for the OA/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/Bandwidth Constraints and use values which are
larger(overbooking) or smaller(underbooking) than actually
Le Faucheur et. al 4
Protocols for Diff-Serv-aware TE September 2003
supported by the link. We refer to this method as the "Link
Size Overbooking method".
The "LSP Size Overbooking" method and the "Link size overbooking"
method 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.
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
Class Types. The preemption attributes of setup priority and holding
priority retain existing semantics, and in particular these semantics
are not affected by the LSP Class Type. This means that if LSP1
contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a
higher set-up 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
Le Faucheur et. al 5
Protocols for Diff-Serv-aware TE September 2003
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.
When the TE-class mapping needs to be modified in the DS-TE domain,
care must 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 which 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 which 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 Constraint Model, what are the Bandwidth Constraints 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 is 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 is section 4.2.1 above.
The LSR MUST enforce these two rules at configuration time.
4.4. Examples of Parameters Configuration
Le Faucheur et. al 6
Protocols for Diff-Serv-aware TE September 2003
For illustrative purposes, we now present a few examples of how these
configurable parameters may be used. All these examples assume that
different bandwidth constraints 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 Class Types
(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, set-up priority =0, holding priority=0
Data LSPs would then be configured with:
- CT=CT0, set-up 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, set-up priority =0, holding priority=0
Large size Data LSPs could be configured with:
- CT=CT0, set-up priority = 1, holding priority=1
Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 2, holding priority=2
Small size Data LSPs could be configured with:
- CT=CT0, set-up priority = 3, holding priority=3.
Le Faucheur et. al 7
Protocols for Diff-Serv-aware TE September 2003
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 while
also achieving 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, set-up priority = 0, holding priority=0.
Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 1, holding priority=1.
Large size Data LSPs could be configured with:
- CT=CT0, set-up priority = 2, holding priority=2.
Small size Data LSPs could be configured with:
- CT=CT0, set-up 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.
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:
Le Faucheur et. al 8
Protocols for Diff-Serv-aware TE September 2003
- CT=CT1, set-up priority =0, holding priority=0
Data LSPs would then be configured with:
- CT=CT0, set-up 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, set-up priority = 0, holding priority=0.
Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 1, holding priority=0.
Large size Data LSPs could be configured with:
- CT=CT0, set-up priority = 2, holding priority=1.
Small size Data LSPs could be configured with:
- CT=CT0, set-up 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.
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
Le Faucheur et. al 9
Protocols for Diff-Serv-aware TE September 2003
As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
( BCb, 0 <= b <= 7) are configurable on any given link.
With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained
with a generalized semantic 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 Bandwidth Constraints (BC0 to BC7):
"Bandwidth Constraints" sub-TLV:
- Bandwidth Constraint Model Id (1 octet)
- Bandwidth Constraints (Nx4 octets)
Where:
- With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
sub-TLV type is TBD. See IANA Considerations section below.
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS
reachability TLV" and its sub-TLV type is TBD. See IANA
Considerations section below.
- Bandwidth Constraint Model Id: 1 octet identifier for the
Bandwidth Constraints Model currently in use by the LSR
initiating the IGP advertisement.
- Value 0 identifies the Russian Dolls Model specified in
[DSTE-RDM].
- Value 1 identifies the Maximum Allocation Model
specified in [DSTE-MAM].
- Bandwidth Constraints: contains BC0, BC1,... BC(N-1).
Each Bandwidth Constraint 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.
A DS-TE LSR MAY optionally advertise Bandwidth Constraints.
A DS-TE LSR which does advertise Bandwidth Constraints MUST use the
new "Bandwidth Constraints" sub-TLV (in addition to the existing
Maximum Reservable Bandwidth sub-TLV) to do so. For example,
considering 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 Bandwidth Constraints would
Le Faucheur et. al 10
Protocols for Diff-Serv-aware TE September 2003
include in the IGP advertisement the Maximum Reservable Bandwidth
sub-TLV as well as the "Bandwidth Constraints" sub-TLV, where the
former should contain the aggregate bandwidth constraint across all
CTs and the latter would contain BC0 and BC1.
A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
Bandwidth Constraint Model Id which does not match the Bandwidth
Constraint Model it currently uses, MAY generate a warning to the
operator reporting the inconsistency between Bandwidth Constraint
Models used on different links. Also, in that case, if the DS-TE LSR
does not support the Bandwidth Constraint Model designated by the
Bandwidth Constraint Model Id, or if the DS-TE LSR does not support
operations with multiple simultaneous Bandwidth Constraint Models,
the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR
does support the Bandwidth Constraint Model designated by the
Bandwidth Constraint Model Id and if the DS-TE LSR does support
operations with multiple simultaneous Bandwidth Constraint 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 semantic. The Unreserved Bandwidth sub-TLV
still carries eight bandwidth values but they now correspond to the
unreserved bandwidth for each of the TE-Class (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 which 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, with
unreserved bandwidth for TE-Class [0] occurring 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 which :
- transports a Traffic Trunk from the Class-Type of TE-
Class[i], and
- has a setup priority corresponding to the preemption priority
of TE-Class[i].
The units are bytes per second.
Since the bandwidth values are now ordered by TE-class index and thus
can relate to different CTs with different bandwidth constraints and
Le Faucheur et. al 11
Protocols for Diff-Serv-aware TE September 2003
can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT
assume any ordered relationship among these bandwidth values.
With existing TE, since all preemption priorities reflect the same
(and only) bandwidth constraints and since bandwidth values are
advertised in preemption priority order, the following relationship
is always true, and is often assumed by TE implementations:
If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
With DS-TE, no relationship is to be assumed so that:
If i < j , then any of the following relationship 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
Diff-Serv-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 Diff-Serv 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 C-Type 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.
Le Faucheur et. al 12
Protocols for Diff-Serv-aware TE September 2003
This new CLASSTYPE object is optional with respect to RSVP so that
general RSVP implementations not concerned with MPLS LSP set up do
not have to support this object.
An LSR supporting DS-TE MUST support the CLASSTYPE Object.
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 format is shown below.
6.2.1. CLASSTYPE object
class = TBD, C_Type = 1 (need to get an official class num from the
IANA with the form 0bbbbbbb). See IANA Considerations section 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
6.3. Handling CLASSTYPE Object
Le Faucheur et. al 13
Protocols for Diff-Serv-aware TE September 2003
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.
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
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 the Path message contained a CLASSTYPE object or not).
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 which contains the CLASSTYPE object but which does not
contain a LABEL_REQUEST object or which does not have a session type
of LSP_Tunnel_IPv4, MUST send a PathErr towards the sender with the
error code 'Diff-Serv-aware TE Error' and an error value of
'Unexpected CLASSTYPE object'. Those are defined below in section
6.5.
An LSR receiving a Path message with the CLASSTYPE object, which
recognizes the CLASSTYPE object but does not support the particular
Class-Type, MUST send a PathErr towards the sender with the error
code 'Diff-Serv-aware TE Error' and an error value of 'Unsupported
Class-Type'. Those are defined below in section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which
recognizes the CLASSTYPE object but 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 'Diff-Serv-aware TE Error' and
an error value of 'Invalid Class-Type value'. Those are defined below
in section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which:
Le Faucheur et. al 14
Protocols for Diff-Serv-aware TE September 2003
- recognizes the CLASSTYPE object,
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the set-up 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 'Diff-
Serv-aware TE Error' and an error value of 'CT and setup priority do
not form a configured TE-Class'. Those are defined below in section
6.5.
An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object,
- supports the particular Class-Type, but
- 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 'Diff-
Serv-aware TE Error' and an error value of 'CT and holding priority
do not form a configured TE-Class'. Those are defined below in
section 6.5.
An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an L-LSP, which:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types
and PSC (e.g. via configuration)
- based on this local knowledge, determines that the 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 'Diff-
Serv-aware TE Error' and an error value of 'Inconsistency between
signaled PSC and signaled CT'. Those are defined below in section
6.5.
An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an E-LSP, which:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types
and PHBs (e.g. via configuration)
- based on this local knowledge, determines 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 'Diff-
Serv-aware TE Error' and an error value of 'Inconsistency between
signaled PHBs and signaled CT'. Those are defined below in section
6.5.
An LSR MUST handle the situations where the LSP can not be accepted
for other reasons than those already discussed in this section, in
Le Faucheur et. al 15
Protocols for Diff-Serv-aware TE September 2003
accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is
rejected by admission control, a label can not 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 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).
In both situations, this causes the path set-up to fail. The sender
SHOULD notify management that a LSP cannot be established and
possibly might take action to retry reservation establishment without
the CLASSTYPE object.
6.5. Error Codes For Diff-Serv-aware TE
In the procedures described above, certain errors must be reported as
a 'Diff-Serv-aware TE Error'. The value of the 'Diff-Serv-aware TE
Error' error code is (TBD). See IANA Considerations section below.
The following defines error values for the Diff-Serv-aware TE Error:
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 CT and setup priority do not form a configured TE-Class
5 CT and holding priority do not form a configured
TE-Class
6 Inconsistency between signaled PSC and signaled CT
7 Inconsistency between signaled PHBs and signaled CT
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]
[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 otherwise specify
Le Faucheur et. al 16
Protocols for Diff-Serv-aware TE September 2003
encodings or behavior that have a different meaning for an DS-TE
router.
In order for an implementation to support both this specification for
Diff-Serv-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, such as it is used in this specification.
Additionally, current and future MPLS enhancements may include more
precise specification for how they interact with Diff-Serv-aware TE.
7.1. DS-TE support and references to preemption priority
When a router supports both Diff-Serv-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 to be 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 interpret it as such as well.
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 the preemption priorities 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 Diff-Serv-aware TE and MPLS protocol
extensions such as those mentioned above, advertisements of Maximum
Reservable Bandwidth MUST be done with the generalized interpretation
defined above in section 4.1.1 as the aggregate bandwidth constraint
across all Class-Types and MAY also allow the optional advertisement
of all Bandwidth Constraints.
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 set-up 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].
Le Faucheur et. al 17
Protocols for Diff-Serv-aware TE September 2003
The Constraint Based Routing algorithm of a DS-TE LSR is still only
required to perform path computation satisfying a single bandwidth
constraint which is to fit in "Unreserved TE-Class [i]" as advertised
by the IGP for every link. Thus, no changes are required to the
existing TE Constraint Based Routing algorithm itself.
The Constraint Based Routing algorithm MAY also optionally take into
account, when used, the optional additional information advertised in
IGP such as the Bandwidth Constraints and the Maximum Reservable
Bandwidth. As an example, the Bandwidth Constraints MIGHT be used as
a tie-breaker criteria in situations where multiple paths, otherwise
equally attractive, are possible.
9. Diff-Serv 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 Diff-Serv scheduler. In addition, the Diff-Serv
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 to a PSC/OA within
a Class Type by the Diff-Serv scheduler.
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 an a bandwidth
constraint applying across all LSPs
Since all LSPs transport traffic from CT0, RSVP-TE signaling is done
without explicit signaling of the Class-Type (which is only used for
other Class-Types than CT0 as explained in section 6) as with
existing TE.
Le Faucheur et. al 18
Protocols for Diff-Serv-aware TE September 2003
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
implementations since 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 which 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 of the Bandwidth Constraints 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 bandwidth constraints 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 set-up 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 link,
an LSP of bandwidth B, of set-up preemption priority p and of Class-
Type CTc is admissible on that link iff:
B <= Unreserved Bandwidth for TE-Class[i]
Where
Le Faucheur et. al 19
Protocols for Diff-Serv-aware TE September 2003
- TE-Class [i] maps to < CTc , p > in the LSR's configured TE-
Class mapping
12. Security Considerations
This document does not introduce additional security threats beyond
those inherent to Diff-Serv and MPLS Traffic Engineering and the same
security mechanisms proposed for these technologies are applicable
and may be used. 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 Diff-Serv 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. Acknowledgments
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.
14. IANA Considerations
This document defines a number of objects with implications for IANA.
This document defines in section 5.1 a new sub-TLV, the "Bandwidth
Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. A sub-TLV
Type in the range 10 to 32767 needs to be assigned by Expert Review.
This sub-TLV Type also needs to be registered 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
[ISIS-TE]. A sub-TLV Type needs to be assigned by Expert Review. This
sub-TLV Type also needs to be registered by IANA.
This document defines in section 5.3 a "Bandwidth Constraint Model
Id" field within the "Bandwidth Constraints" sub-TLV. This document
also defines in section 5.3 two values for this field (0 and 1).
Future allocations of values in this space and in the range 2 to 127
should be handled by IANA using the First Come First Served policy
defined in [IANA]. Values in the range 128 to 255 are reserved for
experimental use.
This document defines in section 6.2.1 a new RSVP object, the
CLASSTYPE object. This object requires a number from the space
defined in [RSVP] for those objects which, if not understood, cause
Le Faucheur et. al 20
Protocols for Diff-Serv-aware TE September 2003
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
requires a number to be allocated by IANA from the "IETF Consensus"
space.
This document defines in section 6.5 a new RSVP error code, the
"Diff-Serv-aware TE Error". This new Error code needs to be allocated
by IANA. This document defines values 1 through 7 of the value field
to be used within the ERROR_SPEC object for the "Diff-Serv-aware TE
error" code. Future allocations of values in this space should be
handled by IANA using the First Come First Served policy defined in
[IANA].
15. Normative References
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, RFC3564, .
[MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching
Architecture", RFC3031.
[DIFF-ARCH] Blake et al., "An Architecture for Differentiated
Services", RFC2475.
[TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over
MPLS", RFC2702.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-
katz-yeung-ospf-traffic-10.txt, June 2003.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-traffic-05.txt, August 2003.
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version
1 Functional Specification", RFC 2205, September 1997.
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270,
May 2002.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997.
16. Informative References
Le Faucheur et. al 21
Protocols for Diff-Serv-aware TE September 2003
[DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints
Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, September
2003
[DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth
Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-01.txt,
September 2003.
[DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth Constraint
Model for MPLS/DiffServ TE & Performance Comparisons", March 2003.
[GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC3471
[GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-gmpls-routing-05.txt, work in
progress.
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic
Engineering", draft-ietf-mpls-bundle-04.txt, work in progress.
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress.
[REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in
progress.
17. 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
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. One example
would be to perform better load-distribution of the multiple LSPs
across multiple paths. Another example would be to avoid CAC
rejection when the (n+1)-th LSP would no longer fit on a link after
establishment of the n-th LSP. While there are also a number of
Le Faucheur et. al 22
Protocols for Diff-Serv-aware TE September 2003
conceivable scenarios where doing such predictions might result in a
worse situation, it is more likely to improve the situation. 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 Bandwidth
Constraint 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 Bandwidth
Constraint 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 used by
other LSRs.
Appendix B - Solution Evaluation
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].
The objective set out in the last paragraph of section "4.7
overbooking" of [DSTE-REQ] 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 Bandwidth Constraints (such
as the Maximum Reservable Bandwidth).
2. Flexibility
Le Faucheur et. al 23
Protocols for Diff-Serv-aware TE September 2003
This DS-TE solution supports 8 CTs. It is entirely flexible as to how
Traffic Trunks are grouped together into a CT.
3. Extendibility
A maximum of 8 CTs is considered by the authors of this document as
more than comfortable. However, this solution could be extended to
support more CTs if deemed necessary in the future. However, this
would necessitate additional IGP extensions beyond those specified in
this document.
Although the prime objective of this solution is support of Diff-
Serv-aware Traffic Engineering, its mechanisms are not tightly
coupled with Diff-Serv. This makes the solution amenable, or more
easily extendable, for support of potential other future Traffic
Engineering applications.
4. Scalability
This DS-TE solution is expected to have a very small scalability
impact compared to existing TE.
From an IGP viewpoint, the amount of mandatory information to be
advertised is identical to 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 Bandwidth
Constraints).
We expect no noticeable impact on LSP Path computation since, as with
existing TE, this solution only requires CSPF to consider a single
unreserved bandwidth value for any given LSP.
From a signaling viewpoint we expect no significant impact due to
this solution since it only requires processing of one additional
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 the sense that it assumes that different classes
of traffic are split over different LSPs so that more LSPs need to be
signaled; but this is due to the DS-TE concept itself and not to the
actual DS-TE solution discussed here.
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 increasing
the number of CTs actually deployed since it only requires
Le Faucheur et. al 24
Protocols for Diff-Serv-aware TE September 2003
configuration changes. however, these changes must 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 while some LSRs and not DS-TE capable, which
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 requires that the TE-class mapping in the DS-TE
domain is configured so that:
- a TE-class exist for CT0 for every preemption priority
actually used in the TE domain
- the index in the TE-class mapping for each of these TE-
classes is equal to the preemption priority.
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, the whole TE-class
mapping does not have to be consistent with the TE domain, but the
subset of this TE-Class mapping applicable to CT0 must effectively be
consistent with the TE domain.
Hybrid operations also requires that:
- non DS-TE capable LSRs be configured to advertise the Maximum
Reservable Bandwidth
- DS-TE capable LSRs be configured to advertise Bandwidth
Constraints (using the Max Reservable Bandwidth sub-TLV as
well as the Bandwidth Constraints sub-TLV, as specified in
section 5.1 above).
This allows DS-TE capable LSRs to unambiguously identify non DS-TE
capable LSRs.
Finally hybrid operations require that non DS-TE capable LSRs be able
to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth
values (ie with Unreserved [p] < Unreserved [q] with p <q).
In such hybrid networks :
- CT0 LSPs can be established by both DS-TE capable LSRs and
non-DSTE capable LSRs
Le Faucheur et. al 25
Protocols for Diff-Serv-aware TE September 2003
- CT0 LSPs can transit via (or terminate at) both DS-TE capable
LSRs and non-DSTE capable LSRs
- LSPs from other CTs can only be established by DS-TE capable
LSRs
- LSPs from other CTs can only transit via (or terminate at)
DS-TE capable LSRs
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 preemption 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.
LSR0 will advertise in IGP for Link01:
- Max Reservable Bw sub-TLV = <m01>
- 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:
- understand that LSR0 is not DS-TE capable because it
advertised a Max Reservable Bw sub-TLV and no Bandwidth
Constraint sub-TLV
- 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.
LSR1 will advertise in IGP for Link01:
- Max Reservable Bw sub-TLV = <m10>
- Bandwidth Constraint sub-TLV = <BC Model ID, x0,x1>
- Unreserved Bw sub-TLV = <CT1/0,CT1/1,CT0/2,CT0/3,0,0,0,0>
Le Faucheur et. al 26
Protocols for Diff-Serv-aware TE September 2003
On receipt of such advertisement, LSR0 will:
- Ignore the Bandwidth Constraint sub-TLV (unrecognized)
- Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-
TLV and use these values for CTO LSP establishment
- Incorrectly believe that the other values contained in the
Unreserved Bw sub-TLV relates to other preemption priorities
for CT0, but will actually never use those since we assume
that only preemption 2 and 3 are used in the TE domain.
Le Faucheur et. al 27
| PAFTECH AB 2003-2026 | 2026-04-23 05:50:46 |