RFC 2215

General Characterization Parameters for Integrated Service Network Elements

📅 published September 1997, from ietf

RFC 2215: General Characterization Parameters for Integrated Service Network Elements 🎀

Network Working Group, the group this one came out of 🌸
Authors: S. Shenker and J. Wroclawski, both from Xerox PARC/MIT LCS 💜
Category: Standards Track ✨
Date: September 1997 🦋
Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🧚

Status of this Memo 📜

okay so this doc is an Internet standards track protocol for the Internet community 💅 It also asks people to discuss it and suggest improvements 🫶 For the standardization state and status of this protocol, you should check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited, so share it with everyone 🌈

Abstract ✨

this memo defines a set of general control and characterization parameters for network elements that support the IETF integrated services QoS control framework 💖 "General" parameters are the ones with common, shared definitions across all QoS control services. no cap, that's the whole vibe 🔥

1. Introduction 💖

so this memo defines the set of general control and characterization parameters that network elements use when they support the integrated services framework 🎀 "General" just means the parameter has a common definition and shared meaning across every QoS control service ✨

Control parameters are how applications tell the network about their QoS control requests 📨 An example is the traffic specification (TSpec) that application senders and receivers generate 🫶

Characterization parameters are how the network figures out what the QoS management environment looks like along the path of a packet flow that's asking for active end-to-end QoS control 🔍 These can end up being used by the application requesting QoS control, or by other network elements along the path 🧚 Examples include info about which QoS control services are available on a network path, and estimates of the available path bandwidth 🌸

individual QoS control service specifications can reference these parameter definitions, and they can also define extra parameters that their specific service needs 💅

parameters get machine-oriented ID's, using a method described in [RFC 2216] (here's the summary) 💜 These ID's can be used inside protocol messages (like the ones described in [RFC 2210]) or in management interfaces to describe which parameter values are present 🦋 Each parameter ID is made of two numerical fields. One identifies the service the parameter belongs to (the <service_number>), and the other (the <parameter_number>) identifies the parameter itself 🎀 Since the parameters in this note are shared by all QoS control services, their <parameter_number> values come from the "general parameters" range, 1 - 127 ✨

NOTE: <parameter_numbers> in the range 128 - 254 name parameters whose definitions are specific to one particular QoS control service 😭 Unlike the general parameters here, you have to look at both the <service_number> and the <parameter_number> to figure out what the parameter means 🙈 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 🌈 Right now, Guaranteed service [RFC 2212] has number 2, and Controlled-load service [RFC 2211] has number 5 💖

in this note, we write a service_number, parameter_number pair like this 🍓

<service_number, parameter_number>

the range of possible service_number and parameter_number values specified in [RFC 2216] lets the parameter ID form the tail portion of a MIB object ID that represents the parameter 🧚 This makes it way easier to make parameter values available to network management applications, which is literally iconic 💅

each parameter that characterizes a path through the network describes two types of values: local and composed 🔥 A local value gives info about a single network element 🎀 Composed values reflect the running composition of local values along a path, following some composition rule 🌸 Each parameter definition specifies the composition rule for that parameter, and that rule explains how to combine an incoming composed value (from the part of the path already traversed) with the local value. The result is a new composed value that gets passed to the next network element in the path 🦋 The composition can go downstream (toward the receiver(s)) or upstream (toward the sender) 🫶 Each parameter can give only one definition for the local value, but it may give more than one definition for composition rules and composed values 💜 That's because it can be useful to compose the same local value several times using different composition rules ✨

since characterization parameters are used to compute the properties of one specific path through the internetwork, all characterization parameter definitions are conceptually "per-next-hop", not "per interface" or "per network element" 🌈 If the network element is (or is controlling) a shared media or large-cloud subnet, it might need to give different values for different next-hops inside the cloud 😭 In practice, vendors may want to choose and document a tolerance range, so that if all next-hop values fall within that range, only a single value needs to be stored and provided 🍓

local and composed characterization parameter values have distinct ID's, so a network management entity can look at the value of either a local or path-composed parameter at any point in the network 🔍

each parameter definition includes a description of the minimal properties, like range and precision, that any wire representation of that parameter's values must have 🎀 Each definition also includes an XDR [RFC 1832] description of the parameter, which describes an appropriate external (wire) data representation for its values 💖 This dual definition is meant to push everyone toward a common wire representation whenever possible, while still allowing other representations when specific circumstances need them (for example, 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 in this note are mandatory 🔥 A network element that claims 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 element has to compute and export an accurate local value 👑 For other parameters, it's fine for the element to indicate that it can't compute and export an accurate local value 🙈 The definition of these parameters provides a reserved value that means "indeterminate" or "invalid" 🌸 That value tells everyone the element can't process the parameter accurately, so the end-to-end composition result is also questionable 😭

