Network Working Group S. Aggarwal
Internet Draft Juniper Networks
Expiration Date: April 2007
R. Aggarwal
Juniper Networks
J.L. Le Roux
France Telecom
Bob Thomas
Cisco Systems, Inc.
October 2006
LDP Capabilities
draft-thomas-mpls-ldp-capabilities-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."
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.
Aggarwal, et al. [Page 1]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A number of enhancements to the Label Distribution Protocol (LDP)
have been proposed. Some have been implemented, and some are
advancing toward standardization. It is likely that additional
enhancements will be proposed in the future. At present there is no
common mechanism for LDP speakers to activate such enhancements.
Consequently, an enhancement specification typically includes an ad
hoc procedure for activating it at session initialization time. This
draft specifies a mechanism for activating enhancements that allows
LDP speakers to enable enhancements at session establishment time as
well as to to enable and disable them following session
establishment.
Table of Contents
1 Introduction ............................................ 3
2 Specification Language .................................. 4
3 The LDP Capability Mechanism ............................ 4
4 Capability Message ...................................... 5
5 The Capability List TLV ................................. 5
6 Note on Terminology ..................................... 7
7 Procedures for Capability TLVs in Initialization Messages. 8
8 Procedures for Capability List TLVs in Capability Messages. 9
9 Extensions to Error Handling ............................ 10
10 Backward Compatibility .................................. 10
11 Security Considerations ................................. 11
12 IANA Considerations ..................................... 11
13 Acknowledgements ........................................ 12
14 References .............................................. 12
15 Author Information ...................................... 13
16 Intellectual Property Statement ......................... 13
17 Full Copyright Statement ................................ 14
Aggarwal, et al. [Page 2]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
1. Introduction
A number of enhancements to LDP as specified in [RFC3036] have been
proposed. These include LDP Graceful Restart [RFC3478], Fault
Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
layer 2 circuits [PWE], a method for learning labels advertised by
next next hop routers in support of fast reroute node protection
[NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
signaling inter-area LSPs [IALDP]. Some have been implemented, and
some are advancing toward standardization. It is likely that
additional enhancements will be proposed in the future.
At present LDP has no common mechanism for LDP speakers to activate
such enhancements. Consequently, the enhancement specifications
typically include ad hoc procedures for activating the enhancement at
session initialization time or assume that the enhancement is always
active. Furthermore, LDP has no mechanism for de-activating an
enhancement once activated.
This draft specifies an LDP capability advertisement mechanism for
managing the use of enhancements that associates capabilities with
LDP enhancements and defines an infrastructure for enabling and
disabling enhancements that enables peers to:
- Advertise the capability associated with an enhancement at
session establishment time or following session establishment,
thereby enabling the enhancement.
- Withdraw the capability associated with an enhancement following
session establishment thereby disabling the corresponding
capability.
The LDP capability advertisement mechanism is similar to the BGP
capability advertisement mechanism [RFC3392] [BGP-DYNCAP].
When the capability advertisement mechanism is in place an LDP
enhancement requiring LDP capability advertisement will be specified
by a document that:
- Describes the motivation for the enhancement;
- Specifies the behavior of LDP when the enhancement is enabled.
This includes the procedures, parameters, messages, and TLV's
required by the enhancement;
Aggarwal, et al. [Page 3]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
- Includes an IANA considerations section that notes that an IANA-
assigned code point for the capability corresponding to the
enhancement is required.
2. Specification 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 [RFC2119].
3. The LDP Capability Mechanism
Enhancements are likely to be announced during LDP session
establishment as each LDP speaker advertises capabilities
corresponding to the enhancements it desires.
Beyond that, capability advertisements may be used to dynamically
modify the characteristics of the session to suit changing
conditions. For example, an LSR capable of a particular enhancement
in support of some "feature" may not have advertised the
corresponding capability to its peers at session establishment time
because the feature was disabled at that time. Later an operator may
enable the feature, at which time the LSR would react by advertising
the corresponding capability to its peers. Similarly, when an
operator disables a feature associated with a capability the LSR
reacts by withdrawing the capability advertisement from its peers.
The LDP capability advertisement mechanism operates as follows:
- Each LDP speaker is assumed to implement a set of features each
of which has an associated capability. At any time a speaker may
have none, one or more of those features "enabled". When a
feature is enabled the speaker advertises the associated
capability to its peers. By advertising the capability to a peer
the speaker asserts that it shall perform the protocol actions
specified for the associated feature. For example, the actions
may involve receiving and processing messages from a peer that
the feature requires. Unless the capability has been advertised
the speaker will not perform protocol actions specified for the
corresponding feature.
- At session establishment time an LDP speaker MAY advertise
capabilities for features that are currently enabled by including
a Capability List TLV in its Initialization message.
Aggarwal, et al. [Page 4]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
- There is a well-known capability called Dynamic Announcement
which an LDP speaker MAY advertise in its Initialization message
to indicate that it is capable of advertising and withdrawing
capabilities following session establishment.
If a peer had advertised the Dynamic Announcement capability in
its Initialization message then at any time following session
establishment an LDP speaker MAY announce changes in its
advertised capabilities to that peer. To do this the LDP speaker
sends the peer a Capability message that includes a Capability
List TLV which specifies capabilities being advertised or
withdrawn.
4. Capability Message
The LDP Capability message is used by an LDP speaker subsequent to
session establishment to announce changes in the state for one or
more of its capabilities. In addition, it is used to carry
acknowledgements for capability state changes announcements that
require them (see Section 8).
The format of the Capability message is:
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| Capability (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability List TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where the Capability List TLV specifies capability state changes
being advertised or acknowledged.
5. The Capability List TLV
An LDP speaker MAY include a Capability List TLV as an optional
parameter in an Initialization message to announce capabilities it
has enabled to its LDP peer.
In addition, if its peer had advertised the Dynamic Announcement
capability at session establishment time an LDP speaker MAY send the
peer a Capability message when the speaker wishes to change the
capabilities it has advertised. The Capability List TLV included in
Aggarwal, et al. [Page 5]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
the Capability message specifies the capabilities the LDP speaker
wishes to advertise or withdraw.
The Capability List TLV MAY also be carried in a Notification message
when the Status Code in the Status TLV is Unsupported Capability as
described below.
The format of the Capability List TLV is:
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|0| Capability List TLV (IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where Capability List is a list of 1 or more Capability Objects, each
of which has the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Code(IANA) | Capability Length |C|S|A| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Capability Data |
| |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Capability Code: Identifies the capability. Capability codes are
assigned by IANA.
Capability Length: The length in octets of the Capability Object
exclusive of the Capability Code and Length fields.
C, S, A bits:
Each MUST be 0 in a Capability Object included in an
Initialization message.
The C, S, and A bits of a Capability Object in a Capability
message are used as follows:
C bit: The Command Bit indicates whether the sender is
Aggarwal, et al. [Page 6]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
announcing a change in state for the specified capability or
acknowledging receipt of a state change announcement.
1 - Announcement of a capability state change
0 - Acknowledgement of an capability announcement
S bit: The State Bit indicates whether the sender is
advertising or withdrawing the specified capability. The S
bit is ignored for acknowledgements (C-bit = 0).
1 - Capability is advertised
0 - Capability is withdrawn
A bit: The Acknowledgement Request Bit indicates that the
sender requests the receiver acknowledge the change in state
of the specified capability. The A bit is ignored for
acknowledgements (C bit = 0).
1 - Acknowledgement requested for capability
advertisement (withdrawal)
0 - Acknowledgement not required
Rsvrd: Reserved for future use.
Sequence Number:
The Sequence Number MUST be 0 in a Capability Object included in
an Initialization message.
The Sequence Number is used to uniquely identify the revision of
the capability state for a capability state change initiated by a
Capability message that requires acknowledgement. The Sequence
Number is specified by the LDP speaker initiating the change and
included by its peer in the peer's acknowledgement of the change.
Capability Data: Additional data required to fully specify the
capability.
6. Note on Terminology
The sections that follow talk of enabling and disabling capabilities.
The terminology "enabling (or disabling) a capability" is short hand
for "advertising (or withdrawing) a capability". Bear in mind that
it is an LDP enhancement that is enabled or disabled and that it is
the corresponding capability that is advertisted or withdrawn.
Aggarwal, et al. [Page 7]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
7. Procedures for Capability TLVs in Initialization Messages
An LDP speaker SHOULD NOT include more than one instance of a
capability with the same Capability Code, Capability Length, and
Capability Value in an Initialization message. Note however, that
processing multiple instances of such a capability does not require
special handling, as additional instances do not change the meaning
of an announced capability.
An LDP speaker determines the capabilities enabled by a peer by
examining the list of capabilities in the Capability List TLV, if
present in the Initialization message the speaker receives from the
peer.
An LDP speaker that has enabled a particular capability MAY use the
capability with its peer after the speaker determines that the peer
has enabled the capability.
These procedures enable an LDP speaker A that advertises a specific
LDP capability C to establish an LDP session with speaker B that does
not advertise C though B may support the LDP Capability List TLV and
the feature associated with C. In this situation whether or not
capability C may be used for the session depends on the semantics of
the functionality associated with C. If the semantics do not require
both A and B advertise C to one another then B could use it; that is,
A's advertisement of C permits B to use the corresponding
functionality for the session.
It is the responsibility of the capability designer to specify the
behavior of an LDP speaker that has enabled a certain enhancement and
determines that its peer has not advertised the corresponding
capability. The document specifying procedures for the capability
MUST describe the behavior in this situation. If the specified
procedure is to terminate the session the LDP speaker SHOULD send a
Notification message to the peer before terminating the session. The
Status Code in the Status TLV of the Notification message SHOULD be
Unsupported Capability, and the message SHOULD contain the
unsupported capabilities (see Section 9 for more details). In this
case the session SHOULD NOT be re-established automatically. How the
session is re-established is beyond the scope of this document. It
depends on the LDP capability and MUST be specified along with the
procedures specifying the capability.
An LDP speaker that supports capability advertisement and includes a
Capability List TLV in its Initialization message MAY set the TLV U
bit to 1. This ensures that an RFC3036 compliant peer that does not
support the capability mechanism will ignore the TLV and allow the
session to be established.
Aggarwal, et al. [Page 8]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
8. Procedures for Capability List TLVs in Capability Messages.
An LDP speaker MUST NOT send a Capability message to a peer unless
both the speaker and its peer had advertised the Dynamic Announcement
capability in their session Initialization messages and neither has
disabled the capability by means of a Capability message.
An LDP speaker MAY send a Capability message to a peer if both the
speaker and its peer had advertised the Dynamic Announcement
capability in their session Initialization messages.
An LDP speaker determines the capabilities enabled by a peer by
determining the set of capabilities enabled at session initialization
(as specified in Section 7) and tracking changes to that set made by
Capability messages from the peer.
An LDP speaker that has enabled a particular capability MAY use the
enhancement corresponding to the capability with its peer after the
speaker determines that the peer has enabled the capability.
Some capabilities may be such that when dynamically enabled or
disabled proper operation requires synchronization of the protocol
message stream between LDP speakers. The purpose of the
synchronization is to ensure that when a protocol message is received
and processed during the state transition of such a capability the
capability state in effect at the receiver is the same as the
capability state in effect when the sender generated the message.
The following acknowledgement mechanism provides the coordination
required for such capabilities:
- The LDP speaker that initiates the state change for such a
capability MUST include an acknowledgement request with the
Capability Object in the Capability message to its peer, and the
peer receiving a Capability message for a change that includes an
acknowledgement request MUST acknowledge receipt of the
capability state change by means of a Capability message.
- For the LDP speaker initiating the capability change the change
for generating messages related to the capability takes effect
immediately after the Capability message is sent, and the change
for processing received messages takes effect immediately after
an acknowledgement is received from its peer.
- For the peer receiving the capability change announcement the
change for processing received messages takes effect immediately
after the capability change is received and the change for
generating messages takes effect immediately after the
Aggarwal, et al. [Page 9]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
acknowledgement is sent.
Not every capability requires the type of synchronization the
acknowledgement mechanism provides. Furthermore, the announcement of
a capability in an Initialization message does not require it since
no messages other than those required to establish the session are
permitted until the session is fully established.
It is the responsibility of the capability designer to specify
whether the capability requires the acknowledgement mechanism when it
is announced by means of a Capability message.
9. Extensions to Error Handling
This document defines a new LDP status code named Unsupported
Capability. The S bit of the Status TLV carried in a Notification
message that includes this status code SHOULD be set to 0.
In addition, this document defines a new LDP TLV named Returned TLV
that MAY be carried in a Notification message. The U- bit and F bit
settings for the Returned TLV in a Notification message is TBD and
will be specified when the Returned TLV is fully specified.
When the Status Code in a Notification message is Unsupported
Capability the message SHOULD specify the capabilities that are
unsupported. When the Notification message specifies the unsupported
capabilities it MUST specify them as a Capability List TLV included
in a Returned TLV, the Capability List TLV MUST include only the
capabilities not supported, and each capability MUST be encoded in
the way it would be in an Initialization TLV.
When the Status Code in a Notification Message is Unknown TLV the
message SHOULD specify the TLV that was unknown. When the
Notification message specifies the TLV that was unknown it MUST
include the unknown TLV in a Returned TLV.
10. Backward Compatibility
From the point of view of the LDP capability advertisement mechanism
an RFC3036 compliant peer has label distribution for IPv4 enabled by
default. To ensure compatibility with an RFC3036 compliant peer LDP
implementations that support capability advertisement have label
distribution for IPv4 enabled until it is explicitly disabled and
MUST assume that their peers do as well.
Existing LDP enhancements that use an ad hoc mechanism for activation
Aggarwal, et al. [Page 10]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
(e.g., [RFC3478] [RFC3479]) MAY continue to do so.
11. Security Considerations
The security considerations described in [RFC3036] that apply to the
base LDP specification apply to the capability mechanism described in
this document.
12. IANA Considerations
This document creates a new LDP capability name space for the
Capability codes contained in the Capability List TLV. The LDP
capability name space is to be managed by IANA.
- Capability Code value 0 is reserved.
- Capability Code value 1 is assigned to the Dynamic Announcement
capability defined in this document.
- Capability Code values 2 through 1023 are to be assigned by
IANA using the "IETF Consensus" policy defined in RFC 2434.
- Capability Code values 1024 through 2047 are to be assigned by
IANA, using the "First Come First Served" policy defined in RFC
2434.
- Capability Code values 2048 through 4095 are for "Private Use"
as defined in RFC 2434.
This document specifies the following which require code points
assigned by IANA:
- New LDP Capability message. The authors request message type
0x202 for the Capability message.
- New LDP Capability List TLV type. The authors request TLV type
0x505 for the Capability List TLV.
- New LDP Returned TLV TLV type. The authors request TLV type
0x506.
- New LDP Unsupported Capability Status Code.
Aggarwal, et al. [Page 11]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
13. Acknowledgements
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
Yakov Rekhter, and Eric Rosen for their comments.
14. References
Normative References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
Thomas, B., "LDP Specification", RFC 3036, January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
Informative References
[RFC3392] Chandra, R. and Scudder, J., "Capabilities Advertisement
with BGP-4", November 2002
[BGP-DYNCAP] Chen, E., Sanglii, S., "Dynamic Capabilities for BGP-4",
draft-ietf-idr-dynamic-cap-08.txt, Work in Progress, June 2006
[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-01.txt, Work in
Progress, October 2005
[MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol
Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00.txt, Work in
Progress, September 2005
[NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop
Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in Progress,
May 2005
[PWE] Martini L. Editor. "Pseudowire Setup and Maintenance using the
Label Distribution Protocol", draft-ietf-pwe3-control-protocol-
17.txt, Work in Progress, June 2005
[RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart
Mechanism for Label Distribution Protocol (LDP)", RFC 3478, February
2003.
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label
Distribution Protocol (LDP)", RFC 3479, February 2003.
Aggarwal, et al. [Page 12]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
[UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label
Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work in
Progress, February 2006.
15. Author Information
Shivani Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: shivani@juniper.net
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
E-mail: jeanlouis.leroux@orange_ft.com
Bob Thomas
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough MA 01719
E-mail: rhthomas@cisco.com
16. 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
Aggarwal, et al. [Page 13]
Internet Draft draft-thomas-mpls-ldp-capabilities-01.txt October 2006
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.
17. Full Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
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 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.
Aggarwal, et al. [Page 14]