2.4.13 Resource Allocation Protocol (rap)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 28-Nov-00


Andrew Smith <ah_smith@pacbell.net>
Mark Stevens <mstevens@ellacoya.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@ops.ietf.org
To Subscribe: rap-request@ops.ietf.org
In Body: subscribe
Archive: ftp://ops.ietf.org/pub/lists/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 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:






Signaled Preemption Priority Policy Element



Identity Representation for RSVP



A Framework for Policy-based Admission Control



The COPS (Common Open Policy Service) Protocol



COPS usage for RSVP



RSVP Extensions for Policy Control



Application and Sub Application Identity Policy Element for Use with RSVP



Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients

Current Meeting Report

49th IETF
TUESDAY, December 12, 2000 1300-1400 Afternoon Sessions I
Resource Allocation Protocol WG Meeting Minutes (Grande Blrm B)

The chair (Mark Stevens) gave an overview of the agenda:
-Status of COPS-PR -Dave Durham
-Status of Framework PIB - Scott Hahn
-Using RSVP to maintain control of network resources - Yoram Bernet
-Framework Accounting PIB - Diana Rawlins
-Std Application ids for use in RSVP identity policy element - Ralph Santitoro
-A Filtering PIB for Edge Router Services and Provisioning via COPS-PR - Joerg Ottensmeyer
-RSVP Policy Control Criteria PIB - Diana Rawlins
-Data Model for Network Access - David Spence
-COPS usage for SIP- Gerhard Gross

***Status of COPS-PR -Dave Durham

The COPS-PR draft has completed last call. Some clarifications were added to the text; Forward SPPI references were added to the draft; Size Restriction for Reports was removed and the document is in IETF last call. The AD pointed out that the document could go through last call pending the SPPI is approved. Dave pointed out that the related documents i.e., SPPI and the framework PIB also completed last call. The COPS over TLS draft needs a port number from IANA.

Comments/Questions: None

***Status of Framework PIB - Scott Hahn

WG last call completed. Scott presented the following updates: text was cleaned up in the draft; The Role and RoleCombination TCs were added to the framework PIB document; Filters were simplified by removing the FilterGroup PRC, adding a negation flag to the base filter and using EXTENDS to extend the base filter to define the IP and 802 filters. The authors intend to ask for IETF last call for the framework PIB and the SPPI after this IETF.

The AD confirmed that all 3 drafts (COPS-PR, SPPI and the frameworkPIB) will be submitted to the IESG for the Standards Track together.

***New RSVP ErrorValues Used to Modify Sender Behavior - Yoram Bernet

Yoram pointed out that IT managers tend to not put traffic on the network if there is no way to control it. He presented two sample networks - one with a leased line and another with a diffserv n/w with a static SLA. The Sender behavior was to be controlled. This can be done by causing admitted traffic to be marked for prioritized traffic while, rejected traffic be marked for LBE (Less-than Best Effort) or be reduced. When there is no more capacity on the link, flow is rejected, hence no RESV is returned, hence no DCLASS is set. The objective is to have a mechanism to stop multimedia traffic from trashing the link as it interferes with BE traffic. The solution is to use PATH_ERR.
-To signal explicit notification that flow cannot be handled. - Include policy error object NO_QOS_PROVIDED (optionally include DCLASS to force LBE) - explicit and immediate direction NOT to send (via PATH_ERR object DO_NOT_SEND). The sender responses for each of the above error codes was described. For NO_QOS_PROVIDED the sender can - scale back (reduce TSpec), - settle for LBE, - give busy signal to user (abstraction) - or use alternate I/f. For error code DO_NOT_SEND - the app has no choice. It either, does not send, or scales back and tries again or - use alternate I/f.
Yoram presented a sample policy: if Requests (Total) < TB1 - admit and return DCLASS, if TB1 < Requests (Total) < TB2 admit BE DCLASS (or no DCLASS) OR reject if Requests (Total)>TB2 return DO_NOT_SEND

