Internet Draft Shai Herzog Expiration: May 1997 IBM T.J. Watson Research Center File: draft-ietf-rsvp-policy-ext-01.txt 11/22/96 RSVP Extensions for Policy Control Status of 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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo describes a set of extensions for supporting generic policy based admission control in RSVP. [Note 1] This document does not advocate particular policy control mechanisms; however, a recommendation for a mechanism built on top of these extensions can be found in [LPM]. _________________________ [Note 1] This memo could be conceived as an extension to the RSVP functional specifications [RSVPSP]. Shai Herzog Expiration: May 1997 [Page 1] Internet Draft RSVP Extensions for Policy Control November 1996 Table of Contents 1 Introduction 3 2 Policy Data Object Format 3 2.1 Base Format ........................................... 3 2.2 Policy Data Options .................................... 4 2.2.1 RSVP Objects ..................................... 4 2.2.2 Policy Options ................................... 5 2.2.3 Options Constraints .............................. 7 3 RSVP/Policy Control Interface 7 3.1 Policy Control Services ................................ 8 3.2 PC Success Codes ....................................... 10 3.3 PC Codes: Required Action by RSVP ...................... 11 3.3.1 Refreshing Policy State ......................... 11 3.3.2 Policy Error Signaling .......................... 11 3.3.3 RSVP Response .................................... 12 3.4 Default Handling of Policy Data Objects ................ 12 4 Syntactic Fragmentation of large Policy Data objects 13 5 API Considerations 15 6 Acknowledgment 16 Shai Herzog Expiration: May 1997 [Page 2] Internet Draft RSVP Extensions for Policy Control November 1996 1. Introduction RSVP, by its definition, discriminates between users, by providing some users with better service at the expense of others. Therefore, it is reasonable to expect that RSVP be accompanied by mechanisms for controlling and enforcing access and usage policies. Historically, when RSVP Ver. 1 was developed, the knowledge and understanding of policy issues was in its infancy. As a result, Ver. 1 of the RSVP Functional Specifications[RSVPSP] left a place holder for policy support in the form of POLICY_DATA objects. However, it deliberately refrained from specifying mechanisms, message formats, or providing insight into how policy enforcement should be carried out. This document is intended to fill in this void. The current RSVP Functional Specification describes the interface to admission (traffic) control that is based "only" on resource availability (capacity). In this document we describe a set of extensions to RSVP for supporting policy based admission control as well, in one atomic operation. The scope of this document is limited to these extensions; a discussion of accounting and access control policies for resource reservation protocols can be found in [Arch] and a recommendation for a mechanism built on top of these extensions can be found in [LPM]. 2. Policy Data Object Format The following replaces section A.13 in [RSVPSP]: 2.1 Base Format POLICY_DATA class=14 o Type 1 POLICY_DATA object: Class=14, C-Type=1 +-------------+-------------+-------------+-------------+ | Length | POLICY_DATA | 1 | +---------------------------+-------------+-------------+ | Data Offset | OID | +---------------------------+---------------------------+ | | // Option List // | | +-------------------------------------------------------+ | | // Policy Element List // | | +-------------------------------------------------------+ Shai Herzog Expiration: May 1997 [Page 3] Internet Draft RSVP Extensions for Policy Control November 1996 Data Offset: 16 bits The offset in bytes of the data portion (from the first byte of the object header). OID: 16 bits This field contains an Object ID or 0 if unused. OIDs must be unique for each object of a local session (within a single RSVP node). The OID value is assigned by the PC module, and is mainly used for fragmenting POLICY_DATA objects. (All fragments of a single POLICY_DATA object must have the same OID, see Section 4.) Option List The list of options and their usage is defined in Section 2.2. Policy Element List Policy Elements have the following format: +-------------+-------------+-------------+-------------+ | Length | P-type | +---------------------------+---------------------------+ | | // Policy information (Opaque to RSVP) // | | +-------------------------------------------------------+ The contents of policy elements is opaque to RSVP and its internal format is only known to the Policy Control (PC) module (see [LPM]). 2.2 Policy Data Options The following objects could appear as options in POLICY_DATA objects: 2.2.1 RSVP Objects o FILTER_SPEC object (list) This list represent the set of senders associated with the POLICY_DATA object. If none is provided, the policy Shai Herzog Expiration: May 1997 [Page 4] Internet Draft RSVP Extensions for Policy Control November 1996 information is assumed to be associated with all the flows of the session. o RSVP_HOP Object The RSVP_HOP object uses the same format as RSVP's neighboring node identifier, however, in policy objects it has a slightly different meaning. Here, it identifies the neighbor/peer policy-capable node that constructed the policy object. When policy is enforced at border nodes, the peer policy-capable node may be several RSVP hops away. o INTEGRITY Object The INTEGRITY object [Bak96], provides guarantees that the object was not compromised. [Note 2] 2.2.2 Policy Options o Fragmentation Option +-------------+-------------+-------------+-------------+ | Length | 0 | 1 | +---------------------------+-------------+-------------+ | Variable Length | +-------------------------------------------------------+ This is required and present only in POLICY_DATA fragment objects (allowing RSVP to distinguish them from unfragmented or token objects). The only current format is: - Length = 4, no variable length. This option is present when semantic fragmentation is used. _________________________ [Note 2] In this document, we do not define the algorithm for computing the INTEGRITY value. However, in order to guarantee that the policy is associated with the correct flow/reservation, it may be necessary to perform the computation over other RSVP objects like SESSION, FILTER_SPEC list, etc. Shai Herzog Expiration: May 1997 [Page 5] Internet Draft RSVP Extensions for Policy Control November 1996 o NoChange Option +-------------+-------------+-------------+-------------+ | Length | 0 | 2 | +---------------------------+-------------+-------------+ | 0 | Previous-OID | +---------------------------+---------------------------+ This option provide a hint to the receiving node that the policy information is identical to the "Previous-OID" object. While this option may save on input and output processing, it does not reduce the size of the transmitted state; the complete information must be transmitted in full anyhow since with RSVP's soft-state there is no guarantee that the information associated with the Previous-OID is available at the receiving node. o FilterSpec Option +-------------+-------------+-------------+-------------+ | Length | 0 | 3 | +---------------------------+-------------+-------------+ | Counter | hash type | 0 | +---------------------------+-------------+-------------+ | FILTER_SPEC List 32 bit hash/CRC | +-------------------------------------------------------+ This option allows separating FILTER_SPECs from their corresponding policy data. When present, the policy information should not be associated with the session, but instead, with a list of FILTER_SPECs which was previously sent in a separate POLICY_DATA fragment. This option conserves resources across a non-policy cloud: it allows multiple POLICY_DATA objects from multiple rsvp hops to share the same FILTER_SPEC list. The FILTER_SPEC list itself is sent by a special type of POLICY_DATA fragment. This fragment carries the Fragmentation option, however, its OID is always 0; this way, a POLICY_DATA object created at one node can be matched with a FILTER_SPEC list created by another. Instead of using the OID field, this match is based on the counter field, which provides information about the number of FILTER_SPECs in the list. When two FILTER_SPEC lists have the same number of elements, the included CRC becomes the only method for matching policy data and filter lists. The CRC algorithm is a matter for agreement between adjacent policy nodes, (like key management); however, a default hash/CRC (type 0) algorithm can be defined. When this option has a Shai Herzog Expiration: May 1997 [Page 6] Internet Draft RSVP Extensions for Policy Control November 1996 length of 8, no CRC is provided, and the list identification is limited to the counter value. 2.2.3 Options Constraints o The RSVP_HOP and INTEGRITY options are mutually exclusive since the INTEGRITY object already contains the sending- system address. If neither is present, the policy data is implicitly assumed to have been constructed by the RSVP_HOP indicated in the RSVP message itself (i.e., the neighboring RSVP node is policy-capable). o If present, the Fragmentation option should appear first. o If present, the NoChange option should appear first (after the Fragmentation option). o If present FILTER_SPEC objects must appear as one consecutive list (i.e., no more than one list in each POLICY_DATA object and its fragments). 3. RSVP/Policy Control Interface Policy control in RSVP is performed through a set of functions that regulate the use of POLICY_DATA objects and advise RSVP about the policy status of reservations. In this section, we describe these services as a set of functions, which conceptually belong in Section 3.10.3 titled "RSVP/Policy Control Interface" of the RSVP functional specification[RSVPSP]. Shai Herzog Expiration: May 1997 [Page 7] Internet Draft RSVP Extensions for Policy Control November 1996 3.1 Policy Control Services Before we discuss the functions themselves, let us describe some of their common parameters: The session and filter_spec_list describe the set of flows to which an outgoing policy applies. Parameters lih, rsvp_hop and message_type provide network/topology information, and resv_handle and resv_flowspec provide information about the current/desired level of reservation and traffic characteristics. o Process a received POLICY_DATA object Call: PC_InPolicy (session, lih, rsvp_hop, message_type, in_policy_objects, resv_handle, resv_flowspec, timeout) -> RCode Incoming policy objects are checked for syntax, and a policy admission decision takes place (i.e., PC_AuthCheck() is called internally). If successful, the reservation can be admitted. Otherwise, the reservation should be rejected in a manner similar to admission control failure. A reservation may be marked as preemptable, which means that admission control may cancel it at any time to make room for another more important reservation. (See the "TC_Preempt()" upcall and the discussion of service preemption in [RSVPSP].) The timeout parameter communicates the lifespan (in seconds) of the state contained in the input policy object. This value should be identical to the one used by RSVP to purge the state created by the RSVP message that carried the policy object. An authorization to establish reservations must always be performed on outgoing interfaces (lih). However, for messages arriving on incoming interfaces (e.g., Path) only the incoming lih is known, and therefore only an authorization for accepting the Path message could be checked. Since the policy status of a reservation may change upon receiving an incoming Path message, RSVP should either perform individual "PC\_AuthCheck()" calls for each of its outgoing interfaces, or wait until the reservation refresh timer goes off. o Request an outgoing POLICY_DATA object Call: PC_OutPolicy (session, filter_spec_list, lih, rsvp_hop, message_type, out_policy_objects, max_pd, avail_pd) -> RCode Shai Herzog Expiration: May 1997 [Page 8] Internet Draft RSVP Extensions for Policy Control November 1996 Before RSVP finalizes an outgoing control message it must query the PC module for policy data objects. RSVP specifies the desired maximal object size ("max_pd"), and the available space within the current RSVP control message ("avail_pd"). [Note 3] The call returns a linked list of outgoing POLICY_DATA objects which must be sent by RSVP either embedded in the current RSVP message, or in separate ones (see Section 4). In the case of Path messages, the rsvp_hop parameter should be NULL. The outgoing policy object must include policy information for all the next hops over interface lih. o Check the status of an existing reservation Call: PC_AuthCheck (session, filter_spec_list, lih, message_type, resv_handle, resv_flowspec, ind) -> RCode Authorization checks can be performed on both Path and Resv directions. When the message_type is an upstream type (Resv, Resv Tear, Path Err) the lih is assumed to be an outgoing interface and reservation status is checked. However, when the message_type is an downstream type (Path, Path Tear, Resv Err), the lih is assumed to be an incoming interface and Path-sending authorization is checked. Authorization checks are usually event triggered by the arrival of a new message; these are handled transparently by the input processing call PC_InPolicy(). However, RSVP itself must verify the status of reservations periodically before refreshing them by calling PC_AuthCheck() with RSVP_RESV message type, for each _________________________ [Note 3] "avail_pd" must be at least the size of a POLICY_DATA object without a data portion (i.e., 64 bits), since this is a minimal size of any valid policy object. Shai Herzog Expiration: May 1997 [Page 9] Internet Draft RSVP Extensions for Policy Control November 1996 outgoing reserved interface. If the reservation status changes, RSVP must act accordingly (e.g., cancel the reservation, etc.). o Initialize Policy Control services Call: PC_Init (void) -> RCode o Synchronize RSVP and policy control state Call: PC_Branch (session, filter_spec_list, rsvp_hop, op_type) -> RCode This call affects all the state associated with a particular multicast (or unicast) branch. It is used when routing indicates that this path is no longer in use, or when blockade state changes. "op_type": 1: Block branch (blockade state: ignore branch state) 2: Unblock branch 3: Delete branch o Delete policy control state Call: PC_Close (session, filter_spec_list) -> RCode This call purges all the policy state that is associated with the filter_spec_list. It provide the PC module with the opportunity to shut-down on-going operations (e.g., accounting) in an orderly manner before the state is purged. 3.2 PC Success Codes The return code (RCode) provides policy feedback to RSVP, it is made of three separate return variables: [Note 4] _________________________ [Note 4] This is only an initial list, we expect that part to change as policy control matures. Shai Herzog Expiration: May 1997 [Page 10] Internet Draft RSVP Extensions for Policy Control November 1996 o Function return value: 0: Success 1: Warning 2: Syntax Error (bad object) 3: Policy failure o "PC_errno": An external variable (similar to the "errno" in Unix) which provides specific error (reason) code. o "PC_flags": An external variable with flags that advise RSVP about required operations: 0x01 PC_RC_ModState New or modified policy 0x02 PC_RC_SendErr Send immediate RSVP error 0x04 PC_RC_Respond Send immediate RSVP response 0x08 PC_RC_Cancel Cancel the reservation 0x10 PC_RC_Preempt Allow preemption of flow 3.3 PC Codes: Required Action by RSVP The PC success codes, and especially "PC_Flags" advise RSVP about appropriate required actions: 3.3.1 Refreshing Policy State When flag PC_RC_ModState is set, RSVP must immediately send a refresh message. If RSVP schedules an immediate refresh anyway (i.e., because of new or modified Path/Resv state) then the modified policy can be piggybacked on this refresh message. Otherwise, RSVP should either schedule an immediate refresh or send the policy refresh in a vacuous message (see Section 4). 3.3.2 Policy Error Signaling Policy errors are reported inside POLICY_DATA objects and is transparent to RSVP. The PC module is responsible for generating the right contents in outgoing policy error objects and interpreting the incoming ones. Generic error signaling involves the following steps: o While in PC_AuthCheck() or PC_InPolicy(), the PC module Shai Herzog Expiration: May 1997 [Page 11] Internet Draft RSVP Extensions for Policy Control November 1996 detects an error, and reports it to RSVP using a return code. o RSVP performs its standard error handling, by initiating either a PathErr or ResvErr message. o Before sending the error message, RSVP queries the PC module for an outgoing object PC_OutPolicy(). o The PC modules provides an outgoing object with specific error information. (Setting flag PC_RC_SendErr). o RSVP sends the error message with the embedded (error) policy object. 3.3.3 RSVP Response When flag PC_RC_Respond is set, RSVP must generate a message in the reverse direction to the current one. (i.e., Path vs. Resv and PathErr vs. ResvErr). The reverse message may be a standard one. It may also be a vacuous message if no RSVP state need be transmitted in the reverse direction at this time. A common case for such a response is when an acknowledgment for some specific policy is required. 3.4 Default Handling of Policy Data Objects It is generally assumed that policy enforcement (at least in its initial stages) is likely to concentrate on border nodes between autonomous systems. This would mean that policy objects transmitted at one edge of an autonomous cloud may need to traverse a non-policy-capable, RSVP cloud before reaching the other edge. The minimal requirement from a non-policy-capable RSVP node is to forward POLICY_DATA objects embedded in the appropriate outgoing messages, as-is (without modifications) according to the following rules: o POLICY_DATA objects are to be forwarded as is, in RSVP messages with the same type as the ones with which they arrive. o POLICY_DATA objects may be syntactically fragmented at any time to fit inside the outgoing message. [Note 5] _________________________ [Note 5] The available space in an outgoing message may be smaller than in the incoming message due to state merging, change of MTU or other reasons. Shai Herzog Expiration: May 1997 [Page 12] Internet Draft RSVP Extensions for Policy Control November 1996 [Note 6] [Note 7] o Multicast merging (splitting) nodes: In the upstream direction, POLICY_DATA objects are concatenated into a merged list. If the list is too large it is up to RSVP to fragment the outgoing message. [Note 8] 4. Syntactic Fragmentation of large Policy Data objects RSVP's extensions for policy control provide support for a wide range of policies; at least in the initial phases, we could assume that they would be limited to very basic policies, carried by small size POLICY_DATA objects. However, we it is important to ensure that our approach would be capable of handling policies that are more complex, and of large sizes. In the current version of the RSVP spec [RSVPSP], each RSVP message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the recipient node. Future versions of the RSVP protocol may provide more flexible solutions; the most likely direction will be to perform "semantic fragmentation" (see Section 3.2 in [RSVPSP]). Unfortunately neither the current or proposed fragmentation solutions would be adequate for policy objects; When using IP fragmentation, large POLICY_DATA objects would increase the overall RSVP message size, the number of fragments, and as a result, the risk of loosing complete RSVP messages. Even if RSVP adopts a future proposal for semantic fragmentation, it is hard to see how POLICY_DATA objects, being semantically opaque, could be fragmented effectively by RSVP. If the prevailing goal is to have as little as possible adverse _________________________ [Note 6] The minimal POLICY_DATA object size is 64 bits (without the data portion). Bigger objects are considered as complete objects that may be fragmented. [Note 7] Syntactic fragmentation is achieved by breaking the object into two asymmetric objects: the full size POLICY_DATA object and a token object. The full size object will undergo IP fragmentation (see [LPM]). [Note 8] Notice here that because this is a set of semantically independent POLICY_DATA objects, RSVP can fragment the list effectively. Shai Herzog Expiration: May 1997 [Page 13] Internet Draft RSVP Extensions for Policy Control November 1996 effect on RSVP, fragmentation and reassembly of POLICY_DATA objects should be separated from RSVP. We introduce a third approach called "syntactic fragmentation". With this approach, RSVP would be aware of the syntax but not the semantics of policy fragmentation. (A detailed fragmentation discussion can be found in [LPM].) The basic building blocks of syntactic fragmentation are: Vacuous RSVP Messages Vacuous RSVP messages are a method for using RSVP signaling to carry policy information without jeopardizing important RSVP state. Vacuous messages carry fragments and only the minimal RSVP information that is required to properly route and process these messages; however, any information contained in them is merely a duplicate of information sent by other non-vacuous RSVP messages. As a result, a lost vacuous message has no adverse effect on RSVP's signaling. POLICY_DATA fragments A POLICY_DATA object is broken into a series of fragments PD_1, ..., PD_n, PDE, where all the fragments are conceptually linked by having the same OID value in their header. The OID serves a similar purpose to IPv6's Fragment Identification field in the Fragment header; its value should be selected in a way that will prevent two instances of policy objects (of the same session and RSVP_HOP) from having the same OID value. OID selection is a responsibility of the sending node, and can be achieved by various strategies. A possible approach could be to use the low 16 bit value in seconds of the Real-Time system clock. [Note 9] Objects PD_1,...,PD_n contain policy data fragments, and the Fragmentation option. PDE is a special token object with a minimal size (64 bit header only). The "PDE"'s minimal size allows it to be embedded in the standard outgoing RSVP control message, while the other fragments must be sent by separate "vacuous" RSVP messages. Sending Fragments _________________________ [Note 9] Using the system clock provides protection against system crash/recovery problems. Such OID values would wraps around only after 2^16 seconds (over 8 hour) which is enough to guarantee that all old fragments have either been timed-out or lost. Shai Herzog Expiration: May 1997 [Page 14] Internet Draft RSVP Extensions for Policy Control November 1996 Prior to sending an RSVP message M of type RSVP_XXXX, RSVP calls PC_OutPolicy() to obtain the list of outgoing POLICY_DATA objects. For efficient processing, fragment objects must appear first on this list. If the list contains any fragment objects, RSVP halts its normal processing to send these fragments in vacuous RSVP_XXXX messages. Once these fragments have been sent, RSVP continues its regular processing by placing the PDE objects in M, and sending the standard RSVP_XXXX message out. In some cases, multiple PDE objects (PDE_1...PDE_k) may be embedded in the outgoing message M. However, if their overall size exceeds the available space in the outgoing message, RSVP could apply its own fragmentation rules, but should never send them in vacuous messages (whose sole function is to carry fragments). Receiving Fragments On the receiving side, when an RSVP message arrives with a POLICY_DATA object with a fragmentation option, it should be handed over to the PC module (using PC_InPolicy()) regardless of the success of the RSVP message- syntax checks or policy control return codes. Token objects do not contain the fragmentation option, and therefore are indistinguishable (to RSVP) from unfragmented ones. 5. API Considerations Section 3.10.1 in [RSVPSP] defines the Application/RSVP interface. Because the API design is operating system specific, this section should be only considered as a suggestion. Supporting policy control requires the following considerations: o The SENDER and RESERVE calls accept policy data parameters. There are at least two different approaches for providing these parameters: the first places the burden on applications (or their proxy servers) to build complete POLICY_DATA objects and pass them as API parameters. The second require that applications merely provide general guidelines that are later converted to POLICY_DATA by the API processing code. We recommend using hybrid approach where applications provide partial POLICY_DATA objects through the API, and API processing adds additional, system related information (e.g., INTEGRITY object, FILTER_SPEC list, etc.). This hybrid approach provides applications with the flexibility to specify new policy parameterization without having to change the API, and at the Shai Herzog Expiration: May 1997 [Page 15] Internet Draft RSVP Extensions for Policy Control November 1996 same time relieves applications from the burden of specifying routine, system related details. o State merging at the API level should be handled with care; It is essential that each API client (application) have its own separate state. An analogy to shared medium may be appropriate: to distinguish between reservations over a shared medium, RSVP maintains reservation state for each outgoing interface, as well as individual next hops. In the API case, local clients may be perceived as all belonging to a single virtual interface (local-host) however, each of them is subscribed with a separate upcall procedure address ("next-hop"). 6. Acknowledgment This document incorporates inputs from Lou Berger, Bob Braden, Deborah Estrin, Roch Gu'erin and Scott Shenker, and feedback from many RSVP collaborators. References [Bak96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", draft-ietf-rsvp-md5-02.txt, 1996. [RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. "Internet-Draft", draft-ietf-RSVPSP-14.[ps,txt], Nov. 1996. [LPM] S. Herzog Local Policy Modules (LPM): Policy Enforcement for Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp- policy-lpm-01.[ps,txt], Nov. 1996. [Arch] S. Herzog Accounting and Access Control Policies for Resource Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy- arch-01.[ps,txt], Nov. 1996. Author's Address Shai Herzog IBM T. J. Watson Research Center, P.O. Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-6059 Email: herzog@watson.ibm.com Shai Herzog Expiration: May 1997 [Page 16]