RFC 2216

RFC 2216: Network Element Service Specification Template 🎀

okay bestie, this one is the Network Element Service Specification Template 💅 It's from Request for Comments: 2216, written by S. Shenker and J. Wroclawski of Xerox PARC/MIT LCS, dated September 1997. It's Informational, so it's sharing good info with the community, not laying down a standard 🦋 Its header doesn't list anything it obsoletes or updates.

---

Status of This Memo 📝

This memo gives information to the Internet community. It does not specify an Internet standard of any kind 🙈 Distribution is unlimited, so share it with everyone 💜

Abstract ✨

This doc sets up a framework for describing services that network elements provide to applications inside an internetwork that offers multiple qualities of service 🌈 It starts with some necessary context, including relevant definitions and suggested data formats, and then lays out a "template" that service specification documents should follow. The template covers per-element requirements like how the service handles packets, which parameters the service requires and makes available, traffic specification and policing requirements, and how traffic ordering relationships work. It also has evaluation criteria for elements that provide the service, plus examples of how the service might be implemented by network elements and used by applications 🧚

Introduction 🌸

This document defines the framework for specifying what internetwork system components do when they support giving applications multiple, dynamically selectable qualities of service 🫶 The behavior of individual routers and subnetworks gets captured as a set of "services," and each element may offer some or all of them. When you chain these services along the end-to-end data paths an application uses, you get overall quality of service control 👑

A service definition says what a router (or any network element, like a switch or subnet) has to do when it supports a particular service 😭 The definition also specifies the parameters used to invoke the service, how those parameters relate to the service that gets delivered, and the end-to-end behavior you get by chaining several instances of the service 🔥

Each service definition also specifies the interface between that service and its environment. That includes the parameters needed to invoke the service, informational parameters the service must make available for setup, routing, and management mechanisms to use, and information that should be carried between end-nodes and network elements by those mechanisms to get the desired end-to-end behavior ✨ A service definition does not describe the specific protocols or mechanisms used to establish state in the network elements for flows that use the described service, though 💀

Services defined under this document are meant for use both across the global Internet and in private IP networks 🌍 Sometimes a chain of network element services can provide a range of end-to-end behaviors. Some are better suited to a decentralized internet, and some fit a tightly managed private network better. This document points out places where that distinction may be appropriate 🍓

This document has three parts. The first defines terms used both in this document and in the various service specification documents. The second discusses data formats and representations. The third describes the various components of the service specification template 🎀

Definitions 💖

The following terms are used throughout this document. Service specification documents should use the same terms to express these concepts, so everyone's on the same page 🦋

Quality of Service (QoS) 🌟

In this document, quality of service refers to the nature of the packet delivery service, described by parameters like achieved bandwidth, packet delay, and packet loss rates 💅 Traditionally the Internet has offered a single quality of service, best-effort delivery, where the available bandwidth and delay depend on instantaneous load 😭 You control the quality of service applications see by properly provisioning the network infrastructure. A network with dynamically controllable quality of service is different: individual application sessions can request packet delivery characteristics that match what they need, and different applications can get different qualities of service 🌈 There's a whole range of useful options between no dynamic QoS control at all and extremely precise, accurate control of QoS parameters, and it should be understood that the range is huge 🧚

Network Element 🔌

A "Network Element" (or the shorter form "Element") is any component of an internetwork that directly handles data packets and so could potentially control QoS for the data flowing through it 👑 Network elements include routers, subnetworks, and end-node operating systems. A QoS-capable network element is one that offers one or more of the services defined under the rules in this document. Note that this definition, by itself, precludes QoS-capable network elements that meet performance goals purely through adequate provisioning rather than active admission and traffic control mechanisms 🙈 A "QoS-aware" network element supports the interfaces (described below) that the service definitions require. So a QoS-aware element doesn't have to offer any of the services defined under this document's format. It just needs to know how to deny service requests 💀

Flow 🦋

For this document, a flow is a set of packets traversing a network element that are all covered by the same request for control of quality of service 🫶 At a given network element, a flow might be the packets from a single application session, or it might be an aggregation of combined data traffic from several application sessions ✨

