As per Relevance of the word statement, we have this rfc below:
Network Working Group J.
Request for Comments: 3213 AT&
Category: Informational M.
Atoga
E.
B.
G.
Nortel Networks Corp
January 2002
Applicability Statement for CR-
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 (2002). All Rights Reserved
This document discusses the applicability of Constraint-Based
Setup using LDP. It discusses possible network applications
extensions to Label Distribution Protocol (LDP) required to
constraint-based routing, guidelines for deployment and
limitations of the protocol. This document is a prerequisite
advancing CR-LDP on the standards track
1.
As the Internet evolves, additional capabilities are required
ensure proper treatment of data [3], voice, video and other
sensitive traffic [4]. MPLS enhances source routing and allows
certain techniques, used in circuit switching, in IP networks.
permits a scalable approach to handling these diverse
requirements. CR-LDP [1] is a simple, scalable, open, non
proprietary, traffic engineering signaling protocol for MPLS
networks
CR-LDP provides mechanisms for establishing explicitly routed
Switched Paths (LSPs). These mechanisms are defined as extensions
LDP [2]. Because LDP is a peer-to-peer protocol based on
Ash, et al Informational [Page 1]
RFC 3213 Applicability Statement for CR-LDP January 2002
establishment and maintenance of TCP sessions, the following
benefits exist
CR-LDP messages are reliably delivered by the underlying TCP,
State information associated with explicitly routed LSPs does
require periodic refresh
CR-LDP messages are flow controlled (throttled) through TCP
CR-LDP is defined for the specific purpose of establishing
maintaining explicitly routed LSPs. Additional optional
included have minimal impact on system performance and
when not in use for a specific explicitly routed LSP.
capabilities provide for negotiation of LSP services and
management parameters over and above best-effort packet
including bandwidth allocation, setup and holding priorities. CR-
optionally allows these parameters to be dynamically modified
disruption of the operational (in-service) LSP [4].
CR-LDP allows the specification of a set of parameters to be
along with the LSP setup request. Moreover, the network can
provisioned with a set of edge traffic conditioning functions (
could include marking, metering, policing and shaping). This set
parameters along with the specification of edge
functions can be shown to be adequate and powerful enough
describe, characterize and parameterize a wide variety of
scenarios and services including IP differentiated services [5],
integrated services [6], ATM service classes [7], and frame
[8].
CR-LDP is designed to adequately support the various media types
MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.). Hence
it will work equally well for Multi-service switched networks,
networks, or hybrid networks
This applicability statement does not preclude the use of
signaling and label distribution protocols for the
engineering application in MPLS based networks. Service
are free to deploy whatever signaling protocol meets their needs
In particular CR-LDP and RSVP-TE [9] are two signaling protocols
perform similar functions in MPLS networks. There is currently
consensus on which protocol is technically superior. Therefore
network administrators should make a choice between the two
upon their needs and particular situation. Applicability of RSVP-
is described in [10].
Ash, et al Informational [Page 2]
RFC 3213 Applicability Statement for CR-LDP January 2002
2. Applicability of extensions to
To provide support of additional LSP services, CR-LDP extensions
defined in such a way as to be directly translatable to objects
messages used in other protocols defined to provide similar
[9]. Implementations can take advantage of this fact to
Setup LSPs for provision of an aggregate service associated
the services being provided via these other protocols
Directly translate protocol messages to provide services
in a non-CR-LDP portion of the network
Describe, characterize and parameterize a wide variety of
scenarios and services including IP differentiated services
integrated services, ATM service classes, and frame relay
Steady state information required for proper maintenance of an
may be as little as 200 bytes or less. It is not unreasonable
anticipate that CR-LDP implementations may support in excess of
hundred thousand or one million LSPs switched through a single
Switching Router (LSR) under fairly stable conditions
Because CR-LDP provides for low overhead per LSP - both in terms
needed state information and control traffic - CR-LDP is
in those portions of the Internet where very large numbers of
may need to be switched at each LSR. An example of this would
large backbone networks using MPLS exclusively to transport
large numbers of traffic streams between a moderately large number
MPLS edge nodes
CR-LDP may also be applicable as a mediating service between
providing similar service extensions using widely varying
models
3. Implementation and deployment considerations in relation to
LDP specifies the following label distribution and management
(which can be combined in various logical ways described in LDP):
. Downstream On Demand label
. Downstream Unsolicited label
. Independent Label Distribution
. Ordered Label Distribution
. Conservative Label Retention
. Liberal Label Retention
The applicability of LDP is described in [11].
Ash, et al Informational [Page 3]
RFC 3213 Applicability Statement for CR-LDP January 2002
In networks where only Traffic Engineered LSPs are required, the CR
LDP implementation and deployment does NOT require all
functionality defined in the LDP specification. The basic Discovery
Session, and Notification messages are required. However, CR-
requires one specific combination of the label distribution modes
. Downstream On Demand Ordered label distribution
conservative Label Retention
Although CR-LDP is defined as an extension to LDP, support
Downstream Unsolicited Label Advertisement and Independent
modes is not required for support of Strict Explicit Routes.
addition, implementations of CR-LDP MAY be able to support
Explicit Routes via the use of 'Abstract Nodes' and/or '
Explicit Routing', without using LDP for hop-by-hop LSP setup
CR-LDP also includes support for loose explicit routes. Use of
capability allows the network operator to define an 'explicit path
through portions of their network with imperfect knowledge of
entire network topology. Proper use of this capability may
allow CR-LDP implementations to inter-operate with 'vanilla'
implementations - particularly if it is desired to set up
explicitly routed LSP for best-effort packet delivery via a
defined path
Finally, in networks where both Routing Protocol-driven LSPs (a.k.a
hop-by-hop LSPs) and Traffic Engineered LSPs are required, a
protocol (LDP, with the extensions defined in CR-LDP) can be used
both TE and Hop-by-Hop LSPs. New protocols do not have to
introduced in the network to provide TE-LSP signaling
4.
CR-LDP specification only supports point-to-point LSPs. Multi
point-to-point and point-to-multi-point are for further study (FFS).
CR-LDP specification only supports unidirectional LSP setup. Bi
directional LSP setup is FFS
CR-LDP specification only supports a unique label allocation per
setup. Multiple label allocations per LSP setup are FFS
5. Security
No additional security issues are introduced in this document. As
extension to LDP, CR-LDP shares the security concerns associated
LDP
Ash, et al Informational [Page 4]
RFC 3213 Applicability Statement for CR-LDP January 2002
6.
The authors would like to thank the following people for
careful review of the document and their comments: Loa Andersson
Peter Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil
Adrian Farrel
7.
[1] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint
based LSP Setup Using LDP", RFC 3212, January 2002.
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B
Thomas, "LDP Specification", RFC 3036, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J
McManus, "Requirements for Traffic Engineering Over MPLS",
2702, September 1999.
[4] Ash, B., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D.,
Skalecki, D. and L. Li, "LSP Modification using CR-LDP",
3214, January 2002.
[5] Blake S., Black, D., Carlson, M., Davies, E., Wang, Z. and W
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[6] Shenker, S. and J. Wroclawski, "General
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.
[7] ATM Forum Traffic Management Specification Version 4.1 (AF-TM
0121.000), March 1999.
[8] CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING
SERVICE, ITU (CCITT) Recommendation I.370, 1991.
[9] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
3209, December 2001.
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability
for Extensions to RSVP for LSP-Tunnels", RFC 3210,
2001.
Ash, et al Informational [Page 5]
RFC 3213 Applicability Statement for CR-LDP January 2002
[11] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
2001.
8. Author's
Gerald R.
AT&
Room MT D5-2A01
200 Laurel
Middletown, NJ 07748
Phone: 732-420-4578
Fax: 732-368-8659
EMail: gash@att.
Eric
600 Federal
Andover, MA 01810
Phone: (978) 689-1610
EMail: eric.gray@sandburst.
Gregory
Nortel Networks Corp
P O Box 3511 Station
Ottawa, ON K1Y 4H
Phone: +1 613 765-7912
EMail: gwright@nortelnetworks.
M. K.
Atoga
49026 Milmont
Fremont, CA 94538
EMail: muckai@atoga.
Bilel
Nortel Networks Corp
600 Technology Park
Billerica, MA 01821
phone: +1 978-288-4506
EMail: Jamoussi@nortelnetworks.
Ash, et al Informational [Page 6]
RFC 3213 Applicability Statement for CR-LDP January 2002
9. Full Copyright
Copyright (C) The Internet Society (2002). 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
Ash, et al 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
