Internet Draft


policy/mpls                                                   R. Chadha
Internet Draft                                       Huai-An (Paul) Lin
Expires January 2001                             Telcordia Technologies
draft-chadha-policy-mpls-te-00.txt                            July 2000


         Policy Information Model for MPLS Traffic Engineering


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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

   The purpose of this draft is to describe an information model for
   representing MPLS traffic engineering policies. RFC 2702,
   "Requirements for Traffic Engineering over MPLS", is used as a basis
   for determining the types of information that need to be represented
   in such an information model. The latter document describes the
   functional capabilities required to implement policies that
   facilitate efficient and reliable network operations in an MPLS
   domain. The information model described in this draft attempts to
   capture the information required to enable the functional
   capabilities described in RFC 2702. This information model could be
   used by a management system to optimize network performance through
   the necessary network provisioning actions.

   An overview of policy-based management is given in this document,
   along with a description of the relationship of this work to other
   information models that are being defined in the IETF Policy
   Framework working group. This is followed by a detailed description
   of the information model, and a number of examples illustrating its
   use.



Chadha                   Expires January 2001                        1

        Policy Information Model for MPLS Traffic Engineering July 2000


Conventions used in this document

   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 [2].

Table of Contents

1.  Introduction.....................................................3
 1.1  Terminology....................................................3
 1.2  Purpose of this document and Roadmap...........................4
2.  Policy-Enabled MPLS Traffic Engineering..........................5
 2.1  Relationship to previous work..................................5
 2.2  Overview and Scope of this work................................6
3.  Overview of MPLS Traffic Engineering Policy Data Model...........7
 3.1  Overview of object classes and their associations..............7
 3.2  High-level description of information model...................10
4.  Detailed Description of MPLS Traffic Engineering Policy Information
Model................................................................14
 4.1  Object Class MPLSActivateTTAction.............................14
 4.2  Object Class MPLSCreateLSPAction..............................16
 4.3  Object Class MPLSDestroyLSPAction.............................16
 4.4  Object Class MPLSDestroyTTAction..............................17
 4.5  Object Class MPLSModifyTTAction...............................18
 4.6  Object Class MPLSAssignLSPAction..............................18
 4.7  Object Class MPLSDeassignLSPAction............................20
 4.8  Object Class MPLSTrafficTrunk.................................21
 4.9  Object Class MPLSRoute........................................25
 4.10 Object Class MPLSLSP..........................................29
 4.11 Object Class MPLSRouteSpec....................................31
 4.12 Object Class MPLSResourceProfile..............................31
 4.13 Object Class MPLSResources....................................33
 4.14 The association MPLSHopInRoute................................35
 4.15 The association MPLSASInRoute.................................36
 4.16 The association MPLSSystemResources...........................37
 4.17 The association MPLSEndpointResources.........................38
 4.18 The association MPLSActiveConnection..........................38
 4.19 The association MPLSReverseDirTT..............................40
 4.20 The association MPLSEligibleRouteSpec.........................41
 4.21 The association MPLSCurrentlyAssignedLSP......................42
 4.22 The association MPLSBackupLSP.................................43
 4.23 The association MPLSRouteResourceProfile......................44
 4.24 The association MPLSRealizes..................................45
 4.25 The association MPLSLSPinLSP..................................45
 4.26 The association MPLSTrafficProfile............................46
5.  Usage Examples..................................................47
 5.1  Implementing Olympic Services.................................47
 5.2  Creating traffic trunks.......................................54
 5.3  Load balancing................................................57
 5.4  Implementing Service Level Agreements (SLAs)..................57
6.  Security Considerations.........................................58
7.  Conclusions.....................................................58
8.  References......................................................58

Chadha                   Expires January 2001                        2

        Policy Information Model for MPLS Traffic Engineering July 2000


9.  Acknowledgments.................................................60
10.  Author's Addresses.............................................60


1. Introduction

   According to [3], Traffic Engineering (TE) is concerned with
   performance optimization of operational networks. In general, it
   encompasses the application of technology and scientific principles
   to the measurement, modeling, characterization, and control of
   Internet traffic, and the application of such knowledge and
   techniques to achieve specific performance objectives. The aspects
   of traffic engineering that are of interest for MPLS are measurement
   and control. A major goal of Internet traffic engineering is to
   facilitate efficient and reliable network operations while
   simultaneously optimizing network resource utilization and traffic
   performance. Traffic engineering has become an indispensable
   function in many large autonomous systems because of the high cost
   of network assets and the commercial and competitive nature of the
   Internet. These factors emphasize the need for maximal operational
   efficiency.

   The concept of MPLS traffic trunks is used extensively in the
   remainder of this document. According to Li and Rekhter [4], a
   traffic trunk is an aggregation of traffic flows of the same class
   which are placed inside a Label Switched Path. Essentially, a
   traffic trunk is an abstract representation of traffic to which
   specific characteristics can be associated. It is useful to view
   traffic trunks as objects that can be routed; that is, the path
   through which a traffic trunk traverses can be changed. In this
   respect, traffic trunks are similar to virtual circuits in ATM and
   Frame Relay networks.  It is important, however, to emphasize that
   there is a fundamental distinction between a traffic trunk and the
   path, and indeed the LSP, through which it traverses. An LSP is a
   specification of the label switched path through which the traffic
   traverses.


1.1 Terminology

   The following abbreviations are used in this document:

   AS           Autonomous System
   ATM          Asynchronous Transfer Mode
   CIM          Common Information Model
   CLI          Command Line Interface
   COPS         Common Open Policy Service
   DMTF         Distributed Management Task Force
   FEC          Forwarding Equivalence Class
   LDAP         Lightweight Directory Access Protocol
   LSP          Label Switched Path
   LSR          Label Switched Router
   MAM          Maximum Allocation Multiplier

Chadha                   Expires January 2001                        3

        Policy Information Model for MPLS Traffic Engineering July 2000


   MIB          Management Information Base
   MPLS         Multi-Protocol Label Switching
   PCIM         Policy Core Information Model
   PDP          Policy Decision Point
   QoS          Quality of Service
   QPIM         QoS Policy Information Model
   SLA          Service Level Agreement
   SNMP         Simple Network Management Protocol
   TE           Traffic Engineering
   WG           Work Group


1.2 Purpose of this document and Roadmap

   This document presents an object-oriented information model for
   representing MPLS traffic engineering policy information. The model
   is based on the Policy Core Information Model [5] currently being
   jointly developed by the IETF Policy Framework WG and by the
   Distributed Management Task Force (DMTF) as part of the CIM (Common
   Information Model) extensions work.  Our model defines two
   hierarchies of object classes: structural classes representing
   policy information and MPLS-specific objects referenced by these
   policies; and association classes that indicate how instances of the
   structural classes are related to each other. Subsequent documents
   will define mappings of this information model to various concrete
   implementations, for example, to a directory that uses LDAPv3 as its
   access protocol.

   The policy core information model is sufficiently generic to
   represent policies related to practically anything.  Extensions of
   this model for representing QoS policies are being developed by the
   IETF Policy Framework WG [6]. The IETF IPSec Policy (ipsp) WG is
   also working on defining an information model for representing IPSec
   policies. This document derives object classes from the Policy Core
   Information Model and also makes use of some object classes from the
   QoS information model [6].

   This document is organized in the following manner:

      - Section 2 describes the relationship of this work to previous
        work, provides a general overview of policies and how they
        are modeled.

      - Section 3 presents a high-level overview of the classes and
        associations comprising the Policy Information Model for MPLS
        Traffic Engineering.

      - Section 4 presents the detailed specifications for each of the
        object classes and associations in the data model.

      - Section 5 provides detailed examples illustrating the use of
        the Policy Information Model for MPLS Traffic Engineering.


Chadha                   Expires January 2001                        4

        Policy Information Model for MPLS Traffic Engineering July 2000



2. Policy-Enabled MPLS Traffic Engineering


2.1 Relationship to previous work

   As described in the Policy Core Information Model (PCIM) [5],
   policies can be regarded as rules with two basic components:
   conditions and actions. Conditions are boolean expressions which
   evaluate to either true or false. Actions represent some concrete
   action that should be taken by a management system if the conditions
   in the rule evaluate to true.

   The policy framework described in PCIM provides an elaborate
   mechanism for prioritizing policy rules; specifying time periods
   during which policy rules are applicable; specifying complex boolean
   conditions using either disjunctive normal form or conjunctive
   normal form and negations; grouping policies together; specifying
   reusable conditions and actions; etc. Policies are specified using a
   declarative rather than a procedural approach, i.e. policies
   describe the conditions and actions that make up a rule, but do not
   give a step-by-step description of how to implement the policy.

   In the QoS Policy Information Model (QPIM) [6], new object classes
   are defined to model the management and configuration of Diffserv-
   and RSVP-capable network elements. Apart from QoS-specific
   information, the model contains a number of concepts that are rather
   general and can be re-used in a number of different contexts. One
   such concept is that of variables and constants with well-defined
   semantics that represent things like IP addresses, port numbers,
   protocol numbers, etc. These variables are used to describe traffic
   classifiers in QPIM. Such a representation is also very useful for
   the information model described in this draft, as there is a need to
   define the FECs (Forwarding Equivalence Classes) that map to given
   traffic trunks. Other concepts that are re-used from QPIM are those
   defining traffic profiles and policing actions (see object classes
   qosPolicyPRTrfcProf and qosPolicyPRAction in [6]). These are used
   here for describing the traffic profiles of traffic trunks, and the
   policing requirements for traffic trunks (including what to do with
   non-conforming traffic for a given traffic trunk).

   Earlier Internet drafts ([13, 14]) discuss policy for MPLS. [13]
   outlines requirements for policy-enabled MPLS and identifies two
   main categories of MPLS policies: LSP admission policies that map
   traffic flows onto LSPs, and LSP life cycle policies that affect LSP
   creation, deletion, configuration and monitoring. The information
   model presented in the current draft addresses both these categories
   of policies, excluding any monitoring requirements. In [14], the
   authors discuss policies for MPLS load balancing. The information
   model that we present is broader in scope and addresses all aspects
   of traffic engineering, including load balancing.



Chadha                   Expires January 2001                        5

        Policy Information Model for MPLS Traffic Engineering July 2000


   The information model in this draft builds upon the PCIM model and
   further refines it by adding new actions that are specific to the
   domain of MPLS traffic engineering. Actions are included for
   creating, modifying, and destroying traffic trunks and LSPs, and
   assigning LSPs to traffic trunks. Also, new object classes and
   associations are introduced to model MPLS traffic engineering
   concepts referenced by these actions, such as traffic trunks, route
   specifications, LSPs and their hops, resources and resource classes,
   etc. No attempt is made to define new object classes for
   representing classifier information as this is currently being
   addressed in QPIM.


2.2 Overview and Scope of this work

   This information model presented in this draft has been designed to
   support the functionality outlined in RFC 2702 [3]. The latter
   document describes the following notions which have been modeled in
   this document:

        - Basic traffic engineering attributes of traffic trunks
        - Basic operations on traffic trunks
        - Traffic parameter attributes
        - Generic path selection and management attributes
        - Resource attributes.

   This information model currently does not cover modeling of LSP
   monitoring and operational attributes (such as LSP lifetime, error
   statistics, etc.). Further, this document does not seek to select
   mechanisms for performing MPLS traffic engineering; rather, it
   enables the specification of MPLS traffic engineering policies by
   defining an information model that attempts to capture the
   information required to describe such policies. Thus, even though
   MPLS supports traffic engineering via a number of mechanisms (CR-
   LDP, RSVP) that allow LSPs to be managed, such mechanisms are not
   referenced in this information model. This is in conformance with
   the requirement in [13] that an MPLS policy information model should
   be independent of the MPLS mechanisms used.

   The policy actions described in this draft enable the specification
   of actions that create, modify, and destroy traffic trunks and LSPs;
   and assign/de-assign LSPs to/from traffic trunks (object classes
   MPLSActivateTTAction, MPLSCreateLSPAction, MPLSDestroyLSPAction,
   MPLSDestroyTTAction, MPLSModifyTTAction, MPLSAssignLSPAction, and
   MPLSDeassignLSPAction). These actions reference and manipulate
   traffic trunks, LSPs, and related objects and associations. The idea
   is that a traffic engineering management system would be able to
   specify policies that result in the manipulation of traffic trunks,
   LSPs, and related information. The implementation of the policies
   would be performed by a PDP (Policy Decision Point) (see [7]). The
   PDP could make use of mechanisms supported by network elements to
   implement the specified policies; e.g. COPS, SNMP, CLI, etc. Several
   MIBs have been defined that could be used for implementing such

Chadha                   Expires January 2001                        6

        Policy Information Model for MPLS Traffic Engineering July 2000


   policies, namely the MPLS Traffic Engineering MIB [8] and the MPLS
   LSR MIB [9], etc.


3. Overview of MPLS Traffic Engineering Policy Data Model


