Link-State Packet TLVs

The previous sections of this chapter reviewed the LSP packet format and discussed fields in the LSP header. As shown in Figure 5-2, TLV fields are appended to the header of an IS-IS packet, depending on its type and the specifics of the routing environment, to form the complete packet. This section covers the TLVs defined for Level 1 and Level 2 LSPs by ISO 10589 and RFC 1195. Table 5-3 lists the TLVs for Level 1 LSPs defined in both standards, and Table 5-4 lists the TLVs for Level 2 LSPs. Some TLVs are used in both Level 1 and Level 2 LSPs. Those unique to a specific level of LSP are bolded. Some of the recent TLVs defined by the IETF for various extensions to Integrated IS-IS, such as MPLS traffic engineering, are covered in the section "IS-IS Metric Extensions" later in this chapter.

TLVs for Level 1 LSPs

Table 5-3 lists the TLVs specified in ISO 10589 and RFC 1195 to support the IS-IS Level 1 routing environment. TLVs (Type, Length, Value) fields also are referred to as CLV (Code, Length, Value) fields in the previously mentioned standards. TLV is used because it is more common in recent literature and IETF publications . The End System Neighbors information TLV (Type 3) is bolded because it is specific only to the Level 1 routing environment.

Table 5-3. Level-1 TLVs

TLV	Type	Source
Area Address	1	ISO 10589
Intermediate System Neighbors	2	ISO 10589
End System Neighbors	3	ISO 10589
Authentication Information	10	ISO 10589
IP Internal Reachability Information	128	RFC 1195
Protocols Supported	129	RFC 1195
IP Interface Address	132	RFC 1195

The uses of the various Level 1 TLVs are described here:

• Area Address TLV ” This TLV lists the set of area addresses configured on the originating router. The TLV features only in nonpseudonode LSPs and is in the first fragment if the LSP is fragmented . The Area Address TLV is made up of the following fields:

  - Type (1 byte) ” 1
  
  

  - Length (1 byte) ” Total length of the Value field
  
  

  - Value ” n x (1-byte address length + variable area address)
  
  

• Intermediate System Neighbors TLV ” This TLV captures the list of adjacent Level 1 routers. It consists of the following fields:

  - Type (1 byte) ” 2
  
  

  - Length (1 byte) ” 1 byte + n x (system ID length + 5 in bytes) for n neighbors
  
  

  - Value ” 1 byte virtual flag + n multiples of (4-byte neighbor metric information + neighbor SysID + 1 byte Pseudonode ID)
  
  

The Intermediate System Neighbors TLV is repeated for each neighbor. The TLV differs from the IS Neighbors TLVs (Type 6) used in LAN hello packets. Specifically, this TLV (Type 2) also carries metric information for each of the neighbors. IS-IS metrics is an interesting topic and is discussed in detail in the sections "IS-IS Metrics Information" and "IS-IS Metric Extensions" later in this chapter.

• End System Neighbors TLV ” This TLV is available only in Level 1 LSPs. It captures and lists adjacent Level 1 routers as well as end systems, such as ISO CLNP workstations captured through the ES-IS protocol. It has the following structure:

  - Type (1 byte) ” 3
  
  

  - Length (1 byte) ” 4 bytes + SysID length of ES neighbor
  
  

  - Value ” Common metric + multiples of SysID of ES neighbors
  
  

  End systems with the same metric are grouped together in a single TLV.

• Authentication Information TLV ” This TLV provides for LSP authentication through a simple clear-text password scheme. No other password types for IS-IS packet authentication have been standardized as of this writing. However, the IETF IS-IS Working Group is looking at a more sophisticated MD5-based authentication scheme. Authentication is discussed in further detail in Chapter 9, "Configuring IS-IS for IP Routing on Cisco Routers".

  - Type (1 byte) ” 10
  
  

  - Length (1 byte) ” Specified length of the Value field in bytes within the range of 1 “254 bytes
  
  

  - Value ” This field is made up of two components : Type of Authentication and Authentication Password, as follows :
  
  

  • Type of authentication (1 byte)

    0 and 2 “254 “ Reserved

    1 “ Clear-text password

    255 “ Domainwide authentication

  • Authentication password ”For authentication Type 1, this is a variable-length clear-text password up to 254 bytes long.

• IP Internal Reachability Information TLV ” This TLV stores a list of directly connected IP prefixes. It is used only in nonpseudonode LSPs. Each prefix is assigned a metric value, which corresponds to that of the link over which the IP prefix is configured.

  - Type (1 byte) ” 128
  
  

  - Length (1 byte) ” Multiples of 12 bytes
  
  

  - Value ” Multiple entries, each consisting of the following:
  
  

  • 4 bytes for metric information

  • 4 bytes for IP prefix

  • 4 bytes for IP subnet mask

