idnits 2.17.1 draft-ietf-issll-isslow-svcmap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-issl-isslow-svcmap-00', but the file name used is 'draft-ietf-issll-isslow-svcmap-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 5) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 24 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 118 has weird spacing: '...w), the admis...' == Line 122 has weird spacing: '... leased line....' == Line 223 has weird spacing: '...n would viola...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1997) is 9842 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT S. Jackowski 3 draft-ietf-issl-isslow-svcmap-00.txt NetManage Inc. 4 May 1997 5 Expires: 11/97 7 Network Element Service Specification for Low Speed Networks 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This draft is a product of the Integrated Services Working Group of 28 the Internet Engineering Task Force. Comments are solicited and 29 should be addressed to the working group's mailing list at int- 30 serv@isi.edu and/or the author(s). 32 Abstract 34 This document defines the service mappings for controlled load and 35 guaranteed services over low-bitrate networks. These low bitrate 36 networks typically include components such as analog lines, ISDN 37 connections and sub-T1 rate links. The document specifies the per- 38 network element packet handling behavior, parameters required, traffic 39 specification, policing requirements, and traffic ordering 40 relationships which are required to provide both Guaranteed and 41 Controlled Load service capabilities. It also includes evaluation 42 criteria for elements providing the service. 44 This document is a product of the IETF ISSL working group and is based 45 on [1] and [2] which describe modifications to the PPP protocol to 46 enable these services. 48 Table of Contents 50 1. Introduction 3 51 2. End to end Behavior 4 52 3. Motivation 5 53 4. Network Element Data Handling 5 54 4.1 Controlled Load Versus Guaranteed Service 7 55 4.2 Controlled Load and Guaranteed Service Data Handling 7 56 5. Invocation Information 7 57 6. Exported Information 8 58 7. Policing 8 59 8. Ordering and Merging 8 60 9. Guidelines for Implementors 9 61 9.1 Admission Control 9 62 10. Evaluation Criteria 11 63 11. Security Considerations 12 64 12. Author's Address 12 65 13. References 12 66 1. Introduction 68 With the proliferation of Internet usage in both businesses and homes, 69 there has been an explosion in demand for non-LAN access to the 70 Internet. Most of these connections occur over dial up links. There 71 has also been a recent surge in the requirements for ISDN and other sub- 72 T1 rate connections. Unfortunately, the nature of these 'low-bitrate' 73 links is that it is difficult to provide Quality of Service (QoS) when 74 there are multiple flows of data over the link. For example, it is 75 virtually impossible for a user to receive consistent performance when 76 running a browser, a file transfer and an IP telephony application 77 simultaneously over a low speed link. 79 The ISSLOW subgroup of the ISSL working group has focused on defining 80 mechanisms to permit flow differentiation and QoS capabilities for mixed 81 traffic over low speed links. This has been accomplished through a 82 series of extensions to the PPP protocol which permit fragmentation 83 and/or suspension of large packets in favor of packets on flows which 84 require QoS. The protocol extensions are presented in [1] and [2]. 86 This document describes the service mapping required to implement the 87 controlled load and guaranteed services over these PPP protocol 88 extensions. It is modeled on the Network Element Service Specification 89 Template described in [3]. It is assumed that the ISSLOW Network 90 Element is one portion of a PPP service available to the system. 92 2. End-to-end Behavior 94 Unlike many of the other specific link layers addressed in the ISSL 95 working group, ISSLOW operates only over low speed point to point links 96 or connections. Examples of these links include dial up lines, ISDN 97 channels, and leased lines. As such, 'end to end' simply means between 98 two points. In today's inter/intranet environment, this will include: 100 - host to directly connected host. 101 - host to/from network access device (router or switch). 102 - Edge device (subnet router or switch) to/from router or switch. 103 - In rare circumstances, the link may run from backbone router to 104 backbone router. 106 Thus, the endpoints are two network elements as described above. The 107 Controlled Load and Guaranteed services for ISSLOW links are applied on 108 the link between these elements and often represent the first or last 109 wide area hop in a true end to end service. It is important to note 110 that these links tend to be the most 'bandwidth constrained' along the 111 path. 113 ISSLOW services are only provided if both endpoints on the link support 114 ISSLOW. This is determined during the PPP negotiation. Because of the 115 unique characteristics of a point to point link with both endpoints 116 supporting ISSLOW, traffic is automatically shaped. That is, incoming 117 traffic will be TSpec conformant, and except for some special 118 considerations for Guaranteed Service (below), the admission control 119 function can make decisions based on local state: it does not need to 120 coordinate with the network element on the other end of the link. As 121 described in [5], Guaranteed Service should approximate the 122 functionality of a leased line. Since ISSLOW runs over point to point 123 links, when rate control and delay bounds are provided for individual 124 flows, the link acts like a leased circuit. So again, even for 125 Guaranteed Service, local state can suffice. 127 3. Motivation 129 Previous sections described the motivation for the ISSLOW capabilities. 130 Dial up users are now treating their relatively low-bitrate connections 131 as they would a higher speed connection. They are mixing multiple flows 132 of data and expect performance similar to what they see in a LAN 133 environment. However, it is deployment of realtime applications which 134 is the primary motivation for hosts to implement Integrated Services. 135 In particular, IP Telephony, which has tight delay constraints for 136 commercial-level performance, produces small packets. When these are 137 mixed with flows consisting of large packets (e.g. HTTP ,FTP), delay 138 variance increases and absolute delay suffers as these small packets 139 wait in the queue behind even a single large packet being transmitted on 140 the link. Because of the jitter tolerance and adaptive nature of codecs 141 used for packet voice and video, just providing a controlled load 142 service would satisfy most of the need for IP Telephony and other 143 realtime applications which are expected to run over low bitrate 144 connections. 146 Another consideration in handling of packets over low speed links occurs 147 when looking at the end to end considerations. The low speed link is 148 usually just one hop on a longer path between endpoints. As such, it is 149 usually the limiting factor in performance. While this needs to be 150 considered in the host to router configuration, it becomes more critical 151 between edge devices and backbone routers where there is a multiuser 152 subnet as source and destination for traffic and a low-bitrate link to 153 the router. To ensure some performance bounds end to end, guaranteed 154 service should be considered over these links even if it cannot be 155 offered end to end in the network. 157 4. Network Element Data Handling Requirements 159 The ISSLOW Network Service element may be implemented in hardware or 160 software. As described in [1] and [2], for systems which can perform 161 bit-oriented transmission control, the suspend/resume approach optimizes 162 the available bandwidth by minimizing header overhead associated with 163 MLPPP fragmentation. For systems which provide frame-oriented 164 transmission control, the fragmentation approach can be implemented with 165 no hardware changes. Choice of suspend/resume versus fragmentation 166 should be made based on the hardware's capability to handle the new HDLC 167 framing described in [1] and the system overhead associated with byte by 168 byte scanning (required by suspend/resume). 170 To provide controlled load or guaranteed service with the suspend/resume 171 approach, when a packet for an IntServ admitted flow (QoS packet) 172 arrives during transmission of a best efforts packet and continued 173 transmission of the best efforts packet would violate delay constraints 174 of the QoS service flows, the best efforts packet is preempted, the QoS 175 packet/fragments are added to the transmission, and the best effort 176 packet transmission is then resumed: usually all in one transmission. 177 The receiving station separates the best effort packet from the embedded 178 QoS fragments. It is also conceivable that one IntServe Flow's packet 179 might suspend another flow's packet if the delivery deadline of the new 180 packet is earlier than the current packet. 182 For systems which use fragmentation, since suspend/resume is not 183 possible, all packets longer than the minimal tolerable delay for an 184 IntServ packet are fragmented prior to transmission so that a short 185 packet for another flow can be interleaved between fragments of a large 186 packet and still meet the transmission deadline for the IntServ flow. 188 Note that the fragmentation discussed in this document refers to 189 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 190 as described in [1], not IP fragmentation. MTU size is preserved across 191 the link. 193 ISSLOW assumes that the nature of point to point links is such that 194 rate, transmission time and delay are fixed and consistent. The rate of 195 the link is determined at connection time, and the devices on the link 196 (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. 197 Although certain link types, like ISDN, permit dynamic allocation of 198 bandwidth, it is assumed that the Admission Control service will 199 consider the impact of multiple physical links over the point to point 200 logical connection. 202 Note that because of the load balancing effect of Multilink PPP (MLPPP), 203 two 64 Kbps links should exhibit the delay and transmission 204 characteristics of a single 128 Kbps link. However, MLPPP 205 implementations may approach load balancing and fragmentation 206 differently. The mechanism used should be taken into consideration when 207 implementing the scheduler (especially token bucket) for packets, 208 fragments, and suspend/resume on top of existing MLPPP services to 209 ensure that adequate rate and delay characteristics are maintained. 211 4.1 Controlled Load versus Guaranteed Service 213 With most link layers, Guaranteed Service requires more tightly 214 controlled service by the Network Element, and in most cases, acceptance 215 of a Guaranteed Service request results in over-provisioning of link 216 level resources. Controlled Load Service is usually less constrained 217 and permits more flexibility in scheduling of packets for the link. For 218 ISSLOW, when the suspend/resume approach is used, Controlled Load 219 Service actually forces immediate preemption of any best efforts packet. 220 This is required to create the 'lightly loaded' link. Ironically, with 221 Guaranteed Service, since delays are specified, suspend/resume only 222 needs to take place when continued transmission of the packet in 223 question would violate the contracted delay bounds. As such, 224 Guaranteed Service offers potentially better utilization of the link. 226 This anomaly does not exist with a fragmentation approach, since all 227 packets are fragmented to provide a maximum delay. Hence fragment 228 scheduling can ensure the appropriate characteristics of a lightly 229 loaded network. 231 One optional approach to avoid this would be to create a system level 232 definition of 'lightly loaded.' The definition would specify the 233 acceptable delay in a lightly loaded network. This would enable the 234 Controlled Load Service to only suspend packets if they violated the 235 delay constraints associated with the 'lightly loaded' definition. 237 4.2 Controlled Load and Guaranteed Service Data Handling 239 Upon arrival of a QoS flow's packet, The ISSLOW Network Element 240 determines if the packet is conformant. If it is not, Policing is 241 applied (see Policing). Conformant means: 243 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 244 for Guaranteed Service: rT+b with T=time period). 245 2) The packet does not cause a token bucket overflow. 247 If the packet is conformant, it is compressed as required, fragmented 248 (if necessary), and scheduled. If there is no conflicting best efforts 249 traffic, the packet is queued along with the rest of conformant QoS 250 traffic and scheduled with respect to any other IntServ flows such that 251 its transmission deadline is met. 253 For the suspend/resume implementation to achieve controlled load, any 254 best efforts packets which are being transmitted are suspended, 255 otherwise, the QoS packet/fragments are scheduled ahead of any queued 256 best efforts traffic. 258 For Fragmentation implementations, the packet/fragment is scheduled 259 ahead of any best efforts packets. Note that all best efforts packets 260 are fragmented to the smallest MRU (or associated fragment size) of all 261 the QoS flows. This incurs at most one fragment delay for the QoS 262 traffic: a lightly loaded network. 264 For Guaranteed Service or if the Lightly Loaded delay is defined, then 265 for both Fragmentation and suspend/resume, the scheduler determines if 266 continued transmission of the best effort packet being transmitted would 267 cause delay greater than the acceptable delay. If so, the best efforts 268 packet is preempted or, in the case of fragmentation, the QoS packet is 269 scheduled ahead of the rest of the best effort packets' fragments. 271 5. Invocation Information 273 To invoke Controlled Load and Guaranteed Services, both traffic 274 characteristics and the flow itself must be identified to the Network 275 Element. Several methods can be employed to identify the flows. For 276 RSVP, filtering can be used to identify the flows. For non-RSVP 277 implementations, mechanisms such at the FlowID field in IP Version 6, or 278 the TOS field in IP version 4 can be used. In fact, although 279 implementation dependent, there is some debate on the number of 280 different TSpecs that would have to be supported in the ISSLOW 281 environment. It is possible that both the flows and the service level 282 could be specified by applications based on just the FlowID and TOS 283 fields. Otherwise: 285 As described in [4], Controlled Load Service is invoked by specifying 286 the flow's traffic characteristics through a TSpec (see [5]). 288 As described in [5], Guaranteed Service is invoked by specifying the 289 flow's TSpec and a requested reservation via an RSpec (see [6]). 291 6. Exported Information. 293 For Controlled Load Service, there is no requirement to export 294 information. 296 For Guaranteed service, both C and D terms for delay computations must 297 be made available for export through the Adspec or other means. See 298 Sections 9.1 (Admission Control) for guidelines on computing the C and D 299 terms. 301 See [4] and [5] for additional information on Exported Information. 303 7. Policing 305 Policing is applied to non-conformant QoS traffic and to best efforts 306 traffic whose transmission would violate the Controlled Load or 307 Guaranteed Service constraints. This document does not require a 308 specific a packet scheduling implementation. As such, implementors 309 should do their best to maintain best efforts service levels as well as 310 to provide QoS services. Ideally, best efforts traffic can be serviced 311 through separate queues and a weighted queuing mechanism, or when a 312 conflict with QoS traffic arises, it can simply be discarded. 314 Both Controlled Load and Guaranteed Services permit scheduling of non- 315 conformant traffic as well as the option to discard non-conformant 316 packets. See [4] and [5] for additional information on policing options 317 for Controlled Load and Guaranteed Services. 319 8. Ordering and Merging 321 Refer to [4] and [5] for TSpec and RSpec ordering and merging 322 guidelines. 324 9. Guidelines for Implementors 326 9.1 Admission Control Considerations 328 The ISSLOW specification supports several PPP options. When deciding 329 whether to admit a flow, Admission Control must compute the impact of 330 the following on MTU size, rate, and fragment size: 332 Header compression: Van Jacobson or Casner-Jacobsen. 333 Prefix Elision. 334 CCP. 335 Fragment header option used. 336 Fragmentation versus suspend/resume approach. 338 If any of the compression options is implemented for the connection, the 339 actual transmission rate, and thus the bandwidth required of the link, 340 will be reduced by the compression method(s) used. The fragment header 341 option and use of fragmentation versus suspend/resume will determine the 342 additional overhead associated with the MLPPP transmissions. 344 Admission Control must decide whether to admit a flow based on rate and 345 delay. Assume the following: 347 LinkRate is the rate of the link. 348 MTU is the maximum transmission unit from a protocol. 349 MRU is the maximum receive unit for a particular link. 350 CMTU is the maximum size of the MTU after compression is applied. 351 eMTU is the maximum effective size of the MTU after fragmentation. 352 FRAG is the fragment size including MLPPP header/trailers. 353 Header is the size of the header/trailers/framing for MLPPP/Fragments. 354 pHeader is the additional header/framing overhead associated with 355 suspend/resume. 356 pDelay is the delay associated with suspend/resume packets. 357 b is the bucket depth in bytes 358 R is the requested Rate. 359 D is the fixed overhead delay for the link (Modem, DSU, etc). 360 C is the delay associated with transmission and fragmentation. 361 eRate is the effective rate after compression and fragmentation. 363 The D term may be configured by an administrative tool once the network 364 is installed; it may be computed using the Adspec or other realtime 365 measurement means; or it may be available from hardware during link 366 setup and/or PPP negotiation. 368 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 369 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 370 Service: 372 To determine whether the requested rate is available, Admission Control 373 must compute the effective rate of the request (eRate) - worse case - as 374 follows: 376 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 378 eMTU = (#_of_Fragments) * FRAG 380 eRate = eMTU/CMTU * R 382 Admission Control should compare the eRate of the request against the 383 remaining bandwidth available to determine if the requested rate can be 384 delivered. 386 For Controlled Load Service, a flow can be admitted as long as there is 387 sufficient bandwidth available (after the above computation) to meet the 388 rate requirement, and if there is sufficient buffer space (sum of the 389 token bucket sizes does not exceed the buffer capacity). While some 390 statistical multiplexing could be done in computing admissability, the 391 nature of the low-bitrate links could make this approach risky as any 392 delay incurred to address a temporary overcommitment could be difficult 393 to amortize. 395 Guaranteed Service and a 'lightly loaded' delay bound require delay 396 computations. These computation are based on the standard formula for 397 delay: 399 Delay = b/R + C/R + D 401 Note that for suspend/resume, an additional term is required: 403 pDelay = b/R + C/R + D + pHeader/R. 405 This term exists because of the additional overhead associated with the 406 suspend/resume headers created when suspending a packet. In the worse 407 case, every transmission of a QoS packet could require suspension of a 408 best efforts packet and thus incur the overhead. In most networks, this 409 term will be nominal at most. However, on some low-bitrate links, the 410 overhead may be worth computing. 412 Since MLPPP includes fragmentation, the C term is not fixed and must be 413 represented by the worse case fragmentation as computed in the effective 414 MTU size: 416 C = eMTU. 418 Note that because ISSLOW runs on point to point links, Guaranteed 419 Service can be offered over a link without any negotiated agreement from 420 the next hop. However, if these services are used in conjunction with 421 RSVP, the C and D values above should be used in the Adspec. 423 10. Evaluation Criteria 425 For Controlled Load Service, the ISSLOW network element must ensure that 426 the service requested via the TSpec is delivered to the requesting QoS 427 flow such that the PPP link appears to be a 'lightly loaded link. 429 As a baseline, it is suggested that performance measurements on 430 throughput, delay, and packet error measurements be performed on an 431 unloaded link with just the QoS flow using various packet sizes. The 432 baseline should measure performance for both conformant and non- 433 conformant traffic where for a single flow, this means overloading the 434 link. Once these measurements are complete, measurements of the 435 Controlled Load Service should be performed as follows: 437 1) Request QoS flows in the presence of best efforts traffic and ensure 438 that the QoS flows' performance approximate the unloaded baseline 439 measurements. 441 2) Request QoS flows whose aggregate throughput would exceed the link 442 capacity. Admission Control should deny these service requests or admit 443 them as best efforts only. 445 3) Generate traffic on a QoS flow which exceeds it's TSpec commitment. 446 Ensure recovery of the flow once the traffic becomes conformant. 448 For Guaranteed Service: 450 1) Ensure that Admission Control will deny service requests or convert 451 them to Best Efforts when link capacity or delay bounds would be 452 exceeded. 454 2) On a best-efforts loaded link, ensure that the number of lost packets 455 do not exceed those established in the baseline measurements. 457 3) On a best-efforts loaded link, ensure that delay an rate commitments 458 can be met for QoS flows. 460 4) With multiple QoS flows, ensure that an admission of additional QoS 461 flows does not cause a violation in rate, error rate, or delay 462 constraints of any QoS flow. 464 11. Security Considerations 466 Security considerations for PPP links are the subject of other working 467 groups and are not discussed in this document. 469 12. References 471 [1] C. Bormann "The Multi-Class Extension to Multilink PPP" 472 Internet Draft, March 1997, 474 [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" 475 Internet Draft, March 1997, 477 [3] S. Shenker and J. Wroclawski. "Network Element Service 478 Specification Template", Internet Draft, November 1996, 479 481 [4] J. Wroclawski. "Specification of the Controlled Load Quality 482 of Service", Internet Draft, November 1996, 485 [5] S. Shenker, C. Partridge, and R Guerin. "Specification of 486 Guaranteed Quality of Service", Internet Draft, February 1997, 487 489 [6] S. Shenker and J. Wroclawski. "General Characterization 490 Parameters for Integrated Service Network Elements", Internet Draft, 491 October 1996, 493 13 Author's Address: 495 Steve Jackowski 496 NetManage, Inc 497 269 Mt Hermon Rd, Ste 201 498 Scotts Valley, CA 95060 499 stevej@netmanage.com 500 408-439-6834 501 408-438-5115 (fax)