The Label Distribution Protocol (LDP) Implementation Survey Results
RFC 5038
|
| Document |
Type |
|
RFC - Informational
(October 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5038 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Bill Fenner
|
|
Send notices to |
|
(None)
|
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
1. Introduction
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.
1.1. The LDP 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
Show full document text