NOTE: this definition of a flow is different from the one used in IPv6, where a flow is defined as the packets with the same source address and FlowID. 🙈

Mechanisms that link a request for quality of service control to the packets covered by that request are beyond the scope of this document 💅

Service 🌸

The phrase "service" or "QoS Control Service" describes a named, coordinated set of QoS control capabilities provided by a single network element 🎀 The definition of a service includes the functions the network element must perform, the information the element needs to perform them, and the information the element makes available to other parts of the system. Conceptually, a service is implemented inside the "service module" within the network element 🧚

NOTE: The above gives "service" a precise meaning. Service is a word with a bunch of meanings across the networking community, and here it refers specifically to the actions and responses of a single network element like a router or subnet 💅 That's different from the more end-to-end meaning the word has in some other networking contexts 🫶

Behavior 🌈

A "behavior" is the QoS-related end-to-end performance an application session sees 👑 It's the end result of composing the services each network element offers along the path of the application's data flow 🔥

When every network element along a data flow path offers the same service, it's often possible to explain the resulting end-to-end behavior in a straightforward way 😭 A data flow path made of elements using different services is more complicated and may actually be undefined. A future version of this document may add requirements to the service specification about multi-service concatenation 🍓

Characterization 🔮

A characterization is a computed approximation of the actual end-to-end behavior a flow would see when requesting specific QoS services from the network 🦋 By giving the end-nodes extra information before a flow is set up, characterizations help end-nodes choose which services to request from the network ✨

Characterization Parameters 🧮

Characterizations are computed from a set of characterization parameters that each network element on the flow's path provides, plus a composition function that turns those parameters into the end-to-end characterization 💖 The composition function may in practice be run in a distributed way by the setup or routing protocol. Or the characterization parameters may be gathered to a single point and the characterization computed there 🌟

Several characterizations may be computed for a single candidate data flow. On the flip side, a service may provide no characterizations at all, and under some conditions no characterizations may be available to the end-nodes requesting QoS services 💀

Composition Function ⚙️

A composition function accepts characterization parameters as input and computes a characterization, as described above 🧠

Traffic Specification (TSpec) 📦

A Traffic Specification, or TSpec, describes the traffic pattern a service is being requested for 👑 Generally, the TSpec is one side of a "contract" between the data flow and the service. Once a service request is accepted, the service module has agreed to provide a specific QoS, as long as the flow's data traffic keeps matching the TSpec 🫶

As examples, this specification might take the form of a token bucket filter (defined below) or an upper bound on the peak rate 🌈 Note that the traffic specification describes the flow's allowed traffic pattern, not the flow's actual traffic pattern 🙈 The behavior of a service when a flow's actual traffic doesn't conform to the traffic specification must be defined by the service (see "Policing" below) 😭

Service Request Specification (RSpec) 📋

A Service Request Specification, or RSpec, specifies the quality of service a flow wants to request from a network element 🎀 What goes in a service request specification is highly specific to a particular service. For example, these specifications might include information about bandwidth allocated to the flow, maximum delays, or packet loss rates 💅

Setup Protocol 🔧

A setup protocol carries QoS-related information from the end-nodes requesting QoS control to the network elements that have to exercise that control. It also installs and maintains the required QoS control state in those network elements 🧚 A setup protocol may also collect QoS-related information from interior network elements along an application's data flow path, so it can be delivered to end nodes 🫶 Examples of protocols that perform setup functions are RSVP [RFC 2205], ST-II [RFC 1819], and Q.2931 🌸

Other mechanisms, like network management protocols, may also perform this function. The phrase "setup protocol" usually refers to a protocol that has this function as its main purpose 💖

Token Bucket

Okay so picking up right where the Token Bucket definition left off 💖 A Token Bucket is a traffic spec with two dials: a token rate r and a bucket size b ✨. The r is the data rate you can keep up forever, and the b is how far you're allowed to go above that rate for short bursts 🎀. The rule is that over any time period, the amount of data sent can't go past rT+b, where T is how long that period is 🦋

