RFC 3784

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

📅 published June 2004, from ietf

Network Working Group RFC 3784 🎀

Okay bestie, here's the title block tea ☕: RFC 3784 is called Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) 💖. It was written by H. Smit (Procket Networks) and T. Li 🧚. It's Category: Informational, which means it's sharing info with the Internet community, not setting a standard ✨. The date is June 2004 🌸. It doesn't list anything it obsoletes or updates, so no drama there 💅.

Status of this Memo ✨

Okay so this memo gives info to the Internet community. It is NOT an Internet standard of any kind 🙈. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2004).

Abstract 🌈

This doc describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol so it can support Traffic Engineering (TE) ✨. It adds new info that an Intermediate System (router) can put in Link State Protocol (LSP) Data Units 💅. That info describes extra details about the state of the network, and those details are super useful for traffic engineering math 🧮🔥.

1. Introduction 💖

The IS-IS protocol is specified in ISO 10589 [1], and its IPv4 extensions are specified in RFC 1195 [3] 🎀. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing info 🌸. Each LSP is made of a fixed header plus a bunch of tuples, and each tuple has a Type, a Length, and a Value 🧚. Those tuples are commonly called TLVs, and they're a seriously good way to encode info in a flexible, extensible format 👑.

This doc has the design for new TLVs that replace the existing IS Neighbor TLV and IP Reachability TLV ✨. It also adds more info about the characteristics of a particular link to an IS-IS LSP 🦋. The characteristics in this doc are needed for Traffic Engineering [4] (TE) 💅. The secondary goals are increasing the dynamic range of the IS-IS metric and improving how IP prefixes are encoded 🔥.

The router id is useful for traffic engineering because it describes a single address that can always be used to reference a particular router 🫶.

Mechanisms and procedures for migrating to the new TLVs are NOT discussed in this doc 🙈.

2. Introducing Sub-TLVs 🧚

Okay this is the big new idea: this doc introduces a new way to encode routing info in IS-IS, and the new object is called a sub-TLV 💖. Sub-TLVs are similar to regular TLVs and use the same concepts 🌈. The difference is WHERE they live: TLVs exist inside IS-IS packets, while sub-TLVs exist inside TLVs 💅. TLVs add extra info to IS-IS packets, and sub-TLVs add extra info to particular TLVs ✨.

Each sub-TLV has three fields: a one-octet Type field, a one-octet Length field, and zero or more octets of Value 🎀. The Type field says what kind of items are in the Value field 🦋. The Length field gives 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 worked out from the length of the whole sub-TLV, as long as 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 📚. If 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 🎀.

Okay so the existing IS reachability (TLV type 2, defined in ISO 10589 [1]) holds info about a series of IS neighbors 🌸. For each neighbor there's a structure with the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor 🧚. Of all that, the default metric is the one that's commonly used 💖. The default metric is currently one octet, with one bit saying whether the metric is internal or external, and one bit that was originally unused but was later defined by RFC 2966 as the up/down bit 🦋. The remaining 6 bits store the actual metric, which gives a possible metric range of 0-63 😭. This limitation is one of the restrictions we'd like to lift 🔥.

The other three metrics (delay, monetary cost, and reliability) aren't commonly implemented and just reflect unused overhead in the TLV 💀. The neighbor is identified by its system ID, typically 6-octets, plus one octet for the pseudonode number 🌈. So the existing TLV eats 11 octets per neighbor: 4 octets for metric and 7 octets for neighbor identification 🍓. To show multiple adjacencies, this structure gets repeated within the IS reachability TLV 💜. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors 🙈. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors ✨.

The proposed extended IS reachability TLV has a new data structure made of:

      7 octets of system Id and pseudonode number
      3 octets of default metric
      1 octet of length of sub-TLVs
      0-244 octets of sub-TLVs,
           where each sub-TLV consists of a sequence of
                1 octet of sub-type
                1 octet of length of the value field of the sub-TLV
                0-242 octets of value

