idnits 2.17.1 draft-ietf-issll-isslow-svcmap-01.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-23) 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-01', but the file name used is 'draft-ietf-issll-isslow-svcmap-01' == No 'Intended status' indicated for this document; assuming Proposed Standard 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 20 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 34 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 224 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 (November 1997) is 9656 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: 10 errors (**), 0 flaws (~~), 6 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-01.txt NetManage Inc. 4 November 1997 5 Expires: 5/98 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 8 57 6. Exported Information 9 58 7. Policing 10 59 8. Ordering and Merging 10 60 9. Guidelines for Implementors 10 61 9.1 Admission Control 10 62 10. Evaluation Criteria 12 63 11. Security Considerations 13 64 12. Author's Address 13 65 13. References 14 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, Admission Control can rely on local state. 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. 136 In particular, IP Telephony, which has tight delay constraints for 137 commercial-level performance, produces small packets. When these are 138 mixed with flows consisting of large packets (e.g. HTTP ,FTP), delay 139 variance increases and absolute delay suffers as these small packets 140 wait in the queue behind even a single large packet being transmitted on 141 the link. Because of the jitter tolerance and adaptive nature of codecs 142 used for packet voice and video, just providing a controlled load 143 service would satisfy most of the need for IP Telephony and other 144 realtime applications which are expected to run over low bitrate 145 connections. 147 Another consideration in handling of packets over low speed links occurs 148 when looking at the end-to-end issues. The low speed link is 149 usually just one hop on a longer path between endpoints. As such, it is 150 usually the limiting factor in performance. While this needs to be 151 considered in the host to router configuration, it becomes more critical 152 between edge devices and backbone routers where there is a multiuser 153 subnet as source and destination for traffic and a low-bitrate link to 154 the router. To ensure some performance bounds end-to-end, guaranteed 155 service should be considered over these links even if it cannot be 156 offered end to end in the network. 158 4. Network Element Data Handling Requirements 160 The ISSLOW Network Service element may be implemented in hardware or 161 software. As described in [1] and [2], for systems which can perform 162 bit-oriented transmission control, the suspend/resume approach optimizes 163 the available bandwidth by minimizing header overhead associated with 164 MLPPP fragmentation. For systems which provide frame-oriented 165 transmission control, the fragmentation approach can be implemented with 166 no hardware changes. Choice of suspend/resume versus fragmentation 167 should be made based on the hardware's capability to handle the new HDLC 168 framing described in [1] and the system overhead associated with byte by 169 byte scanning (required by suspend/resume). 171 To provide controlled load or guaranteed service with the suspend/resume 172 approach, when a packet for an IntServ admitted flow (QoS packet) 173 arrives during transmission of a best efforts packet and continued 174 transmission of the best efforts packet would violate delay constraints 175 of the QoS service flows, the best efforts packet is preempted, the QoS 176 packet/fragments are added to the transmission, and the best effort 177 packet transmission is then resumed: usually all in one transmission. 178 The receiving station separates the best effort packet from the embedded 179 QoS fragments. It is also conceivable that one IntServe Flow's packet 180 might suspend another flow's packet if the delivery deadline of the new 181 packet is earlier than the current packet. 183 For systems which use fragmentation, since suspend/resume is not 184 possible, all packets longer than the minimal tolerable delay for an 185 IntServ packet are fragmented prior to transmission so that a short 186 packet for another flow can be interleaved between fragments of a large 187 packet and still meet the transmission deadline for the IntServ flow. 189 Note that the fragmentation discussed in this document refers to 190 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 191 as described in [1], not IP fragmentation. MTU size is preserved across 192 the link. 194 ISSLOW assumes that the nature of point to point links is such that 195 rate, transmission time and delay are fixed and consistent. The rate of 196 the link is determined at connection time, and the devices on the link 197 (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. 198 Although certain link types, like ISDN, permit dynamic allocation of 199 Bandwidth acroos multiple links, it is assumed that the Admission Control 200 service willconsider the impact of multiple physical links over the point to 201 point logical connection. 203 Note that because of the load balancing effect of Multilink PPP (MLPPP), 204 two 64 Kbps links should exhibit the delay and transmission 205 characteristics of a single 128 Kbps link. However, MLPPP 206 implementations may approach load balancing and fragmentation 207 differently. The mechanism used should be taken into consideration when 208 implementing the scheduler (especially token bucket) for packets, 209 fragments, and suspend/resume on top of existing MLPPP services to 210 ensure that adequate rate and delay characteristics are maintained. 212 4.1 Controlled Load versus Guaranteed Service 214 With most link layers, Guaranteed Service requires more tightly 215 controlled service by the Network Element, and in most cases, acceptance 216 of a Guaranteed Service request results in over-provisioning of link 217 level resources. Controlled Load Service is usually less constrained 218 and permits more flexibility in scheduling of packets for the link. For 219 ISSLOW, when the suspend/resume approach is used, Controlled Load 220 Service actually forces immediate preemption of any best efforts packet. 221 This is required to create the 'lightly loaded' link. Ironically, with 222 Guaranteed Service, since delays are specified, suspend/resume only 223 needs to take place when continued transmission of the packet in 224 question would violate the contracted delay bounds. As such, 225 Guaranteed Service offers potentially better utilization of the link. 227 This anomaly does not exist with a fragmentation approach, since all 228 packets are fragmented to provide a maximum delay. Hence fragment 229 scheduling can ensure the appropriate characteristics of a lightly 230 loaded network. 232 One optional approach to avoid this would be to create a system level 233 definition of 'lightly loaded.' The definition would specify the 234 acceptable delay in a lightly loaded network. This would enable the 235 Controlled Load Service to only suspend packets if they violated the 236 delay constraints associated with the 'lightly loaded' definition. 238 4.2 Controlled Load and Guaranteed Service Data Handling 240 Upon arrival of a QoS flow's packet, the ISSLOW Network Element 241 determines if the packet is conformant. If it is not, Policing is 242 applied (see Policing). Conformant means: 244 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 245 for Guaranteed Service: rT+b with T=time period). 246 2) The packet does not cause a token bucket overflow. 248 If the packet is conformant, it is compressed as required, fragmented 249 (if necessary), and scheduled. If there is no conflicting best efforts 250 traffic, the packet is queued along with the rest of conformant QoS 251 traffic and scheduled with respect to any other IntServ flows such that 252 its transmission deadline is met. 254 For the suspend/resume implementation to achieve controlled load, any 255 best efforts packets which are being transmitted are suspended, 256 otherwise, the QoS packet/fragments are scheduled ahead of any queued 257 best efforts traffic. 259 For Fragmentation implementations, the packet/fragment is scheduled 260 ahead of any best efforts packets. Note that all best efforts packets 261 are fragmented to the smallest MRU (or associated fragment size) of all 262 the QoS flows. This incurs at most one fragment delay for the QoS 263 traffic: a lightly loaded network. 265 For Guaranteed Service or if the Lightly Loaded delay is defined, then 266 for both Fragmentation and suspend/resume, the scheduler determines if 267 continued transmission of the best effort packet being transmitted would 268 cause delay greater than the acceptable delay. If so, the best efforts 269 packet is preempted or, in the case of fragmentation, the QoS packet is 270 scheduled ahead of the rest of the best effort packets' fragments. 272 5. Invocation Information 274 To invoke Controlled Load and Guaranteed Services, both traffic 275 characteristics and the flow itself must be identified to the Network 276 Element. Several methods can be employed to identify the flows. For 277 RSVP, filtering can be used to identify the flows. For non-RSVP 278 implementations, mechanisms such at the FlowID field in IP Version 6, or 279 the TOS field in IP version 4 can be used. In fact, although 280 implementation dependent, there is some debate on the number of 281 different TSpecs that would have to be supported in the ISSLOW 282 environment. It is possible that both the flows and the service level 283 could be specified by applications based on just the FlowID and TOS 284 fields. That is, an application or policy editor associated with the Network 285 Element could map Tspecs and or Rspects to specific TOS or FlowID values. The 286 Network Element can then use the specified values to apply the appropriate QoS 287 and to map the flows to a particular class. 289 A similar approach is currently under discussion in the Differential Services 290 BOF. They are proposing to map TOS values to 802.1p and 802.1q priorities. In 291 fact, a number of major router and switch vendors currently support use of the 292 TOS bits to signal priority and class of service. As such, a number of 293 applications and host proxies have been developed to enable users and network 294 managers to apply policies requesting differential services via TOS. Use of 295 these bits is the easiest way to identify flows without the overhead of 296 filtering. 298 It is therefore strongly recommended that the Network Service Element support 299 mapping of the IP Precedence bits of the TOS field to MLPPP classes described in 300 [1] as follows: 302 IP Precedence Value Multiclass - short sequence Multiclass - long sequence 304 0 0 0 305 1 0 1 306 2 1 2 307 3 1 3 308 4 2 4 309 5 2 5 310 6 3 6 311 7 3 7 313 Note that use of the TOS field or of the FlowID field does not preclude prefix 314 elision. The Network Service Element can map the TOS or FlowID to a MLPPP 315 class, elide the prefix before transmission, and the prefix (with TOS or FlowID) 316 will be reapplied by the receiver. 318 If the Network Service Element is running on a system that doesn't support 319 application or proxy use of the TOS or FlowID fields, then filtering must be 320 applied and: 322 As described in [4], Controlled Load Service is invoked by specifying 323 the flow's traffic characteristics through a TSpec (see [5]). 325 As described in [5], Guaranteed Service is invoked by specifying the 326 flow's TSpec and a requested reservation via an RSpec (see [6]). 328 6. Exported Information. 330 For Controlled Load Service, there is no requirement to export 331 information. 333 For Guaranteed service, both C and D terms for delay computations must 334 be made available for export through the Adspec or other means. See 335 Sections 9.1 (Admission Control) for guidelines on computing the C and D 336 terms. 338 See [4] and [5] for additional information on Exported Information. 340 7. Policing 342 Policing is applied to non-conformant QoS traffic and to best efforts 343 traffic whose transmission would violate the Controlled Load or 344 Guaranteed Service constraints. This document does not designate a 345 specific a packet scheduling implementation. As such, implementors 346 should do their best to maintain best efforts service levels as well as 347 to provide QoS services. Ideally, best efforts traffic can be serviced 348 through separate queues and a weighted queuing mechanism, or when a 349 conflict with QoS traffic arises, best-efforts traffic can simply be discarded. 351 Both Controlled Load and Guaranteed Services permit scheduling of non- 352 conformant traffic as well as the option to discard non-conformant 353 packets. See [4] and [5] for additional information on policing options 354 for Controlled Load and Guaranteed Services. 356 8. Ordering and Merging 358 Refer to [4] and [5] for TSpec and RSpec ordering and merging 359 guidelines. 361 9. Guidelines for Implementors 363 9.1 Admission Control Considerations 365 The ISSLOW specification supports several PPP options. When deciding 366 whether to admit a flow, Admission Control must compute the impact of 367 the following on MTU size, rate, and fragment size: 369 Header compression: Van Jacobson or Casner-Jacobsen. 370 Prefix Elision. 371 CCP. 372 Fragment header option used. 373 Fragmentation versus suspend/resume approach. 375 If any of the compression options are implemented for the connection, the 376 actual transmission rate, and thus the bandwidth required of the link, 377 will be reduced by the compression method(s) used. The fragment header 378 option and use of fragmentation versus suspend/resume will determine the 379 additional overhead associated with the MLPPP transmissions. 381 Admission Control must decide whether to admit a flow based on rate and 382 delay. Assume the following: 384 LinkRate is the rate of the link. 385 MTU is the maximum transmission unit from a protocol. 386 MRU is the maximum receive unit for a particular link. 387 CMTU is the maximum size of the MTU after compression is applied. 388 eMTU is the maximum effective size of the MTU after fragmentation. 389 FRAG is the fragment size including MLPPP header/trailers. 390 Header is the size of the header/trailers/framing for MLPPP/Fragments. 391 pHeader is the additional header/framing overhead associated with 392 suspend/resume. This should include FSE and worst case stuffing 393 overhead. 394 pDelay is the delay associated with suspend/resume packets. 395 b is the bucket depth in bytes 396 R is the requested Rate. 397 D is the fixed overhead delay for the link (Modem, DSU, etc). 398 C is the delay associated with transmission and fragmentation. 399 eRate is the effective rate after compression and fragmentation. 401 The D term may be configured by an administrative tool once the network 402 is installed; it may be computed using the Adspec or other realtime 403 measurement means; or it may be available from hardware during link 404 setup and/or PPP negotiation. 406 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 407 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 408 Service: 410 To determine whether the requested rate is available, Admission Control 411 must compute the effective rate of the request (eRate) - worst case - as 412 follows: 414 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 416 eMTU = (#_of_Fragments) * FRAG 418 eRate = eMTU/CMTU * R 420 Admission Control should compare the eRate of the request against the 421 remaining bandwidth available to determine if the requested rate can be 422 delivered. 424 For Controlled Load Service, a flow can be admitted as long as there is 425 sufficient bandwidth available (after the above computation) to meet the 426 rate requirement, and if there is sufficient buffer space (sum of the 427 token bucket sizes does not exceed the buffer capacity). While some 428 statistical multiplexing could be done in computing admissability, the 429 nature of the low-bitrate links could make this approach risky as any 430 delay incurred to address a temporary overcommitment could be difficult 431 to amortize. 433 Guaranteed Service and a 'lightly loaded' delay bound require delay 434 computations. These computation are based on the standard formula for 435 delay: 437 Delay = b/R + C/R + D 439 Note that for suspend/resume, an additional term is required: 441 pDelay = b/R + C/R + D + pHeader/R. 443 This term exists because of the additional overhead associated with the 444 suspend/resume headers created when suspending a packet. In the worse 445 case, every transmission of a QoS packet could require suspension of a 446 best efforts packet and thus incur the overhead. In most networks, this 447 term will be nominal at most. However, on some low-bitrate links, the 448 overhead may be worth computing. 450 Since MLPPP includes fragmentation, the C term is not fixed and must be 451 represented by the worse case fragmentation as computed in the effective 452 MTU size: 454 C = eMTU. 456 Note that because ISSLOW runs on point to point links, Guaranteed 457 Service can be offered over a link without any negotiated agreement from 458 the next hop. However, if these services are used in conjunction with 459 RSVP, the C and D values above should be used in the Adspec. 461 10. Evaluation Criteria 463 For Controlled Load Service, the ISSLOW network element must ensure that 464 the service requested via the TSpec is delivered to the requesting QoS 465 flow such that the PPP link appears to be a 'lightly loaded link. 467 As a baseline, it is suggested that performance measurements on 468 throughput, delay, and packet error measurements be performed on an 469 unloaded link with just the QoS flow using various packet sizes. The 470 baseline should measure performance for both conformant and non- 471 conformant traffic where for a single flow, this means overloading the 472 link. Once these measurements are complete, measurements of the 473 Controlled Load Service should be performed as follows: 475 1) Request QoS flows in the presence of best efforts traffic and ensure 476 that the QoS flows' performance approximate the unloaded baseline 477 measurements. 479 2) Request QoS flows whose aggregate throughput would exceed the link 480 capacity. Admission Control should deny these service requests or admit 481 them as best efforts only. 483 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. 484 Ensure recovery of the flow once the traffic becomes conformant. 486 For Guaranteed Service: 488 1) Ensure that Admission Control will deny service requests or convert 489 them to Best Efforts when link capacity or delay bounds would be 490 exceeded. 492 2) On a best-efforts loaded link, ensure that the number of lost packets 493 does not exceed those established in the baseline measurements. 495 3) On a best-efforts loaded link, ensure that delay and rate commitments 496 can be met for QoS flows. 498 4) With multiple QoS flows, ensure that an admission of additional QoS 499 flows does not cause a violation in rate, error rate, or delay 500 constraints of any QoS flow. 502 11. Security Considerations 504 Security considerations for PPP links are the subject of other working 505 groups and are not discussed in this document. 507 12. References 509 [1] C. Bormann "The Multi-Class Extension to Multilink PPP" 510 Internet Draft, May 1997, 512 [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" 513 Internet Draft, May 1997, 515 [3] S. Shenker and J. Wroclawski. "Network Element Service 516 Specification Template", Internet Draft, November 1996, 517 519 [4] J. Wroclawski. "Specification of the Controlled Load Quality 520 of Service", Internet Draft, November 1996, 523 [5] S. Shenker, C. Partridge, and R Guerin. "Specification of 524 Guaranteed Quality of Service", Internet Draft, February 1997, 525 527 [6] S. Shenker and J. Wroclawski. "General Characterization 528 Parameters for Integrated Service Network Elements", Internet Draft, 529 October 1996, 531 13 Author's Address: 533 Steve Jackowski 534 NetManage, Inc 535 269 Mt Hermon Rd, Ste 201 536 Scotts Valley, CA 95060 537 stevej@netmanage.com 538 408-439-6834 539 408-438-5115 (fax)