HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:30:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 09 Aug 1997 03:25:18 GMT ETag: "2e700c-4057-33ebe31e" Accept-Ranges: bytes Content-Length: 16471 Connection: close Content-Type: text/plain Internet Engineering Task Force RSVP WG INTERNET-DRAFT L. Breslau/S. Shenker draft-ietf-rsvp-partial-service-00.txt Xerox PARC April 23, 1997 Expires: 10/23/97 Partial Service Deployment in the Integrated Services Architecture 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). Abstract Specifications for providing enhanced qualities of service in the Internet have been defined in [2,4]. Technical and administrative concerns may prevent a network element from offering one or more of these services. In this document, we present a mechanism for dealing with heterogeneity in the set of services offered by different network elements. This approach enables end-to-end service to be composed of different per-hop services while not requiring end systems to be aware of the details of the service provided at each hop. Breslau/Shenker Expires 10/23/97 [Page 1] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 Introduction The Integrated Services Working Group has produced specifications for new types of service[2,4]. These services will provide enhanced qualities of service to applications that use them. Such services will be most useful when they are provided at all network elements along a data distribution path. However, because these services impose stricter requirements on the network elements than traditional best-effort service, it may not be practical to provide these services on some subnet technologies. Furthermore, the ultimate decision to implement and deploy a particular service belongs to vendors and network service providers, respectively. A vendor may choose not to implement a service, or network service provider may choose not to offer a service (e.g., for administrative reasons), even if the underlying technology is able to support the service. Therefore, newly defined services will not always be available end- to-end along a data distribution path. In this document we describe a strategy for coping with this heterogeneity in the set of services offered in a network. Replacement Services The mechanism for addressing the problem of service heterogeneity is built on the concept of "replacement" services. When a network element does not offer a service, it can offer a replacement service for it. Under circumstances described below, when a network element receives a request for a service it does not offer, it treats the request as if it were for the replacement service. A replacement service can be one of the other real-time services, best-effort service, or a non-compliant implementation of the original service. Decisions about the use of replacement services are a local matter. Replacement services are characterized as either "reliable" or "unreliable". A reliable replacement is one that is expected to meet the requirements of the service being replaced a large majority of the time (e.g., over 95%). No assurance is given about the resulting quality of an unreliable replacement. Since best effort service qualifies as an unreliable replacement in all circumstances, network elements are always able to at least offer unreliable replacements for every service. When a network element offers a reliable replacement it MUST also export meaningful values for any characterization parameters required by the original service. (See [1] and [3] for a discussion of Breslau/Shenker Expires 10/23/97 [Page 2] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 characterization parameters.) These parameters must accurately characterize the replacement service, and when composed end-to-end with parameters from other network elements they must provide applications with a valid characterization of the end-to-end service. When a network element offers an unreliable replacement it MAY export values for any characterization parameters of the original service if it is able to accurately characterize the service. However, given that an unreliable replacement may be arbitrarily bad, the network element may instead set the value of all characterization parameters to the "invalid" values defined for those parameters. We provide the following guidelines for determining whether a network element offers an actual service, a reliable replacement, or an unreliable replacement. Offered Service: In order to claim to offer a service, a network element's implementation of the service must conform to the service specification. Specific conformance requirements are included in the service specification documents (e.g., [2,4]). Some knowledge about the environment in which an implementation is deployed can be used in making this determination. For example, an implementation of Controlled-Load in a router attached to an ethernet may be compliant if all routers and hosts attached to the network participate in a distributed admission control process to reserve resources on the ethernet. However, the same implementation may not be compliant if there are hosts attached to the ethernet that do not participate in the bandwidth allocation procedure. Knowledge of link bandwidth can also be used to determine service compliance. For example, a router may be able to offer a service on an interface using FIFO scheduling and no admission control if the bandwidth on the link exceeds the sum of the input bandwidths on all other links. On the other hand, knowledge about average levels of offered load cannot be used to claim compliance with the currently defined service specifications; the offered service must comply with the service specifications independent of ambient loading. Reliable Replacement: A network element can claim to offer a reliable replacement if it does not offer the actual service but the service it provides is expected to adhere to the specification of the original service a large majority of the time. This determination can take local conditions, including expected load, into account. However, since the semantics of a reliable replacement are that it emulates very closely the actual service, applications using reliable replacements will expect to receive service that is in general not significantly different than the original service. Therefore, the reliable replacement label should be applied to service replacements with caution. Furthermore, since a reliable replacement will often depend on local conditions, and conditions may change over time, Breslau/Shenker Expires 10/23/97 [Page 3] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 network operators should monitor these conditions and continually reassess the suitability of reliable replacements. Finally, note that the ability to provide a reliable replacement may also depend on the availability of appropriate invocation parameters for the replacement service. We offer two examples of reliable replacements. First, a router on a vastly underutilized point-to-point link, which rarely experiences persistent congestion, may offer best effort service as a reliable replacement for Controlled Load service. Second, a router attached to an ethernet that has an otherwise compliant implementation of Controlled Load but has no means to control the load generated by other stations attached to the ethernet may claim to offer a reliable replacement for Controlled Load if the ethernet is not in general highly loaded. Unreliable Replacement: Since unreliable replacements make no assurances about the service they provide, any service qualifies as an unreliable replacement for any other service. Hence, when the actual service or a reliable replacement is not offered, an unreliable replacement can always be offered. For example, best effort service on a congested link qualifies as an unreliable replacement for any real-time service. Applications should have no expectations about the resulting service when they use an unreliable replacement. Finally, additional real-time services may be defined after a particular implementation is deployed. Hence, a network element may not even know about a requested service, so it cannot make an informed decision about the suitability of its offered services (other than best effort) to act as replacements. In such cases, the router can always use best effort as an unreliable replacement. Characterizing Service Offerings Each network element must export characterization parameters describing the various services and replacements that it offers. An example format and composition rules for these characterization parameters are described in the Appendix to this document. Service Handling Flags When characterization parameters are provided end-to-end by a setup protocol, an application will know before issuing a service request whether any replacement services will be substituted for its request. Breslau/Shenker Expires 10/23/97 [Page 4] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 Applications that would be dissatisfied with the level of assurance provided by the resulting service should refrain from issuing service requests when such substitutions would be made. The Integrated Services architecture is intended to allow services to be invoked by more than one setup protocol or by network management functions. Therefore, we cannot assume that end-to-end characterizations of service offerings will always be available to the applications. When they are not, mechanisms are needed so that applications can express to the network elements their willingness to accept replacement services. We propose that application preferences be expressed in a new object that we refer to as the Service Handling Flags, which is optionally included in service requests. These flags are associated with service requests in general, and not with specific services, so they are associated with service_name 0 (just like general characterization parameters). The parameter is a 16-bit value. The most significant bit is set to 1 if service replacements are *not* allowed and 0 if replacements are allowed. The remaining 15 bits are currently unused. Hence, the default router action is to perform replacements when a requested service is not available. In environments where end-to-end characterizations are available (e.g., as with RSVP) the Service Handling Flags are not needed. When end-to-end characterizations are not available, an end system must include the Service Handling Flags with the most significant bit set in order to prevent the use of replacement services. Security Considerations Security considerations are not discussed in this memo. Appendix -- Service Availability Characterization Parameters The following is an example format for characterization parameters describing service availability. An integrated services aware router exports a general characterization parameter for each service that it knows about indicating whether it offers the service, a reliable replacement for the service, or an unreliable replacement for the service. These parameters, when composed end-to-end, inform the endpoints about the Breslau/Shenker Expires 10/23/97 [Page 5] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 end-to-end availability of services. The parameter_name for the local parameter is N. A single router can export multiple characterization parameters with parameter_name N, each corresponding to a different service. The specific service referenced by a particular parameter is identified by a field within the parameter itself. Each local parameter is represented by a sequence of 4 16-bit unsigned integers in network byte order. The first is the service_name for the service referenced by the parameter. The service_name is defined within the service specification for each service (e.g., see [2,4]). The second has the value 1 if the router offers the indicated service and 0 if the router does not offer the service. The third field has the value 1 if the router offers a reliable replacement for the service and 0 if the router does not offer a reliable replacement for the service. The fourth field has the value 1 if the router offers an unreliable replacement for the service and 0 if the router does not offer an unreliable replacement for the service. A router must assign a value of 1 to exactly one of the latter three fields. Guidelines for offering reliable replacements and unreliable replacements are specified earlier in this document. The parameter_name for the composed end-to-end parameter is N+1. The specific service referenced by a particular parameter is specified by a field inside the parameter itself. Each composed parameter is represented by a sequence of 4 16-bit unsigned integers in network byte order. The first is the service_name for the service characterized by the parameter. The second is the number of routers that offer the service. The third is the number of routers that offer reliable replacements for the service. The fourth is the number of routers that offer unreliable replacements for the service. The composition rule for composing a local parameter with a composed parameter is to add the i_th value of the local parameter to the i_th value of the composed parameter, for i = {2,3,4}. Two parameters can be composed only if the first field in each parameter (the service_name) is the same. References [1] S. Shenker and J. Wroclawski. "Specification of General Breslau/Shenker Expires 10/23/97 [Page 6] INTERNET-DRAFT draft-ietf-rsvp-partial-service-00.txt April 23, 1997 Characterization Parameters", Internet Draft, October 1996, . [2] S. Shenker, C. Partridge and R. Guerin. "Specification of Guaranteed Quality of Service", Internet Draft, February 1997, . [3] S. Shenker and J. Wroclawski. "Network Element Service Specification Template", Internet Draft, November 1996, . [4] J. Wroclawski. "Specification of Controlled-Load Network Element Service", Internet Draft, November 1996, . Authors' Addresses: Lee Breslau Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 breslau@parc.xerox.com 415-812-4402 415-812-4471 (FAX) Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 shenker@parc.xerox.com 415-812-4840 415-812-4471 (FAX) Breslau/Shenker Expires 10/23/97 [Page 7]