Document ID: 5739
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
The Function of TLV
TLV Encoding
IS-IS PDU and TLV Definitions
TLVs Implemented by Cisco
TLV Details
Sub-TLVs and Traffic Engineering
Sub-TLV Details
Related Information
Introduction
This document explains the IS-IS Type Length Value (TLV) and its use.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
The Function of TLV
IS-IS, originally designed for Open System Interconnection (OSI) routing, uses TLV parameters to carry information in Link State Packets (LSPs). The TLVs make IS-IS extendable. IS-IS can therefore carry different kinds of information in the LSPs. As defined by ISO 10589, IS-IS supports only the Connectionless Network Protocol (CLNP). However, IS-IS was extended for IP routing in RFC 1195 
with the registration of TLV 128 which contains a set of 12-octet fields to carry IP information.
In the IS-IS Protocol Data Unit (PDU), there is a fixed and a variable part of the header. The fixed part of the header contains fields that are always present, and the variable part of the header contains the TLV which permits the flexible encoding of parameters within link state records. These fields are identified by one octet of type (T), one octet of length (L) and "L" octets of value (V). The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field. The Value field is the data portion of the packet. Not all router implementations support all TLVs, but they are required to ignore and retransmit the ignored types.
As explained by RFC 1195 , TLV 128 extends IS-IS to carry IP, in addition to Connectionless Network Service (CLNS), routing information in the same packet. DEC has also implemented an extension to IS-IS with TLV 42. This extension allows the IS-IS to hold information about DECnet Phase IV networks. In the future, a new TLV may be implemented allowing CLNS to carry IPv6 routing information.
Several routing protocols use TLVs to carry a variety of attributes. Cisco Discovery Protocol (CDP), Label Discovery Protocol (LDP), and Border Gateway Protocol (BGP) are examples of protocols that use TLVs. BGP uses TLVs to carry attributes such as Network Layer Reachability Information (NLRI), Multiple Exit Discriminator (MED), and local preference.
TLV Encoding
The variable length fields are encoded as follows:
|
Field |
Number of Octets |
|---|---|
|
Type |
1 |
|
Length |
1 |
|
Value |
LENGTH |
RFC 1142 Section 9, a revision of ISO 10589, provides detail about the packet layouts for each type of IS-IS PDU, as well as the TLVs supported for each type. The first eight octets of all IS-IS PDUs are header fields that are common to all PDU types. The TLV information is stored at the very end of the PDU. Different types of PDUs have a set of currently-defined codes. Any codes that are not recognized should be ignored and passed through unchanged.
IS-IS PDU and TLV Definitions
Definitions for IS-IS PDU types and valid code values have been established. ISO 10589 defines type codes 1 through 10. RFC 1195 defines type codes 128 through 133.
Note: TLV code 133 (Authentication Information) is specified in RFC 1195 , but Cisco uses the ISO code of 10 instead. Additionally, TLV code 4 is used for partition repair and is not supported by Cisco.
TLVs Implemented by Cisco
Cisco implements most TLVs. However, in some cases, draft or low-demand TLVs are not implemented. Below are the explanations of the popular TLVs implemented by Cisco.
|
TLV |
Name |
Description |
|---|---|---|
|
1 |
Area Address |
Includes the Area Addresses to which the Intermediate System is connected. |
|
2 |
IIS Neighbors |
Includes all the IS-ISs running interfaces to which the router is connected. |
|
8 |
Padding |
Primarily used in the IS-IS Hello (IIH) packets to detect the maximum transmission unit (MTU) inconsistencies. By default, IIH packets are padded to the fullest MTU of the interface. |
|
10 |
Authentication |
The information that is used to authenticate the PDU. |
|
22 |
TE IIS Neighbors |
Increases the maximum metric to three bytes (24 bits). Known as the Extended IS Reachability TLV, this TLV addresses a TLV 2 metric limitation. TLV 2 has a maximum metric of 63, but only six out of eight bits are used. |
|
128 |
IP Int. Reachability |
Provides all the known IP addresses that the given router knows about via one or more internally-originated interfaces. This information may appear multiple times. |
|
129 |
Protocols Supported |
Carries the Network Layer Protocol Identifiers (NLPID) for Network Layer protocols that the IS (Intermediate System) is capable. It refers to the Data Protocols that are supported. For example, IPv4 NLPID value 0xCC, CLNS NLPID value 0x81, and/or IPv6 NLPID value 0x8E will be advertised in this NLPID TLV. |
|
130 |
IP Ext. Address |
Provides all the known IP addresses that the given router knows about via one or more externally-originated interfaces. This information may appear multiple times. |
|
132 |
IP Int. Address |
The IP interface address that is used to reach the next-hop address. |
|
134 |
TE Router ID |
This is the Multi-Protocol Label Switching (MPLS) traffic engineering router ID. |
|
135 |
TE IP Reachability |
Provides a 32 bit metric and adds a bit for the "up/down" resulting from the route-leaking of L2->L1. Known as the Extended IP Reachability TLV, this TLV addresses the issues with both TLV 128 and TLV 130. |
|
137 |
Dynamic Hostname |
Identifies the symbolic name of the router originating the link-state packet (LSP). |
|
10 and 133 |
TLV 10 should be used for Authentication; not the TLV 133. If TLV 133 is received, it is ignored on receipt, like any other unknown TLVs. TLV 10 should be accepted for authentication only. |
TLV Details
|
Name |
TLV |
IIH |
SNP |
L1 LSP |
L2 LSP |
Origin |
|---|---|---|---|---|---|---|
|
Area Addresses |
1 |
Yes |
No |
Yes |
Yes |
ISO 10589 |
|
IIS Neighbors |
2 |
No |
No |
Yes |
Yes |
ISO 10589 |
|
ES Neighbors |
3 |
No |
No |
Yes |
No |
ISO 10589 |
|
Part. DIS |
4 |
No |
No |
Yes |
ISO 10589 |
|
|
Prefix Neighbors |
5 |
No |
No |
Yes |
ISO 10589 |
|
|
IIS Neighbors |
6 |
Yes |
No |
Yes |
ISO 10589 |
|
|
Padding |
8 |
Yes |
No |
No |
No |
ISO 10589 |
|
LSP Entries |
9 |
No |
Yes |
No |
No |
ISO 10589 |
|
Authentication |
10 |
Yes |
Yes |
Yes |
Yes |
ISO 10589 |
|
Opt. Checksum |
12 |
Yes |
Yes |
Yes |
Yes |
draft-ietf-isis-wg-snp-checksu |
|
LSPBufferSize |
14 |
Yes |
No |
SIF-DRAFT |
||
|
TE IIS Neighbors |
22 |
No |
No |
draft-ietf-isis-traffic-04.txt |
||
|
HMAC-MD5 Authentic |
54 |
draft-ietf-isis-hmac-03.txt |
||||
|
IP Int. Reach |
128 |
No |
No |
Yes |
Yes |
RFC 1195 |
|
Prot. Supported |
129 |
Yes |
No |
Yes |
Yes |
RFC 1195 |
|
IP Ext. Address |
130 |
No |
No |
Yes |
Yes |
RFC 1195 |
|
IDRPI |
131 |
No |
Yes |
No |
Yes |
RFC 1195 |
|
IP Intf. Address |
132 |
Yes |
No |
Yes |
Yes |
RFC 1195 |
|
Authentication |
*133 |
No |
No |
No |
No |
RFC 1195 (illegal) |
|
TE-Router ID |
134 |
No |
No |
Yes |
Yes |
draft-ietf-isis-traffic-04.txt |
|
TE IP. Reach |
135 |
No |
No |
draft-ietf-isis-traffic-04.txt |
||
|
Dynamic Name |
137 |
No |
No |
RFC 2763 |
||
|
Shared Risk Link Group |
138 |
draft-ietf-isis-gmpls-extensions-12.txt |
||||
|
MT-ISN |
222 |
No |
No |
draft-ietf-isis-wg-multi-topol |
||
|
M-Topologies |
229 |
Yes |
No |
draft-ietf-isis-wg-multi-topol |
||
|
IPv6 Intf. Addr. |
232 |
Yes |
No |
draft-ietf-isis-ipv6-02.txt |
||
|
MT IP. Reach |
235 |
No |
No |
draft-ietf-isis-wg-multi-topol |
||
|
3-Way hellos |
240 |
Yes |
No |
draft-ietf-isis-3way-01.txt |
||
|
Restart TLV |
211 |
Yes |
No |
No |
No |
draft-shand-isis-restart-01.txt |
|
IPv6 Reachability |
236 |
No |
No |
Yes |
Yes |
draft-ietf-isis-ipv6-02.txt |
|
MT IPv6 IP Reach |
237 |
No |
No |
Yes |
Yes |
draft-ietf-isis-wg-multi-topol |
|
p2p 3-way Adj. |
240 |
Yes |
No |
draft-ietf-isis-3way-06.txt |
Sub-TLVs and Traffic Engineering
Sub-TLVs use the same concepts as 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 on receipt.
The majority of the Sub-TLVs are defined in draft-ietf-isis-traffic-04.txt and draft-ietf-isis-gmpls-extensions-12.txt.
Additionally, these sub-TLVs are part of Extended IS Reachability TLV 22, with the exception of the sub-TLV 1 which is part of Extended IP Reachability TLV 135. The sub-TLV 1 is defined in draft-martin-neal-policy-isis-admin-tags-01.txt
Below is the brief description of the Sub-TLVs:
|
Sub-TLV |
Name |
Description |
|---|---|---|
|
1 |
Administration Group |
This sub-TLV associates a tag with an IP prefix. Some of the examples of this 'tag' include controlling redistribution between levels and areas, different routing protocols, or on an interface. |
|
3 |
Administration Group |
If the link or interface has been colored (from the traffic engineering point of view), that information is carried by this TLV. |
|
6 |
IPv4 Interface Address |
The interface IP address that is used for the traffic engineering purposes. |
|
8 |
IPv4 Neighbor Address |
The neighbor interface IP address that is used for the traffic engineering purposes. |
|
9 |
Maximum Link Bandwidth |
The maximum link bandwidth of the interface in question (for the traffic engineering purposes). |
|
10 |
Maximum Reservable Link Bandwidth |
The maximum amount of bandwidth that can be reserved on the interface in question. |
|
11 |
Unreserved Bandwidth |
The amount of bandwidth which is not yet reserved on the interface. |
|
18 |
Traffic Engineering Default Metric |
The metric that is administratively assigned for the traffic engineering purposes. |
Sub-TLV Details
|
Sub-TLV |
TLV |
Definitions |
Bytes |
|---|---|---|---|
|
Administrative Tag |
1 |
ISIS_ROUTE_ADMIN_TAG |
|
|
Admin. Group (color) |
3 |
ISIS_ADMIN_GROUP |
4 |
|
Outgoing Int. Identifier |
4 |
4 |
|
|
Incoming Int. Identifier |
5 |
4 |
|
|
IPv4 Inter. Address |
6 |
ISIS_INTERFACE_IP_ADDRESS |
4 |
|
Interface MTU |
7 |
2 |
|
|
IPv4 Neigh. Address |
8 |
ISIS_NEIGHBOR_IP_ADDRESS |
4 |
|
Maximum Link Bandwidth |
9 |
ISIS_MAXIMUM_LINK_BW |
4 |
|
Max. Reserv. Link Bandwidth |
10 |
ISIS_MAXIMUM_LINK_RES |
4 |
|
Unreserved Bandwidth |
11 |
ISIS_CURRENT_BW_UNRESERVED |
32 |
|
TE Default Metric |
18 |
ISIS_TRAFFIC_ENGINEERING_METRIC |
3 |
|
Link Protection Type |
20 |
2 |
|
|
Int. Switch. Capability Desc. |
21 |
variable |
|
|
MT Reachable IPv4 Prefixes |
117 |
||
|
Max. Link. Reser. Sub Pool |
*250 |
ISIS_MAXIMUM_LINK_RES_SUB |
|
|
Current BW UnReser. Sub Pool |
*251 |
ISIS_CURRENT_BW_UNRESERVED_SUB |
* The Sub-TLVs 250 and 251 are part of Cisco-specific extensions in support of MPLS-TE that is documented in draft-ietf-isis-traffic-04.txt. These Sub-TLVs are used during the Guraranteed Bandwidth application under MPLS-TE.
Note: Always refer to the most recent Internet Engineering Task Force (IETF) draft. The IETF draft mentioned in this document is subject to change. It may be replaced by a more recent version or RFC, or it may expire.
Related Information
| Updated: Aug 10, 2005 | Document ID: 5739 |