Network Working Group R. Santitoro Internet Draft Nortel Networks Document: draft-ietf-rap-modify-sender-behavior-00.txt Category: Standards Track R. Pabbati Expiration: December 2001 Y. Bernet Microsoft July 2001 RSVP ErrorValues Used to Modify Sender Behavior draft-ietf-rap-modify-sender-behavior-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1. Abstract This draft defines several mechanisms by which network policies can use RSVP signaling to control the behavior of compliant sending applications. Specifically, two new error codes are defined for use in the RSVP Policy Data object [RFC 2752]. In addition, a new use of the DCLASS object [RFC 2996] is defined. 2. Introduction The initial focus of RSVP was to offer enhanced service to quantitative, multimedia applications. Over the past few years, we have learned that this focus is inconsistent with the priorities of many network managers. Most network managers are primarily concerned with maintaining control of their network resources to protect qualitative, mission critical traffic. Ironically, this usually means either disallowing or severely restricting the deployment of just the type of multimedia application that RSVP was Santitoro, et. al. Expires: December 2001 1 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 originally intended to serve. If it were possible to better control the behavior of these applications, they would become more deployable. RSVP can be used to do so. From the perspective of a sender and a receiver of application traffic, the conventional usage of RSVP is as follows: 1. Application sends PATH message. 2. Receiver uses RESV message to request reservation of resources for transmitted traffic. 3. Network either dedicates resources to the transmitted traffic or not (makes an admission control decision). 4. The admission control decision is indicated to the *receiver*. 5. Sender sends traffic regardless of the admission control decision. RSVP signaling focuses on allocating network resources rather than controlling the behavior of the sending application. (Certain applications may use out of band signaling between receiver and sender. This signaling can be used to convey the network's admission control decision from the receiver to the sender, in order to impact the behavior of the sender. However, there is no explicit mechanism by which network policies can use RSVP to control the behavior of the sender). RSVP has been adapted to address pragmatic concerns. Its integration with DiffServ [RFC 2998] addresses scalability concerns. The definition of the null service [RFC 2997] applies it to the type of qualitative mission critical applications that network managers deem most important to protect. Finally, the specification of the DCLASS object [RFC 2996] provides a mechanism by which network policies can control the behavior of sending applications (by using RSVP signaling to tell the sending application or host which DSCP to use in marking its traffic). The ErrorValues and the DCLASS usage proposed in this draft provide the ability for network policies to explicitly control the behavior of sending applications. The first ErrorValue informs the sending application that it MUST NOT send the traffic described in its PATH message. The second ErrorValue informs the sending application that prioritized resources are not available but that it may proceed to send with no resource guarantees. (The ErrorValues are intended to be included in PATH_ERR messages, in response to corresponding PATH messages). Finally, the inclusion of a DCLASS object in a PATH_ERR message is also discussed. In RFC 2996, the DCLASS object is discussed primarily in the context of RESV messages that are returned to the sender when a reservation request is admitted in the network. By including a DCLASS object in PATH_ERR messages as described in this document, it is possible Santitoro, et. al. Expires: December 2001 2 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 to control the behavior of the sender when a reservation request is not admitted. 3. New ErrorValues for Policy Error Object The Policy Error Object from the Policy Data Object (P-Type=1 or 2, A- Type=4, SubType=0) contains the ErrorValue field. The following two new ErrorValues are defined below. ErrorValue Description ------------------ ---------------------------------------------------- 7 DO_NOT_SEND The network cannot accommodate the traffic described in the sender's PATH message. The application must not transmit this traffic. 6 NO_QOS_PROVIDED The application may send the traffic described in the PATH message but the network will not offer any service assurances. 3.1. DO_NOT_SEND (ErrorValue=7) This ErrorValue is used to instruct sending applications not to send the traffic described in the PATH messages for the corresponding session. Note that this ErrorValue does not preclude sending altogether. Rather, it precludes sending per the profile described in the PATH messages for the session. Compliant applications respond either by refraining from sending altogether, or by modifying their traffic profile (typically, to a less demanding profile). The new traffic profile will be reflected in subsequent PATH messages and is less likely to elicit the DO_NOT_SEND response from the network. This ErrorValue enables network managers (via a policy management system) to limit the impact of certain applications on the network resources. It is important to distinguish this mechanism from alternate control mechanisms available to the network manager. One alternative is to simply deny QoS to the sending application (as in rejecting RESV messages on the corresponding session). Although this approach prevents the traffic transmitted on the session from interfering with other prioritized traffic, it does not prevent it from consuming best-effort resources. Thus, the transmitted traffic will compete with all other best-effort applications. Another alternative is available to the network manager in certain cases. If the network is capable, it may force the traffic transmitted on the session to a less than best-effort (LBE) queue. To do so, the network must identify the traffic on the session. It may do so either by extracting the classification information for the session from the corresponding RSVP messages, or by causing the sending host to mark the traffic with a DSCP corresponding to LBE service. (The latter approach uses the DCLASS object as described in section 4). Santitoro, et. al. Expires: December 2001 3 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 While forcing traffic to an LBE queue does protect best-effort traffic, it requires functionality that may or may not be available in different parts of the network. The DO_NOT_SEND ErrorValue makes it possible to deploy compliant applications on networks that do not support this functionality. Finally, an often-used alternative is to simply refuse to allow the deployment of aggressive applications on the network. 3.2 NO_QOS_PROVIDED (ErrorValue=6) This ErrorValue indicates to the sending application that it will receive prioritized service for the traffic described in the PATH message for the corresponding session. Unlike the DO_NOT_SEND ErrorValue, it does not preclude the application from sending. Rather, it warns the application that transmitted traffic will not be assured any particular QoS. From the network perspective, this response is similar to rejecting RESV messages for the corresponding session. However, unlike RESV message rejection (which is not indicated to the sender and may or may not be indicated to the receiver), the NO_QOS_PROVIDED ErrorValue gives immediate and explicit indication to the sender. The sender may respond to the NO_QOS_PROVIDED ErrorValue by either: - Not sending traffic on the corresponding session, - Proceeding to send the traffic described by the corresponding PATH message (with no QoS assurances) or - Modifying its traffic profile (typically, to a less demanding profile). The new traffic profile will be reflected in subsequent PATH messages and is less likely to elicit the NO_QOS_PROVIDED response from the network. 4. Use of the DCLASS Object in PATH_ERR Messages As discussed in section 3.1, it is often desirable to force certain traffic to an LBE queue in the network. To do so, PEPs must either store classification information to be used in identifying the traffic (typically in the form of a 5-tuple), or the traffic must be marked explicitly for LBE service. One way to mark traffic for LBE service is by marking the transmitted packets with an LBE DSCP. The DCLASS object [RFC 2996] can be used by policy management systems to tell senders the DSCP with which to mark their traffic flows. RFC 2996 focuses on the use of the DCLASS object in RSVP RESV messages. However, senders only receive RESV messages if the network has admitted the RSVP request. If the network rejects the RSVP request, no RESV message will arrive at the sender and there is no mechanism by which to force the sender to mark the rejected traffic with a specific DSCP. In the absence of alternate mechanisms, rejected traffic is either sent with Santitoro, et. al. Expires: December 2001 4 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 the best-effort DSCP (DSCP=0) or is not sent at all (DO_NOT_SEND response). We therefore propose that the DCLASS object be used in PATH_ERR messages when it is necessary to mark traffic on a session for which the corresponding RSVP request was rejected. A DCLASS object in a PATH_ERR message can specify a DSCP that is interpreted by the network PEPs to correspond to an LBE service. 5. Policies and Policy Server Support The mechanisms described are expected to be supported by policy servers (PDPs) that are COPS/RSVP [COPS-RSVP] conversant. The following examples illustrate the types of policies that may be authored. 5.1 Prevent Streaming Video App. from Compromising Best-Effort Services A policy would be created in a PDP that controls PEPs in the affected part of the network where streaming video applications are to be blocked. The policy would apply to all PATH messages including the application ID [RFC 2872] corresponding to the streaming video application. It would respond to each such PATH message with a PATH_ERR message specifying the DO_NOT_SEND ErrorValue. 5.2 Allocate Prioritized Service to a Limited Volume of Streaming Video Application traffic while Preventing Excess Traffic from Compromising Best-Effort Service A policy would be created in a PDP that controls PEPs in the affected part of the network. The policy would admit RSVP resource requests including the application ID corresponding to the streaming video application, up to a maximum allowed bandwidth. Once the maximum bandwidth is reached, additional resource requests will be rejected (using the conventional RESV_ERR message). The network will preclude additional traffic by responding to the sender's PATH messages with a PATH_ERR message specifying the DO_NOT_SEND ErrorValue. 5.3 Allocate Prioritized Service to a Limited Volume of Streaming Audio Traffic while Forcing Excess Traffic to LBE Service A policy would be created in a PDP that controls PEPs in the affected part of the network. The policy would admit RSVP resource requests including the application ID corresponding to the streaming audio application, up to a maximum bandwidth. Once the maximum bandwidth is reached, additional resource requests will be rejected (using the conventional RESV_ERR message). However, additional traffic will not be precluded but rather, relegated to an LBE service. PATH_ERR messages specifying the NO_QOS_PROVIDED ErrorValue and a DCLASS object (specifying a DSCP corresponding to LBE service) will be sent in response to PATH messages corresponding to the additional traffic. These will provide explicit and immediate notification to the sending application indicating that its traffic will not receive prioritized service and that it must be marked for LBE service. Santitoro, et. al. Expires: December 2001 5 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 6. Security Considerations Security mechanisms defined in [RFC 2752] apply to this draft. 7. References [RFC 2753] Yavatkar R., et. al. "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC 2750] Herzog S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RFC 2752] Yadav S., et. al. "Identity Representation for RSVP", RFC 2752, January 2000. [RFC 2872] Bernet Y., Pabbati R. "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RFC 2996] Bernet Y. "Format of the RSVP DCLASS Object", RFC 2996, November 2000. [COPS-RSVP] Herzog S., et. al. "COPS usage for RSVP", RFC 2749, January 2000. [RFC 2997] Bernet Y., et. al. "Specification of the Null Service Type", RFC 2997, November 2000. [RFC 2998] Bernet Y., et. al. "A Framework for Integrated Services Operation over DiffServ Networks", RFC 2998, November 2000. 8. Acknowledgements The authors would like to thank Kwok-Ho Chan, Ron Pashby, Eric Edwards and Nabil Seddigh for their input into the creation of this document. 9. Author's Addresses Ralph Santitoro Nortel Networks 4100 Guardian Street Simi Valley, CA 93063 Phone: 805-527-3024 Email: rsantito@nortelnetworks.com Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054 Phone: 425-936-9438 Email: rameshpa@microsoft.com Yoram Bernet Santitoro, et. al. Expires: December 2001 6 draft-ietf-rap-modify-sender-behavior-00.txt July 2001 Microsoft 1 Microsoft Way Redmond, WA 98054 Phone: 425-936-9568 Email: yoramb@microsoft.com Santitoro, et. al. Expires: December 2001 7