• Protocols Supported TLV ” This TLV identifies the Layer 3 protocols supported by Integrated IS-IS. It must appear in the first fragment (LSP number 0) if the LSP is fragmented. Currently, the only protocols supported are CLNP (NLPID 0x81) andIP (NLPID 0xCC).

  - Type (1 byte) ” 129
  
  

  - Length (1 byte) ” Total length of the Value field in bytes
  
  

  - Value ” Network layer protocol identifiers (NLPIDs) for supported protocols, 1 byte each
  
  

• IP Interface Address TLV ” This TLV contains one or more of the IP addresses configured on the originator of the LSP. In recent IOS releases, the highest loopback address is entered automatically in this field.

  - Type (1 byte) ” 132
  
  

  - Length (1 byte) ” Total length of the Value field in bytes
  
  

  - Value ” Multiples of 4-byte IP addresses
  
  

Example 5-4 shows a Level 1 LSP output from a Cisco router displayed by the command show isis database . An LSP ID and the keyword "detail" are entered as arguments to display the details of a specific LSP. The output shows the LSP header and the TLVs in the LSP. The following TLVs are present: Area Address TLV, Protocols Supported TLV, IP Address TLV, Internal IP Reachability TLV, IS Neighbors TLV, and the ES Neighbors TLV. LSP shows that only IP (NLPID OxCC) is supported. This is because CLNP routing is not enabled and because IS-IS is used for routing only IP on this router.

Example 5-4 Level-1 LSP from a Cisco Router

 RTD#  show isis database 0000.0000.0004.00-00 level-1 detail  IS-IS Level-1 LSP 0000.0000.0004.00-00 LSPID                  LSP Seq Num  LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0004.00-00* 0x0000000F    0x6699      1036            1/0/0  Area Address: 49.0002  NLPID:    0xCC IP Address:  11.1.1.4 Metric: 10 IP 10.1.2.0 255.255.255.0 Metric: 10 IP 192.168.2.12 255.255.255.252 Metric: 10 IP 11.1.1.4 255.255.255.255 Metric: 10 IS 0000.0000.0004.02 Metric: 10 IS 0000.0000.0002.01 Metric: 0 ES 0000.0000.0004 

The following calculation enables you to determine how many IP prefixes can be advertised in an LSP. The following constraints are to be considered in the calculation:

• The maximum size (maxLSPsize) of an LSP is 1492 bytes.

• The LSP header (lspHeadersize) is 27 bytes.

• The maximum length of a TLV (maxTLVlength) is 255 bytes.

• Each TLV 128 consists of type (1 byte), length (1 byte), and IP prefixes ( n x 12 bytes) up to total of 255 bytes.

• The maximum number of fragments of an LSP (maxLSPfragments) is 256. The number of fragments is determined from the 1-byte LSP Number field in the LSP identifier.

• The first fragment contains other TLVs, and the remaining 255 fragments are packed with only TLV 128.

The actual calculation is as follows:

1. The total space available for TLVs in an LSP is

   TLVSpace = maxLSPsize - lspHeadersize = 1492 - 27 = 1465 bytes

2. The number of TLVs that can fit into TLVSpace is

   1465/255 = 5.7, approximately 6

   Assuming a 1 “byte Type field and 1-byte Length field, overhead for 6 TLVs is

   6 x 2 = 12 bytes.

3. Actual space available for prefixes is

   1465 “ 12 bytes overhead = 1453 bytes

4. Number of prefixes, each 12 bytes (address + subnet mask + metric) that can fit into TLVSpace is

   1453/12 = 121.08 (approximately 121 IP prefixes per LSP)

Considering that few other TLVs can be generated by the router, the number of IP prefixes that can be supported per IS-IS router is 256 fragments, each containing 121 prefixes, for a total of 30,976 prefixes.

TLVs for Level 2 LSPs

Table 5-4 lists the Level 2 TLVs, which are the subject of this section. The blocked TLVs are available only in Level 2 LSPs. The others are shared TLVs and can be used in both Level 1 and Level 2 LSPs (refer to Table 5-3). As in Table 5-3, the TLV type and the standard in which a TLV was originally specified are shown in this table.

Table 5-4. Level-2 TLVs

