RFC 2702 (rfc2702) - Page 3 of 29

Requirements for Traffic Engineering Over MPLS

RFC 2702                MPLS Traffic Engineering          September 1999


   the realization of these objectives.  A description of the basic
   capabilities and functionality required of an MPLS implementation to
   accommodate the requirements is also presented.

   It should be noted that even though the focus is on Internet
   backbones, the capabilities described in this document are equally
   applicable to Traffic Engineering in enterprise networks. In general,
   the capabilities can  be applied to any label switched network under
   a single technical administration in which at least two paths exist
   between two nodes.

   Some recent manuscripts have focused on the considerations pertaining
   to Traffic Engineering and Traffic management under MPLS, most
   notably the works of Li and Rekhter [3], and others.  In [3], an
   architecture is proposed which employs MPLS and RSVP to provide
   scalable differentiated services and Traffic Engineering in the
   Internet.  The present manuscript complements the aforementioned and
   similar efforts.  It reflects the authors' operational experience in
   managing a large Internet backbone.

1.1 Terminology

   The reader is assumed to be familiar with the MPLS terminology as
   defined in [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [11].

1.2 Document Organization

   The remainder of this document is organized as follows: Section 2
   discusses the basic functions of Traffic Engineering in the Internet.
   Section 3, provides an overview of the traffic Engineering potentials
   of MPLS. Sections 1 to 3 are essentially background material. Section
   4 presents an overview of the fundamental requirements for Traffic
   Engineering over MPLS. Section 5 describes the desirable attributes
   and characteristics of traffic trunks which are pertinent to Traffic
   Engineering. Section 6 presents a set of attributes which can be
   associated with resources to constrain the routability of traffic
   trunks and LSPs through them. Section 7 advocates the introduction of
   a "constraint-based routing" framework in MPLS domains.  Finally,
   Section 8 contains concluding remarks.








Awduche, et al.              Informational