[PARTRIDGE] has more on token buckets if you're into that 🧚

Token Bucket Filter

A Token Bucket Filter is a filtering or policing function that sorts the packets in a traffic flow. The ones that fit a given token bucket spec count as conforming, and the ones that don't count as nonconforming 💅 This definition doesn't say what happens to nonconforming packets. Common options are dropping them to best effort service, discarding them, or marking them somehow 🫶

Admission Control

Admission control is the process of deciding whether a brand new request for service from a network element can be granted 👑 Any service that wants to promise absolute, quantitative bounds on overall performance must do this. Services that only make relative statements about performance, like the Internet's current best-effort service, don't need it 🙈 The exact criteria for the decision are specific to each particular service 💀

Policing

Policing is the set of actions that kick in when a flow's real traffic characteristics go past the values in its traffic specification 😭 Services that need policing to work correctly have to specify two things: the action to take when this happens, and where in the network those mismatches should be detected 🔥 Examples of actions include relegating the packet to best effort service, dropping packets, reshaping the traffic, or marking nonconforming traffic in some way 🌈

Interfaces

The service module talks to other parts of the network element through a bunch of conceptual interfaces 🧚 The service specification document should clearly define the specific data that moves across each interface, including the formats. It should also make sure the mapping between those conceptual interfaces and the specific mechanisms of the service is clear 💜

Data Format and Representation ✨

A service module imports and exports a variety of data, depending on the services the network element supports 🎀 Each service definition MUST specify the format of each of those data items in an abstract manner. The info has to be enough for whoever designs a setup protocol to pick a good concrete (packet) format for variables holding that data 💖 At minimum, the following information must be given:

• Type: whether the quantity is an enumeration, a numerical value, etc.
• Range: for numerical quantities, the minimum and maximum values the quantity must be able to represent. For enumerated quantities, an estimate of the maximum number of items that may need to be enumerated in the future, even if many of the values are unused right now 🦋
• Precision: the precision a numerical quantity must be represented with, and whether that precision is absolute (meaning an integer quantity) or a percentage of the value (allowing a floating point quantity) 🌸

The service definition SHOULD also specify a preferred concrete format for each data field, using the usual packet-layout format in current Internet Standard documents, or some other accepted spec format ✨ If the service definition includes these concrete definitions, they should be complete and detailed enough that the service definition can be pulled in by reference into setup protocols and other users of the data 🫶

NOTE: The wording above is meant to encourage all protocols carrying data for a specific service to use common data formats 🧚 It doesn't force that common format, and it doesn't get in the way of protocol designers who want to define data representations with other mechanisms, like ASN.1 or XDR 💅

Service and Data Element Naming

End-nodes, network elements, setup protocols, and management entities in an integrated services internetwork need to swap info about services, service invocation parameters, characterization parameters, and the intermediate variables and end results of composition functions 😭 So there's one uniform namespace for services and their parameters 👑

The namespace is a two-level hierarchy:

<service_name>.<parameter_name>

Each of these elements is an integer numerical quantity 🔥

<Service Name> is an integer from 1 to 254, and the number space is split into three regions 🌈

Service number 1 means the associated parameter is "generic" and isn't tied to a specific service. More on generic parameters is in [RFC 2215] 🦋

The range 2 to 127 is for services defined by the IETF. Procedures for allocating service numbers here will be set up by the IETF INT-SERV WG and the IANA. Services meant for public use should get a number from this space. The minimum requirement is a published RFC that follows the format in this note 💖

Service numbers above 127 are reserved for experimental or private services. Designers can pick numbers from this space at random for local experimental use 🧚 A policy for global but temporary allocation may be set up later if needed 💜

The value 0 is left unused so parameter names can map directly to MIB object names, as described below 🎀

The value 255 is reserved for future expansion of the service number space, if that's ever needed ✨

<Parameter_name> is a number from 1 to 254, allocated per service 🫶 Within that range, values 1 to 127 are reserved for parameters with a common, shared meaning across all services. Those are defined in [RFC 2215] 🌸

