RFC 4558

Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement

📅 published June 2006, from ietf

RFC 4558 is giving Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement 💖 It came from the Network Working Group in June 2006, written by Z. Ali, R. Rahman, and D. Prairie from Cisco Systems, plus D. Papadimitriou from Alcatel. It's a Standards Track document, and its header doesn't list any RFCs it obsoletes or updates. Iconic fr 🧚

Status of This Memo

Okay so this doc is a Standards Track protocol spec for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🦋

Copyright (C) The Internet Society (2006) 🌸

Abstract

Node-ID based RSVP Hello messages are kind of implied in a bunch of cases, like when data and control planes are separated or when TE links are unnumbered 🙈 Also, when link level failure detection is done some other way than swapping RSVP Hello messages, a Node-ID based Hello session is the optimal move for spotting signaling adjacency failure for RSVP-TE 💅 The vibe is that this implied behavior is unclear, so this document formalizes using the Node-ID based RSVP Hello session in some scenarios. The procedure here applies to both MPLS and GMPLS capable nodes, so it's giving full coverage ✨

1. Introduction

The RSVP Hello message exchange first showed up in [RFC3209]. Then [RFC3473] extended how Hello gets used so it can support RSVP Graceful Restart (GR) procedures 🎀

More specifically, [RFC3473] spells out using RSVP Hello messages for GR procedures in GMPLS. GMPLS brings in the idea of control plane and data plane separation. So in GMPLS networks, control plane info travels over a control network whose endpoints are IP capable, and that network might be physically or logically disjoint from the data bearer links it controls 😭 One result of separating data bearer links from control channels is that RSVP Hello messages don't terminate on data bearer link interfaces, even if some of those are numbered. Instead, they terminate at the IP capable control channel endpoints. Those endpoints MAY be identified by the value assigned to the node hosting those control channels, which is the Node-ID 👑 So using RSVP Hello for GR applications means we really need to clarify how Node-ID based Hello sessions behave and how they get used.

Even when a packet switching capable interface is in play, if link failure detection is done some other way than RSVP Hello messages (for example, [BFD]), a Node-ID based Hello session is still the optimal choice for detecting signaling adjacency failures for GMPLS-RSVP-TE and RSVP-TE when there's more than one link between a pair of nodes 🔥 Likewise, when all TE links between neighbor nodes are unnumbered, the nodes are implied to swap Node-ID based Hello messages to detect signaling adjacency failures. This document also clarifies how Node-ID based Hello message exchanges work when all or a subset of TE links are unnumbered 🌈

2. Terminology

Here's the vocab, bestie 📝

  • Node-ID: The TE Router ID as advertised in the Router Address TLV for OSPF [OSPF-TE] and the Traffic Engineering Router ID TLV for ISIS [ISIS-TE]. For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE].
  • Node-ID based Hello Session: A Hello session where the local and remote Node-IDs are used in the source and destination fields of the Hello packet, respectively.
  • Interface bounded Hello Session: A Hello session where the local and remote addresses of the interface in question are used in the source and destination fields of the Hello packet, respectively.

2.1. Conventions Used in This Document

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. Node-ID Based RSVP Hello Messages

A Node-ID based Hello session gets set up through an exchange of RSVP Hello messages, where the local and remote Node-IDs are respectively used in the source and destination fields of Hello packets. For IPv4, Node-ID means the TE router-id as defined in the Router Address TLV for OSPF [OSPF-TE] and the Traffic Engineering router ID TLV for ISIS [ISIS-TE]. For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. This section makes the procedure for setting up Node-ID based Hello sessions official 🧚

If a node wants to set up a Node-ID based RSVP Hello session with its neighbor, it sends a Hello message with its Node-ID in the source IP address field of the Hello packet. The node also puts the neighbor's Node-ID in the destination address field of the IP packet 💅

When a node gets a Hello packet where the destination IP address is its local Node-ID as advertised in the IGP-TE topology, the node MUST use its Node-ID when replying to the Hello message. Put another way, nodes MUST ensure that the Node-IDs used in RSVP Hello messages are the ones derived from or contained in the IGP-TE topology. Also, a node can only run one Node-ID based RSVP Hello session per IGP instance (that is, per Node-ID pair) with its neighbor 🫶

