Network Working Group A. Lo Internet-Draft K. Patel Intended status: Standards Track V. Lim Expires: January 2, 2012 Cisco Systems July 1, 2011 Incremental Label Announcement Extensions for LDP draft-ldp-ila-extension-00.txt Abstract The current LDP Graceful Restart (GR) mechanism specified in RFC3478 requires a complete re-advertisement of the LDP label binding information across a session restart, even though complete label binding information might be preserved. In this document we specify extensions to LDP graceful restart in order to support avoiding unnecessary transmission of the label binding information preserved across a session restart, thus accelerating the router re-convergence. More specifically, we describe a version number based batching mechanism for keeping track of the label binding information across a session restart. The new 1) LDP ILA capability TLV, 2) LDP VERSION ID TLV and 3) LDP ILA Version message type, is introduced for checkpointing the label binding version maintained for a neighbor. We also specify procedures for handling label binding table version update across a session restart. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 2, 2012. Copyright Notice Lo, et al. Expires January 2, 2012 [Page 1] Internet-Draft Incremental Label Announcement for LDP July 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Lo, et al. Expires January 2, 2012 [Page 2] Internet-Draft Incremental Label Announcement for LDP July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Incremental Label Announcement Capability TLV . . . . . . . . 4 3. Incremental Label Announcement FEC Version TLV . . . . . . . . 5 4. Incremental Label Announcement Version Message . . . . . . . . 6 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Session Initialization . . . . . . . . . . . . . . . . . . 7 5.2. Label Mapping Sender/Receiver (LMS/LMR) . . . . . . . . . 7 5.3. ILA Version ID=0 Handling . . . . . . . . . . . . . . . . 9 5.4. ILA Version ID Assignment . . . . . . . . . . . . . . . . 9 5.5. ILA Version ID wraparound . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Lo, et al. Expires January 2, 2012 [Page 3] Internet-Draft Incremental Label Announcement for LDP July 2011 1. Introduction This document defines a new LDP Incremental Label Announcement extension for LDP Graceful restart. This mechanism avoids unnecessary transmission of the label binding information during session restarts and thus improve the overall router convergence. 1.1. Requirements Language 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 [RFC2119]. 2. Incremental Label Announcement Capability TLV The LDP Incremental Label Announcement (ILA) Capability TLV is used by an LDP speaker to list the FEC types that support the ILA capability. This TLV MUST be announced in the LDP initialization message along with the LDP FT Session TLV. An implementation that support LDP ILA MUST implement the procedures for Capability Parameters in LDP Initialization Messages. The format of a "Incremental Label Announcement Capability" TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ILA Capability (TBD IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ FEC Type List | | +-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit: The Unknown TLV bit should be set to the value 1. F-bit: The forward unknown TLV bit should be set to the value 0. ILA Capability: The ILA Capability code is assigned by IANA (TBD). Lo, et al. Expires January 2, 2012 [Page 4] Internet-Draft Incremental Label Announcement for LDP July 2011 Length: The length indicates the number of octets for S/Reserved byte and the bytes found in the FEC Type List Data. S-bit: The State Bit MUST always be set to 1. It indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV code point. The State Bit value is used as follows: 1 - The TLV is advertising the capability specified by the TLV code point. 0 - The TLV is withdrawing the capability specified by the TLV code point. FEC Type List: The FEC type list indicates the sender supported ILA FEC types. Each Octet of FEC Type List Data corresponds to a FEC type defined in the LDP Forwarding Equivalence Class (FEC) Type Namespace. 3. Incremental Label Announcement FEC Version TLV The ILA Version TLV is defined for controlling/versioning label mapping advertisements/withdraw messages for a given FEC type. This TLV is used by the receiver of the label advertisements/withdraw message to request which versions of Label bindings the LDP speaker should announce from. Furthermore, it is also used by the LDP speaker to verify that the labels advertisements for a given FEC type do fall within the specified version id. The LDP speaker uses this information in generating incremental announcements. The "ILA Version" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ILA Version (TBD IANA) | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Type | Mode | Reserved (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Version ID (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lo, et al. Expires January 2, 2012 [Page 5] Internet-Draft Incremental Label Announcement for LDP July 2011 U-bit: The Unknown TLV bit MUST be set to the value 0. F-bit: The forward unknown TLV bit MUST be set to the value 0. ILA Version: The ILA Version TLV type is assigned by IANA (TBD). Length: The length field is always set to 12. FEC type: Identifies the FEC type for which the ILA version message applies. Mode: 0 - Request Mode: Request label bindings starting from specified version. 1 - Assign Mode: Assign the specified version ID to the bindings that follow. Label Version ID: A 64 bit version number. 4. Incremental Label Announcement Version Message The new Incremental Label Announcement Version message is used by the speaker to send 1 or more ILA Version TLVs. This message contains one or more per FEC type TLVs used to request the peer to start sending labels with a given version number and to inform the peer the current version ID assigned to the bindings that follow. If there are multiple TLVs of a specific FEC type, at most there MUST be one Version-id "request", and Version-ID "assign" TLV for a given FEC type. An LDP speaker MUST not send this message unless the LDP peer has previously announced its ability to support the ILA capabilities. Only the LDP FEC types found in the ILA Capability FEC Type List should appear in the the ILA version TLVs. The ILA Version message is defined as following: Lo, et al. Expires January 2, 2012 [Page 6] Internet-Draft Incremental Label Announcement for LDP July 2011 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| ILA (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where TLV_1 through TLV_N are currently used for ILA Version-ID TLVs. 5. Procedures 5.1. Session Initialization An LDP speaker that is capable and willing to support the ILA procedures for a given FEC type advertises this ability through the Incremental Label Announcement Capability TLV in the LDP session initialization message. The ILA Capability TLV MUST only be included in the LDP initialization message when if LDP initialization message contains a FT session TLV indicating its ability to support LDP Graceful Restart. The sender of the ILA Capability TLV MUST include all the FEC types for which it intends to support ILA procedures for. The set of FEC types that is found in both the sent ILA Capability TLV and the received ILA Capability TLV represents the FEC types for which both LDP endpoints will follow ILA procedures when advertising/ withdrawing label bindings. The FEC type list may potentially change across a LDP restart. When this happens, the bindings for FEC types previously supporting ILA that changed disappeared for the new LDP session need to be purged. 5.2. Label Mapping Sender/Receiver (LMS/LMR) During label mapping advertisement/withdraw, an LDP endpoint plays the role of the label mapping sender (LMS) or label mapping receiver (LMR). For FEC types which the ILA procedures apply, the LMS will need to maintain a local label binding table and associate a ILA VERSION ID Lo, et al. Expires January 2, 2012 [Page 7] Internet-Draft Incremental Label Announcement for LDP July 2011 with each binding. Each time a local label binding changes (such that a re-advertisement or withdraw needs to be sent), the VERSION ID for the binding must be updated such that the value is greater than or equal to the current VERSION_ID being used to advertise/withdraw label mapping bindings. The local label binding table and associated VERSION ID must be maintained across a LDP session restart. This version id can be managed either on a router basis or on a per session level and is left to the implementer. The LMR similarly, will need to keep 1) bindings learned from an LMS in a remote binding table, and 2) the last VERSION ID "assign" value learned from the LMS. Both the remote binding table and the LMS version ID "assign" value needs to be maintained across a LDP session restart. After session establishments, the LMS must wait for a VERSION ID "request" message from the LMR. The LMR sends the VERSION ID that it last processed from the LMS. If the LMR needs to purge its remote binding table, it can optionally send a VERSION ID=0 "request" to the LMS request that it re-send all its bindings. The LMR does not necessarily send a VERSION-ID "request" TLV immediately after a session is established. It sends it the request when it's ready to receive bindings. After receiving a VERSION-ID "request" message from the LMR, a LMS should send a VERSION_ID "assign" message starting with version ID not greater than the VERSION-ID requested by the LMR. The LMS should then scan it's local label binding table and advertise/withdraw bindings with version id's starting with the version id it indicated in the VERSION-ID "assign" message. The LMS must also scan its local label binding table and mark all previously withdrawn bindings with VERSION-ID less than the "request" version ID as released. If the LMS is not able to honor sending with the requested Version-ID, it should send a VERSION-ID "assign" message with VERSION-ID equal to zero to indicate that all previously advertised label bindings should be discarded and that the LMS will be re- advertising all bindings. The bindings to be removed needs to be marked stale and purged if not reclaimed after the GR recovery period. Unlike the existing LDP Graceful restart behavior, after a session goes down and is re-established, label bindings previously advertised are not implied withdrawn, so a LMS MUST keep track of all its bindings and withdraw them. If bindings are deleted from the local label binding table while a "downed" neighbor is still in a LDP GR recovery period, that session must be flagged to indicate that if the LDP session re-establishes, then a VERSION ID "assign" message must Lo, et al. Expires January 2, 2012 [Page 8] Internet-Draft Incremental Label Announcement for LDP July 2011 use a value=0, to force the LMR to purge all previously learned bindings. 5.3. ILA Version ID=0 Handling If a LMS sets this version ID: 1) the LMR must purge all its previously received label bindings as the LMS will not be sending label withdraw's for previously advertised label mappings. 2) The LMS does not need to send label withdraws for previously advertised bindings, as all previously advertised bindings are implied withdrawn. 5.4. ILA Version ID Assignment Version ID's value can be incremented. The grouping of the number of label mapping updates per Version ID is up to the implementer. It's suggested that the default value is 100 label updates messages per unique Version ID. Each subsequent assigned value MUST be greater than the previously assigned value, but need not be contiguous. For example, the implementer may choose to have a unit Version id per update, but choose to send a Version ID "assign" message per 100 update. In this case, the LSR may send "assign" a Version id of 1, 101, 201,... The spacing of the increment is left to the implementor. 5.5. ILA Version ID wraparound The Version ID field is defined as a 64 bit value so wraparound is unlikely. This section defines how to handle this rare case. Since the each subsequent version ID needs to be assigned a value greater than the previously assigned value, when a wrap around occurs, the LMS must reset the LDP session, update the Version ID assigned to every binding and send a Version ID "assign" message after the session re-establishes. Since LDP graceful restart is supported by the sessions that employ ILA, resetting the session will not disrupt forwarding as the existing LDP GR mechanism should protect traffic. 6. Acknowledgements The authors wish to thank Bin Mo and Eric Rosen for their comments. Lo, et al. Expires January 2, 2012 [Page 9] Internet-Draft Incremental Label Announcement for LDP July 2011 7. IANA Considerations This draft require any new allocations by IANA for the 1) LDP ILA capability TLV, 2) LDP ILA Version ID TLV, and 3) LDP ILA Version Message.. 8. Security Considerations This extension to LDP does not change the underlying security issues inherent in the existing [RFC3478] and [RFC5036] 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and J. Le Roux, "LDP Capabilities", RFC 5561, July 2009. Authors' Addresses Alton Lo Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: altonlo@cisco.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Lo, et al. Expires January 2, 2012 [Page 10] Internet-Draft Incremental Label Announcement for LDP July 2011 Vanson Lim Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: vlim@cisco.com Lo, et al. Expires January 2, 2012 [Page 11]