Numbers for parameters specific to a service come from the range 128-254 and are assigned by the author of the service specification document 💅

The value 0 is left unused, again so parameter names can map directly to MIB object names 🙈

The value 255 is reserved for future expansion of the parameter number space, if needed 🍓

Beyond the integrated services framework, these <service_number>.<parameter_number> pairs should be used as the last two levels of the MIB name whenever the matching values are made available to network management protocols 🔥

Specification Document Format

This part describes the layout and contents of a service specification 🎀 Each service specification document MUST contain the sections marked [required] below, in the order listed. Each document SHOULD contain each of the remaining sections in the list, unless there's a compelling argument that including a section isn't beneficial 💖 Additional material, including references, goes at the end of the document ✨

Some sections are normative, meaning they describe specific requirements that conformant implementations must follow 👑 Other sections are informational, meaning they give the context and technical considerations that matter to whoever implements the service 🧚 Each section's nature (required or optional, and informational or normative) is listed below 💜

Components

The body of a service specification document includes these sections:

• End-to-End Behavior [required] [informational]
• Motivation [required] [informational]
• Network Element Data Handling Requirements [required] [normative]
• Invocation Information [required] [normative]
• Exported Information [required] [normative]
• Policing [required] [normative]
• Ordering and Merging [required] [normative]
• Guidelines for Implementors [optional] [informational]
• Evaluation Criteria [required] [informational]
• Examples of Implementation [optional] [informational]
• Examples of Use [optional] [informational]

End-to-end Behavior

This describes the behavior you get if every network element along the path offers the same service, invoked with a defined set of parameters 🦋

In private networks, the required end-to-end behavior usually comes from chaining together network elements that use the same service and make significant use of characterizations 🌸

On the global Internet, that won't always hold 😭 End-to-end behaviors often come from chaining network elements that support different services, and sometimes including elements that do no QoS control at all 💀 The mechanisms for characterizing end-to-end behavior in this situation aren't fully established yet. Future versions of this document may add requirements to service specifications to help with inter-service composition 🔥

This section is for informational purposes only 🫶

Motivation

This section explains why the service is being defined 💖 It describes what kinds of applications might use the service, and why it might suit those applications better than other choices 🧚 This section is for informational purposes only 🎀

Network Element Data Handling Requirements

This section describes the QoS properties that data packets see when a network element processes them with this service 👑 The description has to clearly explain which variables are controlled, how much control is exercised, and which parts of the service's handling model are fixed or assumed 💅 Examples of degree-of-control information include "this property must be mathematically assured" and "this property should be met under most conditions" ✨ An example of a stated assumption is "this service is assumed to have extremely low packet loss; delay targets must be met using admission control rather than by discarding packets when overloaded" 😭

Requirements on packet handling SHOULD, whenever possible, be written as performance requirements instead of naming a particular packet scheduling algorithm 🌈 Performance requirements might specify things like the maximal packet delays or the minimal bandwidth share given to a flow 🦋

This section also specifies actions the packet handling path must take to actively give feedback to end-nodes about conditions at the network element 🔥 Those actions might include explicitly generated congestion feedback, indicated either as bits set in the header of data packets or as separate control messages sent 🫶

Okay bestie, let's get into the good stuff 💅✨ The big goal for this part of the spec is to be super precise about what's required, but still leave room for different hardware, different setups, and different kinds of network boxes 🦋 Getting that balance right takes real care, so pay attention 🎀

Invocation Information

This bit covers the set of parameters a service module needs to invoke the service, plus how the module actually uses those values 🧚 For example, a made-up "bounded delay" service could take a request with a delay target for the network element and the set of packets that target applies to. Then it processes those packets with a delay of the target value or less. Iconic 🙌

Most services need two chunks of invocation info: the Traffic Specification (TSpec) and the Service Request Specification (RSpec) 💖 The TSpec describes the characteristics of the data traffic being handled. The RSpec says which properties you want from the service. So a service that promises a mathematical bound on delay might take a TSpec with the flow's bandwidth and burstiness written as a Token Bucket, and an RSpec with the maximum queueing delay you can tolerate 🍓

