Internet Engineering Task Force Peter S. Ford, Microsoft Yoram Bernet, Microsoft Internet Draft Document: draft-ford-issll-diff-svc-00.txt March 1998 Expires in six months Integrated Services Over Differentiated Services 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a _working draft_ or _work in progress_. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before September, 1998. Distribution of this draft is unlimited. 1. Abstract This document describes a mapping of IETF Integrated Services[3] over Diff-Serv Networks built from network elements having diff-serv defined Per Hop Behaviours (PHBs)[11]. In many ways, this document should look like an ISSLL document assuming that a differentiated service network looks like an instance of _media_ within a integrated services network. It describes parameter mappings for supporting Controlled Load [6] and Guaranteed Service [7] using the capabilities of diff-serv networks in routers and switches. These mappings fit within an overall Framework for Integrated and Differentiated Services[to be submitted]. 2. Introduction The IETF has started working group activites addressing Differentiated Services for the Internet Protocol. This includes enhancements to the basic IP forwarding Service provided by routed Networks. The diff-serv work proposes differential traffic class queuing and access to bandwidth on the basis of requested Per Hop Int-Serv over Diff-Serv March 1998 Behaviours indicated in the "TOS" byte of IP packets (a current proposal is to rename this octet the DS byte). We summarise a model for identifying service classes in diff-serv networks. Due to the lack of final definition for how diff-serv service classes will be encoded we specify an indirect encoding using one interpretation on where diff-serv is today. In future drafts we will refine the specification to track progress in the diff-serv working group. We then cover how Integrated Services networks can exploit differentiated services networks. This document "borrows" liberally from prior work [1] in the ISSLL working group on 802 LAN technologies including SBM and the IS over 802 Framework documents. Errors in the current document are the sole responsibility of the author. 3. Differentiated Services serving Int-Serv Networks by ServiceMapping There is an approach to Diff-Serv Service classes in which service classes are standardized and can be known by the requestor of the differentiated service "a priori". The simplest mapping between int-serv and diff-serv then becomes a mapping between int-serv (e.g. controlled load, guaranteed and best effort) to the standardized well known diff-serv services (e.g. assured, priority/premium, and best effort). An alternative model is for non-standardization of services in diff- serv networks (e.g. perhaps standardizing only per hop behaviours). In this model the diff-serv network could indicate (e.g. via configuration, signaling, SNMP, etc.) to the int-serv requestor the int/diff serv mapping to be used. A mapping function could be present at each int/diff serv boundary, and the mapping function would not be globally agreed upon for all such boundaries. Each application/host originating a flow needing QoS support and that is attached directly to a diff-serv network can mark packets with the appropriate diff-serv service request in the TOS byte as packets are generated. The packet marking conforms to the diff-serv marking expected for the network to which the host is attached. In addition the application/host can signal the service request into the network (e.g. using RSVP). 4. Mapping Parameters Classification and special handling on a fine grain level (e.g. per- application flows) is expensive in terms of Processing and Memory when dealing with a large number of flows as found in the middle of large backbone Internet Service Provider networks. Indeed, diff- serv work is motivated to address the issues of scaling "better than best effort" services in non-trivial networks. The primary Ford Expires September 1998 Int-Serv over Diff-Serv March 1998 mechanism suggested by diff-serv is to provide aggregation of per- application service requests into a small number of services offered by a network. Diff-serv can also be used to aggregate special handling of per-destination network service requests (e.g. VPNs). In this document "flow" identification in int-serv is identified by the RSVP flow specs (e.g. IP addresses, protocols and ports), and in the diff-serv model "flows" are based on diff-serv markings in the IP packet TOS byte. (Indeed, the many proposals for diff-serv are not about "flows" but in fact a simple augmentation of the per- packet service behaviour.) At int-serv to diff-serv boundaries there can be mappings (and possibly packet remarking) that takes IP packets that are part of an int-serv flow and marks the packet with diff-serv markings. This marking process can exist at any int/diff serv boundary including hosts, within "intra-nets" and in particular we expect much of this work to occur at administrative boundaries (e.g. customer network to ISP). We assume admission control will be applied when determining whether to admit a new flow through a diff-serv network and that a int/diff serv boundary element sending into the diff-serv network will be making admission control decisions. The boundary element will make the determination based on the service request and some measure of the current utilization of the network such as maintaining a bandwidth budget, measuring the current utilization of diff-serv service classes, etc. Given that in general diff-serv is working on aggregates of application flows there will not be a strict 1-1 mapping of int-serv service requests to diff-serv service classes. 4.1 General parameters There are some general parameters [9] that a device will need to use and/or supply for all service types: * Ingress link * Egress links and their MTUs, framing overheads and minimum packet sizes (see media-specific information presented above). * available path bandwidth: updated hop-by-hop by any device along the path of the flow. * minimum latency 4.2 Parameters for Guaranteed Service It is expected that diff-serv proposals for priority/premium style are used to implement int-serv guaranteed services. An int-serv to diff-serv network element must be able to determine the following parameters as documented in [7]: Delay Bound, Receive Ford Expires September 1998 Int-Serv over Diff-Serv March 1998 resources (e.g. buffering, bandwidth), predicted packet loss for the requested service, and Transmit resources needed. 4.3 Parameters for Controlled Load A int-serv to diff-serv boundary network element must be able to determine the following parameters which is documented in [6]: Receive and Transmit resources that would need to be associated with this flow if it were to be admitted. 4.4 Parameters to implement Best Effort It is interesting to note that with diff-serv the definition of service parameters for best effort will likely become soft (e.g. not dependant of the peak rate of the physical access media). It would be possible to provide admission control for best effort service requests, however it is unlikely that this would be considered desireable. 5. Mapping Table for Int-Serv to Diff-Serv Service Classes One can envision several models for aggregating int-serv flows to diff-serv service classes. We will propose a simple mapping function that is intended as a place holder for discussion and refinement as diff-serv is further illuminated. For this disussion we assume services defined in the 2-bit diff-serv. Diff-Serv Service Int-Serv Service Best Effort Default, Best Effort Assured Controlled Load Premium Guaranteed With this example all traffic that uses the Controlled Load service is mapped to a single assured service and Guaranteed Service flows are put into the _premium_ service. Other diff-serv services have been proposed and we can investigate their usage over time. 6. Discussion It is likely that to implement a truly guaranteed service one will have to deploy premium style differentiated services across the entire network. We do not anticipate this in any foreseeable time frame in the Internet at large. However, several access networks Ford Expires September 1998 Int-Serv over Diff-Serv March 1998 might elect to deploy these network elements to meet localized service requirements (e.g. IP telephony access networks). By providing simple and cheap admission control to diff-serv service classes it might be possible to ensure higher utility (read _ less likely to overcommit) networks and therefore make controlled load services quite useful for interactive latency sensitieve traffic. 7. Security Considerations This memo introduces no new security issues. We expect that there will be security issues with policy based admission control [14]. 8. References [1] M. Seaman, _Integrated Services Mappings on IEEE 802 Networks_, Internet Draft, November 1997, [2] "Supplement to MAC Bridges: Traffic Class Expediting and Dynamic Multicast Filtering", September 1997, IEEE P802.1p/D8 [3] "Integrated Services in the Internet Architecture: an Overview" RFC1633, June 1994 [4] "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997 [5] "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", Internet Draft, November 1997 [6] "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997 [7] "Specification of Guaranteed Quality of Service", RFC 2212 September 1997 [8] "Draft Standard for Virtual Bridged Local Area Networks", October 1997, IEEE P802.1Q/D8 [9] "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997 [10] D.Hoffman et al. "SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet", Internet Draft, November 1997 Ford Expires September 1998 Int-Serv over Diff-Serv March 1998 [11] K. Nichols et al. _Differentiated Services Operation Model and Definitions_, Internet Draft, February 1998 [12] K. Nichols et al., _A Two-bit Differentiated Services Architecture for the Internet_, Internet Draft, November 1997, [13] D. Clark and J. Wroclawski, _An Approach to Service Allocation in the Internet_, Internet Draft, July 1997, [14] S. Herzog, _RSVP Extensions for Policy Control_, Internet Draft, April 1997, 9. Acknowledgments This document is a literal borrowing of work of the ISSLL WG of the IETF and the IEEE P802.1 Interworking Task Group. Hopefully the spirit of _imitation is the sincerest form of flattery_ will be accepted. We acknowledge contributions from the diff-serv and int-serv communities and in particular discussions with Yoram Bernet, Raj Yavaktar, Ramesh Pabatti, Kam Lee, Tim Moore, Van Jacobson, Lixia Zhang, Fred Baker, and several colleagues at Microsoft. The musings are those of the authors and the reader should not imply that others actually agree with them. This draft does not constitute any product commitments on the part of Microsoft Corporation. 10. Author's Addresses Peter S. Ford Yoram Bernet One Microsoft Way Redmond, WA 98054 +1 425 703 2032 peterf@microsoft.com yoramb@microsoft.com Ford Expires September 1998