One document matched: draft-heinanen-diff-tos-octet-00.txt

Internet Engineering Task Force                            Juha Heinanen
INTERNET DRAFT                                           Telecom Finland
Expires April 1998                                          October 1997


       Use of the IPv4 TOS Octet to Support Differential Services
                 <draft-heinanen-diff-tos-octet-00.txt>



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).

Abstract

   This document describes how the TOS octet in the IPv4 header can be
   used to support differential Internet services.  The proposal is
   based on the existing format of the TOS octet as defined in [RFC791]
   and [RFC1349].

1. Introduction

   In order to support differential services within the Internet, such
   as those proposed by [Clark] and [Kilkki], the routers must be able
   to distinguish, how they should treat IP packets in terms of Type of
   Service (TOS) and Drop Preference (DP).  The TOS usually indicates
   the desired delay characteristics of the packet, whereas the DP
   identifies how "important" the packet is if packets need to be
   discarded due to congestion.

   In a typical router implementation, each TOS has its own queue, which
   it serves with such a policy that meets the characteristics of the
   TOS.  The DPs, on the other hand, map to queue thresholds so that an



Heinanen             Differential Services TOS Octet            [Page 1]

INTERNET DRAFT                                             October, 1997


   incoming packet with a DP value i may be discarded if the length of
   the corresponding queue has exceeded a threshold value th(i) of that
   queue.

   The TOS of a packet is set by the application or, if the application
   is unaware of differential Internet services, by the operating system
   or a router.  In the latter two cases, the TOS may be determined from
   the TCP/UDP port numbers of the packet.

   The DP of a packet can also be set by the application, the OS, or a
   router, but the criteria based on which the DP is assigned can vary
   widely.  For example, a packet may be assigned a higher DP if it is
   consider to be "outside" of a given user profile.  For more
   information on policies to set the DP, see [Clark] and [Kilkki].

2. TOS and DP in the IPv4 Header

   Ideally, in order to support a wide range of TOSes and DPs, the IPv4
   header should have several bits available for this purpose.  Luckily,
   the The IPv4 header has an 8 bit TOS octet, that can be used to carry
   the TOS and DP information.

   According to [RFC791], the IPv4 TOS octet is divided into a 3 bit
   Precedence field and a 3 bit TOS field.  The last two bits of the TOS
   octet are reserved for future use:

         Bits 0-2:  Precedence.
         Bit    3:  0 = Normal Delay,       1 = Low Delay.
         Bits   4:  0 = Normal Throughput,  1 = High Throughput.
         Bits   5:  0 = Normal Reliability, 1 = High Reliability.
         Bit  6-7:  Reserved for Future Use.

   The following two sections propose how the TOS and DP information
   needed to provide differential Internet services can be mapped to the
   IPv4 TOS octet.

3. Drop Preference (DP)

   The semantics of the 3 bit Precedence field doesn't contradict its
   use as the DP field:

       "Several networks offer service precedence, which somehow treats
       high precedence traffic as more important than other traffic
       (generally by accepting only traffic above a certain precedence
       at time of high load)."

   However, the actual meaning assigned in [RFC791] to the 3 bits of the
   Precedence field is outdated and not very useful:



Heinanen             Differential Services TOS Octet            [Page 2]

INTERNET DRAFT                                             October, 1997


       111 - Network Control
       110 - Internetwork Control
       101 - CRITIC/ECP
       100 - Flash Override
       011 - Flash
       010 - Immediate
       001 - Priority
       000 - Routine

   On the other hand, [RFC791] further specifies that the Precedence
   field has only local significance within a single network:

       "The Network Control precedence designation is intended to be
       used within a network only.  The actual use and control of that
       designation is up to each network. The Internetwork Control
       designation is intended for use by gateway control originators
       only. If the actual use of these precedence designations is of
       concern to a particular network, it is the responsibility of that
       network to control the access to, and use of, those precedence
       designations."

   This makes it easier to refine the precise semantic of the precedence
   values without breaking possible existing usage of the Precedence
   field.

   It is proposed that differential Internet services use the Precedence
   field of the IPv4 header to indicate the DP of the packet.  The DP of
   the packet can range from value 0, indicating the lowest DP, to value
   7, indicating the highest DP.

   A network does not need to implement all 8 DP levels.  The table
   below shows how a network can map a DP value given in the Precedence
   field of an IPv4 packet to any number of DPs actually supported by
   it:

        DP        Number of Supported DPs
       value     2   3   4   5   6   7   8
       -----------------------------------
         0       0   0   0   0   0   0   0
         1       0   0   0   0   0   0   1
         2       0   0   1   1   1   1   2
         3       0   0   1   1   2   2   3
         4       1   1   2   2   3   3   4
         5       1   1   2   3   4   4   5
         6       1   2   3   4   5   5   6
         7       1   2   3   4   5   6   7

   The above mapping thus supports the 2 DP levels as proposed by



