Internet DRAFT - draft-fangman-ryon-dhc-hqos


DHC Working Group                                           Rick Fangman
INTERNET-DRAFT                                                  Ken Ryon
                                                        Voxpath Networks

                                                          April 26, 2002

                        DHCP Option for Host QoS

Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.  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".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (US East Coast),
   (Europe), (US West Coast), or (Pacific Rim).

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document defines a new Dynamic Host Configuration Protocol (DHCP)
   option that is passed from the DHCP Server to the DHCP Client to
   define which QoS mechanism and the specific classification settings
   to be used by the host in its IP datagram forwarding field.  This 
   document describes the option support for IP datagram network layer
   QoS mechanisms.  This option does have the ability to support data
   link layer QoS mechanisms if so defined in future updates of this

Fangman-Ryon                                                    [Page 1]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

Table of Contents

   1. Introduction.............................................2
   2. Requirements Terminology.................................3
   3. Host QoS Option Definition...............................3
   4. Host QoS Option Usage....................................5
   5. IANA Considerations......................................6
   6. Security Considerations..................................6
   7. Acknowledgements.........................................6
         Author's Address......................................7
         Full Copyright Statement..............................8

1. Introduction

   Quality of Service (QoS) has become a critical success factor in the
   transition to converged multiservice applications within both the
   metropolitan multi-system operators (MSO) and enterprise networks,
   with the latter being the source and destination of converged
   multiservice applications.  The integration of telephony traffic with
   an array of complex data applications, each with different service
   requirements, makes network engineering and management much more
   difficult.  With each network-attached system that requires
   application specific QoS settings supported by the MSO networks, the
   problem of managing QoS has assumed a position of great importance.
   For example, the quality of streaming media is significantly
   affected by small erratic delays in the stream that become magnified
   significantly to the end user.

   QoS mechanisms have been widely used for a period of time in the WAN,
   but this is not so true in the case of MSO networks that provide
   access to local ASP services and the public Internet.  This is
   changing with the acceptance of converged packet-based multimedia
   applications. In addition, the growing use of intranets, extranets
   and VPNs has made QoS control on an end-to-end basis a necessity.
   Wire speed operation is needed so that the QoS "solutions" do not
   introduce more problems than they solve. Managing QoS functionality
   should be as simple and as user friendly as possible.

   With the acceptance of the Dynamic Host Control Protocol (DHCP) for
   dynamically supporting network-attached systems, the support for
   dynamically defining QoS settings per network scope is a natural

Fangman-Ryon                                                    [Page 2]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

2. Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].
   The DHCP related terminology used in this document is described in
   RFC 2131 [2] and RFC 2132 [3].

   The Type of Service (IPv4) and Traffic Class (Ipv6) terminology used
   in this document is described in RFC 791 [4] and RFC 2460 [5]

   The Differentiated Services (Diffserv) terminology used in this
   document is described in RFCs 2474, 2475 and 3168.

3. Host QoS Option Definition

   The Host QoS DHCP option contains the QoS mechanism to be
   implemented and a list array of transport layer protocols, service
   port numbers and the bits thrown pattern in the type of service
   (ToS) byte field for IPv4 datagrams and Traffic Class field for IPv6

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |    Option     |     Length    |  Reserved-0   |      Type     |
    |    Protocol   |              P/T              |     Class     |

   Option:  8 bits

      DHCP_QOS_OPTION (to be assigned by IANA).

   Length:  8 bits

      Length Field is the total bytes of this option, not including the
      Options code and Length bytes.

   Reserved-0:  8 bits

      Reserved Field for future use sent as zero and ignored on 

Fangman-Ryon                                                    [Page 3]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

   Type:  8 bits

      Type Field defines the standards based QoS mechanism to implement
      for the defined application protocol.

         0      IP Precedence
         1      Type of Service
         2      Diffserv
         3      Diffserv-ECN
         4-254  Reserved for future assignment
         255    Experimental

      NOTE: The remaining Type Field descriptor bits (4-254) MUST be
            reserved for future assignment of QoS mechanisms.  Future
            assignments MAY include QoS mechanisms supported at the
            Data Link layer for traffic management within the LAN, WAN
            or MAN.  An example would be the support of IEEE 802.1p/q.

   Protocol:  8 bits

      Protocol Field indicates the next level protocol used in the data
      portion of the IP datagram.  The values for various protocols are
      specified in "Assigned Number" [7].

   P/T:  16 bits

      Port or Type Field indicates the next level protocol port or type
      number used in the data portion of the IP datagram.  The values 
      for various protocol port and protocol type numbers are specified
      in "Assigned Number" [7].

   Class:  8 bits

   The Class Field is used to specify the bit pattern of the IP
   forwarding field (i.e. DS, ToS, Precedence or Traffic Class) that
   define a per protocol-P/T pair classifier.

