One document matched: draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
CCAMP Working Group Zafar Ali
Reshad Rahman
Danny Prairie
Cisco Systems, Inc.
Internet Draft
Category: Informational
Expires: August 2004 February 2004
Node ID based RSVP Hello: A Clarification Statement
draft-ali-ccamp-rsvp-node-id-based-hello-00.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 node failure detection. Nonetheless, this
implied behavior is unclear and this informational draft clarifies
use of node-id based RSVP Hellos.
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 draft clarifies use of node-id based RSVP Hellos.
Z. Ali, et al. Page 1 2/5/2004
[Page 1]
draft-ali-ccamp-rsvp-node-id-based-hello-00.txt February 2004
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 draft 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...................................................2
3. Node-id based RSVP Hellos......................................3
4. Backward Compatibility Note....................................4
5. Security Considerations........................................4
6. Acknowledgements...............................................4
7. IANA Considerations............................................4
Reference.........................................................4
Author's Addresses................................................4
1. Terminology
Node-id: Router-id as defined in the Router Address TLV for OSPF
[OSPF-TE] and Traffic Engineering router ID TLV for ISIS [ISIS-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 protocol was introduced in [RFC 3209]. The usage of
RSVP Hello protocol is over-loaded in [RFC 3473] to support RSVP
Graceful Restart (GR) procedures. Specifically, [RFC 3473] specifies
the use of the RSVP Hello protocol 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
information is carried over a control network, which may be
physically different than the data network. The notion of separation
of data and control plane also applies to the Optical User Network
Interface (O-UNI) 1.0 Signaling Specification [OIF-UNI], which reuses
the RSVP GR procedures defined in [RFC 3473]. One of the consequences
of separation of data bearer links from control channels is that RSVP
Hellos are not exchanged over data links; instead hellos use the
control channel. Consequently, the use of RSVP Hellos for GR
applications introduces a need for node-id based Hellos. Nonetheless,
this implied behavior is unclear and this draft clarifies the usage.
Z. Ali, et al. Page 2 2/5/2004
[Page 2]
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
than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
also optimal for detection of nodal failures.
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.
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
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.
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
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
with its neighbor.
If all interfaces between a pair of nodes are unnumbered, the optimal
way to use RSVP to detect nodal failure is to run node-id based
Hellos. Similarly, when link level failure detection is performed by
some means other than RSVP Hellos, use of node-id based Hellos is
also optimal in detecting nodal failures. Therefore, if all
interfaces between a pair of nodes are unnumbered or when link level
failure detection is performed by some means other than RSVP Hellos,
a node MUST run node-id based Hellos for node failure detection.
Nonetheless, if it is desirable to distinguish between node and link
failures, node id based Hellos can co-exist with interface bound
Z. Ali, et al. Page 3 2/5/2004
[Page 3]
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
both [RFC3209] and [RFC3473].
5. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant.
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
None.
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 3471, L. Berger, et al, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
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
Forum, October 2001.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt (work in progress)
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-katz-ward-bfd-01.txt (work in progress).
Author's Addresses
Zafar Ali
Cisco Systems Inc.
Z. Ali, et al. Page 4 2/5/2004
[Page 4]
draft-ali-ccamp-rsvp-node-id-based-hello-00.txtFebruary 2004
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
Z. Ali, et al. Page 5 2/5/2004
[Page 5]
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:27 |