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

Document Type RFC - Informational (June 2004; No errata)
Obsoleted by RFC 5305
Updated by RFC 4205
Authors Henk Smit  , Tony Li 
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 3784 (Informational)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ross Callon
Send notices to (None)
Network Working Group                                            H. Smit
Request for Comments: 3784                              Procket Networks
Category: Informational                                            T. Li
                                                               June 2004

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

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   This document describes extensions to the Intermediate System to
   Intermediate System (IS-IS) protocol to support Traffic Engineering
   (TE).  This document extends the IS-IS protocol by specifying new
   information that an Intermediate System (router) can place in Link
   State Protocol (LSP) Data Units.  This information describes
   additional details regarding the state of the network that are useful
   for traffic engineering computations.

1.  Introduction

   The IS-IS protocol is specified in ISO 10589 [1], with extensions for
   supporting IPv4 specified in RFC 1195 [3].  Each Intermediate System
   (IS) (router) advertises one or more IS-IS Link State Protocol Data
   Units (LSPs) with routing information.  Each LSP is composed of a
   fixed header and a number of tuples, each consisting of a Type, a
   Length, and a Value.  Such tuples are commonly known as TLVs, and are
   a good way of encoding information in a flexible and extensible

   This document contains the design of new TLVs to replace the existing
   IS Neighbor TLV, IP Reachability TLV, and to include additional
   information about the characteristics of a particular link to an IS-
   IS LSP.  The characteristics described in this document are needed
   for Traffic Engineering [4] (TE).  Secondary goals include increasing
   the dynamic range of the IS-IS metric and improving the encoding of
   IP prefixes.

Smit & Li                    Informational                      [Page 1]
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
   (  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

Smit & Li                    Informational                      [Page 2]
RFC 3784        IS-IS extensions for Traffic Engineering       June 2004

   The remaining three metrics (delay, monetary cost, and reliability)
Show full document text