GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc3213

Network Working Group J. Ash Request for Comments: 3213 AT&T Category: Informational M. Girish

                                                         Atoga Systems
                                                               E. Gray
                                                             Sandburst
                                                           B. Jamoussi
                                                             G. Wright
                                                 Nortel Networks Corp.
                                                          January 2002
                 Applicability Statement for CR-LDP

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.

Copyright Notice

 Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

 This document discusses the applicability of Constraint-Based LSP
 Setup using LDP.  It discusses possible network applications,
 extensions to Label Distribution Protocol (LDP) required to implement
 constraint-based routing, guidelines for deployment and known
 limitations of the protocol.  This document is a prerequisite to
 advancing CR-LDP on the standards track.

1. Introduction

 As the Internet evolves, additional capabilities are required to
 ensure proper treatment of data [3], voice, video and other delay
 sensitive traffic [4].  MPLS enhances source routing and allows for
 certain techniques, used in circuit switching, in IP networks.  This
 permits a scalable approach to handling these diverse transmission
 requirements.  CR-LDP [1] is a simple, scalable, open, non-
 proprietary, traffic engineering signaling protocol for MPLS IP
 networks.
 CR-LDP provides mechanisms for establishing explicitly routed Label
 Switched Paths (LSPs).  These mechanisms are defined as extensions to
 LDP [2].  Because LDP is a peer-to-peer protocol based on the

Ash, et al Informational [Page 1] RFC 3213 Applicability Statement for CR-LDP January 2002

 establishment and maintenance of TCP sessions, the following natural
 benefits exist:
    CR-LDP messages are reliably delivered by the underlying TCP, and
    State information associated with explicitly routed LSPs does not
    require periodic refresh.
    CR-LDP messages are flow controlled (throttled) through TCP.
 CR-LDP is defined for the specific purpose of establishing and
 maintaining explicitly routed LSPs.  Additional optional capabilities
 included have minimal impact on system performance and requirements
 when not in use for a specific explicitly routed LSP.  Optional
 capabilities provide for negotiation of LSP services and traffic
 management parameters over and above best-effort packet delivery
 including bandwidth allocation, setup and holding priorities.  CR-LDP
 optionally allows these parameters to be dynamically modified without
 disruption of the operational (in-service) LSP [4].
 CR-LDP allows the specification of a set of parameters to be signaled
 along with the LSP setup request.  Moreover, the network can be
 provisioned with a set of edge traffic conditioning functions (which
 could include marking, metering, policing and shaping).  This set of
 parameters along with the specification of edge conditioning
 functions can be shown to be adequate and powerful enough to
 describe, characterize and parameterize a wide variety of QoS
 scenarios and services including IP differentiated services [5],
 integrated services [6], ATM service classes [7], and frame relay
 [8].
 CR-LDP is designed to adequately support the various media types that
 MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.).  Hence,
 it will work equally well for Multi-service switched networks, router
 networks, or hybrid networks.
 This applicability statement does not preclude the use of other
 signaling and label distribution protocols for the traffic
 engineering application in MPLS based networks.  Service providers
 are free to deploy whatever signaling protocol meets their needs.
 In particular CR-LDP and RSVP-TE [9] are two signaling protocols that
 perform similar functions in MPLS networks.  There is currently no
 consensus on which protocol is technically superior.  Therefore,
 network administrators should make a choice between the two based
 upon their needs and particular situation.  Applicability of RSVP-TE
 is described in [10].

Ash, et al Informational [Page 2] RFC 3213 Applicability Statement for CR-LDP January 2002

2. Applicability of extensions to LDP

 To provide support of additional LSP services, CR-LDP extensions are
 defined in such a way as to be directly translatable to objects and
 messages used in other protocols defined to provide similar services
 [9].  Implementations can take advantage of this fact to:
    Setup LSPs for provision of an aggregate service associated with
    the services being provided via these other protocols.
    Directly translate protocol messages to provide services defined
    in a non-CR-LDP portion of the network.
    Describe, characterize and parameterize a wide variety of QoS
    scenarios and services including IP differentiated services,
    integrated services, ATM service classes, and frame relay.
 Steady state information required for proper maintenance of an LSP
 may be as little as 200 bytes or less.  It is not unreasonable to
 anticipate that CR-LDP implementations may support in excess of one
 hundred thousand or one million LSPs switched through a single Label
 Switching Router (LSR) under fairly stable conditions.
 Because CR-LDP provides for low overhead per LSP - both in terms of
 needed state information and control traffic - CR-LDP is applicable
 in those portions of the Internet where very large numbers of LSPs
 may need to be switched at each LSR.  An example of this would be
 large backbone networks using MPLS exclusively to transport very
 large numbers of traffic streams between a moderately large number of
 MPLS edge nodes.
 CR-LDP may also be applicable as a mediating service between networks
 providing similar service extensions using widely varying signaling
 models.

