idnits 2.17.1 draft-fangman-ryon-dhc-hqos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2002) is 8033 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 271, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 282, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 286, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 289, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 293, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 795 (ref. '2') ** Obsolete normative reference: RFC 1349 (ref. '4') (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 2460 (ref. '9') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '11') -- Duplicate reference: RFC2475, mentioned in '12', was also mentioned in '11'. ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '12') ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Rick Fangman 2 INTERNET-DRAFT Ken Ryon 3 Voxpath Networks 5 April 26, 2002 7 DHCP Option for Host QoS 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net 32 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document defines a new Dynamic Host Configuration Protocol (DHCP) 41 option that is passed from the DHCP Server to the DHCP Client to 42 define which QoS mechanism and the specific classification settings 43 to be used by the host in its IP datagram forwarding field. This 44 document describes the option support for IP datagram network layer 45 QoS mechanisms. This option does have the ability to support data 46 link layer QoS mechanisms if so defined in future updates of this 47 document. 49 Table of Contents 51 1. Introduction.............................................2 52 2. Requirements Terminology.................................3 53 3. Host QoS Option Definition...............................3 54 4. Host QoS Option Usage....................................5 55 5. IANA Considerations......................................6 56 6. Security Considerations..................................6 57 7. Acknowledgements.........................................6 58 References............................................6 59 Author's Address......................................7 60 Full Copyright Statement..............................8 62 1. Introduction 64 Quality of Service (QoS) has become a critical success factor in the 65 transition to converged multiservice applications within both the 66 metropolitan multi-system operators (MSO) and enterprise networks, 67 with the latter being the source and destination of converged 68 multiservice applications. The integration of telephony traffic with 69 an array of complex data applications, each with different service 70 requirements, makes network engineering and management much more 71 difficult. With each network-attached system that requires 72 application specific QoS settings supported by the MSO networks, the 73 problem of managing QoS has assumed a position of great importance. 74 For example, the quality of streaming media is significantly 75 affected by small erratic delays in the stream that become magnified 76 significantly to the end user. 78 QoS mechanisms have been widely used for a period of time in the WAN, 79 but this is not so true in the case of MSO networks that provide 80 access to local ASP services and the public Internet. This is 81 changing with the acceptance of converged packet-based multimedia 82 applications. In addition, the growing use of intranets, extranets 83 and VPNs has made QoS control on an end-to-end basis a necessity. 84 Wire speed operation is needed so that the QoS "solutions" do not 85 introduce more problems than they solve. Managing QoS functionality 86 should be as simple and as user friendly as possible. 88 With the acceptance of the Dynamic Host Control Protocol (DHCP) for 89 dynamically supporting network-attached systems, the support for 90 dynamically defining QoS settings per network scope is a natural 91 extension. 93 2. Requirements Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [1]. 98 The DHCP related terminology used in this document is described in 99 RFC 2131 [2] and RFC 2132 [3]. 101 The Type of Service (IPv4) and Traffic Class (Ipv6) terminology used 102 in this document is described in RFC 791 [4] and RFC 2460 [5] 103 respectively. 105 The Differentiated Services (Diffserv) terminology used in this 106 document is described in RFCs 2474, 2475 and 3168. 108 3. Host QoS Option Definition 110 The Host QoS DHCP option contains the QoS mechanism to be 111 implemented and a list array of transport layer protocols, service 112 port numbers and the bits thrown pattern in the type of service 113 (ToS) byte field for IPv4 datagrams and Traffic Class field for IPv6 114 datagrams. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Option | Length | Reserved-0 | Type | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Protocol | P/T | Class | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Option: 8 bits 126 DHCP_QOS_OPTION (to be assigned by IANA). 128 Length: 8 bits 130 Length Field is the total bytes of this option, not including the 131 Options code and Length bytes. 133 Reserved-0: 8 bits 135 Reserved Field for future use sent as zero and ignored on 136 receipt. 138 Type: 8 bits 140 Type Field defines the standards based QoS mechanism to implement 141 for the defined application protocol. 143 0 IP Precedence 144 1 Type of Service 145 2 Diffserv 146 3 Diffserv-ECN 147 4-254 Reserved for future assignment 148 255 Experimental 150 NOTE: The remaining Type Field descriptor bits (4-254) MUST be 151 reserved for future assignment of QoS mechanisms. Future 152 assignments MAY include QoS mechanisms supported at the 153 Data Link layer for traffic management within the LAN, WAN 154 or MAN. An example would be the support of IEEE 802.1p/q. 156 Protocol: 8 bits 158 Protocol Field indicates the next level protocol used in the data 159 portion of the IP datagram. The values for various protocols are 160 specified in "Assigned Number" [7]. 162 P/T: 16 bits 164 Port or Type Field indicates the next level protocol port or type 165 number used in the data portion of the IP datagram. The values 166 for various protocol port and protocol type numbers are specified 167 in "Assigned Number" [7]. 169 Class: 8 bits 171 The Class Field is used to specify the bit pattern of the IP 172 forwarding field (i.e. DS, ToS, Precedence or Traffic Class) that 173 define a per protocol-P/T pair classifier. 175 Simple Example of Use: 177 DHCP_QOS_OPTION { 2; # QoS Mechanism Type 178 6, 80, 90; # Protocol, P/T, Class in Hex 179 6, 8080, 90; # Protocol, P/T, Class in Hex 180 17, 10000, 28; # Protocol, P/T, Class in Hex 181 17, 2944, 68; # Protocol, P/T, Class in Hex 182 1, 0, 98; # Protocol, P/T, Class in Hex 183 50, 0, 68; # Protocol, P/T, Class in Hex 184 } 186 4. Host QoS Option Usage 188 With Diffserv and ECN obsolescing the traditional ToS settings and 189 Precedence Fields, the potential for conflicts arise. Different or 190 conflicting QoS technologies may be deployed across a single 191 autonomous network. Indicating the locally adopted QoS mechanism, 192 along with the corresponding protocol-P/T pair classification 193 settings, allows administrators to distinguish between differing or 194 incompatible QoS technologies that may exist between the LAN, the 195 WAN, the Internet and other boundaries. Assuming the "border" 196 routers between these QoS domains have a proper or standards based 197 interpretation of the classification settings, and then possibly 198 remarking settings as traffic traverses these boundaries, this DHCP 199 option allows administrators to dynamically configure hosts to 200 utilize the specified QoS mechanism along with the protocol-P/T 201 pairs settings without confusion on the nature of the bits being set 202 in the IPv4 ToS, IPv6 Traffic Class or DS fields. 204 Those protocols, protocol ports and types that are not specifically 205 indicated via this option MUST NOT be limited in the QoS mechanisms 206 that may be employed in the use of those protocols. This option is 207 only one means by which QoS configurations may be implemented. QoS 208 configurations may be achieved by other means. However, QoS 209 configurations employed by other means MUST NOT explicitly conflict 210 with those QoS configurations indicated via this option. Use of 211 this option SHOULD NOT create any error conditions by causing DHCP 212 clients to mark traffic in a method unknown to intermediary devices. 213 That is the responsibility of the standards-based QoS mechanisms 214 themselves, and the devices upon which the mechanisms are 215 implemented [5]. For example, DIFFSERV [10] requires the use of a 216 "default" per-hop behavior (PHB) when there is no matching codepoint. 218 With DHCP clients required to accept a minimum DHCP option field of 219 312 octets, and the ability to concatenate an additional 64 octets 220 of option space via option 52 (option overload) [8], the 221 DHCP_QOS_OPTION can theoretically define at least 94 separate 222 protocol-P/T pair classifications. 224 5. IANA Consideration 226 The value for the DHCP_QOS_OPTION code must be assigned from the 227 numbering space defined for public DHCP Options in RFC 2939 [6]. 228 This must not conflict with any other numbers already allocated in 229 this numbering space. 231 6. Security Considerations 233 This proposal in and by itself provides no security, nor does it 234 directly impact existing security. This proposal does overtly expose 235 the QoS technologies deployed within a network segment, the 236 applications that take advantage of those technologies, and the 237 relative prioritization given to those applications. This option 238 does not indicate the resources allocated based on the settings. Use 239 of this option does not enable Denial of Service (DoS), though 240 possessing such knowledge could be used to increase the effectiveness 241 of DoS attacks by marking such traffic with a relatively high 242 prioritization. 244 7. Acknowledgements 246 References 248 [1] Postel, J. (ed), "Internet Protocol - DARPA Internet Program 249 Protocol Specification", RFC 791, September 1981. 251 [2] Postel, J., "Service Mappings", RFC 795, September 1981. 253 [3] Bradev, R. (ed), "Requirements for Internet Hosts -- 254 Communication Layers", RFC 1122, October 1989. 256 [4] Almquist, P., "Type of Service in the Internet Protocol Suite", 257 RFC 1349, July 1992. 259 [5] Baker, F. (ed), "Requirements for IP Version 4 Routers", 260 RFC 1812, June 1995. 262 [6] Bradner, S., "Keys words for use in RFCs to Indicate Requirement 263 Levels", RFC 2119, March 1997. 265 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 266 March 1997. 268 [8] Alexander, S., Droms, R., "DHCP Options and BOOTP Extensions", 269 RFC 2132, March 1997. 271 [9] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) 272 Specification", RFC 2460, December 1998. 274 [10] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the 275 Differentiated Services Field (DS Field) in the IPv4 and IPv6 276 Headers", RFC 2474, December 1998. 278 [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, 279 W., "An Architecture for Differentiated Services", RFC 2475, 280 December 1998. 282 [12] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, 283 W., "An Architecture for Differentiated Services", RFC 2475, 284 December 1998. 286 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is replaced by an 287 on-line Database", RFC 3232, January 2002. 289 [14] Ramakrishnan, K., Floyd, S., Black, D., "The Addition of 290 Explicit Congestion Notification (ECN) to IP", RFC 3168, 291 September 2001. 293 [15] Droms, R., Lemon, T., "The DHCP Handbook: Understanding, 294 Deploying, and Managing Automated Configuration Services", 1999. 296 Author's Address 298 Richard Fangman 299 Voxpath Networks, Inc. 300 7600B N Capital of Texas Hwy 301 Suite 220 302 Austin, Texas 78731 303 USA 304 Rick.Fangman@voxpath.com 306 Ken Ryon 307 Voxpath Networks, Inc. 308 7600B N Capital of Texas Hwy 309 Suite 220 310 Austin, Texas 78731 311 USA 312 Ken.Ryon@voxpath.com 314 Full Copyright Statement 316 Copyright (C) The Internet Society(2002). All Rights Reserved. 318 This document and translations of it may be copied and 319 furnished to others, and derivative works that comment on or 320 otherwise explain it or assist in its implementation may be 321 prepared, copied, published and distributed, in whole or in 322 part, without restriction of any kind, provided that the above 323 copyright notice and this paragraph are included on all such 324 copies and derivative works. However, this document itself 325 may not be modified in any way, such as by removing the 326 copyright notice or references to the Internet Society or 327 other Internet organizations, except as needed for the purpose 328 of developing Internet standards in which case the procedures 329 for copyrights defined in the Internet Standards process must 330 be followed, or as required to translate it into languages 331 other than English. 333 The limited permissions granted above are perpetual and will 334 not be revoked by the Internet Society or its successors or 335 assigns. 337 This document and the information contained herein is provided 338 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 339 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 340 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 341 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 342 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 343 PARTICULAR PURPOSE. 345 Acknowledgement 347 Funding for the RFC Editor function is currently provided by 348 the Internet Society.