Here's the vibe: when a service accepts an invocation request, it's basically signing a "contract" 📜 It promises to provide the service described by the RSpec, as long as the flow's traffic keeps matching the TSpec. If the traffic goes outside the TSpec bounds, the QoS the flow gets can change. The exact nature of that change is also spelled out in the service specification (see "Policing" below) 👀

The RSpec and TSpec should be specified separately and independently 🫶 That's because different parts of the internetwork will often generate them. Also, all the quantitative information in this section should follow the guidelines in the Data Formats section of this document, above 💜

Exported Information and Characterization Parameters

This section describes information that the service module must collect and export 📦 Exported info is available to other modules on the network element, and by extension to setup protocols, routing protocols, network management tools, and so on 🌈

Exported info can be used in a bunch of ways, lowkey all of them useful. For instance, things like how much link bandwidth is dedicated to the service, and which data flows are currently getting the service, are great to expose as network management variables 📊

A service definition can pick out a subset of its exported info and call those characterization parameters 🦋 These can be used to compute or estimate the end-to-end behavior of a data flow crossing a chain of network service elements. They can also describe parts of the path for use by network elements. For example, to work out how much buffer it needs, an element might need to know something about the service characteristics of the upstream part of the path 🧚 A service that defines characterization parameters also has to specify the characterizations they generate and the composition functions used to make them 💅

NOTE: Characterization parameters are identified as such by virtue of being the inputs to a service's defined composition functions. Because characterization parameters are part of a service's overall exported data set, they are also available to other functions, such as network management. The discussion below relates solely to their use as characterization parameters, and is not intended to limit other uses.

Characterization parameters can be pretty static, like the bandwidth available on a specific link, or pretty dynamic, like a running estimate of current packet delay ⭐

Support for a service's defined characterization parameters is mandatory 🔥 Any network element offering this service must be able to measure, compute, or, if the specification allows it, estimate the service's characterization parameters. Service designers are encouraged to think hard about what it means to specify characterization parameters, especially about not unduly restricting the choice of hardware and software architectures used to build the network element 🎀

Characterization parameters get used by composing the values exported by each network element along a flow's path, according to a composition rule. For every parameter or set of parameters used to build a characterization, the service specification must specify the composition rule to be used. These composition rules should give characterizations that don't depend on the order the elements are composed in. Commutativity and associativity are sufficient for that, but not necessary 🧠

Characterization parameters are available through a general interface, and they're provided when some other module asks for them, like a setup protocol or the routing protocol 💌 Exactly how (or whether) a specific protocol, such as RSVP, uses characterization parameters to generate characterizations is described in that protocol's own specification 🌸

Whether characterization parameters get used correctly depends on the setup, routing, or management protocol that controls the module 🙈 There's no absolute guarantee that characterizations will reach end-nodes that want to use a QoS control service. Service designers aiming for the global Internet may want to make sure a service is still useful when there are no characterizations, and to show that in the "Examples" sections of the service description document 🌍

On the flip side, characterizations may be mandatory in some situations, especially for private IP networks giving tightly controlled quality of service to specific applications 🔒 Designers targeting that environment should make sure the service provides adequate characterization parameters and composition functions for the target audience 💪 It can make sense to specify the same basic service with extra characterizations that meet requirements beyond what the global Internet needs ✨

Some handy "general" characterization parameters and their composition rules aren't tied to any specific service 🧚 These include the speed-of-light latency of communication links and the available link bandwidth. These general characterization parameters are defined in [RFC 2215].

Even though every conformant implementation of a service is required to provide that service's characterization parameters, the desired parameters might still not be available for composition at every network element in a path 😭 This can happen when different network element services are used at different points along the end-to-end path, like in a heterogeneous internetworking environment. So characterization parameters and composition function results conceptually include a "validity flag" 🚩 A network element that can't provide the characterization parameter must set this flag, and otherwise leave the parameter or composed value unchanged. Once it's set, the flag is preserved by the composition function, and it tells you whether the data is valid when the final composed result reaches its destination 🫶