So if no sub-TLVs are used, the new encoding needs 11 octets and can contain up to 23 neighbors 🎀. Please note that while the encoding allows for 255 octets of sub-TLVs, that maximum value can't fit in the overall IS reachability TLV 🫶. The practical maximum is 255 octets minus the 11 octets described above, which is 244 octets 🧮. Also, there's no defined mechanism for extending the sub-TLV space for a particular neighbor, so wasting sub-TLV space is discouraged 🙅‍♀️.

The metric octets are encoded as a 24-bit unsigned integer 🦋. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer 💅. These different sizes were picked so that it's very unlikely the cost of an intra-area route has to get chopped off to fit in the metric field of an inter-area route 🌸.

To prevent overflow inside a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC 🔥. It's easiest to select MAX_PATH_METRIC so that MAX_PATH_METRIC plus a single link metric doesn't overflow the number of bits for internal metric calculation 🧚. We assume that's 32 bits 💜. So MAX_PATH_METRIC was chosen to be 4,261,412,864 (0xFE000000, 2^32 - 2^25) 👑.

If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. This lets a link be advertised for purposes other than building the normal Shortest Path Tree 🚨. An example is a link that's available for traffic engineering but NOT for hop-by-hop routing 💀.

Certain sub-TLVs are proposed here 💖:

   Sub-TLV type  Length (octets)  Name
      3               4           Administrative group (color)
      6               4           IPv4 interface address
      8               4           IPv4 neighbor address
      9               4           Maximum link bandwidth
      10              4           Reservable link bandwidth
      11              32          Unreserved bandwidth
      18              3           TE Default metric
      250-254                     Reserved for cisco specific extensions
      255                         Reserved for future expansion

Each of these sub-TLVs is described below 🌈. Unless stated otherwise, multiple occurrences of the info are supported by multiple inclusions of the sub-TLV 🫶.

3.1. Sub-TLV 3: Administrative group (color, resource class) 🌈

The administrative group sub-TLV has a 4-octet bit mask assigned by the network administrator 🎀. Each set bit corresponds to one administrative group assigned to the interface 💜.

By convention, the least significant bit is called 'group 0', and the most significant bit is called 'group 31' 🦋.

This sub-TLV is OPTIONAL 🙈. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV 💅.

3.2. Sub-TLV 6: IPv4 interface address 🧚

This sub-TLV has a 4-octet IPv4 address for the interface described by the (main) TLV 🌸. This sub-TLV can occur multiple times 💖.

Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV 😭.

If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency ✨. If a router implements traffic engineering, it MUST include this sub-TLV 🔥.

3.3. Sub-TLV 8: IPv4 neighbor address 🍓

This sub-TLV has a single IPv4 address for a neighboring router on this link 🎀. This sub-TLV can occur multiple times 🦋.

Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV 💀.

If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency 🌈. If a router implements traffic engineering, it MUST include this sub-TLV on point-to-point adjacencies 👑.

This sub-TLV has the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors) 🫶. That's really useful for traffic engineering 🔥.

The maximum link bandwidth is encoded in 32 bits in IEEE floating point format 🧮. The units are bytes (not bits!) per second 💅.

This sub-TLV is optional 🌸. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV ✨.

This sub-TLV has the maximum amount of bandwidth that can be reserved in this direction on this link 💖. Note that for oversubscription purposes, this can be greater than the bandwidth of the link 🧚.

The maximum reservable link bandwidth is encoded in 32 bits in IEEE floating point format 🎀. The units are bytes (not bits!) per second 🌈.

This sub-TLV is optional 💅. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV 🔥.

3.6. Sub-TLV 11: Unreserved bandwidth ✨

okay so this sub-TLV spills the tea on how much bandwidth can still be reserved in this direction on this link 🦋 and ngl it's giving generous, because the number can be bigger than the link's actual bandwidth if you're oversubscribing on purpose 💅

