Internet Draft                                             T.M.T. Nguyen
Expires December 2001                                         G. Pujolle
                                                   University of Paris 6
                                                            N. Boukhatem
                                                              ENST Paris
                                                               June 2001


             COPS Usage for SLS negotiation (COPS-SLS)
                 <draft-nguyen-rap-cops-sls-00.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. 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 December 2001               [Page 1]

Internet Draft                    COPS-SLS                     June 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 example.....................................11
   7. Security Considerations.........................................14
   8. Acknowledgements................................................14
   9. References......................................................15
   10. Authors' Addresses.............................................16
   11. Full Copyright Statement.......................................16

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 December 2001              [Page 2]

Internet Draft                   COPS-SLS                      June 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 December 2001              [Page 3]

Internet Draft                   COPS-SLS                      June 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 a SLS-PDP accepts a 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 a 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 a SLS using the
   Outsourcing model. (See more information in section 5)



Nguyen, et al.               Expires December 2001              [Page 4]

Internet Draft                    COPS-SLS                     June 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:

               <Request> ::= <Common Header>
                             <Client Handle>
                             <Context>
                             *(<Named ClientSI>)
                             *(<Signaled 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 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:

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

              <Decision> ::= <Context>
                             <Decision Flags>
                             *(<Named Decision Data>)
                             *(<Client Specific 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 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 December 2001              [Page 5]

Internet Draft                    COPS-SLS                     June 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:

               <Report State> ::= <Common Header>
                                  <Client Handle>
                                  <Report Type>
                                  *(<Named ClientSI>)
                                  *(<Signaled 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.

   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 a 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 December 2001              [Page 6]

Internet Draft                    COPS-SLS                     June 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 December 2001              [Page 7]

Internet Draft                    COPS-SLS                     June 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 (not defined in this document)   |
          |                                                    |
          |<---------------------------------------------------|(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 (not defined in this document)|
          |                                                    |





Nguyen, et al.               Expires December 2001              [Page 8]

Internet Draft                    COPS-SLS                     June 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 (not defined in this document)   |
          |                                                    |
          |<---------------------------------------------------|(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 December 2001              [Page 9]

Internet Draft                    COPS-SLS                     June 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 a 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 a SLS conforming to one of
   these predefined SLSs. The PEP MUST NOT request a SLS outside these
   predefined SLSs. 
 
   In non-predefined SLS mode, the PEP CAN request a 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 December 2001              [Page 10]

Internet Draft                    COPS-SLS                     June 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 example:

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

   IMPORTS
        Unsigned32, InstanceId, MODULE-IDENTITY, OBJECT-TYPE
             FROM COPS-PR-SPPI
        
   slsPolicyPib MODULE-IDENTITY
        SUBJECT-CATEGORIES { tbd - COPS-SLS Client Type }
        LAST-UPDATED "200106111200Z"
        ORGANIZATION "University of Paris 6 and ENST Paris"
        CONTACT-INFO "
                      Thi Mai Trang Nguyen
                      INFRES-ENST
                      46 Rue Barrault
                      75013 Paris - France
                      Phone: +33 -0 1 45 81 74 61
                      Email: trnguyen@enst.fr

                      Guy Pujolle
                      RP-LIP6-UPMC
                      8 Rue du Capitaine Scott
                      75015 Paris - France
                      




Nguyen, et al.              Expires December 2001              [Page 11]

Internet Draft                    COPS-SLS                     June 2001


                      Phone: +33 รป0 1 44 27 75 14
                      Email: Guy.Pujolle@lip6.fr

                      Nadia Boukhatem
                      INFRES-ENST
                      46 Rue Barrault
                      75013 Paris - France
                      Phone: +33 -0 1 45 81 82 16
                      Email: Nadia.BouKhatem@enst.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 }

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

   



Nguyen, et al.              Expires December 2001              [Page 12]

Internet Draft                    COPS-SLS                     June 2001


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
        PIB-ACCESS   install
        STATUS       current
        DESCRIPTION
             "SLS negotiation policies to be installed by the PDP"
        ::= { slsPolicyClasses 2 }

   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 }
        
   


Nguyen, et al.              Expires December 2001              [Page 13]

Internet Draft                    COPS-SLS                     June 2001

   
   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 }
   
   END

   This SLS-NEGOTIATION-PIB is not yet in a final version. It is only a
   PIB example for this document. Classes and attributes can be added or
   modified in the future. For example, the slsNegoRole class which
   indicates the role of the SLS client (e.g., DS domain, subnet 
   gateway, end host...) is under study.

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.





Nguyen, et al.              Expires December 2001              [Page 14]

Internet Draft                    COPS-SLS                     June 2001


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-04.txt, March 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 
                 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-00.txt,
                 November 2000, Work in progress.

   





Nguyen, et al.              Expires December 2001              [Page 15]

Internet Draft                    COPS-SLS                     June 2001


[SPPI]           K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn,
                 R. Sahita, A. Smith, F. Reichmeyer, "Structure of
                 Policy Provisioning Information SPPI", draft-ietf-rap-
                 sppi-07.txt, May 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) (-0)1 45 81 74 61
   Email: trnguyen@enst.fr 

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

   Nadia Boukhatem 
   Ecole Nationale Superieure des Telecommunications
   Departement Informatique-Reseaux
   46 Rue Barrault
   74013 Paris - FRANCE
   Phone: (+33) (-0)1 45 81 82 16
   Email: Nadia.Boukhatem@enst.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
   




Nguyen, et al.              Expires December 2001              [Page 16]

Internet Draft                    COPS-SLS                     June 2001


   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 December 2001              [Page 17]