policy/mpls R. Chadha Internet Draft Huai-An (Paul) Lin Expires January 2001 Telcordia Technologies draft-chadha-policy-mpls-te-00.txt July 2000 Policy Information Model for MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The purpose of this draft is to describe an information model for representing MPLS traffic engineering policies. RFC 2702, "Requirements for Traffic Engineering over MPLS", is used as a basis for determining the types of information that need to be represented in such an information model. The latter document describes the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. The information model described in this draft attempts to capture the information required to enable the functional capabilities described in RFC 2702. This information model could be used by a management system to optimize network performance through the necessary network provisioning actions. An overview of policy-based management is given in this document, along with a description of the relationship of this work to other information models that are being defined in the IETF Policy Framework working group. This is followed by a detailed description of the information model, and a number of examples illustrating its use. Chadha Expires January 2001 1 Policy Information Model for MPLS Traffic Engineering July 2000 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction.....................................................3 1.1 Terminology....................................................3 1.2 Purpose of this document and Roadmap...........................4 2. Policy-Enabled MPLS Traffic Engineering..........................5 2.1 Relationship to previous work..................................5 2.2 Overview and Scope of this work................................6 3. Overview of MPLS Traffic Engineering Policy Data Model...........7 3.1 Overview of object classes and their associations..............7 3.2 High-level description of information model...................10 4. Detailed Description of MPLS Traffic Engineering Policy Information Model................................................................14 4.1 Object Class MPLSActivateTTAction.............................14 4.2 Object Class MPLSCreateLSPAction..............................16 4.3 Object Class MPLSDestroyLSPAction.............................16 4.4 Object Class MPLSDestroyTTAction..............................17 4.5 Object Class MPLSModifyTTAction...............................18 4.6 Object Class MPLSAssignLSPAction..............................18 4.7 Object Class MPLSDeassignLSPAction............................20 4.8 Object Class MPLSTrafficTrunk.................................21 4.9 Object Class MPLSRoute........................................25 4.10 Object Class MPLSLSP..........................................29 4.11 Object Class MPLSRouteSpec....................................31 4.12 Object Class MPLSResourceProfile..............................31 4.13 Object Class MPLSResources....................................33 4.14 The association MPLSHopInRoute................................35 4.15 The association MPLSASInRoute.................................36 4.16 The association MPLSSystemResources...........................37 4.17 The association MPLSEndpointResources.........................38 4.18 The association MPLSActiveConnection..........................38 4.19 The association MPLSReverseDirTT..............................40 4.20 The association MPLSEligibleRouteSpec.........................41 4.21 The association MPLSCurrentlyAssignedLSP......................42 4.22 The association MPLSBackupLSP.................................43 4.23 The association MPLSRouteResourceProfile......................44 4.24 The association MPLSRealizes..................................45 4.25 The association MPLSLSPinLSP..................................45 4.26 The association MPLSTrafficProfile............................46 5. Usage Examples..................................................47 5.1 Implementing Olympic Services.................................47 5.2 Creating traffic trunks.......................................54 5.3 Load balancing................................................57 5.4 Implementing Service Level Agreements (SLAs)..................57 6. Security Considerations.........................................58 7. Conclusions.....................................................58 8. References......................................................58 Chadha Expires January 2001 2 Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments.................................................60 10. Author's Addresses.............................................60 1. Introduction According to [3], Traffic Engineering (TE) is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives. The aspects of traffic engineering that are of interest for MPLS are measurement and control. A major goal of Internet traffic engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance. Traffic engineering has become an indispensable function in many large autonomous systems because of the high cost of network assets and the commercial and competitive nature of the Internet. These factors emphasize the need for maximal operational efficiency. The concept of MPLS traffic trunks is used extensively in the remainder of this document. According to Li and Rekhter [4], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. It is useful to view traffic trunks as objects that can be routed; that is, the path through which a traffic trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks. It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses. An LSP is a specification of the label switched path through which the traffic traverses. 1.1 Terminology The following abbreviations are used in this document: AS Autonomous System ATM Asynchronous Transfer Mode CIM Common Information Model CLI Command Line Interface COPS Common Open Policy Service DMTF Distributed Management Task Force FEC Forwarding Equivalence Class LDAP Lightweight Directory Access Protocol LSP Label Switched Path LSR Label Switched Router MAM Maximum Allocation Multiplier Chadha Expires January 2001 3 Policy Information Model for MPLS Traffic Engineering July 2000 MIB Management Information Base MPLS Multi-Protocol Label Switching PCIM Policy Core Information Model PDP Policy Decision Point QoS Quality of Service QPIM QoS Policy Information Model SLA Service Level Agreement SNMP Simple Network Management Protocol TE Traffic Engineering WG Work Group 1.2 Purpose of this document and Roadmap This document presents an object-oriented information model for representing MPLS traffic engineering policy information. The model is based on the Policy Core Information Model [5] currently being jointly developed by the IETF Policy Framework WG and by the Distributed Management Task Force (DMTF) as part of the CIM (Common Information Model) extensions work. Our model defines two hierarchies of object classes: structural classes representing policy information and MPLS-specific objects referenced by these policies; and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. The policy core information model is sufficiently generic to represent policies related to practically anything. Extensions of this model for representing QoS policies are being developed by the IETF Policy Framework WG [6]. The IETF IPSec Policy (ipsp) WG is also working on defining an information model for representing IPSec policies. This document derives object classes from the Policy Core Information Model and also makes use of some object classes from the QoS information model [6]. This document is organized in the following manner: - Section 2 describes the relationship of this work to previous work, provides a general overview of policies and how they are modeled. - Section 3 presents a high-level overview of the classes and associations comprising the Policy Information Model for MPLS Traffic Engineering. - Section 4 presents the detailed specifications for each of the object classes and associations in the data model. - Section 5 provides detailed examples illustrating the use of the Policy Information Model for MPLS Traffic Engineering. Chadha Expires January 2001 4 Policy Information Model for MPLS Traffic Engineering July 2000 2. Policy-Enabled MPLS Traffic Engineering 2.1 Relationship to previous work As described in the Policy Core Information Model (PCIM) [5], policies can be regarded as rules with two basic components: conditions and actions. Conditions are boolean expressions which evaluate to either true or false. Actions represent some concrete action that should be taken by a management system if the conditions in the rule evaluate to true. The policy framework described in PCIM provides an elaborate mechanism for prioritizing policy rules; specifying time periods during which policy rules are applicable; specifying complex boolean conditions using either disjunctive normal form or conjunctive normal form and negations; grouping policies together; specifying reusable conditions and actions; etc. Policies are specified using a declarative rather than a procedural approach, i.e. policies describe the conditions and actions that make up a rule, but do not give a step-by-step description of how to implement the policy. In the QoS Policy Information Model (QPIM) [6], new object classes are defined to model the management and configuration of Diffserv- and RSVP-capable network elements. Apart from QoS-specific information, the model contains a number of concepts that are rather general and can be re-used in a number of different contexts. One such concept is that of variables and constants with well-defined semantics that represent things like IP addresses, port numbers, protocol numbers, etc. These variables are used to describe traffic classifiers in QPIM. Such a representation is also very useful for the information model described in this draft, as there is a need to define the FECs (Forwarding Equivalence Classes) that map to given traffic trunks. Other concepts that are re-used from QPIM are those defining traffic profiles and policing actions (see object classes qosPolicyPRTrfcProf and qosPolicyPRAction in [6]). These are used here for describing the traffic profiles of traffic trunks, and the policing requirements for traffic trunks (including what to do with non-conforming traffic for a given traffic trunk). Earlier Internet drafts ([13, 14]) discuss policy for MPLS. [13] outlines requirements for policy-enabled MPLS and identifies two main categories of MPLS policies: LSP admission policies that map traffic flows onto LSPs, and LSP life cycle policies that affect LSP creation, deletion, configuration and monitoring. The information model presented in the current draft addresses both these categories of policies, excluding any monitoring requirements. In [14], the authors discuss policies for MPLS load balancing. The information model that we present is broader in scope and addresses all aspects of traffic engineering, including load balancing. Chadha Expires January 2001 5 Policy Information Model for MPLS Traffic Engineering July 2000 The information model in this draft builds upon the PCIM model and further refines it by adding new actions that are specific to the domain of MPLS traffic engineering. Actions are included for creating, modifying, and destroying traffic trunks and LSPs, and assigning LSPs to traffic trunks. Also, new object classes and associations are introduced to model MPLS traffic engineering concepts referenced by these actions, such as traffic trunks, route specifications, LSPs and their hops, resources and resource classes, etc. No attempt is made to define new object classes for representing classifier information as this is currently being addressed in QPIM. 2.2 Overview and Scope of this work This information model presented in this draft has been designed to support the functionality outlined in RFC 2702 [3]. The latter document describes the following notions which have been modeled in this document: - Basic traffic engineering attributes of traffic trunks - Basic operations on traffic trunks - Traffic parameter attributes - Generic path selection and management attributes - Resource attributes. This information model currently does not cover modeling of LSP monitoring and operational attributes (such as LSP lifetime, error statistics, etc.). Further, this document does not seek to select mechanisms for performing MPLS traffic engineering; rather, it enables the specification of MPLS traffic engineering policies by defining an information model that attempts to capture the information required to describe such policies. Thus, even though MPLS supports traffic engineering via a number of mechanisms (CR- LDP, RSVP) that allow LSPs to be managed, such mechanisms are not referenced in this information model. This is in conformance with the requirement in [13] that an MPLS policy information model should be independent of the MPLS mechanisms used. The policy actions described in this draft enable the specification of actions that create, modify, and destroy traffic trunks and LSPs; and assign/de-assign LSPs to/from traffic trunks (object classes MPLSActivateTTAction, MPLSCreateLSPAction, MPLSDestroyLSPAction, MPLSDestroyTTAction, MPLSModifyTTAction, MPLSAssignLSPAction, and MPLSDeassignLSPAction). These actions reference and manipulate traffic trunks, LSPs, and related objects and associations. The idea is that a traffic engineering management system would be able to specify policies that result in the manipulation of traffic trunks, LSPs, and related information. The implementation of the policies would be performed by a PDP (Policy Decision Point) (see [7]). The PDP could make use of mechanisms supported by network elements to implement the specified policies; e.g. COPS, SNMP, CLI, etc. Several MIBs have been defined that could be used for implementing such Chadha Expires January 2001 6 Policy Information Model for MPLS Traffic Engineering July 2000 policies, namely the MPLS Traffic Engineering MIB [8] and the MPLS LSR MIB [9], etc. 3. Overview of MPLS Traffic Engineering Policy Data Model 3.1 Overview of object classes and their associations The following figures show some of the new object classes and associations defined for the MPLS Traffic Engineering Policy Information Model. Some of these were briefly mentioned in the previous section. A number of object classes from previously defined information models, namely CIM [10] and QPIM [6], are also shown where necessary to illustrate new associations relating newly defined structural object classes to object classes previously defined in those information models. Object classes belonging to these information models are appropriately marked. A detailed description of the depicted object classes is provided in Section 4 of this document. +-----------------------------+ | qosPolicyPRTrfcProf (QPIM) | +-----------^-----------------+ 0..1| (a) | ---------- *| 0..1| | +-----------v---------v-+ | (b) | MPLSTrafficTrunk <------- | | 0..1 +-^-----------------^--^+ *| *| *| | | | (c) | (d)| |(e) | | | (f) | | | ---------- *| *| *| * | | +-----------------v-----+ * (g)* +-v--v-------------v----+ | | MPLSRouteSpec <---------> MPLSLSP <---- +-----------------------+ +-----------------------+ * Figure 1. Relationships between traffic trunks, LSPs, route specifications, and traffic profiles In Figures 1 and 2, boxes represent object classes and arrows represent associations between the classes. The following associations appear in Figure 1 above: (a) MPLSTrafficProfile (b) MPLSReverseDirTT (c) MPLSEligibleRouteSpec (d) MPLSCurrentlyAssignedLSP (e) MPLSBackupLSP Chadha Expires January 2001 7 Policy Information Model for MPLS Traffic Engineering July 2000 (f) MPLSLSPinLSP (g) MPLSRealizes An association represents a relationship between two classes (e.g. associations (a), (c), (d), (e), and (g) above in Figure 1), or between a class and itself (e.g. associations (b) and (f) in Figure 1). Cardinalities are part of each association; the cardinality of an association indicates how many instances of each class may be related to an instance of the other class. For example, the MPLSBackupLSP association has the cardinality "*" (i.e. "0..n") for both the MPLSTrafficTrunk and the MPLSLSP classes. These ranges are interpreted as follows: - The "*" written next to MPLSTrafficTrunk indicates that an MPLSLSP may be related to no MPLSTrafficTrunk, to one MPLSTrafficTrunk, or to more than one MPLSTrafficTrunk via the MPLSBackupLSP association. In other words, an LSP may be a backup LSP for zero or more traffic trunks. - The "*" written next to MPLSLSP indicates that a MPLSTrafficTrunk may be related to no MPLSLSP, to one MPLSLSP, or to more than one MPLSLSP via the MPLSBackupLSP association. In other words, a traffic trunk may have zero or more backup LSPs. ----------- (h)| | *| | +----------------+ +---------------v--+ | |ComputerSystem | | ProtocolEndpoint <------| | (CIM) | | (CIM) |* +----------- ^---+ +^---------^-------+ *| *| *| (i)| (j)| (k)| 0..1| 0..1| *| +----v-----------v+ +-v------------+ | MPLSResources | | MPLSRoute | +-----------------+ +^----------^--+ *| *| (l)| (m)| *| 0..1| +----------------------v+ +----v----------------+ | AutonomousSystem (CIM)| | MPLSResourceProfile | +-----------------------+ +---------------------+ Figure 2. Relationships between routes, hops, resources, etc. The following associations appear in Figure 2 above: (h) MPLSActiveConnection (i) MPLSSystemResources (j) MPLSEndpointResources (k) MPLSHopInRoute (l) MPLSASInRoute Chadha Expires January 2001 8 Policy Information Model for MPLS Traffic Engineering July 2000 (m) MPLSRouteResourceProfile The inheritance tree for the object classes defined in this document is given below. Apart from the new object classes defined in this document, the tree below contains references to object classes defined in the Policy Core Information Model [5], marked "PCIM" below, and to object classes defined in the Common Information Model [10], marked "CIM" below. For detailed descriptions of these object classes, please see the relevant documents. +--Policy (abstract) (PCIM) | | | +---PolicyAction (PCIM) | | | | | +---MPLSActivateTTAction | | | | | +---MPLSCreateLSPAction | | | | | +---MPLSDestroyLSPAction | | | | | +---MPLSDestroyTTAction | | | | | +---MPLSModifyTTAction | | | | | +---MPLSAssignLSPAction | | | | | +---MPLSDeassignLSPAction | | | +--- MPLSResourceProfile | +--CIM_ManagedSystemElement (abstract) (CIM) | +--CIM_LogicalElement (abstract) (CIM) | +--MPLSResources | +--MPLSTrafficTrunk | +--MPLSRoute (abstract) | +---MPLSRouteSpec | +---MPLSLSP Figure 3. Inheritance Hierarchy for MPLS Policy object classes In CIM, associations are also modeled as classes. For the MPLS Traffic Engineering Policy Information Model, the inheritance hierarchy is shown below: Chadha Expires January 2001 9 Policy Information Model for MPLS Traffic Engineering July 2000 [unrooted] | +---MPLSHopInRoute | +---MPLSASInRoute | +---MPLSSystemResources | +---MPLSEndpointResources | +---ActiveConnection (CIM) | | | +---MPLSActiveConnection | +---MPLSReverseDirTT | +---MPLSEligibleRouteSpec | +---MPLSCurrentlyAssignedLSP | +---MPLSBackupLSP | +---MPLSRouteResourceProfile | +---MPLSRealizes | +---MPLSLSPinLSP | +---MPLSTrafficProfile Figure 4. Inheritance Hierarchy for associations 3.2 High-level description of information model 3.2.1 MPLS Traffic Engineering Policy Actions A number of policy actions are defined for the purpose of enabling a management system to manipulate traffic trunks and LSPs. These actions may reference instances of traffic trunks, LSPs, and route specifications (see definition of route specification in Section 3.2.2). In order to reference such instances, they must first be created and populated; and any related objects and associations must also be instantiated and populated. For example, MPLSActivateTTAction activates a traffic trunk; the property mpTrafficTrunk in this action references an instance of a traffic trunk that is to be activated. Thus before instantiating an instance of MPLSActivateTTAction, one must instantiate an instance of MPLSTrafficTrunk that will be referenced by this action. In addition, all the related object instances and associations must also be instantiated before instantiating this action. RFC 2702 [3] Chadha Expires January 2001 10 Policy Information Model for MPLS Traffic Engineering July 2000 describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). 3.2.1.1 Referencing traffic trunks The following objects may need to be instantiated in order to fully describe a traffic trunk referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped. The association is modeled by the MPLSEligibleRouteSpec association. - Traffic profile: A traffic profile (qosPolicyPRAction) describing the resource requirements of a traffic trunk can be defined for every traffic trunk and associated with the traffic trunk via the MPLSTrafficProfile association. - Assigned LSPs: Any LSPs (MPLSLSP) currently assigned to a traffic trunk can be defined and associated with it via the MPLSCurrentlyAssignedLSP association. - Backup LSPs: Any LSPs (MPLSLSP) that are acting as backup LSPs for a traffic trunk can be defined and associated with it via the MPLSBackupLSP association. - Reverse traffic trunk: If a traffic trunk carrying traffic in the reverse direction exists, it can be associated with a given traffic trunk via the MPLSReverseDirTT association. 3.2.1.2 Referencing LSPs The following objects may need to be instantiated in order to fully describe an LSP referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with an LSP to indicate that this LSP is an realization of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Any traffic trunks (MPLSTrafficTrunk) whose traffic is currently being carried by an LSP should be defined and associated with this LSP via the MPLSCurrentlyAssignedLSP association. Further, any traffic trunks for which an LSP is a backup LSP should be associated with this LSP via the MPLSBackupLSP association. Chadha Expires January 2001 11 Policy Information Model for MPLS Traffic Engineering July 2000 - LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be associated with any LSPs contained in or containing it via the MPLSLSPinLSP association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of an LSP can be defined for every LSP and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every known hop in an LSP is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with an LSP via the MPLSHopInRoute association. - Autonomous systems in LSP path: If the path of an LSP through an external autonomous system is unknown, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with an LSP via the MPLSASInRoute association. 3.2.1.3 Referencing route specifications The following objects may need to be instantiated in order to fully describe a route specification referenced by an action: - LSPs: Zero or more LSPs (MPLSLSP) can be associated with a route specification to indicate that these LSPs are realizations of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Traffic trunks (MPLSTrafficTrunk) for which a given route specification is a potential route should be associated with the route specification via the MPLSEligibleRouteSpec association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of a route specification can be defined for every route specification and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every hop specified for a route specification is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with a route specification via the MPLSHopInRoute association. - Autonomous systems in route path: If a route specification is to be routed via an specified autonomous sytem, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with a route specification via the MPLSASInRoute association. Chadha Expires January 2001 12 Policy Information Model for MPLS Traffic Engineering July 2000 3.2.2 Traffic trunks, LSPs, and supporting object classes and associations The following object classes and associations are defined. Many of these are referenced by the actions described in the previous section. - Traffic trunk (object class MPLSTrafficTrunk): For a description of a traffic trunk, see the Introduction section of this document, or see RFC 2702 [3] for more details. The attributes of a traffic trunk are described by the properties of this object class. A traffic trunk can be associated with LSPs that are currently carrying its traffic (MPLSCurrentlyAssignedLSP association) and with backup LSPs that are used for backup in fault/congestion scenarios (MPLSBackupLSP association). Eligible routes for this traffic trunk are associated with it via the MPLSEligibleRouteSpec association. If a traffic trunk going in the reverse direction exists, it is associated with this traffic trunk via the MPLSReverseDirTT association. Finally, a traffic profile for this traffic trunk can be represented by the qosPolicyPRTrfcProf object class (reused from QPIM [6]) and associated with the traffic trunk via the MPLSTrafficProfile association. - Abstract route (object class MPLSRoute): This is an abstract object class that represents a route from point A to point B. The route may or may not be realized in the network by an LSP. In other words, a route could either be a specification of a route from one point to another, or it could be an actual LSP that has been set up in the network. A route is associated with all the hops contained in this route. These hops could either be interfaces on LSRs (represented by instances of ProtocolEndpoint, which is an object class defined in the CIM Network Model [10]), or they could be autonomous systems (represented by instances of AutonomousSystem, another object class defined in the CIM Network Model [10]). The associations with these hops are realized via the MPLSHopInRoute and MPLSASInRoute associations, respectively. A route may also be associated with a resource profile (represented by object class MPLSResourceProfile, defined in this draft) which describes the resource profile for this route, i.e. the allowable traffic rates and burst sizes, etc. (MPLSRouteResourceProfile association). - Route specification (object class MPLSRouteSpec): This object class is used to describe a specification of a route from one node to another and is derived from the MPLSRoute object class described above. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Also note that it could be an incomplete specification of a route; e.g. it could specify three hops for a route which actually requires at least four hops, and leave the job of choosing the missing hop to a signaling protocol that sets up the corresponding LSP. Its properties are inherited from MPLSRoute and are a subset of the Chadha Expires January 2001 13 Policy Information Model for MPLS Traffic Engineering July 2000 properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The typical use of this object class is for a network operator to be able to specify potential MPLS routes in advance and later instantiate them by creating LSPs that use this specification. A route specification can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped (MPLSEligibleRouteSpec association). - Label-Switched Path (LSP) (object class MPLSLSP): This object class represents an LSP. An LSP can be associated with a route specification in order to indicate that this LSP implements this route specification (MPLSRealizes association). An LSP can also be associated with a traffic trunk if it is currently carrying the traffic for this traffic trunk (via the MPLSCurrentlyAssignedLSP association) or if it is a backup LSP for this traffic trunk (via the MPLSBackupLSP association). An LSP can also be associated with another LSP to indicate a hierarchy of LSPs (MPLSLSPinLSP association). - Resource profile (object class MPLSResourceProfile): This object class represents the resource profile associated with a route, i.e. the allowable traffic rates and burst sizes, etc. - Resources (object class MPLSResources): This object class represents resources associated with LSRs and interfaces on these LSRs, such as buffer resources, etc. (MPLSSystemResources and MPLSEndpointResources associations, respectively). - Links and their resources (association MPLSActiveConnection): The resources associated with a link (e.g. bandwidth, etc.) are represented by properties of the association MPLSActiveConnection. This association is used to relate two instances of ProtocolEndpoint that currently have an active connection between them. Apart from these newly defined object classes and associations, the qosPolicyPRAction object class is reused from QPIM [6] for representing policing actions including actions to be taken for non- conforming traffic. Also, object classes qosPolicySimpleCondition, qosPolicyVariable, and qosPolicyValue and their derived classes from QPIM are used for representing classifier information. 4. Detailed Description of MPLS Traffic Engineering Policy Information Model This section provides a detailed description of all the newly defined object classes and associations in this information model, along with their properties. 4.1 Object Class MPLSActivateTTAction Chadha Expires January 2001 14 Policy Information Model for MPLS Traffic Engineering July 2000 This object class represents a policy action (see [5]) that creates an instance of a traffic trunk by assigning it to a traffic flow (referred to as "activation" of a traffic trunk in [3]). Note that a traffic trunk must first be established or defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). RFC 2702 [3] describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). The class definition is as follows: NAME MPLSActivateTTAction DESCRIPTION A class used to describe a policy action that activates a traffic trunk. DERIVED FROM policyAction (defined in [5]) ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.1.1 The property Name Name of the action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.1.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. The semantics are that this policy action assigns the traffic described in the condition portion of the corresponding policy rule to this traffic trunk. The condition portion of the containing policy rule would describe the FECs that are mapped to this traffic trunk by using instances of qosPolicySimpleCondition (from QPIM [6]). Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk associated with traffic described in the policy rule to which this action belongs SYNTAX Reference to an MPLSTrafficTrunk Chadha Expires January 2001 15 Policy Information Model for MPLS Traffic Engineering July 2000 4.2 Object Class MPLSCreateLSPAction This class is used to create an LSP. Note that a route specification must first be defined by creating an instance of MPLSRouteSpec and related objects/associations (see Section 3.2.1.3 for details). NAME MPLSCreateLSPAction DESCRIPTION A class that represents an action that creates an MPLS LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpCreateLSP 4.2.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string 4.2.2 The property mpCreateLSP This property contains a reference to an MPLSRouteSpec according to whose specifications an LSP is to be created. The property definition is as follows: NAME mpCreateLSP DESCRIPTION Specification of LSP to be created SYNTAX Reference to an instance of MPLSRouteSpec 4.3 Object Class MPLSDestroyLSPAction This class is used to represent the action of tearing down an LSP and reclaiming all the resources allocated to it. NAME MPLSDestroyLSPAction DESCRIPTION A class that represents an action that destroys an LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpLSP 4.3.1 The property Name Chadha Expires January 2001 16 Policy Information Model for MPLS Traffic Engineering July 2000 Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.3.2 The property mpLSP This property is a reference to the instance of MPLSLSP that is to be torn down. The property definition is as follows: NAME mpLSP DESCRIPTION Reference to LSP being destroyed. SYNTAX Reference to an instance of MPLSLSP 4.4 Object Class MPLSDestroyTTAction This class is used to represent the action of tearing down a traffic trunk and reclaiming all the resources allocated to it. This does not mean that the LSP(s) assigned to this trunk will be torn down; rather, such LSPs will have more resources available for carrying alternate traffic. NAME MPLSDestroyTTAction DESCRIPTION A class that represents an action that destroys a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.4.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.4.2 The property mpTrafficTrunk Chadha Expires January 2001 17 Policy Information Model for MPLS Traffic Engineering July 2000 This property is a reference to the instance of MPLSTrafficTrunk that is to be torn down. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk being destroyed. SYNTAX Reference to an instance of MPLSTrafficTrunk 4.5 Object Class MPLSModifyTTAction This class is used to modify a traffic trunk. Note that the traffic trunk is assumed to have been defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). NAME MPLSModifyTTAction DESCRIPTION A class that represents an action that modifies an MPLS traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.5.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string 4.5.2 The property mpTrafficTrunk This property contains a reference to an MPLSTrafficTrunk that is to be modified. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk to be modified SYNTAX Reference to an instance of MPLSTrafficTrunk 4.6 Object Class MPLSAssignLSPAction This class is used to represent the action of assigning an LSP to a traffic trunk. Note that the traffic trunk and LSP are assumed to Chadha Expires January 2001 18 Policy Information Model for MPLS Traffic Engineering July 2000 have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSAssignLSPAction DESCRIPTION A class that represents an action that assigns an LSP to a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpAssignedLSP 4.6.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.6.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk to which an LSP is being assigned SYNTAX Reference to an MPLSTrafficTrunk 4.6.3 The property mpAssignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this action is to be sent over the referenced LSP. The property definition is as follows: NAME mpAssignedLSP DESCRIPTION Reference to LSP being assigned to a traffic trunk SYNTAX Reference to an instance of MPLSLSP Chadha Expires January 2001 19 Policy Information Model for MPLS Traffic Engineering July 2000 4.7 Object Class MPLSDeassignLSPAction This class is used to represent the action of de-assigning an LSP from a traffic trunk, i.e. if the traffic belonging to a traffic trunk was being sent over a given LSP, this action stops any further traffic from this traffic trunk from being sent over this LSP. Note that the traffic trunk and LSP are assumed to have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSDeassignLSPAction DESCRIPTION A class that represents an action that de-assigns an LSP from a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpDeassignedLSP 4.7.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.7.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk for which an LSP is being de-assigned SYNTAX Reference to an MPLSTrafficTrunk 4.7.3 The property mpDeassignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this Chadha Expires January 2001 20 Policy Information Model for MPLS Traffic Engineering July 2000 action is assumed to be currently transported by the referenced LSP and is no longer to be sent over this LSP. The property definition is as follows: NAME mpDeassignedLSP DESCRIPTION Reference to LSP being de-assigned from a traffic trunk SYNTAX Reference to an instance of MPLSLSP 4.8 Object Class MPLSTrafficTrunk This object class is used to represent an MPLS traffic trunk and its properties. A traffic trunk is an aggregation of traffic flows of the same class which are placed inside an LSP (or more than one LSPs, in the case of load balancing). Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. This class contains properties describing attributes that can be associated with traffic trunks to influence their behavioral characteristics. Several of these attributes are drawn from RFC 2702 [3]. The class definition is as follows: NAME MPLSTrafficTrunk DESCRIPTION A class with several properties for describing an MPLS traffic trunk. DERIVED FROM LogicalElement ABSTRACT FALSE PROPERTIES Name mpResourceClassAffinity mpPreemption mpPriority mpResilience mpTrafficProportion mpReoptimizationFreq 4.8.1 The property Name Name for this traffic trunk. The property definition is as follows: NAME Name DESCRIPTION Name for this traffic trunk. SYNTAX string 4.8.2 The property mpResourceClassAffinity Chadha Expires January 2001 21 Policy Information Model for MPLS Traffic Engineering July 2000 This property represents the resource class affinity attributes (see [3]) associated with a traffic trunk which can be used to specify the class of resources that are to be explicitly included or excluded from the path of the traffic trunk (the property mpResourceClass, which appears in object class MPLSResources and in association MPLSActiveConnection, describes the "class" that a resource belongs to). The mpResourceClassAffinity property contains a list of policy attributes which can be used to impose additional constraints on the path traversed by a given traffic trunk. The resource class affinity property for a traffic trunk contains a string of the form: <resource-class, affinity; resource-class, affinity; ...> The "resource-class" parameter in the above identifies a resource class for which an affinity relationship is defined with respect to the traffic trunk. The "affinity" parameter above is a boolean value that indicates the affinity relationship; that is, whether members of the resource class are to be included or excluded from the path of the traffic trunk. The value "true" signifies explicit inclusion, and the value "false" specifies explicit exclusion. If no resource class affinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the traffic trunk and all resources. That is, there is no requirement to explicitly include or exclude any resources from the traffic trunk's path. This should be the default in practice. Resource class affinity attributes are very useful and powerful constructs because they can be used to implement a variety of policies. For example, they can be used to contain certain traffic trunks within specific topological regions of the network. A "constraint-based routing" framework (see [3]) can be used to compute an LSP for a traffic trunk subject to resource class affinity constraints in the following manner: 1. For explicit inclusion, prune all resources not belonging to the specified classes before performing LSP computation. 2. For explicit exclusion, prune all resources belonging to the specified classes before performing LSP computation. The property definition is as follows: NAME mpResourceClassAffinity DESCRIPTION String containing resource class affinities SYNTAX string 4.8.3 The property mpPreemption Chadha Expires January 2001 22 Policy Information Model for MPLS Traffic Engineering July 2000 The preemption attribute (see [3]) determines whether a traffic trunk can preempt another traffic trunk from a given path, and whether it can be preempted by another traffic trunk. Preemption can used to assure that high priority traffic trunks can always be routed through relatively favorable paths within a differentiated services environment. Preemption can also be used to implement various prioritized restoration policies following fault events. The preemption property can take one of four values, with the following semantics: 1. preemptor-enabled: can preempt lower priority preemptable traffic trunks 2. non-preemptor: cannot preempt other traffic trunks 3. preemptable: can be preempted by higher priority preemptor- enabled traffic trunks 4. non-preemptable: cannot be preempted. It is trivial to see that some of the preempt modes are mutually exclusive. Using the numbering scheme depicted above, the feasible preempt mode combinations for a given traffic trunk are as follows: (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be the default. A traffic trunk, say "A", can preempt another traffic trunk, say "B", only if *all* of the following five conditions hold: 1. "A" has a relatively higher priority than "B" 2. "A" contends for a resource utilized by "B" 3. The resource cannot concurrently accommodate "A" and "B" based on certain decision criteria 4. "A" is preemptor enabled 5. "B" is preemptable. Preemption is not considered a mandatory attribute under the current best effort Internet service model, although it may be useful. However, in a differentiated services scenario, the need for preemption becomes more compelling. Moreover, in the emerging optical internetworking architectures, where some protection and restoration functions may be migrated from the optical layer to data network elements (such as gigabit and terabit label switching routers) to reduce costs, preemptive strategies can be used to reduce the restoration time for high priority traffic trunks under fault conditions. The property definition is as follows: NAME mpPreemption DESCRIPTION Contains preemptability information SYNTAX uint16[] (values from 1 to 4) 4.8.4 The property mpPriority Chadha Expires January 2001 23 Policy Information Model for MPLS Traffic Engineering July 2000 The priority of a traffic trunk is described by this property. The priority property defines the relative importance of traffic trunks. If a constraint-based routing framework is used with MPLS, priorities can be used to determine the order in which path selection is done for traffic trunks at connection establishment and under fault scenarios. Priorities are also important in implementations permitting preemption because they can be used to impose a partial order on the set of traffic trunks according to which preemptive policies can be applied. The priority of a traffic trunk, along with its preemptability information (see the description of the mpPreemption property in the previous section), determines when it will preempt and/or be preempted by other traffic trunks. The property definition is as follows: NAME mpPriority DESCRIPTION Priority for this traffic trunk. SYNTAX uint16 4.8.5 The property mpResilience The mpResilience property indicates the recovery procedure to be applied to traffic trunks whose paths are impacted by faults. More specifically, it contains a boolean value that determines whether the target traffic trunk is to be rerouted or not when segments of its path fail. Note that RFC 2702 [3] discusses extended resilience attributes that could be used to specify detailed actions to be taken when faults occur. The representation of such attributes is left for further study. The property definition is as follows: NAME mpResilience DESCRIPTION If set to true, this traffic trunk should be rerouted in case of failure; if false, it should not. SYNTAX boolean 4.8.6 The property mpTrafficProportion This property is used to indicate the relative proportion of traffic to be carried by parallel traffic trunks. This enables one to perform load distribution across multiple parallel traffic trunks between two nodes. In many practical situations, the aggregate traffic between two nodes may be such that no single link can carry the load. In this case, the only feasible solution is to appropriately divide the aggregate traffic into sub-streams and route the sub-streams through multiple paths between the two nodes. Chadha Expires January 2001 24 Policy Information Model for MPLS Traffic Engineering July 2000 This problem can be addressed by instantiating multiple traffic trunks between the two nodes, such that each traffic trunk carries a proportion of the aggregate traffic. The proportion of traffic carried by each such trunk is specified by the mpTrafficProportion property. The property definition is as follows: NAME mpTrafficProportion DESCRIPTION Proportion of traffic to be carried by this traffic trunk, specified as a percentage from 0 to 100. SYNTAX uint16 4.8.7 The property mpReoptimizationFreq Due to changes in network and traffic characteristics, there may be a need to periodically change the paths of traffic trunks for optimization purposes. This should not be done too frequently as this could adversely affect the stability of the network. This property indicates how often such reoptimization should be performed. The property definition is as follows: NAME mpReoptimizationFreq DESCRIPTION Indicates how frequently reoptimization should be performed for this traffic trunk. If the value of this property is set to zero, this indicates that reoptimization should not be performed. SYNTAX uint16 4.9 Object Class MPLSRoute This object class is used to represent an MPLS route and its properties. An MPLS route is an abstract class with two structural subclasses, MPLSRouteSpec and MPLSLSP, representing a specification of an MPLS route or a concrete LSP respectively. Some of the properties of this class have been drawn from the mplsTunnelTable in the MPLS Traffic Engineering MIB [8]. The class definition is as follows: NAME MPLSRoute DESCRIPTION A class with several properties for describing an MPLS route. DERIVED FROM LogicalElement ABSTRACT true PROPERTIES Name mpIngressIPAddress mpEgressIPAddress Chadha Expires January 2001 25 Policy Information Model for MPLS Traffic Engineering July 2000 mpCOS mpSignalingProtocol mpSetupPriority mpHoldingPriority mpIngressMayReroute mpIsPersistent mpLocalProtectionAvailable mpIsPinned mpOwner mpInstancePriority mpIsAdaptive mpPreference 4.9.1 The property Name The canonical name assigned to the MPLS route. The property definition is as follows: NAME Name DESCRIPTION MPLS route name SYNTAX string 4.9.2 The property mpIngressIPAddress Ingress IP address for this MPLS route. The property definition is as follows: NAME mpIngressIPAddress DESCRIPTION Ingress IP address for this MPLS route. SYNTAX string 4.9.3 The property mpEgressIPAddress Egress IP address for this MPLS route. The property definition is as follows: NAME mpEgressIPAddress DESCRIPTION Egress IP address for this MPLS route. SYNTAX string 4.9.4 The property mpCOS This property defines the class of service for this MPLS route. This class of service could represent either a DSCP value or a ToS value. Further refinement of this property definition is for further study. Chadha Expires January 2001 26 Policy Information Model for MPLS Traffic Engineering July 2000 The property definition is as follows: NAME mpCOS DESCRIPTION Class of service for MPLS route SYNTAX uint16 DEFAULT VALUE 0 4.9.5 The property mpSignalingProtocol The signaling protocol, if any, used or to be used to set up this MPLS route. The property definition is as follows: NAME mpSignalingProtocol DESCRIPTION Signaling protocol used or to be used to set up this MPLS route. SYNTAX uint16 VALUES none(1), ldp(2), rsvp(3), other(4) 4.9.6 The property mpSetupPriority Indicates the setup priority of this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpSetupPriority DESCRIPTION Indicates the setup priority of this MPLS route. SYNTAX uint16 4.9.7 The property mpHoldingPriority Indicates the holding priority for this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpHoldingPriority DESCRIPTION Holding priority for this MPLS route SYNTAX uint16 4.9.8 The property mpIngressMayReroute This flag indicates that the MPLS route ingress node may choose to reroute this MPLS route without tearing it down. The property definition is as follows: Chadha Expires January 2001 27 Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpIngressMayReroute DESCRIPTION Fast reroute enabled SYNTAX boolean 4.9.9 The property mpIsPersistent Indicates whether this MPLS route should be restored automatically after a failure occurs. The property definition is as follows: NAME mpIsPersistent DESCRIPTION Indicates whether this MPLS route is persistent or not SYNTAX boolean 4.9.10 The property mpLocalProtectionAvailable This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit routing of this MPLS route. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. The property definition is as follows: NAME mpLocalProtectionAvailable DESCRIPTION Indicates whether local protection is available SYNTAX boolean 4.9.11 The property mpIsPinned This flag indicates whether the loose-routed hops of this MPLS route are to be pinned (see [11]). The property definition is as follows: NAME mpIsPinned DESCRIPTION Indicates whether the route is pinned SYNTAX boolean 4.9.12 The property mpOwner Indicates which protocol created/should create this route and is/should be responsible for managing it. The property definition is as follows: Chadha Expires January 2001 28 Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpOwner DESCRIPTION Indicates which protocol created/should create this route and is/should be responsible for managing it. SYNTAX uint16 VALUES snmp (1), ldp (2), rsvp (3),policyAgent (4), other (5) 4.9.13 The property mpInstancePriority This value indicates the priority for this route, with zero indicating the lowest priority. The property definition is as follows: NAME mpInstancePriority DESCRIPTION Route Priority SYNTAX uint16 4.9.14 The property mpIsAdaptive An MPLS route might need to re-route itself (e.g. due to re- optimization, connectivity problems, increase in bandwidth, etc.). If an MPLS route is configured to be adaptive, it (a) maintains existing resources until a new path is set up (b) avoids double-counting for links shared by the old and new paths. The property definition is as follows: NAME mpIsAdaptive DESCRIPTION A boolean indicating whether an MPLS route is adaptive or not. SYNTAX boolean DEFAULT VALUE true 4.9.15 The property mpPreference Multiple MPLS routes may exist between ingress and egress routers; the MPLS route with the lowest preference is used (useful for load balancing). The property definition is as follows: NAME mpPreference DESCRIPTION Preference assigned to an MPLS route. SYNTAX uint16 4.10 Object Class MPLSLSP Chadha Expires January 2001 29 Policy Information Model for MPLS Traffic Engineering July 2000 This object class is used to represent an MPLS LSP and its properties. Instances of this class represent existing LSPs in the network. The class definition is as follows: NAME MPLSLSP DESCRIPTION A class with several properties for describing an MPLS LSP. DERIVED FROM MPLSRoute ABSTRACT FALSE PROPERTIES Name mpAdminStatus mpOperationalStatus mpLevel 4.10.1 The property Name This is the canonical name assigned to the LSP. The name may be the tunnel ID or may be the name used to refer to the LSP on the LSR's console port (see the definition of mplsTunnelName in [8]). This definition may need further refinement in subsequent versions of this document. The property definition is as follows: NAME Name DESCRIPTION Name for this LSP. SYNTAX string 4.10.2 The property mpAdminStatus This property indicates the desired operational status of this LSP. The property definition is as follows: NAME mpAdminStatus DESCRIPTION Administrative status of an LSP. SYNTAX uint16 VALUES up(1), down(2), testing(3) 4.10.3 The property mpOperationalStatus This property indicates the actual operational status of this LSP, which is typically (but is not limited to) a function of the state of individual segments of this LSP. The property definition is as follows: NAME mpOperationalStatus DESCRIPTION Operational status of an LSP. Chadha Expires January 2001 30 Policy Information Model for MPLS Traffic Engineering July 2000 SYNTAX uint16 VALUES up(1), down(2), testing(3), unknown(4), dormant(5), notPresent(6), lowerLayerDown(7) 4.10.4 The property mpLevel This property indicates the nesting level of this LSP. The property definition is as follows: NAME mpLevel DESCRIPTION LSP nesting level. SYNTAX uint16 4.11 Object Class MPLSRouteSpec This object class is used to represent a specification of a potential path for routing an MPLS traffic trunk. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Its properties are inherited from MPLSRoute and are a subset of the properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The class definition is as follows: NAME MPLSRouteSpec DESCRIPTION A class describing an MPLS route specification. DERIVED FROM MPLSRoute ABSTRACT FALSE 4.12 Object Class MPLSResourceProfile This object class describes bandwidth resources required or used by an MPLS route (recall that an MPLS route is an abstract class and can be instantiated either as an MPLS LSP or as an MPLS route specification). The properties describing these resources form a resource profile and different LSPs/route specifications with the same resource profile can reuse the same instance of this object class via the MPLSRouteResourceProfile association. The properties of this object class are derived from the mplsTunnelResourceTable in the MPLS TE MIB [8]. The class definition is as follows: NAME MPLSResourceProfile DESCRIPTION A class with several properties for Chadha Expires January 2001 31 Policy Information Model for MPLS Traffic Engineering July 2000 describing resources required or used by zero or more MPLS LSPs and/or route specifications. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES Name mpInMaxRate mpInMeanRate mpInMaxBurstSize mpOutMaxrate mpOutMeanRate mpOutMaxBurstSize 4.12.1 The property Name Name of this resource profile. The property definition is as follows: NAME Name DESCRIPTION Name of this resource profile. SYNTAX string 4.12.2 The property mpInMaxRate The maximum incoming rate in bits/second. Note that setting mpInMaxRate, mpInMeanRate, and mpInMaxBurstSize to 0 indicates best- effort treatment. The property definition is as follows: NAME mpInMaxRate DESCRIPTION Maximum incoming rate in bits/second. SYNTAX uint16 4.12.3 The property mpInMeanRate The mean incoming rate in bits/second. The property definition is as follows: NAME mpInMeanRate DESCRIPTION Mean incoming rate in bits/second. SYNTAX uint16 4.12.4 The property mpInMaxBurstSize The maximum burst size in bytes. The property definition is as follows: Chadha Expires January 2001 32 Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpInMaxBurstSize DESCRIPTION The maximum burst size in bytes. SYNTAX uint16 4.12.5 The property mpOutMaxrate The maximum outgoing rate in bits/second. Note that setting mpOutMaxRate to 0 indicates best-effort treatment. The property definition is as follows: NAME mpOutMaxrate DESCRIPTION The maximum outgoing rate in bits/second. SYNTAX uint16 4.12.6 The property mpOutMeanRate The mean outgoing rate in bits/second. The property definition is as follows: NAME mpOutMeanRate DESCRIPTION The mean outgoing rate in bits/second. SYNTAX uint16 4.12.7 The property mpOutMaxBurstSize The maximum outgoing burst size in bytes. The property definition is as follows: NAME mpOutMaxBurstSize DESCRIPTION The maximum outgoing burst size in bytes. SYNTAX uint16 4.13 Object Class MPLSResources This class represents resources associated with LSRs and with interfaces on LSRs. The resources described by this class are associated with the corresponding LSRs/interfaces via the MPLSSystemResources and the MPLSEndpointResources associations, respectively. The class definition is as follows: NAME MPLSResources DESCRIPTION Resources associated with LSRs and their interfaces Chadha Expires January 2001 33 Policy Information Model for MPLS Traffic Engineering July 2000 ABSTRACT false DERIVED FROM LogicalElement PROPERTIES Name mpBufferResources mpMaxAllocMultiplier mpResourceClass 4.13.1 The property Name Name for this set of resources. The property definition is as follows: NAME Name DESCRIPTION Name for this set of resources SYNTAX string 4.13.2 The property mpBufferResources Buffer resources for an LSR or an LSR interface. The property definition is as follows: NAME mpBufferResources DESCRIPTION Buffer resources. SYNTAX uint16 4.13.3 The property mpMaxAllocMultiplier The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to buffer resources on LSRs. The value of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of buffer resources that are available for allocation to traffic trunks. SYNTAX uint16 4.13.4 The property mpResourceClass Chadha Expires January 2001 34 Policy Information Model for MPLS Traffic Engineering July 2000 This property describes the "class" that a resource belongs to (see [3]). Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belongs to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class(es) that a resource belongs to. SYNTAX uint16[] 4.14 The association MPLSHopInRoute The association MPLSHopInRoute provides a way to associate hops with MPLSRoutes. Hops are instances of ProtocolEndpoint (from the CIM model [10]) and represent LSR interfaces. The association definition is as follows: NAME MPLSHopInRoute DESCRIPTION Associates hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute[ref MPLSRoute[0..n]] mpHop[ref ProtocolEndpoint[0..n]] mpIsStrict mpOrder 4.14.1 The reference mpRoute This property contains an object reference to an MPLSRoute with which a number of hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given hop, indicating that this hop is contained in all these routes. 4.14.2 The reference mpHop Chadha Expires January 2001 35 Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one hops associated with any given MPLSRoute. These are all the hops that are included in the route specification. 4.14.3 The property mpIsStrict Denotes whether the referenced hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced hop is routed in a strict or loose fashion. SYNTAX boolean 4.14.4 The property mpOrder This property indicates the hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION Hop sequence SYNTAX uint16 4.15 The association MPLSASInRoute The association MPLSASInRoute provides a way to associate AS hops with MPLSRoutes. AS hops are instances of AutonomousSystem (from the CIM model [10]) and represent autonomous systems. The association definition is as follows: NAME MPLSASInRoute DESCRIPTION Associates AS hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute [ref MPLSRoute[0..n]] mpHop[ref AutonomousSystem[0..n]] mpIsStrict mpOrder 4.15.1 The reference mpRoute This property contains an object reference to an MPLSRoute with which a number of autonomous system hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than Chadha Expires January 2001 36 Policy Information Model for MPLS Traffic Engineering July 2000 one MPLSRoutes associated with any given AS hop, indicating that this AS hop is contained in all these routes. 4.15.2 The reference mpHop This property contains an object reference to an AutonomousSystem that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one AS hops associated with any given MPLSRoute. These are all the AS hops that are included in the route specification. 4.15.3 The property mpIsStrict Denotes whether the referenced AS hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced AS hop is Routed in a strict or loose fashion. SYNTAX boolean 4.15.4 The property mpOrder This property indicates the AS hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION AS hop sequence SYNTAX uint16 4.16 The association MPLSSystemResources The association MPLSSystemResources associates a set of resources (object class MPLSResources) with an LSR (modeled by an instance of ComputerSystem as defined in the CIM model [13]). The association definition is as follows: NAME MPLSSystemResources DESCRIPTION Associates MPLS resources with an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpLSR [ref ComputerSystem[0..n]] 4.16.1 The reference mpResources Chadha Expires January 2001 37 Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to an MPLSResources instance to which zero or one ComputerSystems (representing LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR. 4.16.2 The reference mpLSR This property contains an object reference to a ComputerSystem (representing an LSR) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSRs associated with any given MPLSResources instance. These LSRs all have the same resource specifications. 4.17 The association MPLSEndpointResources The association MPLSEndpointResources associates a set of resources (object class MPLSResources) with an interface of an LSR (modeled by an instance of ProtocolEndpoint as defined in the CIM model [10]). The association definition is as follows: NAME MPLSEndpointResources DESCRIPTION Associates MPLS resources with an interface of an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpPE [ref ProtocolEndpoint [0..n]] 4.17.1 The reference mpResources This property contains an object reference to an MPLSResources instance to which zero or one ProtocolEndpoints (representing interfaces on LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR interface. 4.17.2 The reference mpPE This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSR interfaces associated with any given MPLSResources instance. These LSR interfaces all have the same resource specifications. 4.18 The association MPLSActiveConnection Chadha Expires January 2001 38 Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSActiveConnection associates a ProtocolEndpoint with another and represents a link between them. Here ProtocolEndpoint (taken from the CIM model [10]) represents an LSR interface. The association definition is as follows: NAME MPLSActiveConnection DESCRIPTION Represents a link between two LSR interfaces ABSTRACT false DERIVED FROM ActiveConnection (from CIM [10]) PROPERTIES mpEndpoint1 [ref ProtocolEndpoint [0..n]] mpEndpoint2 [ref ProtocolEndpoint [0..n]] mpBandwidth mpMaxAllocMultiplier mpResourceClass 4.18.1 The reference mpEndpoint1 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.2 The reference mpEndpoint2 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.3 The property mpBandwidth Bandwidth for the link represented by this connection. The property definition is as follows: NAME mpBandwidth DESCRIPTION Link bandwidth SYNTAX uint16 4.18.4 The property mpMaxAllocMultiplier Chadha Expires January 2001 39 Policy Information Model for MPLS Traffic Engineering July 2000 The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to link bandwidth. The values of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of link bandwidth that is available for allocation. SYNTAX uint16 4.18.5 The property mpResourceClass This property describes the "class" that a resource belongs to. Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belong to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class assigned to this link. SYNTAX uint16[] 4.19 The association MPLSReverseDirTT The association MPLSReverseDirTT associates an MPLS traffic trunk with a traffic trunk going in the reverse direction. Chadha Expires January 2001 40 Policy Information Model for MPLS Traffic Engineering July 2000 The association definition is as follows: NAME MPLSReverseDirTT DESCRIPTION Associates a traffic trunk with another going in the reverse direction. ABSTRACT false PROPERTIES mpTT1 [ref MPLSTrafficTrunk [0..1]] mpTT2 [ref MPLSTrafficTrunk [0..1]] 4.19.1 The reference mpTT1 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.19.2 The reference mpTT2 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.20 The association MPLSEligibleRouteSpec The association MPLSEligibleRouteSpec associates a MPLS traffic trunk with a route specification that is a potential route for this traffic trunk. The association definition is as follows: NAME MPLSEligibleRouteSpec DESCRIPTION Associates a traffic trunk with a route specification that is a potential route for this traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpRoute [ref MPLSRouteSpec [0..n]] mpPreference mpIsMandatory 4.20.1 The reference mpTT Chadha Expires January 2001 41 Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to an MPLSTrafficTrunk instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSRouteSpec; i.e. zero or more traffic trunks may share the same route specification, indicating that this route specification is an eligible route for these traffic trunks. 4.20.2 The reference mpRoute This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSTrafficTrunk. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSTrafficTrunk instance; i.e. any traffic trunk can have multiple eligible route specifications. 4.20.3 The property mpPreference This property represents the preference for the referenced route by the referenced traffic trunk. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced route for the referenced traffic trunk. SYNTAX uint16 4.20.4 The property mpIsMandatory Indicates whether this is a mandatory route for this traffic trunk or not. The property definition is as follows: NAME mpIsMandatory DESCRIPTION Indicates whether this is a mandatory route for this traffic trunk or not. SYNTAX boolean 4.21 The association MPLSCurrentlyAssignedLSP The association MPLSCurrentlyAssignedLSP associates the LSP to which a traffic trunk is assigned with that traffic trunk. The association definition is as follows: NAME MPLSCurrentlyAssignedLSP DESCRIPTION Associates a traffic trunk with the LSP Chadha Expires January 2001 42 Policy Information Model for MPLS Traffic Engineering July 2000 assigned to it. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] 4.21.1 The reference mpTT This property contains an object reference to an MPLSTrafficTrunk instance to which zero or more MPLSLSPs can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP could be carrying traffic for zero or more traffic trunks. 4.21.2 The reference mpLSP This property contains an object reference to an MPLSLSP instance to which zero or more MPLSTrafficTrunks can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. these LSPs are sharing the traffic load for this traffic trunk. 4.22 The association MPLSBackupLSP The association MPLSBackupLSP associates a backup LSP with an MPLS traffic trunk. The idea is that this LSP can be used as a backup for this traffic trunk if necessary. The association definition is as follows: NAME MPLSBackupLSP DESCRIPTION Associates a backup LSP with a traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] mpPreference 4.22.1 The reference mpTT This property contains an object reference to an MPLSTrafficTrunk instance with which zero or more MPLSLSPs can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] Chadha Expires January 2001 43 Policy Information Model for MPLS Traffic Engineering July 2000 cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP can be a backup for zero or more traffic trunks. 4.22.2 The reference mpLSP This property contains an object reference to an MPLSLSP instance with which zero or more MPLSTrafficTrunks can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. there may be zero or more backup LSPs for this traffic trunk. 4.22.3 The property mpPreference This property represents the preference for the referenced backup LSP by the referenced traffic trunk. In other words, an explicit order can be imposed on all the backup LSPs for a traffic trunk to indicate a sequence of backup LSPs ordered from most preferred to least preferred. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced backup LSP for the referenced traffic trunk. SYNTAX uint16 4.23 The association MPLSRouteResourceProfile The association MPLSRouteResourceProfile associates a resource profile with an MPLS route. The association definition is as follows: NAME MPLSRouteResourceProfile DESCRIPTION Associates a resource profile with an MPLS route. ABSTRACT false PROPERTIES mpResourceProf[ref MPLSResourceProfile [0..1]] mpRoute[ref MPLSRoute [0..n]] 4.23.1 The reference mpResourceProf This property contains an object reference to an MPLSResourceProfile instance associated with an MPLSRoute. The [0..1] cardinality Chadha Expires January 2001 44 Policy Information Model for MPLS Traffic Engineering July 2000 indicates that there may be zero or one instances of MPLSResourceProfile associated with any given MPLSRoute. 4.23.2 The reference mpRoute This property contains an object reference to an MPLSRoute that is associated with an MPLSResourceProfile. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given MPLSResourceProfile instance; i.e. zero or more MPLSRoutes can share the same resource profile definition. 4.24 The association MPLSRealizes The association MPLSRealizes associates an LSP with an MPLS route specification (MPLSRouteSpec). Such an association exists if the referenced LSP is an implementation of the referenced route specification. Recall that a route specification could be loosely or strictly specified; an LSP associated to a route specification via the MPLSRealizes association satisfies all the constraints laid down in this route specification. The association definition is as follows: NAME MPLSRealizes DESCRIPTION Associates an LSP with a route specification. ABSTRACT false PROPERTIES mpLSP [ref MPLSLSP [0..n]] mpRouteSpec [ref MPLSRouteSpec [0..n]] 4.24.1 The reference mpLSP This property contains an object reference to an MPLSLSP instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSRouteSpec; i.e. zero or more LSPs can be a realization of the same route specification. 4.24.2 The reference mpRouteSpec This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSLSP. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSLSP instance; i.e. any LSP can be a realization of have zero or more route specifications. 4.25 The association MPLSLSPinLSP Chadha Expires January 2001 45 Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSLSPinLSP associates an LSP with another LSP and indicates a hierachical relationship between the two LSPs. The association definition is as follows: NAME MPLSLSPinLSP DESCRIPTION Associates an LSP with another LSP, indicating a hierarchical relationship between the two. ABSTRACT false PROPERTIES mpContainingLSP [ref MPLSLSP [0..n]] mpContainedLSP [ref MPLSLSP [0..n]] 4.25.1 The reference mpContainingLSP This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs all contain the referenced LSP. 4.25.2 The reference mpContainedLSP This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs are all contained in the referenced LSP. 4.26 The association MPLSTrafficProfile The association MPLSTrafficProfile associates a traffic trunk with a traffic profile, represented by an instance of qosPolicyPRTrfcProf (defined in [6]). This traffic profile describes the characteristics of the traffic carried by the referenced traffic trunk. The association definition is as follows: NAME MPLSTrafficProfile DESCRIPTION Associates a traffic trunk with a traffic profile. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpTrfcProf[ref qosPolicyPRTrfcProf [0..1]] 4.26.1 The reference mpTT This property contains an object reference to an MPLSTrafficTrunk instance associated with a qosPolicyPRTrfcProf. The [0..n] cardinality indicates that there may be zero or more instances of Chadha Expires January 2001 46 Policy Information Model for MPLS Traffic Engineering July 2000 MPLSTrafficTrunk associated with any given qosPolicyPRTrfcProf; i.e. zero or more traffic trunks can share the same traffic profile specification. 4.26.2 The reference mpTrfcProf This property contains an object reference to a qosPolicyPRTrfcProf that is associated with an MPLSTrafficTrunk. The [0..1] cardinality indicates that there may be zero or one traffic profiles associated with any given traffic trunk. 5. Usage Examples 5.1 Implementing Olympic Services In the following example, the following scenario is depicted: - Manual LSP creation - Manual traffic trunk creation - Manual assignment of LSPs to traffic trunks. This should be contrasted with the example in the next section (Section 5.2), where a traffic trunk is defined in a policy and LSPs are assumed to be created automatically by a traffic engineering system based on traffic trunk route specifications and network status. This example illustrates the use of the information model described in this document for representing policies that govern the assignment of different classes of traffic to different MPLS LSPs. Suppose that an enterprise needs to implement three classes of service, gold, silver, and bronze, between a pair of sites. In this scenario, we assume that traffic is marked using IP precedence (ToS) bits in the IP header as follows: Traffic entitled to gold service is marked with ToS=3 Traffic entitled to silver service is marked with ToS=2 Traffic entitled to bronze service is marked with ToS=1. Let the two sites be IP subnets 10.1.0.0/16 and 10.2.0.0/16, respectively. 5.1.1 MPLS LSP creation The first task is to set up the MPLS LSPs for traffic between these two sites (note that this step could be performed after the step in Section 5.1.2 as well). We will assume that three MPLS LSPs are to be created, each with different bandwidth constraints and different routing, to carry the three different types of service above: Chadha Expires January 2001 47 Policy Information Model for MPLS Traffic Engineering July 2000 MPLS LSP 1: Carries gold service traffic MPLS LSP 2: Carries silver service traffic MPLS LSP 3: Carries bronze service traffic. To represent the creation of these three LSPs, we define one policy rule with three actions: - Each action corresponds to the creation of one LSP and is an instance of MPLSCreateLSPAction. - Each action refers to a route specification (instance of MPLSRouteSpec). - Each route specification is associated with a resource profile (instance of MPLSResourceProfile, association MPLSRouteResourceProfile) - Each route specification is associated with route hops for this route (a hop is an instance of ProtocolEndpoint) via association MPLSHopInRoute. Thus before defining the three policy actions, we need to define the corresponding three route specifications and the associated objects/associations. 5.1.1.1 Creation of route specifications We depict below the objects and associations that are created to represent the route specification for the Gold traffic class. Silver and bronze route specifications and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a route specification GoldRouteSpec with resource profile GoldResourceProfile and three hops, GoldHop1, GoldHop2, and GoldHop3. One instance of association MPLSRouteResourceProfile (which associates GoldRouteSpec and GoldResourceProfile) and three instances of association MPLSHopInRoute (which associate GoldRouteSpec with each of GoldHop1, GoldHop2, and GoldHop3) are created. Chadha Expires January 2001 48 Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ | GoldResourceProfile | | (instance of | | MPLSResourceProfile) | +-----------^-----------+ GoldRouteResourceProfile | (instance of | MPLSRouteResourceProfile) | | +-----------v---------v--------+ | GoldRouteSpec (instance of | | MPLSRouteSpec) | +-^-----------------^--------^-+ | | | GoldHop1InRoute | GoldHop2InRoute| | GoldHop3InRoute (instance of | (instance of | | (instance of MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | +---------------v-+ +-----------v-----+ +v----------------+ | GoldHop1 | | GoldHop2 | | GoldHop3 | | (instance of | | (instance of | | (instance of | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| +-----------------+ +-----------------+ +-----------------+ Figure 5. Gold route specification with resource profile and three hops 5.1.1.2 Creation of LSPs Once route specifications for the gold, silver, and bronze traffic have been created, the actions to create LSPs corresponding to these three route specifications can be instantiated. Assume that the previous step created three route specifications named GoldRouteSpec (see Figure 5 above), SilverRouteSpec, and BronzeRouteSpec, with the obvious semantics. Three actions are then created: Action 1: (instance of MPLSCreateLSPAction) Name: CreateGoldLSP mpCreateLSP: <reference to GoldRouteSpec> Action 2: (instance of MPLSCreateLSPAction) Name: CreateSilverLSP mpCreateLSP: <reference to SilverRouteSpec> Action 3: (instance of MPLSCreateLSPAction) Name: CreateBronzeLSP mpCreateLSP: <reference to BronzeRouteSpec> These three actions each reference an instance of an MPLSRouteSpec object, whose creation was discussed above. Chadha Expires January 2001 49 Policy Information Model for MPLS Traffic Engineering July 2000 The result of implementing the policy rule containing these three actions (note that this policy rule would contain no conditions, only Actions 1, 2, 3 described earlier) is to create three instances of MPLSLSP, namely GoldLSP, SilverLSP, and BronzeLSP (say). Each created instance of MPLSLSP will be associated with the hops in its path and with the appropriate resource profile. Note that the hops in each LSP's path could contain new hops that were not specified in the corresponding route specification, if the latter was an incomplete specification of the route to be followed by the LSP. Each instance of MPLSLSP will also be associated with the instance of MPLSRouteSpec that it implements, via the MPLSRealizes association. The figure below shows the MPLSLSP GoldLSP created from the route specification GoldRouteSpec. Here we assume that the LSP has four hops, which include the three hops specified as belonging to the route specification GoldRouteSpec and one additional new hop, GoldHop4. Instances SilverLSP and BronzeLSP have similar associations. Chadha Expires January 2001 50 Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ ------------------> GoldResourceProfile | | | (instance of | | | MPLSResourceProfile) | | +-----------^-----------+ | GoldRouteResourceProfile | | (instance of | | MPLSRouteResourceProfile) | | | | +-----------v---------v--------+ | | GoldRouteSpec (instance of <--------------- | | MPLSRouteSpec | | | +^---------------^---------^---+ | | | | | | | GoldHop1InRoute|GoldHop2InRoute| | GoldHop3InRoute | | (instance of | (instance of | | (instance of | | MPLSHopInRoute)|MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | | | | | | | | | +----------------v+ +-----------v-----+ +v----------------+ | | | GoldHop1 | | GoldHop2 | | GoldHop3 | | | | (instance of | | (instance of | | (instance of | | | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| | | +-----------------+ +-----------------+ +-----------------+ | | | | | | | GoldHop1InLSP | GoldHop2InLSP | | GoldHop3InLSP | | (instance of | (instance of | | (instance of | | MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute)| | | | | | | | | | | | | | | | | +-v----------------v---------v-+ | ------------------> GoldLSP (instance of <--------------- GoldLSPProfile | MPLSLSP | GoldLSPSpec (instance of +--------------^---------------+ (instance of MPLSRouteResourceProfile) | MPLSRealizes) | | | GoldHop4InLSP | (instance of | MPLSHopInRoute) +-----------v--------+ | GoldHop4 | | (instance of | | ProtocolEndpoint) | +--------------------+ Figure 6. Gold LSP and its associations 5.1.2 Policies for traffic trunks Chadha Expires January 2001 51 Policy Information Model for MPLS Traffic Engineering July 2000 Once LSPs have been created for each class of service, the next requirement is to create policies that activate traffic trunks that will be transported on these LSPs (this step could have been performed before the previous one too). The policy rules that are to be created for site 1 are: Policy Rule 1: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3) then (traffic is assigned to GoldTrunk) Policy Rule 2: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=2) then (traffic is assigned to SilverTrunk) Policy Rule 3: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=1) then (traffic is assigned to BronzeTrunk) The conditions in each of the above three rules can be represented using conditions with variables and values, as described in the Policy Framework QoS Information Model (see [6]). The actions are described using instances of the MPLSActivateTTAction object class, as described in Section 5.1.2.2. To represent the creation of these three traffic trunks, we define three policy rules, each with three conditions and one action: - Each condition is defined to represent the conditions described above using the mechanisms discussed in QPIM [6]. - Each action corresponds to the activation of one traffic trunk and is an instance of MPLSActivateTTAction. - Each action refers to a traffic trunk (instance of MPLSTrafficTrunk). - Each traffic trunk is associated with a traffic profile (instance of qosPolicyPRTrfcProf, association MPLSTrafficProfile). Thus before defining the three policy rules, we need to define the corresponding three traffic trunks and the associated traffic profiles and associations that will be referenced by the three actions of these rules. 5.1.2.1 Creation of traffic trunks We depict below the objects and associations that are created to represent the traffic trunk for the Gold traffic class. Silver and Chadha Expires January 2001 52 Policy Information Model for MPLS Traffic Engineering July 2000 bronze traffic trunks and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a traffic trunk GoldTrunk with traffic profile GoldTrafficProfile. An instance of association MPLSTrafficProfile (which associates GoldTrunk and GoldTrafficProfile) is created. +-----------------------+ | GoldTrunk | | (instance of | | MPLSTrafficTrunk) | +-----------^-----------+ GoldTrunkTrafficProfile | (instance of | MPLSTrafficProfile)| | +-----------v---------v-------------+ | GoldTrafficProfile (instance of | | qosPolicyPRTrfcProf | +-^-----------------^--------^------+ Figure 7. Gold traffic trunk and its traffic profile 5.1.2.2 Activation of traffic trunks Once traffic trunks for the gold, silver, and bronze traffic have been defined, the actions to activate these three traffic trunks can be defined. Assume that the previous step created three traffic trunks named GoldTrunk (see Figure 7 above), SilverTrunk, and BronzeTrunk, with the obvious semantics. Three actions are then created: Action 4: (instance of MPLSActivateTTAction) Name: CreateGoldTrunk mpTrafficTrunk: <reference to GoldTrunk> Action 5: (instance of MPLSActivateTTAction) Name: CreateSilverTrunk mpTrafficTrunk: <reference to SilverTrunk> Action 6: (instance of MPLSActivateTTAction) Name: CreateBronzeLSP mpTrafficTrunk: <reference to BronzeTrunk> These three actions each reference an instance of an MPLSTrafficTrunk object, whose creation was discussed above and depicted in Figure 7 (for the GoldTrunk object). The three policy rules described at the beginning of Section 5.1.2 each contain one of the above actions (i.e. Policy Rule 1 contains Action 4, Policy Rule 2 contains Action 5, and Policy Rule 3 Chadha Expires January 2001 53 Policy Information Model for MPLS Traffic Engineering July 2000 contains Action 6). Policy Rules 1, 2, and 3 also contain the conditions described earlier. The result of implementing these three policy rules is to activate the three traffic trunks described above. 5.1.3 Assignment of LSPs to traffic trunks The next requirement is to create policies that assign LSPs to the previously activated traffic trunks. The policy rules that are to be created for site 1 are: Policy Rule 4: Send traffic for GoldTrunk over GoldLSP Policy Rule 5: Send traffic for SilverTrunk over SilverLSP Policy Rule 6: Send traffic for BronzeTrunk over BronzeLSP Note that the above policy rules contain no conditions, only actions. The actions are described using instances of the MPLSAssignLSPAction object class. Action 7: Name: AssignGoldLSP mpTrafficTrunk: <reference to GoldTrunk> mpAssignedLSP: GoldLSP Action 8: Name: AssignSilverLSP mpTrafficTrunk: <reference to SilverTrunk> mpAssignedLSP: SilverLSP Action 9: Name: AssignBronzeLSP mpTrafficTrunk: <reference to BronzeTrunk> mpAssignedLSP: BronzeLSP The effect of executing these rules is to assign the appropriate LSPs to the desired traffic trunks. 5.2 Creating traffic trunks In this example, we demonstrate the use of policies for activating traffic trunks and related information. A policy is defined that describes the traffic that will belong to this traffic trunk. Associated with the traffic trunk is a traffic profile that describes the resource requirements for this trunk. Also associated with the traffic trunk are one or more route specifications that Chadha Expires January 2001 54 Policy Information Model for MPLS Traffic Engineering July 2000 specify possible ways of routing this traffic trunk through the network. Each such route specification has its hops and its resource requirements specified. The idea is that a traffic engineering module will use these specifications, along with information about the current nodes and links in the network, to perform computations that will yield a decision about which of the above specified route specifications should be used to create LSPs. In other words, not all route specifications will necessarily be used to create LSPs. The number of LSPs actually created to carry a traffic trunk will depend on the network resiliency requirements. Thus backup LSPs could be created in situations where high survivability and high performance is required, whereas backup LSPs may not be created for best-effort traffic. However, in cases of congestion/failures, existing route specifications can be used to create new LSPs to alleviate/remedy the problem. Route specification attributes are used to indicate routing preferences to aid the traffic engineering module in deciding which route specifications should be used to create LSPs. Note that another scenario could be that no route specifications are provided by the policy and the traffic engineering module computes suitable LSPs based on traffic trunk attributes alone. Initially, we assume that the following information is known to the management system: - All the LSRs in the network (instances of ComputerSystem (defined in CIM model [10])) - All the MPLS interfaces on these LSRs (instances of ProtocolEndpoint (defined in CIM model [10])) - All the links between MPLS interfaces on LSRs (instances of MPLSActiveConnection). The network administrator then defines policies for traffic trunks. For example, the following is an example of such a policy: If source address = 192.8.0.0/16 AND destination address = 128.5.0.0/16 AND ToS=3 then Assign this traffic to Traffic Trunk TT1 AND Police TT1 according to its traffic profile and drop all out-of-profile packets. All relevant attributes of TT1 must be specified. Related information such as a traffic profile TP1 for this traffic trunk must also be specified, including all relevant attributes of TP1, so that TP1 can be used for policing the traffic trunk. This is achieved by instantiating an instance of MPLSTrafficTrunk (named TT1), an instance of qosPolicyPRTrfcProf (named TP1), and an instance of association MPLSTrafficProfile relating TT1 to TP1. Further, TT1 could have a number of MPLSRouteSpec instances associated with it using the MPLSEligibleRouteSpec association. Chadha Expires January 2001 55 Policy Information Model for MPLS Traffic Engineering July 2000 These route specifications basically describe possible paths for routing the trunk TT1 through the network. The route specifications can have associations to ProtocolEndpoint instances (association MPLSHopInRoute) that represent LSR interfaces that are hops for the route; the route specifications could also have associations to AutonomousSystem instances (association MPLSASInRoute) that are hops for the route. Thus each route can be loosely or strictly specified. Each MPLSRouteSpec has an MPLSResourceProfile instance associated with it via the MPLSRouteResourceProfile association. The MPLSResourceProfile instance contains information about the resources for this route specification, i.e. the average and maximum traffic rates and burst sizes. The above policy rule is represented using instances of PolicyRule (from [5]), qosPolicySimpleCondition (to represent the "if" portion of the rule), MPLSActivateTTAction (to represent the action of activating this traffic trunk), and qosPolicyPRAction (to represent the policing actions described above. The latter object class (qosPolicyPRAction ) allows the network operator to specify the action to take for non-conforming traffic (e.g. shape, drop, or re- mark). In this case, the action to be taken is to drop all non- conforming traffic. For details about the usage of qosPolicyPRAction, see QPIM [6]. The rule is structured as follows: - PolicyRule represents the policy rule described above and contains three conditions (three instances of qosPolicySimpleCondition) and two actions (instances of MPLSActivateTTAction and qosPolicyPRAction). - The instances of qosPolicySimpleCondition represent the classifier described above, i.e. source address = 192.8.0.0/16 AND destination address = 128.5.0.0/16 AND ToS=3. These conditions are represented using instances of qosPolicyVariable, qosPolicyIPv4AddrValue, and qosPolicyIntegerValue. - The instance of MPLSActivateTTAction contains a reference to TT1, which is associated with TP1 using association MPLSTrafficProfile, as described above. - The instance of qosPolicyPRAction (see [6] for details) contains a reference to TP1 and specifies that non-conforming traffic should be dropped (property qpOutOfProfileAction is set to 1 for DISCARD) - TT1 is associated with one or more MPLSRouteSpecs via the MPLSEligibleRouteSpec association. - Each instance of MPLSRouteSpec may be associated with an instance of MPLSResourceProfile (via the MPLSRouteResourceProfile association) and with hops that could be ProtocolEndpoints or AutonomousSystems (via the MPLSHopInRoute and the MPLSASInRoute associations, respectively). The above rule is processed by the traffic engineering module as described at the beginning of this section. Chadha Expires January 2001 56 Policy Information Model for MPLS Traffic Engineering July 2000 5.3 Load balancing In order to perform load balancing, a traffic stream between two nodes must be assigned to two or more LSPs at the ingress node. Policies can be designed to decide how traffic gets partitioned across LSPs. Assume that a traffic stream is to be load-balanced across two existing LSPs. Possible approaches include: - Define two parallel traffic trunks between the two nodes and assign a different LSP to each traffic trunk. The proportion of the traffic stream to be carried by each traffic trunk is specified by the mpTrafficProportion property of the MPLSTrafficTrunk object class. Thus one could specify that 80% of the traffic is to be carried across the first LSP and 20% across the second. This is the approach referred to in Section 5.6.5 of RFC 2702. - Define one traffic trunk and assign the two LSPs to carry its traffic. This will result in the traffic being shared equally by the two LSPs. From the information modeling perspective, the first option can be implemented by activating two instances of MPLSTrafficTrunk with the value of the property mpTrafficProportion set to 80 for the first trunk and to 20 for the second (using policy action MPLSActivateTTAction as described earlier); and subsequently assigning an LSP to each of these traffic trunks using the MPLSAssignLSPAction as described in the previous example. The second option can be implemented by creating one instance of MPLSTrafficTrunk (using policy action MPLSActivateTTAction); and subsequently assigning two LSPs to this traffic trunk using two instances of the MPLSAssignLSPAction. 5.4 Implementing Service Level Agreements (SLAs) Suppose a service provider has an SLA with a customer that guarantees premium quality of service for that customer during business hours (8:00am to 5:00pm) and best-effort service during non-business hours. Let's say that the service provider wishes to implement this SLA by assigning the customer's traffic during business hours to a certain LSP L1 that carries premium traffic; and by assigning the customer's traffic during non-business hours to another LSP L2 that carries best-effort traffic. Policy rules that model this requirement can be specified as follows: Policy Rule 1: Define and activate traffic trunk for this customer's traffic. qosPolicySimpleConditions: <Define the FECs for this customer's traffic as described earlier> Chadha Expires January 2001 57 Policy Information Model for MPLS Traffic Engineering July 2000 MPLSActivateTTAction: <references an MPLSTrafficTrunk TT1 and related objects characterizing the traffic for this trunk> Policy Rule 2: Assign premium LSP L1 for business hours Condition: The time is between 8:00am - 5:00pm Action: Assign LSP L1 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. Policy Rule 3: Assign best-effort LSP L2 for non-business hours Condition: The time is between 5:00pm - 8:00am Action: Assign LSP L2 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. 6. Security Considerations The security issues inherent in a policy-based management system are those of ensuring that only authorized users are allowed to manipulate policies, since these policies exert a large degree of control over the MPLS network. Such issues must be addressed by the implementation of the policy management system. 7. Conclusions This document provides a draft information model for policy-enabled MPLS network engineering. The authors of this draft would like to propose incorporation of this material into working group drafts in the mpls and/or policy working groups. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chadha Expires January 2001 58 Policy Information Model for MPLS Traffic Engineering July 2000 3 Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 4 Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 5 Moore, B., Ellesson, E. , Strassner, J., "Policy Core Information Model -- Version 1 Specification", Internet Draft draft-ietf- policy-core-info-model-06.txt, May 2000. 6 Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., "Policy Framework QoS Information Model", Internet Draft draft-ietf- policy-qos-info-model-01.txt. 7 Mahon, H., Bernet, Y., Herzog, S., "Requirements for a Policy Management System", Internet Draft draft-ietf-policy-req-01.txt, October 1999. 8 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-te-mib-03.txt, March 2000. 9 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Label Switch Router Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-lsr-mib-04.txt, April 2000. 10 Distributed Management Task Force, Inc., "Common Information Model (CIM) Schema, version 2.3, March 2000. The components of the CIM v2.3 schema are available via links on the following DMTF web page: http://www.dmtf.org/spec/cims.html 11 Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft draft-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 12 Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., Vaananen, P., Wu, L., "Constraint-Based LSP Setup using LDP", Internet Draft draft-ietf-mpls-cr-ldp-04.txt, July 2000. 13 Wright, S., Herzog, S., Reichmeyer, F., Jaeger, R., "Requirements for Policy Enabled MPLS", Internet Draft draft-wright-policy- mpls-00.txt, March 2000. 14 Wright, S., Reichmeyer, F., Jaeger, R., Gibson, M., "Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", Internet Draft draft-wright-mpls-te-policy-00.txt, June 2000. Chadha Expires January 2001 59 Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments Many thanks are due to Tony Bogovic, Ravi Vaidyanathan, and George Mykoniatis for their insights and careful reviews of this material. 10. Author's Addresses Ritu Chadha Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-4869 Email: chadha@research.telcordia.com Huai-An (Paul) Lin Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-2412 Email: hlin1@telcordia.com Chadha Expires January 2001 60 Policy Information Model for MPLS Traffic Engineering July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chadha Expires January 2001 61