Each head end needs to know how much bandwidth is reserved at each priority level, because priority and preemption are a whole thing 👑 So this sub-TLV holds eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second 🙈 The values line up with the bandwidth that can be reserved at setup priority 0 through 7, in increasing order. Priority 0 sits at the start of the sub-TLV and priority 7 sits at the end.

For stability, rapid changes in the values in this sub-TLV SHOULD NOT cause rapid generation of LSPs 🫶

This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV 🌸

3.7. Sub-TLV 18: Traffic Engineering Default Metric 🧚

this one holds a 24-bit unsigned integer. The metric is administratively assigned, and it's how you present a differently weighted topology to traffic engineering SPF calculations. it's giving custom map 🗺️✨

Now, to keep things from overflowing inside a traffic engineering SPF implementation, every metric greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC 😭 The easiest move is picking a MAX_PATH_METRIC where MAX_PATH_METRIC plus a single link metric still fits in the number of bits used for internal metric calculation. We assume that's 32 bits. So we picked MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). Iconic, honestly 💜

This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV. If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV 🍓

4. The Extended IP Reachability TLV 🎀

the extended IP reachability TLV is TLV type 135 🌈

The existing IP reachability TLVs (TLV type 128 and TLV type 130, defined in RFC 1195 [3]) carry IP prefixes in a format that's similar to the IS neighbor TLV from ISO 10589 [1]. They carry four metrics, but only the default metric is really used. That default metric has a possible range of 0-63, and we'd love to remove that restriction 🙄

Route redistribution (a.k.a. route leaking) also has a big problem that the existing IP reachability TLVs didn't fully fix. RFC 1195 [3] lets a router advertise prefixes upwards in the level hierarchy. Unfortunately, there was no mechanism defined to advertise prefixes downwards 💀

So to fix both of these, the proposed extended IP reachability TLV gives us a 32 bit metric and adds one bit to show that a prefix has been redistributed 'down' in the hierarchy ✨

The proposed extended IP reachability TLV contains a new data structure, consisting of:

   4 octets of metric information
   1 octet of control information, consisting of
        1 bit of up/down information
        1 bit indicating the presence of sub-TLVs
        6 bits of prefix length
   0-4 octet of IPv4 prefix
   0-250 optional octets of sub-TLVs, if present consisting of
        1 octet of length of sub-TLVs
        0-249 octets of sub-TLVs,
             where each sub-TLV consists of a sequence of
                  1 octet of sub-type
                  1 octet of length of the value field of the sub-TLV
                  0-247 octets of value

This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV 🫧

The 6 bits of prefix length can have the values 0-32 and show the number of significant bits in the prefix. The prefix is encoded in the minimal number of octets for the given number of significant bits. So:

      Significant bits                Octets
      0                               0
      1-8                             1
      9-16                            2
      17-24                           3
      25-32                           4

The remaining bits of prefix are transmitted as zero and ignored upon receipt 🧼

If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This lets you advertise a prefix for stuff other than building the normal IP routing table, which is a whole vibe 🦋

4.1. The up/down Bit 🔥

if routers were allowed to redistribute IP prefixes freely in both directions between level 1 and level 2 with no extra mechanisms, they wouldn't be able to tell when routing information is looping 😵‍💫 Here's the nightmare: a router learns a prefix through level 2 routing and advertises it down into a level 1 area. Another router in that area might pick it up and advertise it back up into the level 2 backbone. If the original source withdraws the prefix, those two routers could end up in a routing loop, where part of the path goes through level 1 routing and the other part goes through level 2 routing. RFC 1195 [3] handled this by only allowing prefixes to be advertised upward, and disallowing advertising them downward in the hierarchy.

To stop prefixes from looping between levels, the new extended IP reachability TLV defines a new bit called the up/down bit. The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit MUST be set to 1, which means the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e. to lower levels 🙅‍♀️

These semantics still apply even if IS-IS gets extended in the future with additional levels. By making sure prefixes only follow the IS-IS hierarchy, the information can't loop, and that means there are no persistent forwarding loops 💅

If a prefix is advertised from one area to another at the same level, then the up/down bit SHALL be set to 1. This can happen when a router runs multiple virtual routers at the same level, but in different areas 🌸

