As per Relevance of the word procedure, we have this rfc below:
Network Working Group B.
Request for Comments: 3037 Cisco Systems, Inc
Category: Informational E.
Zaffire, Inc
January 2001
LDP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Multiprotocol Label Switching (MPLS) is a method for
packets that uses short, fixed-length values carried by packets
called labels, to determine packet nexthops. A fundamental
in MPLS is that two Label Switching Routers (LSRs) must agree on
meaning of the labels used to forward traffic between and
them. This common understanding is achieved by using a set
procedures, called a label distribution protocol, by which one
informs another of label bindings it has made. This
describes the applicability of a set of such procedures called
(for Label Distribution Protocol) by which LSRs distribute labels
support MPLS forwarding along normally routed paths
1. LDP
A label distribution protocol is a set of procedures by which
Label Switching Router (LSR) informs another of the meaning of
used to forward traffic between and through them
The MPLS architecture allows for the possibility of more than
single method for distributing labels, and a number of
label distribution protocols are being standardized.
protocols have been extended so that label distribution can
piggybacked on them, and new protocols have been defined for
explicit purpose of distributing labels
Thomas & Gray Informational [Page 1]
RFC 3037 LDP Applicability January 2001
This document describes the applicability of the Label
Protocol (LDP), a new protocol for label distribution designed
support label distribution for MPLS forwarding along normally
paths as determined by destination-based routing protocols. This
sometimes called MPLS hop-by-hop forwarding
LDP, together with an IP routing plane and software to program
switch or Frame Relay switch cross-connect tables, can implement
in a network of ATM and/or Frame Relay switches without requiring
overlay or the use of ATM-specific or Frame Relay-specific
or routing
LDP is also useful in situations that require efficient hop-by-
routed tunnels, such as MPLS-based VPN architectures [RFC2574]
tunneling between BGP border routers
In addition, LDP includes a mechanism that makes it possible
extend it to support MPLS features that go beyond best effort hop
by-hop forwarding
As a stand-alone protocol for distributing labels LDP does not
on the presence of specific routing protocols at every hop along
LSP path in order to establish an LSP. Hence LDP is useful
situations in which an LSP must traverse nodes which may not
support a common piggybacked approach to distributing labels
Traffic Engineering [TE] is expected to be an important
application. MPLS support for Traffic Engineering uses
routed LSPs, which need not follow normally-routed (hop-by-hop
paths
Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set
extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions
RSVP. There is currently no consensus on which of these protocols
technically superior. Therefore, network administrators should
a choice between the two based upon their needs and
situation
2. Requirement
The "requirement level" [RFC2026] for LDP is
Implementation of LDP is recommended for devices that perform
forwarding along normally routed paths as determined
destination-based routing protocols
Thomas & Gray Informational [Page 2]
RFC 3037 LDP Applicability January 2001
3. Feature
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031]
each label it distributes. Two LSRs which use LDP to exchange FEC
label binding information are known as "LDP Peers", and we speak
there being an "LDP Session" between them
LDP uses TCP for session communication. Use of TCP ensures
session messages are reliably delivered, and that distributed
and state information associated with LSPs need not be
periodically
LDP includes a mechanism by which an LSR can discover potential
peers. The discovery mechanism makes it unnecessary for operators
explicitly configure each LSR with its LDP peers
When an LSR discovers another LSR it follows the LDP session
procedure to establish an LDP session. By means of this
the LSRs establish a session TCP connection and use it to
parameters for the session, such as the label distribution method
be used (see below). After the LSRs agree on the parameters,
session is operational and the LSRs use the TCP connection for
distribution
LDP supports two different methods for label distribution. An
using Downstream Unsolicited distribution advertises FEC-
bindings to its peers when it is ready to forward packets in the
by means of MPLS. An LSR using Downstream on Demand
provides FEC-label bindings to a peer in response to
requests from the peer for a label for the FEC
LDP allows LSRs flexibility in strategies for retaining
labels. An LSR using liberal label retention stores all
learned from peers regardless of whether it currently needs them
forwarding, whereas one using conservative label retention
only labels for which it has immediate use and releases
labels to the peer that advertised them
In addition, LDP allows flexibility in strategies for when
advertise FEC-label bindings. An LSR using independent control
advertises FEC-label bindings to peers whenever it sees fit,
one using ordered control advertises bindings only when it
previously received a label for the FEC from the FEC nexthop or it
an MPLS egress for the FEC
Downstream on Demand distribution with conservative label
and ordered control is appropriate in situations where labels are
relatively scarce resource that must be conserved, and
Thomas & Gray Informational [Page 3]
RFC 3037 LDP Applicability January 2001
Unsolicited distribution with liberal label retention and
control is appropriate where labels are plentiful and need not
carefully conserved. However, the protocol permits
combinations of distribution method, label retention mode and
mode, including hybrid variants of them
LDP defines a mechanism for loop detection to protect
forwarding loops in LSPs that traverse non-TTL MPLS clouds;
[RFC3031] for discussion of situations which may benefit from
mechanism. The loop detection mechanism is optional in the
that it may be disabled by LSR configuration. However, an LDP
compliant LSR must implement it
LDP includes an extension mechanism which supports the development
vendor-private and experimental features. This mechanism
procedures for introducing new types of messages and TLVs, methods
LSR can use for detecting such messages and TLVs, and procedures
LSR must follow when it receives a message or TLV it does
implement. While it is not possible to make every future
backwards compatible, these procedures facilitate the introduction
new capabilities in MPLS networks that include older
that do not recognize them
4. Scalability
The following factors may influence the scalability of
implementations
- LDP label distribution is incremental, requiring no
refresh of FEC-label bindings
- In situations were label resources may be scarce (ATM and
Relay links) the use of the Downstream on Demand
method with conservative label retention ensures that
those labels required to support normally-routed paths
allocated and distributed
- In situations where label resources are not scarce, the use
the Downstream Unsolicited method with liberal label
ensures that changes in FEC nexthop from one LDP peer
another require no distribution action to update
distributed labels
- Limitations on the number of TCP connections an LSR
limit the number of LDP peers the LSR can support
Thomas & Gray Informational [Page 4]
RFC 3037 LDP Applicability January 2001
- Use of the optional path vector based loop detection
imposes additional memory and processing requirements on
LSR, as well as additional LDP traffic. Both
scalability
5. Security
LDP defines the optional use of the TCP MD5 Signature Option
protect against the introduction of spoofed TCP segments into
session connection streams. LDP use of the TCP MD5 Signature
is similar to BGP [RFC1771] use of the option specified in [RFC2385].
6.
[CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright
"Applicability Statement for CR-LDP", Work in Progress
September 1999.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the
MD5 Signature Option", RFC 2385, August 1998.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "
Label Switching Architecture", RFC 3031, January 2001.
[RSVP-TE-AS] Awduche, D., Hannan, A. and X. Xiao, "
State for Extensions to RSVP for LSP-Tunnels", Work
Progress, April 2000.
Thomas & Gray Informational [Page 5]
RFC 3037 LDP Applicability January 2001
7. Authors'
Eric
Zaffire,
2630 Orchard Parkway
San Jose, CA 95134-2020
Phone: 408-894-7362
EMail: ewgray@mindspring.
Bob
Cisco Systems, Inc
250 Apollo Dr
Chelmsford, MA 01824
Phone: 978-244-8078
EMail: rhthomas@cisco.
Thomas & Gray Informational [Page 6]
RFC 3037 LDP Applicability January 2001
8. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Thomas & Gray Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
