merging at R8, because detour R3 has a shorter ERO path length (that
is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as
the final LSP and will only propagate its Path messages downstream.
Upon receiving a Resv (or a ResvTear) message, R8 must relay the
messages toward both R2 and R3.
R5 has to merge as well, and it will select the main LSP, since it
has the FAST_REROUTE object. Thus, the detour LSP terminates at R5.
7.1.3. Message Handling for Merged Detours
When an LSR receives a ResvTear for an LSP, the LSR must determine
whether it has an alternate associated LSP. For instance, if the
ResvTear was received for a protected LSP but an associated backup
LSP has not received a ResvTear, then the LSR has an alternate
associated LSP. If the LSR does not have an alternate associated
LSP, then the MP MUST propagate the ResvTear toward the LSP’s
ingress, and, for each backup LSP merged into that LSP at this LSR,
the ResvTear SHOULD also be propagated along the backup LSP.
The MP may receive PathTear messages for some of the merging LSPs.
PathTear messages SHOULD NOT be propagated downstream until the MP
has received PathTear messages for each of the merged LSPs. However,
the fact that one or more of the merged LSPs has been torn down
should be reflected in the downstream message, such as by changing
the DETOUR object, if there is one.
7.2. Handling Failures
When a downstream LSR detects a local link failure, for any protected
LSPs routed over the failed link, Path and Resv state MUST NOT be
cleared, and PathTear and ResvErr messages MUST NOT be sent
immediately. If this is not the case, then the facility backup
method will not work. Furthermore, a downstream LSR SHOULD reset the
refresh timers for these LSPs as if they had just been refreshed.
This is to allow time for the PLR to begin refreshing state via the
bypass tunnel. State MUST be removed if it has not been refreshed
before the refresh timer expires. This allows the facility backup
method to work without requiring that it signal backup paths through
the bypass tunnel before failure.
After a failure has occurred, the MP must still send Resv messages
for the backup LSPs associated with the protected LSPs that have
failed. If the backup LSP was sent through a bypass tunnel, then the
PHOP object in its Path message will have the IP address of the
associated PLR. This will ensure that Resv state is refreshed.
Once the local link has recovered, the MP may or may not accept Path
messages for existing protected LSPs that had failed over to their
backup.
8. Behavior of All LSRs
The objects and methods defined in this document require behavior
from all LSRs in the traffic-engineered network, even if an LSR is
not along the path of a protected LSP.
First, if a DETOUR object is included in the backup LSP’s path
message for the sender template-specific method, the LSRs in the
traffic-engineered network should support the DETOUR object.
Second, if the path-specific method is to be supported for the one-
to-one backup method, it is necessary that the LSRs in the traffic-
engineered network be capable of merging detours as specified in
Section 8.1.
It is possible to avoid specific LSRs that do not support this
behavior by assigning a link attribute to all the links of those LSPs
and then requesting that backup paths exclude this link attribute.
8.1. Merging Detours in the Path-Specific Method
If multiple Path Messages for different detours are received with the
same SESSION, SENDER_TEMPLATE, outgoing interface, and next-hop LSR,
then the LSR must function as a Detour Merge Point and merge the
detour Path Messages. This merging should occur as specified in
Section 7.1.2 and shown in Example 4.
In addition, it is necessary to update the DETOUR object to reflect
the merging that has taken place. This is done using the following
algorithm to format the outgoing DETOUR object for the final LSP:
- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR
objects of all merged LSPs into a new object. Ordering is
insignificant.
9. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain
relevant.
Note that the facility backup method requires that a PLR and its
selected merge point trust RSVP messages received from each other.
10. IANA Considerations
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for
objects defined in this document.
10.1. DETOUR Object
IANA has assigned:
63 DETOUR
Class Types or C-Types:
7 IPv4
8 IPv6
Future C-Types will be assigned using the following guidelines:
C-Types 0 through 127 are assigned by Standards Action.
C-Types 128 through 191 are assigned by Expert Review.
C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of
the DETOUR object after the C-Type must be the Vendor’s SMI Network
Management Private Enterprise Code (see [ENT]) in network byte order.
10.2. FAST_REROUTE Object
IANA has assigned:
205 FAST_REROUTE
Class Types or C-Types:
1 FAST_REROUTE Type 1
7 RESERVED
In the FAST_REROUTE object, C-Type 7 is reserved as it is still used
by pre-standard implementations. Future C-Types will be assigned
using the following guidelines:
C-Types 0 through 127 are assigned by Standards Action.
C-Types 128 through 191 are assigned by Expert Review.
C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of
the FAST_REROUTE object after the C-Type must be the Vendor’s SMI
Network Management Private Enterprise Code (see [ENT]) in network
byte order.
11. Contributors
This document was written by George Swallow, Ping Pan, Alia Atlas,
Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 497 6238
EMail: jpv@cisco.com
Markus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
USA
Phone: +1 781 359 5071
EMail: mjork@quarrytech.com
Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
Phone: +1 408 745 2074
EMail: dhg@juniper.net
Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
USA
Phone: +1 916 415 0437
EMail: dcooper@gblx.net
12. Acknowledgments
We would like to acknowledge input and helpful comments from Rob
Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we
thank those, who have been involved in interoperability testing and
field trails, and provided invaluable ideas and suggestions. They
are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard
Southern, and Bijan Jabbari.
13. Normative References
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RSVP-TE] 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.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
Authors’ Addresses
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan
Hammerhead Systems
640 Clyde Court
Mountain View, CA 94043
USA
EMail: ppan@hammerheadsystems.com
Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.