idnits 2.17.1 draft-heinanen-diff-tos-octet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC791], [RFC1349]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1997) is 9659 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) -- Possible downref: Normative reference to a draft: ref. 'Clark' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kilkki' ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Juha Heinanen 3 INTERNET DRAFT Telia Finland, Inc. 4 Expires May 1998 November 1997 6 Use of the IPv4 TOS Octet to Support Differential Services 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes how the TOS octet in the IPv4 header can be 30 used to support differential Internet services. The proposal is 31 based on the existing format of the TOS octet as defined in [RFC791] 32 and [RFC1349]. 34 1. Introduction 36 In order to support differential services within the Internet, such 37 as those proposed by [Clark] and [Kilkki], the routers must be able 38 to distinguish, how they should treat IP packets in terms of Type of 39 Service (TOS) and Drop Preference (DP). The TOS usually indicates 40 the desired delay characteristics of the packet, whereas the DP 41 identifies how "important" the packet is if packets need to be 42 discarded due to congestion. 44 In a typical router implementation, each TOS has its own queue, which 45 it serves with a policy that meets the characteristics of the TOS. 46 The DPs, on the other hand, map to queue thresholds so that an 47 incoming packet with a DP value i may be discarded if the length of 48 the corresponding queue has exceeded a threshold value th(i) of that 49 queue. 51 The TOS of a packet is set by the application or, if the application 52 is unaware of differential Internet services, by the operating system 53 or a router. In the latter two cases, the TOS may be determined from 54 the TCP/UDP port numbers of the packet. 56 The DP of a packet can also be set by the application, the OS, or a 57 router, but the criteria based on which the DP is assigned can vary 58 widely. For example, a packet may be assigned a higher DP if it is 59 consider to be "outside" of a given user profile. For more 60 information on policies to set the DP, see [Clark] and [Kilkki]. 62 2. TOS and DP in the IPv4 Header 64 Ideally, in order to support a wide range of TOSes and DPs, the IP 65 packet header should have several bits available for this purpose. 66 Luckily, the The IPv4 header has an 8 bit TOS octet, that can be used 67 to carry the TOS and DP information. 69 According to [RFC791], the IPv4 TOS octet is divided into a 3 bit 70 Precedence field and a 3 bit TOS field. The last two bits of the TOS 71 octet are reserved for future use: 73 Bits 0-2: Precedence. 74 Bit 3: 0 = Normal Delay, 1 = Low Delay. 75 Bits 4: 0 = Normal Throughput, 1 = High Throughput. 76 Bits 5: 0 = Normal Reliability, 1 = High Reliability. 77 Bit 6-7: Reserved for Future Use. 79 The following two sections propose how the TOS and DP information 80 needed to support the implementation of differential Internet 81 services can be mapped to the IPv4 TOS octet. 83 3. Drop Preference (DP) 85 The semantics of the 3 bit Precedence field as defined in [RFC791] 86 doesn't contradict its use as the DP field: 88 "Several networks offer service precedence, which somehow treats 89 high precedence traffic as more important than other traffic 90 (generally by accepting only traffic above a certain precedence 91 at time of high load)." 93 Further, [RFC791] assigns the following meaning to the eight possible 94 values of Precedence field: 96 111 - Network Control 97 110 - Internetwork Control 98 101 - CRITIC/ECP 99 100 - Flash Override 100 011 - Flash 101 010 - Immediate 102 001 - Priority 103 000 - Routine 105 Consistently with the semantics of DP, the above values can be 106 interpreted to describe the increasing importance of an IPv4 packet 107 from the value 000 to value 111. 109 It is proposes that differential Internet services use the Precedence 110 field of the IPv4 header to indicate the DP of the packet. In 111 accordance with [RFC791], the DP of the packet can range from value 112 000, indicating the highest DP, to value 111, indicating the lowest 113 DP. Note that if conformance with [RFC791] if not a requirement, it 114 would be more natural to use the value 000 to indicate the lowest DP 115 and 111 the highest DP, since value 000 is usually the default in 116 IPv4 packets. 118 At present it is still unclear how many levels of DP will be actually 119 needed. No matter what the conclusion will be, it is highly unlikely 120 that every network would support all three Precedence bits and 121 implement all eight levels of DP. This documemnt therefore proposes 122 that a network is allowed to support one, two, or three DP bits. If 123 it supports only one DP bit, it is the Bit 0, and if it supports two, 124 they are the Bits 0 and 1. 126 4. Type of Service (TOS) 128 The three bit TOS field can be used to indicate the Type of Service 129 that an IPv4 packet expects to receive from a network. As already 130 shown above, [RFC791] specifies the following semantics for these 3 131 bits: 133 Bit 3: 0 = Normal Delay, 1 = Low Delay. 134 Bits 4: 0 = Normal Throughput, 1 = High Throughput. 135 Bits 5: 0 = Normal Reliability, 1 = High Reliability. 137 In [RFC1349], the TOS field has been extended by one of the reserved 138 bits of [RFC791] resulting in the following semantics for the Bits 139 3-6 of the IPv4 TOS octet: 141 1000 -- minimize delay 142 0100 -- maximize throughput 143 0010 -- maximize reliability 144 0001 -- minimize monetary cost 145 0000 -- normal service 147 Ideally, the TOS field of IPv4 TOS octet should support a wide 148 variety of delay characteristics. However, it is not known yet, how 149 many different levels of delay can be actually supported by 150 implementations so that each level would have its own distinguised 151 "feel". It is therefore proposed that networks that support 152 differential Internet services initially only use the Bit 3 of the 153 TOS field to indicate the desired delay treatment of a packet. 154 According to both [RFC791] and [RFC1349], by setting the Bit 3 to 0 155 or 1, the packet requests a normal or low delay, respectively. 157 This proposal doesn't exclude the possibility to later extend the 158 delay "field" by another bit if it turns out that two levels of delay 159 is not enough and that more levels can be supported by 160 implementations. It is proposed that the Bit 4 of the TOS octet is 161 reserved for the possible extension of the delay "field" until the 162 issue is resolved. If two delay bits will be later defined, a 163 network is still allowed to support only one of them, which is the 164 Bit 3. 166 The use of the Bits 5-7 of the TOS octet in connection with 167 differential Internet services is left for further study. 169 5. Summary 171 This document has proposed how the IPv4 TOS octet can be used to 172 support differential services within the Internet. The proposal does 173 not include any syntactical changes to the IPv4 header and also the 174 semantic changes are kept to the very minimum. 176 The author hopes that this proposal could help to create a common 177 convention on the usage of the TOS octet for the support of 178 differential services within the Internet. Such services will be or, 179 more precisely, are being implemented anyhow and it is thus very 180 important that the implementations and service offerings will be 181 compatible with each other. 183 6. Security Considerations 185 Security is not addressed in the current version of this document. 187 References 189 [Clark] Clark, D. and Wroclawski, J., "An Approach to Service 190 Allocation in the Internet". draft-clark-diff-svc-alloc-00.txt, July 191 1997. 193 [Kilkki] Kilkki, K., "Simple Integrated Media Access (SIMA)". 194 , June 1997. 196 [RFC791] Information Sciences Institute, "Internet Protocol". RFC 197 791, September 1981. 199 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 200 Suite". RFC 1349, July 1992. 202 Acknowledgements 204 I would like to thank Kalevi Kilkki for his comments on earlier 205 versions of this document. The current version has been influenced 206 by the discussions on the int-serv mailing lists. 208 Author Information 210 Juha Heinanen 211 Telia Finland, Inc. 212 Myyrmaentie 2 213 01600 VANTAA 214 Finland 216 Phone +358 303 944 808 217 Email jh@telia.fi