General Characterization Parameters for Integrated Service Network Elements
Extracted elements (27)
AVAILABLE_PATH_BANDWIDTH is frequently difficult to provide accurately before a specific QoS request is in place (destination, service type, and policy may affect available bandwidth). When the parameter cannot be provided accurately, overestimating is acceptable; zero should be exported to signal 'unknown'.
Characterization parameters are defined as conceptually 'per-next-hop' rather than 'per-interface' or 'per-network-element' because they characterize properties of a specific path through the internetwork. In shared-media or large-cloud scenarios, elements may need to provide different values for different next-hops.
General parameters have both a default (service_number=1) and optional service-specific override values. This allows a node to export a single default value when all services share the same value, reducing message size and processing overhead; service-specific values override the default only for the service to which they apply.
MINIMUM_PATH_LATENCY is defined as the absolute smallest possible forwarding delay and will always underestimate rather than overestimate latency, particularly in multicast or large-cloud scenarios. This is intentional so that, combined with a service's queuing delay bound, endpoints can accurately compute de-jitter buffer requirements.
PATH_MTU cannot rely on existing MTU discovery mechanisms because those mechanisms provide information only to the sender and do not allow QoS control services to specify MTUs smaller than the physical link MTU.
The minimum policed unit [m] bounds the bandwidth overhead consumed by link-level headers: without it, worst-case overhead would require assuming every flow sends minimum-sized packets. With [m], the overhead is bounded by the ratio of link-level header size to [m].
The reserved-value approach (a single distinguished value meaning 'indeterminate/invalid') is used exclusively instead of a separate INVALID flag, so that any protocol retrieving a parameter value—including SNMP—can carry the invalid indication without needing a separate flag.
TOKEN_BUCKET_TSPEC is defined as a general parameter rather than a service-specific one because the same traffic description may be used by multiple QoS control services. It is not a characterization parameter (intermediate nodes do not export local values for it); it is a common data structure shared across services.
Each parameter definition includes both a minimal properties description (range, precision) and an XDR representation. The dual definition encourages a common wire format while allowing alternative representations (e.g., ASN.1 within SNMP) when required by the specific protocol context.
The NON_IS_HOP parameter's data representation used 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. In RSVP (RFC 2210), this parameter is carried as a single-bit flag called the 'break bit'.
A correct and valid value of PATH_MTU MUST be provided by all IS-aware network elements. A service module MAY specify a smaller MTU via a service-specific override but MUST NOT specify a value larger than the global PATH_MTU.
A router sending packets into an IP tunnel MUST assume that tunneled packets will not receive QoS control services unless it or the setup protocol can prove otherwise; the NON_IS_HOP determination must be conservative.
All parameters defined in this memo are mandatory: a network element claiming to support integrated services MUST recognize arriving parameter values in setup and management protocol messages, process them correctly, and export a reasonable value in response.
In TOKEN_BUCKET_TSPEC, the minimum policed unit [m] and maximum packet size [M] MUST both be positive, and [m] MUST be less than or equal to [M]. All IP datagrams smaller than [m] are treated as size [m] for resource allocation and policing.
The minimum requirement for MINIMUM_PATH_LATENCY accuracy is that the element estimate its delay to the nearest 100-microsecond granularity. Measuring in milliseconds is explicitly unacceptable because multi-hop composed delays would be misleadingly large.
AVAILABLE_PATH_BANDWIDTH: local parameter_number 5 is an estimate of bandwidth available to the path; composed parameter_number 6 uses the MIN rule to yield the bottleneck bandwidth. Measured in bytes per second; range 1 B/s to 40 TB/s. A local value of zero means 'unknown'. XDR type: float (non-negative only).
Characterization parameter composition follows a 6-step algorithm: service-specific parameters are composed using the specified service's local value; general parameters arriving as service-specific values are composed with either the local service-specific or global value; global arriving values are composed with all service-specific local values (generating new service-specific results) and also with the global local value.
MINIMUM_PATH_LATENCY: local parameter_number 7 is the absolute minimum packet forwarding delay (propagation + processing, no queuing); composed parameter_number 8 uses summation clamped at (2^32-1). Units are microseconds; individual element values 1 to 2^28; end-to-end up to (2^32)-2. XDR type: unsigned int.
NON_IS_HOP is a boolean flag: local parameter_number 1 is set to 1 if the element does not implement the relevant QoS control service or knows of a break in the service chain; composed parameter_number 2 uses the OR rule, so a composed value of 1 at the endpoint indicates at least one non-IS hop along the path.
NUMBER_OF_IS_HOPS: local parameter_number 3 (incremented by 1 at each IS-aware hop); composed parameter_number 4 gives the total count of IS-aware network elements traversed. Values range from 1 to 255, bounded by IP hop count. XDR type: unsigned int.
Parameter IDs are composed of two fields: <service_number, parameter_number>. General parameters use parameter_number 1–127; service-specific parameters use 128–254. Service number 1 denotes default (global) values applicable to all services.
PATH_MTU: local parameter_number 9 is the IP MTU (maximum packet size without fragmentation, including IP and upper-layer headers, excluding link-layer headers); composed parameter_number 10 uses the MIN rule to yield the path MTU. XDR type: unsigned int; range 1 byte to 2^32-1 bytes.
The distinguished value (2^32)-1 in MINIMUM_PATH_LATENCY means 'indeterminate latency'. A network element unable to accurately predict its packet latency sets its local parameter to this value; the summation clamp propagates this indeterminate indication end-to-end.
TOKEN_BUCKET_TSPEC (parameter_number 127) is a traffic specification using: token rate [r] (bytes/sec, float), bucket depth [b] (bytes, float), peak rate [p] (bytes/sec, float or +infinity), minimum policed unit [m] (bytes, unsigned int), and maximum packet size [M] (bytes, unsigned int). Both [r] and [b] must be positive; [m] ≤ [M].
Service numbers are allocated as follows: 1 is reserved for default/global general parameter values; 2 is assigned to Guaranteed Service (RFC 2212); 5 is assigned to Controlled-Load Service (RFC 2211). Numbers 2–254 are allocated to individual QoS control services.
Implementation of the characterization parameters described in this memo creates no known new avenues for malicious attack on the network infrastructure. However, these parameters do reveal additional information about a network's performance characteristics, which in extremely rare circumstances could be viewed as a security concern by the network provider.
TOKEN_BUCKET_TSPEC XDR encoding: struct { float r; float b; float p; unsigned m; unsigned M; }. Fields r and b: non-negative finite floats only. Field p: non-negative float or positive infinity. Negative values, negative zero, negative infinity, and NaN are not allowed in any float field.