view Side-By-Side changes
Date: Tue, 09 Apr 2002 07:01:05 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 18 Mar 1998 02:31:00 GMT ETag: "2e7bb0-81bd-350f31e4" Accept-Ranges: bytes Content-Length: 33213 Connection: close Content-Type: text/plain Internet Draft Shai Herzog Expiration:Oct. 1998Apr. 1999 IPHighway File:draft-ietf-rap-rsvp-ext-00.txt Apr. 1998draft-ietf-rap-rsvp-ext-01.txt RSVP Extensions for Policy Control03/13/98November 18, 1998 Status of this Memo This document is anInternet-Draft. Internet-DraftsInternet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), itsareas,Areas, and itsworking groups.Working Groups. Note that other groups may also distribute working documents asInternet-Drafts. Internet-DraftsInternet Drafts. Internet Drafts are draft documents valid for a maximum of sixmonths andmonths. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It isinappropriatenot appropriate to useInternet-DraftsInternet Drafts as reference material or to cite them other than as a "working draft" or "work inprogress."progress". To learn the current status of any Internet-Draft, please check the"1id-abstracts.txt"1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories onds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),ftp.ietf.org, nic.nordu.net, ftp.isi.edu, ormunnari.oz.au (Pacific Rim).munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire at the expiration date listed above. Distribution of this draft is unlimited. Abstract This memo presents a set of extensions for supporting generic policy based admission control in RSVP.[Note 1]It should be perceived as an extension to the RSVP functional specifications [RSVPSP] These extensions include the standard format of POLICY_DATA objects,a generic RSVP/Policy-Control interface,and a description of RSVP's handling of policy events. This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in[COPS]. _________________________ [Note 1] This memo could be conceived as an extension to the RSVP functional specifications [RSVPSP]. Shai Herzog Expiration: Oct. 1998[Fwk, COPS, COPS-RSVP]. Internet Draft [Page 1] Internet Draft RSVPExtensionsExt. for Policy Control November 18, 1998 Table of Contents1 Introduction 3 2Abstract...............................................................1 Table of Contents......................................................2 1. Introduction........................................................3 2. Policy Data ObjectFormat 3 2.1Format...........................................3 2.1. BaseFormat ........................................... 4 2.2 Policy Data Options .................................... 4 2.2.1Format.......................................................4 2.2. Options...........................................................4 2.2.1.Native RSVPObjects as Policy Options ................... 5 2.2.2 Other Options .................................... 5 3 RSVP/Policy Control Interface 6 3.1 Synchronous vs. Asynchronous Policy Control ........... 6 3.2Options..............................................5 2.2.2.Other Options....................................................6 2.3. PolicyControl Services ................................ 7 3.3 PC Success Codes ....................................... 10 3.4 RSVP's Policy Actions ................................. 11 3.4.1 Pending Results and Asynchronous Notification ... 11 3.4.2Elements...................................................6 3. Processing Rules....................................................7 3.1. Basic Signaling...................................................7 3.2. ErrorSignaling ................................. 11 3.4.3 Policy Response ................................. 12 3.5Signaling...................................................7 3.3. DefaultHandling of Policy Data Objects ................ 12 4 Acknowledgment 13 ShaiHandling..................................................7 4. References..........................................................9 5. Acknowledgments.....................................................9 6. Author Information..................................................9 HerzogExpiration: Oct.et al. Expires June 1998 [Page 2] Internet Draft RSVPExtensionsExt. for Policy Control November 18, 1998 1. Introduction RSVP, byitsdefinition, 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 FunctionalSpecifications[RSVPSP]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. In this document we describe a set of extensions to RSVP for supporting policy based admission control aswell, in one atomic operation.well. The scope of this document is limited to theseextensions; a discussion of accountingextensions andaccess control policiesdoes not advocate specific architectures forresource reservation protocols can be found in [Fwk] and a descriptionpolicy based controls. For the purpose ofa router-serverthis document we define Local PolicyProtocol for these extensions canModule (LPM) as the policy entity within the RSVP node. This may befoundfully contained within the RSVP node or may be using an outsourcing mechanism such as described in[COPS].[Fwk, COPS, COPS-RSVP]. 2. Policy Data Object Format The following replaces section A.13 in [RSVPSP]. POLICY_DATA objects are carried by RSVP messages and contain policy information. All policy-capable nodes (at any location in the network) can generate, modify, or remove policyobjects in compliance with local policies. [Note 2] _________________________ [Note 2] Core nodes can add policy objects to RSVP messages,objects, even whennone was provided bysenders orreceivers. Most likely, this wouldreceivers do not provide, and may not even bebased on specific network topology properties (e.g., incoming port ID). Shaiaware of policy data objects. The exchange of POLICY_DATA objects between policy-capable nodes along the data path, supports the generation of consistent end-to-end policies. Furthermore, such policies can be successfully deployed across multiple administrative domains when border nodes manipulate and translate POLICY_DATA objects according to established sets of bilateral agreements. HerzogExpiration: Oct.et al. Expires June 1998 [Page 3] Internet Draft RSVPExtensionsExt. for Policy Control2.1November 18, 1998 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 | Flags | 0 (reserved)| +---------------------------+-------------+-------------+ | | // Option List // | | +-------------------------------------------------------+ | | // Policy Element List // | | +-------------------------------------------------------+ Data Offset: 16 bits The offset in bytes of the data portion (from the first byte of the object header). Flags: 8 bits 0x01 PCF_Updt A modified object, don't check against previousone 0x02 PCF_Fragmentone. This isa fragment of a PD objectan optimization for systems that attempt to detect unchanged refreshes of POLICY_DATA objects Reserved: 8 bits Always 0. OptionListList: Variable length The list of options and their usage is defined in Section 2.2. Policy ElementListList: Variable length The contents of policy elements is opaque toRSVP and its internal format is only known to the Local Policy Module (LPM). (SeeRSVP. See more details in Section3). Policy Elements have the following format: Shai Herzog Expiration: Oct. 1998 [Page 4] Internet Draft RSVP Extensions for Policy Control +-------------+-------------+-------------+-------------+ | Length | P-type | +---------------------------+---------------------------+ | | // Policy information (Opaque to RSVP) // | | +-------------------------------------------------------+ 2.2 Policy Data2.3. 2.2. Options This section describes a set of options that may appear as options in POLICY_DATA objects. All policy options appear as RSVP objects; some use their valid original format while others appear as NULL objects.2.2.1Herzog et al. Expires June 1998 [Page 4] Internet Draft RSVPObjects asExt. for Policy Control November 18, 1998 2.2.1. Native RSVP Options The following objects retain the same format specified in [RSVPSP] however, they gain different semantics when used inside POLICY_DATA objects. FILTER_SPEC object (list) The set of senders associated with the POLICY_DATA object. If none is provided, the policy information is assumed to be associated with all the flows of the session. This option is only useful for WF or SE reservation styles, where merged reservations may have originally been intended for different subsets of senders. It can also be used to prevent “policy loops” in a manner similar to the usage of RSVP’s SCOPE object. Using this option may have significant impact on scaling and size of POLICY_DATA objects and therefore should be taken with care. Originating RSVP_HOPObject(s)The RSVP_HOP object identifies the neighbor/peerpolicy- capablepolicy-capable node that constructed the policy object. When policy is enforced at border nodes, peer policy nodes may be several RSVP hops away from eachother.other and the originating RSVP_HOP is the basis for the mechanism that allows them to recognize each other and communicate safely and directly. Ifanno RSVP_HOP objectfollows either an INTEGRITY or RSVP_HOP objects it identifiesis present, thedestinationpolicynode. [Note 3] If a destinationdata is implicitly assumed to have been constructed by the RSVP_HOPandindicated in theaddress ofRSVP message itself (i.e., thereceivingneighboring RSVP nodedo not match, the entire POLICY_DATA objectis_________________________ [Note 3] Thispolicy-capable). Destination RSVP_HOP A second RSVP_HOP object maybefollow the originating RSVP_HOP object. This second RSVP_HOP identifies the destination policy node. This is used to ensure the POLICY_DATA object is delivered tothetargeted policynode.nodes. It may be used to emulate unicast delivery in multicast Path messages. It may alsohelpshelp prevent using a policy object in other parts of the network (replay attack).Shai Herzog Expiration: Oct. 1998 [Page 5] Internet Draft RSVP Extensions for Policy Control ignored.On the receiving side, a policy node should ignore any POLCY_DATA that includes a destination RSVP_HOP that doesn’t match its own IP address. INTEGRITY Object The INTEGRITY object provides guarantees that the object was not compromised. It follows the rules from [MD5], and is calculated over theSESSION object,POLICY_DATA object, the SESSION object, and the message type field[Note 4](byte, padded with zero to 32 bit) as if they formed one continuousin-order message, without any alignment.in- Herzog et al. Expires June 1998 [Page 5] Internet Draft RSVP Ext. for Policy Control November 18, 1998 order message. This concatenation is designed to prevent copy and replay attacks of POLICY_DATA objects from other sessions, flows, message types or even other network locations.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). 2.2.22.2.2. Other Options All options that do not use a valid RSVP object format, should use the NULL RSVP object format with different CType values. This document defines only one such option, however, several other may be considered in future versions. (e.g., Fragmentation, NoChange, etc.). o Policy Refresh Multiplier Some policies may have looser timing constraints than RSVP, and therefore may allow for lower refresh frequency. If the Policy Refresh Multiplier option is present, policy is refreshed only once in "Multiplier" RSVP refreshes, for "Duplicates" times. +-------------+-------------+-------------+-------------+ | 8 |0NULL | 1 | +-------------+-------------+-------------+-------------+ | Multiplier | Duplicates |Reserve (0) |+-------------+-------------+---------------------------+_________________________ [Note 4] As it appears in RSVP's common header. Shai Herzog Expiration: Oct. 1998 [Page 6] Internet Draft RSVP Extensions for Policy ControlFor example, for "Multiplier=16" and "Duplicates=3", the policy should be refreshed on RSVP's refreshes number 1,2,3,16,17,18,...3. RSVP/Policy Control Interface Conceptually,Note: thissection belong to Section 3.10.3 titled "RSVP/Policy Control Interface" ofoption’s natural recovery time may be as long as Multiplier times the RSVPfunctional specification[RSVPSP]. Policy controlrefresh period. Hence, it should only be used inRSVP is modeled as a set of functions which are provided by a separate component known as Localconjunction with longer-term policies or topologies that can tolerate longer recovery time. 2.3. PolicyModule.Elements TheLPM controls the usecontents ofPOLICY_DATA objects and provides authorization information to RSVP. 3.1 Synchronous vs. Asynchronous Policy Control RSVP must routinely consult the LPM forpolicydecisions. The consultation can follow one of two models: Synchronous or Asynchronous. In the Synchronous model, when RSVP calls a particular service, it must block until the call is completed. (even if it takes substantial time). In the Asynchronous model, the call never blocks; delayed results are communicated back to RSVP through an upcall. The asynchronous modelelements isharderopaque tosupport, sinceRSVPmust be able to halt incomplete tasks, save their context, and complete them later, when results become available, however, it has significantly better scaling properties. Query results may be commonly delayed when policy decisions are performed by an external server (See [COPS]). Consider a case where an average query takes 10ms; a synchronous RSVP/policy implementation would be roughly limited to less than 100 unicast flows and even much less for multicast flows. Since the two models provide the same functionality,anddiffer only in performance; each RSVP implementationits internal format isfreeonly known toselect the model best fitting its needs. RSVP may choosethesynchronous model by specifying a NULL as a cdp parameter when calling a service. 3.2Local PolicyControl Services o Common Parameters The following is aModule (LPM). A list ofcommon parameters (shared by severalpolicycontrol functions. Shaielements code points (based on P-type) starting from 0, is registered with IANA. Local, Proprietary, and temporary P-Types can be used from the high end and down (2^16-1 and down). HerzogExpiration: Oct.et al. Expires June 1998 [Page7]6] Internet Draft RSVPExtensionsExt. for Policy Controlsession, filter_spec_list and shr_ind The set of flows to which the POLICY_DATA object applies, and an indication whether they are shared. rsvp_hop The peer policy node, as well as the local LIH connecting to it. The (rsvp_hop includes the local lih), message_type The direction and type of message that carried the POLICY_DATA object. resv_handle and resv_flowspec Information regarding the current/desired level of reservation and traffic characteristics. cbp and giveup_time A pointer (address) of the Control Block. RSVP provides this address when making service calls. This value is echoed back to RSVP with the completion notification upcall. Giveup_time is the maximal period RSVP is willing to wait; If results are still unavailable after this period, RSVP should receive an upcall with failure results (and timer-expired error). o Call: PC_InPolicy (message_type, rsvp_hop, session, shr_ind, filter_spec_list, in_policy_objects, resv_handle, resv_flowspec, refresh_period, cbp, giveup_time) -> RCode RSVP calls PC_InPolicy for all incoming messages; However, it is acceptable for implementations to turn off policy processing for messages other than Path and Resv, when they don't carry any POLICY_DATA objects. [Note 5] _________________________ [Note 5] It is highly desirable to authorize Tear and Error messages even when they don't carry policy objects. However, since the risk from Shai Herzog Expiration: Oct. 1998 [Page 8] Internet Draft RSVP Extensions for Policy Control The LPM verifies any incoming policy objects (if included) and provides an authorization decision. [Note 6] If the incoming message is authorized, RSVP continues its normal processing. If it is rejected, RSVP drops the message entirely (as if it was never received), and sends the appropriate error message (with a policy failure error code). With RSVP's soft-state management, the consequences of dropping the incoming message is that the existing state (Path or Resv) begins to age and would eventually time-out. [Note 7] Reservations may also be authorized with a warning which marks them as preemptable. A preemptable reservation may be canceled at any time by admission control to make room for another more important reservation. (See "TC_Preempt()" and the discussion of service preemption in [RSVPSP].) Parameter refresh-period has the same value and semantics as in RSVP. o Call: PC_OutPolicy (message_type, rsvp_hop_list, session, shr_ind, filter_spec_list, max_pd, avail_pd, cbp, giveup_time, out_policy_objects) -> RCode Before RSVP finalizes an any outgoing RSVP message it calls PC_OutPolicy() to prepare outgoing objects for the a specified flow. RSVP specifies the desired maximal object size ("max_pd"), and the available space within the current RSVP control message ("avail_pd"). [Note 8] _________________________ relaxed authorization is limited to denial of service for a single flow, the decision is left at the discretion of local administrators. [Note 6] To prevent code duplication, PC_AuthCheck() may be called internally. [Note 7] An incoming messages may fail authorization simply because it lacks a particular policy object which was lost in transit. This approach is consistent with RSVP's state management rules. [Note 8] "avail_pd" must be at least the size of a POLICY_DATA object without a data portion or the call would fail. Shai Herzog Expiration: Oct. 1998 [Page 9] Internet Draft RSVP Extensions for Policy Control The filter_spec_list includes the set of filters corresponding to the reserved sources. When the filter_spec_list includes multiple filters (either because of a shared reservation or an aggregated policy over multiple FF) individual outgoing hops may be associated with different sets of filter_specs. RSVP must build the filter_spec_list as a union of all filter_spec lists over all outgoing hops. (All reserved sources) The LPM computes individual per-hop filter_spec lists as the intersection of this list with the set of sources upstream to a specific previous hop. (Previous-hop information is obtained from incoming Path messages.) A NULL filter_spec_list represents "all" sources (i.e., WF). The call returns a list of outgoing POLICY_DATA objects for each rsvp_hop. o Call: PC_AuthCheck (message_type, session, shr_ind, filter_spec_list, resv_desc list, full_list_ind, cbp, giveup_time) -> RCode Parameter resv_desc provides a list of reservation descriptions. This description is made of three components: lih, resv_handle, and resv_flowspec. In the upstream direction (e.g., Resv) authorization may need to be checked on multiple LIHs (all reservations for a flow). In such cases, status queries can be perform separately for each LIH, once for all LIHs, or anything in between. full_list_indication must be set at the last of PC_AuthCheck() query of the series. [Note 9] Authorization can be verified on both the 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 _________________________ [Note 9] When policies are interdependent across LIHs (as when the cost is shared among downstream receivers), full_list_ind notifies the server that the list of reserved LIH is complete and that it can safely compute the status of these reservations. Shai Herzog Expiration: Oct. 1998 [Page 10] Internet Draft RSVP Extensions for Policy Control 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 triggered by the arrival of a new message; these are handled transparently by the input processing call PC_InPolicy(). In a synchronous, when an upcall mechanism is not supported, RSVP must verify the status of reservations before refreshing them. o Call: PC_Init (K, upcall,... ) -> RCode This call initializes the LPM and sets specific RSVP/policy configuration parameters. K is the soft-state multiplier for refresh-period (see [RSVPSP]) and upcall registers a routine that may be called by the LPM to notify RSVP on policy changes. (See next item) o Call: upcall (event_type, cbp, message_type, lih, rsvp_hop list, session, shr_ind, filter_spec_list, out_policy_objects, RCode) Event_type determines the original call type (if applicable). cbp is an echo of the cbp provided by RSVP when making the original call. RSVP may use this pointer to locate the original context of the call. RCode uses the same values specified in this document, as it would for the original calls. Notice that the upcall parameters are a superset of the parameters used by all the non-blocking PC calls. o Call: PC_DelState (message_type, rsvp_hop, session, filter_spec_list, op_type) -> RCode This call affects all the state associated with a particular multicast (or unicast) branch. It is used for route changes, blockade state other instantaneous state change performed by RSVP. When applicable parameters are NULL, an aggregate of the state is affected (across all values of the NULL-ed parameter). For example, PC_DelState(NULL, session, NULL, NULL, PC_delete) would purge all the policy state associated with "session". Shai Herzog Expiration: Oct. 1998 [Page 11] Internet Draft RSVP Extensions for Policy Control Parameter "op_type" is the requested type of state change: PC_Delete : Purge state. PC_Block : Blockade (ignore) state PC_Unblock: Unblock state. 3.3 PC Success Codes The return code (RCode) provides policy feedback to RSVP, it is made of three separate return variables: [Note 10] o Function return value: 0: Success The call was completed successfully. For PC_AuthCheck() and PC_InPolicy() it also signals the authorization of the RSVP operation (e.g., Reservation, Path, Tear, etc.) RSVP need not check the PC_flags or PC_errno. 1: Pending The requested results are delayed. Should these results become available or the giveup_time expires, the notification upcall would signal RSVP. 2: Warning Same as success except that there is a non-fatal warning and RSVP must check the PC_flags for further instructions. 3: Policy failure Policy authorization for the RSVP operation has failed. RSVP should invoke its standard error reporting mechanism (PathErr or ResvErr). o "PC_errno": _________________________ [Note 10] This is only an initial list, we expect that part to change as policy control matures. Shai Herzog Expiration: Oct.November 18, 1998[Page 12] Internet Draft RSVP Extensions for Policy Control 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 The incoming POLICY_DATA object contains an update. RSVP must immediately initiate update forwarding procedures. 0x02 PC_RC_Resp RSVP must immediately initiate a message. The type of requested message is placed in the PC_errno variable and corresponds to message type values in the RSVP common header. 0x04 PC_RC_Preempt Only for Resv incoming objects. RSVP should inform the local admission control that the reservation is of lower priority and can be preempted, if necessary. 3.4 RSVP'sPolicyActions The PC success codes, and especially "PC_Flags" advise RSVP about appropriate required actions. This section describes these actions in greater detail. 3.4.1 Pending Results and Asynchronous Notification For various reasonsElements have theLPM may need to consult an external entity (e.g., server) for partial policy processing. (For a description of a router/server protocol see [COPS]). For efficiency reasons, RSVP must not be forced to wait idly while external policy processing takes place. Instead, A configurable option permits calls to PC_AuthCheck() or PC_OutPolicy() to terminate with a "pending" return value whenever results are delayed (for any reason). Thefollowingsteps take place when RSVP receives a pending return value: Shai Herzog Expiration: Oct. 1998 [Page 13] Internet Draft RSVP Extensions forformat: +-------------+-------------+-------------+-------------+ | Length | P-Type | +---------------------------+---------------------------+ | | // PolicyControl o RSVP halts the current operation, saves its state (linkedinformation (Opaque to RSVP) // | | +-------------------------------------------------------+ 3. Processing Rules This sections describes thecbp),minimal required policy processing rules for RSVP. 3.1. Basic Signaling It is generally agreed that policy control should only be enforced for Path, Resv, PathErr, and ResvErr. PathTear andmovesResvTear and assumed not to require policy control based on two assumptions: First, that MD-5 authentication verifies that thenext task. o Once results are available or the giveup_time expires [Note 11] the LPM "wakes up" RSVP by calling the notification upcall. o The wakeup call provides results, context, andTear is received from thecbp (see Section 3.2). o RSVP resumessame node that sent thepreviously halted operationinitial reservation, anduses the provided context parameters as if they were returned by the original (previously pending) call. 3.4.2second, that it is functionally equivalent to that node holding-off refreshes for this reservation. 3.2. Error Signaling Policy errors are reported by either ResvErr or PathErr messages with a policy failure error code (specified in [RSVPSP]). Policy error message must include a POLICY_DATA object; the object contains details of the error type andreason. If none is provided, the error message should not be sent.reason in a P-Type specific format. If a multicast reservationfails,fails due to policy reasons, RSVP should not attempt to discover which reservation caused the failure (as it would do for blockade state). Instead, it should attempt to deliver the policy ResvErr to ALL downstreamhops. The LPM would limit the error distribution by providing outgoing objects only to "culprit" next-hops; if the LPM performs local repair [Note 12] it can preventhops, and have thefurther distribution of ResvErr or PathErr messages. TheLPM decide where messages shouldinternally implement blockade state style mechanism for similar reasons as RSVP (preventing an unauthorized reservation from forcing other valid reservations to fail). This document does not define this mechanism and assumes it would be policy-implementation specific. _________________________ [Note 11] If results are still unavailable at giveup_time, the answer is assumed to be failure (for AuthCheck) or no output (for OutPolicy). [Note 12] Local repair canbeperformed by substituting the failed POLICY_DATA object with a different one. Shai Herzog Expiration: Oct. 1998 [Page 14] Internet Draft RSVP Extensions for Policy Control 3.4.3 Policy Response The LPM can initiate an immediate outgoing RSVP message (Path, Resv, etc.) by setting the flag PC_RC_Response and providing the number of the requested RSVP message in the PC_errno variable. [Note 13]sent. This mechanismis useful when the appropriate RSVP message is either scheduled for a significantly later time, or not at all. Whenallows thePC_RC_Response flag is set, RSVP, should scheduleLPM to limit therequested outgoing message as if its refresh timer has expired; for non-refreshed messages like ResvErr, RSVP should act as if they were just received. This mechanismerror distribution by deciding which "culprit" next-hops should be informed. It also allowspolicies that require an immediate confirmationthe LPM to prevent further distribution of ResvErr or PathErr messages byscheduling a reverse-direction messageperforming local repair (e.g. substituting the failed POLICY_DATA object with aconfirmation POLICY_DATA object. 3.5different one). 3.3. Default Handlingof Policy Data ObjectsIt is generally assumed that policy enforcement (at least in its initial stages) is likely to concentrate on border nodes between autonomous systems. Consequently, policy objects transmitted at one edge of an autonomous cloud may traverse intermediatenon- policy-capablenon-policy- capable RSVP nodes. The minimal requirement from anon- policy-capablenon-policy-capable RSVP node is to forward POLICY_DATA objects embedded in the appropriate outgoingmessages, as-is (without modifications)messages according to the following rules: Herzog et al. Expires June 1998 [Page 7] Internet Draft RSVP Ext. for Policy Control November 18, 1998 o POLICY_DATA objects are to be forwarded as is,in the same type of RSVP messages in which they arrived.without any modifications. o Multicast merging (splitting) nodes: In the upstream direction:Applicable incomingWhen multiple POLICY_DATA objectsare concatenated, andarrive from downstream, thelist is forwardedRSVP node should concatenate all of them and forward them with theupstreamoutgoing (upstream) message. On the downstream direction:A copy of all applicableWhen a single incomingobjects isPOLICY_DATA object arrives from upstream, it should be forwarded_________________________ [Note 13] The value of the PC_errno corresponds(copied) tomessage type values in the RSVP common header. Shai Herzog Expiration: Oct. 1998 [Page 15] Internet Draft RSVP Extensions for Policy Control with eachall downstreammessage.branches of the multicast tree. The same rules apply to unrecognized policies (sub-objects) within the POLICY_DATA object. However, sincethatthis can only occur in apolicy-capablepolicy- capable node, it is the responsibility of the LPM and not RSVP. Herzog et al. Expires June 1998 [Page 8] Internet Draft RSVP Ext. for Policy Control November 18, 1998 4.AcknowledgmentReferences [Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. "A Framework for Policy Based Admission Control", Internet-Draft <draft-ietf-rap- framework-00.txt>, November, 1997. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", Internet-Draft <draft-ietf-rap-cops-02.txt>, Aug. 1998. [RSVPSP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", IETF RFC 2205, Proposed Standard, September 1997. [MD5] F. Baker. “RSVP Cryptographic Authentication" Internet-Draft, <draft-ietf-rsvp-md5-05.txt>, Aug. 1997. 5. Acknowledgments This document incorporates inputs from Lou Berger, Bob Braden, Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju Rajan,andScottShenker. It also reflects feedback from many other RSVP collaborators. References [MD5] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", draft-ietf-rsvp-md5-05.txt, Aug. 1997. [RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog,Shenker, Raj Yavatkar andS. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC 2205, Sep. 1997. [COPS] J. Boyle, R Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry. The COPS (Common Open Policy Service) Protocol "Internet-Draft", draft-ietf-rap-cops-01.txt, Mar. 1998. [Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. A Framework for Policy-based Admission Control "Internet-Draft", draft-ietf-rap-framework-00.txt, Nov. 1997. Author's Addressmany others. 6. Author Information ShaiHerzogHerzog, IPHighway2055 Gateway Place,Parker Plaza, Suite 1500 400San Jose, CA 95110 Phone: (408) 390-3045 Email:Kelby St. Fort-Lee, NJ 07024 (201) 585-0800 herzog@iphighway.comShaiHerzogExpiration: Oct.et al. Expires June 1998 [Page16]9] ----