2.4.12 Resource Allocation Protocol (rap)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00


Andrew Smith <andrew@extremenetworks.com>
Mark Stevens <markstevens@lucent.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

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

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 data 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 RAP 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.

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 Framework 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 the 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.

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:



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



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



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.

Jul 99


Submit Initial draft of document that specifies COPS usage for policy provisioning transactions

Sep 99


Submit initial ID on object syntax for carrying QoS policy provisioning information (dependent on progress in DiffServ and ISSLL working groups)

Nov 99


Working Group last call on revised version of COPS Usage document incorporating mailing list discussions

Jan 00


Submit COPS Usage document to IESG for publication as an RFC

Jan 00


Submit object syntax transport protocol ID

Mar 00


Submit object syntax transport protocol to IESG for consideration as a RFC.


Request For Comments:







The COPS (Common Open Policy Service) Protocol



COPS usage for RSVP



RSVP Extensions for Policy Control



Signaled Preemption Priority Policy Element



Identity Representation for RSVP



A Framework for Policy-based Admission Control

Current Meeting Report

Minutes of the Resource Allocation Protocol WG (rap)
IETF47, Adelaide, Australia, March 28th 2000

WG co-chairs: Mark Stevens and Andrew Smith
Minutes submitted by: Andrew Smith
WG charter: http://www.ietf.org/html.charters/rap-charter.html

Current status - chairs (see slides
1. Policy terminology
2. COPS Client MIB
3. COPS for Provisioning and PIB framework/mechanisms
4. Interop testing of COPS-PR
5. New work - Proxy-RSVP, interactions between COPS-RSVP and COPS-PR

Policy Terminology - Mark Stevens/co-chair

Please use consistent terminology: need to align with policy WG and others in this area: see e.g. draft-reichmeyer-polterm-terminology-00.txt which is now owned by Policy WG. Please help with contributions in this area.

COPS Client MIB - Andrew Smith

COPS client MIB (draft-ietf-rap-cops-client-mib-02.txt) from Extreme/Ericsson/Nortel. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-cops-mib-0300.ppt. Revised objects for server retry algorithms - in WG last call (again).

COPS-PR - Scott Hahn

Overview of provisioning using COPS - see slides
- Changes: added multiple contexts for data, supports different encoding methods, multiple client-types, expanded treatment of reports. PIB syntax is now described in separate draft.
- Client-Types:
- COPS-PR is not a client-type now: client-type represents an area of policy
- ClientType is described by the PIBs themselves.

Data encoding: still BER encoded - future PIBs might use different encoding rules (clarification: he means future usages of COPS-PR - we do not expect PIBs to choose their own encodings) Contexts: to support multiple concurrent configuration sets with a flag to indicate which one is current. PDP can initiate a new context (by asking PEP to allocate a new context).

Error handling: broke up errors into 2 different types: global, class-specific.
New COPS-PR objects (new S-nums): PRID, PRID Prefix, EPD, GPERR, CPERR, ErrorPRID
Q: if COPS-PR does not have its own ClientType, how do we know what format ClientSI objects are in?
A: Dave Durham - thinks this works out OK. Accounting: sent as a {PRID,EPD} - we have not developed an accounting PIB yet.
Q: Is COPS-PR intended as an AAA protocol?
A: Not directly although there is overlap. AD suggests that those interested in having COPS considered in this space (AAA WG) should contribute there.
Q Jeff Case: where are encodings specified?
A: Inherited from SNMP right now - need to make this more explicit.

Structure of Policy Provisioning Information (SPPI) - Keith McCloghrie

See slides ftp://ftpeng.cisco.com/ftp/kzm/pub/sppi-mar00.ppt. Now a formal definition: deltas to RFC 2578-80 SMIv2 (which is a Full Standard).

- POLICY-ACCESS: install or notify (or both).
- MAX-ACCESS - not needed
- SYNTAX - we do not want the base types to specify semantics here: that is the job of Textual-Conventions. Just have base types here for on-the-wire encodings (INTEGER, OCTET STRING, OBJECT IDENTIFIER). Application-defined types e.g. Integer32, Integer64. We retained Timeticks & IpAddress since SNMP does but they shouldn't really be base types.
- INDEX clauses: limited to a single Unsigned32 with arbitrary semantics (TC for PolicyInstanceId). We do not really intend COPS for GETNEXT-like searching so multiple indices are not that useful. We keep it here just for consistency with SMI syntax.
- UNIQUENESS: specific the set of attributes that must be unique for all instances of the PRC - promotes good design and aids understandability.
- AUGMENTS: it is its own PRC. An install/delete of the base PRC implicitly installs/deletes an instance of the augmenting class.

Q Bert: how does implicit install work?
A: rely on DEFVALs if PDP does not specify).

