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