diff options
Diffstat (limited to 'doc/rfc/rfc2215.txt')
| -rw-r--r-- | doc/rfc/rfc2215.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2215.txt b/doc/rfc/rfc2215.txt new file mode 100644 index 0000000..f072f94 --- /dev/null +++ b/doc/rfc/rfc2215.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group S. Shenker +Request for Comments: 2215 J. Wroclawski +Category: Standards Track Xerox PARC/MIT LCS + September 1997 + + + General Characterization Parameters for + Integrated Service Network Elements + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines a set of general control and characterization + parameters for network elements supporting the IETF integrated + services QoS control framework. General parameters are those with + common, shared definitions across all QoS control services. + +1. Introduction + + This memo defines the set of general control and characterization + parameters used by network elements supporting the integrated + services framework. "General" means that the parameter has a common + definition and shared meaning across all QoS control services. + + Control parameters are used by applications to provide information to + the network related to QoS control requests. An example is the + traffic specification (TSpec) generated by application senders and + receivers. + + Characterization parameters are used to discover or characterize the + QoS management environment along the path of a packet flow requesting + active end-to-end QoS control. These characterizations may + eventually be used by the application requesting QoS control, or by + other network elements along the path. Examples include information + about which QoS control services are available along a network path + and estimates of the available path bandwidth. + + Individual QoS control service specifications may refer to these + parameter definitions as well as defining additional parameters + specific to the needs of that service. + + + +Shenker & Wroclawski Standards Track [Page 1] + +RFC 2215 General Characterization Parameters September 1997 + + + Parameters are assigned machine-oriented ID's using a method + described in [RFC 2216] and summarized here. These ID's may be used + within protocol messages (e.g., as described in [RFC 2210]) or + management interfaces to describe the parameter values present. Each + parameter ID is composed from two numerical fields, one identifying + the service associated with the parameter (the <service_number>), and + the other (the <parameter_number>) identifying the parameter itself. + Because the definitions of the parameters defined in this note are + common to all QoS control services, the <parameter_number> values for + the parameters defined here are assigned from the "general + parameters" range (1 - 127). + + NOTE: <parameter_numbers> in the range 128 - 254 name parameters + with definitions specific to a particular QoS control service. In + contrast to the general parameters described here, it is necessary + to consider both the <service_number> and <parameter_number> to + determine the meaning of the parameter. + + Service number 1 is reserved for use as described in Section 2 of + this note. Service numbers 2 through 254 will be allocated to + individual QoS control services. Currently, Guaranteed service + [RFC 2212] is allocated number 2, and Controlled-load service [RFC + 2211] is allocated number 5. + + In this note, the textual form + + <service_number, parameter_number> + + is used to write a service_number, parameter_number pair. The range + of possible of service_number and parameter_number values specified + in [RFC 2216] allow the parameter ID to directly form the tail + portion of a MIB object ID representing the parameter. This + simplifies the task of making parameter values available to network + management applications. + + The definition of each parameter used to characterize a path through + the network describes two types of values; local and composed. A + Local value gives information about a single network element. + Composed values reflect the running composition of local values along + a path, specified by some composition rule. Each parameter + definition specifies the composition rule for that parameter. The + composition rule tells how to combine an incoming composed value + (from the already-traversed portion of the path) and the local value, + to give a new composed value which is passed to the next network + element in the path. Note that the composition may proceed either + + + + + + +Shenker & Wroclawski Standards Track [Page 2] + +RFC 2215 General Characterization Parameters September 1997 + + + downstream, toward the receiver(s), or upstream, toward the sender. + Each parameter may give only one definition for the local value, but + may potentially give more than one definition for composition rules + and composed values. This is because it may be useful to compose the + same local value several times following different composition rules. + + Because characterization parameters are used to compute the + properties of a specific path through the internetwork, all + characterization parameter definitions are conceptually "per-next- + hop", as opposed to "per interface" or "per network element". In + cases where the network element is (or is controlling) a shared media + or large-cloud subnet, the element may need to provide different + values for different next-hops within the cloud. In practice, it may + be appropriate for vendors to choose and document a tolerance range, + such that if all next-hop values are within the tolerance range only + a single value need be stored and provided. + + Local and composed characterization parameter values have distinct + ID's so that a network management entity can examine the value of + either a local or path-composed parameter at any point within the + network. + + Each parameter definition includes a description of the minimal + properties, such as range and precision, required of any wire + representation of that parameter's values. Each definition also + includes an XDR [RFC 1832] description of the parameter, describing + an appropriate external (wire) data representation for the + parameter's values. This dual definition is intended to encourage a + common wire representation format whenever possible, while still + allowing other representations when required by the specific + circumstances (e.g., ASN.1 within SNMP). + + The message formats specified in [RFC 2210] for use with the RSVP + setup protocol use the XDR data representation parameters. + + All of the parameters described in this note are mandatory, in the + sense that a network element claiming to support integrated service + must recognize arriving values in setup and management protocol + messages, process them correctly, and export a reasonable value in + response. For some parameters, the specification requires that the + network element compute and export an *accurate* local value. For + other parameters, it is acceptable for the network element to + indicate that it cannot compute and export an accurate local value. + The definition of these parameters provides a reserved value which + indicates "indeterminate" or "invalid". This value signals that an + element cannot process the parameter accurately, and consequently + that the result of the end-to-end composition is also questionable. + + + + +Shenker & Wroclawski Standards Track [Page 3] + +RFC 2215 General Characterization Parameters September 1997 + + + NOTE (temporary): Previous versions of this and the RSVP use + document used both the reserved-value approach and a separate + INVALID flag to record this fact. Now, the reserved-value + approach is used exclusively. This is so that any protocol which + retrieves a parameter value, including SNMP, can carry the invalid + indication without needing a separate flag. The INVALID flag + remains in the RSVP message format but is reserved for use only + with a possible future service-composition scheme. + +2. Default and Service-Specific Values for General Parameters + + General parameters have a common *definition* across all QoS control + services. Frequently, the same *value* of a general parameter will be + correct for all QoS control services offered by a network element. In + this circumstance, there is no need to export a separate copy of the + value for each QoS control service; instead the node can export one + number which applies to all supported services. + + A general parameter value which applies to all services supported at + a network node is called a default or global value. For example, if + all of the QoS control services provided at a node support the same + maximum packet size, the node may export a single default value for + the PATH_MTU parameter described in Section 3, rather than providing + a separate copy of the value for each QoS control service. In the + common case, this reduces both message size and processing overhead + for the setup protocol. + + Occasionally an individual service needs to report a value differing + from the default value for a particular general parameter. For + example, if the implementation of Guaranteed Service [RFC 2212] at a + router is restricted by scheduler or hardware considerations to a + maximum packet size smaller than supported by the router's best- + effort forwarding path, the implementation may wish to export a + "service-specific" value of the PATH_MTU parameter so that + applications using the Guaranteed service will function correctly. + + In the example above, the router might supply a value of 1500 for the + default PATH_MTU parameter, and a value of 250 for the PATH_MTU + parameter applying to guaranteed service. In this case, the setup + protocol providing path characterization carries (and delivers to the + application) both a value for Guaranteed service and a value for + other services. + + The distinction between default and service-specific parameter values + makes no sense for non-general parameters (those defined by a + specific QoS control service, rather than this note), because both + the definition and value of the parameter are always specific to the + particular service. + + + +Shenker & Wroclawski Standards Track [Page 4] + +RFC 2215 General Characterization Parameters September 1997 + + + The distinction between default and service-specific values for + general parameters is reflected in the parameter ID name space. This + allows network nodes, setup protocols, and network management tools + to distinguish default from service-specific values, and to determine + which service a service-specific parameter value is associated with. + + Service number 1 is used to indicate the default value. A parameter + value identified by the ID: + + <1, parameter_number> + + is a default value, which applies to all services unless it is + overridden by a service-specific value for the same parameter. + + A parameter value identified by the ID: + + <service_number, parameter_number> + + where service_number is not equal to 1, is a service-specific value. + It applies only to the service identified by service_number. + + These service-specific values are also called override values. This + is because when both service-specific and default values are present + for a parameter, the service-specific value overrides the default + value (for the service to which it applies). The rules for composing + service-specific and global general parameters support this override + capability. The basic rule is to use the service-specific value if + it exists, and otherwise the global value. + + A complete summary of the characterization parameter composition + process is given below. In this summary, the "arriving value" is the + incompletely composed parameter value arriving from a neighbor node. + The "local value" is the (global or service-specific) value made + available by the local node. The "result" is the newly composed value + to be sent to the next node on the data path. + + 1. Examine the <service_number, parameter_number> pair associated + with the arriving value. This information is conveyed by the setup + protocol together with the arriving value. + + 2. If the arriving value is for a parameter specific to a single + service (this is true when the parameter_number is larger than + 128), compose the arriving value with the local value exported by + the specified service, and pass the result to the next hop. In this + case there is no need to consider global values, because the + parameter itself is specific to just one service. + + + + + +Shenker & Wroclawski Standards Track [Page 5] + +RFC 2215 General Characterization Parameters September 1997 + + + 3. If the arriving value is a service-specific value for a + generally defined parameter (the parameter_number is 127 or less, + and the service_number is other than 1), and the local + implementation of that service also exports a service-specific + value for the parameter, compose the service-specific arriving + value and the service-specific local value of the parameter, and + pass the result as a service-specific value to the next-hop node. + + 4. If the arriving value is a service-specific value for a general + parameter (the parameter_number is 127 or less, and the + service_number is other than 1), and the local implementation of + that service does *not* export a service-specific value, compose + the service-specific arriving value with the global value for that + parameter exported by the local node, and pass the result as a + service-specific value to the next-hop node. + + 5. If the arriving value is a global value for a general parameter + (parameter_number is 127 or less, and the service_number is 1), and + the local implementation of *any* service exports a service- + specific value for that general parameter, compose the arriving + (global) value with the service-specific value for that parameter + exported by the local service, and pass the result as a service- + specific value to the next-hop node. This will require adding a new + data field to the message passed to the next hop, to hold the newly + generated service-specific value. Repeat this process for each + service that exports a service-specific value for the parameter. + + 6. If the arriving value is a global value for a general parameter + (the service_number is 1, and the parameter_number is 127 or less), + compose the arriving (global) value with the global parameter value + exported by the local node, and pass the result as a global + (service 1) value to the next-hop node. This step is performed + whether or not any service-specific values were generated and + exported in step 5. + +3. General Parameter Definitions + + 3.1 NON-IS_HOP flag parameter + + This parameter provides information about the presence of network + elements which do not implement QoS control services along the data + path. + + The local value of the parameter is 1 if the network element does not + implement the relevant QoS control service, or knows that there is a + break in the chain of elements which implement the service. The + local parameter is 0 otherwise. The local parameter is assigned + parameter_number 1. + + + +Shenker & Wroclawski Standards Track [Page 6] + +RFC 2215 General Characterization Parameters September 1997 + + + The composition rule for this parameter is the OR function. A + composed parameter value of 1 arriving at the endpoint of a path + indicates that at least one point along the path does not offer the + indicated QoS control service. The parameter_number for the composed + quantity is 2. + + The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this + flag is set, it indicates that one or more network elements along the + application's data path does not support the integrated services + framework at all. An example of such an element would be an IP router + offering only best-effort packet delivery and not supporting any + resource reservation requests. + + Obviously, a network element which does not support this + specification will not know to set this flag. The actual + responsibility for determining that a network node does not support + integrated services may fall to the network element, the setup + protocol, or a manual configuration operation and is dependent on + implementation and usage. This calculation must be conservative. + For example, a router sending packets into an IP tunnel must assume + that the tunneled packets will not receive QoS control services + unless it or the setup protocol can prove otherwise. + + Service-specific versions of the NON_IS_HOP flag indicate that one or + more network elements along a path don't support the particular + service. For example, the flag parameter identified by ID <2,2> being + set indicates that some network element along the path does not + support the Guaranteed service, though it might support another + service such as Controlled-Load. + + If the global NON_IS_HOP flag <1,2> is set for a path, the receiver + (network element or application) should consider the values of all + other parameters defined in this specification, including service- + specific NON_IS_HOP flags, as possibly inaccurate. If a service + specific NON_IS_HOP flag is set for a path, the receiver should + consider the values of all other parameters associated with that + service as possibly inaccurate. + + The NON_IS_HOP parameter may be represented in any form which can + express boolean true and false. However, note that a network element + must set this flag precisely when it does *not* fully understand the + format or data representation of an arriving protocol message + (because it does not support the specified service). Therefore, the + data representation used for this parameter by setup and management + protocols must allow the parameter value to be read and set even if + the network element cannot otherwise parse the protocol message. + + + + + +Shenker & Wroclawski Standards Track [Page 7] + +RFC 2215 General Characterization Parameters September 1997 + + + An appropriate XDR description of this parameter is: + + bool NON_IS_HOP; + + However, the standard XDR data encoding for this description will not + meet the requirement described above unless other restrictions are + placed on message formats. An alternative data representation may be + more appropriate. + + NOTE: The message format described for RSVP in [RFC 2210] carries + this parameter as a single-bit flag, referred to as the "break + bit". + + 3.2 NUMBER_OF_IS_HOPS + + IS stands for "integrated services aware". An integrated services + aware network element is one that conforms to the various + requirements described in this and other referenced documents. The + network element need not offer a specific service, but if it does it + must support and characterize the service in conformance with the + relevant specification, and if it does not it must correctly set the + NON_IS_HOP flag parameter for the service. For completeness, the + local parameter is assigned the parameter_number 3. + + The composition rule for this parameter is to increment the counter + by one at each IS-aware hop. This quantity, when composed end-to- + end, informs the endpoint of the number of integrated-services aware + network elements traversed along the path. The parameter_number for + this composed parameter is 4. + + Values of the composed parameter will range from 1 to 255, limited by + the bound on IP hop count. + + The XDR representation of this parameter is: + + unsigned int NUMBER_OF_IS_HOPS; + + 3.3. AVAILABLE_PATH_BANDWIDTH + + This parameter provides information about the bandwidth available + along the path followed by a data flow. The local parameter is an + estimate of the bandwidth the network element has available for + packets following the path. Computation of the value of this + parameter should take into account all information available to the + network element about the path, taking into consideration + administrative and policy controls on bandwidth, as well as physical + resources. + + + + +Shenker & Wroclawski Standards Track [Page 8] + +RFC 2215 General Characterization Parameters September 1997 + + + NOTE: This parameter should reflect, as closely as possible, the + actual bandwidth available to packets following a path. However, + the bandwidth available may depend on a number of factors not + known to the network element until a specific QoS request is in + place, such as the destination(s) of the packet flow, the service + to be requested by the flow, or external policy information + associated with a reservation request. Because the parameter must + in fact be provided before any specific QoS request is made, it is + frequently difficult to provide the parameter accurately. In + circumstances where the parameter cannot be provided accurately, + the network element should make the best attempt possible, but it + is acceptable to overestimate the available bandwidth by a + significant amount. + + The parameter_number for AVAILABLE_PATH_BANDWIDTH is 5. The global + parameter <1, 5> is an estimate of the bandwidth available to any + packet following the path, without consideration of which (if any) + QoS control service the packets may be subject to. + + In cases where a particular service is administratively or + technically restricted to a limited portion of the overall available + bandwidth, the service module may wish to export an override + parameter which specifies this smaller bandwidth value. + + The composition rule for this parameter is the MIN function. The + composed value is the minimum of the network element's value and the + previously composed value. This quantity, when composed end-to-end, + informs the endpoint of the minimal bandwidth link along the path + from sender to receiver. The parameter_number for the composed + minimal bandwidth along the path is 6. + + Values of this parameter are measured in bytes per second. The + representation must be able to express values ranging from 1 byte per + second to 40 terabytes per second, about what is believed to be the + maximum theoretical bandwidth of a single strand of fiber. + + Particularly for large bandwidths, only the first few digits are + significant, so the use of a floating point representation, accurate + to at least 0.1%, is encouraged. + + The XDR representation for this parameter is: + + float AVAILABLE_PATH_BANDWIDTH; + + For values of this parameter only valid non-negative floating point + numbers are allowed. Negative numbers (including "negative zero"), + infinities, and NAN's are not allowed. + + + + +Shenker & Wroclawski Standards Track [Page 9] + +RFC 2215 General Characterization Parameters September 1997 + + + NOTE: An implementation which utilizes general-purpose hardware or + software IEEE floating-point support may wish to verify that + arriving parameter values meet these requirements before using the + values in floating-point computations, in order to avoid + unexpected exceptions or traps. + + If the network element cannot or chooses not to provide an estimate + of path bandwidth, it may export a local value of zero for this + parameter. A network element or application receiving a composed + value of zero for this parameter must assume that the actual + bandwidth available is unknown. + + 3.4 MINIMUM_PATH_LATENCY + + The local parameter is the latency of the packet forwarding process + associated with the network element, where the latency is defined to + be the *smallest* possible packet delay added by the network element. + This delay results from speed-of-light propagation delay, from packet + processing limitations, or both. It does not include any variable + queuing delay which may be present. + + The purpose of this parameter is to provide a baseline minimum path + latency for use with services which provide estimates or bounds on + additional path delay, such as Guaranteed [RFC 2212]. Together with + the queuing delay bound offered by Guaranteed and similar services, + this parameter gives the application knowledge of both the minimum + and maximum packet delivery delay. Knowing both the minimum and + maximum latency experienced by data packets allows the receiving + application to accurately compute its de-jitter buffer requirements. + + Note that the quantity characterized by this parameter is the + absolute smallest possible value for the packet processing and + transmission latency of the network element. This value is the + quantity required to provide the end hosts with jitter bounds. The + parameter does *not* provide an upper-bound estimate of minimum + latency, which might be of interest for best-effort traffic and QoS + control services which do not explicitly offer delay bounds. In other + words, the parameter will always underestimate, rather than + overestimate, latency, particularly in multicast and large cloud + situations. + + When packets traversing a network element may experience different + minimal latencies over different paths, this parameter should, if + possible, report an accurate latency value for each path. For + example, when an ATM point-multipoint virtual circuit is used to + implement IP multicast, the mechanism that implements this parameter + for the ATM cloud should ideally compute a separate value for each + destination. Doing this may require cooperation between the ingress + + + +Shenker & Wroclawski Standards Track [Page 10] + +RFC 2215 General Characterization Parameters September 1997 + + + and egress elements bounding the multi-access communication cloud. + The method by which this cooperation is achieved, and the choice of + which IP-level network element actually provides and composes the + value, is technology-dependent. + + An alternative choice is to provide the same value of this parameter + for all paths through the cloud. The value reported must be the + smallest latency for any possible path. Note that in this situation, + QoS control services (e.g., Guaranteed) which provide an upper bound + on latency cannot simply add their queuing delay to the value + computed by this parameter; they must also compensate for path delays + above the minimum. In this case the range between the minimum and + maximum packet delays reported to the application may be larger than + actually occurs, because the application will be told about the + minimum delay along the shortest path and the maximum delay along the + actual path. This is acceptable in most situations. + + A third alternative is to report the "indeterminate" value, as + specified below. In this circumstance the client application may + either deduce a minimum path latency through measurement, or assume a + value of zero. + + The composition rule for this parameter is summation with a clamp of + (2**32 - 1) on the maximum value. This quantity, when composed end- + to-end, informs the endpoint of the minimal packet delay along the + path from sender to receiver. The parameter_number for the latency of + the network element's link is 7. The parameter_number for the + cumulative latency along the path is 8. + + The latencies are reported in units of one microsecond. An individual + element can advertise a latency value between 1 and 2**28 (somewhat + over two minutes) and the total latency added across all elements can + range as high as (2**32)-2. If the sum of the different elements + delays exceeds (2**32)-2, the end-to-end advertised delay should be + reported as indeterminate. This is described below. + + Note that while the granularity of measurement is microseconds, a + conforming element is free to actually measure delays more loosely. + The minimum requirement is that the element estimate its delay + accurately to the nearest 100 microsecond granularity. Elements that + can measure more accurately are, of course, encouraged to do so. + + NOTE: Measuring in milliseconds is not acceptable, because if the + minimum delay value is a millisecond, a path with several hops + will lead to a composed delay of at least several milliseconds, + which is likely to be misleading. + + + + + +Shenker & Wroclawski Standards Track [Page 11] + +RFC 2215 General Characterization Parameters September 1997 + + + The XDR description of this parameter is: + + unsigned int MINIMUM_PATH_LATENCY; + + The distinguished value (2**32)-1 is taken to mean "indeterminate + latency". A network element which cannot accurately predict the + latency of packets it is processing should set its local parameter to + this value. Because the composition function limits the composed sum + to this value, receipt of this value at a network element or + application indicates that the true path latency is not known. This + may happen because one or more network elements could not supply a + value, or because the range of the composition calculation was + exceeded. + + 3.5. PATH_MTU + + This parameter computes the maximum transmission unit (MTU) for + packets following a data path. This value is required to invoke QoS + control services which require that IP packet size be strictly + limited to a specific MTU. Existing MTU discovery mechanisms cannot + be used because they provide information only to the sender and they + do not directly allow for QoS control services to specify MTU's + smaller than the physical MTU. + + The local characterization parameter is the IP MTU, where the MTU of + a network element is defined to be the maximum transmission unit the + network element can accommodate without fragmentation, including IP + and upper-layer protocol headers but not including link level + headers. The composition rule is to take the minimum of the network + element's MTU and the previously composed value. This quantity, when + composed end-to-end, informs the endpoint of the maximum transmission + unit that can traverse the path from sender to receiver without + fragmentation. The parameter_number for the MTU of the network + element's link is 9. The parameter_number for the composed MTU along + the path is 10. + + A correct and valid value of this parameter must be provided by all + IS-aware network elements. + + A specific service module may specify an MTU smaller than that of the + overall network element by overriding this parameter with one giving + the service's MTU value. A service module may not specify an MTU + value larger than that given by the global parameter. + + Values of this parameter are measured in bytes. The representation + must be able to express values ranging from 1 byte to 2**32-1 bytes. + + + + + +Shenker & Wroclawski Standards Track [Page 12] + +RFC 2215 General Characterization Parameters September 1997 + + + The XDR description of this parameter is: + + unsigned int PATH_MTU; + + 3.6. TOKEN_BUCKET_TSPEC + + This parameter is used to describe data traffic parameters using a + simple token bucket filter. This parameter is used by data senders to + describe the traffic parameters of traffic it expects to generate, + and by QoS control services to describe the parameters of traffic for + which the reservation should apply. It is defined as a general rather + than service-specific parameter because the same traffic description + may be used by several QoS control services in some situations. + + NOTE: All previous definitions in this note have described + "characterization parameters", with local values set by network + elements to characterize their behavior and composition rules to + give the resulting end-to-end behavior. The TOKEN_BUCKET_TSPEC is + not a characterization parameter, because intermediate nodes + within the network do not export local values for + TOKEN_BUCKET_TSPECs. The TOKEN_BUCKET_TSPEC is simply a data + structure definition given here because it is common to more than + one QoS control service. + + The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127. + + The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification + plus a peak rate [p], minimum policed unit [m], and a maximum packet + size [M]. + + The token bucket specification includes an average or token rate [r] + and a bucket depth [b]. Both [r] and [b] must be positive. + + The token rate [r] is measured in bytes of IP datagrams per second. + Values of this parameter may range from 1 byte per second to 40 + terabytes per second. In practice, only the first few digits of the + [r] and [p] parameters are significant, so the use of floating point + representations, accurate to at least 0.1% is encouraged. + + The bucket depth, [b], is measured in bytes. Values of this parameter + may range from 1 byte to 250 gigabytes. In practice, only the first + few digits of the [b] parameter are significant, so the use of + floating point representations, accurate to at least 0.1% is + encouraged. + + The peak traffic rate [p] is measured in bytes of IP datagrams per + second. Values of this parameter may range from 1 byte per second to + 40 terabytes per second. In practice, only the first few digits of + + + +Shenker & Wroclawski Standards Track [Page 13] + +RFC 2215 General Characterization Parameters September 1997 + + + the [r] and [p] parameters are significant, so the use of floating + point representations, accurate to at least 0.1% is encouraged. The + peak rate value may be set to positive infinity, indicating that it + is unknown or unspecified. + + The range of values allowed for these parameters is intentionally + large to allow for future network technologies. A particular network + element is not expected to support the full range of values. + + The minimum policed unit, [m], is an integer measured in bytes. This + size includes the application data and all protocol headers at or + above the IP level (IP, TCP, UDP, RTP, etc.). It does not include the + link-level header size, because these headers will change in size as + the packet crosses different portions of the internetwork. + + All IP datagrams less than size [m] are treated as being of size m + for purposes of resource allocation and policing. The purpose of this + parameter is to allow reasonable estimation of the per-packet + resources needed to process a flow's packets (maximum packet rate can + be computed from the [b] and [m] terms) and to reasonably bound the + bandwidth overhead consumed by the flow's link-level packet headers. + The maximum bandwidth overhead consumed by link-level headers when + carrying a flow's packets is bounded by the ratio of the link-level + header size to [m]. Without the [m] term, it would be necessary to + compute this bandwidth overhead assuming that every flow was always + sending minimum-sized packets, which is unacceptable. + + The maximum packet size, [M], is the biggest packet that will conform + to the traffic specification; it is also measured in bytes. Any + packets of larger size sent into the network may not receive QoS- + controlled service, since they are considered to not meet the traffic + specification. + + Both [m] and [M] must be positive, and [m] must be less then or equal + to [M]. + + The XDR description of this parameter is: + + struct { + float r; + float b; + float p; + unsigned m; + unsigned M; + } TOKEN_BUCKET_TSPEC; + + + + + + +Shenker & Wroclawski Standards Track [Page 14] + +RFC 2215 General Characterization Parameters September 1997 + + + For the fields [r] and [b] only valid non-negative floating point + numbers are allowed. Negative numbers (including "negative zero), + infinities, and NAN's are not allowed. + + For the field [p], only valid non-negative floating point numbers or + positive infinity are allowed. Negative numbers (including "negative + zero), negative infinities, and NAN's are not allowed. + + NOTE: An implementation which utilizes general-purpose hardware or + software IEEE floating-point support may wish to verify that + arriving parameter values meet these requirements before using the + values in floating-point computations, in order to avoid + unexpected exceptions or traps. + +4. Security Considerations + + Implementation of the characterization parameters described in this + memo creates no known new avenues for malicious attack on the network + infrastructure. Implementation of these characterization parameters + does, of necessity, reveal some additional information about a + network's performance, which in extremely rare circumstances could be + viewed as a security matter by the network provider. + +5. References + + [RFC 2005] Braden, R., Ed., et. al., "Resource Reservation Protocol + (RSVP) - Version 1 Functional Specification", RFC 2205, September + 1997. + + [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 1997. + + [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS + Control Service Specification Template", RFC 2216, September 1997. + + [RFC 2212] Shenker, S., Partridge, C., and R. Guerin "Specification + of the Guaranteed Quality of Service", RFC 2212, September 1997. + + [RFC 2211] Wroclawski, J., "Specification of the Controlled Load + Quality of Service", RFC 2211, September 1997. + + [RFC 1832] Srinivansan, R., "XDR: External Data Representation + Standard", RFC 1832, August 1995. + + + + + + + + +Shenker & Wroclawski Standards Track [Page 15] + +RFC 2215 General Characterization Parameters September 1997 + + +Authors' Addresses + + Scott Shenker + Xerox PARC + 3333 Coyote Hill Road + Palo Alto, CA 94304-1314 + + Phone: 415-812-4840 + Fax: 415-812-4471 + EMail: shenker@parc.xerox.com + + + John Wroclawski + MIT Laboratory for Computer Science + 545 Technology Sq. + Cambridge, MA 02139 + + Phone: 617-253-7885 + Ffax: 617-253-2673 (FAX) + EMail: jtw@lcs.mit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Shenker & Wroclawski Standards Track [Page 16] + |