RFC 5073

IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities

📅 published December 2007, from ietf

Okay bestie, RFC 5073 is giving "how to tell the whole network what your router can do" 🦋✨

RFC 5073 is titled IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities 💖 It's from the Network Working Group, and the authors are J.P. Vasseur, Ed. (Cisco Systems, Inc.) and J.L. Le Roux, Ed. (France Telecom). It's a Standards Track doc, dated December 2007. This copy has no Obsoletes or Updates line, so it doesn't list any documents it replaces or changes 📜

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract 🌸

It's highly desired, in several cases, to take TE node capabilities into account when picking a Traffic Engineered LSP during MPLS and GMPLS path selection. A great example is being able to act as a branch LSR on a P2MP LSP 🌳 To make that work, these capabilities have to be advertised in the IGP. So this doc specifies OSPF and IS-IS traffic engineering extensions to advertise the control plane and data plane TE node capabilities 💜

Table of Contents 🗺️

   1. Introduction.....................................................2
   2. Terminology......................................................3
   3. TE Node Capability Descriptor ...................................3
      3.1. Description ................................................3
      3.2. Required Information .......................................3
   4. TE Node Capability Descriptor TLV Formats .......................4
      4.1. OSPF TE Node Capability Descriptor TLV Format ..............4
      4.2. IS-IS TE Node Capability Descriptor sub-TLV format .........5
   5. Elements of Procedure ...........................................6
      5.1. OSPF .......................................................6
      5.2. IS-IS ......................................................7
   6. Backward Compatibility ..........................................8
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
      8.1. OSPF TLV ...................................................8
      8.2. ISIS sub-TLV ...............................................8
      8.3. Capability Registry ........................................9
   9. Acknowledgments .................................................9
   10. References ....................................................10
      10.1. Normative References .....................................10
      10.2. Informative References ...................................11

1. Introduction ✨

Okay so MPLS-TE routing ([RFC3784], [RFC3630], [OSPFv3-TE]) leans on extensions to link state IGPs ([IS-IS], [RFC1195], [RFC2328], [RFC2740]) to advertise TE link info for constraint-based routing. GMPLS routing extensions live in [RFC4205] and [RFC4203] 🧚

The next move is to complement those by advertising TE node capabilities too, not just link info. These node capabilities then count as constraints during path selection 💅

It's super useful to advertise data plane TE node capabilities, like whether an LSR can be a branch LSR or a bud-LSR on a P2MP LSP. Those capabilities can be used as constraints when computing the route of TE LSPs 🌈

Control plane TE node capabilities matter too. Think about support for GMPLS signaling on a packet LSR, or support for P2MP TE LSP signaling. This lets you pick a path that skips nodes without a given control plane feature, or trigger a mechanism to support those nodes on the path. Which, bestie, means better backward compatibility 🫶

So this doc specifies IGP (OSPF and IS-IS) extensions to advertise the data plane and control plane capabilities of a node 🔥

For OSPF, there's a new TLV called the TE Node Capability Descriptor TLV, carried within the Router Information LSA ([RFC4970]). For IS-IS, there's a new sub-TLV called the TE Node Capability Descriptor sub-TLV, carried within the IS-IS Capability TLV ([RFC4971]) 🎀

2. Terminology 🎀

This document uses terminologies defined in [RFC3031], [RFC3209], and [RFC4461].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

3. TE Node Capability Descriptor 💅

3.1. Description

LSRs in a network can have different control plane and data plane TE capabilities 🌸 The TE Node Capability Descriptor info in this doc describes the data and control plane capabilities of an LSR. Path computation can use that info to avoid nodes that don't support a given TE feature in either plane, or to trigger procedures that handle those nodes along the path. For example, you could trigger LSP hierarchy to support a legacy transit LSR on a P2MP LSP (see [RFC4875]) 🦋

3.2. Required Information

The TE Node Capability Descriptor has a variable-length set of bit flags, and each bit stands for one TE node capability 🌈

Five TE Node Capabilities are defined in this document:

B bit: when set, this flag indicates that the LSR can act as a branch node on a P2MP LSP (see [RFC4461]);
E bit: when set, this flag indicates that the LSR can act as a bud LSR on a P2MP LSP, i.e., an LSR that is both transit and egress (see [RFC4461]);
M bit: when set, this flag indicates that the LSR supports MPLS-TE signaling ([RFC3209]);
G bit: when set this flag indicates that the LSR supports GMPLS signaling ([RFC3473]);
P bit: when set, this flag indicates that the LSR supports P2MP MPLS-TE signaling ([RFC4875]).

Note that new capability bits may be added in the future if required 🔮

4. TE Node Capability Descriptor TLV Formats 🦋

4.1. OSPF TE Node Capability Descriptor TLV Format