3.1 Overview of object classes and their associations

   The following figures show some of the new object classes and
   associations defined for the MPLS Traffic Engineering Policy
   Information Model. Some of these were briefly mentioned in the
   previous section. A number of object classes from previously defined
   information models, namely CIM [10] and QPIM [6], are also shown
   where necessary to illustrate new associations relating newly
   defined structural object classes to object classes previously
   defined in those information models. Object classes belonging to
   these information models are appropriately marked. A detailed
   description of the depicted object classes is provided in Section 4
   of this document.

                        +-----------------------------+
                        |  qosPolicyPRTrfcProf (QPIM) |
                        +-----------^-----------------+
                                0..1|
                              (a)   |         ----------
                                   *|     0..1|        |
                        +-----------v---------v-+      | (b)
                        |   MPLSTrafficTrunk    <-------
                        |                       | 0..1
                        +-^-----------------^--^+
                         *|                *| *|
                          |                 |  |
                      (c) |              (d)|  |(e)
                          |                 |  |                (f)
                          |                 |  |             ----------
                         *|                *| *|           * |        |
        +-----------------v-----+ *  (g)* +-v--v-------------v----+   |
        |    MPLSRouteSpec      <--------->         MPLSLSP       <----
        +-----------------------+         +-----------------------+ *

       Figure 1. Relationships between traffic trunks, LSPs, route
                 specifications, and traffic profiles

   In Figures 1 and 2, boxes represent object classes and arrows
   represent associations between the classes.  The following
   associations appear in Figure 1 above:

        (a) MPLSTrafficProfile
        (b) MPLSReverseDirTT
        (c) MPLSEligibleRouteSpec
        (d) MPLSCurrentlyAssignedLSP
        (e) MPLSBackupLSP

Chadha                   Expires January 2001                        7

        Policy Information Model for MPLS Traffic Engineering July 2000


        (f) MPLSLSPinLSP
        (g) MPLSRealizes

   An association represents a relationship between two classes (e.g.
   associations (a), (c), (d), (e), and (g) above in Figure 1), or
   between a class and itself (e.g. associations (b) and (f) in Figure
   1). Cardinalities are part of each association; the cardinality of
   an association indicates how many instances of each class may be
   related to an instance of the other class.  For example, the
   MPLSBackupLSP association has the cardinality "*" (i.e. "0..n") for
   both the MPLSTrafficTrunk and the MPLSLSP classes.  These ranges are
   interpreted as follows:

   - The "*" written next to MPLSTrafficTrunk indicates that an MPLSLSP
     may be related to no MPLSTrafficTrunk, to one MPLSTrafficTrunk, or
     to more than one MPLSTrafficTrunk via the MPLSBackupLSP
     association. In other words, an LSP may be a backup LSP for zero
     or more traffic trunks.
   - The "*" written next to MPLSLSP indicates that a MPLSTrafficTrunk
     may be related to no MPLSLSP, to one MPLSLSP, or to more than one
     MPLSLSP via the MPLSBackupLSP association. In other words, a
     traffic trunk may have zero or more backup LSPs.

                                              -----------
                                           (h)|         |
                                             *|         |
      +----------------+      +---------------v--+      |
      |ComputerSystem  |      | ProtocolEndpoint <------|
      |    (CIM)       |      |    (CIM)         |*
      +----------- ^---+      +^---------^-------+
                  *|          *|        *|
                (i)|        (j)|      (k)|
               0..1|       0..1|        *|
              +----v-----------v+      +-v------------+
              |  MPLSResources  |      |  MPLSRoute   |
              +-----------------+      +^----------^--+
                                       *|         *|
                                     (l)|       (m)|
                                       *|      0..1|
                 +----------------------v+    +----v----------------+
                 | AutonomousSystem (CIM)|    | MPLSResourceProfile |
                 +-----------------------+    +---------------------+


       Figure 2. Relationships between routes, hops, resources, etc.

   The following associations appear in Figure 2 above:

        (h) MPLSActiveConnection
        (i) MPLSSystemResources
        (j) MPLSEndpointResources
        (k) MPLSHopInRoute
        (l) MPLSASInRoute

Chadha                   Expires January 2001                        8

        Policy Information Model for MPLS Traffic Engineering July 2000


        (m) MPLSRouteResourceProfile

   The inheritance tree for the object classes defined in this document
   is given below. Apart from the new object classes defined in this
   document, the tree below contains references to object classes
   defined in the Policy Core Information Model [5], marked "PCIM"
   below, and to object classes defined in the Common Information Model
   [10], marked "CIM" below. For detailed descriptions of these object
   classes, please see the relevant documents.

         +--Policy (abstract) (PCIM)
         |  |
         |  +---PolicyAction (PCIM)
         |  |          |
         |  |          +---MPLSActivateTTAction
         |  |          |
         |  |          +---MPLSCreateLSPAction
         |  |          |
         |  |          +---MPLSDestroyLSPAction
         |  |          |
         |  |          +---MPLSDestroyTTAction
         |  |          |
         |  |          +---MPLSModifyTTAction
         |  |          |
         |  |          +---MPLSAssignLSPAction
         |  |          |
         |  |          +---MPLSDeassignLSPAction
         |  |
         |  +--- MPLSResourceProfile
         |
         +--CIM_ManagedSystemElement (abstract) (CIM)
            |
            +--CIM_LogicalElement (abstract) (CIM)
               |
               +--MPLSResources
               |
               +--MPLSTrafficTrunk
               |
               +--MPLSRoute (abstract)
                  |
                  +---MPLSRouteSpec
                  |
                  +---MPLSLSP


      Figure 3. Inheritance Hierarchy for MPLS Policy object classes


   In CIM, associations are also modeled as classes.  For the MPLS
   Traffic Engineering Policy Information Model, the inheritance
   hierarchy is shown below:



Chadha                   Expires January 2001                        9

        Policy Information Model for MPLS Traffic Engineering July 2000


   [unrooted]
         |
         +---MPLSHopInRoute
         |
         +---MPLSASInRoute
         |
         +---MPLSSystemResources
         |
         +---MPLSEndpointResources
         |
         +---ActiveConnection (CIM)
         |            |
         |            +---MPLSActiveConnection
         |
         +---MPLSReverseDirTT
         |
         +---MPLSEligibleRouteSpec
         |
         +---MPLSCurrentlyAssignedLSP
         |
         +---MPLSBackupLSP
         |
         +---MPLSRouteResourceProfile
         |
         +---MPLSRealizes
         |
         +---MPLSLSPinLSP
         |
         +---MPLSTrafficProfile

             Figure 4. Inheritance Hierarchy for associations


3.2 High-level description of information model


3.2.1   MPLS Traffic Engineering Policy Actions

   A number of policy actions are defined for the purpose of enabling a
   management system to manipulate traffic trunks and LSPs. These
   actions may reference instances of traffic trunks, LSPs, and route
   specifications (see definition of route specification in Section
   3.2.2). In order to reference such instances, they must first be
   created and populated; and any related objects and associations must
   also be instantiated and populated.

   For example, MPLSActivateTTAction activates a traffic trunk; the
   property mpTrafficTrunk in this action references an instance of a
   traffic trunk that is to be activated. Thus before instantiating an
   instance of MPLSActivateTTAction, one must instantiate an instance
   of MPLSTrafficTrunk that will be referenced by this action. In
   addition, all the related object instances and associations must
   also be instantiated before instantiating this action. RFC 2702 [3]

Chadha                   Expires January 2001                       10

        Policy Information Model for MPLS Traffic Engineering July 2000


   describes the difference between establishing a traffic trunk (which
   we model by creating an instance of MPLSTrafficTrunk and related
   classes as described in Section 3.2.1.1) and activating a traffic
   trunk (which is modeled by the MPLSActivateTTAction).


3.2.1.1  Referencing traffic trunks

   The following objects may need to be instantiated in order to fully
   describe a traffic trunk referenced by an action:

   - Route specifications: Zero or more route specifications
   (MPLSRouteSpec) can be associated with a traffic trunk to indicate
   that this is a potential route to which this traffic trunk can be
   mapped. The association is modeled by the MPLSEligibleRouteSpec
   association.

   - Traffic profile: A traffic profile (qosPolicyPRAction) describing
   the resource requirements of a traffic trunk can be defined for
   every traffic trunk and associated with the traffic trunk via the
   MPLSTrafficProfile association.

   - Assigned LSPs: Any LSPs (MPLSLSP) currently assigned to a traffic
   trunk can be defined and associated with it via the
   MPLSCurrentlyAssignedLSP association.

   - Backup LSPs: Any LSPs (MPLSLSP) that are acting as backup LSPs for
   a traffic trunk can be defined and associated with it via the
   MPLSBackupLSP association.

   - Reverse traffic trunk: If a traffic trunk carrying traffic in the
   reverse direction exists, it can be associated with a given traffic
   trunk via the MPLSReverseDirTT association.


3.2.1.2 Referencing LSPs

   The following objects may need to be instantiated in order to fully
   describe an LSP referenced by an action:

   - Route specifications: Zero or more route specifications
   (MPLSRouteSpec) can be associated with an LSP to indicate that this
   LSP is an realization of the route specification. The association is
   modeled by the MPLSRealizes association.

   - Traffic trunks: Any traffic trunks (MPLSTrafficTrunk) whose
   traffic is currently being carried by an LSP should be defined and
   associated with this LSP via the MPLSCurrentlyAssignedLSP
   association. Further, any traffic trunks for which an LSP is a
   backup LSP should be associated with this LSP via the MPLSBackupLSP
   association.



Chadha                   Expires January 2001                       11

        Policy Information Model for MPLS Traffic Engineering July 2000


   - LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be
   associated with any LSPs contained in or containing it via the
   MPLSLSPinLSP association.

   - Resource profile: A resource profile (MPLSResourceProfile)
   describing the resource profile of an LSP can be defined for every
   LSP and associated with it via the MPLSRouteResourceProfile
   association.

   - Route hops: Every known hop in an LSP is represented by an
   instance of ProtocolEndpoint (from the CIM information model; see
   [10]) and is associated with an LSP via the MPLSHopInRoute
   association.

   - Autonomous systems in LSP path: If the path of an LSP through an
   external autonomous system is unknown, this autonomous system is
   represented by an instance of AutonomousSystem (from the CIM
   information model; see [10]) and is associated with an LSP via the
   MPLSASInRoute association.


3.2.1.3 Referencing route specifications

   The following objects may need to be instantiated in order to fully
   describe a route specification referenced by an action:

   - LSPs: Zero or more LSPs (MPLSLSP) can be associated with a route
   specification to indicate that these LSPs are realizations of the
   route specification. The association is modeled by the MPLSRealizes
   association.

   - Traffic trunks: Traffic trunks (MPLSTrafficTrunk) for which a
   given route specification is a potential route should be associated
   with the route specification via the MPLSEligibleRouteSpec
   association.

   - Resource profile: A resource profile (MPLSResourceProfile)
   describing the resource profile of a route specification can be
   defined for every route specification and associated with it via the
   MPLSRouteResourceProfile association.

   - Route hops: Every hop specified for a route specification is
   represented by an instance of ProtocolEndpoint (from the CIM
   information model; see [10]) and is associated with a route
   specification via the MPLSHopInRoute association.

   - Autonomous systems in route path: If a route specification is to
   be routed via an specified autonomous sytem, this autonomous system
   is represented by an instance of AutonomousSystem (from the CIM
   information model; see [10]) and is associated with a route
   specification via the MPLSASInRoute association.



Chadha                   Expires January 2001                       12

        Policy Information Model for MPLS Traffic Engineering July 2000


3.2.2   Traffic trunks, LSPs, and supporting object classes and
     associations

   The following object classes and associations are defined. Many of
   these are referenced by the actions described in the previous
   section.

   - Traffic trunk (object class MPLSTrafficTrunk): For a description
   of a traffic trunk, see the Introduction section of this document,
   or see RFC 2702 [3] for more details. The attributes of a traffic
   trunk are described by the properties of this object class. A
   traffic trunk can be associated with LSPs that are currently
   carrying its traffic (MPLSCurrentlyAssignedLSP association) and with
   backup LSPs that are used for backup in fault/congestion scenarios
   (MPLSBackupLSP association). Eligible routes for this traffic trunk
   are associated with it via the MPLSEligibleRouteSpec association. If
   a traffic trunk going in the reverse direction exists, it is
   associated with this traffic trunk via the MPLSReverseDirTT
   association. Finally, a traffic profile for this traffic trunk can
   be represented by the qosPolicyPRTrfcProf object class (reused from
   QPIM [6]) and associated with the traffic trunk via the
   MPLSTrafficProfile association.

   - Abstract route (object class MPLSRoute): This is an abstract
   object class that represents a route from point A to point B. The
   route may or may not be realized in the network by an LSP. In other
   words, a route could either be a specification of a route from one
   point to another, or it could be an actual LSP that has been set up
   in the network. A route is associated with all the hops contained in
   this route. These hops could either be interfaces on LSRs
   (represented by instances of ProtocolEndpoint, which is an object
   class defined in the CIM Network Model [10]), or they could be
   autonomous systems (represented by instances of AutonomousSystem,
   another object class defined in the CIM Network Model [10]). The
   associations with these hops are realized via the MPLSHopInRoute and
   MPLSASInRoute associations, respectively. A route may also be
   associated with a resource profile (represented by object class
   MPLSResourceProfile, defined in this draft) which describes the
   resource profile for this route, i.e. the allowable traffic rates
   and burst sizes, etc. (MPLSRouteResourceProfile association).

   - Route specification (object class MPLSRouteSpec): This object
   class is used to describe a specification of a route from one node
   to another and is derived from the MPLSRoute object class described
   above. The difference between an MPLSRouteSpec and an MPLSLSP is
   that the former is not necessarily a physically created LSP; rather,
   it is a specification of a route that could be used by a management
   system to create an actual LSP (for rerouting or backup purposes).
   Also note that it could be an incomplete specification of a route;
   e.g. it could specify three hops for a route which actually requires
   at least four hops, and leave the job of choosing the missing hop to
   a signaling protocol that sets up the corresponding LSP. Its
   properties are inherited from MPLSRoute and are a subset of the

