idnits 2.17.1 draft-isoyama-policy-mpls-info-model-00.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 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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 336 has weird spacing: '... chosen by th...' -- 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 (12 July 2000) is 8687 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'QPIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'DS-MPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ENC' -- Possible downref: Non-RFC (?) normative reference: ref. 'REQPMPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PBLBMPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'POLICY-FW' ** Downref: Normative reference to an Informational RFC: RFC 2702 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT K. Isoyama 3 M. Yoshida 4 Expires January 2001 NEC Corporation 5 M. Brunner 6 A. Kind 7 J. Quittek 8 NEC Europe Ltd. 9 12 July 2000 11 Policy Framework QoS Information Model for MPLS 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document presents an information model for representing QoS 37 policies for Multi-Protocol Label Switching (MPLS). The model is 38 based on the Policy Framework QoS Information Model (QPIM) and the 39 Policy Core Information Model (PCIM). These models are extended with 40 new classes for controlling and managing the life-cycle of Label 41 Switched Paths (LSPs) and for mapping of traffic onto existing LSPs. 42 The control and management of LSP life-cycles includes mainly the 43 creation, update, and deletion of LSPs and the assignment of QoS 44 properties to LSPs. 46 Even if this document is primarily intended to cover the QoS related 47 MPLS areas, it also covers traffic engineering related policies. 49 Table of Contents 51 1. Introduction 2 52 1.1 Goals 3 53 2. Information Model Hierarchy 4 54 2.1 Relation with PCIM 4 55 2.2 Relation with QPIM 5 56 2.3 Class Hierarchy 5 57 3. MPLS and Label Switched Paths 8 58 3.1 QoS Properties 8 59 3.2 QoS routing for LSP 8 60 3.3 Signaling LSPs 9 61 3.4 Controlling the Signaling 9 62 3.5 Forward Equivalence Classes (FEC) 9 63 4. Constructing MPLS Policy Rule 9 64 4.1 Actions related to MPLS signaling 10 65 4.2 MPLS classifier actions 10 66 4.3 DiffServ with MPLS policy rules 11 67 4.4 MPLS tunneling 11 68 4.5 MPLS Policy Variables 12 69 5. Class Definitions 12 70 5.1 Class mplsPolicyLSP 12 71 5.2 Class mplsPolicyCRLSP 13 72 5.3 Class mplsPolicyLSPResvAction 15 73 5.4 Class mplsPolicyCRLSPResvAction 16 74 5.5 Class mplsPolicyCRLDPSignalCtrlAction 18 75 5.6 Class mplsPolicyMPLSPRAction 21 76 5.7 Class mplsPolicyFEC 21 77 5.8 Class mplsPolicyFECIP 21 78 5.9 Class mplsPolicyFECIPDS 22 79 5.10 Class mplsPolicyCRLSPTrfcProf 23 80 5.11 Class mplsResourceClass 24 81 5.12 Class mplsCRLDPResourceClass 25 82 6. Examples 26 83 7. Security Considerations 28 84 8. References 28 85 9. Author's Addresses 30 87 1. Introduction 89 This document presents an information model for representing QoS 90 policies for Multi-Protocol Label Switching (MPLS). The model is 91 based on the Policy Framework QoS Information Model (QPIM) and the 92 Policy Core Information Model (PCIM). These models are extended with 93 new classes for controlling and managing the life-cycle of Label 94 Switched Paths (LSPs) and for mapping of traffic onto existing LSPs. 95 The control and management of LSP life-cycles includes mainly the 96 creation, update, and deletion of LSPs and the assignment of QoS 97 properties to LSPs. 99 The informational model described in this draft is independent of a 100 binding to a specific type of repository. A future draft may provide 101 a mapping to a schema for a repository that can be accessed, for 102 instance, via the Lightweight Directory Access Protocol (LDAP). 104 1.1 Goals 106 The ultimate goal of policy-based networking is to support the trend 107 away from individual device management, toward managing and 108 controlling a network as a whole [POLICY-FW]. Policy-based networking 109 allows that network elements from different vendors, equipped with 110 different capabilities can be consistently configured according to 111 network policies. Network policies may be, for instance, aligned to 112 the business goals of a company. 114 MPLS is a combination of switched forwarding with network layer 115 routing. The added value of MPLS is provided by a better 116 price/performance ratio of network layer routing, improved 117 scalability in the network layer, and greater flexibility in the 118 delivery of routing services [MPLS-FW]. These advantages are achieved 119 by label switching: A packet is assigned to a Forwarding Equivalence 120 Class (FEC) when it enters the MPLS network. The FEC is encoded as a 121 label in the packet so that it can then be used at subsequent hops 122 between ingress and egress nodes to determine the forwarding 123 treatment by indexing into a table. All packets belonging to a 124 particular FEC travel the same path through the network. 126 Typically, information about bindings of labels to FECs is 127 distributed by a label distribution protocol (e.g. LDP, CR-LDP, BGP, 128 RSVP-TE). The use of policies in the context of MPLS is motivated by 129 the need to provide high-level support for the operation of MPLS 130 networks beyond a standard way of label distribution with LDP or 131 other label distribution protocols. An important aim is to provide 132 high-level means for mapping traffic that matches a specific traffic 133 filter onto an LSP with specific QoS characteristics. Such high-level 134 policies could be used, for instance, with DiffServ over MPLS [DS- 135 MPLS]. 137 Wright et al. state requirements for policy-enabled MPLS networks in 138 [REQPMPLS]. These include 140 - a higher-level MPLS abstraction for specifying network-wide MPLS 141 policies, 142 - controllability of the LSP Life Cycle, 143 - consistency with other techniques, such as DiffServ, 144 - flexibility in LSP admission control, and 145 - integration with network service objectives. 147 The model introduced below complies with these requirements. It is 148 also suited to specify MPLS load balancing policies as described in 149 [PBLBMPLS]. The classes introduced in this document focus on the 150 representation of MPLS-related policy actions, including the 151 representation of LSPs, FECs, and CR-LSP traffic profiles. These 152 classes can be instantiated in order to specify the MPLS traffic 153 profile for different kind of traffic entering the MPLS domain. 154 Currently, the classes only reflect traffic profiles according to 155 CR-LSP. However, the class hierarchy is designed such that other 156 means for describing traffic profiles in MPLS (e.g. RSVP) can be 157 added later. Whether LSPs that have been set up already are able to 158 accommodate traffic according to the specified profile, a new LSP has 159 to be created, or the resources in the MPLS domain do not suffice to 160 accommodate the traffic, is transparent with this model. 162 Even if this document is primarily intended to cover the QoS related 163 MPLS areas, it also covers traffic engineering related policies. 165 2. Information Model Hierarchy 167 The model is based on the Policy Framework QoS Information Model 168 (QPIM) [QPIM]. QPIM defines classes for representing QoS policy 169 rules, including QoS policy rule conditions and QoS policy rule 170 actions. The classes specified in QPIM address QoS provisioning using 171 Differentiated Services (DiffServ) as well as QoS control via RSVP 172 for Integrated Services (IntServ). QPIM itself refines the Core 173 Information Model (CIM) [PCIM] which includes generic classes for 174 policy-based networking. 176 2.1 Relation with PCIM 178 The object-oriented information model described in PCIM provides 179 generic classes for representing policy information. The model allows 180 to specify network policies in terms of policy rules. A policy rule 181 is an object that stands for a "IF conditions THEN actions" 182 statement. A policy rule is most importantly defined by a list of 183 policy conditions and a list of policy actions. 185 The QoS model for MPLS refines the notion of policy actions as 186 described in PCIM. New classes are introduced in order to model the 187 following MPLS-related policy actions: 189 - Generic reservation of a LSP 190 - Reservation of a LSP with QoS properties or 191 using an CR-LDP Label Request Message 192 - Decision for CR-LDP Messages 193 - Mapping of traffic into a LSP 195 Furthermore, new policy classes are specified directly under the PCIM 196 class Policy. These classes are used because their instances may be 197 reused and shared between several MPLS policies. The new classes are 198 related to: 200 - CR-LSP traffic profiles 201 - Representation of LSPs 202 - Representation of FECs 203 - Mapping of LSPs to specific network 204 resources 206 2.2 Relation with QPIM 208 QPIM defines a condition class to model individual conditions in 209 terms of variable, operator and value [QPIM]. The variable specifies 210 a specific traffic attribute that can be compared with the value 211 using the operation. QPIM lists a set of variables that are typically 212 required on layer 2 and 3. This draft extends the list of predefined 213 variables to access the top label entry on the label stack of an MPLS 214 packet [MPLS-ENC]. 216 2.3 Class Hierarchy 218 This section presents with Figure 1 the inheritance class hierarchy 219 for the MPLS information model. The classes introduced with PCIM and 220 QPIM are indicated, so that the relation of these classes to the 221 classes defined later in this document is visible. 223 [unrooted] 224 | 225 +---Policy (abstract, defined in PCIM) 226 | | 227 | +---PolicyGroup (PCIM) 228 | | | 229 | | +---qosPolicyDomain (QPIM) 230 | | | 231 | | +---qosNamedPolicyContainer (QPIM) 232 | | 233 | +---PolicyRule (PCIM) 234 | | 235 | +---PolicyCondition (PCIM) 236 | | | 237 | | +---PolicyTimePeriodCondition (PCIM) 238 | | | 239 | | +---VendorPolicyCondition (PCIM) 240 | | | 241 | | +---qosPolicySimpleCondition (QPIM) 242 | | 243 | +---PolicyAction (PCIM) 244 | | | 245 | | +---VendorPolicyAction (PCIM) 246 | | | 247 | | +---qosPolicyPRAction (QPIM) 248 | | | 249 | | +---qosPolicyRSVPAction (QPIM) 250 | | | 251 | | +---qosPolicyRSVPSignalCtrlAction (QPIM) 252 | | | 253 | | +---qosPolicyRSVPInstallAction (QPIM) 254 | | | 255 | | +---mplsPolicyLSPResvAction (this document) 256 | | | 257 | | +---mplsPolicyCRLSPResvAction (this document) 258 | | | 259 | | +---mplsPolicyCRLDPSignalCtrlAction (this document) 260 | | | 261 | | +---mplsPolicyMPLSPRAction (this document) 262 | | 263 | +---qosPolicyPRTrfcProf (QPIM) 264 | | 265 | +---qosPolicyRSVPTrfcProf (QPIM) 266 | | 267 | +---mplsPolicyCRLSPTrfcProf (this document) 268 | | 269 | +---qosPolicyVariable (QPIM) 270 | | 271 | +---qosPolicyValue (QPIM) 272 | | | 273 | | +---qosPolicyIPv4AddrValue (QPIM) 274 | | | 275 | | +---qosPolicyIPv6AddrValue (QPIM) 276 | | | 277 | | +---qosPolicyMACAddrValue (QPIM) 278 | | | 279 | | +---qosPolicyStringValue (QPIM) 280 | | | 281 | | +---qosPolicyBitStringValue (QPIM) 282 | | | 283 | | +---qosPolicyDNValue (QPIM) 284 | | | 285 | | +---qosPolicyAttributeValue (QPIM) 286 | | | 287 | | +---qosPolicyIntegerValue (QPIM) 288 | | 289 | +---qosPolicyMeter (QPIM) 290 | | 291 | +---qosPolicyPHBSet (QPIM) 292 | | 293 | +---qosPolicyPHB (QPIM) 294 | | 295 | +---mplsPolicyLSP (this document) 296 | | | 297 | | +---mplsPolicyCRLSP (this document) 298 | | 299 | +---mplsResourceClass (abstract, this document) 300 | | | 301 | | +---mplsCRLDPResourceClass (this document) 302 | | 303 | +---mplsPolicyFEC (abstract, this document) 304 | | 305 | +---mplsPolicyFECIP (this document) 306 | | 307 | +---mplsPolicyFECIPDS (this document) 308 | 309 +---CIM_ManagedSystemElement (abstract, defined in PCIM) 310 | 311 +---CIM_LogicalElement (abstract, defined in PCIM) 312 | 313 +---CIM_System (abstract, defined in PCIM) 314 | 315 +---CIM_AdminDomain (abstract, defined in PCIM) 316 | 317 +---PolicyRepository (PCIM) 318 Figure 1: Inheritance Class Hierarchy 320 3. MPLS and Label Switched Paths 322 A general discussion of issues related to MPLS is presented in the 323 framework [MPLS-FW] and architecture [MPLS-ARCH] documents. A brief 324 summary of salient features is provided below to provide background 325 information for the later sections. 327 MPLS has the concept of a Label Switched Path (LSP) with or without 328 QoS guarantees. A path needs to be setup using some sort of a 329 signaling protocol. Currently under discussion are [LDP], [CRLDP], 330 and [RSVP-TE]. CR-LDP and RSVP-TE support setting up LSPs with QoS 331 guarantees. Furthermore, LSPs can be specified in a explicit or 332 implicit manner. Explicit routed LSPs specify the path the LSP is 333 taking explicitly. Implicit routed LSPs require a routing mechanisms 334 within the network, which determines the path. A mixture of these are 335 loosely routed LSPs, where some nodes are specified others need to be 336 chosen by the signaling protocol from a given set of nodes. 338 LSPs are the key objects to be modeled in an MPLS information model. 339 The properties of the LSP depend on what kind of LSPs are taken into 340 account (explicit vs implicit, with or without QoS etc.). The 341 explicit route of an explicitly routed LSP may, for instance, be a 342 property of an LSP. Note however, that the labels an LSP gets on 343 links is not a property of the LSP, needed on this level of 344 abstraction. 346 3.1 QoS Properties 348 MPLS in its original fashion has no notion of QoS. However, using 349 MPLS for appropriate traffic engineering already enables an ISP to 350 provide better quality to its customers than without MPLS. 352 On the other hand, an LSP can have QoS properties, which need to be 353 enforced by QoS mechanisms in LSRs. In a recent proposal to support 354 DiffServ over MPLS [DS-MPLS] MPLS is used in conjunction with 355 DiffServ for QoS enforcement. This approach allows a Label Switched 356 Router (LSR) to apply a specified Per-Hop Behavior (PHB) to packets 357 of an LSP. 359 3.2 QoS routing for LSP 361 In order to maintain the quality, the LSP setup process is constraint 362 to QoS requirements. However, different possibilities of QoS routing 363 can be applied. First, a central instance can calculate the best 364 route with QoS state information of the whole network and signal the 365 route with the explicit route feature of CR-LSP or any other 366 configuration mechanism. Second, the route can be calculated in a 367 distributed fashion, during the signaling process. The MPLS model of 368 this document is transparent to the different routing issues. 370 3.3 Signaling LSPs 372 Setting up a new LSP requires signaling or configuration mechanisms. 373 Fundamentally two types are possible (1) using a hop-by-hop signaling 374 protocol like LDP, CR-LDP, or RSVP-TE, or (2) configuring the LSP 375 over SNMP or COPS. 377 How the LSP is setup is also transparent to this draft, even so, we 378 decided to use the CR-LDP traffic profile. The action to be taken 379 from a policy servers point of view is initiating the setup process. 381 3.4 Controlling the Signaling 383 The signaling process for setting up a new LSP may be under different 384 policy or resource constraints. Therefore, we introduce the 385 mplsPolicyCRLDPSignallingAction as a mean to control this process 386 with policies. In some network operation environments this will not 387 be needed, if the policy control is applied before the signaling 388 process in the domain. 390 In others, it is very convenient for the policy-based management 391 system to define policies for the signaling process. 393 3.5 Forward Equivalence Classes (FEC) 395 The concept of a FEC specifies, what traffic is mapped into a 396 specific LSP. The specification of FECs can range from very simple, 397 e.g., just the destination IP address, to very complex, e.g., a set 398 of filters including IP addresses, ports, DSCPs etc. In our model of 399 a FEC, we regard a FEC as a property of an LSP. The binding of FECs 400 to LSPs may be performed at or after the LSP setup. 402 4. Constructing MPLS Policy Rule 404 Policies in the MPLS domain mainly focus on 405 - life-cycle management of LSPs, including the signaling, 406 resource control, and admission control etc., and 407 - mapping of traffic to LSPs, including mapping of DiffServ traffic 408 and tunneling of MPLS traffic over a different LSP for the purpose 409 of traffic engineering. 411 The QoS information model is extended mainly with new objects to be 412 stored in a directory or database, such as an LSP, a FEC etc, and 413 with policy actions controlling the signaling process, initiating the 414 LSP setup, and mapping traffic into LSPs. 416 This section discusses the policy actions, objects, and variables 417 that are necessary to construct MPLS Policy Rules. 419 4.1 Actions related to MPLS signaling 421 Signaling in MPLS comprises setting up, releasing and updating an LSP 422 along a number of LSRs. 424 It should be possible to control the initiation and the execution of 425 these processes by policies. For some signaling protocols, e.g. the 426 Label Distribution Protocol (LDP), the signaling is initiated by a 427 LSR. However, even in this case the start of the signaling process 428 may be triggered by a policy. 430 Therefore, the draft specifies policy actions to initiate the setup, 431 update, or release of an LSP (mplsPolicyLSPResvAction, 432 mplsPolicyCRLSPResvAction), as well as a policy action controlling 433 the LSP setup process (mplsPolicyCRLDPSignalingAction). 435 4.2 MPLS classifier actions 437 The mapping of traffic to LSPs is performed at the edge LSR of an 438 MPLS domain. The MPLS framework document describes different examples 439 of traffic granularities, that can be mapped to LSPs. In the MPLS 440 context, the traffic mapped is often referred to as Forward 441 Equivalence Class (FEC), which forwards a group of packets in the 442 same manner. This draft defines the mplsPolicyPRAction class for 443 specifying the mapping. 445 Since there are so many possibilities, the definition of all kinds of 446 FECs is for further study. In this document, we propose two kinds of 447 FECs, one specified through the IP destination address 448 (mplsPolicyFECIP) and the other through the IP destination address 449 together with the DSCP value in DiffServ (mplsPolicyFECIPDS). 450 However, note that the FEC class is mainly used to store a FEC 451 together with an LSP. 453 The definition of the mapping between FECs and LSPs, is specified in 454 the policy rule condition. In the policy condition any kind of 455 filters can be specified. See QPIM for a deeper discussion of the 456 specification of filters. 458 4.3 DiffServ with MPLS policy rules 460 MPLS with DiffServ capable Label Switched Routers extends also the 461 policy rule set in order to perform the mapping from DiffServ Ordered 462 Aggregates to MPLS paths. This mainly includes 464 - the mapping of DiffServ specific traffic into LSPs on the 465 edge LSRs, and 466 - the mapping of LSRs to Per-Hop Behaviors on the core LSRs 468 4.3.1 Mapping of DiffServ specific traffic into LSPs 470 The mapping consists of a specification of a DiffServ-MPLS specific 471 FEC and a reference to an LSP object. The FEC includes the 472 specification of the DSCP value and the destination IP address of a 473 packet. Together with the mplsPolicyPRAction this allows a policy 474 manager to specify the mapping of DiffServ classes to LSPs. 476 4.3.2 Assignment of LSP to PHB 478 At core LSRs, arriving packets are forwarded according to the MPLS 479 label. As soon as DiffServ-enabled LSRs are deployed, packets get a 480 pre-defined per-hop behavior. Most likely the assignment of a packet 481 with MPLS label X to behavior class Y has been configured already at 482 the LSP setup time. However, the mapping could be policy controlled. 484 4.4 MPLS tunneling 486 In MPLS, a mechanism for label stacking is defined, and the label 487 stacking is mainly used for tunneling/aggregating MPLS traffic for 488 traffic engineering purposes. Since the LSP is defined very open in 489 this draft, no differentiation between an LSP used as an MPLS tunnel 490 and an LSP used as an IP path is needed. However, the mapping of 491 traffic into an LSP is different. In the first case, the mapping is 492 in the MPLS domain, meaning MPLS packets with specified labels are 493 mapped to an MPLS tunnel. In the IP case, the mapping from IP traffic 494 to an LSP needs to be defined. 496 This document does not specify special class for MPLS tunneling. 497 However, tunneling can be achieved by specifying mplsPolicyPRAction 498 for tunneling points. In order to specify the mapping of an LSP into 499 another LSP, we only define the MPLS label variable in the following 500 section. 502 4.5 MPLS Policy Variables 504 The QoS policy information model specifies a set of pre-defined 505 variables to support a set of fundamental QoS terms that are commonly 506 used in policy conditions [QPIM]. In order to specify meaningful 507 policy rules in the MPLS domain, we need to extend the set of pre- 508 defined variables with MPLS specific variables. 510 The following table defines the pre-defined variables for MPLS and 511 its local binding. 513 +----------------+--------------------------------------------------+ 514 | Variable name | Logical binding | 515 +----------------+--------------------------------------------------+ 516 | MPLSLabel | The MPLS label of the flow. Compared to the MPLS | 517 | | label in the MPLS shim header field or the | 518 | | combined VPI/VCI in ATM. | 519 +----------------+--------------------------------------------------+ 520 | MPLSExp | The MPLS Exp field of the flow. Compared to the | 521 | | MPLS Experimental field in the MPLS shim header. | 522 +----------------+--------------------------------------------------+ 523 Table 1: Pre-defined Variable Names and their Bindings 525 Both variables can be of class type qosPolicyIntegerValue or 526 qosPolicyBitStringValue. 528 5. Class Definitions 530 5.1 Class mplsPolicyLSP 532 This class represents properties of a general LSP. It contains only a 533 minimal set of properties. It includes a unique LSP identifier and a 534 Forward Equivalence Class (FEC). The LSP identifier is composed of 535 the ingress LSR router ID (or any of its own IP addresses) and a 536 locally unique LSP ID. See also the LSPID TLV in [CRLDP]. The 537 identifier is used to refer to an LSP in the whole MPLS network. The 538 FEC property stores the FECs currently mapped to this LSP. The FEC 539 may be empty in the LSP setup phase, and filled with FEC in the 540 process of mapping different kind of FEC to this LSP. 542 NAME mplsPolicyLSP 543 DERIVED FROM Policy (defined in [PCIM]) 544 ABSTRACT False 545 PROPERTIES mpLocalLSPID, mpIngressLSRRouterID, 546 mpFEC 548 5.1.1 The Property mpLocalLSPID 550 This property is an integer that indicate the LSPID which is unique 551 with reference to Ingress LSR. 553 NAME mpLocalLSPID 554 SYNTAX Integer (must be in the range 0-65535) 556 5.1.2 The Property mpIngressLSRRouterID 558 This property represents Router ID of the Ingress LSR of the LSP. 559 Typically the router id is specified by one of its own IP addresses. 561 NAME mpIngressLSRRouterID 562 SYNTAX String 563 FORMAT IPv4address | hostname | number 565 5.1.3 The Property mpFEC 567 This property specifies the Forward Equivalence Class (FEC) of the 568 LSP. The property contains a reference to an object of the 569 mplsPolicyFEC class. The FEC can be specified in many different ways 570 depending on the area, MPLS is applied. For example, in the case of 571 DiffServ with MPLS, the FEC consist of an IP destination address 572 (prefix) and a set of DSCPs. 574 NAME mpFEC 575 SYNTAX Reference to a mplsPolicyFEC object 577 5.2 Class mplsPolicyCRLSP 579 This class represents properties of a CR-LSP, which is typically 580 established using CR-LDP [CRLDP]. The explicit route property 581 specifies the path an LSP takes in the setup phase, or stores the 582 path an LSP setup process has chosen. It refers to the Explicit Route 583 TLV of CR-LDP. Furthermore, the CR-LSP contains a traffic profile 584 description modeled after the CR-LDP traffic model. As soon as 585 resources are associated with a path, it is very convenient from the 586 management perspective to have different resource classes in a 587 network. So the resource class property specifies from which resource 588 class the CR-LSP draws its resources. The route pinning property 589 defines whether the part of the route, which is loosely specified, is 590 pinned after the setup or if the network is allowed to re-route the 591 loosely routed part of the LSP. The holding priority is the counter 592 part to the set priority specified in the mplsPolicyCRLSPResvAction. 594 Setting up a new CR-LSP with a higher set priority than the hold 595 priority of existing LSPs, results in releasing the existing CR-LSP. 596 However, decisions in case of resource shortage, can also be made by 597 the policy server through the possibility of the 598 mplsPolicyCRLDPSignalCtrlAction. Finally, the LSP type is mainly 599 introduced to easier distinguish explicit routed from implicit routed 600 LSPs and LSPs with or without QoS. 602 NAME mplsPolicyCRLSP 603 DERIVED FROM mplsPolicyLSP 604 ABSTRACT False 605 PROPERTIES mpExplicitRoute, mpCRLSPTrfcProf, 606 mpResourceClass, mpCRLSPRoutePinning, 607 mpCRLSPHoldPrio, mpLSPType 609 5.2.1 The Property mpExplicitRoute 611 This property represents the explicit routing path of the CR-LSP. The 612 explicit path is specified through a list of routers (IP address or 613 hostname) an LSP is traversing in the given order. 615 NAME mpExplicitRoute 616 SYNTAX String 617 FORMAT ordered list of IPv4address | IPv6address | hostname 619 5.2.2 The Property mpCRLSPTrfcProf 621 This property is a reference to a mplsPolicyCRLSPTrfcProf object, 622 which defines a CR-LSP traffic parameter according to the Traffic 623 Parameters TLV of [CRLDP]. 625 NAME mpCRLSPTrfcProf 626 SYNTAX Reference to a mplsPolicyCRLSPTrfcProf object 628 5.2.3 The Property mpResourceClass 630 This property represents the resource class of the LSP as a reference 631 to a mplsResourceClass object. We propose to specify the property as 632 a reference of an abstract resource class object, because different 633 types, aggregation schemas etc. of resource classes are possible. So 634 this design enables an implementation to extend the resource classes 635 to application specific types without changing the CRLSP class. 637 NAME mpResourceClass 638 SYNTAX Reference to an mplsResourceClass object. 640 5.2.4 The Property mpCRLSPRoutePinning 642 This property indicates whether route pinning of the CR-LSP is 643 requested or not. 645 NAME mpCRLSPPRoutePinning 646 SYNTAX Integer (ENUM) - {"NotRequested"=0; "Requested"=1} 648 5.2.5 The Property mpCRLSPHoldPrio 650 This property represents the holding priority of the CR-LSP which is 651 already set up. A newly setup LSP is only allowed to take the 652 resources of this LSP if its set priority is higher than the hold 653 priority. 655 NAME mpCRLSPHoldPrio 656 SYNTAX Integer (must be in the range 0-255) 658 5.2.6 The property mpLSPType 660 An LSP can be defined in different ways. It is possible to have 661 explicit or implicit routing with or without QoS traffic profile. 662 This property defines which sort of LSP is defined out of the four 663 combinations. A implicit routed LSP has an empty mpExplicitRoute 664 property. Where as an LSP without QoS has an empty mpCRLSPTrfcProf 665 property. 667 NAME mpLSPType 668 SYNTAX Integer (ENUM) - { 669 "implicit/no QoS"=1; 670 "implicit/QoS"=2; 671 "explicit/no QoS"=3; 672 "explicit/QoS"=4; 673 } 675 5.3 Class mplsPolicyLSPResvAction 677 This class defines a generic LSP reservation action. The action 678 initiates the setup, update, or release of an LSP given in the mpLSP 679 property. The FEC specification in the LSP may determine the route of 680 the LSP. The route is implicitly chosen according to the IP routing 681 tables. No constraints can be applied to this action. See the next 682 section for constraint-based routing of LSPs. The class definition is 683 as follows: 685 NAME mplsPolicyLSPResvAction 686 DERIVED FROM PolicyAction (defined in [PCIM]) 687 ABSTRACT False 688 PROPERTIES mpLSP, mpMode 690 5.3.1 The Property mpLSP 692 This property is a reference to a mplsPolicyLSP object, which defines 693 an LSP. The attribute is defined as follows: 695 NAME mpLSP 696 SYNTAX Reference to a mplsPolicyLSP object 698 5.3.2 The Property mpMode 700 The mpMode property specifies whether the action is a setup, release, 701 or update action of an LSP. 703 NAME mpMode 704 SYNTAX Integer (ENUM) - { 705 "LSPSetup"=0; 706 "LSPUpdate"=1; 707 "LSPRelease"=2; 708 } 710 5.4 Class mplsPolicyCRLSPResvAction 712 This class defines a CR-LSP reservation action using CR-LDP Label 713 Request Messages. The LSP to be setup is specified in the mpCRLSP 714 property, which contains all properties associated with the CR-LSP. 715 The set priority property specifies whether an existing LSP may be 716 preempted in order to setup the new more important LSP. The property 717 is mapped to the SetPrio field of the Preemption TLV [CRLDP]. All 718 negotiable properties specify whether the traffic parameter is 719 negotiable or not. The properties are mapped to the flags field of 720 the Traffic Parameter TLV of [CRLDP]. The class definition is as 721 follows: 723 NAME mplsPolicyCRLSPResvAction 724 DERIVED FROM PolicyAction (defined in [PCIM]) 725 ABSTRACT False 726 PROPERTIES mpCRLSP, mpCRLSPsetPrio, 727 mpPDRNegotiable, mpPBSNegotiable, 728 mpCDRNegotiable, mpCBSNegotiable, 729 mpEBSNegotiable, mpWeightNegotiable 731 5.4.1 The Property mpCRLSP 733 This property is a reference to a mplsPolicyCRLSP object, which 734 defines the CR-LSP to be setup. The property is defined as follows: 736 NAME mpCRLSP 737 SYNTAX Reference to a mplsPolicyCRLSP object 739 5.4.2 The Property mpCRLSPSetPrio 741 This property represents the setting priority of the CR-LSP. The 742 property is defined as follows: 744 NAME mpCRLSPSetPrio 745 SYNTAX Integer (must be in the range 0-255) 747 5.4.3 The Property mpPDRNegotiable 749 This property indicates whether Peak Data Rate of the CR-LSP is 750 negotiable or not. The attribute is defined as follows: 752 NAME mpPDRNegotiable 753 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 755 5.4.4 The Property mpPBSNegotiable 757 This property indicates whether Peak Burst Size of the CR-LSP is 758 negotiable or not. The attribute is defined as follows: 760 NAME mpPBSNegotiable 761 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 763 5.4.5 The Property mpCDRNegotiable 765 This property indicates whether Committed Data Rate of the CR-LSP is 766 negotiable or not. The attribute is defined as follows: 768 NAME mpCDRNegotiable 769 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 771 5.4.6 The Property mpCBSNegotiable 773 This property indicates whether Committed Burst Size of the CR-LSP is 774 negotiable or not. The attribute is defined as follows: 776 NAME mpCBSNegotiable 777 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 779 5.4.7 The Property mpEBSNegotiable 781 This property indicates whether Excess Burst Size of the CR-LSP is 782 negotiable or not. The attribute is defined as follows: 784 NAME mpEBSNegotiable 785 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 787 5.4.8 The Property mpWeightNegotiable 789 This property indicates whether Weight of the CR-LSP is negotiable or 790 not. The attribute is defined as follows: 792 NAME mpWeightNegotiable 793 SYNTAX Integer (ENUM) - {"NotNegotiable"=0; "Negotiable"=1} 795 5.5 Class mplsPolicyCRLDPSignalCtrlAction 797 This class defines a policy action to be applied to CR-LDP messages. 798 The message type property defines which messages are concerned. The 799 mpSendNotification property specifies whether a notification should 800 be sent, in case the notification is sent, the mpErrCode property 801 specifies which one. Furthermore, the replace properties specify 802 whether the traffic profile of the CR-LDP message is changed. 804 NAME mplsPolicyCRLDPSignalCtrlAction 805 DERIVED FROM PolicyAction (defined in [PCIM]) 806 ABSTRACT False 807 PROPERTIES mpCRLDPMessageType, mpSendNotification, 808 mpSendRelease, mpErrCode 809 mpReplacePDR, mpReplacePBS, 810 mpReplaceCDR, mpReplaceCBS, 811 mpReplaceEBS, mpReplaceWeight 813 5.5.1 The Property CRLDPMessageType 815 This property is an enumerated integer and defines different values 816 that limit the scope of the action to be enforced to specific types 817 of CR-LDP Messages. The attribute is defined as follows: 819 NAME CRLDPMessageType 820 SYNTAX Integer (ENUM) - { 821 "LabelMapping"=0; 822 "LabelRequest"=1; 823 "LabelWithdraw"=2; 824 "LabelRelease"=3; 825 "LabelAbortRequest"=4; 826 "Notification"=5; 827 } 829 5.5.2 The Property mpSendNotification 831 This property is an enumerated integer and controls the generation of 832 CR-LDP Notification Message. The attribute is defined as follows: 834 NAME mpSendNotification 835 SYNTAX Integer (ENUM) - {No=0, Yes=1} 837 5.5.3 The Property mpSendRelease 839 This property is an enumerated integer and controls the generation of 840 CR-LDP Release Message. The attribute is defined as follows: 842 NAME mpSendRelease 843 SYNTAX Integer (ENUM) - {No=0, Yes=1} 845 5.5.4 The Property mpErrCode 847 This property specifies the error code in case the mpSendNotification 848 property has the value 1=yes. In the case, the sent notification 849 property is no, this property is undefined. The error codes are the 850 ones specified in LDP and CR-LDP. 852 NAME mpErrCode 853 SYNTAX Integer 855 5.5.5 The Property mpReplacePDR 857 This property is a non-negative integer that replaces the Peak Data 858 Rate value in a CR-LDP message. The attribute is defined as follows: 860 NAME mpReplacePDR 861 SYNTAX Integer (must be non-negative) 863 5.5.6 The Property mpReplacePBS 865 This property is a non-negative integer that replaces the Peak Burst 866 Size value in a CR-LDP message. The attribute is defined as follows: 868 NAME mpReplacePBS 869 SYNTAX Integer (must be non-negative) 871 5.5.7 The Property mpReplaceCDR 873 This property is a non-negative integer that replaces the Committed 874 Data Rate value in a CR-LDP message. The attribute is defined as 875 follows: 877 NAME mpReplaceCDR 878 SYNTAX Integer (must be non-negative) 880 5.5.8 The Property mpReplaceCBS 882 This property is a non-negative integer that replaces the Committed 883 Burst Size value in CR-LDP message. The attribute is defined as 884 follows: 886 NAME mpReplaceCBS 887 SYNTAX Integer (must be non-negative) 889 5.5.9 The Property mpReplaceEBS 891 This property is a non-negative integer that replaces the Excess 892 Burst Size value a in CR-LDP message. The attribute is defined as 893 follows: 895 NAME mpReplaceEBS 896 SYNTAX Integer (must be non-negative) 898 5.5.10 The Property mpReplaceWeight 900 This property is a non-negative integer that replaces the Weight 901 value in a CR-LDP message. The attribute is defined as follows: 903 NAME mpReplaceWeight 904 SYNTAX Integer (must be in the range 0-255) 906 5.6 Class mplsPolicyMPLSPRAction 908 The mplsPolicyMPLSPRAction class specifies the mapping of traffic 909 into a Label Switched Path (LSP). What kind of traffic is mapped is 910 transparent to the action on this level. The mapping is performed in 911 an edge LSR in the case of IP over MPLS or in the core LSRs in the 912 case of MPLS tunneling. Both cases can be specified with this action. 913 However, the condition of the policy rule may differ. Note that the 914 traffic to be mapped is specified in the condition of the policy 915 rule. The traffic specification may be plain IP style, it may contain 916 DSCP values, or it may be given by MPLS labels. The LSP is given as a 917 reference to an LSP object, which specifies an already setup LSP, the 918 traffic should take. Note that we do not need to specify any label 919 stacking operation on this abstraction level. 921 The class is defined as follows: 923 NAME mplsPolicyMPLSPRAction 924 DERIVED FROM PolicyAction (defined in [PCIM]) 925 ABSTRACT False 926 PROPERTIES mplsSetLSP 928 5.6.1 The property mplsSetLSP 930 This property contains a reference to an object, which defines an LSP 931 in the network to which the traffic is mapped. The property is 932 defined as follows: 934 NAME mplsSetLSP 935 SYNTAX Reference to a mplsLSP object 937 5.7 Class mplsPolicyFEC 939 The mplsPolicyFEC class is an abstract class specifying the Forward 940 Equivalence Class of an LSP. The class is abstract in order to be 941 open for different kinds of FECs. The FECs may differ depending on 942 the application of MPLS. 944 NAME mplsPolicyFEC 945 DERIVED FROM Policy (defined in [PCIM]) 946 ABSTRACT True 947 PROPERTIES 949 5.8 Class mplsPolicyFECIP 950 This class defines a FEC based on the IP destination address. The 951 class definition is as follows: 953 NAME mplsPolicyFECIP 954 DERIVED FROM mplsPolicyFEC 955 ABSTRACT False 956 PROPERTIES mpFECType, mpFECValue 958 5.8.1 The Property mpFECType 960 This property is an enumerated integer that defines the type of the 961 FEC. Even if the Wildcard FEC type is used only in the Label Withdraw 962 and Label Release Messages of the LDP specification, we included the 963 type in this property. The wildcard type indicates that the 964 withdraw/release is applied to all FECs associated with the label. 965 The attribute is defined as follows: 967 NAME mpFECType 968 SYNTAX Integer (ENUM) - {Wildcard=1,Prefix=2,HostAddress=3} 970 5.8.2 The Property mpFECValue 972 This property is a set IP addresses that define the FEC of this LSP. 973 The attribute is defined as follows: 975 NAME mpFECValue 976 SYNTAX IPv4Address | IPv6Address | * 978 5.9 Class mplsPolicyFECIPDS 980 The class mplsPolicyFECIPDS is derived from the mplsPolicyFECIP 981 class. It specifies a FEC with IP destination address and DSCP value. 982 This kind of FEC is usually used in the case of mapping from DiffServ 983 traffic specified with IP destination address and DSCP value to an 984 LSP. 986 NAME mplsPolicyFECIPDS 987 DERIVED FROM mplsPolicyFECIP 988 ABSTRACT False 989 PROPERTIES mpDSCP 991 5.9.1 The property mpDSCP 993 The property specifies a DSCP value or a set of DSCP values. 995 NAME mpDSCP 996 SYNTAX Integer | Set of Integer (in the range 0..63, 997 inclusive) 999 5.10 Class mplsPolicyCRLSPTrfcProf 1001 This class represents a CR-LSP traffic parameter as specified in 1002 [CRLDP]. The value of CR-LSP traffic profiles corresponds to the 1003 Traffic Parameter TLV carried in CR-LDP messages. 1005 NAME mplsPolicyCRLSPTrfcProf 1006 DERIVED FROM Policy (defined in [PCIM]) 1007 ABSTRACT False 1008 PROPERTIES mpCRLSPFrequency, mpCRLSPWeight 1009 mpCRLSPPeakDataRate, mpCRLSPPeakBurstSize, 1010 mpCRLSPCommittedDataRate, mpCRLSPCommittedBurstSize, 1011 mpCRLSPExcessBurstSize 1013 5.10.1 The Property mpCRLSPFrequency 1015 This property specifies at what granularity the CDR allocated to the 1016 CR-LSP is made available. 1018 NAME mpCRLSPFrequency 1019 SYNTAXInteger(ENUM)-{"Unspecified"=0;"Frequent"=1;"VeryFrequent"=2} 1021 5.10.2 The Property mpCRLSPWeight 1023 This property represents the CR-LSP's relative share of the possible 1024 excess bandwidth above its committed rate. 1026 NAME mpCRLSPWeight 1027 SYNTAX Integer (must be in the range 0-255) 1029 5.10.3 The Property mpCRLSPPeakDataRate 1031 This property is a non-negative integer that defines the token rate 1032 parameter of peak rate token bucket, measured in byte per second. The 1033 attribute is defined as follows: 1035 NAME mpCRLSPPeakDataRate 1036 SYNTAX Integer (must be non-negative) 1038 5.10.4 The Property mpCRLSPPeakBurstSize 1040 This property is a non-negative integer that defines the token bucket 1041 size parameter of peak rate token bucket, measured in byte. The 1042 attribute is defined as follows: 1044 NAME mpCRLSPPeakBurstSize 1045 SYNTAX Integer (must be non-negative) 1047 5.10.5 The Property mpCRLSPCommittedDataRate 1049 This property is a non-negative integer that defines the token rate 1050 parameter of committed data rate token bucket, measured in byte per 1051 second. The attribute is defined as follows: 1053 NAME mpCRLSPCommittedDataRate 1054 SYNTAX Integer (must be non-negative) 1056 5.10.6 The Property mpCRLSPCommittedBurstSize 1058 This property is a non-negative integer that defines the token bucket 1059 size parameter of committed data rate token bucket, measured in byte. 1060 The attribute is defined as follows: 1062 NAME mpCRLSPCommittedBurstSize 1063 SYNTAX Integer (must be non-negative) 1065 5.10.7 The Property mpCRLSPExcessBurstSize 1067 This property is a non-negative integer that defines the token bucket 1068 size parameter of excess burst size, measured in byte. The attribute 1069 is defined as follows: 1071 NAME mpCRLSPExcessBurstSize 1072 SYNTAX Integer (must be non-negative) 1074 5.11 Class mplsResourceClass 1076 The class defines a resource class, which is defined for the whole 1077 MPLS domain. The resource class is specified abstract in order to 1078 allow different resource classes to be derived. See the next section 1079 for the specification of the CR-LDP specific resource class. The 1080 concept of resource classes is regarded a powerful abstraction from a 1081 traffic engineering perspective [RFC2702]. 1083 NAME mplsResourceClass 1084 DERIVED FROM Policy (defined in [PCIM]) 1085 ABSTRACT True 1087 5.12 Class mplsCRLDPResourceClass 1089 MplsCRLDPResourceClass defines a specific resource class, which is 1090 defined in an MPLS domain using CR-LDP for signaling purposes. The 1091 mpCRLDPRC property contains an integer specifying the resource class 1092 according to the resource class TLV in [CRLDP]. 1094 NAME mplsCRLDPResourceClass 1095 DERIVED FROM mplsResourceClass 1096 ABSTRACT False 1097 PROPERTY mpCRLDPRC 1099 5.12.1 The property mpCRLDPRC 1101 The property defines an integer to represent a resource class. The 1102 integer can be easily mapped to the resource class TLV in CR-LDP. 1104 NAME mpCRLDPRC 1105 SYNTAX Integer (must be non-negative) 1107 6. Examples 1109 This section provides an example that shows how the classes defined 1110 above as part of the QoS information model for MPLS may be used in a 1111 typical policy scenario. For the example scenario we assume an MPLS 1112 network and two hosts (A and B) outside the MPLS domain (see Figure 1113 2). 1115 192.168.100.66 1116 +--------+ 1117 | Host A | +------------------+ 1118 +--------+ / \ 1119 | +---------+ | 1120 \--...--->| Ingress | +--------+ 1121 +---------+ | Egress |--\ 1122 | +--------+ | 1123 \ MPLS domain / | +--------+ 1124 +------------------+ \-...->| Host B | 1125 +--------+ 1126 202.247.5.136 1128 Figure 2: Example MPLS Network 1130 Furthermore, we assume for the scenario that traffic from A to B 1131 should be given a committed data rate of 10Mb/s within the MPLS 1132 domain. A corresponding policy rule could be given for the MPLS 1133 Ingress node: 1135 IF SourceIP=192.168.100.66 AND 1136 DestinationIP=202.247.5.136 1137 THEN 1138 Provide LSP X with profile.committedDataRate=10Mb/s AND 1139 Map traffic to be forwarded along LSP X AND 1140 Shape traffic to 10Mb/s 1142 The policy rule as written in a pseudo policy language above can be 1143 represented in a policy system as a structured object (see Figure 3). 1145 +-------------------------+ 1146 | PolicyRule | 1147 | ConditionListType=CNF | 1148 +-------------------------+ 1149 | | 1150 | | +---------------------------+ 1151 | |-> | qosPolicySimpleCondition | (1a) 1152 | | | SourceIP=192.168.100.66 | 1153 | | +---------------------------+ 1154 | | 1155 | | +-------------------------------+ 1156 | \-> | qosPolicySimpleCondition | (1b) 1157 | | DestinationIP=202.247.5.136 | 1158 | +-------------------------------+ 1159 | 1160 | +----------------------------+ 1161 |-> | mplsPolicyCRLSPResvAction | (2) 1162 | +----------------------------+ 1163 | | 1164 | | +-----------------+ 1165 | \->| mplsPolicyCRLSP |<-------------------------\ 1166 | +-----------------+ | 1167 | | | 1168 | | +-----------------------------------+ | 1169 | \->| mplsPolicyCRLSPTrfcProf | | 1170 | | mpCRLSPCommittedDataRate=10Mb/s | | 1171 | +-----------------------------------+ | 1172 | | 1173 | +-------------------------+ | 1174 |-> | mplsPolicyMPLSPRAction | (3) | 1175 | +-------------------------+ | 1176 | | | 1177 | \-----------------------------------------------/ 1178 | 1179 | +-------------------+ 1180 \-> | qosPolicyPRAction | (4) 1181 +-------------------+ 1182 | 1183 | +---------------------+ 1184 \->| qosPolicyPRTrfcProf | 1185 | qpPRRate=10Mb/s | 1186 +---------------------+ 1188 Figure 3: Representation of the example policy rule 1190 The policy object illustrated in Figure 3 is built from policy 1191 classes defined in CIM, QPIM and this document. The root of the 1192 policy object is a rule object that is associated with two instances 1193 of class qosPolicySimpleCondition (1a and 1b). The condition objects 1194 together specify a traffic filter so that the rule applies only to 1195 traffic from source IP address 192.168.100.66 and destination IP 1196 addresses 202.247.5.136. The rule object is furthermore associated 1197 with a list of instances of class PolicyAction. 1199 The first policy action object (2) is an instance of 1200 mplsPolicyCRLSPResvAction and specifies a CR-LSP reservation with a 1201 CR-LDP Label Request Message. The path is most importantly defined by 1202 a reference to an instance of mplsPolicyCRLSP. Along with other 1203 properties, this LSP instance is described by a traffic profile 1204 object. The profile object is, in this case, an instance of class 1205 mplsPolicyCRLSPTrfcProf that is initialized with a committed data 1206 rate of 10Mb/s. 1208 The second policy action (3) specifies that the traffic characterized 1209 by the policy rule conditions should be mapped to the LSP that has 1210 been reserved by the previous action. This connection may, for 1211 instance, be realized in a DiffServ context with a DSCP value that is 1212 used for traffic that matches the filter defined by the policy rule 1213 condition objects. The same DSCP value can then be used for mapping 1214 the traffic to the reserved LSP. 1216 The third policy action object (4) is an instance of 1217 qosPolicyPRAction that represents a DiffServ action to be applied on 1218 a (group of) flow(s). This may include marking, dropping, policing 1219 and shaping. For the sample policy rule above the traffic profile 1220 property of the qosPolicyPRAction instance describes a traffic 1221 profile that has to be considered when entering the MPLS domain. The 1222 object, thus, represents a shaper with a given rate of 10Mb/s. 1224 The example policy given here illustrates only some aspects of the 1225 potential of policy-based networking for MPLS. For the sake of 1226 brevity, a fairly simple policy rule is chosen here. Also, not all 1227 properties are shown in the object structure representing the example 1228 policy rule. 1230 7. Security Considerations 1232 The security considerations for this document are the same as those 1233 of the [PCIM] and are not further addressed in this version of the 1234 draft. 1236 8. References 1238 [PCIM] B. Moore, E. Ellesson, J. Strassner, "Policy Core Information 1239 Model -- Version 1 Specification", Internet Draft, 1240 work in progress, , 1241 May 2000 1243 [QPIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy 1244 Framework QoS Information Model", Internet draft, 1245 work in progress, , 1246 April 2000 1248 [LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, 1249 "LSP Specification", Internet Draft, work in progress, 1250 , June 2000. 1252 [CRLDP] B. Jamoussi, "Constraint-Based LSP Setup using LDP", 1253 Internet Draft, work in progress, 1254 , March 2000 1256 [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, 1257 V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 1258 work in progress, , 1259 Februar 2000. 1261 [DS-MPLS] F. LeFaucher, L. Wu, B. Davie, S. Davari, P. Vaanenen, 1262 R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 1263 Differentiated Services", Internet Draft, work in progrss, 1264 , June 2000 1266 [MPLS-ARCH] E.Rosen, A.Viswanathan, R.Callon, "Multiprotocol Label 1267 Switching Architecture", Internet Draft, work in progress, 1268 , August 1999. 1270 [MPLS-FW] R.Callon, P.Doolan, N.Feldman, A.Freddette, G.Swallow, 1271 A.Viswanathan, "A Framework for MPLS", Internet Draft, 1272 work in progress, , 1273 September 1999. 1275 [MPLS-ENC] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, 1276 G. Fedorkow, T. Li, A. Conta, "MPLS Label Stack Encoding", 1277 work in progress, , 1278 September 1999. 1280 [REQPMPLS] S. Wright, S. Herzog, F. Reichmayer, R. Jaeger, 1281 "Requirements for Policy Enabled MPLS", work in progress, 1282 , March 2000. 1284 [PBLBMPLS] S. Wright, F. Reichmeyer, R. Jaeger, M. Gibson, 1285 "Policy-Based Load Balancing in Traffic-Engineered MPLS 1286 Networks", Internet Draft, work in progress, 1287 , June 2000. 1289 [POLICY-FW] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, 1290 G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", 1291 work in progress, , 1292 September 1999. 1294 [RFC2702] D. Awduche, J. Malcom, J. Agogbua, M. O'Dell, J. McManus, 1295 "Requirements for Traffic Engineerring over MPLS", RFC 2702, 1296 September 1999. 1298 9. Authors' Addresses 1300 Kazuhiko Isoyama 1301 NEC Corporation 1302 Development Laboratories 1303 1131, Hinode, Abiko, Chiba, 270-1198, JAPAN 1304 Phone: +81 471-85-6738 1305 Fax: +81 471-85-6841 1306 Email: iso@ptl.abk.nec.co.jp 1308 Makiko Yoshida 1309 NEC Corporation 1310 Development Laboratories 1311 1131, Hinode, Abiko, Chiba, 270-1198, JAPAN 1312 Phone: +81 471-85-6738 1313 Fax: +81 471-85-6841 1314 Email: myoshida@ptl.abk.nec.co.jp 1316 Marcus Brunner 1317 NEC Europe Ltd. 1318 C&C Research Laboratories 1319 Adenauerplatz 6 1320 D-69115 Heidelberg, Germany 1321 Phone: +49 (0)6221 905110 1322 Fax: +49 (0)6221 9051155 1323 Email: brunner@ccrle.nec.de 1325 Andreas Kind 1326 NEC Europe Ltd. 1327 C&C Research Laboratories 1328 Adenauerplatz 6 1329 D-69115 Heidelberg, Germany 1330 Phone: +49 (0)6221 905110 1331 Fax: +49 (0)6221 9051155 1333 Email: ak@ccrle.nec.de 1335 Juergen Quittek 1336 NEC Europe Ltd. 1337 C&C Research Laboratories 1338 Adenauerplatz 6 1339 D-69115 Heidelberg, Germany 1340 Phone: +49 (0)6221 905110 1341 Fax: +49 (0)6221 9051155 1343 Email: quittek@ccrle.nec.de