sender fills in the Src_Instance field with a value representing it's
per neighbor instance. This value MUST NOT change while the agent is
exchanging Hellos with the corresponding neighbor. The sender also
fills in the Dst_Instance field with the Src_Instance value most
recently received from the neighbor. For reference, call this
variable Neighbor_Src_Instance. If no value has ever been received
from the neighbor or this node considers communication to the
neighbor to have been lost, the Neighbor_Src_Instance is set to zero
(0). The generation of a message SHOULD be suppressed when a HELLO
REQUEST object was received from the destination node within the
prior hello_interval interval.
On receipt of a message containing a HELLO REQUEST object, the
receiver MUST generate a Hello message containing a HELLO ACK object.
The receiver SHOULD also verify that the neighbor has not reset.
This is done by comparing the sender's Src_Instance field value with
the previously received value. If the Neighbor_Src_Instance value is
zero, and the Src_Instance field is non-zero, the
Neighbor_Src_Instance is updated with the new value. If the value
differs or the Src_Instance field is zero, then the node MUST treat
the neighbor as if communication has been lost.
The receiver of a HELLO REQUEST object SHOULD also verify that the
neighbor is reflecting back the receiver's Instance value. This is
done by comparing the received Dst_Instance field with the
Src_Instance field value most recently transmitted to that neighbor.
If the neighbor continues to advertise a wrong non-zero value after a
configured number of intervals, then the node MUST treat the neighbor
as if communication has been lost.
On receipt of a message containing a HELLO ACK object, the receiver
MUST verify that the neighbor has not reset. This is done by
comparing the sender's Src_Instance field value with the previously
received value. If the Neighbor_Src_Instance value is zero, and the
Src_Instance field is non-zero, the Neighbor_Src_Instance is updated
with the new value. If the value differs or the Src_Instance field
is zero, then the node MUST treat the neighbor as if communication
has been lost.
The receiver of a HELLO ACK object MUST also verify that the neighbor
is reflecting back the receiver's Instance value. If the neighbor
advertises a wrong value in the Dst_Instance field, then a node MUST
treat the neighbor as if communication has been lost.
If no Instance values are received, via either REQUEST or ACK
objects, from a neighbor within a configured number of
hello_intervals, then a node MUST presume that it cannot communicate
with the neighbor. The default for this number is 3.5.
When communication is lost or presumed to be lost as described above,
a node MAY re-initiate HELLOs. If a node does re-initiate it MUST
use a Src_Instance value different than the one advertised in the
previous HELLO message. This new value MUST continue to be
advertised to the corresponding neighbor until a reset or reboot
occurs, or until another communication failure is detected. If a new
instance value has not been received from the neighbor, then the node
MUST advertise zero in the Dst_instance value field.
5.4. Multi-Link Considerations
As previously noted, the Hello extension is targeted at detecting
node failures not per link failures. When there is only one link
between neighboring nodes or when all links between a pair of nodes
fail, the distinction between node and link failures is not really
meaningful and handling of such failures has already been covered.
When there are multiple links shared between neighbors, there are
special considerations. When the links between neighbors are
numbered, then Hellos MUST be run on each link and the previously
described mechanisms apply.
When the links are unnumbered, link failure detection MUST be
provided by some means other than Hellos. Each node SHOULD use a
single Hello exchange with the neighbor. The case where all links
have failed, is the same as the no received value case mentioned in
the previous section.
5.5. Compatibility
The Hello extension does not affect the processing of any other RSVP
message. The only effect is to allow a link (node) down event to be
declared sooner than it would have been. RSVP response to that
condition is unchanged.
The Hello extension is fully backwards compatible. The Hello class
is assigned a class value of the form 0bbbbbbb. Depending on the
implementation, implementations that do not support the extension
will either silently discard Hello messages or will respond with an
"Unknown Object Class" error. In either case the sender will fail to
see an acknowledgment for the issued Hello.
6. Security Considerations
In principle these extensions to RSVP pose no security exposures over
and above RFC2205[1]. However, there is a slight change in the
trust model. Traffic sent on a normal RSVP session can be filtered
according to source and destination addresses as well as port
numbers. In this specification, filtering occurs only on the basis
of an incoming label. For this reason an administration may wish to
limit the domain over which LSP tunnels can be established. This can
be accomplished by setting filters on various ports to deny action on
a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7)
or LSP_TUNNEL_IPv6 (8).
7. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current
document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are
defined. Each of these objects contain subobjects. This section
defines the rules for the assignment of subobject numbers. This
section uses the terminology of BCP 26 "Guidelines for Writing an
IANA Considerations Section in RFCs" [15].
EXPLICIT_ROUTE Subobject Type
EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies
the function of the subobject. There are no range restrictions.
All possible values are available for assignment.
Following the policies outlined in [15], subobject types in the
range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus
action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as
First Come First Served, and codes in the range 96 - 127 (0x60 -
0x7F) are reserved for Private Use.
ROUTE_RECORD Subobject Type
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
function of the subobject. There are no range restrictions. All
possible values are available for assignment.
Following the policies outlined in [15], subobject types in the
range 0 - 127 (0x00 - 0x7F) are allocated through an IETF
Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are
allocated as First Come First Served, and codes in the range 192 -
255 (0xC0 - 0xFF) are reserved for Private Use.
The following assignments are made in this document.
7.1. Message Types
Message Message
Number Name
20 Hello
7.2. Class Numbers and C-Types
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel
7.3. Error Codes and Globally-Defined Error Value Sub-Codes
The following list extends the basic list of Error Codes and Values
that are defined in [RFC2205].
Error Code Meaning
24 Routing Problem
This Error Code has the following globally-defined
Error Value sub-codes:
1 Bad EXPLICIT_ROUTE object
2 Bad strict node
3 Bad loose node
4 Bad initial subobject
5 No route available toward
destination
6 Unacceptable label value
7 RRO indicated routing loops
8 MPLS being negotiated, but a
non-RSVP-capable router stands
in the path
9 MPLS label allocation failure
10 Unsupported L3PID
25 Notify Error
This Error Code has the following globally-defined
Error Value sub-codes:
1 RRO too large for MTU
2 RRO Notification
3 Tunnel locally repaired
7.4. Subobject Definitions
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Subobjects of the RECORD_ROUTE object with C-Type 1:
1 IPv4 address
2 IPv6 address
3 Label
8. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. Acknowledgments
This document contains ideas as well as text that have appeared in
previous Internet Drafts. The authors of the current document wish
to thank the authors of those drafts. They are Steven Blake, Bruce
Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun
Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex
Mondrus for their comments on this document.
10. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC2205, September 1997.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC3031, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC2702,
September 1999.
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC2211, September 1997.
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC3032,
January 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC1349, July 1992.
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC2474, December 1998.
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
2751, January 2000.
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
for Extensions to RSVP for LSP-Tunnels", RFC3210, December
2001.
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC2210, September 1997.
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC792,
September 1981.
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC1191,
November 1990.
[14] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC2463,
December 1998.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null
Service Type", RFC2997, November 2000.
11. Authors' Addresses
Daniel O. Awduche
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703-298-5291
EMail: awduche@movaz.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703 847 1801
EMail: lberger@movaz.com
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
EMail: dhg@juniper.net
Tony Li
Procket Networks
3910 Freedom Circle, Ste. 102A
Santa Clara CA 95054
EMail: tli@procket.com
Vijay Srinivasan
Cosine Communications, Inc.
1200 Bridge Parkway
Redwood City, CA 94065
Voice: +1 650 628 4892
EMail: vsriniva@cosinecom.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8143
EMail: swallow@cisco.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.