NOTE (temporary): earlier versions of this document and the RSVP document used both the reserved-value approach and a separate INVALID flag to record this 💀 Now the reserved-value approach is used exclusively 🫶 That way, any protocol that retrieves a parameter value, including SNMP, can carry the invalid indication without needing a separate flag 🌈 The INVALID flag is still in the RSVP message format, but it's reserved for use only with a possible future service-composition scheme 🦋

2. Default and Service-Specific Values for General Parameters ✨

okay so general parameters have one shared definition across ALL the QoS control services 🎀 Often the same value of a general parameter is totally correct for every QoS control service a network element offers 💅 In that case there's no reason to export a separate copy for each service. The node can just export ONE number that applies to all supported services. no cap, iconic efficiency 🦋

A general parameter value that applies to all services supported at a network node is called a default or global value 👑 For example, if all the QoS control services 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, instead of a separate copy for each QoS control service. In the common case this reduces both message size and processing overhead for the setup protocol 🫶

Sometimes an individual service needs to report a value that's different from the default 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 what the router's best-effort forwarding path supports, 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 that example, 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 values makes no sense for non-general parameters (the ones defined by a specific QoS control service, rather than by this note), because both the definition and the value of the parameter are always specific to that one service. 🧚

The distinction between default and service-specific values for general parameters is reflected in the parameter ID name space. This lets network nodes, setup protocols, and network management tools tell default values apart from service-specific ones, and figure out which service a service-specific parameter value belongs to 🔥

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. That's because when both service-specific and default values are present for a parameter, the service-specific value overrides the default value (for the service it applies to). The rules for composing service-specific and global general parameters support this override capability. The basic rule is: use the service-specific value if it exists, and otherwise use the global value. 👑

A complete summary of the characterization parameter composition process is below. In this summary, the "arriving value" is the incompletely composed parameter value coming in 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. 🌸

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.
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. 🎀
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. 🦋
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. 💅
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. 🔥
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 tells you whether there are network elements along the path that don't implement QoS control services 🫶

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. Otherwise the local parameter is 0. The local parameter is assigned parameter_number 1. 💖

The composition rule for this parameter is the OR function. A composed parameter value of 1 arriving at the endpoint of a path means 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 means 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 won't 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 depends 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 means 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. 🙈

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. Once composed end-to-end, this quantity tells the endpoint how many integrated-services aware network elements were 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. Computing the value of this parameter SHOULD take into account all information available to the network element about the path, including administrative and policy controls on bandwidth, as well as physical resources. 💖

NOTE: okay bestie, this one is SO important 💅 This parameter should reflect, as closely as possible, the actual bandwidth available to packets following a path. The catch is that the available bandwidth can depend on things the network element doesn't know until a specific QoS request is in place, like the destination(s) of the packet flow, the service the flow wants, or external policy info tied to a reservation request. Since this parameter has to be provided before any specific QoS request shows up, it's honestly hard to get it accurate 😭 When it can't be accurate, the network element should make the best attempt possible, but it's 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 caring about which (if any) QoS control service the packets might be subject to. 🦋

In cases where a particular service is administratively or technically restricted to a smaller slice of the overall available bandwidth, the service module may wish to export an override parameter that specifies this smaller bandwidth value. Main character energy for the service module, honestly 👑

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. Once it's composed end-to-end, this quantity tells the endpoint 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, which is about what is believed to be the maximum theoretical bandwidth of a single strand of fiber. Wild, right? 🌈

Particularly for large bandwidths, only the first few digits are significant, so using a floating point representation, accurate to at least 0.1%, is encouraged. 🧚

The XDR representation for this parameter is:

float AVAILABLE_PATH_BANDWIDTH;

For this parameter, only valid non-negative floating point numbers are allowed. Negative numbers (including "negative zero"), infinities, and NAN's are not allowed. No cap, these rules are strict 🙈

NOTE: an implementation that uses general-purpose hardware or software IEEE floating-point support may wish to verify that arriving parameter values meet these requirements before using them in floating-point computations, so it doesn't run into unexpected exceptions or traps. Protect your math, bestie 💖

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 that receives a composed value of zero for this parameter must assume that the actual bandwidth available is unknown. That's the vibe of "I don't know" in protocol form 🤷‍♀️

3.4 MINIMUM_PATH_LATENCY

The local parameter is the latency of the packet forwarding process associated with the network element. Here, latency is defined as the smallest possible packet delay added by the network element. ⭐ This delay comes from speed-of-light propagation delay, from packet processing limitations, or from both. It does not include any variable queuing delay that might be present.

The purpose of this parameter is to give a baseline minimum path latency for services that 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 lets the receiving application accurately compute its de-jitter buffer requirements. It's giving precision 🎀

