Internet DRAFT - draft-ldp-ila-extension
draft-ldp-ila-extension
Network Working Group A. Lo
Internet-Draft K. Patel
Intended status: Standards Track V. Lim
Expires: July 4, 2012 Cisco Systems
January 1, 2012
Incremental Label Announcement Extensions for LDP
draft-ldp-ila-extension-01.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 July 4, 2012.
Copyright Notice
Lo, et al. Expires July 4, 2012 [Page 1]
Internet-Draft Incremental Label Announcement for LDP January 2012
Copyright (c) 2012 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 July 4, 2012 [Page 2]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 (LM-S/LM-R) . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Lo, et al. Expires July 4, 2012 [Page 3]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 July 4, 2012 [Page 4]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 July 4, 2012 [Page 5]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 supported by both endpoints should appear in
the the ILA version TLVs. If unsupported FEC types appear, they will
be discarded by the receiver.
The ILA Version message is defined as following:
Lo, et al. Expires July 4, 2012 [Page 6]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 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.
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 (LM-S/LM-R)
During label mapping advertisement/withdraw, an LDP endpoint plays
the role of the label mapping sender (LM-S) or label mapping receiver
(LM-R).
For FEC types which the ILA procedures apply, the LM-S will need to
maintain a local label binding table and associate an ILA VERSION-ID
Lo, et al. Expires July 4, 2012 [Page 7]
Internet-Draft Incremental Label Announcement for LDP January 2012
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 LM-R similarly, will need to keep 1) bindings learned from an
LM-S in a remote binding table, and 2) the last VERSION-ID "assign"
value learned from the LM-S. Both the remote binding table and the
LM-S version ID "assign" value needs to be maintained across a LDP
session restart.
After session establishments, the LM-S must wait for a VERSION-ID
"request" message from the LM-R. The LM-R sends the VERSION-ID that
it last processed from the LM-S. If the LM-R needs to purge its
remote binding table, it can optionally send a VERSION ID=0 "request"
to the LM-S request that it re-send all its bindings. The LM-R does
not necessarily send a VERSION-ID "request" TLV immediately after a
session is established. It sends the request when it's ready to
receive bindings.
After receiving a VERSION-ID "request" message from the LM-R, an LM-S
should send a VERSION-ID "assign" message starting with VERSION-ID
not greater than the VERSION-ID requested by the LM-R. The LM-R upon
receiving the VERSION-ID "assign", must mark all bindings with
VERSION-ID greater than the assigned VERSION-ID as stale and purge
them after the graceful restart period expires. The LM-S should then
scan its local label binding table and advertise/withdraw bindings
with VERSION-IDs starting with the version id less than or equal to
the VERSION-ID "assign" message. The LM-S 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 LM-S 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 LM-S 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 an LM-S MUST keep track of all its
bindings and withdraw them. If bindings are deleted from the local
Lo, et al. Expires July 4, 2012 [Page 8]
Internet-Draft Incremental Label Announcement for LDP January 2012
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
use a value=0, to force the LM-R to purge all previously learned
bindings.
5.3. ILA Version ID=0 Handling
VERSION-ID=0 is a special value that MUST NOT be used as a version-id
value for a label mapping. If an LM-S sends a VERSION-ID assign TLV
with this version ID:
1) the LM-R upon processing this message, MUST mark all it's
received bindings as stale and follow LDP GR restart procedures.
2) The LM-S 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
It's left to the implementer to decide how to assign ILA VERSION-ID
values to label mappings and how frequently to send per FEC type ILA
Version ID "assign" updates from the LM-S to the LM-R. The simplest
approach is to assign a unique version ID per label mapping messages.
Unlike BGP, LDP announcements complete in a relative short period
after the LDP session re-establishes, so a single ILA VERSION-ID
update per FEC type sent after finishing LIB advertisement completes
is sufficient.
5.5. ILA Version ID wraparound
The Version ID field is defined as a 64 bit value, so wraparound is
unlikely unless the implementer uses a fewer number of bytes
internally to represent the version-id. This section describes 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 wraparound occurs, this situations needs to be handled otherwise
the ILA procedures will fail if the session resets before the re-
announcment updates to the LM-R completes.
When wraparound occurs, the LM-S MUST:
mark all the affected LDP peers with a "re-announcement required"
flag indicating that labels must be completely re-announced.
send an ILA VERSION-ID =1 "assign" update to reset the version id
to lest possible value for every affected LM-R.
Lo, et al. Expires July 4, 2012 [Page 9]
Internet-Draft Incremental Label Announcement for LDP January 2012
walk entire LIB and update the VERSION-ID value of every label
binding.
reannounce all local label bindings to the affected LM-R.
for each affected LM-R, clear the "re-announce required" flag only
after VERSION-ID renumber/re-announcement is complete.
If the LDP session goes down and re-establishes with the "re-announce
require"d flag still set, the LM-S MUST respond to the LM-R
VERSION-ID request with a LM-S VERSION-ID "Assign" with version-id
set to 0 and re-announce all its bindings.
6. Acknowledgements
The authors wish to thank Bin Mo and Eric Rosen for their comments.
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.
Lo, et al. Expires July 4, 2012 [Page 10]
Internet-Draft Incremental Label Announcement for LDP January 2012
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
Vanson Lim
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: vlim@cisco.com
Lo, et al. Expires July 4, 2012 [Page 11]