Q: Is there some way of signaling - premium or nothing (go ahead and drop it)?
A: On the host side we haven't thought of distinguishing that but that
would be useful. Note that what one PDP uses as a DSCP for LBE may not be the same on another host.

Q: 1. I noticed that a difference exists between what happens to RESV in the last two cases when the flow is rejected.2. Isn't the path pinned?
A: There is no reserved path between the 2 endpoints- this should be mapped to something in the diffserv domain.

Q: Should we explore the trust relationship here-should the n/w rely on actions taken by the host?
A: The initial n/w we looked at is a leased line, and the diffserv cloud is a static SLA so the trust relationship is between the PDP and the clients around the diffserv cloud.

Q: is there an issue here about traffic being injected into the n/w?
A: The diffserv providers will have policies at the edge routers, and if somebody is hacking the PDP then there is recourse. In this case its not an issue - Now if the agent is adjusting the enterprise resources based on this traffic then it can be an issue.

Q: The Busy signal - is this a metaphor you want to define?
A: It's not the "beep beep". Its feedback of the form "go use a different network" or "Quality will be mediocre" or "use 56k instead of T1" - it's an abstract. The network should indicate the resources are not available.

Q: Is Standards Track intended?
-Yes, the error objects defined for the PATH_ERR message are optional, ignore them if you don't know what they mean.

***Framework Accounting PIB - Diana Rawlins

Diana pointed out that this draft was being presented for the second time with significant changes from the 48th IETF. The draft addresses a need for a deterministic and flexible Reporting mechanism. The Approach was to define Reusable + extensible PRCs to specify selection, linkage and usage. PDP controls the RPT interval (ref RFC2748 AcctTimeObject) by specifying the Max interval and the resume attribute. PEP specifies reporting capabilities. Reporting TC CountType defined as an Unsigned64 that sticks. SPPI defines a "report" PIB-ACCESS type for report PRCs. The PRC structure is as follows: the selection-PRCs define "who"; the usage classes define "what" is counted/recorded and the linkage classes are the association classes. Issues to be addressed are:

What if acct rpt spans many COPS RPT messages? - This was not anticipated but suggested resolution was a continuation flag to indicate more messages.
Next steps were listed - to develop diffserv QoS Acct PIB and - Classification of multiple usage instances per report message.

Q is this also useful for RSVP?
- Yes, it's needed; needs to be done.

***Standardized Application Identifiers for RSVP Identity Policy- Ralph Santitoro

Background - RFC 2752 and 2782. Needed as QoS-enabled Apps are being rolled out, networks are administered by X, and deployed by Y, the Std app-ids will facilitate vendor interoperability-policies can be in a common set. PDP can make informed decisions; the app-ids use a textual format to describe what the application is. Draft focuses on real time apps.
AppId = Name, sup-app-id, sub-app-id - for example Voice, Video, Audio A Policy examples for campus LAN was explained, (use G.711 codec for traffic with DA x.y.z.*, Use no voice activity detection); Also a service provider policy was explained.

Q: From author for audience, WG: is this work something they want to work on?
C: We are mixing RSVP with SIP - signaling protocol model is broken
A: Call admission is done by the PDP.
C: RSVP should not have to know about an audio decoder

C: Once you are talking about n/w resources, in some parts of the n/w, some apps may not have access to n/w resources, in the enterprise the policy may be "no n/w m media on my n/w"
A SIP for QoS addresses these issues.

Q: Why do you want to standardize SApp-IDs in this group. Why not Voice-over-IP?
A: As you have different policies, when the telephony device signals the n/w and because app providers put these into the devices, the PDP does use this information.

Q: Current model has "voice activity" - is that required?
A: When VA is enables - bandwidth can be saved

C: But - Originator and destination negotiate a codec in SIP
A: This is done during call setup - what we're talking about is Media path reservation.

C: in general, I can see a value in sub class ids, but the voice space is very muddy and with b/w mgmt systems not well defined, also call setup is a concern when you're doing end-to-end resv. This activity is premature - voice activity should be flushed out.

