[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-ccamp-rsvp-node-id-based-hello

   CCAMP Working Group                                        Zafar Ali
                                                          Reshad Rahman
                                                          Danny Prairie
                                                          Cisco Systems
                                                       D. Papadimitriou
                                                                Alcatel
   Internet Draft
   Category: BCP
   Expires: October 2004                                     April 2004



            Node ID based RSVP Hello: A Clarification Statement
              draft-ali-ccamp-rsvp-node-id-based-hello-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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 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.


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, when TE links
   are unnumbered. Furthermore, when link level failure detection is
   performed by some means other than RSVP Hellos, use of node-id based
   Hellos is optimal for detecting signaling adjacency failure for RSVP-
   TE. Nonetheless, this implied behavior is unclear and this document
   formalizes use of node-id based RSVP Hello sessions as a best current
   practice (BCP) in some scenarios.



Z. Ali, et al.                  Page 1                       4/16/2004

[Page 1]


            draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004


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

Routing Area ID Summary

   (This section to be removed before publication.)

   SUMMARY

      This document clarifies use of node-id based RSVP Hellos.

   WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK?

      This work fits in the context of [RFC 3209] and [RFC 3473].

   WHY IS IT TARGETED AT THIS WG?

      This document is targeted at ccamp as it clarifies procedures in
   [RFC 3209] and [RFC 3473], related to use of RSVP-TE Hello protocol.

   RELATED REFERENCES

   Please refer to the reference section.

Table of Contents

   1. Terminology....................................................2
   2. Introduction...................................................3
   3. Node-id based RSVP Hellos......................................3
   4. Backward Compatibility Note....................................4
   5. Security Considerations........................................4
   6. Acknowledgements...............................................4
   7. IANA Considerations............................................5
   8. Reference......................................................5
      8.1 Normative Reference........................................5
      8.2 Informative Reference......................................5
   9. Author's Addresses.............................................5

1.   Terminology

   Node-id: Router-id as advertised in the Router Address TLV for OSPF
   [OSPF-TE] and Traffic Engineering router ID TLV for ISIS [ISIS-TE].



Z. Ali, et al.                  Page 2                       4/16/2004

[Page 2]


            draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004


   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. Specifically, [RFC 3473] specifies
   the use of the RSVP Hellos 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 Hellos are
   not terminated on  data bearer linksÆ interfaces even if (some of)
   those are numbered. Instead RSVP hellos 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 Hellos for GR applications
   introduces a need for clarifying the behavior and usage of node-id
   based Hellos.

   Even in the case of packet MPLS, when link failure detection is
   performed by some means other than RSVP Hellos (e.g., [BFD]), the use
   of node-id based Hellos is also optimal for detection of signaling
   adjacency failures for RSVP-TE. Similarly, when all TE links between
   neighbor nodes are unnumbered, it is implied that the nodes will use
   node-id based Hellos for detection of signaling adjacency failures.
   This document also clarifies the use of node-id based Hellos when all
   or a sub-set of TE links are unnumbered. This draft also clarifies
   use of node-id based Hellos in these scenarios.

3.   Node-id based RSVP Hellos

   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 to a router-id as defined in the Router
   Address TLV for OSPF [OSPF-TE] and the Traffic Engineering router ID
   TLV for ISIS [ISIS-TE]. This section formalizes a procedure for
   establishing node-id based Hello sessions.


Z. Ali, et al.                  Page 3                       4/16/2004

[Page 3]


            draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004



   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.

   In the case of packet MPLS, when link failure detection is performed
   by some means other than RSVP Hellos, use of node-id based Hellos is
   also optimal in detecting signaling adjacency failures, e.g., for
   RSVP GR procedure. 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 Hellos. Furthermore, in the
   case of optical network with single or multiple, numbered or
   unnumbered control channels, use of node-id based Hellos for
   detecting signaling adjacency failure is also optimal. Therefore,
   when link failure detection is performed by some means other than
   RSVP Hellos, 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 Hellos 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 Hellos can co-exist with interface bound
   Hellos messages. Similarly, if a pair of nodes share numbered and
   unnumbered TE links, node id and interface based Hellos can co-exist.

4.   Backward Compatibility Note

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

5.   Security Considerations

     This document does not introduce new security issues. The security
   considerations pertaining to the original [RFC3209] remain relevant.

6.   Acknowledgements




Z. Ali, et al.                  Page 4                       4/16/2004

[Page 4]


            draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004


     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

   None.

8.   Reference

8.1     Normative Reference

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

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

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

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

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

8.2     Informative Reference

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

   [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
   Engineering", draft-ietf-isis-traffic-05.txt (work in progress).

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

9.   Author's Addresses

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


Z. Ali, et al.                  Page 5                       4/16/2004

[Page 5]


           draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004


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

   Danny Prairie
   Cisco Systems Inc.
   2000 Innovation Dr.,
   Kanata, Ontario, K2K 3E8, Canada.
   Phone: (613)-254-3519
   Email: rrahman@cisco.com

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

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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

   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



Z. Ali, et al.                  Page 6                       4/16/2004

[Page 6]


            draft-ali-ccamp-rsvp-node-id-based-hello-01.txt   April 2004


   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.


































Z. Ali, et al.                  Page 7                       4/16/2004

[Page 7]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/