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