Network Working Group Siva Sivabalan (Ed.)
Internet Draft Sami Boutros
Intended status: Standards Track Kamran Raza
Expires: May 2009 Cisco Systems, Inc.,
Bob Thomas
K. Kumaki
KDDI Corporation
November 1, 2008
Graceful Shutdown of LDP Adjacency
draft-boutros-mpls-ldp-gs-adj-01.txt
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."
Sivabalan Expires May 2, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
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
This Internet-Draft will expire on May 2, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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. LDP GS Capability Advertisement................................6
6. Operation......................................................7
7. Security Considerations........................................8
8. IANA Considerations............................................9
9. Acknowledgments................................................9
10. References....................................................9
10.1. Normative References.....................................9
Sivabalan Expires May 2, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
Author's Addresses................................................9
Intellectual Property Statement..................................10
Disclaimer of Validity...........................................11
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
Sivabalan Expires May 2, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
that the proposed method can also be used to gracefully shutdown
targeted Hello adjacency as well provided that there is such a need.
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
Sivabalan Expires May 2, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
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
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| Type = 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.
Sivabalan Expires May 2, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
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
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. LDP GS Capability Advertisement
A new LDP capability TLV can be advertised using LDP Capability
message as specified in [2]. This TLV is termed "LDP Graceful
Shutdown Capability TLV" (LDP GS Capability TLV), and 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| GS Capability Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
The LDP GS Capability type is to be assigned by IANA.
Length equals 1.
S is set to 1 and 0 respectively to advertise and withdraw the GS
capability.
There is no capability data associated with this TLV.
If a neighbor LSR supports "Dynamic Capability", then the GS
capability TLV can be sent after session establishment. If an LSR
receives a notification message with the status code "Unsupported
Sivabalan Expires May 2, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
Capability" for GS TLV, it should stop sending GS TLV in Hello
message to the sender.
6. 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 May 2, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 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
necessary.
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).
7. 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 May 2, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
8. IANA Considerations
IANA is requested to make new allocation from its registry as
follows:
Optional Parameter Type Reference
Graceful Shutdown 0x0404 draft-boutros-ldp-gs-adj-00.txt
Furthermore, IANA is requested to allocate a new codepoint for GS
capability TLV.
9. Acknowledgments
The authors would like to thank George Swallow and Rajiv Asati for
their valuable comments.
10. References
10.1. Normative References
[1] Andersson, L., Minei, I, Thomas, B. (Editors), "LDP
Specification", RFC 5036, October 2007.
[2] Thomas, B., et. al., "LDP Capabilities", draft-ietf-mpls-ldp-
capabilities-02.txt, Work in Progress, April 2008.
Author's Addresses
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: msiva@cisco.com
Sivabalan Expires May 2, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: skraza@cisco.com
Bob Thomas
Email: bobthomas@alum.mit.edu
Kenji Kumaki
KDDI Corporation
Garden Air Tower Iidabashi, Chiyoda-ku
Tokyo, 102-8460
Japan
Email: ke-kumaki@kddi.com
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
Sivabalan Expires May 2, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
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
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
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, THE IETF TRUST 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.
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.
Sivabalan Expires May 2, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-gs-ldp-adj-01.txt November 2008
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sivabalan Expires May 2, 2009 [Page 12]