Internet Draft                                             T.M.T. Nguyen
Expires January 2003                  University of Paris 6 - ENST Paris
                                                            N. Boukhatem
                                                              ENST Paris
                                                           Y. El Mghazli
                                                              N. Charton
                                                                 Alcatel
                                                     Louis-Nicolas Hamer
                                                         Nortel Networks
                                                              G. Pujolle
                                                   University of Paris 6

                                                          July, 1st 2002

            COPS-PR Usage for SLS negotiation (COPS-SLS)
                 <draft-nguyen-rap-cops-sls-03.txt>

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 (COPS-SLS). 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 between customer and 
   provider. COPS-SLS can be used at different interfaces such as 





Nguyen, et al.               Expires January 2003               [Page 1]
Internet Draft                    COPS-SLS                     July 2002


   vertically between a service provider and a network provider or 
   horizontally between network providers in order to decide if the 
   network guarantees a service level for a traffic stream. This version 
   presents COPS-SLS as a candidate protocol for the interface between 
   the Resource Control Domain (RCD) and the Service Control Domain 
   (SCD), according to [SESSION-AUTH] vocabulary. It enables an SCD to
   vertically reserve RCD resource for its customers. Once resource has 
   been reserved in the RCD, the media session establishment, together 
   with the horizontal resource reservation, follows the steps described 
   in the [AUTHSESSION] framework. Moreover, the respective PDPs have to 
   verify that all the media streams being accepted lie within the 
   bounds of the resource reserved in the RCD by the SCD.



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.................................................. 5
   2.1 Overall model                                                   5
   2.2 Consistency with the framework for session set-up with media 
       authorization.................................................. 6
   3. Message Content................................................. 7
   3.1. Request message (REQ) PEP -> PDP.............................. 7
   3.2. Decision message (DEC) PDP -> PEP............................. 7
   3.3. Report State message (RPT) PEP -> PDP......................... 8
   4. COPS-SLS protocol objects and Client-Specific data format....... 9
   4.1. COPS-SLS protocol objects..................................... 9
   4.2. Client-Specific data format................................... 9
   5. Common Operation and example.................................... 9
   6. COPS-SLS PIB Module ............................................13
   7. Security Considerations.........................................29
   8. IANA Considerations.............................................29
   9. Acknowledgements................................................29
   10. References.....................................................29
   11. Authors' Addresses.............................................30
   12. Full Copyright Statement.......................................31

Glossary

      ClientSI  Client Specific Information. See [COPS]
      CPERR     PRC Class Provisioning Error. See [COPS-PR]




Nguyen, et al.               Expires January 2003               [Page 2]
Internet Draft                    COPS-SLS                     July 2002


      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. 
      PDP       Policy Decision Point. See [RAP]
      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]

1. Introduction

   This document describes the use of the Common Open Policy Service
   (COPS) protocol [COPS] for supporting Service Level Specification
   (SLS)negotiation (COPS-SLS). 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 between a 
   customer and a network provider. 

   COPS-SLS can be used for horizontal as well as vertical negotiations 
   as illustrated in Figure 1. 

               +-------------------+
               |  Service Provider |
               +-------------------+
                         ^    
                         | (vertical negotiation)
                         |
                         v
                +------------------+ (horizontal   +------------------+
                |                  | negotiation)  |                  |
            ----| Network Provider |<------------->| Network Provider |-
                |                  |               |                  |
                +------------------+               +------------------+

                  Figure 1 – Vertical and horizontal negotiations

   In horizontal negotiation, two network providers (or two ISPs)
   negotiate a service level for a traffic stream entering from one 
   domain to the other. Vertical negotiation takes place between a 
   Service Provider and a Network Provider in order for the traffic 
   stream to be guaranteed with a service level in the network provider 
   domain.

   In this version, we introduce the use of COPS-SLS between the Service 
   Control Domain and the Resource Control Domain in the framework of 
   




Nguyen, et al.               Expires January 2003               [Page 3]
Internet Draft                    COPS-SLS                     July 2002


   session set-up with media authorization [SESSION-AUTH]. The Service 
   Provider corresponds to the Service Control Domain and the Network 
   Provider corresponds to the Resource Control Domain in this 
   framework. COPS-SLS enables an SCD to vertically reserve RCD resource
   for its customers. Once resource has been reserved in the RCD, the 
   media session establishment, together with the horizontal resource 
   reservation, follow the steps described in the [SESSION-AUTH]
   framework. Moreover, the respective PDPs have to verify that all the 
   media streams being accepted lie within the bounds of the resource 
   reserved in the RCD by the SCD.

   Many protocols could be envisaged between the RCD and the SCD. 
   This document proposes the COPS-PR protocol for the following 
   reasons:

   - Policy-based networking provides interesting architecture concepts
     for service level management.

   - By designing a SLS specific PIB (Policy Information Base), no 
     change is needed to the COPS-PR protocol itself. This is a good 
     way of building on the existing technology without having to 
     revisit the protocol every time new information needs to be carried 
     by the protocol. This also provides a faster way for a deployment 
     without going through another cycle of standardization for the 
     protocol. This provides more flexibility and a standard way for the 
     implementations to add value by extending the standardized Policy 
     Control Information.

   - Separation of Protocol and Policy Control Information. COPS-PR 
     takes the approach of defining a stable, reusable, more widely 
     applicable protocol. With the applicability addressed by the Policy 
     Control Information carried by the COPS-PR protocol.

   - Provisioning functionality has generally been thought of as static, 
     but within the context of COPS-PR, the degree of dynamic/static is 
     up to the user of the technology. The events handled by COPS-PR can 
     be very dynamic to very static. The degree of dynamic-ness is in 
     itself a policy, and can be controlled with COPS-PR with 
     flexibility in both event detection/reporting frequency and 
     granularity.

   - Levels of outsourcing details can be as coarse (aggregated) or fine 
     (per micro-flow) as necessary and can be adjusted dynamically when 
     needed.
   
   COPS-SLS makes uses of both common models supported by the COPS 
   protocol: Outsourcing model and Configuration (a.k.a. Provisioning) 
   model. 

   