The OSPF TE Node Capability Descriptor TLV is a variable-length TLV with a series of bit flags, where each bit corresponds to a TE node capability. The bit-field MAY be extended with additional 32-bit words if more bit flags need to be assigned. Any unknown bit flags SHALL be treated as Reserved bits 💖

This TLV is carried within an OSPF Router Information LSA, which is defined in [RFC4970] 🧚

The format is the same as the TLV format used by the Traffic Engineering Extensions to OSPF ([RFC3630]). So the TLV is 2 octets for the type, 2 octets for the length of the value field, and then the value field itself 🎀

The OSPF TE Node Capability Descriptor TLV has this format:

   TYPE:     5 (see Section 8.1)
   LENGTH:   Variable (multiple of 4).
   VALUE:    Array of units of 32 flags numbered from the most
             significant bit as bit zero, where each bit represents
             a TE node capability.

These bits are defined:

   Bit       Capabilities

   0      B bit: P2MP Branch Node capability: When set, this indicates
          that the LSR can act as a branch node on a P2MP LSP
          [RFC4461].
   1      E bit: P2MP Bud-LSR capability: When set, this indicates
          that the LSR can act as a bud LSR on a P2MP LSP, i.e., an
          LSR that is both transit and egress [RFC4461].
   2      M bit: If set, this indicates that the LSR supports MPLS-TE
          signaling ([RFC3209]).
   3      G bit: If set, this indicates that the LSR supports GMPLS
          signaling ([RFC3473]).
   4      P bit: If set, this indicates that the LSR supports P2MP
          MPLS-TE signaling ([RFC4875]).

   5-31   Reserved for future assignments by IANA.

Reserved bits MUST be set to zero on transmission, and MUST be ignored on reception. If the length field is greater than 4, meaning there are more than 32 bits in the value field, then any extra bits (the ones not yet assigned) are reserved 🙈

4.2. IS-IS TE Node Capability Descriptor sub-TLV format

The IS-IS TE Node Capability Descriptor sub-TLV is a variable-length sub-TLV with a series of bit flags, where each bit corresponds to a TE node capability. The bit-field MAY be extended with additional bytes if more bit flags need to be assigned. Any unknown bit flags SHALL be treated as Reserved bits 💅

This sub-TLV is carried within an IS-IS CAPABILITY TLV, which is defined in [RFC4971] 🌈

The format is the same as the sub-TLV format used by the Traffic Engineering Extensions to IS-IS ([RFC3784]). So the sub-TLV is 1 octet for the type and 1 octet for the length of the value field 🍓

The IS-IS TE Node Capability Descriptor sub-TLV has this format:

   TYPE:   1 (see Section 8.2)
   LENGTH: Variable
   VALUE:  Array of units of 8 flags numbered from the most
           significant bit as bit zero, where each bit represents
           a TE node capability.

These bits are defined:

    Bit       Capabilities

     0      B bit: P2MP Branch Node capability: When set, this indicates
            that the LSR can act as a branch node on a P2MP LSP
            [RFC4461].
     1      E bit: P2MP Bud-LSR capability: When set, this indicates
            that the LSR can act as a bud LSR on a P2MP LSP, i.e., an
            LSR that is both transit and egress [RFC4461].
     2      M bit: If set, this indicates that the LSR supports MPLS-TE
            signaling ([RFC3209]).
     3      G bit: If set, this indicates that the LSR supports GMPLS
            signaling ([RFC3473]).
     4      P bit: If set, this indicates that the LSR supports P2MP
            MPLS-TE signaling ([RFC4875]).

     5-7    Reserved for future assignments by IANA.

Reserved bits MUST be set to zero on transmission, and MUST be ignored on reception. If the length field is greater than 1, meaning there are more than 8 bits in the value field, then any extra bits (the ones not yet assigned) are reserved 🫶

5. Elements of Procedure 👑

5.1. OSPF 💅

okay so this TLV rides inside an OSPFv2 Router Information LSA (Opaque type of 4 and Opaque ID of 0) or an OSPFv3 Router Information LSA (function code of 12) 🦋 both defined in [RFC4970]. that means the elements of procedure are inherited from [RFC2328], [RFC2740], and [RFC4970]. no need to reinvent the wheel, bestie 🫶

The TE Node Capability Descriptor TLV advertises capabilities that can be taken into account as constraints during path selection, so its flooding scope is area-local ✨. It MUST be carried within an OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an OSPFv3 Router Information LSA with the S1 bit set and the S2 bit cleared (as defined in [RFC2740]). main character energy, literally 👑

A router MUST originate a new OSPF Router Information LSA whenever the content of the TE Node Capability Descriptor TLV changes, or whenever the regular OSPF procedure requires it (LSA refresh, every LSRefreshTime) 🔥

