RFC 3784 (rfc3784) - Page 2 of 13
Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)
Alternative Format: Original Text Document
RFC 3784 IS-IS extensions for Traffic Engineering June 2004
The router id is useful for traffic engineering purposes because it
describes a single address that can always be used to reference a
particular router.
Mechanisms and procedures to migrate to the new TLVs are not
discussed in this document.
2. Introducing Sub-TLVs
This document introduces a new way to encode routing information in
IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to
regular TLVs. They use the same concepts as regular TLVs. The
difference is that TLVs exist inside IS-IS packets, while sub-TLVs
exist inside TLVs. TLVs are used to add extra information to IS-IS
packets. Sub-TLVs are used to add extra information to particular
TLVs. Each sub-TLV consists of three fields, a one-octet Type field,
a one-octet Length field, and zero or more octets of Value. The Type
field indicates the type of items in the Value field. The Length
field indicates the length of the Value field in octets. Each sub-
TLV can potentially hold multiple items. The number of items in a
sub-TLV can be computed from the length of the whole sub-TLV, when
the length of each item is known. Unknown sub-TLVs are to be ignored
and skipped upon receipt.
The Sub-TLV type space is managed by the IETF IS-IS WG
(http://www.ietf.org/html.charters/isis-charter.html). New type
values are allocated following review on the IETF IS-IS mailing list.
This will normally require publication of additional documentation
describing how the new type is used. In the event that the IS-IS
working group has disbanded the review shall be performed by a
Designated Expert assigned by the responsible Area Director.
3. The Extended IS Reachability TLV
The extended IS reachability TLV is TLV type 22.
The existing IS reachability (TLV type 2, defined in ISO 10589 [1])
contains information about a series of IS neighbors. For each
neighbor, there is a structure that contains the default metric, the
delay, the monetary cost, the reliability, and the 7-octet ID of the
adjacent neighbor. Of this information, the default metric is
commonly used. The default metric is currently one octet, with one
bit used to indicate whether the metric is internal or external, and
one bit that was originally unused, but which was later defined by
RFC 2966 to be the up/down bit. The remaining 6 bits are used to
store the actual metric, resulting in a possible metric range of 0-
63. This limitation is one of the restrictions that we would like to
lift.
Smit & Li Informational