T. Moore, Microsoft Internet Draft February, 1999 Document: draft-moore-qualsvc-00.txt expires August, 1999 Specification of the Qualitative Service Type Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 1. Abstract This draft describes the use of RSVP [RFC2205] with applications that do not have resource requirements that may not be readily quantifiable (qualitative applications). We introduce the æqualitativeÆ service-type. This service-type can be used in conjunction with RSVP signaling to manage the allocation of network resources to traffic originating from qualitative applications. This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diff-serv) QoS mechanisms with RSVP signaling [intdiff]. 2. Motivation Using standard RSVP/Intserv signaling, applications running on hosts issue requests for network resources by communicating the following information to network devices: 1. A requested service level (Guaranteed or Controlled Load). 2. The quantity of resources required at that service level. Moore 1 draft-moore-qualsvc-00.txt February, 1999 3. Classification information by which the network can recognize specific traffic (filterspec). 4. Policy/identity information indicating the user and/or the app for which resources are required. In response, standard RSVP aware network nodes choose to admit or deny a resource request. The decision is based on the availability of resources along the relevant path and on policies. Policies define the resources that may be granted to specific users and/or applications. When a resource request is admitted, network nodes install classifiers that are used to recognize the admitted traffic and policers that are used to assure that the traffic remains within the limits of the resources requested. Standard RSVP/Intserv is not suitable for qualitative applications because these applications are unable to quantify the resources they require from the network. Since the required resources cannot be quantified, network nodes cannot determine whether sufficient resources exist to accommodate an applicationÆs traffic and standard Intserv style admission control cannot be applied. Diff-serv QoS mechanisms are better suited for qualitative applications. Nodes in a diff-serv network are typically provisioned to classify arriving packets to some small number of behaviour aggregates (BAs) [diffarch], and to treat them accordingly. This provisioning tends to be æopen-loopÆ in the sense that there is no signaling between hosts and the network. Instead, the network administrator uses a combination of heuristics, measurement and experience to provision the network devices, with no deterministic knowledge of the volume of traffic that will arrive at any specific node. In applying diff-serv mechanisms to manage qualitative traffic, network administrators are faced with two challenges: 1. Provisioning û network administrators need to anticipate the volume of traffic likely to arrive at each network node for each diff-serv BA. If the volume of traffic arriving is likely to exceed the capacity available for the BA claimed, the network administrator has the choice of increasing the capacity for the BA, reducing the volume of traffic claiming the BA, or compromising service to all traffic arriving for the BA. 2. Classification û diff-serv nodes classify traffic to user and/or application, based on the diff-serv codepoint (DSCP) in each packetÆs IP header or based on other fields in the packetÆs IP header (source/destination address/port and protocol). The latter method of classification is referred to as MF classification. This method of classification may be unreliable and imposes a management burden. By using RSVP signaling, the management of traffic from qualitative applications in diff-serv networks can be significantly facilitated. (Note that RSVP/diff-serv interoperability has been discussed Moore 2 draft-moore-qualsvc-00.txt February, 1999 previously in the context of quantitative applications and quantitative diff-serv services [intdiff]. This draft focuses on qualitative applications.) 3. Operational Overview In the proposed mechanism, the RSVP sender advertises the new service type, æService Type Qualitative' in the ADSPEC that is included with the PATH message. No SENDER_TSPEC object is included in the PATH message. The RSVP sender also includes with the PATH message policy objects identifying the user, application and sub application ID [identity, application]. Network nodes receiving these PATH messages interpret the service type to indicate that the traffic flow is not quantifiable. Instead of applying quantitative admission control, network nodes manage the traffic flow based on the requesting user, the requesting application and the type of application sub-flow. This mechanism offers significant advantage over a pure diff-serv network. It informs each network node which would be affected by the traffic flow (and which is interested in intercepting the signaling) of: 1. The demand for resources in terms of number of flows of a particular type traversing the node. 2. The binding between classification information and user, application and sub-application. This information is particularly useful to policy enforcement points and policy decision points (PEPs and PDPs). The network is expected to return an RSVP RESV message to the sender. The returned RESV message may include a DCLASS object [dclass]. The DCLASS object instructs the sender to mark packets on the corresponding flow with a specific DSCP. This mechanism allows PEP/PDPs to affect the volume of traffic arriving at a node for any given BA. It enables the PEP/PDP to do so based on sophisticated policies. 3.1 Operational Notes 3.1.1 Scalability Issues In any network in which per-flow signaling is used, it is wise to consider scalability concerns. Signaling for qualitative applications (in addition to quantitative applications) will increase the amount of signaling traffic in the network. However, since RSVP signaling does not, in general, generate a significant amount of traffic relative to the actual data traffic associated with the session. Moore 3 draft-moore-qualsvc-00.txt February, 1999 Perhaps of more concern is the impact on processing resources at network nodes that process the signaling messages. When considering this issue, it's important to point out that it is not necessary to process the signaling messages at each network node. In fact, the combination of RSVP signaling with diff-serv networks may afford significant benefits even when the RSVP messages are processed only at certain key nodes (such as boundaries between network domains, first-hop routers, PEPs or any subset of these). Individual nodes should be enabled or disabled for RSVP processing at the discretion of the network administrator. See [intdiff] for a discussion of the impact of RSVP signaling on diff-serv networks. In any case, per-flow state is not necessarily required, even in nodes that apply per-flow processing. 3.1.2 Policy Enforcement in Legacy Networks Network nodes that adhere to the RSVP spec will transparently pass the signaling messages associated with qualitative applications. As such, it is possible to introduce a small number of PEPs that are enabled for Service Type Qualitative into a legacy network and to realize the benefits described in this draft. 3.1.3 Quantitative Applications which Accept Qualitative Service This draft does not preclude applications from offering both a quantitative service type and Service Type Qualitative, at the same time. An example of such an application would be a telephony application that benefits from a quantitative service but is able to adapt to a qualitative service. By advertising its support for both, the application enables network policy to decide which service type to provide. 4. Signaling Details 4.1 ADSPEC Generation The RSVP sender constructs an initial RSVP ADSPEC object specifying Service Type Qualitative. Since there are no service specific parameters associated with this service type, the associated ADSPEC fragment is empty and contains only the header word. Network nodes may or may not supply valid values for bandwidth and latency general parameters. As such, they may use the unknown values defined in [RFC2216]. The ADSPEC is added to the RSVP PATH message created at the sender. 4.2 RSVP SENDER_TSPEC Object The RSVP SENDER_TSPEC object should not be included in PATH messages advertising Service Type Qualitative as the only service type supported. Moore 4 draft-moore-qualsvc-00.txt February, 1999 4.3 RSVP FLOWSPEC Object Receivers may respond to PATH messages by generating an RSVP RESV message including a FLOWSPEC object. The FLOWSPEC object should specify that it is requesting Service Type Qualitative. 5. Detailed Message Formats 5.1 Standard ADSPEC Format A standard RSVP ADSPEC object is described in [RFC2210]. It includes a message header and a default general parameters fragment. Following the default general parameters fragment are fragments for each supported service type. 5.2 ADSPEC for Qualitative Service Type The Qualitative Service Type ADSPEC includes the message header and the default general parameters fragment, followed by a single fragment denoting Service Type Qualitative. The new fragment introduced for Service Type Qualitative is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (a) |x| Reserved | 0 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a - indicates Service Type Qualitative (3). x - is the break-bit. b - indicates zero words in addition to the header. A complete ADSPEC supporting only Service Type Qualitative is illustrated below: Moore 5 draft-moore-qualsvc-00.txt February, 1999 31 24 23 16 15 8 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | Reserved | Msg length û1 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 1 (c) |x| Reserved | 8 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 4 (e) | (f) | 1 (g) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | IS hop cnt (32-bit unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | 6 (h) | (i) | 1 (j) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Path b/w estimate (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | 8 (k) | (l) | 1 (m) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Minimum path latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 | 10 (n) | (o) | 1 (p) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10 | Composed MTU (32-bit unsigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 11 | 3 (q) |x| Reserved | 0 (r) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Word 1: Message Header: (a) - Message header and version number (b) - Message length - 10 words not including header Words 2-10: Default general characterization parameters (c) - Per-Service header, service number 1 (Default General Parameters) (x) - Global Break bit (NON_IS_HOP general parameter 2) (d) - Length of General Parameters data block (8 words) (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general parameter) (f) - Parameter 4 flag byte (g) - Parameter 4 length, 1 word not including header (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general parameter) (i) - Parameter 6 flag byte (j) - Parameter 6 length, 1 word not including header (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general parameter) (l) - Parameter 8 flag byte (m) - Parameter 8 length, 1 word not including header (n) - Parameter ID, parameter 10 (PATH_MTU general parameter) (o) - Parameter 10 flag byte (p) - Parameter 10 length, 1 word not including header Word 11: Qualitative parameters (q) - Per-Service header, service number 3 (Qualitative) (x) - Break bit for Service Type Qualitative Moore 6 draft-moore-qualsvc-00.txt February, 1999 (r) - Length (0) of per-service data not including header word. Note that the standard rules for parsing ADSPEC service fragments ensure that the ADSPEC will not be rejected by legacy network elements. Specifically, these rules state that a network element encountering a per-service data header which it does not understand should set bit 23 (the break-bit) to indicate that the service is not supported and should use the length field from the header to skip over the rest of the fragment. Also note that it is likely that it will not be possible for hosts or network nodes to generate meaningful values for words 5 and/or 7 (bandwidth estimates and path latency), due to the qualitative nature of the service. In this case, the unknown values from [RFC2216] should be used. 5.3 FLOWSPEC Object Format The format of an RSVP FLOWSPEC object originating at a receiver requesting Qualitative service is shown below. The value of 3 in the per-service header (field (c), below) indicates that Service Type Qualitative is being requested. 31 24 23 16 15 8 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 1 (b) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | 3 (c) |0| reserved | 0 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length 1 word not including header) (c) - Service header, service number 3 (Qualitative) (d) - Length of qualitative data, 0 words not including per-service header 5.4 DCLASS Object Format DCLASS objects may be included in RESV messages. For details regarding the DCLASS object format, see [dclass]. 6. Security Considerations The message formatting and usage rules described in this note raise no new security issues. 9. References [RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [RFC2216] Shenker, S., and Wroclawski, J., "Network Element QoS Control Service Specification Template", RFC 2216, September 1997. Moore 7 draft-moore-qualsvc-00.txt February, 1999 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., "A Framework for Use of RSVP with Diff-serv Networks", Internet Draft, November 1998. [diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", RFC 2475, December 1998. [identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., "Identity Representation for RSVP", Internet Draft, February 1999. [application] Bernet, Y., "Application and Sub Application Identity Policy Objects for Use with RSVP", Internet Draft, February 1999. [dclass] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP Signaling", Internet Draft, February 1999. 10. Acknowledgments We thank Andrew Smith and Fred Baker for their comments on this draft. 11. Author's Addresses Tim Moore Microsoft One Microsoft Way Redmond, WA 98052 Timmoore@microsoft.com Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052 Yoramb@microsoft.com Andrew Smith Extreme Networks 10460 Bandley Drive Cupertino CA 95014 USA +1 (408) 342 0999 andrew@extremenetworks.com This draft expires August, 1999 Moore 8