One document matched: draft-ietf-rsvp-policy-ext-00.txt
Internet Draft Shai Herzog
Expiration: December 1996 USC/ISI
File: draft-ietf-rsvp-policy-ext-00.txt
RSVP Extensions for Policy Control
June 12, 1996
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 RSVP extensions required to support
policy based admission control in RSVP. The contents of this document
should be considered as an extension to the RSVP functional
specifications document~[BRA96].
Shai Herzog Expiration: December 1996 [Page 1]
Internet Draft RSVP Extensions for Policy Control June 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 infantile stages. As a result, Ver. 1 of the
RSVP Functional Specifications[BRA96] 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
any insight about how policy enforcement should be carried out. The
current RSVP Functional Specification defines an admission decision
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~[HER96b] and a discussion of a prototype
mechanism for enforcing these policies can be found in~[HER96a].
We expect that this document would merge into the RSVP specification
document~[BRA96] as it matures.
2. Object Format
In this section we describe the internal format of two types of
policy objects. This section defines RSVP objects, and thus,
conceptually belongs with the RSVP spec, however, due to the early
stage and dynamic nature of this work, this unification is currently
deferred.
2.1 POLICY_DATA objects
+-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 |
+-------------+-------------+-------------+-------------+
| Flags | Reserved |
+-------------+-----------------------------------------+
| |
// FILTER_SPEC Objects (optional) ... //
| |
+-------------------------------------------------------+
| |
// POLICY_ELEMENT or {INTEGRITY,POLICY_ELEMENT} //
| objects (optional) ... |
| |
+-------------------------------------------------------+
Shai Herzog Expiration: December 1996 [Page 2]
Internet Draft RSVP Extensions for Policy Control June 1996
POLICY_DATA objects begin with the standard RSVP object header.
The header is followed by a 32 bit word, out of which the first
eight bits are used for flags and the rest is reserved for future
use. The only flag currently defined is PDF_REPORT. This flag
applies only to Resv messages, and if set, it informs RSVP that a
Resv-Report message is required. [Note 1]
Next comes an optional list of FILTER_SPEC. This list can
associate the policies included in the object with a set of
specific senders (flows). If no FILTER_SPEC objects are listed,
the policy is considered to be associated with the "all" the flows
of the session. The POLICY_DATA object ends with a list of
POLICY_ELEMENTs.
2.2 POLICY_ELEMENT objects
We introduce POLICY_ELEMENT as a new class of RSVP object. These
objects carry policy specific information, and their internal
representation is opaque to RSVP.
+-------------+-------------+-------------+-------------+
| Length | 20 | CType |
+---------------------------+-------------+-------------+
| Variable length opaque data |
+-------------------------------------------------------+
Individual POLICY_ELEMENT objects may be preceded by INTEGRITY
objects. In this document, we do not define the algorithm for
computing the INTEGRITY value. However, in order to guarantee that
the POLICY_ELEMENT object 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.
2.3 Semantic fragmentation of POLICY_DATA objects
POLICY_DATA objects may need to be fragmented since their size can
potentially exceed the size of the MTU by orders of magnitude.
Large objects mainly result from the concatenation of multiple
POLICY_DATA objects arriving from multiple previous hops.
Semantic fragmentation provides an excellent solution for this
case; if these objects are large as a result of concatenation, we
see no reason why the original, self contained objects could not
be forwarded individually. The relationship between these self
_________________________
[Note 1] This flag may become obsolete if/when a Report Request bit is
added to the Resv message format.
Shai Herzog Expiration: December 1996 [Page 3]
Internet Draft RSVP Extensions for Policy Control June 1996
contained objects is not trivial and usually depends on the
underlying policy. Consider the case where N receivers share a
reservation; in one access control policy, access may be granted
based on a sufficient subset, while in some accounting policies,
accurate results may depend on obtaining the complete set.
However, when fragments are lost we only have two options: one is
to use the received subset, and the other one is to drop the whole
message. These options should be preserved such that the policy
module would be aware of fragments (POLICY_DATA objects) loss, and
specific policies can choose their response to the loss. The
practical implications are that semantic fragmentation POLICY_DATA
objects turns out to be quite simple, using a single rule:
"A POLICY_DATA object consisting of a list of objects L can be
broken into N sub-lists (L_i), each creating an object
conceptually identical to the original one, [Note 2]
except that L_i replaces L in each object (i=1..N)."
This rule applies recursively; for example, consider the following
POLICY_DATA object:
[H,F,S_1,S_2,S_3,Pe_1,I_2,Pe_2,Pe_3]
Where H,F represent the header and flags. F_i represents a filter
for source i, Pe_j represent a POLICY_ELEMENT object j and I_j
represent an INTEGRITY object for Pe_j.
First, we fragment the source list, creating two objects:
[H,F,S_1,S_2,Pe_1,I_2,Pe_2,Pe_3], and [H,F,S_3,Pe_1,I_2,Pe_2,Pe_3]
Then we fragment the policy element list, creating four objects:
[H,F,S_1,S_2,Pe_1,Pe_3], [H,F,S_1,S_2,I_2,Pe_2],
[H,F,S_3, Pe_1,Pe_3], and [H,F,S_3,
I_2,Pe_2]
The result of this semantic fragmentation allowed us to replace a
single large object with four smaller ones, while maintaining
identical semantics. Semantic fragmentation imposes an added
burden on state management since the absence of a policy element
_________________________
[Note 2] Checksums, and similar values may change as a result of the
object split.
Shai Herzog Expiration: December 1996 [Page 4]
Internet Draft RSVP Extensions for Policy Control June 1996
is ambiguous; a missing policy information may be the result of an
actual change in the policy, or a result of a fragment loss. This
implies the need for a timeout mechanism for each {POLICY_ELEMENT,
FILTER_SPEC} object pair. Moreover, if one wanted to purge state
before the timeout period, a teardown mechanism would be required
as well.
Notice that we consider individual POLICY_ELEMENT objects to be
atomic and do not attempt to further fragment them. This decision
is based on our desire to keep things simple, and our believe that
at present, IP fragmentation should be sufficient for such
individual objects.
3. New RSVP message: Reservation Report
Irrespective of specific mechanisms or implementation, the basic
building blocks of access control and accounting must be bi-
directional in order to allow both source and receiver based
policies, and both advertising and feedback. Which RSVP messages
should encapsulate these upstream and downstream objects? The choice
for upstream message is natural; the reservation message. The
downstream direction, however, is more problematic: Path messages
flow downstream, but are routed according to the multicast group
membership, and therefore cannot accurately be delivered to a
specific next hop. [Note 3]
This makes Path messages less likely to be used for access control,
and especially for accounting.
We proposed a new RSVP message type: "Reservation Report" (Rept).
Reservation Report messages are sent unicast, downstream, according
to the Next_Hop object carried by Resv messages; although Reservation
Report messages follow the multicast tree, their unicast delivery
provides accurate delivery to the appropriate next hop nodes and only
to these nodes [Note 4]
Although we propose this new message for policy control, it may prove
useful for other, more general functions of the RSVP protocol. A
_________________________
[Note 3] The same problem existed for the original design of ResvErr,
until it was changed to a unicast delivery along the multicast tree.
[Note 4] Consider the case of multipoint links or network clouds: a
single copy of a Path message may be delivered to an unknown number of
next hops, while the copy of a Report message is guaranteed to reach
only the targeted node.
Shai Herzog Expiration: December 1996 [Page 5]
Internet Draft RSVP Extensions for Policy Control June 1996
reservation may have different forms of responses to it: A negative
response (ResvErr), a positive response (ack), and a more advanced
form of a Reservation Report, like the one proposed here. An
integrated approach may incorporate all three responses in the same
message type while leaving room for future types.
4. Default handling of policy data objects
It is generally agreed upon that policies may be enforced on a much
coarser resolution than RSVP deployment. We do not expect (or desire)
every RSVP node to function as a policy node, nor do we expect each
node to be able to recognize and handle all types of policies (i.e.,
both intranet and internet policies). The question is: what should be
RSVP's default handling of unrecognized POLICY_DATA objects ? We
consider two potential cases; first, when the RSVP node is not a
policy node at all, and second, when the incoming POLICY_DATA object
includes objects of an unknown type. Both cases are handled in a
similar manner: RSVP is required to stored and forward the set of
unknown object without any modification, merging or other
manipulation. Notice that the internal format of POLICY_DATA objects
is a list of POLICY_ELEMENT objects; If a node is a merging point in
the multicast tree, the default output is simply the concatenation of
the lists of incoming objects encapsulated in a single POLICY_DATA
object.
5. API modifications
The current version of the RSVP functional specification~[BRA96] is
silent about possible policy interaction between applications (end-
users) and the first hop RSVP node. Furthermore, it does not provide
guidelines for an API design that would be consistent with future
policy control mechanisms. For example, some policies (e.g.,
accounting) require RSVP to be able to relate an incoming message to
individual local receivers. (e.g., split incoming costs between the
local receivers). An API which is not designed to maintain
information about local receivers, but instead merges their state,
would be unable to support user-based accounting.
This section is a place holder for a more detailed API design that
will be developed in future versions of this document.
6. Acknowledgment
This document incorporates inputs from Deborah Estrin, Scott Shenker
and Bob Braden and feedback from RSVP collaborators.
Shai Herzog Expiration: December 1996 [Page 6]
Internet Draft RSVP Extensions for Policy Control June 1996
References
[BRA96] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin,
Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification. "Internet-Draft", draft-ietf-rsvp-spec-12.txt.
[HER96a] Local Policy Modules (LPM): Policy Enforcement for Resource
Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
lpm-00.[ps,txt].
[HER96b] Accounting and Access Control Policies for Resource
Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
arch-00.[ps,txt].
Shai Herzog Expiration: December 1996 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-22 23:34:50 |