Nguyen, et al.               Expires January 2003               [Page 4]
Internet Draft                    COPS-SLS                     July 2002


   During the negotiation phase, the customer requests a service by 
   triggering the PEP function which negotiate the desired SLS with the 
   provider. The decision sent by the PDP addresses the desired SLS sent 
   by the PEP. There is a direct 1:1 correlation between PEP events and 
   PDP decisions. Therefore, the negotiation phase follows the 
   Outsourcing mode as defined in RFC3084, section 1 [RFC 3084].

   In order to make the negotiation configurable according to the domain 
   policies, a configuration phase is used in COPS-SLS. The 
   configuration phase follows the COPS Provisioning mode defined in 
   RFC3084, section 1 [RFC 3084]. The domain negotiation policies are 
   provisioned down to the customer. These policies indicate the service 
   offered by a provider, this can be the negotiable parameters, the 
   value constraints of these parameters, the dynamic level of the 
   negotiation, etc. The configuration phase is also useful to provision 
   pre-defined service templates that can be requested as is by the 
   customer in case there is a correspondence with its own needs.  

   [COPS-FRWK] describes in more details how COPS-PR can be utilized in 
   both outsourcing and configuration mode.

2. COPS-SLS model 

2.1 Overall model

     Policy Client (SCD/RCD)            Policy Server (RCD/SCD)
       +--------------+              +-----------+     
       |              |              |           |     
       |   +-----+    |    REQ()     |  +-----+  |     
       |   | SLS |----|--------------|->| SLS |  |         
       |   | PEP |<---|--------------|--| PDP |--|--------->
       |   +-----+    |    DEC()     |  +-----+  |         
       |              |              |           |         
       +--------------+              +-----------+         
                                                        
                    Figure 2 - COPS-SLS model 


   As depicted in Figure 2, the SLS Policy Client negotiates with the
   SLS Policy Server using the COPS protocol. This negotiation process 
   can take place within an administrative domain or between 
   administrative domains. The SLS PEP represents the customer and the 
   SLS PDP represents the network provider. The customer is the entity  
   consuming network resources of a network provider. It may be an 
   enterprise, an Application Service Provider (ASP) or another network 
   provider.
   
   





Nguyen, et al.               Expires January 2003               [Page 5]
Internet Draft                    COPS-SLS                     July 2002


   When the SLS-PEP module is activated, the PEP connects to its   
   primary SLS-PDP. 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 relevant policies. The SLS policies 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 and an SLS-PEP agreed on a service level for a
   Traffic stream, the SLS-PDP MAY interact with other entities (e.g., a 
   COPS-PR-DiffServ PDP) so that the network resources could be properly 
   provisioned. The interaction between the SLS-PDP and the other 
   entities is outside the scope of this document.

2.2 Consistency with the framework for session set-up with media 
    authorization

   For vertical negotiations, i.e. negotiations between service 
   providers and network providers, the framework defined in [SESSION-
   AUTH] should be assumed. Basically, the network provider MUST verify 
   with the service provider that the QoS resources requested by a 
   particular user are within the bounds of the authorized session. 

   [SESSION-AUTH] describes 4 different models: the coupled model, the 
   associated model with one policy server, the associated model with 
   two policy servers and the non-associated model. 

   Only the coupled & associated models apply to the original COPS-SLS 
   concept presented since version 00. The SCD can negotiate with the 
   RCD for a number of resources and distribute them to different 
   sessions. When the used resource arrives at a threshold, the SCD 
   renegotiates with the RCD to get more resources. The SCD can 
   dynamically negotiate resources with the RCD for each session. The 
   non-associated model does not require a negotiation between service 
   and network providers.

   In the coupled & associated model with one policy server, the service 
   provider acts as the SLS PEP since it is consuming network resources
   controlled by the SLS PDP. However, in the associated model with two
   policy servers, the roles are reversed. In fact, since the service 
   provider does not have an a priori relationship with the network 
   provider, the negotiation process cannot be triggered. Instead, the 
   service provider will send an authorization token, providing his 
   identity, back to the end host. The end host relays this 
   authorization token to the network provider in his resource request. 
   The network provider can then establish communication with the 
   identified service provider in the authorization token. Since the 
   network provider requests session authorization information from the 
   