The TE Node Capability Descriptor TLV is OPTIONAL and MUST NOT appear more than once in an OSPF Router Information LSA 🙈. If one shows up more than once anyway, only the first occurrence MUST be processed, and the others MUST be ignored. not me reading the duplicates 💀

When an OSPF Router Information LSA does not contain any TE Node Capability Descriptor TLV, that means the TE node capabilities of that LSR are unknown 🌸

Note that a change in any of these capabilities MAY trigger Constrained Shortest Path First (CSPF) computation, but it MUST NOT trigger normal SPF computation. the vibe check is that CSPF can wake up, normal SPF stays asleep 😴

Note also that TE node capabilities are expected to be fairly static. they can change because of a configuration change or a software upgrade, but this is expected not to appear more than once a day 🍓

5.2. IS-IS

The TE Node Capability sub-TLV is carried within an IS-IS CAPABILITY TLV defined in [RFC4971], so the elements of procedure are inherited from [RFC4971] 🧚

The TE Node Capability Descriptor sub-TLV advertises capabilities that can be taken into account as constraints during path selection. its flooding is area-local, so it MUST be carried within an IS-IS CAPABILITY TLV having the S flag cleared 💖

An IS-IS router MUST originate a new IS-IS LSP whenever the content of any of the TE Node Capability sub-TLV changes, or whenever the regular IS-IS procedure requires it (LSP refresh) ✨

The TE Node Capability Descriptor sub-TLV is OPTIONAL and MUST NOT appear more than once in an ISIS Router Capability TLV 🎀

When an IS-IS LSP does not contain any TE Node Capability Descriptor sub-TLV, that means the TE node capabilities of that LSR are unknown 🦋

Note that a change in any of these capabilities MAY trigger CSPF computation, but it MUST NOT trigger normal SPF computation. same energy as the OSPF side, obviously 💅

Note also that TE node capabilities are expected to be fairly static. they can change due to a configuration change or a software upgrade. this is expected not to appear more than once a day 🌈

6. Backward Compatibility 🫧

The TE Node Capability Descriptor TLVs defined in this document do not introduce any interoperability issues 🫶. For OSPF, a router that doesn't support the TE Node Capability Descriptor TLV will just silently ignore the TLV, as specified in [RFC4970]. For IS-IS, a router that doesn't support the TE Node Capability Descriptor sub-TLV will just silently ignore the sub-TLV, as specified in [RFC4971] 🌸

When the TE Node Capability Descriptor TLV is absent, that means the TE Capabilities of that LSR are unknown 🙈

The absence of a word of capability flags in OSPF, or an octet of capability flags in IS-IS, means that these capabilities are unknown 🍓

7. Security Considerations 🔐

okay this part is SERIOUS 😭. This document specifies the content of the TE Node Capability Descriptor TLV in IS-IS and OSPF, to be used for (G)MPLS-TE path computation. because this TLV is not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing 💜. BUT tampering with this TLV may have an effect on Traffic Engineering computation, so it's giving "guard it". Mechanisms defined to secure IS-IS Link State PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs can be used to secure this TLV as well 🔥

8. IANA Considerations 🌷

8.1. OSPF TLV

[RFC4970] defines a new codepoint registry for TLVs carried in the Router Information LSA defined in [RFC4970] 🧚

IANA has made a new codepoint assignment from that registry for the TE Node Capability Descriptor TLV defined in this document and carried within the Router Information LSA. the value is 5 ✨. See Section 4.1 of this document.

8.2. ISIS sub-TLV

IANA has defined a registry for sub-TLVs of the IS-IS CAPABILITY TLV defined in [RFC4971] 🎀

IANA has made a new codepoint assignment from that registry for the TE Node Capability Descriptor sub-TLV defined in this document, carried within the ISIS CAPABILITY TLV. the value is 1 💖. See Section 4.2 of this document.

8.3. Capability Registry

IANA has created a new registry to manage the space of capability bit flags carried within the OSPF and ISIS TE Node Capability Descriptor 🦋

A single registry must be defined for both protocols. a new base registry has been created to cover IGP-TE registries that apply to both OSPF and IS-IS, and the new registry requested by this document is a sub-registry of that base registry 👑

Bits in the new registry should be numbered in the usual IETF notation, starting with the most significant bit as bit zero 🌈

New bit numbers may be allocated only by an IETF Consensus action 🔒

Each bit should be tracked with the following qualities:

Bit number
Defining RFC
Name of bit

IANA has made assignments for the five TE node capabilities defined in this document (see Sections 8.1 and 8.2) using the following values:

