[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                     Ping Pan (Juniper Networks)
Internet Draft                       Yakov Rekhter (Juniper Networks)
Expiration Date: February 2002    Kireeti Kompella (Juniper Networks)
                                             Fong Liaw (Zaffire Inc.)
                                 Dimitrios Pendarakis (Tellium, Inc.)
                                       George Swallow (Cisco Systems)
                                        John Drake (Calient Networks)


                 Graceful Restart Mechanism for RSVP-TE

                    draft-pan-rsvp-te-restart-01.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026, except that the right to
   produce derivative works is not granted.

   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.
















draft-pan-rsvp-te-restart-01.txt                                [Page 1]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


2. Abstract

   This document describes a mechanism that helps to minimize the
   negative effects on MPLS traffic caused by LSR's control plane
   restart, and specifically by the restart of its RSVP-TE component, on
   LSRs that are capable of preserving the MPLS forwarding component
   across the restart.

   This document also describes a mechanism that helps to minimize the
   negative effects on MPLS traffic caused by the disruption of the
   communication channel that is used to exchange RSVP messages between
   a pair of LSR, when the communication channel is separate from the
   channels carrying the actual LSPs, and the channels carrying the
   actual LSPs are not disrupted.


3. Summary for Sub-IP Area


3.1. Summary

   This document describes a mechanism that helps to minimize the
   negative effects on MPLS traffic caused by LSR's control plane
   restart, and specifically by the restart of its RSVP-TE component, on
   LSRs that are capable of preserving the MPLS forwarding component
   across the restart.

   This document also describes a mechanism that helps to minimize the
   negative effects on MPLS traffic caused by the disruption of the
   communication channel that is used to exchange RSVP messages between
   a pair of LSR, when the communication channel is separate from the
   channels carrying the actual LSPs, and the channels carrying the
   actual LSPs are not disrupted.


3.2. Related documents

   See the Reference Section


3.3. Where does it fit in the Picture of the Sub-IP Work

   This work fits squarely in either MPLS or CCAMP box.








draft-pan-rsvp-te-restart-01.txt                                [Page 2]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


3.4. Why is it Targeted at this WG

   The RSVP TE is a product of the MPLS WG. This document specifies
   procedures to minimize the negative effects caused by either restart
   of RSVP TE module of the control plane, or by a temporary failure of
   communication channel used to exchange RSVP messages between a pair
   of LSRs. Since the procedures described in this document are directly
   related to RSVP TE, it would be logical to target this document at
   the MPLS WG.

   At the same time, since the procedures described in this document use
   one of the RSVP objects defined in Generalized MPLS Signaling, and
   since Generalized MPLS Signaling belongs to CCAMP, one could also say
   that this document could be targeted at the CCAMP WG.


3.5. Justification

   The WG should consider this document, as it allows to minimize the
   negative effects caused by either restart of RSVP TE module of the
   control plane, or by a temporary failure of communication channel
   used to exchange RSVP messages between a pair of LSRs.


4. Motivation

   In the case where an LSR could preserve its MPLS forwarding state
   across restart of its control plane, and specifically its RSVP-TE
   component, it may be desirable not to perturb the LSPs going through
   that LSR (and specifically, the LSPs established by RSVP-TE).  In
   this document, we describe a mechanism, termed "RSVP-TE Graceful
   Restart", that allows to accomplish this goal.


5. RSVP-TE Extension

   The RSVP-TE Graceful Restart requires one new object, RESTART_CAP.
   The RSVP-TE Graceful Restart also uses one of the objects,
   SUGGESTED_LABEL, defined in GMPLS (an alternative to using the
   SUGGESTED_LABEL object would be to define a new object).


5.1. RESTART_CAP Object

   To indicate to a neighbor the Graceful Restart capability (as well as
   several parameters associated with this capability), an LSR uses a
   new object, RESTART_CAP. This object is carried in RSVP Hello
   messages. The object has the following format:



draft-pan-rsvp-te-restart-01.txt                                [Page 3]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


         Class = RESTART_CAP Class, C_Type = 1

         +-------------+-------------+-------------+-------------+
         |                Restart Time (in milliseconds)         |
         +-------------+-------------+-------------+-------------+
         |                Recovery Time (in milliseconds)        |
         +-------------+-------------+-------------+-------------+

      Restart Time

         This is a time (in milliseconds) that the sender of the
         RESTART_CAP object would like the receiver of that object to
         wait after the receiver detects the failure of RSVP
         communication with the sender.  While waiting, the receiver
         should retain the RSVP and MPLS forwarding state for the
         (already established) LSPs that traverse a link between the
         sender and the receiver.

         The Restart Time should long enough to allow the restart of the
         control plane, and specifically its RSVP-TE component.
         Likewise, the Restart Time should be long enough to allow the
         restart of the communication channel that is used, among other
         things, for RSVP communication.

      Recovery Time

         For a restarting LSR, this is the time (in milliseconds) that
         the restarting LSR is willing to retain its MPLS forwarding
         state that it preserved across the restart. The time is from
         the moment the LSR sends the RSVP Hello message carrying this
         information. Setting this time to 0 indicates that the
         forwarding state wasn't preserved across the restart (or even
         if it was preserved, is no longer available).

         For an (non restarting) LSR that re-established an RSVP
         adjacency with a neighbor, this is the time (in milliseconds)
         that the LSR is willing to retain its RSVP and MPLS state for
         the (already established) LSPs that traverse a link between the
         LSR and the neighbor.

         The Recovery Time should be long enough to allow the
         neighboring LSR's to re-sync all the LSP's in a graceful
         manner, without creating congestion in the RSVP-TE control
         plane.

         Value 0xffffffff in the Recovery Time is used to indicate that
         the MPLS forwarding state has been preserved across the
         restart, and will be retained until removed by means outside of



