Network Working Group Jiang Weilian Internet Draft Feng Jun Cui Ying Expiration Date: June 2006 Kong Yong Luo Jian ZTE, Inc. Dec. 2005 Extensions to RSVP-TE Fast Reroute draft-weilian-mpls-fast-reroute-ext-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 5 of RFC3209, Section 9 of RFC3473. 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. 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 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 20, 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 through the Refresh message of backup tunnel, so that the protocol message of protected tunnel will not be refreshed along the path of backup tunnel, the middle nodes and tail node of backup tunnel will not assign many unused labels. weilian Expires: June 2006 [Page 1] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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 along the path of backup tunnel, intermediate and tail nodes of the backup tunnel will allocate abundant useless labels. 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 through the Refresh message of the backup tunnel, so that the protocol message of protected tunnels will not be refreshed along the path of backup tunnel, the middle nodes and tail node of backup tunnel will not assign many unused labels. 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. weilian Expires: June 2006 [Page 2] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 Class-Number = TBA (form 11bbbbbb) 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: June 2006 [Page 3] Internet-Draft draft-weilian-mpls-rsvp-te-ext-00.txt Dec. 2005 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. weilian Expires: June 2006 [Page 4] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 Class-Number = TBA (form 11bbbbbb) C-Type = 1 IPv4 address C-Type = 2 IPv6 address 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PLR-Node Router ID: Router ID of the Point of Local Repair (PLR) of the protected tunnel. weilian Expires: June 2006 [Page 5] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 MP-Node Router ID: Router ID of the Merge Point (MP) of the protected tunnel and backup tunnel. Subobject 1: IPv4 address 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Protected Tunnel Sender Address (4bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Tunnel Tunnel ID | Protected Tunnel LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type£º 0x01 IPv4 address. Length£º The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is always 12. Reserved (Res)£º This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Protected Tunnel Sender Address: The source address of the protected tunnel in FRR switchover state. Protected Tunnel Tunnel ID: The Tunnel ID of the protected tunnel in FRR switchover state. Protected Tunnel Lsp ID: The LSP ID of the protected tunnel in FRR switchover state. Subobject 2: IPv6 address 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Protected Tunnel Sender Address (16bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Tunnel Tunnel ID | Protected Tunnel LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ weilian Expires: June 2006 [Page 6] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 Type£º 0x02 IPv6 address. Length£º The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is always 24. Reserved (Res)£º This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Protected Tunnel Sender Address: The source address of the protected tunnel in FRR switchover state. Protected Tunnel Tunnel ID: The Tunnel ID of the protected tunnel in FRR switchover state. Protected Tunnel Lsp ID: The LSP ID of the protected tunnel in FRR switchover state. 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) 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. weilian Expires: June 2006 [Page 7] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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. 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. weilian Expires: June 2006 [Page 8] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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. 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 weilian Expires: June 2006 [Page 9] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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, as well as Sender Address, Tunnel ID and LSP ID of the protected tunnel. Then, it should send the message to the downstream node to notify explicitly the protected tunnel in FRR switchover state 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 tunnel recovers, the PLR node should delete the subobject containing the protected tunnel info from the FRR_SWITCH object in the Path message of backup tunnel (or delete the whole FRR_SWITCH object if it has no subobject). Then the PLR node sends the message to the downstream node to notify implicitly to the MP node of the FRR switchover recovery of protected tunnel. 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. 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 subobject information 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 weilian Expires: June 2006 [Page 10] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 protected tunnel¡¯s PSB according to 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, Sender Address, Tunnel ID and LSP ID of the protected tunnel, and sends the Resv message to the upstream PLR node to notify explicitly the acknowledgement to the protected tunnel in FRR switchover state. 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 subobject information notified by the FRR_SWITCH_ACK object, 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 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 weilian Expires: June 2006 [Page 11] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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 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 weilian Expires: June 2006 [Page 12] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 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 (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. 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. weilian Expires: June 2006 [Page 13] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005 [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: June 2006 [Page 14] Internet-Draft draft-weilian-mpls-fast-reroute-ext-00 Dec. 2005