idnits 2.17.1 draft-chadha-policy-mpls-te-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 23) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1959 has weird spacing: '... of the netwo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2000) is 8531 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MPLSFW' is mentioned on line 144, but not defined == Missing Reference: 'MPLS-DS' is mentioned on line 201, but not defined == Missing Reference: 'QPIM' is mentioned on line 936, but not defined == Missing Reference: 'LDP' is mentioned on line 364, but not defined == Missing Reference: 'CR-LDP' is mentioned on line 364, but not defined == Missing Reference: 'MPLS-ENC' is mentioned on line 523, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PCIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'PQIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRLDP' -- No information found for draft-mpls-rsvp-lsp-tunnel - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVP-TE' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-05 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 -- Possible downref: Normative reference to a draft: ref. 'MPLS-FW' == Outdated reference: A later version (-04) exists of draft-wright-policy-mpls-00 -- Possible downref: Normative reference to a draft: ref. 'REQPMPLS' == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-03 ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Downref: Normative reference to an Informational RFC: RFC 2430 Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT K. Isoyama 3 draft-chadha-policy-mpls-te-01.txt M. Brunner 4 Expires June 2001 M. Yoshida 5 J. Quittek 6 NEC Corporation 7 R. Chadha 8 G. Mykoniatis 9 A. Poylisher 10 R. Vaidyanathan 11 Telcordia Technologies 12 A. Kind 13 IBM 14 F. Reichmeyer 15 PfN, Inc. 17 December 2000 19 Policy Framework MPLS Information Model for QoS and TE 20 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 The purpose of this draft is to describe an information model for 46 representing MPLS policies, including MPLS for traffic engineering 47 and QoS. RFC 2702, "Requirements for Traffic Engineering over MPLS", 48 is used as a basis for determining the types of information that 49 need to be represented in the traffic engineering part of the 50 information model. The latter document describes the functional 51 capabilities required to implement policies that facilitate 52 efficient and reliable network operations in an MPLS domain. 53 For the QoS-related part, the Policy Framework QoS Information Model 54 (QPIM) is extended with new classes for controlling and managing the 55 lifecycle of Label Switched Paths (LSPs) and for mapping of traffic 56 onto existing LSPs. The control and management of LSP lifecycles 57 includes mainly the creation, update, and deletion of LSPs and the 58 assignment of QoS properties to LSPs. 60 This information model may be used by a management system to 61 optimize network performance through the necessary network 62 provisioning actions. 64 An overview of policy-based management is given in this document, 65 along with a description of the relationship of this work to other 66 information models that are being defined in the IETF Policy 67 Framework working group. A detailed description of the information 68 model and a number of examples illustrating its use follow this. 70 A UML diagram of this model is available at 71 http://www.ccrle.nec.de/ietf/MPLS_policy_info_model_01.pdf 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in RFC-2119. 79 Table of Contents 81 1. Introduction.....................................................3 82 1.1. Goals..........................................................3 83 1.2. Terminology....................................................4 84 2. Motivation for Policy-based Management of MPLS...................5 85 3. Background.......................................................7 86 3.1. MPLS concepts and their relation to this model.................7 87 3.2. Relationship to previous work..................................9 88 4. Overview of MPLS Policy Information Model.......................11 89 4.1. Overview of object classes and their associations.............11 90 4.2. High-level description of information model...................15 91 4.3. MPLS Policy Variables.........................................19 92 5. Class Definitions...............................................19 93 5.1. Class mplsPolicyTTAction......................................19 94 5.2. Class mplsPolicy_TT_LSPAction.................................20 95 5.3. Class mplsPolicyLSPAction.....................................21 96 5.4. Class mplsPolicyCRLSPResvAction...............................22 97 5.5. Class mplsPolicyCRLDPSignalCtrlAction.........................24 98 5.6. Class mplsPolicyLSP...........................................26 99 5.7. Class mplsPolicyFEC...........................................29 100 5.8. Class mplsPolicyCRLSPTrfcProf.................................30 101 5.9. Class mplsPolicyTrafficTrunk..................................31 102 5.10.Class mplsPolicyRouteSpec.....................................35 103 5.11.Class mplsPolicyProtocolEndpoint..............................36 104 5.12.Class mplsPolicyResources.....................................36 105 5.13.Association mplsPolicySystemResources.........................38 106 5.14.Association mplsPolicyEndpointResources.......................38 107 5.15.Association mplsPolicyActiveConnection........................39 108 5.16.Association mplsPolicyHopInRoute..............................41 109 5.17.Association mplsPolicyEligibleRouteSpec.......................42 110 5.18.Association mplsPolicyReverseDirTT............................43 111 5.19.Association mplsPolicyRealizes................................44 112 5.20.Association mplsPolicyCurrentlyAssignedLSP....................44 113 5.21.Association mplsPolicyBackupLSP...............................45 114 5.22.Association mplsPolicyLSPinLSP................................46 115 5.23.Association mplsPolicyTT_TrafficProfile.......................47 116 5.24.Association mplsPolicyLSP_TrafficProfile......................47 117 5.25.Association mplsPolicyFECofTrunk..............................48 118 5.26.Association mplsPolicyFECofLSP................................49 119 5.27.Association mplsPolicyFECFilterSet............................49 120 6. Examples........................................................50 121 6.1. Establishing an LSP...........................................50 122 6.2. Network wide bandwidth adjustment example.....................52 123 7. Security Considerations.........................................54 124 8. Open Issues.....................................................54 125 9. References......................................................55 126 10. Authors' Addresses.............................................56 128 1. Introduction 130 1.1. Goals 132 The ultimate goal of policy-based networking is to support the trend 133 away from individual device management, toward managing and 134 controlling a network as a whole [PCIM]. Policy-based networking 135 allows network elements from different vendors, equipped with 136 different capabilities, to be consistently configured according to 137 network policies. For instance, network policies may be aligned with 138 the business goals of a company. 140 MPLS is a combination of switched forwarding with network layer 141 routing. The added value of MPLS is provided by a better 142 price/performance ratio of network layer routing, improved 143 scalability in the network layer, and greater flexibility in the 144 delivery of routing services [MPLSFW]. These advantages are achieved 145 with label switching: a packet belongs to a Forwarding Equivalence 146 Class (FEC). All packets belonging to the same class will get 147 assigned a MPLS label, when it enters the MPLS network. The label in 148 the packet can then be used at subsequent hops between ingress and 149 egress nodes to determine the forwarding treatment by indexing into 150 a table. All packets belonging to a particular FEC and enter the 151 network at the same ingress travel the same path through the 152 network. 154 Typically, information about bindings of labels to FECs is 155 distributed by a label distribution protocol (e.g. LDP, CR-LDP, BGP, 156 RSVP-TE). The use of policies in the context of MPLS is motivated by 157 the need to provide high-level support for the operation of MPLS 158 networks beyond a standard way of label distribution with LDP or 159 other label distribution protocols. 161 Some of the important applications of MPLS that are foreseen today 162 are Traffic Engineering (TE), Quality of Service (QoS) support and 163 MPLS based Virtual Private Networks (VPNs). 165 According to [RFC2702], Traffic Engineering (TE) is concerned with 166 performance optimization of operational networks. In general, it 167 encompasses the application of technology and scientific principles 168 to the measurement, modeling, characterization, and control of 169 Internet traffic, and the application of such knowledge and 170 techniques to achieve specific performance objectives. The aspects 171 of traffic engineering that are of interest for MPLS are measurement 172 and control. A major goal of Internet traffic engineering is to 173 facilitate efficient and reliable network operations while 174 simultaneously optimizing network resource utilization and traffic 175 performance. Traffic engineering has become an indispensable 176 function in many large autonomous systems because of the high cost 177 of network assets and the commercial and competitive nature of the 178 Internet. These factors emphasize the need for maximal operational 179 efficiency. 181 The concept of MPLS traffic trunks is used extensively in the 182 remainder of this document. According to Li and Rekhter [RFC2430], a 183 traffic trunk is an aggregation of traffic flows of the same class, 184 which are placed inside a Label Switched Path. Essentially, a 185 traffic trunk is an abstract representation of traffic to which 186 specific characteristics can be associated. It is useful to view 187 traffic trunks as objects that can be routed; that is, the path 188 through which a traffic trunk traverses can be changed. In this 189 respect, traffic trunks are similar to virtual circuits in ATM and 190 Frame Relay networks. It is important, however, to emphasize that 191 there is a fundamental distinction between a traffic trunk and the 192 path, and indeed the LSP, through which it traverses. An LSP is a 193 specification of the label switched path through which the traffic 194 traverses. 196 For QoS support in IP networks, MPLS provides route pinning in order 197 to guarantee certain services to customers. Therefore, high-level 198 means for mapping traffic that matches a specific traffic filter 199 onto an LSP with specific QoS characteristics is needed. Such high- 200 level policies could be used, for instance, with DiffServ over MPLS 201 (MPLSDS) [MPLS-DS]. 203 1.2. Terminology 205 The following abbreviations are used in this document: 207 AS Autonomous System 208 ATM Asynchronous Transfer Mode 209 CIM Common Information Model 210 CLI Command Line Interface 211 COPS Common Open Policy Service 212 DMTF Distributed Management Task Force 213 FEC Forwarding Equivalence Class 214 LDAP Lightweight Directory Access Protocol 215 LSP Label Switched Path 216 LSR Label Switched Router 217 MAM Maximum Allocation Multiplier 218 MIB Management Information Base 219 MPLS Multi-Protocol Label Switching 220 PCIM Policy Core Information Model 221 PDP Policy Decision Point 222 QoS Quality of Service 223 QPIM QoS Policy Information Model 224 SLA Service Level Agreement 225 SNMP Simple Network Management Protocol 226 TE Traffic Engineering 227 WG Work Group 229 2. Motivation for Policy-based Management of MPLS 231 The following is a discussion of the advantages of the policy-based 232 management approach for MPLS, which is the approach used in this 233 draft, in comparison to the traditional Internet management 234 approach. 236 Policy-based management provides the ability to control the network 237 as a whole instead of controlling each individual managed object 238 (network device, interface, queue, LSP) in an independent way. This 239 is also one of the most important advantages of this approach, 240 compared to the traditional network management paradigm, especially 241 in the context of network configuration and provisioning. The reason 242 for this is that traditional managed objects (typically organized by 243 MIB trees) are device-level data models, populated in each router, 244 while the policy information model can be used to represent network- 245 wide entities (e.g. MPLS traffic trunks,) and can be populated in a 246 logically centralized repository. However, note that policy-based 247 management is still possible in a SNMP/MIB based environment. There 248 are various approaches to do so. The policies addressed in this 249 draft are meant to be high-level. The low-level mechanisms for 250 configuration can be implemented with different management 251 protocols. 253 The object-oriented policy information model defined in this draft 254 enables policy-based management of MPLS networks. The advantages of 255 policy-based management can be realized while performing management 256 tasks, such as MPLS configuration for traffic engineering. In the 257 traditional case, the traffic engineering MIB defined in [MPLS-MIB] 258 provides control of LSP tunnel lifecycles. Consequently, every time 259 the LSP tunnel network design needs to be changed to support new or 260 modified network services, or to react to network events, the MIBs 261 of all the appropriate LSRs have to be modified accordingly. 262 However, in the policy information model defined in this draft, the 263 administrator can describe changes to the network in terms of policy 264 constructs, thus avoiding the micro-management of the individual 265 LSRs. Also in this case, the policy-based management system may 266 automatically change the network behavior with whatever mechanism 267 available. 269 The policy-based management approach provides a new level of 270 abstraction that allows network devices from different vendors, 271 supporting different capabilities, to be consistently configured 272 according to high-level network policies. 274 The selection of the specific policy rules to be applied to each 275 network entity is carried out according to their "role". This 276 concept, introduced in [PCIM], permits the grouping of the network 277 entities according to the role they play in the network. 279 One very useful concept in this draft is the MPLS traffic trunk 280 [RFC2702]. A traffic trunk represents an aggregation of traffic 281 flows of the same class, placed inside one or more Label Switched 282 Paths. Traffic trunks provide a powerful tool for the administrator 283 or for the automatic traffic engineering module. They can be used to 284 support efficient administration of the way in which traffic is 285 handled by the network. 287 Another important point is the support of DiffServ, which is already 288 being modeled in a similar fashion [QPIM] and enhanced in order to 289 support DiffServ over MPLS. Using the policy-based management 290 approach will obviously simplify the interaction in the context of 291 configuration and provisioning. 293 The following example demonstrates some of the points discussed 294 above. A more detailed description of this example can be found in 295 section 6. We are considering a network-wide policy that varies 296 bandwidth allocations based on time of day and type of traffic. 297 Traffic Trunks (TTs) in the network are assigned "roles" in 298 accordance with the Olympic Services Model, i.e. they are marked as 299 "gold", "silver", or "bronze" according to the QoS properties of the 300 traffic that they carry. A network-wide policy controls the 301 bandwidth allocation associated with these traffic trunks. 303 Specifically, the bandwidth for all gold TTs is reduced by 50% 304 during nights and weekends, which allows traffic in the bronze TTs 305 to be increased during the same time period. This could be 306 potentially useful if the Service Level Agreements are such that a 307 number of customers require gold service during business hours on 308 weekdays, while they subscribe to lower service levels during non- 309 business hours and weekends. 311 To implement the network-wide policy described above, the following 312 two policy rules are required for the gold TTs: 314 Policy Rule 1: role is "gold TT" 315 IF "time is 8am-5pm AND day is Monday to Friday" 316 THEN "Modify TT: increase bandwidth by 100%" 318 Policy Rule 2: role is "gold TT" 319 IF "(time is 5pm-8am AND day is Monday to Friday) OR 320 (day is Saturday to Sunday)" 321 THEN "Modify TT: Decrease bandwidth by 50%" 323 The semantics of the first rule is that when the condition becomes 324 true, it increases the bandwidth of all the gold TTs by 100%. In a 325 similar fashion, the semantics of the second rule is that when the 326 condition becomes true, it decreases the bandwidth of all the gold 327 TTs by 50%. Note that this is the same absolute amount. 329 The role of the two policy rules is set to "gold TT", which 330 indicates which TTs those rules are to be applied to. In this case, 331 these two rules are applied to all the TTs that are characterized as 332 "gold_TT". 334 The above brief example shows how policies can be applied to MPLS 335 traffic engineering in a network-wide fashion. The above example is 336 explained in detail with reference to our MPLS policy information 337 model in Section 6. 339 3. Background 341 The model described in this document is based on the Policy 342 Framework QoS Information Model (QPIM)[QPIM]. QPIM defines classes 343 for representing QoS policy rules, including QoS policy rule 344 conditions and QoS policy rule actions. The classes specified in 345 QPIM address QoS provisioning using Differentiated Services 346 (DiffServ) as well as QoS control via RSVP for Integrated Services 347 (IntServ). QPIM itself refines the Policy Core Information Model 348 (PCIM) [PCIM] which includes generic classes for policy-based 349 networking. 351 3.1. MPLS concepts and their relation to this model 353 A general discussion of issues related to MPLS is presented in the 354 framework [MPLS-FW] and architecture [MPLS-ARCH] documents. A brief 355 summary of salient features is provided below as context for the 356 later sections. 358 3.1.1. 359 Label Switched Paths 361 MPLS uses the concept of a Label Switched Path (LSP), which is used 362 to carry traffic through the network. An LSP is set up using a 363 signaling protocol and may or may not be associated with QoS 364 guarantees. Currently under discussion are [LDP], [CR-LDP], and 365 [RSVP-TE], where the latter two support setting up LSPs with QoS 366 guarantees. LSPs can be specified in an explicit or implicit manner. 367 Explicitly routed LSPs specify the path that the LSP should take. 368 Depending on whether the entire sequence of hops is specified or 369 not, the explicit LSP is said to be strictly or loosely routed. 370 Implicitly routed LSPs require a routing mechanism within the 371 network, which decides the path they take. 373 The LSP is thus a basic object that must be modeled in an MPLS 374 information model. The properties of the LSP depend on what kind of 375 LSPs are taken into account (explicit vs. implicit, with or without 376 QoS etc.). For example, for explicitly routed LSPs, the explicit 377 route for the LSP must also be modeled. Note, however, that the MPLS 378 labels, which carry local significance, are not part of the 379 information modeled about an LSP. 381 3.1.2. 382 QoS Properties 384 MPLS in its original fashion has no notion of QoS. However, using 385 MPLS for appropriate traffic engineering enables an ISP to provide a 386 relatively higher quality service to its customers. This improvement 387 in quality is not quantifiable, but is based on the premise that 388 improved network utilization results in improved service quality. 390 Further, an LSP may be associated with QoS properties, which need to 391 be enforced by QoS mechanisms in LSRs via other, non-MPLS means. In 392 a recent proposal to support DiffServ over MPLS [DS-MPLS] MPLS is 393 used in conjunction with DiffServ for QoS enforcement. This approach 394 allows a Label Switched Router (LSR) to apply a specified Per-Hop 395 Behavior (PHB) to packets of an LSP. In this draft, QoS 396 specification of LSPs and its signaling is covered, but QoS 397 enforcement is not addressed (see [QPIM] instead). 399 3.1.3. 400 QoS routing for LSPs 402 The LSP setup process may be constrained by QoS requirements, to 403 achieve a requisite level of service. Such constraint-based routing 404 can be realized in one of two ways. In the first approach, a 405 centralized application, that has knowledge of network-wide QoS 406 state, could calculate the best route through the network for each 407 LSP. The centralized application can then initiate the setup of the 408 LSP, using the explicit route feature of CR-LDP or RSVP-TE to 409 control the path taken by the LSP. In the second approach, the route 410 can be calculated in a distributed fashion, during the signaling 411 process. The MPLS model of this document is transparent to the 412 different QoS routing issues; it only addresses the specification of 413 traffic trunks and LSPs with QoS requirements. The mapping of these 414 requirements to underlying QoS routing mechanisms is out of the 415 scope of this document. 417 3.1.4. 418 Signaling LSPs 420 Setting up a new LSP requires signaling or configuration mechanisms. 421 Two basic mechanisms exist for creating LSPs: (1) using a hop-by-hop 422 signaling protocol like LDP, CR-LDP, or RSVP-TE, or (2) configuring 423 the LSP using SNMP or COPS. 425 The mechanisms used for LSP setup are transparent to this draft. 426 However, certain CR-LDP-specific mechanisms have been included in 427 this draft (see open issues at the end of this draft). For RSVP 428 traffic profiles, see [QPIM]. The action to be taken from a policy 429 server's point of view is to initiate the setup process with means 430 available in the domain. 432 3.1.5. 433 Controlling the Signaling Process 435 The signaling process for setting up a new LSP may be subject to 436 different policies or resource constraints. Therefore, we introduce 437 the mplsPolicyCRLDPSignallingAction as a means to control this 438 process with policies. In some network operation environments this 439 will not be needed, if the policy control is applied before the 440 signaling process in the domain. In others, it is very convenient 441 for the policy-based management system to define policies for the 442 signaling process. 444 3.1.6. 445 Forwarding Equivalence Classes (FEC) 447 A Forwarding Equivalence Class (FEC) specifies what traffic is 448 mapped to a specific traffic trunk and/or LSP. The specification of 449 FECs can range from very simple, e.g., just the destination IP 450 address, to very complex, e.g., a set of filters including IP 451 addresses, ports, DSCPs etc. In our model, we associate an FEC with 452 an LSP and/or a traffic trunk. The binding of FECs to LSPs and 453 traffic trunks may be performed during or after the LSP/TT setup. 455 3.2. Relationship to previous work 457 3.2.1. 458 Relationship to PCIM 460 The object-oriented information model described in PCIM provides 461 generic classes for representing policy information. The model 462 allows one to specify network policies in terms of policy rules. A 463 policy rule contains a list of policy conditions and a list of 464 policy actions. Conditions are Boolean expressions that evaluate to 465 either true or false. Actions represent some concrete steps that 466 should be taken by a management system if the conditions in the rule 467 evaluate to true. 469 The policy framework described in PCIM provides an elaborate 470 mechanism for prioritizing policy rules; specifying time periods 471 during which policy rules are applicable; specifying complex boolean 472 conditions using either disjunctive normal form or conjunctive 473 normal form and negations; grouping policies together; specifying 474 reusable conditions and actions; etc. Policies are specified using a 475 declarative rather than a procedural approach, i.e. policies 476 describe the conditions and actions that make up a rule, but do not 477 give a step-by-step description of how to implement the policy. 479 The MPLS information model described in this draft refines the 480 notion of policy actions as described in PCIM. New classes are 481 introduced in order to model the following MPLS-related policy 482 actions: 484 - Generic reservation of a Label Switched Path (LSP) 485 - Generic setup of Traffic Trunk (TT) 486 - Reservation of a Label Switched Path (LSP) using CR-LDP 487 - Policy decisions for a CR-LDP message 488 - Mapping of traffic into a Label Switched Path (LSP). 490 Furthermore, new policy classes are defined that inherit from the 491 Policy class in PCIM. The new classes describe: 493 - Traffic profiles 494 - Label Switched Paths (LSPs) 495 - Traffic Trunks 496 - Forwarding Equivalence Classes (FECs) 497 - Route Specifications. 499 3.2.2. 500 Relationship to QPIM 502 In the QoS Policy Information Model (QPIM) [QPIM], new object 503 classes are defined to model the management and configuration of 504 Diffserv- and RSVP-capable network elements. Apart from QoS-specific 505 information, the model contains a number of concepts that are rather 506 general and can be re-used in a number of different contexts. One 507 such concept is that of variables and constants with well-defined 508 semantics that represent things like IP addresses, port numbers, 509 protocol numbers, etc. These variables are used to describe traffic 510 classifiers in QPIM. Such a representation is also very useful for 511 the information model described in this draft, as there is a need to 512 define the FECs (Forwarding Equivalence Classes) that map to given 513 traffic trunks and LSPs. Other concepts that are re-used from QPIM 514 are those defining traffic profiles and policing actions (see object 515 classes qosPolicyPRTrfcProf and qosPolicyPRAction in [QPIM]). These 516 are used here for describing the traffic profiles of traffic trunks, 517 and the policing requirements for traffic trunks (including what to 518 do with non-conforming traffic for a given traffic trunk). 520 QPIM lists a set of pre-defined variables that are typically 521 required for layers 2 and 3. This draft extends the list of 522 predefined variables to access the label entries on the label stack 523 of an MPLS packet [MPLS-ENC]. 525 3.2.3. 526 Relationship to MPLS Policy Information Model Requirements 528 Earlier Internet drafts ([REQPMPLS], [REQMPLS_TE]) discussed 529 policies for MPLS and MPLS-TE. [REQPMPLS] outlines requirements for 530 policy-enabled MPLS and identifies two main categories of MPLS 531 policies: LSP admission policies that map traffic flows onto LSPs, 532 and LSP lifecycle policies that affect LSP creation, deletion, 533 configuration and monitoring. The information model presented in the 534 current draft addresses both these categories of policies, excluding 535 any monitoring requirements. In [REQMPLS_TE], the authors discuss 536 policies for MPLS load balancing. The information model that we 537 present is broader in scope and addresses all aspects of traffic 538 engineering, including load balancing. 540 The information model in this draft builds upon the PCIM model and 541 further refines it by adding new actions that are specific to the 542 domain of MPLS for traffic engineering and QoS support. Actions are 543 included for creating, modifying, and destroying traffic trunks and 544 LSPs, and assigning LSPs to traffic trunks. Also, new object classes 545 and associations are introduced to model MPLS traffic engineering 546 concepts referenced by these actions, such as traffic trunks, route 547 specifications, LSPs and their hops, resources and resource classes, 548 etc. No attempt is made to define new object classes for 549 representing classifier information as this is currently being 550 addressed in QPIM. 552 4. Overview of MPLS Policy Information Model 554 4.1. Overview of object classes and their associations 556 The following figures show some of the new object classes and 557 associations defined for the MPLS Traffic Engineering and QoS Policy 558 Information Model. A number of object classes from previously 559 defined information models, namely CIM [CIM], are also shown where 560 necessary to illustrate new associations relating newly defined 561 structural object classes to object classes previously defined in 562 those information models. Object classes belonging to these 563 information models are appropriately marked. A detailed description 564 of the depicted object classes is provided in Section 5 of this 565 document. 567 +---------------------------+ 568 | FilterList (CIM) | 569 +-------------^-------------+ 570 *| 571 (a)| 572 *| 573 +-------------v-------------+ 574 +----> mplsPolicyFEC <----+ 575 (b)|0..1+---------------------------+0..1|(i) 576 | | 577 | +---------------------------+ | 578 | | qosPolicyTrafficProfile | | 579 | +-^-----------------------^-+ | 580 | 0..1| 0..1| | 581 | (c)| +------+ (j)| | +------+ 582 *| *| 0..1| (d)| *| *| *| (k)| 583 +----------v------v-----v-+ | +-----v------v-------v-+ | 584 | <----+ | <----+ 585 | |0..1 | |* 586 | mplsPolicyTrafficTrunk <---------> mplsPolicyLSP | 587 | |* (m) *| | 588 | <---------> | 589 +--------------------^----+* (n) *+--^-------------------+ 590 *| *| 591 (e)| (l)| 592 *| *| 593 +----v-----------------v----+ 594 | mplsPolicyRouteSpec | 595 +----------------------^----+ 596 *| 597 (f)| +------+ 598 *| *| (h)| 599 +-------------------------+ +------v-----------------v-+ | 600 | ComputerSystem(CIM) | |mplsPolicyProtocolEndpoint<----+ 601 +--------------------^----+ +------^-------------------+* 602 *| *| 603 (o)| (g)| 604 0..1| 0..1| 605 +----v-----------------v----+ 606 | mplsPolicyResources | 607 +---------------------------+ 609 Figure 1. Relationships between traffic trunks, LSPs, routes, 610 FECs, traffic profiles hops, resources, etc. 612 In Figure 1, boxes represent object classes and arrows represent 613 associations between the classes. The following associations appear 614 in Figure 1 above: 616 (a) mplsPolicyFECFilterSet 617 (b) mplsPolicyFECofTrunk 618 (c) mplsPolicyTT_TrafficProfile 619 (d) mplsPolicyReverseDirTT 620 (e) mplsPolicyEligibleRouteSpec 621 (f) mplsPolicyHopInRoute 622 (g) mplsPolicyEndpointResources 623 (h) mplsPolicyActiveConnection 624 (i) mplsPolicyFECofLSP 625 (j) mplsPolicyLSPTrafficProfile 626 (k) mplsPolicyLSPinLSP 627 (l) mplsPolicyRealizes 628 (m) mplsPolicyCurrentlyAssignedLSP 629 (n) mplsPolicyBackupLSP 630 (o) mplsPolicySystemResources 632 An association represents a relationship between two classes (e.g. 633 associations (a) to (o) excepting (d), (h) and (k) above in Figure 634 1), or between a class and itself (e.g. associations (d), (h) and 635 (k) in Figure 1). Cardinalities are part of each association; the 636 cardinality of an association indicates how many instances of each 637 class may be related to an instance of the other class. For 638 example, the mplsPolicyBackupLSP association has the cardinality "*" 639 (i.e. "0..n") for both the mplsPolicyTrafficTrunk and the 640 mplsPolicyLSP classes. These ranges are interpreted as follows: 642 - The "*" written next to mplsPolicyTrafficTrunk indicates that an 643 mplsPolicyLSP may be related to no mplsPolicyTrafficTrunk, to one 644 mplsPolicyTrafficTrunk, or to more than one mplsPolicyTrafficTrunk 645 via the mplsPolicyBackupLSP association. In other words, an LSP 646 may be a backup LSP for zero or more traffic trunks. 647 - The "*" written next to mplsPolicyLSP indicates that a 648 mplsPolicyTrafficTrunk may be related to no mplsPolicyLSP, to one 649 mplsPolicyLSP, or to more than one mplsPolicyLSP via the 650 mplsPolicyBackupLSP association. In other words, a traffic trunk 651 may have zero or more backup LSPs. 653 The inheritance tree for the object classes defined in this document 654 is given below. Apart from the new object classes defined in this 655 document, the tree below contains references to object classes 656 defined in the Policy Core Information Model [PCIM], marked "PCIM" 657 below, and to object classes defined in the Common Information Model 658 [CIM], marked "CIM" below. For detailed descriptions of these object 659 classes, see the relevant documents. 661 +--Policy (abstract) (PCIM) 662 | | 663 | +---PolicyAction (PCIM) 664 | | | 665 | | +---mplsPolicyTTAction 666 | | | 667 | | +---mplsPolicyLSPAction 668 | | | | 669 | | | +---mplsPolicyCRLSPResvAction 670 | | | 671 | | +---mplsPolicyTT_LSP_Action 672 | | | 673 | | +---mplsPolicySignalCtrlAction 674 | | 675 | +---qosPolicyTrfcProf (PQIM) 676 | | | 677 | | +--- mplsPolicyCRLSPTrfcProf 678 | | 679 | +---mplsPolicyFEC 680 | 681 +--CIM_ManagedSystemElement (abstract) (CIM) 682 | 683 +--CIM_LogicalElement (abstract) (CIM) 684 | 685 +--mplsPolicyResources 686 | 687 +--mplsPolicyTrafficTrunk 688 | 689 +--mplsPolicyLSP 690 | 691 +--mplsPolicyRouteSpec 692 | 693 +--CIM_ServiceAccessPoint (abstract) (CIM) 694 | 695 +--CIM_ProtocolEndpoint (abstract) (CIM) 696 | 697 +--mplsPolicyProtocolEndpoint 699 Figure 2. Inheritance Hierarchy for MPLS Policy object classes 701 In CIM, associations are also modeled as classes. For the MPLS 702 Traffic Engineering Policy Information Model, the inheritance 703 hierarchy is shown below: 705 [unrooted] 706 | 707 +---mplsPolicyHopInRoute 708 | 709 +---mplsPolicySystemResources 710 | 711 +---mplsPolicyEndpointResources 712 | 713 +---ActiveConnection (CIM) 714 | | 715 | +---mplsPolicyActiveConnection 716 | 717 +---mplsPolicyReverseDirTT 718 | 719 +---mplsPolicyEligibleRouteSpec 720 | 721 +---mplsPolicyCurrentlyAssignedLSP 722 | 723 +---mplsPolicyBackupLSP 724 | 725 +---mplsPolicyRealizes 726 | 727 +---mplsPolicyLSPinLSP 728 | 729 +---mplsPolicyTT_TrafficProfile 730 | 731 +---mplsPolicyLSPTrafficProfile 732 | 733 +---mplsPolicyFECofTrunk 734 | 735 +---mplsPolicyFECofLSP 737 Figure 3. Inheritance Hierarchy for associations 739 4.2. High-level description of information model 741 Policies in the MPLS domain mainly center on 742 - lifecycle management of LSPs, including signaling, resource 743 control, admission control etc., 744 - management of traffic trunks, including the specification of the 745 traffic traversing the trunks, and 746 - the mapping of traffic trunks to LSPs, including mapping of 747 DiffServ traffic and tunneling of MPLS traffic over parallel LSPs 748 for the purpose of traffic engineering. 750 4.2.1. 751 MPLS Signaling Actions 753 Signaling in MPLS consists of setting up, releasing and updating an 754 LSP along a number of LSRs. It should be possible to control the 755 initiation and the execution of these processes using policies. For 756 some signaling protocols, e.g. the Label Distribution Protocol 757 (LDP), the signaling is initiated by an LSR itself, without any 758 intervention by the Policy Server. The signaling actions in the 759 draft are applicable to constraint based LSP setup using protocols 760 such as CR-LDP and RSVP-TE, and include policy actions to initiate 761 the setup, update, or release of an LSP (mplsPolicyLSPAction), as 762 well as a policy action controlling the LSP setup process 763 (mplsPolicyCRLDPSignalCtrlAction). 765 4.2.2. 766 MPLS Traffic Engineering Policy Actions 768 A number of policy actions are defined for the purpose of enabling a 769 management system to manipulate traffic trunks and LSPs. These 770 actions may reference instances of traffic trunks, LSPs, and route 771 specifications (see definition of route specification in a later 772 section). In order to reference such instances, they must first be 773 created and populated; and any related objects and associations must 774 also be instantiated and populated. 776 For example, mplsPolicyTTAction operates upon a traffic trunk; the 777 property mpTrafficTrunk in this action references an instance of a 778 traffic trunk that is to be operated upon. Thus before instantiating 779 an instance of mplsPolicyTTAction, one must instantiate an instance 780 of mplsPolicyTrafficTrunk that will be referenced by this action. In 781 addition, all the related object instances and associations must 782 also be instantiated before instantiating this action. RFC 2702 783 [RFC2702] describes the difference between establishing a traffic 784 trunk (which we model by creating an instance of 785 mplsPolicyTrafficTrunk and related classes as described later) and 786 activating a traffic trunk (which is modeled by the 787 mplsPolicyTTAction). 789 Referencing traffic trunks 791 The following objects may need to be instantiated in order to fully 792 describe a traffic trunk referenced by an action: 794 - Route specifications: Zero or more route specifications 795 (mplsPolicyRouteSpec) can be associated with a traffic trunk to 796 indicate that this is a potential route to which this traffic trunk 797 can be mapped. The association is modeled by the 798 mplsPolicyEligibleRouteSpec. 800 - Traffic profile: A traffic profile (qosPolicyPRTrfcProf) 801 describing the resource requirements of a traffic trunk can be 802 defined for every traffic trunk and associated with the traffic 803 trunk via the mplsPolicyTT_TrafficProfile association. 805 - Assigned LSPs: Any LSPs (mplsPolicyLSP) currently assigned to a 806 traffic trunk can be defined and associated with it via the 807 mplsPolicyCurrentlyAssignedLSP association. 809 - Backup LSPs: Any LSPs (mplsPolicyLSP) that are acting as backup 810 LSPs for a traffic trunk can be defined and associated with it via 811 the mplsPolicyBackupLSP association. 813 - Reverse traffic trunk: If a traffic trunk carrying traffic in the 814 reverse direction exists, it can be associated with a given traffic 815 trunk via mplsPolicyReverseDirTT. 817 Referencing LSPs 819 The following objects may need to be instantiated in order to fully 820 describe an LSP referenced by an action: 822 - Route specifications: Zero or more route specifications 823 (mplsPolicyRouteSpec) can be associated with an LSP to indicate that 824 this LSP is a realization of the route specification. The 825 association is modeled by the mplsPolicyRealizes. 827 - Traffic trunks: Any traffic trunks (mplsPolicyTrafficTrunk) whose 828 traffic is currently being carried by an LSP should be defined and 829 associated with this LSP via the mplsPolicyCurrentlyAssignedLSP 830 association. Further, any traffic trunks for which an LSP is a 831 backup LSP should be associated with this LSP via the 832 mplsPolicyBackupLSP association. 834 - LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be 835 associated with any LSPs contained in or containing it via the 836 mplsPolicyLSPinLSP association. 838 Referencing route specifications 840 The following objects may need to be instantiated in order to fully 841 describe a route specification referenced by an action: 843 - LSPs: Zero or more LSPs (mplsPolicyLSP) can be associated with a 844 route specification to indicate that these LSPs are realizations of 845 the route specification. The association is modeled by the 846 mplsPolicyRealizes. 848 - Traffic trunks: Traffic trunks (mplsPolicyTrafficTrunk) for which 849 a given route specification is a potential route should be 850 associated with the route specification via the 851 mplsPolicyEligibleRouteSpec association. 853 - Route hops: Every hop specified for a route specification is 854 represented by an instance of mplsPolicyProtocolEndpoint (derived 855 from ProtocolEndpoint in [CIM]) and is associated with a route 856 specification via the mplsPolicyHopInRoute association. 858 Traffic trunks, LSPs, and supporting object classes and associations 860 The following object classes and associations are defined. Many of 861 these are referenced by the actions described in the previous 862 section. 864 - Traffic trunk (object class mplsPolicyTrafficTrunk): For a 865 description of a traffic trunk, see the Introduction section of this 866 document, or see RFC 2702 [RFC2702] for more details. The attributes 867 of a traffic trunk are described by the properties of this object 868 class. A traffic trunk can be associated with LSPs that are 869 currently carrying its traffic (mplsPolicyCurrentlyAssignedLSP 870 association) and with backup LSPs that are used for backup in 871 fault/congestion scenarios (mplsPolicyBackupLSP association). 872 Eligible routes for this traffic trunk are associated with it via 873 the mplsPolicyEligibleRouteSpec association. If a traffic trunk 874 going in the reverse direction exists, it is associated with this 875 traffic trunk via the mplsPolicyReverseDirTT association. Finally, a 876 traffic profile for this traffic trunk can be represented by the 877 qosPolicyPRTrfcProf object class (reused from QPIM) and associated 878 with the traffic trunk via the mplsPolicyTrafficProfile association. 880 - Route Specification (object class mplsPolicyRouteSpec): This is an 881 object class that represents a route specification from point A to 882 point B. The route specification may or may not be realized in the 883 network by an LSP. A route specification is associated with all the 884 hops contained in this route. These hops are interfaces on LSRs 885 (represented by instances of ProtocolEndpoint, which is an object 886 class defined in the CIM Network Model [CIM]). The associations with 887 these hops are realized via the mplsPolicyHopInRoute associations. 888 Note that a route specification could be an incomplete specification 889 of a route; e.g. it could specify three hops for a route which 890 actually requires at least four hops, and leave the job of choosing 891 the missing hop to a signaling protocol that sets up the 892 corresponding LSP. An LSP can be created based on a route 893 specification using the mplsPolicyLSPAction. 895 The typical use of this object class is for a network operator to be 896 able to specify potential MPLS routes in advance and later 897 instantiate them by creating LSPs that use this specification. A 898 route specification can be associated with a traffic trunk to 899 indicate that this is a potential route to which this traffic trunk 900 can be mapped (mplsPolicyEligibleRouteSpec association). 902 - Label-Switched Path (LSP) (object class mplsPolicyLSP): This 903 object class represents an LSP. An LSP can be associated with a 904 route specification in order to indicate that this LSP implements 905 this route specification (mplsPolicyRealizes association). An LSP 906 can also be associated with a traffic trunk if it is currently 907 carrying the traffic for this traffic trunk (via the 908 mplsPolicyCurrentlyAssignedLSP association) or if it is a backup LSP 909 for this traffic trunk (via the mplsPolicyBackupLSP association). An 910 LSP can also be associated with another LSP to indicate a hierarchy 911 of LSPs (mplsPolicyLSPinLSP association). 913 - Resources (object class mplsPolicyResources): This object class 914 represents resources associated with LSRs and interfaces on these 915 LSRs, such as buffer resources, etc. (mplsPolicySystemResources and 916 mplsPolicyEndpointResources associations, respectively). 918 - Links and their resources (association 919 mplsPolicyActiveConnection): The resources associated with a link 920 (e.g. bandwidth, etc.) are represented by properties of the 921 association mplsPolicyActiveConnection. This association is used to 922 relate two instances of ProtocolEndpoint that currently have an 923 active connection between them. 925 Apart from these newly defined object classes and associations, the 926 qosPolicyPRAction object class is reused from QPIM for representing 927 policing actions including actions to be taken for non-conforming 928 traffic. Also, object classes qosPolicySimpleCondition, 929 qosPolicyVariable, and qosPolicyValue and their derived classes from 930 QPIM are used for representing classifier information. 932 4.3. MPLS Policy Variables 934 The QoS policy information model specifies a set of pre-defined 935 variables to support a set of fundamental QoS terms that are commonly 936 used in policy conditions [QPIM]. In order to specify meaningful 937 policy rules in the MPLS domain, we extend the set of pre-defined 938 variables with MPLS-specific variables. Here we define a preliminary 939 set of low-level concepts; these may need to be extended in updates 940 to this draft. 942 The following table defines the pre-defined variables for MPLS and 943 their logical bindings. 945 +----------------+--------------------------------------------------+ 946 | Variable name | Logical binding | 947 +----------------+--------------------------------------------------+ 948 | MPLSLabel | The MPLS label of the flow. Compared to the MPLS | 949 | | label in the MPLS shim header field or the | 950 | | combined VPI/VCI in ATM. | 951 +----------------+--------------------------------------------------+ 952 | MPLSExp | The MPLS Exp field of the flow. Compared to the | 953 | | MPLS Experimental field in the MPLS shim header. | 954 +----------------+--------------------------------------------------+ 955 Table 1: Pre-defined Variable Names and their Bindings 957 Both variables can be of class type qosPolicyIntegerValue or 958 qosPolicyBitStringValue. 960 5. Class Definitions 962 5.1. Class mplsPolicyTTAction 964 This class represents a policy action that creates, destroys or 965 modifies an instance of a traffic trunk by assigning it to a traffic 966 flow (referred to as "activation" of a traffic trunk in [RFC2702]). 967 Note that a traffic trunk MUST first be established or defined by 968 creating an instance of mplsPolicyTrafficTrunk and related 969 objects/associations (see Section below for details). RFC 2702 970 describes the difference between establishing a traffic trunk (which 971 we model by creating an instance of mplsPolicyTrafficTrunk and 972 related classes as described in Section below) and activating a 973 traffic trunk (which is modeled by the mplsPolicyTTAction). 975 The class definition is as follows: 977 NAME mplsPolicyTTAction 978 DESCRIPTION A class used to describe a policy action that 979 activates, destroys or modifies a traffic trunk. 980 DERIVED FROM policyAction (defined in [PCIM]) 981 ABSTRACT False 982 PROPERTIES mpTrafficTrunk, 983 mpTTMode 985 5.1.1. 986 The property mpTrafficTrunk 988 This property is a reference to the instance of 989 mplsPolicyTrafficTrunk that is to be created, destroyed or modified. 990 The property definition is as follows: 992 NAME mpTrafficTrunk 993 DESCRIPTION Traffic trunk being created, destroyed or modified 994 SYNTAX Reference to an mplsPolicyTrafficTrunk 996 5.1.2. 997 The Property mpTTMode 999 The mpTTMode property specifies whether the action is a creation, 1000 destruction, modification of a Traffic Trunk action, or a 1001 modification of a traffic profile action (see 5.2.) 1003 NAME mpTTMode 1004 DESCRIPTION Mode of the action 1005 SYNTAX Integer (ENUM) - { 1006 "TTCreate"=0; 1007 "TTModify"=1; 1008 "TTDestroy"=2; 1009 } 1011 5.2. Class mplsPolicy_TT_LSPAction 1013 This class is used to represent the action of assigning or de- 1014 assigning an LSP to a traffic trunk. Note that the traffic trunk and 1015 LSP are assumed to have been defined by creating instances of 1016 mplsPolicyTrafficTrunk and mplsPolicyLSP, respectively, as well as 1017 related objects/associations (see Sections X.2.1.1 and X.2.1.2 for 1018 details). 1020 NAME mplsPolicy_TT_LSPAction 1021 DESCRIPTION A class that represents an action that 1022 assigns or deassigns an LSP to a traffic trunk. 1023 DERIVED FROM PolicyAction 1024 ABSTRACT False 1025 PROPERTIES mpTrafficTrunk, 1026 mpAssignedLSP, 1027 mpTT_LSPMode 1029 5.2.1. 1030 The property mpTrafficTrunk 1032 This property contains a reference to an instance of 1033 mplsPolicyTrafficTrunk. Note that the instance of 1034 mplsPolicyTrafficTrunk that is referenced can be re-used as it can be 1035 referenced by multiple policy actions. 1037 The property definition is as follows: 1039 NAME mpTrafficTrunk 1040 DESCRIPTION Traffic trunk to which an LSP is being 1041 assigned 1042 SYNTAX Reference to an mplsPolicyTrafficTrunk 1044 5.2.2. 1045 The property mpAssignedLSP 1047 This property is a reference to an instance of mplsPolicyLSP. The 1048 semantics here are that the traffic trunk referenced within this 1049 action is to be sent over the referenced LSP. 1051 The property definition is as follows: 1053 NAME mpAssignedLSP 1054 DESCRIPTION Reference to LSP being assigned to a traffic 1055 trunk 1056 SYNTAX Reference to an instance of mplsPolicyLSP 1058 5.2.3. 1059 The Property mpTT_LSPMode 1061 The mpTT_LSPMode property specifies whether the action is an 1062 assignment or deassignment of a LSP to a Traffic Trunk. 1064 NAME mpTT_LSPMode 1065 DESCRIPTION Mode of the action 1066 SYNTAX Integer (ENUM) - { 1067 "Assign"=0; 1068 "Deassign"=1; 1069 } 1071 5.3. Class mplsPolicyLSPAction 1073 This class defines a generic LSP reservation action. The action 1074 initiates the setup, update, or release of an LSP referred to by the 1075 in the mpCreateLSP property. The class definition is as follows: 1077 NAME mplsPolicyLSPAction 1078 DESCRIPTION A class used to describe a policy action that 1079 sets up, releases, or modifies any a LSP. 1080 DERIVED FROM PolicyAction (defined in [PCIM]) 1081 ABSTRACT False 1082 PROPERTIES mpCreateLSP, 1083 mpLSPMode 1085 5.3.1. 1086 The Property mpCreateLSP 1088 This property is a reference to an mplsPolicyLSP object, which 1089 defines an LSP. The property is defined as follows: 1091 NAME mpCreateLSP 1092 DESCRIPTION LSP being set up, released, or modified 1093 SYNTAX Reference to an mplsPolicyLSP object 1095 5.3.2. 1096 The Property mpLSPMode 1098 The mpLSPMode property specifies whether the action is a setup, 1099 release, or update action of an LSP. 1101 NAME mpLSPMode 1102 DESCRIPTION Mode of the action 1103 SYNTAX Integer (ENUM) - { 1104 "LSPSetup"=0; 1105 "LSPUpdate"=1; 1106 "LSPRelease"=2; 1107 } 1109 5.4. Class mplsPolicyCRLSPResvAction 1111 This class defines an CR-LSP reservation action using CR-LDP Label 1112 Request Messages. The set priority property specifies whether an 1113 existing LSP may be preempted in order to The property is mapped to 1114 the SetPrio field of the Preemption TLV [CRLDP]. Negotiable 1115 properties specify whether the corresponding traffic parameter is 1116 negotiable or not. The properties are mapped to the flags field of 1117 the Traffic Parameter TLV of [CRLDP]. 1119 This class defines a protocol-specific action and will likely be 1120 moved to a protocol-specific information model in the future. 1122 The class definition is as follows: 1124 NAME mplsPolicyCRLSPResvAction 1125 DESCRIPTION A class used to describe a policy action that 1126 sets up, releases or modifies an LSP using CR-LDP. 1127 DERIVED FROM mplsPolicyLSPAction 1128 ABSTRACT False 1129 PROPERTIES mpCRLSPsetPrio, 1130 mpPDRNegotiable, mpPBSNegotiable, 1131 mpCDRNegotiable, mpCBSNegotiable, 1132 mpEBSNegotiable, mpWeightNegotiable 1134 5.4.1. 1135 The Property mpCRLSPSetPrio 1137 This property represents the setting priority of the CR-LSP. The 1138 property is defined as follows: 1140 NAME mpCRLSPSetPrio 1141 DESCRIPTION setting priority of the CR-LSP 1142 SYNTAX Integer (MUST be in the range 0-255) 1144 5.4.2. 1145 The Property mpPDRNegotiable 1147 This property indicates whether the Peak Data Rate of the CR-LSP is 1148 negotiatble or not. The property is defined as follows: 1150 NAME mpPDRNegotiable 1151 DESCRIPTION Flag that indicates whether PDR is negotiable or not 1152 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1154 5.4.3. 1155 The Property mpPBSNegotiable 1157 This property indicates whether the Peak Burst Size of the CR-LSP is 1158 negotiable or not. The property is defined as follows: 1160 NAME mpPBSNegotiable 1161 DESCRIPTION Flag that indicates whether PBS is negotiable or not 1162 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1164 5.4.4. 1165 The Property mpCDRNegotiable 1167 This property indicates whether the Committed Data Rate of the CR-LSP 1168 is negotiable or not. The property is defined as follows: 1170 NAME mpCDRNegotiable 1171 DESCRIPTION Flag that indicates whether CDR is negotiable or not 1172 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1174 5.4.5. 1175 The Property mpCBSNegotiable 1177 This property indicates whether the Committed Burst Size of the CR- 1178 LSP is negotiable or not. The property is defined as follows: 1180 NAME mpCBSNegotiable 1181 DESCRIPTION Flag that indicates whether CBS is negotiable or not 1182 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1184 5.4.6. 1185 The Property mpEBSNegotiable 1187 This property indicates whether the Excess Burst Size of the CR-LSP 1188 is negotiable or not. The property is defined as follows: 1189 NAME mpEBSNegotiable 1190 DESCRIPTION Flag that indicates whether EBS is negotiable or not 1191 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1193 5.4.7. 1194 The Property mpWeightNegotiable 1196 This property indicates whether the Weight of the CR-LSP is 1197 negotiable or not. The property is defined as follows: 1199 NAME mpWeightNegotiable 1200 DESCRIPTION Flag that indicates whether Weight is negotiable or 1201 not 1202 SYNTAX Boolean - {"NotNegotiable"=0; "Negotiable"=1} 1204 5.5. Class mplsPolicyCRLDPSignalCtrlAction 1206 This class defines a policy action to be applied to CR-LDP messages. 1207 The message type property identifies the concerned messages. The 1208 mpSendNotification property specifies whether a notification should 1209 be sent. If the notification message is sent, the mpErrCode property 1210 identifies the error code to be sent. Furthermore, the replace 1211 properties specify whether the traffic profile of the CR-LDP message 1212 is changed. 1214 This class defines a protocol-specific action and will likely be 1215 moved to a protocol-specific information model in the future. 1217 NAME mplsPolicyCRLDPSignalCtrlAction 1218 DESCRIPTION A class used to describe a policy action that 1219 is applied to CR-LDP messages. 1220 DERIVED FROM PolicyAction (defined in [PCIM]) 1221 ABSTRACT False 1222 PROPERTIES mpCRLDPMessageType, mpSendNotification, 1223 mpSendRelease, mpErrCode 1224 mpReplacePDR, mpReplacePBS, 1225 mpReplaceCDR, mpReplaceCBS, 1226 mpReplaceEBS, mpReplaceWeight 1228 5.5.1. 1229 The Property CRLDPMessageType 1231 This property is an enumerated integer and defines different values 1232 that limit the scope of the action to be enforced to specific types 1233 of CR-LDP Messages. The property is defined as follows: 1235 NAME CRLDPMessageType 1236 DESCRIPTION A message type to which the action is enforced 1237 SYNTAX Integer (ENUM) - { 1238 "LabelMapping"=0; 1239 "LabelRequest"=1; 1240 "LabelWithdraw"=2; 1241 "LabelRelease"=3; 1242 "LabelAbortRequest"=4; 1243 "Notification"=5; 1244 } 1246 5.5.2. 1247 The Property mpSendNotification 1249 This property controls the generation of CR-LDP Notification 1250 Messages. The property is defined as follows: 1252 NAME mpSendNotification 1253 DESCRIPTION A flag that indicates whether a Notification Message 1254 is generated or not. 1255 SYNTAX Boolean - {No=0, Yes=1} 1257 5.5.3. 1258 The Property mpSendRelease 1260 This property controls the generation of CR-LDP Release Messages. The 1261 property is defined as follows: 1263 NAME mpSendRelease 1264 DESCRIPTION A flag that indicates whether a Release Message is 1265 generated or not. 1266 SYNTAX Boolean - {No=0, Yes=1} 1268 5.5.4. 1269 The Property mpErrCode 1271 This property specifies the error code in case the mpSendNotification 1272 property has the value 1=yes. If the sent notification property is 1273 no, this property is undefined. The error codes are the ones 1274 specified in LDP and CR-LDP. 1276 NAME mpErrCode 1277 DESCRIPTION Error code of Notification Message 1278 SYNTAX Integer 1280 5.5.5. 1281 The Property mpReplacePDR 1283 This property is a non-negative integer that replaces the Peak Data 1284 Rate value in a CR-LDP message. The property is defined as follows: 1286 NAME mpReplacePDR 1287 DESCRIPTION Replaced PDR value 1288 SYNTAX Integer (MUST be non-negative) 1290 5.5.6. 1291 The Property mpReplacePBS 1293 This property is a non-negative integer that replaces the Peak Burst 1294 Size value in a CR-LDP message. The property is defined as follows: 1296 NAME mpReplacePBS 1297 DESCRIPTION Replaced PBS value 1298 SYNTAX Integer (MUST be non-negative) 1300 5.5.7. 1301 The Property mpReplaceCDR 1303 This property is a non-negative integer that replaces the Committed 1304 Data Rate value in a CR-LDP message. The property is defined as 1305 follows: 1307 NAME mpReplaceCDR 1308 DESCRIPTION Replaced CDR value 1309 SYNTAX Integer (MUST be non-negative) 1311 5.5.8. 1312 The Property mpReplaceCBS 1314 This property is a non-negative integer that replaces the Committed 1315 Burst Size value in CR-LDP message. The property is defined as 1316 follows: 1318 NAME mpReplaceCBS 1319 DESCRIPTION Replaced CBS value 1320 SYNTAX Integer (MUST be non-negative) 1322 5.5.9. 1323 The Property mpReplaceEBS 1325 This property is a non-negative integer that replaces the Excess 1326 Burst Size value in a CR-LDP message. The property is defined as 1327 follows: 1329 NAME mpReplaceEBS 1330 DESCRIPTION Replaced EBS value 1331 SYNTAX Integer (MUST be non-negative) 1333 5.5.10. The Property mpReplaceWeight 1335 This property is a non-negative integer that replaces the Weight 1336 value in a CR-LDP message. The property is defined as follows: 1338 NAME mpReplaceWeight 1339 DESCRIPTION Replaced Weight value 1340 SYNTAX Integer (MUST be in the range 0-255) 1342 5.6. Class mplsPolicyLSP 1344 This object class is used to represent an MPLS LSP and its 1345 properties. Instances of this class represent existing or to be 1346 established LSPs in the network. The class definition is as follows: 1348 NAME mplsPolicyLSP 1349 DESCRIPTION A class with several properties for 1350 describing an MPLS LSP. 1351 DERIVED FROM LogicalElement 1352 ABSTRACT False 1353 PROPERTIES mpAdminStatus, 1354 mpOperationalStatus, 1355 mpLevel, 1356 mpLocalLSPID, 1357 mpResourceClass, 1358 mpHoldingPriority, 1359 mpIngressMayReroute, 1360 mpIsPersistent, 1361 mpIsPinned, 1362 mpLocalProtectionAvailable, 1363 mpIsAdaptive, 1364 Roles 1366 5.6.1. 1367 The property mpAdminStatus 1369 This property indicates the desired operational status of this LSP. 1371 The property definition is as follows: 1373 NAME mpAdminStatus 1374 DESCRIPTION Administrative status of an LSP. 1375 SYNTAX Integer (ENUM) - { 1376 "up"=1; 1377 "down"=2; 1378 "testing"=3; 1379 } 1381 5.6.2. 1382 The property mpOperationalStatus 1384 This property indicates the actual operational status of this LSP, 1385 which is typically (but is not limited to) a function of the state of 1386 individual segments of this LSP. 1388 The property definition is as follows: 1390 NAME mpOperationalStatus 1391 DESCRIPTION Operational status of an LSP. 1392 SYNTAX Integer (ENUM) - { 1393 "up"=1; 1394 "down"=2; 1395 "testing"=3; 1396 "unknown"=4; 1397 "dormant"=5; 1398 "notPresent"=6; 1399 "lowerLayerDown"=7 1400 } 1402 5.6.3. 1403 The property mpLevel 1405 This property indicates the nesting level of this LSP. 1407 The property definition is as follows: 1409 NAME mpLevel 1410 DESCRIPTION LSP nesting level. 1411 SYNTAX Integer 1413 5.6.4. 1414 The Property mpLocalLSPId 1416 This property is an integer that indicates the LSP id which is unique 1417 with reference to the Ingress LSR. 1419 The property definition is as follows: 1421 NAME mpLocalLSPID 1422 SYNTAX Integer (must be in the range 0-65535) 1424 5.6.5. 1425 The Property mpResourceClass 1427 This property defines an integer to represent a resource class of the 1428 LSP. 1430 The property definition is as follows: 1432 NAME mpResourceClass 1433 SYNTAX Integer[] (must be non-negative) 1435 5.6.6. 1436 The Property mpHoldingPriority 1438 This property represents the holding priority of the LSP which is 1439 already set up. A newly set up LSP is only allowed to preempt the 1440 resources of this LSP if its set priority is higher than the hold 1441 priority. 1443 NAME mpHoldingPriority 1444 DESCRIPTION Holding priority for this LSP 1445 SYNTAX Integer (must be in the range 0-255) 1447 5.6.7. 1448 The property mpIngressMayReroute 1450 This flag indicates that the LSP ingress node may choose to reroute 1451 this MPLS route without tearing it down. 1453 The property definition is as follows: 1455 NAME mpIngressMayReroute 1456 DESCRIPTION Fast reroute enabled 1457 SYNTAX boolean 1459 5.6.8. 1460 The property mpIsPersistent 1462 This flag indicates whether this LSP should be restored automatically 1463 after a failure occurs. 1465 The property definition is as follows: 1467 NAME mpIsPersistent 1468 DESCRIPTION Indicates whether this MPLS route is 1469 not 1470 SYNTAX boolean 1472 5.6.9. 1473 The property mpIsPinned 1475 This flag indicates whether the loosely-routed hops of this MPLS 1476 route are to be pinned (see [RSVP-TE][CRLDP]). 1478 The property definition is as follows: 1480 NAME mpIsPinned 1481 DESCRIPTION Indicates whether the route is pinned 1482 SYNTAX boolean 1484 5.6.10. The property mpLocalProtectionAvailable 1486 This flag permits transit routers to use a local repair mechanism 1487 which may result in violation of the explicit routing of this LSP. 1488 When a fault is detected on an adjacent downstream link or node, a 1489 transit router can reroute traffic for fast service restoration. 1491 The property definition is as follows: 1493 NAME mpLocalProtectionAvailable 1494 DESCRIPTION Indicates whether local protection is 1495 SYNTAX boolean 1497 5.6.11. The property mpIsAdaptive 1499 An LSP might need to re-route itself (e.g. due to re-optimization, 1500 connectivity problems, increase in bandwidth, etc.). If an LSP is 1501 configured to be adaptive, it 1502 (a) maintains existing resources until a new path is set up 1503 (b) avoids double-counting for links shared by the old and new 1504 paths. 1506 The property definition is as follows: 1508 NAME mpIsAdaptive 1509 DESCRIPTION A boolean indicating whether an MPLS route is 1510 adaptive or not. 1511 SYNTAX boolean 1512 DEFAULT VALUE true 1514 5.6.12. The property Roles 1516 The Roles property specifies the set of roles this LSP may have. This 1517 property is defined in the CIM Core Information model [CIM] and 1518 therefore its definition is not repeated here. See PCIM for an 1519 explanation of how roles are used. (See also open issues at the end 1520 of the draft) 1522 5.7. Class mplsPolicyFEC 1523 The mplsPolicyFEC specifies the Forwarding Equivalence Class of an 1524 LSP. The FECs may differ depending on the application of MPLS. The 1525 association mplsFECFilterSet association associates a FilterList 1526 [CIM] with this class. 1528 NAME mplsPolicyFEC 1529 DESCRIPTION A Forwarding Equivalence Class of a Traffic Trunk or 1530 an LSP 1531 DERIVED FROM Policy (defined in [PCIM]) 1532 ABSTRACT FALSE 1533 PROPERTIES 1535 5.8. Class mplsPolicyCRLSPTrfcProf 1537 This class represents CR-LSP traffic parameters as specified in 1538 [CRLDP]. The value of CR-LSP traffic profiles corresponds to the 1539 Traffic Parameter TLV carried in CR-LDP messages. The traffic profile 1540 is derived from the qosPolicyPRTrfcProf, where the property 1541 qpPRExcessBurst is used for the CR-LDP ExcessBurstSize, the qpPRRate 1542 replaces CR-LDP PeakDataRate, and qpNormalBurst refers to CR-LDP 1543 PeakBurstSize 1545 This class represents protocol-specific parameters and will likely be 1546 moved to a protocol-specific information model in the future. 1548 NAME mplsPolicyCRLSPTrfcProf 1549 DESCRIPTION Traffic profile of CR-LSP 1550 DERIVED FROM qosPolicyPRTrfcProf (defined in [PQIM]) 1551 ABSTRACT False 1552 PROPERTIES mpCRLSPFrequency, 1553 mpCRLSPWeight, 1554 mpCRLSPCommittedDataRate, 1555 mpCRLSPCommittedBurstSize 1557 5.8.1. 1558 The Property mpCRLSPFrequency 1560 This property specifies at what granularity the CDR allocated to the 1561 CR-LSP is made available. 1563 NAME mpCRLSPFrequency 1564 DESCRIPTION Granularity of CDR 1565 SYNTAX Integer (ENUM){ 1566 "Unspecified"=0; 1567 "Frequent"=1; 1568 "VeryFrequent"=2 1569 } 1571 5.8.2. 1572 The Property mpCRLSPWeight 1574 This property represents the CR-LSP's relative share of the possible 1575 excess bandwidth above its committed rate. 1577 NAME mpCRLSPWeight 1578 DESCRIPTION Relative share of the possible excess bandwidth 1579 SYNTAX Integer (MUST be in the range 0-255) 1581 5.8.3. 1582 The Property mpCRLSPCommittedDataRate 1584 This property is a non-negative integer that defines the token rate 1585 parameter of committed data rate token bucket, measured in bytes per 1586 second. The property is defined as follows: 1588 NAME mpCRLSPCommittedDataRate 1589 DESCRIPTION Committed data rate 1590 SYNTAX Integer (MUST be non-negative) 1592 5.8.4. 1593 The Property mpCRLSPCommittedBurstSize 1595 This property is a non-negative integer that defines the token bucket 1596 size parameter of committed data rate token bucket, measured in 1597 bytes. 1599 The property is defined as follows: 1601 NAME mpCRLSPCommittedBurstSize 1602 DESCRIPTION Committed burst size 1603 SYNTAX Integer (MUST be non-negative) 1605 5.9. Class mplsPolicyTrafficTrunk 1607 This object class is used to represent an MPLS traffic trunk and its 1608 properties. A traffic trunk is an aggregation of traffic flows of 1609 the same class which are placed inside an LSP (or more than one 1610 LSPs, in the case of load balancing). Essentially, a traffic trunk 1611 is an abstract representation of traffic to which specific 1612 characteristics can be associated. 1614 This class contains properties describing attributes that can be 1615 associated with traffic trunks to influence their behavioral 1616 characteristics. Several of these attributes are drawn from RFC 2702 1617 [RFC2702]. The class definition is as follows: 1619 NAME mplsPolicyTrafficTrunk 1620 DESCRIPTION A class with several properties for 1621 describing an MPLS traffic trunk. 1622 DERIVED FROM LogicalElement 1623 ABSTRACT False 1624 PROPERTIES mpResourceClassAffinity, 1625 mpPreemption, 1626 mpPriority, 1627 mpResilience, 1628 mpTrafficProportion, 1629 mpReoptimizationFreq, 1630 Roles 1632 5.9.1. 1633 The property mpResourceClassAffinity 1635 This property represents the resource class affinity attributes (see 1636 [RFC2702]) associated with a traffic trunk which can be used to 1637 specify the class of resources that are to be explicitly included or 1638 excluded from the path of the traffic trunk (the property 1639 mpResourceClass, which appears in object class mplsPolicyResources 1640 and in association mplsPolicyActiveConnection, describes the "class" 1641 that a resource belongs to). The mpResourceClassAffinity property 1642 contains 1643 a list of policy attributes which can be used to impose additional 1644 constraints on the path traversed by a given traffic trunk. The 1645 resource class affinity property for a traffic trunk contains a 1646 string of the form: 1648 1650 The "resource-class" parameter in the above identifies a resource 1651 class for which an affinity relationship is defined with respect to 1652 the traffic trunk. The "affinity" parameter above is a boolean value 1653 that indicates the affinity relationship; that is, whether members 1654 of the resource class are to be included or excluded from the path 1655 of the traffic trunk. The value "true" signifies explicit inclusion, 1656 and the value "false" specifies explicit exclusion. 1658 If no resource class affinity attributes are specified, then a 1659 "don't care" affinity relationship is assumed to hold between the 1660 traffic trunk and all resources. That is, there is no requirement to 1661 explicitly include or exclude any resources from the traffic trunk's 1662 path. This should be the default in practice. 1664 Resource class affinity attributes are very useful and powerful 1665 constructs because they can be used to implement a variety of 1666 policies. For example, they can be used to contain certain traffic 1667 trunks within specific topological regions of the network. 1669 A "constraint-based routing" framework (see [RFC2702]) can be used to 1670 compute an LSP for a traffic trunk subject to resource class 1671 affinity constraints in the following manner: 1673 1. For explicit inclusion, prune all resources not belonging 1674 to the specified classes before performing LSP computation. 1676 2. For explicit exclusion, prune all resources belonging to the 1677 specified classes before performing LSP computation. 1679 The property definition is as follows: 1681 NAME mpResourceClassAffinity 1682 DESCRIPTION String containing resource class affinities 1683 SYNTAX string 1685 5.9.2. 1686 The property mpPreemption 1688 The preemption attribute (see [RFC2702]) determines whether a traffic 1689 trunk can preempt another traffic trunk from a given path, and 1690 whether it can be preempted by another traffic trunk. Preemption can 1691 used to assure that high priority traffic trunks can always be 1692 routed through relatively favorable paths within a differentiated 1693 services environment. Preemption can also be used to implement 1694 various prioritized restoration policies following fault events. 1696 The preemption property can take one of four values, with the 1697 following semantics: 1698 1. preemptor-enabled: can preempt lower priority preemptable 1699 traffic trunks 1700 2. non-preemptor: cannot preempt other traffic trunks 1701 3. preemptable: can be preempted by higher priority preemptor- 1702 enabled traffic trunks 1703 4. non-preemptable: cannot be preempted. 1705 It is trivial to see that some of the preempt modes are mutually 1706 exclusive. Using the numbering scheme depicted above, the feasible 1707 preempt mode combinations for a given traffic trunk are as follows: 1708 (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be 1709 the default. 1711 A traffic trunk, say "A", can preempt another traffic trunk, say 1712 "B", only if *all* of the following five conditions hold: 1713 1. "A" has a relatively higher priority than "B" 1714 2. "A" contends for a resource utilized by "B" 1715 3. The resource cannot concurrently accommodate "A" and "B" 1716 based on certain decision criteria 1717 4. "A" is preemptor enabled 1718 5. "B" is preemptable. 1720 Preemption is not considered a mandatory attribute under the current 1721 best effort Internet service model, although it may be useful. 1722 However, in a differentiated services scenario, the need for 1723 preemption becomes more compelling. Moreover, in the emerging 1724 optical internetworking architectures, where some protection and 1725 restoration functions may be migrated from the optical layer to data 1726 network elements (such as gigabit and terabit label switching 1727 routers) to reduce costs, preemptive strategies can be used to 1728 reduce the restoration time for high priority traffic trunks under 1729 fault conditions. 1731 The property definition is as follows: 1733 NAME mpPreemption 1734 DESCRIPTION Contains preemptability information 1735 SYNTAX Integer (MUST be in the range 1-4) 1737 5.9.3. 1738 The property mpPriority 1740 The priority of a traffic trunk is described by this property. The 1741 priority property defines the relative importance of traffic trunks. 1742 If a constraint-based routing framework is used with MPLS, 1743 priorities can be used to determine the order in which path 1744 selection is done for traffic trunks at connection establishment and 1745 under fault scenarios. Priorities are also important in 1746 implementations permitting preemption because they can be used to 1747 impose a partial order on the set of traffic trunks according to 1748 which preemptive policies can be applied. The priority of a traffic 1749 trunk, along with its preemptability information (see the 1750 description of the mpPreemption property in the previous section), 1751 determines when it will preempt and/or be preempted by other traffic 1752 trunks. 1754 The property definition is as follows: 1756 NAME mpPriority 1757 DESCRIPTION Priority for this traffic trunk. 1758 SYNTAX Integer 1760 5.9.4. 1761 The property mpResilience 1763 The mpResilience property indicates the recovery procedure to be 1764 applied to traffic trunks whose paths are impacted by faults. More 1765 specifically, it contains a boolean value that determines whether 1766 the target traffic trunk is to be rerouted or not when segments of 1767 its path fail. 1769 Note that RFC 2702[RFC2702] discusses extended resilience attributes 1770 that could be used to specify detailed actions to be taken when 1771 faults occur. The representation of such attributes is left for 1772 further study. 1774 The property definition is as follows: 1776 NAME mpResilience 1777 DESCRIPTION If set to true, this traffic trunk should be 1778 rerouted in case of failure; if false, it 1779 should not. 1780 SYNTAX boolean 1782 5.9.5. 1783 The property mpTrafficProportion 1785 This property is used to indicate the relative proportion of traffic 1786 to be carried by parallel traffic trunks. This enables one to 1787 perform load distribution across multiple parallel traffic trunks 1788 between two nodes. In many practical situations, the aggregate 1789 traffic between two nodes may be such that no single link can carry 1790 the load. In this case, the only feasible solution is to 1791 appropriately divide the aggregate traffic into sub-streams and 1792 route the sub-streams through multiple paths between the two nodes. 1793 This problem can be addressed by instantiating multiple traffic 1794 trunks between the two nodes, such that each traffic trunk carries a 1795 proportion of the aggregate traffic. The proportion of traffic 1796 carried by each such trunk is specified by the mpTrafficProportion 1797 property. 1799 The property definition is as follows: 1801 NAME mpTrafficProportion 1802 DESCRIPTION Proportion of traffic to be carried by this 1803 traffic trunk, specified as a percentage from 1804 0 to 100. 1805 SYNTAX Integer 1807 5.9.6. 1808 The property mpReoptimizationFreq 1810 Due to changes in network and traffic characteristics, there may be 1811 a need to periodically change the paths of traffic trunks for 1812 optimization purposes. This should not be done too frequently as 1813 this could adversely affect the stability of the network. This 1814 property indicates how often such reoptimization should be 1815 performed. 1817 The property definition is as follows: 1819 NAME mpReoptimizationFreq 1820 DESCRIPTION Indicates how frequently reoptimization should 1821 be performed for this traffic trunk. If the 1822 value of this property is set to zero, this 1823 indicates that reoptimization should not be 1824 performed. 1825 SYNTAX Integer 1827 5.9.7. 1828 The property Roles 1830 The Roles property specifies the set of roles this TT may have. This 1831 property is defined in the CIM Core Information model [CIM] and 1832 therefore its definition is not repeated here. See PCIM for an 1833 explanation of how roles are used. 1835 5.10. 1836 Class mplsPolicyRouteSpec 1838 This object class is used to represent a specification of a path for 1839 routing an MPLS traffic trunk/LSP. An LSP can be created based on a 1840 route specification using the mplsPolicyLSPAction. 1842 The class definition is as follows: 1844 NAME mplsPolicyRouteSpec 1845 DESCRIPTION A class describing an MPLS route specification. 1846 DERIVED FROM LogicalElement 1847 ABSTRACT False 1848 PROPERTIES mpIngressIPAddress, 1849 MpEgressIPAddress 1851 5.10.1. The property mpIngressIPAddress 1853 Ingress IP address for this MPLS route. 1855 The property definition is as follows: 1857 NAME mpIngressIPAddress 1858 DESCRIPTION Ingress IP address for this MPLS route. 1859 SYNTAX string 1861 5.10.2. The property mpEgressIPAddress 1863 Egress IP address for this MPLS route. 1865 The property definition is as follows: 1867 NAME mpEgressIPAddress 1868 DESCRIPTION Egress IP address for this MPLS route. 1869 SYNTAX string 1871 5.11. 1872 Class mplsPolicyProtocolEndpoint 1874 This class is derived from ProtocolEndpoint [CIM] and represents a 1875 hop in the route of LSP or Traffic Trunk. A hop represents an LSR 1876 interface and this class provides a way to assign roles of an LSR 1877 interface such as "MPLS_INGRESS", "MPLS_EGRESS", "MPLS_CORE", etc. 1879 NAME mplsPolicyProtocolEndpoint 1880 DESCRIPTION A class that represents a LSR interface. 1881 DERIVED FROM ProtocolEndpoint (defined in [CIM]) 1882 ABSTRACT False 1883 PROPERTIES Roles 1885 5.11.1. The Property Roles 1887 The Roles property specifies the set of roles this 1888 mplsPolicyProtocolEndpoint may have. This property is defined in the 1889 CIM Core Information model [CIM] and therefore its definition is not 1890 repeated here. See PCIM for an explanation of how roles are used. 1892 5.12. 1893 Class mplsPolicyResources 1895 This class represents resources associated with LSRs and with 1896 interfaces on LSRs. The resources described by this class are 1897 associated with the corresponding LSRs/interfaces via the 1898 mplsPolicySystemResources and the mplsPolicyEndpointResources 1899 associations, respectively. 1901 The class definition is as follows: 1903 NAME mplsPolicyResources 1904 DESCRIPTION Resources associated with LSRs and their 1905 interfaces 1906 ABSTRACT False 1907 DERIVED FROM LogicalElement, 1908 PROPERTIES mpBufferResources, 1909 mpMaxAllocMultiplier, 1910 mpResourceClass 1912 5.12.1. The property mpBufferResources 1914 Buffer resources for an LSR or an LSR interface. 1916 The property definition is as follows: 1918 NAME mpBufferResources 1919 DESCRIPTION Buffer resources. 1920 SYNTAX Integer 1922 5.12.2. The property mpMaxAllocMultiplier 1924 The maximum allocation multiplier (MAM) (see [RFC2702]) of a 1925 resource determines the proportion of the resource that is available 1926 for allocation to traffic trunks. This attribute is applicable to 1927 buffer resources on LSRs. The value of the MAM can be chosen so that 1928 a resource can be under-allocated or over-allocated. A resource is 1929 said to be under-allocated if the aggregate demands of all traffic 1930 trunks that can be allocated to it are always less than the capacity 1931 of the resource. A resource is said to be over-allocated if the 1932 aggregate demands of all traffic trunks allocated to it can exceed 1933 the capacity of the resource. 1935 The property definition is as follows: 1937 NAME mpMaxAllocMultiplier 1938 DESCRIPTION Proportion of buffer resources that are 1939 available for allocation to traffic trunks. 1940 SYNTAX Integer 1942 5.12.3. The property mpResourceClass 1944 This property describes the "class" that a resource belongs to (see 1945 [RFC2702]). Thus a resource class can be viewed as a "color" 1946 assigned to a resource such that the set of resources with the same 1947 "color" conceptually belongs to the same class. Resource classes can 1948 be used to implement a variety of policies. From a Traffic 1949 Engineering perspective, they can be used to implement many policies 1950 with regard to both traffic and resource oriented performance 1951 optimization. For example, resource class attributes can be used to 1952 apply uniform policies to a set of resources; specify the relative 1953 preference of sets of resources for path placement of traffic 1954 trunks; explicitly restrict the placement of traffic trunks to 1955 specific subsets of resources; etc. In general, a resource can be 1956 assigned more than one resource class attribute. For example, all of 1957 the OC-48 links in a given network may be assigned a distinguished 1958 resource class attribute. The subsets of OC-48 links which exist 1959 within a given domain of the network may be assigned additional 1960 resource class attributes in order to implement specific containment 1961 policies, or to architect the network in a certain manner. 1963 The property definition is as follows: 1965 NAME mpResourceClass 1966 DESCRIPTION Resource class(es) that a resource belongs to. 1967 SYNTAX Integer[] 1969 5.13. 1970 Association mplsPolicySystemResources 1972 The association mplsPolicySystemResources associates a set of 1973 resources (object class mplsPolicyResources) with an LSR (modeled by 1974 an instance of ComputerSystem as defined in the CIM model [CIM]). 1976 The association definition is as follows: 1978 NAME mplsPolicySystemResources 1979 DESCRIPTION Associates MPLS resources with an LSR. 1980 ABSTRACT False 1981 PROPERTIES mpResources[ref MPLSResources [0..1]], 1982 mpLSR [ref ComputerSystem[0..n]] 1984 5.13.1. The reference mpResources 1986 This property contains an object reference to an mplsPolicyResources 1987 instance to which zero or one ComputerSystems (representing LSRs) 1988 can be associated. The [0..1] cardinality indicates that there may 1989 be zero or one instances of mplsPolicyResources associated with any 1990 given LSR. 1992 5.13.2. The reference mpLSR 1994 This property contains an object reference to a ComputerSystem 1995 (representing an LSR) that is associated with mplsPolicyResources. 1996 The [0..n] cardinality indicates that there may be 0, 1, or more 1997 than one LSRs associated with any given mplsPolicyResources 1998 instance. These LSRs all have the same resource specifications. 2000 5.14. 2001 Association mplsPolicyEndpointResources 2003 The association mplsPolicyEndpointResources associates a set of 2004 resources (object class mplsPolicyResources) with an interface of an 2005 LSR (modeled by an instance of mplsPolicyProtocolEndpoint). 2007 The association definition is as follows: 2009 NAME mplsPolicyEndpointResources 2010 DESCRIPTION Associates MPLS resources with an interface 2011 of an LSR. 2013 ABSTRACT False 2014 PROPERTIES mpResources[ref mplsPolicyResources [0..1]], 2015 mpPE [ref mplsPolicyProtocolEndpoint [0..n]] 2017 5.14.1. The reference mpResources 2019 This property contains an object reference to an mplsPolicyResources 2020 instance to which zero or one mplsPolicyProtocolEndpoints 2021 (representing interfaces on LSRs) can be associated. The [0..1] 2022 cardinality indicates that there may be zero or one instances of 2023 mplsPolicyResources associated with any given LSR interface. 2025 5.14.2. The reference mpPE 2027 This property contains an object reference to a 2028 mplsPolicyProtocolEndpoint (representing an LSR interface) that is 2029 associated with mplsPolicyResources. The [0..n] cardinality 2030 indicates that there may be 0, 1, or more than one LSR interfaces 2031 associated with any given mplsPolicyResources instance. These LSR 2032 interfaces all have the same resource specifications. 2034 5.15. 2035 Association mplsPolicyActiveConnection 2037 The association mplsPolicyActiveConnection associates a 2038 mplsPolicyProtocolEndpoint with another and represents a link 2039 between them. Here mplsPolicyProtocolEndpoint represents an LSR 2040 interface. 2042 The association definition is as follows: 2044 NAME mplsPolicyActiveConnection 2045 DESCRIPTION Represents a link between two LSR interfaces 2046 ABSTRACT false 2047 DERIVED FROM ActiveConnection (from [CIM]) 2048 PROPERTIES mpEndpoint1 [ref mplsPolicyProtocolEndpoint [0..n]], 2049 mpEndpoint2 [ref mplsPolicyProtocolEndpoint [0..n]], 2050 mpBandwidth, 2051 mpMaxAllocMultiplier, 2052 mpResourceClass 2054 5.15.1. The reference mpEndpoint1 2056 This property contains a reference to a mplsPolicyProtocolEndpoint 2057 instance (representing an LSR interface) to which zero or more 2058 ProtocolEndpoints (also representing LSR interfaces) can be 2059 associated, representing a connection between the 2060 mplsPolicyProtocolEndpoints. The [0..n] cardinality indicates that 2061 there may be zero or more instances of mplsPolicyProtocolEndpoint 2062 associated with any given mplsPolicyProtocolEndpoint. 2064 5.15.2. The reference mpEndpoint2 2065 This property contains a reference to a mplsPolicyProtocolEndpoint 2066 instance (representing an LSR interface) to which zero or more 2067 ProtocolEndpoints (also representing LSR interfaces) can be 2068 associated, representing a connection between the 2069 mplsPolicyProtocolEndpoints. The [0..n] cardinality indicates that 2070 there may be zero or more instances of mplsPolicyProtocolEndpoint 2071 associated with any given mplsPolicyProtocolEndpoint. 2073 5.15.3. The property mpBandwidth 2075 Bandwidth for the link represented by this connection. 2076 The property definition is as follows: 2078 NAME mpBandwidth 2079 DESCRIPTION Link bandwidth 2080 SYNTAX Integer 2082 5.15.4. The property mpMaxAllocMultiplier 2084 The maximum allocation multiplier (MAM) (see [RFC2702]) of a 2085 resource determines the proportion of the resource that is available 2086 for allocation to traffic trunks. This attribute is applicable to 2087 link bandwidth. The values of the MAM can be chosen so that a 2088 resource can be under-allocated or over-allocated. A resource is 2089 said to be under-allocated if the aggregate demands of all traffic 2090 trunks that can be allocated to it are always less than the capacity 2091 of the resource. A resource is said to be over-allocated if the 2092 aggregate demands of all traffic trunks allocated to it can exceed 2093 the capacity of the resource. 2095 The property definition is as follows: 2097 NAME mpMaxAllocMultiplier 2098 DESCRIPTION Proportion of link bandwidth that is available 2099 for allocation. 2100 SYNTAX Integer 2102 5.15.5. The property mpResourceClass 2104 This property describes the "class" that a resource belongs to. Thus 2105 a resource class can be viewed as a "color" assigned to a resource 2106 such that the set of resources with the same "color" conceptually 2107 belong to the same class. Resource classes can be used to implement 2108 a variety of policies. From a Traffic Engineering perspective, they 2109 can be used to implement many policies with regard to both traffic 2110 and resource oriented performance optimization. For example, 2111 resource class attributes can be used to apply uniform policies to a 2112 set of resources; specify the relative preference of sets of 2113 resources for path placement of traffic trunks; explicitly restrict 2114 the placement of traffic trunks to specific subsets of resources; 2115 etc. In general, a resource can be assigned more than one resource 2116 class attribute. For example, all of the OC-48 links in a given 2117 network may be assigned a distinguished resource class attribute. 2118 The subsets of OC-48 links which exist within a given domain of the 2119 network may be assigned additional resource class attributes in 2120 order to implement specific containment policies, or to architect 2121 the network in a certain manner. 2123 The property definition is as follows: 2125 NAME mpResourceClass 2126 DESCRIPTION Resource class assigned to this link. 2127 SYNTAX Integer[] 2129 5.16. 2130 Association mplsPolicyHopInRoute 2132 The association mplsPolicyHopInRoute provides a way to associate 2133 hops with mplsPolicyRouteSpec. Hops are instances of 2134 mplsPolicyProtocolEndpoint and represent LSR interfaces. 2136 The association definition is as follows: 2138 NAME mplsPolicyHopInRoute 2139 DESCRIPTION Associates hops with mplsPolicyRouteSpec 2140 ABSTRACT False 2141 PROPERTIES mpRoute[ref mplsPolicyRouteSpec[0..n]], 2142 mpHop[ref mplsPolicyProtocolEndpoint[0..n]], 2143 mpIsStrict, 2144 mpOrder 2146 5.16.1. The reference mpRoute 2148 This property contains an object reference to an mplsPolicyRouteSpec 2149 with which a number of hops can be associated. The [0..n] 2150 cardinality indicates that there may be 0, 1, or more than one 2151 mplsPolicyRouteSpec associated with any given hop, indicating that 2152 this hop is contained in all these routes. 2154 5.16.2. The reference mpHop 2156 This property contains an object reference to a 2157 mplsPolicyProtocolEndpoint (representing an LSR interface) that is a 2158 hop for an mplsPolicyRouteSpec. The [0..n] cardinality indicates 2159 that there may be 0, 1, or more than one hops associated with any 2160 given mplsPolicyRouteSpec. These are all the hops that are included 2161 in the route specification. 2163 5.16.3. The property mpIsStrict 2165 Denotes whether the referenced hop is routed in a strict or loose 2166 fashion. 2168 The property definition is as follows: 2170 NAME mpIsStrict 2171 DESCRIPTION Denotes whether the referenced hop is routed 2172 in a strict or loose fashion. 2173 SYNTAX boolean 2175 5.16.4. The property mpOrder 2177 This property indicates the hop sequence, 1..n. 2179 The property definition is as follows: 2181 NAME mpOrder 2182 DESCRIPTION Hop sequence 2183 SYNTAX Integer 2185 5.17. 2186 Association mplsPolicyEligibleRouteSpec 2188 The association mplsPolicyEligibleRouteSpec associates an MPLS 2189 traffic trunk with a route specification that is a potential route 2190 for this traffic trunk. 2192 The association definition is as follows: 2194 NAME mplsPolicyEligibleRouteSpec 2195 DESCRIPTION Associates a traffic trunk with a route 2196 specification that is a potential route for 2197 this traffic trunk. 2198 ABSTRACT false 2199 PROPERTIES mpTT [ref MplsPolicyTrafficTrunk [0..n]], 2200 mpRoute [ref MplsPolicyRouteSpec [0..n]], 2201 mpPreference, 2202 mpIsMandatory 2204 5.17.1. The reference mpTT 2206 This property contains an object reference to an 2207 mplsPolicyTrafficTrunk instance associated with an 2208 mplsPolicyRouteSpec. The [0..n] cardinality indicates that there may 2209 be zero or more instances of mplsPolicyTrafficTrunk associated with 2210 any given mplsPolicyRouteSpec; i.e. zero or more traffic trunks may 2211 share the same route specification, indicating that this route 2212 specification is an eligible route for these traffic trunks. 2214 5.17.2. The reference mpRoute 2216 This property contains an object reference to an mplsPolicyRouteSpec 2217 that is associated with an mplsPolicyTrafficTrunk. The [0..n] 2218 cardinality indicates that there may be 0, 1, or more than one 2219 mplsPolicyRouteSpecs associated with any given 2220 mplsPolicyTrafficTrunk instance; i.e. any traffic trunk can have 2221 multiple eligible route specifications. 2223 5.17.3. The property mpPreference 2225 This property represents the preference for the referenced route by 2226 the referenced traffic trunk. 2228 The property definition is as follows: 2230 NAME mpPreference 2231 DESCRIPTION Preference for the referenced route for the 2232 referenced traffic trunk. 2233 SYNTAX Integer 2235 5.17.4. The property mpIsMandatory 2237 Indicates whether this is a mandatory route for this traffic trunk 2238 or not. 2240 The property definition is as follows: 2242 NAME mpIsMandatory 2243 DESCRIPTION Indicates whether this is a mandatory route 2244 for this traffic trunk or not. 2245 SYNTAX boolean 2247 5.18. 2248 Association mplsPolicyReverseDirTT 2250 The association mplsPolicyReverseDirTT associates an MPLS traffic 2251 trunk with a traffic trunk going in the reverse direction. 2253 The association definition is as follows: 2255 NAME mplsPolicyReverseDirTT 2256 DESCRIPTION Associates a traffic trunk with another going 2257 in the reverse direction. 2258 ABSTRACT False 2259 PROPERTIES mpTT1 [ref mplsPolicyTrafficTrunk [0..1]], 2260 mpTT2 [ref mplsPolicyTrafficTrunk [0..1]] 2262 5.18.1. The reference mpTT1 2264 This property contains an object reference to an 2265 mplsPolicyTrafficTrunk instance to which zero or one 2266 mplsPolicyTrafficTrunks can be associated. An mplsPolicyReverseDirTT 2267 association between two traffic trunks represents the fact that 2268 these traffic trunks carry traffic in opposite directions. The 2269 [0..1] cardinality indicates that there may be zero or one instances 2270 of mplsPolicyTrafficTrunk associated with any given 2271 mplsPolicyTrafficTrunk. 2273 5.18.2. The reference mpTT2 2274 This property contains an object reference to an 2275 mplsPolicyTrafficTrunk instance to which zero or one 2276 mplsPolicyTrafficTrunks can be associated. An mplsPolicyReverseDirTT 2277 association between two traffic trunks represents the fact that 2278 these traffic trunks carry traffic in opposite directions. The 2279 [0..1] cardinality indicates that there may be zero or one instances 2280 of mplsPolicyTrafficTrunk associated with any given 2281 mplsPolicyTrafficTrunk. 2283 5.19. 2284 Association mplsPolicyRealizes 2286 The association mplsPolicyRealizes associates an LSP with an MPLS 2287 route specification (mplsPolicyRouteSpec). Such an association 2288 exists if the referenced LSP is an implementation of the referenced 2289 route specification. Recall that a route specification could be 2290 loosely or strictly specified; an LSP associated to a route 2291 specification via the mplsPolicyRealizes association satisfies all 2292 the constraints laid down in this route specification. 2294 The association definition is as follows: 2296 NAME mplsPolicyRealizes 2297 DESCRIPTION Associates an LSP with a route specification. 2298 ABSTRACT False 2299 PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]], 2300 mpRouteSpec [ref mplsPolicyRouteSpec [0..n]] 2302 5.19.1. The reference mpLSP 2304 This property contains an object reference to an mplsPolicyLSP 2305 instance associated with an mplsPolicyRouteSpec. The [0..n] 2306 cardinality indicates that there may be zero or more instances of 2307 mplsPolicyLSP associated with any given mplsPolicyRouteSpec; i.e. 2308 zero or more LSPs can be a realization of the same route 2309 specification. 2311 5.19.2. The reference mpRouteSpec 2313 This property contains an object reference to an mplsPolicyRouteSpec 2314 that is associated with an mplsPolicyLSP. The [0..n] cardinality 2315 indicates that there may be 0, 1, or more than one 2316 mplsPolicyRouteSpecs associated with any given mplsPolicyLSP 2317 instance; i.e. any LSP can be a realization of have zero or more 2318 route specifications. 2320 5.20. 2321 Association mplsPolicyCurrentlyAssignedLSP 2323 The association mplsPolicyCurrentlyAssignedLSP associates the LSP to 2324 which a traffic trunk is assigned with that traffic trunk. 2326 The association definition is as follows: 2328 NAME mplsPolicyCurrentlyAssignedLSP 2329 DESCRIPTION Associates a traffic trunk with the LSP 2330 assigned to it. 2331 ABSTRACT False 2332 PROPERTIES mpTT [ref MplsPolicyTrafficTrunk [0..n]], 2333 mpLSP [ref mplsPolicyLSP [0..n]] 2335 5.20.1. The reference mpTT 2337 This property contains an object reference to an 2338 mplsPolicyTrafficTrunk instance to which zero or more mplsPolicyLSPs 2339 can be associated. An mplsPolicyCurrentlyAssignedLSP association 2340 between a traffic trunk and an LSP represents the fact that this LSP 2341 is currently carrying the traffic for this traffic trunk. The [0..n] 2342 cardinality indicates that there may be zero or more instances of 2343 mplsPolicyTrafficTrunk associated with any given mplsPolicySLSP, 2344 i.e. an LSP could be carrying traffic for zero or more traffic 2345 trunks. 2347 5.20.2. The reference mpLSP 2349 This property contains an object reference to an mplsPolicyLSP 2350 instance to which zero or more mplsPolicyTrafficTrunks can be 2351 associated. An mplsPolicyCurrentlyAssignedLSP association between a 2352 traffic trunk and an LSP represents the fact that this LSP is 2353 currently carrying the traffic for this traffic trunk. The [0..n] 2354 cardinality indicates that there may be zero or more instances of 2355 mplsPolicyLSP associated with any given mplsPolicyTrafficTrunk, i.e. 2356 these LSPs are sharing the traffic load for this traffic trunk. 2358 5.21. 2359 Association mplsPolicyBackupLSP 2361 The association mplsPolicyBackupLSP associates a backup LSP with an 2362 MPLS traffic trunk. The idea is that this LSP can be used as a 2363 backup for this traffic trunk if necessary. 2365 The association definition is as follows: 2367 NAME mplsPolicyBackupLSP 2368 DESCRIPTION Associates a backup LSP with a traffic trunk. 2369 ABSTRACT False 2370 PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]], 2371 mpLSP [ref mplsPolicyLSP [0..n]], 2372 mpPreference 2374 5.21.1. The reference mpTT 2376 This property contains an object reference to an 2377 mplsPolicyTrafficTrunk instance with which zero or more 2378 mplsPolicyLSPs can be associated. An mplsPolicyBackupLSP association 2379 between a traffic trunk and an LSP represents the fact that this LSP 2380 is a backup for this traffic trunk and can be used in 2381 failure/congestion situations. The [0..n] cardinality indicates that 2382 there may be zero or more instances of mplsPolicyTrafficTrunk 2383 associated with any given mplsPolicyLSP, i.e. an LSP can be a backup 2384 for zero or more traffic trunks. 2386 5.21.2. The reference mpLSP 2388 This property contains an object reference to an mplsPolicyLSP 2389 instance with which zero or more mplsPolicyTrafficTrunks can be 2390 associated. An mplsPolicyBackupLSP association between a traffic 2391 trunk and an LSP represents the fact that that this LSP is a backup 2392 for this traffic trunk and can be used in failure/congestion 2393 situations. The [0..n] cardinality indicates that there may be zero 2394 or more instances of mplsPolicyLSP associated with any given 2395 mplsPolicyTrafficTrunk, i.e. there may be zero or more backup LSPs 2396 for this traffic trunk. 2398 5.21.3. The property mpPreference 2400 This property represents the preference for the referenced backup 2401 LSP by the referenced traffic trunk. In other words, an explicit 2402 order can be imposed on all the backup LSPs for a traffic trunk to 2403 indicate a sequence of backup LSPs ordered from most preferred to 2404 least preferred. 2406 The property definition is as follows: 2408 NAME mpPreference 2409 DESCRIPTION Preference for the referenced backup LSP for 2410 the referenced traffic trunk. 2411 SYNTAX Integer 2413 5.22. 2414 Association mplsPolicyLSPinLSP 2416 The association mplsPolicyLSPinLSP associates an LSP with another 2417 LSP and indicates a hierarchical relationship between the two LSPs. 2419 The association definition is as follows: 2421 NAME mplsPolicyLSPinLSP 2422 DESCRIPTION Associates an LSP with another LSP, indicating 2423 a hierarchical relationship between the two. 2424 ABSTRACT False 2425 PROPERTIES mpContainingLSP [ref mplsPolicyLSP [0..n]], 2426 mpContainedLSP [ref mplsPolicyLSP [0..n]] 2428 5.22.1. The reference mpContainingLSP 2430 This property contains an object reference to an mplsPolicyLSP 2431 instance associated with another mplsPolicyLSP. The [0..n] 2432 cardinality indicates that there may be zero or more instances of 2433 mplsPolicyLSP associated with other mplsPolicyLSPs via this 2434 association, indicating that these LSPs all contain the referenced 2435 LSP. 2437 5.22.2. The reference mpContainedLSP 2439 This property contains an object reference to an mplsPolicyLSP 2440 instance associated with another mplsPolicyLSP. The [0..n] 2441 cardinality indicates that there may be zero or more instances of 2442 mplsPolicyLSP associated with other mplsPolicyLSPs via this 2443 association, indicating that these LSPs are all contained in the 2444 referenced LSP. 2446 5.23. 2447 Association mplsPolicyTT_TrafficProfile 2449 The association mplsPolicyTT_TrafficProfile associates a traffic 2450 trunk with a traffic profile, represented by an instance of 2451 qosPolicyTrafficProfile. This traffic profile describes the 2452 characteristics of the traffic carried by the referenced traffic 2453 trunk. 2455 The association definition is as follows: 2457 NAME mplsPolicyTT_TrafficProfile 2458 DESCRIPTION Associates a traffic trunk with a traffic 2459 profile. 2460 ABSTRACT False 2461 PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]], 2462 mpTrfcProf[ref qosPolicyTrafficProfile [0..1]] 2464 5.23.1. The reference mpTT 2466 This property contains an object reference to an 2467 mplsPolicyTrafficTrunk instance associated with a 2468 qosPolicyTrafficProfile. The [0..n] cardinality indicates that there 2469 may be zero or more instances of mplsPolicyTrafficTrunk associated 2470 with any given qosPolicyTrafficProfile; i.e. zero or more traffic 2471 trunks can share the same traffic profile specification. 2473 5.23.2. The reference mpTrfcProf 2475 This property contains an object reference to a 2476 qosPolicyTrafficProfile that is associated with an 2477 mplsPolicyTrafficTrunk. The [0..1] cardinality indicates that there 2478 may be zero or one traffic profiles associated with any given traffic 2479 trunk. 2481 5.24. 2482 Association mplsPolicyLSP_TrafficProfile 2484 The association mplsPolicyLSP_TrafficProfile associates an LSP with 2485 a traffic profile, represented by an instance of 2486 qosPolicyTrafficProfile. This traffic profile describes the 2487 characteristics of the traffic carried by the referenced LSP. 2489 The association definition is as follows: 2491 NAME mplsPolicyLSP_TrafficProfile 2492 DESCRIPTION Associates an LSP with a traffic profile. 2493 ABSTRACT False 2494 PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]], 2495 mpTrfcProf[ref qosPolicyTrafficProfile [0..1]] 2497 5.24.1. The reference mpLSP 2499 This property contains an object reference to an mplsPolicyLSP 2500 instance associated with a qosPolicyTrafficProfile. The [0..n] 2501 cardinality indicates that there may be zero or more instances of 2502 mplsPolicyLSP associated with any given qosPolicyTrafficProfile; 2503 i.e. zero or more LSPs can share the same traffic profile 2504 specification. 2506 5.24.2. The reference mpTrfcProf 2508 This property contains an object reference to a 2509 qosPolicyTrafficProfile that is associated with an mplsPolicyLSP. The 2510 [0..1] cardinality indicates that there may be zero or one traffic 2511 profiles associated with any given LSP. 2513 5.25. 2514 Association mplsPolicyFECofTrunk 2516 The association mplsPolicyFECofTrunk associates a Traffic Trunk with 2517 an FEC, represented by an instance of qosPolicyTrafficTrunk. 2519 The association definition is as follows: 2521 NAME mplsPolicyFECofTrunk 2522 DESCRIPTION Associates a Traffic Trunk with a FEC. 2523 ABSTRACT False 2524 PROPERTIES mpTT [ref mplsPolicyTrafficTrunk [0..n]], 2525 mpFEC[ref mplsPolicyFEC [0..1]] 2527 5.25.1. The reference mpLSP 2529 This property contains an object reference to an 2530 mplsPolicyTrafficTrunk instance associated with a mplsPolicyFEC. The 2531 [0..n] cardinality indicates that there may be zero or more 2532 instances of mplsPolicyTrafficTrunk associated with any given 2533 mplsPolicyFEC; i.e. zero or more LSPs can share the same FEC 2534 specification. 2536 5.25.2. The reference mpFEC 2538 This property contains an object reference to an mplsPolicyFEC that 2539 is associated with an mplsPolicyTrafficTrunk. The [0..1] cardinality 2540 indicates that there may be zero or one FEC associated with any given 2541 traffic trunk. 2543 5.26. 2544 Association mplsPolicyFECofLSP 2546 The association mplsPolicyFECofLSP associates an LSP with a FEC. 2548 The association definition is as follows: 2550 NAME mplsPolicyFECofLSP 2551 DESCRIPTION Associates an LSP with a FEC. 2552 ABSTRACT False 2553 PROPERTIES mpLSP [ref mplsPolicyLSP [0..n]], 2554 mpFEC[ref mplsPolicyFEC [0..1]] 2556 5.26.1. The reference mpLSP 2558 This property contains an object reference to an mplsPolicyLSP 2559 instance associated with a mplsPolicyFEC. The [0..n] cardinality 2560 indicates that there may be zero or more instances of mplsPolicyLSP 2561 associated with any given mplsPolicyFEC; i.e. zero or more LSPs can 2562 share the same FEC specification. 2564 5.26.2. The reference mpFEC 2566 This property contains an object reference to an mplsPolicyFEC that 2567 is associated with an mplsPolicyTrafficTrunk. The [0..1] cardinality 2568 indicates that there may be zero or one FEC associated with any given 2569 LSP. 2571 5.27. 2572 Association mplsPolicyFECFilterSet 2574 The association mplsPolicyFECFilterSet associates a FilterList [CIM] 2575 with an mplsPolicyFEC. A FilterList represents the packet identifier 2576 of the FEC. 2578 NAME mplsPolicyFECFilterSet 2579 DESCRIPTION 2580 ABSTRACT False 2581 PROPERTIES mpFEC[ref mplsPolicyFEC[0..n], 2582 mpFilter[ref FilterList[0..n], 2583 mpFilterListPosition 2585 5.27.1. The Property mpFEC 2587 This property contains an object reference to an mplsPolicyFEC 2588 instance with which a number of filters can be associated. The [0..n] 2589 cardinality indicates that there may be 0, 1, or more than one 2590 mplsPolicyFEC associated with any given filter. i.e. zero or more 2591 FECs can share the same Filter specification. 2593 5.27.2. The Property mpFilter 2594 This property contains an object reference to a FilterList[CIM] 2595 instance. The [0..n] cardinality indicates that there may be 0, 1, or 2596 more than one FilterList associated with any given FEC. 2598 5.27.3. The Property mpFilterListPosition 2600 This property indicates the position of the FilterList in the FEC. 2601 The property is defined as follows: 2603 NAME mpFilterListPosition 2604 DESCRIPTION 2605 SYNTAX Integer (MUST be non-negative) 2607 6. Examples 2609 6.1. Establishing an LSP 2611 This section provides an example that shows how the classes defined 2612 above as part of the QoS information model for MPLS may be used in a 2613 typical policy scenario. For the example scenario we assume an MPLS 2614 network and two hosts (A and B) outside the MPLS domain (see Figure 2615 4). 2617 1.2.3.4 2618 +--------+ 2619 | Host A | +------------------+ 2620 +--------+ / \ 2621 | +---------+ | 2.3.4.5 2622 \--...--->| Ingress | +--------+ 2623 +---------+ | Egress |--\ 2624 1.2.3.5 | +--------+ | 2625 \ MPLS domain / | +--------+ 2626 +------------------+ \-...->| Host B | 2627 +--------+ 2628 2.3.4.6 2630 Figure 4: Example MPLS Network 2632 Furthermore, we assume for the scenario that traffic from A to B 2633 should be mapped to a specific forwarding equivalence class of a 2634 newly created LSP. The LSP be specified with a committed data rate 2635 of 10Mb/s. 2637 A provisioning policy to establish the LSP can be represented using 2638 the classes defined in the MPLS information model as follows: 2640 +--------------+ 2641 | PolicyRule | 2642 +--------------+ 2643 | 2644 | 2645 +------------------------+ 2646 | mplsPolicyLSPAction | 2647 +------------------------+ 2648 | 2649 | 2650 +------------------+ 2651 | mplsPolicyLSP | 2652 +------------------+ 2653 | 2654 | +-----------------+ 2655 |-- | mplsPolicyFEC | 2656 | +-----------------+ 2657 | | 2658 | | +----------------------------------+ 2659 | \--| FilterList | 2660 | | TrafficType=IPv4 | 2661 | | SourceIPAddress=1.2.3.4 | 2662 | | DestinationIPAddress=2.3.4.6 | 2663 | +----------------------------------+ 2664 | 2665 | +---------------------------+ 2666 |-- | qosPolicyTrfcProf | 2667 | | qpPRRate=10Mb/s | 2668 | +---------------------------+ 2669 | 2670 | +---------------------------------+ 2671 \-- | mplsPolicyRouteSpec | 2672 | mpIngressIPAddress=1.2.3.5 | 2673 | mpEgressIPAddress=2.3.4.5 | 2674 +---------------------------------+ 2676 Figure 5: Representation of the example policy rule 2678 The policy object illustrated in Figure 5 is built from policy 2679 classes defined in CIM, QPIM and this document. The root of the 2680 policy object is a rule object that is associated with no conditions 2681 (i.e. provisioning case) and on LSP establishing action 2682 (mplsPolicyLSPAction). The LSP is specified by an instance of 2683 mplsPolicyLSP. The specification includes FEC specification 2684 (mplsPolicyFEC), a specification of the LSP traffic profile of the 2685 LSP (qosPolicyTrafficProfile) and the route specification 2686 (mplsPolicyRouteSpec). 2688 6.2. Network wide bandwidth adjustment example 2690 The following example demonstrates the use of our information model 2691 to define policies that are applied on a network-wide basis. In this 2692 example, we describe the implementation of a network-wide policy 2693 that varies bandwidth allocations based on time of day and type of 2694 traffic using the policy information model. Traffic Trunks in the 2695 network are assigned "roles" in accordance with the Olympic Services 2696 Model, i.e. they are marked as "gold", "silver" or "bronze" 2697 according to the QoS properties of the traffic that they carry. A 2698 network-wide policy controls the bandwidth allocation associated 2699 with these traffic trunks. 2701 Specifically, the bandwidth for all gold TTs is reduced by 50% 2702 during nights and weekends. This could be potentially useful if the 2703 Service Level Agreements are such that a number of customers require 2704 gold service during business hours on weekdays, while they subscribe 2705 to lower service levels during non-business hours and weekends. 2707 Policy rules are defined to describe the time-varying bandwidth 2708 allocations to the appropriate Traffic Trunks. Associated with each 2709 traffic trunk is a traffic profile that describes the resource 2710 requirements for this trunk. Also associated with each traffic trunk 2711 are one or more route specifications that specify possible ways of 2712 routing this traffic trunk through the network. Each such route 2713 specification has its hops specified. 2715 For purposes of illustration, we assume the presence of a traffic 2716 engineering module that uses these specifications, along with 2717 information about the current nodes and links in the network, to 2718 compute appropriate constrained routes from these route 2719 specifications. In other words, not all route specifications will 2720 necessarily be used to create LSPs. Each traffic trunk is assigned 2721 to one or more LSPs according to its bandwidth requirements. 2723 When the TT's bandwidth requirements are modified, the traffic 2724 engineering module attempts to resize the LSP(s) for this TT to 2725 accommodate the new bandwidth demand. If the existing LSPs are not 2726 adequate, the traffic engineering module performs computations so 2727 that new LSPs are established, in the manner described above. 2729 Note that another scenario could be that the policy information 2730 model and the traffic provide no route specifications engineering 2731 module computes suitable LSPs based on traffic trunk attributes 2732 alone. 2734 For this example, the policy-based system contains the following: 2736 - A number of activated TTs (instance of mplsPolicyTrafficTrunk), 2737 each one assigned to one or more already established LSPs (instance 2738 of mplsPolicyLSP). For the assignment association an instance of 2739 mplsPolicyCurrentlyAssignedLSP association is used. 2741 - Each TT is characterized as either "gold", "silver" or "bronze", 2742 according to the QoS requirements of the traffic that is being 2743 forwarded through it, using its Roles property to store this value. 2744 - Each TT is associated (instance of mplsPolicyTT_TrafficProfile 2745 association) with one traffic profile (instance of 2746 qosPolicyPRTrfcProf). 2747 - Each TT is associated (instance of mplsPolicyEligibleRouteSpec 2748 association) with zero or more eligible route specifications 2749 (instance of mplsPolicyRouteSpec). 2750 - Each LSP is associated (instance of mplsPolicyLSPTrafficProfile 2751 association) with one traffic profile. 2753 To implement the network-wide policy described above, the following 2754 two policy rules are required for the gold TTs: 2756 Policy Rule 1: Roles property is set to "gold TT" 2757 IF "time is 8am" AND ("day is Monday" OR "day is Tuesday" 2758 OR "day is Wednesday" OR "day is Thursday" 2759 OR "day is Friday") 2760 THEN "Modify TT: Increase traffic profile bandwidth by 100%" 2762 Policy Rule 2: Roles property is set to "gold TT" 2763 IF "time is 5pm" AND ("day is Monday" OR "day is Tuesday" 2764 OR "day is Wednesday" OR "day is Thursday" 2765 OR "day is Friday") 2766 THEN "Modify TT: Decrease traffic profile bandwidth by 50%" 2768 The semantics of the first rule is that when the condition becomes 2769 true, it modifies the traffic profile of all the gold TTs, such that 2770 their bandwidth is increased by 100%. 2772 In a similar fashion, the semantics of the second rule is that when 2773 the condition becomes true, it modifies the traffic profile of all 2774 the gold TTs such that their bandwidths get decreased by 50%. Note 2775 that the increase and decrease is the same absolute amount. 2777 Note that the "Roles" property of those two policy rules is set to 2778 "gold TT" which indicates which TTs those rules are to be applied 2779 to. In this case those two rules are applied to all the TTs that 2780 have their Roles property also set to "gold TT". 2782 When the traffic profiles of the gold TTs are modified, the traffic 2783 engineering module is activated, to verify whether the current 2784 mapping of TTs to LSPs is still valid. For each modified TT, the 2785 traffic engineering module might either increase the bandwidth of 2786 the currently assigned LSPs, or reroute it based on its attributes. 2788 For modeling each of the above policy rules we use an instance of 2789 PolicyRule (defined in [PCIM]), an instance of 2790 PolicyTimePeriodCondition (also from [PCIM]) to represent the 2791 condition part of the rule, and we have an instance of 2792 mplsPolicyTTAction class to represent the action part of the rule, 2793 with its mpTTmode property set to "TTModify". This action takes the 2794 current TTs in the context of the action and modifies the traffic 2795 profile of this TT by the given amount. Note that this poses some 2796 problem with the current PCIM; see the section on open issues for a 2797 description of this. 2799 The Roles property is set to "gold TT" for the two rules (gold TT). 2800 In this way, the two rules will be applied to all the TTs that are 2801 considered gold and therefore have their Roles property set to "gold 2802 TT". 2804 7. Security Considerations 2806 The security considerations for this document are the same as those 2807 of [PCIM] and are not further addressed in this version of the draft. 2809 8. Open Issues 2811 The following open issues need to be resolved: 2813 1) Control of Signaling protocol mechanisms: While the draft is 2814 independent of the signaling protocol used for label distribution, 2815 policy actions relating to the control of specific CR-LDP mechanisms 2816 are incorporated in this version. These mechanisms may be moved to a 2817 protocol-specific model in later versions. 2819 2) The current draft contains traffic parameters specific to CR-LDP, 2820 as well as generic traffic parameters. Future versions may include 2821 additional parameters specific to other signaling protocols such as 2822 RSVP-TE. Further discussion is required to assess whether this is 2823 within the scope of the information model. Furthermore, this needs 2824 to be discussed with the PQIM authors. 2826 3) As discussed in the example, we want to calculate a new value for 2827 the bandwidth property of the traffic trunk's traffic profile. This 2828 raises three questions: how do we refer to the traffic profile in 2829 the context of the action, how do we access a single property of the 2830 traffic profile, and how do we calculate a new value for the traffic 2831 profile based on its old value? We initially considered introducing 2832 specific actions to do this, but decided to wait until a PCIM 2833 extension (e.g., as proposed in [PCIM_EXT]) is discussed. Basically, 2834 the same problem arises if a policy wants to add new traffic to a TT 2835 or LSP (change the FEC by adding new filter entries etc.) 2837 4) There may be a need to introduce a new class to model a Label 2838 Switched Router (LSR). This class would be derived from 2839 ComputerSystem in CIM. 2841 5) mplsPolicyFEC and qosPolicyTrfcProf are derived from Policy. 2842 Should they be derived from CIM's LogicalElement? 2844 6) In a future version, we will replace all the references in the 2845 actions with associations. 2847 7) Section 4.2.2 Traffic Trunks: "If a traffic trunk going in the 2848 reverse direction exists, it is associated with this traffic trunk 2849 via the mplsPolicyReverseDirTT association." What is the precise 2850 meaning of "in the reverse direction"? Possible meanings include 2851 reverse Ingress/Egress ProtocolEndpoints; reverse route; the reverse 2852 of the loosely specified route. 2854 8) For the classes mplsPolicyLSP, mplsPolicyTrafficTrunc, and 2855 mplsPolicyProtocolEndpoint, we have defined a role property "Roles". 2856 First question, does PCIM support roles for objects not derived from 2857 the class System in CIM? Second, is there a naming convention to be 2858 used in order to meet PCIMs definition? If no, we will change the 2859 name into unique names in order to more easily map the model into 2860 different data representions such as LDAP. 2862 9) In order to deal with DiffServ over MPLS, future work should take 2863 into account the mapping from LSPs to PHBs, and mapping of packets 2864 in LSPs to different PHBs (in case of E-LSPs [DS-MPLS]). Are there 2865 other means needed in this area? 2867 9. References 2869 [CIM] Distributed Management Task Force, Inc., "Common Information 2870 Model (CIM) Schema, version 2.3, March 2000. The components 2871 of the CIM v2.3 schema are available via links on the 2872 following DMTF web page: http://www.dmtf.org/spec/cims.html 2874 [PCIM] B. Moore, E. Ellesson, J. Strassner, "Policy Core Information 2875 Model -- Version 1 Specification", Internet Draft, 2876 , May, 2000. 2878 [PQIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy 2879 Framework QoS Information Model", Internet draft, 2880 , April 2000. 2882 [CRLDP] B. Jamoussi, "Constraint-Based LSP Setup using LDP", 2883 Internet Draft, , March 2000. 2885 [RSVP-TE] Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V., 2886 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 2887 Internet Draft draft-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 2889 [DS-MPLS] F. LeFaucher, L. Wu, B. Davie, S. Davari, P. Vaanenen, 2890 R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 2891 Differentiated Services", work in progrss, 2892 draft-ietf-mpls-diff-ext-05.txt, June 2000. 2894 [MPLS-ARCH] E.Rosen, A.Viswanathan, R.Callon, "Multiprotocol Label 2895 Switching Architecture", work in progress, 2896 draft-ietf-mpls-arch-06.txt, August 1999. 2898 [MPLS-FW] R.Callon, P.Doolan, N.Feldman, A.Freddette, G.Swallow, 2899 A.Viswanathan, "A Framework for MPLS", work in progress, 2900 draft-ietf-mpls-framework-05.txt, September 1999. 2902 [REQPMPLS] S. Wright, S. Herzog, F. Reichmayer, R. Jaeger, 2903 "Requirements for Policy Enabled MPLS", work in progress, 2904 draft-wright-policy-mpls-00.txt, March 2000. 2906 [REQMPLS_TE] Wright, S., Reichmeyer, F., Jaeger, R., Gibson, M., 2907 "Policy-Based Load-Balancing in Traffic-Engineered MPLS 2908 Networks", Internet Draft draft-wright-mpls-te-policy-00.txt, 2909 June 2000. 2911 [MPLS-MIB] Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS 2912 Traffic Engineering Management Information Base Using SMIv2", 2913 Internet Draft, draft-ietf-mpls-te-mib-03.txt, March 2000. 2915 [RFC2702] D. Awduche, J. Malcom, J. Agogbua, M. O'Dell, J. McManus, 2916 "Requirements for Traffic Engineering over MPLS", RFC 2702, 2917 September 1999. 2919 [RFC2430] Li, T. and Y. Rekhter, "Provider Architecture for 2920 Differentiated Services and Traffic Engineering (PASTE)", 2921 RFC 2430, October 1998. 2923 [PCIM_EXT] M. Brunner, J. Quittek, "Policy Framework Core Info Model 2924 Extensions", Internet Draft, 2925 draft-brunner-policy-core-ext-00.txt, November 2000. 2927 10. Authors' Addresses 2929 Kazuhiko Isoyama, Makiko Yoshida 2930 NEC Corporation 2931 Development Laboratories 2932 1131, Hinode, Abiko, Chiba, 270-1198, JAPAN 2933 Phone: +81 471-85-6738 2934 Fax: +81 471-85-6841 2935 Email: [iso|myoshida]@ptl.abk.nec.co.jp 2937 Marcus Brunner, Juergen Quittek 2938 NEC Europe Ltd. 2939 C&C Research Laboratories 2940 Adenauerplatz 6 2941 D-69115 Heidelberg, Germany 2942 Phone: +49 (0)6221 905110 2943 Fax: +49 (0)6221 9051155 2944 Email: [brunner|quittek]@ccrle.nec.de 2946 Ritu Chadha, George Mykoniatis, Alex Poylisher, Ravichander 2947 Vaidyanathan 2948 Telcordia Technologies 2949 445 South Street 2950 Morristown NJ 07960 2951 Phone: +1-973-829-4869 2952 Email: [chadha|mykoniat|sher|vravi]@research.telcordia.com 2954 Andreas Kind 2955 IBM Zurich Research Laboratory 2956 Saumerstrasse 4 2957 CH-8803 Ruschlikon 2958 Switzerland 2959 Phone: +41-1-724-8915 2960 Fax +41-1-724-8578 2961 Email: ank@zurich.ibm.com 2963 Francis Reichmeyer 2964 PfN, Inc. 2965 26 Landsdowne St. 2966 Cambridge, MA 02139 2967 Phone: +1-617-529-3970 2968 Email: franr@pfn.com 2970 Full Copyright Statement 2972 Copyright (C) The Internet Society (2000). All Rights Reserved. 2974 This document and translations of it may be copied and furnished to 2975 others, and derivative works that comment on or otherwise explain it 2976 or assist in its implementation may be prepared, copied, published 2977 and distributed, in whole or in part, without restriction of any 2978 kind, provided that the above copyright notice and this paragraph are 2979 included on all such copies and derivative works. However, this 2980 document itself may not be modified in any way, such as by removing 2981 the copyright notice or references to the Internet Society or other 2982 Internet organizations, except as needed for the purpose of 2983 developing Internet standards in which case the procedures for 2984 copyrights defined in the Internet Standards process must be 2985 followed, or as required to translate it into languages other than 2986 English. 2988 The limited permissions granted above are perpetual and will not be 2989 revoked by the Internet Society or its successors or assigns. 2991 This document and the information contained herein is provided on an 2992 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2993 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 2994 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2995 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2996 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.