Chadha                   Expires January 2001                       13

        Policy Information Model for MPLS Traffic Engineering July 2000


   properties in MPLSLSP. An LSP can be created based on a route
   specification using the MPLSCreateLSPAction.

   The typical use of this object class is for a network operator to be
   able to specify potential MPLS routes in advance and later
   instantiate them by creating LSPs that use this specification. A
   route specification can be associated with a traffic trunk to
   indicate that this is a potential route to which this traffic trunk
   can be mapped (MPLSEligibleRouteSpec association).

   - Label-Switched Path (LSP) (object class MPLSLSP): This object
   class represents an LSP. An LSP can be associated with a route
   specification in order to indicate that this LSP implements this
   route specification (MPLSRealizes association). An LSP can also be
   associated with a traffic trunk if it is currently carrying the
   traffic for this traffic trunk (via the MPLSCurrentlyAssignedLSP
   association) or if it is a backup LSP for this traffic trunk (via
   the MPLSBackupLSP association). An LSP can also be associated with
   another LSP to indicate a hierarchy of LSPs (MPLSLSPinLSP
   association).

   - Resource profile (object class MPLSResourceProfile): This object
   class represents the resource profile associated with a route, i.e.
   the allowable traffic rates and burst sizes, etc.

   - Resources (object class MPLSResources): This object class
   represents resources associated with LSRs and interfaces on these
   LSRs, such as buffer resources, etc. (MPLSSystemResources and
   MPLSEndpointResources associations, respectively).

   - Links and their resources (association MPLSActiveConnection): The
   resources associated with a link (e.g. bandwidth, etc.) are
   represented by properties of the association MPLSActiveConnection.
   This association is used to relate two instances of ProtocolEndpoint
   that currently have an active connection between them.

   Apart from these newly defined object classes and associations, the
   qosPolicyPRAction object class is reused from QPIM [6] for
   representing policing actions including actions to be taken for non-
   conforming traffic. Also, object classes qosPolicySimpleCondition,
   qosPolicyVariable, and qosPolicyValue and their derived classes from
   QPIM are used for representing classifier information.


4. Detailed Description of MPLS Traffic Engineering Policy Information
   Model

   This section provides a detailed description of all the newly
   defined object classes and associations in this information model,
   along with their properties.


4.1 Object Class MPLSActivateTTAction

Chadha                   Expires January 2001                       14

        Policy Information Model for MPLS Traffic Engineering July 2000



   This object class represents a policy action (see [5]) that creates
   an instance of a traffic trunk by assigning it to a traffic flow
   (referred to as "activation" of a traffic trunk in [3]). Note that a
   traffic trunk must first be established or defined by creating an
   instance of MPLSTrafficTrunk and related objects/associations (see
   Section 3.2.1.1 for details). RFC 2702 [3] describes the difference
   between establishing a traffic trunk (which we model by creating an
   instance of MPLSTrafficTrunk and related classes as described in
   Section 3.2.1.1) and activating a traffic trunk (which is modeled by
   the MPLSActivateTTAction). The class definition is as follows:

        NAME             MPLSActivateTTAction
        DESCRIPTION      A class used to describe a policy action that
                         activates a traffic trunk.
        DERIVED FROM     policyAction (defined in [5])
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpTrafficTrunk


4.1.1   The property Name

   Name of the action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action.
        SYNTAX           string
    

4.1.2   The property mpTrafficTrunk

   This property contains a reference to an instance of
   MPLSTrafficTrunk. The semantics are that this policy action assigns
   the traffic described in the condition portion of the corresponding
   policy rule to this traffic trunk. The condition portion of the
   containing policy rule would describe the FECs that are mapped to
   this traffic trunk by using instances of qosPolicySimpleCondition
   (from QPIM [6]). Note that the instance of MPLSTrafficTrunk that is
   referenced can be re-used as it can be referenced by multiple policy
   actions.

   The property definition is as follows:

        NAME             mpTrafficTrunk
        DESCRIPTION      Traffic trunk associated with traffic
                         described in the policy rule to which this
                         action belongs
        SYNTAX           Reference to an MPLSTrafficTrunk



Chadha                   Expires January 2001                       15

        Policy Information Model for MPLS Traffic Engineering July 2000


4.2 Object Class MPLSCreateLSPAction

   This class is used to create an LSP. Note that a route specification
   must first be defined by creating an instance of MPLSRouteSpec and
   related objects/associations (see Section 3.2.1.3 for details).

        NAME             MPLSCreateLSPAction
        DESCRIPTION      A class that represents an action that
                         creates an MPLS LSP.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpCreateLSP


4.2.1   The property Name

   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action
        SYNTAX           string
    

4.2.2   The property mpCreateLSP

   This property contains a reference to an MPLSRouteSpec according to
   whose specifications an LSP is to be created.

   The property definition is as follows:

        NAME             mpCreateLSP
        DESCRIPTION      Specification of LSP to be created
        SYNTAX           Reference to an instance of MPLSRouteSpec
    

4.3 Object Class MPLSDestroyLSPAction

   This class is used to represent the action of tearing down an LSP
   and reclaiming all the resources allocated to it.

        NAME             MPLSDestroyLSPAction
        DESCRIPTION      A class that represents an action that
                         destroys an LSP.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpLSP


4.3.1   The property Name

Chadha                   Expires January 2001                       16

        Policy Information Model for MPLS Traffic Engineering July 2000



   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action.
        SYNTAX           string


4.3.2   The property mpLSP

   This property is a reference to the instance of MPLSLSP that is to
   be torn down.

   The property definition is as follows:

        NAME             mpLSP
        DESCRIPTION      Reference to LSP being destroyed.
        SYNTAX           Reference to an instance of MPLSLSP


4.4 Object Class MPLSDestroyTTAction

   This class is used to represent the action of tearing down a traffic
   trunk and reclaiming all the resources allocated to it. This does
   not mean that the LSP(s) assigned to this trunk will be torn down;
   rather, such LSPs will have more resources available for carrying
   alternate traffic.

        NAME             MPLSDestroyTTAction
        DESCRIPTION      A class that represents an action that
                         destroys a traffic trunk.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpTrafficTrunk


4.4.1   The property Name

   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action.
        SYNTAX           string


4.4.2   The property mpTrafficTrunk



Chadha                   Expires January 2001                       17

        Policy Information Model for MPLS Traffic Engineering July 2000


   This property is a reference to the instance of MPLSTrafficTrunk
   that is to be torn down.

   The property definition is as follows:

        NAME             mpTrafficTrunk
        DESCRIPTION      Reference to traffic trunk being destroyed.
        SYNTAX           Reference to an instance of MPLSTrafficTrunk


4.5 Object Class MPLSModifyTTAction

   This class is used to modify a traffic trunk. Note that the traffic
   trunk is assumed to have been defined by creating an instance of
   MPLSTrafficTrunk and related objects/associations (see Section
   3.2.1.1 for details).

        NAME             MPLSModifyTTAction
        DESCRIPTION      A class that represents an action that
                         modifies an MPLS traffic trunk.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpTrafficTrunk


4.5.1   The property Name

   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action
        SYNTAX           string
    

4.5.2   The property mpTrafficTrunk

   This property contains a reference to an MPLSTrafficTrunk that is to
   be modified.

   The property definition is as follows:

        NAME             mpTrafficTrunk
        DESCRIPTION      Reference to traffic trunk to be modified
        SYNTAX           Reference to an instance of MPLSTrafficTrunk


4.6 Object Class MPLSAssignLSPAction

   This class is used to represent the action of assigning an LSP to a
   traffic trunk. Note that the traffic trunk and LSP are assumed to

Chadha                   Expires January 2001                       18

        Policy Information Model for MPLS Traffic Engineering July 2000


   have been defined by creating instances of MPLSTrafficTrunk and
   MPLSLSP, respectively, as well as related objects/associations (see
   Sections 3.2.1.1 and 3.2.1.2 for details).

        NAME             MPLSAssignLSPAction
        DESCRIPTION      A class that represents an action that
                         assigns an LSP to a traffic trunk.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpTrafficTrunk
                         mpAssignedLSP


4.6.1   The property Name

   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action.
        SYNTAX           string


4.6.2   The property mpTrafficTrunk

   This property contains a reference to an instance of
   MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is
   referenced can be re-used as it can be referenced by multiple policy
   actions.

   The property definition is as follows:

        NAME             mpTrafficTrunk
        DESCRIPTION      Traffic trunk to which an LSP is being
                         assigned
        SYNTAX           Reference to an MPLSTrafficTrunk


4.6.3   The property mpAssignedLSP

   This property is a reference to an instance of MPLSLSP. The
   semantics here are that the traffic trunk referenced within this
   action is to be sent over the referenced LSP.

   The property definition is as follows:

        NAME             mpAssignedLSP
        DESCRIPTION      Reference to LSP being assigned to a traffic
                         trunk
        SYNTAX           Reference to an instance of MPLSLSP


Chadha                   Expires January 2001                       19

        Policy Information Model for MPLS Traffic Engineering July 2000



4.7 Object Class MPLSDeassignLSPAction

   This class is used to represent the action of de-assigning an LSP
   from a traffic trunk, i.e. if the traffic belonging to a traffic
   trunk was being sent over a given LSP, this action stops any further
   traffic from this traffic trunk from being sent over this LSP. Note
   that the traffic trunk and LSP are assumed to have been defined by
   creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as
   well as related objects/associations (see Sections 3.2.1.1 and
   3.2.1.2 for details).

        NAME             MPLSDeassignLSPAction
        DESCRIPTION      A class that represents an action that
                         de-assigns an LSP from a traffic trunk.
        DERIVED FROM     PolicyAction
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpTrafficTrunk
                         mpDeassignedLSP


4.7.1   The property Name

   Name for this action.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this action.
        SYNTAX           string


4.7.2   The property mpTrafficTrunk

   This property contains a reference to an instance of
   MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is
   referenced can be re-used as it can be referenced by multiple policy
   actions.

   The property definition is as follows:

        NAME             mpTrafficTrunk
        DESCRIPTION      Traffic trunk for which an LSP is being
                         de-assigned
        SYNTAX           Reference to an MPLSTrafficTrunk


4.7.3   The property mpDeassignedLSP

   This property is a reference to an instance of MPLSLSP. The
   semantics here are that the traffic trunk referenced within this


Chadha                   Expires January 2001                       20

        Policy Information Model for MPLS Traffic Engineering July 2000


   action is assumed to be currently transported by the referenced LSP
   and is no longer to be sent over this LSP.

   The property definition is as follows:

        NAME             mpDeassignedLSP
        DESCRIPTION      Reference to LSP being de-assigned from a
                         traffic trunk
        SYNTAX           Reference to an instance of MPLSLSP


4.8 Object Class MPLSTrafficTrunk

   This object class is used to represent an MPLS traffic trunk and its
   properties. A traffic trunk is an aggregation of traffic flows of
   the same class which are placed inside an LSP (or more than one
   LSPs, in the case of load balancing). Essentially, a traffic trunk
   is an abstract representation of traffic to which specific
   characteristics can be associated.

   This class contains properties describing attributes that can be
   associated with traffic trunks to influence their behavioral
   characteristics. Several of these attributes are drawn from RFC 2702
   [3]. The class definition is as follows:

        NAME             MPLSTrafficTrunk
        DESCRIPTION      A class with several properties for
                         describing an MPLS traffic trunk.
        DERIVED FROM     LogicalElement
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpResourceClassAffinity
                         mpPreemption
                         mpPriority
                         mpResilience
                         mpTrafficProportion
                         mpReoptimizationFreq


4.8.1   The property Name

   Name for this traffic trunk.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this traffic trunk.
        SYNTAX           string


4.8.2   The property mpResourceClassAffinity



Chadha                   Expires January 2001                       21

        Policy Information Model for MPLS Traffic Engineering July 2000


   This property represents the resource class affinity attributes (see
   [3]) associated with a traffic trunk which can be used to specify
   the class of resources that are to be explicitly included or
   excluded from the path of the traffic trunk (the property
   mpResourceClass, which appears in object class MPLSResources and in
   association MPLSActiveConnection, describes the "class" that a
   resource belongs to). The mpResourceClassAffinity property contains
   a list of policy attributes which can be used to impose additional
   constraints on the path traversed by a given traffic trunk.  The
   resource class affinity property for a traffic trunk contains a
   string of the form:

       

   The "resource-class" parameter in the above identifies a resource
   class for which an affinity relationship is defined with respect to
   the traffic trunk. The "affinity" parameter above is a boolean value
   that indicates the affinity relationship; that is, whether members
   of the resource class are to be included or excluded from the path
   of the traffic trunk. The value "true" signifies explicit inclusion,
   and the value "false" specifies explicit exclusion.

   If no resource class affinity attributes are specified, then a
   "don't care" affinity relationship is assumed to hold between the
   traffic trunk and all resources. That is, there is no requirement to
   explicitly include or exclude any resources from the traffic trunk's
   path. This should be the default in practice.

   Resource class affinity attributes are very useful and powerful
   constructs because they can be used to implement a variety of
   policies. For example, they can be used to contain certain traffic
   trunks within specific topological regions of the network.

   A "constraint-based routing" framework (see [3]) can be used to
   compute an LSP for a traffic trunk subject to resource class
   affinity constraints in the following manner:

      1. For explicit inclusion, prune all resources not belonging
         to the specified classes before performing LSP computation.

      2. For explicit exclusion, prune all resources belonging to the
         specified classes before performing LSP computation.

   The property definition is as follows:

        NAME             mpResourceClassAffinity
        DESCRIPTION      String containing resource class affinities
        SYNTAX           string


4.8.3   The property mpPreemption



