Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT S. Shenker/J. Wroclawski draft-ietf-intserv-svc-template-01.txt Xerox PARC/MIT LCS June, 1995 Expires: 12/25/95 Network Element Service Specification Template Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft is a product of the Integrated Services Working Group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at int- serv@isi.edu and/or the author(s). Abstract This document defines a format for specifying services provided by network elements, and available to applications, in a network which offers multiple classes of service. The document provides necessary context, including definitions, data formats, and interfaces; 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 Shenker/Wroclawski Expires 12/25/95 [Page 1] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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 format used to specify the functionality of internetwork system components related to "Integrated Services"; the ability to provide multiple, dynamically selectable qualities of service to applications using the 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, as specified by this document, 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 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. The service definition does not describe the protocols or mechanisms used to establish state in the network elements for flows that use the described service, but may specify information which must be carried between end-nodes and network elements by those mechanisms. 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. Definitions The following terms are used throughout this document. Service specification documents should employ the same terms to express these concepts. Shenker/Wroclawski Expires 12/25/95 [Page 2] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 o Quality of Service (QoS) In the context of this document, quality of service refers to the suitability of a packet delivery service for the needs of a particular application, as defined 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 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-aware" network element is one which offers one or more of the services defined according to the format of this document. Note that this definition does not by itself preclude QoS-aware network elements which meet performance goals purely through adequate provisioning, rather than active control mechanisms. 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. Mechanisms used to associate a request for quality of service control with the packets covered by that request are beyond the scope of this Shenker/Wroclawski Expires 12/25/95 [Page 3] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 document. o Service The word "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 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 a "service module" contained within the network element. A network element may and generally will contain more than one service module and hence offer more than one service. NOTE: The above defines a precise meaning for the word "service"; 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 Shenker/Wroclawski Expires 12/25/95 [Page 4] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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. Several characterizations may be computed for a single candidate data flow. Conversely, characterizations are not mandatory, 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 specification of the traffic pattern which a flow expects to exhibit. 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 -expected- 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). Traffic specifications are most frequently created by the originator of the data flow. Shenker/Wroclawski Expires 12/25/95 [Page 5] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 o Service Request Specification (RSpec) A Service Request Specification, or RSpec, is a specification of the quality of service a flow desires from a network element. The form 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. Service request specifications may originate from either the sender or receiver(s) of a data flow. 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 [xxx], ST-II [xxx] and Q.2931 [xxx]. o Token Bucket 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. Token buckets are further discussed in [xxx]. o Token Bucket Filter 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 discarding of the packet or marking the packet in some fashion. NOTE: The definition of token bucket in this document does not Shenker/Wroclawski Expires 12/25/95 [Page 6] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 allow for token bucket filters with a "backing buffer" which queues packets that do not immediately pass through the filter. The intent is to cleanly distinguish the bufferless case from the buffer case through the use of different names; however this draft does not yet provide a definition for the second case. o Admission Control Admission control is the process of deciding whether a newly arriving request for service from a network element can be granted, or must be refused due to scarcity of resources. 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 the locations in the network where discrepancies are to be detected and the action to be taken when such discrepancies occur. Examples of such actions might include dropping packets, reshaping the traffic, or marking non- conforming traffic for later discard if necessary. Data Format and Representation Each service module will import and export a variety of data according to its specific requirements. The 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 Shenker/Wroclawski Expires 12/25/95 [Page 7] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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. 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. 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. Interfaces The service module conceptually interacts with other portions of the network element through a number of interfaces. These interfaces are documented in [xxx; the non-existent new IS - Overview RFC]. The service specification document should clearly define each 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. 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 Shenker/Wroclawski Expires 12/25/95 [Page 8] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 document. o Components The body of a service specification document incorporates the following sections: - Motivation [required] - Network Element Data Handling Requirements [required] - Invocation Information [required] - Exported Information [required] - Policing [required] - Ordering and Merging [required] - Resulting Service [required] - Guidelines for Implementors - Evaluation Criteria [required] - Examples of Implementation - Examples of Use 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. 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 Shenker/Wroclawski Expires 12/25/95 [Page 9] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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 the 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 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. These two components of the invocation information should be specified separately and Shenker/Wroclawski Expires 12/25/95 [Page 10] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 independently, as they will often be generated and transported 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 portions 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. A service which defines characterization parameters also specifies the characterizations they are used to generate and the composition functions used to generate the characterizations. 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 soley 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 Shenker/Wroclawski Expires 12/25/95 [Page 11] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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 that would most likely come from either the setup protocol or the routing protocol. The issue of exactly how, or if, a specific protocol (e.g., RSVP) uses characterization parameters to generate characterizations should be described in the specification of that specific protocol. There is no requirement that setup and routing protocols use the characterization parameters supplied by service modules, and there is no 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. 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 fully 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. It may be useful to define "generic" characterization parameters not associated with any specific service. These might include the speed-of-light latency of communication links (additive composition rule) and available link bandwidth (minimum composition rule). Eventually, these generic parameters should be defined in the Integrated Services overview document, and incorporated by reference in the Router Requirements document and the relevant service specification documents. Characterization parameters are named, so that protocols which Shenker/Wroclawski Expires 12/25/95 [Page 12] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 transport and use these parameters can uniquely identify them. The namespace is a two-level hierarchy: .; each of these elements is a numerical quantity. This same namespace is used to name the results of composition functions which are made available to end-nodes. The service specification author may also choose to name intermediate data which might be transported as part of a distributed composition function computation. The reason for assigning names to these data objects is to support a variety of styles for calculating the composition function, and to ensure that the end-nodes can clearly determine the meaning of data delivered to them as part of a characterization. - is a 16-bit number. The number space is broken into two regions. The region below 32768 (high bit 0) is managed by the IANA. 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 is a published RFC following the format described in this note. Numbers in the region above 32768 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 appropriate in the future. - is a 16-bit number assigned on a per-service basis. Numbers are allocated by the author of the service specification document. [ Is 16 bits too big? Could be 8.8, or a non-byte split such as 6.10 ] Service Number 0 (zero) is reserved for the "generic" parameters described above. Parameter numbers within this space are initially allocated by the INT-SERV WG, and may in the future be allocated by IANA. These . pairs should be used as last two levels of the MIB name when the parameters are made available to network management protocols. Shenker/Wroclawski Expires 12/25/95 [Page 13] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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 immediately dropping nonconforming packets, delaying these packets until they once again "fit" into the TSpec, or "marking" nonconforming packets in some way, to enable dropping them preferentially if a later network element in the marked packet's path should be overloaded. - 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. - 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", 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 Shenker/Wroclawski Expires 12/25/95 [Page 14] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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 service 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 requirements of all the original requesters. This new request is a "merged" request. It may be equal to one of the original requests, or it may be a newly computed request. Operationally, this is achieved by having the setup protocol ask the service module, given a set of requests R1...Rn, to compute an merged request which which results in service to the merged flow at least equivalent to that which any of the original requests would obtain for its corresponding unmerged flow. Hence, the merged invocation request represents an "upper bound" on the set of original invocation requests. This upper bound calculation must be performed by the service module because it is specific to a particular service. 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 Ru is compliant as long as it substitutable for each of the parameters R1...Rn 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). A merging computation (upper bound calculation) MAY be given in the document as well. Shenker/Wroclawski Expires 12/25/95 [Page 15] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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. 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. This portion of the service description may also note any ordering 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 SHOULD 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. 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. This section should be as detailed as possible. There are certain services where the end-to-end behavior is a highly nontrivial result of the concatenation of per-hop services; one purpose of this section is that such nontrivial results are not left unrevealed to the reader of this document. In private networks it will generally be the case that the required Shenker/Wroclawski Expires 12/25/95 [Page 16] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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. 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 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. Shenker/Wroclawski Expires 12/25/95 [Page 17] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 are appropriate. It may also be useful to consider this point in the "Examples of Use" section described below. ] NOTE: The possibility of adopting alternative wording for this document which allows a service to require that the invocation protocol support specific additional functionality or return an error is a topic open to discussion. 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 Shenker/Wroclawski Expires 12/25/95 [Page 18] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 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. 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. 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. Security Considerations Security considerations are not discussed in this memo. Authors' Address: Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 shenker@parc.xerox.com 415-812-4840 Shenker/Wroclawski Expires 12/25/95 [Page 19] INTERNET-DRAFT draft-ietf-intserv-svc-template-01.txt June, 1995 415-812-4471 (FAX) John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 jtw@lcs.mit.edu 617-253-7885 617-253-2673 (FAX) Shenker/Wroclawski Expires 12/25/95 [Page 20]