Internet DRAFT - draft-ali-ccamp-rsvp-node-id-based-hello

draft-ali-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]