Chadha                   Expires January 2001                       22

        Policy Information Model for MPLS Traffic Engineering July 2000


   The preemption attribute (see [3]) determines whether a traffic
   trunk can preempt another traffic trunk from a given path, and
   whether it can be preempted by another traffic trunk. Preemption can
   used to assure that high priority traffic trunks can always be
   routed through relatively favorable paths within a differentiated
   services environment. Preemption can also be used to implement
   various prioritized restoration policies following fault events.

   The preemption property can take one of four values, with the
   following semantics:
        1. preemptor-enabled: can preempt lower priority preemptable
           traffic trunks
        2. non-preemptor: cannot preempt other traffic trunks
        3. preemptable: can be preempted by higher priority preemptor-
           enabled traffic trunks
        4. non-preemptable: cannot be preempted.

   It is trivial to see that some of the preempt modes are mutually
   exclusive. Using the numbering scheme depicted above, the feasible
   preempt mode combinations for a given traffic trunk are as follows:
   (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be
   the default.

   A traffic trunk, say "A", can preempt another traffic trunk, say
   "B", only if *all* of the following five conditions hold:
        1. "A" has a relatively higher priority than "B"
        2. "A" contends for a resource utilized by "B"
        3. The resource cannot concurrently accommodate "A" and "B"
           based on certain decision criteria
        4. "A" is preemptor enabled
        5. "B" is preemptable.

   Preemption is not considered a mandatory attribute under the current
   best effort Internet service model, although it may be useful.
   However, in a differentiated services scenario, the need for
   preemption becomes more compelling. Moreover, in the emerging
   optical internetworking architectures, where some protection and
   restoration functions may be migrated from the optical layer to data
   network elements (such as gigabit and terabit label switching
   routers) to reduce costs, preemptive strategies can be used to
   reduce the restoration time for high priority traffic trunks under
   fault conditions.

   The property definition is as follows:

        NAME             mpPreemption
        DESCRIPTION      Contains preemptability information
        SYNTAX           uint16[] (values from 1 to 4)


4.8.4   The property mpPriority



Chadha                   Expires January 2001                       23

        Policy Information Model for MPLS Traffic Engineering July 2000


   The priority of a traffic trunk is described by this property. The
   priority property defines the relative importance of traffic trunks.
   If a constraint-based routing framework is used with MPLS,
   priorities can be used to determine the order in which path
   selection is done for traffic trunks at connection establishment and
   under fault scenarios. Priorities are also important in
   implementations permitting preemption because they can be used to
   impose a partial order on the set of traffic trunks according to
   which preemptive policies can be applied. The priority of a traffic
   trunk, along with its preemptability information (see the
   description of the mpPreemption property in the previous section),
   determines when it will preempt and/or be preempted by other traffic
   trunks.

   The property definition is as follows:

        NAME             mpPriority
        DESCRIPTION      Priority for this traffic trunk.
        SYNTAX           uint16


4.8.5   The property mpResilience

   The mpResilience property indicates the recovery procedure to be
   applied to traffic trunks whose paths are impacted by faults. More
   specifically, it contains a boolean value that determines whether
   the target traffic trunk is to be rerouted or not when segments of
   its path fail.

   Note that RFC 2702 [3] discusses extended resilience attributes that
   could be used to specify detailed actions to be taken when faults
   occur. The representation of such attributes is left for further
   study.

   The property definition is as follows:

        NAME             mpResilience
        DESCRIPTION      If set to true, this traffic trunk should be
                         rerouted in case of failure; if false, it
                         should not.
        SYNTAX           boolean


4.8.6   The property mpTrafficProportion

   This property is used to indicate the relative proportion of traffic
   to be carried by parallel traffic trunks. This enables one to
   perform load distribution across multiple parallel traffic trunks
   between two nodes.  In many practical situations, the aggregate
   traffic between two nodes may be such that no single link can carry
   the load. In this case, the only feasible solution is to
   appropriately divide the aggregate traffic into sub-streams and
   route the sub-streams through multiple paths between the two nodes.

Chadha                   Expires January 2001                       24

        Policy Information Model for MPLS Traffic Engineering July 2000


   This problem can be addressed by instantiating multiple traffic
   trunks between the two nodes, such that each traffic trunk carries a
   proportion of the aggregate traffic. The proportion of traffic
   carried by each such trunk is specified by the mpTrafficProportion
   property.

   The property definition is as follows:

        NAME             mpTrafficProportion
        DESCRIPTION      Proportion of traffic to be carried by this
                         traffic trunk, specified as a percentage from
                         0 to 100.
        SYNTAX           uint16


4.8.7   The property mpReoptimizationFreq

   Due to changes in network and traffic characteristics, there may be
   a need to periodically change the paths of traffic trunks for
   optimization purposes. This should not be done too frequently as
   this could adversely affect the stability of the network. This
   property indicates how often such reoptimization should be
   performed.

   The property definition is as follows:

        NAME             mpReoptimizationFreq
        DESCRIPTION      Indicates how frequently reoptimization should
                         be performed for this traffic trunk. If the
                         value of this property is set to zero, this
                         indicates that reoptimization should not be
                         performed.
        SYNTAX           uint16


4.9 Object Class MPLSRoute

   This object class is used to represent an MPLS route and its
   properties. An MPLS route is an abstract class with two structural
   subclasses, MPLSRouteSpec and MPLSLSP, representing a specification
   of an MPLS route or a concrete LSP respectively. Some of the
   properties of this class have been drawn from the mplsTunnelTable in
   the MPLS Traffic Engineering MIB [8]. The class definition is as
   follows:

        NAME             MPLSRoute
        DESCRIPTION      A class with several properties for
                         describing an MPLS route.
        DERIVED FROM     LogicalElement
        ABSTRACT         true
        PROPERTIES       Name
                         mpIngressIPAddress
                         mpEgressIPAddress

Chadha                   Expires January 2001                       25

        Policy Information Model for MPLS Traffic Engineering July 2000


                         mpCOS
                         mpSignalingProtocol
                         mpSetupPriority
                         mpHoldingPriority
                         mpIngressMayReroute
                         mpIsPersistent
                         mpLocalProtectionAvailable
                         mpIsPinned
                         mpOwner
                         mpInstancePriority
                         mpIsAdaptive
                         mpPreference


4.9.1   The property Name

   The canonical name assigned to the MPLS route.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      MPLS route name
        SYNTAX           string


4.9.2   The property mpIngressIPAddress

   Ingress IP address for this MPLS route.

   The property definition is as follows:

        NAME             mpIngressIPAddress
        DESCRIPTION      Ingress IP address for this MPLS route.
        SYNTAX           string
    

4.9.3   The property mpEgressIPAddress

   Egress IP address for this MPLS route.

   The property definition is as follows:

        NAME             mpEgressIPAddress
        DESCRIPTION      Egress IP address for this MPLS route.
        SYNTAX           string
    

4.9.4   The property mpCOS

   This property defines the class of service for this MPLS route. This
   class of service could represent either a DSCP value or a ToS value.
   Further refinement of this property definition is for further study.


Chadha                   Expires January 2001                       26

        Policy Information Model for MPLS Traffic Engineering July 2000


   The property definition is as follows:

        NAME             mpCOS
        DESCRIPTION      Class of service for MPLS route
        SYNTAX           uint16
        DEFAULT VALUE    0


4.9.5   The property mpSignalingProtocol

   The signaling protocol, if any, used or to be used to set up this
   MPLS route.

   The property definition is as follows:

        NAME             mpSignalingProtocol
        DESCRIPTION      Signaling protocol used or to be used to set
                         up this MPLS route.
        SYNTAX           uint16
        VALUES           none(1), ldp(2), rsvp(3), other(4)
    

4.9.6   The property mpSetupPriority

   Indicates the setup priority of this MPLS route (see [11] and [12]).

   The property definition is as follows:

        NAME             mpSetupPriority
        DESCRIPTION      Indicates the setup priority of this MPLS
                         route.
        SYNTAX           uint16
    

4.9.7   The property mpHoldingPriority

   Indicates the holding priority for this MPLS route (see [11] and
   [12]).

   The property definition is as follows:

        NAME             mpHoldingPriority
        DESCRIPTION      Holding priority for this MPLS route
        SYNTAX           uint16
    

4.9.8   The property mpIngressMayReroute

   This flag indicates that the MPLS route ingress node may choose to
   reroute this MPLS route without tearing it down.

   The property definition is as follows:


Chadha                   Expires January 2001                       27

        Policy Information Model for MPLS Traffic Engineering July 2000


        NAME             mpIngressMayReroute
        DESCRIPTION      Fast reroute enabled
        SYNTAX           boolean


4.9.9   The property mpIsPersistent

   Indicates whether this MPLS route should be restored automatically
   after a failure occurs.

   The property definition is as follows:

        NAME             mpIsPersistent
        DESCRIPTION      Indicates whether this MPLS route is
                         persistent or not
        SYNTAX           boolean
    

4.9.10  The property mpLocalProtectionAvailable

   This flag permits transit routers to use a local repair mechanism
   which may result in violation of the explicit routing of this MPLS
   route. When a fault is detected on an adjacent downstream link or
   node, a transit router can reroute traffic for fast service
   restoration.

   The property definition is as follows:

        NAME             mpLocalProtectionAvailable
        DESCRIPTION      Indicates whether local protection is
                         available
        SYNTAX           boolean
    

4.9.11  The property mpIsPinned

   This flag indicates whether the loose-routed hops of this MPLS route
   are to be pinned (see [11]).

   The property definition is as follows:

        NAME             mpIsPinned
        DESCRIPTION      Indicates whether the route is pinned
        SYNTAX           boolean
    

4.9.12  The property mpOwner

   Indicates which protocol created/should create this route and
   is/should be responsible for managing it.

   The property definition is as follows:


Chadha                   Expires January 2001                       28

        Policy Information Model for MPLS Traffic Engineering July 2000


        NAME             mpOwner
        DESCRIPTION      Indicates which protocol created/should create
                         this route and is/should be responsible for
                         managing it.
        SYNTAX           uint16
        VALUES           snmp (1), ldp (2), rsvp (3),policyAgent (4),
                         other (5)


4.9.13  The property mpInstancePriority

   This value indicates the priority for this route, with zero
   indicating the lowest priority.

   The property definition is as follows:

        NAME             mpInstancePriority
        DESCRIPTION      Route Priority
        SYNTAX           uint16
    

4.9.14  The property mpIsAdaptive

   An MPLS route might need to re-route itself (e.g. due to re-
   optimization, connectivity problems, increase in bandwidth, etc.).
   If an MPLS route is configured to be adaptive, it
        (a) maintains existing resources until a new path is set up
        (b) avoids double-counting for links shared by the old and new
            paths.

   The property definition is as follows:

        NAME             mpIsAdaptive
        DESCRIPTION      A boolean indicating whether an MPLS route is
                         adaptive or not.
        SYNTAX           boolean
        DEFAULT VALUE    true


4.9.15  The property mpPreference

   Multiple MPLS routes may exist between ingress and egress routers;
   the MPLS route with the lowest preference is used (useful for load
   balancing).

   The property definition is as follows:

        NAME             mpPreference
        DESCRIPTION      Preference assigned to an MPLS route.
        SYNTAX           uint16


4.10    Object Class MPLSLSP

Chadha                   Expires January 2001                       29

        Policy Information Model for MPLS Traffic Engineering July 2000



   This object class is used to represent an MPLS LSP and its
   properties. Instances of this class represent existing LSPs in the
   network. The class definition is as follows:

        NAME             MPLSLSP
        DESCRIPTION      A class with several properties for
                         describing an MPLS LSP.
        DERIVED FROM     MPLSRoute
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpAdminStatus
                         mpOperationalStatus
                         mpLevel


4.10.1  The property Name

   This is the canonical name assigned to the LSP. The name may be the
   tunnel ID or may be the name used to refer to the LSP on the LSR's
   console port (see the definition of mplsTunnelName in [8]). This
   definition may need further refinement in subsequent versions of
   this document.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this LSP.
        SYNTAX           string


4.10.2  The property mpAdminStatus

   This property indicates the desired operational status of this LSP.

   The property definition is as follows:

        NAME             mpAdminStatus
        DESCRIPTION      Administrative status of an LSP.
        SYNTAX           uint16
        VALUES           up(1), down(2), testing(3)


4.10.3  The property mpOperationalStatus

   This property indicates the actual operational status of this LSP,
   which is typically (but is not limited to) a function of the state
   of individual segments of this LSP.

   The property definition is as follows:

        NAME             mpOperationalStatus
        DESCRIPTION      Operational status of an LSP.

Chadha                   Expires January 2001                       30

        Policy Information Model for MPLS Traffic Engineering July 2000


        SYNTAX           uint16
        VALUES           up(1), down(2), testing(3), unknown(4),
                         dormant(5), notPresent(6), lowerLayerDown(7)


4.10.4  The property mpLevel

   This property indicates the nesting level of this LSP.

   The property definition is as follows:

        NAME             mpLevel
        DESCRIPTION      LSP nesting level.
        SYNTAX           uint16


4.11    Object Class MPLSRouteSpec

   This object class is used to represent a specification of a
   potential path for routing an MPLS traffic trunk. The difference
   between an MPLSRouteSpec and an MPLSLSP is that the former is not
   necessarily a physically created LSP; rather, it is a specification
   of a route that could be used by a management system to create an
   actual LSP (for rerouting or backup purposes). Its properties are
   inherited from MPLSRoute and are a subset of the properties in
   MPLSLSP.

   An LSP can be created based on a route specification using the
   MPLSCreateLSPAction.

   The class definition is as follows:

        NAME             MPLSRouteSpec
        DESCRIPTION      A class describing an MPLS route
                         specification.
        DERIVED FROM     MPLSRoute
        ABSTRACT         FALSE


4.12    Object Class MPLSResourceProfile

   This object class describes bandwidth resources required or used by
   an MPLS route (recall that an MPLS route is an abstract class and
   can be instantiated either as an MPLS LSP or as an MPLS route
   specification). The properties describing these resources form a
   resource profile and different LSPs/route specifications with the
   same resource profile can reuse the same instance of this object
   class via the MPLSRouteResourceProfile association. The properties
   of this object class are derived from the mplsTunnelResourceTable in
   the MPLS TE MIB [8]. The class definition is as follows:

        NAME             MPLSResourceProfile
        DESCRIPTION      A class with several properties for

Chadha                   Expires January 2001                       31

        Policy Information Model for MPLS Traffic Engineering July 2000


                         describing resources required or used by zero
                         or more MPLS LSPs and/or route specifications.
        DERIVED FROM     Policy
        ABSTRACT         FALSE
        PROPERTIES       Name
                         mpInMaxRate
                         mpInMeanRate
                         mpInMaxBurstSize
                         mpOutMaxrate
                         mpOutMeanRate
                         mpOutMaxBurstSize


4.12.1  The property Name

   Name of this resource profile.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name of this resource profile.
        SYNTAX           string
    

4.12.2  The property mpInMaxRate

   The maximum incoming rate in bits/second.  Note that setting
   mpInMaxRate, mpInMeanRate, and mpInMaxBurstSize to 0 indicates best-
   effort treatment.

   The property definition is as follows:

        NAME             mpInMaxRate
        DESCRIPTION      Maximum incoming rate in bits/second.
        SYNTAX           uint16
    

4.12.3  The property mpInMeanRate

   The mean incoming rate in bits/second.

   The property definition is as follows:

        NAME             mpInMeanRate
        DESCRIPTION      Mean incoming rate in bits/second.
        SYNTAX           uint16
    

4.12.4  The property mpInMaxBurstSize

   The maximum burst size in bytes.

   The property definition is as follows:

Chadha                   Expires January 2001                       32

        Policy Information Model for MPLS Traffic Engineering July 2000



        NAME             mpInMaxBurstSize
        DESCRIPTION      The maximum burst size in bytes.
        SYNTAX           uint16
    

4.12.5  The property mpOutMaxrate

   The maximum outgoing rate in bits/second.  Note that setting
   mpOutMaxRate to 0 indicates best-effort treatment.

   The property definition is as follows:

        NAME             mpOutMaxrate
        DESCRIPTION      The maximum outgoing rate in bits/second.
        SYNTAX           uint16
    

4.12.6  The property mpOutMeanRate

   The mean outgoing rate in bits/second.

   The property definition is as follows:

        NAME             mpOutMeanRate
        DESCRIPTION      The mean outgoing rate in bits/second.
        SYNTAX           uint16
    

4.12.7  The property mpOutMaxBurstSize

   The maximum outgoing burst size in bytes.

   The property definition is as follows:

        NAME             mpOutMaxBurstSize
        DESCRIPTION      The maximum outgoing burst size in bytes.
        SYNTAX           uint16


4.13    Object Class MPLSResources

   This class represents resources associated with LSRs and with
   interfaces on LSRs. The resources described by this class are
   associated with the corresponding LSRs/interfaces via the
   MPLSSystemResources and the MPLSEndpointResources associations,
   respectively.

   The class definition is as follows:

        NAME             MPLSResources
        DESCRIPTION      Resources associated with LSRs and their
                         interfaces

Chadha                   Expires January 2001                       33

        Policy Information Model for MPLS Traffic Engineering July 2000


        ABSTRACT         false
        DERIVED FROM     LogicalElement
        PROPERTIES       Name
                         mpBufferResources
                         mpMaxAllocMultiplier
                         mpResourceClass


4.13.1   The property Name

   Name for this set of resources.

   The property definition is as follows:

        NAME             Name
        DESCRIPTION      Name for this set of resources
        SYNTAX           string


4.13.2   The property mpBufferResources

   Buffer resources for an LSR or an LSR interface.

   The property definition is as follows:

        NAME             mpBufferResources
        DESCRIPTION      Buffer resources.
        SYNTAX           uint16


4.13.3  The property mpMaxAllocMultiplier

   The maximum allocation multiplier (MAM) (see [3]) of a resource
   determines the proportion of the resource that is available for
   allocation to traffic trunks.  This attribute is applicable to
   buffer resources on LSRs. The value of the MAM can be chosen so that
   a resource can be under-allocated or over-allocated. A resource is
   said to be under-allocated if the aggregate demands of all traffic
   trunks that can be allocated to it are always less than the capacity
   of the resource. A resource is said to be over-allocated if the
   aggregate demands of all traffic trunks allocated to it can exceed
   the capacity of the resource.

   The property definition is as follows:

        NAME             mpMaxAllocMultiplier
        DESCRIPTION      Proportion of buffer resources that are
                         available for allocation to traffic trunks.
        SYNTAX           uint16


4.13.4  The property mpResourceClass


Chadha                   Expires January 2001                       34

        Policy Information Model for MPLS Traffic Engineering July 2000


   This property describes the "class" that a resource belongs to (see
   [3]). Thus a resource class can be viewed as a "color" assigned to a
   resource such that the set of resources with the same "color"
   conceptually belongs to the same class. Resource classes can be used
   to implement a variety of policies. From a Traffic Engineering
   perspective, they can be used to implement many policies with regard
   to both traffic and resource oriented performance optimization. For
   example, resource class attributes can be used to apply uniform
   policies to a set of resources; specify the relative preference of
   sets of resources for path placement of traffic trunks; explicitly
   restrict the placement of traffic trunks to specific subsets of
   resources; etc. In general, a resource can be assigned more than one
   resource class attribute. For example, all of the OC-48 links in a
   given network may be assigned a distinguished resource class
   attribute. The subsets of OC-48 links which exist within a given
   domain of the  network may be assigned additional resource class
   attributes in order to implement specific containment policies, or
   to architect the network in a certain manner.

   The property definition is as follows:

        NAME             mpResourceClass
        DESCRIPTION      Resource class(es) that a resource belongs to.
        SYNTAX           uint16[]


4.14    The association MPLSHopInRoute

   The association MPLSHopInRoute provides a way to associate hops with
   MPLSRoutes. Hops are instances of ProtocolEndpoint (from the CIM
   model [10]) and represent LSR interfaces.

   The association definition is as follows:

        NAME             MPLSHopInRoute
        DESCRIPTION      Associates hops with MPLSRoutes
        ABSTRACT         false
        PROPERTIES       mpRoute[ref MPLSRoute[0..n]]
                         mpHop[ref ProtocolEndpoint[0..n]]
                         mpIsStrict
                         mpOrder

4.14.1  The reference mpRoute
    
   This property contains an object reference to an MPLSRoute with
   which a number of hops can be associated. The [0..n] cardinality
   indicates that there may be 0, 1, or more than one MPLSRoutes
   associated with any given hop, indicating that this hop is contained
   in all these routes.


4.14.2  The reference mpHop
    

Chadha                   Expires January 2001                       35

        Policy Information Model for MPLS Traffic Engineering July 2000


   This property contains an object reference to a ProtocolEndpoint
   (representing an LSR interface) that is a hop for an MPLSRoute. The
   [0..n] cardinality indicates that there may be 0, 1, or more than
   one hops associated with any given MPLSRoute. These are all the hops
   that are included in the route specification.


4.14.3  The property mpIsStrict

   Denotes whether the referenced hop is routed in a strict or loose
   fashion.

   The property definition is as follows:

        NAME             mpIsStrict
        DESCRIPTION      Denotes whether the referenced hop is routed
                         in a strict or loose fashion.
        SYNTAX           boolean
    

4.14.4  The property mpOrder

   This property indicates the hop sequence, 1..n.

   The property definition is as follows:

        NAME             mpOrder
        DESCRIPTION      Hop sequence
        SYNTAX           uint16


4.15    The association MPLSASInRoute

   The association MPLSASInRoute provides a way to associate AS hops
   with MPLSRoutes. AS hops are instances of AutonomousSystem (from the
   CIM model [10]) and represent autonomous systems.

   The association definition is as follows:

        NAME             MPLSASInRoute
        DESCRIPTION      Associates AS hops with MPLSRoutes
        ABSTRACT         false
        PROPERTIES       mpRoute [ref MPLSRoute[0..n]]
                         mpHop[ref AutonomousSystem[0..n]]
                         mpIsStrict
                         mpOrder
    

4.15.1  The reference mpRoute
    
   This property contains an object reference to an MPLSRoute with
   which a number of autonomous system hops can be associated. The
   [0..n] cardinality indicates that there may be 0, 1, or more than

Chadha                   Expires January 2001                       36

        Policy Information Model for MPLS Traffic Engineering July 2000


   one MPLSRoutes associated with any given AS hop, indicating that
   this AS hop is contained in all these routes.


4.15.2  The reference mpHop
    
   This property contains an object reference to an AutonomousSystem
   that is a hop for an MPLSRoute. The [0..n] cardinality indicates
   that there may be 0, 1, or more than one AS hops associated with any
   given MPLSRoute. These are all the AS hops that are included in the
   route specification.


4.15.3  The property mpIsStrict

   Denotes whether the referenced AS hop is routed in a strict or loose
   fashion.

   The property definition is as follows:

        NAME             mpIsStrict
        DESCRIPTION      Denotes whether the referenced AS hop is
                         Routed in a strict or loose fashion.
        SYNTAX           boolean
    

4.15.4  The property mpOrder

   This property indicates the AS hop sequence, 1..n.

   The property definition is as follows:

        NAME             mpOrder
        DESCRIPTION      AS hop sequence
        SYNTAX           uint16


4.16    The association MPLSSystemResources

   The association MPLSSystemResources associates a set of resources
   (object class MPLSResources) with an LSR (modeled by an instance of
   ComputerSystem as defined in the CIM model [13]).

   The association definition is as follows:

        NAME             MPLSSystemResources
        DESCRIPTION      Associates MPLS resources with an LSR.
        ABSTRACT         false
        PROPERTIES       mpResources[ref MPLSResources [0..1]]
                         mpLSR [ref ComputerSystem[0..n]]


4.16.1  The reference mpResources

Chadha                   Expires January 2001                       37

        Policy Information Model for MPLS Traffic Engineering July 2000


    
   This property contains an object reference to an MPLSResources
   instance to which zero or one ComputerSystems (representing LSRs)
   can be associated. The [0..1] cardinality indicates that there may
   be zero or one instances of MPLSResources associated with any given
   LSR.


4.16.2  The reference mpLSR
    
   This property contains an object reference to a ComputerSystem
   (representing an LSR) that is associated with MPLSResources. The
   [0..n] cardinality indicates that there may be 0, 1, or more than
   one LSRs associated with any given MPLSResources instance. These
   LSRs all have the same resource specifications.


4.17    The association MPLSEndpointResources

   The association MPLSEndpointResources associates a set of resources
   (object class MPLSResources) with an interface of an LSR (modeled by
   an instance of ProtocolEndpoint as defined in the CIM model [10]).

   The association definition is as follows:

        NAME             MPLSEndpointResources
        DESCRIPTION      Associates MPLS resources with an interface
                         of an LSR.
        ABSTRACT         false
        PROPERTIES       mpResources[ref MPLSResources [0..1]]
                         mpPE [ref ProtocolEndpoint [0..n]]


4.17.1  The reference mpResources
    
   This property contains an object reference to an MPLSResources
   instance to which zero or one ProtocolEndpoints (representing
   interfaces on LSRs) can be associated. The [0..1] cardinality
   indicates that there may be zero or one instances of MPLSResources
   associated with any given LSR interface.


4.17.2  The reference mpPE
    
   This property contains an object reference to a ProtocolEndpoint
   (representing an LSR interface) that is associated with
   MPLSResources. The [0..n] cardinality indicates that there may be 0,
   1, or more than one LSR interfaces associated with any given
   MPLSResources instance. These LSR interfaces all have the same
   resource specifications.


4.18    The association MPLSActiveConnection

Chadha                   Expires January 2001                       38

        Policy Information Model for MPLS Traffic Engineering July 2000



   The association MPLSActiveConnection associates a ProtocolEndpoint
   with another and represents a link between them. Here
   ProtocolEndpoint (taken from the CIM model [10]) represents an LSR
   interface.

   The association definition is as follows:

        NAME             MPLSActiveConnection
        DESCRIPTION      Represents a link between two LSR interfaces
        ABSTRACT         false
        DERIVED FROM     ActiveConnection (from CIM [10])
        PROPERTIES       mpEndpoint1 [ref ProtocolEndpoint [0..n]]
                         mpEndpoint2 [ref ProtocolEndpoint [0..n]]
                         mpBandwidth
                         mpMaxAllocMultiplier
                         mpResourceClass


4.18.1  The reference mpEndpoint1
    
   This property contains a reference to a ProtocolEndpoint instance
   (representing an LSR interface) to which zero or more
   ProtocolEndpoints (also representing LSR interfaces) can be
   associated, representing a connection between the ProtocolEndpoints.
   The [0..n] cardinality indicates that there may be zero or more
   instances of ProtocolEndpoint associated with any given
   ProtocolEndpoint.


4.18.2  The reference mpEndpoint2
    
   This property contains a reference to a ProtocolEndpoint instance
   (representing an LSR interface) to which zero or more
   ProtocolEndpoints (also representing LSR interfaces) can be
   associated, representing a connection between the ProtocolEndpoints.
   The [0..n] cardinality indicates that there may be zero or more
   instances of ProtocolEndpoint associated with any given
   ProtocolEndpoint.


4.18.3   The property mpBandwidth

   Bandwidth for the link represented by this connection.

   The property definition is as follows:

        NAME             mpBandwidth
        DESCRIPTION      Link bandwidth
        SYNTAX           uint16


4.18.4   The property mpMaxAllocMultiplier

Chadha                   Expires January 2001                       39

        Policy Information Model for MPLS Traffic Engineering July 2000



   The maximum allocation multiplier (MAM) (see [3]) of a resource
   determines the proportion of the resource that is available for
   allocation to traffic trunks.  This attribute is applicable to link
   bandwidth. The values of the MAM can be chosen so that a resource
   can be under-allocated or over-allocated. A resource is said to be
   under-allocated if the aggregate demands of all traffic trunks that
   can be allocated to it are always less than the capacity of the
   resource. A resource is said to be over-allocated if the aggregate
   demands of all traffic trunks allocated to it can exceed the
   capacity of the resource.

   The property definition is as follows:

        NAME             mpMaxAllocMultiplier
        DESCRIPTION      Proportion of link bandwidth that is available
                         for allocation.
        SYNTAX           uint16


4.18.5  The property mpResourceClass

   This property describes the "class" that a resource belongs to. Thus
   a resource class can be viewed as a "color" assigned to a resource
   such that the set of resources with the same "color" conceptually
   belong to the same class. Resource classes can be used to implement
   a variety of policies. From a Traffic Engineering perspective, they
   can be used to implement many policies with regard to both traffic
   and resource oriented performance optimization. For example,
   resource class attributes can be used to apply uniform policies to a
   set of resources; specify the relative preference of sets of
   resources for path placement of traffic trunks; explicitly restrict
   the placement of traffic trunks to  specific subsets of resources;
   etc. In general, a resource can be assigned more than one resource
   class attribute. For example, all of the OC-48 links in a given
   network may be assigned a distinguished resource class attribute.
   The subsets of OC-48 links which exist within a given domain of the
   network may be assigned additional resource class attributes in
   order to implement specific containment policies, or to architect
   the network in a certain manner.

   The property definition is as follows:

        NAME             mpResourceClass
        DESCRIPTION      Resource class assigned to this link.
        SYNTAX           uint16[]


4.19    The association MPLSReverseDirTT

   The association MPLSReverseDirTT associates an MPLS traffic trunk
   with a traffic trunk going in the reverse direction.


Chadha                   Expires January 2001                       40

        Policy Information Model for MPLS Traffic Engineering July 2000


   The association definition is as follows:

        NAME             MPLSReverseDirTT
        DESCRIPTION      Associates a traffic trunk with another going
                         in the reverse direction.
        ABSTRACT         false
        PROPERTIES       mpTT1 [ref MPLSTrafficTrunk [0..1]]
                         mpTT2 [ref MPLSTrafficTrunk [0..1]]


4.19.1  The reference mpTT1
    
   This property contains an object reference to an MPLSTrafficTrunk
   instance to which zero or one MPLSTrafficTrunks can be associated.
   An MPLSReverseDirTT association between two traffic trunks
   represents the fact that these traffic trunks carry traffic in
   opposite directions. The [0..1] cardinality indicates that there may
   be zero or one instances of MPLSTrafficTrunk associated with any
   given MPLSTrafficTrunk.


4.19.2  The reference mpTT2
    
   This property contains an object reference to an MPLSTrafficTrunk
   instance to which zero or one MPLSTrafficTrunks can be associated.
   An MPLSReverseDirTT association between two traffic trunks
   represents the fact that these traffic trunks carry traffic in
   opposite directions. The [0..1] cardinality indicates that there may
   be zero or one instances of MPLSTrafficTrunk associated with any
   given MPLSTrafficTrunk.


4.20    The association MPLSEligibleRouteSpec

   The association MPLSEligibleRouteSpec associates a MPLS traffic
   trunk with a route specification that is a potential route for this
   traffic trunk.

   The association definition is as follows:

        NAME             MPLSEligibleRouteSpec
        DESCRIPTION      Associates a traffic trunk with a route
                         specification that is a potential route for
                         this traffic trunk.
        ABSTRACT         false
        PROPERTIES       mpTT [ref MPLSTrafficTrunk [0..n]]
                         mpRoute [ref MPLSRouteSpec [0..n]]
                         mpPreference
                         mpIsMandatory


4.20.1  The reference mpTT
    

Chadha                   Expires January 2001                       41

        Policy Information Model for MPLS Traffic Engineering July 2000


   This property contains an object reference to an MPLSTrafficTrunk
   instance associated with an MPLSRouteSpec. The [0..n] cardinality
   indicates that there may be zero or more instances of
   MPLSTrafficTrunk associated with any given MPLSRouteSpec; i.e. zero
   or more traffic trunks may share the same route specification,
   indicating that this route specification is an eligible route for
   these traffic trunks.


4.20.2  The reference mpRoute
    
   This property contains an object reference to an MPLSRouteSpec that
   is associated with an MPLSTrafficTrunk. The [0..n] cardinality
   indicates that there may be 0, 1, or more than one MPLSRouteSpecs
   associated with any given MPLSTrafficTrunk instance; i.e. any
   traffic trunk can have multiple eligible route specifications.


4.20.3  The property mpPreference

   This property represents the preference for the referenced route by
   the referenced traffic trunk.

   The property definition is as follows:

        NAME             mpPreference
        DESCRIPTION      Preference for the referenced route for the
                         referenced traffic trunk.
        SYNTAX           uint16


4.20.4  The property mpIsMandatory

   Indicates whether this is a mandatory route for this traffic trunk
   or not.

   The property definition is as follows:

        NAME             mpIsMandatory
        DESCRIPTION      Indicates whether this is a mandatory route
                         for this traffic trunk or not.
        SYNTAX           boolean


4.21    The association MPLSCurrentlyAssignedLSP

   The association MPLSCurrentlyAssignedLSP associates the LSP to which
   a traffic trunk is assigned with that traffic trunk.

   The association definition is as follows:

        NAME             MPLSCurrentlyAssignedLSP
        DESCRIPTION      Associates a traffic trunk with the LSP

Chadha                   Expires January 2001                       42

        Policy Information Model for MPLS Traffic Engineering July 2000


                         assigned to it.
        ABSTRACT         false
        PROPERTIES       mpTT [ref MPLSTrafficTrunk [0..n]]
                         mpLSP [ref MPLSLSP [0..n]]


4.21.1  The reference mpTT
    
   This property contains an object reference to an MPLSTrafficTrunk
   instance to which zero or more MPLSLSPs can be associated. An
   MPLSCurrentlyAssignedLSP association between a traffic trunk and an
   LSP represents the fact that this LSP is currently carrying the
   traffic for this traffic trunk. The [0..n] cardinality indicates
   that there may be zero or more instances of MPLSTrafficTrunk
   associated with any given MPLSLSP, i.e. an LSP could be carrying
   traffic for zero or more traffic trunks.


4.21.2  The reference mpLSP
    
   This property contains an object reference to an MPLSLSP instance to
   which zero or more MPLSTrafficTrunks can be associated. An
   MPLSCurrentlyAssignedLSP association between a traffic trunk and an
   LSP represents the fact that this LSP is currently carrying the
   traffic for this traffic trunk. The [0..n] cardinality indicates
   that there may be zero or more instances of MPLSLSP associated with
   any given MPLSTrafficTrunk, i.e. these LSPs are sharing the traffic
   load for this traffic trunk.


4.22    The association MPLSBackupLSP

   The association MPLSBackupLSP associates a backup LSP with an MPLS
   traffic trunk. The idea is that this LSP can be used as a backup for
   this traffic trunk if necessary.

   The association definition is as follows:

        NAME             MPLSBackupLSP
        DESCRIPTION      Associates a backup LSP with a traffic trunk.
        ABSTRACT         false
        PROPERTIES       mpTT [ref MPLSTrafficTrunk [0..n]]
                         mpLSP [ref MPLSLSP [0..n]]
                         mpPreference


4.22.1  The reference mpTT
    
   This property contains an object reference to an MPLSTrafficTrunk
   instance with which zero or more MPLSLSPs can be associated. An
   MPLSBackupLSP association between a traffic trunk and an LSP
   represents the fact that this LSP is a backup for this traffic trunk
   and can be used in failure/congestion situations. The [0..n]

Chadha                   Expires January 2001                       43

        Policy Information Model for MPLS Traffic Engineering July 2000


   cardinality indicates that there may be zero or more instances of
   MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP can
   be a backup for zero or more traffic trunks.


4.22.2  The reference mpLSP
    
   This property contains an object reference to an MPLSLSP instance
   with which zero or more MPLSTrafficTrunks can be associated. An
   MPLSBackupLSP association between a traffic trunk and an LSP
   represents the fact that that this LSP is a backup for this traffic
   trunk and can be used in failure/congestion situations. The [0..n]
   cardinality indicates that there may be zero or more instances of
   MPLSLSP associated with any given MPLSTrafficTrunk, i.e. there may
   be zero or more backup LSPs for this traffic trunk.


4.22.3  The property mpPreference

   This property represents the preference for the referenced backup
   LSP by the referenced traffic trunk. In other words, an explicit
   order can be imposed on all the backup LSPs for a traffic trunk to
   indicate a sequence of backup LSPs ordered from most preferred to
   least preferred.

   The property definition is as follows:

        NAME             mpPreference
        DESCRIPTION      Preference for the referenced backup LSP for
                         the referenced traffic trunk.
        SYNTAX           uint16


4.23    The association MPLSRouteResourceProfile

   The association MPLSRouteResourceProfile associates a resource
   profile with an MPLS route.

   The association definition is as follows:

        NAME             MPLSRouteResourceProfile
        DESCRIPTION      Associates a resource profile with an MPLS
                         route.
        ABSTRACT         false
        PROPERTIES       mpResourceProf[ref MPLSResourceProfile [0..1]]
                         mpRoute[ref MPLSRoute [0..n]]


4.23.1  The reference mpResourceProf
    
   This property contains an object reference to an MPLSResourceProfile
   instance associated with an MPLSRoute. The [0..1] cardinality


Chadha                   Expires January 2001                       44

        Policy Information Model for MPLS Traffic Engineering July 2000


   indicates that there may be zero or one instances of
   MPLSResourceProfile associated with any given MPLSRoute.


4.23.2  The reference mpRoute
    
   This property contains an object reference to an MPLSRoute that is
   associated with an MPLSResourceProfile. The [0..n] cardinality
   indicates that there may be 0, 1, or more than one MPLSRoutes
   associated with any given MPLSResourceProfile instance; i.e. zero or
   more MPLSRoutes can share the same resource profile definition.


4.24    The association MPLSRealizes

   The association MPLSRealizes associates an LSP with an MPLS route
   specification (MPLSRouteSpec). Such an association exists if the
   referenced LSP is an implementation of the referenced route
   specification. Recall that a route specification could be loosely or
   strictly specified; an LSP associated to a route specification via
   the MPLSRealizes association satisfies all the constraints laid down
   in this route specification.

   The association definition is as follows:

        NAME             MPLSRealizes
        DESCRIPTION      Associates an LSP with a route specification.
        ABSTRACT         false
        PROPERTIES       mpLSP [ref MPLSLSP [0..n]]
                         mpRouteSpec [ref MPLSRouteSpec [0..n]]


4.24.1  The reference mpLSP
    
   This property contains an object reference to an MPLSLSP instance
   associated with an MPLSRouteSpec. The [0..n] cardinality indicates
   that there may be zero or more instances of MPLSLSP associated with
   any given MPLSRouteSpec; i.e. zero or more LSPs can be a realization
   of the same route specification.


4.24.2  The reference mpRouteSpec
    
   This property contains an object reference to an MPLSRouteSpec that
   is associated with an MPLSLSP. The [0..n] cardinality indicates that
   there may be 0, 1, or more than one MPLSRouteSpecs associated with
   any given MPLSLSP instance; i.e. any LSP can be a realization of
   have zero or more route specifications.


4.25    The association MPLSLSPinLSP



Chadha                   Expires January 2001                       45

        Policy Information Model for MPLS Traffic Engineering July 2000


   The association MPLSLSPinLSP associates an LSP with another LSP and
   indicates a hierachical relationship between the two LSPs.

   The association definition is as follows:

        NAME             MPLSLSPinLSP
        DESCRIPTION      Associates an LSP with another LSP, indicating
                         a hierarchical relationship between the two.
        ABSTRACT         false
        PROPERTIES       mpContainingLSP [ref MPLSLSP [0..n]]
                         mpContainedLSP [ref MPLSLSP [0..n]]


4.25.1  The reference mpContainingLSP
    
   This property contains an object reference to an MPLSLSP instance
   associated with another MPLSLSP. The [0..n] cardinality indicates
   that there may be zero or more instances of MPLSLSP associated with
   other MPLSLSPs via this association, indicating that these LSPs all
   contain the referenced LSP.


4.25.2  The reference mpContainedLSP
    
   This property contains an object reference to an MPLSLSP instance
   associated with another MPLSLSP. The [0..n] cardinality indicates
   that there may be zero or more instances of MPLSLSP associated with
   other MPLSLSPs via this association, indicating that these LSPs are
   all contained in the referenced LSP.


4.26    The association MPLSTrafficProfile

   The association MPLSTrafficProfile associates a traffic trunk with a
   traffic profile, represented by an instance of qosPolicyPRTrfcProf
   (defined in [6]). This traffic profile describes the characteristics
   of the traffic carried by the referenced traffic trunk.

   The association definition is as follows:

        NAME             MPLSTrafficProfile
        DESCRIPTION      Associates a traffic trunk with a traffic
                         profile.
        ABSTRACT         false
        PROPERTIES       mpTT [ref MPLSTrafficTrunk [0..n]]
                         mpTrfcProf[ref qosPolicyPRTrfcProf [0..1]]


4.26.1  The reference mpTT
    
   This property contains an object reference to an MPLSTrafficTrunk
   instance associated with a qosPolicyPRTrfcProf. The [0..n]
   cardinality indicates that there may be zero or more instances of

Chadha                   Expires January 2001                       46

        Policy Information Model for MPLS Traffic Engineering July 2000


   MPLSTrafficTrunk associated with any given qosPolicyPRTrfcProf; i.e.
   zero or more traffic trunks can share the same traffic profile
   specification.


4.26.2  The reference mpTrfcProf
    
   This property contains an object reference to a qosPolicyPRTrfcProf
   that is associated with an MPLSTrafficTrunk. The [0..1] cardinality
   indicates that there may be zero or one traffic profiles associated
   with any given traffic trunk.


5. Usage Examples


5.1 Implementing Olympic Services

   In the following example, the following scenario is depicted:

        -  Manual LSP creation
        -  Manual traffic trunk creation
        -  Manual assignment of LSPs to traffic trunks.

   This should be contrasted with the example in the next section
   (Section 5.2), where a traffic trunk is defined in a policy and LSPs
   are assumed to be created automatically by a traffic engineering
   system based on traffic trunk route specifications and network
   status.

   This example illustrates the use of the information model described
   in this document for representing policies that govern the
   assignment of different classes of traffic to different MPLS LSPs.
   Suppose that an enterprise needs to implement three classes of
   service, gold, silver, and bronze, between a pair of sites.  In this
   scenario, we assume that traffic is marked using IP precedence (ToS)
   bits in the IP header as follows:

        Traffic entitled to gold service is marked with ToS=3
        Traffic entitled to silver service is marked with ToS=2
        Traffic entitled to bronze service is marked with ToS=1.

   Let the two sites be IP subnets 10.1.0.0/16 and 10.2.0.0/16,
   respectively.


5.1.1   MPLS LSP creation

   The first task is to set up the MPLS LSPs for traffic between these
   two sites (note that this step could be performed after the step in
   Section 5.1.2 as well). We will assume that three MPLS LSPs are to
   be created, each with different bandwidth constraints and different
   routing, to carry the three different types of service above:

Chadha                   Expires January 2001                       47

        Policy Information Model for MPLS Traffic Engineering July 2000



        MPLS LSP 1:     Carries gold service traffic
        MPLS LSP 2:     Carries silver service traffic
        MPLS LSP 3:     Carries bronze service traffic.

   To represent the creation of these three LSPs, we define one policy
   rule with three actions:
   - Each action corresponds to the creation of one LSP and is an
   instance of MPLSCreateLSPAction.
   - Each action refers to a route specification (instance of
   MPLSRouteSpec).
   - Each route specification is associated with a resource profile
   (instance of MPLSResourceProfile, association
   MPLSRouteResourceProfile)
   - Each route specification is associated with route hops for this
   route (a hop is an instance of ProtocolEndpoint) via association
   MPLSHopInRoute.

   Thus before defining the three policy actions, we need to define the
   corresponding three route specifications and the associated
   objects/associations.


5.1.1.1 Creation of route specifications

   We depict below the objects and associations that are created to
   represent the route specification for the Gold traffic class. Silver
   and bronze route specifications and the associated objects and
   associations are created in a similar manner. The following figure
   shows the object instances that are created to specify a route
   specification GoldRouteSpec with resource profile
   GoldResourceProfile and three hops, GoldHop1, GoldHop2, and
   GoldHop3. One instance of association MPLSRouteResourceProfile
   (which associates GoldRouteSpec and GoldResourceProfile) and three
   instances of association MPLSHopInRoute (which associate
   GoldRouteSpec with each of GoldHop1, GoldHop2, and GoldHop3) are
   created.

















Chadha                   Expires January 2001                       48

        Policy Information Model for MPLS Traffic Engineering July 2000


                        +-----------------------+
                        |  GoldResourceProfile  |
                        | (instance of          |
                        | MPLSResourceProfile)  |
                        +-----------^-----------+
           GoldRouteResourceProfile |
            (instance of            |
          MPLSRouteResourceProfile) |
                                    |
                        +-----------v---------v--------+
                        | GoldRouteSpec (instance of   |
                        |   MPLSRouteSpec)             |
                        +-^-----------------^--------^-+
                          |                |         |
          GoldHop1InRoute | GoldHop2InRoute|         | GoldHop3InRoute
          (instance of    | (instance of   |         | (instance of
          MPLSHopInRoute) | MPLSHopInRoute)|         | MPLSHopInRoute)
                          |                |         |
                          |                |         |
                          |                |         |
          +---------------v-+  +-----------v-----+  +v----------------+
          |   GoldHop1      |  |  GoldHop2       |  |  GoldHop3       |
          |   (instance of  |  | (instance of    |  | (instance of    |
          |ProtocolEndpoint)|  |ProtocolEndpoint)|  |ProtocolEndpoint)|
          +-----------------+  +-----------------+  +-----------------+

       Figure 5. Gold route specification with resource profile and
                 three hops


5.1.1.2   Creation of LSPs

   Once route specifications for the gold, silver, and bronze traffic
   have been created, the actions to create LSPs corresponding to these
   three route specifications can be instantiated. Assume that the
   previous step created three route specifications named GoldRouteSpec
   (see Figure 5 above), SilverRouteSpec, and BronzeRouteSpec, with the
   obvious semantics. Three actions are then created:

   Action 1: (instance of MPLSCreateLSPAction)
   Name: CreateGoldLSP
   mpCreateLSP: 

   Action 2: (instance of MPLSCreateLSPAction)
   Name: CreateSilverLSP
   mpCreateLSP: 

   Action 3: (instance of MPLSCreateLSPAction)
   Name: CreateBronzeLSP
   mpCreateLSP: 

   These three actions each reference an instance of an MPLSRouteSpec
   object, whose creation was discussed above.

Chadha                   Expires January 2001                       49

        Policy Information Model for MPLS Traffic Engineering July 2000



   The result of implementing the policy rule containing these three
   actions (note that this policy rule would contain no conditions,
   only Actions 1, 2, 3 described earlier) is to create three instances
   of MPLSLSP, namely GoldLSP, SilverLSP, and BronzeLSP (say). Each
   created instance of MPLSLSP will be associated with the hops in its
   path and with the appropriate resource profile. Note that the hops
   in each LSP's path could contain new hops that were not specified in
   the corresponding route specification, if the latter was an
   incomplete specification of the route to be followed by the LSP.
   Each instance of MPLSLSP will also be associated with the instance
   of MPLSRouteSpec that it implements, via the MPLSRealizes
   association. The figure below shows the MPLSLSP GoldLSP created from
   the route specification GoldRouteSpec. Here we assume that the LSP
   has four hops, which include the three hops specified as belonging
   to the route specification GoldRouteSpec and one additional new hop,
   GoldHop4. Instances SilverLSP and BronzeLSP have similar
   associations.




































Chadha                   Expires January 2001                       50

        Policy Information Model for MPLS Traffic Engineering July 2000


                        +-----------------------+
      ------------------>  GoldResourceProfile  |
      |                 | (instance of          |
      |                 | MPLSResourceProfile)  |
      |                 +-----------^-----------+
      |    GoldRouteResourceProfile |
      |     (instance of            |
      |   MPLSRouteResourceProfile) |
      |                             |
      |                 +-----------v---------v--------+
      |                 | GoldRouteSpec (instance of   <---------------
      |                 |   MPLSRouteSpec              |              |
      |                 +^---------------^---------^---+              |
      |                  |               |         |                  |
      |   GoldHop1InRoute|GoldHop2InRoute|         | GoldHop3InRoute  |
      |   (instance of   | (instance of  |         | (instance of     |
      |   MPLSHopInRoute)|MPLSHopInRoute)|         | MPLSHopInRoute)  |
      |                  |               |         |                  |
      |                  |               |         |                  |
      |                  |               |         |                  |
      | +----------------v+  +-----------v-----+  +v----------------+ |
      | |   GoldHop1      |  |  GoldHop2       |  |  GoldHop3       | |
      | |   (instance of  |  | (instance of    |  | (instance of    | |
      | |ProtocolEndpoint)|  |ProtocolEndpoint)|  |ProtocolEndpoint)| |
      | +-----------------+  +-----------------+  +-----------------+ |
      |                   |                |         |                |
      |   GoldHop1InLSP   | GoldHop2InLSP  |         | GoldHop3InLSP  |
      |   (instance of    | (instance of   |         | (instance of   |
      |   MPLSHopInRoute) | MPLSHopInRoute)|         | MPLSHopInRoute)|
      |                   |                |         |                |
      |                   |                |         |                |
      |                   |                |         |                |
      |                 +-v----------------v---------v-+              |
      ------------------> GoldLSP (instance of         <---------------
       GoldLSPProfile   |   MPLSLSP                    | GoldLSPSpec
       (instance of     +--------------^---------------+ (instance of
      MPLSRouteResourceProfile)        |                  MPLSRealizes)
                                       |
                                       |
                                       | GoldHop4InLSP
                                       | (instance of
                                       |  MPLSHopInRoute)
                           +-----------v--------+
                           |  GoldHop4          |
                           | (instance of       |
                           | ProtocolEndpoint)  |
                           +--------------------+

                 Figure 6. Gold LSP and its associations


5.1.2   Policies for traffic trunks


Chadha                   Expires January 2001                       51

        Policy Information Model for MPLS Traffic Engineering July 2000


   Once LSPs have been created for each class of service, the next
   requirement is to create policies that activate traffic trunks that
   will be transported on these LSPs (this step could have been
   performed before the previous one too). The policy rules that are to
   be created for site 1 are:

   Policy Rule 1:
        If (source address is in IP subnet 10.1.0.0/16) and
           (destination address is in IP subnet 10.2.0.0/16) and
           (ToS=3)
        then
           (traffic is assigned to GoldTrunk)

   Policy Rule 2:
        If (source address is in IP subnet 10.1.0.0/16) and
           (destination address is in IP subnet 10.2.0.0/16) and
           (ToS=2)
        then
           (traffic is assigned to SilverTrunk)

   Policy Rule 3:
        If (source address is in IP subnet 10.1.0.0/16) and
           (destination address is in IP subnet 10.2.0.0/16) and
           (ToS=1)
        then
           (traffic is assigned to BronzeTrunk)

   The conditions in each of the above three rules can be represented
   using conditions with variables and values, as described in the
   Policy Framework QoS Information Model (see [6]). The actions are
   described using instances of the MPLSActivateTTAction object class,
   as described in Section 5.1.2.2. To represent the creation of these
   three traffic trunks, we define three policy rules, each with three
   conditions and one action:
   - Each condition is defined to represent the conditions described
   above using the mechanisms discussed in QPIM [6].
   - Each action corresponds to the activation of one traffic trunk and
   is an instance of MPLSActivateTTAction.
   - Each action refers to a traffic trunk (instance of
   MPLSTrafficTrunk).
   - Each traffic trunk is associated with a traffic profile (instance
   of qosPolicyPRTrfcProf, association MPLSTrafficProfile).

   Thus before defining the three policy rules, we need to define the
   corresponding three traffic trunks and the associated traffic
   profiles and associations that will be referenced by the three
   actions of these rules.


5.1.2.1 Creation of traffic trunks

   We depict below the objects and associations that are created to
   represent the traffic trunk for the Gold traffic class. Silver and

Chadha                   Expires January 2001                       52

        Policy Information Model for MPLS Traffic Engineering July 2000


   bronze traffic trunks and the associated objects and associations
   are created in a similar manner. The following figure shows the
   object instances that are created to specify a traffic trunk
   GoldTrunk with traffic profile GoldTrafficProfile. An instance of
   association MPLSTrafficProfile (which associates GoldTrunk and
   GoldTrafficProfile) is created.

                        +-----------------------+
                        |  GoldTrunk            |
                        | (instance of          |
                        | MPLSTrafficTrunk)     |
                        +-----------^-----------+
            GoldTrunkTrafficProfile |
                  (instance of      |
                 MPLSTrafficProfile)|
                                    |
                        +-----------v---------v-------------+
                        | GoldTrafficProfile (instance of   |
                        | qosPolicyPRTrfcProf               |
                        +-^-----------------^--------^------+

           Figure 7. Gold traffic trunk and its traffic profile


5.1.2.2   Activation of traffic trunks

   Once traffic trunks for the gold, silver, and bronze traffic have
   been defined, the actions to activate these three traffic trunks can
   be defined. Assume that the previous step created three traffic
   trunks named GoldTrunk (see Figure 7 above), SilverTrunk, and
   BronzeTrunk, with the obvious semantics. Three actions are then
   created:

   Action 4: (instance of MPLSActivateTTAction)
   Name: CreateGoldTrunk
   mpTrafficTrunk: 

   Action 5: (instance of MPLSActivateTTAction)
   Name: CreateSilverTrunk
   mpTrafficTrunk: 

   Action 6: (instance of MPLSActivateTTAction)
   Name: CreateBronzeLSP
   mpTrafficTrunk: 

   These three actions each reference an instance of an
   MPLSTrafficTrunk object, whose creation was discussed above and
   depicted in Figure 7 (for the GoldTrunk object).

   The three policy rules described at the beginning of Section 5.1.2
   each contain one of the above actions (i.e. Policy Rule 1 contains
   Action 4, Policy Rule 2 contains Action 5, and Policy Rule 3


Chadha                   Expires January 2001                       53

        Policy Information Model for MPLS Traffic Engineering July 2000


   contains Action 6). Policy Rules 1, 2, and 3 also contain the
   conditions described earlier.

   The result of implementing these three policy rules is to activate
   the three traffic trunks described above.


5.1.3   Assignment of LSPs to traffic trunks

   The next requirement is to create policies that assign LSPs to the
   previously activated traffic trunks. The policy rules that are to be
   created for site 1 are:

   Policy Rule 4:
        Send traffic for GoldTrunk over GoldLSP

   Policy Rule 5:
        Send traffic for SilverTrunk over SilverLSP

   Policy Rule 6:
        Send traffic for BronzeTrunk over BronzeLSP

   Note that the above policy rules contain no conditions, only
   actions. The actions are described using instances of the
   MPLSAssignLSPAction object class.

   Action 7:
   Name: AssignGoldLSP
   mpTrafficTrunk: 
   mpAssignedLSP: GoldLSP

   Action 8:
   Name: AssignSilverLSP
   mpTrafficTrunk: 
   mpAssignedLSP: SilverLSP

   Action 9:
   Name: AssignBronzeLSP
   mpTrafficTrunk: 
   mpAssignedLSP: BronzeLSP

   The effect of executing these rules is to assign the appropriate
   LSPs to the desired traffic trunks.


5.2 Creating traffic trunks

   In this example, we demonstrate the use of policies for activating
   traffic trunks and related information. A policy is defined that
   describes the traffic that will belong to this traffic trunk.
   Associated with the traffic trunk is a traffic profile that
   describes the resource requirements for this trunk. Also associated
   with the traffic trunk are one or more route specifications that

Chadha                   Expires January 2001                       54

        Policy Information Model for MPLS Traffic Engineering July 2000


   specify possible ways of routing this traffic trunk through the
   network. Each such route specification has its hops and its resource
   requirements specified. The idea is that a traffic engineering
   module will use these specifications, along with information about
   the current nodes and links in the network, to perform computations
   that will yield a decision about which of the above specified route
   specifications should be used to create LSPs. In other words, not
   all route specifications will necessarily be used to create LSPs.
   The number of LSPs actually created to carry a traffic trunk will
   depend on the network resiliency requirements. Thus backup LSPs
   could be created in situations where high survivability and high
   performance is required, whereas backup LSPs may not be created for
   best-effort traffic. However, in cases of congestion/failures,
   existing route specifications can be used to create new LSPs to
   alleviate/remedy the problem. Route specification attributes are
   used to indicate routing preferences to aid the traffic engineering
   module in deciding which route specifications should be used to
   create LSPs.

   Note that another scenario could be that no route specifications are
   provided by the policy and the traffic engineering module computes
   suitable LSPs based on traffic trunk attributes alone.

   Initially, we assume that the following information is known to the
   management system:

   - All the LSRs in the network (instances of ComputerSystem (defined
     in CIM model [10]))
   - All the MPLS interfaces on these LSRs (instances of
     ProtocolEndpoint (defined in CIM model [10]))
   - All the links between MPLS interfaces on LSRs (instances of
     MPLSActiveConnection).

   The network administrator then defines policies for traffic trunks.
   For example, the following is an example of such a policy:

   If
        source address = 192.8.0.0/16 AND destination address =
        128.5.0.0/16 AND ToS=3
   then
        Assign this traffic to Traffic Trunk TT1 AND
        Police TT1 according to its traffic profile and drop all
        out-of-profile packets.

   All relevant attributes of TT1 must be specified. Related
   information such as a traffic profile TP1 for this traffic trunk
   must also be specified, including all relevant attributes of TP1, so
   that TP1 can be used for policing the traffic trunk. This is
   achieved by instantiating an instance of MPLSTrafficTrunk (named
   TT1), an instance of qosPolicyPRTrfcProf (named TP1), and an
   instance of association MPLSTrafficProfile relating TT1 to TP1.
   Further, TT1 could have a number of MPLSRouteSpec instances
   associated with it using the MPLSEligibleRouteSpec association.

Chadha                   Expires January 2001                       55

        Policy Information Model for MPLS Traffic Engineering July 2000


   These route specifications basically describe possible paths for
   routing the trunk TT1 through the network. The route specifications
   can have associations to ProtocolEndpoint instances (association
   MPLSHopInRoute) that represent LSR interfaces that are hops for the
   route; the route specifications could also have associations to
   AutonomousSystem instances (association MPLSASInRoute) that are hops
   for the route. Thus each route can be loosely or strictly specified.
   Each MPLSRouteSpec has an MPLSResourceProfile instance associated
   with it via the MPLSRouteResourceProfile association. The
   MPLSResourceProfile instance contains information about the
   resources for this route specification, i.e. the average and maximum
   traffic rates and burst sizes.

   The above policy rule is represented using instances of PolicyRule
   (from [5]), qosPolicySimpleCondition (to represent the "if" portion
   of the rule), MPLSActivateTTAction (to represent the action of
   activating this traffic trunk), and qosPolicyPRAction (to represent
   the policing actions described above. The latter object class
   (qosPolicyPRAction ) allows the network operator to specify the
   action to take for non-conforming traffic (e.g. shape, drop, or re-
   mark). In this case, the action to be taken is to drop all non-
   conforming traffic. For details about the usage of
   qosPolicyPRAction, see QPIM [6]. The rule is structured as follows:

   - PolicyRule represents the policy rule described above and contains
   three conditions (three instances of qosPolicySimpleCondition) and
   two actions (instances of MPLSActivateTTAction and
   qosPolicyPRAction).
   - The instances of qosPolicySimpleCondition represent the classifier
   described above, i.e.
        source address = 192.8.0.0/16 AND
        destination address = 128.5.0.0/16 AND
        ToS=3.
   These conditions are represented using instances of
   qosPolicyVariable, qosPolicyIPv4AddrValue, and
   qosPolicyIntegerValue.
   - The instance of MPLSActivateTTAction contains a reference to TT1,
   which is associated with TP1 using association MPLSTrafficProfile,
   as described above.
   - The instance of qosPolicyPRAction (see [6] for details) contains a
   reference to TP1 and specifies that non-conforming traffic should be
   dropped (property qpOutOfProfileAction is set to 1 for DISCARD)
   - TT1 is associated with one or more MPLSRouteSpecs via the
   MPLSEligibleRouteSpec association.
   - Each instance of MPLSRouteSpec may be associated with an instance
   of MPLSResourceProfile (via the MPLSRouteResourceProfile
   association) and with hops that could be ProtocolEndpoints or
   AutonomousSystems (via the MPLSHopInRoute and the MPLSASInRoute
   associations, respectively).

   The above rule is processed by the traffic engineering module as
   described at the beginning of this section.


Chadha                   Expires January 2001                       56

        Policy Information Model for MPLS Traffic Engineering July 2000



5.3 Load balancing

   In order to perform load balancing, a traffic stream between two
   nodes must be assigned to two or more LSPs at the ingress node.
   Policies can be designed to decide how traffic gets partitioned
   across LSPs.

   Assume that a traffic stream is to be load-balanced across two
   existing LSPs. Possible approaches include:

   - Define two parallel traffic trunks between the two nodes and
   assign a different LSP to each traffic trunk. The proportion of the
   traffic stream to be carried by each traffic trunk is specified by
   the mpTrafficProportion property of the MPLSTrafficTrunk object
   class. Thus one could specify that 80% of the traffic is to be
   carried across the first LSP and 20% across the second. This is the
   approach referred to in Section 5.6.5 of RFC 2702.

   - Define one traffic trunk and assign the two LSPs to carry its
   traffic. This will result in the traffic being shared equally by the
   two LSPs.

   From the information modeling perspective, the first option can be
   implemented by activating two instances of MPLSTrafficTrunk with the
   value of the property mpTrafficProportion set to 80 for the first
   trunk and to 20 for the second (using policy action
   MPLSActivateTTAction as described earlier); and subsequently
   assigning an LSP to each of these traffic trunks using the
   MPLSAssignLSPAction as described in the previous example. The second
   option can be implemented by creating one instance of
   MPLSTrafficTrunk (using policy action MPLSActivateTTAction); and
   subsequently assigning two LSPs to this traffic trunk using two
   instances of the MPLSAssignLSPAction.


5.4 Implementing Service Level Agreements (SLAs)

   Suppose a service provider has an SLA with a customer that
   guarantees premium quality of service for that customer during
   business hours (8:00am to 5:00pm) and best-effort service during
   non-business hours. Let's say that the service provider wishes to
   implement this SLA by assigning the customer's traffic during
   business hours to a certain LSP L1 that carries premium traffic; and
   by assigning the customer's traffic during non-business hours to
   another LSP L2 that carries best-effort traffic. Policy rules that
   model this requirement can be specified as follows:

   Policy Rule 1:
   Define and activate traffic trunk for this customer's traffic.

   qosPolicySimpleConditions: 

Chadha                   Expires January 2001                       57

        Policy Information Model for MPLS Traffic Engineering July 2000



   MPLSActivateTTAction: 

   Policy Rule 2:
   Assign premium LSP L1 for business hours

   Condition: The time is between 8:00am - 5:00pm
   Action: Assign LSP L1 to traffic trunk TT1

   This policy is modeled as follows: an instance of
   PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the
   above condition; and an instance of MPLSAssignLSPAction is used to
   model the above action.

   Policy Rule 3:
   Assign best-effort LSP L2 for non-business hours

   Condition: The time is between 5:00pm - 8:00am
   Action: Assign LSP L2 to traffic trunk TT1

   This policy is modeled as follows: an instance of
   PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the
   above condition; and an instance of MPLSAssignLSPAction is used to
   model the above action.


6. Security Considerations

   The security issues inherent in a policy-based management system are
   those of ensuring that only authorized users are allowed to
   manipulate policies, since these policies exert a large degree of
   control over the MPLS network. Such issues must be addressed by the
   implementation of the policy management system.


7. Conclusions

   This document provides a draft information model for policy-enabled
   MPLS network engineering. The authors of this draft would like to
   propose incorporation of this material into working group drafts in
   the mpls and/or policy working groups.


8. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.



Chadha                   Expires January 2001                       58

        Policy Information Model for MPLS Traffic Engineering July 2000



   3  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,
      "Requirements for Traffic Engineering Over MPLS", RFC 2702,
      September 1999.

   4  Li, T. and Y. Rekhter, "Provider Architecture for Differentiated
      Services and Traffic Engineering (PASTE)", RFC 2430, October
      1998.

   5  Moore, B., Ellesson, E. , Strassner, J., "Policy Core Information
      Model -- Version 1 Specification", Internet Draft draft-ietf-
      policy-core-info-model-06.txt, May 2000.

   6  Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., "Policy
      Framework QoS Information Model", Internet Draft draft-ietf-
      policy-qos-info-model-01.txt.

   7  Mahon, H., Bernet, Y., Herzog, S., "Requirements for a Policy
      Management System", Internet Draft draft-ietf-policy-req-01.txt,
      October 1999.

   8  Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Traffic
      Engineering Management Information Base Using SMIv2", Internet
      Draft draft-ietf-mpls-te-mib-03.txt, March 2000.

   9  Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Label Switch
      Router Management Information Base Using SMIv2", Internet Draft
      draft-ietf-mpls-lsr-mib-04.txt, April 2000.

   10 Distributed Management Task Force, Inc., "Common Information
      Model (CIM) Schema, version 2.3, March 2000.  The components of
      the CIM v2.3 schema are available via links on the following DMTF
      web page:  http://www.dmtf.org/spec/cims.html

   11 Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V.,
      Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
      Internet Draft draft-mpls-rsvp-lsp-tunnel-06.txt, July 2000.

   12 Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P.,
      Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Doolan, P.,
      Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E.,
      Halpern, J.,  Heinanen, J., Kilty, T., Malis, A., Vaananen, P.,
      Wu, L., "Constraint-Based LSP Setup using LDP", Internet Draft
      draft-ietf-mpls-cr-ldp-04.txt, July 2000.

   13 Wright, S., Herzog, S., Reichmeyer, F., Jaeger, R., "Requirements
      for Policy Enabled MPLS", Internet Draft draft-wright-policy-
      mpls-00.txt, March 2000.

   14 Wright, S., Reichmeyer, F., Jaeger, R., Gibson, M., "Policy-Based
      Load-Balancing in Traffic-Engineered MPLS Networks", Internet
      Draft draft-wright-mpls-te-policy-00.txt, June 2000.


Chadha                   Expires January 2001                       59

        Policy Information Model for MPLS Traffic Engineering July 2000





9. Acknowledgments

   Many thanks are due to Tony Bogovic, Ravi Vaidyanathan, and George
   Mykoniatis for their insights and careful reviews of this material.


10.     Author's Addresses

   Ritu Chadha
   Telcordia Technologies
   445 South Street
   Morristown NJ 07960
   Phone: +1-973-829-4869
   Email: chadha@research.telcordia.com

   Huai-An (Paul) Lin
   Telcordia Technologies
   445 South Street
   Morristown NJ 07960
   Phone: +1-973-829-2412
   Email: hlin1@telcordia.com






























Chadha                   Expires January 2001                       60

        Policy Information Model for MPLS Traffic Engineering July 2000



  Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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 implmentation 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, INCLUDIN
   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.



























Chadha                   Expires January 2001                       61