< draft-boutros-mpls-ldp-gs-adj-00.txt   draft-boutros-mpls-ldp-gs-adj-01.txt >
Network Working Group Siva Sivabalan (Ed.) Network Working Group Siva Sivabalan (Ed.)
Internet Draft Sami Boutros Internet Draft Sami Boutros
Intended status: Standards Track Kamran Raza Intended status: Standards Track Kamran Raza
Expires: January 2009 Cisco Systems, Inc., Expires: May 2009 Cisco Systems, Inc.,
Bob Thomas Bob Thomas
July 6, 2008 K. Kumaki
KDDI Corporation
November 1, 2008
Graceful Shutdown of LDP Adjacency Graceful Shutdown of LDP Adjacency
draft-boutros-mpls-ldp-gs-adj-00.txt draft-boutros-mpls-ldp-gs-adj-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 32 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 6, 2009. This Internet-Draft will expire on May 2, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies an extension to Label Distribution Protocol This document specifies an extension to Label Distribution Protocol
(LDP) using which a Label Switched Router (LSR) can explicitly notify (LDP) using which a Label Switched Router (LSR) can explicitly notify
its neighbor LSR its intention to shutdown one or more LDP its neighbor LSR its intention to shutdown one or more LDP
adjacencies. This extension shall be used to shutdown LDP adjacencies adjacencies. This extension shall be used to shutdown LDP adjacencies
for planned maintenance without interrupting traffic. for planned maintenance without interrupting traffic.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................4 2. Terminology....................................................4
3. Graceful Shutdown Mechanism....................................4 3. Graceful Shutdown Mechanism....................................4
4. Graceful Shutdown TLV..........................................5 4. Graceful Shutdown TLV..........................................5
5. Operation......................................................6 5. LDP GS Capability Advertisement................................6
6. Security Considerations........................................7 6. Operation......................................................7
7. IANA Considerations............................................8 7. Security Considerations........................................8
8. Acknowledgments................................................8 8. IANA Considerations............................................9
9. References.....................................................8 9. Acknowledgments................................................9
9.1. Normative References......................................8 10. References....................................................9
Author's Addresses................................................8 10.1. Normative References.....................................9
Intellectual Property Statement...................................9
Disclaimer of Validity...........................................10 Author's Addresses................................................9
Intellectual Property Statement..................................10
Disclaimer of Validity...........................................11
1. Introduction 1. Introduction
In an MPLS network where LDP is used to establish Label Switched In an MPLS network where LDP is used to establish Label Switched
Paths (LSPs), there could be more than one LDP-enabled links between Paths (LSPs), there could be more than one LDP-enabled links between
a pair of Label Switched Routers (LSRs). In this case, LDP Hello a pair of Label Switched Routers (LSRs). In this case, LDP Hello
adjacency can be formed over more than one such links between the adjacency can be formed over more than one such links between the
LSRs, and MPLS traffic can be sent over all links supporting LSRs, and MPLS traffic can be sent over all links supporting
adjacency for load balancing purpose. adjacency for load balancing purpose.
skipping to change at page 5, line 22 skipping to change at page 5, line 25
GS acknowledgement TLV from a neighbor and the LSR has not sent GS GS acknowledgement TLV from a neighbor and the LSR has not sent GS
request TLV, it will simply ignores the GS TLV. request TLV, it will simply ignores the GS TLV.
4. Graceful Shutdown TLV 4. Graceful Shutdown TLV
The GS TLV has the following format: The GS TLV has the following format:
0 1 2 3 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 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 | |1|0| Type = 0x0404 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved | |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type is to be assigned by IANA (recommended value is 0x0404). 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. 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 R-bit: indicates whether the Hello message is for graceful shutdown
request or acknowledgement. This bit is set to 1 and 0 for request request or acknowledgement. This bit is set to 1 and 0 for request
skipping to change at page 6, line 10 skipping to change at page 6, line 13
Reserved: This field is ignored. Reserved: This field is ignored.
If an LSR does not support GS TLV, it should silently ignore the GS 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 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 not forward the GS TLV any further. Thus, the U and F bits are set to
1 and 0 respectively in accordance with RFC5036. 1 and 0 respectively in accordance with RFC5036.
If the Hello message contains multiple GS TLVs, only the first one is If the Hello message contains multiple GS TLVs, only the first one is
taken into consideration. taken into consideration.
5. Operation 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
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: An LSR initiating GS carries out the following steps:
1. Update the forwarding entries such that the adjacency being 1. Update the forwarding entries such that the adjacency being
shutdown is no longer used in the data plane to transmit MPLS shutdown is no longer used in the data plane to transmit MPLS
packets belonging to LDP applications to the receiver. packets belonging to LDP applications to the receiver.
2. Send up to N Hello messages with GS request (R bit set to 1) TLV. 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 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 default value of N is 2. The LSR does not send more than N Hello
skipping to change at page 7, line 32 skipping to change at page 8, line 32
3. Continue to send Hello messages corresponding to the adjacency 3. Continue to send Hello messages corresponding to the adjacency
being shutdown so that the adjacency can be brought up again if being shutdown so that the adjacency can be brought up again if
necessary. necessary.
In case both LSRs corresponding to an adjacency initiate GS at the In case both LSRs corresponding to an adjacency initiate GS at the
same time, each LSR removes the adjacency from the forwarding plane same time, each LSR removes the adjacency from the forwarding plane
upon getting the GS acknowledgement from its neighbor or on the upon getting the GS acknowledgement from its neighbor or on the
expiry of GS timer (whichever comes first). expiry of GS timer (whichever comes first).
6. Security Considerations 7. Security Considerations
The security considerations pertaining to LDP Hello messages are The security considerations pertaining to LDP Hello messages are
discussed in RFC5036. The optional GS TLV introduced in this document discussed in RFC5036. The optional GS TLV introduced in this document
does not impose any extra security concern or requirement. does not impose any extra security concern or requirement.
7. IANA Considerations 8. IANA Considerations
IANA is requested to make new allocation from its registry as IANA is requested to make new allocation from its registry as
follows: follows:
Optional Parameter Type Reference Optional Parameter Type Reference
Graceful Shutdown 0x0404 draft-boutros-ldp-gs-adj-00.txt Graceful Shutdown 0x0404 draft-boutros-ldp-gs-adj-00.txt
8. Acknowledgments Furthermore, IANA is requested to allocate a new codepoint for GS
capability TLV.
The authors would like to thank George Swallow for his valuable 9. Acknowledgments
comments.
9. References The authors would like to thank George Swallow and Rajiv Asati for
their valuable comments.
9.1. Normative References 10. References
10.1. Normative References
[1] Andersson, L., Minei, I, Thomas, B. (Editors), "LDP [1] Andersson, L., Minei, I, Thomas, B. (Editors), "LDP
Specification", RFC 5036, October 2007. 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 Author's Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 9, line 21 skipping to change at page 10, line 21
Kamran Raza Kamran Raza
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
Email: skraza@cisco.com Email: skraza@cisco.com
Bob Thomas Bob Thomas
Email: bobthomas@alum.mit.edu 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 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 17 change blocks. 
23 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/