Internet Draft Shai Herzog
Expiration: December 1996 USC/ISI
File: draft-ietf-rsvp-policy-arch-00.txt
Accounting and Access Control Policies
for
Resource Reservation Protocols
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 provides insight into some possible generic approaches for
policy enforcement in resource reservation protocols. We present
sample scenarios for each of these approaches as a way to demonstrate
their feasibility, and to motivate the development of supporting
architectures.
Shai Herzog Expiration: December 1996 [Page 1]
Internet Draft Policies for Reservation Protocols June 1996
1. Introduction
Reservation protocols, by definition, discriminate between users, by
providing some users with better service at the expense of others.
Therefore, it is reasonable to expect that these protocols be
accompanied by mechanisms for controlling and enforcing access and
usage policies. In this document, we refer to such policies as
"access control". The term "access control" is quite broad; it
ranges from simple access approval to sophisticated accounting and
debiting mechanisms For scaling reasons, we concentrate on policies
that follow the bilateral agreements model. The bilateral model
assumes that network clouds (providers) contract with their closest
point of contact (neighbor) to establish ground rules and
arrangements for access control and accounting. These contracts are
mostly local and do not rely on global agreements. The bilateral
model has similar scaling properties to multicast and is easier to
maintain in distributed environments.
Throughout this document we would use the terms "reservation
protocols" and RSVP interchangeably. However, the contents of this
document should be interpreted as applying to similar resource
reservation protocols as well. The current admission process in RSVP
uses resource (capacity) based admission control; we expand this
model to include policy based admission control as well, in one
atomic operation. Policy admission control is enforced locally at
border/policy nodes (also see~[HER96a]). Policy nodes are responsible
for receiving, processing, and forwarding POLICY_DATA objects. Subject
to the applicable bilateral agreements, and local policies, policy
nodes may also rewrite and modify the POLICY_DATA objects as the pass
through policy nodes.
In this document, we outline a few sample scenarios for access
control and accounting; we provide these scenarios as motivation and
as needed context for the development of policy control architectures
for resource reservation protocols. These scenarios are based on two
simple assumptions: (1) RSVP provides the needed transport service
of carrying access control state (POLICY_DATA objects), hop-by-hop.
(2) Access control policies are enforced locally, and can be based,
among other factors, on bilateral agreements between neighboring
providers, local policies and the contents of POLICY_DATA objects.
2. Simple access control
To provide simple access control, the local node attempts to match
incoming policy objects with one or more of the pre-configured
policies or bilateral agreements, in order to accept or reject the
reservation.
Shai Herzog Expiration: December 1996 [Page 2]
Internet Draft Policies for Reservation Protocols June 1996
Consider the following network scenario: one receiver from ISI and
two from MIT listen to a PARC seminar. For simplicity of the
scenario, let us limit ourselves to a receiver based access control
scenario.
........... .............
. *ba* . *ba* . .
. S1------->A--------------->B---+ *mc* .
. . . | .
........... ...C.........
PARC / BARRNet
*mc* /
/
........ .............D..... ........
. . . *ln+ne* / . . .
. *is* . *ln* . / . *ne* . *mi* .
. +----G------F<--------E-------->J------->K----+ .
. | . . *ln* *ne* .| . | .
...H.... ................. | ....L...
Los | MCINet | | Near
Nettos| *is* *sp* / *mi* | Net
.......I.... / .......M...
. | . ......N.. .*r2*/ \*r3*.
. *r1*| . . *r4*| . . / \ .
. R1 . . R4 . . R2 R3 .
............ ......... ...........
ISI Sprint MIT
LEGEND:
*xx* Credential
.... Cloud border
A..N Nodes
Si Sender i
Ri Receiver i
Figure 1: Simple access control
The bilateral agreements between each two neighboring providers
(e.g., R1, R2 with ISI, ISI with LosNettos,... BARRNet with PARC) are
simple: the first provider obtains a permission to make reservations
over the second provider's network. The notation PD(cr,uid)
represents a policy data object of type "cr" (credential) verifying
that the flow belongs to uid. Credentials can be hierarchical, and
may be rewritten on a hop by hop basis through a locally configured
Shai Herzog Expiration: December 1996 [Page 3]
Internet Draft Policies for Reservation Protocols June 1996
conversion table.
Figure illustrates a reservation scenario. An typical example of a
bilateral agreement could be between MCI and LosNettos: MCI would
allow the LosNettos users to use its backbone. A policy data object
PD(cr, LosNettos) would be interpreted by MCI as a green light to
accept the reservation. In this scenario, reservations from R1, R2,
R3 carry policy data objects that propagate hop-by-hop (encapsulated
in reservation messages) toward S1. Assuming all nodes are
configured consistently, policy objects are rewritten in nodes
B,D,G,I,K,M, which are entry points to clouds).
The MCI cloud is interesting. E is not a border/policy node, but
still, it receives the following policy data objects: F->E:
PD(cr,LosNettos) and J->E: PD(cr,NearNet). Assuming E has no
authority to merge or rewrite these credentials, it must concatenate
the two objects and send PD(cr,LosNettos) + PD(cr,NearNet) to D. Let
us further assume that D is configured with the following conversion
table:
PD(cr, LosNettos) -> PD(cr, MCI)
PD(cr, NearNet) -> PD(cr, MCI)
Node D first checks if LosNettos and NearNet are authorized to
reserve on their corresponding links and responds accordingly.
Assuming authorization is cleared, it merges and rewrites these
policy objects as PD(cr, MCI) and forwards the reservation to C.
To complicate the example, assume the conversion table was:
PD(cr, LosNettos) -> PD(cr, MCI1)
PD(cr, NearNet) -> PD(cr, MCI2)
Then node D would forward PD(cr, MCI1) + PD(cr, MCI2) to C instead.
Local policies can also reject reservations:
In figure we see that a reservation made by R4 is rejected because
it arrives with insufficient credentials: the local policy in node J
accepts only traffic marked as PD(cr, NearNet), and R4's reservation
arrives with PD(cr, Sprint).
3. Advanced reservation and preemption control
Advanced reservation can be built on top of simple access control:
consider the case where every advanced reservation consists of a set
of bilateral agreements between different service providers,
reserving network capacity at some future period of time. When
Shai Herzog Expiration: December 1996 [Page 4]
Internet Draft Policies for Reservation Protocols June 1996
advanced reservations are not public (i.e., only authorized users can
use them), three classes of reservations exist: (1) walk-ins (where
the conference itself does not have advanced reservations, (2)
advanced reservation with unauthorized users, and (3) advanced
reservation with authorized users. These numbers (1..3) can define a
"preemption priority" (i.e., walk-ins are preempted first,
unauthorized pre-reserved second, and authorized pre-reserved are
never preempted).
The advanced reservation scenario is almost identical to the simple
access control: let us assume that each bilateral pre-registration is
identified by a PRID (Pre-Registration confirmation ID). Policy data
objects of type AR (Advanced Reservation) would take the following
form: PD(ar, prid ,uid). When an AR object arrives, the local node
verifies the existence of pre-reservation prid, and checks that uid
is permitted to use it. Finally, the flow is classified to one of the
above three preemptive priorities and RSVP is notifies.
4. Quota enforcement/accounting/debiting
The next step is to allow for more sophisticated access control that
is based on usage feedback. Here we add two additional mechanisms
which (1) determine how much should be debited for a reservation and
(2) what debiting mechanism should be used (if any). The following
scenarios assume a pre-existing set of local accounts. These accounts
are established by bilateral agreements that pre-purchase network
capacity and set applicable debiting rules. The role of accounting
mechanism is to verify the availability of funds/quotas in these
accounts for maintaining the reservation. We consider several
accounting schemes and briefly describe three: simple debiting,
limited debiting, Edge Pricing, and MultiCost (MCost).
Simple debiting
Consider the following example: lets assume that LosNettos and
Nearnet each have a debit account (pre-purchased capacity) with MCI
for their traffic. When node E receives the following
PD(cr,LosNettos) and PD(cr,NearNet) for flow f, it must decide the
following: (1) How much should be debited for flow f, and (2) how
would that debit be shared between the account of LosNettos and
NearNet. These are local configuration issues left for service
providers. In this scenario, the local node would attempt to perform
the debiting, and would notify RSVP on success or failure. The other
aspects of the scenario (Merging policy data objects and forwarding
them) is identical to that of simple access control.
Limited debiting (willingness to pay)
Shai Herzog Expiration: December 1996 [Page 5]
Internet Draft Policies for Reservation Protocols June 1996
Although we do not have a full understanding of the dynamics of
willingness-to-pay and its properties, we can outline the basic
scenario, as an extension of the simple debiting model. Willingness
to pay is manifested as a limit on the policy object that authorizes
the debit. For instance, PD(crwp,ISI,10% of unicast) would represent
a policy data object of type crwp (Credential, Willingness to Pay),
that authorizes debiting the ISI account up to 10% of the unicast
cost. Here, the basic idea is that market forces would be the driving
force behind what users specify as their willingness to pay.
Edge Pricing
Edge Pricing was presented in [SHE95]. This paradigm is based on the
assumption that network costs can be estimated and approximated at
the edge of the network, based on purely local information. Edge
Pricing is an extension of simple debiting: Edge Pricing can
determine how much is to be debited, and the set of credentials
associated with the reservation determines who (which account) should
be debited.
MultiCost (MCost)
MCost is an accounting scheme (and mechanism) that was introduced in
[HER95]. MCost has a unique feature: it takes into account the benefits
of sharing a multicast tree and distributes these savings among the
members of the multicast group, according to configurable policies,
basic fairness, and equality.
MCost computes the cost allocated to each user, and that cost can be
the basis for debiting. MCost can be combined with simple debiting in
a similar manner to Edge Pricing.
5. Acknowledgment
This document incorporates inputs from Deborah Estrin, Scott Shenker
and Bob Braden and feedback from RSVP collaborators.
References
[HER95] S. Herzog, S. Shenker and D. Estrin, Sharing the Cost of
Multicast Trees: An Axiomatic Analysis, "Proceedings of ACM/SIGCOMM
'95", Cambridge, MA, Aug. 1995
[HER96a] Local Policy Modules (LPM): Policy Enforcement for Resource
Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy-
lpm-00.[ps,txt].
[SHE95] S. Shenker, D. Clark, D. Estrin, and S. Herzog Pricing in
Shai Herzog Expiration: December 1996 [Page 6]
Internet Draft Policies for Reservation Protocols June 1996
Computer Networks: Reshaping the Research Agenda,
"Telecommunications Policy", Vol. 20, No. 1, 1996 also published in
"Proceedings of the Twenty-Third Annual Telecommunications Policy
Research Conference", 1995.
Shai Herzog Expiration: December 1996 [Page 7]