TLV	Type	Source
Area Address	1	ISO 10589
Intermediate System Neighbors	2	ISO 10589
Partition-Designated Level 2 Intermediate System	4	ISO 10589
Prefix Neighbors	5	ISO 10589
Authentication Information	10	ISO 10589
IP Internal Reachability Information	128	RFC 1195
Protocols Supported	129	RFC 1195
IP External Reachability Information	130	RFC 1195
Interdomain Routing Protocol Information	131	RFC 1195
IP Interface Address	132	RFC 1195

The uses of the various Level 2 TLVs are as follows:

• Area Address ” Type 1. Same as defined for Level 1 LSPs.

• Intermediate System Neighbors ” Type 2. Same as defined for Level 1 LSPs.

• Partition-Designated Level 2 Intermediate System TLV ” This TLV supports partition repair of a partitioned Level 1 area by creating a virtual path over the backbone between two Level 2 routers in each of the partitions. Partition repair is currently not supported on Cisco routers.

  - Type (1 byte) ” 4
  
  

  - Length (1 byte) ” Length of SysID
  
  

  - Value ” SysID of partition-designated Level 2 IS
  
  

• Prefix Neighbors TLV ” This TLV collects information on reachable NSAP prefixes. The TLV is relevant only for ISO CLNP routing between areas (Level 2 routing). Prefixes with the same metric value are bundled together in the same TLV. There can be multiples of this TLV in an LSP, and it can occur in any fragment of an LSP.

  - Type (1 byte) ” 5.
  
  

  - Length (1 byte) ” Total length of the Value field.
  
  

  - Value ” Each Prefix Neighbor TLV consists of 4 bytes of common metric + multiples of (1-byte address prefix length + address prefix).
  
  

  Authentication Information TLV ” Type 10. Same as defined for Level 1 LSPs.

• IP Internal Reachability Information ” Type 128. Same as defined for Level 1 LSPs.

• Protocols Supported ” Type 129. Same as defined for Level 1 LSPs.

• IP External Reachability Information ” This TLV collects IP routes obtained from other routing protocol sources by means of redistribution into IS-IS:

  - Type (1 byte) ” 130
  
  

  - Length (1 byte) ” n x 12, where n is the number of external routes
  
  

  - Value ” Multiples of 4-byte metric information + (4-byte IP prefix and 4-byte prefix mask)
  
  

  Only the IS-IS default metric type is supported on Cisco routers. When configuring redistribution on a Cisco router, two choices of metric labels for external routes apply: internal or external. The actual value applied to external routes depend on the label selected in the configuration. Redistribution is covered in detail in Chapter 9.

• Interdomain Routing Protocol Information (IDRPI) TLV ” This TLV is specified in RFC 1195 to support interaction of the IS-IS protocol with any Interdomain Routing Protocol running on the boundary of the IS-IS domain. It is currently not supported in Cisco IOS Software:

  - Type (1 byte) ” 131.
  
  

  - Length (1 byte) ” Total length of the Value field.
  
  

  - Value ” This field is made up of two components.
  
  

  A byte specifies the type of Interdomain Information field as follows:

  0 “ Reserved.

  1 “ External Information field has special format.

  2 “ External Information field contains a single 2-byte autonomous system (AS) number. The AS number is to be used for tagging all subsequent IP external reachability information in the LSP up to the occurrence of another IDRPI TLV.

  External Information field, which depends on the type of the Interdomain Information field.

• IP Interface Address TLV ” Type 132. Same as defined for Level 1 LSPs. The TLV can occur multiple times and in any LSP fragment. The same addresses must be in both Level 1 and Level 2 LSPs if the router is Level 1-2.

Example 5-5 shows a Level 2 LSP from a Cisco router. Some of the information in this LSP is also present in the Level 1 LSP displayed from the same router (refer to Example 5-4). Information specific to the Level 2 LSP is the IP External Reachability Information TLV. The ES Neighbors TLV is present in only the Level 1 LSP and the two LSP share a common IP address in the IP Interface TLV (11.1.1.4).

Example 5-5 Level-2 LSP from a Cisco Router

 RTD#  show isis database 0000.0000.0004.00-00 level-2 detail  IS-IS Level-2 LSP 0000.0000.0004.00-00 LSPID                  LSP Seq Num  LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0004.00-00* 0x00000012    0xC837      389            0/0/0  Area Address: 49.0002  NLPID:    0xCC IP Address:  11.1.1.4 Metric: 10 IS 0000.0000.0004.02 Metric: 10 IS 0000.0000.0003.00 Metric: 10 IS 0000.0000.0002.01 Metric: 128 IP-External 172.16.0.0 255.255.0.0 Metric: 10 IP 10.1.2.0 255.255.255.0 Metric: 20 IP 11.1.1.2.255.255.255.255 Metric: 10 IP 11.1.1.4 255.255.255.255 Metric: 10 IP 192.168.2.12 255.255.255.252 

