Internet DRAFT - draft-fangman-ryon-dhc-hqos
draft-fangman-ryon-dhc-hqos
DHC Working Group Rick Fangman
INTERNET-DRAFT Ken Ryon
Voxpath Networks
April 26, 2002
DHCP Option for Host QoS
<draft-fangman-ryon-dhc-hqos-00.txt>
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]
