Network Working Group Jiang Weilian
Internet Draft Feng Jun
Cui Ying
Expiration Date: Apr. 2007 Kong Yong
Luo Jian
ZTE, Inc.
Oct. 2006
Extensions to RSVP-TE Fast Reroute
draft-weilian-mpls-fast-reroute-ext-01
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines extensions to the Fast Reroute (FRR) mechanism
of Facility Backup defined in RFC4090. Through the extensions, the
node that has set up FRR relation is capable of notifying the tail
node of backup tunnel to act as Merge Point (MP) of the protected and
backup tunnels. In addition, after the FRR switchover, PLR and MP
nodes can refresh the protocol state of protected tunnel by the
Refresh message of backup tunnel, so that the protocol messages of
protected tunnel don't need to be refreshed through the backup
tunnel.
weilian Expires: Apr. 2007 [Page 1]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
1. Specification of Requirements
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
2. Acknowledgements
The editors gratefully acknowledge the authors of [RFC4090], since
that document is the basis of our work. We would also like to thank
all the future participants for their comments and suggestions
on this draft.
3. Introduction
RFC4090 defines the objects that Fast Reroute extends to RSVP-TE and
the Fast Reroute mechanism to implement link protection and node
protection of the active tunnel. However, for N:1 backup, after the
protected tunnel switches to the backup tunnel, the protocol state
should still be refreshed through sending protocol messages of the
protected tunnel along the path of backup tunnel. Once FRR switchover
occurs, abundant Refresh messages of the protected tunnel are
transmitted through the backup tunnel.
This document defines extensions to the Fast Reroute (FRR) mechanism
of Facility Backup defined in RFC4090. Through the extended new
objects and new mechanisms, the node that has set up the FRR relation
is capable of notifying the tail node of backup tunnel to act as
Merge Point (MP) of the protected and backup tunnels. In addition,
after the FRR switchover, PLR and MP nodes can refresh the protocol
state of protected tunnels by the Refresh message of the backup
tunnel, so that the protocol messages of protected tunnels don't need
to be refreshed through the backup tunnel.
4. Terminology
We assume that readers are familiar with the terms defined in
[RFC3209], [RFC4090], [RFC2205], [RFC3473], [draft-ietf-ccamp-rsvp-
restart-ext-05], and [draft-ietf-ccamp-rsvp-node-id-based-hello-02].
5. Objects Extension of Fast Reroute
5.1 MP_NOTIFY Object
The MP_NOTIFY object is used by an upstream PLR node to notify the
downstream MP node of the PLR-Node Router ID, the MP-Node Router ID
and the Backup Tunnel Tunnel ID, LSP ID. In addition, the PLR-Node
Router ID indicates the source address of the backup tunnel. This
object can only be transmitted in the Path message of protected
tunnel.
Class-Number = TBA (form 11bbbbbb)
weilian Expires: Apr. 2007 [Page 2]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
The IPv4 MP_NOTIFY object is in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 PLR-Node Router ID (4bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 MP-Node Router ID (4bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 MP_NOTIFY object is in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 PLR-Node Router ID (16bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 MP-Node Router ID (16bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PLR-Node Router ID:
Router ID of the Point of Local Repair (PLR) of the protected
tunnel.
weilian Expires: Apr. 2007 [Page 3]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
MP-Node RouterID:
Router ID of the Merge Point (MP) of the protected tunnel and the
backup tunnel.
Subobject：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Tunnel Tunnel ID | Backup Tunnel LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type：
0x01 Default value.
Length：
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The length is always 8.
Backup Tunnel Tunnel ID:
The current Tunnel ID of the backup tunnel.
Backup Tunnel LSP ID:
The current LSP ID of the backup tunnel.
5.2. MP_NOTIFY_ACK Object
The MP_NOTIFY_ACK object is used by an MP node to notify the upstream
PLR node that the MP node acknowledges the MP_NOTIFY. This object can
only be transmitted in the Resv message of protected tunnel.
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
The IPv4 MP_NOTIFY_ACK object is defined in the same format as the
IPv4 MP_NOTIFY object.
The IPv6 MP_NOTIFY_ACK object is defined in the same format as the
IPv6 MP_NOTIFY object.
5.3 FRR_SWITCH Object
FRR_SWITCH is used by an upstream PLR node to notify the downstream
MP node of the source address, Tunnel ID and LSP ID of the protected
tunnel in FRR switchover state. This object can only be transmitted
in the Path message of backup tunnel.
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
weilian Expires: Apr. 2007 [Page 4]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
The IPv4 FRR_SWITCH object is in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 PLR-Node Router ID (4bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 MP-Node Router ID (4bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 FRR_SWITCH object is in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(TBA)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 PLR-Node Router ID (16bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 MP-Node Router ID (16bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PLR-Node Router ID:
Router ID of the Point of Local Repair (PLR) of the protected
tunnel.
MP-Node Router ID:
Router ID of the Merge Point (MP) of the protected tunnel and
backup tunnel.
5.4 FRR_SWITCH_ACK Object
The FRR_SWITCH_ACK object is used by a downstream MP node to notify
the upstream PLR node that the MP node acknowledges the FRR_SWITCH.
This object can only be transmitted in the Resv message of backup
tunnel.
Class-Number = TBA (form 11bbbbbb)
weilian Expires: Apr. 2007 [Page 5]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
The IPv4 FRR_SWITCH_ACK object is defined in the same format as the
IPv4 FRR_SWITCH object.
The IPv6 FRR_SWITCH_ACK object is defined in the same format as the
IPv6 FRR_SWITCH object.
6. Processing the MP_NOTIFY Object
6.1. Processing at the PLR Node
A node is said to be a PLR node if FRR relation is established
between the protected tunnel and backup tunnel of the node. So the
PLR node can determine where the corresponding MP is located
according to the protected tunnel and backup tunnel. The PLR node
adds MP_NOTIFY object to the Path message of protected tunnel and
fills in the PLR-Node Router ID, MP-Node Router ID, Backup Tunnel
Tunnel ID and LSP ID. Then the PLR node sends the message to the
downstream node to notify explicitly it of where the MP node is
located and of the corresponding backup tunnel.
If there are multi backup tunnels, PLR node shold fill Tunnel ID and
LSP ID of all Backup Tunnels into subobjects of MP_NOTIFY object, and
send to the downstream node.
After the FRR relation between the protected tunnel and backup tunnel
of a PLR node is cancelled, the protected tunnel must stop adding
MP_NOTIFY object to the Path message. Then, it sends the message to
the downstream node to notify implicitly the downstream MP node to
cancel the MP relation with the backup tunnel.
6.2 Processing at the Downstream Node
When a downstream node receives a Path message containing the
MP_NOTIFY object:
If this node does not support MP_NOTIFY object it should continue
to send the object to its downstream node along the path.
If this node supports MP_NOTIFY object, it should parse the object
to get MP Router ID. If the MP Router ID is not the Router ID of
this node, it indicates that this node is not the MP node and thus
should send the object to the downstream node along the path.
6.3 Processing at the MP Node
When the parsed MP Router ID is just the Router ID of a downstream
node, it indicates this node is the MP node.
The MP node must stop adding the MP_NOTIFY object to the Path message
to be sent to the downstream node.
weilian Expires: Apr. 2007 [Page 6]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
The MP node determines the backup tunnel according to the PLR-Node
Router ID (which acts as the source address of backup tunnel) ,the
Backup Tunnel Tunnel ID and LSP ID notified by the MP_NOTIFY object.
If the backup tunnel exists, the MP node should sets up MP relations
between the protected tunnel and backup tunnel, and then sends a Resv
message containing the MP_NOTIFY_ACK object to the upstream node.
If the backup tunnel does not exist, the MP node should not send a
Resv message containing the subobject of this backup tunnel in
MP_NOTIFY_ACK object or even the whole MP_NOTIFY_ACK object to the
upstream node.
When the MP node has set up MP relation between the protected tunnel
and a backup tunnel, if the new received Path message does not
include the subobject containing this backup tunnel info in MP_NOTIFY
object or the whole MP_NOTIFY object, the MP node should cancel the
MP relation between the protected tunnel and this backup tunnel.
7. Processing the MP_NOTIFY_ACK Object
7.1 Processing at the MP Node
After the MP node establishes MP relation between the protected
tunnel and backup tunnel, it should include the MP_NOTIFY_ACK object
in the Resv message of protected tunnel to be sent to the upstream
node, and fill in the PLR-Node Router ID, MP-Node Router ID, the
Backup Tunnel Tunnel ID and LSP ID.
7.2 Processing at the Upstream Node
When an upstream node receives a Resv message containing the
MP_NOTIFY_ACK object:
If this node does not support MP_NOTIFY_ACK, it should continue to
send the object to its upstream node along the path.
If this node supports MP_NOTIFY_ACK, it should parse the object to
get PLR-Node Router ID. If the PLR RouterID is not the Router ID of
this node, it indicates that this node is not the PLR node and thus
should send the object to the upstream node along the path.
7.3 Processing at the PLR Node
When the parsed PLR RouterID is just the Router ID of a upstream
node, it indicates that this node is the PLR node.
The PLR node must stop adding the MP_NOTIFY_ACK object to the Resv
message to be sent to the upstream node.
The PLR node parses the Backup Tunnel Tunnel ID and LSP ID notified
by the MP_NOTIFY_ACK object.
weilian Expires: Apr. 2007 [Page 7]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
If the parsed backup tunnel Tunnel ID and LSP ID is consistent with
the Tunnel ID and LSP ID of the backup tunnel that has set up FRR
relation, then the PLR node thinks that it receives an
acknowledgement from the downstream MP node. In this case, when the
FRR switchover occurs, the FRR_SWITCH object mechanism may be used
to update the protocol state of protected tunnel.
If the parsed backup tunnel Tunnel ID and LSP ID is inconsistent
with the Tunnel ID and LSP ID of the backup tunnel that has set up
FRR relation, then the PLR node should think that the
acknowledgement received from the downstream MP node is incorrect.
In this case, when the FRR switchover occurs, only the mechanism
defined by RFC4090 can be used to update the protocol state of
protected tunnel.
If the upstream PLR node supporting this object receives a Resv
message of protected tunnel not containing the MP_NOTIFY_ACK
object, it indicates that the downstream MP node does not support
the MP_NOTIFY object. In this case, when the FRR switchover occurs,
only the mechanism defined by RFC4090 can be used to update the
protocol state of protected tunnel.
8. Processing the FRR_SWITCH Object
8.1 Processing at the PLR Node
Upon receipt of the MP_NOTIFY_ACK object of the MP node, once FRR
switchover happens to the protected tunnel due to link or node
failure, the PLR node should add the FRR-SWITCH object to the Path
message of backup tunnel, and fill in the PLR-Node RouterID, MP-Node
RouterID. Then, it should send the message to the downstream node to
explicitly notify FRR switchover in PLR node to the MP node.
During the FRR switchover, Path messages of the backup tunnel of PLR
node must contain the FRR_SWITCH object.
After the FRR switchover of protected tunnels recover, the PLR node
should remove the FRR_SWITCH object from the Path message of backup
tunnel. Then the PLR node sends the message to the downstream node to
implicitly notify the FRR switchover recovery to the MP node.
8.2 Processing at the Downstream Node
When an downstream node receives a Path message containing the
FRR_SWITCH object:
If this node does not support FRR_SWITCH, it should continue to
send the object to its downstream node along the path.
If this node supports FRR_SWITCH, it should parse the object to
get MP Router ID. If the MP Router ID is not the Router ID of this
node, it indicates that this node is not the MP node and thus
should send the object to the downstream node along the path.
weilian Expires: Apr. 2007 [Page 8]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
8.3 Processing at the MP Node
When the parsed MP Router ID is just the Router ID of a downstream
node, it indicates that this node is the MP node.
The MP node must stop adding the FRR_SWITCH object to the Path
message to be sent to the downstream node.
The MP node determines the protected tunnel to which FRR switchover
occurs according to the MP relation established before and the
PLR-Node RouterID notified by the FRR_SWITCH object, and then
refreshes the time-to-die of the protected tunnel’s PSB.
9 .Processing the FRR_SWITCH_ACK Object
9.1 Processing at the MP Node
Upon receipt of the Path messages containing the FRR_SWITCH object
of backup tunnel, the MP node refreshes the time-to-die of the
protected tunnel’s PSB according to the MP relations set up before
and the FRR_SWITCH object. The Resv message of backup tunnel that the
MP node sends to the upstream PLR node must contain the FRR_SWITCH_ACK
object. The MP node fill in PLR-Node Router ID, MP-Node Router ID, and
sends the Resv message to the upstream PLR node to explicitly notify
the acknowledgement to the FRR switchover in PLR node.
9.2 Processing at the Upstream Node
When an upstream node receives a Resv message containing the
FRR_SWITCH_ACK object:
If this node does not support FRR_SWITCH_ACK, it should continue to
send the object to its upstream node along the path.
If this node supports FRR_SWITCH_ACK, it should parse the object
to get PLR-Node Router ID. If the PLR RouterID is not the Router ID
of this node, it indicates that this node is not the PLR node and
thus should send the object to the upstream node along the path.
9.3 Processing at the PLR Node
When the parsed PLR RouterID is just the Router ID of a upstream
node, it indicates that this node is the PLR node.
The PLR node must stop adding the FRR_SWITCH_ACK object to the Resv
message to be sent to the upstream node.
The PLR node determines the protected tunnel to which FRR switchover
occurs according to the FRR relation established before, and then
refreshes the time-to-die of the protected tunnel’s RSB.
10. Processing the Err, Tear and Conf Messages of the Protected Tunnel
weilian Expires: Apr. 2007 [Page 9]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
10.1 PathErr and ResvTear Messages
In the FRR switchover state, the protected tunnel of MP node possibly
receives PathErr and ResvTear messages from a downstream node. When
sending the messages to the upstream node, it uses the source address
of backup tunnel as the destination IP addresses and uses the out
interface and next hop address of the backup tunnel Resv message.
When messages are received by the PLR node, they are processed in the
normal process, and the PLR node continues sending the messages to
upstream node.
10.2 ResvErr Message
In the FRR switchover state, the protected tunnel of PLR node
possibly receives a ResvErr message from the upstream node. When
sending the message to the downstream node, it uses the destination
address of backup tunnel as the destination IP addresses and uses the
out interface and next hop address of the backup tunnel Path
message. When the message is received by the MP node, it is processed
in the normal process, and the MP node continues sending the messages
to downstream node.
10.3 PathTear and ResvConf Messages
In the FRR switchover state, the protected tunnel of PLR node
possibly receives PathTear and ResvConf messages from an upstream
node. When sending the messages(the Router Alert option should be
removed) to a downstream node, it uses the out interface and next-hop
address of the backup tunnel Path message. When the messages are
received by the MP node, they are processed in the normal process,
and the MP node continues sending the messages (the Router Alert
option should be added)to downstream node.
11. IANA Considerations
Four new RSVP objects are defined in this document. The Class-Numbers
are TBA by IANA.
MP_NOTIFY object
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
MP_NOTIFY_ACK object
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
weilian Expires: Apr. 2007 [Page 10]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
FRR_SWITCH object
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
FRR_SWITCH_ACK object
Class-Number = TBA (form 11bbbbbb)
C-Type = 1 IPv4 address
C-Type = 2 IPv6 address
12 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
13. Disclaimer of Validity
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.
14. Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
weilian Expires: Apr. 2007 [Page 11]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006
15. References
[RFC4090] P. Pan, et al., "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels ", RFC4090, May 2005.
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels",RFC 3209, December 2001.
[RFC2205] R. Braden, et al., "Resource ReSerVation Protocol
(RSVP)", RFC 2205, September 1997.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC3473, January 2003.
[draft-ietf-ccamp-rsvp-node-id-based-hello-02]
Zafar Ali, et al., "Node ID based RSVP Hello:
A Clarification Statement", September 2005.
[draft-ietf-ccamp-rsvp-restart-ext-05] Satyanarayana, et al.,
"Extension to GMPLS RSVP Graceful Restart", September 2005.
16.Author Information
Jiang Weilian
ZTE Inc.
CHINA
Email: jiang.weilian@zte.com.cn
Kong Yong
ZTE Inc.
CHINA
Email: kong.yong@zte.com.cn
Luo Jian
ZTE Inc.
CHINA
Email: luo.jian@zte.com.cn
Feng Jun
ZTE Inc.
CHINA
Email: Feng.jun99@zte.com.cn
Cui Ying
ZTE Inc.
CHINA
Email: Feng.jun99@zte.com.cn
weilian Expires: Apr. 2007 [Page 12]
Internet-Draft draft-weilian-mpls-fast-reroute-ext-01 Oct. 2006