2.7.11 RSVP Admission Policy (rap)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 31-Jul-98


T. O'Malley <timo@bbn.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:rap@iphighway.com
To Subscribe: majordomo@iphighway.com
In Body: subscribe rap
Archive: ftp://ftp.iphighway.com/pub/IETF/rap

Description of Working Group:

Recent work in the IETF has led to the development of standards for a QoS-enabled Internet. Through the efforts of the Integrated Services working group, data flows can describe their desired or required service to the network. RSVP carries the service requests into the network, where the acceptance of these QoS requests results in better network service to some flows, possibly at the expense of service to traditional best-effort flows.

In an open and public Internet (as well as large intranets), maintaining such service differentiation inherently depends on mechanisms capable of enforcing (or reporting) operational policy constraints. Towards this end, RSVP message formats contain a place-holder for policy data0 elements, which may contain information relevant to the network's decision to grant a reservation request.

Certain network elements may require assistance in the processing of these policy-data elements and, therefore, may communicate with one or more policy servers, entities which specialize in the making of policy decisions.

The purpose of the IPC working group is to establish a scalable policy control model for RSVP. The working group will specify a protocol for use among RSVP-capable network nodes and policy servers. This work will also require documentation of any extensions to RSVP which may be necessary in support of this policy control.

Documents produced by the working group must fully address all the security aspects of this type of protocol. In particular, theft and denial of service threats must be minimized.

In pursuit of these goals, the working group must expressly avoid specifying policy behavior. The judgment of specific policies is similarly beyond the scope of the working group. The working group will, however, specify mechanisms that allow for a wide variety of possible policies to be carried out.

Goals and Milestones:

Jul 98


Submit I-D framework document for policy control for RSVP to IESG for publication as a RFC.

Aug 98


Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a RFC

Jan 99


Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a RFC.


No Request For Comments

Current Meeting Report

RAP WG meeting - 8/27/98 (minutes reported by Andrew Smith)

Agenda bashing
DiffServ discussion moved to end of agenda.

Area Director
new co-chair Andrew Smith, subject to IESG approval
no direction to use DIAMETER

Updates to the COPS model - Shai Herzog:

Presented model - see slides. Emphasises Front-end/back-end split. We only talk about
the PEP/PDP protocol and content here. COPS and data representation are separated.
Should keep in mind the DiffServ/RSVP edge work (Bernet etc.) and RSVP/MPLS
ongoing work.

COPS-02 draft - David Durham:

See slides:
<A HREF="slides/rap-durham-slides-98aug/index.html" TARGET="_BLANK">COPS 02 Overview</A>.
COPS encapsulates RSVP objects without understanding them. Accounting support. Security
assumed using IPSEC or TCP security. Some changes made since the last interop testing -
new DECISION operation which handles both solicited and unsolicited responses, new
CONTEXT object, some improvements for indicating end of synchronisation operations,
some flags to help configuration mode, removed reference handle.

???: what is the purpose of getting accounting information back to policy server?

Durham: So that policy sever can export it into other accounting mechanisms.

???: what about multicast? Durham: Not an issue for COPS

Bernet: What about defining objects for DiffServ? Bradner: do this after current work
items are done.

COPS-RSVP usage - Shai Herzog: draft-ietf-rap-cops-rsvp-00.txt and

How to interprete RSVP objects and pack them into messages? Only need to notify
RSVP's Path, Resv, PathErr, ResvErr messages to PDP. No major changes have
occurred recently. Replacement RSVP objects - allows PDP to modify parameters in
sessions as a result of policy decisions e.g. replace MD5 keys etc. Report messages
allow notification of Commit/Delete decisions based on admission control.

Concept of multiple contexts for a decision-request (input, resource allocation, output):
can put all 3 in a single request if you want to. See example in slides:
<A HREF="slides/rap-herzog-cops-slides-98aug/index.html" TARGET="_BLANK">COPS usage for RSVP</A>

Multicast merged policy: this is quite complicated - example is in draft-ietf-rap-cops-
rsvp-00 which will get posted as an official draft real soon now. RSVP extensions
probably needs to be split - part goes to cops-rsvp and part back into the base RSVP specs.

Smith: for multicast, perhaps need to clarify what is protocol rules and which is just

COPS-RSVP Policy data for User Identity - Tim Moore:

See Slides. Securely identifies a user to an RSVP node in a secure manner. Allows
remapping of identity of user e.g. organisation identity at a router. Note that
certificates and Kerberos tickets are big - probably good to only put a single one in
each RSVP message. Open issues with multicast merging:

- Do you merge all the receiver user identities into the message? 3 choices: replace
users with a "network identity", generate a "group ID" or don't use the Identity
element, use existing integrity object for example.
- What if this happens before the policy check? Answer: deploy your policy server
before the merge point. Might need to change the RSVP Integrity draft to support
this - RSVP WG will probably make some fixes.

RSVP Preemption priority - Shai Herzog.
Preemption priority exists per reservation. How do you aggregate preemption priorities
with the requested QoS? RSVP says "merge to highest QoS". Leads to denial of service
(high QoS+low priority preempts >low QoS+high priority). 4 proposed solutions:

- Take priority of the highest QoS: killer reservation issues
- Take lowest priority: denial of service and instability
- Take highest priority: free riders + denial of service + instability
- Error - only allow homogeneous flows

There is no right answer - choose simple, flexible: define a COPS policy element to
tell router what to do so that PDP decides. Will write this up as a draft.


Boyle: do higher numbers mean higher priority? YES

Davie: MPLS? Wants to use priority to help auto-reroute of tunnels but keep stability
(see http://www.ietf.org/internet-drafts/draft-awduche-mpls-traffic-eng-00.txt). Will
investigate this.

Weiss: Who chooses relative priorities of multicast vs. unicast? PDP choice. Is there
an RSVP "you've been preempted by policy" error? Not yet, just ResvError for now.

Interoperability meeting - Raj Yavatkar.
Took place August 5-7th. See slides. Tested interop between servers and clients (5
implementations). Tested basic protocol operations. Vendors have announced products.
Future interoperability testing - Arun Sastry/Cisco will be hosting another interop
this Fall.

COPS for DiffServ - Fran Reichmeyer.

DS has no explicit signaling but might have a Bandwidth Broker generating such
requests (e.g. triggered by H.323 server). PDP needs to pass sufficient filter
information down to PEPs. No proposal here for BBs in different domains to talk to
each other. Propose a new client type "DiffServ Client". 2 objects, Install/Delete/
Enable/Disable operations.

Bernet - confusion about where COPS and RSVP fit in DS model - need to clarify
this in this draft.

Smith - there's nothing specific to DiffServ in the proposal.??? - What is the value of
going to a policy server, rather than a directory for example?

COPS-DS data objects - Keith McCloghrie.
Use SMI data format. Do not use SNMP protocol - see slides for comparison.

Elleson: do you think this definition language can be same for Policy BOF (e.g.
usable for LDAP)? Yes, probably.

Next Steps & Timetable - Tim O'Malley
4 documents on the agenda right now:

1. COPS Framework draft-ietf-rap-framework-00.txt- Tim O' and Raj will complete
this. Open issues: reasons why SNMP was avoided, change LDP to something
else e.g. "Local PDP".

2. Policy Extensions for RSVP draft-ietf-rap-rsvp-ext-00.txt - need this last called too.
Not sure if this is RAP's or RSVP's. Probably needs splitting.

3. COPS-RSVP document draft-ietf-rap-cops-rsvp-00.txt - comments needed: please
read it. Simpler multicast example needed.

4. COPS protocol draft-ietf-rap-cops-02.txt - WG last call after Orlando.

RSVP Pre-emption priority policy ojects will be written up by Shai and added to this
list. Will possibly add the COPS-DS (draft-ietf-rap-cops-ds-00.txt) and user identity
policy objects (draft-ietf-rap-user-identity -00.txt) work to RAP charter after
submitting base drafts.

Summary: Base protocol and RSVP extensions to support it are almost ready for last
call - some small clarifications still needed. 4 current documents: {COPS framework,
COPS base protocol, RSVP extensions for policy, COPS usage with RSVP} to be
forwarded together on standards track. Pre-emption Priority policy objects for RSVP
still needs to be written up as a draft (Herzog). Proposed DiffServ extension
framework - will work more on this after RSVP work is done (WG is chartered only
for RSVP right now). Extensions for User Identity policy objects for RSVP may
also be worked then.


COPS 02 Overview
COPS usage for RSVP
COPS Usage for Diff Serv
Second COPS Interop Event
COPS-DS Policy Data
RSVP Preemption Priority
Common Open Policy Service Quick Update

Attendees List

go to list