Internet DRAFT - draft-declercq-ppp-ds-sla-negotiation
draft-declercq-ppp-ds-sla-negotiation
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]
