Network Working Group Z. Ali
Request for Comments: 4558 R. Rahman
Category: Standards Track D. Prairie
Cisco Systems
D. Papadimitriou
Alcatel
June 2006
Node-ID Based Resource Reservation Protocol (RSVP) Hello:
A Clarification Statement
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Use of Node-ID based Resource Reservation Protocol (RSVP) Hello
messages is implied in a number of cases, e.g., when data and control
planes are separated, when TE links are unnumbered. Furthermore,
when link level failure detection is performed by some means other
than exchanging RSVP Hello messages, use of a Node-ID based Hello
session is optimal for detecting signaling adjacency failure for
Resource reSerVation Protocol-Traffic Engineering (RSVP-TE).
Nonetheless, this implied behavior is unclear, and this document
formalizes use of the Node-ID based RSVP Hello session in some
scenarios. The procedure described in this document applies to both
Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
capable nodes.
Ali, et al. Standards Track [Page 1]
RFC 4558 Node-ID Based RSVP Hello June 2006
1. Introduction
The RSVP Hello message exchange was introduced in [RFC3209]. The
usage of RSVP Hello has been extended in [RFC3473] to support RSVP
Graceful Restart (GR) procedures.
More specifically, [RFC3473] specifies the use of the RSVP Hello
messages for GR procedures for Generalized MPLS (GMPLS). GMPLS
introduces the notion of control plane and data plane separation. In
other words, in GMPLS networks, the control plane information is
carried over a control network whose end-points are IP capable and
that may be physically or logically disjoint from the data bearer
links it controls. One of the consequences of separation of data
bearer links from control channels is that RSVP Hello messages are
not terminated on data bearer links' interfaces even if (some of)
those are numbered. Instead, RSVP Hello messages are terminated at
the control channel (IP-capable) end-points. The latter MAY be
identified by the value assigned to the node hosting these control
channels, i.e., Node-ID. Consequently, the use of RSVP Hello
messages for GR applications introduces a need for clarifying the
behavior and usage of Node-ID based Hello sessions.
Even in the case of packet switching capable interfaces, when link
failure detection is performed by some means other than RSVP Hello
messages (e.g., [BFD]), the use of Node-ID based Hello sessions is
also optimal for detection of signaling adjacency failures for
GMPLS-RSVP-TE and RSVP-TE when there is more than one link between a
pair of nodes. Similarly, when all TE links between neighbor nodes
are unnumbered, it is implied that the nodes will exchange Node-ID
based Hello messages for detection of signaling adjacency failures.
This document also clarifies the use of Node-ID based Hello message
exchanges when all or a sub-set of TE links are unnumbered.
2. Terminology
Node-ID: TE Router ID as advertised in the Router Address TLV for
OSPF [OSPF-TE] and 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 in which 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 in which local and
remote addresses of the interface in question are used in the source
and destination fields of the Hello packet, respectively.
Ali, et al. Standards Track [Page 2]
RFC 4558 Node-ID Based RSVP Hello June 2006
2.1. Conventions Used in This Document
datatracker.ietf.org