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