Protocols that transport characterization parameters and composition data must define and support a concrete representation for this validity flag, as well as for the characterization parameters themselves 🎀

NOTE: This service specification template does not allow a service definition to require that a setup or invocation mechanism used with the service perform any function other than transport of invocation parameters to the network elements and signalling of errors generated by the network elements to the end nodes. A notable example of this is that service specification documents may not require or assume that characterizations defined in the specification are actually computed or presented to the end nodes.

That said, how useful a specific service is can depend a lot on extra behavior in the networked system 🧐 Examples include computing and presenting characterizations to end-nodes, or reliably making sure every network element on the path from sender to receivers supports the given service. Service specification authors are strongly encouraged to clearly explain where their service stands on this 💅 Statements like these are appropriate:

The characterizations defined by this service serve as useful
hints to the application. However, the service is specifically
intended to be useful even if characterizations are not available.

or

The usefulness of this service depends strongly on the delivery of
both characterizations and the knowledge that all network elements
on the path support the service. Requests for this service when
characterizations are not available are likely to lead to
incorrect or misleading results.

It may also be worth thinking about this point in the "Examples of Use" section described below 🦋

NOTE: The possibility of modifying the overall architecture to provide information about the invoking protocol in a service request, and to allow a service to require that the invocation protocol support specific additional functionality, is an area of active study. 🔬

Policing

This part of the service description covers the nature of the policing used to enforce adherence to a flow's Traffic Specification 👑 The specification document must cover the following points:

• Expected policing action. This is the action taken when packets that don't conform to the TSpec are detected. Example actions include relegating nonconforming packets to best effort, immediately dropping nonconforming packets, delaying these packets until they once again "fit" into the TSpec, or "marking" nonconforming packets in some way 🌈
• Legality of alternative policing actions. The section must specify whether actions not specifically mentioned in the specification's description of policing behavior are legal 💖 For example, a service description that says nonconforming packets are to be dropped should state whether an alternate action, such as delaying these packets, is acceptable 🤔
• Location of policing actions in the internetwork. okay so this one is all about where policing happens 👀 The description of policing must specify where that policing is done. Options include "at the edges of the network only", "at every hop", "heterogeneous branch points" (where the branches of a multicast tree converge and have different TSpecs reserved downstream), and "source merge points" (where multiple data streams covered by a single resource reservation converge) 🌿 The specification should clearly state requirements about topology information (like "this is an edge node" or "this is a source merge point") that must be available from the setup protocol or another source 🧭

In this section the specification should also spell out whether policing at additional points in the network is legal, beyond those listed above. This matters because of technical effects like the ones in the next paragraph 💅

• Applicable additional technical considerations. If policing of data flows is required or legal at points other than the flow's first entry into the network, the service definition should describe any additional technical considerations that affect the design of that policing 🎀 For example, lots of potential services will let a data flow get more bursty as it moves through the network 😮‍💨 If a service like that allows policing somewhere other than the network edge, the traffic specification describing the flow has to be modified from what the application gave the network, to account for that growing burstiness. Otherwise the flow is likely to get overpoliced, meaning packets get penalized for no reason 😭

Ordering and Merging

Ordering and merging come into play when a network element receives several invocation requests covering the same data flow 🦋 This could happen if several receivers of a multicast data flow asked for QoS for that flow using the RSVP setup protocol, or if a flow had both a statically installed permanent invocation request and a dynamic request from a resource setup protocol 🌸

In this situation the service module must be able to answer questions about the ordering between different invocation requests, and it must be able to generate a single new invocation request that meets the semantics of the setup protocol and the requirements of all the original requesters ✨ In practice, the invoking protocol asks the service module, given a set of invocation requests I1...In, to compute a new request that gives the desired behavior 🫶

Five operations must be defined in this section:

