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 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]