draft-pan-rsvp-te-restart-01.txt                                [Page 4]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


         the mechanisms described in this document.

   To support RSVP-TE Graceful Restart, a RSVP Hello message can be as
   follows:

         <Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>

                             [ <RESTART_CAP> ]



6. Operations

   For the sake of brevity in the context of this document by "the
   control plane" we mean "the RSVP-TE component of the control plane".

   An LSR that is capable of retaining its MPLS forwarding state across
   restart of its control plane should advertise this capability to its
   neighbors by carrying the RESTART_CAP object in the Hello messages it
   sends to the neighbors.

   Note that an LSR should advertise this capability to a neighbor only
   when the Dst_instance that the LSR advertises to the neighbor is 0.


6.1. Procedures for the restarting LSR

   After an LSR restarts its control plane, the LSR should check whether
   it was able to preserve its MPLS forwarding state from prior to the
   restart. If no, then the LSR must set the Recovery Time to 0 in the
   Hellos the LSR sends to its neighbors.

   If the forwarding state has been preserved, then the LSR starts its
   internal timer, called MPLS Forwarding State Holding timer (the value
   of that timer should be configurable), and marks all the MPLS
   forwarding state entries as "stale". At the expiration of the timer
   all the entries still marked as stale should be purged.  The value of
   the Recovery Time advertised in RSVP Hello messages should be set to
   the (current) value of the timer at the point when the Hello message
   carrying the Recovery Time is sent.

   We say that an LSR is in the process of restarting when the MPLS
   Forwarding State Holding timer is not expired. Once the timer
   expires, we say that the LSR completed its restart.

   The following procedures apply when an LSR is in the process of
   restarting.