Heinanen             Differential Services TOS Octet            [Page 3]

INTERNET DRAFT                                             October, 1997


   [Clark] and the 4 DP levels as proposed by [Kilkki].

4. Type of Service (TOS)

   The 3 bit TOS field can be used to indicate the actual Type of
   Service that an IP packet expects to receive from a network that
   supports differential services.  As already shown above, [RFC791]
   specifies the following semantics for these 3 bits:

         Bit    3:  0 = Normal Delay,       1 = Low Delay.
         Bits   4:  0 = Normal Throughput,  1 = High Throughput.
         Bits   5:  0 = Normal Reliability, 1 = High Reliability.

   In [RFC1349], the TOS field has been extended by one of the reserved
   bits of [RFC791] resulting in the following semantics for the bits
   3-6 of the IPv4 TOS octet:

         1000   --   minimize delay
         0100   --   maximize throughput
         0010   --   maximize reliability
         0001   --   minimize monetary cost
         0000   --   normal service

   It is not known to the author, what the status of [RFC1349] is in
   terms of the standards' process or implementations.

   Ideally, the whole TOS field of IPv4 TOS octet should be usable by
   differential Internet services to support a wide variety of delay
   characteristics.  However, because it is not known yet, how many
   delay levels will actually be needed and because the standardization
   of the semantics of the TOS field is still at least somewhat open, it
   is proposed that initially networks that support differential
   Internet services only use the bit 3 of the TOS field to indicate the
   desired delay treatment of a packet.

   This is a safe choice, since the Bit 3 of the TOS octet is the delay
   indicator bit according to both [RFC791] and [RFC1349].  By setting
   the Bit 3 to 0 or 1, the packets requests a normal or low delay,
   respectively.  The possibility to request for low delay is believed
   to be important in facilitating large scale deployment of the rapidly
   emerging real-time applications, such as voice and video over IP.

   The use of the Bits 4-7 of the TOS octet in connection with
   differential Internet services is left for further study.







Heinanen             Differential Services TOS Octet            [Page 4]

INTERNET DRAFT                                             October, 1997


5. Summary

   This document has proposed how the IPv4 TOS octet can be used to
   support differential services within the Internet.  The proposal does
   not include any syntactical changes to the IPv4 header and even the
   semantic changes are kept to the very minimum.

   The author hopes that this proposal could help to create a common
   convention on the usage of the TOS octet for the support of
   differential services within the Internet.  Such services will be or,
   more precisely, are being implemented anyhow and it is thus very
   important that the implementations and service offerings will be
   compatible with each other.

6. Security Considerations

   Security is not addressed in the current version of this document.

References

   [Clark]  Clark, D. and Wroclawski, J., "An Approach to Service
   Allocation in the Internet".  draft-clark-diff-svc-alloc-00.txt, July
   1997.

   [Kilkki]  Kilkki, K., "Simple Integrated Media Access (SIMA)".
   <draft-kalevi-simple-media-access-01.txt>, June 1997.

   [RFC791]  Information Sciences Institute, "Internet Protocol".  RFC
   791, September 1981.

   [RFC1349] Almquist, P., "Type of Service in the Internet Protocol
   Suite".  RFC 1349, July 1992.

Acknowledgements

   I would like to thank Kalevi Kilkki for his comments on earlier
   versions of this document.

Author Information

   Juha Heinanen
   Telecom Finland
   PO Box 777
   33101 Tampere
   Finland

   Phone +358 400 500 958
   Email jh@tele.fi



Heinanen             Differential Services TOS Octet            [Page 5]