NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Andrew Smith <firstname.lastname@example.org>
T. O'Malley <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe 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:
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.
No Request For Comments
Minutes of RSVP Admission Policy (rap) Working Group meeting
43rd IETF, Orlando, FL, 9th December 1998
Recorded by Andrew Smith
Set of 6 documents, 1 informational describing RAP framework, 5 standards' track protocol specs for COPS base protocol and its use with RSVP. Editorial and minor technical issues need to be resolved on 3 of these documents - expect to have new versions of these 3 for WG last call in early January 1999. This document set fulfills current RAP charter. Strong support within WG for a new work item to define COPS usage in DiffServ environments. This requires action from area directors and coordination with other WG chairs.
1. Agenda bashing, WG scope statement etc. - Chairs - 5 mins
2. RAP Framework updates - Raj Yavatkar - 10 mins
3. COPS Protocol updates/changes - Dave Durham - 20 mins
4. COPS for RSVP updates - Shai Herzog - 15 mins
5. Policy Extensions for RSVP - Shai Herzog - 15 mins
6. Priority policy objects for RSVP - Shai Herzog - 10 mins
7. Identity representation for RSVP - Satyendra Yadav - 15 mins
8. Last-call/standards'-track discussion - Chairs - 10 mins
9. Expanded charter discussion - Chairs - 15 mins
10. COPS for DiffServ - ?? - MAYBE
Updates to the RAP framework - Raj Yavatkar: draft-ietf-rap-framework-01.txt
No open issues.
COPS-03 draft - David Durham: draft-ietf-rap-cops-03.txt
1. Who owns PEPID - writable? Open.
2. Keepalive per client-type or per-TCP connection? This is really a transport issue but there is not a fast enough notification from TCP. Open issue.
3. IANA client-type admin? Yes, but is there internal structure? Some feeling that this should be a flat space.
4. Is context needed for LocalPDP decisions? Probably not.
5. PDP Redirect to alternate port numbers? Probably not needed.
What are the implications of choosing TCP as the transport (c.f. RUTS BoF)? Should we define our own ordering mechanisms just in case we choose non-TCP in future? No.
Does TCP's tendency to stall get in the way? Yes but ...
Smith: we could redefine COPS to have an abstracted transport service interface? No.
Bradner: don't change anything at this point.
COPS-RSVP usage - Shai Herzog: draft-ietf-rap-cops-rsvp-01.txt
Presented motivation for allowing multiple contexts for each decision returned from PDP. No known open issues.
RSVP Extensions for Policy - Shai Herzog: draft-ietf-rap-rsvp-ext-01.txt
Defines RSVP rules for handling policy objects in policy-capable and policy-ignorant nodes (PINs). Flag to indicate "this is a refresh of earlier policy data" - optimisation.
Option list: can indicate which FilterSpecs in the reservation this policy applies to, can indicate which originator or destination it applies to. Integrity object to prevent replay attacks.
Refresh Multiplier object: allows some control over how often these policy elements will be included in refresh RSVP messages e.g. every 'n' refresh cycles. Discussion: a time-based object would be more useful; what if intermediate routers use different refresh timers? What about route changes/network errors? General feeling that this needs some more discussion or else removing - open issue.
Fragmentation - not addressed: this is a potential RSVP problem although policy objects make it worse - certificates can be big. Hopefully there will not be too many PINs in between ones that are actually merging/compressing these objects. General feeling that this does not need solution as part of this work item.
Policy element number space: do we need IANA to allocate these? Yes - needs description in the draft.
RSVP Preemption priority - Shai Herzog: draft-ietf-rap-priority-00.txt
Priority assigned by PDPs, simple to use by PEPs.
Merging: cannot define a single algorithm suitable for all intended uses that solves free-rider, denial-of-service and instability problems. The object itself therefore defines one of 3 different algorithms. Examples of merging scenarios. Stability is ensured by a concept of a "defending priority" vs. new priority (hysteresis). No known open issues.
COPS-RSVP Policy data for User Identity - Satyendra Yadav: draft-ietf-rap-rsvp-identity-00.txt
Added encodings for "application name".
Should we create a registry for user/string encodings (currently has ASCII and Unicode, Encrypted and Plain)? Should these be IANA assigned? Open issue.
Issue raised later on mailing list: make sure that the RAP WG is aware of the work done in the ROAMOPS area: standard way to present a user identifier (NAI). This may be accomplished by registering NAI as a subtype through IANA - IANA considerations sections still need to be finalised.
Next Steps & Timetable - chair (Smith)
Documents on the agenda right now: only editorial and minor technical issues outstanding - propose to issue WG last call on all of these after spinning several drafts, hopefully early in January 1999.
1. COPS Framework - Informational
2. COPS protocol (needs spin) - Standards' track
3. COPS-RSVP - Standards' track
4. Policy Extensions for RSVP (needs spin) - Standards' track
5. Policy Extensions for preemption priority - Standards' track
6. Policy Extensions for identity (needs spin) - Standards' track
7. Publication of these would fulfill existing RAP charter.
Charter extensions? - chair (Smith) + area director (Bradner)
Bradner: issue needs to be resolved by ADs and WG chairs about possible overlap with Policy WG and AAA BoF. Concerns raised by multiple people in discussion about there being significant multi-vendor momentum to extend COPS for, in particular, DiffServ control (there is existing draft but this is currently considered out of WG scope). Concern that AAA work will be long in coming. Should any DiffServ work be just a framework mechanism for transporting arbitrary DiffServ information or should it be morenarrowly defined (specific objects etc.)?
Elleson - strong desire to coordinate closely between policy WG and any potential-RAP work item.
RSVP Extensions for Policy Admission Control
Preemption Priority for RSVP
COPS Usage for RSVP
COPS 03 Overview
Identity Representation for RSVP