draft-pan-rsvp-te-restart-01.txt                                [Page 5]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


   When the LSR receives a Path message from an (upstream) neighbor, the
   LSR first checks if it has an RSVP state associated with the message.
   If the state is found, then the LSR handles this message according to
   the procedures defined in [RSVP-TE] (this is irrespective of whether
   the message carries the SUGGESTED_LABEL object or not).  In addition,
   if the LSR is not the tail-end of the LSP associated with the Path
   message, and the downstream neighbor is in the process of restarting,
   the LSR places the outgoing label (the label that was received in the
   LABEL object from that neighbor prior to the neighbor's restart) in
   the SUGGESTED_LABEL object of the Path message that the LSR sends to
   the neighbor.

   If the RSVP state is not found, and the message does not carry the
   SUGGESTED_LABEL object, the LSR treats this as a setup for a new LSP,
   and handles it according to the procedures defined in [RSVP-TE].

   If the RSVP state is not found, and the message carries the
   SUGGESTED_LABEL object, the LSR searches its MPLS forwarding table
   (the one that was preserved across the restart) for an entry whose
   incoming label is equal to the label carried in the SUGGESTED_LABEL
   object (in the case of link bundling, this may also involve first
   identifying the appropriate incoming component link).

   If the MPLS forwarding table entry is not found, the LSR treats this
   as a setup for a new LSP, and handles it according to the procedures
   defined in [RSVP-TE].

   If the MPLS forwarding table entry is found, the appropriate RSVP
   state is created, the entry is bound to the LSP associated with the
   message, and the entry is no longer marked as stale. In addition, if
   the LSR is not the tail-end of the LSP, and the next hop LSR is in
   the process of restarting, the outgoing label from the entry is sent
   in the SUGGESTED_LABEL object of the Path message further downstream
   (in the case of link bundling the found entry also identifies the
   appropriate outgoing component link).

   For bidirectional LSP [GMPLS], in addition to the procedures
   described above, the LSR extracts the label from the UPSTREAM_LABEL
   object carried in the received Path message, and searches its MPLS
   forwarding table for an entry whose outgoing label is equal to the
   label carried in the object (in the case of link bundling, this may
   also involved first identifying the appropriate incoming component
   link).

   If the MPLS forwarding table entry is not found, the LSR treats this
   as a setup for a new LSP, and handles it according to the procedures
   defined in [RSVP-TE].




draft-pan-rsvp-te-restart-01.txt                                [Page 6]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


   If the MPLS forwarding table entry is found, the entry is bound to
   the LSP associated with the Path message, and the entry is no longer
   marked as stale.  In addition, if the LSR is not the tail-end of the
   LSP, the incoming label from that entry is sent in the UPSTREAM_LABEL
   object of the Path message further downstream (in the case of link
   bundling the found entry also identifies the appropriate outgoing
   component link).

   The Resv messages are processed as specified in [RSVP-TE], except
   that if the LSR, while in the process of restarting, receives a Resv
   message for which the LSR has no matching Path State Block, the LSR
   should not generate an RERR message specifying "no path information
   for this Resv", but just should drop the Resv message.


6.2. Procedures for restart of RSVP communication with a neighbor LSR

   An RSVP communication between an LSR and its neighbor could go down
   for two reasons: (1) the channel that carries the RSVP messages
   between the LSR and its neighbor went down, and (2) the neighbor's
   control plane went down.

   When an LSR detects that its communication with a neighbor's control
   plane went down, and the LSR knows that the neighbor is capable of
   preserving its MPLS forwarding state across restart (as was indicated
   by the presence of the RESTART_CAP object in the Hello messages
   received from the neighbor), the LSR should wait certain amount of
   time before taking any further actions.

   The amount of time the LSR is willing to wait is set to the lesser of
   the Restart Time, as was advertised by the neighbor, and a local
   timer. The local timer is started when the LSR detects that its
   communication with the neighbor's control plane went down. The value
   of the local timer should be configurable.  While waiting, the LSR
   should try to re-establish RSVP communication with the neighbor.

   While attempting to re-establish the RSVP communication with the
   neighbor, the LSR MUST use 0 as the Dst_instance, and the same
   Src_instance as the one it used before the communication went down.
   The Recovery Time carried in the RESTART_CAP object of the Hellos
   that the LSR sends to the neighbor should be set to the amount of
   time the LSR is willing to wait before taking any further actions.

   While waiting, the LSR should preserve the RSVP and MPLS forwarding
   state for the (already) established LSPs that traverse the link(s)
   between the LSR and the neighbor. In a sense with respect to such
   LSPs the LSR should behave as it continues to receive periodic RSVP
   refresh messages from the neighbor. At the same time, the LSR may



draft-pan-rsvp-te-restart-01.txt                                [Page 7]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


   clear LSPs that are in the process of being established when their
   refresh timers expire.


6.2.1. Neighbor's control plane restart

   The following specifies the procedures that apply when the LSR re-
   establishes communication with the neighbor's control plane within
   the Restart Time, the LSR determines (using the procedures defined in
   Section 5 of [RSVP-TE]) that the neighbor's control plane re-started,
   and the neighbor was able to preserve its forwarding state across the
   restart (as was indicated by a non-zero Recovery Time carried in the
   RESTART_CAP object of the RSVP Hello messages received from the
   neighbor).

   For each LSP that traverses the LSR, and for which the neighbor is
   the next hop, the LSR places the outgoing label (the label that was
   received in the LABEL object from that neighbor prior to the
   neighbor's restart) in the SUGGESTED_LABEL object of the Path message
   that the LSR sends to the neighbor.

   When the LSR receives a Path message from the neighbor, and the LSR
   itself is in the process of restarting, the LSR handles the Path
   message as described in the previous section.

   When the LSR receives a Path message from the neighbor, and the LSR
   completed its restart, the LSR handles this message according to the
   procedures defined in [RSVP-TE] (this is irrespective of whether the
   message carries the SUGGESTED_LABEL object or not).

   The Resv messages are processed as specified in [RSVP-TE], except
   that the LSR should send no Resv messages to the restarting neighbor
   until it first receives the Path messages from the neighbor.

   If there are many LSP's going through the restarting LSR, the
   neighbor LSR should avoid sending Path messages in a short time
   interval, as to avoid unnecessary stressing the restarting LSR's CPU.
   Instead, it should spread the messages across the Recovery Time
   interval.


6.2.2. Restart of RSVP control channel

   If the RSVP communication is re-established, the received
   Src_instance is unchanged, and the Recovery Time received from the
   neighbor is non-zero, then the LSR should treat the situation as
   simply an RSVP communication channel restart (and not as a restart of
   the neighbor's control plane).



draft-pan-rsvp-te-restart-01.txt                                [Page 8]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


   Once the communication gets re-established, the LSR SHOULD send an
   RSVP Summary Refresh to the neighbor.  A Summary Refresh messages
   containing the message_IDs for all acknowledged messages should be
   sent. IF the number of message_IDs causes the message to exceed the
   MTU, multiple messages are sent. These messages should carry their
   own message_ID with the ack requested flag set. This simply ensures
   that the Summary Refresh messages are reliably sent.  From this point
   normal Summary Refresh procedures are followed.  For any message that
   have not be acked, or did not carry a message_ID, normal procedures
   are followed. Note that if a large number of messages are due for
   immediate refresh, some pacing should be applied.


7. RSVP Refresh Overhead Reduction Extensions

   The mechanisms described in this document may benefit when combined
   with the RSVP Refresh Overhead Reduction Extensions, as specified in
   [RFC2961].


8. Fast Reroute and Graceful Restart

   Fast reroute [FR-Juniper, FR-Cisco] and RSVP-TE graceful restart are
   two complement techniques that are designed to protect traffic during
   failures.  Here are the conditions for their usage:

    (1) If the interface to a neighbor is up, and the LSR does not
        detect any communication problem with the neighbor's control
        plane, do nothing.

    (2) If the interface to a neighbor is up, and the LSR detects that
        its communication with a neighbor's control plane went down,
        the LSR should activate RSVP-TE graceful restart.

    (3) If the interface to a neighbor is up, but the LSR cannot
        receive Hello messages from the neighbor, the LSR should
        activate RSVP-TE graceful restart.

    (4) If the interface to a neighbor goes down, the LSR should
        activate fast reroute.











draft-pan-rsvp-te-restart-01.txt                                [Page 9]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


9. Security Consideration

   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol remain
   relevant.


10. Intellectual Property Considerations

   Juniper Networks, Inc. is seeking patent protection on some or all of
   the technology described in this Internet-Draft. If technology in
   this document is adopted as a standard, Juniper Networks agrees to
   license, on reasonable and non-discriminatory terms, any patent
   rights it obtains covering such technology to the extent necessary to
   comply with the standard.


11. Acknowledgments

   We acknowledge the helpful comments from Arthi Ayyangar, Bruce Cole,
   Manoj Leelanivas, Der-Hwa Gan, Nischal Sheth, Ewart Tempest, and
   Jonathan Lang.


12. References

   [RFC2961] L. Berger, et al, "RFC 2961: RSVP Refresh Overhead
   Reduction Extensions", RFC2961.

   [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
   -- version 1 functional specification," RFC2205.

   [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
   tunnels," Internet Draft.

   [GMPLS] P. Ashwood-Smith, et al, "Generalized MPLS Signaling - RSVP-
   TE Extensions", Internet Draft.

   [FR-Juniper] D. Gan, et al, "A Method for MPLS LSP Fast-Reroute Using
   RSVP Detours", Internet Draft.

   [FR-Cisco] R. Goguen, et al, "RSVP Label Allocation for Backup
   Tunnels", Internet Draft.








draft-pan-rsvp-te-restart-01.txt                               [Page 10]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001


13. Author Information


















































draft-pan-rsvp-te-restart-01.txt                               [Page 11]


Internet Draft      draft-pan-rsvp-te-restart-01.txt         August 2001



Ping Pan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: pingpan@juniper.net

Yakov Rekhter
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: yakov@juniper.net

Kireeti Kompella
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net

Fong Liaw
Zaffire Inc.
2630 Orchard Parkway,
San Jose, CA 95134
e-mail: fliaw@zaffire.com

Dimitrios Pendarakis
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757
tel. 732 923-4254
e-mail: dpendarakis@tellium.com

George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice:  +1 978 244 8143
e-mail:  swallow@cisco.com

John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
e-mail: jdrake@calient.net






draft-pan-rsvp-te-restart-01.txt                               [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/