The semantics of the up/down bit in the new extended IP reachability TLV are identical to the semantics of the up/down bit defined in RFC 2966 [2] ✨

4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs 🧚‍♀️

The extended IP reachability TLV can hold sub-TLVs that apply to a particular prefix, which makes future extensions super easy 🌈 If there are no sub-TLVs associated with a prefix, the bit indicating the presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the first octet after the prefix is read as the length of all sub-TLVs associated with this IPv4 prefix. Please note that even though the encoding allows for 255 octets of sub-TLVs, that maximum can't fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets 🙈

This document does not define any sub-TLVs for the extended IP reachability TLV.

5. The Traffic Engineering Router ID TLV 👑

the Traffic Engineering router ID TLV is TLV type 134 🦋

The router ID TLV contains the 4-octet router ID of the router that originates the LSP. This is useful in a few ways 🫶

For traffic engineering, it guarantees a single stable address that can always be referenced in a path that's reachable from multiple hops away, no matter what state the node's interfaces are in 🌟

If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies 🍓

If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP 🧼

If a router advertises the Traffic Engineering router ID TLV in its LSP, and it advertises prefixes via the Border Gateway Protocol (BGP) with the BGP next hop attribute set to the BGP router ID, the Traffic Engineering router ID SHOULD be the same as the BGP router ID 💜

Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table, because that can lead to forwarding loops when interacting with systems that don't support this TLV. Bestie, don't do it 💀

6. IANA Considerations 📋

6.1. TLV Codepoint Allocations

This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV code-point registry:

   Type        Description                            IIH   LSP   SNP
   ----        -----------------------------------    ---   ---   ---
    22         The extended IS reachability TLV        n     y     n
    134        The Traffic Engineering router ID TLV   n     y     n
    135        The extended IP reachability TLV        n     y     n

6.2. New Registries

IANA has created the following new registries.

6.2.1. Sub-TLVs for the Extended IS Reachability TLV

This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).

Taking into consideration the allocations specified in this document, the registry has been initialized as follows:

      Type        Description
      ----        -----------------------------------
      0-2         unassigned
       3          Administrative group (color)
      4-5         unassigned
       6          IPv4 interface address
       7          unassigned
       8          IPv4 neighbor address
       9          Maximum link bandwidth
       10         Reservable link bandwidth
       11         Unreserved bandwidth
      12-17       unassigned
       18         TE Default metric
      19-254      unassigned
       255        Reserved for future expansion

6.2.2. Sub-TLVs for the Extended IP Reachability TLV

This registry contains codepoints for Sub-TLVs of TLV 135. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).

No codepoints are defined in this document.

7. References 📚

7.1. Normative References

  • [1] ISO, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589:2002, Second Edition
  • [2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.

7.2. Informative References

  • [3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990
  • [4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
  • [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8. Security Considerations ✨

okay so this one is short and sweet 🎀 this document raises no new security issues for IS-IS 🔒🫶 that's it, that's the whole tea. no new attack surface, nothing new to panic about 💅

9. Acknowledgments 🌸

the authors wanted to give a big shoutout to Yakov Rekhter and Dave Katz for their comments on this work 🫶 they're the real MVPs, literally 👑

10. Authors' Addresses 🦋

these are the people who wrote it, bestie 💖

Henk Smit EMail: hhwsmit@xs4all.nl

Tony Li EMail: tony.li@tony.li

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

this document and the information in it are provided on an "AS IS" basis 🫠 and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. no guarantees, no vibes-based promises, just vibes 💀

Intellectual Property 🧠

the IETF takes no position on whether any intellectual property rights that might be claimed to cover the technology in this document are valid or in scope 🤷‍♀️ and it doesn't say whether any license under those rights would or wouldn't be available. it also doesn't claim it did any independent digging to find such rights 👀

info on how rights work for RFC documents can be found in BCP 78 and BCP 79 📚

copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌈

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 💜

funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from