IS-IS Metrics Information

TLVs specified by ISO 10589 contain metric information:

• ES Neighbors TLV (Type 2)

• IS Neighbors TLV (Type 3)

• Prefix Neighbors TLV (Type 5)

The overall formats of these TLVs exhibit minor differences; however, the format ofthe metric fields is the same in all of them. Figure 5-8 shows the metric fields in the IS Neighbors TLV. Of the following four types of metric specified, only the default is currently supported on Cisco routers:

Figure 5-8. IS Neighbors TLV metric fields.

• Default metric ” Must be supported by all routers in the domain. Frequently interpreted as a measure that is inversely proportional to bandwidth. Therefore, lower values imply high bandwidth and are better.

• Delay metric ” Optional. Measures the transit delay of a link.

• Expense metric ” Optional. Measures the financial- related costs of using a link.

• Error metric ” Optional. Measures the residual error probability of a link.

Bit 8 (the S bit) of each metric byte indicates support for the specific metric. For the default metric, this bit is reserved and is always set to 0. In the case of the other metric types, if bit 8 is set, the metric is unsupported. Bit 7 is this internal/external bit. It is set to 0 to indicate that the specific metric is an internal type and to 1 to indicate external type.

The following IP information TLVs specified by RFC 1195 also contain metric information:

• IP Internal Reachability TLV (Type 128)

• IP External Reachability TLV (Type 130)

Figure 5-9 shows the layout of the metric fields in the IP Internal Reachability TLV, which is quite similar to the format of the IS Neighbors TLV, as shown in Figure 5-8. Obviously, RFC 1195 borrows directly from the metric definitions of ISO 10589. Notice that, in Figure 5-9, only the default metric has the I/E field. The setting for the default metric (internal or external) applies to all the other metrics. The I/E bit fields in the other bytes are reserved.

Figure 5-9. IP Internal Reachability metric fields (TLV 128/ TLV 130).

The default metric must be supported on all nodes in the routing domain. The delay, expense, and error metrics are optional and are specified to support quality-of-service routing. The delay, expense, and error metrics are relevant to path selection criteria defined by the Globally Unique Quality of Service parameters that can be set in the Quality of Service (QoS) Maintenance field of a CLNP packet header. The QoS Maintenance field specifies optional path selection criteria by the network services user .

Each type of metric is independent of the other, and their consideration in path selection relative to each other depends on various bit settings of the QoS Maintenance field in conjunction with selection of a globally unique QoS criterion. Each type of metric is allocated a byte in the TLV. Setting bit 8 (S) of a QoS metric indicates that it is not supported. Because the default metric must be supported, its bit value 8 is specified as 0. As indicated previously, currently none of the optional QoS-related metrics are supported in Cisco IOS. Only the default metric is available as path selection criteria. The default metric is a scalar parameter referred to as cost. In most current applications, it is given an inverse bandwidth connotation. It is essentially a numeric representation of the traffic-handling capacity of a link.

In subsequent text, any reference to a metric implies the default metric, which is the only type IS-IS metric supported on Cisco routers. As discussed previously, bit 7 of the metric field is used to classify the metric as internal or external. Internal metrics refer to routes generated within the IS-IS domain, whereas external metrics refer to routes originating outside the local domain or from another routing protocol source. With bit 8 reserved and bit 7 for internal or external classification, only the remaining 6 bits of the metric byte are available for the metric value. Using 6 bits for the metric value gives a maximum value of 63 per link.

On Cisco routers, metric values are configured on interfaces and apply to the outgoing link. IOS does not automatically assign the link metric based on bandwidth. The default value for IS-IS metrics on all interfaces, regardless of connecting link speed, is 10. Link metric can be modified by configuration. For computational purposes, the metric must be a positive value, and 1 is recommended as the minimum. The total metric for a path is the sum metric on the outgoing interfaces of all links between source and destination. ISO 10589 specifies the maximum metric value for a complete path to be only 1023. Therefore, it is important for operators to plan link metric assignments to achieve the desired path differentiation.

The next section discusses recent IETF extensions to the IS-IS protocol that increase the maximum values of the default metric. The extension introduces more flexibility in metric assignment and facilitates the designing of IS-IS networks. It also provides support for recent innovations in IP routing, such as IS-IS-based MPLS traffic engineering.