< draft-ali-ccamp-rsvp-node-id-based-hello-00.txt   draft-ali-ccamp-rsvp-node-id-based-hello-01.txt >
CCAMP Working Group Zafar Ali CCAMP Working Group Zafar Ali
Reshad Rahman Reshad Rahman
Danny Prairie Danny Prairie
Cisco Systems, Inc. Cisco Systems
D. Papadimitriou
Alcatel
Internet Draft Internet Draft
Category: Informational Category: BCP
Expires: August 2004 February 2004 Expires: October 2004 April 2004
Node ID based RSVP Hello: A Clarification Statement Node ID based RSVP Hello: A Clarification Statement
draft-ali-ccamp-rsvp-node-id-based-hello-00.txt draft-ali-ccamp-rsvp-node-id-based-hello-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 25 skipping to change at page 1, line 27
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Use of node-id based RSVP Hello messages is implied in a number of 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 cases, e.g., when data and control plan are separated, when TE links
are unnumbered. Furthermore, when link level failure detection is are unnumbered. Furthermore, when link level failure detection is
performed by some means other than RSVP Hellos, use of node-id based performed by some means other than RSVP Hellos, use of node-id based
Hellos is optimal for node failure detection. Nonetheless, this Hellos is optimal for detecting signaling adjacency failure for RSVP-
implied behavior is unclear and this informational draft clarifies TE. Nonetheless, this implied behavior is unclear and this document
use of node-id based RSVP Hellos. 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
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
Routing Area ID Summary Routing Area ID Summary
(This section to be removed before publication.) (This section to be removed before publication.)
SUMMARY SUMMARY
This draft clarifies use of node-id based RSVP Hellos.
Z. Ali, et al. Page 1 2/5/2004
draft-ali-ccamp-rsvp-node-id-based-hello-00.txt February 2004 This document clarifies use of node-id based RSVP Hellos.
WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK?
This work fits in the context of [RFC 3209] and [RFC 3473]. This work fits in the context of [RFC 3209] and [RFC 3473].
WHY IS IT TARGETED AT THIS WG? WHY IS IT TARGETED AT THIS WG?
This draft is targeted at ccamp as it clarifies procedures in [RFC
3209] and [RFC 3473], related to use of RSVP-TE Hello protocol. 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 RELATED REFERENCES
Please refer to the reference section.
Please refer to the reference section.
Table of Contents Table of Contents
1. Terminology....................................................2 1. Terminology....................................................2
2. Introduction...................................................2 2. Introduction...................................................3
3. Node-id based RSVP Hellos......................................3 3. Node-id based RSVP Hellos......................................3
4. Backward Compatibility Note....................................4 4. Backward Compatibility Note....................................4
5. Security Considerations........................................4 5. Security Considerations........................................4
6. Acknowledgements...............................................4 6. Acknowledgements...............................................4
7. IANA Considerations............................................4 7. IANA Considerations............................................5
Reference.........................................................4 8. Reference......................................................5
Author's Addresses................................................4 8.1 Normative Reference........................................5
8.2 Informative Reference......................................5
9. Author's Addresses.............................................5
1. Terminology 1. Terminology
Node-id: Router-id as defined in the Router Address TLV for OSPF 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]. [OSPF-TE] and Traffic Engineering router ID TLV for ISIS [ISIS-TE].
Z. Ali, et al. Page 2 4/16/2004
Node-id based Hello Session: A Hello session such that local and 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 remote node-ids are used in the source and destination fields of the
Hello packet, respectively. Hello packet, respectively.
Interface bounded Hello Session: A Hello session such that local and Interface bounded Hello Session: A Hello session such that local and
remote addresses of the interface in question are used in the source remote addresses of the interface in question are used in the source
and destination fields of the Hello packet, respectively. and destination fields of the Hello packet, respectively.
2. Introduction 2. Introduction
The RSVP Hello protocol was introduced in [RFC 3209]. The usage of The RSVP Hello message exchange was introduced in [RFC 3209]. The
RSVP Hello protocol is over-loaded in [RFC 3473] to support RSVP usage of RSVP Hello has been extended in [RFC 3473] to support RSVP
Graceful Restart (GR) procedures. Specifically, [RFC 3473] specifies Graceful Restart (GR) procedures. Specifically, [RFC 3473] specifies
the use of the RSVP Hello protocol for GR procedures for Generalized the use of the RSVP Hellos for GR procedures for Generalized MPLS
MPLS (GMPLS). GMPLS introduces the notion of control plane and data (GMPLS). GMPLS introduces the notion of control plane and data plane
plane separation. In other words, in GMPLS networks, the control separation. In other words, in GMPLS networks, the control plane
information is carried over a control network, which may be information is carried over a control network whose end-points are IP
physically different than the data network. The notion of separation capable, and which may be physically or logically disjoint from the
of data and control plane also applies to the Optical User Network data bearer links it controls. One of the consequences of separation
Interface (O-UNI) 1.0 Signaling Specification [OIF-UNI], which reuses of data bearer links from control channels is that RSVP Hellos are
the RSVP GR procedures defined in [RFC 3473]. One of the consequences not terminated on data bearer linksÆ interfaces even if (some of)
of separation of data bearer links from control channels is that RSVP those are numbered. Instead RSVP hellos are terminated at the control
Hellos are not exchanged over data links; instead hellos use the channel (IP-capable) end-points. The latter MAY be identified by the
control channel. Consequently, the use of RSVP Hellos for GR value assigned to the node hosting these control channels i.e. Node-
applications introduces a need for node-id based Hellos. Nonetheless, Id. Consequently, the use of RSVP Hellos for GR applications
this implied behavior is unclear and this draft clarifies the usage. introduces a need for clarifying the behavior and usage of node-id
based Hellos.
Z. Ali, et al. Page 2 2/5/2004
draft-ali-ccamp-rsvp-node-id-based-hello-00.txt February 2004
Another scenario which introduces the need for node-id based Hellos
is when nodes support unnumbered TE links. Specifically, when all TE
links between neighbor nodes are unnumbered, it is implied that the
nodes will use node-id based Hellos for detecting node failures. This
draft also clarifies the use of node-id based Hellos when all or a
sub-set of TE links are unnumbered.
When link level failure detection is performed by some means other Even in the case of packet MPLS, when link failure detection is
than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is performed by some means other than RSVP Hellos (e.g., [BFD]), the use
also optimal for detection of nodal failures. 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 3. Node-id based RSVP Hellos
A node-id based Hello session is established through the exchange of A node-id based Hello session is established through the exchange of
RSVP Hello messages such that local and remote node-ids are RSVP Hello messages such that local and remote node-ids are
respectively used in the source and destination fields of Hello respectively used in the source and destination fields of Hello
packets. Here, node-id refers to a router-id as defined in the Router 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 Address TLV for OSPF [OSPF-TE] and the Traffic Engineering router ID
TLV for ISIS [ISIS-TE]. This section formalizes a procedure for TLV for ISIS [ISIS-TE]. This section formalizes a procedure for
establishing node-id based Hello sessions. establishing node-id based Hello sessions.
Z. Ali, et al. Page 3 4/16/2004
If a node wishes to establish a node-id based RSVP Hello session with If a node wishes to establish a node-id based RSVP Hello session with
its neighbor, it sends a Hello Request message with its node-id in its neighbor, it sends a Hello message with its node-id in the source
the source IP address field of the Hello packet. Furthermore, the IP address field of the Hello packet. Furthermore, the node also puts
node also puts the neighborÆs node-id in the destination address the neighborÆs node-id in the destination address field of the IP
field of the IP packet. packet.
An implementation may initiate a node-id based Hello session when it
starts sharing RSVP states with the neighbor or at an earlier time.
Similarly, an implementation may use the IGP topology to determine
the remote node-id which matches an interface address(es) used in
RSVP signaling. These aspects are considered to be a local
implementation decision.
When a node receives a Hello packet where the destination IP address 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 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 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 words, nodes must ensure that the node-ids used in RSVP Hello
messages are those derived/contained in the IGP-TE topology. messages are those derived/contained in the IGP-TE topology.
Furthermore, a node can only run one node-id based RSVP Hello session Furthermore, a node can only run one node-id based RSVP Hello session
with its neighbor. per IGP instance (i.e., per node-id pair) with its neighbor.
If all interfaces between a pair of nodes are unnumbered, the optimal In the case of packet MPLS, when link failure detection is performed
way to use RSVP to detect nodal failure is to run node-id based by some means other than RSVP Hellos, use of node-id based Hellos is
Hellos. Similarly, when link level failure detection is performed by also optimal in detecting signaling adjacency failures, e.g., for
some means other than RSVP Hellos, use of node-id based Hellos is RSVP GR procedure. Similarly, if all interfaces between a pair of
also optimal in detecting nodal failures. Therefore, if all nodes are unnumbered, the optimal way to use RSVP to detect signaling
interfaces between a pair of nodes are unnumbered or when link level adjacency failure is to run node-id based Hellos. Furthermore, in the
failure detection is performed by some means other than RSVP Hellos, case of optical network with single or multiple, numbered or
a node MUST run node-id based Hellos for node failure detection. unnumbered control channels, use of node-id based Hellos for
Nonetheless, if it is desirable to distinguish between node and link 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 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.
Z. Ali, et al. Page 3 2/5/2004 4. Backward Compatibility Note
draft-ali-ccamp-rsvp-node-id-based-hello-00.txt February 2004
Hellos. 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 draft is backward compatible with The procedure presented in this document is backward compatible with
both [RFC3209] and [RFC3473]. both [RFC3209] and [RFC3473].
5. Security Considerations 5. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] considerations pertaining to the original [RFC3209] remain relevant.
remain relevant.
6. Acknowledgements 6. Acknowledgements
Z. Ali, et al. Page 4 4/16/2004
We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi
Ayyangar and Carol Iturralde for their useful comments and Ayyangar and Carol Iturralde for their useful comments and
suggestions. suggestions.
7. IANA Considerations 7. IANA Considerations
None. None.
Reference 8. Reference
[RFC2205] " Resource ReSerVation Protocol (RSVP) - Version 1, 8.1 Normative Reference
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", RFC 2205, Braden, et al, September Functional Specification", RFC 2205, Braden, et al, September
1997. 1997.
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001. RFC 3209, December 2001.
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al, Signaling Functional Description, RFC 3471, L. Berger, et al,
January 2003. January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
TE) Extensions", RFC 3471, L. Berger, et al, January 2003. TE) Extensions", RFC 3473, L. Berger, et al, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997. RFC 2119, S. Bradner, March 1997.
[OIF-UNI] "User Network Interface (UNI) 1.0 Signaling Specification -
Implementation Agreement OIF-UNI-01.0," The Optical Internetworking 8.2 Informative Reference
Forum, October 2001.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic- Extensions to OSPF Version 2", RFC 3630.
09.txt(work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt (work in progress) Engineering", draft-ietf-isis-traffic-05.txt (work in progress).
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-katz-ward-bfd-01.txt (work in progress). draft-katz-ward-bfd-01.txt (work in progress).
Author's Addresses 9. Author's Addresses
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
Z. Ali, et al. Page 4 2/5/2004
100 South Main St. #200 100 South Main St. #200
Ann Arbor, MI 48104, USA. Ann Arbor, MI 48104, USA.
Z. Ali, et al. Page 5 4/16/2004
Phone: (734) 276-2459 Phone: (734) 276-2459
Email: zali@cisco.com Email: zali@cisco.com
Reshad Rahman Reshad Rahman
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Dr., 2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada. Kanata, Ontario, K2K 3E8, Canada.
Phone: (613)-254-3519 Phone: (613)-254-3519
Email: rrahman@cisco.com Email: dprairie@cisco.com
Danny Prairie Danny Prairie
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Dr., 2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8, Canada. Kanata, Ontario, K2K 3E8, Canada.
Phone: (613)-254-3519 Phone: (613)-254-3519
Email: dprairie@cisco.com Email: rrahman@cisco.com
Z. Ali, et al. Page 5 2/5/2004 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
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
 End of changes. 51 change blocks. 
103 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/