Q: do we want RAP to finish before we add to the charter?
AD: I would like RAP to be finished, before we want to take more work.

Yoram: we need to give more control to the n/w admins
AD: we need to finish this working group. Is this work a part of the "Using RSVP to maintain control of network resources" presentation?

Yoram: No, these are two separate drafts, I don't understand why the question - should we work on this, was answered by - should we finish?

Ralph Santitoro gave an explanation of what the two drafts are proposing.

C: We need to close off the work that's done, this work belongs in this group but I'd like to see the work that's done - completed.

The chair moved this discussion to the RAP wg mailing list.

***A Filtering PIB for Edge Router Services and Provisioning via COPS-PR
- Joerg Ottensmeyer

A filtering service is a useful thing to have to control access to n/w and/or services, to enforce certain handling of packets. - Filtering rules need to be updated frequently example: when a new user session is starting, when a session must be terminated. Joerg gave an example of filtering for a Portal service. A PIB overview was presented. The PIB consists of interface objects (params of I/Fs), filter rules, classifier objects and session objects. Session Objects are meaningless to PEP, have meaning for PDP.
They are used to recover from switch over and allow PDP to seamlessly restore control of PEP without interrupting existing sessions. Session objects are retrieved by PDP at (re)synchronization

Joerg requested some COPS-PR enhancements for accounting and listing PIB table instances: Accounting - Need: PDP wants to query PEP for account information.
Solution (Essential functionality): PDP sends DEC command with command code set to "accounting" and prids of accounting objects to retrieve.
List - Need (Obsolete): PDP wants to retrieve all objects of a certain class.


C: Dave commented that the same behavior can be achieved by modeling the PIB, not changing the protocol.

C: Scott commented that, Filter classes can be extended to form specialized classes.

***RSVP Policy Control Criteria PIB - Diana Rawlins

Outsourcing RSVP is not feasible all the time and manual configuration is not an option. 3 operational modes were presented: Local decision and outsource for confirmation, Local decision and outsource only if there is no PDP, Policy decisions only.

The Policy definition is represented by an association instance linking a filter instance and an authorization instance. The filtering requirement is fulfilled by frwkIPFilter from the framework PIB. The authorization PRC contains traffic specification (SENDER_T_SPEC: Controlled load or guaranteed services, RSPEC: Guaranteed services), Auth specification, priority preemption priority element.
Diana presented the following next steps: Solicit feedback from policy wg, RAP wg.
-Should this be a RAP wg item?

Q: How do you deal with aggregation issues? How do you deal with security factors?
There is a notion that we authorize something to go through, but send it to confirm the decision and it may come back and cut it off.

***Data Model for Network Access - David Spence

This effort grew out of the AAA wg. Need for a Ng protocol to succeed Radius.
SPPI is a very nice way of structuring data. Radius carries its data in type, attribute pairs, and you pick and choose what you want and that is your protocol. We wanted to structure the information on n/w access data. AUML model of a NAS providing n/w access service was constructed. We started with Radius attributes. Grouped by service into classes.
Created a PIB. David gave an overview of the UML model for NAS.
Radius PIB: If implemented: Mgmt programs doing real time monitoring versus AAA server log. Diameter for Acct/Auth, SNMP for accounting.

David presented some issues and pointed out that temporal aspects are not modeled right now. These can be modeled in UML, as we need more than static data model. David expressed the need for future work in the direction of a proper model for NAS, not necessarily Radius based.


***COPS usage for SIP- Gerhard Gross

Gery presented COPS usage for SIP Inter-domain QoS. This is a COPS extension for SIP.

Q: Yoram: What is the protocol used for QOS?

C: Diana: This is a new COPS client type (tbd) for SIP usage using COPS.


Status for all the drafts given by the chair.
-RAP signaled priority draft (in IESG queue, pending "new-identity" draft issue)
-New Identity draft

-Pol Aux MIB draft - Scott mentioned changes required.
-jwalker-cops-tls moved to last call
-jwalker-cops-cms moved to last call


None received.