idnits 2.17.1 draft-nguyen-rap-cops-sls-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([AUTHSESSION], [COPS], [SESSION-AUTH], [RAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 () is 739377 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: 'SESSION-AUTH' is mentioned on line 260, but not defined == Missing Reference: 'AUTHSESSION' is mentioned on line 57, but not defined == Missing Reference: 'RFC 3084' is mentioned on line 202, but not defined == Unused Reference: 'SPPI' is defined on line 1402, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 3084 (ref. 'COPS-PR') ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DS-TERM') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'SLS-AQU' == Outdated reference: A later version (-03) exists of draft-tequila-sls-01 -- Possible downref: Normative reference to a draft: ref. 'SLS-TEQ' ** Downref: Normative reference to an Historic RFC: RFC 3159 (ref. 'SPPI') -- Possible downref: Normative reference to a draft: ref. 'COPS-FRWK' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T.M.T. Nguyen 3 Expires January 2003 University of Paris 6 - ENST Paris 4 N. Boukhatem 5 ENST Paris 6 Y. El Mghazli 7 N. Charton 8 Alcatel 9 Louis-Nicolas Hamer 10 Nortel Networks 11 G. Pujolle 12 University of Paris 6 14 July, 1st 2002 16 COPS-PR Usage for SLS negotiation (COPS-SLS) 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026 [RFC-2026]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet- Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Distribution of this memo is unlimited. 40 Abstract 42 This document describes the use of the Common Open Policy Service 43 (COPS) protocol for supporting Service Level Specification (SLS) 44 negotiation (COPS-SLS). The COPS protocol [COPS] has been defined by 45 the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used 46 in this memo to communicate SLS information between customer and 47 provider. COPS-SLS can be used at different interfaces such as 48 vertically between a service provider and a network provider or 49 horizontally between network providers in order to decide if the 50 network guarantees a service level for a traffic stream. This version 51 presents COPS-SLS as a candidate protocol for the interface between 52 the Resource Control Domain (RCD) and the Service Control Domain 53 (SCD), according to [SESSION-AUTH] vocabulary. It enables an SCD to 54 vertically reserve RCD resource for its customers. Once resource has 55 been reserved in the RCD, the media session establishment, together 56 with the horizontal resource reservation, follows the steps described 57 in the [AUTHSESSION] framework. Moreover, the respective PDPs have to 58 verify that all the media streams being accepted lie within the 59 bounds of the resource reserved in the RCD by the SCD. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC-2119]. 67 Table of Contents 69 Glossary........................................................... 2 70 1. Introduction.................................................... 3 71 2. COPS-SLS Model.................................................. 5 72 2.1 Overall model 5 73 2.2 Consistency with the framework for session set-up with media 74 authorization.................................................. 6 75 3. Message Content................................................. 7 76 3.1. Request message (REQ) PEP -> PDP.............................. 7 77 3.2. Decision message (DEC) PDP -> PEP............................. 7 78 3.3. Report State message (RPT) PEP -> PDP......................... 8 79 4. COPS-SLS protocol objects and Client-Specific data format....... 9 80 4.1. COPS-SLS protocol objects..................................... 9 81 4.2. Client-Specific data format................................... 9 82 5. Common Operation and example.................................... 9 83 6. COPS-SLS PIB Module ............................................13 84 7. Security Considerations.........................................29 85 8. IANA Considerations.............................................29 86 9. Acknowledgements................................................29 87 10. References.....................................................29 88 11. Authors' Addresses.............................................30 89 12. Full Copyright Statement.......................................31 91 Glossary 93 ClientSI Client Specific Information. See [COPS] 94 CPERR PRC Class Provisioning Error. See [COPS-PR] 95 EPD Encoded Provisioning Instance. See [COPS-PR] 96 ErrorPRID Error PRID. See [COPS-PR] 97 GPERR Global Provisioning Error Object. See [COPS-PR] 98 ISP Internet Service Provider. 99 PDP Policy Decision Point. See [RAP] 100 PEP Policy Enforcement Point. See [RAP]. 101 PIB Policy Information Base. See [COPS-PR] 102 PPRID Prefix PRID. See [COPS-PR] 103 PRID Provisioning Instance Identifier. See [COPS-PR] 104 RAP Resource Allocation Protocol. See [RAP] 105 SLS Service Level Specification. See [DS-TERM] 107 1. Introduction 109 This document describes the use of the Common Open Policy Service 110 (COPS) protocol [COPS] for supporting Service Level Specification 111 (SLS)negotiation (COPS-SLS). The COPS protocol has been defined 112 by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be 113 used in this memo to communicate the SLS information between a 114 customer and a network provider. 116 COPS-SLS can be used for horizontal as well as vertical negotiations 117 as illustrated in Figure 1. 119 +-------------------+ 120 | Service Provider | 121 +-------------------+ 122 ^ 123 | (vertical negotiation) 124 | 125 v 126 +------------------+ (horizontal +------------------+ 127 | | negotiation) | | 128 ----| Network Provider |<------------->| Network Provider |- 129 | | | | 130 +------------------+ +------------------+ 132 Figure 1 � Vertical and horizontal negotiations 134 In horizontal negotiation, two network providers (or two ISPs) 135 negotiate a service level for a traffic stream entering from one 136 domain to the other. Vertical negotiation takes place between a 137 Service Provider and a Network Provider in order for the traffic 138 stream to be guaranteed with a service level in the network provider 139 domain. 141 In this version, we introduce the use of COPS-SLS between the Service 142 Control Domain and the Resource Control Domain in the framework of 143 session set-up with media authorization [SESSION-AUTH]. The Service 144 Provider corresponds to the Service Control Domain and the Network 145 Provider corresponds to the Resource Control Domain in this 146 framework. COPS-SLS enables an SCD to vertically reserve RCD resource 147 for its customers. Once resource has been reserved in the RCD, the 148 media session establishment, together with the horizontal resource 149 reservation, follow the steps described in the [SESSION-AUTH] 150 framework. Moreover, the respective PDPs have to verify that all the 151 media streams being accepted lie within the bounds of the resource 152 reserved in the RCD by the SCD. 154 Many protocols could be envisaged between the RCD and the SCD. 155 This document proposes the COPS-PR protocol for the following 156 reasons: 158 - Policy-based networking provides interesting architecture concepts 159 for service level management. 161 - By designing a SLS specific PIB (Policy Information Base), no 162 change is needed to the COPS-PR protocol itself. This is a good 163 way of building on the existing technology without having to 164 revisit the protocol every time new information needs to be carried 165 by the protocol. This also provides a faster way for a deployment 166 without going through another cycle of standardization for the 167 protocol. This provides more flexibility and a standard way for the 168 implementations to add value by extending the standardized Policy 169 Control Information. 171 - Separation of Protocol and Policy Control Information. COPS-PR 172 takes the approach of defining a stable, reusable, more widely 173 applicable protocol. With the applicability addressed by the Policy 174 Control Information carried by the COPS-PR protocol. 176 - Provisioning functionality has generally been thought of as static, 177 but within the context of COPS-PR, the degree of dynamic/static is 178 up to the user of the technology. The events handled by COPS-PR can 179 be very dynamic to very static. The degree of dynamic-ness is in 180 itself a policy, and can be controlled with COPS-PR with 181 flexibility in both event detection/reporting frequency and 182 granularity. 184 - Levels of outsourcing details can be as coarse (aggregated) or fine 185 (per micro-flow) as necessary and can be adjusted dynamically when 186 needed. 188 COPS-SLS makes uses of both common models supported by the COPS 189 protocol: Outsourcing model and Configuration (a.k.a. Provisioning) 190 model. 192 During the negotiation phase, the customer requests a service by 193 triggering the PEP function which negotiate the desired SLS with the 194 provider. The decision sent by the PDP addresses the desired SLS sent 195 by the PEP. There is a direct 1:1 correlation between PEP events and 196 PDP decisions. Therefore, the negotiation phase follows the 197 Outsourcing mode as defined in RFC3084, section 1 [RFC 3084]. 199 In order to make the negotiation configurable according to the domain 200 policies, a configuration phase is used in COPS-SLS. The 201 configuration phase follows the COPS Provisioning mode defined in 202 RFC3084, section 1 [RFC 3084]. The domain negotiation policies are 203 provisioned down to the customer. These policies indicate the service 204 offered by a provider, this can be the negotiable parameters, the 205 value constraints of these parameters, the dynamic level of the 206 negotiation, etc. The configuration phase is also useful to provision 207 pre-defined service templates that can be requested as is by the 208 customer in case there is a correspondence with its own needs. 210 [COPS-FRWK] describes in more details how COPS-PR can be utilized in 211 both outsourcing and configuration mode. 213 2. COPS-SLS model 215 2.1 Overall model 217 Policy Client (SCD/RCD) Policy Server (RCD/SCD) 218 +--------------+ +-----------+ 219 | | | | 220 | +-----+ | REQ() | +-----+ | 221 | | SLS |----|--------------|->| SLS | | 222 | | PEP |<---|--------------|--| PDP |--|---------> 223 | +-----+ | DEC() | +-----+ | 224 | | | | 225 +--------------+ +-----------+ 227 Figure 2 - COPS-SLS model 229 As depicted in Figure 2, the SLS Policy Client negotiates with the 230 SLS Policy Server using the COPS protocol. This negotiation process 231 can take place within an administrative domain or between 232 administrative domains. The SLS PEP represents the customer and the 233 SLS PDP represents the network provider. The customer is the entity 234 consuming network resources of a network provider. It may be an 235 enterprise, an Application Service Provider (ASP) or another network 236 provider. 238 When the SLS-PEP module is activated, the PEP connects to its 239 primary SLS-PDP. The SLS-PDP is a server who manages all SLSs of an 240 administrative domain. The SLS-PDP gets to its Policy Repository to 241 retrieve the relevant policies. The SLS policies helps the SLS-PDP to 242 accept or reject the requested SLS. The SLS-PDP MAY also suggest 243 another SLS to be applied to the PEP. 245 Once an SLS-PDP and an SLS-PEP agreed on a service level for a 246 Traffic stream, the SLS-PDP MAY interact with other entities (e.g., a 247 COPS-PR-DiffServ PDP) so that the network resources could be properly 248 provisioned. The interaction between the SLS-PDP and the other 249 entities is outside the scope of this document. 251 2.2 Consistency with the framework for session set-up with media 252 authorization 254 For vertical negotiations, i.e. negotiations between service 255 providers and network providers, the framework defined in [SESSION- 256 AUTH] should be assumed. Basically, the network provider MUST verify 257 with the service provider that the QoS resources requested by a 258 particular user are within the bounds of the authorized session. 260 [SESSION-AUTH] describes 4 different models: the coupled model, the 261 associated model with one policy server, the associated model with 262 two policy servers and the non-associated model. 264 Only the coupled & associated models apply to the original COPS-SLS 265 concept presented since version 00. The SCD can negotiate with the 266 RCD for a number of resources and distribute them to different 267 sessions. When the used resource arrives at a threshold, the SCD 268 renegotiates with the RCD to get more resources. The SCD can 269 dynamically negotiate resources with the RCD for each session. The 270 non-associated model does not require a negotiation between service 271 and network providers. 273 In the coupled & associated model with one policy server, the service 274 provider acts as the SLS PEP since it is consuming network resources 275 controlled by the SLS PDP. However, in the associated model with two 276 policy servers, the roles are reversed. In fact, since the service 277 provider does not have an a priori relationship with the network 278 provider, the negotiation process cannot be triggered. Instead, the 279 service provider will send an authorization token, providing his 280 identity, back to the end host. The end host relays this 281 authorization token to the network provider in his resource request. 282 The network provider can then establish communication with the 283 identified service provider in the authorization token. Since the 284 network provider requests session authorization information from the 285 service provider, the network provider acts as a PEP, while the 286 service provider acts as a PDP. Although the service provider is 287 still consuming resources from the resource provider, the latter is 288 the initiator (or client) of the exchange, and the former acts as the 289 server by providing detailed information about the authorized 290 session. 292 3. Message Content 294 This section presents the content of the Request, Decision and Report 295 messages. In this version, we only use the Named ClientSI object 296 defined in COPS-PR to convey information exchanged between the PEP 297 and the PDP both in Provisioning mode (Configuration phase) and in 298 Outsourcing mode (Negotiation phase). The Context Object 299 distinguishes the two phases: Configuration and Negotiation. 301 3.1. Request message (REQ) PEP -> PDP 303 The REQ message is sent by the SLS-PEP to the SLS-PDP with the 304 following format: 306 ::= 307 308 309 *( 310 [] 312 Note that *() means zero or more (s). The COPS 313 objects IN-Int, OUT-Int and LPDPDecisions are not included in a COPS- 314 SLS Request. 316 The Context object specifies the context of the message. A 'context = 317 configuration request' specifies a request in the Configuration 318 phase. A 'Context = resource allocation request' specifies a request 319 in the Negotiation phase. 321 The Named ClientSI object is included in the REQ message to convey 322 negotiation's information under PIB classes' instances. In the 323 Configuration phase, this object is used to inform the PDP about the 324 PEP negotiation capabilities and all predefined SLS available in the 325 PEP. In the Negotiation phase, this object is used to transport the 326 SLS requested by the PEP. 328 3.2. Decision message (DEC) PDP -> PEP 330 The DEC message is sent by the SLS-PDP to the SLS-PEP with the 331 following format: 333 ::= 334 335 *() | 336 [] 338 ::= 339 340 *() 342 A solicited DEC message is sent from the PDP to answer a REQ message 343 sent by the PEP. Unsolicited DEC messages may be sent by the PDP to 344 transport the updated policy information. The Client-Handle value 345 identifies the request to which the PDP wants to send a decision. The 346 Context object specifies the context of the decision ('configuration' 347 or 'resource-allocation'). 349 The Named Decision Data object is included in the DEC message to 350 convey the PIB class instances in the decision. In the Configuration 351 phase, this object is used to transport the negotiation configuration 352 (e.g., negotiation mode, predefined SLSs, ...) which the PDP wants to 353 install/remove in/from the PEP. The action 'install' or 'remove' is 354 specified in the Decision Flags object. In the Negotiation phase, 355 this object is used when the PDP suggests another SLS. The Decision 356 Flags object will specify the action of 'install' in this case. 358 For the decisions which simply accept or reject the SLS indicated in 359 the REQ message without proposing another service level, the action 360 'install' or 'remove' in the Decision Flags object is sufficient. No 361 Named Decision Data Object is included in the DEC message to convey 362 the SLS proposal. 364 3.3. Report State message (RPT) PEP -> PDP 366 The RPT message is sent by the SLS-PEP to the SLS-PDP with the 367 following format: 369 ::= 370 371 372 *() 373 [] 375 A solicited RPT message MUST be sent by the PEP upon receipt of a DEC 376 message from the PDP. The Client-Handle object contains the same 377 value as the Client-Handle value in the DEC message to which the PEP 378 wants to make a report. 380 The Report-Type object is used to specify the action (success/fail) 381 taken by the PEP. The Named ClientSI objects are eventually included 382 in the RPT message to transport error/accounting information. 384 4. COPS-SLS protocol objects and Client-Specific data formats 386 4.1 COPS-SLS protocol objects 388 The COPS-SLS protocol objects follow the same object formats defined 389 in [COPS-PR]. More precisely, six objects (PRID object, PPRID object, 390 EPD object, GPERR object, CPERR object and ErrorPRID object) are 391 defined in section 4 of [COPS-PR]. 393 4.2 Client-Specific data format 395 The Named ClientSI object used in the REQ message have the same 396 format as the ClientSI Request Data defined in section 5.2 of [COPS- 397 PR]. 399 The Named Decision Data object used in the DEC have the same format 400 as the Named Decision Data defined in section 5.1 of [COPS-PR]. 402 The Named ClientSI object used in the RPT message has the same format 403 as the Policy Provisioning Report Data defined in section 5.3 of 404 [COPS-PR]. In the case of a 'Failure' Report-Type due to the reject 405 of the PDP suggested SLS, the PEP MUST send a report indicating 406 'slsNonAccepted' using slsNegoRptEntry PRC. 408 5. Common Operation and example 410 To illustrate the operation of COPS-SLS, an example of COPS-SLS is 411 shown in Figure 3. 413 COPS-SLS-PEP COPS-SLS-PDP 414 | | 415 | | 416 |--------------------------------------------------->|(step 1) 417 | OPN : | 418 | Common Header : | 419 | Client-type = COPS-SLS (tbd) | 420 | PEPID : | 421 | PEPID = PEP_1 | 422 | | 423 |<---------------------------------------------------|(step 2) 424 | CAT : | 425 | Common Header : | 426 | Client-type = COPS-SLS | 427 | KA Timer : | 428 | KATimer = 50 | 429 | | 430 |--------------------------------------------------->|(step 3) 431 | REQ : | 432 | Common Header : | 433 | Client-type = COPS-SLS | 434 | Client-Handle : | 435 | Handle = config_req_A | 436 | Context : | 437 | R-Type = 0x08 (Configuration request) | 438 | Named ClientSI : | 439 | frwkPrcCapsTable | 440 | slsNegoCapsTable | 441 | slsSlsTable | 442 | | 443 |<---------------------------------------------------|(step 4) 444 | DEC : | 445 | Common Header : | 446 | Flags = 0x1 (solicited message) | 447 | Client-type = COPS-SLS | 448 | Client-Handle : | 449 | Handle = config_req_A | 450 | Context : | 451 | R-Type = 0x08 (configuration) | 452 | Decision : | 453 | Decision Flag : | 454 | Command Code = Install | 455 | Named Decision Data : | 456 | slsNegoTable | 457 | (slsNegoMode = predefined SLSs | 458 | slsNegoMaxInt = 120) | 459 | slsSlsTable | 460 | | 461 |--------------------------------------------------->|(step 5) 462 | RPT : | 463 | Common Header: | 464 | Flags = 0x1 (solicited message) | 465 | Client-Type = COPS-SLS | 466 | Client-Handle : | 467 | Handle = config_req_A | 468 | Report-Type : | 469 | Report-type = Success | 470 | | 471 |--------------------------------------------------->|(step 6) 472 | REQ : | 473 | Common Header : | 474 | Flags = 0 | 475 | Client-Type = COPS-SLS | 476 | Client-Handle : | 477 | Handle = res_req_B | 478 | Context : | 479 | R-Type = 0x02 (Resource-Allocation request) | 480 | Named ClientSI : | 481 | slsSlsTable | 482 | | 483 |<---------------------------------------------------|(step 7) 484 | DEC : | 485 | Common Header : | 486 | Flags = 0x01 (solicited message) | 487 | Client-Type = COPS-SLS | 488 | Client-Handle : | 489 | Handle = res_req_B | 490 | Context : | 491 | R-Type = 0x02 (Resource-Allocation) | 492 | Decision Flags: | 493 | Commande Code = install | 494 | | 495 |--------------------------------------------------->|(step 8) 496 | RPT : | 497 | Common Header : | 498 | Flags = 0x01 (solicited massage) | 499 | Client-Type = COPS-SLS | 500 | Client-Handle : | 501 | Handle = res_req_B | 502 | Report-Type : | 503 | Report-Type = Success | 505 Figure 3 - Example of COPS-SLS operation 507 The next section describes the Common Operation on the COPS-SLS 508 connection between the PEP and the PDP. 510 When the SLS-PEP module is activated, the PEP connects to its 511 primary SLS-PDP and sends the OPN message with a Client-Type=COPS- 512 SLS (Figure 3 - step 1). 514 If the PDP accepts this PEP, it sends to the PEP a CAT message 515 (Figure 3 - step 2). Otherwise, it sends a CC message. 517 When the COPS-SLS connection is successfully established, the PEP 518 sends the first REQ with a Context='configuration request'. The 519 Named ClientSI object is used in this request to inform the PDP about 520 the capabilities of the PEP (e.g, the PRCs the PEP understands, the 521 negotiation mode the PEP supports, ...) and all existing predefined 522 SLSs (Figure 3 - step 3). 524 Predefined SLS is defined in [SLS-AQU] as an SLS with predefined 525 values (or a range of values) for a subset of the parameters in the 526 generic SLS. 528 In predefined SLS mode, the PDP installs all predefined SLS in 529 the PEP. The PEP CAN only request an SLS conforming to one of 530 these predefined SLSs. The PEP MUST NOT request an SLS outside these 531 predefined SLSs. 533 In the non-predefined SLS mode, the PEP CAN request an SLS with any 534 parameter values. 536 Upon receipt of the REQ message, the PDP sends a solicited DEC 537 message with a Context='configuration' and installs the configuration 538 information at the PEP (Figure 3 - step 4). 540 After receiving the DEC message, the PEP installs the configuration 541 sent by the PDP and sends a RPT message to the PDP to report the 542 installation result (Figure 3 - step 5). 544 If the configuration is successfully installed, the PEP CAN now send 545 a REQ message with a Context='resource-allocation' to request the 546 desired SLS (Figure 3 - step 6). 548 In response to the REQ message, the PDP sends a DEC message with the 549 same context (i.e., resource-allocation). The PDP can accept the 550 requested SLS, or reject the requested SLS, or suggest another SLS. 551 To accept the requested SLS, the PDP sends a DEC message with a 552 Decision-Flags='Install' (Figure 3 - step 7). To reject the requested 553 SLS, the PDP sends a DEC message with a Decision-Flags='Remove'. To 554 suggest another SLS, the PDP sends a DEC message with a Decision- 555 Flags='install' and includes the suggested SLS in the Named Decision 556 Data object. 558 If the PEP receives a DEC message accepting/rejecting the requested 559 SLS, it installs the decision and sends a 'success' report to the PDP 560 (Figure 3 - step 8). If the PEP cannot install the decision, 561 it sends a 'failure' report to the PDP including the corresponding 562 Error object. If the PEP receives a DEC message suggesting another 563 SLS, it can accept the suggestion by sending a RPT message with a 564 Report-Type=Success or reject the suggested SLS by sending a RPT 565 message with a Report-Type=Failure and an instance of the PRC 566 SlsNegoRptEntry with a 'slsNegoRptFailRea = 1'. 568 If the PEP wants to modify some parameters of a negotiated SLS, it 569 sends a REQ message using the Client-Handle value identifying the SLS 570 and includes in the Named ClientSI object the SLS with its new 571 parameter values. 573 To delete a requested SLS, the PEP sends a DRQ message using the 574 Client-Handle value identifying the SLS to be deleted. 576 At any time, the PDP CAN send an unsolicited DEC message to supply 577 the PEP with the updated policy information or to degrade some 578 negotiated SLSs. 580 If the PEP receives a SSQ message, it reissues all requested SLSs and 581 finishes the synchronization period by the SSC message. 583 6. COPS-SLS PIB Module 585 This section defines the PIB used in COPS-SLS client-type. This PIB 586 defines the SLS parameters necessary for horizontal negotiation. The 587 SLS parameters are organized similarly to [SLS-TEQ] in six groups: 588 scope, flowId, traffic conformance, excess treatment, performance and 589 service schedule. More classes or attributes useful to vertical 590 negotiation will be added in further versions. 592 SLS-NEGOTIATION-PIB PIB-DEFINITIONS ::= BEGIN 594 IMPORTS 595 Unsigned32, InstanceId, MODULE-IDENTITY, OBJECT-TYPE 596 FROM COPS-PR-SPPI 597 ZerroDotZero 598 FROM SNMPv2-SMI [SMIv2] 599 ExtUTCTime 600 FROM SNMPv2-SMI 601 InetAddressType, InetAddress, InetAddressPrefixLength, 602 InetPortNumber 603 FROM INET-ADDRESS-MIB [INET-ADDR] 604 DscpOrAny 605 FROM DIFFSERV-DSCP-TC 607 slsPolicyPib MODULE-IDENTITY 608 SUBJECT-CATEGORIES { tbd - COPS-SLS Client Type } 609 LAST-UPDATED "200202281200Z" 610 ORGANIZATION "Alcatel, ENST Paris and University of Paris 6" 611 CONTACT-INFO " 612 Thi Mai Trang Nguyen 613 INFRES-ENST 614 46 Rue Barrault 615 75013 Paris - France 616 Phone: +33 1 45 81 74 61 617 Email: trnguyen@enst.fr 619 Nadia Boukhatem 620 INFRES-ENST 621 46 Rue Barrault 622 75013 Paris - France 623 Phone: +33 1 45 81 82 16 624 Email: Nadia.BouKhatem@enst.fr 626 Yacine El Mghazli 627 Alcatel R&I 628 Route de Nozay 629 F-91460 Marcoussis - FRANCE 630 Phone: +33 1 69 63 41 87 631 Email: yacine.el_mghazli@alcatel.fr 633 Nathalie Charton 634 Alcatel R&I 635 Route de Nozay 636 F-91460 Marcoussis - FRANCE 637 Phone: +33 1 69 63 14 85 638 Email: Nathalie.Charton@ms.alcatel.fr 640 Guy Pujolle 641 RP-LIP6-UPMC 642 8 Rue du Capitaine Scott 643 75015 Paris - France 644 Phone: +33 1 44 27 75 14 645 Email: Guy.Pujolle@lip6.fr" 646 DESCRIPTION 647 "The PIB module contains a set of classes 648 describing the policies in SLS negotiation" 649 ::= { tbd } 651 slsCapabilityClasses OBJECT IDENTIFIER ::= { slsPolicyPib 1 } 652 slsPolicyClasses OBJECT IDENTIFIER ::= { slsPolicyPib 2 } 653 slsParamClasses OBJECT IDENTIFIER ::= { slsPolicyPib 3 } 654 slsReportClasses OBJECT IDENTIFIER ::= { slsPolicyPib 4} 656 slsNegoCapsTable OBJECT-TYPE 657 SYNTAX SEQUENCE OF SlsCapsEntry 658 PIB-ACCESS notify 659 STATUS current 660 DESCRIPTION 661 "SLS negotiation capabilities supported by the client" 662 ::= { slsCapabilityClasses 1} 664 slsNegoCapsEntry OBJECT-TYPE 665 SYNTAX SlsNegoCapsEntry 666 STATUS current 667 DESCRIPTION 668 "An instance of this class describes the SLS negotiation 669 capabilities of a client" 670 ::= { slsNegoCapsTable 1 } 671 PIB-INDEX { slsNegoCapsPrid } 673 SlsNegoCapsEntry ::= SEQUENCE { 674 slsNegoCapsPrid InstanceId 675 slsNegoCapsNegoMode BITS 676 slsNegoCapsNegoInt Unsigned32 677 slsNegoCapsMaxPredefSls Unsigned32 678 } 680 slsNegoCapsPrid OBJECT-TYPE 681 SYNTAX InstanceId 682 STATUS current 683 DESCRIPTION 684 "An arbitrary integer index that uniquely identifies an 685 instance of the class" 686 ::= { slsNegoCapsEntry 1 } 688 slsNegoCapsNegoMode OBJECT-TYPE 689 SYNTAX BITS { 690 predefSls(1) 691 -- the ability to support predefined SLS mode 692 non-predefinedSls (2) 693 -- the ability to support non-predefined SLS mode" 694 } 695 STATUS current 696 DESCRIPTION 697 "The SLS negotiation mode supported by the PEP 698 (1) - predefined SLS mode 699 (2) - non-predefined SLS mode" 700 ::= { slsNegoCapsEntry 2 } 702 slsNegoCapsNegoInt OBJECT-TYPE 703 SYNTAX Unsigned32 704 STATUS current 705 DESCRIPTION 706 "The desired interval before which the client could 707 send another REQ message to modify a 708 negotiated SLS" 709 ::= { slsNegoCapsEntry 3 } 711 slsNegoCapsMaxPredefSls OBJECT-TYPE 712 SYNTAX Unsigned32 713 STATUS current 714 DESCRIPTION 715 "The maximum number of predefined SLSs that the PDP can 716 install at the client device. If the client does not 717 support the predefined SLS negotiation mode, this value 718 MUST be 0" 720 ::= { slsNegoCapsEntry 4 } 722 slsNegoTable OBJECT-TYPE 723 SYNTAX SEQUENCE OF SlsNegoEntry 724 PIB-ACCESS install 725 STATUS current 726 DESCRIPTION 727 "SLS negotiation policies to be installed by the PDP" 728 ::= { slsPolicyClasses 1 } 730 slsNegoEntry OBJECT-TYPE 731 SYNTAX SlsNegoEntry 732 STATUS current 733 DESCRIPTION 734 "An instance of this class describes the policies about 735 SLS negotiation that the PDP installs at the PEP" 737 PIB-INDEX { slsNegoPrid } 738 ::= { slsNegoTable 1 } 740 SlsNegoEntry ::= SEQUENCE { 741 slsNegoPrid InstanceId 742 slsNegoMode BITS 743 slsNegoMaxInt Unsigned32 744 } 746 slsNegoPrid OBJECT-TYPE 747 SYNTAX InstanceId 748 STATUS current 749 DESCRIPTION 750 "An arbitrary integer index that uniquely identifies an 751 instance of the class" 752 ::= { slsNegoEntry 1 } 754 slsNegoMode OBJECT-TYPE 755 SYNTAX BITS{ 756 predefSls(1) 757 -- predefined SLS mode 758 non-predefinedSls (2) 759 -- non-predefined SLS mode" 760 } 761 STATUS current 762 DESCRIPTION 763 "The negotiation mode used by the client. 764 1 - indicates the predefined SLS mode. 765 2 - indicates the non-predefined SLS mode" 766 ::= { slsNegoEntry 2 } 768 slsNegoMaxInt OBJECT-TYPE 769 SYNTAX Unsigned32 770 STATUS current 771 DESCRIPTION 772 "The maximum interval during which the client cannot issue 773 a REQ message to change a negotiated SLS" 774 ::= { slsNegoEntry 3 } 776 slsSlsTable OBJECT-TYPE 777 SYNTAX SEQUENCE OF slsSlsEntry 778 PIB-ACCESS install-notify 779 STATUS current 780 DESCRIPTION 781 "Represent an SLS" 782 ::= { slsPolicyClasses 2 } 784 slsSlsEntry OBJECT-TYPE 785 SYNTAX SEQUENCE OF SlsSlsEntry 786 STATUS current 787 DESCRIPTION 788 "An instance of this class specifies an SLS" 789 ::= { slsSlsTable 1 } 791 SlsSlsEntry ::= SEQUENCE { 792 slsSlsPrid InstanceId 793 slsSlsScope Prid 794 slsSlsFlowId Prid 795 slsSlsTrafficConformance Prid 796 slsSlsExcessTreatment Prid 797 slsSlsPerformance Prid 798 slsSlsServiceSchedule Prid 799 } 801 slsSlsPrid OBJECT-TYPE 802 SYNTAX InstanceId 803 STATUS current 804 DESCRIPTION 805 "An arbitrary integer that uniquely identifies an instance 806 of the class" 807 ::= { slsSlsEntry 1} 809 slsSlsScope OBJECT-TYPE 810 SYNTAX Prid 811 STATUS current 812 DESCRIPTION 813 " This attribute uniquely indicates where the QoS policy 814 for that specific service is to be enforced. The value 815 must point to a valid instance of one of these classes: 816 slsScopeParamEntry 817 ::= { slsSlsEntry 2 } 819 slsSlsFlowId OBJECT-TYPE 820 SYNTAX Prid 821 STATUS current 822 DESCRIPTION 823 " This attribute specifies the identification of a flow. It 824 indentifies a stream of IP packets sharing at least one 825 common characteristic. The value must point to a valid 826 instance of one of these classes: 827 slsFlowIdParamEntry" 828 ::= { slsSlsEntry 3 } 830 slsSlsTrafficConformance OBJECT-TYPE 831 SYNTAX Prid 832 STATUS current 833 DESCRIPTION 834 " This attribute specifies the traffic conformance of the 835 flow identified in slsSlsFlowId. The traffic conformance 836 parameters describes how the packet stream should look 837 like to get the guarantees indicated by the perfomance 838 parameters. The value must point to 839 a valid instance of one of these classes: 840 slsConformParamEntry" 841 ::= { slsSlsEntry 4 } 843 slsSlsExcessTreatment OBJECT-TYPE 844 SYNTAX Prid 845 STATUS current 846 DESCRIPTION 847 "This attribute specifies the excess treatment applied to 848 the flow identified by slsSlsFlowId if it does not conform 849 to parameters specified in slsSlsTrafficConformance. 850 Excess traffic may be dropped, shaped and/or remarked. 851 The value must point to a valid instance of one of these 852 classes: 853 slsExcTreatParamEntry" 854 ::= { slsSlsEntry 5 } 856 slsSlsPerformance OBJECT-TYPE 857 SYNTAX Prid 858 STATUS current 859 DESCRIPTION 860 "This attribute specifies the performance guarantees the 861 network offers to the customer for the flow identified by 862 slsSlsFlowId. The value must point to an instance of one of 863 these classes: 864 slsPerformanceParamEntry " 865 ::= { slsSlsEntry 6 } 867 slsSlsServiceSchedule OBJECT-TYPE 868 SYNTAX Prid 869 STATUS current 870 DESCRIPTION 871 " This attribute indicates the start time and end time of 872 the service, i.e. when the service is available. The value 873 must point to an valid instance of one of these classes: 874 slsScheduleParamEntry 875 zeroDotZero (non specified)" 876 ::= { slsSlsEntry 7 } 878 slsScopeParamTable OBJECT-TYPE 879 SYNTAX SEQUENCE OF slsScopeParamEntry 880 PIB-ACESS install-notify 881 STATUS current 882 DESCRIPTION 883 "This class specifies the scope parameters" 884 ::= { slsParamClasses 1} 886 slsScopeParamEntry OBJECT-TYPE 887 SYNTAX SlsScopeParamEntry 888 STATUS current 889 DESCRIPTION 890 "This PRC uniquely identifies the geographical/topological 891 region over which the QoS is to be enforced by indicating 892 the boundaries of that region." 893 ::= { slsScopeParamTable 1 } 895 slsScopeParamEntry ::= SEQUENCE { 896 SlsScopeParamPrid Prid 897 slsScopeParamId TagReferenceId 898 } 900 slsScopeParamPrid OBJECT-TYPE 901 SYNTAX InstanceId 902 STATUS current 903 DESCRIPTION 904 "An arbitrary integer index that uniquely identifies an 905 instance of the class." 906 ::= { slsScopeParamEntry 1 } 908 slsScopeParamId OBJECT-TYPE 909 SYNTAX TagReferenceId 910 PIB-TAG {slsScopeIfParamId} 911 STATUS current 912 DESCRIPTION 913 "Identifies an SLS Scope." 914 ::= { slsScopeParamEntry 2 } 916 slsScopeIfParamTable OBJECT-TYPE 917 SYNTAX SEQUENCE OF slsScopeInterfaceParamEntry 918 PIB-ACCESS install-notify 919 STATUS current 920 DESCRIPTION 921 "The entry points (interfaces) of the IP packets relative 922 to the region (network)." 923 ::= { slsParamClasses 2 } 925 slsScopeIfParamEntry OBJECT-TYPE 926 SYNTAX SlsScopeIfParamEntry 927 STATUS current 928 DESCRIPTION 929 An entry in the scope interface table describes a single 930 interface of the scope. 931 ::= { slsScopeIfParamTable 1 } 933 slsScopeIfParamEntry ::= SEQUENCE { 934 SlsScopeIfParamPrid Prid 935 slsScopeIfParamId TagId 936 slsScopeIfParamIfIndex InterfaceIndex 937 slsScopeIfParamDirection BITS 938 } 940 slsScopeIfParamPrid OBJECT-TYPE 941 SYNTAX Prid 942 STATUS current 943 DESCRIPTION 944 "An arbitrary integer index that uniquely identifies an 945 instance of the class." 946 ::= { slsScopeIfParamEntry 1 } 948 slsScopeIfParamId OBJECT-TYPE 949 SYNTAX TagId 950 STATUS current 951 DESCRIPTION 952 "An SLS Scope is composed of one or more entry/exit 953 points. Each interface belonging to the same scope uses the 954 same Scope ID. Hence, A scope Id identifies which scope 955 this interface is a part of. This needs to be the value of 956 slsScopeParamId attribute for an existing instance of 957 slsScopeParamEntry." 958 ::= { slsScopeIfParamEntry 2 } 960 slsScopeIfParamIfIndex OBJECT-TYPE 961 SYNTAX InterfaceIndex 962 STATUS current 963 DESCRIPTION 964 " This value contains the interface index of the entry/exit 965 interface." 966 ::= { slsScopeIfParamEntry 3 } 968 slsScopeIfParamDirection OBJECT-TYPE 969 SYNTAX BITS{ 970 ingress (0) 971 egress (1) 972 } 973 STATUS current 974 DESCRIPTION 975 " This attribute specifies whether the interface is an 976 entry point (ingress) or an exit point (egress) of the SLS 977 scope." 978 ::= { slsScopeIfParamEntry 4 } 980 slsFlowIdParamTable OBJECT-TYPE 981 SYNTAX SEQUENCE OF slsFlowIdParamEntry 982 PIB-ACCESS install-notify 983 STATUS current 984 DESCRIPTION 985 "This class specifies parameters identifying a traffic 986 stream" 987 ::= { slsParamClasses 3 } 989 slsFlowIdParamEntry OBJECT-TYPE 990 SYNTAX SlsFlowIdParamEntry 991 STATUS current 992 DESCRIPTION 993 "The instance of this class identifies a traffic stream" 994 ::= { slsFlowIdParamTable 1 } 996 SlsFlowIdParamEntry ::= SEQUENCE{ 997 slsFlowIdParamPrid InstanceId 998 slsFlowIdParamAddrType InetAddressType, 999 slsFlowIdParamDstAddr InetAddress, 1000 slsFlowIdParamDstPrefixLength InetAddressPrefixLength 1001 slsFlowIdParamSrcAddr InetAddress, 1002 slsFlowIdParamSrcPrefixLength InetAddressPrefixLength, 1003 slsFlowIdParamDscp DscpOrAny, 1004 slsFlowIdParamFlowLable Unsigned32, 1005 slsFlowIdParamProtocol Integer32, 1006 slsFlowIdParamDstL4PortMin InetPortNumber, 1007 slsFlowIdParamDstL4PortMax InetPortNumber, 1008 slsFlowIdParamSrcL4PortMin InetPortNumber, 1009 slsFlowIdParamSrcL4PortMax InetPortNumber 1010 } 1012 slsFlowIdParamPrid OBJECT-TYPE 1013 SYNTAX InstanceId 1014 STATUS current 1015 DESCRIPTION 1016 "An arbitrary integer index that uniquely identifies an 1017 instance of the class" 1018 ::= { slsFlowIdParamEntry 1 } 1020 slsFlowIdParamAddrType OBJECT-TYPE 1021 SYNTAX InetAddressType 1022 STATUS current 1023 DESCRIPTION 1024 "Specify the type of packet's IP address." 1025 ::= { slsFlowIdParamEntry 2 } 1027 slsFlowIdParamDstAddr OBJECT-TYPE 1028 SYNTAX InetAddress 1029 STATUS current 1030 DESCRIPTION 1031 "The IP address of the packet's destination." 1032 ::= { slsFlowIdParamEntry 3 } 1034 slsFlowIdParamDstPrefixLength OBJECT-TYPE 1035 SYNTAX InetAddressPrefixLength 1036 STATUS current 1037 DESCRIPTION 1038 "The length of a mask for the matching of the destination 1039 IP address. The value of 0 indicates that the address 1040 always matches." 1041 ::= { slsFlowIdParamEntry 4 } 1043 slsFlowIdParamSrcAddr OBJECT-TYPE 1044 SYNTAX InetAddress 1045 STATUS current 1046 DESCRIPTION 1047 "The IP address of the packet's source." 1048 ::= { slsFlowIdParamEntry 5 } 1050 slsFlowIdParamSrcPrefixLength OBJECT-TYPE 1051 SYNTAX InetAddressPrefixLength 1052 STATUS current 1053 DESCRIPTION 1054 "The length of a mask for the matching of the destination 1055 IP address. A value of 0 indicates that the address always 1056 matches." 1057 ::= { slsFlowIdParamEntry 6 } 1059 slsFlowIdParamDscp OBJECT-TYPE 1060 SYNTAX DscpOrAny 1061 STATUS current 1062 DESCRIPTION 1063 "The DSCP value of the packet. A value of 1 indicates that 1064 DSCP value has not been defined." 1065 ::= { slsFlowIdParamEntry 7 } 1067 slsFlowIdParamFlowLable OBJECT-TYPE 1068 SYNTAX Unsigned32 1069 STATUS current 1070 DESCRIPTION 1071 "The value of the Flow Label field in IPv6 header." 1072 ::= { slsFlowIdParamEntry 8 } 1074 slsFlowIdParamProtocol OBJECT-TYPE 1075 SYNTAX Integer32 1076 STATUS current 1077 DESCRIPTION 1078 "The value of the Protocol field in IP header." 1079 ::= { slsFlowIdParamEntry 9 } 1081 slsFlowIdParamDstL4PortMin OBJECT-TYPE 1082 SYNTAX InetPortNumber 1083 STATUS current 1084 DESCRIPTION 1085 "The minimum value that the packet's layer 4 destination 1086 port number can have." 1087 ::= { slsFlowIdParamEntry 10 } 1089 slsFlowIdParamDstL4PortMax OBJECT-TYPE 1090 SYNTAX InetPortNumber 1091 STATUS current 1092 DESCRIPTION 1093 "The maximum value that the packet's layer 4 destination 1094 port number can have." 1095 ::= { slsFlowIdParamEntry 11 } 1097 slsFlowIdParamSrcL4PortMin OBJECT-TYPE 1098 SYNTAX InetPortNumber 1099 STATUS current 1100 DESCRIPTION 1101 "The minimum value that the packet's layer 4 source port 1102 number can have." 1103 ::= { slsFlowIdParamEntry 12 } 1105 slsFlowIdParamSrcL4PortMax OBJECT-TYPE 1106 SYNTAX InetPortNumber 1107 STATUS current 1108 DESCRIPTION 1109 "The minimum value that the packet's layer 4 source port 1110 number can have." 1111 ::= { slsFlowIdParamEntry 13 } 1113 slsConformParamTable OBJECT-TYPE 1114 SYNTAX SEQUENCE OF slsConformParamEntry 1115 PIB-ACCESS install-notify 1116 STATUS current 1117 DESCRIPTION 1118 "This class defines the traffic conformance of a traffic 1119 stream." 1120 ::= { slsParamClasses 4 } 1122 slsConformParamEntry OBJECT-TYPE 1123 SYNTAX SlsConformParamEntry 1124 STATUS current 1125 DESCRIPTION 1126 "The instance of this class specifies algorithm and profile 1127 to verify the conformance of a traffic stream" 1128 ::= { slsConformParamTable 1 } 1130 SlsConformParamEntry ::= SEQUENCE { 1131 slsConformParamPrid InstanceId 1132 slsConformParamAlgo Unsigned32 1133 slsConformParamRate Unsigned32 1134 slsConformParamBurstSize Unsigned32 1135 } 1137 slsConformPrid OBJECT-TYPE 1138 SYNTAX InstanceId 1139 STATUS current 1140 DESCRIPTION 1141 "An arbitrary integer that uniquely identifies an instance 1142 of the class." 1143 ::= { slsConformParamEntry 1 } 1145 slsConformParamAlgo OBJECT-TYPE 1146 SYNTAX Unsigned32 1147 STATUS current 1148 DESCRIPTION 1149 "Specify the algorithm used to verify the conformance of 1150 the traffic stream. 1151 1 - Simple Token Bucket" 1152 ::= { slsConformParamEntry 2 } 1154 slsConformParamRate OBJECT-TYPE 1155 SYNTAX Unsigned32 1156 STATUS current 1157 DESCRIPTION 1158 "The rate value used in Simple Token Bucket algorithm." 1159 ::= { slsConformParamEntry 3 } 1161 slsConformParamBurstSize OBJECT-TYPE 1162 SYNTAX Unsigned32 1163 STATUS current 1164 DESCRIPTION 1165 "The burst size value used in Simple Token Bucket 1166 algorithm." 1167 ::= { slsConformParamEntry 4 } 1169 slsExcTreatParamTable OBJECT-TYPE 1170 SYNTAX SEQUENCE OF slsExcTreatParamEntry 1171 PIB-ACCESS install-notify 1172 STATUS current 1173 DESCRIPTION 1174 "This class specifies parameters of schedule of service" 1175 ::= { slsParamClasses 5 } 1177 slsExcTreatParamEntry OBJECT-TYPE 1178 SYNTAX SlsExctreatParamEntry 1179 STATUS current 1180 DESCRIPTION 1181 "The instance of this class identifies a traffic stream" 1182 ::= { slsExcTreatParamTable 1 } 1184 SlsExcTreatParamEntry ::= SEQUENCE { 1185 slsExcTreatParamPrid InstanceId 1186 slsExcTreatParamAction BITS 1187 } 1189 slsExcTreatParamPrid OBJECT-TYPE 1190 SYNTAX InstanceId 1191 STATUS current 1192 DESCRIPTION 1193 "An arbitrary integer that uniquely identifies an instance 1194 of the class." 1195 ::= { slsExcTreatParamEntry 1 } 1197 slsExcTreatParamAction OBJECT-TYPE 1198 SYNTAX BITS{ 1199 shapping(1) 1200 -- traffic exceeding the conformance parameters 1201 negotiated will be shaped. 1202 dropping (2) 1203 -- traffic exceeding the conformance parameters 1204 negotiated will be dropped 1205 } 1206 STATUS current 1207 DESCRIPTION 1208 "Specify the treatment applied to the packet out of the 1209 data stream's conformance negotiated 1210 (1) shapping exceeding traffic 1211 (2) dropping exceeding traffic" 1212 ::= { slsExcTreatParamEntry 2 } 1214 slsPerformanceParamTable OBJECT-TYPE 1215 SYNTAX SEQUENCE OF slsPerformanceParamEntry 1216 PIB-ACCESS install-notify 1217 STATUS current 1218 DESCRIPTION 1219 "This class specifies parameters of performance of a flow" 1220 ::= { slsParamClasses 6 } 1222 slsPerformanceParamEntry OBJECT-TYPE 1223 SYNTAX SlsPerformanceParamEntry 1224 STATUS current 1225 DESCRIPTION 1226 "Describes performance parameters of a flow" 1227 ::= { sls PerformanceParamTable 1 } 1229 SlsPerformanceParamEntry ::= SEQUENCE { 1230 slsPerformanceParamPrid InstanceId 1231 slsPerformanceParamDelay Unsigned32 1232 slsPerformanceParamJitter Unsigned32 1233 slsPerformanceParamPacketLoss Unsigned32 1234 } 1236 slsPerformanceParamPrid OBJECT-TYPE 1237 SYNTAX InstanceId 1238 STATUS current 1239 DESCRIPTION 1240 "An arbitrary integer that uniquely identifies an instance 1241 of the class." 1242 ::= { slsPerformanceParamEntry 1 } 1244 slsPerformanceParamDelay OBJECT-TYPE 1245 SYNTAX Unsigned32 1246 STATUS current 1247 DESCRIPTION 1248 "Specifies the delay value in milisecond" 1249 ::= { slsPerformanceParamEntry 2 } 1251 slsPerformanceParamJitter OBJECT-TYPE 1252 SYNTAX Unsigned32 1253 STATUS current 1254 DESCRIPTION 1255 "Specifies the jitter value in milisecond" 1256 ::= { slsPerformanceParamEntry 3 } 1258 slsPerformanceParamPacketLoss OBJECT-TYPE 1259 SYNTAX Unsigned32 1260 STATUS current 1261 DESCRIPTION 1262 "Specifies the packet loss ratio in %" 1263 ::= { slsPerformanceParamEntry 4 } 1265 slsScheduleParamTable OBJECT-TYPE 1266 SYNTAX SEQUENCE OF slsScheduleParamEntry 1267 PIB-ACCESS install-notify 1268 STATUS current 1269 DESCRIPTION 1270 "This class specifies parameters of schedule of service" 1271 ::= { slsParamClasses 7} 1273 slsScheduleParamEntry OBJECT-TYPE 1274 SYNTAX SlsScheduleParamEntry 1275 STATUS current 1276 DESCRIPTION 1277 "Specifies a service schedule" 1278 ::= { slsScheduleParamTable 1 } 1280 SlsScheduleParamEntry ::= SEQUENCE { 1281 slsScheduleParamPrid InstanceId 1282 slsScheduleParamStartTime ExtUTCTime 1283 slsScheduleParamStopTime ExtUTCTime 1284 } 1286 slsScheduleParamPrid OBJECT-TYPE 1287 SYNTAX InstanceId 1288 STATUS current 1289 DESCRIPTION 1290 "An arbitrary integer that uniquely identifies an instance 1291 of the class." 1292 ::= { slsScheduleParamEntry 1 } 1294 slsScheduleParamStartTime OBJECT-TYPE 1295 SYNTAX ExtUTCTime 1296 STATUS current 1297 DESCRIPTION 1298 "The time the service starts" 1299 ::= { slsScheduleParamEntry 2 } 1301 slsScheduleParamStopTime OBJECT-TYPE 1302 SYNTAX ExtUTCTime 1303 STATUS current 1304 DESCRIPTION 1305 "The time the service terminate" 1306 ::= { slsScheduleParamEntry 3 } 1308 slsNegoRptTable OBJECT-TYPE 1309 SYNTAX SEQUENCE OF SlsNegoRptEntry 1310 PIB-ACCESS report-only 1311 STATUS current 1312 DESCRIPTION 1313 "This class is used by the PEP to convey negotiation 1314 information in RPT message" 1315 ::= { slsReportClasses 1 } 1317 slsNegoRptEntry OBJECT-TYPE 1318 SYNTAX SlsNegoRptEntry 1319 STATUS current 1320 DESCRIPTION 1321 "An instance of this class reports on the SLS negotiation" 1322 ::= { slsNegoRptTable 1 } 1324 SlsNegoRptEntry ::= SEQUENCE { 1325 slsNegoRptPrid InstanceId 1326 slsNegoRptFailRea BITS 1327 } 1329 slsNegoRptPrid OBJECT-TYPE 1330 SYNTAX InstanceId 1331 STATUS current 1332 DESCRIPTION 1333 "An arbitrary integer that uniquely identifies an instance 1334 of the class" 1335 ::= { slsNEgoRptEntry 1 } 1337 slsNegoRptFailRea OBJECT-TYPE 1338 SYNTAX BITS { 1339 slsNonAccepted (1) 1340 } 1341 STATUS current 1342 DESCRIPTION 1343 "This attribute specifies the reason by which the PEP sends 1344 a 'failure' report 1345 (1) the PEP does not accept the SLS suggested" 1346 ::= { slsNEgoRptEntry 1 } 1348 END. 1350 7. Security Considerations 1352 COPS-SLS follows the security considerations for COPS protocol [COPS] 1354 8. IANA Consideration 1356 The client-type value of COPS-SLS is to be assigned through IANA. 1358 9. Acknowledgements 1360 We would like to acknowledge ours friends from LIP6 or INFRES-ENST 1361 for their comments and discussions during the preparation of this 1362 document. 1364 10. References 1366 [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. 1367 Sastry, "The COPS (Common Open Policy Service) 1368 Protocol", RFC 2748, January 2000. 1370 [COPS-PR] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, 1371 S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS 1372 Usage for Policy Provisioning (COPS-PR)", RFC 3084, 1373 March 2001. 1375 [DS-TERM] D. Grossman, "New Terminology for Diffserv", draft- 1376 ietf-diffserv-new-terms-08.txt, January 2002, Work in 1377 progress. 1379 [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 1380 Framework for Policy Based Admission Control", RFC 1381 2753, January 2000. 1383 [RFC-2026] S. Bradner, " The Internet Standards Process -- 1384 Revision 3", RFC 2026, October 1996. 1386 [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate 1387 Requirement Levels", RFC 2119, March 1997. 1389 [SLS-AQU] S. Salsano, F. Ricciato, M. Winter, G. Eichler, A. 1391 Thomas, F. Fuenfstueck, T. Ziegler, C. Brandauer, 1392 "Definition and usage of SLSs in the AQUILA 1393 consortium", draft-salsano-aquila-sls-00.txt, November 1394 2000, Work in pogress. 1396 [SLS-TEQ] D. Goderis, Y. T'Joens, C. Jacquenet, G. Memenios, G. 1397 Pavlou, R. Egan, D. Griffin, P. Georgatsos, L. 1398 Georgiadis, P.V. Heuven, "Service Level Specification 1399 Semantics and parameters", draft-tequila-sls-01.txt, 1400 June 2001, Work in progress. 1402 [SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, 1403 R. Sahita, A. Smith, F. Reichmeyer, "Structure of 1404 Policy Provisioning Information (SPPI)", RFC 3159, 1405 August 2001. 1407 [SESSION-AUTH]L-N. Hamer, B. Gage, "Framework for session setup with 1408 media authorization", Internet-Draft, draft-ietf-rap- 1409 session-auth-03.txt, June 2002, Work in progress. 1411 [COPS-FRWK] K. Chan, L-N. Hamer, "An Architecture for COPS Based 1412 Policy Control Management Framework COPS Framework, 1413 draft-ietf-rap-cops-frwk-01.txt, June 2002, work in 1414 progress. 1416 [SMIv2] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, 1417 K. McCloghrie, M. Rose, S. Waldbusser, " Structure of 1418 Management Information Version 2 (SMIv2)", RFC 2578, 1419 April 1999. 1421 [INET-ADDR] M. Daniele, B. Haberman, S. Routhier and J. 1422 Schoenwaelder, "Textual Conventions for Internet 1423 Network Addresses", draft-ietf-ops-rfc2851-update- 1424 06.txt, December 2001. 1426 12. Authors' Addresses 1428 Thi Mai Trang Nguyen 1429 Ecole Nationale Superieure des Telecommunications 1430 Departement Informatique-Reseaux 1431 46 Rue Barrault 1432 74013 Paris - FRANCE 1433 Phone: +33 1 45 81 74 61 1434 Email: trnguyen@enst.fr 1436 Nadia Boukhatem 1437 Ecole Nationale Superieure des Telecommunications 1438 Department Informatique-Reseaux 1439 46 Rue Barrault 1440 74013 Paris - FRANCE 1441 Phone: +33 1 45 81 82 16 1442 Email: Nadia.Boukhatem@enst.fr 1444 Yacine El Mghazli 1445 Alcatel R&I 1446 Route de Nozay 1447 F-91460 Marcoussis - FRANCE 1448 Phone: +33 1 69 63 41 87 1449 Email: yacine.el_mghazli@alcatel.fr 1451 Nathalie Charton 1452 Alcatel R&I 1453 Route de Nozay 1454 F-91460 Marcoussis - FRANCE 1455 Phone: +33 1 69 63 14 85 1456 Email: Nathalie.Charton@ms.alcatel.fr 1458 Louis-Nicolas Hamer 1459 Nortel Networks 1460 Ottawa, Canada 1461 Email: nhamer@nortelnetworks.com 1463 Guy Pujolle 1464 University of Pierre et Marie Curie 1465 Laboratoire d'Informatique de Paris 6 1466 8 Rue du Capitaine Scotte 1467 75015 Paris - FRANCE 1468 Phone: +33 1 44 27 75 14 1469 Email: Guy.Pujolle@lip6.fr 1471 12. Full Copyright Statement 1473 Copyright (C) The Internet Society (2001). All Rights Reserved. 1475 This document and translations of it may be copied and furnished to 1476 others, and derivative works that comment on or otherwise explain it 1477 or assist in its implementation may be prepared, copied, published 1478 and distributed, in whole or in part, without restriction of any 1479 kind, provided that the above copyright notice and this paragraph are 1480 included on all such copies and derivative works. However, this 1481 document itself may not be modified in any way, such as by removing 1482 the copyright notice or references to the Internet Society or other 1483 Internet organizations, except as needed for the purpose of 1484 developing Internet standards in which case the procedures for 1485 copyrights defined in the Internet Standards process must be 1486 followed, or as required to translate it into languages other than 1487 English. 1489 The limited permissions granted above are perpetual and will not be 1490 revoked by the Internet Society or its successors or assigns. 1492 This document and the information contained herein is provided on an 1493 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1494 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1495 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1496 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1497 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.