MODULE IDENTITY: now has a "CLIENT-TYPE" clause to say which ClientTypes are relevant.
IMPORTS - from SPPI, from other PIBs, from MIBS, from TCs. Extending the SPPI: can add client-types, INSTALL-ERRORS.
Algorithm for converting PIB to MIB (need to define how to map to 64-bit types: propose we make them OCTET STRINGs).
Q Bert: need to consider how to invent OIDs for RowStatus objects that get automatically added.
Q Bert: CLIENT-TYPE maybe needs a new non-COPS name. There are probably other places.
Q Dan: is it OK to define SPPI by reference to SMIv2? What if it changes.
A: the existing understanding of SMI is worth
Q Jeff: is it a design goal that we continue to support algorithmic mapping to SNMP?
A: yes.
Q Jeff: Why read-only MIB?
Q Jeff: Why map Integer64 to an octet string? SNMP only had problem with Integer64. Be consistent.
A: want to avoid the SNMP controversy over 64-bit types. AD says it is up to this WG - you may want to see what SNMPv3 WG comes up with in this space.
Q Bert: why not just do a complete definition, rather than reference SMI?
A: Because it's easier for the many who know (or would benefit by knowing) the SMI to determine what's different, and to avoid accidental divergence.

Framework PIB - Dave Durham

Universal COPS-PR PIB concepts are placed in their own module/document.
Re-usable PIBs are useful; reusable between ClientTypes - can list a PIB as "all ClientTypes" or a list of explicit ones.
- Incarnation: determines which is the currently-active context, which PDP installed it and TTL policy for the information.
- Roles and Interface types: shows what roles are supported on which interfaces.
- Capabilities and Limits: shows restrictions on supported PRCs and their values: supportTable shows per-attribute support and what ranges/values are supported. We could also use some sort of constraint language to specify more detail - not for now though. Capabilities are sent in a COPS-PR request.

Q Jeff Case: different revisions of cards in a chassis - same interface type, different capabilities: how do we model this?
A: interface type" is a more general concept, not an IANA InterfaceType.
Q Andrew: Capabilities are a bitmap right now - how does this get extended?
A: these are probably per-PIB-module. We might need a more general language but this should suffice for now.

Policy Auxiliary MIB - Kwok Chan

Used for managing a policy client: contains a table to relate
RoleCombination to physical interfaces. Each interface has one and only one RoleCombination. This is a mapping needed to associate feedback from the device with policy. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/chan-PolAuxMIB-0300.ppt.

COPS-PR and QoS PIB Interoperability testing - Kwok Chan

Tested COPS base protocol, COPS-PR-01 and QoS PIB
Protocol interpreted and implementation was pretty good - we have some feedback. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/chan-COPS+PIB%20Inter Op1-0300.ppt.
MCI, Nortel, Extreme, IPH, Cisco, Intel.

Want to do subsequent testing, as well as COPS-RSVP.
Q Yoram: how does this relate to QoS Forum work?
A: this is for bug fixing in the specs, not necessarily in implementations. But we need to coordinate.
Q Jeff: where do we define which subset of ASN.1 needs to be implemented?
A: need to fix this.
Thanks to Kwok Chan for hosting this event. Feedback needs to be folded into next revs of all drafts.

COPS for Proxy-RSVP - Dinesh Dutt

See slides
ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/dutt-copsproxy-0300.pdf. Receiver Proxy: a new extension to RSVP. No on-the-wire changes, only message processing changes. This is to be informational RFC from RSVP WG. Need a policy decision as to whether to proxy a session or not ¡V also needs a COPS protocol extension to specify which objects to include. Adds a flag to base COPS protocol (this should be more general than "send
RESV") to say "proxy it").
Q Shai Herzog: it seems wrong to be messing around with the PEP here - it is really the PDP doing the proxying. What is needed beyond "schedule this RESV message" capability? How about a more general solution.
Q Silvano: sometimes need to forward the PATH as well as proxy a RESV: we haven't written that up yet.
Q Andrew: Not clear on the model in use here.
Q Silvano: we need to provide some support for receiver proxy functionality.
Solve this problem.

COPS-RSVP and COPS-PR interactions - Dave Durham

Best of both worlds is RSVP/IntServ + DiffServ, all coordinated by COPS with a common model. Need deterministic roles that map to RSVP interfaces which are sent as part of COPS-RSVP messaging - seems to be scope for some informational material on this.


COPS-RSVP and COPS-PR Interactions
Framework PIB