that it MUST now be interpreted as the aggregate bandwidth constraint
across all Class-Types; i.e., SUM (Reserved (CTc)) <= Max Reservable
Bandwidth, independently of the Bandwidth Constraints Model.
This document also defines the following new optional sub-TLV to
advertise the eight potential BCs (BC0 to BC7):
"Bandwidth Constraints" sub-TLV:
- Bandwidth Constraints Model Id (1 octet)
- Reserved (3 octets)
- Bandwidth Constraints (N x 4 octets)
Where:
- With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
sub-TLV type is 17.
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS
reachability TLV" and its sub-TLV type is 22.
- Bandwidth Constraints Model Id: a 1-octet identifier for the
Bandwidth Constraints Model currently in use by the LSR
initiating the IGP advertisement. See the IANA Considerations
section for assignment of values in this name space.
- Reserved: a 3-octet field. This field should be set to zero
by the LSR generating the sub-TLV and should be ignored by the
LSR receiving the sub-TLV.
- Bandwidth Constraints: contains BC0, BC1,... BC(N-1). Each BC
is encoded on 32 bits in IEEE floating point format. The
units are bytes (not bits!) per second. Where the configured
TE-Class mapping and the Bandwidth Constraints model in use
are such that BCh+1, BCh+2, ...and BC7 are not relevant to any
of the Class-Types associated with a configured TE-Class, it
is RECOMMENDED that only the Bandwidth Constraints from BC0 to
BCh be advertised, in order to minimize the impact on IGP
scalability.
All relevant generic TLV encoding rules (including TLV format,
padding and alignment, as well as IEEE floating point format
encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this
new sub-TLV.
The "Bandwidth Constraints" sub-TLV format is illustrated below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise BCs.
A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth
Constraints" sub-TLV (in addition to the existing Maximum Reservable
Bandwidth sub-TLV) to do so. For example, in the case where a
service provider deploys DS-TE with TE-Classes associated with CT0
and CT1 only, and where the Bandwidth Constraints Model is such that
only BC0 and BC1 are relevant to CT0 and CT1, a DS-TE LSR which does
advertise BCs would include in the IGP advertisement the Maximum
Reservable Bandwidth sub-TLV, as well as the "Bandwidth Constraints"
sub-TLV. The former should contain the aggregate bandwidth
constraint across all CTs, and the latter should contain BC0 and BC1.
A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
Bandwidth Constraints Model Id that does not match the Bandwidth
Constraints Model it currently uses SHOULD generate a warning to the
operator/management system, reporting the inconsistency between
Bandwidth Constraints Models used on different links. Also, in that
case, if the DS-TE LSR does not support the Bandwidth Constraints
Model designated by the Bandwidth Constraints Model Id, or if the
DS-TE LSR does not support operations with multiple simultaneous
Bandwidth Constraints Models, the DS-TE LSR MAY discard the
corresponding TLV. If the DS-TE LSR does support the Bandwidth
Constraints Model designated by the Bandwidth Constraints Model Id,
and if the DS-TE LSR does support operations with multiple
simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept
the corresponding TLV and allow operations with different Bandwidth
Constraints Models used in different parts of the DS-TE domain.
5.2. Unreserved Bandwidth
With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained
as the only vehicle to advertise dynamic bandwidth information
necessary for Constraint-Based Routing on head-ends, except that it
is used with a generalized semantics. The Unreserved Bandwidth sub-
TLV still carries eight bandwidth values, but they now correspond to
the unreserved bandwidth for each of the TE-Classes (instead of for
each preemption priority, as per existing TE).
More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth
sub-TLV with a definition that is generalized into the following:
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
not yet reserved for each of the eight TE-Classes, in IEEE floating
point format arranged in increasing order of TE-Class index.
Unreserved bandwidth for TE-Class [0] occurs at the start of the
sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the
sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <=
7) is referred to as "Unreserved TE-Class [i]". It indicates the
bandwidth that is available, for reservation, to an LSP that:
- 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.
Because the bandwidth values are now ordered by TE-class index and
thus can relate to different CTs with different BCs and to any
arbitrary preemption priority, a DS-TE LSR MUST NOT assume any
ordered relationship among these bandwidth values.
With existing TE, because all preemption priorities reflect the same
(and only) BCs and bandwidth values are advertised in preemption
priority order, the following relationship is always true, and is
often assumed by TE implementations:
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
With DS-TE, no relationship is to be assumed such that:
If i < j, then any of the following relationships may be true:
"Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
Rules for computing "Unreserved TE-Class [i]" are specified in
Section 11.
If TE-Class[i] is unused, the value advertised by the IGP in
"Unreserved TE-Class [i]" MUST be set to zero by the LSR generating
the IGP advertisement, and MUST be ignored by the LSR receiving the
IGP advertisement.
6. RSVP-TE Extensions for DS-TE
In this section, we describe extensions to RSVP-TE for support of
Diffserv-aware MPLS Traffic Engineering. These extensions are in
addition to the extensions to RSVP defined in [RSVP-TE] for support
of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP
defined in [DIFF-MPLS] for support of Diffserv over MPLS.
6.1. DS-TE-Related RSVP Messages Format
One new RSVP object is defined in this document: the CLASSTYPE
object. Detailed description of this object is provided below. This
new object is applicable to Path messages. This specification only
defines the use of the CLASSTYPE object in Path messages used to
establish LSP Tunnels in accordance with [RSVP-TE] and thus
containing a session object with a CT equal to LSP_TUNNEL_IPv4 and
containing a LABEL_REQUEST object.
Restrictions defined in [RSVP-TE] for support of establishment of LSP
Tunnels via RSVP-TE are also applicable to the establishment of LSP
Tunnels supporting DS-TE. For instance, only unicast LSPs are
supported, and multicast LSPs are for further study.
This new CLASSTYPE object is optional with respect to RSVP so that
general RSVP implementations not concerned with MPLS LSP setup do not
have to support this object.
An LSR supporting DS-TE MUST support the CLASSTYPE object.
6.1.1. Path Message Format
The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
6.2. CLASSTYPE Object
The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is
66. Currently, there is only one defined C-Type which is C-Type 1.
The CLASSTYPE object format is shown below.
6.2.1. CLASSTYPE object
Class Number = 66
Class-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 29 bits
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
CT: 3 bits
Indicates the Class-Type. Values currently allowed are
1, 2, ... , 7. Value of 0 is Reserved.
6.3. Handling CLASSTYPE Object
To establish an LSP tunnel with RSVP, the sender LSR creates a Path
message with a session type of LSP_Tunnel_IPv4 and with a
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also
include the DIFFSERV object as per [DIFF-MPLS].
If the LSP is associated with Class-Type 0, the sender LSR MUST NOT
include the CLASSTYPE object in the Path message. This allows
backward compatibility with non-DSTE-configured or non-DSTE-capable
LSRs as discussed below in Section 10 and Appendix C.
If the LSP is associated with Class-Type N (1 <= N <=7), the sender
LSR MUST include the CLASSTYPE object in the Path message with the
Class-Type (CT) field set to N.
If a Path message contains multiple CLASSTYPE objects, only the first
one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
MUST NOT be forwarded.
Each LSR along the path MUST record the CLASSTYPE object, when it is
present, in its path state block.
If the CLASSTYPE object is not present in the Path message, the LSR
MUST associate the Class-Type 0 to the LSP.
The destination LSR responding to the Path message by sending a Resv
message MUST NOT include a CLASSTYPE object in the Resv message
(whether or not the Path message contained a CLASSTYPE object).
During establishment of an LSP corresponding to the Class-Type N, the
LSR MUST perform admission control over the bandwidth available for
that particular Class-Type.
An LSR that recognizes the CLASSTYPE object and that receives a Path
message that:
- contains the CLASSTYPE object, but
- does not contain a LABEL_REQUEST object or does not have a
session type of LSP_Tunnel_IPv4,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "Unexpected CLASSTYPE
object". These codes are defined in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object, but
- does not support the particular Class-Type,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "Unsupported Class-
Type". These codes are defined in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object that:
- 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
"Diffserv-aware TE Error" and an error value of "Invalid Class-Type
value". These codes are defined in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object and
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the setup priority signaled in the same Path message, is
not one of the eight TE-Classes configured in the TE-class
mapping,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "CT and setup
priority do not form a configured TE-Class". These codes are defined
in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object and
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-Classes configured in the TE-class
mapping,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "CT and holding
priority do not form a configured TE-Class". These codes are defined
in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object and
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the setup priority signaled in the same Path message, is
not one of the eight TE-Classes configured in the TE-class
mapping, AND
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-Classes configured in the TE-class
mapping
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "CT and setup
priority do not form a configured TE-Class AND CT and holding
priority do not form a configured TE-Class". These codes are defined
in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an L-LSP that:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types
and Per Hop Behavior (PHB) Scheduling Class, e.g., via
configuration, and
- determines, based on this local knowledge, that the PHB
Scheduling Class (PSC) signaled in the DIFFSERV object is
inconsistent with the Class-Type signaled in the CLASSTYPE
object,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "Inconsistency
between signaled PSC and signaled CT". These codes are defined below
in Section 6.5.
An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an E-LSP that:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types
and PHBs (e.g., via configuration)
- determines, based on this local knowledge, that the PHBs
signaled in the MAP entries of the DIFFSERV object are
inconsistent with the Class-Type signaled in the CLASSTYPE
object,
MUST send a PathErr towards the sender with the error code
"Diffserv-aware TE Error" and an error value of "Inconsistency
between signaled PHBs and signaled CT". These codes are defined in
Section 6.5.
An LSR MUST handle situations in which the LSP cannot be accepted for
reasons other than those already discussed in this section, in
accordance with [RSVP-TE] and [DIFF-MPLS] (e.g., a reservation is
rejected by admission control, and a label cannot be associated).
6.4. Non-support of the CLASSTYPE Object
An LSR that does not recognize the CLASSTYPE object Class-Num MUST
behave in accordance with the procedures specified in [RSVP] for an
unknown Class-Num whose format is 0bbbbbbb (i.e., it MUST send a
PathErr with the error code "Unknown object class" toward the
sender).
An LSR that recognizes the CLASSTYPE object Class-Num but that does
not recognize the CLASSTYPE object C-Type, MUST behave in accordance
with the procedures specified in [RSVP] for an unknown C-type (i.e.,
it MUST send a PathErr with the error code "Unknown object C-Type"
toward the sender).
Both of the above situations cause the path setup to fail. The
sender SHOULD notify the operator/management system that an LSP
cannot be established and might take action to retry reservation
establishment without the CLASSTYPE object.
6.5. Error Codes for Diffserv-aware TE
In the procedures described above, certain errors are reported as a
"Diffserv-aware TE Error". The value of the "Diffserv-aware TE
Error" error code is 28.
The following table defines error values for the Diffserv-aware TE
Error:
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a
configured TE-Class
6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not form
a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type
8 Inconsistency between signaled PHBs and signaled
Class-Type
See the IANA Considerations section for allocation of additional
values.
7. DS-TE Support with MPLS Extensions
There are a number of extensions to the initial base specification
for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].
Those include enhancements for generalization ([GMPLS-SIG] and
[GMPLS-ROUTE]), as well as for additional functionality, such as LSP
hierarchy [HIERARCHY], link bundling [BUNDLE], and fast restoration
[REROUTE]. These specifications may reference how to encode
information associated with certain preemption priorities, how to
treat LSPs at different preemption priorities, or they may otherwise
specify encodings or behavior that have a different meaning for a
DS-TE router.
In order for an implementation to support both this specification for
Diffserv-aware TE and a given MPLS enhancement, such as those listed
above (but not limited to those), it MUST treat references to
"preemption priority" and to "Maximum Reservable Bandwidth" in a
generalized manner, i.e., the manner in which this specification uses
those terms.
Additionally, current and future MPLS enhancements may include more
precise specification for how they interact with Diffserv-aware TE.
7.1. DS-TE Support and References to Preemption Priority
When a router supports both Diffserv-aware TE and one of the MPLS
protocol extensions such as those mentioned above, encoding of values
of preemption priority in signaling or encoding of information
associated with preemption priorities in IGP defined for the MPLS
extension, MUST be considered an encoding of the same information for
the corresponding TE-Class. For instance, if an MPLS enhancement
specifies advertisement in IGP of a parameter for routing information
at preemption priority N, in a DS-TE environment it MUST actually be
interpreted as specifying advertisement of the same routing
information but for TE-Class [N]. On receipt, DS-TE routers MUST
also interpret it as such.
When there is discussion on how to comparatively treat LSPs of
different preemption priority, a DS-TE LSR MUST treat the preemption
priorities in this context as those associated with the TE-Classes of
the LSPs in question.
7.2. DS-TE Support and References to Maximum Reservable Bandwidth
When a router supports both Diffserv-aware TE and MPLS protocol
extensions such as those mentioned above, advertisements of Maximum
Reservable Bandwidth MUST be done with the generalized interpretation
defined in Section 4.1.1 as the aggregate bandwidth constraint across
all Class-Types. It MAY also allow the optional advertisement of all
BCs.
8. Constraint-Based Routing
Let us consider the case where a path needs to be computed for an LSP
whose Class-Type is configured to CTc and whose setup preemption
priority is configured to p.
Then the pair of CTc and p will map to one of the TE-Classes defined
in the TE-Class mapping. Let us refer to this TE-Class as TE-
Class[i].
The Constraint-Based Routing algorithm of a DS-TE LSR is still only
required to perform path computation satisfying a single BC which is
to fit in "Unreserved TE-Class [i]" as advertised by the IGP for
every link. Thus, no changes to the existing TE Constraint-Based
Routing algorithm itself are required.
The Constraint-Based Routing algorithm MAY also take into account,
when used, the optional additional information advertised in IGP such
as the BCs and the Maximum Reservable Bandwidth. For example, the
BCs MIGHT be used as tie-breaker criteria in situations where
multiple paths, otherwise equally attractive, are possible.
9. Diffserv Scheduling
The Class-Type signaled at LSP establishment MAY optionally be used
by DS-TE LSRs to dynamically adjust the resources allocated to the