Internet Draft
INTERNET-DRAFT K. Isoyama
draft-chadha-policy-mpls-te-01.txt M. Brunner
Expires June 2001 M. Yoshida
J. Quittek
NEC Corporation
R. Chadha
G. Mykoniatis
A. Poylisher
R. Vaidyanathan
Telcordia Technologies
A. Kind
IBM
F. Reichmeyer
PfN, Inc.
December 2000
Policy Framework MPLS Information Model for QoS and TE
<draft-chadha-policy-mpls-te-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The purpose of this draft is to describe an information model for
representing MPLS policies, including MPLS for traffic engineering
and QoS. 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 the traffic engineering part of the
information model. The latter document describes the functional
capabilities required to implement policies that facilitate
efficient and reliable network operations in an MPLS domain.
For the QoS-related part, the Policy Framework QoS Information Model
(QPIM) is extended with new classes for controlling and managing the
lifecycle of Label Switched Paths (LSPs) and for mapping of traffic
Chadh, et al. Expires June 2001 [Page 1]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
onto existing LSPs. The control and management of LSP lifecycles
includes mainly the creation, update, and deletion of LSPs and the
assignment of QoS properties to LSPs.
This information model may 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. A detailed description of the information
model and a number of examples illustrating its use follow this.
A UML diagram of this model is available at
http://www.ccrle.nec.de/ietf/MPLS_policy_info_model_01.pdf
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.
Table of Contents
1. Introduction.....................................................3
1.1. Goals..........................................................3
1.2. Terminology....................................................4
2. Motivation for Policy-based Management of MPLS...................5
3. Background.......................................................7
3.1. MPLS concepts and their relation to this model.................7
3.2. Relationship to previous work..................................9
4. Overview of MPLS Policy Information Model.......................11
4.1. Overview of object classes and their associations.............11
4.2. High-level description of information model...................15
4.3. MPLS Policy Variables.........................................19
5. Class Definitions...............................................19
5.1. Class mplsPolicyTTAction......................................19
5.2. Class mplsPolicy_TT_LSPAction.................................20
5.3. Class mplsPolicyLSPAction.....................................21
5.4. Class mplsPolicyCRLSPResvAction...............................22
5.5. Class mplsPolicyCRLDPSignalCtrlAction.........................24
5.6. Class mplsPolicyLSP...........................................26
5.7. Class mplsPolicyFEC...........................................29
5.8. Class mplsPolicyCRLSPTrfcProf.................................30
5.9. Class mplsPolicyTrafficTrunk..................................31
5.10.Class mplsPolicyRouteSpec.....................................35
5.11.Class mplsPolicyProtocolEndpoint..............................36
5.12.Class mplsPolicyResources.....................................36
5.13.Association mplsPolicySystemResources.........................38
5.14.Association mplsPolicyEndpointResources.......................38
5.15.Association mplsPolicyActiveConnection........................39
5.16.Association mplsPolicyHopInRoute..............................41
Chadha, et al. Expires June 2001 [Page 2]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.17.Association mplsPolicyEligibleRouteSpec.......................42
5.18.Association mplsPolicyReverseDirTT............................43
5.19.Association mplsPolicyRealizes................................44
5.20.Association mplsPolicyCurrentlyAssignedLSP....................44
5.21.Association mplsPolicyBackupLSP...............................45
5.22.Association mplsPolicyLSPinLSP................................46
5.23.Association mplsPolicyTT_TrafficProfile.......................47
5.24.Association mplsPolicyLSP_TrafficProfile......................47
5.25.Association mplsPolicyFECofTrunk..............................48
5.26.Association mplsPolicyFECofLSP................................49
5.27.Association mplsPolicyFECFilterSet............................49
6. Examples........................................................50
6.1. Establishing an LSP...........................................50
6.2. Network wide bandwidth adjustment example.....................52
7. Security Considerations.........................................54
8. Open Issues.....................................................54
9. References......................................................55
10. Authors' Addresses.............................................56
1. Introduction
1.1. Goals
The ultimate goal of policy-based networking is to support the trend
away from individual device management, toward managing and
controlling a network as a whole [PCIM]. Policy-based networking
allows network elements from different vendors, equipped with
different capabilities, to be consistently configured according to
network policies. For instance, network policies may be aligned with
the business goals of a company.
MPLS is a combination of switched forwarding with network layer
routing. The added value of MPLS is provided by a better
price/performance ratio of network layer routing, improved
scalability in the network layer, and greater flexibility in the
delivery of routing services [MPLSFW]. These advantages are achieved
with label switching: a packet belongs to a Forwarding Equivalence
Class (FEC). All packets belonging to the same class will get
assigned a MPLS label, when it enters the MPLS network. The label in
the packet can then be used at subsequent hops between ingress and
egress nodes to determine the forwarding treatment by indexing into
a table. All packets belonging to a particular FEC and enter the
network at the same ingress travel the same path through the
network.
Typically, information about bindings of labels to FECs is
distributed by a label distribution protocol (e.g. LDP, CR-LDP, BGP,
RSVP-TE). The use of policies in the context of MPLS is motivated by
the need to provide high-level support for the operation of MPLS
networks beyond a standard way of label distribution with LDP or
other label distribution protocols.
Chadha, et al. Expires June 2001 [Page 3]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
Some of the important applications of MPLS that are foreseen today
are Traffic Engineering (TE), Quality of Service (QoS) support and
MPLS based Virtual Private Networks (VPNs).
According to [RFC2702], 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 [RFC2430], 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.
For QoS support in IP networks, MPLS provides route pinning in order
to guarantee certain services to customers. Therefore, high-level
means for mapping traffic that matches a specific traffic filter
onto an LSP with specific QoS characteristics is needed. Such high-
level policies could be used, for instance, with DiffServ over MPLS
(MPLSDS) [MPLS-DS].
1.2. 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
Chadha, et al. Expires June 2001 [Page 4]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
LDAP Lightweight Directory Access Protocol
LSP Label Switched Path
LSR Label Switched Router
MAM Maximum Allocation Multiplier
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
2. Motivation for Policy-based Management of MPLS
The following is a discussion of the advantages of the policy-based
management approach for MPLS, which is the approach used in this
draft, in comparison to the traditional Internet management
approach.
Policy-based management provides the ability to control the network
as a whole instead of controlling each individual managed object
(network device, interface, queue, LSP) in an independent way. This
is also one of the most important advantages of this approach,
compared to the traditional network management paradigm, especially
in the context of network configuration and provisioning. The reason
for this is that traditional managed objects (typically organized by
MIB trees) are device-level data models, populated in each router,
while the policy information model can be used to represent network-
wide entities (e.g. MPLS traffic trunks,) and can be populated in a
logically centralized repository. However, note that policy-based
management is still possible in a SNMP/MIB based environment. There
are various approaches to do so. The policies addressed in this
draft are meant to be high-level. The low-level mechanisms for
configuration can be implemented with different management
protocols.
The object-oriented policy information model defined in this draft
enables policy-based management of MPLS networks. The advantages of
policy-based management can be realized while performing management
tasks, such as MPLS configuration for traffic engineering. In the
traditional case, the traffic engineering MIB defined in [MPLS-MIB]
provides control of LSP tunnel lifecycles. Consequently, every time
the LSP tunnel network design needs to be changed to support new or
modified network services, or to react to network events, the MIBs
of all the appropriate LSRs have to be modified accordingly.
However, in the policy information model defined in this draft, the
administrator can describe changes to the network in terms of policy
constructs, thus avoiding the micro-management of the individual
LSRs. Also in this case, the policy-based management system may
Chadha, et al. Expires June 2001 [Page 5]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
automatically change the network behavior with whatever mechanism
available.
The policy-based management approach provides a new level of
abstraction that allows network devices from different vendors,
supporting different capabilities, to be consistently configured
according to high-level network policies.
The selection of the specific policy rules to be applied to each
network entity is carried out according to their "role". This
concept, introduced in [PCIM], permits the grouping of the network
entities according to the role they play in the network.
One very useful concept in this draft is the MPLS traffic trunk
[RFC2702]. A traffic trunk represents an aggregation of traffic
flows of the same class, placed inside one or more Label Switched
Paths. Traffic trunks provide a powerful tool for the administrator
or for the automatic traffic engineering module. They can be used to
support efficient administration of the way in which traffic is
handled by the network.
Another important point is the support of DiffServ, which is already
being modeled in a similar fashion [QPIM] and enhanced in order to
support DiffServ over MPLS. Using the policy-based management
approach will obviously simplify the interaction in the context of
configuration and provisioning.
The following example demonstrates some of the points discussed
above. A more detailed description of this example can be found in
section 6. We are considering a network-wide policy that varies
bandwidth allocations based on time of day and type of traffic.
Traffic Trunks (TTs) in the network are assigned "roles" in
accordance with the Olympic Services Model, i.e. they are marked as
"gold", "silver", or "bronze" according to the QoS properties of the
traffic that they carry. A network-wide policy controls the
bandwidth allocation associated with these traffic trunks.
Specifically, the bandwidth for all gold TTs is reduced by 50%
during nights and weekends, which allows traffic in the bronze TTs
to be increased during the same time period. This could be
potentially useful if the Service Level Agreements are such that a
number of customers require gold service during business hours on
weekdays, while they subscribe to lower service levels during non-
business hours and weekends.
To implement the network-wide policy described above, the following
two policy rules are required for the gold TTs:
Policy Rule 1: role is "gold TT"
IF "time is 8am-5pm AND day is Monday to Friday"
THEN "Modify TT: increase bandwidth by 100%"
Policy Rule 2: role is "gold TT"
Chadha, et al. Expires June 2001 [Page 6]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
IF "(time is 5pm-8am AND day is Monday to Friday) OR
(day is Saturday to Sunday)"
THEN "Modify TT: Decrease bandwidth by 50%"
The semantics of the first rule is that when the condition becomes
true, it increases the bandwidth of all the gold TTs by 100%. In a
similar fashion, the semantics of the second rule is that when the
condition becomes true, it decreases the bandwidth of all the gold
TTs by 50%. Note that this is the same absolute amount.
The role of the two policy rules is set to "gold TT", which
indicates which TTs those rules are to be applied to. In this case,
these two rules are applied to all the TTs that are characterized as
"gold_TT".
The above brief example shows how policies can be applied to MPLS
traffic engineering in a network-wide fashion. The above example is
explained in detail with reference to our MPLS policy information
model in Section 6.
3. Background
The model described in this document is based on the Policy
Framework QoS Information Model (QPIM)[QPIM]. QPIM defines classes
for representing QoS policy rules, including QoS policy rule
conditions and QoS policy rule actions. The classes specified in
QPIM address QoS provisioning using Differentiated Services
(DiffServ) as well as QoS control via RSVP for Integrated Services
(IntServ). QPIM itself refines the Policy Core Information Model
(PCIM) [PCIM] which includes generic classes for policy-based
networking.
3.1. MPLS concepts and their relation to this model
A general discussion of issues related to MPLS is presented in the
framework [MPLS-FW] and architecture [MPLS-ARCH] documents. A brief
summary of salient features is provided below as context for the
later sections.
3.1.1.
Label Switched Paths
MPLS uses the concept of a Label Switched Path (LSP), which is used
to carry traffic through the network. An LSP is set up using a
signaling protocol and may or may not be associated with QoS
guarantees. Currently under discussion are [LDP], [CR-LDP], and
[RSVP-TE], where the latter two support setting up LSPs with QoS
guarantees. LSPs can be specified in an explicit or implicit manner.
Explicitly routed LSPs specify the path that the LSP should take.
Depending on whether the entire sequence of hops is specified or
not, the explicit LSP is said to be strictly or loosely routed.
Implicitly routed LSPs require a routing mechanism within the
network, which decides the path they take.
Chadha, et al. Expires June 2001 [Page 7]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
The LSP is thus a basic object that must be modeled in an MPLS
information model. The properties of the LSP depend on what kind of
LSPs are taken into account (explicit vs. implicit, with or without
QoS etc.). For example, for explicitly routed LSPs, the explicit
route for the LSP must also be modeled. Note, however, that the MPLS
labels, which carry local significance, are not part of the
information modeled about an LSP.
3.1.2.
QoS Properties
MPLS in its original fashion has no notion of QoS. However, using
MPLS for appropriate traffic engineering enables an ISP to provide a
relatively higher quality service to its customers. This improvement
in quality is not quantifiable, but is based on the premise that
improved network utilization results in improved service quality.
Further, an LSP may be associated with QoS properties, which need to
be enforced by QoS mechanisms in LSRs via other, non-MPLS means. In
a recent proposal to support DiffServ over MPLS [DS-MPLS] MPLS is
used in conjunction with DiffServ for QoS enforcement. This approach
allows a Label Switched Router (LSR) to apply a specified Per-Hop
Behavior (PHB) to packets of an LSP. In this draft, QoS
specification of LSPs and its signaling is covered, but QoS
enforcement is not addressed (see [QPIM] instead).
3.1.3.
QoS routing for LSPs
The LSP setup process may be constrained by QoS requirements, to
achieve a requisite level of service. Such constraint-based routing
can be realized in one of two ways. In the first approach, a
centralized application, that has knowledge of network-wide QoS
state, could calculate the best route through the network for each
LSP. The centralized application can then initiate the setup of the
LSP, using the explicit route feature of CR-LDP or RSVP-TE to
control the path taken by the LSP. In the second approach, the route
can be calculated in a distributed fashion, during the signaling
process. The MPLS model of this document is transparent to the
different QoS routing issues; it only addresses the specification of
traffic trunks and LSPs with QoS requirements. The mapping of these
requirements to underlying QoS routing mechanisms is out of the
scope of this document.
3.1.4.
Signaling LSPs
Setting up a new LSP requires signaling or configuration mechanisms.
Two basic mechanisms exist for creating LSPs: (1) using a hop-by-hop
signaling protocol like LDP, CR-LDP, or RSVP-TE, or (2) configuring
the LSP using SNMP or COPS.
The mechanisms used for LSP setup are transparent to this draft.
However, certain CR-LDP-specific mechanisms have been included in
this draft (see open issues at the end of this draft). For RSVP
traffic profiles, see [QPIM]. The action to be taken from a policy
Chadha, et al. Expires June 2001 [Page 8]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
server's point of view is to initiate the setup process with means
available in the domain.
3.1.5.
Controlling the Signaling Process
The signaling process for setting up a new LSP may be subject to
different policies or resource constraints. Therefore, we introduce
the mplsPolicyCRLDPSignallingAction as a means to control this
process with policies. In some network operation environments this
will not be needed, if the policy control is applied before the
signaling process in the domain. In others, it is very convenient
for the policy-based management system to define policies for the
signaling process.
3.1.6.
Forwarding Equivalence Classes (FEC)
A Forwarding Equivalence Class (FEC) specifies what traffic is
mapped to a specific traffic trunk and/or LSP. The specification of
FECs can range from very simple, e.g., just the destination IP
address, to very complex, e.g., a set of filters including IP
addresses, ports, DSCPs etc. In our model, we associate an FEC with
an LSP and/or a traffic trunk. The binding of FECs to LSPs and
traffic trunks may be performed during or after the LSP/TT setup.
3.2. Relationship to previous work
3.2.1.
Relationship to PCIM
The object-oriented information model described in PCIM provides
generic classes for representing policy information. The model
allows one to specify network policies in terms of policy rules. A
policy rule contains a list of policy conditions and a list of
policy actions. Conditions are Boolean expressions that evaluate to
either true or false. Actions represent some concrete steps 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.
The MPLS information model described in this draft refines the
notion of policy actions as described in PCIM. New classes are
introduced in order to model the following MPLS-related policy
actions:
- Generic reservation of a Label Switched Path (LSP)
Chadha, et al. Expires June 2001 [Page 9]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
- Generic setup of Traffic Trunk (TT)
- Reservation of a Label Switched Path (LSP) using CR-LDP
- Policy decisions for a CR-LDP message
- Mapping of traffic into a Label Switched Path (LSP).
Furthermore, new policy classes are defined that inherit from the
Policy class in PCIM. The new classes describe:
- Traffic profiles
- Label Switched Paths (LSPs)
- Traffic Trunks
- Forwarding Equivalence Classes (FECs)
- Route Specifications.
3.2.2.
Relationship to QPIM
In the QoS Policy Information Model (QPIM) [QPIM], 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 and LSPs. Other concepts that are re-used from QPIM
are those defining traffic profiles and policing actions (see object
classes qosPolicyPRTrfcProf and qosPolicyPRAction in [QPIM]). 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).
QPIM lists a set of pre-defined variables that are typically
required for layers 2 and 3. This draft extends the list of
predefined variables to access the label entries on the label stack
of an MPLS packet [MPLS-ENC].
3.2.3.
Relationship to MPLS Policy Information Model Requirements
Earlier Internet drafts ([REQPMPLS], [REQMPLS_TE]) discussed
policies for MPLS and MPLS-TE. [REQPMPLS] 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 lifecycle 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 [REQMPLS_TE], 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, et al. Expires June 2001 [Page 10]
Internet Draft Policy MPLS Info Model for QoS & TE November 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 for traffic engineering and QoS support. 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.
4. Overview of MPLS Policy Information Model
4.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 and QoS Policy
Information Model. A number of object classes from previously
defined information models, namely CIM [CIM], 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 5 of this
document.
Chadha, et al. Expires June 2001 [Page 11]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
+---------------------------+
| FilterList (CIM) |
+-------------^-------------+
*|
(a)|
*|
+-------------v-------------+
+----> mplsPolicyFEC <----+
(b)|0..1+---------------------------+0..1|(i)
| |
| +---------------------------+ |
| | qosPolicyTrafficProfile | |
| +-^-----------------------^-+ |
| 0..1| 0..1| |
| (c)| +------+ (j)| | +------+
*| *| 0..1| (d)| *| *| *| (k)|
+----------v------v-----v-+ | +-----v------v-------v-+ |
| <----+ | <----+
| |0..1 | |*
| mplsPolicyTrafficTrunk <---------> mplsPolicyLSP |
| |* (m) *| |
| <---------> |
+--------------------^----+* (n) *+--^-------------------+
*| *|
(e)| (l)|
*| *|
+----v-----------------v----+
| mplsPolicyRouteSpec |
+----------------------^----+
*|
(f)| +------+
*| *| (h)|
+-------------------------+ +------v-----------------v-+ |
| ComputerSystem(CIM) | |mplsPolicyProtocolEndpoint<----+
+--------------------^----+ +------^-------------------+*
*| *|
(o)| (g)|
0..1| 0..1|
+----v-----------------v----+
| mplsPolicyResources |
+---------------------------+
Figure 1. Relationships between traffic trunks, LSPs, routes,
FECs, traffic profiles hops, resources, etc.
In Figure 1, boxes represent object classes and arrows represent
associations between the classes. The following associations appear
in Figure 1 above:
(a) mplsPolicyFECFilterSet
(b) mplsPolicyFECofTrunk
(c) mplsPolicyTT_TrafficProfile
(d) mplsPolicyReverseDirTT
Chadha, et al. Expires June 2001 [Page 12]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
(e) mplsPolicyEligibleRouteSpec
(f) mplsPolicyHopInRoute
(g) mplsPolicyEndpointResources
(h) mplsPolicyActiveConnection
(i) mplsPolicyFECofLSP
(j) mplsPolicyLSPTrafficProfile
(k) mplsPolicyLSPinLSP
(l) mplsPolicyRealizes
(m) mplsPolicyCurrentlyAssignedLSP
(n) mplsPolicyBackupLSP
(o) mplsPolicySystemResources
An association represents a relationship between two classes (e.g.
associations (a) to (o) excepting (d), (h) and (k) above in Figure
1), or between a class and itself (e.g. associations (d), (h) and
(k) 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 mplsPolicyBackupLSP association has the cardinality "*"
(i.e. "0..n") for both the mplsPolicyTrafficTrunk and the
mplsPolicyLSP classes. These ranges are interpreted as follows:
- The "*" written next to mplsPolicyTrafficTrunk indicates that an
mplsPolicyLSP may be related to no mplsPolicyTrafficTrunk, to one
mplsPolicyTrafficTrunk, or to more than one mplsPolicyTrafficTrunk
via the mplsPolicyBackupLSP association. In other words, an LSP
may be a backup LSP for zero or more traffic trunks.
- The "*" written next to mplsPolicyLSP indicates that a
mplsPolicyTrafficTrunk may be related to no mplsPolicyLSP, to one
mplsPolicyLSP, or to more than one mplsPolicyLSP via the
mplsPolicyBackupLSP association. In other words, a traffic trunk
may have zero or more backup LSPs.
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 [PCIM], marked "PCIM"
below, and to object classes defined in the Common Information Model
[CIM], marked "CIM" below. For detailed descriptions of these object
classes, see the relevant documents.
Chadha, et al. Expires June 2001 [Page 13]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
+--Policy (abstract) (PCIM)
| |
| +---PolicyAction (PCIM)
| | |
| | +---mplsPolicyTTAction
| | |
| | +---mplsPolicyLSPAction
| | | |
| | | +---mplsPolicyCRLSPResvAction
| | |
| | +---mplsPolicyTT_LSP_Action
| | |
| | +---mplsPolicySignalCtrlAction
| |
| +---qosPolicyTrfcProf (PQIM)
| | |
| | +--- mplsPolicyCRLSPTrfcProf
| |
| +---mplsPolicyFEC
|
+--CIM_ManagedSystemElement (abstract) (CIM)
|
+--CIM_LogicalElement (abstract) (CIM)
|
+--mplsPolicyResources
|
+--mplsPolicyTrafficTrunk
|
+--mplsPolicyLSP
|
+--mplsPolicyRouteSpec
|
+--CIM_ServiceAccessPoint (abstract) (CIM)
|
+--CIM_ProtocolEndpoint (abstract) (CIM)
|
+--mplsPolicyProtocolEndpoint
Figure 2. 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, et al. Expires June 2001 [Page 14]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
[unrooted]
|
+---mplsPolicyHopInRoute
|
+---mplsPolicySystemResources
|
+---mplsPolicyEndpointResources
|
+---ActiveConnection (CIM)
| |
| +---mplsPolicyActiveConnection
|
+---mplsPolicyReverseDirTT
|
+---mplsPolicyEligibleRouteSpec
|
+---mplsPolicyCurrentlyAssignedLSP
|
+---mplsPolicyBackupLSP
|
+---mplsPolicyRealizes
|
+---mplsPolicyLSPinLSP
|
+---mplsPolicyTT_TrafficProfile
|
+---mplsPolicyLSPTrafficProfile
|
+---mplsPolicyFECofTrunk
|
+---mplsPolicyFECofLSP
Figure 3. Inheritance Hierarchy for associations
4.2. High-level description of information model
Policies in the MPLS domain mainly center on
- lifecycle management of LSPs, including signaling, resource
control, admission control etc.,
- management of traffic trunks, including the specification of the
traffic traversing the trunks, and
- the mapping of traffic trunks to LSPs, including mapping of
DiffServ traffic and tunneling of MPLS traffic over parallel LSPs
for the purpose of traffic engineering.
4.2.1.
MPLS Signaling Actions
Signaling in MPLS consists of setting up, releasing and updating an
LSP along a number of LSRs. It should be possible to control the
initiation and the execution of these processes using policies. For
some signaling protocols, e.g. the Label Distribution Protocol
(LDP), the signaling is initiated by an LSR itself, without any
intervention by the Policy Server. The signaling actions in the
Chadha, et al. Expires June 2001 [Page 15]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
draft are applicable to constraint based LSP setup using protocols
such as CR-LDP and RSVP-TE, and include policy actions to initiate
the setup, update, or release of an LSP (mplsPolicyLSPAction), as
well as a policy action controlling the LSP setup process
(mplsPolicyCRLDPSignalCtrlAction).
4.2.2.
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 a later
section). 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, mplsPolicyTTAction operates upon a traffic trunk; the
property mpTrafficTrunk in this action references an instance of a
traffic trunk that is to be operated upon. Thus before instantiating
an instance of mplsPolicyTTAction, one must instantiate an instance
of mplsPolicyTrafficTrunk 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
[RFC2702] describes the difference between establishing a traffic
trunk (which we model by creating an instance of
mplsPolicyTrafficTrunk and related classes as described later) and
activating a traffic trunk (which is modeled by the
mplsPolicyTTAction).
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
(mplsPolicyRouteSpec) 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
mplsPolicyEligibleRouteSpec.
- Traffic profile: A traffic profile (qosPolicyPRTrfcProf)
describing the resource requirements of a traffic trunk can be
defined for every traffic trunk and associated with the traffic
trunk via the mplsPolicyTT_TrafficProfile association.
- Assigned LSPs: Any LSPs (mplsPolicyLSP) currently assigned to a
traffic trunk can be defined and associated with it via the
mplsPolicyCurrentlyAssignedLSP association.
- Backup LSPs: Any LSPs (mplsPolicyLSP) that are acting as backup
LSPs for a traffic trunk can be defined and associated with it via
the mplsPolicyBackupLSP association.
Chadha, et al. Expires June 2001 [Page 16]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
- Reverse traffic trunk: If a traffic trunk carrying traffic in the
reverse direction exists, it can be associated with a given traffic
trunk via mplsPolicyReverseDirTT.
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
(mplsPolicyRouteSpec) can be associated with an LSP to indicate that
this LSP is a realization of the route specification. The
association is modeled by the mplsPolicyRealizes.
- Traffic trunks: Any traffic trunks (mplsPolicyTrafficTrunk) whose
traffic is currently being carried by an LSP should be defined and
associated with this LSP via the mplsPolicyCurrentlyAssignedLSP
association. Further, any traffic trunks for which an LSP is a
backup LSP should be associated with this LSP via the
mplsPolicyBackupLSP association.
- LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be
associated with any LSPs contained in or containing it via the
mplsPolicyLSPinLSP association.
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 (mplsPolicyLSP) can be associated with a
route specification to indicate that these LSPs are realizations of
the route specification. The association is modeled by the
mplsPolicyRealizes.
- Traffic trunks: Traffic trunks (mplsPolicyTrafficTrunk) for which
a given route specification is a potential route should be
associated with the route specification via the
mplsPolicyEligibleRouteSpec association.
- Route hops: Every hop specified for a route specification is
represented by an instance of mplsPolicyProtocolEndpoint (derived
from ProtocolEndpoint in [CIM]) and is associated with a route
specification via the mplsPolicyHopInRoute association.
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 mplsPolicyTrafficTrunk): For a
description of a traffic trunk, see the Introduction section of this
Chadha, et al. Expires June 2001 [Page 17]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
document, or see RFC 2702 [RFC2702] 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 (mplsPolicyCurrentlyAssignedLSP
association) and with backup LSPs that are used for backup in
fault/congestion scenarios (mplsPolicyBackupLSP association).
Eligible routes for this traffic trunk are associated with it via
the mplsPolicyEligibleRouteSpec association. If a traffic trunk
going in the reverse direction exists, it is associated with this
traffic trunk via the mplsPolicyReverseDirTT association. Finally, a
traffic profile for this traffic trunk can be represented by the
qosPolicyPRTrfcProf object class (reused from QPIM) and associated
with the traffic trunk via the mplsPolicyTrafficProfile association.
- Route Specification (object class mplsPolicyRouteSpec): This is an
object class that represents a route specification from point A to
point B. The route specification may or may not be realized in the
network by an LSP. A route specification is associated with all the
hops contained in this route. These hops are interfaces on LSRs
(represented by instances of ProtocolEndpoint, which is an object
class defined in the CIM Network Model [CIM]). The associations with
these hops are realized via the mplsPolicyHopInRoute associations.
Note that a route specification 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. An LSP can be created based on a route
specification using the mplsPolicyLSPAction.
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 (mplsPolicyEligibleRouteSpec association).
- Label-Switched Path (LSP) (object class mplsPolicyLSP): 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 (mplsPolicyRealizes association). An LSP
can also be associated with a traffic trunk if it is currently
carrying the traffic for this traffic trunk (via the
mplsPolicyCurrentlyAssignedLSP association) or if it is a backup LSP
for this traffic trunk (via the mplsPolicyBackupLSP association). An
LSP can also be associated with another LSP to indicate a hierarchy
of LSPs (mplsPolicyLSPinLSP association).
- Resources (object class mplsPolicyResources): This object class
represents resources associated with LSRs and interfaces on these
LSRs, such as buffer resources, etc. (mplsPolicySystemResources and
mplsPolicyEndpointResources associations, respectively).
Chadha, et al. Expires June 2001 [Page 18]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
- Links and their resources (association
mplsPolicyActiveConnection): The resources associated with a link
(e.g. bandwidth, etc.) are represented by properties of the
association mplsPolicyActiveConnection. 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 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.3. MPLS Policy Variables
The QoS policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly
used in policy conditions [QPIM]. In order to specify meaningful
policy rules in the MPLS domain, we extend the set of pre-defined
variables with MPLS-specific variables. Here we define a preliminary
set of low-level concepts; these may need to be extended in updates
to this draft.
The following table defines the pre-defined variables for MPLS and
their logical bindings.
+----------------+--------------------------------------------------+
| Variable name | Logical binding |
+----------------+--------------------------------------------------+
| MPLSLabel | The MPLS label of the flow. Compared to the MPLS |
| | label in the MPLS shim header field or the |
| | combined VPI/VCI in ATM. |
+----------------+--------------------------------------------------+
| MPLSExp | The MPLS Exp field of the flow. Compared to the |
| | MPLS Experimental field in the MPLS shim header. |
+----------------+--------------------------------------------------+
Table 1: Pre-defined Variable Names and their Bindings
Both variables can be of class type qosPolicyIntegerValue or
qosPolicyBitStringValue.
5. Class Definitions
5.1. Class mplsPolicyTTAction
This class represents a policy action that creates, destroys or
modifies an instance of a traffic trunk by assigning it to a traffic
flow (referred to as "activation" of a traffic trunk in [RFC2702]).
Note that a traffic trunk MUST first be established or defined by
creating an instance of mplsPolicyTrafficTrunk and related
objects/associations (see Section below for details). RFC 2702
describes the difference between establishing a traffic trunk (which
Chadha, et al. Expires June 2001 [Page 19]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
we model by creating an instance of mplsPolicyTrafficTrunk and
related classes as described in Section below) and activating a
traffic trunk (which is modeled by the mplsPolicyTTAction).
The class definition is as follows:
NAME mplsPolicyTTAction
DESCRIPTION A class used to describe a policy action that
activates, destroys or modifies a traffic trunk.
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES mpTrafficTrunk,
mpTTMode
5.1.1.
The property mpTrafficTrunk
This property is a reference to the instance of
mplsPolicyTrafficTrunk that is to be created, destroyed or modified.
The property definition is as follows:
NAME mpTrafficTrunk
DESCRIPTION Traffic trunk being created, destroyed or modified
SYNTAX Reference to an mplsPolicyTrafficTrunk
5.1.2.
The Property mpTTMode
The mpTTMode property specifies whether the action is a creation,
destruction, modification of a Traffic Trunk action, or a
modification of a traffic profile action (see 5.2.)
NAME mpTTMode
DESCRIPTION Mode of the action
SYNTAX Integer (ENUM) - {
"TTCreate"=0;
"TTModify"=1;
"TTDestroy"=2;
}
5.2. Class mplsPolicy_TT_LSPAction
This class is used to represent the action of assigning or de-
assigning an LSP to a traffic trunk. Note that the traffic trunk and
LSP are assumed to have been defined by creating instances of
mplsPolicyTrafficTrunk and mplsPolicyLSP, respectively, as well as
related objects/associations (see Sections X.2.1.1 and X.2.1.2 for
details).
NAME mplsPolicy_TT_LSPAction
DESCRIPTION A class that represents an action that
assigns or deassigns an LSP to a traffic trunk.
DERIVED FROM PolicyAction
ABSTRACT False
PROPERTIES mpTrafficTrunk,
Chadha, et al. Expires June 2001 [Page 20]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
mpAssignedLSP,
mpTT_LSPMode
5.2.1.
The property mpTrafficTrunk
This property contains a reference to an instance of
mplsPolicyTrafficTrunk. Note that the instance of
mplsPolicyTrafficTrunk 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 mplsPolicyTrafficTrunk
5.2.2.
The property mpAssignedLSP
This property is a reference to an instance of mplsPolicyLSP. 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 mplsPolicyLSP
5.2.3.
The Property mpTT_LSPMode
The mpTT_LSPMode property specifies whether the action is an
assignment or deassignment of a LSP to a Traffic Trunk.
NAME mpTT_LSPMode
DESCRIPTION Mode of the action
SYNTAX Integer (ENUM) - {
"Assign"=0;
"Deassign"=1;
}
5.3. Class mplsPolicyLSPAction
This class defines a generic LSP reservation action. The action
initiates the setup, update, or release of an LSP referred to by the
in the mpCreateLSP property. The class definition is as follows:
NAME mplsPolicyLSPAction
DESCRIPTION A class used to describe a policy action that
sets up, releases, or modifies any a LSP.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT False
Chadha, et al. Expires June 2001 [Page 21]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
PROPERTIES mpCreateLSP,
mpLSPMode
5.3.1.
The Property mpCreateLSP
This property is a reference to an mplsPolicyLSP object, which
defines an LSP. The property is defined as follows:
NAME mpCreateLSP
DESCRIPTION LSP being set up, released, or modified
SYNTAX Reference to an mplsPolicyLSP object
5.3.2.
The Property mpLSPMode
The mpLSPMode property specifies whether the action is a setup,
release, or update action of an LSP.
NAME mpLSPMode
DESCRIPTION Mode of the action
SYNTAX Integer (ENUM) - {
"LSPSetup"=0;
"LSPUpdate"=1;
"LSPRelease"=2;
}
5.4. Class mplsPolicyCRLSPResvAction
This class defines an CR-LSP reservation action using CR-LDP Label
Request Messages. The set priority property specifies whether an
existing LSP may be preempted in order to The property is mapped to
the SetPrio field of the Preemption TLV [CRLDP]. Negotiable
properties specify whether the corresponding traffic parameter is
negotiable or not. The properties are mapped to the flags field of
the Traffic Parameter TLV of [CRLDP].
This class defines a protocol-specific action and will likely be
moved to a protocol-specific information model in the future.
The class definition is as follows:
NAME mplsPolicyCRLSPResvAction
DESCRIPTION A class used to describe a policy action that
sets up, releases or modifies an LSP using CR-LDP.
DERIVED FROM mplsPolicyLSPAction
ABSTRACT False
PROPERTIES mpCRLSPsetPrio,
mpPDRNegotiable, mpPBSNegotiable,
mpCDRNegotiable, mpCBSNegotiable,
mpEBSNegotiable, mpWeightNegotiable
5.4.1.
The Property mpCRLSPSetPrio
Chadha, et al. Expires June 2001 [Page 22]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property represents the setting priority of the CR-LSP. The
property is defined as follows:
NAME mpCRLSPSetPrio
DESCRIPTION setting priority of the CR-LSP
SYNTAX Integer (MUST be in the range 0-255)
5.4.2.
The Property mpPDRNegotiable
This property indicates whether the Peak Data Rate of the CR-LSP is
negotiatble or not. The property is defined as follows:
NAME mpPDRNegotiable
DESCRIPTION Flag that indicates whether PDR is negotiable or not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.4.3.
The Property mpPBSNegotiable
This property indicates whether the Peak Burst Size of the CR-LSP is
negotiable or not. The property is defined as follows:
NAME mpPBSNegotiable
DESCRIPTION Flag that indicates whether PBS is negotiable or not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.4.4.
The Property mpCDRNegotiable
This property indicates whether the Committed Data Rate of the CR-LSP
is negotiable or not. The property is defined as follows:
NAME mpCDRNegotiable
DESCRIPTION Flag that indicates whether CDR is negotiable or not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.4.5.
The Property mpCBSNegotiable
This property indicates whether the Committed Burst Size of the CR-
LSP is negotiable or not. The property is defined as follows:
NAME mpCBSNegotiable
DESCRIPTION Flag that indicates whether CBS is negotiable or not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.4.6.
The Property mpEBSNegotiable
This property indicates whether the Excess Burst Size of the CR-LSP
is negotiable or not. The property is defined as follows:
NAME mpEBSNegotiable
DESCRIPTION Flag that indicates whether EBS is negotiable or not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.4.7.
The Property mpWeightNegotiable
Chadha, et al. Expires June 2001 [Page 23]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property indicates whether the Weight of the CR-LSP is
negotiable or not. The property is defined as follows:
NAME mpWeightNegotiable
DESCRIPTION Flag that indicates whether Weight is negotiable or
not
SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1}
5.5. Class mplsPolicyCRLDPSignalCtrlAction
This class defines a policy action to be applied to CR-LDP messages.
The message type property identifies the concerned messages. The
mpSendNotification property specifies whether a notification should
be sent. If the notification message is sent, the mpErrCode property
identifies the error code to be sent. Furthermore, the replace
properties specify whether the traffic profile of the CR-LDP message
is changed.
This class defines a protocol-specific action and will likely be
moved to a protocol-specific information model in the future.
NAME mplsPolicyCRLDPSignalCtrlAction
DESCRIPTION A class used to describe a policy action that
is applied to CR-LDP messages.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES mpCRLDPMessageType, mpSendNotification,
mpSendRelease, mpErrCode
mpReplacePDR, mpReplacePBS,
mpReplaceCDR, mpReplaceCBS,
mpReplaceEBS, mpReplaceWeight
5.5.1.
The Property CRLDPMessageType
This property is an enumerated integer and defines different values
that limit the scope of the action to be enforced to specific types
of CR-LDP Messages. The property is defined as follows:
NAME CRLDPMessageType
DESCRIPTION A message type to which the action is enforced
SYNTAX Integer (ENUM) - {
"LabelMapping"=0;
"LabelRequest"=1;
"LabelWithdraw"=2;
"LabelRelease"=3;
"LabelAbortRequest"=4;
"Notification"=5;
}
5.5.2.
The Property mpSendNotification
Chadha, et al. Expires June 2001 [Page 24]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property controls the generation of CR-LDP Notification
Messages. The property is defined as follows:
NAME mpSendNotification
DESCRIPTION A flag that indicates whether a Notification Message
is generated or not.
SYNTAX Boolean - {No=0, Yes=1}
5.5.3.
The Property mpSendRelease
This property controls the generation of CR-LDP Release Messages. The
property is defined as follows:
NAME mpSendRelease
DESCRIPTION A flag that indicates whether a Release Message is
generated or not.
SYNTAX Boolean - {No=0, Yes=1}
5.5.4.
The Property mpErrCode
This property specifies the error code in case the mpSendNotification
property has the value 1=yes. If the sent notification property is
no, this property is undefined. The error codes are the ones
specified in LDP and CR-LDP.
NAME mpErrCode
DESCRIPTION Error code of Notification Message
SYNTAX Integer
5.5.5.
The Property mpReplacePDR
This property is a non-negative integer that replaces the Peak Data
Rate value in a CR-LDP message. The property is defined as follows:
NAME mpReplacePDR
DESCRIPTION Replaced PDR value
SYNTAX Integer (MUST be non-negative)
5.5.6.
The Property mpReplacePBS
This property is a non-negative integer that replaces the Peak Burst
Size value in a CR-LDP message. The property is defined as follows:
NAME mpReplacePBS
DESCRIPTION Replaced PBS value
SYNTAX Integer (MUST be non-negative)
5.5.7.
The Property mpReplaceCDR
This property is a non-negative integer that replaces the Committed
Data Rate value in a CR-LDP message. The property is defined as
follows:
Chadha, et al. Expires June 2001 [Page 25]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
NAME mpReplaceCDR
DESCRIPTION Replaced CDR value
SYNTAX Integer (MUST be non-negative)
5.5.8.
The Property mpReplaceCBS
This property is a non-negative integer that replaces the Committed
Burst Size value in CR-LDP message. The property is defined as
follows:
NAME mpReplaceCBS
DESCRIPTION Replaced CBS value
SYNTAX Integer (MUST be non-negative)
5.5.9.
The Property mpReplaceEBS
This property is a non-negative integer that replaces the Excess
Burst Size value in a CR-LDP message. The property is defined as
follows:
NAME mpReplaceEBS
DESCRIPTION Replaced EBS value
SYNTAX Integer (MUST be non-negative)
5.5.10. The Property mpReplaceWeight
This property is a non-negative integer that replaces the Weight
value in a CR-LDP message. The property is defined as follows:
NAME mpReplaceWeight
DESCRIPTION Replaced Weight value
SYNTAX Integer (MUST be in the range 0-255)
5.6. Class mplsPolicyLSP
This object class is used to represent an MPLS LSP and its
properties. Instances of this class represent existing or to be
established LSPs in the network. The class definition is as follows:
NAME mplsPolicyLSP
DESCRIPTION A class with several properties for
describing an MPLS LSP.
DERIVED FROM LogicalElement
ABSTRACT False
PROPERTIES mpAdminStatus,
mpOperationalStatus,
mpLevel,
mpLocalLSPID,
mpResourceClass,
mpHoldingPriority,
mpIngressMayReroute,
mpIsPersistent,
mpIsPinned,
Chadha, et al. Expires June 2001 [Page 26]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
mpLocalProtectionAvailable,
mpIsAdaptive,
Roles
5.6.1.
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 Integer (ENUM) - {
"up"=1;
"down"=2;
"testing"=3;
}
5.6.2.
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.
SYNTAX Integer (ENUM) - {
"up"=1;
"down"=2;
"testing"=3;
"unknown"=4;
"dormant"=5;
"notPresent"=6;
"lowerLayerDown"=7
}
5.6.3.
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 Integer
5.6.4.
The Property mpLocalLSPId
This property is an integer that indicates the LSP id which is unique
with reference to the Ingress LSR.
Chadha, et al. Expires June 2001 [Page 27]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
The property definition is as follows:
NAME mpLocalLSPID
SYNTAX Integer (must be in the range 0-65535)
5.6.5.
The Property mpResourceClass
This property defines an integer to represent a resource class of the
LSP.
The property definition is as follows:
NAME mpResourceClass
SYNTAX Integer[] (must be non-negative)
5.6.6.
The Property mpHoldingPriority
This property represents the holding priority of the LSP which is
already set up. A newly set up LSP is only allowed to preempt the
resources of this LSP if its set priority is higher than the hold
priority.
NAME mpHoldingPriority
DESCRIPTION Holding priority for this LSP
SYNTAX Integer (must be in the range 0-255)
5.6.7.
The property mpIngressMayReroute
This flag indicates that the LSP ingress node may choose to reroute
this MPLS route without tearing it down.
The property definition is as follows:
NAME mpIngressMayReroute
DESCRIPTION Fast reroute enabled
SYNTAX boolean
5.6.8.
The property mpIsPersistent
This flag indicates whether this LSP should be restored automatically
after a failure occurs.
The property definition is as follows:
NAME mpIsPersistent
DESCRIPTION Indicates whether this MPLS route is
not
SYNTAX boolean
5.6.9.
The property mpIsPinned
Chadha, et al. Expires June 2001 [Page 28]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This flag indicates whether the loosely-routed hops of this MPLS
route are to be pinned (see [RSVP-TE][CRLDP]).
The property definition is as follows:
NAME mpIsPinned
DESCRIPTION Indicates whether the route is pinned
SYNTAX boolean
5.6.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 LSP.
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
SYNTAX boolean
5.6.11. The property mpIsAdaptive
An LSP might need to re-route itself (e.g. due to re-optimization,
connectivity problems, increase in bandwidth, etc.). If an LSP 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
5.6.12. The property Roles
The Roles property specifies the set of roles this LSP may have. This
property is defined in the CIM Core Information model [CIM] and
therefore its definition is not repeated here. See PCIM for an
explanation of how roles are used. (See also open issues at the end
of the draft)
5.7. Class mplsPolicyFEC
Chadha, et al. Expires June 2001 [Page 29]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
The mplsPolicyFEC specifies the Forwarding Equivalence Class of an
LSP. The FECs may differ depending on the application of MPLS. The
association mplsFECFilterSet association associates a FilterList
[CIM] with this class.
NAME mplsPolicyFEC
DESCRIPTION A Forwarding Equivalence Class of a Traffic Trunk or
an LSP
DERIVED FROM Policy (defined in [PCIM])
ABSTRACT FALSE
PROPERTIES
5.8. Class mplsPolicyCRLSPTrfcProf
This class represents CR-LSP traffic parameters as specified in
[CRLDP]. The value of CR-LSP traffic profiles corresponds to the
Traffic Parameter TLV carried in CR-LDP messages. The traffic profile
is derived from the qosPolicyPRTrfcProf, where the property
qpPRExcessBurst is used for the CR-LDP ExcessBurstSize, the qpPRRate
replaces CR-LDP PeakDataRate, and qpNormalBurst refers to CR-LDP
PeakBurstSize
This class represents protocol-specific parameters and will likely be
moved to a protocol-specific information model in the future.
NAME mplsPolicyCRLSPTrfcProf
DESCRIPTION Traffic profile of CR-LSP
DERIVED FROM qosPolicyPRTrfcProf (defined in [PQIM])
ABSTRACT False
PROPERTIES mpCRLSPFrequency,
mpCRLSPWeight,
mpCRLSPCommittedDataRate,
mpCRLSPCommittedBurstSize
5.8.1.
The Property mpCRLSPFrequency
This property specifies at what granularity the CDR allocated to the
CR-LSP is made available.
NAME mpCRLSPFrequency
DESCRIPTION Granularity of CDR
SYNTAX Integer (ENUM){
"Unspecified"=0;
"Frequent"=1;
"VeryFrequent"=2
}
5.8.2.
The Property mpCRLSPWeight
This property represents the CR-LSP's relative share of the possible
excess bandwidth above its committed rate.
NAME mpCRLSPWeight
Chadha, et al. Expires June 2001 [Page 30]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
DESCRIPTION Relative share of the possible excess bandwidth
SYNTAX Integer (MUST be in the range 0-255)
5.8.3.
The Property mpCRLSPCommittedDataRate
This property is a non-negative integer that defines the token rate
parameter of committed data rate token bucket, measured in bytes per
second. The property is defined as follows:
NAME mpCRLSPCommittedDataRate
DESCRIPTION Committed data rate
SYNTAX Integer (MUST be non-negative)
5.8.4.
The Property mpCRLSPCommittedBurstSize
This property is a non-negative integer that defines the token bucket
size parameter of committed data rate token bucket, measured in
bytes.
The property is defined as follows:
NAME mpCRLSPCommittedBurstSize
DESCRIPTION Committed burst size
SYNTAX Integer (MUST be non-negative)
5.9. Class mplsPolicyTrafficTrunk
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
[RFC2702]. The class definition is as follows:
NAME mplsPolicyTrafficTrunk
DESCRIPTION A class with several properties for
describing an MPLS traffic trunk.
DERIVED FROM LogicalElement
ABSTRACT False
PROPERTIES mpResourceClassAffinity,
mpPreemption,
mpPriority,
mpResilience,
mpTrafficProportion,
mpReoptimizationFreq,
Roles
Chadha, et al. Expires June 2001 [Page 31]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.9.1.
The property mpResourceClassAffinity
This property represents the resource class affinity attributes (see
[RFC2702]) 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 mplsPolicyResources
and in association mplsPolicyActiveConnection, 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 [RFC2702]) 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
Chadha, et al. Expires June 2001 [Page 32]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.9.2.
The property mpPreemption
The preemption attribute (see [RFC2702]) 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 Integer (MUST be in the range 1-4)
5.9.3.
The property mpPriority
Chadha, et al. Expires June 2001 [Page 33]
Internet Draft Policy MPLS Info Model for QoS & TE November 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 Integer
5.9.4.
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[RFC2702] 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
5.9.5.
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.
This problem can be addressed by instantiating multiple traffic
Chadha, et al. Expires June 2001 [Page 34]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
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 Integer
5.9.6.
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 Integer
5.9.7.
The property Roles
The Roles property specifies the set of roles this TT may have. This
property is defined in the CIM Core Information model [CIM] and
therefore its definition is not repeated here. See PCIM for an
explanation of how roles are used.
5.10.
Class mplsPolicyRouteSpec
This object class is used to represent a specification of a path for
routing an MPLS traffic trunk/LSP. An LSP can be created based on a
route specification using the mplsPolicyLSPAction.
The class definition is as follows:
NAME mplsPolicyRouteSpec
DESCRIPTION A class describing an MPLS route specification.
DERIVED FROM LogicalElement
ABSTRACT False
PROPERTIES mpIngressIPAddress,
MpEgressIPAddress
Chadha, et al. Expires June 2001 [Page 35]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.10.1. 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
5.10.2. 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
5.11.
Class mplsPolicyProtocolEndpoint
This class is derived from ProtocolEndpoint [CIM] and represents a
hop in the route of LSP or Traffic Trunk. A hop represents an LSR
interface and this class provides a way to assign roles of an LSR
interface such as "MPLS_INGRESS", "MPLS_EGRESS", "MPLS_CORE", etc.
NAME mplsPolicyProtocolEndpoint
DESCRIPTION A class that represents a LSR interface.
DERIVED FROM ProtocolEndpoint (defined in [CIM])
ABSTRACT False
PROPERTIES Roles
5.11.1. The Property Roles
The Roles property specifies the set of roles this
mplsPolicyProtocolEndpoint may have. This property is defined in the
CIM Core Information model [CIM] and therefore its definition is not
repeated here. See PCIM for an explanation of how roles are used.
5.12.
Class mplsPolicyResources
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
mplsPolicySystemResources and the mplsPolicyEndpointResources
associations, respectively.
The class definition is as follows:
NAME mplsPolicyResources
DESCRIPTION Resources associated with LSRs and their
Chadha, et al. Expires June 2001 [Page 36]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
interfaces
ABSTRACT False
DERIVED FROM LogicalElement,
PROPERTIES mpBufferResources,
mpMaxAllocMultiplier,
mpResourceClass
5.12.1. The property mpBufferResources
Buffer resources for an LSR or an LSR interface.
The property definition is as follows:
NAME mpBufferResources
DESCRIPTION Buffer resources.
SYNTAX Integer
5.12.2. The property mpMaxAllocMultiplier
The maximum allocation multiplier (MAM) (see [RFC2702]) 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 Integer
5.12.3. The property mpResourceClass
This property describes the "class" that a resource belongs to (see
[RFC2702]). 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
Chadha, et al. Expires June 2001 [Page 37]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
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 Integer[]
5.13.
Association mplsPolicySystemResources
The association mplsPolicySystemResources associates a set of
resources (object class mplsPolicyResources) with an LSR (modeled by
an instance of ComputerSystem as defined in the CIM model [CIM]).
The association definition is as follows:
NAME mplsPolicySystemResources
DESCRIPTION Associates MPLS resources with an LSR.
ABSTRACT False
PROPERTIES mpResources[ref MPLSResources [0..1]],
mpLSR [ref ComputerSystem[0..n]]
5.13.1. The reference mpResources
This property contains an object reference to an mplsPolicyResources
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 mplsPolicyResources associated with any
given LSR.
5.13.2. The reference mpLSR
This property contains an object reference to a ComputerSystem
(representing an LSR) that is associated with mplsPolicyResources.
The [0..n] cardinality indicates that there may be 0, 1, or more
than one LSRs associated with any given mplsPolicyResources
instance. These LSRs all have the same resource specifications.
5.14.
Association mplsPolicyEndpointResources
The association mplsPolicyEndpointResources associates a set of
resources (object class mplsPolicyResources) with an interface of an
LSR (modeled by an instance of mplsPolicyProtocolEndpoint).
The association definition is as follows:
NAME mplsPolicyEndpointResources
DESCRIPTION Associates MPLS resources with an interface
of an LSR.
Chadha, et al. Expires June 2001 [Page 38]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
ABSTRACT False
PROPERTIES mpResources[ref mplsPolicyResources [0..1]],
mpPE [ref mplsPolicyProtocolEndpoint [0..n]]
5.14.1. The reference mpResources
This property contains an object reference to an mplsPolicyResources
instance to which zero or one mplsPolicyProtocolEndpoints
(representing interfaces on LSRs) can be associated. The [0..1]
cardinality indicates that there may be zero or one instances of
mplsPolicyResources associated with any given LSR interface.
5.14.2. The reference mpPE
This property contains an object reference to a
mplsPolicyProtocolEndpoint (representing an LSR interface) that is
associated with mplsPolicyResources. The [0..n] cardinality
indicates that there may be 0, 1, or more than one LSR interfaces
associated with any given mplsPolicyResources instance. These LSR
interfaces all have the same resource specifications.
5.15.
Association mplsPolicyActiveConnection
The association mplsPolicyActiveConnection associates a
mplsPolicyProtocolEndpoint with another and represents a link
between them. Here mplsPolicyProtocolEndpoint represents an LSR
interface.
The association definition is as follows:
NAME mplsPolicyActiveConnection
DESCRIPTION Represents a link between two LSR interfaces
ABSTRACT false
DERIVED FROM ActiveConnection (from [CIM])
PROPERTIES mpEndpoint1 [ref mplsPolicyProtocolEndpoint [0..n]],
mpEndpoint2 [ref mplsPolicyProtocolEndpoint [0..n]],
mpBandwidth,
mpMaxAllocMultiplier,
mpResourceClass
5.15.1. The reference mpEndpoint1
This property contains a reference to a mplsPolicyProtocolEndpoint
instance (representing an LSR interface) to which zero or more
ProtocolEndpoints (also representing LSR interfaces) can be
associated, representing a connection between the
mplsPolicyProtocolEndpoints. The [0..n] cardinality indicates that
there may be zero or more instances of mplsPolicyProtocolEndpoint
associated with any given mplsPolicyProtocolEndpoint.
5.15.2. The reference mpEndpoint2
Chadha, et al. Expires June 2001 [Page 39]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property contains a reference to a mplsPolicyProtocolEndpoint
instance (representing an LSR interface) to which zero or more
ProtocolEndpoints (also representing LSR interfaces) can be
associated, representing a connection between the
mplsPolicyProtocolEndpoints. The [0..n] cardinality indicates that
there may be zero or more instances of mplsPolicyProtocolEndpoint
associated with any given mplsPolicyProtocolEndpoint.
5.15.3. The property mpBandwidth
Bandwidth for the link represented by this connection.
The property definition is as follows:
NAME mpBandwidth
DESCRIPTION Link bandwidth
SYNTAX Integer
5.15.4. The property mpMaxAllocMultiplier
The maximum allocation multiplier (MAM) (see [RFC2702]) 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 Integer
5.15.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
Chadha, et al. Expires June 2001 [Page 40]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
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 Integer[]
5.16.
Association mplsPolicyHopInRoute
The association mplsPolicyHopInRoute provides a way to associate
hops with mplsPolicyRouteSpec. Hops are instances of
mplsPolicyProtocolEndpoint and represent LSR interfaces.
The association definition is as follows:
NAME mplsPolicyHopInRoute
DESCRIPTION Associates hops with mplsPolicyRouteSpec
ABSTRACT False
PROPERTIES mpRoute[ref mplsPolicyRouteSpec[0..n]],
mpHop[ref mplsPolicyProtocolEndpoint[0..n]],
mpIsStrict,
mpOrder
5.16.1. The reference mpRoute
This property contains an object reference to an mplsPolicyRouteSpec
with which a number of hops can be associated. The [0..n]
cardinality indicates that there may be 0, 1, or more than one
mplsPolicyRouteSpec associated with any given hop, indicating that
this hop is contained in all these routes.
5.16.2. The reference mpHop
This property contains an object reference to a
mplsPolicyProtocolEndpoint (representing an LSR interface) that is a
hop for an mplsPolicyRouteSpec. The [0..n] cardinality indicates
that there may be 0, 1, or more than one hops associated with any
given mplsPolicyRouteSpec. These are all the hops that are included
in the route specification.
5.16.3. The property mpIsStrict
Denotes whether the referenced hop is routed in a strict or loose
fashion.
The property definition is as follows:
Chadha, et al. Expires June 2001 [Page 41]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
NAME mpIsStrict
DESCRIPTION Denotes whether the referenced hop is routed
in a strict or loose fashion.
SYNTAX boolean
5.16.4. The property mpOrder
This property indicates the hop sequence, 1..n.
The property definition is as follows:
NAME mpOrder
DESCRIPTION Hop sequence
SYNTAX Integer
5.17.
Association mplsPolicyEligibleRouteSpec
The association mplsPolicyEligibleRouteSpec associates an MPLS
traffic trunk with a route specification that is a potential route
for this traffic trunk.
The association definition is as follows:
NAME mplsPolicyEligibleRouteSpec
DESCRIPTION Associates a traffic trunk with a route
specification that is a potential route for
this traffic trunk.
ABSTRACT false
PROPERTIES mpTT [ref MplsPolicyTrafficTrunk [0..n]],
mpRoute [ref MplsPolicyRouteSpec [0..n]],
mpPreference,
mpIsMandatory
5.17.1. The reference mpTT
This property contains an object reference to an
mplsPolicyTrafficTrunk instance associated with an
mplsPolicyRouteSpec. The [0..n] cardinality indicates that there may
be zero or more instances of mplsPolicyTrafficTrunk associated with
any given mplsPolicyRouteSpec; 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.
5.17.2. The reference mpRoute
This property contains an object reference to an mplsPolicyRouteSpec
that is associated with an mplsPolicyTrafficTrunk. The [0..n]
cardinality indicates that there may be 0, 1, or more than one
mplsPolicyRouteSpecs associated with any given
mplsPolicyTrafficTrunk instance; i.e. any traffic trunk can have
multiple eligible route specifications.
Chadha, et al. Expires June 2001 [Page 42]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.17.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 Integer
5.17.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
5.18.
Association mplsPolicyReverseDirTT
The association mplsPolicyReverseDirTT associates an MPLS traffic
trunk with a traffic trunk going in the reverse direction.
The association definition is as follows:
NAME mplsPolicyReverseDirTT
DESCRIPTION Associates a traffic trunk with another going
in the reverse direction.
ABSTRACT False
PROPERTIES mpTT1 [ref mplsPolicyTrafficTrunk [0..1]],
mpTT2 [ref mplsPolicyTrafficTrunk [0..1]]
5.18.1. The reference mpTT1
This property contains an object reference to an
mplsPolicyTrafficTrunk instance to which zero or one
mplsPolicyTrafficTrunks can be associated. An mplsPolicyReverseDirTT
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 mplsPolicyTrafficTrunk associated with any given
mplsPolicyTrafficTrunk.
5.18.2. The reference mpTT2
Chadha, et al. Expires June 2001 [Page 43]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property contains an object reference to an
mplsPolicyTrafficTrunk instance to which zero or one
mplsPolicyTrafficTrunks can be associated. An mplsPolicyReverseDirTT
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 mplsPolicyTrafficTrunk associated with any given
mplsPolicyTrafficTrunk.
5.19.
Association mplsPolicyRealizes
The association mplsPolicyRealizes associates an LSP with an MPLS
route specification (mplsPolicyRouteSpec). 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 mplsPolicyRealizes association satisfies all
the constraints laid down in this route specification.
The association definition is as follows:
NAME mplsPolicyRealizes
DESCRIPTION Associates an LSP with a route specification.
ABSTRACT False
PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]],
mpRouteSpec [ref mplsPolicyRouteSpec [0..n]]
5.19.1. The reference mpLSP
This property contains an object reference to an mplsPolicyLSP
instance associated with an mplsPolicyRouteSpec. The [0..n]
cardinality indicates that there may be zero or more instances of
mplsPolicyLSP associated with any given mplsPolicyRouteSpec; i.e.
zero or more LSPs can be a realization of the same route
specification.
5.19.2. The reference mpRouteSpec
This property contains an object reference to an mplsPolicyRouteSpec
that is associated with an mplsPolicyLSP. The [0..n] cardinality
indicates that there may be 0, 1, or more than one
mplsPolicyRouteSpecs associated with any given mplsPolicyLSP
instance; i.e. any LSP can be a realization of have zero or more
route specifications.
5.20.
Association mplsPolicyCurrentlyAssignedLSP
The association mplsPolicyCurrentlyAssignedLSP associates the LSP to
which a traffic trunk is assigned with that traffic trunk.
The association definition is as follows:
Chadha, et al. Expires June 2001 [Page 44]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
NAME mplsPolicyCurrentlyAssignedLSP
DESCRIPTION Associates a traffic trunk with the LSP
assigned to it.
ABSTRACT False
PROPERTIES mpTT [ref MplsPolicyTrafficTrunk [0..n]],
mpLSP [ref mplsPolicyLSP [0..n]]
5.20.1. The reference mpTT
This property contains an object reference to an
mplsPolicyTrafficTrunk instance to which zero or more mplsPolicyLSPs
can be associated. An mplsPolicyCurrentlyAssignedLSP 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
mplsPolicyTrafficTrunk associated with any given mplsPolicySLSP,
i.e. an LSP could be carrying traffic for zero or more traffic
trunks.
5.20.2. The reference mpLSP
This property contains an object reference to an mplsPolicyLSP
instance to which zero or more mplsPolicyTrafficTrunks can be
associated. An mplsPolicyCurrentlyAssignedLSP 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
mplsPolicyLSP associated with any given mplsPolicyTrafficTrunk, i.e.
these LSPs are sharing the traffic load for this traffic trunk.
5.21.
Association mplsPolicyBackupLSP
The association mplsPolicyBackupLSP 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 mplsPolicyBackupLSP
DESCRIPTION Associates a backup LSP with a traffic trunk.
ABSTRACT False
PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]],
mpLSP [ref mplsPolicyLSP [0..n]],
mpPreference
5.21.1. The reference mpTT
This property contains an object reference to an
mplsPolicyTrafficTrunk instance with which zero or more
mplsPolicyLSPs can be associated. An mplsPolicyBackupLSP 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] cardinality indicates that
Chadha, et al. Expires June 2001 [Page 45]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
there may be zero or more instances of mplsPolicyTrafficTrunk
associated with any given mplsPolicyLSP, i.e. an LSP can be a backup
for zero or more traffic trunks.
5.21.2. The reference mpLSP
This property contains an object reference to an mplsPolicyLSP
instance with which zero or more mplsPolicyTrafficTrunks can be
associated. An mplsPolicyBackupLSP 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 mplsPolicyLSP associated with any given
mplsPolicyTrafficTrunk, i.e. there may be zero or more backup LSPs
for this traffic trunk.
5.21.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 Integer
5.22.
Association mplsPolicyLSPinLSP
The association mplsPolicyLSPinLSP associates an LSP with another
LSP and indicates a hierarchical relationship between the two LSPs.
The association definition is as follows:
NAME mplsPolicyLSPinLSP
DESCRIPTION Associates an LSP with another LSP, indicating
a hierarchical relationship between the two.
ABSTRACT False
PROPERTIES mpContainingLSP [ref mplsPolicyLSP [0..n]],
mpContainedLSP [ref mplsPolicyLSP [0..n]]
5.22.1. The reference mpContainingLSP
This property contains an object reference to an mplsPolicyLSP
instance associated with another mplsPolicyLSP. The [0..n]
cardinality indicates that there may be zero or more instances of
mplsPolicyLSP associated with other mplsPolicyLSPs via this
Chadha, et al. Expires June 2001 [Page 46]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
association, indicating that these LSPs all contain the referenced
LSP.
5.22.2. The reference mpContainedLSP
This property contains an object reference to an mplsPolicyLSP
instance associated with another mplsPolicyLSP. The [0..n]
cardinality indicates that there may be zero or more instances of
mplsPolicyLSP associated with other mplsPolicyLSPs via this
association, indicating that these LSPs are all contained in the
referenced LSP.
5.23.
Association mplsPolicyTT_TrafficProfile
The association mplsPolicyTT_TrafficProfile associates a traffic
trunk with a traffic profile, represented by an instance of
qosPolicyTrafficProfile. This traffic profile describes the
characteristics of the traffic carried by the referenced traffic
trunk.
The association definition is as follows:
NAME mplsPolicyTT_TrafficProfile
DESCRIPTION Associates a traffic trunk with a traffic
profile.
ABSTRACT False
PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]],
mpTrfcProf[ref qosPolicyTrafficProfile [0..1]]
5.23.1. The reference mpTT
This property contains an object reference to an
mplsPolicyTrafficTrunk instance associated with a
qosPolicyTrafficProfile. The [0..n] cardinality indicates that there
may be zero or more instances of mplsPolicyTrafficTrunk associated
with any given qosPolicyTrafficProfile; i.e. zero or more traffic
trunks can share the same traffic profile specification.
5.23.2. The reference mpTrfcProf
This property contains an object reference to a
qosPolicyTrafficProfile that is associated with an
mplsPolicyTrafficTrunk. The [0..1] cardinality indicates that there
may be zero or one traffic profiles associated with any given traffic
trunk.
5.24.
Association mplsPolicyLSP_TrafficProfile
The association mplsPolicyLSP_TrafficProfile associates an LSP with
a traffic profile, represented by an instance of
qosPolicyTrafficProfile. This traffic profile describes the
characteristics of the traffic carried by the referenced LSP.
Chadha, et al. Expires June 2001 [Page 47]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
The association definition is as follows:
NAME mplsPolicyLSP_TrafficProfile
DESCRIPTION Associates an LSP with a traffic profile.
ABSTRACT False
PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]],
mpTrfcProf[ref qosPolicyTrafficProfile [0..1]]
5.24.1. The reference mpLSP
This property contains an object reference to an mplsPolicyLSP
instance associated with a qosPolicyTrafficProfile. The [0..n]
cardinality indicates that there may be zero or more instances of
mplsPolicyLSP associated with any given qosPolicyTrafficProfile;
i.e. zero or more LSPs can share the same traffic profile
specification.
5.24.2. The reference mpTrfcProf
This property contains an object reference to a
qosPolicyTrafficProfile that is associated with an mplsPolicyLSP. The
[0..1] cardinality indicates that there may be zero or one traffic
profiles associated with any given LSP.
5.25.
Association mplsPolicyFECofTrunk
The association mplsPolicyFECofTrunk associates a Traffic Trunk with
an FEC, represented by an instance of qosPolicyTrafficTrunk.
The association definition is as follows:
NAME mplsPolicyFECofTrunk
DESCRIPTION Associates a Traffic Trunk with a FEC.
ABSTRACT False
PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]],
mpFEC[ref mplsPolicyFEC [0..1]]
5.25.1. The reference mpLSP
This property contains an object reference to an
mplsPolicyTrafficTrunk instance associated with a mplsPolicyFEC. The
[0..n] cardinality indicates that there may be zero or more
instances of mplsPolicyTrafficTrunk associated with any given
mplsPolicyFEC; i.e. zero or more LSPs can share the same FEC
specification.
5.25.2. The reference mpFEC
This property contains an object reference to an mplsPolicyFEC that
is associated with an mplsPolicyTrafficTrunk. The [0..1] cardinality
indicates that there may be zero or one FEC associated with any given
traffic trunk.
Chadha, et al. Expires June 2001 [Page 48]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
5.26.
Association mplsPolicyFECofLSP
The association mplsPolicyFECofLSP associates an LSP with a FEC.
The association definition is as follows:
NAME mplsPolicyFECofLSP
DESCRIPTION Associates an LSP with a FEC.
ABSTRACT False
PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]],
mpFEC[ref mplsPolicyFEC [0..1]]
5.26.1. The reference mpLSP
This property contains an object reference to an mplsPolicyLSP
instance associated with a mplsPolicyFEC. The [0..n] cardinality
indicates that there may be zero or more instances of mplsPolicyLSP
associated with any given mplsPolicyFEC; i.e. zero or more LSPs can
share the same FEC specification.
5.26.2. The reference mpFEC
This property contains an object reference to an mplsPolicyFEC that
is associated with an mplsPolicyTrafficTrunk. The [0..1] cardinality
indicates that there may be zero or one FEC associated with any given
LSP.
5.27.
Association mplsPolicyFECFilterSet
The association mplsPolicyFECFilterSet associates a FilterList [CIM]
with an mplsPolicyFEC. A FilterList represents the packet identifier
of the FEC.
NAME mplsPolicyFECFilterSet
DESCRIPTION
ABSTRACT False
PROPERTIES mpFEC[ref mplsPolicyFEC[0..n],
mpFilter[ref FilterList[0..n],
mpFilterListPosition
5.27.1. The Property mpFEC
This property contains an object reference to an mplsPolicyFEC
instance with which a number of filters can be associated. The [0..n]
cardinality indicates that there may be 0, 1, or more than one
mplsPolicyFEC associated with any given filter. i.e. zero or more
FECs can share the same Filter specification.
5.27.2. The Property mpFilter
Chadha, et al. Expires June 2001 [Page 49]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
This property contains an object reference to a FilterList[CIM]
instance. The [0..n] cardinality indicates that there may be 0, 1, or
more than one FilterList associated with any given FEC.
5.27.3. The Property mpFilterListPosition
This property indicates the position of the FilterList in the FEC.
The property is defined as follows:
NAME mpFilterListPosition
DESCRIPTION
SYNTAX Integer (MUST be non-negative)
6. Examples
6.1. Establishing an LSP
This section provides an example that shows how the classes defined
above as part of the QoS information model for MPLS may be used in a
typical policy scenario. For the example scenario we assume an MPLS
network and two hosts (A and B) outside the MPLS domain (see Figure
4).
1.2.3.4
+--------+
| Host A | +------------------+
+--------+ / \
| +---------+ | 2.3.4.5
\--...--->| Ingress | +--------+
+---------+ | Egress |--\
1.2.3.5 | +--------+ |
\ MPLS domain / | +--------+
+------------------+ \-...->| Host B |
+--------+
2.3.4.6
Figure 4: Example MPLS Network
Furthermore, we assume for the scenario that traffic from A to B
should be mapped to a specific forwarding equivalence class of a
newly created LSP. The LSP be specified with a committed data rate
of 10Mb/s.
Chadha, et al. Expires June 2001 [Page 50]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
A provisioning policy to establish the LSP can be represented using
the classes defined in the MPLS information model as follows:
+--------------+
| PolicyRule |
+--------------+
|
|
+------------------------+
| mplsPolicyLSPAction |
+------------------------+
|
|
+------------------+
| mplsPolicyLSP |
+------------------+
|
| +-----------------+
|-- | mplsPolicyFEC |
| +-----------------+
| |
| | +----------------------------------+
| \--| FilterList |
| | TrafficType=IPv4 |
| | SourceIPAddress=1.2.3.4 |
| | DestinationIPAddress=2.3.4.6 |
| +----------------------------------+
|
| +---------------------------+
|-- | qosPolicyTrfcProf |
| | qpPRRate=10Mb/s |
| +---------------------------+
|
| +---------------------------------+
\-- | mplsPolicyRouteSpec |
| mpIngressIPAddress=1.2.3.5 |
| mpEgressIPAddress=2.3.4.5 |
+---------------------------------+
Figure 5: Representation of the example policy rule
The policy object illustrated in Figure 5 is built from policy
classes defined in CIM, QPIM and this document. The root of the
policy object is a rule object that is associated with no conditions
(i.e. provisioning case) and on LSP establishing action
(mplsPolicyLSPAction). The LSP is specified by an instance of
mplsPolicyLSP. The specification includes FEC specification
(mplsPolicyFEC), a specification of the LSP traffic profile of the
LSP (qosPolicyTrafficProfile) and the route specification
(mplsPolicyRouteSpec).
Chadha, et al. Expires June 2001 [Page 51]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
6.2. Network wide bandwidth adjustment example
The following example demonstrates the use of our information model
to define policies that are applied on a network-wide basis. In this
example, we describe the implementation of a network-wide policy
that varies bandwidth allocations based on time of day and type of
traffic using the policy information model. Traffic Trunks in the
network are assigned "roles" in accordance with the Olympic Services
Model, i.e. they are marked as "gold", "silver" or "bronze"
according to the QoS properties of the traffic that they carry. A
network-wide policy controls the bandwidth allocation associated
with these traffic trunks.
Specifically, the bandwidth for all gold TTs is reduced by 50%
during nights and weekends. This could be potentially useful if the
Service Level Agreements are such that a number of customers require
gold service during business hours on weekdays, while they subscribe
to lower service levels during non-business hours and weekends.
Policy rules are defined to describe the time-varying bandwidth
allocations to the appropriate Traffic Trunks. Associated with each
traffic trunk is a traffic profile that describes the resource
requirements for this trunk. Also associated with each traffic trunk
are one or more route specifications that specify possible ways of
routing this traffic trunk through the network. Each such route
specification has its hops specified.
For purposes of illustration, we assume the presence of a traffic
engineering module that uses these specifications, along with
information about the current nodes and links in the network, to
compute appropriate constrained routes from these route
specifications. In other words, not all route specifications will
necessarily be used to create LSPs. Each traffic trunk is assigned
to one or more LSPs according to its bandwidth requirements.
When the TT's bandwidth requirements are modified, the traffic
engineering module attempts to resize the LSP(s) for this TT to
accommodate the new bandwidth demand. If the existing LSPs are not
adequate, the traffic engineering module performs computations so
that new LSPs are established, in the manner described above.
Note that another scenario could be that the policy information
model and the traffic provide no route specifications engineering
module computes suitable LSPs based on traffic trunk attributes
alone.
For this example, the policy-based system contains the following:
- A number of activated TTs (instance of mplsPolicyTrafficTrunk),
each one assigned to one or more already established LSPs (instance
of mplsPolicyLSP). For the assignment association an instance of
mplsPolicyCurrentlyAssignedLSP association is used.
Chadha, et al. Expires June 2001 [Page 52]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
- Each TT is characterized as either "gold", "silver" or "bronze",
according to the QoS requirements of the traffic that is being
forwarded through it, using its Roles property to store this value.
- Each TT is associated (instance of mplsPolicyTT_TrafficProfile
association) with one traffic profile (instance of
qosPolicyPRTrfcProf).
- Each TT is associated (instance of mplsPolicyEligibleRouteSpec
association) with zero or more eligible route specifications
(instance of mplsPolicyRouteSpec).
- Each LSP is associated (instance of mplsPolicyLSPTrafficProfile
association) with one traffic profile.
To implement the network-wide policy described above, the following
two policy rules are required for the gold TTs:
Policy Rule 1: Roles property is set to "gold TT"
IF "time is 8am" AND ("day is Monday" OR "day is Tuesday"
OR "day is Wednesday" OR "day is Thursday"
OR "day is Friday")
THEN "Modify TT: Increase traffic profile bandwidth by 100%"
Policy Rule 2: Roles property is set to "gold TT"
IF "time is 5pm" AND ("day is Monday" OR "day is Tuesday"
OR "day is Wednesday" OR "day is Thursday"
OR "day is Friday")
THEN "Modify TT: Decrease traffic profile bandwidth by 50%"
The semantics of the first rule is that when the condition becomes
true, it modifies the traffic profile of all the gold TTs, such that
their bandwidth is increased by 100%.
In a similar fashion, the semantics of the second rule is that when
the condition becomes true, it modifies the traffic profile of all
the gold TTs such that their bandwidths get decreased by 50%. Note
that the increase and decrease is the same absolute amount.
Note that the "Roles" property of those two policy rules is set to
"gold TT" which indicates which TTs those rules are to be applied
to. In this case those two rules are applied to all the TTs that
have their Roles property also set to "gold TT".
When the traffic profiles of the gold TTs are modified, the traffic
engineering module is activated, to verify whether the current
mapping of TTs to LSPs is still valid. For each modified TT, the
traffic engineering module might either increase the bandwidth of
the currently assigned LSPs, or reroute it based on its attributes.
For modeling each of the above policy rules we use an instance of
PolicyRule (defined in [PCIM]), an instance of
PolicyTimePeriodCondition (also from [PCIM]) to represent the
condition part of the rule, and we have an instance of
mplsPolicyTTAction class to represent the action part of the rule,
Chadha, et al. Expires June 2001 [Page 53]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
with its mpTTmode property set to "TTModify". This action takes the
current TTs in the context of the action and modifies the traffic
profile of this TT by the given amount. Note that this poses some
problem with the current PCIM; see the section on open issues for a
description of this.
The Roles property is set to "gold TT" for the two rules (gold TT).
In this way, the two rules will be applied to all the TTs that are
considered gold and therefore have their Roles property set to "gold
TT".
7. Security Considerations
The security considerations for this document are the same as those
of [PCIM] and are not further addressed in this version of the draft.
8. Open Issues
The following open issues need to be resolved:
1) Control of Signaling protocol mechanisms: While the draft is
independent of the signaling protocol used for label distribution,
policy actions relating to the control of specific CR-LDP mechanisms
are incorporated in this version. These mechanisms may be moved to a
protocol-specific model in later versions.
2) The current draft contains traffic parameters specific to CR-LDP,
as well as generic traffic parameters. Future versions may include
additional parameters specific to other signaling protocols such as
RSVP-TE. Further discussion is required to assess whether this is
within the scope of the information model. Furthermore, this needs
to be discussed with the PQIM authors.
3) As discussed in the example, we want to calculate a new value for
the bandwidth property of the traffic trunk's traffic profile. This
raises three questions: how do we refer to the traffic profile in
the context of the action, how do we access a single property of the
traffic profile, and how do we calculate a new value for the traffic
profile based on its old value? We initially considered introducing
specific actions to do this, but decided to wait until a PCIM
extension (e.g., as proposed in [PCIM_EXT]) is discussed. Basically,
the same problem arises if a policy wants to add new traffic to a TT
or LSP (change the FEC by adding new filter entries etc.)
4) There may be a need to introduce a new class to model a Label
Switched Router (LSR). This class would be derived from
ComputerSystem in CIM.
5) mplsPolicyFEC and qosPolicyTrfcProf are derived from Policy.
Should they be derived from CIM's LogicalElement?
6) In a future version, we will replace all the references in the
actions with associations.
Chadha, et al. Expires June 2001 [Page 54]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
7) Section 4.2.2 Traffic Trunks: "If a traffic trunk going in the
reverse direction exists, it is associated with this traffic trunk
via the mplsPolicyReverseDirTT association." What is the precise
meaning of "in the reverse direction"? Possible meanings include
reverse Ingress/Egress ProtocolEndpoints; reverse route; the reverse
of the loosely specified route.
8) For the classes mplsPolicyLSP, mplsPolicyTrafficTrunc, and
mplsPolicyProtocolEndpoint, we have defined a role property "Roles".
First question, does PCIM support roles for objects not derived from
the class System in CIM? Second, is there a naming convention to be
used in order to meet PCIMs definition? If no, we will change the
name into unique names in order to more easily map the model into
different data representions such as LDAP.
9) In order to deal with DiffServ over MPLS, future work should take
into account the mapping from LSPs to PHBs, and mapping of packets
in LSPs to different PHBs (in case of E-LSPs [DS-MPLS]). Are there
other means needed in this area?
9. References
[CIM] 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
[PCIM] B. Moore, E. Ellesson, J. Strassner, "Policy Core Information
Model -- Version 1 Specification", Internet Draft,
, May, 2000.
[PQIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy
Framework QoS Information Model", Internet draft,
, April 2000.
[CRLDP] B. Jamoussi, "Constraint-Based LSP Setup using LDP",
Internet Draft, , March 2000.
[RSVP-TE] 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.
[DS-MPLS] F. LeFaucher, L. Wu, B. Davie, S. Davari, P. Vaanenen,
R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of
Differentiated Services", work in progrss,
draft-ietf-mpls-diff-ext-05.txt, June 2000.
[MPLS-ARCH] E.Rosen, A.Viswanathan, R.Callon, "Multiprotocol Label
Switching Architecture", work in progress,
draft-ietf-mpls-arch-06.txt, August 1999.
[MPLS-FW] R.Callon, P.Doolan, N.Feldman, A.Freddette, G.Swallow,
Chadha, et al. Expires June 2001 [Page 55]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
A.Viswanathan, "A Framework for MPLS", work in progress,
draft-ietf-mpls-framework-05.txt, September 1999.
[REQPMPLS] S. Wright, S. Herzog, F. Reichmayer, R. Jaeger,
"Requirements for Policy Enabled MPLS", work in progress,
draft-wright-policy-mpls-00.txt, March 2000.
[REQMPLS_TE] 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.
[MPLS-MIB] 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.
[RFC2702] D. Awduche, J. Malcom, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[RFC2430] Li, T. and Y. Rekhter, "Provider Architecture for
Differentiated Services and Traffic Engineering (PASTE)",
RFC 2430, October 1998.
[PCIM_EXT] M. Brunner, J. Quittek, "Policy Framework Core Info Model
Extensions", Internet Draft,
draft-brunner-policy-core-ext-00.txt, November 2000.
10. Authors' Addresses
Kazuhiko Isoyama, Makiko Yoshida
NEC Corporation
Development Laboratories
1131, Hinode, Abiko, Chiba, 270-1198, JAPAN
Phone: +81 471-85-6738
Fax: +81 471-85-6841
Email: [iso|myoshida]@ptl.abk.nec.co.jp
Marcus Brunner, Juergen Quittek
NEC Europe Ltd.
C&C Research Laboratories
Adenauerplatz 6
D-69115 Heidelberg, Germany
Phone: +49 (0)6221 905110
Fax: +49 (0)6221 9051155
Email: [brunner|quittek]@ccrle.nec.de
Ritu Chadha, George Mykoniatis, Alex Poylisher, Ravichander
Vaidyanathan
Telcordia Technologies
445 South Street
Chadha, et al. Expires June 2001 [Page 56]
Internet Draft Policy MPLS Info Model for QoS & TE November 2000
Morristown NJ 07960
Phone: +1-973-829-4869
Email: [chadha|mykoniat|sher|vravi]@research.telcordia.com
Andreas Kind
IBM Zurich Research Laboratory
Saumerstrasse 4
CH-8803 Ruschlikon
Switzerland
Phone: +41-1-724-8915
Fax +41-1-724-8578
Email: ank@zurich.ibm.com
Francis Reichmeyer
PfN, Inc.
26 Landsdowne St.
Cambridge, MA 02139
Phone: +1-617-529-3970
Email: franr@pfn.com
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 implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into 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, et al. Expires June 2001 [Page 57]