RFC 3480

Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)

📅 published February 2003, from ietf

Part 1 of 2 🎀

Okay bestie, this one is from the Network Working Group 🌸 and it's written by three people: K. Kompella (Juniper Networks), Y. Rekhter (Juniper Networks), and A. Kullberg (NetPlane Systems). It's dated February 2003 and it's on the Standards Track 👑 so it's a real protocol spec, not just a vibe. The title block doesn't list anything this RFC obsoletes or updates, so it's standing on its own 💅

Status of This Memo

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

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒

Abstract

Okay so the problem is that the signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) doesn't support unnumbered links 😭 This document defines the procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), which is one of the MPLS TE signalling protocols that we need in order to support unnumbered links. It's the fix, and it's giving main character energy 💖

Specification of Requirements

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 BCP 14, RFC 2119 [RFC2119]. 📚

1. Overview 🧚

Supporting MPLS TE over unnumbered links (aka links that don't have IP addresses) comes down to two pieces 🍓

  • (a) being able to carry the TE information about unnumbered links in IGP TE extensions (ISIS or OSPF), and
  • (b) being able to specify unnumbered links in MPLS TE signalling.

The first one is covered in [GMPLS-ISIS, GMPLS-OSPF]. This document is all about the second one, so that's our focus 🎯

Here's the tea ☕ Current MPLS TE signalling doesn't support unnumbered links because it has no way to indicate an unnumbered link in its Explicit Route Objects. This document proposes simple procedures and extensions that let CR-LDP signalling [CR-LDP] work with unnumbered links. Simple and iconic 🔥

An unnumbered link has to be a point-to-point link. Then, an LSR at each end of the unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it. If you're using OSPF or ISIS as the IGP for traffic engineering, the IS-IS and/or OSPF and CR-LDP modules on an LSR have to agree on the identifiers 🤝

There's no a priori relationship between the identifiers that the LSRs at each end of a link assign to that link. They're totally independent, no cap 🙈

The LSRs at the two end points of an unnumbered link exchange the identifiers they assigned to the link with each other. That exchange can happen by configuration, by a protocol like LMP ([LMP]), by CR-LDP (especially when the link is a Forwarding Adjacency, more on that below), or by IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]) ✨

Let's say we have an (unnumbered) link between LSRs A and B. LSR A picks an identifier for that link, and so does LSR B. From A's point of view, the identifier A assigned is called the "link local identifier" (or just "local identifier"), and the identifier B assigned is called the "link remote identifier" (or just "remote identifier"). And from B's point of view, it flips: the identifier B assigned is the local identifier, and the identifier A assigned is the remote identifier. Mirror mirror 🪞

Now, the term "Router ID" in this document means a stable IP address of an LSR that's always reachable as long as there's any connectivity to the LSR 💜 This is usually a "loopback address". The key thing is that the address doesn't become unusable if an interface on the LSR goes down. Sometimes this value needs to be configured. And if you're using OSPF or ISIS as the IGP for traffic engineering, it is RECOMMENDED that the Router ID be set to the "Router Address" defined in [OSPF-TE], or the "Traffic Engineering Router ID" defined in [ISIS-TE] 🌈

This section works the exact same way for unnumbered component links (see [LINK-BUNDLE]) 💅

3. Unnumbered Forwarding Adjacencies 🎀

Okay this is the spicy part 🌶️ If an LSR that originates an LSP advertises that LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or if the LSR uses the Forwarding Adjacency formed by that LSP as an unnumbered component link of a bundled link (see [LINK-BUNDLE]), then the LSR MUST allocate an identifier to that Forwarding Adjacency (just like it would for any other unnumbered link). On top of that, the REQUEST message used to set up the LSP that forms the Forwarding Adjacency MUST contain an LSP_TUNNEL_INTERFACE_ID TLV (described below). That TLV has the LSR's Router ID set to the head end's Router ID, and the Interface ID set to the identifier the LSR allocated to the Forwarding Adjacency 🧁

If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then the tail-end LSR MUST allocate an identifier to that Forwarding Adjacency (again, just like any other unnumbered link). Also, the MAPPING message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the tail-end's Router ID, and the Interface ID set to the identifier the tail-end LSR allocated 🫶