3. Implementation and deployment considerations in relation to LDP

 LDP specifies the following label distribution and management modes
 (which can be combined in various logical ways described in LDP):
    . Downstream On Demand label distribution
    . Downstream Unsolicited label distribution
    . Independent Label Distribution Control
    . Ordered Label Distribution Control
    . Conservative Label Retention Mode
    . Liberal Label Retention Mode
 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 the
 functionality defined in the LDP specification.  The basic Discovery,
 Session, and Notification messages are required.  However, CR-LDP
 requires one specific combination of the label distribution modes:
    . Downstream On Demand Ordered label distribution and
      conservative Label Retention Mode
 Although CR-LDP is defined as an extension to LDP, support for
 Downstream Unsolicited Label Advertisement and Independent Control
 modes is not required for support of Strict Explicit Routes.  In
 addition, implementations of CR-LDP MAY be able to support Loose
 Explicit Routes via the use of 'Abstract Nodes' and/or 'Hierarchical
 Explicit Routing', without using LDP for hop-by-hop LSP setup.
 CR-LDP also includes support for loose explicit routes.  Use of this
 capability allows the network operator to define an 'explicit path'
 through portions of their network with imperfect knowledge of the
 entire network topology.  Proper use of this capability may also
 allow CR-LDP implementations to inter-operate with 'vanilla' LDP
 implementations - particularly if it is desired to set up an
 explicitly routed LSP for best-effort packet delivery via a loosely
 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 single
 protocol (LDP, with the extensions defined in CR-LDP) can be used for
 both TE and Hop-by-Hop LSPs.  New protocols do not have to be
 introduced in the network to provide TE-LSP signaling.

4. Limitations

 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 LSP
 setup.  Multiple label allocations per LSP setup are FFS.

5. Security Considerations

 No additional security issues are introduced in this document.  As an
 extension to LDP, CR-LDP shares the security concerns associated with
 LDP.

Ash, et al Informational [Page 4] RFC 3213 Applicability Statement for CR-LDP January 2002

6. Acknowledgements

 The authors would like to thank the following people for their
 careful review of the document and their comments: Loa Andersson,
 Peter Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil and
 Adrian Farrel.

7. References

 [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", RFC
      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", RFC
      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 Characterization
      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 BEARER
      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", RFC
      3209, December 2001.
 [10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
      for Extensions to RSVP for LSP-Tunnels", RFC 3210, December
      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, January
      2001.

8. Author's Addresses

 Gerald R. Ash
 AT&T
 Room MT D5-2A01
 200 Laurel Avenue
 Middletown, NJ 07748
 USA
 Phone: 732-420-4578
 Fax:   732-368-8659
 EMail: gash@att.com
 Eric Gray
 Sandburst
 600 Federal Drive
 Andover, MA  01810
 Phone: (978) 689-1610
 EMail: eric.gray@sandburst.com
 Gregory Wright
 Nortel Networks Corp.
 P O Box 3511 Station C
 Ottawa, ON K1Y 4H7
 Canada
 Phone: +1 613 765-7912
 EMail: gwright@nortelnetworks.com
 M. K. Girish
 Atoga Systems
 49026 Milmont Drive
 Fremont, CA 94538
 EMail: muckai@atoga.com
 Bilel Jamoussi
 Nortel Networks Corp.
 600 Technology Park Drive
 Billerica, MA 01821
 USA
 phone: +1 978-288-4506
 EMail: Jamoussi@nortelnetworks.com

Ash, et al Informational [Page 6] RFC 3213 Applicability Statement for CR-LDP January 2002

9. Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Ash, et al Informational [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3213.txt · Last modified: 2002/02/06 23:48 (external edit)