• Ordering. The section must define an ordering relationship between the service's TSpecs and RSpecs. This may be a partial ordering, meaning some TSpecs or RSpecs may be unordered with respect to each other 🧩
• Summation. This function computes an invocation request that represents the sum of N input invocation requests. Usually this is used to size a service request for a shared reservation covering N different flows 🫧 It is desirable, but not required, that this function compute the "least possible sum" 💜
• Minimum. This function computes the minimum of two TSpecs. Usually this is used to get the TSpec for an actual service invocation, given a target TSpec for the service request and a TSpec for the flow's actual traffic pattern 🍓 The minimum function must compute the smallest TSpec adequate to describe the minimum of the requested TSpec and the flow's actual traffic 🎯
• RSVP-Merge function. This function computes the invocation request used to request service at an RSVP [RFC 2205] merge point. It must a) compute an appropriate invocation request for a set of downstream reservations being merged, and b) generate appropriate reservation parameters to be passed upstream by RSVP 🔁 This function is described further below and in [RFC 2210] 📖
• Least Common Request function. This function computes an invocation request sufficient to provide service at least equivalent to any one of the original requests passed to it. It differs from the RSVP-merge function in that it simply computes an upper bound 🙈 It does not need to compute new invocation parameters to be passed upstream by RSVP, and it cannot utilize the second option discussed in "Notes on RSVP Merging" below 🚫

Notes on Ordering

Usually the ordering relation is described separately for the service's TSpec and RSpec 🧁 An invocation request is ordered with respect to another if and only if both its TSpec and its RSpec are similarly ordered with respect to each other 💖

For TSpecs, the basic ordering relation is well defined 🌈 TSpec A is substitutable for TSpec B if and only if any flow that is compliant with TSpec B is also compliant with TSpec A. The service specification must explain how to compare two TSpecs to determine whether this is true 🔍

For RSpecs, the ordering relation depends on the service 🪄 RSpec A is substitutable for RSpec B if the quality of service invoked by RSpec A is at least as good as the quality of service invoked by RSpec B. There's no precise mathematical description of "goodness" of quality of service, so these ordering relations must be spelled out explicitly in the service description 🫠

Notes on RSVP Merging

The whole point of the RSVP merging function is to compute an invocation request that gives the merged flow service at least as good as what any of the original requests would get for its corresponding unmerged flow 💅 There are two ways to get that equivalence:

1. The merged request may be computed as an upper bound on the set of original (unmerged) invocation requests. In this case, the service offered by the merged request to any particular traffic flow is identical to what the largest unmerged request offers, by definition 🏔️
2. The merged request may be computed as a value smaller than the upper bound on the set of original requests, but the results passed upstream may restrict the traffic sources to behavior that makes the merged and unmerged requests behave identically 🤏

Note that the merging rules for a particular service may apply either option 1 or option 2 to the different components of a TSpec, as appropriate 🎀 The decision is usually made like this:

When a downstream service module instance can tolerate a flow that exceeds the parameter, the upper bound should be used. For example, if the service supports policing to protect itself against excess traffic, the traffic rate supported by a merged reservation might be an upper bound across the traffic rates supported by each unmerged reservation. The effect is to install the merged reservation at the local node and to inform each traffic source of the largest traffic rate protected by reservation along any one distribution path from the source to a receiver. 🛡️

When a downstream service module instance will not function properly if the parameter is exceeded, the merge function should select the least aggressive value of the parameter to install and pass upstream. In this case, the traffic sources will be informed of a parameter value that is appropriate for all distribution paths traversed by the traffic flow. For example, services that can handle only limited packet sizes can incorporate packet size in the TSpec, and treat the parameter as described in option 2. The effect is to limit packet sizes in the flow to those that every instance of the service along the flow's path can handle 📦

This merging calculation must be performed by the service module, because it is specific to a particular service 🧠

Notes on Calculating Upper Bounds

Both the RSVP-Merge function and the Least Common Request function may use calculated upper bounds on TSpec and RSpec parameters 📐

