1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4558.txt b/doc/rfc/rfc4558.txt
new file mode 100644
index 0000000..bd46361
--- /dev/null
+++ b/doc/rfc/rfc4558.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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
+
+   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 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, for IPv4, Node-ID refers 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 interfaces, 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
+   and 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 an
+   optical network with single or multiple numbered or unnumbered
+   control channels, use 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 a 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,
+
+
+
+Ali, et al.                 Standards Track                     [Page 3]
+
+RFC 4558                Node-ID Based RSVP Hello               June 2006
+
+
+   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 [RFC3209], 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 [RFC3473] (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.
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al.                 Standards Track                     [Page 4]
+
+RFC 4558                Node-ID Based RSVP Hello               June 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al.                 Standards Track                     [Page 5]
+
+RFC 4558                Node-ID Based RSVP Hello               June 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ali, et al.                 Standards Track                     [Page 6]
+
+RFC 4558                Node-ID Based RSVP Hello               June 2006
+
+
+Full 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.
+
+   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
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Ali, et al.                 Standards Track                     [Page 7]
+