Nguyen, et al.               Expires January 2003               [Page 6]
Internet Draft                    COPS-SLS                     July 2002


   service provider, the network provider acts as a PEP, while the 
   service provider acts as a PDP. Although the service provider is 
   still consuming resources from the resource provider, the latter is 
   the initiator (or client) of the exchange, and the former acts as the 
   server by providing detailed information about the authorized 
   session.
   

3. Message Content

   This section presents the content of the Request, Decision and Report 
   messages. In this version, we only use the Named ClientSI object 
   defined in COPS-PR to convey information exchanged between the PEP 
   and the PDP both in Provisioning mode (Configuration phase) and in 
   Outsourcing mode (Negotiation phase). The Context Object 
   distinguishes the two phases: Configuration and Negotiation.


3.1. Request message (REQ)  PEP -> PDP

   The REQ message is sent by the SLS-PEP to the SLS-PDP with the
   following format:

               <Request> ::= <Common Header>
                             <Client Handle>
                             <Context>
                             *(<Named ClientSI>
                             [<Integrity>]

   Note that *(<entity>) means zero or more <entity>(s). The COPS
   objects IN-Int, OUT-Int and LPDPDecisions are not included in a COPS-
   SLS Request.

   The Context object specifies the context of the message. A 'context = 
   configuration request' specifies a request in the Configuration 
   phase. A 'Context = resource allocation request' specifies a request 
   in the Negotiation phase.

   The Named ClientSI object is included in the REQ message to convey 
   negotiation's information under PIB classes' instances. In the 
   Configuration phase, this object is used to inform the PDP about the 
   PEP negotiation capabilities and all predefined SLS available in the 
   PEP. In the Negotiation phase, 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





Nguyen, et al.               Expires January 2003               [Page 7]
Internet Draft                    COPS-SLS                     July 2002


   following format:

      <Decision Message> ::= <Common Header>
                             <Client Handle>
                             *(<Decision>) | <Error>
                             [<Integrity>]

              <Decision> ::= <Context>
                             <Decision Flags>
                             *(<Named Decision Data>)

   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 to which the PDP wants to send a decision. The 
   Context object specifies the context of the decision ('configuration' 
   or 'resource-allocation').

   The Named Decision Data object is included in the DEC message to 
   convey the PIB class instances in the decision. In the Configuration 
   phase, 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. In the Negotiation phase, 
   this object is used when the PDP suggests another SLS. The Decision 
   Flags object will specify the action of 'install' in this case. 

   For the decisions which simply accept or reject the SLS indicated in 
   the REQ message without proposing another service level, the action
   'install' or 'remove' in the Decision Flags object is sufficient. No 
   Named Decision Data Object is included in the DEC message to convey 
   the SLS proposal.
   
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:

               <Report State> ::= <Common Header>
                                  <Client Handle>
                                  <Report Type>
                                  *(<Named ClientSI>)
                                  [<Integrity>]

   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.





Nguyen, et al.               Expires January 2003               [Page 8]
Internet Draft                    COPS-SLS                     July 2002


   The Report-Type object is used to specify the action (success/fail)
   taken by the PEP.  The Named ClientSI objects are eventually included 
   in the RPT message to transport error/accounting information. 

4. COPS-SLS protocol objects and Client-Specific data formats

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].

                       
4.2 Client-Specific data format
     
   The Named 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 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]. In the case of a 'Failure' Report-Type due to the reject 
   of the PDP suggested SLS, the PEP MUST send a report indicating 
   'slsNonAccepted' using slsNegoRptEntry PRC.

5. Common Operation and example

   To illustrate the operation of COPS-SLS, an example of COPS-SLS is
   shown in Figure 3. 

     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                       |





