Internet Draft MPLS WG Jerry Ash Internet Draft AT&T draft-jamoussi-mpls-crldp-applicability-00.txt M. K. Girish SBC Technology Resources Eric Gray Lucent Technologies B. Jamoussi G. Wright Nortel Networks Corp August 1999 Applicability Statement for CR-LDP draft-jamoussi-mpls-crldp-applicability-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This Internet-Draft discusses the applicability of Constraint-Based LSP Setup using LDP [1]. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) [2] 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. Jamoussi, et. al 1 Applicability Statement for CR-LDP August, 1999 1. Introduction As the Internet evolves, additional capabilities are required to ensure proper treatment of data [3], voice, video and other delay sensitive traffic [Ash]. MPLS brings source routing and circuit switching techniques into IP permitting a scalable approach to handling these diverse transmission requirements. CR-LDP 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 [1]. Because LDP is a peer-to-peer protocol based on 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 minimally 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 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 should work equally well for a Multi-service switched networks, a router networks, or hybrid networks. Jamoussi, et. al. February 2000 2 Applicability Statement for CR-LDP August, 1999 2. Applicability of extensions to LDP To provide for 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. 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 Switch 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 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 Jamoussi, et. al. February 2000 3 Applicability Statement for CR-LDP August, 1999 Although CR-LDP is defined as extensions 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 defined 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 setup 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/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 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 draft. As extensions to LDP, CR-LDP shares the security concerns associated with LDP. 6. References 1 B. Jamoussi, et., al., _Constrain-based LSP Setup Using LDP_, work in progress, March 1999. 2 L. Andersson, et., al., _LDP Specification_, work in progress, June 1999. 3 Awduche et al, "Requirements for Traffic Engineering Over MPLS", work in progress (draft-ietf-mpls-traffic-eng-01), June 1999. Jamoussi, et. al. February 2000 4 Applicability Statement for CR-LDP August, 1999 4 G. Ash, Y. Lee, B. Jamoussi, P. Ashwood-Smith, L. Li, D. Skalecki, D. Fedyk, "LSP Modification using CR-LDP," work in progress 5 Blake et al, "An Architecture for Differentiated Services", work in progress 6 S. Shenker, J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements" RFC-2215 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 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan, "Extensions to RSVP for LSP Tunnels," work in progress 7. Author's Addresses Gerald R. Ash M. K. Girish AT&T SBC Technology Resources, Inc. Room MT E3-3C37 4698 Willow Road, 200 Laurel Avenue Pleasanton, CA 94588 Middletown, NJ 07748 USA USA Phone: +1 925 598-1263 Phone: 732-420-4578 Fax: +1 925 598-1322 Fax: 732-440-6687 mgirish@tri.sbc.com Email: gash@att.com Eric W Gray Lucent Technologies, Inc. PO Box 0710 Durham, NH, 03824-0710 USA Phone: +1 603 659 3386 Ewgray@lucent.com Bilel Jamoussi Gregory Wright Nortel Networks Corp. Nortel Networks Corp. 3 Federal Street P O Box 3511 Station C Billerica, MA 01821 Ottawa, ON K1Y 4H7 USA Canada phone: +1 978-288-4506 Phone: +1 613 765-7912 Jamoussi@nortelnetworks.com gwright@nortelnetworks.com Jamoussi, et. al. February 2000 5 Applicability Statement for CR-LDP August, 1999 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 Jamoussi, et. al. February 2000 6