[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                              Siva Sivabalan (Ed.)
Internet Draft                                             Sami Boutros
Intended status: Standards Track                            Kamran Raza
Expires: January 2009                              Cisco Systems, Inc.,

                                                             Bob Thomas

                                                           July 6, 2008

                    Graceful Shutdown of LDP Adjacency

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-

   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

Sivabalan              Expires January 6, 2009                 [Page 1]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 6, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   This document specifies an extension to Label Distribution Protocol
   (LDP) using which a Label Switched Router (LSR) can explicitly notify
   its neighbor LSR its intention to shutdown one or more LDP
   adjacencies. This extension shall be used to shutdown LDP adjacencies
   for planned maintenance without interrupting traffic.

Table of Contents

   1. Introduction...................................................3
   2. Terminology....................................................4
   3. Graceful Shutdown Mechanism....................................4
   4. Graceful Shutdown TLV..........................................5
   5. Operation......................................................6
   6. Security Considerations........................................7
   7. IANA Considerations............................................8
   8. Acknowledgments................................................8
   9. References.....................................................8
      9.1. Normative References......................................8
   Author's Addresses................................................8
   Intellectual Property Statement...................................9
   Disclaimer of Validity...........................................10

Sivabalan              Expires January 6, 2009                 [Page 2]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

1. Introduction

   In an MPLS network where LDP is used to establish Label Switched
   Paths (LSPs), there could be more than one LDP-enabled links between
   a pair of Label Switched Routers (LSRs). In this case, LDP Hello
   adjacency can be formed over more than one such links between the
   LSRs, and MPLS traffic can be sent over all links supporting
   adjacency for load balancing purpose.

   In case where multiple links exist between a pair of LSRs, an
   operator may want to gracefully shutdown LDP adjacency(ies) on one or
   more links (but not all) without bringing down the LDP session
   between the corresponding LSRs. Such planned shutdown can be required
   for maintenance purpose. In this context, the word "gracefully" means
   ceasing to use the specified link(s) for forwarding MPLS traffic with
   minimal or no traffic loss. It is possible to tweak the IGP metric of
   the link(s) so that IGP best paths do not include the link(s) from
   which MPLS traffic is to be diverted. However, this approach moves
   not only MPLS traffic but also IP traffic thereby causing unnecessary
   churn in the network. Furthermore, since IGP metric is tweaked, IGP
   updates must be triggered and advertised throughout the network which
   also creates unnecessary routing messages. It is also possible that
   LDP paths are learned via static routing in which case no amount of
   IGP tweaking would help. Using LDP mechanisms available today,
   operator could gracefully shutdown one or more LDP sessions on a
   given LSR. However, such mechanisms cannot be used for gracefully
   disabling LDP on specific adjacency(ies) between LSRs.

   In this document, we propose a mechanism to gracefully shutdown Hello
   adjacency(ies) between a pair of LSRs without shutting down the LDP
   session if multiple Hello adjacencies exist between those LSRs. Note
   that the proposed method can also be used to gracefully shutdown
   targeted Hello adjacency as well provided that there is such a need.

Sivabalan              Expires January 6, 2009                 [Page 3]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

2. Terminology

   GS: Graceful Shutdown

   IGP: Interior Gateway Protocol

   LSP: Label Switch Path

   LSR: Label Switch Router

   TLV: Type Length Value

3. Graceful Shutdown Mechanism

   The proposed mechanism is based on a new optional TLV called
   "Graceful Shutdown" TLV to be included in LDP Hello message. This TLV
   is similar to the existing optional parameters specified in RFC5036
   [1]. An LSR that intends to terminate a Hello adjacency sends a Hello
   message with the Graceful Shutdown (GS) TLV. Since Hello messages are
   sent over UDP, the proposed mechanism expects the receiving LSR to
   acknowledge the receipt of GS request by sending a Hello message with
   a GS TLV back to the sender. The value of GS TLV indicates whether
   the GS TLV represents the request or acknowledgement as described
   later in this document. However, if the receiver does not support GS
   TLV, the sender will not receive an acknowledgement. In this case,
   the sender will shutdown the corresponding adjacency based on a local
   policy (e.g., after sending a certain number of Hello messages with
   GS TLV or after a certain period of time since the Hello message with
   GS TLV was sent).

   Note that an LSR can have multiple adjacencies over a shared media
   link; one for each neighbor LSR connected via the link. Thus, each
   Hello message originating from an LSR will be sent over all the
   adjacencies on the link. The LSR initiating GS will bring down an
   adjacency after either getting GS acknowledgement from the
   corresponding neighbor LSR or a certain period of time (whichever

Sivabalan              Expires January 6, 2009                 [Page 4]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   comes first). An operator may want to disable LDP on a shared media
   link after gracefully shutting down all adjacencies over the link.

   If an LSR capable of recognizing GS TLV receives a Hello message with
   GS request TLV and the adjacency does not exist, it will immediately
   send a Hello message with GS acknowledgement TLV.

   If an LSR capable of recognizing GS TLV receives a Hello message with
   GS acknowledgement TLV from a neighbor and the LSR has not sent GS
   request TLV, it will simply ignores the GS TLV.

4. Graceful Shutdown TLV

   The GS TLV has 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
  |1|0|       0x0404              |           Length              |
  |R|                       Reserved                              |

   Type is to be assigned by IANA (recommended value is 0x0404).

   Length is set to 4 indicating that the value field is 4 Octet long.

   R-bit: indicates whether the Hello message is for graceful shutdown
   request or acknowledgement. This bit is set to 1 and 0 for request
   and acknowledgement respectively.

   Reserved: This field is ignored.

   If an LSR does not support GS TLV, it should silently ignore the GS
   TLV and process the rest of the message. Furthermore, the LSR does

Sivabalan              Expires January 6, 2009                 [Page 5]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   not forward the GS TLV any further. Thus, the U and F bits are set to
   1 and 0 respectively in accordance with RFC5036.

   If the Hello message contains multiple GS TLVs, only the first one is
   taken into consideration.

5. Operation

   An LSR initiating GS carries out the following steps:

   1. Update the forwarding entries such that the adjacency being
      shutdown is no longer used in the data plane to transmit MPLS
      packets belonging to LDP applications to the receiver.

   2. Send up to N Hello messages with GS request (R bit set to 1) TLV.
      These messages are sent at the configured Hello interval. The
      default value of N is 2. The LSR does not send more than N Hello
      messages even if it does not receive GS acknowledgement TLV (R bit
      set to 0) from the receiver.

   3. Stop sending any more Hello messages (even if it has not sent N
      Hello messages) and go to step 7 if the LSR receives a Hello
      message with GS acknowledgement TLV.

   4. After sending N Hello messages with GS request TLV without getting
      any Hello message with GS acknowledgement TLV from the receiver,
      stop sending any more Hello messages and start a timer (let us
      call it the "GS timer"). The expiry value of the GS timer can be
      configured and has a default value equal to the Hello adjacency
      expiry timer value.

   5. While waiting for the GS timer to expire, if a Hello message with
      GS acknowledgment TLV arrives from the receiver, stop the GS timer
      and go to step 7.

   6. Wait until the GS timer expires and then go to step 7.

Sivabalan              Expires January 6, 2009                 [Page 6]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   7. Update the forwarding plane such that MPLS packets belonging to
      LDP applications are no longer received from the receiver over the
      shutdown adjacency.

   An LSR receiving GS request carries out the following steps:

   1. If the GS TLV is recognized, update the forwarding plane such that
      the adjacency being shutdown is no longer used in the data plane
      to transmit MPLS packets belonging to LDP applications. If GS TLV
      is not recognized, simply ignore the TLV.

   2. Send a Hello message with GS acknowledgement TLV if the GS TLV is
      recognized. If the GS TLV is not recognized and Hello messages are
      not received from the sender during the Hello adjacency expiry
      period, update the forwarding plane such that the adjacency is no
      longer used in the data plane to transmit MPLS packets belonging
      to LDP applications to the sender.

   3. Continue to send Hello messages corresponding to the adjacency
      being shutdown so that the adjacency can be brought up again if

   In case both LSRs corresponding to an adjacency initiate GS at the
   same time, each LSR removes the adjacency from the forwarding plane
   upon getting the GS acknowledgement from its neighbor or on the
   expiry of GS timer (whichever comes first).

6. Security Considerations

   The security considerations pertaining to LDP Hello messages are
   discussed in RFC5036. The optional GS TLV introduced in this document
   does not impose any extra security concern or requirement.

Sivabalan              Expires January 6, 2009                 [Page 7]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

7. IANA Considerations

   IANA is requested to make new allocation from its registry as

   Optional Parameter     Type         Reference

   Graceful Shutdown      0x0404       draft-boutros-ldp-gs-adj-00.txt

8. Acknowledgments

   The authors would like to thank George Swallow for his valuable

9. References

9.1. Normative References

   [1]   Andersson, L., Minei, I, Thomas, B. (Editors), "LDP
         Specification", RFC 5036, October 2007.

Author's Addresses

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Email: msiva@cisco.com

Sivabalan              Expires January 6, 2009                 [Page 8]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   Sami Boutros
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, California 95134
   Email: sboutros@cisco.com

   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Email: skraza@cisco.com

   Bob Thomas
   Email: bobthomas@alum.mit.edu

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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

Sivabalan              Expires January 6, 2009                 [Page 9]

Internet-Draft   draft-boutros-mpls-gs-ldp-adj-00.txt         July 2008

   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Sivabalan              Expires January 6, 2009                [Page 10]