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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract 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 document. 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 References............................................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 extension. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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] respectively. 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 datagrams. 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 receipt. 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 prioritization. 7. Acknowledgements References [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 USA Rick.Fangman@voxpath.com Ken Ryon Voxpath Networks, Inc. 7600B N Capital of Texas Hwy Suite 220 Austin, Texas 78731 USA Ken.Ryon@voxpath.com 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 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Fangman-Ryon [Page 8]