2.7.13 Resource Allocation Protocol (rap)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

Andrew Smith <andrew@extremenetworks.com>
T. O'Malley <timo@bbn.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

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/

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:

Done

  

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

Done

  

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

Done

  

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.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the 46th IETF RAP WG Session, Washington DC, 11/08/99

Minutes reported by Diana Rawlins (Diana.Rawlins@wcom.com)
Mark Stevens, acting WG "chair"

The agenda items, see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-rap-1199.ppt, were:
1. COPS Client MIB - status
2. Yoram Bernet "Application and Sub Application Identity Policy Element for use with RSVP"
3. David Durham " Status of COPS Specification"
4. David Durham "COPS for Provisioning"
5. Yasusi Kanada "SNMP based QoS Programming Interface with MIB for Routers

1. COPS Client MIB

No discussion at this meeting. Plan to go to WG last call following IETF meeting.

2. Application and Sub Application Identity Policy Element for use with RSVP

Scott Bradner (Transport Area co-AD) clarified that this item was more appropriate for the RAP WG because the RSVP WG was ramping down. Yoram Bernet presented an overview of the draft. It builds on the identify draft by adding additional levels of granularity with an application as well as sub-application identifier that can be used in an RSVP aware network. This additional granularity permits network QoS management of application based policy. The new application element consists of a policy locator attribute and credential attribute. The policy locator attribute is a formatted X.500 DN that represents the application, version number and sub-application.

3. COPS draft status.

Scott Bradner (Transport Area co-AD) reported that the IESG members received the clarification that was requested and the 6 drafts were entering the RFC editor's queue - RFCs should be published in a few weeks (ed: specifications were approved by IESG as Proposed Standards on 11/18/99). Dave Durham reported that the changes in the cops-08 draft included a mandatory to implement security mechanism. Security is accomplished with the COPS Integrity object which can have manual configuration keys, multiple simultaneous keys, time to live specified, etc. It is similar to IPSEC. The IPSEC/TLS is still optional. IKE can be used for COPS the KEYID exchange. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/durham-COPS-Update-for-46IETF.ppt

4. COPS Usage for Policy Provisioning

Dave Durham presented an overview of the draft, see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/durham-COPS-PR-for-46 IETF.ppt. This draft addresses the provisioning/configuration policy model rather than the outsourcing model. There are protocol suitability issues that are being addressed in the Configuration Management BOF on Thursday. The COPS-PR capabilities include dynamic provisioning support, transactional support, efficient data encoding, and simple access in terms of indexing and security. A provisioning example is the provisioning of Diffserv. The COPS-PR can be used to pre-provisioned classification, metering, and actions in a potentially dynamic manner. Dave quickly reviewed some advantages of using COPS to configure network elements. These included the dynamic update of shared state between the PDP and PEP, the addition/update/removal of provisioned data, the reliable support of large and small transactions, the exclusive access to data, fault tolerance, the support of fail-over, PEP initiated capabilities, the avoidance of network polling, and the ability for the PDP to collects capabilities from the PEPs.

Dave pointed out that the Data Model is still needed and work on this is underway (-- pending based on the outcome of the Configuration Management BOF.) The configuration data is opaquely transported via COPS-PR in the ClientSI objects. The proposed PIB provides the Data Model. The decision carries the configuration data. The proposed data representation for Differentiated Services reuses SNMP SMI and BER encoding. The COPS PIB optimizes the SMI for provisioning. It provides row level access, has minimum transmission of object identifiers and avoids data consistency problems by using an OID unique to client type. The draft has included a section describing extending and updating the Data Model. It is expected that it would change over time. Some attributes won't be needed (deprecated) and new attributes may be added.

The COPS Report operation can be used to send unsolicited accounting updates. The unsolicited reports are triggered by events and remove the need for polling. Security for COPS-PR uses the same mechanism as the base COPS draft (Integrity Object or the IPSEC.)

Questions from floor:
1) When adding PRC's or deprecating PRC's from a PIB why wait until a DECISION to determine this. Why not do it during the initial request / solicited decision exchange? The response was that this seemed to be a reasonable approach.
2) The REPORT type accounting lacks clarification in the draft. The response was to post a suggestion to the mailing list.
3) What is role of bandwidth broker in this scheme? This discussion is postponed until the Configuration Management BOF.

5. SNMP based QoS Programming Interface with MIB for Routers http://www.ietf.org/internet-drafts/draft-kanada-diffserv-qospifmib-00.txt

The draft was originally submitted to the DS WG, but was considered more suitable for CONFIGMGT BoF since it deals with configuration management or RAP WG (since we have more time on the agenda). Yasusi Kanada presented an overview of the draft - see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/kanada-QoSMIB-IETF46R AP.ppt. It is based on the concept of Active Networks (AN) where networks download programs to nodes and policy based resource allocation is the first step of AN. Hitachi has implemented both a version of the QoS MIB and COPS PIB using an API of standardized IEEE P1520 CORBA IDL. Problems were found with both the MIB and PIB since they were unsuitable for representing program semantic. The solution proposed by the draft is to provide a rule based programming language for the interface. The definition of the protocol must include a rules based language.

Questions:
1) Is this draft alternative to COPS-PR? Response was that the draft is "not opposing COPS" but expanding it.
2) The point was made that pushing programs to the router was never the intention of the MIB or PIB.
3) It was asked that if MIB's aren't good for programming language, then why is the draft submitting a MIB for this purpose. The response was that the MIB was not suited for downloading programming to the router.
4) The point was made the Policy Framework WG assumes that policy rules are declarative and not procedural. The concern was noted that network behavior is unpredictable and what was the reasoning for the policy rule to be procedural? The response was that policy rules viewed as semantics is a different, but good approach.

6. CONCLUSION:

Mark Stevens concluded session by providing a summary of the RAP Time Table and milestones and work related to RAP (see slides).

Slides

COPS for Provisioning
COPS Update
SNMP-based QoS Programming Interface MIB for Routers
Resource Allocation Protocol Working Group