idnits 2.17.1 draft-declercq-ppp-ds-sla-negotiation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 382 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 468: '...vice Scope is an OPTIONAL Service Para...' RFC 2119 keyword, line 612: '... OPTIONAL Service Parameter with...' RFC 2119 keyword, line 718: '...er is a 4-bytes OPTIONAL Service Para...' RFC 2119 keyword, line 741: '...rst three bits (D, S and R) MUST be...' RFC 2119 keyword, line 742: '...t, the other two MUST remain unset: th...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...d is in full ...' == Line 23 has weird spacing: '...-Drafts may ...' == Line 25 has weird spacing: '... Drafts as r...' == Line 34 has weird spacing: '...e check the...' == Line 35 has weird spacing: '...listing conta...' == (377 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8807 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 85, but not defined == Unused Reference: 'DSARCH' is defined on line 1017, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'DSFRAM' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DSARCH') ** Obsolete normative reference: RFC 2598 (ref. 'EF') (Obsoleted by RFC 3246) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Jeremy De Clercq 3 Peter De Schrijver 4 Carmelo Zaccone 5 Yves T'Joens 6 Alcatel 8 March 2000 9 Expires September, 2000 11 PPP Diffserv SLA Negotiation 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 To view the entire list of current Internet-Drafts, please check the 35 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 36 Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 37 ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), 38 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 40 Distribution of this memo is unlimited. 42 Abstract 44 This draft defines extensions to IPCP to allow dynamic negotiation 45 and re-negotiation of a Diffserv-based Service Level Specification. 46 This is achieved by introducing a new IPCP Option, and the concept of 47 Suboption negotiation. 49 1. Introduction 51 Of all the emerging QoS frameworks, the Differentiated Services 52 (Diffserv) framework [DSFRAM] is widely considered to be the most 53 scaleable approach towards QoS provisioning in the Internet. It is 54 therefore assumed in this document that at least the core of the ISP 55 network will be managed according to the Diffserv framework. 57 Quality of Service (QoS) expectations are driving customers to 58 negotiate guarantees with their Service Provider about the offered 59 services. A Service Level Specification is a contract between a 60 provider and a customer that guarantees specific levels of 61 performances and reliability at a certain cost. The contract 62 specifies the 'services' that a customer will have access to, and on 63 the other hand it specifies what the service provider can expect from 64 its customers in terms of workload and resource usage. 66 This document concentrates on the specification of guarantees solely 67 on the IP transport layer, not on the application level. As we 68 assume that the Diffserv framework is used to provision QoS in the 69 ISP network, the SLS format used in this document will define 70 services in terms of Diffserv terminology. 72 Since it is assumed that the vast majority of access configurations 73 use PPP [PPP], and that PPP is mandatory for roaming operations, this 74 document defines a PPP IPCP extension allowing the dynamic 75 negotiation and re-negotiation of a Diffserv-based SLS [DSFRAM]. 77 The next section will focus on the formal format of a SLS, and 78 section 3 will focus on the IPCP extensions. 80 1.1 Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Formal Format of the Service Level Specification 88 This section defines the formal format of a customer Service Level 89 Specification in a Diffserv environment. 91 Service providers may not only offer guarantees in terms of 92 availability, but also offer performance guarantees such as latency, 93 throughput, etc. 95 A 'Service' as it is defined in this document may be specified by 96 means of 6 different parameters. If the SLS does not specify all the 97 6 parameters, the unspecified parameters will be set to default 98 values. The 6 parameters defined in this document are: 100 The Diffserv Codepoint associated with the Service 101 As it is currently defined, Diffserv describes two different Per- 102 Hop Behaviours: Expedited Forwarding (EF) [EF] as a 'virtual 103 leased line' and Assured Forwarding (AF) [AF]. IP packets are 104 differentiated by means of the DSCP field in the IP header. 106 The Conformance Agreement 108 The Conformance Agreement is an agreement between the customer and 109 the Service Provider on a measurable specification of the 110 considered IP traffic. A model must be negotiated to characterize 111 the traffic flow. One could for example use a Token Bucket model 112 to define the 'bandwidth' in the Conformance Agreement. This 113 document uses the two-parameter single bucket model for the EF 114 conformance agreement and the Two-Rate Three Color Marker model 115 for the AF conformance agreement (4 token bucket parameters and 116 one parameter distinguishing between colorblindness and color- 117 awareness) [trTCM] as an example. Many more types of Conformance 118 Agreements may be added over time. 120 The Characteristics of the Service 122 This document identifies the following characteristics for the two 123 defined services: 125 The Maximum Delay. This characteristic defines how much time 126 (in ms) it may take for a packet to get from the ingress point 127 to the egress point. 129 The Maximum Jitter. More than one definition can be used for 130 this characteristic. It may for example define the maximum 131 difference between the longest and the shortest delay in some 132 period of time. Or it could define the maximum delay 133 difference between two consecutive packets in some period of 134 time. The definition to be used in this document is FFS. 136 The Loss Probability. This characteristic defines the fraction 137 of all the packets that do not arrive at their destination. 139 See also [IPPM_1] for details on how one-way delays could be 140 qualified. Related documents [IPPM_2][IPPM_3] explain how other 141 characteristics could be qualified. 143 The Scope of the Service 145 The Scope of the service defines a (set of) location(s) that are 146 allowed to send traffic matching the concerned service, and a set 147 of locations that are allowed to receive traffic matching the 148 concerned service. A set of physical locations can be specified 149 by means of IP-addresses, by means of IP subnetwork addresses or 150 prefixes, or by means of Autonomous System Numbers. 152 The Availability of the Service 154 The Availability of the service defines the period of time during 155 which the concerned service may be used. It can be expressed by 156 different types of time-ranges. Every Range of time is specified 157 by a start moment and a stop moment. This document uses a Time of 158 the Day Range (specified by a start and stop time of the day), a 159 Day of the Week Range (specified by a start and stop day of the 160 week), a Month of the Year Range (specified by a start and stop 161 month of the year), and a Year Range (specified by a start and 162 stop year). In every time-related specification, the UTC must be 163 used to avoid possible confusion. 165 The Excess Treatment 167 The Excess treatment defines the actions (in Diffserv terminology) 168 that will be undertaken by the Service Provider when the traffic 169 contract is violated. This document handles 3 different Excess 170 treatments: 172 Dropping the excessive traffic. 174 Shaping the excessive traffic. 176 Remarking the excessive traffic. When the excessive traffic is 177 being remarked (assigned to another, lower service level), the 178 new service level used must be specified. For convenience, the 179 Service Provider can define a default treatment. 181 3. IPCP Extensions 183 3.1 Summary of Operation 185 The formal process of the negotiation scheme does not differ from the 186 conventional PPP IPCP [IPCP] negotiation scheme. This document 187 defines a new IPCP Option, the SLS IPCP option (representing a 188 certain 'service'), and defines SLS Suboptions for that IPCP SLS 189 Option (representing the parameters associated with that 'service'). 190 This document also extends the negotiation scheme allowing 191 negotiation about SLS Suboptions. 193 The basic operation will be that a PPP peer that requires negotiation 194 about a SLS will send an IPCP CONFREQ including a list of SLS 195 options. Every SLS Option will contain a certain service the peer 196 wants to have access to. The receiving PPP peer will analyse all the 197 included options. After parsing an SLS Option, the receiving PPP 198 peer can make the following decisions: 200 It can reject the whole SLS Option, because it doesn't allow 201 negotiation about SLSs, resulting in an IPCP CONFREJ message. 203 It can reject some of the SLS parameters (suboptions), associated 204 with a certain SLS option (service) because it doesn't understand 205 some of the inserted suboptions or Service Parameters, resulting 206 in an IPCP CONFREJ message. 208 It can accept the SLS option, but not agree on the values of some 209 of the related parameters, resulting in an IPCP CONFNAK message, 210 giving suggestions about appropriate values for the not accepted 211 parameters. 213 And finally it can accept the SLS Option and agree about all the 214 included parameters, resulting in an ACK for that SLS Option 215 (service). When all the IPCP Options are ACK'ed, the resulting 216 IPCP message will be a CONFACK message, which terminates the 217 negotiation. 219 3.2 Message Formats 221 3.2.1 IPCP Message Format 223 Like any other PPP-message, an IPCP-message contains the following 224 fields: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | PPP Protocol | Code Field | ID Field | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | PPP Length Field | Opt Typ Field | Opt Len Field | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Option Data Field | 234 | ... | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Opt Typ Field | Opt Len Field | Option Data Field | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Option Data Field | 239 | ... | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | ... | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 PPP Protocol: 246 This 2-octet field contains the PPP Protocol Number. The PPP 247 Protocol Number for IPCP is 0x8021. 249 Code Field: 251 This 1-octet field contains the Code Number, that differentiates 252 the different kinds of negotiation messages. Configure-Request 253 messages have a Code Number 01, Configure-Ack messages have a Code 254 Number 02, Configure-Nak messages have a Code Number 03 and 255 Configure-Reject messages have a Code Number 04. 257 ID Field: 259 This 1-octet field contains the Identification Number of a 260 negotiation attempt. Every new Configure-Request will receive a 261 new Identification Number. 263 PPP Length Field: 265 This 2-octet field represents the total length of the message, 266 including the four-octet IPCP header and all of the Options. 268 Opt Type Field: 270 This 1-octet field contains the Option Type Number that identifies 271 the type of the considered option that is included in the 272 negotiation message. Examples of existing IPCP-options are the 273 IP-Addresses Option (Opt Type Field 01) and the IP-Compression- 274 Protocol Option (Opt Type Field 02). 276 Opt Len Field: 278 This 1-octet field represents the length of the considered option, 279 including the 2-octet header. 281 Option Data Field: 283 This variable length field contains the information for the option 284 being negotiated. 286 3.2.2 IPCP SLS Option 288 This document defines a new IPCP option: the Service Level 289 Specification (SLS) Option. The Option Type Number to include in the 290 Opt Type Field must be standardized (SLS Option Type). The format of 291 the SLS Option is the conventional 292