Bit No.  Name                                    Reference
--------+---------------------------------------+---------------
0        B bit: P2MP Branch LSR capability       [RFC5073]
1        E bit: P2MP Bud LSR capability          [RFC5073]
2        M bit: MPLS-TE support                  [RFC5073]
3        G bit: GMPLS support                    [RFC5073]
4        P bit: P2MP RSVP-TE support             [RFC5073]
5-7      Unassigned                              [RFC5073]

9. Acknowledgments 💕

we would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri Papadimitriou, Acee Lindem, and David Ward for their useful comments and suggestions 🫶

We would also like to thank the authors of [RFC4420] and [RFC4970], by which some text of this document has been inspired ✨

Adrian Farrel prepared the final version of this document for submission to the IESG 👑

10. References 📚

10.1. Normative References

[RFC1195]    Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
             dual environments", RFC 1195, December 1990.

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2328]    Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC2370]    Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
             1998.

[RFC2740]    Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
             RFC 2740, December 1999.

[RFC3031]    Rosen, E., Viswanathan, A., and R. Callon,
             "Multiprotocol Label Switching Architecture", RFC 3031,
             January 2001.

[RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
             V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.

[RFC3473]    Berger, L., Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
             3473, January 2003.

[RFC3630]    Katz, D., Kompella, K., and D. Yeung, "Traffic
             Engineering (TE) Extensions to OSPF Version 2", RFC
             3630, September 2003.

[RFC3784]    Smit, H. and T. Li, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Traffic Engineering (TE)",
             RFC 3784, June 2004.

[IS-IS]      "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)", ISO 10589.

[RFC4971]    Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
             "Intermediate System to Intermediate System (IS-IS)
             Extensions for Advertising Router Information", RFC
             4971, July 2007.

[RFC4970]    Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R.,
             and S. Shaffer, "Extensions to OSPF for Advertising
             Optional Router Capabilities", RFC 4970, July 2007.

[RFC4875]    Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
             Yasukawa, Ed., "Extensions to Resource Reservation
             Protocol - Traffic Engineering (RSVP-TE) for Point-to-
             Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
             May 2007.

10.2. Informative References

[RFC2154]    Murphy, S., Badger, M., and B. Wellington, "OSPF with
             Digital Signatures", RFC 2154, June 1997.

[RFC3567]    Li, T. and R. Atkinson, "Intermediate System to
             Intermediate System (IS-IS) Cryptographic
             Authentication", RFC 3567, July 2003.

[RFC4203]    Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005.

[RFC4205]    Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
             System to Intermediate System (IS-IS) Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4205, October 2005.

[RFC4420]    Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and
             A. Ayyangar, "Encoding of Attributes for Multiprotocol
             Label Switching (MPLS) Label Switched Path (LSP)
             Establishment Using Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.

[RFC4461]    Yasukawa, S., Ed., "Signaling Requirements for Point-
             to-Multipoint Traffic-Engineered MPLS Label Switched
             Paths (LSPs)", RFC 4461, April 2006.

[OSPFv3-TE]  Ishiguro K., Manral V., Davey A., and Lindem A.,
             "Traffic Engineering Extensions to OSPF version 3", Work
             in Progress.

Contributors' Addresses 🫂

Seisho Yasukawa
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
EMail: s.yasukawa@hco.ntt.co.jp

Stefano Previdi
Cisco Systems, Inc
Via Del Serafico 200
Roma, 00142
Italy
EMail: sprevidi@cisco.com

Peter Psenak
Cisco Systems, Inc
Pegasus Park DE Kleetlaan 6A
Diegmen, 1831
BELGIUM
EMail: ppsenak@cisco.com

Paul Mabbey
Comcast
USA

Editors' Addresses ✍️

Jean-Philippe Vasseur
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
USA
EMail: jpv@cisco.com

Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com

Full Copyright Statement ✨

okay so the legal bit, bestie 🧾💅 Copyright (C) The IETF Trust (2007). the IETF Trust owns the copyright on this one 💜 this document is covered by the rights, licenses, and restrictions in BCP 78, and unless that says otherwise, the authors keep all their rights 🦋

the document and the info in it are provided "AS IS" 🫶 no promises here, bestie 😭 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE all DISCLAIM ALL WARRANTIES, express or implied 💀 that includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose. ngl that's a lot of disclaiming, but it's giving legal safety 🛡️✨

Intellectual Property 🎀

the IETF doesn't take a side on whether any IPR (intellectual property rights) or other rights that might be claimed over the tech in this doc are valid or how far they reach 🙈 it also doesn't say whether any license under those rights is available or not, and it hasn't independently gone looking for any such rights either. if you want the procedures for rights in RFC docs, check out BCP 78 and BCP 79 🌸

copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔥

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 👑 send that info to the IETF at ietf-ipr@ietf.org 💖

📦 where this page comes from

ietf: rfc5073 2007-12
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms