Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT S. Jackowski draft-ietf-issl-isslow-svcmap-01.txt NetManage Inc. November 1997 Expires: 5/98 Network Element Service Specification for Low Speed Networks Status of this Memo This document is an Internet-Draft. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft is a product of the Integrated Services Working Group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at int- serv@isi.edu and/or the author(s). Abstract This document defines the service mappings for controlled load and guaranteed services over low-bitrate networks. These low bitrate networks typically include components such as analog lines, ISDN connections and sub-T1 rate links. The document specifies the per- network element packet handling behavior, parameters required, traffic specification, policing requirements, and traffic ordering relationships which are required to provide both Guaranteed and Controlled Load service capabilities. It also includes evaluation criteria for elements providing the service. This document is a product of the IETF ISSL working group and is based on [1] and [2] which describe modifications to the PPP protocol to enable these services. Jackowski Expires 5/98 [Page 1]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 Table of Contents 1. Introduction 3 2. End to end Behavior 4 3. Motivation 5 4. Network Element Data Handling 5 4.1 Controlled Load Versus Guaranteed Service 7 4.2 Controlled Load and Guaranteed Service Data Handling 7 5. Invocation Information 8 6. Exported Information 9 7. Policing 10 8. Ordering and Merging 10 9. Guidelines for Implementors 10 9.1 Admission Control 10 10. Evaluation Criteria 12 11. Security Considerations 13 12. Author's Address 13 13. References 14 Jackowski Expires 5/98 [Page 2]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 1. Introduction With the proliferation of Internet usage in both businesses and homes, there has been an explosion in demand for non-LAN access to the Internet. Most of these connections occur over dial up links. There has also been a recent surge in the requirements for ISDN and other sub- T1 rate connections. Unfortunately, the nature of these 'low-bitrate' links is that it is difficult to provide Quality of Service (QoS) when there are multiple flows of data over the link. For example, it is virtually impossible for a user to receive consistent performance when running a browser, a file transfer and an IP telephony application simultaneously over a low speed link. The ISSLOW subgroup of the ISSL working group has focused on defining mechanisms to permit flow differentiation and QoS capabilities for mixed traffic over low speed links. This has been accomplished through a series of extensions to the PPP protocol which permit fragmentation and/or suspension of large packets in favor of packets on flows which require QoS. The protocol extensions are presented in [1] and [2]. This document describes the service mapping required to implement the controlled load and guaranteed services over these PPP protocol extensions. It is modeled on the Network Element Service Specification Template described in [3]. It is assumed that the ISSLOW Network Element is one portion of a PPP service available to the system. Jackowski Expires 5/98 [Page 3]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 2. End-to-end Behavior Unlike many of the other specific link layers addressed in the ISSL working group, ISSLOW operates only over low speed point to point links or connections. Examples of these links include dial up lines, ISDN channels, and leased lines. As such, 'end to end' simply means between two points. In today's inter/intranet environment, this will include: - host to directly connected host. - host to/from network access device (router or switch). - Edge device (subnet router or switch) to/from router or switch. - In rare circumstances, the link may run from backbone router to backbone router. Thus, the endpoints are two network elements as described above. The Controlled Load and Guaranteed services for ISSLOW links are applied on the link between these elements and often represent the first or last wide area hop in a true end to end service. It is important to note that these links tend to be the most 'bandwidth constrained' along the path. ISSLOW services are only provided if both endpoints on the link support ISSLOW. This is determined during the PPP negotiation. Because of the unique characteristics of a point to point link with both endpoints supporting ISSLOW, traffic is automatically shaped. That is, incoming traffic will be TSpec conformant, and except for some special considerations for Guaranteed Service (below), the admission control function can make decisions based on local state: it does not need to coordinate with the network element on the other end of the link. As described in [5], Guaranteed Service should approximate the functionality of a leased line. Since ISSLOW runs over point to point links, when rate control and delay bounds are provided for individual flows, the link acts like a leased circuit. So again, even for Guaranteed Service, Admission Control can rely on local state. Jackowski Expires 5/98 [Page 4]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt May, 1997 3. Motivation Previous sections described the motivation for the ISSLOW capabilities. Dial up users are now treating their relatively low-bitrate connections as they would a higher speed connection. They are mixing multiple flows of data and expect performance similar to what they see in a LAN environment. However, it is deployment of realtime applications which is the primary motivation for hosts to implement Integrated Services. In particular, IP Telephony, which has tight delay constraints for commercial-level performance, produces small packets. When these are mixed with flows consisting of large packets (e.g. HTTP ,FTP), delay variance increases and absolute delay suffers as these small packets wait in the queue behind even a single large packet being transmitted on the link. Because of the jitter tolerance and adaptive nature of codecs used for packet voice and video, just providing a controlled load service would satisfy most of the need for IP Telephony and other realtime applications which are expected to run over low bitrate connections. Another consideration in handling of packets over low speed links occurs when looking at the end-to-end issues. The low speed link is usually just one hop on a longer path between endpoints. As such, it is usually the limiting factor in performance. While this needs to be considered in the host to router configuration, it becomes more critical between edge devices and backbone routers where there is a multiuser subnet as source and destination for traffic and a low-bitrate link to the router. To ensure some performance bounds end-to-end, guaranteed service should be considered over these links even if it cannot be offered end to end in the network. 4. Network Element Data Handling Requirements The ISSLOW Network Service element may be implemented in hardware or software. As described in [1] and [2], for systems which can perform bit-oriented transmission control, the suspend/resume approach optimizes the available bandwidth by minimizing header overhead associated with MLPPP fragmentation. For systems which provide frame-oriented transmission control, the fragmentation approach can be implemented with no hardware changes. Choice of suspend/resume versus fragmentation should be made based on the hardware's capability to handle the new HDLC framing described in [1] and the system overhead associated with byte by byte scanning (required by suspend/resume). Jackowski Expires 5/98 [Page 5]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 To provide controlled load or guaranteed service with the suspend/resume approach, when a packet for an IntServ admitted flow (QoS packet) arrives during transmission of a best efforts packet and continued transmission of the best efforts packet would violate delay constraints of the QoS service flows, the best efforts packet is preempted, the QoS packet/fragments are added to the transmission, and the best effort packet transmission is then resumed: usually all in one transmission. The receiving station separates the best effort packet from the embedded QoS fragments. It is also conceivable that one IntServe Flow's packet might suspend another flow's packet if the delivery deadline of the new packet is earlier than the current packet. For systems which use fragmentation, since suspend/resume is not possible, all packets longer than the minimal tolerable delay for an IntServ packet are fragmented prior to transmission so that a short packet for another flow can be interleaved between fragments of a large packet and still meet the transmission deadline for the IntServ flow. Note that the fragmentation discussed in this document refers to multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications as described in [1], not IP fragmentation. MTU size is preserved across the link. ISSLOW assumes that the nature of point to point links is such that rate, transmission time and delay are fixed and consistent. The rate of the link is determined at connection time, and the devices on the link (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. Although certain link types, like ISDN, permit dynamic allocation of Bandwidth acroos multiple links, it is assumed that the Admission Control service willconsider the impact of multiple physical links over the point to point logical connection. Note that because of the load balancing effect of Multilink PPP (MLPPP), two 64 Kbps links should exhibit the delay and transmission characteristics of a single 128 Kbps link. However, MLPPP implementations may approach load balancing and fragmentation differently. The mechanism used should be taken into consideration when implementing the scheduler (especially token bucket) for packets, fragments, and suspend/resume on top of existing MLPPP services to ensure that adequate rate and delay characteristics are maintained. Jackowski Expires 5/98 [Page 6]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 4.1 Controlled Load versus Guaranteed Service With most link layers, Guaranteed Service requires more tightly controlled service by the Network Element, and in most cases, acceptance of a Guaranteed Service request results in over-provisioning of link level resources. Controlled Load Service is usually less constrained and permits more flexibility in scheduling of packets for the link. For ISSLOW, when the suspend/resume approach is used, Controlled Load Service actually forces immediate preemption of any best efforts packet. This is required to create the 'lightly loaded' link. Ironically, with Guaranteed Service, since delays are specified, suspend/resume only needs to take place when continued transmission of the packet in question would violate the contracted delay bounds. As such, Guaranteed Service offers potentially better utilization of the link. This anomaly does not exist with a fragmentation approach, since all packets are fragmented to provide a maximum delay. Hence fragment scheduling can ensure the appropriate characteristics of a lightly loaded network. One optional approach to avoid this would be to create a system level definition of 'lightly loaded.' The definition would specify the acceptable delay in a lightly loaded network. This would enable the Controlled Load Service to only suspend packets if they violated the delay constraints associated with the 'lightly loaded' definition. 4.2 Controlled Load and Guaranteed Service Data Handling Upon arrival of a QoS flow's packet, the ISSLOW Network Element determines if the packet is conformant. If it is not, Policing is applied (see Policing). Conformant means: 1) The flow does not exceed the associated TSpec peak rate (RSpec rate for Guaranteed Service: rT+b with T=time period). 2) The packet does not cause a token bucket overflow. If the packet is conformant, it is compressed as required, fragmented (if necessary), and scheduled. If there is no conflicting best efforts traffic, the packet is queued along with the rest of conformant QoS traffic and scheduled with respect to any other IntServ flows such that its transmission deadline is met. For the suspend/resume implementation to achieve controlled load, any best efforts packets which are being transmitted are suspended, otherwise, the QoS packet/fragments are scheduled ahead of any queued best efforts traffic. Jackowski Expires 5/98 [Page 7]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 For Fragmentation implementations, the packet/fragment is scheduled ahead of any best efforts packets. Note that all best efforts packets are fragmented to the smallest MRU (or associated fragment size) of all the QoS flows. This incurs at most one fragment delay for the QoS traffic: a lightly loaded network. For Guaranteed Service or if the Lightly Loaded delay is defined, then for both Fragmentation and suspend/resume, the scheduler determines if continued transmission of the best effort packet being transmitted would cause delay greater than the acceptable delay. If so, the best efforts packet is preempted or, in the case of fragmentation, the QoS packet is scheduled ahead of the rest of the best effort packets' fragments. 5. Invocation Information To invoke Controlled Load and Guaranteed Services, both traffic characteristics and the flow itself must be identified to the Network Element. Several methods can be employed to identify the flows. For RSVP, filtering can be used to identify the flows. For non-RSVP implementations, mechanisms such at the FlowID field in IP Version 6, or the TOS field in IP version 4 can be used. In fact, although implementation dependent, there is some debate on the number of different TSpecs that would have to be supported in the ISSLOW environment. It is possible that both the flows and the service level could be specified by applications based on just the FlowID and TOS fields. That is, an application or policy editor associated with the Network Element could map Tspecs and or Rspects to specific TOS or FlowID values. The Network Element can then use the specified values to apply the appropriate QoS and to map the flows to a particular class. A similar approach is currently under discussion in the Differential Services BOF. They are proposing to map TOS values to 802.1p and 802.1q priorities. In fact, a number of major router and switch vendors currently support use of the TOS bits to signal priority and class of service. As such, a number of applications and host proxies have been developed to enable users and network managers to apply policies requesting differential services via TOS. Use of these bits is the easiest way to identify flows without the overhead of filtering. Jackowski Expires 5/98 [Page 8]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 It is therefore strongly recommended that the Network Service Element support mapping of the IP Precedence bits of the TOS field to MLPPP classes described in [1] as follows: IP Precedence Value Multiclass - short sequence Multiclass - long sequence 0 0 0 1 0 1 2 1 2 3 1 3 4 2 4 5 2 5 6 3 6 7 3 7 Note that use of the TOS field or of the FlowID field does not preclude prefix elision. The Network Service Element can map the TOS or FlowID to a MLPPP class, elide the prefix before transmission, and the prefix (with TOS or FlowID) will be reapplied by the receiver. If the Network Service Element is running on a system that doesn't support application or proxy use of the TOS or FlowID fields, then filtering must be applied and: As described in [4], Controlled Load Service is invoked by specifying the flow's traffic characteristics through a TSpec (see [5]). As described in [5], Guaranteed Service is invoked by specifying the flow's TSpec and a requested reservation via an RSpec (see [6]). 6. Exported Information. For Controlled Load Service, there is no requirement to export information. For Guaranteed service, both C and D terms for delay computations must be made available for export through the Adspec or other means. See Sections 9.1 (Admission Control) for guidelines on computing the C and D terms. See [4] and [5] for additional information on Exported Information. Jackowski Expires 5/98 [Page 9]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 7. Policing Policing is applied to non-conformant QoS traffic and to best efforts traffic whose transmission would violate the Controlled Load or Guaranteed Service constraints. This document does not designate a specific a packet scheduling implementation. As such, implementors should do their best to maintain best efforts service levels as well as to provide QoS services. Ideally, best efforts traffic can be serviced through separate queues and a weighted queuing mechanism, or when a conflict with QoS traffic arises, best-efforts traffic can simply be discarded. Both Controlled Load and Guaranteed Services permit scheduling of non- conformant traffic as well as the option to discard non-conformant packets. See [4] and [5] for additional information on policing options for Controlled Load and Guaranteed Services. 8. Ordering and Merging Refer to [4] and [5] for TSpec and RSpec ordering and merging guidelines. 9. Guidelines for Implementors 9.1 Admission Control Considerations The ISSLOW specification supports several PPP options. When deciding whether to admit a flow, Admission Control must compute the impact of the following on MTU size, rate, and fragment size: Header compression: Van Jacobson or Casner-Jacobsen. Prefix Elision. CCP. Fragment header option used. Fragmentation versus suspend/resume approach. If any of the compression options are implemented for the connection, the actual transmission rate, and thus the bandwidth required of the link, will be reduced by the compression method(s) used. The fragment header option and use of fragmentation versus suspend/resume will determine the additional overhead associated with the MLPPP transmissions. Jackowski Expires 5/98 [Page 10]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 Admission Control must decide whether to admit a flow based on rate and delay. Assume the following: LinkRate is the rate of the link. MTU is the maximum transmission unit from a protocol. MRU is the maximum receive unit for a particular link. CMTU is the maximum size of the MTU after compression is applied. eMTU is the maximum effective size of the MTU after fragmentation. FRAG is the fragment size including MLPPP header/trailers. Header is the size of the header/trailers/framing for MLPPP/Fragments. pHeader is the additional header/framing overhead associated with suspend/resume. This should include FSE and worst case stuffing overhead. pDelay is the delay associated with suspend/resume packets. b is the bucket depth in bytes R is the requested Rate. D is the fixed overhead delay for the link (Modem, DSU, etc). C is the delay associated with transmission and fragmentation. eRate is the effective rate after compression and fragmentation. The D term may be configured by an administrative tool once the network is installed; it may be computed using the Adspec or other realtime measurement means; or it may be available from hardware during link setup and/or PPP negotiation. Admission Control must compute CMTU, eMTU, and eRate for Controlled Load Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed Service: To determine whether the requested rate is available, Admission Control must compute the effective rate of the request (eRate) - worst case - as follows: #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) eMTU = (#_of_Fragments) * FRAG eRate = eMTU/CMTU * R Admission Control should compare the eRate of the request against the remaining bandwidth available to determine if the requested rate can be delivered. For Controlled Load Service, a flow can be admitted as long as there is sufficient bandwidth available (after the above computation) to meet the rate requirement, and if there is sufficient buffer space (sum of the token bucket sizes does not exceed the buffer capacity). While some statistical multiplexing could be done in computing admissability, the nature of the low-bitrate links could make this approach risky as any delay incurred to address a temporary overcommitment could be difficult to amortize. Jackowski Expires 5/98 [Page 11]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 Guaranteed Service and a 'lightly loaded' delay bound require delay computations. These computation are based on the standard formula for delay: Delay = b/R + C/R + D Note that for suspend/resume, an additional term is required: pDelay = b/R + C/R + D + pHeader/R. This term exists because of the additional overhead associated with the suspend/resume headers created when suspending a packet. In the worse case, every transmission of a QoS packet could require suspension of a best efforts packet and thus incur the overhead. In most networks, this term will be nominal at most. However, on some low-bitrate links, the overhead may be worth computing. Since MLPPP includes fragmentation, the C term is not fixed and must be represented by the worse case fragmentation as computed in the effective MTU size: C = eMTU. Note that because ISSLOW runs on point to point links, Guaranteed Service can be offered over a link without any negotiated agreement from the next hop. However, if these services are used in conjunction with RSVP, the C and D values above should be used in the Adspec. 10. Evaluation Criteria For Controlled Load Service, the ISSLOW network element must ensure that the service requested via the TSpec is delivered to the requesting QoS flow such that the PPP link appears to be a 'lightly loaded link. As a baseline, it is suggested that performance measurements on throughput, delay, and packet error measurements be performed on an unloaded link with just the QoS flow using various packet sizes. The baseline should measure performance for both conformant and non- conformant traffic where for a single flow, this means overloading the link. Once these measurements are complete, measurements of the Controlled Load Service should be performed as follows: 1) Request QoS flows in the presence of best efforts traffic and ensure that the QoS flows' performance approximate the unloaded baseline measurements. 2) Request QoS flows whose aggregate throughput would exceed the link capacity. Admission Control should deny these service requests or admit them as best efforts only. 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. Ensure recovery of the flow once the traffic becomes conformant. Jackowski Expires 5/98 [Page 12]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 For Guaranteed Service: 1) Ensure that Admission Control will deny service requests or convert them to Best Efforts when link capacity or delay bounds would be exceeded. 2) On a best-efforts loaded link, ensure that the number of lost packets does not exceed those established in the baseline measurements. 3) On a best-efforts loaded link, ensure that delay and rate commitments can be met for QoS flows. 4) With multiple QoS flows, ensure that an admission of additional QoS flows does not cause a violation in rate, error rate, or delay constraints of any QoS flow. 11. Security Considerations Security considerations for PPP links are the subject of other working groups and are not discussed in this document. 12. References [1] C. Bormann "The Multi-Class Extension to Multilink PPP" Internet Draft, May 1997, <draft-ietf-issl-isslow-mcml-02.txt> [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" Internet Draft, May 1997, <draft-ietf-issl-isslow-rtf-02.txt> [3] S. Shenker and J. Wroclawski. "Network Element Service Specification Template", Internet Draft, November 1996, <draft-ietf-intserv-svc-template-03.txt> [4] J. Wroclawski. "Specification of the Controlled Load Quality of Service", Internet Draft, November 1996, <draft-ietf-intserv-ctrl- load-svc-04.txt> [5] S. Shenker, C. Partridge, and R Guerin. "Specification of Guaranteed Quality of Service", Internet Draft, February 1997, <draft-ietf-intserv-guaranteed-svc-07.txt> [6] S. Shenker and J. Wroclawski. "General Characterization Parameters for Integrated Service Network Elements", Internet Draft, October 1996, <draft-ietf-intserv-charac-02.txt> Jackowski Expires 5/98 [Page 13]
INTERNET-DRAFT draft-ietf-issl-isslow-svcmap-01.txt Nov 1997 13 Author's Address: Steve Jackowski NetManage, Inc 269 Mt Hermon Rd, Ste 201 Scotts Valley, CA 95060 stevej@netmanage.com 408-439-6834 408-438-5115 (fax) Jackowski Expires 5/98 [Page 14]
