idnits 2.17.1 draft-ietf-intserv-charac-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 ([1-3], [2-3], [1]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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-3' on line 52 -- Looks like a reference, but probably isn't: '1-3' on line 98 == Unused Reference: '3' is defined on line 299, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT S. Shenker/J. Wroclawski 3 draft-ietf-intserv-charac-01.txt Xerox PARC/MIT LCS 4 June, 1996 5 Expires: 12/96 7 Specification of General Characterization Parameters 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 This document is a product of the Integrated Services working group 28 of the Internet Engineering Task Force. Comments are solicited and 29 should be addressed to the working group's mailing list at int- 30 serv@isi.edu and/or the author(s). 32 Abstract 34 This memo defines general characterization parameters for network 35 elements supporting enhanced qualities of service. 36 Characterization parameters are used to characterize the service 37 environment along the path of a packet flow desiring QoS control. 38 General characterization parameters are those that are not 39 specific to a particular quality of service. 41 Introduction 43 This memo defines a standard for general, or service-independent, 44 characterization parameters for network elements. General 45 characterization parameters are those that are not specific to a 46 particular quality of service. A discussion of how these parameters 47 fit into an integrated services architecture can be found in [1]. 48 Please refer to that document for definitions and additional 49 information about the specification of qualities of service within 50 the IP protocol family. 52 The specifications of the various qualities of service ([2-3]) 53 describe the associated characterization parameters made available by 54 those services. However, there are some quantities of interest that 55 are not specific to a particular quality of service. These "general" 56 characterizations are described in this document. 58 Characterization parameters are named using a scheme described in 59 [1]. Each parameter is identified by a service_name and a 60 parameter_within_service field. The service-name associated with 61 general characterization parameters is 0. The 62 parameter_within_service value for each parameter defined in this 63 document is given below. 65 Parameters described here are of two types; local or composed. Local 66 parameters reflect a value exported by a single network element. 67 Composed parameters reflect the running composition of local 68 parameters along a path, as specified by a composition rule. The 69 definition of each parameter also specifies the composition rule. 71 Both local and composed parameters are named so that a network 72 management entity can request the value of either a local or path- 73 composed parameter at any point within the network. 75 Note that a particular service may specify a service_specific 76 parameter which overrides a general parameter with the same 77 information. For example, a service may allow network elements to 78 specify a MTU for packets requesting that service which is smaller 79 than the physical MTU supported by the network element. 81 Conceptually, all characterization parameter definitions are "per- 82 next-hop" as opposed to "per interface" or "per network element". In 83 cases where the network element is a (or controlling) a shared media 84 path, the element may need to provide different values for different 85 next-hops. In some cases, parameter definitions may include a 86 tolerance range, such that if all next-hop values are within the 87 tolerance range only a single value need be stored and provided. 89 This document is not yet stable, and should not be taken as an 90 implementation specification. 92 Parameter Definitions 94 Number of IS Hops 96 IS stands for "integrated services aware". An integrated services 97 aware network element is one that conforms to the various 98 requirements described in this document and the documents [1-3]. (The 99 network element need not offer those services, but if it does it 100 supports and characterizes the services in conformance with the 101 relevant specification). The local parameter always has a value of 1. 102 For completeness, the local parameter is assigned the parameter_name 103 1. 105 The composition rule for this parameter is to increment the counter 106 by one at each IS-aware hop. This quantity, when composed end-to-end, 107 informs the endpoint of the number of Integrated-Services aware 108 network elements traversed along the path from sender to receiver. 109 The parameter_name for this composed parameter is 2. The parameter 110 may be represented as a single 16-bit unsigned integer in network 111 byte order. 113 Non-IS hop encountered flag 115 For each outgoing path from a network element, the local parameter is 116 0 if the network element is certain that there exists no break in the 117 QoS control services between itself and the next IS-aware network 118 element on the path. The local parameter is 1 otherwise. The local 119 parameter is assigned parameter_name 3. 121 The actual responsibility for computing the value of the local 122 parameter at a network node along the path may fall to the network 123 element, the setup protocol, or a manual configuration operation. 124 This calculation must be conservative. For example, a router sending 125 packets into an IP tunnel must assume that the tunneled packets will 126 not receive QoS control services unless it or the setup protocol can 127 prove otherwise. 129 The composition rule for this parameter is the OR function. A 130 composed parameter value of 1 arriving at the endpoint of a path 131 indicates that at least one point along the path does not offer QoS 132 control services. The parameter_name for the composed quantity is 4. 134 These characterization parameters may be represented as 16-bit 135 unsigned integers in network byte order. 137 If the Non-IS-hop flag is set for a path, the values of all other 138 parameters defined in this specification must be considered 139 approximate. 141 NOTE: The previous version of this document defined the above 142 parameter as a count. Discussion within the intserv and RSVP 143 groups suggests that accurately counting non-IS hops in all 144 situations is both difficult and unnecessary. 146 Minimum Available Path Bandwidth 148 The local parameter is the minimum bandwidth the network element 149 makes available to packets following the path. The value of this 150 parameter must be as accurate as possible, taking into consideration 151 administrative and policy controls on bandwidth, as well as physical 152 resources. Computation of the value of this parameter should take 153 into account all information available to the network element about 154 the path. If the value cannot be calculated exactly, the result 155 should err on the side of underestimating the available bandwidth. 157 The composition rule for this parameter is the MIN() function; the 158 composed value is the minimum of the network element's value and the 159 previously composed value. This quantity, when composed end-to-end, 160 informs the endpoint of the minimal bandwidth link along the path 161 from sender to receiver. The parameter_name for the bandwidth of the 162 network element is 4. The parameter_name for the composed minimal 163 bandwidth along the path is 5. 165 These values are measured in bytes per second, and can range from 1 166 byte per second to as large as 40 terabytes per second (or about what 167 is believed to be the maximum theoretical bandwidth of a single 168 strand of fiber). Clearly, particularly for large bandwidths, only 169 the first few digits are significant and so the use of floating point 170 representations, accurate to at least 0.1% is encouraged. These 171 characterizations of bandwidth can be represented by floating point 172 numbers in single-precision IEEE floating point format. Only bit 173 patterns representing valid zero or positive floating-point numbers 174 are allowed. Bit patterns representing negative numbers, NAN's, or 175 "negative zero" are illegal. 177 NOTE: This parameter should reflect, as much as possible, policy 178 and administrative restrictions on bandwidth available to a path. 179 However, the actual value available may depend on a number of 180 factors not available to the network element, such as the 181 destination(s) of the packet flow, the service to be requested by 182 the flow, or external policy information associated with a 183 reservation request. This makes it difficult to provide the 184 parameter accurately. Generally, a network element expected to 185 provide an accurate value of this parameter would have to have in 186 hand all of the information necessary to process a resource 187 reservation request. In circumstances where the parameter cannot 188 be provided accurately, the network element should come as close 189 as possible, but is not expected to be either "conservative" 190 (consistantly estimating low) or "liberal" (consistantly 191 estimating high). 193 Minimum Path Latency 195 The local parameter is the latency of the link associated with the 196 network element, where the latency is defined to be the minimal 197 possible packet delay along the path taken by the flow. This delay 198 may result from "speed-of-light" propagation delay, from packet 199 processing limitations, or both. 201 When packets leaving a network element may follow different paths, 202 such as virtual circuits within an ATM cloud, different latency 203 values must be provided for different paths. Doing so may require 204 cooperation between the ingress and egress elements bounding a 205 communication cloud. The method by which this cooperation is 206 achieved, and the choice of which IP-level network element actually 207 provides and composes the value, is technology-dependent. 209 It is acceptable to provide a single value for multiple paths if the 210 latency values of all paths are within 10 percent or 100 microseconds 211 of each other, whichever is greater. 213 In certain cases determining the correct latency value to report is 214 extremely difficult. For instance, the speed-of-light delays on an 215 ethernet bridged via satellite with another ethernet vary by several 216 orders of magnitude. In a case such as this the network element may 217 either employ a latency estimation protocol, return the best-case 218 (longest) minimum latency between any two nodes using the shared 219 resource, or return the "indeterminate" value, as specified below. 221 NOTE: This parameter represents the "minimal minimum" path 222 latency. In a shared-media situation it should represent the 223 shortest latency between the local node and any other. The 224 rationale for this is that the parameter is intended for use with 225 services such as Guaranteed [ref] which provide a means to 226 advertise additional latency above the minimum. 228 The composition rule for this parameter is summation with a clamp of 229 (2**32 - 1) on the maximum value. This quantity, when composed end- 230 to-end, informs the endpoint of the minimal packet delay along the 231 path from sender to receiver. The parameter_name for the latency of 232 the network element's link is 6. The parameter_name for the 233 cumulative latency along the path is 7. 235 The delays are measured in units of one microsecond. An individual 236 element can advertise a delay value between 1 and 2**28 (somewhat 237 over two minutes) and the total delay added across all elements can 238 range as high as (2**32)-2. Should the sum of the different elements 239 delay exceed (2**32)-2, the end-to-end advertised delay should be 240 (2**32)-1. This value is explained in the next paragraph. 242 The value (2**32)-1 is taken to mean "indeterminate latency". A 243 network element which cannot accurately predict the latency of 244 packets it is processing should set its local parameter to this 245 value. Because the composition function limits the composed sum to 246 this value, presence of this value at the end-point of the path 247 indicates that the true path latency is not known. This may happen 248 because one or more network elements could not supply a value, or 249 because the range of the composition calculation was exceeded. 251 Note that while the granularity of measurement is microseconds, a 252 conforming element is free to measure delays more loosely. The 253 minimum requirement is that the element estimate its delay accurately 254 to the nearest 100 microsecond granularity. Elements that can measure 255 more accurately are, of course, encouraged to do so. 257 NOTE: Measuring in milliseconds is not acceptable, because if the 258 minimum delay value is a millisecond, a path with several hops 259 will lead to a composed delay of at least several milliseconds, 260 which is likely to be misleading. 262 The characterization parameters may be represented as 32-bit unsigned 263 integers in network byte order. 265 Path MTU 267 The local characterization parameter is the path IP MTU, where the 268 MTU of a network element is defined to be the maximum transmission 269 unit the network element can accommodate without fragmentation 270 including IP and upper-layer protocol headers, but not including link 271 level headers. The composition rule is to take the minimum of the 272 network element's MTU and the previously composed value. This 273 quantity, when composed end-to-end, informs the endpoint of the 274 maximum transmission unit that can traverse the path from sender to 275 receiver without fragmentation. The parameter_name for the MTU of the 276 network element's link is 8. The parameter_name for the composed MTU 277 along the path is 9. 279 Service Availability 281 The INT SERV working group is still developing proposals for handling 282 heterogeneity. When that work is complete, a set of requirement 283 parameters will be defined. 285 Security Considerations 287 Security considerations are not discussed in this memo. 289 References 291 [1] S. Shenker and J. Wroclawski. "Network Element Service 292 Specification Template", Internet Draft, June 1995, 295 [3] S. Shenker and C. Partridge. Specification of Guaranteed Quality 296 of Service", Internet Draft, June 1996, 299 [3] J. Wroclawski. "Specification of the Controlled Load Quality of 300 Service", Internet Draft, November 1995, 303 Author's Address: 305 Scott Shenker 306 Xerox PARC 307 3333 Coyote Hill Road 308 Palo Alto, CA 94304-1314 309 shenker@parc.xerox.com 310 415-812-4840 311 415-812-4471 (FAX) 313 John Wroclawski 314 MIT Laboratory for Computer Science 315 545 Technology Sq. 316 Cambridge, MA 02139 317 jtw@lcs.mit.edu 318 617-253-7885 319 617-253-2673 (FAX)