Internet DRAFT - draft-weilian-mpls-fast-reroute-ext

draft-weilian-mpls-fast-reroute-ext



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