Network Working Group R. Santitoro Internet Draft Nortel Networks Category: Informational Expiration Date: January 2001 R. Pabbati Microsoft July 2000 Implementation Experience with Policy Error Object in Identity Policy Element draft-santitoro-rap-policy-errorcodes-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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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]. 1. Abstract This document defines two new ErrorValues for the Policy Error Object, which is part of the Policy Data object [RFC2752]. These new ErrorValues are being defined because the ErrorValues defined in RFC 2752 are not extensive enough for a Policy server(PDP) to control application data flows. Hence this draft is defining two new ErrorValues to provide the host with additional information on the error that caused the RSVP reservation failure. Santitoro and Pabbati Expires: January 2001 1 draft-ietf-rap-policy-errorcodes-00.txt July 2000 One ErrorValue allows the host to request a new reservation with different QoS requirements from the initial reservation. Consequently, the network may be able to provide this new QoS level and hence the host can achieve some QoS instead of only achieving a best effort service. The other ErrorValue is used to convey to a host that the reservation has failed and host must not send the particular type of traffic. This is important for applications that the network cannot easily classify and therefore may have difficulty blocking from the network. The ErrorValues are sent back to the host in the Policy Data Object inside an RSVP PathErr or ResvErr message as defined in [RFC 2752]. This works for both sender-based or receiver-based admission control. 2. Introduction The POLICY_DATA object can be used to convey two types of policy failure information back to hosts initiating an RSVP reservation. The first type of failure informs the host that it must choose between sending its traffic with no QoS (best effort service) or attempt another reservation requesting a different QoS level from the network. Some applications, e.g., IP telephony used in a business environment, may be configured to use alternate paths to send traffic, e.g., route call to PSTN, because a best effort service does not provide an acceptable level of quality for the user. The second type of failure informs the requesting host and/or application that it should not send any traffic for the flow signaled in the RSVP messages. This is useful when the network cannot provide a useful level of QoS that the application needs and it is better for the host to not send the traffic rather than the traffic experiencing unpredictable and hence undesirable QoS. This is also useful to limit the amount of traffic send to expensive connections. Note that this approach works for both sender-based and receiver-based admission control models. The POLICY_DATA object containing this ErrorValue may be part of either a PathErr or ResvErr message depending upon whether the Path message or Resv message is used for admission control. 3. New ErrorValues for Policy Error Object The Policy Error 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 Santitoro and Pabbati Expires January 2001 2 draft-ietf-rap-policy-errorcodes-00.txt July 2000 6 INSUFFICIENT_BANDWIDTH Reservation failed due to insufficient bandwidth to satisfy the host's reservation request. Host may still send traffic but the network provides no QoS. 7 DO_NOT_SEND Reservation failed and host is informed to not send any traffic 3.1 INSUFFICIENT_BANDWIDTH (ErrorValue=6) This ErrorValue is used to quickly fail an RSVP reservation due to insufficient bandwidth. For certain types of applications, such as IP telephony, it is critical to minimize connection setup time. Therefore, it is best to fail an RSVP reservation as soon as it is known that insufficient bandwidth is available for the call. For an IP telephony application, the PDP could include this ErrorValue in a PathErr message back to the initiating IP Phone. This allows the reservation to be failed by a PDP (Policy Decision Point) or LDP (Local Decision Point) in the first RSVP-aware PEP (Policy Enforcement Point) in the network where there is insufficient bandwidth to satisfy the IP Phone's reservation request. Once this reservation has failed, additional information can be conveyed to the host in the OctetString field in the Policy Error Object. The host may use this additional information for the new reservation request. Because this ErrorValue can be sent via a PathErr message in response to a Path message, the reservation can be quickly failed. This type of quick failure is important for applications such as IP telephony that have stringent connection setup times. Note that this scenario uses a sender-based admission control model. When a reservation is failed using this ErrorValue, the host may send the traffic with no QoS if this is acceptable to the application. This can also be achieved by the PDP sending a DCLASS object with DSCP '000000' (best effort service) back to the originating host to use to mark subsequent traffic associated with the reservation. This has the same result of getting no QoS treatment from the network. However, in the latter case, the application will not know that it is getting no QoS and may not function properly. Finally, the network may send a non-best effort DCLASS object back to the host so its traffic can achieve some QoS from the network albeit not the QoS it requested in the initial reservation. The determination of the alternative DCLASS object would be made by the PDP and the host may elect to accept this new DCLASS object. Example 1: Santitoro and Pabbati Expires January 2001 3 draft-ietf-rap-policy-errorcodes-00.txt July 2000 A host attempts a reservation request for 384kbps but the network can only provide 128kbps during the time of the reservation. The network fails the reservation due to insufficient bandwidth (ErrorValue=6) and can indicate in the OctetString "128kbps available" (128kbps of bandwidth was available at the time the reservation had failed). The host may then initiate a new reservation requesting 128kbps if this is acceptable to the host's application. Example 2: A host attempts a reservation request for 384kbps with a given QoS level but the network has no bandwidth available at for the requested QoS level. The network fails the reservation due to insufficient bandwidth (ErrorValue=6). The host can then use this information to make one of many decision, e.g., attempt to initiate new reservation with different QoS level or lower bandwidth, send as best effort, etc. 3.2 FLOW_DENIED (ErrorValue=7) This ErrorValue informs the host to not send traffic. This is used when the PDP (or LDP) does not want the host to send any traffic even as best effort. Network administrators are limiting deploying of multimedia applications on enterprise networks because they are concerned about sending multimedia traffic over their expensive wide area network connections. Network administrators would like to either prevent high bandwidth applications from sending any data over these expensive connections or at least limit the number of simultaneous sessions that can be active. The simple choice is not to deploy these types of applications. This ErrorValue provides the network administrators with the control they need over these expensive network resources. Furthermore, when a PDP returns this ErrorValue, it could also push a filter to the PEP to drop all packets for this session. 4. Security Considerations Authentication mechanisms defined in [RFC 2752] apply to this document. 5. 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. Santitoro and Pabbati Expires January 2001 4 draft-ietf-rap-policy-errorcodes-00.txt July 2000 [RFC 2752] Yadav S., et al. "Identity Representation for RSVP", RFC 2752, January 2000. 6. Acknowledgments The authors would like to thank Yoram Bernet, Kwok-Ho Chan, Ron Pashby, Eric Edwards and Nabil Seddigh for their input into the creation of this document. 7. 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 Santitoro and Pabbati Expires January 2001 5