INTERNET DRAFT                                          Jeremy De Clercq
<draft-declercq-ppp-ds-sla-negotiation-00.txt>        Peter De Schrijver
                                                         Carmelo Zaccone
                                                            Yves T'Joens
                                                                 Alcatel

                                                              March 2000
                                                 Expires September, 2000

                      PPP Diffserv SLA Negotiation


Status of this Memo

   This document is an Internet-Draft and is in  full  conformance  with
   all provisions of Section 10 of RFC2026.

   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.  Internet-Drafts  may  be  updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use  Internet-
   Drafts  as  reference  material  or  to  cite  them  other  than as a
   ``working draft'' or ``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.



   To view the entire list of current Internet-Drafts, please check  the
   "1id-abstracts.txt"  listing  contained in the Internet-Drafts Shadow
   Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
   ftp.nis.garr.it   (Southern   Europe),   munnari.oz.au(Pacific  Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.


Abstract

   This draft defines extensions to IPCP to  allow  dynamic  negotiation
   and  re-negotiation  of a Diffserv-based Service Level Specification.
   This is achieved by introducing a new IPCP Option, and the concept of
   Suboption negotiation.

1. Introduction

   Of all the  emerging  QoS  frameworks,  the  Differentiated  Services
   (Diffserv)  framework  [DSFRAM]  is  widely considered to be the most
   scaleable approach towards QoS provisioning in the Internet.   It  is



De Clercq, et al.        Expires September 2000                 [Page 1]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   therefore  assumed in this document that at least the core of the ISP
   network will be managed according to the Diffserv framework.

   Quality of  Service  (QoS)  expectations  are  driving  customers  to
   negotiate  guarantees  with  their Service Provider about the offered
   services.  A Service Level Specification  is  a  contract  between  a
   provider   and   a   customer  that  guarantees  specific  levels  of
   performances  and  reliability  at  a  certain  cost.   The  contract
   specifies  the 'services' that a customer will have access to, and on
   the other hand it specifies what the service provider can expect from
   its customers in terms of workload and resource usage.

   This document concentrates on the specification of guarantees  solely
   on  the  IP  transport  layer,  not  on the application level.  As we
   assume that the Diffserv framework is used to provision  QoS  in  the
   ISP  network,  the  SLS  format  used  in  this  document will define
   services in terms of Diffserv terminology.

   Since it is assumed that the vast majority of  access  configurations
   use PPP [PPP], and that PPP is mandatory for roaming operations, this
   document  defines  a  PPP  IPCP  extension   allowing   the   dynamic
   negotiation and re-negotiation of a Diffserv-based SLS [DSFRAM].

   The next section will focus on  the  formal  format  of  a  SLS,  and
   section 3 will focus on the IPCP extensions.

1.1 Conventions

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

2. Formal Format of the Service Level Specification

   This section defines the formal format of a  customer  Service  Level
   Specification in a Diffserv environment.

   Service  providers  may  not  only  offer  guarantees  in  terms   of
   availability,  but also offer performance guarantees such as latency,
   throughput, etc.

   A 'Service' as it is defined in this document  may  be  specified  by
   means of 6 different parameters.  If the SLS does not specify all the
   6 parameters, the unspecified  parameters  will  be  set  to  default
   values. The 6 parameters defined in this document are:

   The Diffserv Codepoint associated with the Service




De Clercq, et al.        Expires September 2000                 [Page 2]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


      As it is currently defined, Diffserv describes two different  Per-
      Hop  Behaviours:  Expedited  Forwarding  (EF)  [EF]  as a 'virtual
      leased line' and Assured Forwarding (AF)  [AF].   IP  packets  are
      differentiated by means of the DSCP field in the IP header.

   The Conformance Agreement

      The Conformance Agreement is an agreement between the customer and
      the   Service  Provider  on  a  measurable  specification  of  the
      considered IP traffic.  A model must be negotiated to characterize
      the  traffic flow.  One could for example use a Token Bucket model
      to define the 'bandwidth'  in  the  Conformance  Agreement.   This
      document  uses  the  two-parameter  single bucket model for the EF
      conformance agreement and the Two-Rate Three  Color  Marker  model
      for  the  AF  conformance agreement (4 token bucket parameters and
      one parameter distinguishing  between  colorblindness  and  color-
      awareness)  [trTCM] as an example.  Many more types of Conformance
      Agreements may be added over time.

   The Characteristics of the Service

      This document identifies the following characteristics for the two
      defined services:


         The Maximum Delay.  This characteristic defines how  much  time
         (in  ms) it may take for a packet to get from the ingress point
         to the egress point.

         The Maximum Jitter.  More than one definition can be  used  for
         this  characteristic.   It  may  for example define the maximum
         difference between the longest and the shortest delay  in  some
         period   of  time.   Or  it  could  define  the  maximum  delay
         difference between two consecutive packets in  some  period  of
         time.  The definition to be used in this document is FFS.

         The Loss Probability.  This characteristic defines the fraction
         of all the packets that do not arrive at their destination.

      See also [IPPM_1] for details  on  how  one-way  delays  could  be
      qualified.   Related  documents [IPPM_2][IPPM_3] explain how other
      characteristics could be qualified.

   The Scope of the Service

      The Scope of the service defines a (set of) location(s)  that  are
      allowed  to send traffic matching the concerned service, and a set
      of locations that are allowed  to  receive  traffic  matching  the



De Clercq, et al.        Expires September 2000                 [Page 3]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


      concerned  service.   A set of physical locations can be specified
      by means of IP-addresses, by means of IP subnetwork  addresses  or
      prefixes, or by means of Autonomous System Numbers.

   The Availability of the Service

      The Availability of the service defines the period of time  during
      which  the  concerned service may be used.  It can be expressed by
      different types of time-ranges.  Every Range of time is  specified
      by a start moment and a stop moment.  This document uses a Time of
      the Day Range (specified by a start and stop time of the  day),  a
      Day  of  the  Week Range (specified by a start and stop day of the
      week), a Month of the Year Range (specified by a  start  and  stop
      month  of  the  year),  and a Year Range (specified by a start and
      stop year).  In every time-related specification, the UTC must  be
      used to avoid possible confusion.

   The Excess Treatment

      The Excess treatment defines the actions (in Diffserv terminology)
      that  will  be undertaken by the Service Provider when the traffic
      contract is violated.  This document handles  3  different  Excess
      treatments:

         Dropping the excessive traffic.

         Shaping the excessive traffic.

         Remarking the excessive traffic.  When the excessive traffic is
         being  remarked (assigned to another, lower service level), the
         new service level used must be specified.  For convenience, the
         Service Provider can define a default treatment.

3. IPCP Extensions

3.1 Summary of Operation

   The formal process of the negotiation scheme does not differ from the
   conventional  PPP  IPCP  [IPCP]  negotiation  scheme.   This document
   defines a new IPCP  Option,  the  SLS  IPCP  option  (representing  a
   certain  'service'),  and  defines  SLS  Suboptions for that IPCP SLS
   Option (representing the parameters associated with that  'service').
   This   document   also   extends   the  negotiation  scheme  allowing
   negotiation about SLS Suboptions.

   The basic operation will be that a PPP peer that requires negotiation
   about  a  SLS  will  send  an  IPCP  CONFREQ  including a list of SLS
   options.  Every SLS Option will contain a certain  service  the  peer



De Clercq, et al.        Expires September 2000                 [Page 4]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   wants to have access to.  The receiving PPP peer will analyse all the
   included options.  After parsing an SLS  Option,  the  receiving  PPP
   peer can make the following decisions:

      It can reject the whole  SLS  Option,  because  it  doesn't  allow
      negotiation about SLSs, resulting in an IPCP CONFREJ message.

      It can reject some of the SLS parameters (suboptions),  associated
      with  a certain SLS option (service) because it doesn't understand
      some of the inserted suboptions or Service  Parameters,  resulting
      in an IPCP CONFREJ message.

      It can accept the SLS option, but not agree on the values of  some
      of  the  related parameters, resulting in an IPCP CONFNAK message,
      giving suggestions about appropriate values for the  not  accepted
      parameters.

      And finally it can accept the SLS Option and agree about  all  the
      included  parameters,  resulting  in  an  ACK  for that SLS Option
      (service).  When all the IPCP Options are  ACK'ed,  the  resulting
      IPCP  message  will  be  a  CONFACK  message, which terminates the
      negotiation.

3.2 Message Formats

3.2.1 IPCP Message Format

      Like any other PPP-message, an IPCP-message contains the following
      fields:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         PPP Protocol          |  Code Field   |    ID Field   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       PPP Length Field        | Opt Typ Field | Opt Len Field |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Option Data Field                      |
      |                               ...                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Opt Typ Field | Opt Len Field |      Option Data Field        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Option Data Field                      |
      |                               ...                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               ...                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




De Clercq, et al.        Expires September 2000                 [Page 5]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   PPP Protocol:

      This 2-octet field contains the  PPP  Protocol  Number.   The  PPP
      Protocol Number for IPCP is 0x8021.

   Code Field:

      This 1-octet field contains the Code Number,  that  differentiates
      the  different  kinds  of  negotiation messages. Configure-Request
      messages have a Code Number 01, Configure-Ack messages have a Code
      Number  02,  Configure-Nak  messages  have  a  Code  Number 03 and
      Configure-Reject messages have a Code Number 04.

   ID Field:

      This  1-octet  field  contains  the  Identification  Number  of  a
      negotiation  attempt.   Every new Configure-Request will receive a
      new Identification Number.

   PPP Length Field:

      This 2-octet field represents the total  length  of  the  message,
      including the four-octet IPCP header and all of the Options.

   Opt Type Field:

      This 1-octet field contains the Option Type Number that identifies
      the  type  of  the  considered  option  that  is  included  in the
      negotiation message.  Examples of existing  IPCP-options  are  the
      IP-Addresses  Option  (Opt  Type Field 01) and the IP-Compression-
      Protocol Option (Opt Type Field 02).

   Opt Len Field:

      This 1-octet field represents the length of the considered option,
      including the 2-octet header.

   Option Data Field:

      This variable length field contains the information for the option
      being negotiated.

3.2.2 IPCP SLS Option

   This  document  defines  a  new  IPCP  option:  the   Service   Level
   Specification (SLS) Option.  The Option Type Number to include in the
   Opt Type Field must be standardized (SLS Option Type).  The format of
   the  SLS  Option is the conventional <Opt Type Field> <Opt Len Field>



De Clercq, et al.        Expires September 2000                 [Page 6]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   <Option Data Field> format:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SLS Option    |Len SLS Option |    Service Parameters ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SLS Option:

      This 1-octet field contains the IPCP SLS Option Type number to  be
      standardized.

   Len SLS Option:

      This 1-octet field represents the length  of  the  considered  SLS
      Option,  including  the  2-octet  header  (SLS  Option and Len SLS
      Option) and all the included Service Parameters for the considered
      SLS Option.

   Service Parameters:

      This variable length field contains  all  the  service  parameters
      that  are  included  for  the  considered  negotiated  SLS  Option
      (service).  The Service Parameters field consists  of  a  list  of
      variable  length  Service  Parameters.   Every SLS Option may have
      some  mandatory  Service  Parameters  and  some  optional  Service
      Parameters.   Not  specified  optional  Service Parameters must be
      interpreted according to specific default values defined  in  this
      document.  Every Service Parameter is defined as a <type> <length>
      <value> block:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Param Type   | Len Ser Param |   Value Service Param ...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Param Type:

         This 1-octet field identifies a  Service  Parameter  associated
         with the considered SLS Service.

      Len Ser Param:



De Clercq, et al.        Expires September 2000                 [Page 7]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


         This 1-octet field represents  the  length  of  the  considered
         Service  Parameter,  including  the 2-octet header (Param Type,
         Len Ser Param).

      Value Service Param:

         This variable length field contains  the  information  for  the
         considered Service Parameter.


3.2.2.1 Service Parameters

   This document defines the  following  Service  Parameters  associated
   with the negotiated services:

   The Service Identifier (Parameter Type 00)

      The Service Identifier Parameter (Service ID) uniquely  identifies
      a   specific   service   that   is  being  negotiated.   That  per
      negotiation-unique Service Identifier must be used to refer  to  a
      specific service.  The Service ID is a MANDATORY Service Parameter
      with a 1-octet information  field  (Value  Service  Param).   This
      means the total length of the Service ID Parameter (Len Ser Param)
      is 3 octets.

   The Diffserv Codepoint (Parameter Type 05)

      The Diffserv Codepoint Parameter defines  the  Diffserv  Codepoint
      that  must  be used in the IP header of the IP packets that belong
      to the considered negotiated service.  The Diffserv Codepoint is a
      MANDATORY  Service  Parameter  with  a  1-octet  information field
      (Value Service Param).  This means that the total  length  of  the
      Diffserv  Codepoint  Parameter  (Len  Ser Param) is 3 octets.  The
      first 6 bits of the Diffserv Codepoint information field represent
      the DSCP, the last 2 bits are currently unused and set to zero.

   The Conformance Agreement (Parameter Type 10):

      The Conformance Agreement specifies the way the traffic flow  will
      be modelled.  It is a variable length MANDATORY Service Parameter.
      The format of the information field of the  Conformance  Agreement
      Service  Parameter  is  of the <type> <value> - type.  The 1-octet
      Type field defines which traffic flow model is to be used, and the
      Value  field contains the parameters needed for the specified flow
      model.  It is by means of the Conformance Agreement Parameter that
      the  throughput  of  the  flow is characterized.  A lot of traffic
      flow models can be used as a Conformance Agreement, this  document
      defines two of them:



De Clercq, et al.        Expires September 2000                 [Page 8]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


      A Single Bucket Model as an example to characterize the  bandwidth
      of a 'virtual leased line' (EF traffic).

         The Single Bucket Model (Conformance Agreement Type 00) defines
         two  parameters: the Token Bucket Rate (in bits per second) and
         the Token Bucket Size (in bits).  The information field of  the
         Conformance  Agreement Service Parameter constists of a 1-octet
         type field, defining the Single Bucket Model, and of a  4-octet
         Value  field:  the  first  2 octets containing the Token Bucket
         Rate and the last 2 octets containing the  Token  Bucket  Size.
         Both Token Bucket Parameters are encoded as an 11-bits mantissa
         field, followed by a 5-bits exponent field.  The value  of  the
         Token   Bucket   Parameters  is  calculated  as:  <mantissa>  x
         2^<exponent>.  The  format  and  encoding  of  the  Conformance
         Agreement  Service  Parameter using the Single Bucket Model are
         as follows:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x10      | Len Conf Agr  |  Type: 0x00   |    TB Rate    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    TB Rate    |            TB Size            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         The encoding of the Token Bucket Rate and of the  Token  Bucket
         Size is as follows:
          0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       mantissa      |   exp   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         For example, a Token Bucket Rate of 5 kbit per second  will  be
         encodes as (5 x 2^10):
          0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0 0 0 0 0 0 0 0 1 0 1|0 1 0 1 0|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      A Two Rate Three Color Marker  Model  [trTCM]  as  an  example  to
      characterize  the  'bandwidth'  related  to a possible Diffserv AF
      Service.

         The Two Rate Three Color Marker  Model  (Conformance  Agreement
         Type  02 or 03) defines 5 parameters: the Peak Information Rate
         (PIR, bits per second), the Committed  Information  Rate  (CIR,



De Clercq, et al.        Expires September 2000                 [Page 9]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


         bits  per  second),  the  Peak  Burst  Size  (PBS,  bits),  the
         Committed  Burst  Size  (CBS,  bits)  and  the  operation  mode
         (Color-Blind  mode or Color-Aware mode).  The information field
         of the Conformance Agreement Service Parameter  consists  of  a
         1-octet  type  field, defining one of the two possible Two Rate
         Three Color Marker Models, and a 8-octet Value field: the first
         2  octets  contain  the PIR, the 2 following octets contain the
         CIR, the next 2 octets contain the PBS and the last two  octets
         contain  the  CBS.   All  of these parameters are encoded as an
         11-bits mantissa followed by a 5-bits exponent (see the  Single
         Bucket  Model  for  the  encoding).  Conformance Agreement Type
         '02' is used for the Color-Blind Mode of  the  Two  Rate  Three
         Color Marker Model, and Conformance Agreement Type '03' is used
         for the Color-Aware Mode of the Two  Rate  Three  Color  Marker
         Model.   The  format  and encoding of the Conformance Agreement
         Service Parameter using the Two Rate Three Color  Marker  Model
         is as follows:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x10      | Len Conf Agr  |  Type: 02/03  |      PIR      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PIR      |              CIR              |      PBS      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PBS      |              CBS              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Service Scope (Parameter Type 15)

      The Service Scope Parameter defines the scope  of  the  negotiated
      service.   The Service Scope is an OPTIONAL Service Parameter with
      a variable length information field.  The  default  Scope  (as  it
      must  be  interpreted when the optional Scope Service Parameter is
      not included) is the 'complete Internet': no restrictions  on  the
      scope  of the service.  The information field of the Service Scope
      Parameter consists of a variable length list  of  variable  length
      Location Groups.  A Location Group is defined as a <type> <length>
      <value> block:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Loc Group Typ | Len Loc Group |   Value Location Group ...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




De Clercq, et al.        Expires September 2000                [Page 10]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


      Loc Group Type:

         This 1-octet field defines the  Type  of  a  specific  Location
         Group  included in the negotiated Service Scope Parameter.  The
         different  Location  Group  Types  that  are  defined  in  this
         document, are explained further in this section, when the Value
         Location Group field is examined.

      Len Loc Group:

         This 1-octet field represents  the  length  of  the  considered
         Location Group, including the 2-octet header.

      Value Location Group:

         This variable length field contains the value of the considered
         Location  Group.   This document defines the following types of
         Location Groups, with the according values:

         Source IPv4 Address (Location Group Type 00):

            The Source IPv4  Address  Location  Group  defines  an  IPv4
            Address  from  where the service is allowed to be used.  The
            according Value Location Group field contains a 4-octet IPv4
            Address.   The  resulting  location  group  length  (Len Loc
            Group) is 6 octets.

         Destination IPv4 Address (Location Group Type 01):

            The Destination IPv4 Address Location Group defines an  IPv4
            Address  whereto  the  service  is  allowed to be used.  The
            according Value Location Group field contains a 4-octet IPv4
            Address.   The  resulting  location  group  length  (Len Loc
            Group) is 6 octets.

         Source IPv4 Network Address CIDR (Location Group Type 10):

            The Source IPv4  Network  Address  CIDR  defines  a  network
            IPv4-prefix  that  represents a group of IPv4 addresses from
            where the service is allowed to be used.  The network  IPv4-
            prefix  is described by a mask, that can be described by the
            CIDR-notation : <IPv4-Address> "/"  <length  of  the  mask>.
            The  according Value Location Group field contains a 4-octet
            IPv4 prefix, followed by 1 byte that represents  the  length
            of  the  mask.   The  resulting  location  group length is 7
            octets.

         Destination IPv4 Network Address CIDR (Location Group Type 11):



De Clercq, et al.        Expires September 2000                [Page 11]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


            The Destination IPv4 Network Address CIDR defines a  network
            IPv4-prefix  that  represents  a  group  of  IPv4  addresses
            whereto the service is allowed  to  be  used.   The  network
            IPv4-prefix is described by a mask, that can be described by
            the CIDR-notation : <IPv4-Address> "/" <length of the mask>.
            The  according Value Location Group field contains a 4-octet
            IPv4 prefix, followed by 1 byte that represents  the  length
            of  the  mask.   The  resulting  location  group length is 7
            octets.

         Source IPv4 Address Sequence (Location Group Type 20):

            The  Source  IPv4  Address  Sequence  defines  a  group   of
            successive  IPv4 addresses from where the service is allowed
            to be used.  The  group  of  successive  IPv4  addresses  is
            represented  by  the first IPv4 address and by the last IPv4
            address of the sequence.  The according Value Location Group
            field  contains  two  4-octet IPv4-addresses.  The resulting
            location group length is 10 octets.

         Destination IPv4 Address Sequence (Location Group Type 21):

            The Destination IPv4 Address Sequence  defines  a  group  of
            successive  IPv4 addresses whereto the service is allowed to
            be  used.   The  group  of  successive  IPv4  addresses   is
            represented  by  the first IPv4 address and by the last IPv4
            address of the sequence.  The according Value Location Group
            field  contains  two  4-octet IPv4-addresses.  The resulting
            location group length is 10 octets.

         Source Autonomous System Number (Location Group Type 30):

            The Source Autonomous System Number Location  Group  defines
            an  Autonomous  System  from where the considered service is
            allowed to be used.   The  according  Value  Location  Group
            field  contains a 2-octet ASN.  The resulting location group
            length (Len Loc Group) is 4 octets.

         Destination Autonomous System Number (Location Group Type 31):

            The Destination  Autonomous  System  Number  Location  Group
            defines  an Autonomous System whereto the considered service
            is allowed to be used.  The according Value  Location  Group
            field  contains a 2-octet ASN.  The resulting location group
            length (Len Loc Group) is 4 octets.

         Source Autonomous System Sequence (Location Group Type 40):




De Clercq, et al.        Expires September 2000                [Page 12]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


            The Source Autonomous System Sequence Location Group defines
            a  group  of  Autonomous  Systems with successive Autonomous
            System Numbers from where the considered service is  allowed
            to  be  used.  The group of successive ASs is represented by
            the first ASN and by the last  ASN  of  the  sequence.   The
            according  Value  Location  Group field contains two 2-octet
            ASNs.  The resulting location group length is 6 octets.

         Destination Autonomous System  Sequence  (Location  Group  Type
            41):

            The Destination Autonomous System  Sequence  Location  Group
            defines  a  group  of  Autonomous  Systems  with  successive
            Autonomous System Numbers whereto the considered service  is
            allowed  to  be  used.   The  group  of  successive  ASs  is
            represented by the first ASN and by  the  last  ASN  of  the
            sequence.  The according Value Location Group field contains
            two 2-octet ASNs.  The resulting location group length is  6
            octets.

      The Service Scope Parameter could be extended  with  new  location
      groups  to  define  scopes with a finer granularity: one could use
      port numbers and protocol IDs  to  negotiate  about  services  for
      specific microflows.

   The Service Availability (Parameter Type 20)

      The Service Availability Parameter defines the time period  during
      which  the  considered  service  may  be  accessed.  This document
      defines the Service Availability as a  set  of  Time  Range,  Date
      Range, Month Range and Year Range.  The Service Availability is an
      OPTIONAL Service Parameter  with  a  variable  length  information
      field.    The   default   Service  Availability  (as  it  must  be
      interpreted when the optional Service  Availability  Parameter  is
      not  included)  is 'Always': no restriction on the Availability of
      the Service.  The information field of  the  Service  Availability
      Parameter  consists  of  a variable length list of variable length
      Range  fields.   Range  fields  that  are  not  included  must  be
      interpreted  according  to  the specified default values.  A Range
      field is defined as a <type> <length> <value> block:

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Range Type  | Length Range  |       Value Range   ...       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



De Clercq, et al.        Expires September 2000                [Page 13]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


      Range Type:

         The Range Type field  defines  the  type  of  the  Range  field
         specified.   The different Range Types that are defined in this
         document, are explained further in this section, when the Value
         Range field is examined.

      Length Range:

         The Length Range field represents the length of the  considered
         Range  field,  including the 2-octet header (Range Type, Length
         Range).

      Value Range:

         The Value Range field contains  the  value  of  the  considered
         Range.  This document defines the following Range classes, with
         the according Range Type:

         Time Range (Range Type 00):

            The Time Range class identifies the time of  the  day  range
            during which the service may be used.  The Value Range field
            consists of 2 bytes: one byte specifying the time of the day
            associated  with  the  beginning  of the range, and one byte
            specifying the time of the day associated with  the  end  of
            the range.  The value of the byte specifying a specific time
            of the day represents the amount of quarters of an hour past
            midnight.   The  resulting length of the complete Time Range
            is 4 octets.  The default Time Range is "the whole day":  no
            restriction  on  the  time  of  the  day that the service is
            available.

         Day Range (Range Type 10):

            The Day Range class identifies which days of  the  week  the
            service   may  be  used.   The  1-octet  Value  Range  field
            specifies a single day or a group of sequential  days.   The
            first  4  bits  of the Value Range field represent the first
            day of the Day Range, and the last 4 bits of the Value Range
            field  represent the last day of the Day Range.  Monday will
            be represented as day '0',  Sunday  as  day  '6'.   A  Range
            consisting  of a single day will be represented as the first
            4 bits and the last 4 bits representing the same  day,  both
            containing the according value.  The resulting length of the
            Day Range is 3 octets.  The default Day Range is "the  whole
            week":  no  restriction  on  the  days  of the week that the
            service is available.



De Clercq, et al.        Expires September 2000                [Page 14]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


         Month Range (Range Type 20):

            The Month Range class defines during  which  months  of  the
            year  the considered service may be used.  The 1-octet Value
            Range  field  specifies  a  single  month  or  a  group   of
            sequential  months.   The  first  4  bits of the Value Range
            field represent the first month of the Month Range, and  the
            last  4  bits  represent  the last month of the Month Range.
            January will be represented as month  '0'  and  December  as
            month  '0xb'.   A Range consisting of a single month will be
            represented by  the  first  4  bits  and  the  last  4  bits
            representing  the  same month, both containing the according
            value.  The resulting length of the Month Range is 3 octets.
            The  default Month Range is "the whole year": no restriction
            on the months of the year that the service is available.

         Year Range (Range Type 30):

            The Year Range  class  identifies  during  which  years  the
            considered  service  may  be  used.  The 4-octet Value Range
            field specifies a single  year  or  a  group  of  sequential
            years.  The first two octets of the Value Range field define
            the first year of the Year Range, the last two octets of the
            Value Range field define the last year of the Year Range.  A
            Range consisting of a single year will be represented by the
            2  first  octets and the last 2 octets representing the same
            year.  The resulting length of the Year Range is  6  octets.
            The  default  Year  Range is "every year": no restriction on
            the years that the service is available.

      As stated previously, the  not  included  Range  classes  will  be
      interpreted according to the defined default values.

      Note also that the time-related values must be UTC time values.

   The Excess Action (Parameter Type 25):

      The Excess Action Parameter defines the action  to  be  undertaken
      when  the  characteristics of the measured traffic do not meet the
      agreed specifications of the service.  The Excess  Action  Service
      Parameter  is a 4-bytes OPTIONAL Service Parameter. The format and
      the definition of the 2-bytes  information  field  of  the  Excess
      Action Service Parameter is the following:








De Clercq, et al.        Expires September 2000                [Page 15]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


          0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |D|S|R|  Unused |  Service ID   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first 3 bits define the action to be undertaken.  If the first
      bit  is  set (D) then the traffic that doesn't meet the negotiated
      service specifications ("Excess Traffic") should be discarded.  If
      the  second  bit  is  set  (S)  then  the Excess Traffic should be
      'shaped'.  This means that packets  will  be  buffered  until  the
      traffic  meets  the  specifications  or  until 'free' bandwidth is
      available.  If the third bit is set (R) then the traffic should be
      remarked.   This  means  that  the remarked Excess Traffic will be
      assigned to another 'service'.  The 1-octet 'Service ID'-field  is
      used  to  refer to a particular service to assign when the traffic
      should be remarked (R-bit set).  The default value for the Service
      ID field could be 00, and could identify 'Best Effort' remarking.

      Note that only one of the first three bits (D, S and  R)  MUST  be
      set, the other two MUST remain unset: they are mutually exclusive.

      The default Excess Action is Dropping.  This means that if  a  SLS
      CONFREQ  for  a  certain service does not contain an Excess Action
      Service Parameter, excessive traffic must be dropped.

   The Maximum Delay (Parameter Type 30):

      This OPTIONAL Service Parameter specifies the  maximum  delay  (in
      milliseconds)  to be associated with the considered Service, as is
      defined in section 2.  The information field is 2 octets long  and
      the  length  of  the  Maximum Delay Service Parameter is 4 octets.
      The default value for the Maximum Delay (as it must be interpreted
      when  the  optional  Maximum  Delay  Parameter is not included) is
      "infinity".  This means that no maximum delay is guaranteed  (like
      in Best Effort treatment).

   The Maximum Jitter (Parameter Type 35):

      The OPTIONAL Maximum Jitter Service Parameter defines the  maximum
      jitter  (in  milliseconds) associated with the considered service,
      as defined in section 2.  The information field  of  this  Service
      Parameter is 1 octet long, and the resulting length of the Maximum
      Jitter Service Parameter is 3 octets.  The default value  for  the
      Maximum  Jitter  (as  it  must  be  interpreted  when the optional
      Maximum Jitter Parameter is not  included)  is  "infinity".   This
      means  that  no  maximum jitter is guaranteed (like in Best Effort
      treatment).



De Clercq, et al.        Expires September 2000                [Page 16]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   The Loss Probability (Parameter Type 40):

      The OPTIONAL Loss Probability Service Parameter defines  the  loss
      probability  associated with the considered service, as defined in
      section 2.  The information field of this Service Parameter  is  1
      octet  long, and the resulting length of this Service Parameter is
      3 octets.  The Loss Parameter is expressed as a negative  exponent
      of  10.  The value of the 1-octet information field represents the
      absolute value of the negative exponent.  The  default  value  for
      the  Loss Probability (as it must be interpreted when the optional
      Loss Probability Parameter is not  included)  is  "no  guarantees"
      (like in Best Effort treatment).


3.3 Message Handling

   The introduction of the new  SLS  IPCP  Option  does  not  alter  the
   general  working of IPCP message exchanges.  A PPP peer that does not
   recognize the SLS IPCP Option will simply reject the SLS option,  and
   IPCP negotiation will continue without SLS negotiation.  The PPP peer
   requesting specific services will  be  further  referred  to  as  the
   'client'.  The PPP peer offering specific services to the client will
   be further referred to as the 'provider'.

   The provider will  analyse  every  request  for  a  certain  'service
   profile'.  It does this by parsing all the included parameters of the
   concerned SLS Option.  Whether the  provider  accepts  the  specified
   service,  rejects  it  or  suggests  an  alternative service profile,
   depends on the availability of provider and network resources and  on
   the  provider's  local  policy  concerning  the  assigning of service
   profiles.

   Note that the use of the Diffserv Codepoint Parameter does not impose
   any  Codepoint-knowledge  on  the 'client'.  The client MAY include a
   RANDOM  Diffserv  Codepoint  Parameter  with  the  requested  service
   profile.  If the 'provider' recognizes the IPCP SLS Option and all of
   the Service  Parameters,  the  provider  must  include  the  Diffserv
   Codepoint Parameter that the client must use to mark the packets that
   match the requested service in a CONFNACK message.  The 'client' MUST
   use  the  Diffserv Codepoint inserted in the CONFNACK message for the
   according SLS Option in the consecutive CONFREQ messages and  finally
   in the IP header of the IP-packets that match that service.

3.3.1 IPCP CONFREQ Handling

   A client  that  wants  to  have  access  to  some  specific  services
   regarding  the IP traffic on the PPP link, will insert SLS Options in
   the IPCP CONFREQ message it sends to the provider.  Every SLS  Option



De Clercq, et al.        Expires September 2000                [Page 17]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   represents  a  Service  the client requests, with the required values
   for the Service Parameters specified in the Parameters field  of  the
   SLS  Option.   The mandatory Service Parameters MUST be included, the
   optional Service Parameters MAY be included.  As  we  don't  want  to
   impose any Diffserv knowledge on the client, the information field of
   the mandatory Diffserv Codepoint  Service  Parameter  MAY  contain  a
   RANDOM  value.   Alternatively,  a  'more  intelligent'  value MAY be
   chosen.   Optional Service Parameters that are not  included  in  the
   CONFREQ  message  must  be  interpreted according to specific default
   values.

   Upon receipt of a CONFREQ message  with  SLS  Options  included,  the
   provider  will  parse  the message according to the conventional IPCP
   CONFREQ message handling.  If  the  SLS  Option  Type  field  is  not
   recognised  by  the  provider,  the  provider  does  not  support SLS
   negotiation via PPP.  The provider will  then  send  a  CONFREJ  IPCP
   message  back to the client, completely including all the unknown SLS
   options.

   A provider that recognizes the SLS Option Type field  should  analyze
   the  included  Service Parameters.  If some of the Service Parameters
   are not recognized, the response will be  an  IPCP  CONFREJ  message,
   with  SLS  Options  containing only the complete unrecognized Service
   Parameters.

   A provider that  recognizes  the  SLS  Option  Type  field  and  that
   recognizes  all  the  included  Service  Parameters  of a certain SLS
   Option, may compare the requested Service Profile (the combination of
   the Service Parameters from the requested Service) with the available
   resources and according to possible  local  policies.   Not  included
   optional  Service  Parameters  must  be  interpreted according to the
   defined default values.

   If (the combination of)  all  the  inserted  Service  Parameters  are
   'acceptable'  (including  the  correct  Diffserv  Codepoint) then the
   considered SLS Option is ACK'ed.  When all the SLS  Options  and  all
   the  other  IPCP  Options  are ACK'ed, the provider must send an IPCP
   CONFACK response.

   If the combination of all the inserted Service  Parameters  from  the
   considered  Service  is not 'acceptable' (this means that the Service
   profile  is  not  acceptable  and/or  that  the  Diffserv   Codepoint
   Parameter  is not correct), the provider must NACK the SLS Option and
   insert an appropriate SLS  Option  in  the  resulting  IPCP  CONFNACK
   message.

3.3.2 IPCP CONFREJ Handling




De Clercq, et al.        Expires September 2000                [Page 18]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   When at least one of the IPCP Options in a received  CONFREQ  message
   is  not recognized, the resulting IPCP response is a CONFREJ message.
   The IPCP CONFREJ message must contain identical  copies  of  all  the
   unrecognized options.

   When  all  the  IPCP  Options  in  a  received  CONFREQ  message  are
   recognized,  the  IPCP  Options  are  analyzed. If a certain IPCP SLS
   Option contains any unknown Service Parameters (suboptions), the IPCP
   SLS Option must be rejected.  The resulting IPCP CONFREJ message must
   contain an SLS Option with a Service Parameters field containing only
   the  Service ID Parameter of the considered Service and the unchanged
   unrecognized Service Parameters.

   Upon receipt of an IPCP CONFREJ message, a new CONFREQ message may be
   send.   The  new  CONFREQ  message  may  contain  all the common IPCP
   Options that were included in the previous CONFREQ message  and  that
   are  not  included  in  the received CONFREJ message.  If an IPCP SLS
   Option is included in the CONFREJ message, it is  compared  with  the
   according (with the same Service ID Parameter) SLS Option sent in the
   previous CONFREQ message.  If both SLS Options are identical, the PPP
   peer  does  not  support SLS negotiation, and the new CONFREQ message
   must not contain any SLS  Options.   If  both  SLS  Options  are  not
   identical,  then  an  SLS  Option  field  may  be included in the new
   CONFREQ message, containing all the requested Service Parameters from
   the previous CONFREQ message that are not rejected.

   Note that the MANDATORY Service Parameters must be included in  every
   CONFREQ  message,  and that the MANDATORY Service Parameters included
   in a received CONFREQ message must not be rejected.

3.3.3 IPCP CONFNAK Handling

   When  all  the  IPCP  Options  in  a  received  CONFREQ  message  are
   recognized,  and considered for negotiation, but some of them are not
   accepted, then  the  resulting  IPCP  response  is  an  IPCP  CONFNAK
   message.   The  IPCP  CONFNAK message must contain IPCP Option fields
   for all the unaccepted  messages,  specifying  suggested  information
   fields for the PPP peer to use in subsequent CONFREQ messages.

   When  the  SLS  Option  Type  is  recognized,  and  all  the  Service
   Parameters  from  a  certain  SLS  Option  are  recognized,  then the
   provider  will  decide  upon  the  requested  Service  Profile   (the
   combination  of  the  Service  Parameters from the requested Service)
   depending on the available resources and its user policies.

   If the combination of all the inserted Service  Parameters  from  the
   considered Service is 'acceptable' (this means the Service profile is
   acceptable), but the Diffserv Codepoint Parameter  is  not  'correct'



De Clercq, et al.        Expires September 2000                [Page 19]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   (which  is probable as it MAY even be chosen randomly by the client),
   the provider must NACK the SLS  Option  and  insert  the  SLS  Option
   containing  only  the  according Service ID Parameter and the correct
   Diffserv Codepoint Parameter in the resulting IPCP CONFNACK message.

   If the combination of all the inserted Service  Parameters  from  the
   considered  Service  is not 'acceptable' (this means that the Service
   profile is not acceptable and probably that  the  Diffserv  Codepoint
   Parameter is not correct), than the provider must NACK the SLS Option
   and insert an appropriate SLS Option in the resulting  IPCP  CONFNACK
   message.   That  appropriate  SLS Option in the IPCP CONFNACK message
   MUST  contain  only  the  according  Service  ID  Parameter  and  the
   Parameter  fields  for  the  unaccepted  Service  Parameters, with an
   acceptable  'hint'-value  in  the  value  field  of   these   Service
   Parameters.  The Diffserv Codepoint Parameter is treated the same way
   as the other Service Parameters.  If the Diffserv Codepoint  was  not
   correct in the CONFREQ message, the correct value MUST be included in
   the CONFNACK message.  If the Diffserv Codepoint was correct  in  the
   CONFREQ  message,  the  Diffserv  Codepoint  Parameter  must  not  be
   included in the CONFNACK message

   Upon receipt of an IPCP CONFNAK message, a new IPCP  CONFREQ  message
   may  be  sent,  containing  all the IPCP Options of the previous IPCP
   CONFREQ message that are not included in the received CONFNAK message
   (the accepted IPCP Options), and eventually the (or some of the) IPCP
   Options included in the IPCP CONFNAK message (the not  accepted  IPCP
   Options),  but  with  other  values  for  the information fields (the
   values suggested in the CONFNAK message for example).

   If an IPCP SLS Option is included in the IPCP CONFNAK message, it  is
   compared  with  the  according  SLS  Option (with the same Service ID
   Parameter) sent with the previous CONFREQ  message.   An  appropriate
   SLS  Option  MAY  be  included in the resulting next CONFREQ message.
   That appropriate SLS Option contains all the Service Parameters  that
   were  included  in  the  previous  CONFREQ  message  and that are not
   included in the  received  CONFNACK  message  (the  accepted  Service
   Parameters)  and  eventually  the (or some of the) Service Parameters
   included in the SLS Option of the received CONFNACK message, but with
   other   values  in  the  according  information  fields  (the  values
   suggested in the received CONFNACK message or values  that  are  even
   less demanding than these suggested values).  Note that the MANDATORY
   Service Parameters MUST be included in  every  SLS  Option  of  every
   CONFREQ message.

3.3.4 IPCP CONFACK Handling

   When all the IPCP Options in a  received  IPCP  CONFREQ  message  are
   recognized  and accepted, then the resulting IPCP response is an IPCP



De Clercq, et al.        Expires September 2000                [Page 20]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   CONFACK message.  The IPCP CONFACK message must  be  identically  the
   same  as the last received CONFREQ message, except for the Code Field
   (CONFACK in stead of CONFREQ).

   Upon receipt of an IPCP CONFACK message, the  negotiation  about  the
   IPCP  Options  for  the  transport  in  the  considered  direction is
   finished.  The services that are offered by  the  'provider'  to  the
   'client'  are  the  SLS Options included in the IPCP CONFACK message,
   with the associated Service Parameters.

3.4 Changing Existing Services

   In addition to the conventional  IPCP  negotiation  schemes  and  the
   extensions  that  allow  negotiation  about SUBoptions, this document
   defines some additional negotiation schemes.  An existing SLA can  be
   changed  by  means  of  a  new  IPCP  CONFREQ message.  This document
   defines the following additional negotiation schemes:

   Cancelling a specific Service

      To cancel a specific  service,  the  'client'  can  send  an  IPCP
      CONFREQ  message  containing  an appropriate IPCP SLS Option.  The
      SLS Option Data field of that appropriate SLS Option must  contain
      only  the  Service  ID  Parameter,  and  may not contain the other
      mandatory and optional Service Parameters.

      If a provider receives an IPCP CONFREQ message containing  an  SLS
      Option with a Data field containing only the Service ID Parameter,
      this provider must cancel the service identified by the considered
      Service ID.

   Altering a specific Service

      To alter a specific existing service, the  'client'  can  send  an
      IPCP  CONFREQ  message  containing an appropriate IPCP SLS Option.
      The SLS Option Data field of that  SLS  Option  must  contain  the
      according  Service  ID  Parameter  and  all  the requested Service
      Parameters (the  changed  Service  Parameters  and  the  unchanged
      Service Parameters).

4. Security Considerations

   No security considerations outside  these  described  in  [IPCP]  are
   foreseen.

5. References

   [PPP] Simpson W., "The Point-to-Point Protocol (PPP)", RFC 1661, July



De Clercq, et al.        Expires September 2000                [Page 21]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   1994

   [IPCP] McGregor G.,  "The  PPP  Internet  Protocol  Control  Protocol
   (IPCP)", RFC 1332, May 1992

   [DSFRAM]  Bernet  Y.,  "A  Framework  for  Differentiated  Services",
   draft-ietf-diffserv-framework-02, February 1999

   [DSARCH]  Blake  S.  et  al.,  "An  Architecture  for  Differentiated
   Services", RFC 2475, December 1998

   [AF] Heinanen J. et al., "Assured Forwarding PHB  Group",  RFC  2597,
   June 1999

   [EF] Jacobson V. et al., "An Expedited  Forwarding  PHB  Group",  RFC
   2598, June 1999

   [trTCM] Heinanen J., Guerin R., "A Two Rate Three Color Marker",  RFC
   2698, September 1999

   [IPPM_1] Almes G. et al., "A One-way  Delay  Metric  for  IPPM",  RFC
   2679, September 1999

   [IPPM_2] Almes G. et al., "A Round-trip Delay Metric for  IPPM",  RFC
   2681, September 1999

   [IPPM_3] Almes G. et al., "A One-way Packet Loss  Metric  for  IPPM",
   RFC 2680, September 1999


6. Contacts

   Jeremy De Clercq
   Alcatel Corporate Research Center
   Francis Wellesplein 1, 2018 Antwerp, Belgium
   Phone : +32 3 240 4752
   E-mail : jeremy.de_clercq@alcatel.be

   Peter De Schrijver
   Alcatel Corporate Research Center
   Francis Wellesplein 1, 2018 Antwerp, Belgium
   Phone : +32 3 240 8569
   E-mail : peter.de_schrijver@alcatel.be

   Carmelo Zaccone
   Alcatel Corporate Research Center
   Francis Wellesplein 1, 2018 Antwerp, Belgium
   Phone : +32 3 240 8344



De Clercq, et al.        Expires September 2000                [Page 22]

Internet Draft  draft-declercq-ppp-ds-sla-negotiation-00     March  2000


   E-mail : carmelo.zaccone@alcatel.be

   Yves T'joens
   Alcatel Corporate Research Center
   Francis Wellesplein 1, 2018 Antwerp, Belgium
   Phone : +32 3 240 7890
   E-mail : yves.tjoens@alcatel.be












































De Clercq, et al.        Expires September 2000                [Page 23]