Nguyen, et al.               Expires January 2003               [Page 9]
Internet Draft                    COPS-SLS                     July 2002


          |    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                               |
          |                                                    |
          |--------------------------------------------------->|(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                                    |





Nguyen, et al.               Expires January 2003              [Page 10]
Internet Draft                    COPS-SLS                     July 2002


          |       Client-Type = COPS-SLS                       |
          |    Client-Handle :                                 |
          |       Handle = res_req_B                           |
          |    Context :                                       |
          |       R-Type = 0x02 (Resource-Allocation request)  |
          |    Named 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 3 - Example of COPS-SLS operation

   The next section describes the Common Operation on the COPS-SLS
   connection between the PEP and the PDP.

   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 3 - step 1).

   If the PDP accepts this PEP, it sends to the PEP a CAT message
   (Figure 3 - 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
   SLSs (Figure 3 - step 3). 





Nguyen, et al.               Expires January 2003              [Page 11]
Internet Draft                    COPS-SLS                     July 2002


   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 the 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 3 - 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 3 - 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 3 - 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 3 - 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 Named Decision
   Data object. 

   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 3 - 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 and an instance of the PRC 
   SlsNegoRptEntry with a 'slsNegoRptFailRea = 1'.

   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 Named ClientSI object the SLS with its new
   parameter values.





Nguyen, et al.               Expires January 2003              [Page 12]
Internet Draft                    COPS-SLS                     July 2002


   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 SLSs.

   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

   This section defines the PIB used in COPS-SLS client-type. This PIB
   defines the SLS parameters necessary for horizontal negotiation. The 
   SLS parameters are organized similarly to [SLS-TEQ] in six groups: 
   scope, flowId, traffic conformance, excess treatment, performance and 
   service schedule. More classes or attributes useful to vertical 
   negotiation will be added in further versions.

   SLS-NEGOTIATION-PIB PIB-DEFINITIONS ::= BEGIN

   IMPORTS
        Unsigned32, InstanceId, MODULE-IDENTITY, OBJECT-TYPE
             FROM COPS-PR-SPPI
        ZerroDotZero
             FROM SNMPv2-SMI [SMIv2]
        ExtUTCTime
             FROM SNMPv2-SMI
        InetAddressType, InetAddress, InetAddressPrefixLength,
        InetPortNumber
             FROM INET-ADDRESS-MIB [INET-ADDR]
        DscpOrAny
             FROM DIFFSERV-DSCP-TC 

   slsPolicyPib MODULE-IDENTITY
        SUBJECT-CATEGORIES { tbd - COPS-SLS Client Type }
        LAST-UPDATED "200202281200Z"
        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

                      Nadia Boukhatem
                      INFRES-ENST





Nguyen, et al.               Expires January 2003              [Page 13]
Internet Draft                    COPS-SLS                     July 2002


                      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.el_mghazli@alcatel.fr    
 
                      Nathalie Charton
                      Alcatel R&I
                      Route de Nozay
                      F-91460 Marcoussis - FRANCE
                      Phone: +33 1 69 63 14 85
                      Email: Nathalie.Charton@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 SLS negotiation"
        ::= { tbd }

   slsCapabilityClasses OBJECT IDENTIFIER ::= { slsPolicyPib 1 }
   slsPolicyClasses OBJECT IDENTIFIER ::= { slsPolicyPib 2 }
   slsParamClasses OBJECT IDENTIFIER ::= { slsPolicyPib 3 }
   slsReportClasses OBJECT IDENTIFIER ::= { slsPolicyPib 4}

   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
             





Nguyen, et al.               Expires January 2003              [Page 14]
Internet Draft                    COPS-SLS                     July 2002


             "An instance of this class describes the SLS negotiation
              capabilities of a client"
        ::= { slsNegoCapsTable 1 }
        PIB-INDEX { slsNegoCapsPrid }

   SlsNegoCapsEntry ::= SEQUENCE {
             slsNegoCapsPrid InstanceId
             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






Nguyen, et al.               Expires January 2003              [Page 15]
Internet Draft                    COPS-SLS                     July 2002


             "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
        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 BITS
            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 BITS{
                    predefSls(1)
                    -- predefined SLS mode
                    non-predefinedSls (2)
                    -- non-predefined SLS mode"
        }
        STATUS current
        DESCRIPTION





Nguyen, et al.               Expires January 2003              [Page 16]
Internet Draft                    COPS-SLS                     July 2002


             "The negotiation mode used by the client. 
                 1 - indicates the predefined SLS mode. 
                 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"
        ::= { slsNegoEntry 3 }

   slsSlsTable OBJECT-TYPE
        SYNTAX     SEQUENCE OF slsSlsEntry
        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
        slsSlsScope Prid
        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}

   slsSlsScope OBJECT-TYPE
        SYNTAX Prid





Nguyen, et al.               Expires January 2003              [Page 17]
Internet Draft                    COPS-SLS                     July 2002


        STATUS current
        DESCRIPTION
             " This attribute uniquely indicates where the QoS policy 
               for that specific service is to be enforced. The value 
               must point to a valid instance of one of these classes:
                    slsScopeParamEntry
        ::= { slsSlsEntry 2 }

   slsSlsFlowId OBJECT-TYPE
        SYNTAX Prid
        STATUS current
        DESCRIPTION
             " This attribute specifies the identification of a flow. It 
               indentifies a stream of IP packets sharing at least one 
               common characteristic. The value must point to a valid 
               instance of one of these classes:
                    slsFlowIdParamEntry"
        ::= { slsSlsEntry 3 }

   slsSlsTrafficConformance OBJECT-TYPE
        SYNTAX Prid
        STATUS current
        DESCRIPTION
             " This attribute specifies the traffic conformance of the
               flow identified in slsSlsFlowId. The traffic conformance 
               parameters describes how the packet stream should look 
               like to get the guarantees indicated by the perfomance 
               parameters. The value must point to 
               a valid instance of one of these classes: 
                   slsConformParamEntry"
        ::= { slsSlsEntry 4 }

   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. 
              Excess traffic may be dropped, shaped and/or remarked.
              The value must point to a valid instance of one of these
              classes:
                   slsExcTreatParamEntry" 
        ::= { slsSlsEntry 5 }

   slsSlsPerformance OBJECT-TYPE
        SYNTAX Prid
        STATUS current





Nguyen, et al.               Expires January 2003              [Page 18]
Internet Draft                    COPS-SLS                     July 2002


        DESCRIPTION
             "This attribute specifies the performance guarantees the 
             network offers to the customer for the flow identified by 
             slsSlsFlowId. The value must point to an instance of one of 
             these classes:
                   slsPerformanceParamEntry "
        ::= { slsSlsEntry 6 }

   slsSlsServiceSchedule OBJECT-TYPE
        SYNTAX Prid
        STATUS current
        DESCRIPTION
             " This attribute indicates the start time and end time of 
             the service, i.e. when the service is available. The value 
             must point to an valid instance of one of these classes:
                  slsScheduleParamEntry
                  zeroDotZero (non specified)"
        ::= { slsSlsEntry 7 }

   slsScopeParamTable OBJECT-TYPE
        SYNTAX SEQUENCE OF slsScopeParamEntry
        PIB-ACESS install-notify
        STATUS current
        DESCRIPTION
             "This class specifies the scope parameters"
        ::= { slsParamClasses 1}

   slsScopeParamEntry OBJECT-TYPE
        SYNTAX SlsScopeParamEntry
        STATUS current
        DESCRIPTION
             "This PRC uniquely identifies the geographical/topological 
              region over which the QoS is to be enforced by indicating 
              the boundaries of that region."
        ::= { slsScopeParamTable 1 }

   slsScopeParamEntry ::= SEQUENCE {
        SlsScopeParamPrid      Prid
        slsScopeParamId TagReferenceId
   }

   slsScopeParamPrid OBJECT-TYPE 
       SYNTAX       InstanceId 
       STATUS       current 
       DESCRIPTION 
          "An arbitrary integer index that uniquely identifies an 
           instance of the class." 
       ::= { slsScopeParamEntry 1 } 





Nguyen, et al.               Expires January 2003              [Page 19]
Internet Draft                    COPS-SLS                     July 2002


   slsScopeParamId OBJECT-TYPE 
       SYNTAX       TagReferenceId 
       PIB-TAG      {slsScopeIfParamId} 
       STATUS       current 
       DESCRIPTION 
          "Identifies an SLS Scope." 
       ::= { slsScopeParamEntry 2 } 

   slsScopeIfParamTable OBJECT-TYPE
        SYNTAX SEQUENCE OF slsScopeInterfaceParamEntry
        PIB-ACCESS install-notify
        STATUS current
        DESCRIPTION
             "The entry points (interfaces) of the IP packets relative 
              to the region (network)."
        ::= { slsParamClasses 2 }

   slsScopeIfParamEntry OBJECT-TYPE
        SYNTAX SlsScopeIfParamEntry
        STATUS current
        DESCRIPTION
             An entry in the scope interface table describes a single 
             interface of the scope. 
        ::= { slsScopeIfParamTable 1 }   

   slsScopeIfParamEntry ::= SEQUENCE {
        SlsScopeIfParamPrid        Prid
        slsScopeIfParamId          TagId
        slsScopeIfParamIfIndex     InterfaceIndex
        slsScopeIfParamDirection   BITS
   }

   slsScopeIfParamPrid OBJECT-TYPE
        SYNTAX Prid
        STATUS current
        DESCRIPTION
             "An arbitrary integer index that uniquely identifies an 
             instance of the class."
        ::= { slsScopeIfParamEntry 1 }

   slsScopeIfParamId OBJECT-TYPE
        SYNTAX TagId
        STATUS current
        DESCRIPTION
             "An SLS Scope is composed of one or more entry/exit 
             points. Each interface belonging to the same scope uses the 
             same Scope ID. Hence, A scope Id identifies which scope 
             this interface is a part of. This needs to be the value of 





Nguyen, et al.               Expires January 2003              [Page 20]
Internet Draft                    COPS-SLS                     July 2002


             slsScopeParamId attribute for an existing instance of 
             slsScopeParamEntry."
        ::= { slsScopeIfParamEntry 2 }

   slsScopeIfParamIfIndex OBJECT-TYPE
        SYNTAX InterfaceIndex
        STATUS current
        DESCRIPTION
             " This value contains the interface index of the entry/exit 
             interface."
        ::= { slsScopeIfParamEntry 3 }

   slsScopeIfParamDirection OBJECT-TYPE
        SYNTAX BITS{
                      ingress (0)
                      egress (1)
                    }
        STATUS current
        DESCRIPTION
             " This attribute specifies whether the interface is an 
             entry point (ingress) or an exit point (egress) of the SLS 
             scope."
        ::= { slsScopeIfParamEntry 4 }

   slsFlowIdParamTable OBJECT-TYPE
       SYNTAX SEQUENCE OF slsFlowIdParamEntry
       PIB-ACCESS install-notify
       STATUS current
       DESCRIPTION
            "This class specifies parameters identifying a traffic 
            stream"   
       ::= { slsParamClasses 3 }

   slsFlowIdParamEntry OBJECT-TYPE
        SYNTAX SlsFlowIdParamEntry
        STATUS current
        DESCRIPTION
            "The instance of this class identifies a traffic stream"
        ::= { slsFlowIdParamTable 1 }

  SlsFlowIdParamEntry ::= SEQUENCE{
        slsFlowIdParamPrid            InstanceId
        slsFlowIdParamAddrType        InetAddressType,
        slsFlowIdParamDstAddr         InetAddress,
        slsFlowIdParamDstPrefixLength InetAddressPrefixLength
        slsFlowIdParamSrcAddr         InetAddress,
        slsFlowIdParamSrcPrefixLength InetAddressPrefixLength,
        slsFlowIdParamDscp            DscpOrAny,





Nguyen, et al.               Expires January 2003              [Page 21]
Internet Draft                    COPS-SLS                     July 2002


        slsFlowIdParamFlowLable       Unsigned32,
        slsFlowIdParamProtocol        Integer32,
        slsFlowIdParamDstL4PortMin    InetPortNumber,
        slsFlowIdParamDstL4PortMax    InetPortNumber,
        slsFlowIdParamSrcL4PortMin    InetPortNumber,
        slsFlowIdParamSrcL4PortMax    InetPortNumber
   }

   slsFlowIdParamPrid OBJECT-TYPE
        SYNTAX     InstanceId
        STATUS     current
        DESCRIPTION
             "An arbitrary integer index that uniquely identifies an
             instance of the class"   
        ::= { slsFlowIdParamEntry 1 } 
  
   slsFlowIdParamAddrType  OBJECT-TYPE
        SYNTAX      InetAddressType
        STATUS      current
        DESCRIPTION
             "Specify the type of packet's IP address."
        ::= { slsFlowIdParamEntry 2 }

   slsFlowIdParamDstAddr OBJECT-TYPE
        SYNTAX         InetAddress
        STATUS         current
        DESCRIPTION
             "The IP address of the packet's destination."
        ::= { slsFlowIdParamEntry 3 }

   slsFlowIdParamDstPrefixLength  OBJECT-TYPE
        SYNTAX         InetAddressPrefixLength
        STATUS         current
        DESCRIPTION
             "The length of a mask for the matching of the destination 
             IP address. The value of 0 indicates that the address 
             always matches."
        ::= { slsFlowIdParamEntry 4 }

   slsFlowIdParamSrcAddr OBJECT-TYPE
        SYNTAX       InetAddress
        STATUS         current
        DESCRIPTION
             "The IP address of the packet's source."
        ::= { slsFlowIdParamEntry 5 }

   slsFlowIdParamSrcPrefixLength OBJECT-TYPE
        SYNTAX       InetAddressPrefixLength
 




Nguyen, et al.               Expires January 2003              [Page 22]
Internet Draft                    COPS-SLS                     July 2002


        STATUS       current
        DESCRIPTION
             "The length of a mask for the matching of the destination 
             IP address. A value of 0 indicates that the address always 
             matches."
        ::= { slsFlowIdParamEntry 6 }

   slsFlowIdParamDscp OBJECT-TYPE
        SYNTAX        DscpOrAny
        STATUS        current
        DESCRIPTION
             "The DSCP value of the packet. A value of 1 indicates that 
              DSCP value has not been defined."
        ::= { slsFlowIdParamEntry 7 }

   slsFlowIdParamFlowLable OBJECT-TYPE
        SYNTAX      Unsigned32
        STATUS      current
        DESCRIPTION
             "The value of the Flow Label field in IPv6 header."
        ::= { slsFlowIdParamEntry 8 }

   slsFlowIdParamProtocol OBJECT-TYPE
        SYNTAX       Integer32
        STATUS       current
        DESCRIPTION
             "The value of the Protocol field in IP header."
        ::= { slsFlowIdParamEntry 9 }

   slsFlowIdParamDstL4PortMin OBJECT-TYPE
        SYNTAX       InetPortNumber
        STATUS       current
        DESCRIPTION
             "The minimum value that the packet's layer 4 destination 
             port number can have."
        ::= { slsFlowIdParamEntry 10 }

   slsFlowIdParamDstL4PortMax OBJECT-TYPE
        SYNTAX       InetPortNumber
        STATUS       current
        DESCRIPTION
             "The maximum value that the packet's layer 4 destination 
             port number can have."
        ::= { slsFlowIdParamEntry 11 }

   slsFlowIdParamSrcL4PortMin OBJECT-TYPE
        SYNTAX       InetPortNumber
        STATUS       current





Nguyen, et al.               Expires January 2003              [Page 23]
Internet Draft                    COPS-SLS                     July 2002


        DESCRIPTION
             "The minimum value that the packet's layer 4 source port 
             number can have."
        ::= { slsFlowIdParamEntry 12 }

   slsFlowIdParamSrcL4PortMax  OBJECT-TYPE
        SYNTAX      InetPortNumber
        STATUS      current
        DESCRIPTION
             "The minimum value that the packet's layer 4 source port 
             number can have."
        ::= { slsFlowIdParamEntry 13 }

 slsConformParamTable OBJECT-TYPE
        SYNTAX SEQUENCE OF slsConformParamEntry
        PIB-ACCESS install-notify
        STATUS current
        DESCRIPTION
             "This class defines the traffic conformance of a traffic 
             stream."
        ::= { slsParamClasses 4 }

   slsConformParamEntry OBJECT-TYPE
        SYNTAX SlsConformParamEntry
        STATUS current
        DESCRIPTION
            "The instance of this class specifies algorithm and profile 
            to verify the conformance of a traffic stream"
        ::= { slsConformParamTable 1 }

   SlsConformParamEntry ::= SEQUENCE {
        slsConformParamPrid     InstanceId
        slsConformParamAlgo     Unsigned32
        slsConformParamRate     Unsigned32
        slsConformParamBurstSize Unsigned32
   }

   slsConformPrid OBJECT-TYPE
        SYNTAX      InstanceId  
        STATUS      current
        DESCRIPTION
             "An arbitrary integer that uniquely identifies an instance
              of the class." 
        ::= { slsConformParamEntry 1 }  

   slsConformParamAlgo  OBJECT-TYPE
        SYNTAX      Unsigned32
        STATUS      current





Nguyen, et al.               Expires January 2003              [Page 24]
Internet Draft                    COPS-SLS                     July 2002


        DESCRIPTION
             "Specify the algorithm used to verify the conformance of 
             the traffic stream.
              1 - Simple Token Bucket"
        ::= { slsConformParamEntry 2 }

   slsConformParamRate  OBJECT-TYPE
        SYNTAX      Unsigned32
        STATUS      current
        DESCRIPTION
             "The rate value used in Simple Token Bucket algorithm."
        ::= { slsConformParamEntry 3 }

   slsConformParamBurstSize OBJECT-TYPE
        SYNTAX      Unsigned32
        STATUS      current
        DESCRIPTION
             "The burst size value used in Simple Token Bucket 
             algorithm."
        ::= { slsConformParamEntry 4 }

   slsExcTreatParamTable OBJECT-TYPE
        SYNTAX SEQUENCE OF slsExcTreatParamEntry
        PIB-ACCESS install-notify
        STATUS current
        DESCRIPTION
             "This class specifies parameters of schedule of service"
        ::= { slsParamClasses 5 }

   slsExcTreatParamEntry OBJECT-TYPE
        SYNTAX SlsExctreatParamEntry
        STATUS current
        DESCRIPTION
            "The instance of this class identifies a traffic stream"
        ::= { slsExcTreatParamTable 1 }

   SlsExcTreatParamEntry ::= SEQUENCE {
        slsExcTreatParamPrid   InstanceId
        slsExcTreatParamAction BITS
   }

   slsExcTreatParamPrid OBJECT-TYPE
        SYNTAX      InstanceId  
        STATUS      current
        DESCRIPTION
             "An arbitrary integer that uniquely identifies an instance
              of the class." 
        ::= { slsExcTreatParamEntry 1 }





Nguyen, et al.               Expires January 2003              [Page 25]
Internet Draft                    COPS-SLS                     July 2002


   slsExcTreatParamAction OBJECT-TYPE
        SYNTAX      BITS{
                    shapping(1)
                    -- traffic exceeding the conformance parameters
                       negotiated will be shaped.
                    dropping (2)
                    -- traffic exceeding the conformance parameters
                       negotiated will be dropped
               }
        STATUS      current
        DESCRIPTION
             "Specify the treatment applied to the packet out of the 
             data stream's conformance negotiated
             (1)  shapping exceeding traffic
             (2)  dropping exceeding traffic"
        ::= { slsExcTreatParamEntry 2 }

   slsPerformanceParamTable OBJECT-TYPE
        SYNTAX SEQUENCE OF slsPerformanceParamEntry
        PIB-ACCESS install-notify   
        STATUS current
        DESCRIPTION
             "This class specifies parameters of performance of a flow"
        ::= { slsParamClasses 6 }

   slsPerformanceParamEntry  OBJECT-TYPE
        SYNTAX SlsPerformanceParamEntry
        STATUS current
        DESCRIPTION
             "Describes performance parameters of a flow"
        ::= { sls PerformanceParamTable 1 }

   SlsPerformanceParamEntry ::= SEQUENCE {
        slsPerformanceParamPrid       InstanceId
        slsPerformanceParamDelay      Unsigned32
        slsPerformanceParamJitter     Unsigned32
        slsPerformanceParamPacketLoss Unsigned32
   }

   slsPerformanceParamPrid OBJECT-TYPE
        SYNTAX      InstanceId  
        STATUS      current
        DESCRIPTION
             "An arbitrary integer that uniquely identifies an instance
              of the class." 
        ::= { slsPerformanceParamEntry 1 }
   
   slsPerformanceParamDelay OBJECT-TYPE





Nguyen, et al.               Expires January 2003              [Page 26]
Internet Draft                    COPS-SLS                     July 2002


        SYNTAX Unsigned32        
        STATUS current
        DESCRIPTION
             "Specifies the delay value in milisecond"
        ::= { slsPerformanceParamEntry 2 }

   slsPerformanceParamJitter OBJECT-TYPE
        SYNTAX Unsigned32
        STATUS current
        DESCRIPTION
             "Specifies the jitter value in milisecond"
        ::= { slsPerformanceParamEntry 3 }

   slsPerformanceParamPacketLoss OBJECT-TYPE
        SYNTAX Unsigned32
        STATUS current
        DESCRIPTION
             "Specifies the packet loss ratio in %"
        ::= { slsPerformanceParamEntry 4 }

   slsScheduleParamTable OBJECT-TYPE
        SYNTAX       SEQUENCE OF slsScheduleParamEntry
        PIB-ACCESS   install-notify
        STATUS       current
        DESCRIPTION
             "This class specifies parameters of schedule of service"
        ::= { slsParamClasses 7}

   slsScheduleParamEntry OBJECT-TYPE
        SYNTAX SlsScheduleParamEntry
        STATUS current
        DESCRIPTION
             "Specifies a service schedule"
        ::= { slsScheduleParamTable 1 }

   SlsScheduleParamEntry ::= SEQUENCE {
        slsScheduleParamPrid      InstanceId
        slsScheduleParamStartTime ExtUTCTime
        slsScheduleParamStopTime  ExtUTCTime
   }

   slsScheduleParamPrid OBJECT-TYPE
        SYNTAX      InstanceId  
        STATUS      current
        DESCRIPTION
             "An arbitrary integer that uniquely identifies an instance
              of the class." 
        ::= { slsScheduleParamEntry 1 }





Nguyen, et al.               Expires January 2003              [Page 27]
Internet Draft                    COPS-SLS                     July 2002


   slsScheduleParamStartTime OBJECT-TYPE
        SYNTAX ExtUTCTime
        STATUS current
        DESCRIPTION
             "The time the service starts"
        ::= { slsScheduleParamEntry 2 }

   slsScheduleParamStopTime OBJECT-TYPE
        SYNTAX ExtUTCTime
        STATUS current
        DESCRIPTION
             "The time the service terminate"
        ::= { slsScheduleParamEntry 3 }

   slsNegoRptTable OBJECT-TYPE
        SYNTAX     SEQUENCE OF SlsNegoRptEntry
        PIB-ACCESS report-only
        STATUS     current
        DESCRIPTION
             "This class is used by the PEP to convey negotiation 
             information in RPT message"
        ::= { slsReportClasses 1 }

   slsNegoRptEntry OBJECT-TYPE
        SYNTAX     SlsNegoRptEntry
        STATUS     current
        DESCRIPTION
             "An instance of this class reports on the SLS negotiation"
        ::= { slsNegoRptTable 1 }

   SlsNegoRptEntry ::= SEQUENCE {
        slsNegoRptPrid   InstanceId
        slsNegoRptFailRea BITS
   }

   slsNegoRptPrid OBJECT-TYPE
        SYNTAX    InstanceId
        STATUS    current
        DESCRIPTION
             "An arbitrary integer that uniquely identifies an instance 
             of the class"
        ::= { slsNEgoRptEntry 1 }

   slsNegoRptFailRea OBJECT-TYPE
        SYNTAX    BITS {
                      slsNonAccepted (1) 
                  }
        STATUS    current





Nguyen, et al.               Expires January 2003              [Page 28]
Internet Draft                    COPS-SLS                     July 2002


        DESCRIPTION
             "This attribute specifies the reason by which the PEP sends
             a 'failure' report
             (1)  the PEP does not accept the SLS suggested"
        ::= { slsNEgoRptEntry 1 }

   END.

7. Security Considerations

   COPS-SLS follows the security considerations for COPS protocol [COPS]

8. IANA Consideration

   The client-type value of COPS-SLS is to be assigned through IANA.

9. Acknowledgements

   We would like to acknowledge ours friends from LIP6 or INFRES-ENST 
   for their comments and discussions during the preparation of this 
   document.

10. 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-08.txt, January 2002, 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.





Nguyen, et al.               Expires January 2003              [Page 29]
Internet Draft                    COPS-SLS                     July 2002


                 Thomas, F. Fuenfstueck, T. Ziegler, C. Brandauer, 
                 "Definition and usage of SLSs in the AQUILA 
                 consortium", draft-salsano-aquila-sls-00.txt, November
                 2000, Work in pogress.

   [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.

   [SESSION-AUTH]L-N. Hamer, B. Gage, "Framework for session setup with 
                 media authorization", Internet-Draft, draft-ietf-rap-
                 session-auth-03.txt, June 2002, Work in progress.

   [COPS-FRWK]   K. Chan, L-N. Hamer, "An Architecture for COPS Based
                 Policy Control Management Framework COPS Framework, 
                 draft-ietf-rap-cops-frwk-01.txt, June 2002, work in 
                 progress.

   [SMIv2]       K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, 
                 K. McCloghrie, M. Rose, S. Waldbusser, " Structure of 
                 Management Information Version 2 (SMIv2)", RFC 2578, 
                 April 1999.

   [INET-ADDR]   M. Daniele, B. Haberman, S. Routhier and J.
                 Schoenwaelder, "Textual Conventions for Internet 
                 Network Addresses", draft-ietf-ops-rfc2851-update-
                 06.txt, December 2001.

12. 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
   Department Informatique-Reseaux





Nguyen, et al.               Expires January 2003              [Page 30]
Internet Draft                    COPS-SLS                     July 2002


   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.el_mghazli@alcatel.fr

   Nathalie Charton
   Alcatel R&I
   Route de Nozay
   F-91460 Marcoussis - FRANCE
   Phone: +33 1 69 63 14 85
   Email: Nathalie.Charton@ms.alcatel.fr 

   Louis-Nicolas Hamer 
   Nortel Networks 
   Ottawa, Canada 
   Email: nhamer@nortelnetworks.com

   Guy Pujolle 
   University of Pierre et Marie Curie
   Laboratoire d'Informatique de Paris 6
   8 Rue du Capitaine Scotte
   75015 Paris - FRANCE
   Phone: +33 1 44 27 75 14
   Email: Guy.Pujolle@lip6.fr 

12. 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.




Nguyen, et al.               Expires January 2003              [Page 31]
Internet Draft                    COPS-SLS                     July 2002


   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 January 2003              [Page 32]