doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc2216.txt b/doc/rfc/rfc2216.txt
new file mode 100644
index 0000000..cf38710
--- /dev/null
+++ b/doc/rfc/rfc2216.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                         S. Shenker
+Request for Comments: 2216                                 J. Wroclawski
+Category: Informational                               Xerox PARC/MIT LCS
+                                                          September 1997
+
+
+             Network Element Service Specification Template
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document defines a framework for specifying services provided by
+   network elements, and available to applications, in an internetwork
+   which offers multiple qualities of service. The document first
+   provides some necessary context -- including relevant definitions and
+   suggested data formats -- and then specifies a "template" which
+   service specification documents should follow. The specification
+   template includes per-element requirements such as the service's
+   packet handling behavior, parameters required and made available by
+   the service, traffic specification and policing requirements, and
+   traffic ordering relationships.  It also includes evaluation criteria
+   for elements providing the service, and examples of how the service
+   might be implemented (by network elements) and used (by
+   applications).
+
+Introduction
+
+   This document defines the framework used to specify the functionality
+   of internetwork system components which support the the ability to
+   provide multiple, dynamically selectable qualities of service to
+   applications using an internetwork. The behavior of individual
+   routers and subnetworks is captured as a set of "services", some or
+   all of which may be offered by each element. The concatenation of
+   these services along the end-to-end data paths used by an application
+   provides overall quality of service control.
+
+   The definition of a service states what is required of a router (or,
+   more generally, any network element; a router, switch, subnet, etc.)
+   which supports a particular service. The service definition also
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 1]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   specifies parameters used to invoke the service, the relationship
+   between those parameters and the service delivered, and the end-to-
+   end behavior obtained by concatenating several instances of the
+   service.
+
+   Each service definition also specifies the interface between that
+   service and the environment. This includes the parameters needed to
+   invoke the service, informational parameters which the service must
+   make available for use by setup, routing, and management mechanisms,
+   and information which should be carried between end-nodes and network
+   elements by those mechanisms in order to achieve the desired end-to-
+   end behavior. However, 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.
+
+   Services defined following the guidelines of this document are
+   intended for use both within the global Internet and private IP
+   networks. In certain cases a concatenation of network element
+   services may be used to provide a range of end-to-end behaviors, some
+   more suited to a decentralized internet and some more appropriate for
+   a tightly managed private network. This document points out places
+   where such distinction may be appropriate.
+
+   This document is comprised of three parts.  The first defines some
+   terms used both in this document and in the various service
+   specification documents.  The second discusses data formats and
+   representations.  The third portion of the document describes the
+   various components of the service specification template.
+
+Definitions
+
+   The following terms are used throughout this document. Service
+   specification documents should employ the same terms to express these
+   concepts.
+
+ o Quality of Service (QoS)
+
+   In the context of this document, quality of service refers to the
+   nature of the packet delivery service provided, as described by
+   parameters such as achieved bandwidth, packet delay, and packet loss
+   rates. Traditionally, the Internet has offered a single quality of
+   service, best-effort delivery, with available bandwidth and delay
+   characteristics dependent on instantaneous load. Control over the
+   quality of service seen by applications is exercised by adequate
+   provisioning of the network infrastructure. In contrast, a network
+   with dynamically controllable quality of service allows individual
+   application sessions to request network packet delivery
+   characteristics according to their perceived needs, and may provide
+
+
+
+Shenker & Wroclawski         Informational                      [Page 2]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   different qualities of service to different applications. It should
+   be understood that there is a range of useful possibilities between
+   the two endpoints of providing no dynamic QoS control at all and
+   providing extremely precise and accurate control of QoS parameters.
+
+ o Network Element
+
+   A "Network Element" (or the equivalent shorter form "Element"), is
+   any component of an internetwork which directly handles data packets
+   and thus is potentially capable of exercising QoS control over data
+   flowing through it. Network elements include routers, subnetworks,
+   and end-node operating systems. A QoS-capable network element is one
+   which offers one or more of the services defined according to the
+   rules given in this document.  Note that this definition, by itself,
+   preclude 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 is one
+   which supports the interfaces (described below) required by the
+   service definitions.  Thus, a QoS-aware network element need not
+   actually offer any of the services defined according to the format of
+   this document; it merely needs to know how to deny service requests.
+
+ o Flow
+
+   For the purposes of this document a flow is a set of packets
+   traversing a network element all of which are covered by the same
+   request for control of quality of service. At a given network element
+   a flow may consist of the packets from a single application session,
+   or it may be an aggregation comprising the combined data traffic from
+   a number of application sessions.
+
+      NOTE: this definition of a flow is different from that used in
+      IPv6, where a flow is defined as those packets with the same
+      source address and FlowID.
+
+   Mechanisms used to associate a request for quality of service control
+   with the packets covered by that request are beyond the scope of this
+   document.
+
+ o 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 a
+   specification of the functions to be performed by the network
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 3]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   element, the information required by the element to perform these
+   functions, and the information made available by the element to other
+   elements of the system.  A service is conceptually implemented within
+   the "service module" contained within the network element.
+
+      NOTE: The above defines a precise meaning for the word "service".
+      Service is a word which has a variety of meanings throughout the
+      networking community;  the definition of "service" given here
+      refers specifically to the actions and responses of a single
+      network element such as a router or subnet. This contrasts with
+      the more end-to-end oriented definition of the same word seen in
+      some other networking contexts.
+
+ o Behavior
+
+   A "behavior" is the QoS-related end-to-end performance seen by an
+   application session. This behavior is the end result of composing the
+   services offered by each network element along the path of the
+   application's data flow.
+
+   When each network element along a data flow path offers the same
+   service, it is frequently possible to explain the resulting end-to-
+   end behavior in a straightforward fashion. The behavior of a data
+   flow path comprised of elements using different services is more
+   complicated, and may in fact be undefined. A future version of this
+   document may impose additional requirements on the service
+   specification relating to multi-service concatenation.
+
+ o Characterization
+
+   A characterization is a computed approximation of the actual end-to-
+   end behavior which would be seen by a flow requesting specific QoS
+   services from the network.  By providing additional information to
+   the end-nodes before a flow is established, characterizations assist
+   the end-nodes in choosing the services to be requested from the
+   network.
+
+ o Characterization Parameters
+
+   Characterizations are computed from a set of characterization
+   parameters provided by each network element on the flow's path, and a
+   composition function which computes the end-to-end characterization
+   from those parameters. The composition function may in practice be
+   executed in a distributed fashion by the setup or routing protocol,
+   or the characterization parameters may be gathered to a single point
+   and the characterization computed at that point.
+
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 4]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   Several characterizations may be computed for a single candidate data
+   flow. Conversely, a service may provide no characterizations, and
+   under some conditions no characterizations may be available to the
+   end-nodes requesting QoS services.
+
+ o Composition Function
+
+   A composition function accepts characterization parameters as input
+   and computes a characterization, as described above.
+
+ o Traffic Specification (TSpec)
+
+   A Traffic Specification, or TSpec, is a description of the traffic
+   pattern for which service is being requested. In general, the TSpec
+   forms 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 continues
+   to be accurately described by 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 specifies the flow's *allowed* traffic
+   pattern, not the flows *actual* traffic pattern. The behavior of a
+   service when a flow's actual traffic does not conform to the traffic
+   specification must be defined by the service (see "Policing" below).
+
+ o Service Request Specification (RSpec)
+
+   A Service Request Specification, or RSpec, is a specification of the
+   quality of service a flow wishes to request from a network element.
+   The contents of a service request specification is highly specific to
+   a particular service. As examples, these specifications might contain
+   information about bandwidth allocated to the flow, maximum delays, or
+   packet loss rates.
+
+ o Setup Protocol
+
+   A setup protocol is used to carry QoS-related information from the
+   end-nodes requesting QoS control to network elements which must
+   exercise that control, and to install and maintain to required QoS
+   control state in those network elements.  A setup protocol may also
+   be used to collect QoS-related information from interior network
+   elements along an application's data flow path for ultimate delivery
+   to end nodes. Examples of protocols which perform setup functions are
+   RSVP [RFC 2205], ST-II [RFC 1819], and Q.2931.
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 5]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   Note that other mechanisms, such as network management protocols, may
+   also perform this function. The phrase "setup protocol"
+   conventionally refers to a protocol with this function as its primary
+   purpose.
+
+ o Token Bucket
+
+   A Token Bucket is a particular form of traffic specification
+   consisting of a "token rate" r and a "bucket size" b. Essentially,
+   the r parameter specifies the continually sustainable data rate,
+   while the b parameter specifies the extent to which the data rate can
+   exceed the sustainable level for short periods of time.  More
+   specifically, the traffic must obey the rule that over all time
+   periods, the amount of data sent cannot exceed rT+b, where T is the
+   length of the time period.
+
+   Token buckets are further discussed in [PARTRIDGE].
+
+ o Token Bucket Filter
+
+   A Token Bucket Filter is a filtering or policing function which
+   differentiates those packets in a traffic flow which conform to a
+   particular token bucket specification from those packets which do
+   not. The specific treatment accorded nonconforming packets is not
+   specified in this definition; common actions are relegating the
+   packet to best effort service, discarding the packet, or marking the
+   packet in some fashion.
+
+  o Admission Control
+
+   Admission control is the process of deciding whether a newly arriving
+   request for service from a network element can be granted. This
+   action must be performed by any service which wishes to offer
+   absolute quantitative bounds on overall performance. It is not
+   necessary for services which provide only relative statements about
+   performance, such as the Internet's current best-effort service. The
+   precise criteria for making the admission control decision are a
+   specific to each particular service.
+
+ o Policing
+
+   Policing is the set of actions triggered when a flow's actual data
+   traffic characteristics exceed the expected values given in the
+   flow's traffic specification. Services which require policing
+   functions to operate correctly must specify both the action to be
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 6]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   taken when such discrepancies occur and the locations in the network
+   where discrepancies are to be detected.  Examples of such actions
+   might include relegating the packet to best effort service, dropping
+   packets, reshaping the traffic, or marking non-conforming traffic in
+   some fashion.
+
+  o Interfaces
+
+   The service module conceptually interacts with other portions of the
+   network element through a number of interfaces.  The service
+   specification document should clearly define the specific data,
+   including formats, which moves across each conceptual interface, and
+   ensure that the mapping between conceptual interfaces and the
+   specific mechanisms of the service being defined are clear.
+
+ Data Format and Representation
+
+   A service module will import and export a variety of data according
+   to the specific requirements of the services the network element
+   supports. Each service definition MUST specify the format of each
+   such data item in an abstract manner. The information specified must
+   be sufficient for the designer of a setup protocol to correctly
+   select an appropriate concrete (packet) format for variables
+   containing this 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 which may need be
+     enumerated in the future, even if many of the values are currently
+     unused.
+
+     - Precision: the precision with which a numerical quantity must be
+     represented, and whether that precision is absolute (calling for an
+     integer quantity) or a percentage of the value (allowing for a
+     floating point quantity).
+
+   The service definition SHOULD additionally specify a preferred
+   concrete format for each data field, in the usual packet-layout
+   format used in current Internet Standard documents or in some other
+   accepted specification format. If the service definition contains
+   these concrete definitions, they should be sufficiently complete and
+   detailed to allow the service definition to be incorporated by
+   reference into the specifications for setup protocols and other users
+   of the specified data.
+
+
+
+Shenker & Wroclawski         Informational                      [Page 7]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+      NOTE: The wording above is intended to encourage the use of common
+      data formats by all protocols carrying data related to a specific
+      service, while not mandating this common format or infringing on
+      the freedom of protocol specification designers to define data
+      representations using alternative mechanisms such as ASN.1 or XDR.
+
+Service and Data Element Naming
+
+   End-nodes, network elements, setup protocols, and management entities
+   within an integrated services internetwork need to exchange
+   information about services, service invocation parameters,
+   characterization parameters, and the intermediate variables and end
+   results of composition functions.  To support this requirement, a
+   single uniform namespace is established for services and their
+   parameters.
+
+   The namespace is a two-level hierarchy:
+
+     <service_name>.<parameter_name>.
+
+   Each of these elements is a integer numerical quantity.
+
+   <Service Name> is an integer in the range 1 to 254. The number space
+   is broken into three regions.
+
+   Service number 1 is used to indicate that the associated parameter is
+   generic", and is not associated with a specific service. This use of
+   generic parameters is described more fully in [RFC 2215].
+
+   The range from 2 to 127 used to name services defined by the IETF.
+   Procedures for allocating service numbers in this region will be
+   established by the IETF INT-SERV WG and the IANA. Services designed
+   for public use should obtain a number from this space. The minimum
+   requirement for doing so is a published RFC following the format
+   described in this note.
+
+   Service numbers in the region above 127 are reserved for experimental
+   or private services. Service designers may allocate numbers from this
+   space at random for local experimental use. A policy for global but
+   temporary allocation of these numbers may be established in the
+   future if necessary.
+
+   The value 0 is left unused to allow the direct mapping of parameter
+   names to MIB object names, as described below.
+
+   The value 255 is reserved to facilitate future expansion of the
+   service number space, if required.
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 8]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   <Parameter_name> is a number in the range 1 to 254, allocated on a
+   per-service basis.  Within this range, the values 1 to 127 are
+   reserved for assignment to parameters with a common, shared meaning
+   across all services. These parameters are defined in [RFC 2215].
+
+   Numbers for parameters specific to a service are assigned from the
+   range 128-254 by the author of the service specification document.
+
+   The value 0 is left unused to allow the direct mapping of parameter
+   names to MIB object names, as described below.
+
+   The value 255 is reserved to facilitate future expansion of the
+   parameter number space, if required.
+
+   In addition to their uses within the integrated services framework,
+   these <service_number>.<parameter_number> pairs should be used as
+   last two levels of the MIB name when the corresponding values are
+   made available to network management protocols.
+
+Specification Document Format
+
+   The following portion of this document 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 below, unless there is a compelling argument
+   that the presence of the section is not beneficial. Additional
+   material, including references, should be included at the end of the
+   document.
+
+   Some of these sections are normative, in that they describe specific
+   requirements to which conformant implementations must adhere.  Other
+   sections are informational in nature, in that they describe necessary
+   context and technical considerations important to the implementor of
+   a service. The sections, and their nature (required or optional, and
+   informational or normative) are listed below:
+
+ o Components
+
+   The body of a service specification document incorporates the
+   following sections:
+
+     - End-to-End Behavior [required] [informational]
+
+     - Motivation [required]  [informational]
+
+     - Network Element Data Handling Requirements [required] [normative]
+
+
+
+
+Shenker & Wroclawski         Informational                      [Page 9]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+     - 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]
+
+ o End-to-end Behavior
+
+   This is a description of the behavior that results if all network
+   elements along the path offer the same service, invoked with a
+   defined set of parameters.
+
+   In private networks it will generally be the case that the required
+   end-to-end behavior is obtained by concatenation of network elements
+   utilizing the same service and making significant use of
+   characterizations.
+
+   In the global Internet, this will not always be true. End-to-end
+   behaviors will frequently be obtained through a concatenation of
+   network elements supporting different services, including in some
+   cases elements which exercise no QoS control at all. Mechanisms to
+   characterize end-to-end behavior in this circumstance are not fully
+   established at this time. Future versions of this document may impose
+   additional requirements on service specifications to facilitate
+   inter-service composition.
+
+   This section is for informational purposes only.
+
+ o Motivation
+
+   This section discusses why this service is being defined. It
+   describes what kinds of applications might make use of this service,
+   and why this service might be more appropriate for those applications
+   than other possible choices. This section is for informational
+   purposes only.
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 10]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+ o Network Element Data Handling Requirements
+
+   This section contains a description of the QoS properties seen by
+   data packets processed by a network element using this service. The
+   description must clearly explain what variables are controlled, the
+   degree of control exercised, and what aspects 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, when at all possible, be
+   expressed as performance requirements rather than by specifying a a
+   particular packet scheduling algorithm. The performance requirements
+   might, for example, be a specification of the maximal packet delays
+   or the minimal bandwidth share given to a flow.
+
+   This section also specifies actions which the packet handling path is
+   required to take to actively provide feedback to end-nodes about
+   conditions at the network element. Such actions might include
+   explicitly generated congestion feedback, indicated either as bits
+   set in the header of data packets or separate control messages sent.
+
+   When writing this section of the service specification document, the
+   authors' goal should be to specify the required behavior as precisely
+   as necessary while still leaving adequate room for the implementation
+   and architectural tradeoffs appropriate to different circumstances
+   and classes of network elements. Successfully achieving this balance
+   may require some care.
+
+ o Invocation Information
+
+   This section describes the set of parameters required by a service
+   module to invoke the service, and a description of how the parameter
+   values are used by the service module.  For example, a hypothetical
+   "bounded delay" service might be described as accepting a request
+   indicating a delay target for the network element and the set of
+   packets subject to that delay target, and processing packets in the
+   given set with a delay of the target value or less.
+
+   Necessary invocation information for most services can be broken into
+   two parts, the Traffic Specification (TSpec) and the Service Request
+   Specification (RSpec). The TSpec gives characteristics of the data
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 11]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   traffic to be handled, while the Rspec specifies the properties
+   desired from the service. For example, a service offering a
+   mathematical bound on delay might accept a TSpec giving the traffic
+   flow's bandwidth and burstiness specified as a Token Bucket, and an
+   RSpec giving the maximum tolerable queueing delay.
+
+   A service accepting an invocation request may be thought of as
+   entering into a "contract" to provide the service described by the
+   RSpec as long as the flow's traffic continues to be described by the
+   TSpec. If the flow's traffic pattern falls outside the bounds of the
+   TSpec, the QoS provided to the flow may change. The precise nature of
+   this change is also described by the service specification (see
+   "Policing" below).
+
+   The RSPec and TSpec components of the invocation information should
+   be specified separately and independently, as they will often be
+   generated by different elements of the internetwork
+
+   All quantitative information specifications in this section should
+   follow the guidelines given in the Data Formats section of this
+   document, above.
+
+ o Exported Information and Characterization Parameters
+
+   This section describes information which must be collected and
+   exported by the service module. Exported information is available to
+   other modules of the network element, and by extension to setup
+   protocols, routing protocols, network management tools, and the like.
+
+   Information exported by service modules may be used in several ways.
+   For example, quantities such as the amount of link bandwidth
+   dedicated to the service and the set of data flows currently
+   receiving the service are appropriate pieces of information to make
+   available as network management variables.
+
+   A service definition may identify a particular subset of the
+   information exported by a service module as characterization
+   parameters. These characterization parameters may be used to compute
+   or estimate the end-to-end behavior of a data flow traversing a
+   concatenation of network service elements. They may also be used to
+   characterize portions of the path for use by network elements (e.g.,
+   in computing the buffer necessary, an element may need to know
+   something about the service characteristics of the upstream portion
+   of the path). A service which defines characterization parameters
+   also specifies the characterizations they are used to generate and
+   the composition functions used to generate the characterizations.
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 12]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+      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 may be relatively static quantities, such
+   as the bandwidth available on a specific link, or relatively dynamic
+   quantities, such as a running estimation 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 allowed by the specification, estimate the
+   service's characterization parameters. Service designers are
+   encouraged to understand the implications of specifying
+   characterization parameters for a service, particularly with respect
+   to not unduly restricting the choice of hardware and software
+   architectures used to implement the network element.
+
+   Characterization parameters are used by composing the values exported
+   by each network element along a data flow's path according to a
+   composition rule. For each parameter or set of parameters used to
+   develop a characterization, the service specification must specify
+   the composition rule to be used. These composition rules should
+   result in characterizations that are independent of the order in
+   which the element are composed; commutativity and associativity are
+   sufficient but not necessary conditions for this.
+
+   Characterization parameters are available through a general
+   interface, and are provided in response to a request from some other
+   module, such as a setup protocol or the routing protocol. The
+   question of exactly how, or if, a specific protocol (e.g., RSVP) uses
+   characterization parameters to generate characterizations is
+   described in the specification of that specific protocol.
+
+   The correct use of characterization parameters supplied by service
+   modules is a function of the setup, routing, or management protocol
+   controlling the module. There is no absolute guarantee that
+   characterizations will be available to end-nodes desiring to use a
+
+   QoS control service. Service designers targeting services for the
+   global Internet may wish to ensure that a service is useful even in
+   the absence of characterizations, and to exhibit such uses in the
+   "Examples" sections of the service description document.
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 13]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   Conversely, the availability of characterizations may be mandatory in
+   certain circumstances, particularly for private IP networks providing
+   tightly controlled qualities of service for specific applications.
+   Service designers targeting this environment should particularly
+   ensure that the service provides adequate characterization parameters
+   and composition functions to meet the needs of target audiences. It
+   may be appropriate to specify the same basic service with additional
+   characterizations for meeting specific requirements beyond those of
+   the global Internet.
+
+   Some useful "general" characterization parameters and corresponding
+   composition rules are not associated with any specific service.
+   These include the speed-of-light latency of communication links and
+   available link bandwidth. These general characterization parameters
+   are defined in [RFC 2215].
+
+   Although every conformant implementation of a service is required to
+   provide that service's characterization parameters, it is still
+   possible that the desired characterization parameters will not be
+   available for composition at all network elements in a path. This
+   situation may arise when different network element services are used
+   at different points in the end-to-end path, as may be required in a
+   heterogeneous internetworking environment. For this reason,
+   characterization parameters and composition function results
+   conceptually include a "validity flag". A network element which is
+   unable to provide the characterization parameter must set this flag,
+   and otherwise leave parameter or composed value unchanged. Once set,
+   the flag is preserved by the composition function, and serves as an
+   indicator of the validity of the data when the final composed result
+   is delivered to its destination.
+
+   Protocols which 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 point notwithstanding, the practical usefulness of a specific
+   service may be highly dependent on the presence of some additional
+   behavior in the networked system, such as the computation and
+
+
+
+Shenker & Wroclawski         Informational                     [Page 14]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   presentation of characterizations to end-nodes or the reliable
+   assurance that every network element in the path from sender to
+   receivers supports the given service. Service specification authors
+   are strongly encouraged to clearly explain the situation of their
+   service in this regard. Statements such as:
+
+      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.
+
+   are appropriate. It may also be useful to consider 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.
+
+ o Policing
+
+   This portion of the service description describes the nature of
+   policing used to enforce adherence to a flow's Traffic Specification.
+   The specification document must specify the following points
+
+     - Expected policing action. This is the action taken when packets
+     not conforming 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
+     specification's description of policing behavior are legal. For
+     example, a service description which specifies that nonconforming
+     packets are to be dropped should state whether an alternate action,
+     such as delaying these packets, is acceptable.
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 15]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+     - Location of policing actions in the internetwork. The description
+     of policing must specify where that policing is done. Possibilities
+     include "at the edges of the network only", "at every hop",
+     "heterogeneous branch points" (points where the branches of a
+     multicast tree converge and have different TSpecs reserved
+     downstream), and "source merge points" (points where multiple data
+     streams covered by a single resource reservation converge). The
+     specification should clearly state requirements about topology
+     information (for example "this is an edge node" or "this is a
+     source merge point") which must be available from the setup
+     protocol or another source.
+
+     In this section the specification should also specify the legality
+     of policing at additional points in the network, beyond those
+     listed above.  This is important due to technical effects such as
+     are described 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 which affect the design of such
+     policing. For example, many potential services will allow a data
+     flow to become more bursty as it progresses through the network. If
+     such a service allows policing at points other than the network
+     edge, the traffic specification describing the flow will have to be
+     modified from that given by the application to the network to
+     account for this growing burstiness. Otherwise, it is likely that
+     the flow will be overpoliced, with packets being penalized
+     unnecessarily.
+
+ o Ordering and Merging
+
+   Ordering and merging come into play when a network element receives
+   several invocation requests covering the same data flow. As examples,
+   this could occur if several receivers of a multicast data flow
+   requested QoS services for that flow using the RSVP setup protocol,
+   or if a flow was subject to 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 must be
+   able to generate a single new invocation request which meets the
+   semantics of the setup protocol and the requirements of all the
+   original requesters. Operationally, this is achieved by having the
+   invoking protocol ask the service module, given a set of invocation
+   requests I1...In, to compute a new request which results in the
+   desired behavior.
+
+
+
+Shenker & Wroclawski         Informational                     [Page 16]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   Five operations must be defined in this section. These are:
+
+     - Ordering. The section must define an ordering relationship
+     between the service's TSpecs and RSpecs. This may be a partial
+     ordering, in that some TSpecs or RSpecs may be unordered with
+     respect to each other.
+
+     - Summation. This function computes an invocation request which
+     represents the sum of N input invocation requests. Typically this
+     function is used to compute the size of a service request adequate
+     for a shared reservation for 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.
+     Typically this function is used to compute 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.
+     The function 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 the
+     function. This function 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 cannot
+     utilize the second option discussed in "Notes on RSVP Merging"
+     below.
+
+ oo Notes on Ordering
+
+   Typically the ordering relation will be 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 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.
+
+
+
+Shenker & Wroclawski         Informational                     [Page 17]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   For RSpecs, the ordering relation is dependent 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.  Since there is no precise mathematical description of
+   "goodness" of quality of service, these ordering relations must be
+   spelled out explicitly in the service description.
+
+ oo Notes on RSVP Merging
+
+   The purpose of the RSVP merging function is to compute an invocation
+   request which will provide service to the merged flow at least
+   equivalent to that which any of the original requests would obtain
+   for its corresponding unmerged flow. This equivalence may be obtained
+   in two ways
+
+     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 that offered by the largest unmerged request,
+     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 which 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 typically made as follows:
+
+     When a downstream service module instance can tolerate a flow which
+     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 of this will be 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 merged function should
+     select the least agressive value of the parameter to install and
+     pass upstream. In this case, the traffic sources will be informed
+     of a parameter value which is appropriate for *all* distribution
+     paths traversed by the traffic flow. For example, services which
+     can handle packets of only limited size can incorporate packet size
+     in the TSpec, and treat the parmeter as described in option 2. The
+
+
+
+Shenker & Wroclawski         Informational                     [Page 18]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+     effect of this will be to limit packet sizes in the flow to those
+     which can be handled by every instance of the service along the
+     flow's path.
+
+   This merging calculation must be performed by the service module
+   because it is specific to a particular service.
+
+ oo Notes on Calculating Upper Bounds
+
+   Both the RSVP-Merge function and the Least Common Request function
+   may make use of calculated upper bounds on TSpec and RSpec
+   parameters.
+
+   The calculated upper bound need not be a least upper bound, nor do
+   the various network elements along the path need to all use the same
+   choice of upper bound.  Any selection of invocation parameters Iu is
+   compliant as long as it substitutable for each of the parameters
+   I1...In from which it is calculated.  Intuitively, one set of
+   parameters is substitutable for another if the resulting quality of
+   service is at least as desirable to all applications. A precise
+   definition of this "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 (if it is possible for two RSpecs
+   or TSpecs to be unordered), then a separate upper bound computation
+   for the parmeter must be given as well.
+
+ oo Notes on Service Substitution
+
+   This portion of the service description may also note any
+   relationships with other services which 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
+   the service A given a set of invocation parameters for service A.
+   This ordering information may be used to allow network elements which
+   provide service B to respond to requests for service A, even if the
+   element does not 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 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.
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 19]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+ o Guidelines for Implementors
+
+   Many services may be defined in a manner which allows the range of
+   behavior of a compliant network element to be rather broad.  This
+   section should provide some guidance as to what range of behaviors
+   the author of the service specification expects the community to
+   desire in their implementations.  Because these guidelines depend on
+   such imprecise and undefinable notions at "typical loads", these
+   guidelines cannot be incorporated as part of a strict compliance
+   test. Instead, they are for informational purposes only.
+
+ o Evaluation Criteria
+
+   Specific functional behaviors required of an implementation for
+   conformance to a service specification is detailed in the previous
+   sections.  However, the service specifications are intended to allow
+   a wide range of implementations, and these implementations will
+   differ in performance. This section describes tests that can be used
+   to evaluate a network element's implementation of a given service.
+
+   Implementors of service modules face a number of tradeoffs, and it is
+   unlikely that a single implementation would be considered "best"
+   under all circumstances. For instance, given the same service
+   specification, an implementation appropriate for a low-speed link
+   might target extremely high link utilization, while a different
+   implementation might attempt to reduce non-loaded packet forwarding
+   delay to the minimum at the expense of somewhat lower utilization of
+   the link. The intention of the tests specified in this section should
+   be to probe the tradeoffs made by the implementation designer, and to
+   provide metrics useful to guide the customer's choice of an
+   appropriate implementation for her needs.
+
+   The tests specified in this section should be designed to operate on
+   a single network element in isolation. This enables their use in a
+   comparative rating system for QoS-aware network elements. In
+   production networks, users will be more concerned with the end-to-end
+   behavior obtained, which will depend not just on the particular
+   network elements selected, but also on other factors such as the
+   setup protocol and the bandwidth of the links. 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 document
+   which follow the format given here.
+
+   This section is for informational purposes only.
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 20]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+ o 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 purposes of the section
+   are to to provide a more concrete sense of the service being
+   specified and to provide pointers and hints to aid the implementor.
+   However, the descriptions in this section are specifically not
+   intended to exclude other implementation strategies.
+
+   This section is for informational purposes only.
+
+ o Examples of Use
+
+   In order to provide more a more concrete sense of how this service
+   might be used, this section describes some example uses of the
+   service, for informational purposes only.  The examples here are not
+   meant to be exhaustive, and do not exclude in any way other uses of
+   the service.
+
+   This section is for informational purposes only.
+
+Security Considerations
+
+   Security considerations are not discussed in this memo.
+
+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.
+
+
+
+Shenker & Wroclawski         Informational                     [Page 21]
+
+RFC 2216            Network Element Service Template      September 1997
+
+
+   [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shenker & Wroclawski         Informational                     [Page 22]
+