Note that the quantity this parameter characterizes is the absolute smallest possible value for the packet processing and transmission latency of the network element. This is the quantity required to give the end hosts their jitter bounds. The parameter does not provide an upper-bound estimate of minimum latency, which might matter for best-effort traffic and QoS control services that don't explicitly offer delay bounds. In other words, the parameter will always underestimate, rather than overestimate, latency, especially 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 and egress elements bounding the multi-access communication cloud. How that cooperation happens, and which IP-level network element actually provides and composes the value, is technology-dependent. Different tech, different tea ☕

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. In this case, QoS control services (e.g., Guaranteed) that 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. The range between the minimum and maximum packet delays reported to the application may then be larger than what actually occurs, because the application is 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 that case, 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. Once composed end-to-end, this quantity tells the endpoint 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 228 (somewhat over two minutes), and the total latency added across all elements can range as high as (232)-2. If the sum of the different element 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. Go bestie go 🏃‍♀️

NOTE: measuring in milliseconds is not acceptable. 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. Literally nobody wants that 💀

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 that 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, receiving it at a network element or application means 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. Honestly the "I don't know" flag is iconic 🙃

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 that require IP packet size to be strictly limited to a specific MTU. Existing MTU discovery mechanisms can't be used for this, because they only provide information to the sender, and they don't directly let QoS control services specify MTUs smaller than the physical MTU. Not it, MTU discovery 🙅‍♀️

The local characterization parameter is the IP MTU. The MTU of a network element is defined as 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. Once composed end-to-end, this quantity tells the endpoint 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. No skipping this one, bestie 🫶

A specific service module may specify an MTU smaller than that of the overall network element by overriding this parameter with one that gives the service's MTU value. A service module may not specify an MTU value larger than the one 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. 🍓

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. Data senders use it to describe the traffic parameters of the traffic they expect to generate, and QoS control services use it to describe the parameters of traffic the reservation should apply to. It's 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. Reuse, the sustainable lifestyle 🌍✨

NOTE: all the 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 don't export local values for TOKEN_BUCKET_TSPECs. It's simply a data structure definition, given here because it's common to more than one QoS control service. Different category, same energy 💅

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. ✨

Okay so this is where the token bucket stuff gets real, bestie 🫶

The token rate [r] is measured in bytes of IP datagrams per second 🌊. It can range from 1 byte per second all the way up to 40 terabytes per second 🤯 But ngl, only the first few digits of [r] and [p] actually matter in practice, so floating point numbers accurate to at least 0.1% are encouraged 💖

The bucket depth, [b], is measured in bytes 🪣 It can be anywhere from 1 byte up to 250 gigabytes. Same deal here: only the first few digits really count, so floating point numbers accurate to at least 0.1% are encouraged ✨

The peak traffic rate [p] is also measured in bytes of IP datagrams per second 🚀 It can range from 1 byte per second to 40 terabytes per second, and only the first few digits matter, so again floating point at 0.1% accuracy is encouraged 💅 The peak rate is allowed to be set to positive infinity, which means it's unknown or unspecified 🌈

The range of values here is intentionally huge, so future network tech has room to grow 🦋 Just know that a particular network element isn't expected to support the full range, so don't panic if your router is not the whole universe 🙈

The minimum policed unit, [m], is an integer measured in bytes 🎀 This size counts the application data plus all the protocol headers at or above the IP level (IP, TCP, UDP, RTP, etc.). It does NOT include the link-level header size, because those headers change size as the packet hops across different parts of the internetwork 🧚

All IP datagrams smaller than size [m] get treated as if they were size m for resource allocation and policing 💜 Why? It makes it way easier to estimate the per-packet resources a flow needs (the maximum packet rate can be computed from the [b] and [m] terms), and it keeps the bandwidth overhead from link-level headers reasonably bounded 🍓 That overhead is bounded by the ratio of the link-level header size to [m]. Without [m], you'd have to figure out this overhead assuming every flow was always sending minimum-sized packets, and bestie, that's just unacceptable 💀

The maximum packet size, [M], is the biggest packet that still conforms to the traffic specification, also measured in bytes 📦 Any packet larger than that might not get QoS-controlled service, since it's considered to not meet the traffic spec 😬

Both [m] and [M] must be positive, and [m] must be less then or equal to [M] 👑

The XDR description of this parameter looks like this 🧁

      struct {
        float r;
        float b;
        float p;
        unsigned m;
        unsigned M;
      } TOKEN_BUCKET_TSPEC;

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 that uses general-purpose hardware or software IEEE floating-point support may want to check that arriving parameter values meet these requirements before using them in floating-point computations 🚨 That way you dodge unexpected exceptions or traps. Bestie, protect yourself 🛡️

4. Security Considerations 🛡️✨

Implementing the characterization parameters described in this memo creates no known new avenues for malicious attack on the network infrastructure 🙌 That's the good news. The slightly spicy news is that implementing these parameters does, by necessity, reveal some additional information about a network's performance. In extremely rare circumstances, a network provider could see that as a security matter 👀

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. 🧚

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

📦 where this page comes from

ietf: rfc2215 1997-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms