[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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, <draft-ietf-issll-is802-svc-mapping-
   01.txt>

   [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
           <draft-ietf-issll-is802-framework-03>

   [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
           <draft-ietf-issll-sbm-05>


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 <draft-nichols-dsopdef-
   00.txt>

   [12] K. Nichols et al., _A Two-bit Differentiated Services
   Architecture for the Internet_, Internet Draft, November 1997,
   <draft-nichols-diff-svc-arch-00.txt>

   [13] D. Clark and J. Wroclawski, _An Approach to Service Allocation
   in the Internet_, Internet Draft, July 1997, <draft-clark-diff-svc-
   alloc-00.txt>

   [14] S. Herzog, _RSVP Extensions for Policy Control_, Internet
   Draft, April 1997, <draft-ietf-rsvp-policy-ext-02.txt>

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