Francois Le Faucheur, Editor
Thomas Nadeau
Cisco Systems, Inc.
Martin Tatham
BT
Angela Chiu
Celion Networks
William Townsend
Tenor Networks
Darek Skalecki
Nortel Networks
Pete Hicks
Core Express
IETF Internet Draft
Expires: January, 2002
Document: draft-lefaucheur-diff-te-proto-00.txt July, 2001
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 describes a solution for addressing the requirements
defined in "Requirements for support of Diff-Serv-aware MPLS Traffic
Le Faucheur, et. al 1
Protocols for Diff-Serv-aware TE July 2001
Engineering" [DSTE-REQ] and the corresponding extensions to existing
MPLS TE protocols (ISIS, OSPF, RSVP-TE, CR-LDP) and procedures.
This document also discusses how the detailed requirements defined
in [DSTE-REQ] are met and how the solution fares against the
evaluation criteria also defined in [DSTE-REQ].
1. I-D Summary Information
This section contains the information submitted on the
"idsummary@subip.ietf.org" list of the Sub-IP area.
SUMMARY:
This draft describes protocol extensions (RSVP-TE, CR-LDP, OSPF,
ISIS) to address the requirements defined in
http://www.ietf.org/internet-drafts/draft-ietf-TEWG-diff-te-reqts-
01.txt, "Requirements for support of Diff-Serv-aware MPLS Traffic
Engineering".
RELATED DOCUMENTS:
- Complements:
http://www.ietf.org/internet-drafts/draft-ietf-TEWG-diff-te-reqts-
01.txt
- Replaces:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-
01.txt
http://www.ietf.org/internet-drafts/draft-ietf-isis-diff-te-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-ospf-diff-te-00.txt
- Competes:
None that I know of.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK:
This fits into TE-WG.
WHY IS IT TARGETED AT THIS WG
This directly addresses a specific item of the TEWG charter:
"For the time being, it also is covering the area of verification
that diffserv is achievable in traffic engineered SP networks. This
will entail verification and review of the Diffserv requirements in
the the WG Framework document and initial specification of how these
requirements can be met through use and potentially expansion of
existing protocols. "
JUSTIFICATION
The draft directly addresses an item of the charter.
2. Introduction
[DSTE-REQ] presents the Service Providers requirements for support
of Diff-Serv-aware MPLS Traffic Engineering (DS-TE). For memory,
Le Faucheur et. al 2
Protocols for Diff-Serv-aware TE July 2001
this includes the fundamental requirement to be able to enforce
different bandwidth constraints for different Class-Types.
This document describes:
- a solution for addressing these requirements including in
environments relying on distributed Constraint Based Routing
(i.e. path computation involving Head-end LSRs)
- the corresponding extensions to existing MPLS TE protocols
(ISIS, OSPF, RSVP-TE, CR-LDP) and procedures.
- how the detailed requirements defined in [DSTE-REQ] are met
- how the solution fares against the evaluation criteria also
defined in [DSTE-REQ].
3. Solution Overview
3.1. Configurable Parameters
In order to configure the multiple bandwidth constraints to be
enforced by DS-TE, for every link, it is possible to configure, in
addition to all the existing TE parameters, the following new
parameters (or any subset of those):
- Maximum Reservable bandwidth for CT(3)
- Maximum Reservable bandwidth for CT(3)+CT(2)
- Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)
The existing "Maximum Reservable link bandwidth" parameter is
interpreted as the:
- Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)+CT(0)
For example, a network administrator using one Class-Type for Voice
and one Class-Type for data might configure on a given link:
- Maximum Reservable Bandwidth for Voice + Data = 2.5 Gb/s
- Maximum Reservable Bandwidth for Voice = 1.5 Gb/s
3.2. Preemption Model
The preemption attribute defined in [TE-REQ] is retained for all
Class-Types. The preemption attributes of setup priority and holding
priority retain existing semantics, and in particular the preemption
operates independently of class-types. This means that if LSP1
contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has
a higher preemption priority regardless of LSP1's CT and LSP2's CT.
In other words, the solution offers 8 preemption priority levels to
be used by LSPs completely orthogonally to the LSP's Class-Type.
Just for illustration purposes, a Service Provider using two Class-
Types, may elect to configure:
- all Voice LSPs to preemption priority 0
- all Data LSPs to preemption priority 1
Le Faucheur et. al 3
Protocols for Diff-Serv-aware TE July 2001
in order to make sureVoice LSPs are never driven away from their
shortest path because ofData LSPs.
Another Service Provider may elect to configure:
- all large sizeVoice LSPs to preemption priority 0
- all large size Data LSPs to preemption priority 1
- all small size Voice LSPs to preemption priority 2
- all small size Data LSPs to preemption priority 3
in order to try to optimize global network resource utilization by
favoring placement of large LSPs first.
3.3. IGP Advertisement
This solution takes the straightforward approach of advertising for
each active Class-Type the same bandwidth information as currently
advertised for aggregate TE i.e. for each Class-Type advertise the
"unreserved Bandwidth" at each preemption level. This "unreserved
bandwidth" takes account of all the potential constraints that may
apply to the considered Class-Type. Details on how to compute the
"unreserved bandwidth for CT(N)" are provided in Appendix A.
In order to minimize the size of IGP advertisement, a compression
scheme is proposed below so that no bandwidth information is encoded
for preemption levels which are not actually used within a Class-
Type.
Note that no information needs to be advertised for a Class-Type
which is not actually used in a given network.
3.4. LSP Set-up
This solution specifies that the TE-LSP signaling protocols (RSVP-
TE, CR-LDP) signal the Class-Type of the LSP. This is used by LSRs
so that the local CAC enforces the bandwidth constraints relevant
to the LSP Class-Type and updates the corresponding counters for
reserved/unreserved bandwidth for the LSP Class-Type.
This also avoids the need for configuring on intermediate LSRs the
mapping between preemption and Class-Types.
3.5. Constraint Based Routing
Since the "unreserved bandwidth for CT(N)" advertised by the IGP
factors in all the potential bandwidth constraints affecting that
CT, the Constraint Based Routing algorithm is only required to
perform path computation satisfying a single bandwidth constraint.
Thus, no change is required on the existing TE Constraint Based
Routing algorithm. Only, this algorithm now considers the
"unreserved bandwidth" relevant to the particular CT and to the
particular preemption priority of the LSP for which the route is
computed.
Le Faucheur et. al 4
Protocols for Diff-Serv-aware TE July 2001
3.6. Diff-Serv scheduling
The Class-Type signaled by the TE-LSP signaling protocols can
optionally be used by LSRs to dynamically adjust the resources
allocated to a Class-Type by the Diff-Serv scheduler.
In addition, the Diff-Serv information (e.g. PSC) signaled by the
TE-LSP signaling protocols as specified in [DIFF-MPLS] can
optionally be used by LSRs to dynamically adjust the resources
allocated to a Class within a Class-Type by the Diff-Serv scheduler.
4. Protocol and Procedure Extensions
Protocol and Procedure Extensions for the DS-TE solution are
detailed in Appendix B.
5. Addressing DS-TE Detailed Requirements
This section discusses how this solution addresses each of the
detailed requirements for DS-TE identified in section 2 of [DSTE-
REQ].
5.1. DS-TE Compatibility
Since all the DS-TE extensions are above and beyond the existing TE
extensions, this solution raises no interoperability issues with
existing deployed TE mechanisms. Networks which do not require DS-TE
are not impacted in any way.
Since all extensions are on a per Class-Type basis and only used for
actually deployed Class-Types, the solution allows DS-TE deployment
to the required level of granularity and scope (e.g. only in a
subset of the topology, e.g. only for the number of Classes required
in the considered network)
5.2. Separate Bandwidth Constraints
The solutions allows configuration and enforcement of the specific
bandwidth constraints defined in [DSTE-REQ] i.e.:
- never route more than P(N-1)% of CT(N-1) on a given link
- never route more than P(N-2)% of CT(N-1)+CT(N-2) on that
link.
- etc.
- never route more than P(0)% of CT(N-1)+CT(N-2)+... + CT(0) on
that link,
where P(N-1), P(N-2), ..., P(0) are each configurable separately for
every link.
Le Faucheur et. al 5
Protocols for Diff-Serv-aware TE July 2001
More generally, the solution simultaneously supports the combination
of objectives on bandwidth constraints identified in [DSTE-REQ]:
"
- if a high priority class does not use up all of its bandwidth, the
next highest priority should be able to make use of this unused
bandwidth. For instance, in the above example with 3 Class-Types,
if CT2/EF is only using 30% (instead of its maximum 60%), then
CT1/AF should be able to use up to 50%. However, if CT2/EF is
using its 60%, it is obviously necessary to limit CT1/AF to much
below 50% (i.e. to 20% in our example) in order to maintain CT2's
performance levels.
- If a lower priority class (e.g. AF) used some of the unused
bandwidth of a higher priority class (e.g. EF), the high priority
class should be able to reclaim this bandwidth where necessary
(i.e. preempt lower priority class - see section 2.5)
- lower priority class-Types (e.g Best Effort) should not be
completely starved by higher priority classes.
- Highest priority classes, should only be routed away from their
shortest path when they would exceed their own bandwidth
constraints. They should not be routed away from their shortest
path because of lower priority classes.
"
For example, let's assume the network administrator configures:
- Max Reservable bandwidth for CT2/EF= 60%
- Max Reservable bandwidth for CT2/EF + CT1/AF= 80%
- Max Reservable bandwidth for CT2/EF + CT1/AF + CT0/BE = 100%
- Preemption Priority of CT2 LSPs is high
- Preemption Priority of CT1 LSPs is medium
- Preemption Priority of CT0 LSPs is low
Then,
- if CT2 LSPs do not use up all the 60%, whatever's left can be used
by CT1 (or CT0 if not used by CT1)
- If CT1+CT2 LSPs do not use up all the 80%, whatever's left can be
used by CT0
- If CT1 or CT0 LSPs are using some of CT2's 60%, then new CT2 LSPs
will be able to preempt some CT0 (and if necessary CT1) LSPs until
CT2 LSPs use the full 60%, since the preemption priority operates
across Class-Types
- CT1 is never starved since it will always be able to use at least
80-60=20%
- CT0 is never starved since it will always be able to use at least
100-80=20%
- Since they are configured with higher preemption priority, CT2
LSPs will only be routed away from their shortest path if CT2 is
using its 60%, never because of the amount of CT1 or CT0 LSPs
established.
5.3. Number of Class-Types
The DS-TE solution supports the required 4 Class-Types.
Le Faucheur et. al 6
Protocols for Diff-Serv-aware TE July 2001
In a given network, the solution does not force the network
administrator to support the maximum number of Class-Types. The
network administrator may deploy DS-TE for only 2, for only 3 or for
4 Class-Types.
The solution minimizes the scalability impact when low number of
Class-Types are actually deployed because extensions are on a per-CT
basis and are only used for CTs actually deployed.
The solution can be extended to any arbitrary number of Class-Types
simply by replicating the per-CT extensions.
5.4. Number of Classes
The solution does not constrain the number of classes that can be
grouped in a Class-Type.
5.5. Preemption
5.5.1. Preemption Within a Class-Type
Since preemption is defined independently of Class-Types, the
solution supports multiple preemption priorities within a given
Class-Type. To allow preemption among two LSPs of the same CT, the
network administrator only need to configure the two LSPs with
different preemption priorities.
The solution also allows preemption to be disabled within a Class-
Type by simply configuring all LSPs of a given CT to the same
preemption priority.
5.5.2. Preemption Across Class-Types
Since preemption is defined independently of Class-Types, the
solution supports multiple preemption priorities across Class-Types.
To allow preemption among two LSPs of different CTs, the network
administrator only need to configure the two LSPs with different
preemption priorities.
The solution also allows preemption to be disabled across Class-
Types by simply configuring all LSPs of the considered CTs to the
same preemption priority.
5.6. Resource Class Affinity
The solution allows separate configuration of Resource Class
Affinity attributes for each DS-TE tunnel.
5.7. Traffic Mapping
The solution supports traffic mapping as defined in [DSTE-REQ].
Le Faucheur et. al 7
Protocols for Diff-Serv-aware TE July 2001
5.8. Dynamic Adjustment of Diff-Serv PHBs
The solution allows optional adjustment of Diff-Serv PHBs parameters
(e.g. queue bandwidth) based on the amount of TE-LSPs established
for each Class/Class-Type. The Class-Type signaled in TE LSP
signaling protocol can be used for that purposes.
The solution allows for disabling dynamic adjutment via
configuration (thus reverting to PHB treatment with static scheduler
configuration independent of DS-TE operations).
The solution allows dynamic adjustment to take account of the
performance requirements of each class when computing required
adjustments.
5.9. Multiple TE Metrics
The solution can make immediate use of multiple TE metrics once
those are available simply by allowing TE-LSPs for different Classes
of Service to be routed based on a different TE Metric.
5.10. Conclusion
The solution addresses every detailed requirements of [DSTE-REQ].
6. Solution Evaluation
This section discusses how this solution fares against each of the
evaluation criteria identified in section 3 of [DSTE-REQ].
6.1. Addressing Scenarios
The solution addresses all the scenarios described in section 1.
Examples of how the solution can be deployed to address each
scenario are provided in Appendix C.
6.2. Flexibility
The solution supports the number of Class Types identified in [DSTE-
REQ].
The solution supports any arbitrary number of Classes within a
Class-Type
6.3. Extendibility
The solution can be easily extended to support any arbitrary number
of Class-Types that may be required in the future.
6.4. Scalability
Le Faucheur et. al 8
Protocols for Diff-Serv-aware TE July 2001
6.4.1. Path Computation
Path computation is often the most taxing task on the router CPU and
thus the most determinant in terms of IGP scalability, so we
consider this aspect first.
TE/DS-TE typically triggers Constraint Based Routing path
computation on events such as:
1) activation of a TE-LSP
2) reoptimisation timers
3) notification (by TE-LSP signaling protocol or IGP) that a
link on current path of a TE-LSP becomes invalid.
However, TE/DS-TE does not trigger Constraint Based Routing path
computation because of changes in "Unreserved Bandwidth" information
advertised by the IGP. "Unreserved Bandwidth" information will be
used in the future whenever a new path computation is performed but
changes in these value do not directly trigger Constraint Based
Routing path computation.
Since the IGP extensions proposed in this solution only contain
"unreserved Bandwidth" information, our first conclusion is that
this solution does not affect how frequently Constraint Based
Routing path computation is run compared to existing TE.
Secondly, since path computation is performed with the same
algorithm as aggregate TE (but simply considering a different value
of "unreserved bandwidth"), the solution does not have any
significant impact on the time it takes to execute a path
computation.
In short, this solution advertises more information that goes into
the TE topology database but does not significantly affect how often
path computation is run nor the time it takes to run the path
computation.
Consequently, when considering the predominant aspect of IGP
scalability which is path computation, we feel that the proposed DS-
TE solution has no significant scalability impact as compared to
existing TE.
6.4.2. Processing of a received LSP/LSA
Processing a received LSP/LSA and storing its content in the
topology database involves a significant proportion of processing
which is fairly independent of the actual LSP/LSA content (e.g.
parsing, checks, database access). We expect that increasing the
size of the TE TLV by (in worst case) 35 octets (new Sub-TLV
comprises 1 octet for T, 1 octet for L, and 33 octets worst case for
V) per Class-Type would result in no significant overhead in terms
of pure LSP/LSA processing.
Le Faucheur et. al 9
Protocols for Diff-Serv-aware TE July 2001
In normal IGP operations, increase in amount of information
contained in an LSP/LSA potentially affects CPU load (and thus
scalability) because this increases the likelihood of "significant
changes" which can trigger SPF computation. However, as discussed
above, this does not apply to "Unreserved Bandwidth" information
which does not trigger TE/DS-TE path computation.
Thus, the proposed IGP extensions are expected to result in no
significant impact from the viewpoint of processing a received
LSP/LSA.
6.4.3. Generating an LSP/LSA
Similarly generating a LSP/LSA involves a significant proportion of
processing which is fairly independent of the actual LSP/LSA
content. Increasing the size of the TE TLV by 35 octets per Class-
Type is expected to result in no significant overhead in terms of
pure LSP/LSA generation.
6.4.4. Increased Flooding Frequency
In addition to usual IGP flooding triggers, TE/DS-TE implementations
usually also trigger IGP flooding updates via thresholds on local
"Unreserved Bandwidth" values. Since DS-TE maintains more
"Unreserved Bandwidth" values it is expected that this may result in
more frequent generation/reception of LSPs/LSAs.
However, as explained above, this would result in more frequent
generation and processing of LSP/LSA but would not result in more
frequent path computation which is the prime consideration. Also, we
would expect the frequency increase factor to be typically much
below the number of Class-Types since there are correlation between
"unreserved Bandwidth" values changes across Class-Types. So this is
not expected to result in a significant scalability impact.
We also observe that in environments where a given preemption level
is only used by a single Class-Type (as constrained by proposals
such as [DSTE-NOP]), this frequency increase would be identical with
proposals such as [DSTE-NOP] since the number of Unreserved
Bandwidth values which effectively change over time would be
identical with both approach and thus trigger exactly the same
thresholds.
6.4.5. TLV size
We have argued above that the proposed TLV size increase has
marginal impact on CPU load. This section looks more precisely at
the TLV size increase in order to relate this to the hard size
limits of IGP advertisement.
Activating Aggregate TE results in the advertisement of the extended
IS reachability TLV which comprises (at least) 82 bytes (see [ISIS-
Le Faucheur et. al 10
Protocols for Diff-Serv-aware TE July 2001
TE]: 1 octet of T, 1 octet of L, 11 octets of data structure, 7 x 1
octet of T for each sub-TLV, 7x1 octet of L for each sub-TLV, and 55
octets of V for all the sub-TLV Vs). Activating the DS-TE solution
described in this document results in increasing the size of the
extended IS reachability TLV of (P*4)+3 octets [1 octet of T, 1
octet of L and (P*4)+1 octets of V] per Class-Type beyond CT0 (where
1<=P<=8, depending on the number of preemption levels actually used
by the Class-Type in addition to preemption level zero).
Thus, in the worst case where all the 8 preemption levels are used
by every Class-Type, this DS-TE solution increases the TLV size by
35 octets per Class-Type beyond the 82 octets with TE.
In a situation where each Class-Type uses a single level of
preemption (which is not preemption zero), this DS-TE solution
increases the TLV size by 11 octets only per Class-Types beyond the
82 octets with TE.
As a typical example, in DS-TE deployment with 3 Class-Types (ie 2
CTs beyond CT0) each with a single level of preemption, the DS-TE
solution has increased TLV size from 82 to 104 octets.
Thus, we do not expect this solution to result in an issue with
respect to maximum TLV size since we are still well below the
maximum sub-TLV size of 255 bytes. We also do not expect such size
increase to result in issues regarding maximum LSP size (which are
being worked on in IETF anyway).
6.4.6. Database Size
As more information is advertised with the proposed solution
compared to TE, the TE topology database size would increase
compared to existing TE.
If we take the worst case of all 4 Class-Types being deployed (i.e.
3 CTs beyond CT0) and all preemption levels being used by every
Class-Type, then the solution would result in an extra 35x3=105bytes
per TLV. Although this information is often encoded in a different
format when stored in the topology database, it would be of the same
order of magnitude. So increase in database size is O(100byte) per
TLV. Thus, if we consider a network with 1,000 links, we expect the
database size impact to be O(100 kbytes). In a network of 10,000
links, we expect the database size impact to be O(1Mbyte).
Thus we expect the impact of the solution on database size to be
acceptable even in worst case of 4 Class-Types and in large
networks.
6.4.7. Tunnel Signaling
Because accurate unreserved bandwidth information is advertised to
all head-ends for each CT and for each preemption, the solution does
Le Faucheur et. al 11
Protocols for Diff-Serv-aware TE July 2001
not result in any unnecessary tunnel establishment failure/retry
(beyond the inevitable ones due to database de-synchronization in
between floodings) and thus does not have any scalability impact in
terms of tunnel signaling nor path (re)computation.
6.4.8. Link Bandwidth consumed by advertisement
It is the belief of the authors that because of typical link speeds
used in Service Provider networks, bandwidth consumed by IGP
advertisements is not a significant scalability constraint per say.
Increase in consumed link bandwidth as per this solution would not
change this.
6.4.9. Scalability Conclusions
Our assessment is that the DS-TE solution proposed above only has a
marginal impact on IGP scalability compared to existing TE.
Although not entirely intuitive at first glance, this conclusion can
be primarily explained by the combination of those facts:
- IGP scalability is predominantly constrained by CPU load
- CPU load is predominantly due to path computation
- IGP extensions proposed by this solution do not affect frequency
nor affect significantly complexity of path computation.
We also feel that the small delta in scalability impact between this
approach and approaches which may attempt to minimize the amount of
information advertised in the IGP such as [DSTE-NOP] is outweighted
by
(i) the resulting flexibility including:
- any CT can use any subset of the 8 preemption priorities
- preemption is possible within CTs and across CTs
- distribution of preemption priorities used by each CT
can be modified at any time by the Service Provider
without any change on the IGP configuration
(ii) the smooth handling of any migration scenario:
- TE LSRs can be gradually upgraded to DS-TE LSRs and DS-
TE will dynamically be able to operate on all upgraded
LSRs as they get upgraded
- LSRs can be gradually reconfigured to support a new CT
and DS-TE will dynamically be able to establish Tunnels
of the new CT on all upgraded LSRs as they get upgraded.
(iii) its operational resiliency:
- information on relationship between CT and preemption is
encoded in IGP advertisement avoiding reliance on
consistent configuration throughout the whole network.
We are seeking other opinions on this trade-off between scalability
delta Versus flexibility/easier operations.
6.5. Backward compatibility/Migration
6.5.1. Backward compatibility/Migration with existing TE
Le Faucheur et. al 12
Protocols for Diff-Serv-aware TE July 2001
Because the solution only proposes extensions over the existing
aggregate TE mechanisms which are left unchanged, it is fully
compatible with existing TE mechanisms. DS-TE can be deployed in an
environment supporting aggregate TE without any migration.
In particular, the following is supported for smooth migration:
- operations in heterogeneous environments where some LSRs are
Diff-Serv-TE-capable while some other LSRs are not Diff-Serv-
TE-capable (i.e. support aggregate TE only)
- in such heterogeneous environments, the solution allows
establishment of Class-Type 0 LSPs across paths combining Diff-
Serv-TE-capable LSRs and non-Diff-Serv-TE-capable LSRs
- in such heterogeneous environments, the solution ensures that a
non-Diff-Serv-TE-capable LSR would reject establishment of a
Class-Type N (N=1,2,3) LSP.
6.5.2. Backward Compatibility/Migration with Changing Number of CTs
Because the solution proposes separate extensions for each Class-
Type, a Class-Type can be added or removed from a given deployment
without any migration/compatibility issue.
In particular, the following is supported for smooth migration when
increasing/deceasing number of CTs:
- operations in heterogeneous environments where some Diff-Serv-
TE-capable LSRs (as defined in this specification) support N
Class-Types while other Diff-Serv-TE-capable LSRs support M
Class-Types with M>N.
- in such heterogeneous environments, the solution allows
establishment of Class-Type 0,.., N-1 LSPs across paths
combining both types of LSRs
- in such heterogeneous environments, the solution ensures that a
Diff-Serv-TE-capable LSR supporting only N Class-Types would
reject establishment of a Class-Type X LSP if N<=X<=M-1.
6.5.3. Backward Compatibility/Migration with Changing Distribution of
Preemption Across CTs
Because the solution proposes extensions allowing all eight
preemption priorities by each CT, a CT can start/stop using any
preemption level priorities without any migration/compatibility
issue and without any reconfiguration of IGP on LSRs.
7. 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.
Le Faucheur et. al 13
Protocols for Diff-Serv-aware TE July 2001
8. Acknowledgments
This document has benefited from the expertise of Carol Iturralde,
Stefano Previdi and Jean-Philippe Vasseur.
References
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-
01.txt, June 2001.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
draft-katz-yeung-ospf-traffic-05.txt, June 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-traffic-03.txt, June 2001.
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-05.txt, February 2001
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft-
ietf-mpls-diff-ext-09.txt, April 2001
[DIFF-NEW] Grossman, "New Terminology for Diffserv", work in
progress, draft-ietf-diffserv-new-terms-04.txt, March 2001.
[DSTE-NOP] Boyle, "Accomplishing Diffserv TE needs with Current
Specifications", draft-boyle-tewg-ds-nop-00.txt, July 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
Martin Tatham
BT
Adastral Park,
Martlesham Heath,
Ipswich IP5 3RE
UK
Le Faucheur et. al 14
Protocols for Diff-Serv-aware TE July 2001
Phone: +44-1473-606349
Email: martin.tatham@bt.com
Angela Chiu
Celion Networks
1 Sheila Drive, Suite 2
Tinton Falls, NJ 07724
Phone: +1-732 747 9987
Email: angela.chiu@celion.com
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
Email: tnadeau@cisco.com
Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9
Phone: +1-613-765-2252
Email: dareks@nortelnetworks.com
Pete Hicks
CoreExpress, Inc
12655 Olive Blvd, Suite 500
St. Louis, MO 63141
USA
Phone: (314) 317-7504
Email: pete.hicks@coreexpress.net
Le Faucheur et. al 15
Protocols for Diff-Serv-aware TE July 2001
Appendix A - Computing "Unreserved Bandwidth for CT-N"
This Appendix defines how the "unreserved bandwidth for CT-N" is
computed for IGP advertisment as well as for local admission control
of DS-TE LSPs by LSRs.
Imagine the Service Provider configured:
- Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)= 100 Mb/s
- Maximum Reservable bandwidth for CT(3)+CT(2)+CT(1)+CT(0)=155
Mb/s
Say that, at the considered preemption priority, there is currently:
- 0 Mb/s of CT(3) LSPs
- 0 Mb/s of CT(2) LSPs
- 90 Mb/s of CT(1) LSPs
- 10 Mb/s of CT(0) LSPs
then, the bandwidth "reservable" (aka. "unreserved") for new CT(1)
LSPs is 100-90=10 Mb/s and is effectively constrained by the "Max
Reservable bandwidth for CT(3)+CT(2)+CT(1)"
Now say that, at the considered preemption priority, there is
currently:
- 0 Mb/s of CT(3) LSPs
- 0 Mb/s of CT(2) LSPs
- 10 Mb/s of CT(1) LSPs
- 100 Mb/s of CT(0) LSPs
then, the bandwidth "reservable" (aka. "unreserved") for new CT(1)
LSPs is 155-10-100=45 Mb/s and, this time, is effectively
constrained by the "Max Reservable bandwidth for
CT(3)+CT(2)+CT(1)+CT(0)"
More generally, the bandwidth "reservable" (aka. "unreserved") for
new LSPs of CT(N), at a considered preemption priority, is computed
as the smallest of:
- the CT(3)+CT(2)+CT(1)+CT(0) bandwidth currently unreserved
(i.e. the difference between the "Maximum Reservable
Bandwidth for CT(3)+CT(2)+CT(1)+CT(0) and the bandwidth
reserved by LSPs of CT(0) and CT(1) and CT(2) and CT(3)).
- . . .
- the CT(3)+ . . . +CT(1) bandwidth currently unreserved (i.e.
the difference between the "Maximum Reservable Bandwidth for
CT(3)+ . . . +CT(N) and the bandwidth reserved by LSPs of
CT(N) and . . . and CT(3)).
Le Faucheur et. al 16
Protocols for Diff-Serv-aware TE July 2001
Appendix B - Protocol and Procedure Extensions
9. ISIS Extensions
In this section we describe the extensions to IS-IS for support of
DS-TE. These extensions are in addition to the extensions required
to support (aggregate) MPLS Traffic Engineering defined in [ISIS-
TE].
9.1. Existing TE sub-TLVs
[ISIS-TE] defines new extended TLVs for support of (aggregate)
Traffic Engineering. One of these extended TLV is referred to as the
extended IS reachability TLV (TLV type 22). This TLV contains a
number of new sub-TLVs.
In this document we refer to the sub-TLV 10 (Maximum reservable link
bandwidth) of the extended IS reachability TLV (as defined in [ISIS-
TE]) as the "Maximum Reservable Bandwidth for
CT(3)+CT(2)+CT(1)+CT(0)".
We also refer to the sub-TLV 11 (unreserved bandwidth) of the
extended IS reachability TLV (as defined in [ISIS-TE]) as the
"Unreserved Bandwidth for Class-Type 0".
9.2. New Sub-TLVs
The following additional sub-TLVs are defined for the extended IS
reachability TLV (sub-TLV numbers to be allocated):
TBD1 - Unreserved bandwidth for Class-Type 1
TBD2 - Unreserved bandwidth for Class-Type 2
TBD3 - Unreserved bandwidth for Class-Type 3
Each sub-TLV may occur only once. Unrecognized types are ignored.
The additional sub-TLVs defined above are optional so that they may
or may not be included in the extended IS reachability TLV.
The extended IS reachability TLV may include the sub-TLVs for any
subset of the three additional Class-Types. In other words, the IS
reachability TLV may contain none of the three sub-TLVs defined
above, any one of those, any two of those, or the three sub-TLVs.
Where a Class-Type is not effectively used in a network, it is
recommended that the corresponding sub-TLV is not included in the IS
reachability TLV. Therefore, the Class-Types to be advertised in
ISIS should be configurable. For instance, a Network Administrator
may elect to use Diff-Serv Traffic Engineering in order to compute
separate routes for data traffic and voice traffic. In that case,
the IGP would be configured to only advertise the sub-TLV for one
additional Class-Type (i.e. the extended IS reachability TLV would
Le Faucheur et. al 17
Protocols for Diff-Serv-aware TE July 2001
contain sub-TLV 10 for the "Maximum Reservable Bandwidth for
CT(3)+CT(2)+CT(1)+CT(0)", sub-TLV 11 for the "Unreserved Bandwidth
for Class-Type 0" and sub-TLV TBD1 for "Unreserved Bandwidth for
Class-Type 1").
An LSR which supports Class-Type N and receiving an extended IS
reachability TLV without the sub-TLV corresponding to Class-Type N,
must interpret this as meaning that the corresponding link does not
support Class-Type N. For Constraint Based Routing purposes, the LSR
may consider this equivalent to the case where the extended IS
reachability TLV contains an Unreserved Bandwidth Class-Type N sub-
TLV with bandwidth values set to zero.
An LSR which does not support Class-Type N and which receives an
extended IS reachability TLV containing the sub-TLV corresponding to
Class-Type N, must ignore this sub-TLV. However, the IS reachability
TLV must be flooded transparently, so that the sub-TLV for Class-
Type N is kept in the IS reachability TLV when reflooded by this
LSR.
9.3. Sub-TLV Details
The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLVs
specifies the amount of bandwidth reservable by Class-Type N LSPs at
each of the eight preemption priority levels. Details for computing
the Unreserved Bandwitdh for CT(N) are provided in Appendix A.
When the bandwidth value for preemption Z (Z > 0) is identical to
the bandwidth value for preemption Z-1, the bandwidth value for
preemption Z is not explicitly repeated in the sub-TLV. Rather, the
fact that it is identical to the value of preemption Z-1, is encoded
in a "repetition octet".
Thus, the sub-TLV comprises:
- P (1<=P<=8) bandwidth values. These values correspond to the
bandwidth that can be reserved with a holding priority of 0 through
7, arranged in increasing order with priority 0 occurring at the
start of the sub-TLV, and priority 7 towards the end of the sub-TLV,
but omitting all repeated values. The units are bytes per second and
the values are encoded in IEEE floating point format.
- a "repetition octet" where each bit is referred to as bitZ ,
0 <= Z < 8, and is defined to have the following meaning:
* if bitZ = 0 then "Unreserved Bandwidth" for preemption
level Z is explicitely included in the sub-TLV,
* if bitZ = 1 then "Unreserved Bandwidth" for preemption
level Z is not explicitely included in the sub-TLV but is
defined to be equal to "Unreserved Bandwidth" for preemption
level Z-1.
Le Faucheur et. al 18
Protocols for Diff-Serv-aware TE July 2001
Note that the highest preemption level (level 0) is always
advertised and the first bit (Bit0) in the "repetition octet" is
always set to 0.
[Editor's note: should the "repetition octet" be moved before the
bandwidth values?]
The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type
(TBDN). Its length is (P*4 +1), where 1<=P<=8 and where P is the
number of non-equal bandwidth values across all preemption levels
for that Class-Type.
For example, when a link supports LSPs of preemption levels 2 and 4
only (for a particular Class-Type) with "Unreserved Bandwidth" (for
the particular Class-Type) on that link for preemption levels 0, 2,
and 4 currently of 10Mb/s, 5Mb/s and 3Mb/s, respectively, then
"Unreserved Bandwidth" (for the particular Class-Type) for
preemption levels 0, 2, and 4 of 10Mb/s, 5Mb/s and 3Mb/s,
respectively, are explicitly advertised for that link as well as
"repetition octet" of 01010111 in binary form. The sub-TLV length is
13.
10. OSPF Extensions
In this section we describe the extensions to OSPF for support of
DS-TE. These extensions are in addition to the extensions already
defined for support of (aggregate) MPLS Traffic Engineering in
[OSPF-TE].
10.1. Existing TE Sub-TLVs
[OSPF-TE] defines a new LSA for support of (aggregate) Traffic
Engineering, which is referred to as the Traffic Engineering LSA.
This LSA contains a Link TLV (Type 2) comprising a number of sub-
TLVs.
In this document we refer to the sub-TLV 7 (maximum reservable
bandwidth) of the Link TLV (as defined in [OSPF-TE]) as the "Maximum
Reservable Bandwidth for CT(3)+CT(2)+CT(1)+CT(0)".
We also refer to the sub-TLV 8 (unreserved bandwidth) of the Link
TLV (as defined in [OSPF-TE]) as the "Unreserved Bandwidth for
Class-Type 0".
10.2. New Sub-TLVs
The following additional sub-TLVs are defined for the Link TLV of
the Traffic Engineering LSA (sub-TLV numbers to be allocated)
TBD1' - Unreserved Bandwidth for Class-Type 1 (32 octets)
TBD2' - Unreserved Bandwidth for Class-Type 2 (32 octets)
Le Faucheur et. al 19
Protocols for Diff-Serv-aware TE July 2001
TBD3' - Unreserved Bandwidth for Class-Type 3 (32 octets)
The rules relating to which of this new OSPF sub-TLV is present in
the Link TLV are the same as the rules presented in section 3.1.2
relating to which new IS-IS sub-TLV is present in the extended IS
reachability TLV.
10.3. Sub-TLV Details
The encoding for the new OSPF Sub-TLV is identical to the one for
IS-IS described above in section 3.1.3.
11. RSVP Extensions
In this section we describe extensions to RSVP for support of DS-TE.
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.
11.1. Diff-Serv 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 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 DS-TE in compliance with this specification MUST
support the CLASSTYPE Object. It MUST support Class-Type value 1,
and MAY support other Class-Type values.
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 20
Protocols for Diff-Serv-aware TE July 2001
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
11.2. 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 : 30 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
CT : 2 bits
Indicates the Class-Type. Values currently allowed are 1, 2 and
3.
11.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 (N=1,2,3), 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 records the CLASSTYPE object, when present,
in its path state block.
Le Faucheur et. al 21
Protocols for Diff-Serv-aware TE July 2001
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 "unreserved bandwidth"
for that particular Class-Type, which is computed as defined in
Appendix A.
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 TE Error' and an error value of 'Unexpected
CLASSTYPE object'. Those are defined below in section 4.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 TE Error' and an error value of 'Unsupported Class-
Type'. Those are defined below in section 4.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 TE Error' and an
error value of 'Invalid Class-Type value'. Those are defined below
in section 4.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).
11.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).
Le Faucheur et. al 22
Protocols for Diff-Serv-aware TE July 2001
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.
11.5. Error Codes For Diff-Serv TE
In the procedures described above, certain errors must be reported
as a 'Diff-Serv TE Error'. The value of the 'Diff-Serv TE Error'
error code is (TBD).
The following defines error values for the Diff-Serv TE Error:
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
12. CR-LDP Extensions
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 DS-TE. 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
Traffic Engineering are not applicable to LDP due to the fact that
LDP does not support MPLS Traffic Engineering and bandwidth
reservation in particular.
12.1. Diff-Serv 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 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 per-Class-Type
Diff-Serv Traffic Engineering are not required to support this TLV.
An LSR supporting DS-TE 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.
Le Faucheur et. al 23
Protocols for Diff-Serv-aware TE July 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
12.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 : 30 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
CT : 2 bits
Indicates the Class-Type. Values currently allowed are 1, 2 and
3.
12.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.
Le Faucheur et. al 24
Protocols for Diff-Serv-aware TE July 2001
If the LSP is associated with Class-Type N (N=1,2,3), 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).
During establishment of an LSP corresponding to the Class-Type N, an
LSR performs admission control over the "unreserved bandwidth" for
that particular Class-Type, which is computed as defined in Appendix
A.
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 5.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 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 5.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 5.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).
12.4. Status Code Values for Diff-Serv TE
Le Faucheur et. al 25
Protocols for Diff-Serv-aware TE July 2001
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
Le Faucheur et. al 26
Protocols for Diff-Serv-aware TE July 2001
Appendix C - 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].
Scenario 1: High Proportion of Voice
By configuring on every link:
- Max Reservable Bandwidth for CT1/Voice = "certain percentage"
of link capacity
- Max Reservable Bandwidth for CT0+CT1(+CT2+CT3)= link capacity
By configuring:
- every CT1/Voice TE-LSP with preemption =0
- every CT0/Voice TE-LSP with preemption =1
The proposed solution will address all the requirements:
- 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
Scenario 2: Rerouting on Lower Speed Facilities
Using same configuration as for previous scenario, would ensure that
the amount of Voice traffic remains limited below desired percentage
on every link even after rerouting on lower speed facilities. This
in turn ensures QoS performance is preserved even after reroute on
lower speed facilities.
Scenario 3:
By configuring on every link:
- Max Reservable Bandwidth for CT2 = e.g. 45%
- Max Reservable Bandwidth for CT1+CT2 = e.g. 80%
- Max Reservable Bandwidth for CT0+CT1+CT2(+CT3)= 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.
Le Faucheur et. al 27
Protocols for Diff-Serv-aware TE July 2001
Scenario 4: Guaranteed Bandwidth Services
By using a separate Class-Type (e.g. CT1) for the Guaranteed
Bandwidth traffic and by configuring on every link:
- Max Reservable Bandwidth for CT1/guaranteed = "given
percentage" of link capacity
- Max Reservable Bandwidth for CT0+CT1(+CT2+CT3)= link capacity
The Proposed solution will address the requirements:
- the amount of guaranteed traffic wil always be below the
given percentage necessary to meet the QoS objectives of the
Guaranteed Bandwidth Service
- rest of the traffic/CT0 will be able to use all remaining
link capacity
Le Faucheur et. al 28
Datatracker
Report a datatracker bug
draft-lefaucheur-diff-te-proto-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |