idnits 2.17.1 draft-ietf-intserv-charac-02.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-03-28) 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. 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) == Unused Reference: 'RFCRSVP' is defined on line 660, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCRSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCRSVPUSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCTEMPLATE' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCG' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCCL' ** Obsolete normative reference: RFC 1832 (ref. 'RFCXDR') (Obsoleted by RFC 4506) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 and J. Wroclawski 3 draft-ietf-intserv-charac-02.txt Xerox PARC/MIT LCS 4 October, 1996 5 Expires: 3/97 7 General Characterization Parameters for 8 Integrated Service Network Elements 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 a set of general control and characterization 36 parameters for network elements supporting the IETF integrated 37 services QoS control framework. General parameters are those with 38 common, shared definitions across all QoS control services. 40 1. Introduction 42 This memo defines the set of general control and characterization 43 parameters used by network elements supporting the integrated 44 services framework. "General" means that the parameter has a common 45 definition and shared meaning across all QoS control services. 47 Control parameters are used by applications to provide information to 48 the network related to QoS control requests. An example is the 49 traffic specification (TSpec) generated by application senders and 50 receivers. 52 Characterization parameters are used to discover or characterize the 53 QoS management environment along the path of a packet flow requesting 54 active end-to-end QoS control. These characterizations may 55 eventually be used by the application requesting QoS control, or by 56 other network elements along the path. Examples include information 57 about which QoS control services are available along a network path 58 and estimates of the available path bandwidth. 60 Individual QoS control service specifications may refer to these 61 parameter definitions as well as defining additional parameters 62 specific to the needs of that service. 64 Parameters are assigned machine-oriented ID's using a method 65 described in [RFCTEMPLATE] and summarized here. These ID's may be 66 used within protocol messages and management interfaces to describe 67 the parameter values present. Each parameter ID is composed from two 68 numbers, one identifying the service associated with the parameter 69 (the ), and the other (the ) 70 identifying the parameter itself. values for the 71 parameters defined in this document are assigned from the "general 72 parameters" range (1 - 127). Numbers in this range indicate that the 73 parameter definition is shared by all QoS control services. 75 NOTE: Parameters numbered 128 - 254 have definitions specific to a 76 particular QoS control service. In contrast to the general 77 parameters described here, the parameter's meaning depends on the 78 service_number portion of the parameter ID. 80 Service number 1 is reserved for use as described in Section 2 of 81 this note. Service numbers 2 through 254 will be allocated to 82 individual QoS control services. Currently, Guaranteed service 83 [RFCG] is allocated number 2, and Controlled-load service [RFCCL] 84 is allocated number 5. 86 In this note, the textual form 88 90 is used to write a service_number, parameter_number pair. The range 91 of possible of service_number and parameter_number values specified 92 in [RFCTEMPLATE] allow the parameter ID to directly form the tail 93 portion of a MIB object ID representing the parameter. This 94 simplifies the task of making parameter values available to network 95 management applications. 97 The definition of each parameter used to characterize a path through 98 the network describes two types of values; local and composed. Local 99 values reflect conditions at a single network element. Composed 100 values reflect the running composition of local values along a path, 101 as specified by a composition rule. Each parameter definition 102 specifies the composition rule for that parameter. The composition 103 rule describes how to combine the arriving composed value and the 104 local value, to give a new composed value which is passed to the next 105 network element in the path. Note that the composition may proceed 106 either downstream, toward the receiver(s), or upstream, toward the 107 sender. Each parameter may give only one definition for the local 108 value, but may give more than one definition for composition rules 109 and composed values. This is because it may be useful to compose the 110 same local value several times following different composition rules. 112 Because characterization parameters are used to compute the 113 properties of a specific path through the internetwork, all 114 characterization parameter definitions are conceptually "per-next- 115 hop", as opposed to "per interface" or "per network element". In 116 cases where the network element is (or is controlling) a shared media 117 or large-cloud subnet, the element may need to provide different 118 values for different next-hops. In practice, it may be appropriate 119 for vendors to choose and document a tolerance range, such that if 120 all next-hop values are within the tolerance range only a single 121 value need be stored and provided. 123 Local and composed characterization parameter values have distinct 124 ID's so that a network management entity can request the value of 125 either a local or path-composed parameter at any point within the 126 network. 128 Each parameter definition includes a description of the minimal 129 properties, such as range and precision, required of any wire 130 representation of that parameter's values. Each definition also 131 includes an XDR [RFCXDR] description of the parameter, describing an 132 appropriate external (wire) data representation for the parameter's 133 values. This dual definition is intended to encourage a common wire 134 representation format whenever possible, while still allowing other 135 representations when required by the specific circumstances (e.g., 136 ASN.1 within SNMP). 138 The message formats specified in [RFCRSVPUSE] for use with the RSVP 139 setup protocol use the XDR data representation parameters. 141 All of the parameters described in this note are mandatory, in the 142 sense that a network element claiming to support integrated service 143 must recognize arriving values in setup and management protocol 144 messages, process them correctly, and export a reasonable value in 145 response. For certain parameters, it is required that the network 146 element compute and export an *accurate* local value. For other 147 parameters, it is acceptable for the network element to indicate that 148 it cannot compute and export an accurate local value. The definition 149 of these parameters provides a reserved value which indicates 150 "indeterminate" or "invalid". This value signals that an element 151 cannot process the parameter accurately, and consequently that the 152 result of the end-to-end composition is also questionable. 154 NOTE (temporary): Previous versions of this and the RSVP use 155 document used both the reserved-value approach and a separate 156 INVALID flag to record this fact. Now, the reserved-value 157 approach is used exclusively. This is so that any protocol which 158 retrieves a parameter value, including SNMP, can carry the invalid 159 indication without needing a separate flag. The INVALID flag 160 remains in the RSVP message format but is reserved for use only 161 with a possible future service-composition scheme. 163 2. Default and Service-Specific Values for General Parameters 165 General parameters have a common *definition* across all QoS control 166 services. Frequently, the same *value* of a general parameter will be 167 correct for all QoS control services supported at a network element. 168 In this circumstance, there is no need to export a separate copy of 169 the value for each QoS control service; instead the node can export 170 one copy which applies to all supported services. 172 A general parameter value which applies to all services supported at 173 a network node is called a default or global value. For example, if 174 all of the QoS control services provided at a node support the same 175 maximum packet size, the node may export a single default value for 176 the PATH_MTU parameter described in Section 3, rather than providing 177 a separate copy of the value for each QoS control service. In the 178 common case, this reduces both message size and processing overhead 179 for the setup protocol. 181 Occasionally an individual service needs to report a value differing 182 from the default value for a particular general parameter. For 183 example, if the implementation of Guaranteed Service [RFCG] at a 184 router is restricted by scheduler or hardware considerations to a 185 maximum packet size smaller than supported by the router's best- 186 effort forwarding path, the implementation may wish to export a 187 "service-specific" value of the PATH_MTU parameter so that 188 applications using the Guaranteed service will function correctly. 189 In the example above, the router might supply a value of 1500 for the 190 default PATH_MTU parameter, and a value of 250 for the PATH_MTU 191 parameter applying to guaranteed service. In this case, the setup 192 protocol providing path characterization carries (and delivers to the 193 application) both a value for Guaranteed service and a value for 194 other services. 196 The distinction between default and service-specific parameter values 197 makes no sense for non-general parameters (those defined by a 198 specific QoS control service, rather than this note), because both 199 the definition and value of the parameter are always specific to the 200 particular service. 202 The distinction between default and service-specific values for 203 general parameters is reflected in the parameter ID name space. This 204 allows network nodes, setup protocols, and network management tools 205 to distinguish default from service-specific values, and to determine 206 which service a service-specific parameter value is associated with. 208 Service number 1 is used to indicate the default value. A parameter 209 value identified by the ID: 211 <1, parameter_number> 213 is a default value, which applies to all services unless it is 214 overridden by a service-specific value for the same parameter. 216 A parameter value identified by the ID: 218 220 where service_number is not equal to 1, is a service-specific value. 221 It applies only to the service identified by service_number. 223 These service-specific values are also called override values. When 224 both service-specific and default values are present for a parameter, 225 the service-specific value overrides the default value (for the 226 service to which it applies). The rules for composing service- 227 specific and global general parameters support this override 228 capability. The basic rule is to use the service-specific value if 229 it exists, and otherwise the global value. 231 A complete summary of the characterization parameter composition 232 process is given below. In this summary, the "arriving value" is the 233 incompletely composed parameter value arriving from a neighbor node. 234 The "local value" is the (global or service-specific) value made 235 available by the local node. The "result" is the newly composed value 236 to be sent to the next node on the data path. 238 1. Examine the pair associated 239 with the arriving value. This information is conveyed by the setup 240 protocol together with the arriving value. 242 2. If the arriving value is for a parameter specific to a single 243 service (the parameter_number is larger than 128), compose the 244 arriving value with the locally value exported by the specified 245 service, and pass the result to the next hop. 247 3. If the arriving value is a service-specific value for a general 248 parameter (the parameter_number is 127 or less, and the 249 service_number is other than 1), and the local implementation of 250 that service also exports a service-specific value for the 251 parameter, compose the service-specific arriving value and the 252 service-specific local value of the parameter, and pass the result 253 as a service-specific value to the next-hop node. 255 4. If the arriving value is a service-specific value for a general 256 parameter (the parameter_number is 127 or less, and the 257 service_number is other than 1), and the local implementation of 258 that service does *not* export a service-specific value, compose 259 the service-specific arriving value with the global value for that 260 parameter exported by the local node, and pass the result as a 261 service-specific value to the next-hop node. 263 5. If the arriving value is a global value for a general parameter 264 (parameter_number is 127 or less, and the service_number is 1), and 265 the local implementation of *any* service exports a service- 266 specific value for that general parameter, compose the arriving 267 (global) value with the service-specific value for that parameter 268 exported by the local service, and pass the result as a service- 269 specific value to the next-hop node. This will require adding a new 270 data field to the message passed to the next hop, to hold the newly 271 generated service-specific value. Repeat this process for each 272 service that exports a service-specific value for the parameter. 274 6. If the arriving value is a global value for a general parameter 275 (the service_number is 1, and the parameter_number is 127 or less), 276 compose the arriving (global) value with the global parameter value 277 exported by the local node, and pass the result as a global 278 (service 1) value to the next-hop node. This step is performed 279 whether or not any service-specific values were generated and 280 exported in step 5. 282 3. General Parameter Definitions 283 3.1 NON-IS_HOP flag parameter 285 This parameter provides information about the presence of network 286 elements which do not implement QoS control services along the data 287 path. 289 The local value of the parameter is 1 if the network element does not 290 implement the relevant QoS control service, or knows that there is a 291 break in the chain of elements which implement the service. The 292 local parameter is 0 otherwise. The local parameter is assigned 293 parameter_number 1. 295 The composition rule for this parameter is the OR function. A 296 composed parameter value of 1 arriving at the endpoint of a path 297 indicates that at least one point along the path does not offer the 298 indicated QoS control service. The parameter_number for the composed 299 quantity is 2. 301 The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this 302 flag is set, it indicates that one or more network elements along the 303 application's data path does not support the integrated services 304 framework at all. An example of such an element would be an IP router 305 offering only best-effort packet delivery and not supporting any 306 resource reservation requests. 308 Obviously, a network element which does not support this 309 specification will not know to set this flag. The actual 310 responsibility for determining that a network node does not support 311 integrated services may fall to the network element, the setup 312 protocol, or a manual configuration operation and is dependent on 313 implementation and usage. This calculation must be conservative. 314 For example, a router sending packets into an IP tunnel must assume 315 that the tunneled packets will not receive QoS control services 316 unless it or the setup protocol can prove otherwise. 318 Service-specific versions of the NON_IS_HOP flag indicate that one or 319 more network elements along a path don't support the particular 320 service. For example, the flag parameter identified by ID <2,2> being 321 set indicates that some network element along the path does not 322 support the Guaranteed service, though it might support another 323 service such as Controlled-Load. 325 If the global NON_IS_HOP flag <1,2> is set for a path, the receiver 326 (network element or application) should consider the values of all 327 other parameters defined in this specification, including service- 328 specific NON_IS_HOP flags, as possibly inaccurate. If a service 329 specific NON_IS_HOP flag is set for a path, the receiver should 330 consider the values of all other parameters associated with that 331 service as possibly inaccurate. 333 The NON_IS_HOP parameter may be represented in any form which can 334 express boolean true and false. However, note that a network element 335 must set this flag precisely when it does *not* fully understand the 336 format or data representation of an arriving protocol message 337 (because it does not support the specified service). Therefore, the 338 data representation used for this parameter by setup and management 339 protocols must allow the parameter value to be read and set even if 340 the network element cannot otherwise parse the protocol message. 342 An appropriate XDR description of this parameter is: 344 bool NON_IS_HOP; 346 However, the standard XDR data encoding for this description will not 347 meet the requirement described above unless other restrictions are 348 placed on message formats. An alternative data representation may be 349 more appropriate. 351 NOTE: The message format described for RSVP in [RFCRSVPUSE] carries 352 this parameter as a single-bit flag, referred to as the "break 353 bit". 355 3.2 NUMBER_OF_IS_HOPS 357 IS stands for "integrated services aware". An integrated services 358 aware network element is one that conforms to the various 359 requirements described in this and other referenced documents. The 360 network element need not offer a specific service, but if it does it 361 must support and characterize the service in conformance with the 362 relevant specification, and if it does not it must correctly set the 363 NON_IS_HOP flag parameter for the service. For completeness, the 364 local parameter is assigned the parameter_number 3. 366 The composition rule for this parameter is to increment the counter 367 by one at each IS-aware hop. This quantity, when composed end-to- 368 end, informs the endpoint of the number of integrated-services aware 369 network elements traversed along the path. The parameter_number for 370 this composed parameter is 4. 372 Values of the composed parameter will range from 1 to 255, limited by 373 the bound on IP hop count. 375 The XDR representation of this parameter is: 377 unsigned int NUMBER_OF_IS_HOPS; 379 3.3. AVAILABLE_PATH_BANDWIDTH 381 This parameter provides information about the bandwidth available 382 along the path followed by a data flow. The local parameter is an 383 estimate of the bandwidth the network element has available for 384 packets following the path. Computation of the value of this 385 parameter should take into account all information available to the 386 network element about the path, taking into consideration 387 administrative and policy controls on bandwidth, as well as physical 388 resources. 390 NOTE: This parameter should reflect, as closely as possible, the 391 actual bandwidth available to packets following a path. However, 392 the bandwidth available may depend on a number of factors not 393 known to the network element until a specific QoS request is in 394 place, such as the destination(s) of the packet flow, the service 395 to be requested by the flow, or external policy information 396 associated with a reservation request. Because the parameter must 397 in fact be provided before any specific QoS request is made, it is 398 frequently difficult to provide the parameter accurately. In 399 circumstances where the parameter cannot be provided accurately, 400 the network element should make the best attempt possible, but is 401 permitted to overestimate the available bandwidth by a significant 402 amount. 404 The parameter_number for AVAILABLE_PATH_BANDWIDTH is 5. The global 405 parameter <1, 5> is an estimate of the bandwidth available to any 406 packet following the path, without consideration of which (if any) 407 QoS control service the packets may be subject to. 409 In cases where a particular service is administratively or 410 implementationally restricted to a limited portion of the overall 411 available bandwidth, the service module may wish to export an 412 override parameter which specifies this smaller bandwidth value. 414 The composition rule for this parameter is the MIN function. The 415 composed value is the minimum of the network element's value and the 416 previously composed value. This quantity, when composed end-to-end, 417 informs the endpoint of the minimal bandwidth link along the path 418 from sender to receiver. The parameter_number for the composed 419 minimal bandwidth along the path is 6. 421 Values of this parameter are measured in bytes per second. The 422 representation must be able to express values ranging from 1 byte per 423 second to 40 terabytes per second, about what is believed to be the 424 maximum theoretical bandwidth of a single strand of fiber. 425 Particularly for large bandwidths, only the first few digits are 426 significant, so the use of a floating point representation, accurate 427 to at least 0.1%, is encouraged. 429 The XDR representation for this parameter is: 431 float AVAILABLE_PATH_BANDWIDTH; 433 For values of this parameter only valid non-negative floating point 434 numbers are allowed. Negative numbers (including "negative zero"), 435 infinities, and NAN's are not allowed. 437 NOTE: An implementation which utilizes general-purpose hardware or 438 software IEEE floating-point support may wish to verify that 439 arriving parameter values meet these requirements before using the 440 values in floating-point computations, in order to avoid 441 unexpected exceptions or traps. 443 If the network element cannot or wishes not to provide an estimate of 444 path bandwidth, it may export a local value of zero for this 445 parameter. A network element or application receiving a composed 446 value of zero for this parameter should assume that the actual 447 bandwidth available is unknown. 449 3.4 MINIMUM_PATH_LATENCY 451 The local parameter is the latency of the packet forwarding process 452 associated with the network element, where the latency is defined to 453 be the *minimal* possible packet delay added by the network element 454 This delay may result from speed-of-light propagation delay, from 455 packet processing limitations, or both. It does not include any 456 variable queuing delay which may be present. 458 The purpose of this parameter is to provide a baseline minimal path 459 latency for use with services which provide estimates or bounds on 460 additional path delay, such as Guaranteed [RFCG]. In conjunction 461 with the queuing delay bound offered by Guaranteed and similar 462 services, this parameter gives the application knowledge of both the 463 minimum and maximum packet delivery delay. Knowing both the minimum 464 and maximum latency experienced by data packets allows the receiving 465 application to accurately compute its de-jitter buffer requirements. 467 Note that the quantity characterized by this parameter is the 468 absolute lower bound on the packet processing and transmission 469 latency of the network element. This value is the quantity required 470 to provide jitter bounding. The parameter does *not* provide the type 471 of upper-bound estimate on minimum latency which might be of interest 472 for best-effort traffic and QoS control services which do not 473 explicitly offer delay bounds. That is, the parameter will always 474 underestimate, rather than overestimate, latency, particularly in 475 multicast and large cloud situations. 477 When packets traversing a network element may experience different 478 minimal latencies, this parameter should ideally report an accurate 479 latency value for each path. For example, when an ATM point- 480 multipoint virtual circuit is used to implement IP multicast, the 481 mechanism used to implement this parameter would ideally compute a 482 separate value for each destination. Doing so may require cooperation 483 between the ingress and egress elements bounding the multi-path 484 communication cloud. The method by which this cooperation is 485 achieved, and the choice of which IP-level network element actually 486 provides and composes the value, is technology-dependent. 488 An alternative choice is to provide the same value of this parameter 489 for all paths through the cloud. The value reported must be the 490 smallest latency for any possible path. Note that in this situation, 491 QoS control services (e.g., Guaranteed) which provide an upper bound 492 on latency cannot simply add their queuing delay to the value 493 computed by this parameter; they must also compensate for path delays 494 above the minimum. In this case the range between the minimum and 495 maximum packet delays reported to the application will be larger, 496 because the application will be told about the minimum delay along 497 the shortest path and the maximum delay along the actual path. This 498 is acceptable in many situations. 500 A third alternative is to report the "indeterminate" value, as 501 specified below. In this circumstance the client application may 502 either deduce a minimum path latency through measurement, or assume a 503 value of zero. 505 The composition rule for this parameter is summation with a clamp of 506 (2**32 - 1) on the maximum value. This quantity, when composed end- 507 to-end, informs the endpoint of the minimal packet delay along the 508 path from sender to receiver. The parameter_number for the latency of 509 the network element's link is 7. The parameter_number for the 510 cumulative latency along the path is 8. 512 The latencies are measured in units of one microsecond. An individual 513 element can advertise a latency value between 1 and 2**28 (somewhat 514 over two minutes) and the total latency added across all elements can 515 range as high as (2**32)-2. Should the sum of the different elements 516 delay exceed (2**32)-2, the end-to-end advertised delay should be 517 reported as indeterminate. This is described below. 519 Note that while the granularity of measurement is microseconds, a 520 conforming element is free to measure delays more loosely. The 521 minimum requirement is that the element estimate its delay accurately 522 to the nearest 100 microsecond granularity. Elements that can measure 523 more accurately are, of course, encouraged to do so. 525 NOTE: Measuring in milliseconds is not acceptable, because if the 526 minimum delay value is a millisecond, a path with several hops 527 will lead to a composed delay of at least several milliseconds, 528 which is likely to be misleading. 530 The XDR description of this parameter is: 532 unsigned int MINIMUM_PATH_LATENCY; 534 The distinguished value (2**32)-1 is taken to mean "indeterminate 535 latency". A network element which cannot accurately predict the 536 latency of packets it is processing should set its local parameter to 537 this value. Because the composition function limits the composed sum 538 to this value, receipt of this value at a network element or 539 application indicates that the true path latency is not known. This 540 may happen because one or more network elements could not supply a 541 value, or because the range of the composition calculation was 542 exceeded. 544 3.5. PATH_MTU 546 This parameter computes the maximum transmission unit (MTU) for 547 packets following a data path. This value is required to invoke QoS 548 control services which require that IP packet size be strictly 549 limited to a specific MTU. Existing MTU discovery mechanisms cannot 550 be used because they provide information only to the sender and they 551 do not directly allow for QoS control services to specify MTU's 552 smaller than the physical MTU. 554 The local characterization parameter is the IP MTU, where the MTU of 555 a network element is defined to be the maximum transmission unit the 556 network element can accommodate without fragmentation, including IP 557 and upper-layer protocol headers but not including link level 558 headers. The composition rule is to take the minimum of the network 559 element's MTU and the previously composed value. This quantity, when 560 composed end-to-end, informs the endpoint of the maximum transmission 561 unit that can traverse the path from sender to receiver without 562 fragmentation. The parameter_number for the MTU of the network 563 element's link is 9. The parameter_number for the composed MTU along 564 the path is 10. 566 A correct and valid value of this parameter must be provided by all 567 IS-aware network elements. 569 A specific service module may specify an MTU smaller than that of the 570 overall network element by overriding this parameter with one giving 571 the service's MTU value. A service module may not specify an MTU 572 value larger than that given by the global parameter. 574 Values of this parameter are measured in bytes. The representation 575 must be able to express values ranging from 1 byte to 2**32-1 bytes. 577 The XDR description of this parameter is: 579 unsigned int PATH_MTU; 581 3.6. TOKEN_BUCKET_TSPEC 583 This parameter is used to describe data traffic parameters using a 584 simple token bucket filter. This parameter is used by data senders to 585 describe the traffic parameters of traffic it expects to generate, 586 and by QoS control services to describe the parameters of traffic for 587 which the reservation should apply. It is defined as a general rather 588 than service-specific parameter because the same traffic description 589 may be used by several QoS control services in some situations. 591 The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127. 593 The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification 594 plus a peak rate p, minimum policed unit m, and a maximum packet size 595 M. 597 The token bucket specification includes an average or token rate r 598 and a bucket depth b. Both r and b must be positive. 600 The token rate r is measured in bytes of IP datagrams per second. 601 Values of this parameter may range from 1 byte per second to 40 602 terabytes per second. In practice, only the first few digits of the r 603 and p parameters are significant, so the use of floating point 604 representations, accurate to at least 0.1% is encouraged. 606 The bucket depth, b, is measured in bytes. Values of this parameter 607 may range from 1 byte to 250 gigabytes. In practice, only the first 608 few digits of the b parameter are significant, so the use of floating 609 point representations, accurate to at least 0.1% is encouraged. 611 The peak traffic rate p is measured in bytes of IP datagrams per 612 second. Values of this parameter may range from 1 byte per second to 613 40 terabytes per second. In practice, only the first few digits of 614 the r and p parameters are significant, so the use of floating point 615 representations, accurate to at least 0.1% is encouraged. The peak 616 rate value may be set to positive infinity, indicating that it is 617 unknown or unspecified. 619 The range of values allowed for these parameters is intentionally 620 large to allow for future network technologies. Any particular 621 network element is not expected to support the full range of values. 623 The minimum policed unit, m, is an integer measured in bytes. All IP 624 datagrams less than size m will be counted against the token bucket 625 as being of size m. The maximum packet size, M, is the biggest packet 626 that will conform to the traffic specification; it is also measured 627 in bytes. Both m and M must be positive, and m must be less then or 628 equal to M. 630 The XDR description of this parameter is: 632 struct { 633 float r; 634 float b; 635 float p; 636 unsigned m; 637 unsigned M; 638 } TOKEN_BUCKET_TSPEC; 640 For the fields r and b only valid non-negative floating point numbers 641 are allowed. Negative numbers (including "negative zero), infinities, 642 and NAN's are not allowed. 644 For the field p, only valid non-negative floating point numbers or 645 positive infinity are allowed. Negative numbers (including "negative 646 zero), negative infinities, and NAN's are not allowed. 648 NOTE: An implementation which utilizes general-purpose hardware or 649 software IEEE floating-point support may wish to verify that 650 arriving parameter values meet these requirements before using the 651 values in floating-point computations, in order to avoid 652 unexpected exceptions or traps. 654 4. Security Considerations 656 Security considerations are not discussed in this memo. 658 5. References 660 [RFCRSVP] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - 661 Version 1 Functional Specification", Internet Draft, July 1996, 662 664 [RFCRSVPUSE] J. Wroclawski. "The Use of RSVP with IETF Integrated 665 Services", Internet Draft, October, 1996, 668 [RFCTEMPLATE] S. Shenker and J. Wroclawski. "Network Element QoS 669 Control Service Specification Template". Internet Draft, October 670 1996, 672 [RFCG] S. Shenker, C. Partridge, and R Guerin. "Specification of the 673 Guaranteed Quality of Service", Internet Draft, July 1996, 676 [RFCCL] J. Wroclawski. "Specification of the Controlled Load Quality 677 of Service", Internet Draft, July 1996, 680 [RFCXDR] R. Srinivansan. "XDR: External Data Representation 681 Standard", RFC 1832, August 1995. 683 Author's Address: 685 Scott Shenker 686 Xerox PARC 687 3333 Coyote Hill Road 688 Palo Alto, CA 94304-1314 689 shenker@parc.xerox.com 690 415-812-4840 691 415-812-4471 (FAX) 693 John Wroclawski 694 MIT Laboratory for Computer Science 695 545 Technology Sq. 696 Cambridge, MA 02139 697 jtw@lcs.mit.edu 698 617-253-7885 699 617-253-2673 (FAX)