Network Working Group B. Thomas Request for Comments: 5038 Cisco Systems, Inc. Category: Informational L. Andersson Acreo AB October 2007
The Label Distribution Protocol (LDP) Implementation Survey Results
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract
Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard.
Table of Contents
1. Introduction ....................................................2 1.1. The LDP Survey Form ........................................2 1.2. LDP Survey Highlights ......................................3 2. Survey Results for LDP Features .................................4 3. Security Considerations .........................................7 4. References ......................................................7 Appendix A. Full LDP Survey Results ................................8 Appendix B. LDP Implementation Survey Form ........................13
Thomas & Andersson Informational [Page 1]
RFC 5038 LDP Implementation Survey Results October 2007
Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short fixed-length values carried by packets, called labels, to determine packet next hops [RFC3031]. A fundamental MPLS concept is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures by which one LSR informs another of label bindings it has made.
Label Distribution Protocol (LDP) specifies a set of procedures LSRs use to distribute labels to support MPLS forwarding along normally routed paths. LDP was specified originally by [RFC3036]. The current LDP specification is [RFC5036], which obsoletes [RFC3036]. [RFC3037] describes the applicability of LDP.
This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft standard.
This section highlights some of the survey results. Section 2 presents the survey results for LDP features, and Appendix A presents the survey results in full. Appendix B contains a copy of the survey form.
The LDP implementation survey requested the following information about LDP implementation:
- Responding organization. Provisions were made to accommodate organizations that wished to respond anonymously.
- The status, availability, and origin of the LDP implementation.
- The LDP features implemented and for each whether it was tested against an independent implementation. The survey form listed each LDP feature defined by [RFC3036] and requested one of the following as the status of the feature:
t: Tested against another independent implementation y: Implemented but not tested against independent implementation n: Not implemented x: Not applicable to this type of implementation
Thomas & Andersson Informational [Page 2]
RFC 5038 LDP Implementation Survey Results October 2007
In addition, for the 'n' status, the responder could optionally provide the following additional information:
s: RFC specification inadequate, unclear, or confusing u: Utility of feature unclear r: Feature not required for feature set implemented
This document uses the following conventions for reporting survey results for a feature:
At By Cn indicates:
- A responders implemented the feature and tested it against another independent implementation (t) - B responders implemented the feature but have not tested it against an independent implemented (y) - C responders did not implement the feature (n)
(Ds Eu Fr) indicates optional responses:
- D responders thought the RFC 3036 specification of the feature inadequate, unclear, or confusing (s). - E responders thought the utility of the feature unclear (u). - F responders considered the feature not required for the feature set implemented (combines x and r).
This section presents some highlights from the implementation survey.
- There were 12 responses to the survey, 2 of which were anonymous. At the time of the survey, 10 of the implementation were available as products and 2 were in beta test. Eleven of the implementations were available for sale; the remaining implementation had been done by a company no longer in business.
- Seven implementations were independently written from the RFC 3036 specification. Four implementations combined purchased or free code with code written by the responder.
One of the implementations was fully purchased code ported to the vendor's platform.
- Every LDP feature in the survey questionnaire was implemented by at least 2 respondents.
Thomas & Andersson Informational [Page 3]
RFC 5038 LDP Implementation Survey Results October 2007
- Each of the 8 LDP Label Distribution Modes implemented and tested:
8t 2y 2n DU, Ord Cntl, Lib reten 7t 1y 4n DU, Ind Cntl, Lib reten 7t 1y 4n DoD Ord Cntl, Cons reten 6t 1y 5n DoD, Ind Cntl, Cons reten 6t 1y 5n DU, Ord Cntl, Cons reten 6t 0y 6n DU, Ind Cntl, Cons reten 4t 3y 5n DoD, Ord Cntl, Lib reten 4t 2y 6n DoD, Ind Cntl, Lib reten
- Platform and Interface Label Spaces were both widely supported.
12t 0y 0n Per platform 7t 1y 4n Per interface
- LDP Basic and Targeted Sessions were both widely supported.
This section presents the survey results for LDP features using the notational convention described in Section 1.2. It omits the optional status responses (s, u, r); complete results may be found in Appendix A.
This document is a survey of existing LDP implementations; it does not specify any protocol behavior. Thus, security issues introduced by the document are not discussed.
======================================================================= A. General Information
Responders:
Anonymous: 2 Public: 10
Agilent Technologies Celox Networks, Inc. Cisco Systems, Inc. Data Connection Ltd. NetPlane Systems, Inc Redback Networks Riverstone Networks Trillium, An Intel Company Vivace Networks, Inc. Wipro Technologies
Thomas & Andersson Informational [Page 8]
RFC 5038 LDP Implementation Survey Results October 2007
======================================================================= B. LDP Implementation Status, Availability, Origin
Status: [ ] Development [ ] Alpha [ 2] Beta [10] Product [ ] Other (describe):
Availability: [ ] Public and free [ ] Only to selected organizations/companies but free [11] On sale [ ] For internal company use only [ 1] Other:
Implementation based on: (check all that apply) [ 1] Purchased code (please list source if possible) [ ] Free code (please list source if possible) [ 7] Internal implementation (no outside code, just from specs) [ 4] Internal implementation on top of purchased or free code
Thomas & Andersson Informational [Page 9]
RFC 5038 LDP Implementation Survey Results October 2007
======================================================================= C. LDP Feature Survey
For each feature listed, please indicate the status of the implementation using one of the following:
't' tested against another independent implementation 'y' implemented but not tested against independent implementation 'n' not implemented 'x' not applicable to this type of implementation
Optional: For 'n' status, indicate reason for not implementing using one of the following:
's' RFC specification inadequate, unclear, or confusing 'u' utility of feature unclear 'r' feature not required for feature set implemented
The purpose of this form is to gather information about implementations of LDP as defined by RFC 3036. The information is being requested as part of the process of advancing LDP from Proposed to Draft Standard.
The form is patterned after the implementation report form used for HTTP/1.1; see:
Contact for LDP information Name: Title: E-mail: Organization/department: Postal address: Phone: Fax:
Thomas & Andersson Informational [Page 13]
RFC 5038 LDP Implementation Survey Results October 2007
======================================================================= B. LDP Implementation Status, Availability, Origin
Please check [x] the boxes that apply. ----------------------------------------------------------------
Status: [ ] Development [ ] Alpha [ ] Beta [ ] Product [ ] Other (describe):
Availability [ ] Public and free [ ] Only to selected organizations/companies but free [ ] On sale. [ ] For internal company use only [ ] Other:
Implementation based on: (check all that apply) [ ] Purchased code (please list source if possible) [ ] Free code (please list source if possible) [ ] Internal implementation (no outside code, just from specs) [ ] Internal implementation on top of purchased or free code List portions from external source: List portions developed internally:
Thomas & Andersson Informational [Page 14]
RFC 5038 LDP Implementation Survey Results October 2007
======================================================================= C. LDP Feature Survey
For each feature listed, please indicate the status of the implementation using one of the following:
't' tested against another independent implementation 'y' implemented but not tested against independent implementation 'n' not implemented '-' not applicable to this type of implementation
Optional: For 'n' status, indicate reason for not implementing using one of the following:
's' RFC specification inadequate, unclear, or confusing 'u' utility of feature unclear 'r' feature not required for feature set implemented
------------------+-----------------------------+----------------------- | | Status | | (one of t, y, n, -; | | if n, optionally Feature | RFC 3036 Section(s) | one of s, u, r) ==================+=============================+======================= Interface types | 2.2.1, 2.5.3, 2.8.2, 3.4.2 ----------------+-----------------------------+----------------------- Packet | | ----------------+-----------------------------+----------------------- Frame Relay | | ----------------+-----------------------------+----------------------- ATM | | ==================+=============================+======================= Label Spaces | 2.2.1, 2.2.2 ----------------+-----------------------------+----------------------- Per platform | | ----------------+-----------------------------+----------------------- Per interface | | ==================+=============================+======================= LDP Discovery | 2.4 ----------------+-----------------------------+----------------------- Basic | 2.4.1 | ----------------+-----------------------------+----------------------- Targeted | 2.4.2 |
Thomas & Andersson Informational [Page 15]
RFC 5038 LDP Implementation Survey Results October 2007
RFC 5038 LDP Implementation Survey Results October 2007
Author's Addresses
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough MA 01719
EMail: rhthomas@cisco.com
Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden
EMail: loa.andersson@acreo.se loa@pi.se
Thomas & Andersson Informational [Page 22]
RFC 5038 LDP Implementation Survey Results October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
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.