Fangman-Ryon                                                    [Page 4]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

   Simple Example of Use:

   DHCP_QOS_OPTION { 2;              # QoS Mechanism Type
                     6, 80, 90;      # Protocol, P/T, Class in Hex
                     6, 8080, 90;    # Protocol, P/T, Class in Hex
                     17, 10000, 28;  # Protocol, P/T, Class in Hex
                     17, 2944, 68;   # Protocol, P/T, Class in Hex
                     1, 0, 98;       # Protocol, P/T, Class in Hex
                     50, 0, 68;      # Protocol, P/T, Class in Hex

4. Host QoS Option Usage

   With Diffserv and ECN obsolescing the traditional ToS settings and
   Precedence Fields, the potential for conflicts arise.  Different or
   conflicting QoS technologies may be deployed across a single
   autonomous network.  Indicating the locally adopted QoS mechanism,
   along with the corresponding protocol-P/T pair classification
   settings, allows administrators to distinguish between differing or
   incompatible QoS technologies that may exist between the LAN, the
   WAN, the Internet and other boundaries.  Assuming the "border"
   routers between these QoS domains have a proper or standards based
   interpretation of the classification settings, and then possibly
   remarking settings as traffic traverses these boundaries, this DHCP
   option allows administrators to dynamically configure hosts to
   utilize the specified QoS mechanism along with the protocol-P/T
   pairs settings without confusion on the nature of the bits being set
   in the IPv4 ToS, IPv6 Traffic Class or DS fields.

   Those protocols, protocol ports and types that are not specifically
   indicated via this option MUST NOT be limited in the QoS mechanisms
   that may be employed in the use of those protocols.  This option is
   only one means by which QoS configurations may be implemented. QoS
   configurations may be achieved by other means.  However, QoS
   configurations employed by other means MUST NOT explicitly conflict
   with those QoS configurations indicated via this option.  Use of
   this option SHOULD NOT create any error conditions by causing DHCP
   clients to mark traffic in a method unknown to intermediary devices.
   That is the responsibility of the standards-based QoS mechanisms
   themselves, and the devices upon which the mechanisms are 
   implemented [5]. For example, DIFFSERV [10] requires the use of a
   "default" per-hop behavior (PHB) when there is no matching codepoint.

   With DHCP clients required to accept a minimum DHCP option field of
   312 octets, and the ability to concatenate an additional 64 octets
   of option space via option 52 (option overload) [8], the
   DHCP_QOS_OPTION can theoretically define at least 94 separate
   protocol-P/T pair classifications.

Fangman-Ryon                                                    [Page 5]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

5. IANA Consideration

   The value for the DHCP_QOS_OPTION code must be assigned from the
   numbering space defined for public DHCP Options in RFC 2939 [6].
   This must not conflict with any other numbers already allocated in
   this numbering space.

6. Security Considerations

   This proposal in and by itself provides no security, nor does it
   directly impact existing security.  This proposal does overtly expose
   the QoS technologies deployed within a network segment, the
   applications that take advantage of those technologies, and the
   relative prioritization given to those applications.  This option
   does not indicate the resources allocated based on the settings.  Use
   of this option does not enable Denial of Service (DoS), though
   possessing such knowledge could be used to increase the effectiveness
   of DoS attacks by marking such traffic with a relatively high

7. Acknowledgements


   [1] Postel, J. (ed), "Internet Protocol - DARPA Internet Program
       Protocol Specification", RFC 791, September 1981.

   [2] Postel, J., "Service Mappings", RFC 795, September 1981.

   [3] Bradev, R. (ed), "Requirements for Internet Hosts --
       Communication Layers", RFC 1122, October 1989.

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

   [5] Baker, F. (ed), "Requirements for IP Version 4 Routers",
       RFC 1812, June 1995.

   [6] Bradner, S., "Keys words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.

   [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.

   [8] Alexander, S., Droms, R., "DHCP Options and BOOTP Extensions",
       RFC 2132, March 1997.

Fangman-Ryon                                                    [Page 6]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

   [9] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6)
       Specification", RFC 2460, December 1998.

   [10] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the
        Differentiated Services Field (DS Field) in the IPv4 and IPv6
        Headers", RFC 2474, December 1998.

   [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss,
        W., "An Architecture for Differentiated Services", RFC 2475,
        December 1998.

   [12] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss,
        W., "An Architecture for Differentiated Services", RFC 2475,
        December 1998.

   [13] Reynolds, J., "Assigned Numbers: RFC 1700 is replaced by an
        on-line Database", RFC 3232, January 2002.

   [14] Ramakrishnan, K., Floyd, S., Black, D., "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

   [15] Droms, R., Lemon, T., "The DHCP Handbook: Understanding,
        Deploying, and Managing Automated Configuration Services", 1999.

Author's Address

   Richard Fangman
   Voxpath Networks, Inc.
   7600B N Capital of Texas Hwy
   Suite 220
   Austin, Texas 78731

   Ken Ryon
   Voxpath Networks, Inc.
   7600B N Capital of Texas Hwy
   Suite 220
   Austin, Texas 78731

Fangman-Ryon                                                    [Page 7]
INTERNET-DRAFT           DHCP Option for Host QoS             April 2002

Full Copyright Statement

   Copyright (C) The Internet Society(2002). All Rights Reserved.

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise explain it or assist in its implementation may be
   prepared, copied, published and distributed, in whole or in
   part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such
   copies and derivative works.  However, this document itself
   may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or
   other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must
   be followed, or as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or

   This document and the information contained herein is provided


   Funding for the RFC Editor function is currently provided by
   the Internet Society.

Fangman-Ryon                                                    [Page 8]