idnits 2.17.1 draft-ietf-intserv-charac-00.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-19) 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 ([1-4], [2-4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 93 has weird spacing: '...lements along...' -- 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 (14 November 1995) is 10384 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) -- Looks like a reference, but probably isn't: '2-4' on line 50 -- Looks like a reference, but probably isn't: '1-4' on line 65 == Unused Reference: '2' is defined on line 201, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 205, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 209, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Integrated Services WG 3 INTERNET-DRAFT Scott Shenker 4 draft-ietf-intserv-charac-00.txt XEROX PARC 5 14 November 1995 6 Expires: ?/?/96 8 Specification of General Characterization Parameters 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 This document is a product of the Integrated Services working group 29 of the Internet Engineering Task Force. Comments are solicited and 30 should be addressed to the working group's mailing list at int- 31 serv@isi.edu and/or the author(s). 33 Abstract 35 This memo defines general characterization parameters for network 36 elements supporting enhanced qualities of service. General 37 characterization parameters are those that are not specific to a 38 particular quality of service. 40 Introduction 42 This memo defines general, or service-independent, characterization 43 parameters for network elements. General characterization parameters 44 are those that are not specific to a particular quality of service. 45 A discussion of how these parameters fit into an integrated services 46 architecture can be found in [1]. Please refer to that document for 47 definitions and additional information about the specification of 48 qualities of service within the IP protocol family. 50 The specifications of the various qualities of service ([2-4]) 51 describe the associated characterization parameters that must be 52 exported. However, there are some quantities of interest that are 53 not specific to a particular quality of service. These "general" 54 characterizations are described in this document. 56 Characterization parameters associated with a particular service are 57 attached to a service_name. The service-name associated with general 58 characterizations is 0. We describe these general characterization 59 parameters below. 61 Number of IS Hops 63 IS stands for "integrated services aware". An integrated services 64 aware network element is one that conforms to the various 65 requirements described in this document and the documents [1-4] (it 66 need not offer those services, but if it does it supports and 67 characterizes the services in conformance with the relevant 68 specification). The composition rule is to increment the counter by 69 one. This quantity, when composed end-to-end, informs the endpoint 70 of the number of Integrated-Services aware network elements 71 traversed along the path from sender to receiver. The parameter_name 72 for this field is 1. The characterization parameter may be 73 represented as a single 16-bit unsigned integer in network byte 74 order. 76 Number of IP Hops 78 The local parameter is the number of IP hops between the last (i.e., 79 upstream) IS network element and this one. Observe that since the 80 network element may not be aware of its neighbor on the the upstream 81 path, *the local parameter must be provided to the network element by 82 the setup protocol* (possibly by tracking the TTL value). 84 The composition rule is additive. This quantity, when composed end- 85 to-end, informs the endpoint of the number of IP network elements 86 ("hops") traversed along the path from sender to receiver. The 87 parameter_name for local parameter is 2. The parameter_name for the 88 composed quantity is 3. These characterization parameters may be 89 represented as 16-bit unsigned integers in network byte order. 91 Comparison of the end-to-end composition of the two previous 92 characterization values will yield the number of non-IS network 93 elements along the path. 95 Bandwidth 97 The local parameter is the bandwidth of the network element. For 98 links, this value would be the bandwidth of the link. The 99 composition rule is to take the minimum of the network element's 100 value and the previously composed value. This quantity, when 101 composed end-to-end, informs the endpoint of the minimal bandwidth 102 link along the path from sender to receiver. The parameter_name for 103 the bandwidth of the network element's link is 4. The parameter_name 104 for the composed minimal bandwidth along the path is 5. 106 These values are measured in bytes per second, and can range from 1 107 byte per second to as large as 40 terabytes per second (or about what 108 is believed to be the maximum theoretical bandwidth of a single 109 strand of fiber). Clearly, particularly for large bandwidths, only 110 the first few digits are significant and so the use of floating point 111 representations, accurate to at least 0.1% is encouraged. These 112 characterizations of bandwidth can be represented by floating point 113 numbers in single-precision IEEE floating point format. 115 NOTE: If the number of IS hops is less than the number of IP hops, 116 end systems should treat this value as a hint rather than a 117 reliable value. 119 Latency 121 The local parameter is the latency of the link associated with the 122 network element, where the latency is defined to be the minimal 123 possible packet delay along the path taken by the flow. This delay 124 may result from "speed-of-light" propagation delay, or from packet 125 processing limitations, or both. The composition rule is additive. 126 This quantity, when composed end-to-end, informs the endpoint of the 127 minimal packet delay along the path from sender to receiver. The 128 parameter_name for the latency of the network element's link is 6. 129 The parameter_name for the cumulative latency along the path is 7. 131 The delays are measured in units of one microsecond. An individual 132 element can advertise a delay value between 1 and 2**28 (somewhat 133 over two minutes) and the total delay added across all elements can 134 range as high as (2**32)-1. Should the sum of the different elements 135 delay exceed (2**32)-1, the end-to-end advertised delay should be 136 (2**32)-1. 138 Note that while the granularity of measurement is microseconds, a 139 conforming element is free to measure delays more loosely. The 140 minimum requirement is that the element estimate its delay accurately 141 to the nearest 100 microsecond granularity. Elements that can 142 measure more accurately are, of course, encouraged to do so. 144 NOTE: If the number of IS hops is less than the number of IP hops, 145 end systems should treat this value as a hint rather than a 146 promised value. 148 NOTE: Measuring in milliseconds is not acceptable, because if the 149 minimum delay value is a millisecond, a path with several hops 150 will lead to a composed delay of at least several milliseconds, 151 which is likely to be misleading. 153 The characterization parameters may be represented as 32-bit unsigned 154 integers in network byte order. 156 NOTE: There are some subnet technologies where determining this 157 minimal delay is difficult. For instance, the speed-of-light 158 delays on an ethernet bridged via satellite with another ethernet 159 vary by several orders of magnitude. The exported values should 160 be conservative estimates of the delays. Any additional delays 161 (that is, delays larger than this minimal amount) must be 162 considered part of the variable delays which are described by 163 characterizations specific to the individual services. For 164 example, in predictive service the maximal delay experienced going 165 from one network element to the next should be the delay bound 166 plus the latency. 168 MTU 170 The local characterization parameter is the MTU, where the MTU of a 171 network element is defined to be the maximum transmission unit the 172 network element can accommodate without fragmentation. The 173 composition rule is to take the minimum of the network element's MTU 174 and the previously composed value. This quantity, when composed end- 175 to-end, informs the endpoint of the maximum transmission unit that 176 can traverse the path from sender to receiver without fragmentation. 178 The parameter_name for the MTU of the network element's link is 8. 179 The parameter_name for the composed MTU along the path is 9. 181 NOTE: If the number of IS hops is less than the number of IP hops, 182 end systems should treat this value as a hint rather than a 183 promised value. 185 Service Availability 187 The INT SERV working group is still developing proposals for handling 188 heterogeneity. When that work is complete, a set of requirement 189 parameters will be defined. 191 Security Considerations 193 Security considerations are not discussed in this memo. 195 References 197 [1] S. Shenker and J. Wroclawski. "Network Element Service 198 Specification Template", Internet Draft, June 1995, 201 [2] S. Shenker, C. Partridge, and J. Wroclawski. "Specification of 202 Controlled Delay Quality of Service", Internet Draft, ?? 1995, 203 205 [3] S. Shenker and C. Partridge. Specification of Guaranteed Quality 206 of Service", Internet Draft, ?? 1995, 209 [4] S. Shenker, C. Partridge, B. Davie, and L. Breslau. 210 "Specification of Predictive Quality of Service", Internet Draft, ?? 211 1995, 213 Author's Address: 215 Scott Shenker 216 Xerox PARC 217 3333 Coyote Hill Road 218 Palo Alto, CA 94304-1314 219 shenker@parc.xerox.com 220 415-812-4840 221 415-812-4471 (FAX)