Class-Type by the Diffserv scheduler. In addition, the Diffserv
information (i.e., the PSC) signaled by the TE-LSP signaling
protocols as specified in [DIFF-MPLS], if used, MAY optionally be
used by DS-TE LSRs to dynamically adjust the resources allocated by
the Diffserv scheduler to a PSC/OA within a CT.
10. Existing TE as a Particular Case of DS-TE
We observe that existing TE can be viewed as a particular case of
DS-TE where:
(i) a single Class-Type is used,
(ii) all 8 preemption priorities are allowed for that Class-Type,
and
(iii) the following TE-Class mapping is used:
TE-Class[i] <--> < CT0 , preemption i >
Where 0 <= i <= 7.
In that case, DS-TE behaves as existing TE.
As with existing TE, the IGP advertises:
- Unreserved Bandwidth for each of the 8 preemption priorities.
As with existing TE, the IGP may advertise:
- Maximum Reservable Bandwidth containing a BC applying across
all LSPs .
Because all LSPs transport traffic from CT0, RSVP-TE signaling is
done without explicit signaling of the Class-Type (which is only used
for Class-Types other than CT0, as explained in Section 6) as with
existing TE.
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules
11.1. Computing "Unreserved TE-Class [i]"
We first observe that, for existing TE, details on admission control
algorithms for TE LSPs, and consequently details on formulas for
computing the unreserved bandwidth, are outside the scope of the
current IETF work. This is left for vendor differentiation. Note
that this does not compromise interoperability across various
implementations because the TE schemes rely on LSRs to advertise
their local view of the world in terms of Unreserved Bw to other
LSRs. This way, regardless of the actual local admission control
algorithm used on one given LSR, Constraint-Based Routing on other
LSRs can rely on advertised information to determine whether an
additional LSP will be accepted or rejected by the given LSR. The
only requirement is that an LSR advertises unreserved bandwidth
values that are consistent with its specific local admission control
algorithm and take into account the holding preemption priority of
established LSPs.
In the context of DS-TE, again, details on admission control
algorithms are left for vendor differentiation, and formulas for
computing the unreserved bandwidth for TE-Class[i] are outside the
scope of this specification. However, DS-TE places the additional
requirement on the LSR that the unreserved bandwidth values
advertised MUST reflect all the BCs relevant to the CT associated
with TE-Class[i] in accordance with the Bandwidth Constraints Model.
Thus, formulas for computing "Unreserved TE-Class [i]" depend on the
Bandwidth Constraints Model in use and MUST reflect how BCs apply to
CTs. Example formulas for computing "Unreserved TE-Class [i]" Model
are provided for the Russian Dolls Model and Maximum Allocation Model
respectively in [DSTE-RDM] and [DSTE-MAM].
As with existing TE, DS-TE LSRs MUST consider the holding preemption
priority of established LSPs (as opposed to their setup preemption
priority) for the purpose of computing the unreserved bandwidth for
TE-Class [i].
11.2. Admission Control Rules
A DS-TE LSR MUST support the following admission control rule:
Regardless of how the admission control algorithm actually computes
the unreserved bandwidth for TE-Class[i] for one of its local links,
an LSP of bandwidth B, of setup preemption priority p and of Class-
Type CTc is admissible on that link if, and only if,:
B <= Unreserved Bandwidth for TE-Class[i]
where TE-Class [i] maps to < CTc , p > in the TE-Class mapping
configured on the LSR.
12. Security Considerations
This document does not introduce additional security threats beyond
those described for Diffserv ([DIFF-ARCH]) and MPLS Traffic
Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
security measures and procedures described in these documents apply
here. For example, the approach for defense against theft- and
denial-of-service attacks discussed in [DIFF-ARCH], which consists of
the combination of traffic conditioning at DS boundary nodes along
with security and integrity of the network infrastructure within a
Diffserv domain, may be followed when DS-TE is in use. Also, as
stated in [TE-REQ], it is specifically important that manipulation of
administratively configurable parameters (such as those related to
DS-TE LSPs) be executed in a secure manner by authorized entities.
13. IANA Considerations
This document creates two new name spaces that are to be managed by
IANA. Also, a number of assignments from existing name spaces have
been made by IANA in this document. They are discussed below.
13.1. A New Name Space for Bandwidth Constraints Model Identifiers
This document defines in Section 5.1 a "Bandwidth Constraints Model
Id" field (name space) within the "Bandwidth Constraints" sub-TLV,
both for OSPF and ISIS. The new name space has been created by the
IANA and they will maintain this new name space. The field for this
namespace is 1 octet, and IANA guidelines for assignments for this
field are as follows:
o values in the range 0-239 are to be assigned according to the
"Specification Required" policy defined in [IANA-CONS].
o values in the range 240-255 are reserved for "Private Use" as
defined in [IANA-CONS].
13.2. A New Name Space for Error Values under the "Diffserv-aware TE
Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in
an ERROR_SPEC object to define an error condition broadly. With each
Error Code there may be a 16-bit Error Value (which depends on the
Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the
"Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for
the "Diffserv-aware TE Error" constitute a new name space to be
managed by IANA.
This document defines, in Section 6.5, values 1 through 7 in that
name space (see Section 13.3.5).
Future allocations of values in this name space are to be assigned by
IANA using the "Specification Required" policy defined in
[IANA-CONS].
13.3. Assignments Made in This Document
13.3.1. Bandwidth Constraints sub-TLV for OSPF Version 2
[OSPF-TE] creates a name space for the sub-TLV types within the "Link
TLV" of the Traffic Engineering Link State Advertisement (LSA) and
rules for management of this name space by IANA.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth
Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with
the IANA considerations provided in [OSPF-TE], a sub-TLV type in the
range 10 to 32767 was requested, and the value 17 has been assigned
by IANA for the "Bandwidth Constraints" sub-TLV.
13.3.2. Bandwidth Constraints sub-TLV for ISIS
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS
"Extended IS Reachability" TLV and rules for management of this name
space by IANA.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth
Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV.
In accordance with the IANA considerations provided in [ISIS-TE], a
sub-TLV type was requested, and the value 22 has been assigned by
IANA for the "Bandwidth Constraints" sub-TLV.
13.3.3. CLASSTYPE Object for RSVP
[RSVP] defines the Class Number name space for RSVP object, which is
managed by IANA. Currently allocated Class Numbers are listed at
http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.2.1 a new RSVP object, the
CLASSTYPE object. IANA has assigned a Class Number for this RSVP
object from the range defined in Section 3.10 of [RSVP] for objects
that, if not understood, cause the entire RSVP message to be rejected
with an error code of "Unknown Object Class". Such objects are
identified by a zero in the most significant bit of the class number
(i.e., Class-Num = 0bbbbbbb).
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is
defined in this document for the CLASSTYPE object.
13.3.4. "Diffserv-aware TE Error" Error Code
[RSVP] defines the Error Code name space and rules for management of
this name space by IANA. Currently allocated Error Codes are listed
at http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.5 a new RSVP Error Code, the
"Diffserv-aware TE Error". In accordance with the IANA
considerations provided in [RSVP], Error Code 28 was assigned by IANA
to the "Diffserv-aware TE Error".
13.3.5. Error Values for "Diffserv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in
an ERROR_SPEC object to define an error condition broadly. With each
Error Code there may be a 16-bit Error Value (which depends on the
Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the
"Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for
the "Diffserv-aware TE Error" constitute a new name space to be
managed by IANA.
This document defines, in Section 6.5, the following Error Values for
the "Diffserv-aware TE Error":
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a configured
TE-Class
6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not
form a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type
8 Inconsistency between signaled PHBs and signaled
Class-Type
See Section 13.2 for allocation of other values in that name space.
14. Acknowledgements
We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier
contribution in this work. We also thank Sanjaya Choudhury for his
thorough review and suggestions.
Appendix A: Prediction for Multiple Path Computation
There are situations where a head-end needs to compute paths for
multiple LSPs over a short period of time. There are potential
advantages for the head-end in trying to predict the impact of the
n-th LSP on the unreserved bandwidth when computing the path for the
(n+1)-th LSP, before receiving updated IGP information. For example,
better load-distribution of the multiple LSPs would be performed
across multiple paths. Also, when the (n+1)-th LSP would no longer
fit on a link after establishment of the n-th LSP, the head-end would
avoid Connection Admission Control (CAC) rejection. Although there
are a number of conceivable scenarios where worse situations might
result, doing such predictions is more likely to improve situations.
As a matter of fact, a number of network administrators have elected
to use such predictions when deploying existing TE.
Such predictions are local matters, are optional, and are outside the
scope of this specification.
Where such predictions are not used, the optional BC sub-TLV and the
optional Maximum Reservable Bandwidth sub-TLV need not be advertised
in IGP for the purpose of path computation, since the information
contained in the Unreserved Bw sub-TLV is all that is required by
Head-Ends to perform Constraint-Based Routing.
Where such predictions are used on head-ends, the optional BCs sub-
TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be
advertised in IGP. This is in order for the head-ends to predict as
accurately as possible how an LSP affects unreserved bandwidth values
for subsequent LSPs.
Remembering that actual admission control algorithms are left for
vendor differentiation, we observe that predictions can only be
performed effectively when the head-end LSR predictions are based on
the same (or a very close) admission control algorithm as that used
by other LSRs.
Appendix B: Solution Evaluation
B.1. Satisfying Detailed Requirements
This DS-TE Solution addresses all the scenarios presented in
[DSTE-REQ].
It also satisfies all the detailed requirements presented in
[DSTE-REQ].
The objective set out in the last paragraph of Section 4.7 of
[DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE
solution. Through support of the "LSP size Overbooking" and "Link
Size Overbooking" methods, this DS-TE solution effectively allows CTs
to have different overbooking ratios and simultaneously allows
overbooking to be tweaked differently (collectively across all CTs)
on different links. But, in a general sense, it does not allow the
effective overbooking ratio of every CT to be tweaked differently in
different parts of the network independently of other CTs, while
maintaining accurate bandwidth accounting of how different CTs
mutually affect each other through shared BCs (such as the Maximum
Reservable Bandwidth).
B.2. Flexibility
This DS-TE solution supports 8 CTs. It is entirely flexible as to
how Traffic Trunks are grouped together into a CT.
B.3. Extendibility
A maximum of 8 CTs is considered more than comfortable by the authors
of this document. A maximum of 8 TE-Classes is considered sufficient
by the authors of this document. However, this solution could be
extended to support more CTs or more TE-Classes if deemed necessary
in the future; this would necessitate additional IGP extensions
beyond those specified in this document.
Although the prime objective of this solution is support of
Diffserv-aware Traffic Engineering, its mechanisms are not tightly
coupled with Diffserv. This makes the solution amenable, or more
easily extendable, for support of potential other future Traffic
Engineering applications.
B.4. Scalability
This DS-TE solution is expected to have a very small scalability
impact compared to that of existing TE.
From an IGP viewpoint, the amount of mandatory information to be
advertised is identical to that of existing TE. One additional sub-
TLV has been specified, but its use is optional, and it only contains
a limited amount of static information (at most 8 BCs).
We expect no noticeable impact on LSP Path computation because, as
with existing TE, this solution only requires Constrained Shortest
Path First (CSPF) to consider a single unreserved bandwidth value for
any given LSP.
From a signaling viewpoint, we expect no significant impact due to
this solution because it only requires processing of one additional
item of information (the Class-Type) and does not significantly
increase the likelihood of CAC rejection. Note that DS-TE has some
inherent impact on LSP signaling in that it assumes that different
classes of traffic are split over different LSPs so that more LSPs
need to be signaled. However, this is due to the DS-TE concept
itself and not to the actual DS-TE solution discussed here.
B.5. Backward Compatibility/Migration
This solution is expected to allow smooth migration from existing TE
to DS-TE. This is because existing TE can be supported as a
particular configuration of DS-TE. This means that an "upgraded" LSR
with a DS-TE implementation can directly interwork with an "old" LSR
supporting existing TE only.
This solution is expected to allow smooth migration when the number
of CTs actually deployed is increased, as it only requires
configuration changes. However, these changes need to be performed
in a coordinated manner across the DS-TE domain.
Appendix C: Interoperability with Non-DS-TE Capable LSRs
This DSTE solution allows operations in a hybrid network where some
LSRs are DS-TE capable and some are not, as may occur during
migration phases. This appendix discusses the constraints and
operations in such hybrid networks.
We refer to the set of DS-TE-capable LSRs as the DS-TE domain. We
refer to the set of non-DS-TE-capable (but TE-capable) LSRs as the
TE-domain.
Hybrid operations require that the TE-Class mapping in the DS-TE
domain be configured so that:
- a TE-Class exists for CT0 for every preemption priority
actually used in the TE domain, and
- the index in the TE-class mapping for each of these TE-
Classes is equal to the preemption priority.
For example, imagine the TE domain uses preemption 2 and 3. Then,
DS-TE can be deployed in the same network by including the following
TE-Classes in the TE-Class mapping:
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3
Another way to look at this is to say that although the whole TE-
class mapping does not have to be consistent with the TE domain, the
subset of this TE-Class mapping applicable to CT0 effectively has to
be consistent with the TE domain.
Hybrid operations also require that:
- non-DS-TE-capable LSRs be configured to advertise the Maximum
Reservable Bandwidth, and
- DS-TE-capable LSRs be configured to advertise BCs (using the
Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV,
as specified in Section 5.1).
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs
unambiguously.
Finally, hybrid operations require that non-DS-TE-capable LSRs be
able to accept Unreserved Bw sub-TLVs containing non decreasing
bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p <
q).
In such hybrid networks, the following apply:
- CT0 LSPs can be established by both DS-TE-capable LSRs and
non-DS-TE-capable LSRs.
- CT0 LSPs can transit via (or terminate at) both DS-TE-capable
LSRs and non-DS-TE-capable LSRs.
- LSPs from other CTs can only be established by DS-TE-capable
LSRs.
- LSPs from other CTs can only transit via (or terminate at)
DS-TE-capable LSRs.
Let us consider the following example to illustrate operations:
LSR0--------LSR1----------LSR2
Link01 Link12
where:
LSR0 is a non-DS-TE-capable LSR
LSR1 and LSR2 are DS-TE-capable LSRs
Let’s assume again that preemptions 2 and 3 are used in the TE-domain
and that the following TE-Class mapping is configured on LSR1 and
LSR2:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unused
LSR0 is configured with a Max Reservable Bandwidth = m01 for Link01.
LSR1 is configured with a BC0 = x0, a BC1 = x1 (possibly = 0), and a
Max Reservable Bandwidth = m10 (possibly = m01) for Link01.
In IGP for Link01, LSR0 will advertise:
- Max Reservable Bw sub-TLV = <m01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4,
CT0/5, CT0/6, CT0/7>
On receipt of such advertisement, LSR1 will:
- understand that LSR0 is not DS-TE-capable because it
advertised a Max Reservable Bw sub-TLV and no Bandwidth
Constraints sub-TLV, and
- conclude that only CT0 LSPs can transit via LSR0 and that
only the values CT0/2 and CT0/3 are meaningful in the
Unreserved Bw sub-TLV. LSR1 may effectively behave as if the
six other values contained in the Unreserved Bw sub-TLV were
set to zero.
In IGP for Link01, LSR1 will advertise:
- Max Reservable Bw sub-TLV = <m10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- Unreserved Bw sub-TLV =
<CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
On receipt of such advertisement, LSR0 will:
- ignore the Bandwidth Constraints sub-TLV (unrecognized)
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-
TLV and use these values for CTO LSP establishment
- incorrectly believe that the other values contained in the
Unreserved Bw sub-TLV relate to other preemption priorities
for CT0; but it will actually never use those since we assume
that only preemptions 2 and 3 are used in the TE domain.
Normative References
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M. and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, May 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
Informative References
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,