draft-ietf-mpls-ldp-capabilities-02.txt   draft-ietf-mpls-ldp-capabilities-03.txt 
Network Working Group Bob Thomas Network Working Group Bob Thomas
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: October 2008 Intended Status: Proposed Standard
Intended Status: Proposed Standard S. Aggarwal Expiration Date: September 05, 2009 S. Aggarwal
Juniper Networks Juniper Networks
R. Aggarwal R. Aggarwal
Juniper Networks Juniper Networks
J.L. Le Roux J.L. Le Roux
France Telecom France Telecom
Syed Kamran Raza
Cisco Systems, Inc.
March 06, 2009
LDP Capabilities LDP Capabilities
draft-ietf-mpls-ldp-capabilities-02.txt draft-ietf-mpls-ldp-capabilities-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance
applicable patent or other IPR claims of which he or she is aware with the provisions of BCP 78 and BCP 79. This document may
have been or will be disclosed, and any of which he or she becomes contain material from IETF Documents or IETF Contributions
aware will be disclosed, in accordance with Section 6 of BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute working
Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of
and may be updated, replaced, or obsoleted by other documents at any six months and may be updated, replaced, or obsoleted by
time. It is inappropriate to use Internet-Drafts as reference other documents at any time. It is inappropriate to use
material or to cite them other than as "work in progress." 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 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
http://www.ietf.org/shadow.html.
Copyright Notice The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Copyright (C) The IETF TRUST (2008). This Internet-Draft will expire on September 05, 2009.
Abstract Abstract
A number of enhancements to the Label Distribution Protocol (LDP) A number of enhancements to the Label Distribution Protocol (LDP)
have been proposed. Some have been implemented, and some are have been proposed. Some have been implemented, and some are
advancing toward standardization. It is likely that additional advancing toward standardization. It is likely that additional
enhancements will be proposed in the future. At present LDP has no enhancements will be proposed in the future. At present, LDP has no
guidelines for advertising such enhancements at LDP session mechanism for advertising such enhancements at LDP session
initialization time. There is also no mechanism to enable and initialization time. There is also no mechanism to enable and
disable enhancements after the session is established. This document disable enhancements after the session is established. This document
provides guidelines for advertising LDP enhancements at session defines a mechanism for advertising LDP enhancements at session
initialization time. It also defines a mechanism to enable and initialization time, as well as a mechanism to enable and disable
disable enhancements after LDP session establishment. enhancements after LDP session establishment.
Conventions used in this document
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].
This document uses the terms "LDP speaker" and "speaker"
interchangably.
Table of Contents Table of Contents
1 Introduction .................................................. 3 1. Introduction...................................................3
2 Specification Language ........................................ 3 2. The LDP Capability Mechanism...................................4
3 The LDP Capability Mechanism .................................. 3 2.1. Capability Document.......................................5
4 Specifying Capabilities in LDP Messages ....................... 5 3. Specifying Capabilities in LDP Messages........................5
5 Capability Message ............................................ 6 3.1. Backward Compatibility TLVs...............................7
6 Note on Terminology ........................................... 7 4. Capability Message.............................................7
7 Procedures for Capability Parameters in Initialization Messages 7 5. Note on Terminology............................................8
8 Procedures for Capability Parameters in Capability Messages ... 8 6. Procedures for Capability Parameters in Initialization Messages8
9 Extensions to Error Handling ................................. 9 7. Procedures for Capability Parameters in Capability Messages....9
10 Dynamic Capability Announcement TLV ......................... 9 8. Extensions to Error Handling..................................10
11 Backward Compatibility ...................................... 10 9. Dynamic Capability Announcement TLV...........................10
12 Security Considerations ..................................... 10 10. Backward Compatibility.......................................11
13 IANA Considerations ......................................... 10 11. Security Considerations......................................11
14 Acknowledgements ............................................ 11 12. IANA Considerations..........................................11
15 References .................................................. 11 13. Acknowledgments..............................................12
16 Author Information .......................................... 12 14. References...................................................12
17 Intellectual Property Statement ............................. 12 14.1. Normative References....................................12
18 Full Copyright Statement .................................... 13 14.2. Informative References..................................12
15. Author's Addresses...........................................13
1. Introduction 1. Introduction
A number of enhancements to LDP as specified in [RFC5036] have been A number of enhancements to LDP as specified in [RFC5036] have been
proposed. These include LDP Graceful Restart [RFC3478], Fault proposed. These include LDP Graceful Restart [RFC3478], Fault
Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
layer 2 circuits [RFC4447], a method for learning labels advertised layer 2 circuits [RFC4447], a method for learning labels advertised
by next next hop routers in support of fast reroute node protection by next-next-hop routers in support of fast reroute node protection
[NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
signaling inter-area LSPs [IALDP]. Some have been implemented, and signaling inter-area LSPs [IALDP]. Some have been implemented, and
some are advancing toward standardization. It is likely that some are advancing toward standardization. It is also likely that
additional enhancements will be proposed in the future. additional enhancements will be implemented and deployed in the
future.
At present LDP has no guidelines for advertising such enhancements at At present, LDP does not have a mechanism for advertising such
LDP session initialization time. There is also no mechanism to enhancements at LDP session initialization time. There is also no
enable and disable enhancements after the session is established. mechanism to enable and disable these enhancements after the session
is established.
This document provides guidelines for advertising LDP enhancements at This document proposes and defines a mechanism for advertising LDP
session initialization time. It also defines a mechanism to enable enhancements at session initialization time. It also defines a
and disable enhancements after LDP session establishment. mechanism to enable and disable these enhancements after LDP session
establishment.
LDP capability advertisement provides means for an LDP speaker to LDP capability advertisement provides means for an LDP speaker to
announce what it can receive and process. It also provides means for announce what it can receive and process. It also provides means for
a speaker to inform peers of deviations from behavior specified by a speaker to inform peers of deviations from behavior specified by
[RFC5036]. An example of such a deviation is LDP graceful restart [RFC5036]. An example of such a deviation is LDP graceful restart
where a speaker retains MPLS forwarding state for LDP-signaled LSPs where a speaker retains MPLS forwarding state for LDP-signaled LSPs
when its LDP control plane goes down. It is important to point out when its LDP control plane goes down. It is important to point out
that not all LDP enhancements require capability advertisement. For that not all LDP enhancements require capability advertisement. For
example, upstream label allocation does but inbound label filtering, example, upstream label allocation does but inbound label filtering,
where a speaker installs forwarding state for only certain FECs, does where a speaker installs forwarding state for only certain FECs, does
not. not.
2. Specification Language 2. The LDP Capability Mechanism
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 Enhancements are likely to be announced during LDP session
establishment as each LDP speaker advertises capabilities establishment as each LDP speaker advertises capabilities
corresponding to the enhancements it desires. corresponding to the enhancements it desires.
Beyond that, capability advertisements may be used to dynamically Beyond that, capability advertisements may be used to dynamically
modify the characteristics of the session to suit changing modify the characteristics of the session to suit the changing
conditions. For example, an LSR capable of a particular enhancement conditions. For example, an LSR capable of a particular enhancement
in support of some "feature" may not have advertised the in support of some "feature" may not have advertised the
corresponding capability to its peers at session establishment time corresponding capability to its peers at session establishment time
because the feature was disabled at that time. Later an operator may because the feature was disabled at that time. Later, an operator
enable the feature, at which time the LSR would react by advertising may enable the feature, at which time the LSR would react by
the corresponding capability to its peers. Similarly, when an advertising the corresponding capability to its peers. Similarly,
operator disables a feature associated with a capability the LSR when an operator disables a feature associated with a capability, the
reacts by withdrawing the capability advertisement from its peers. LSR reacts by withdrawing the capability advertisement from its
peers.
The LDP capability advertisement mechanism operates as follows: The LDP capability advertisement mechanism operates as follows:
- Each LDP speaker is assumed to implement a set of enhancements - Each LDP speaker is assumed to implement a set of enhancements,
each of which has an associated capability. At any time a each of which has an associated capability. At any time, a
speaker may have none, one or more of those enhancements speaker may have none, one, or more of those enhancements
"enabled". When an enhancement is enabled the speaker advertises "enabled". When an enhancement is enabled, the speaker
the associated capability to its peers. By advertising the advertises the associated capability to its peers. By
capability to a peer the speaker asserts that it shall perform advertising the capability to a peer, the speaker asserts that it
the protocol actions specified for the associated enhancement. shall perform the protocol actions specified for the associated
For example, the actions may involve receiving and processing enhancement. For example, the actions may require the LDP speaker
messages from a peer that the enhancement requires. Unless the to receive and process enhancement-specific messages from its
capability has been advertised the speaker will not perform peer. Unless the capability has been advertised, the speaker will
protocol actions specified for the corresponding enhancement. not perform protocol actions specified for the corresponding
enhancement.
- At session establishment time an LDP speaker MAY advertise a - At session establishment time an LDP speaker MAY advertise a
particular capability by including an optional parameter particular capability by including an optional parameter
associated with the capability in its Initialization message. associated with the capability in its Initialization message.
- There is a well-known capability called Dynamic Capability - There is a well-known capability called "Dynamic Capability
Announcement which an LDP speaker MAY advertise in its Announcement" which an LDP speaker MAY advertise in its
Initialization message to indicate that it is capable of Initialization message to indicate that it is capable of
processing capability announcements following session processing capability announcements following a session
establishment. establishment.
If a peer had advertised the Dynamic Capability Announcement If a peer had advertised the "Dynamic Capability Announcement"
capability in its Initialization message then at any time capability in its Initialization message, then at any time
following session establishment an LDP speaker MAY announce following session establishment an LDP speaker MAY announce
changes in its advertised capabilities to that peer. To do this changes in its advertised capabilities to that peer. To do this,
the LDP speaker sends the peer a Capability message that the LDP speaker sends the peer a "Capability" message that
specifies the capabilities being advertised or withdrawn. specifies the capabilities being advertised or withdrawn.
When the capability advertisement mechanism is in place an LDP 2.1. Capability Document
When the capability advertisement mechanism is in place, an LDP
enhancement requiring LDP capability advertisement will be specified enhancement requiring LDP capability advertisement will be specified
by a document that: by a document that:
- Describes the motivation for the enhancement; - Describes the motivation for the enhancement;
- Specifies the behavior of LDP when the enhancement is enabled. - Specifies the behavior of LDP when the enhancement is enabled.
This includes the procedures, parameters, messages, and TLVs This includes the procedures, parameters, messages, and TLVs
required by the enhancement; required by the enhancement;
- Includes an IANA considerations section that notes that an IANA- - Includes an IANA considerations section that requests IANA for
assigned code point for the optional parameter corresponding to assignment of code point for the optional parameter corresponding
the enhancement is required. to the enhancement.
4. Specifying Capabilities in LDP Messages 3. Specifying Capabilities in LDP Messages
This document uses the term "Capability Parameter" to refer to an This document uses the term "Capability Parameter" to refer to an
optional parameter that may be included in Initialization and optional parameter that may be included in Initialization and
Capability messages to advertise a capability. Capability messages to advertise a capability.
The format of a TLV that is a Capability Parameter is: The format of "Capability Parameter" TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point | Length | |U|F| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | | |S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data | +-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
U-bit U-bit:
SHOULD be 1 (ignore if not understood). The value could be either 0 or 1 as specified in Capability
document associated with given capability.
F-bit: F-bit:
SHOULD be 0 (don't forward if not understood). MUST be 0 (i.e. don't forward if not understood).
TLV Code Point: TLV Code Point:
The TLV type, which identifies a specific capability. The "IANA The TLV type which identifies a specific capability. The "IANA
Considerations" section of [RFC5036] specifies the assignment of Considerations" section of [RFC5036] specifies the assignment of
code points for LDP TLVs. code points for LDP TLVs.
S-bit: S-bit:
The State Bit indicates whether the sender is advertising or The State Bit indicates whether the sender is advertising or
withdrawing the capability corresponding to the TLV Code Point. withdrawing the capability corresponding to the TLV Code Point.
The State bit is used as follows: The State bit is used as follows:
1 - The TLV is advertising the capability specified by the 1 - The TLV is advertising the capability specified by the
TLV Code Point. TLV Code Point.
skipping to change at page 6, line 4 skipping to change at page 6, line 28
Considerations" section of [RFC5036] specifies the assignment of Considerations" section of [RFC5036] specifies the assignment of
code points for LDP TLVs. code points for LDP TLVs.
S-bit: S-bit:
The State Bit indicates whether the sender is advertising or The State Bit indicates whether the sender is advertising or
withdrawing the capability corresponding to the TLV Code Point. withdrawing the capability corresponding to the TLV Code Point.
The State bit is used as follows: The State bit is used as follows:
1 - The TLV is advertising the capability specified by the 1 - The TLV is advertising the capability specified by the
TLV Code Point. TLV Code Point.
0 - The TLV is withdrawing the capability specified by the 0 - The TLV is withdrawing the capability specified by the
TLV Code Point. TLV Code Point.
Capability Data: Capability Data:
Information, if any, about the capability in addition to the TLV Information, if any, about the capability in addition to the TLV
Code Point required to fully specify the capability. Code Point required to fully specify the capability.
The method for interpreting and processing this data is specific
to the TLV Code Point and MUST be described in the document
specifying the capability.
An LDP speaker MAY include more than one instance of a Capability An LDP speaker MUST NOT include more than one instance of a
Parameter (as identified by the TLV Code Point) with different non- Capability Parameter (as identified by the same TLV code point) in an
empty Capability Data in an Initialization or Capability message. Initialization or Capability message. If an LDP speaker receives more
The method for processing such Capability Parameters is specific to than one instance of the same Capability Parameter type in a message,
the TLV Code Point and MUST be described in the document specifying it SHOULD send a Notification message to peer before terminating the
the capability. session with peer. The Status Code in the Status TLV of the
Notification message MUST be "Malformed TLV" and the message SHOULD
To ensure backward compatibility with existing implementations the contain the second "Capability Parameter TLV" of the same type (Code
following TLVs play the role of a Capability Parameter when included point) that is received in the message.
in Initialization messages:
- FT Session TLV [RFC3479] 3.1. Backward Compatibility TLVs
This document refers to such TLVs as Backward Compatibility TLVs. Few LDP protocol extensions have been made in past to advertise and
negotiate some capability or extension at session establishment time.
These extensions usually define a new TLV which is directly included
in an Initialization message. One example of such extension is "FT
Session TLV" which is exchanged in Initialization message between
peers to announce LDP Fault Tolerance [RFC3479] capability. To
ensure backward compatibility with existing implementations, such
TLVs play the role of a "Capability Parameter" when included in
Initialization messages, and this document refers to such TLVs as
"Backward Compatibility TLVs".
5. Capability Message 4. Capability Message
The LDP Capability message is used by an LDP speaker subsequent to The LDP Capability message is used by an LDP speaker to announce
session establishment to announce changes in the state for one or changes in the state of one or more of its capabilities subsequent to
more of its capabilities. session establishment.
The format of the Capability message is: The format of the Capability message is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Capability (IANA) | Length | |0| Capability (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_1 | | TLV_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_N | | TLV_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where TLV_1 through TLV_N are Capability Parameters. The S-bit of where TLV_1 through TLV_N are "Capability Parameter" TLVs. The S-bit
each of the TLVs specifies the new state for the corresponding of each of the TLVs specifies the new state for the corresponding
capability. capability.
Note that Backward Compatibility TLVs (see Section 4) MUST NOT be Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be
included in Capability messages. included in Capability messages.
6. Note on Terminology 5. 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 associated with an
enhancement". 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.
7. Procedures for Capability Parameters in Initialization Messages The following sections in this document talk about enabling and
disabling capabilities. The terminology "enabling (or disabling) a
capability" is short hand for "advertising (or withdrawing) a
capability associated with an enhancement". Bear in mind that it is
an LDP enhancement that is being enabled or disabled, and that it is
the corresponding capability that is being advertisted or withdrawn.
An LDP speaker SHOULD NOT include more than one instance of a 6. Procedures for Capability Parameters in Initialization Messages
Capability Parameter with the same type and value in an
Initialization message. Note, however, that processing multiple
instances of such a parameter does not require special handling, as
additional instances do not change the meaning of an announced
capability.
The S-bit of a Capability Parameter in an Initialization message MUST The S-bit of a Capability Parameter in an Initialization message MUST
be 1 and SHOULD be ignored on receipt. This ensures that any be 1 and SHOULD be ignored on receipt. This ensures that any
Capability Parameter in an Initialization message enables the Capability Parameter in an Initialization message enables the
corresponding capability. corresponding capability.
An LDP speaker determines the capabilities enabled by a peer by An LDP speaker determines the capabilities of a peer by examining the
examining the set of of Capability Parameters present in the set of of Capability Parameters present in the Initialization message
Initialization message received from the peer. received from the peer.
An LDP speaker MAY use a particular capability with its peer after An LDP speaker MAY use a particular capability with its peer after
the speaker determines that the peer has enabled that capability. the speaker determines that the peer has enabled that capability.
These procedures enable an LDP speaker A that advertises a specific These procedures enable an LDP speaker S1, that advertises a specific
LDP capability C to establish an LDP session with speaker B that does LDP capability C, to establish an LDP session with speaker S2 that
not advertise C. In this situation whether or not capability C may does not advertise C. In this situation whether or not capability C
be used for the session depends on the semantics of the enhancement may be used for the session depends on the semantics of the
associated with C. If the semantics do not require both A and B enhancement associated with C. If the semantics do not require both
advertise C to one another then B could use it; that is, A's S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's
advertisement of C permits B to send messages to A used by the advertisement of C permits S2 to send messages to S1 used by the
enhancement. enhancement.
It is the responsibility of the capability designer to specify the It is the responsibility of the capability designer to specify the
behavior of an LDP speaker that has enabled a certain enhancement, behavior of an LDP speaker that has enabled a certain enhancement,
advertised its capability and determines that its peer has not advertised its capability and determines that its peer has not
advertised the corresponding capability. The document specifying advertised the corresponding capability. The document specifying
procedures for the capability MUST describe the behavior in this procedures for the capability MUST describe the behavior in this
situation. If the specified procedure is to terminate the session situation. If the specified procedure is to terminate the session,
the LDP speaker SHOULD send a Notification message to the peer before then the LDP speaker SHOULD send a Notification message to the peer
terminating the session. The Status Code in the Status TLV of the before terminating the session. The Status Code in the Status TLV of
Notification message SHOULD be Unsupported Capability, and the the Notification message MUST be "Unsupported Capability" and the
message SHOULD contain the unsupported capabilities (see Section 9 message SHOULD contain the unsupported capability (see Section 8 for
for more details). In this case the session SHOULD NOT be re- more details).
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 An LDP speaker that supports capability advertisement and includes a
Capability Parameter in its Initialization message SHOULD set the TLV Capability Parameter in its Initialization message MUST set the TLV
U bit to 1. This ensures that an [RFC5036] compliant peer that does U-bit to 0 or 1, as specified by "Capability" document. LDP speaker
not support the capability mechanism will ignore the Capability should set U-bit to 1 if the capability document allows to continue
Parameter and allow the session to be established. with a peer that does not understand the enhancement, and set U-bit
to 0 otherwise. If a speaker receives a message containng unsupported
capability, it responds according to U-bit setting in the TLV. If U-
bit is 1, then speaker MUST silently ignore the Capability Parameter
and allow the session to be established. However, if U-bit is 0, then
speaker SHOULD send a Notification message to the peer before
terminating the session. The Status Code in the Status TLV of the
Notification message MUST be "Unsupported Capability" and the
message SHOULD contain the unsupported capability (see Section 8 for
more details).
8. Procedures for Capability Parameters in Capability Messages 7. Procedures for Capability Parameters in Capability Messages
An LDP speaker MUST NOT send a Capability message to a peer unless An LDP speaker MUST NOT send a Capability message to a peer unless
its peer had advertised the Dynamic Capability Announcement its peer had advertised the Dynamic Capability Announcement
capability in its session Initialization message (see Section 10). capability in its session Initialization message. An LDP speaker MAY
send a Capability message to a peer if its peer had advertised the
An LDP speaker MAY send a Capability message to a peer if its peer Dynamic Capability Announcement capability in its session
had advertised the Dynamic Capability Announcement capability in its Initialization message (see Section 9).
session Initialization message (see Section 10).
An LDP speaker determines the capabilities enabled by a peer by An LDP speaker determines the capabilities enabled by a peer by
determining the set of capabilities enabled at session initialization determining the set of capabilities enabled at session initialization
(as specified in Section 7) and tracking changes to that set made by (as specified in Section 6) and tracking changes to that set made
Capability messages from the peer. by Capability messages from the peer.
An LDP speaker that has enabled a particular capability MAY use the An LDP speaker that has enabled a particular capability MAY use the
enhancement corresponding to the capability with a peer after the enhancement corresponding to the capability with a peer after the
speaker determines that the peer has enabled the capability. speaker determines that the peer has enabled the capability.
9. Extensions to Error Handling 8. Extensions to Error Handling
This document defines a new LDP status code named Unsupported This document defines a new LDP status code named "Unsupported
Capability. The E bit of the Status TLV carried in a Notification Capability". The E-bit of the Status TLV carried in a Notification
message that includes this status code SHOULD be set to 0. message that includes this status code MUST be set to 0.
In addition, this document defines a new LDP TLV named Returned TLVs In addition, this document defines a new LDP TLV, named "Returned
TLV that MAY be carried in a Notification message. The U-bit setting TLVs" that MAY be carried in a Notification message. The U-bit
for a Returned TLVs TLV in a Notification message SHOULD be 1 and the setting for a Returned TLVs TLV in a Notification message SHOULD be 1
F-bit setting SHOULD be 0. and the F-bit setting SHOULD be 0.
When the Status Code in a Notification message is Unsupported When the Status Code in a Notification message is "Unsupported
Capability the message SHOULD specify the capabilities that are Capability", the message SHOULD specify the capabilities that are
unsupported. When the Notification message specifies the unsupported unsupported. When the Notification message specifies the unsupported
capabilities it MUST include a Returned TLVs TLV which includes each capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs
unsupported Capability Parameter. The Returned TLVs TLV MUST include TLV MUST include only the Capability Parameters for unsupported
only the Capability Parameters for unsupported capabilities. In capabilities, and the Capability Parameter for each such capability
addition, the Capability Parameter for each such capability SHOULD be SHOULD be encoded as received from the peer.
encoded as received from the peer.
When the Status Code in a Notification Message is Unknown TLV the When the Status Code in a Notification Message is "Unknown TLV", the
message SHOULD specify the TLV that was unknown. When the message SHOULD specify the TLV that was unknown. When the
Notification message specifies the TLV that was unknown it MUST Notification message specifies the TLV that was unknown, it MUST
include the unknown TLV in a Returned TLVs TLV. include the unknown TLV in a Returned TLVs TLV.
10. Dynamic Capability Announcement TLV 9. Dynamic Capability Announcement TLV
The Dynamic Capability Announcement TLV is a Capability Parameter. The Dynamic Capability Announcement TLV is a Capability Parameter
Its format is: defined by this document with 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| DynCap Announcement (IANA)| Length | |1|0| DynCap Announcement (IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |1| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The Dynamic Capability Announcement Parameter MAY be included by an The Dynamic Capability Announcement Parameter MAY be included by an
LDP speaker in an Initialization message to signal its peer that the LDP speaker in an Initialization message to signal its peer that the
speaker is capable of processing Capability messages. speaker is capable of processing Capability messages.
An LDP speaker MUST NOT include the Dynamic Capability Announcement An LDP speaker MUST NOT include the Dynamic Capability Announcement
Parameter in Capability messages sent to its peers. Once enabled Parameter in Capability messages sent to its peers. Once enabled
during session initialization the Dynamic Capability Announcement during session initialization, the Dynamic Capability Announcement
capability cannot be disabled. capability cannot be disabled. This implies that S-bit is always 1
for Dynamic Capability Announcement.
An LDP speaker that receives a Capability message from a peer that An LDP speaker that receives a Capability message from a peer that
includes the Dynamic Capability Announcement Parameter SHOULD includes the Dynamic Capability Announcement Parameter SHOULD
silently ignore the parameter and process any other Capability silently ignore the parameter and process any other Capability
Parameters in the message. Parameters in the message.
11. Backward Compatibility 10. Backward Compatibility
From the point of view of the LDP capability advertisement mechanism From the point of view of the LDP capability advertisement mechanism,
an [RFC5036] compliant peer has label distribution for IPv4 enabled an [RFC5036] compliant peer has label distribution for IPv4 enabled
by default. To ensure compatibility with an [RFC5036] compliant peer by default. To ensure compatibility with an [RFC5036] compliant
LDP implementations that support capability advertisement have label peer, LDP implementations that support capability advertisement have
distribution for IPv4 enabled until it is explicitly disabled and label distribution for IPv4 enabled until it is explicitly disabled
MUST assume that their peers do as well. and MUST assume that their peers do as well.
Section 3 identifies a set of Backward Compatibility TLVs that may Section 3.1 identifies a set of Backward Compatibility TLVs that
appear in Initialization messages in the role of a Capability may appear in Initialization messages in the role of a Capability
Parameter. This permits existing LDP enhancements that use an ad hoc Parameter. This permits existing LDP enhancements that use an ad hoc
mechanism for enabling capabilities at sesssion initialization time mechanism for enabling capabilities at sesssion initialization time
to continue to do so. to continue to do so.
12. Security Considerations 11. Security Considerations
The security considerations described in [RFC5036] that apply to the The security considerations described in [RFC5036] that apply to the
base LDP specification apply to the capability mechanism described in base LDP specification apply to the capability mechanism described in
this document. this document.
13. IANA Considerations 12. IANA Considerations
This document specifies the following which require code points This document specifies the following which require code points
assigned by IANA: assigned by IANA:
- LDP message code point for the Capability message. The authors - LDP message code point for the Capability message. The authors
request message type 0x0202 for the Capability message. request message type 0x0202 for the Capability message.
- LDP TLV code point for the Dynamic Capability Announcemnt TLV. - LDP TLV code point for the Dynamic Capability Announcemnt TLV.
The authors request TLV type code 0x0506. The authors request TLV type code 0x0506.
- LDP TLV code point for the Returned TLVs TLV. The authors - LDP TLV code point for the Returned TLVs TLV. The authors
request TLV type 0x304. request TLV type 0x304.
- LDP Status Code code point for the Unsupported Capability - LDP Status Code code point for the Unsupported Capability Status
Status Code. The authors request Status Code 0x0000002C. Code. The authors request Status Code 0x0000002C.
14. Acknowledgements 13. Acknowledgments
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
Yakov Rekhter, and Eric Rosen for their comments. Yakov Rekhter, and Eric Rosen for their comments.
15. References This document was prepared using 2-Word-v2.0.template.dot.
Normative References 14. References
14.1. Normative References
[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
Specification", RFC 5036, September 2007. Specification", RFC 5036, September 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label
Distribution Protocol (LDP)", RFC 3479, February 2003. Distribution Protocol (LDP)", RFC 3479, February 2003.
Informative References 14.2. Informative References
[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, Work in Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt,
[MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution
Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Protocol Extensions for Point-to-Multipoint and Multipoint-
Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00.txt, Work in to-Multipoint Label Switched Paths", draft-minei-wijnands-
Progress, September 2005 mpls-ldp-p2mp-00.txt, Work in Progress, September 2005
[NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop [NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop
Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in Progress, Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in
[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron,
"Pseudowire Setup and Maintenance using the Label Distribution "Pseudowire Setup and Maintenance using the Label
Protocol", RFC 4447, April 2006. Distribution Protocol", RFC 4447, April 2006.
[RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart
Mechanism for Label Distribution Protocol (LDP)", RFC 3478, February Mechanism for Label Distribution Protocol (LDP)", RFC 3478,
2003. February 2003.
[UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label
Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work in Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt,
Progress, February 2006. Work in Progress, February 2006.
16. Author Information 15. Author's Addresses
Bob Thomas
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
E-mail: rhthomas@cisco.com
Shivani Aggarwal Shivani Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: shivani@juniper.net Email: shivani@juniper.net
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, Avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex, France
France E-mail: jeanlouis.leroux@orange-ftgroup.com
E-mail: jeanlouis.leroux@orange_ftgroup.com
Bob Thomas Syed Kamran Raza
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 2000 Innovation Dr.
Boxborough MA 01719 Kanata, ON K2K-3E8, Canada
E-mail: rhthomas@cisco.com E-mail: skraza@cisco.com
17. 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
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 Copyright Notice
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.
18. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. All rights reserved.
Copyright (C) The IETF Trust (2008). This document is subject to BCP 78 and the IETF Trust's
Legal Provisions Relating to IETF Documents in effect on the
date of publication of this document
(http://trustee.ietf.org/license-info). Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document.
This document is subject to the rights, licenses and restrictions Legal
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This documents and the information contained therein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
PURPOSE. FOR A PARTICULAR PURPOSE.
 End of changes. 88 change blocks. 
250 lines changed or deleted 273 lines changed or added

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