2.7.11 RSVP Admission Policy (rap)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Jan-99


Andrew Smith <andrew@extremenetworks.com>
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: http://majordomo.iphighway.com/majordomo/archive/threads.html

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

RSVP Admission Policy WG (rap)

Minutes reported by Andrew Smith.

Current status - chair (see slides)

Documents on the agenda right now: done RAP and RSVP WG last calls, only editorial issues outstanding. Will forward to IETF last call real soon.
1. RAP framework - Informational. Needs editorial spin (ed. since completed as -02 draft).
- http://www.ietf.org/internet-drafts/draft-ietf-rap-framework-02.txt.

2. COPS Protocol - Standards' track
- http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-06.txt

3. COPS for RSVP - Standards' track.
- http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-rsvp-04.txt

4. Policy Extensions for RSVP. Standards' track.
- Has had editorial spin after RSVP WG comments but needs another week for RSVP WG review.
- http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-ext-05.txt

5. Preemption Priority policy objects for RSVP. Standards' track.
- http://www.ietf.org/internet-drafts/draft-ietf-rap-signaled-priority-03.txt

6. Identity representation for RSVP. Standards' track.
- http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-identity-03.txt
- Publication of these would fulfill existing RAP charter.

IP Addressing assumptions in COPS - Dave Durham/Intel (see slides)

How does COPS work in the presence of NAT and lack of transparency in IP addressing? COPS is fairly well set up. Only area where we depend on IP addressing is in "PDP Redirect" operation. We have added a TCP port number field here to allow {IP, TCPport} as addressing for PDP - works for port-substitution NATs). Another solution is to use DNS FQDN instead of IP addresses - this is more complex than necessary for simple deployments: might want to add this later on. Right now we support only PEP and PDPs in same domain.

New work - Andrew Smith/Extreme

- Proposal for a COPS client MIB (draft-smith-cops-client-mib-00.txt). Adopted as basis of WG item. See slides.
- Proposal for RSVP/SBM configuration (draft-smith-sbm-config-00.txt), including configuration of policy rules there. This work belongs to ISSLL group but COPS might be one possible way to transport this to PEP nodes. Seems to be interest in pursuing this but needs to wait on ISSLL. See slides.

Charter extensions - Abel Weinrib/Intel

Seems to be consensus that extending COPS for QoS policy provisioning (see draft-sgai-cops-provisioning-00.txt and draft-mfine-cops-pib-00.txt) is a good idea - see also slides presented by Keith McCloghrie to Policy WG, available at ftp://ftpeng.cisco.com/ftp/kzm/pub/pib.ppt.

Proposed additions to WG charter to be circulated subject to agreement by IESG:

"In addition, the working group will define usage directives for use of the COPS base protocol to support policy information exchange transactions within the framework being standardized in the policy ramework Working Group. In particular, the group will address the following work items:

1. COPS usage for policy provisioning transactions ("COPS Usage"):
- The working group will produce a standards-track RFC that specifies usage of COPS for the support of policy information exchange transactions between a PDP and its PEPs.

2. Object syntax for carrying policy provisioning information ("Object Syntax"):
- The working group will produce a standards track RFC that specifies the syntax of objects and their contents for carrying policy information. The working group will specifically focus on syntax of objects needed for carrying information related to QoS policy provisioning.

This work explicitly excludes definition of semantics of policy provisioning objects. Instead, it will rely on the definitions from the relevant working groups such as DiffServ and ISSLL."

RAP WG Summary

Framework, base COPS protocol and RSVP extensions for use with it have completed RAP and RSVP WG last calls. Framework draft still needs some editorial work based on comments received (ed. since submitted). RSVP Extensions draft has had some editorial clarifications based on comments received during RSVP WG last call (will wait another week for RSVP WG last last call). Will forward to AD for IETF last call shortly. Starting work on COPS client MIB. Working group desires to work on simple extensions to COPS base protocol to enable QoS provisioning, particularly of DiffServ routers - this to be driven by requirements from DiffServ WG and to be closely tied to DiffServ MIB work there. A possible WG charter revision will be worked out shortly by co-chair and interested parties.


RSVP/COPS Local Policy Modules