Even with packet switching capable interfaces, when link failure detection is done some other way than exchanging RSVP Hello messages, a Node-ID based Hello session is also optimal for detecting signaling adjacency failures for GMPLS-RSVP-TE and RSVP-TE when there's more than one link between a pair of nodes. Similarly, if all interfaces between a pair of nodes are unnumbered, the optimal way to use RSVP for detecting signaling adjacency failure is to run Node-ID based Hello sessions. And in an optical network with single or multiple numbered or unnumbered control channels, using Node-ID based Hello messages to detect signaling adjacency failure is also optimal 🦋 So, when link failure detection is done some other way than exchanging RSVP Hello messages, or when all interfaces between a pair of nodes are unnumbered, or in a GMPLS network with data and control plane separation, a node MUST run Node-ID based Hello sessions for detecting signaling adjacency failure for RSVP-TE. Still, if you want to tell signaling adjacency failures apart from link failures, Node-ID based Hello sessions can co-exist with the exchange of interface bound Hello messages. And if a pair of nodes shares both numbered and unnumbered TE links, Node-ID based and interface based Hello sessions can co-exist too 🌸

4. Backward Compatibility Note

The procedure in this document is backward compatible with both [RFC3209] and [RFC3473] ✨

Per [RFC3209], the Hello mechanism is meant for use between immediate neighbors, and Hello messages are sent between direct RSVP neighbors by default. This document doesn't change that behavior. It uses the IPv4 or IPv6 source address of the sending node as the "local node_id", and the IPv4 or IPv6 destination address of the neighbor node as the "remote node_id". TTL/Hop Limit setting and processing are also left unchanged 🍓

Also, this document doesn't change the use of Hello Processing for State Recovery as defined in Section 9.3 of [RFC3473], including the definition and processing of the RESTART_CAP object 💖

5. Security Considerations

Okay, this part matters, so listen up 👀 As this document doesn't modify or extend the RSVP Hello message exchange between immediate RSVP neighbors, it doesn't introduce new security considerations.

That said, the security considerations for the original [RFC3209] still apply 😭 RSVP message security is described in [RFC2747], which gives Hello message integrity and authentication of Node-ID ownership. Stay safe, bestie 🔐

6. Acknowledgements

Huge shoutout to Anca Zamfir, Jean-Louis Le Roux, Arthi Ayyangar, and Carol Iturralde for their useful comments and suggestions 🫶🌈

7. Reference

7.1. Normative References

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

[RFC2747]    Baker, F., Lindell, B., and M. Talwar, "RSVP
             Cryptographic Authentication", RFC 2747, January 2000.

[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., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.

7.2. Informative References

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

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

[BFD]        Katz, D. and D. Ward, "Bidirectional Forwarding
             Detection", Work in Progress.

[IS-ISv6-TE] Harrison, J., et al. "IPv6 Traffic Engineering in IS-
             IS", Work in Progress, November 2005.

[OSPFv3-TE]  Ishiguro, K., et al. "Traffic Engineering Extensions to
             OSPF version 3", Work in Progress, April 2006.

Authors' Addresses

Zafar Ali
Cisco Systems Inc.
100 South Main St. #200
Ann Arbor, MI 48104, USA

Phone: (734) 276-2459
EMail: zali@cisco.com


Reshad Rahman
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada

Phone: (613) 254-3519
EMail: rrahman@cisco.com


Danny Prairie
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada

Phone: (613) 254-3544
EMail: dprairie@cisco.com


Dimitri Papadimitriou
Alcatel
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium

Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be

Copyright (C) The Internet Society (2006).

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 contained herein 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.

Intellectual Property ✨

okay so this section is the legal-ish bit, but it's still lowkey important 💅 The IETF takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim 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, and it hasn't independently gone looking for any such rights 🫣 If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are a whole thing too. So are any assurances of licenses that might be offered, and the results of any attempt to get a general license or permission for implementers or users to use the proprietary rights. You can find all of that on the IETF online IPR repository at http://www.ietf.org/ipr 🔍

The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Just send it to the IETF at ietf-ipr@ietf.org 💌 the IETF really wants to know, bestie 🫶

Acknowledgement

and last but not least, the RFC Editor function is funded by the IETF Administrative Support Activity (IASA) 💖 that's the whole crew that keeps the lights on for these docs ✨

📦 where this page comes from