Network Working Group Naiming Shen
Internet Draft Redback Networks
Ping Pan
Expiration Date: June 2004 Ciena Corp
December 2003
Nexthop Fast ReRoute for IP and MPLS
<draft-shen-nhop-fastreroute-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 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
This document describes a mechanism called NFRR (Nexthop
Fast ReRoute) to perform fast re-route for any type of traffic
in the event of a link/node failure or a nexthop unreachable.
The protected traffic can be IP, MPLS, unicast or multicast.
The re-routed traffic can either be destined to the nexthop
router or to the next-nexthop router. RSVP explicitly routed LSPs
are used as a tool to perform the local patch for minimizing
the packet loss.
1. Introduction
This document describes a simple mechanism to quickly re-direct IP
and/or MPLS traffic away from a local link or a nexthop failure.
The mechanism presented is mainly to facilitate the needs
Shen, Pan Expires June 2004 [Page 1]
Internet Draft Nexthop FRR December 2003
of real-time IP applications over native IP unicast/multicast
networks or LDP based MPLS networks. The goal is to limit the IP
packet loss duration in the network to 10s of milliseconds in the
event of link/node failures. RSVP [1] signaled LSP is used with
explicitly routed path as the re-direct tunnel, while the protected
traffic can be either MPLS traffic engineered LSPs, LDP based LSPs,
IP unicast, IP multicast traffic or the mix of them. This mechanism
can be applied to both point-to-point links and multi-access links
in the cases of the link protection and node protection.
An optional RSVP Bypass Nexthop object is defined to allow a
modified RPF checks for re-directed IP multicast data traffic. It
can also be used to detect misconfigured re-direct LSPs.
The node failure fast protection of native IP traffic is also
described in this document. Link State IGP can be used to make
the IP prefixes association with Next-NextHop nodes and the
re-direct LSPs configured towards them. For node protection of
LDP and multicast IP traffic, extension for both protocols are
needed and is beyond the scope of this document.
The re-direct LSP is no different from any other RSVP explicitly
routed LSPs, except that it does not carry data traffic under
normal condition. It is pre-built to reach the nexthop or the
next-nexthop router in the case of the protected link/node fails
or the nexthop over that protected link is unreachable. Any type
of data traffic intended to use this nexthop may be switched onto
this re-direct LSP. Since the LSP is built to protect local links
or adjacent nodes, the explicit path can be easily calculated
either statically or dynamically.
2. Terminology
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 RFC2119 [5].
LSP - An MPLS Label Switched Path. In this document, an LSP
will always refer to an explicitly routed LSP.
LDP LSP - LSP signaled by LDP protocol.
RSVP LSP - LSP signaled by RSVP protocol.
NFRR - Nexthop Fast ReRoute Scheme
NFRR LSP - Nexthop Fast ReRoute LSP, which is same as bypass
LSP or re-direct LSP in this document.
PLR - Point of Local Repair. The head-end LSR of a bypass LSP.
Shen, Pan Expires June 2004 [Page 2]
Internet Draft Nexthop FRR December 2003
MP - Merge Point. The tail-end LSR of a bypass LSP.
Nexthop Node - The router is directly connected to the PLR node.
Next-Nexthop Node - The router is the Nexthop node of PLR's
Nexthop node.
3. Motivations
IP applications such as VoIP and PWE3 are highly desirable to
have the packet loss with less than 10s of milliseconds during
network elements failure. Currently there are three approaches
in practice or proposed to speed up the recovery from such
failures as discussed below.
First, MPLS LSP Fast ReRoute mechanism [2] is used to quickly
re-route the RSVP LSP traffic onto a detour or bypass LSP when
a local link failure is detected. Since the detour or bypass LSPs
are pre-built before the local link failure, this re-route
operation can be accomplished within 10s of milliseconds. If the
IP backbone deploys network-wide MPLS TE, this MPLS Fast ReRoute
approach is the best solution. The Fast ReRoute is just
another application using the existing MPLS infrastructure.
This mechanism does not offer protection of IP, LDP or multicast
data traffic.
Second, IGP fast convergence is another mechanism in reducing the
packet loss time in network element failure. This mechanism also
includes the improvement of LDP convergence. Comparing with the
first solution, the recovery time is usually an order of magnitude
higher, which is in the 100s of milliseconds range. For certain
real-time applications, that duration is still acceptable and
this is a big improvement over "normal" IGP convergence time of
seconds or even 10s of seconds. Since this mechanism is purely
based on the control plane convergence in the network, there is
no guarantee for the convergence to be limited under 100s of
milliseconds.
Third, pre-calculated alternative nexthops are downloaded into
forwarding engines. As in the first mechanism, when a local
link failure is detected, those alternative nexthops are used to
continue forwarding the data traffic. If an alternative nexthop
does exist, then the re-route time can be accomplished within
10s of milliseconds. There are a couple of shortcoming of this
approach. There may not exist such an alternative nexthop for
the IP destinations along with the links it intends to protect.
When such alternative nexthops do exist, if there are many IGP
interfaces and adjacencies on the node, this requires to run
many instances of SPF in order to find a loop-free alternative.
This scheme can not be used to protect MPLS TE LSPs since they
Shen, Pan Expires June 2004 [Page 3]
Internet Draft Nexthop FRR December 2003
are not constructed from the native IP routing. Last, if the
local link failure is shortly after some network events and
the IGP on the node is busy calculating those SPFs, then the
alternative nexthop picture is incomplete at that time and the
re-route action may not be reliable.
There is obviously a need for providers to protect not only the
RSVP based LSP traffic, but also any data traffic in general;
there is a need for providers not only to protect traffic in
the case of link failure, but also with node failure for any
type of traffic; there is a need for providers not only to protect
native IP unicast traffic, but also the IP multicast data traffic.
The Nexthop Fast ReRoute mechanism does not make any assumption of
the protected traffic is MPLS tunneled or not. If a network-wide
MPLS traffic engineering is not the goal of the network design,
the network can either stay with native IP or LDP LSPs but
still get the reliable Fast ReRoute benefits for link/node
protection. In this scheme, RSVP signaled LSP will be used as
the re-direct tunnel for protected links/nodes. Those LSPs are
explicitly routed to get around the intended failure points. In
this scheme, the LSP is used in the network as a tool to fast
re-direct data traffic. If a network has an external Frame Relay
circuit in replacement for the RSVP based LSP, this Nexthop Fast
ReRoute will also work as specified in this document.
4. Nexthop Fast ReRoute(NFRR) Operation Scheme
Over a point-to-point there will be only one nexthop in general.
There are multiple nexthops over a LAN interface. The NFRR
is used to re-route traffic around the IP nexthop over the
protected interface. Assume there is an alternative path to
reach that nexthop node other than the protected link, we can
always pre-build an explicitly routed LSP to the node which owns
this nexthop address. If the local link is down, or the nexthop
is unreachable, the PLR router can quickly re-direct the data
traffic intended for this nexthop onto the NFRR LSP for that
nexthop node. Thus any traffic can be fast re-routed
in a loop-free fashion using NFRR. Over a LAN, the nexthop
unreachable status can possibly be quickly detected using some
link level aliveness protocols, and this is beyond the scope of
this document. When using NFRR protecting MPLS traffic, global
label space scheme is assume on the MP node. The NFRR for link
protection is assumed in this section. Node protection is
described in section 5.
The below network diagram will be used in this document as an
example topology for discussion purpose:
Shen, Pan Expires June 2004 [Page 4]
Internet Draft Nexthop FRR December 2003
lsp1
+-----[R6]---+
| |
| V
| ||==>b[R3] X
[R1]====>[R2]a=|| /
| | ||==>c[R4]===>d[R5]-- Y
| | ^ ^
| | | |
| +--[R7]----+ |
| lsp2 |lsp3
+---------------------+
R2 is the PLR router.
R2, R3 and R4 share a LAN connection with "a", "b" and
"c" belong to the same prefix.
R5 is a Next-Nexthop node from the PLR through R4.
lsp1 is sourced from R2 and explicitly route through R6
to reach R3. lsp1 is configured to protect "b" over
interface "a".
lsp2 is sourced from R2 to reach R4. lsp2 is configured
to protect "c" over interface "a".
lsp3 is sourced from R2 to reach R5. lsp3 is configured
to protect "c" or node R4 over interface "a".
Figure 1: An example of NFRR
4.1 NFRR to protect LDP LSPs
When the protected traffic is LDP LSPs, LDP process can
pre-build the association of the NFRR tunnel and the LDP LSPs
which use this particular nexthop. When the link is down or
the nexthop is unreachable, the forwarding engine can quickly
switch the traffic onto that NFRR tunnel by pushing an outbound
label and send it out. This is no different from re-directing
MPLS TE LSPs as described section 4.5 only without any RSVP
signaling involved in the LDP case.
4.2 NFRR to protect IP unicast traffic
The PLR node can pre-build the association of the NFRR tunnel
and the IP prefixes which use that same nexthop in the route
lookup. When the nexthop failure is detected, the forwarding
engine will be able to re-route the IP traffic to those
affected destinations onto the NFRR tunnel. The only difference
from the LDP case is that, it only has one label on the label
stack of the packet when being switch out to the NFRR LSP.
Shen, Pan Expires June 2004 [Page 5]
Internet Draft Nexthop FRR December 2003
4.3 NFRR to protect IP multicast traffic
Similar to the IP unicast case, the PLR node can pre-build the
association of the NFRR tunnel and the (S, G) entries on the
protected interface. In the point-to-point case, there needs
to be only one NFRR tunnel to be referenced in the (S, G)
entries of the protected interface. In the LAN case, multiple
NFRR tunnel references can exist in the (S, G) entries.
When the protected interface is down, or one of the multicast
forwarding downstream neighbor is unreachable, all or part of
the NFRR tunnels can be applied to re-route multicast traffic
to the downstream nodes. In the example in Figure 1, assume
R2 has both R3 and R4 as downstream for some (S, G)s, when
the link "a" is down, the references in those (S, G)s should
point to both lsp1 and lsp2 as its "new" downstream interfaces.
R2 needs to forward the multicast traffic through both LSPs.
This document defines a new RSVP Bypass Nexthop object
which can be optionally inserted into the PATH message by the
head-end of the NFRR LSP and the RESV message by the tail-end
of the NFRR LSP. The bypassed link nexthop IP address of the
NFRR tunnel can be conveyed to the tail-end node using this
new RSVP object. Multicast RPF check algorithm can be modified
to accept the multicast traffic for the (S, G)s on the
alternative inbound interface even though the RPF check may
currently point to the protected link which has that nexthop
IP address.
4.4 NFRR to protect IPv6 traffic
The same NFRR LSP can protect native IPv6 traffic going to
the same neighbor node over the protected interface. In
this case, an IPv6 nexthop address can be configured along
with the NFRR LSP. The same operation for unicast and multicast
of IPv4 traffic mentioned above applies here.
4.5 NFRR to protect MPLS TE LSPs
When some of the protected traffic to the nexthop belongs to
MPLS TE LSPs, the mechanism is the same as described in [2]
as facility based link-protection bypass tunnel scheme. All
the RSVP signaling extension described in that document
applies here. NFRR only explicitly extends this into the
protection of a nexthop to deal with multi-access case
instead of protection of local link only, but The technique
used is identical.
4.6 Protocol packets over the protected link
There are two types of protocol packets with regard to this scheme.
One requires an IP route lookup such as BGP, OSPF VL or RSVP packets;
Shen, Pan Expires June 2004 [Page 6]
Internet Draft Nexthop FRR December 2003
The other is sent directly over a local interface to neighbors
such as ISIS, OSPF, PIM or LDP adjacency packets. When the
protected link is down or the protected nexthop is unreachable,
the affected routable protocol packets MUST be re-routed over the
NFRR tunnel while the directly transported protocol packets SHOULD
be dropped in order to time out the protocol adjacency (even if
those protocol packets are re-directed over the NFRR LSPs, they
will be dropped by the neighbors due to inbound interface does
not match the protocol packets). The link/node down event will
be eventually propagated across the network and the entire network
can converge into a new topology.
5. Node Protection
The NFRR scheme described in section 4 is for link and nexthop
failure protection. This section describe the technique to use
NFRR for node protection.
5.1 Node Protection for IP Unicast Traffic
As described in section 4, we make the association from the route
nexthop to the NFRR LSP. When the link or nexthop fails, the
forwarding engine switches the traffic using this route nexthop
onto the NFRR LSP. In the node protection case, as long as we
have the knowledge of which routes using this nexthop also going
to the Next-Nexthop node, we are able to make the same association
to re-direct the traffic onto the NFRR LSP which has the
Next-Nexthop node as the tail-end.
For IP unicast traffic, this knowledge of routes association with
nexthop and Next-Nexthop nodes can be easily obtained from link
state IGPs. IGP Shortcut [4] is a technique to dynamically direct
IP traffic through TE LSPs. In the NFRR node protection case,
the PLR can use those shortcuts not for normal IP traffic, it will
only be used when the nexthop element fails. In other words, this
shortcut to the Next-Nexthop node is suddenly enabled by forwarding
engine when it detects the link, nexthop or nexthop node failure.
Those IGP shortcut LSPs can also be called conditional IGP
shortcuts with the conditions being the nexthop link or node failure.
In the example of Figure 1, lsp3 is a NFRR LSP source from PLR R2
with destination of R5 to protect node R4 as well as link "a" and
nexthop "c". IGP uses modified shortcut technique to associated
prefixes X and Y with nexthop "c1" over interface "a". The IGP
also installs a modified shortcut lsp3 to be associated with
nexthop "c1". The nexthop "c1" is just like "c", but it contains
the NFRR LSP lsp3 reference information. Basically if R4 has N
nexthop nodes, R2 will have "c1" through "cn" nexthops, each
references a NFRR LSP to it's Next-Nexthop node. The IP traffic
to X and Y normally is forwarded to R4, in the event of "a", "c"
or R4 node failure, the traffic is re-directed to lsp3 into R5.
Shen, Pan Expires June 2004 [Page 7]
Internet Draft Nexthop FRR December 2003
The algorithm for IGP Shortcut described in section 4 of [4]
has three possible ways to determine the first-hop information.
The first way can be modified for NFRR conditional shortcut as
follows:
- Examine the list of tail-end routers directly reachable via a
NFRR-tunnel. If there is a NFRR-tunnel to this node, we will
copy the first-hop information from the parent node(s) to
the this node. We also attach the NFRR-tunnel information to
the first-hop information on this node.
This first-hop information of the node can be used to construct
the nexthop and its association with the NFRR LSP destined to
that node. The rest of the NFRR operation is the same as in
link protection case as described in section 4.2.
5.2 Node Protection for Other Traffic
NFRR Node Protection for MPLS TE LSP is the same as described
in [2] as facility based node-protection bypass tunnel scheme.
NFRR only explicitly extends this capability into the multi-access
case. The technique used is the same.
NFRR Node Protection for LDP LSP and IP multicast traffic will
be covered by two separate documents using the NFRR technique and
is out side the scope of this document.
6. RSVP Bypass Nexthop Object
A NFRR LSP is just like any explicitly routed LSP defined in [1]
and it is used by the PLR to fast re-route traffic to the same
neighbor over alternative interfaces. As mentioned in section 4.3,
re-routed multicast traffic will be dropped if the neighbor
does not aware certain multicast traffic can come in an alternative
interface. This Bypass Nexthop object is used to dynamically pass
this information from the head-end NFRR node to the tail-end node
so that the RPF check on that protected interface can be modified
to accept with an alternative interface. The tail-end node can
send back the same object to indicate whether the requested
operation is supported.
If NFRR LSP is used to protect the link failure, it is useful to
know if the NFRR tail-end owns this bypassed nexthop address;
When in node protection case, it is also useful to know the NFRR
tail-end does not own this bypassed nexthop address; For IP
multicast re-route application, the bypassed nexthop address needs
to be local to the tail-end node in both link and node protections.
This object can be inserted by the tail-end node in RESV message
to confirm the acknowledged address is local or not to prevent
NFRR LSP mis-configuration.
Shen, Pan Expires June 2004 [Page 8]
Internet Draft Nexthop FRR December 2003
The Bypass Nexthop object has the following format:
Class = TBD (use form 11bbbbbb for compatibility)
C-Type = 1 or 2
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Reserved | Service Option Bits |
+-------------+-------------+-------------+-------------+
// (Subobjects) //
+-------------+-------------+-------------+-------------+
Subobject 1: Nexthop IPv4 address
0 1 2 3
+-------------+-------------+-------------+-------------+
| Type | Length | IPv4 address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 address (continued) |Prefix Length| Pad |
+-------------+-------------+-------------+-------------+
Subobject 2: Nexthop IPv6 address
+-------------+-------------+-------------+-------------+
| Type | Length | IPv6 address (16 bytes) |
+-------------+-------------+-------------+-------------+
| IPv6 address (continued) |
+-------------+-------------+-------------+-------------+
| IPv6 address (continued) |
+-------------+-------------+-------------+-------------+
| IPv6 address (continued) |
+-------------+-------------+-------------+-------------+
| IPv6 address (continued) |Prefix Length| Pad |
+-------------+-------------+-------------+-------------+
This object with C-type of 1 is used in PATH message and C-type
of 2 is used in RESV message. They are called Request and
Acknowledgement Objects. The Request Bypass Nexthop object
MUST only be inserted into PATH message by the head-end of
the NFRR LSP node , and MUST not be changed by downstream LSRs.
The Ack Bypass Nexthop object MUST only be inserted into RESV
message by the tail-end of the NFRR LSP node, and MUST not be
changed by the upstream LSRs.
Only two bits are currently defined for Service Option Bits field
in this document as following (position from the right most to
left most):
Shen, Pan Expires June 2004 [Page 9]
Internet Draft Nexthop FRR December 2003
Bits Description
1 Request/Ack this bypass nexthop address to be
local to the NFRR LSP tail-end node. The head-end LSR
sets this bit in PATH message requesting the information;
the tail-end LSR responds with RESV message by setting
or clearing this bit depends on the bypass nexthop
address is local to the LSR or not.
2 Request/Ack this bypass nexthop address to be
used to support modified multicast RPF checks as
defined in section 4.3. If the tail-end LSR does not
support this extension, then the multicast data
traffic SHOULD NOT be switched over to the NFRR LSP
in the event of link/node failure.
7. Forwarding Entry Update and NFRR LSP Reversion
The link down or nexthop unreachable event will eventually reach
the protocols such as OSPF or LDP. Regardless of IGP fast
convergence is used or not, the new forwarding entry downloading
should be hold for a little longer than the expected network
convergence time. This is to guarantee all the nodes in the
routing area have converged onto the new topology to avoid the
possibility of forwarding loops. It is safe to send traffic over
the NFRR LSP even after the network is converged. Since before the
link failure, the PLR was using the nexthop node to reach some
IP destination; it will be highly unlikely that the nexthop node
sends the traffic back to the PLR after the adjacent link/node
fails in network steady state.
Since the NFRR scheme is nexthop entry based, when those entries
are updated after the NFRR re-route takes place, the re-route
action for those entries will be reverted to normal operation.
In the example in Figure 1, R2 used to reach prefix X and Y through
nexthop "c" of R4. When "a" or "c" is down, the traffic towards
X and Y will be tunneled in lsp2 to use the same R4 for further
forwarding. After the holdown time expires and R2 decides to
use R7 as the new IP nexthop for X and Y. When R2 downloads the
X and Y into the forwarding engine, this update will revert the
re-route operation for traffic to X and Y. If the link "a" comes
up before the holdown time expires, R2 will use "c" as the nexthop
for X and Y again. The reversion time and operation is the same
in both cases.
Fast convergence of IGP will improve the network performance
even with the NFRR presents. It can help to quickly reach the more
optimal forwarding state in the routing domain with topology
changes.
Shen, Pan Expires June 2004 [Page 10]
Internet Draft Nexthop FRR December 2003
8. Operational Considerations
8.1 ECMP Cases
The NFRR scheme is independent of ECMP case and the loadsharing
algorithm should be the same. THe NFRR LSP is used to protect
one particular nexthop, only the portion of traffic used to
use this nexthop will be re-routed in the failure event.
8.2 Bandwidth Reservation
Even in the case the network does not use MPLS TE for normal
traffic, bandwidth reservation for NFRR LSPs can still be
applied. The RSVP interface bandwidth will reflect the amount
of link bandwidth reserved for re-routed traffic purpose.
8.3 Type of Traffic To Be Re-routed.
Since NFRR can be applied to any traffic in link protection
case, it is an implementation or configuration issue to decide
which type of traffic will be applied, others will be dropped.
Even within the same type of traffic, filters can be designed to
select only the traffic using certain destination, service or
labels will be re-routed if the bandwidth is an issue.
8.4 MPLS and IP In The Network
The NFRR scheme uses RSVP explicitly routed LSP to protect data
traffic while data traffic itself may not use MPLS TE LSPs in
the network. In this case, MPLS TE is not the goal of the network
design, the NFRR LSPs are used as a tool to accomplish the
fast re-route goal. In order for the re-routed traffic to be
reliable and loop-free for any network topology, the traffic
has to be either source routed or tunneled independent of
IP routing. RSVP signaled LSP is widely supported technology
and can be easily fit into NFRR application. If the network
only needs to protect a few local links or nodes, the RSVP
LSPs can be restricted to a limited scope in the network using
NFRR. It is also useful for the network which has MPLS TE in the
core and IP or LDP LSPs at the edge.
Even in the case the provider has outband circuits to protect
the link or node, NFRR can also be used without RSVP signaled
LSP involved. The multicast RPF extension for RSVP functionality
can be statically applied on the MP node in this case.
8.5 Link Protection and Node Protection
Node protection in fast re-route is not without issues. Not all
the LSRs have the node-protection option. For example, the PHP
nodes can only perform link-protection for the last hop of LSPs.
Shen, Pan Expires June 2004 [Page 11]
Internet Draft Nexthop FRR December 2003
The node-protection scheme also takes more network resource
since the MP is further away from the nexthop and it requires
more signaling work to identify the flow going through the
next-nexthop node in IP, LDP and multicast cases.
With Non-stop forwarding, protocol graceful restart and software
modular design make good inroad into provider's networks, a
complete node failure will gradually become rare events and a
node down often can be scheduled.
9. IANA Considerations
The NFRR proposal requires that IANA allocate a C-class number
for Bypass Nexthop object.
10. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [3] remain
relevant.
11. Acknowledgments
The authors would like to thank George Apostolopoulos, Enke Chen,
Albert Tian, Liming Wei and Jun Zhang for their contributions and
comments to this document.
12. Intellectual Property Considerations
Redback Networks may have intellectual property rights claimed in
regard to some of the specification contained in this document.
13. Full Copyright Statement
Copyright (C) The Internet Society (2002). 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
Shen, Pan Expires June 2004 [Page 12]
Internet Draft Nexthop FRR December 2003
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.
14. References
[1] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001.
[2] Pan, P., Gan, D., Swallow, G., Vasseur, J.Ph., Copper, D.,
Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE",
Interne draft, draft-pan-rsvp-fastreroute-03.txt, work in
progress.
[3] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205,
September 1997.
[4] Smit, H., Shen, N., "Calculating IGP Routes Over Traffic
Engineering Tunnels", draft-hsmit-shen-mpls-igp-spf-01.txt,
Work In Progress.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
15. Author Information
Naiming Shen
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
Email: naiming@redback.com
Ping Pan
CIENA Corp.
5965 Silver Creek Valley Road
San Jose, CA 95138
Email: ppan@ciena.com
Shen, Pan Expires June 2004 [Page 13]