RFC 3784 (rfc3784) - Page 2 of 13

Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)

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