draft-ietf-rap-rsvp-ext-00.txt   draft-ietf-rap-rsvp-ext-01.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: Oct. 1998 IPHighway Expiration: Apr. 1999 IPHighway
File: draft-ietf-rap-rsvp-ext-00.txt Apr. 1998 File: draft-ietf-rap-rsvp-ext-01.txt
RSVP Extensions for Policy Control RSVP Extensions for Policy Control
03/13/98 November 18, 1998
Status of Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its Areas, and
and its working groups. Note that other groups may also distribute its Working Groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet Drafts are draft documents valid for a maximum of six months.
and may be updated, replaced, or obsoleted by other documents at any Internet Drafts may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is not appropriate to use Internet Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as a "working draft" or
"work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific munnari.oz.au.
Rim).
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 Abstract
This memo presents a set of extensions for supporting generic policy This memo presents a set of extensions for supporting generic policy
based admission control in RSVP. [Note 1] based admission control in RSVP. It should be perceived as an extension
to the RSVP functional specifications [RSVPSP]
These extensions include the standard format of POLICY_DATA objects, These extensions include the standard format of POLICY_DATA objects,
a generic RSVP/Policy-Control interface, and a description of RSVP's and a description of RSVP's handling of policy events.
handling of policy events.
This document does not advocate particular policy control mechanisms; This document does not advocate particular policy control mechanisms;
however, a Router/Server Policy Protocol description for these however, a Router/Server Policy Protocol description for these
extensions can be found in [COPS]. extensions can be found in [Fwk, COPS, COPS-RSVP].
_________________________
[Note 1] This memo could be conceived as an extension to the RSVP
functional specifications [RSVPSP].
Internet Draft RSVP Extensions for Policy Control
Table of Contents Table of Contents
1 Introduction 3 Abstract...............................................................1
Table of Contents......................................................2
2 Policy Data Object Format 3 1. Introduction........................................................3
2. Policy Data Object Format...........................................3
2.1 Base Format ........................................... 4 2.1. Base Format.......................................................4
2.2. Options...........................................................4
2.2 Policy Data Options .................................... 4 2.2.1.Native RSVP Options..............................................5
2.2.2.Other Options....................................................6
2.2.1 RSVP Objects as Policy Options ................... 5 2.3. Policy Elements...................................................6
3. Processing Rules....................................................7
2.2.2 Other Options .................................... 5 3.1. Basic Signaling...................................................7
3.2. Error Signaling...................................................7
3 RSVP/Policy Control Interface 6 3.3. Default Handling..................................................7
4. References..........................................................9
3.1 Synchronous vs. Asynchronous Policy Control ........... 6 5. Acknowledgments.....................................................9
6. Author Information..................................................9
3.2 Policy Control 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.2 Error Signaling ................................. 11
3.4.3 Policy Response ................................. 12
3.5 Default Handling of Policy Data Objects ................ 12
4 Acknowledgment 13
Internet Draft RSVP Extensions for Policy Control
1. Introduction 1. Introduction
RSVP, by its definition, discriminates between users, by providing RSVP, by definition, discriminates between users, by providing some
some users with better service at the expense of others. Therefore, users with better service at the expense of others. Therefore, it is
it is reasonable to expect that RSVP be accompanied by mechanisms for reasonable to expect that RSVP be accompanied by mechanisms for
controlling and enforcing access and usage policies. Historically, controlling and enforcing access and usage policies. Historically,
when RSVP Ver. 1 was developed, the knowledge and understanding of 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 policy issues was in its infancy. As a result, Ver. 1 of the RSVP
Functional Specifications[RSVPSP] left a place holder for policy Functional Specifications[RSVPSP] left a place holder for policy
support in the form of POLICY_DATA objects. However, it deliberately support in the form of POLICY_DATA objects. However, it deliberately
refrained from specifying mechanisms, message formats, or providing refrained from specifying mechanisms, message formats, or providing
insight into how policy enforcement should be carried out. This insight into how policy enforcement should be carried out. This
document is intended to fill in this void. document is intended to fill in this void.
The current RSVP Functional Specification describes the interface to The current RSVP Functional Specification describes the interface to
admission (traffic) control that is based "only" on resource admission (traffic) control that is based "only" on resource
availability. In this document we describe a set of extensions to availability. In this document we describe a set of extensions to RSVP
RSVP for supporting policy based admission control as well, in one for supporting policy based admission control as well. The scope of
atomic operation. The scope of this document is limited to these this document is limited to these extensions and does not advocate
extensions; a discussion of accounting and access control policies specific architectures for policy based controls.
for resource reservation protocols can be found in [Fwk] and a
description of a router-server Policy Protocol for these extensions For the purpose of this document we define Local Policy Module (LPM) as
can be found in [COPS]. the policy entity within the RSVP node. This may be fully contained
within the RSVP node or may be using an outsourcing mechanism such as
described in [Fwk, COPS, COPS-RSVP].
2. Policy Data Object Format 2. Policy Data Object Format
The following replaces section A.13 in [RSVPSP]. The following replaces section A.13 in [RSVPSP].
POLICY_DATA objects are carried by RSVP messages and contain policy POLICY_DATA objects are carried by RSVP messages and contain policy
information. All policy-capable nodes (at any location in the information. All policy-capable nodes (at any location in the network)
network) can generate, modify, or remove policy objects in compliance can generate, modify, or remove policy objects, even when senders or
with local policies. [Note 2] receivers do not provide, and may not even be aware of policy data
objects.
_________________________
[Note 2] Core nodes can add policy objects to RSVP messages, even when
none was provided by senders or receivers. Most likely, this would be
based on specific network topology properties (e.g., incoming port ID).
Internet Draft RSVP Extensions for Policy Control 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.
2.1 Base Format 2.1. Base Format
POLICY_DATA class=14 POLICY_DATA class=14
o Type 1 POLICY_DATA object: Class=14, C-Type=1 o Type 1 POLICY_DATA object: Class=14, C-Type=1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 | | Length | POLICY_DATA | 1 |
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
| Data Offset | Flags | 0 (reserved)| | Data Offset | Flags | 0 (reserved)|
+---------------------------+-------------+-------------+ +---------------------------+-------------+-------------+
skipping to change at page 4, line 35 skipping to change at page 4, line 33
+-------------------------------------------------------+ +-------------------------------------------------------+
Data Offset: 16 bits Data Offset: 16 bits
The offset in bytes of the data portion (from the first The offset in bytes of the data portion (from the first
byte of the object header). byte of the object header).
Flags: 8 bits Flags: 8 bits
0x01 PCF_Updt 0x01 PCF_Updt
A modified object, don't check against previous one A modified object, don't check against previous one. This
0x02 PCF_Fragment is an optimization for systems that attempt to detect
This is a fragment of a PD object unchanged refreshes of POLICY_DATA objects
Reserved: 8 bits Reserved: 8 bits
Always 0. Always 0.
Option List Option List: Variable length
The list of options and their usage is defined in
Section 2.2.
Policy Element List The list of options and their usage is defined in Section 2.2.
The contents of policy elements is opaque to RSVP and Policy Element List: Variable length
its internal format is only known to the Local Policy
Module (LPM). (See Section 3).
Policy Elements have the following format: The contents of policy elements is opaque to RSVP. See more
details in Section 2.3.
Internet Draft RSVP Extensions for Policy Control 2.2. Options
+-------------+-------------+-------------+-------------+ This section describes a set of options that may appear as options in
| Length | P-type | POLICY_DATA objects. All policy options appear as RSVP objects; some
+---------------------------+---------------------------+ use their valid original format while others appear as NULL objects.
| |
// Policy information (Opaque to RSVP) //
| |
+-------------------------------------------------------+
2.2 Policy Data Options 2.2.1. Native RSVP Options
This section describes a set of options that may appear as options The following objects retain the same format specified in [RSVPSP]
in POLICY_DATA objects. All policy options appear as RSVP objects; however, they gain different semantics when used inside POLICY_DATA
some use their valid original format while others appear as NULL
objects. objects.
2.2.1 RSVP Objects as Policy 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) FILTER_SPEC object (list)
The set of senders associated with the POLICY_DATA object. The set of senders associated with the POLICY_DATA object. If none is
If none is provided, the policy information is assumed to provided, the policy information is assumed to be associated with all
be associated with all the flows of the session. the flows of the session.
RSVP_HOP Object(s) 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.
The RSVP_HOP object identifies the neighbor/peer policy- Originating RSVP_HOP
capable node that constructed the policy object. When
policy is enforced at border nodes, peer policy nodes may
be several RSVP hops away from each other.
If an RSVP_HOP object follows either an INTEGRITY or The RSVP_HOP object identifies the neighbor/peer policy-capable node
RSVP_HOP objects it identifies the destination policy that constructed the policy object. When policy is enforced at border
node. [Note 3] nodes, peer policy nodes may be several RSVP hops away from each other
and the originating RSVP_HOP is the basis for the mechanism that allows
them to recognize each other and communicate safely and directly.
If a destination RSVP_HOP and the address of the receiving If no RSVP_HOP object is present, the policy data is implicitly assumed
node do not match, the entire POLICY_DATA object is to have been constructed by the RSVP_HOP indicated in the RSVP message
_________________________ itself (i.e., the neighboring RSVP node is policy-capable).
[Note 3] This RSVP_HOP may be used to ensure the POLICY_DATA object is
delivered to the targeted policy node. It may be used to emulate
unicast delivery in multicast Path messages. It also helps prevent
using a policy object in other parts of the network (replay attack).
Internet Draft RSVP Extensions for Policy Control Destination RSVP_HOP
ignored. A second RSVP_HOP object may follow 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 to targeted policy
nodes. It may be used to emulate unicast delivery in multicast Path
messages. It may also help prevent using a policy object in other parts
of the network (replay attack).
INTEGRITY Object 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.
The INTEGRITY object provides guarantees that the object INTEGRITY Object
was not compromised. It follows the rules from [MD5],
and is calculated over the SESSION object, POLICY_DATA
object, and the message type field [Note 4]
as if they formed one continuous in-order message,
without any alignment. 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 The INTEGRITY object provides guarantees that the object was not
since the INTEGRITY object already contains the sending- compromised. It follows the rules from [MD5], and is calculated over
system address. If neither is present, the policy data is the POLICY_DATA object, the SESSION object, and the message type field
implicitly assumed to have been constructed by the (byte, padded with zero to 32 bit) as if they formed one continuous in-
RSVP_HOP indicated in the RSVP message itself (i.e., the order message. This concatenation is designed to prevent copy and
neighboring RSVP node is policy-capable). replay attacks of POLICY_DATA objects from other sessions, flows,
message types or even other network locations.
2.2.2 Other Options 2.2.2. Other Options
All options that do not use a valid RSVP object format, should All options that do not use a valid RSVP object format, should use the
use the NULL RSVP object format with different CType values. NULL RSVP object format with different CType values. This document
This document defines only one such option, however, several defines only one such option, however, several other may be considered
other may be considered in future versions. (e.g., in future versions. (e.g., Fragmentation, NoChange, etc.).
Fragmentation, NoChange, etc.).
o Policy Refresh Multiplier o Policy Refresh Multiplier
Some policies may have looser timing constraints than Some policies may have looser timing constraints than RSVP, and
RSVP, and therefore may allow for lower refresh frequency. therefore may allow for lower refresh frequency. If the Policy Refresh
If the Policy Refresh Multiplier option is present, policy Multiplier option is present, policy is refreshed only once in
is refreshed only once in "Multiplier" RSVP refreshes, for "Multiplier" RSVP refreshes, for "Duplicates" times.
"Duplicates" times.
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 8 | 0 | 1 | | 8 | NULL | 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Multiplier | Duplicates | Reserve (0) | | Multiplier | Duplicates |
+-------------+-------------+---------------------------+ +-------------+-------------+---------------------------+
_________________________ For example, for "Multiplier=16" and "Duplicates=3", the policy should
[Note 4] As it appears in RSVP's common header. be refreshed on RSVP's refreshes number 1,2,3,16,17,18,...
Internet Draft RSVP Extensions for Policy Control
For 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, this section belong to Section 3.10.3 titled
"RSVP/Policy Control Interface" of the RSVP functional
specification[RSVPSP].
Policy control in RSVP is modeled as a set of functions which are
provided by a separate component known as Local Policy Module. The
LPM controls the use of POLICY_DATA objects and provides
authorization information to RSVP.
3.1 Synchronous vs. Asynchronous Policy Control
RSVP must routinely consult the LPM for policy decisions. 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 model is harder to
support, since RSVP must 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, and differ
only in performance; each RSVP implementation is free to select
the model best fitting its needs. RSVP may choose the synchronous
model by specifying a NULL as a cdp parameter when calling a
service.
3.2 Policy Control Services
o Common Parameters
The following is a list of common parameters (shared by
several policy control functions.
Internet Draft RSVP Extensions for Policy Control
session, 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
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.
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.
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".
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.
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's Policy Actions
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 reasons the LPM 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).
The following steps take place when RSVP receives a pending
return value:
Internet Draft RSVP Extensions for Policy Control
o RSVP halts the current operation, saves its state (linked
to the cbp), and moves to the next 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, and the cbp
(see Section 3.2).
o RSVP resumes the previously halted operation and uses the Note: this option’s natural recovery time may be as long as Multiplier
provided context parameters as if they were returned by times the RSVP refresh period. Hence, it should only be used in
the original (previously pending) call. conjunction with longer-term policies or topologies that can tolerate
longer recovery time.
3.4.2 Error Signaling 2.3. Policy Elements
Policy errors are reported by either ResvErr or PathErr The contents of policy elements is opaque to RSVP and its internal
messages with a policy failure error code (specified in format is only known to the Local Policy Module (LPM). A list of policy
[RSVPSP]). Policy error message must include a POLICY_DATA elements code points (based on P-type) starting from 0, is registered
object; the object contains details of the error type and with IANA. Local, Proprietary, and temporary P-Types can be used from
reason. If none is provided, the error message should not be the high end and down (2^16-1 and down).
sent.
If a multicast reservation fails, RSVP should not attempt to Policy Elements have the following format:
discover which reservation caused the failure (as it would do
for blockade state). Instead, it should attempt to deliver the
policy ResvErr to ALL downstream hops. 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 prevent the further distribution of ResvErr or PathErr
messages.
The LPM should internally implement blockade state style +-------------+-------------+-------------+-------------+
mechanism for similar reasons as RSVP (preventing an | Length | P-Type |
unauthorized reservation from forcing other valid reservations +---------------------------+---------------------------+
to fail). This document does not define this mechanism and | |
assumes it would be policy-implementation specific. // Policy information (Opaque to RSVP) //
| |
+-------------------------------------------------------+
_________________________ 3. Processing Rules
[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 can be performed by substituting the failed This sections describes the minimal required policy processing rules
POLICY_DATA object with a different one. for RSVP.
Internet Draft RSVP Extensions for Policy Control 3.1. Basic Signaling
3.4.3 Policy Response It is generally agreed that policy control should only be enforced for
Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and assumed not
to require policy control based on two assumptions: First, that MD-5
authentication verifies that the Tear is received from the same node
that sent the initial reservation, and second, that it is functionally
equivalent to that node holding-off refreshes for this reservation.
The LPM can initiate an immediate outgoing RSVP message (Path, 3.2. Error Signaling
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]
This mechanism is useful when the appropriate RSVP message is Policy errors are reported by either ResvErr or PathErr messages with a
either scheduled for a significantly later time, or not at all. policy failure error code (specified in [RSVPSP]). Policy error message
When the PC_RC_Response flag is set, RSVP, should schedule the must include a POLICY_DATA object; the object contains details of the
requested outgoing message as if its refresh timer has expired; error type and reason in a P-Type specific format.
for non-refreshed messages like ResvErr, RSVP should act as if
they were just received.
This mechanism allows policies that require an immediate If a multicast reservation fails due to policy reasons, RSVP should not
confirmation by scheduling a reverse-direction message with a attempt to discover which reservation caused the failure (as it would
confirmation POLICY_DATA object. do for blockade state). Instead, it should attempt to deliver the
policy ResvErr to ALL downstream hops, and have the LPM decide where
messages should be sent. This mechanism allows the LPM to limit the
error distribution by deciding which "culprit" next-hops should be
informed. It also allows the LPM to prevent further distribution of
ResvErr or PathErr messages by performing local repair (e.g.
substituting the failed POLICY_DATA object with a different one).
3.5 Default Handling of Policy Data Objects 3.3. Default Handling
It is generally assumed that policy enforcement (at least in its It is generally assumed that policy enforcement (at least in its
initial stages) is likely to concentrate on border nodes between initial stages) is likely to concentrate on border nodes between
autonomous systems. Consequently, policy objects transmitted at autonomous systems. Consequently, policy objects transmitted at one
one edge of an autonomous cloud may traverse intermediate non- edge of an autonomous cloud may traverse intermediate non-policy-
policy-capable RSVP nodes. The minimal requirement from a non- capable RSVP nodes. The minimal requirement from a non-policy-capable
policy-capable RSVP node is to forward POLICY_DATA objects RSVP node is to forward POLICY_DATA objects embedded in the appropriate
embedded in the appropriate outgoing messages, as-is (without outgoing messages according to the following rules:
modifications) according to the following rules:
o POLICY_DATA objects are to be forwarded as is, in the same o POLICY_DATA objects are to be forwarded as is, without any
type of RSVP messages in which they arrived. modifications.
o Multicast merging (splitting) nodes: o Multicast merging (splitting) nodes:
In the upstream direction: In the upstream direction:
Applicable incoming POLICY_DATA objects are When multiple POLICY_DATA objects arrive from downstream, the
concatenated, and the list is forwarded with the RSVP node should concatenate all of them and forward them with
upstream message. the outgoing (upstream) message.
On the downstream direction: On the downstream direction:
A copy of all applicable incoming objects is forwarded When a single incoming POLICY_DATA object arrives from
_________________________ upstream, it should be forwarded (copied) to all downstream
[Note 13] The value of the PC_errno corresponds to message type values branches of the multicast tree.
in the RSVP common header.
Internet Draft RSVP Extensions for Policy Control
with each downstream message.
The same rules apply to unrecognized policies (sub-objects) within
the POLICY_DATA object. However, since that can only occur in a
policy-capable node, it is the responsibility of the LPM and not
RSVP.
4. Acknowledgment
This document incorporates inputs from Lou Berger, Bob Braden, The same rules apply to unrecognized policies (sub-objects) within the
Deborah Estrin, Roch Guerin, Dimitrios Pendarakis, Raju Rajan, and POLICY_DATA object. However, since this can only occur in a policy-
Scott Shenker. It also reflects feedback from many other RSVP capable node, it is the responsibility of the LPM and not RSVP.
collaborators.
References 4. References
[MD5] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", [Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. "A Framework for Policy
draft-ietf-rsvp-md5-05.txt, Aug. 1997. Based Admission Control", Internet-Draft <draft-ietf-rap-
framework-00.txt>, November, 1997.
[RSVPSP] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
Resource ReSerVation Protocol (RSVP) Version 1 Functional Sastry, A., "The COPS (Common Open Policy Service) Protocol",
Specification. RFC 2205, Sep. 1997. Internet-Draft <draft-ietf-rap-cops-02.txt>, Aug. 1998.
[COPS] J. Boyle, R Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry. [RSVPSP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
The COPS (Common Open Policy Service) Protocol "Resource Reservation Protocol (RSVP) Version 1 Functional
"Internet-Draft", draft-ietf-rap-cops-01.txt, Mar. 1998. Specification", IETF RFC 2205, Proposed Standard, September
1997.
[MD5] F. Baker. “RSVP Cryptographic Authentication" Internet-Draft,
<draft-ietf-rsvp-md5-05.txt>, Aug. 1997.
[Fwk] R. Yavatkar, D. Pendarakis, R. Guerin. 5. Acknowledgments
A Framework for Policy-based Admission Control
"Internet-Draft", draft-ietf-rap-framework-00.txt, Nov. 1997.
Author's Address This document incorporates inputs from Lou Berger, Bob Braden, Deborah
Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju
Rajan, Scott Shenker, Raj Yavatkar and many others.
Shai Herzog 6. Author Information
IPHighway
2055 Gateway Place, Suite 400
San Jose, CA 95110
Phone: (408) 390-3045 Shai Herzog, IPHighway
Email: herzog@iphighway.com Parker Plaza, Suite 1500
400 Kelby St.
Fort-Lee, NJ 07024
(201) 585-0800
herzog@iphighway.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/