The calculated upper bound doesn't need to be a least upper bound, and the various network elements along the path don't all need to use the same choice of upper bound 🌷 Any selection of invocation parameters Iu is compliant as long as it is substitutable for each of the parameters I1...In it's calculated from 🤝 Intuitively, one set of parameters is substitutable for another if the resulting quality of service is at least as desirable to all applications 💫 The precise "substitutable for" function (the ordering relation) must be specified in the service definition. (It may be specified as the empty set, in which case merging of dissimilar requests will not be allowed 🚷) If the ordering function specified in this section gives a partial order (meaning it's possible for two RSpecs or TSpecs to be unordered), then a separate upper bound computation for the parameter must be given as well 🧩

Notes on Service Substitution

This part of the service description may also note any relationships with other services that are strictly ordered with respect to the service being defined 🦄 Two services A and B are strictly ordered if it is always possible to substitute service B for service A, given a set of invocation parameters for service A 🔄 This ordering information may let network elements that provide service B respond to requests for service A, even if the element doesn't provide service A directly 🪞 If the service specification describes such an inter-service ordering, it MUST also include a description of the invocation parameter mapping function for that ordering 📝

Substitution of one service for another in cases where they are not strictly ordered is currently not supported 🙅‍♀️ A future version of this document may augment the service specification format to support this capability 🔮

Guidelines for Implementors

Lots of services can be defined in a way that lets the range of behavior of a compliant network element be pretty broad 🌊 This section should give some guidance on the range of behaviors the author of the service specification expects the community to want in their implementations 🎯 Because these guidelines depend on such imprecise and undefinable notions as "typical loads", they can't be part of a strict compliance test 🙃 Instead, they are for informational purposes only 📚

Evaluation Criteria

The specific functional behaviors required of an implementation to conform to a service specification are detailed in the previous sections 📜 But service specifications are meant to allow a wide range of implementations, and those implementations will differ in performance 🏎️ This section describes tests that can be used to evaluate a network element's implementation of a given service 🧪✨

Okay bestie, implementors of service modules have to juggle a bunch of tradeoffs 😭, and honestly there is no single implementation that's "best" in every situation 💅. Same service spec, totally different vibes: a build for a low-speed link might go all-in on extremely high link utilization 🐢, while another build tries to shave non-loaded packet forwarding delay down to the minimum ⚡, even if the link ends up a little less utilized. The whole point of the tests in this section is to poke at the tradeoffs the implementer made 🔍 and give the customer metrics to help her pick the right implementation for her needs 🎀.

The tests should be designed to operate on a single network element in isolation 🧪. That's what makes them usable in a comparative rating system for QoS-aware network elements 📊. In production networks though, users care more about the end-to-end behavior they actually get 🌐, and that depends on way more than the elements picked. Things like the setup protocol and the bandwidth of the links matter too 🔗. Some user-relevant performance factors are the rate of admission control rejections 🚫, the range of services offered 🎁, and the packet delay and drop rates in the various service classes 📦. The form of any standardized end-to-end metrics and measurement tools for integrated service internetworks is not specified by this document, or by service specification documents that follow the format given here 📝.

This section is for informational purposes only. 💖

• Examples of Implementation 🛠️

This section describes example instantiations of the service ✨. Often these will just be references to the literature, or brief sketches of how the service could be implemented 📚. The goal is to give you a more concrete sense of the service being specified, plus pointers and hints to help the implementor 🧚. But the descriptions here are specifically not meant to rule out other implementation strategies, so don't think you're stuck with them 🦋.

This section is for informational purposes only. 🌸

• Examples of Use 🎬

In order to give a more concrete sense of how this service might be used 🍓, this section walks through some example uses of the service, for informational purposes only 💜. These examples are not meant to be exhaustive, and they don't exclude any other uses of the service in any way 🌈.

This section is for informational purposes only. ✨

Security Considerations 🔐

Security considerations are not discussed in this memo. 😱 Dramatic, I know, but that's the official word, so no spiraling in the replies 💀.

References 📚

[PARTRIDGE] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994).

[RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.

[RFC 2205] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of 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 1819] Delgrossi, L., and L. Berger, Editors, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.

[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.

Authors' Address 💌

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
Fax:   617-253-2673
EMail: jtw@lcs.mit.edu

That's the whole RFC, bestie! 🫶👑