Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
draft-ietf-ccamp-rsvp-node-id-based-hello-03

Network Working Group                                         Zafar Ali
Internet Draft                                            Reshad Rahman
Category: Proposed Standard                               Danny Prairie
Expires: September 2006                                       Cisco Systems
                                                       D. Papadimitriou
                                                                Alcatel

                                                             March 2006

            Node ID based RSVP Hello: A Clarification Statement

             draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

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

Abstract

   Use of Node-ID based RSVP Hello messages is implied in a number of
   cases, e.g., when data and control plan are separated, and when TE links
   are unnumbered. Nonetheless, this implied behavior is unclear

Z. Ali, et al.             Expires September 2006                   Page 1


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt                March 2006

   and this document formalizes use of 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.

   When link level failure detection is performed by some means other 
   than exchanging RSVP Hello messages, use of Node-ID based Hello 
   session is optimal for detecting signaling adjacency failure for 
   Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). The use 
   of Node-ID based Hello session is optimal in the sense that as long as
   there is IP reachability to the nieghbor (node-id), the signalling 
   adjacency will remain up. 

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].

1. 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 such that 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 such that local and
   remote addresses of the interface in question are used in the source
   and destination fields of the Hello packet, respectively.

2. Introduction

   The RSVP Hello message exchange was introduced in [RFC 3209]. The
   usage of RSVP Hello has been extended in [RFC 3473] to support RSVP
   Graceful Restart (GR) procedures.

   More specifically, [RFC 3473] 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
   which 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

Z. Ali, et al.             Expires September 2006                 Page 2


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt              March 2006

   applications introduces a need for clarifying the behavior and usage
   of Node-ID based Hello sessions.

   Even in the case of packet switching capable end-points, 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 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.

3. Node-ID based RSVP Hello Messages

   A Node-ID based Hello session is established through the exchange of
   RSVP Hello messages such that local and remote Node-IDs are
   respectively used in the source and destination fields of Hello
   packets. Here, Node-ID refers for IPv4 to 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 formalizes a
   procedure for establishing Node-ID based Hello sessions.

   If a node wishes to establish 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. Furthermore, the node also puts
   the neighbor's Node-ID in the destination address field of the IP
   packet.

   When a node receives 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 in replying to the Hello message. In other
   words, nodes MUST ensure that the Node-IDs used in RSVP Hello
   messages are those derived/contained in the IGP-TE topology.
   Furthermore, a node can only run one Node-ID based RSVP Hello session
   per IGP instance (i.e., per Node-ID pair) with its neighbor.

   Even in the case of packet switching capable end-points, when link
   failure detection is performed by some means other than exchanging
   RSVP Hello messages, use of Node-ID based Hello sessions is also
   optimal in detecting signaling adjacency failures for GMPLS-/RSVP-TE
   when there is 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 to detect signaling adjacency failure is to run Node-
   ID based Hello sessions. Furthermore, in the case of optical network
   with single or multiple, numbered or unnumbered control channels, use

Z. Ali, et al.             Expires September 2006                  Page 3


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt               March 2006

   of Node-ID based Hello messages for detecting signaling adjacency
   failure is also optimal. Therefore, when link failure detection is
   performed by some means other than exchanging RSVP Hello messages, or
   if all interfaces between a pair of nodes are unnumbered, or in GMPLS
   network with data and control plane separation, a node MUST run Node-
   ID based Hello sessions for detection of signaling adjacency failure
   for RSVP-TE. Nonetheless, if it is desirable to distinguish between
   signaling adjacency and link failures, Node-ID based Hello sessions
   can co-exist with the exchange of interface bound Hellos messages.
   Similarly, if a pair of nodes share numbered and unnumbered TE links,
   Node-ID and interface based Hello sessions can co-exist.

4. Backward Compatibility Note

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

   Per [RFC 3209], the Hello mechanism is intended for use between
   immediate neighbors and Hello messages are by default sent between
   direct RSVP neighbors. This document does not modify this behavior as
   it uses as "local node_id" the IPv4/IPv6 source address of the
   sending node and as "remote node_id" the IPv4/IPv6 destination
   address of the neighbor node. TTL/Hop Limit setting and processing
   are also left unchanged.

   Moreover, this document does not modify the use of Hello Processing
   for State Recovery as defined in Section 9.3 of [RFC 3473] (including
   definition and processing of the RESTART_CAP object).

5. Security Considerations

   As this document does not modify or extend the RSVP Hello messages
   exchange between immediate RSVP neighbors, it does not introduce new
   security considerations.

   The security considerations pertaining to the original [RFC3209]
   remain relevant. RSVP message security is described in [RFC2747] and
   provides Hello message integrity and authentication of the Node-ID
   ownership.

6. Acknowledgements

   We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi
   Ayyangar and Carol Iturralde for their useful comments and
   suggestions.

7. IANA Considerations

   This draft makes no requests for IANA action.

Z. Ali, et al.             Expires September 2006                   Page 4


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt                March 2006

8. Reference

8.1  Normative Reference

   [RFC2205]   Braden, R., et al., "Resource ReSerVation Protocol (RSVP)
               - Version 1, Functional Specification", RFC 2205,
               September 1997.

   [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 Talwar, M., "RSVP
               Cryptographic Authentication", RFC 2747, January 2000.

   [RFC3209]   Awduche, D., et al., "Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.

   [RFC3471]   Berger, L., et al., Generalized Multi-Protocol Label
               Switching (GMPLS) Signaling Functional Description, RFC
               3471, January 2003.

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

   [RFC3667]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
               3667, February 2004.

   [RFC3668]   Bradner, S., Ed., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3668, February 2004.

8.2  Informative Reference

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

   [ISIS-TE]   Li, T., Smit, H., "IS-IS extensions for Traffic
               Engineering", RFC 3784, June 2004.

   [BFD]       Katz, D., and Ward, D., "Bidirectional Forwarding
               Detection", draft-katz-ward-bfd, work in progress.

9. Author's Addresses

   Zafar Ali
   Cisco Systems Inc.

Z. Ali, et al.             Expires September 2006                   Page 5


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt                March 2006

   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-3519
   Email: dprairie@cisco.com

   Dimitri Papadimitriou (Alcatel)
   Fr. Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   Email: dimitri.papadimitriou@alcatel.be

Z. Ali, et al.             Expires September 2006                   Page 6


draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt                March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from 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 address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   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.

Copyright Statement

   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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Z. Ali, et al.             Expires September 2006                   Page 7