Internet DRAFT - draft-shivani-mpls-ldp-capability
draft-shivani-mpls-ldp-capability
Network Working Group S. Aggarwal
Internet Draft Juniper Networks
Expiration Date: December 2006
R. Aggarwal
Juniper Networks
J. L. Le Roux
France Telecom
June 2006
Capabilities Advertisement with LDP
draft-shivani-mpls-ldp-capability-00.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.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Shivani, Raggarwa & Le Roux [Page 1]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
Abstract
This document defines a new Optional Parameter, called Capabilities
TLV, that is expected to facilitate the introduction of new
capabilities in the Label Distribution Protocol (LDP) by providing
graceful capability advertisement without requiring that LDP peering
be terminated.
The "LDP peering" in this document refers to the TCP connection
between the 2 routers and not the actual session. The "LDP session"
refers to the connection after the initialization message has been
successfully processed and the session is marked operational.
Table of Contents
1 Specification of requirements ......................... 2
2 Overview of Operations ................................ 3
3 Capabilities TLV ...................................... 4
4 Extensions to Error Handling .......................... 5
5 IANA Considerations ................................... 6
6 Security Considerations ............................... 6
7 Acknowledgements ...................................... 6
8 References ............................................ 6
9 Author Information .................................... 7
10 Intellectual Property Statement ....................... 7
11 Full Copyright Statement .............................. 8
1. Specification of requirements
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].
Shivani, Raggarwa & Le Roux [Page 2]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
2. Overview of Operations
When a LDP speaker that supports capabilities advertisement sends an
INITIALIZATION message to its LDP peer, the message MAY include an
Optional Parameter, called Capabilities TLV. The parameter lists the
capabilities supported by the speaker.
A LDP speaker determines the capabilities supported by its peer by
examining the list of capabilities present in the Capabilities TLV
Optional Parameter carried by the INITIALIZATION message that the
speaker receives from the peer.
A LDP speaker that supports a particular capability may use this
capability with its peer after the speaker determines (as described
above) that the peer supports this capability.
A LDP speaker determines that its peer doesn't support capabilities
advertisement, if in response to an INITIALIZATION message that
carries the Capabilities TLV Optional Parameter, the speaker receives
a NOTIFICATION message with the Status Code of the Status TLV set to
Unknown TLV. This assumes that the speaker knows which TLV was
considered as an Unknown TLV by its peer. In this case, the speaker
SHOULD attempt to re-establish a LDP connection with the peer
without sending to the peer the Capabilities TLV Optional Parameter.
If a LDP speaker that supports a certain capability determines that
its peer doesn't support this capability, the speaker MAY send a
NOTIFICATION message to the peer, and terminate peering (see Section
"Extensions to Error Handling" for more details). The Status Code in
the Status TLV of the NOTIFICATION message is set to Unsupported
Capability. The message SHOULD contain the capability (capabilities)
that caused the speaker to send the message. The decision to send the
message and terminate peering is local to the speaker. If terminated,
such peering SHOULD NOT be re-established automatically. How the
session is re-established is beyond the scope of this document. It
is dependent on the capability and MUST be specified along with the
procedures specifying the LDP capability.
These procedures enable a LDP speaker A, that supports the LDP
Capabilities TLV to establish a LDP session with a LDP speaker B,
that does not support the LDP Capabilities TLV. However the
capabilities that LDP speaker A advertises in the Capabilities TLV,
can not be used between LDP speakers A and B, in this case.
These procedures also enable a LDP speaker C, that supports a
specific LDP capability, to establish a LDP session with a LDP
speaker D, that does not support this specific capability, though LDP
speaker D may support the LDP Capabilities TLV. However this specific
capability supported by LDP speaker C, can not be used between LDP
Shivani, Raggarwa & Le Roux [Page 3]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
speakers C and D in this case.
Further these procedures provide the choice to LDP speakers A and C
to terminate the LDP session with LDP speakers B and D respectively.
Whether LDP speakers A and C decide to do this or not is dependent on
the LDP capability that is not supported by LDP speakers B and D and
MUST be specified along with the procedures specifying the LDP
capability.
3. Capabilities TLV
This is an Optional Parameter that is used by a LDP speaker to convey
to its LDP peer the list of capabilities supported by the speaker.
This new optional paramter is called the Capabilities TLV and it
contains one or more sub-TLVs, each to signal a specific capability.
Following is the format of the LDP Capability TLV:
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 TLV (0x0504) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : To be assigned by IANA. Suggested value is 0x0504
Length: Variable
Each capability sub-TLV is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Capability Code | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Value (variable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use and meaning of these fields are as follows:
Capability Code:
Capability Code is a two octets field that unambiguously
identifies individual capabilities. Capability codes are to be
assigned by IANA.
Shivani, Raggarwa & Le Roux [Page 4]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
Capability Length:
Capability Length is a two octets field that contains the length
of the Capability Value field in octets.
Capability Value:
Capability Value is a variable length field that is interpreted
according to the value of the Capability Code field.
LDP speakers SHOULD NOT include more than one instance of a
capability with the same Capability Code, Capability Length, and
Capability Value. Note however, that processing of multiple
instances of such capability does not require special handling, as
additional instances do not change the meaning of announced
capability.
4. Extensions to Error Handling
This document defines new Status Code - Unsupported Capability. The
value of this Subcode is to be assigned by IANA. The 'E' bit of the
Status TLV in the NOTIFICATION message SHOULD be set to 0.
The NOTIFICATION message SHOULD list the set of capabilities that
caused the speaker to send the message.
For this purpose, a new Optional Parameter, Returned TLV is added to
the NOTIFICATION message. The value of this Optional Parameter,
Returned TLV, is to be assigned by IANA. The suggested value is
0x0505. The 'U' and 'F' bit of the Returned TLV in the
NOTIFICATION message is TBD and will be specified when the value
of the Returned TLV is defined.
If the Status Subcode is UNKNOWN TLV, the Returned TLV MUST contain
the Capability TLV that wasn't understood. If the Status Subcode is
Unsupported Capability, the Capability TLV MUST be encoded in the
Returned TLV Optional Paramter of the NOTIFICATION message with only
the capabilities that aren't supported. Each such capability is
encoded the same way as it would be encoded in the INITIALIZATION
Shivani, Raggarwa & Le Roux [Page 5]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
message.
5. IANA Considerations
This document defines a Capability TLV. We would like to request type
0x0504, to be assigned by IANA to this TLV. IANA maintains the
registry for Capability Code values. Capability Code value 0 is
reserved. Capability Code values 1 through 63 are to be assigned by
IANA using the "IETF Consensus" policy defined in RFC 2434.
Capability Code values 64 through 127 are to be assigned by IANA,
using the "First Come First Served" policy defined in RFC 2434.
Capability Code values 128 through 255 are for "Private Use" as
defined in RFC 2434.
This document also defines a Returned TLV and we would like to
request type 0x0505, to be assigned by IANA to this TLV.
This document defines new Status Code for the LDP Status TLV:
Unsupported Capability. The value of this subcode is to be assigned
by IANA.
6. Security Considerations
This extension to LDP does not change the underlying security issues
inherent in the existing LDP [RFC3036].
7. Acknowledgements
This extension to LDP is modelled after a similar extension to the
Border Gateway Protocol for capability advertisement [RFC3392].
Thanks to Ina Minei for her comments.
8. References
[RFC3036] L. Andersson, et. al., "LDP Specification", January 2001.
[RFC3392] R. Chandra, et. al., "Capabilities Advertisement with
BGP-4", November 2002
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
Shivani, Raggarwa & Le Roux [Page 6]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
9. 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@francetelecom.com
10. 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
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.
Shivani, Raggarwa & Le Roux [Page 7]
Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006
11. Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
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.
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.
Shivani, Raggarwa & Le Roux [Page 8]
