Internet Draft T.M.T. Nguyen Expires May 2001 University of Paris 6 û ENST Paris N. Boukhatem ENST Paris Y. El Mghazli Alcatel G. Pujolle University of Paris 6 November 2001 COPS Usage for SLS negotiation (COPS-SLS) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Abstract This document describes the use of the Common Open Policy Service (COPS) protocol for supporting Service Level Specification (SLS) negotiation. The [SLS-FRW-TEQ] document has presented the need of a Service Level Specification (SLS). Different works [SLS-TEQ], [SLS- AQU], [SLS-INTER] have defined some SLSs for CPE-PE interface and inter-domain QoS negotiation. The COPS protocol [COPS] has been defined by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used in this memo to communicate SLS information from the client to the network provider. Nguyen, et al. Expires May 2001 [Page 1] Internet Draft COPS-SLS November 2001 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Table of Contents Glossary........................................................... 2 1. Introduction.................................................... 3 2. COPS-SLS Model.................................................. 4 3. Message Content................................................. 5 3.1. Request message (REQ) PEP -> PDP.............................. 5 3.2. Decision message (DEC) PDP -> PEP............................. 5 3.3. Report State message (RPT) PEP -> PDP......................... 6 4. COPS-SLS protocol objects and Client-Specific data format....... 6 4.1. COPS-SLS protocol objects..................................... 7 4.2. Client-Specific data format................................... 7 5. Common Operation and example.................................... 7 6. COPS-SLS PIB Module ............................................11 7. Security Considerations.........................................18 8. Acknowledgements................................................18 9. References......................................................18 10. Authors' Addresses.............................................19 11. Full Copyright Statement.......................................20 Glossary ClientSI Client Specific Information. See [COPS] COPS Common Open Policy Service. See [COPS] CPE Customer Premise Edge. See [SLS-TEQ] CPERR PRC Class Provisioning Error. See [COPS-PR] EPD Encoded Provisioning Instance. See [COPS-PR] ErrorPRID Error PRID. See [COPS-PR] GPERR Global Provisioning Error Object. See [COPS-PR] ISP Internet Service Provider. LAN Local Area Network. PDP Policy Decision Point. See [RAP] PE Provider Edge. See [SLS-TEQ] PEP Policy Enforcement Point. See [RAP]. PIB Policy Information Base. See [COPS-PR] PPRID Prefix PRID. See [COPS-PR] PRID Provisioning Instance Identifier. See [COPS-PR] RAP Resource Allocation Protocol. See [RAP] SLS Service Level Specification. See [DS-TERM] Nguyen, et al. Expires May 2001 [Page 2] Internet Draft COPS-SLS November 2001 1. Introduction While the focus of many early systems for policy-based networking has been the control of edge devices such as edge routers, firewalls, and VPN gateways, future systems should have to account for end-user hosts as policy enforcement points. In fact it is necessary to look at these computers as PEPs, both to provide finer-grained classification of traffic and to deal with traffic classification problems that can arise when traffic from the user terminal is encrypted. Problems with network congestion and QoS adaptation will be solved by enforcing policies at the desktop, requiring the host computer to be well aware with regards to the network traffic it generates. This document describes the use of the Common Open Policy Service (COPS) protocol [COPS] for supporting Service Level Specification (SLS)negotiation. In [SLS-FRW-TEQ], the author has presented the need of a Service Level Specification (SLS). Different works, [SLS-TEQ], [SLS-AQU], [SLS-INTER], have defined some SLSs for CPE-PE interface and inter-domain QoS negotiation. The COPS protocol has been defined by the IETF Resource Allocation Protocol (RAP) WG [RAP] and will be used in this memo to communicate the SLS information from the client to the network provider. Many protocols for supporting SLS negotiation could be envisaged [SLS-FRW-TEQ]. This memo uses COPS protocol for the following reasons: - COPS is a flexible protocol which may support multiple client- types. The definition of COPS based SLS negotiation protocol needs only the specification of appropriate objects corresponding to the new client-type (COPS-SLS). - The client-handle object defined by COPS protocol gives a mechanism for handling various requests in a single PEP. This capability will be used to handle many SLS negotiations in a single PEP. See more information in sections 3 and 5. - If the core network uses COPS to configure network devices, the use of the same protocol for SLS negotiation may facilitate the network configuration process in the core network. Nguyen, et al. Expires May 2001 [Page 3] Internet Draft COPS-SLS November 2001 2. COPS-SLS Model SLS Policy Client SLS Policy Server +--------------+ +-----------+ | | | | | +-----+ | REQ() | +-----+ | | | SLS |----|--------------|->| SLS | | | | PEP |<---|--------------|--| PDP |--|---------> | +-----+ | DEC() | +-----+ | | | | | +--------------+ +-----------+ Figure 1: COPS-SLS Model Figure 1 shows the COPS-SLS model. The SLS Policy Client is the customer of an Internet Service Provider (ISP). Here are some examples of the SLS Policy Client: - A host connected directly to an ISP (via a modem). - A gateway of a subnet (a LAN), which is connected to the ISP. - An ISP who wants to guarantee an end-to-end service level for its customers(the case of inter-domain SLS negotiation). When the SLS-PEP module is activated, the PEP will connect to its primary SLS-PDP. The COPS-SLS connection permits the PEP to request the desired service level from the PDP. (Figure 1) The SLS-PDP is a server who manages all SLSs of an administrative domain. The SLS-PDP gets to its Policy Repository to retrieve the policy. The SLS policy helps the SLS-PDP to accept or reject the requested SLS. The SLS-PDP MAY also suggest another SLS to be applied to the PEP. Once an SLS-PDP accepts an SLS, this SLS-PDP MAY interact with other entities (e.g., the COPS-PR PDP or the entity managing the Policy Repository of the COPS-PR PDP) so that the network could be properly configured. The interaction between the SLS-PDP and the other entities is outside the scope of this document. The COPS-SLS uses two common models supported by COPS protocol: Outsourcing model and Configuration model [COPS-PR]. Thus, there are two information types carried by COPS-SLS: configuration information and signalling information. Configuration information defines how the PEP can negotiate an SLS (e.g., the negotiation mode, the time interval before which the PEP cannot send a new request to modify the negotiated SLS,...). Signalling information defines a specific SLS. At first, the PDP sends configuration information to the PEP using the Configuration mode. After receiving and installing the configuration sent by the PDP, the PEP can request an SLS using the Outsourcing model. (See more information in section 5) Nguyen, et al. Expires May 2001 [Page 4] Internet Draft COPS-SLS November 2001 3. Message Content 3.1. Request message (REQ) PEP -> PDP The REQ message is sent by the SLS-PEP to the SLS-PDP with the following format: ::= *() *() [] Note that *() means zero or more (s). The COPS objects IN-Int, OUT-Int and LPDPDecisions are not included in a COPS- SLS Request. The Named ClientSI object is included in the REQ message when the Context object specifies a 'configuration request' (Configuration model). This object is used to inform the PDP about the PEP negotiation capabilities and all predefined SLS available in the PEP. The Signaled ClientSI object is included in the REQ message when the Context object specifies a 'resource allocation request' (Outsourcing model). This object is used to transport the SLS requested by the PEP. 3.2. Decision message (DEC) PDP -> PEP The DEC message is sent by the SLS-PDP to the SLS-PEP with the following format: ::= *() | [] ::= *() *() A solicited DEC message is sent from the PDP to answer a REQ message sent by the PEP. Unsolicited DEC messages may be sent by the PDP to transport the updated policy information. The Client-Handle value identifies the request that the PDP wants to send its decision. The Context object specifies the context of the decision ('configuration' or 'resource allocation'). Nguyen, et al. Expires May 2001 [Page 5] Internet Draft COPS-SLS November 2001 The Named Decision Data object is included in the DEC message when the Context object specifies a 'configuration' decision. This object is used to transport the negotiation configuration (e.g., negotiation mode, predefined SLSs, ...) which the PDP wants to install/remove in/from the PEP. The action 'install' or 'remove' is specified in the Decision Flags object. If the Context object specifies a 'resource allocation' decision, the Client Specific Decision Data object is included in the DEC message only when the PDP suggests another SLS. The Decision Flags object will specify the action of 'install' in this case. When the PDP does not suggest another SLS, the Client Specific Decision Data object MUST NOT be included in the DEC message because the Decision Flags object is sufficient to accept/reject the SLS requested by the PEP. 3.3. Report State message (RPT) PEP -> PDP The RPT message is sent by the SLS-PEP to the SLS-PDP with the following format: ::= *() *() [] A solicited RPT message MUST be sent by the PEP upon receipt of a DEC message from the PDP. The Client-Handle object contains the same value as the Client-Handle value in the DEC message to which the PEP wants to make a report. The Report-Type object is used to specify the action (success/fail) taken by the PEP. The ClientSI objects are eventually included in the RPT message to transport error/accounting information. 4. COPS-SLS protocol objects and Client-Specific data formats: When designing an SLS negotiation protocol, it is difficult to define a built-in message format adapted to all desired negotiation parameters of all providers. Using a named data structure, a.k.a. a PIB, to transport the SLS information seems suitable for SLS negotiation. This memo supposes that the data carried by COPS-SLS has the structure defined in the SLS-NEGOTIATION-PIB and maybe in other future SLS-PIBs. Nguyen, et al. Expires May 2001 [Page 6] Internet Draft COPS-SLS November 2001 4.1 COPS-SLS protocol objects: The COPS-SLS protocol objects follow the same object formats defined in [COPS-PR]. More precisely, six objects (PRID object, PPRID object, EPD object, GPERR object, CPERR object and ErrorPRID object) are defined in section 4 of [COPS-PR]. Beside three Error objects defined by COPS-PR, this document defines a new Error object for COPS-SLS: S-Num = (tbd) (SLSERR), S-Type = 1 (BER), Length = 8. 0 1 2 3 +----------------+----------------+----------------+----------------+ | Length | S-Num = SLSERR | S-Type = BER | +----------------+----------------+----------------+----------------+ | Error-Code | Error Sub-code | +----------------+----------------+----------------+----------------+ Only the following error code is defined in this document: slsNonAccepted(1) : the PEP does not accept the suggested SLS. 4.2 Client-Specific data format: The Named ClientSI object and the Signaled ClientSI object used in the REQ message have the same format as the ClientSI Request Data defined in section 5.2 of [COPS-PR]. The Named Decision Data object and the Client Specific Decision Data object used in the DEC have the same format as the Named Decision Data defined in section 5.1 of [COPS-PR]. The Named ClientSI object used in the RPT message has the same format as the Policy Provisioning Report Data defined in section 5.3 of [COPS-PR]. The Signaled ClientSI object used in the RPT message has the same format as the Policy Provisioning Report Data defined in section 5.3 of [COPS-PR], but in the case of a 'Failure' Report-Type due to the reject of the PDP suggested SLS, the PEP MUST send a report with the SLSERR Error object indicating the Error-code of 'slsNonAccepted'. 5. Common Operation and example: To illustrate the operation of COPS-SLS, an example of COPS-SLS is shown in Figure 2: Nguyen, et al. Expires May 2001 [Page 7] Internet Draft COPS-SLS November 2001 COPS-SLS-PEP COPS-SLS-PDP | | | | |--------------------------------------------------->|(step 1) | OPN : | | Common Header : | | Client-type = COPS-SLS (tbd) | | PEPID : | | PEPID = PEP_1 | | | |<---------------------------------------------------|(step 2) | CAT : | | Common Header : | | Client-type = COPS-SLS | | KA Timer : | | KATimer = 50 | | | |--------------------------------------------------->|(step 3) | REQ : | | Common Header : | | Client-type = COPS-SLS | | Client-Handle : | | Handle = config_req_A | | Context : | | R-Type = 0x08 (Configuration request) | | Named ClientSI : | | frwkPrcCapsTable | | slsNegoCapsTable | | slsSlsTable | | | |<---------------------------------------------------|(step 4) | DEC : | | Common Header : | | Flags = 0x1 (solicited message) | | Client-type = COPS-SLS | | Client-Handle : | | Handle = config_req_A | | Context : | | R-Type = 0x08 (configuration) | | Decision : | | Decision Flag : | | Command Code = Install | | Named Decision Data : | | slsNegoTable | | (slsNegoMode = predefined SLSs | | slsNegoMaxInt = 120) | | slsSlsTable | | | Nguyen, et al. Expires May 2001 [Page 8] Internet Draft COPS-SLS November 2001 |--------------------------------------------------->|(step 5) | RPT : | | Common Header: | | Flags = 0x1 (solicited message) | | Client-Type = COPS-SLS | | Client-Handle : | | Handle = config_req_A | | Report-Type : | | Report-type = Success | | | |--------------------------------------------------->|(step 6) | REQ : | | Common Header : | | Flags = 0 | | Client-Type = COPS-SLS | | Client-Handle : | | Handle = res_req_B | | Context : | | R-Type = 0x02 (Resource-Allocation request) | | Signaled ClientSI : | | slsSlsTable | | | |<---------------------------------------------------|(step 7) | DEC : | | Common Header : | | Flags = 0x01 (solicited message) | | Client-Type = COPS-SLS | | Client-Handle : | | Handle = res_req_B | | Context : | | R-Type = 0x02 (Resource-Allocation) | | Decision Flags: | | Commande Code = install | | | |--------------------------------------------------->|(step 8) | RPT : | | Common Header : | | Flags = 0x01 (solicited massage) | | Client-Type = COPS-SLS | | Client-Handle : | | Handle = res_req_B | | Report-Type : | | Report-Type = Success | Figure 2: Example of COPS-SLS operation The next section describes the Common Operation on the COPS-SLS connection between the PEP and the PDP. Nguyen, et al. Expires May 2001 [Page 9] Internet Draft COPS-SLS November 2001 When the SLS-PEP module is activated, the PEP connects to its primary SLS-PDP and sends the OPN message with a Client-Type=COPS- SLS (Figure 2 - step 1). If the PDP accepts this PEP, it sends to the PEP a CAT message (Figure 2 - step 2). Otherwise, it sends a CC message. When the COPS-SLS connection is successfully established, the PEP sends the first REQ with a Context='configuration request'. The Named ClientSI object is used in this request to inform the PDP about the capabilities of the PEP (e.g, the PRCs the PEP understands, the negotiation mode the PEP supports, ...) and all existing predefined SLS (Figure 2 - step 3). The predefined SLS is defined in [SLS-AQU] as an SLS with predefined values (or a range of values) for a subset of the parameters in the generic SLS. In predefined SLS mode, the PDP installs all predefined SLS in the PEP. The PEP CAN only request an SLS conforming to one of these predefined SLSs. The PEP MUST NOT request an SLS outside these predefined SLSs. In non-predefined SLS mode, the PEP CAN request an SLS with any parameter values. Upon receipt of the REQ message, the PDP sends a solicited DEC message with a Context='configuration' and installs the configuration information at the PEP (Figure 2 - step 4). After receiving the DEC message, the PEP installs the configuration sent by the PDP and sends a RPT message to the PDP to report the installation result (Figure 2 - step 5). If the configuration is successfully installed, the PEP CAN now send a REQ message with a Context='resource-allocation' to request the desired SLS (Figure 2 - step 6). In response to the REQ message, the PDP sends a DEC message with the same context (i.e., resource-allocation). The PDP can accept the requested SLS, or reject the requested SLS, or suggest another SLS. To accept the requested SLS, the PDP sends a DEC message with a Decision-Flags='Install' (Figure 2 - step 7). To reject the requested SLS, the PDP sends a DEC message with a Decision-Flags='Remove'. To suggest another SLS, the PDP sends a DEC message with a Decision- Flags='install' and includes the suggested SLS in the Client Specific Decision Data object. Nguyen, et al. Expires May 2001 [Page 10] Internet Draft COPS-SLS November 2001 If the PEP receives a DEC message accepting/rejecting the requested SLS, it installs the decision and sends a 'success' report to the PDP (Figure 2 - step 8). If the PEP cannot install the decision, it sends a 'failure' report to the PDP including the corresponding Error object. If the PEP receives a DEC message suggesting another SLS, it can accept the suggestion by sending a RPT message with a Report-Type=Success or reject the suggested SLS by sending a RPT message with a Report-Type=Failure. If the PEP wants to modify some parameters of a negotiated SLS, it sends a REQ message using the Client-Handle value identifying the SLS and includes in the Signaled ClientSI object the SLS with its new parameter values. To delete a requested SLS, the PEP sends a DRQ message using the Client-Handle value identifying the SLS to be deleted. At any time, the PDP CAN send an unsolicited DEC message to supply the PEP with the updated policy information or to degrade some negotiated SLS. If the PEP receives a SSQ message, it reissues all requested SLSs and finishes the synchronization period by the SSC message. 6. COPS-SLS PIB Module: SLS-NEGOTIATION-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, InstanceId, MODULE-IDENTITY, OBJECT-TYPE FROM COPS-PR-SPPI ZerroDotZero FROM SNMPv2-SMI ExtUTCTime FROM SNMPv2-SMI slsPolicyPib MODULE-IDENTITY SUBJECT-CATEGORIES { tbd - COPS-SLS Client Type } LAST-UPDATED "200112091200Z" ORGANIZATION "Alcatel, ENST Paris and University of Paris 6" CONTACT-INFO " Thi Mai Trang Nguyen INFRES-ENST 46 Rue Barrault 75013 Paris - France Phone: +33 1 45 81 74 61 Email: trnguyen@enst.fr Nguyen, et al. Expires May 2001 [Page 11] Internet Draft COPS-SLS November 2001 Nadia Boukhatem INFRES-ENST 46 Rue Barrault 75013 Paris - France Phone: +33 1 45 81 82 16 Email: Nadia.BouKhatem@enst.fr Yacine El Mghazli Alcatel R&I Route de Nozay F-91460 Marcoussis - FRANCE Phone: +33 1 69 63 41 87 Email: yacine.elmghazli@ms.alcatel.fr Guy Pujolle RP-LIP6-UPMC 8 Rue du Capitaine Scott 75015 Paris û France Phone: +33 1 44 27 75 14 Email: Guy.Pujolle@lip6.fr" DESCRIPTION "The PIB module contains a set of classes describing the policies in the SLS negotiation" ::= { tbd } slsCapabilityClasses OBJECT IDENTIFIER ::= { slsPolicyPib 1 } slsPolicyClasses OBJECT IDENTIFIER ::= { slsPolicyPib 2 } slsParamClasses OBJECT IDENTIFIER ::= { slsPolicyPib 3 } slsNegoCapsTable OBJECT-TYPE SYNTAX SEQUENCE OF SlsCapsEntry PIB-ACCESS notify STATUS current DESCRIPTION "SLS negotiation capabilities supported by the client" ::= { slsCapabilityClasses 1} slsNegoCapsEntry OBJECT-TYPE SYNTAX SlsNegoCapsEntry STATUS current DESCRIPTION "An instance of this class describes the SLS negotiation capabilities of a client" ::= { slsNegoCapsTable 1 } PIB-INDEX { slsNegoCapsPrid } SlsNegoCapsEntry ::= SEQUENCE { slsNegoCapsPrid InstanceId Nguyen, et al. Expires May 2001 [Page 12] Internet Draft COPS-SLS November 2001 slsNegoCapsNegoMode BITS slsNegoCapsNegoInt Unsigned32 slsNegoCapsMaxPredefSls Unsigned32 } slsNegoCapsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class" ::= { slsNegoCapsEntry 1 } slsNegoCapsNegoMode OBJECT-TYPE SYNTAX BITS { predefSls(1) -- the ability to support predefined SLS mode non-predefinedSls (2) -- the ability to support non-predefined SLS mode" } STATUS current DESCRIPTION "The SLS negotiation mode supported by the PEP (1) - predefined SLS mode (2) - non-predefined SLS mode" ::= { slsNegoCapsEntry 2 } slsNegoCapsNegoInt OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The desired interval before which the client could send another REQ message to modify a negotiated SLS" ::= { slsNegoCapsEntry 3 } slsNegoCapsMaxPredefSls OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The maximum number of predefined SLSs that the PDP can install at the client device. If the client does not support the predefined SLS negotiation mode, this value MUST be 0" ::= { slsNegoCapsEntry 4 } slsNegoTable OBJECT-TYPE SYNTAX SEQUENCE OF SlsNegoEntry Nguyen, et al. Expires May 2001 [Page 13] Internet Draft COPS-SLS November 2001 PIB-ACCESS install STATUS current DESCRIPTION "SLS negotiation policies to be installed by the PDP" ::= { slsPolicyClasses 1 } slsNegoEntry OBJECT-TYPE SYNTAX SlsNegoEntry STATUS current DESCRIPTION "An instance of this class describes the policies about SLS negotiation that the PDP installs at the PEP" PIB-INDEX { slsNegoPrid } ::= { slsNegoTable 1 } SlsNegoEntry ::= SEQUENCE { slsNegoPrid InstanceId slsNegoMode Unsigned32 slsNegoMaxInt Unsigned32 } slsNegoPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the class" ::= { slsNegoEntry 1 } slsNegoMode OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The negotiation mode used by the client. The value of 1 indicates the predefined SLS mode. The value of 2 indicates the non-predefined SLS mode" ::= { slsNegoEntry 2 } slsNegoMaxInt OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The maximum interval during which the client cannot issue a REQ message to change a negotiated SLS or to request a new SLS" ::= { slsNegoEntry 3 } slsSlsTable OBJECT-TYPE SYNTAX SEQUENCE OF slsSlsEntry Nguyen, et al. Expires May 2001 [Page 14] Internet Draft COPS-SLS November 2001 PIB-ACCESS install-notify STATUS current DESCRIPTION "Represent an SLS" ::= { slsPolicyClasses 2 } slsSlsEntry OBJECT-TYPE SYNTAX SEQUENCE OF SlsSlsEntry STATUS current DESCRIPTION "An instance of this class specifies an SLS" ::= { slsSlsTable 1 } SlsSlsEntry ::= SEQUENCE { slsSlsPrid InstanceId slsSlsFlowId Prid slsSlsTrafficConformance Prid slsSlsExcessTreatment Prid slsSlsPerformance Prid slsSlsServiceSchedule Prid } slsSlsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer that uniquely identifies an instance of the class" ::= { slsSlsEntry 1} slsSlsFlowId OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION " This attribute specifies the identification of a flow. The value must point to a valid instance of one of these classes: frwkIpFilterEntry [FRW-PIB]" ::= { slsSlsEntry 2 } slsSlsTrafficConformance OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION " This attribute specifies the traffic conformance of the flow identified in slsSlsFlowId. The value must point to a valid instance of one of these classes: qosTBMeterEntry [DIFF-PIB]" ::= { slsSlsEntry 3 } Nguyen, et al. Expires May 2001 [Page 15] Internet Draft COPS-SLS November 2001 slsSlsExcessTreatment OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "This attribute specifies the excess treatment applied to the flow identified by slsSlsFlowId if it does not conform to parameters specified in slsSlsTrafficConformance. The value must point to a valid instance of one of these classes: qosAction [DIFF-PIB]" ::= { slsSlsEntry 4 } slsSlsPerformance OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "This attribute specifies the performance guarantees applied to the flow identified by slsSlsFlowId. The value must point to an instance of one of these classes: slsPerformanceParamEntry " ::= { slsSlsEntry 5 } slsSlsServiceSchedule OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION " This attribute specifies the service Schedule applied to the SLS specified by this instance. The value must point to an valid instance of one of these classes: slsScheduleParamEntry zeroDotZero (non specified) " ::= { slsSlsEntry 6 } slsScheduleParamTable OBJECT-TYPE SYNTAX SEQUENCE OF slsScheduleParamEntry STATUS current DESCRIPTION "This class specifies parameters of schedule of service" ::= { slsParamClasses 1} slsScheduleParamEntry OBJECT-TYPE SYNTAX SlsScheduleParamEntry STATUS current DESCRIPTION "Specifies a service schedule" ::= { slsScheduleParamTable 1 } Nguyen, et al. Expires May 2001 [Page 16] Internet Draft COPS-SLS November 2001 SlsScheduleParamEntry ::= SEQUENCE { slsScheduleParamStartTime ExtUTCTime slsScheduleParamStopTime ExtUTCTime } slsScheduleParamStartTime OBJECT-TYPE SYNTAX ExtUTCTime STATUS current DESCRIPTION "The time the service starts" ::= { slsScheduleParamEntry 1 } slsScheduleParamStopTime OBJECT-TYPE SYNTAX ExtUTCTime STATUS current DESCRIPTION "The time the service terminate" ::= { slsScheduleParamEntry 2 } slsPerformanceParamTable OBJECT-TYPE SYNTAX SEQUENCE OF slsPerformanceParamEntry STATUS current DESCRIPTION "This class specifies parameters of performance of a flow" ::= { slsParamClasses 2 } slsPerformanceParamEntry OBJECT-TYPE SYNTAX SlsPerformanceParamEntry STATUS current DESCRIPTION "Describes performance parameters of a flow" ::= { sls PerformanceParamTable 1 } SlsPerformanceParamEntry ::= SEQUENCE { slsPerformanceParamDelay Unsigned32 slsPerformanceParamJitter Unsigned32 slsPerformanceParamPacketLoss Unsigned32 } slsPerformanceParamDelay OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "Specifies the delay value in milisecond" ::= { slsPerformanceParamEntry 1 } slsPerformanceParamJitter OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION Nguyen, et al. Expires May 2001 [Page 17] Internet Draft COPS-SLS November 2001 "Specifies the jitter value in milisecond" ::= { slsPerformanceParamEntry 2 } slsPerformanceParamPacketLoss OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "Specifies the packet loss ratio in %" END 7. Security Considerations COPS-SLS follows the security considerations for COPS protocol [COPS] 8. Acknowledgements We would like to acknowledge ours friends from LIP6 or INFRES-ENST for their comments and discussions during the preparation of this document. 9. References [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [COPS-PR] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [DS-TERM] D. Grossman, "New Terminology for Diffserv", draft- ietf-diffserv-new-terms-05.txt, August 2001, Work in progress. [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000. [RFC-2026] S. Bradner, " The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [SLS-AQU] S. Salsano, F. Ricciato, M. Winter, G. Eichler, A. Thomas, F. Fuenfstueck, T. Ziegler, C. Brandauer, "Definition and usage of SLSs in the AQUILA Nguyen, et al. Expires May 2001 [Page 18] Internet Draft COPS-SLS November 2001 consortium", draft-salsano-aquila-sls-00.txt, November 2000, Work in pogress. [SLS-FRW-TEQ] Y. T'Joens, D. Goderis, R. Rajan, S. Salsano, C. Jacquenet, G. Mamanios, G. Pavlou, R. Egan, D. Griffin, P. Vanheuven, P. Georgatsos, L. Georgiadis, "Service Level Specification and Usage", draft-manyfolks-sls- framework-00.txt, October 2000, Work in progress. [SLS-INTER] R. Rajan, E. Celenti, S. Dutta, "Service Level Specification for Inter-domain QoS Negotiation", draft- somefolks-sls-00.txt, November 2000, Work in progress. [SLS-TEQ] D. Goderis, Y. T'Joens, C. Jacquenet, G. Memenios, G. Pavlou, R. Egan, D. Griffin, P. Georgatsos, L. Georgiadis, P.V. Heuven, "Service Level Specification Semantics and parameters", draft-tequila-sls-01.txt, June 2001, Work in progress. [SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [FRW-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer, " Framework Policy Information Base ", draft-ietf-rap-frameworkpib-05.txt, July 2001, Work in progress. [DIFF-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C. Bell, A. Smith, F. Reichmeyer, "Differentiated Services Quality of Service Policy Information Base", draft-ietf-diffserv-pib-04.txt, July 2001, Work in progress. 10. Authors' Addresses Thi Mai Trang Nguyen Ecole Nationale Superieure des Telecommunications Departement Informatique-Reseaux 46 Rue Barrault 74013 Paris - FRANCE Phone: +33 1 45 81 74 61 Email: trnguyen@enst.fr Nadia Boukhatem Ecole Nationale Superieure des Telecommunications Departement Informatique-Reseaux Nguyen, et al. Expires May 2001 [Page 19] Internet Draft COPS-SLS November 2001 46 Rue Barrault 74013 Paris - FRANCE Phone: +33 1 45 81 82 16 Email: Nadia.Boukhatem@enst.fr Yacine El Mghazli Alcatel R&I Route de Nozay F-91460 Marcoussis - FRANCE Phone: +33 1 69 63 41 87 Email: yacine.elmghazli@ms.alcatel.fr Guy Pujolle University of Pierre et Marie Curie Laboratoire d'Informatique de Paris 6 Theme Reseaux-Performances 8 Rue du Capitaine Scotte 75015 Paris - FRANCE Phone: +33 1 44 27 75 14 Email: Guy.Pujolle@lip6.fr 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nguyen, et al. Expires May 2001 [Page 20]