Francois Le Faucheur, Editor
Thomas Nadeau
Cisco Systems, Inc.
Jim Boyle
PDNets
Kireeti Kompella
Juniper Networks
William Townsend
Tenor Networks
Darek Skalecki
Nortel Networks
IETF Internet Draft
Expires: August, 2002
Document: draft-ietf-tewg-diff-te-proto-00.txt February, 2002
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 signaling extensions and
procedures (beyond those already specified for existing MPLS Traffic
Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering.
Le Faucheur, et. al 1
Protocols for Diff-Serv-aware TE February 2002
A Bandwidth Constraints model for Diff-Serv-aware Traffic Engineering
is also specified.
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 signaling extensions and procedures (beyond those
already specified for existing MPLS Traffic Engineering
[OSPF-TE][ISIS-TE][RSVP-TE][CR-LDP]) for support of the DS-TE
requirements [DSTE-REQ] in environments relying on
distributed Constraint Based Routing (i.e. path computation
involving Head-end LSRs).
- A Bandwidth Constraint Model for DS-TE called the Russian
Dolls model. While Diff-Serv-aware implementations may
support other Bandwidth Constraints model, they must all
support the Russian Dolls model to ensure interoperability
across all implementations.
2. Definitions
[DSTE-REQ] discusses how a Head-end LSR may split the set of Ordered
Aggregates from the traffic to a given Tail-end into multiple Traffic
Trunks. Each Traffic Trunk is transported over a separate LSP which
is Constraint Based Routed individually.
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.
Le Faucheur et. al 2
Protocols for Diff-Serv-aware TE February 2002
3. 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], [RSVP-TE] and [CR-LDP]. All other parameters
are unchanged.
3.1. Link Parameters
3.1.1. Bandwidth Constraints (BCs)
[DSTE-REQTS] 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 BC0.
Additionally, on every link, a DS-TE implementation must provide for
configuration of up to 7 additional link parameters which are the
seven other potential Bandwidth Constraints i.e. BC1, BC2 , ... BC7.
The LSR is responsible for interpreting these Bandwidth Constraints
in accordance with the supported Bandwidth Constraint Model (i.e.
what bandwidth constraint applies to what Class-Type and how). At any
one time, all LSRs of the DS-TE domain must support the same
Bandwidth Constraint Model.
Where the Bandwidth Constraint Model imposes some relationship among
the values to be configured for these Bandwidth Constraints, the LSR
is responsible for enforcing those at configuration time. For
example, with the "Russian Doll" Bandwidth Constraints Model defined
below in section 9, the LSR must ensure that BCi is configured
smaller or equal to BCj, where i is greater than j.
3.1.2. per-CT Local Overbooking Multiplier
DS-TE enables a network administrator to apply different overbooking
(or underbooking) ratios for different CTs.
The principal method to achieve this is the same as historically used
in existing TE deployment which is to take into account the over-
booking 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 as the "LSP size overbooking" method.
Since the overbooking ratio is factored into the LSP bandwidth (which
is invariable across all the links spanned by the LSP), using the
"LSP size overbooking" method alone effectively has the following
characteristics:
Le Faucheur et. al 3
Protocols for Diff-Serv-aware TE February 2002
- different overbooking ratios can effectively be enforced for
different CTs (by using a different overbooking ratios for
LSPs of different CTs)
- the overbooking ratio is the same on all links for a given CT
- the overbooking ratios can even be fine-tuned on a per-LSP
basis (i.e. different LSPs of the same CT may be sized based
on overbooking ratios which are tweaked differently).
The "LSP size overbooking" method is expected to be often sufficient
in many DS-TE environments and requires no additional configurable
parameters.
However, in the particular DS-TE environments where, for a given CT,
the overbooking ratio needs to be tweaked differently on different
links, a DS-TE implementation may allow the "LSP size overbooking"
method to be complemented by the use of the "local overbooking"
method. The "local overbooking" method relies on optional "per-CT
Local Overbooking Multipliers" which are configurable, on every link,
for every CT. The per-CT Local Overbooking Multiplier effectively
allows the network operator to increase/decrease", on some links, the
overbooking ratio already enforced by the "LSP size overbooking"
method. This is achieved by factoring the per-CT Local Overbooking
Multiplier in all local bandwidth accounting for the purposes of
admission control and IGP advertisement of unreserved bandwidths.
3.2. LSR Parameters
3.2.1. TE-Class Mapping
In line with [DSTE-REQ], the preemption attributes defined in [TE-
REQ] are retained with DS-TE and applicable 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 Ordered Aggregate transported by the LSP or by the
LSP's 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's
holding preemption priority regardless of LSP1's OA/CT and LSP2's
OA/CT.
For 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
Le Faucheur et. al 4
Protocols for Diff-Serv-aware TE February 2002
Two TE-Classes must not be identical (i.e. have both the same Class-
Type and the same preemption priority).
Where the network administrator uses less than 8 TE-Classes, the
remaining ones must be configured as "Unused".
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.
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.
3.3. LSP Parameters
3.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
applicable to that LSP.
3.3.2. Setup and Holding Preemption Priorities
As per existing TE, DS-TE assumes that every DS-TE LSP is configured
with a setup and holding priority, each with a value between 0 and 7.
3.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 3.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 3.2.1 above.
3.4. Examples of Parameters Configuration
Le Faucheur et. al 5
Protocols for Diff-Serv-aware TE February 2002
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 must be used.
3.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.
3.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:
Le Faucheur et. al 6
Protocols for Diff-Serv-aware TE February 2002
- CT=CT0, set-up 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.
3.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.
3.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
Le Faucheur et. al 7
Protocols for Diff-Serv-aware TE February 2002
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 =0, holding priority=0
No LSP would then be able to preempt any other LSP.
3.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.
4. IGP Advertisement
This section only discusses the differences with the IGP
advertisement supported for MPLS Traffic Engineering as per [OSPF-TE]
and [ISIS-TE]. The rest of the IGP advertisement is unchanged.
4.1. Bandwidth Constraints
Le Faucheur et. al 8
Protocols for Diff-Serv-aware TE February 2002
As detailed above in section 3.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 is now interpreted as
Bandwidth Constraint 0 (BC0).
DS-TE also defines the following optional sub-TLV to advertise the
eight potential Bandwidth Constraints (BC0 to BC7):
"Bandwidth Constraints" sub-TLV:
TBD - Bandwidth Constraint Model Id (1 octet)
Bandwidth Constraints (Nx4 octets)
Where:
- Bandwidth Constraint Model Id: 1 octet identifier for the
Bandwidth Constraints Model currently in use by the LSR
initiating the IGP advertisement.
Values 0 to 127 are to be allocated by the TEWG to identify
Bandwidth Constraints Models defined in the TEWG. Value 0
identifies the Russian Doll Bandwidth Constraint Model
defined in section 9.
Values 128 to 255 are for experimental use.
- Bandwidth Constraints: contains BC0, BC1,... BCN-1. It is
recommended that only the Bandwidth Constraints corresponding
to active CTs be advertised in order to minimize the impact
on IGP scalability.
When DS-TE is deployed and only a single CT is used, the existing
"Maximum Reservable Bw" sub-TLV is used.
When DS-TE is deployed and multiple CTs are used, the new "Bandwidth
Constraints" sub-TLV is used. For example, where a Service Provider
deploys DS-TE with two active CTs, only two Bandwidth Constraints per
link would be meaningful (assuming, for instance, the Russian Doll
Bandwidth Constraint Model defined in section 9). The "Bandwidth
Constraints" sub-TLV would then be used and should 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 an error indication
to the operator reporting the inconsistency between Bandwidth
Constraint Models used on different LSRs and may discard the
corresponding TLV.
4.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
Le Faucheur et. al 9
Protocols for Diff-Serv-aware TE February 2002
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 as per existing TE).
More precisely, the Unreserved Bandwidth sub-TLV definition 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
can relate to any arbitrary preemption priority, no ordered
relationship among these bandwidth values should be assumed.
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
"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]".
Since some Bandwidth Constraints Models are such that a given Class-
Type is constrained by multiple Bandwidth Constraints (as in the case
of the Russian Doll Bandwidth Constraint Model specified in section
9), the value to be advertised by the IGP in "Unreserved TE-Class
[i]" must reflect all of the Bandwidth Constraints relevant to the CT
associated with TE-Class [i]. .
If TE-Class[i] is unused the value to be advertised by the IGP in
"Unreserved TE-Class [i]" is zero.
Le Faucheur et. al 10
Protocols for Diff-Serv-aware TE February 2002
4.3. Local Overbooking Multiplier
The following additional optional sub-TLV is defined for DS-TE:
"Local Overbooking Multiplier" sub-TLV:
TBD - per-CT Local Overbooking Multipliers (N x 1 octet)
where N is the number of per-CT Local Overbooking Multipliers
actually advertised. For example, where a Service Provider only
deploys DS-TE with two CTs and makes use of the Local Overbooking
method, the "Local Overbooking Multiplier" sub-TLV may optionally be
used and would then contain only LOM[0] and LOM[1] in order to
minimize the impact on IGP scalability.
Note that the use of this sub-TLV is only optional even when the
optional Local Overbooking method is actually used (and thus when the
Local Overbooking Multipliers parameters actually configured locally
on some or all links). Its use may assist in head-end prediction of
network response to LSP establishment.
5. LSP Signaling
This section only describes the signaling extensions beyond those
already specified for MPLS Traffic Engineering as per [RSVP-TE] and
[CR-LDP] and for Diff-Serv over MPLS as per [DIFF-MPLS].
The Class-Type of the LSP is signaled in RSVP-TE and CR-LDP for DS-TE
in order for LSRs to enforce the appropriate bandwidth constraint(s)
for admission control and bandwidth accounting.
Protocol and procedure extensions for signaling of the Class-Type are
specified in details in Appendix A and B respectively for RSVP-TE and
CR-LDP.
6. 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 assume that this is the i-th TE-Class
i.e. TE-Class[i].
The Constraint Based Routing algorithm 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.
Le Faucheur et. al 11
Protocols for Diff-Serv-aware TE February 2002
The Constraint Based Routing algorithm may also optionally take into
account, when used, the optional information advertised in IGP which
are the Bandwidth Constraints and the Local Overbooking Multipliers.
As an example, the Bandwidth Constraints might be used as a tie-
breaker criteria in situations where multiple paths, otherwise
equally attractive, are possible.
7. Diff-Serv scheduling
The Class-Type signaled at LSP establishment may optionally be used
by 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 LSRs
to dynamically adjust the resources allocated to a PSC/OA within a
Class Type by the Diff-Serv scheduler.
8. 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, all 8 preemption priorities
are allowed for that Class-Type and the following TE-Class
Mapping is used:
TE-Class[i] <--> < CT0 , preemption i >
Where 0 <= i <= 7.
(ii) optional per-CT Local Overbooking Multipliers are not
used.
In that case, DS-TE behaves exactly as existing TE.
The IGP advertises:
- Unreserved Bandwidth for each of the 8 preemption priorities
- BC0= Maximum Reservable Bandwidth
Since all LSPs transport traffic from CT0, LSP Signaling is done
without explicit signaling of the Class-Type (which is only used for
other Class-Types than CT0 as explained in Appendix A and B).
9. Russian Doll Bandwidth Constraints Model
9.1. Definition
Le Faucheur et. al 12
Protocols for Diff-Serv-aware TE February 2002
[DSTE-REQ] introduces the concept of Bandwidth Constraint Model to
characterize the Bandwidth Constraints associated with CTs, but it
does not actually specify one particular Model.
Although multiple Bandwidth Constraints Models are conceivable and
may be supported by a given DS-TE implementation, DS-TE operation
requires that the same Bandwidth Constraint Model be actually used on
all LSRs of a given DS-TE domain. Thus, for multiple DS-TE
implementations to interoperate, they must support the same Bandwidth
Constraints Model. Consequently, this section specifies one default
Bandwidth Constraint Models which must be supported by all DS-TE
implementations to ensure interoperability. This Model is referred to
as the "Russian Dolls" Bandwidth Constraints model. DS-TE
implementations may also optionally support other Bandwidth
Constraints Models.
The "Russian Doll" model of Bandwidth Constraints is defined in the
following manner:
o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum
Number of Class-Types (MaxCT) = 8
o All LSPs supporting Traffic Trunks from CTb (with
b<=c<=7) use no more than BCb i.e.:
- All LSPs from CT7 use no more than BC7
- All LSPs from CT6 and CT7 use no more than BC6
- All LSPs from CT5, CT6 and CT7 use no more than BC5
- etc.
- All LSPs from CT0, CT1,... CT7 use no more than BC0
Purely for illustration purposes, the diagram below represents the
Russian Doll Bandwidth Constraints model in a pictorial manner when
only 3 Class-Types are active:
I------------------------------------------------------I
I-------------------------------I I
I--------------I I I
I CT2 I CT2+CT1 I CT2+CT1+CT0 I
I--------------I I I
I-------------------------------I I
I------------------------------------------------------I
I-----BC2------>
I----------------------BC1------>
I---------------------------------------------BC0------>
While more flexible/sophisticated Bandwidth Constraints models can be
defined, the Russian Dolls model is an attractive trade-off for the
following reasons:
- Network administrators generally find it superior to the most
basic model of a single independent BC per CT (which, in
typical deployment scenarios, results in either capacity
Le Faucheur et. al 13
Protocols for Diff-Serv-aware TE February 2002
wastage, low priority Traffic Trunk starvation and/or
degradation of QoS objectives)
- network administrators generally find it sufficient for the
real life deployments currently anticipated (e.g. it
addresses all the scenarios described in [DSTE-REQ])
- it remains simple and only requires limited protocol
extensions, while more sophisticated Bandwidth Constraints
model may require more complex extensions.
Another (or other) Bandwidth Constraints Model(s) may be specified
later if additional requirements emerge from Service Providers real
life deployment which cannot be addressed by the Russian Dolls model.
The Russian Doll Bandwidth Constraints Model can be supported with
the extensions defined earlier in this document for DS-TE. Note that
a number of other Bandwidth Constraints could also be supported with
these same extensions. Note also that not all Bandwidth Constraints
models could be supported with these extensions and those may require
additional or different extensions. Both of these situations are
beyond the scope of this specification.
As an example of the "Russian Doll" Bandwidth Constraints Model, a
network administrator using one CT for Voice (CT1) and one CT for
data (CT0) might configure on a given link:
- Existing Maximum Reservable Link Bandwidth (a.k.a. BC0) = 2.5
Gb/s (i.e. Voice + Data is limited to 2.5 Gb/s)
- Bandwidth Constraint 1 (a.k.a. BC1)= 1.5 Gb/s (i.e. Voice is
limited to 1.5 Gb/s).
9.2. 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
Le Faucheur et. al 14
Protocols for Diff-Serv-aware TE February 2002
advertised must reflect all of the Bandwidth Constraints relevant to
the CT associated with TE-Class[i], as discussed in section 4.2.
As with existing TE, DS-TE assumes that the holding preemption
priority is the one considered for established LSPs (as opposed to
their set-up preemption priority) for the purpose of computing the
unreserved bandwidth for TE-Class [i].
Example formulas for computing "Unreserved TE-Class [i]" are provided
in Appendix C.
9.3. Admission Control Rules
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], AND
B <= Max Link Bandwidth
Where
- TE-Class [i] maps to < CTc , p > in the LSR's configured TE-
Class mapping
- Max Link Bandwidth is the maximum link bandwidth configured
on the link and advertised in IGP.
Note that this admission control rule assumes that the optional per-
CT Local Overbooking Multipliers are not used (i.e. LOM[c]=1).
10. Security Considerations
The solution is not expected to add specific security requirements
beyond those of Diff-Serv and existing TE. The security mechanisms
currently used with Diff-Serv and existing TE can be used with this
solution.
11. Acknowledgments
We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier
contribution in this work.
References
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-03.txt,
February 2002.
Le Faucheur et. al 15
Protocols for Diff-Serv-aware TE February 2002
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-
katz-yeung-ospf-traffic-06.txt, October 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-traffic-04.txt, October 2001.
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP", RFC
32 12, January 2002.
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft-
ietf-mpls-diff-ext-09.txt, April 2001
Authors' 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
Jim Boyle
Protocol Driven Networks
1381 Kildaire Farm Road #288
Cary, NC 27511
Phone: +1 919 852-5160
Email: jboyle@pdnets.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94099
Email: kireeti@juniper.net
William Townsend
Tenor Networks
100 Nagog Park
Acton, MA 01720
Phone: +1-978-264-4900
Email: btownsend@tenornetworks.com
Thomas D. Nadeau
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
Le Faucheur et. al 16
Protocols for Diff-Serv-aware TE February 2002
Email: tnadeau@cisco.com
Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9
Phone: +1-613-765-2252
Email: dareks@nortelnetworks.com
Appendix A - RSVP Extensions for Diff-Serv-aware TE
In this section we describe extensions to RSVP 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.
1. Diff-Serv-aware 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 are also applicable to the establishment of LSP
Tunnels supporting Diff-Serv-aware Traffic Engineering. 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 set up do
not have to support this object.
An LSR supporting Diff-Serv-aware Traffic Engineering in compliance
with this specification MUST support the CLASSTYPE Object. It MUST
support Class-Type value 1, and MAY support other Class-Type values.
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> ]
Le Faucheur et. al 17
Protocols for Diff-Serv-aware TE February 2002
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
2. CLASSTYPE Object
The CLASSTYPE object format is shown below.
2.1. CLASSTYPE object
class = TBD, C_Type = 1 (need to get an official class num from the
IANA with the form 0bbbbbbb)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | 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.
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.
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.
Le Faucheur et. al 18
Protocols for Diff-Serv-aware TE February 2002
Each LSR along the path records 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 responds to the Path message by sending a Resv
message without a CLASSTYPE object (whether the Path message
contained a CLASSTYPE object or not).
During establishment of an LSP corresponding to the Class-Type N, the
LSR performs 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 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 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 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 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
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,
Le Faucheur et. al 19
Protocols for Diff-Serv-aware TE February 2002
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 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
accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is
rejected by admission control, a label can not be associated).
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.
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).
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
Appendix B - CR-LDP Extensions for Diff-Serv-aware TE
Le Faucheur et. al 20
Protocols for Diff-Serv-aware TE February 2002
CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in
[LDP], for support of (aggregate) MPLS Traffic Engineering. In this
section we describe extensions to CR-LDP for support of Diff-Serv-
aware MPLS Traffic Engineering. These extensions are in addition to
the extensions to LDP defined in [DIFF-MPLS] for support of Diff-Serv
over MPLS. They closely resemble the extensions to RSVP defined in
the previous section.
Note that extensions of this section for support of Diff-Serv-aware
Traffic Engineering are not applicable to LDP due to the fact that
LDP does not support MPLS Traffic Engineering and bandwidth
reservation in particular.
1. Diff-Serv-aware TE related CR-LDP Messages Encoding
One new CR-LDP TLV is defined in this document: the Class Type TLV.
Detailed description of this TLV is provided below. This new TLV is
applicable to Label Request messages.
Restrictions defined in [CR-LDP] for support of establishment of LSPs
via CR-LDP are also applicable to the establishment of LSPs
supporting Diff-Serv-aware Traffic Engineering: for instance, only
unicast LSPs are supported and multicast LSPs are for further study.
This new Class Type TLV is optional with respect to CR-LDP so that
general CR-LDP implementations not concerned with Diff-Serv-aware
Traffic Engineering are not required to support this TLV.
An LSR supporting Diff-Serv-aware Traffic Engineering in compliance
with this specification MUST support the Class Type TLV. It MUST
support Class-Type value 1, and MAY support other Class-Type values.
1.1. Label Request Message Encoding
The encoding for the CR-LDP Label Request message is extended as
follows, to optionally include the Class Type TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Type TLV (CR-LDP optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other CR-LDP TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur et. al 21
Protocols for Diff-Serv-aware TE February 2002
The extension is based on a related LDP extension, defined in [DIFF-
MPLS], for support of Diff-Serv TLV but further extended for CR-LDP
with CR-LDP TLVs.
2. Class Type TLV
The Class Type TLV has the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Class Type TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
3. Handling Class Type TLV
To establish an LSP using CR-LDP, an ingress LSR generates a Label
Request message as per [CR-LDP]. This Label Request may optionally
include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but
extended to CR-LDP.
If the LSP is associated with Class-Type 0, the ingress LSR must not
include the Class Type TLV in the Label Request message.
If the LSP is associated with Class-Type N (1 <= N <= 7), the ingress
LSR must include the Class Type TLV in the Label Request message with
the Class-Type (CT) field set to N.
If a Label Request message contains multiple Class Type TLVs, only
the first one is meaningful; subsequent Class Type TLV(s) must be
ignored and not forwarded.
If the Class Type TLV is not present in the Label Request message, an
LSR must associate the Class-Type 0 to the LSP.
A downstream LSR sending a Label Mapping message in response to a
Label Request message must not include the Class-Type TLV (whether
the Class-Type TLV was included in the Label Request message or not).
Le Faucheur et. al 22
Protocols for Diff-Serv-aware TE February 2002
During establishment of an LSP corresponding to the Class-Type N, an
LSR performs admission control over the bandwidth available for that
particular Class-Type.
An LSR that recognizes the Class Type TLV and receives a Label
Request message which contains the Class Type TLV but which does not
contain any of the CR-LDP TLVs, must reject the label request by
sending upstream a Notification message which includes the Status TLV
with a Status Code of 'Unexpected Class-Type TLV'. This is defined
below in section 4. This error can only occur when an LDP LSP as
opposed to CR-LDP LSP is being established. As was already mentioned,
Class Type TLV extension for Diff-Serv-aware Traffic Engineering is
not applicable to LDP.
An LSR receiving a Label Request message with the Class Type TLV,
which recognizes the Class Type TLV but does not support the
particular Class-Type, must reject the label request by sending
upstream a Notification message which includes the Status TLV with a
Status Code of 'Unsupported Class-Type'. This is defined below in
section 4.
An LSR receiving a Label Request message with the Class Type TLV,
which recognizes the Class Type TLV but determines that the Class-
Type value is not valid (i.e. Class-Type value 0), must reject the
label request by sending upstream a Notification message which
includes the Status TLV with a Status Code of 'Invalid Class-Type
value'. This is defined below in section 4.
An LSR receiving a Label Request message with the Class Type TLV,
which:
- recognizes the Class Type TLV,
- 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 Label Request
message, is not one of the eight TE-classes configured in
the TE-class mapping,
must reject the label request by sending upstream a Notification
message which includes the Status TLV with a Status Code of 'CT and
setup priority do not form a configured TE-Class'. This is defined
below in section 4.
An LSR receiving a Label Request message with the Class Type TLV,
which:
- recognizes the Class Type TLV,
- 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 Label Request
message, is not one of the eight TE-classes configured in
the TE-class mapping,
must reject the label request by sending upstream a Notification
message which includes the Status TLV with a Status Code of 'CT and
Le Faucheur et. al 23
Protocols for Diff-Serv-aware TE February 2002
holding priority do not form a configured TE-Class'. This is defined
below in section 4.
An LSR MUST handle the situations where the LSP can not be accepted
for other reasons than those already discussed in this section, in
accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation
rejected by admission control, a label can not be associated).
4. Status Code Values for Diff-Serv-aware TE
In the procedures described above, certain errors must be reported.
The following values are defined for the Status Code field of the
Status TLV:
Status Code E Status Data
Unexpected Class Type TLV 0 TBD
Unsupported Class-Type 0 TBD
Invalid Class-Type value 0 TBD
CT and setup priority do not 0 TBD
form a configured TE-Class
CT and holding priority do not 0 TBD
form a configured TE-Class'
Appendix C - Example Formulas for Computing "Unreserved TE-Class [i]"
Keeping in mind that details of admission control algorithms as well
as formulas for computing "Unreserved TE-Class [i]" are outside the
scope of this specification, we provide below, for illustration
purposes, an example of how values for the unreserved bandwidth for
TE-Class[i] might be computed, assuming:
- the Russian Doll Bandwidth Constraints Model is used
- the basic admission control algorithm which simply deducts
the exact bandwidth of any established LSP from all of the
Bandwidth Constraints relevant to the CT associated with that
LSP.
- the optional per-CT Local Overbooking Multipliers are not
used (.i.e. LOM[c]=1, 0<= c <=7).
We assume that:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
Let us define "Reserved(CTb,q)" as the sum of the bandwidth reserved
by all established LSPs which belong to CTb and have a holding
priority of q. Note that if q and CTb do not form one of the 8
possible configured TE-Classes, then there can not be any established
LSP which belong to CTb and have a holding priority of q, so in that
case Reserved(CTb,q)=0.
Le Faucheur et. al 24
Protocols for Diff-Serv-aware TE February 2002
For readability, formulas are first shown assuming only 4 CTs are
active. The formulas below can be extended trivially to cover the
cases where more CTs are used.
If CTc = CT0, then "Unreserved TE-Class [i]" =
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3
If CTc = CT1, then "Unreserved TE-Class [i]" =
MIN [
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3
]
If CTc = CT2, then "Unreserved TE-Class [i]" =
MIN [
[ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3,
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3
]
If CTc = CT3, then "Unreserved TE-Class [i]" =
MIN [
[ BC3 - SUM ( Reserved(CTb,q) ) ] for q <= p and 3 <= b <= 3,
[ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3,
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3
]
The formula can be generalized to 8 active CTs and expressed in a
more compact way in the following:
"Unreserved TE-Class [i]" =
MIN [
[ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
. . .
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
Appendix D - Prediction for Multiple Path Computation
There are situations where a Head-End needs to compute paths for
multiple LSPs. There are potential advantages for the Head-end in
Le Faucheur et. al 25
Protocols for Diff-Serv-aware TE February 2002
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 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 Local Overbooking Multiplier sub-
TLV need not be advertised in IGP 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 Local Overbooking Multiplier
sub-TLV if different overbooking ratios need to be supported on
different links) 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 may only be used
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 E - Addressing [DSTE-REQ] Scenarios
This Appendix provides examples of how the DS-TE solution can be used
to support each of the scenario described in [DSTE-REQ].
1. Scenario 1: Limiting Amount of Voice
By configuring on every link:
- Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage"
of link capacity
- BC0= Max Reservable Link Bandwidth = link capacity
By configuring:
- every CT1/Voice TE-LSP with preemption =0
- every CT0/Data TE-LSP with preemption =1
The proposed solution will address all the requirements:
Le Faucheur et. al 26
Protocols for Diff-Serv-aware TE February 2002
- amount of Voice traffic limited to desired percentage on
every link
- data traffic capable of using all remaining link capacity
- voice traffic capable of preempting other traffic
2. Scenario 2: Maintain Relative Proportion of Traffic Classes
By configuring on every link:
- BC2 for CT2 = e.g. 45%
- BC1 for CT1+CT2 = e.g. 80%
- BC0 for CT0+CT1+CT2= e.g.100%
The proposed DS-TE solution will ensure that the amount of traffic of
each Class Type established on a link is within acceptable levels as
compared to the resources allocated to the corresponding Diff-Serv
PHBs regardless of which order the LSPs are routed in, regardless of
which preemption priorities are used by which LSPs and regardless of
failure situations. Optional automatic adjustment of Diff-Sev
scheduling configuration could be used for maintaining very strict
relationship between amount of established traffic of each Class Type
and corresponding Diff-Serv resources.
3. Scenario 3: Guaranteed Bandwidth Services
By configuring on every link:
- BC1 for CT1 = "given" percentage of bandwidth (appropriate to
achieve the Guaranteed Bandwidth service's QoS objectives)
- BC0 for CT0+CT1 = 100%
The proposed DS-TE solution will ensure that the amount of Guaranteed
Bandwidth Trafic established on every link remains below the given
percentage so that it will always meet its QoS objectives. AT the
same time it will allow traffic engineering of the rest of the
traffic such that links can be filled up.
Appendix F - Solution Evaluation
1. Satisfying Detailed Requirements
This DS-TE Solution address all the scenarios presented in [DSTE-REQ]
as explained in Appendix E. It also satisfy all the detailed
requirements presented in [DSTE-REQ].
2. Flexibility
This DS-TE solution supports 8 CTs. It is entirely flexible as to how
Traffic Trunks are grouped together into a CT.
3. Extendibility
Le Faucheur et. al 27
Protocols for Diff-Serv-aware TE February 2002
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.
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. Two additional sub-TLVs have
been specified, but their use is optional and those contained a
limited amount of static information (at most 8 Bandwidth Constraints
and 8 LOMs).
We expect no noticeable impact on LSP Path computation since, as with
existing TE, this solution only require 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 exactly as
today 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
configuration changes. however, these changes must be performed in a
coordinated manner across the DS-TE domain.
Le Faucheur et. al 28