Now for how the Explicit Route TLV and the Interface ID TLV get processed. An unnumbered Forwarding Adjacency gets treated as an unnumbered (TE) link or an unnumbered component link, like this 👑 The LSR that originates the Adjacency sets the link local identifier for that link to the value the LSR allocates to that Forwarding Adjacency, and it sets the link remote identifier to the value carried in the Interface ID field of the Reverse Interface ID TLV (see below for the definition of Reverse Interface ID TLV). The LSR that's the tail-end of that Forwarding Adjacency sets the link local identifier to the value it allocates to that Forwarding Adjacency, and sets the link remote identifier to the value carried in the Interface ID field of the Forward Interface ID TLV (see below for the definition of Forward Interface ID) 🌸

3.1. LSP_TUNNEL_INTERFACE_ID TLV ✨

The LSP_TUNNEL_INTERFACE ID TLV has Type 0x0836 and length 8. Here's the format 👇

Figure 1: LSP_TUNNEL_INTERFACE_ID TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|            Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LSR's Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Interface ID (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This TLV can optionally appear in either a REQUEST message or a MAPPING message. When it's in the REQUEST, we call it the "Forward Interface ID" for that LSP. When it's in the MAPPING, we call it the "Reverse Interface ID" for the LSP 🦋

A new Type of ER-Hop TLV of the Explicit Route TLV is used to specify unnumbered links. This Type is called Unnumbered Interface ID, and it has the following format:

The Type is 0x0837, and the Length is 12. The L bit is set to indicate a loose hop, and cleared to indicate a strict hop 🧚

The Interface ID is the identifier assigned to the link by the LSR specified by the router ID 🍓

Figure 2: Unnumbered Interface ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|          Type             |            Length = 12        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Interface ID (32 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1. Processing the IF_ID TLV 🔍

When an LSR receives a REQUEST message containing the IF_ID (Interface ID) TLV (see [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV like so. The LSR has to have info about the identifiers its neighbors assigned to the unnumbered links between the neighbors and the LSR (the original says "must have", so this is a hard requirement, bestie). The LSR uses that info to find a link with the tuple <Router ID, local identifier> matching the tuple <IP Address, Interface ID> carried in the IF_INDEX TLV. If the matching tuple is found, the match identifies the link where the LSR has to do label allocation 🎯

Otherwise, the LSR SHOULD return an error 🙅‍♀️

4.2. Processing the Unnumbered Interface ID ER-Hop TLV 💅

The Unnumbered Interface ID ER-Hop is part of a particular abstract node if that node has a Router ID equal to the Router ID field in the Unnumbered Interface ID ER-Hop, and if the node has an (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local identifier (from that node's point of view) equals the value carried in the Interface ID field of the Unnumbered Interface ID ER-Hop ✨

With that in mind, Explicit Route TLV processing when there's an Unnumbered Interface ID ER-Hop follows the rules in section 4.8.1 of [CR-LDP] 🌈

As part of the Explicit Route TLV processing (or, to be more precise, as part of next hop selection), if the outgoing link is unnumbered, the REQUEST message that the node sends to the next hop MUST include the IF_ID TLV. The IP address field of that TLV is set to the node's Router ID, and the Interface ID field is set to the identifier the node assigned to the link 🫶

8.1. Normative References

okay so these are the references the spec needs you to read, bestie 📚✨

  • [CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
  • [GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
  • [GMPLS-CRLDP] Ashwood, P., Ed. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472 January 2003.
  • [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

these ones are more like "good to know" reading, the vibe is "for context, babe" 🧚

  • [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", Work in Progress.
  • [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", Work in Progress.
  • [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", Work in Progress.
  • [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS Extensions in Support of Generalized MPLS", Work in Progress.
  • [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF Extensions in Support of Generalized MPLS", Work in Progress.
  • [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", Work in Progress.
  • [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", Work in Progress.

9. Authors' Addresses 🎀

meet the squad who wrote this bad boy 👑

Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089

EMail: yakov@juniper.net

Alan Kullberg
NetPlane Systems, Inc.
Westwood Executive Center
200 Lowder Brook Drive
Westwood, MA  02090

EMail: akullber@netplane.com

the legal part, but make it cute 🌸

Copyright (C) The Internet Society (2003). All Rights Reserved.

so you're allowed to copy and share this document and translations of it, and you can even make derivative works that comment on or explain it or help people implement it. you can do all of that in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work. BUT the document itself can't be modified in any way, like you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are: you can make changes if it's needed for developing Internet standards (in which case you have to follow the copyright procedures in the Internet Standards process), or you can translate it into languages other than English. 🌈

these permissions are perpetual and the Internet Society or its successors or assigns will never revoke them 🦋

this document and the info in it is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 promises, bestie 🙈

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society! 💖

📦 where this page comes from