NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 28-Jun-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:
· A Framework for Policy-based Admission Control
· The COPS (Common Open Policy Service) Protocol
· RSVP Extensions for Policy Control
· Signaled Preemption Priority Policy Element
· Identity Representation for RSVP
· Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
No Request For Comments
RAP WG 45th IETF, Oslo - RAP working group meeting (99/07/12)
Minutes recorded by: Walter Weiss.
Meeting chair: Andrew Smith
Administrative
Andrew Smith (WG co-chair) started the meeting 5 minutes late. Agenda:
1. intro and presentation of new charter, timetable
2. Status of current RAP WG documents
3. Security issues in COPS protocol
4. COPS clientMIB
5. COPS Usage for policy provisioning
6. RSVP reservation status policy element for end-to-end accounting
New name for WG, 'Resource Allocation Policy' instead of 'RSVP Admission Policy'
[See slides.]
The charter has been updated: 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 WG 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 it's PEPs.
2. Object syntax for carrying policy provisioning information. Overlaps DiffServ working group. Later, Scott Bradner indicated that this work would be moved to the DiffServ WG.
This work explicitly EXCLUDES the definition of policy provisioning objects.
There is a proposal to specify the objects for implementing COPS policy for QoS provisioning (also known as "PIB"). This has been submitted to the DiffServ WG.
Andrew presented the new timetable for the next round of RAP work. Then he reviewed the status of various existing WG drafts.
To get complete understanding of Policy for QoS activities, DiffServ WG will work on PIBs and MIBs.
Scott Bradner (transport AD): as RAP is focusing on general usage cases and focusing less on transports, the plan is to move the RAP WG under the O&M area with monitoring by the Transport AD. This move will happen after the security issues with COPS have been addressed.
Question about whether or not this reorg will impact Policy or AAA working groups. The answer is no.
There was a question as to whether RSVP working group is closing. The indication was that this WG would close. There are still some RSVP issues, but those will probably be addressed in separate drafts.
Abel Weinrib: does RAP WG define the Syntax of RAP objects as opposed to the semantics? The answer was that RAP WG will provide syntax for specifying policies while DiffServ WG will work on the semantics.
Security for COPS - Dave Durham
Dave Durham presented choices for the Required Security Mechanism for the COPS protocol for <draft-ietf-rap-cops-06.txt>. Dave was pleased with himself that he could plug his notebook into the projector for the very first time. [See slides.]
COPS needs a mutual authentication protocol between the PEP and PDP. There also needs to be a mechanism to ensure the integrity of the contents of the COPS messages.
Privacy and Denial of Service attacks are not requirements at this point
COPS could use IPSEC over a TCP/IP stack minimally requiring AH with a NULL ESP and manually configure shared keys.
The pros are that IPSEC is available today and meets the requirements. IPSEC can also get. The cons are that IPSEC is not implemented on all routers. IPSEC is transparent to COPS so COPS is not aware of the status of Security problems or when keys are changed. There is also a problem with NAT and firewalls.
The original solution was to add an Integrity object in the COPS message that would provide authentication and sequence numbers to prevent replay. It would use the same mechanism used for IPSEC AH and RSVP (HMAC-MD5-96/HMAC-SHA1-96)
The pros are that it would be built into COPS so it can be supported by all COPS implementations. It would also work through firewalls and NAT. Also, it does not preclude the use of TLS, IPSEC or other mechanisms in the future.
The cons are that it is redundant with IPSEC and it is a minimal solution. Because it does not use the IPSEC infrastructure, there is more configuration overhead.
Option 3 is to use Transport Layer Security (TLS)
The pros are that it is secure. The cons are that it is not clear whether it is available.
Scott (Hahn?): use the most light-weight option to give the least burden to the switch.
Shai Herzog: IPSEC is always an option for the future. You could start with the light-weight mechanism is that it can be deployed right away and it is less costly to implement in devices.
James Binder: likes light-weight and sees a benefit to being able to removeit.
Keith: wants it mandatory to implement and optional to use.
Consensus was in favor of the COPS Integrity object.
COPS client MIB - Andrew Smith/Dave Partain/John Seligson:
Andrew presented the COPS protocol client MIB <draft-ietf-rap-cops-client-mib-00.txt> used to manage the important features of the COPS protocol client module. [See slides] He thought that perhaps he should rename the draft to be the COPS PEP MIB to avoid confusion. He also thought that a COPS PDP MIB was less urgent. The draft does not provide support for COPS-RSVP specific capabilities. There are three groups: ClientCapabilities (Version and security), ClientStatus (table indexed by the IP address and server/client type containing the TCP port, the cops server type, the security being used, and statistics), and Config (decide when to switch over to another device).
Bert Wijnen: there is a MIB design team that is solving a problem of using IP addresses as indexes to tables (ed: see draft-ops-endpoint-mib-00.txt for their Auguest 1999 report).
Dave Oran: why are DNS names were not being used instead of IP addresses?
Bert: there is a limit to OID size particularly when DNS names can be quite long.
James Binder: Config objects could have the security-related attributes in them as well.
Two open issues: should the IP address be used as an index and whether the client should be configured with a security mode.
Andrew asked for comments to the RAP WG list as soon as possible.
RSVP Reservation Status Policy Element for End-to-End Accounting - Dave Durham/Shai Herzog:
The authors proposed this extension to provide information on the status of an RSVP reservation end-to-end. [See slides] One possible alternative to this approach is to use RSVP RESV confirm message. However, Confirm message is a one time message and is therefore unreliable. Also, it does not provide a reliable indication of the duration of the session. In addition the RESV Confirm message is not Multicast-friendly. The draft proposes using a new RSPE object in the RESV and PATH messages to monitor the reservation. The RSPE would first be sent with the RESV message. When it arrives at the source, the PATH message would include a RSPE object in PATH messages containing information about when the reservation was initiated. RSPEs need to be capable of being merged so that Multicast RESV RSPEs can be integrated upstream at convergence points. It is possible to assign RSPEs hop by hop or Domain by Domain. In the Multicast model, when a new branch is created, the starttime timestamp is reset.
Question: What is the impact of RSVP refresh reduction on this proposal. There has been no consideration of this in the current draft.
There is a question as to whether this is a core RSVP capability or a policy-specific feature.
Walter Weiss: is it appropriate in all cases for the starttime timestamp to be reset in the multicast model? Do you charge for the amount each port on a conference call is active or the duration of the overall call?
COPS usage for Policy Provisioning - Fran Reichmeyer/Shai Herzog/Keith McCloghrie
[See slides] This draft <draft-ietf-rap-pr-00.txt> proposes using COPS to configure network devices based on a network-wide policy model. The idea is to first make the PDP aware of the capabilities of the PEP. Then the PDP configures the device with objects consistent with the devices needs.
Changes since the last revision is a name change to reflect a WG change and that the protocol extensions are no longer limited to just DiffServ.
Why not use SNMP? The solution needs a transactional model that preserves a stateful relation between the router and the manager. This also provides a fault-tolerance mechanism.
The content and encoding of the PIB is opaque to the proposed COPS protocol extension.
Bert Wijnen: is COPS really required or is SNMP or SNMP+ sufficient? The advocates need to construct an internet-draft arguing the merits of COPS over SNMP for configuration purposes. This discussion needs to include the perspectives from the SNMP proponent to balance the discussion and also to make the discussions bilateral.
Bob Moore: is it a rule being downloaded to the PEP or a decision? There will be a change in a future version of the draft that will clarify this. However, the sense is that this is a set of configuration settings and not a rule or a decision.
Shai discussed the semantics of the PIB: PIB is a tree similar to the MIB tree. Presented an example for how a policy is embedded into a PIB table using DiffServ as an example. The example separated ACLs and rules into various tables. The COPS message would send a set of these table entries to the device based on the applicability of the rules to the device.
Brian Carpenter: the formats of the PIB for DiffServ will be defined in the DiffServ group, so none of this is cast in concrete.
Keith McCloghrie presented the proposed PIB for QoS provisioning <draft-mfine-cops-pib-01.txt>, slides at <ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/mccloghrie-oslo-rap.ppt>. He pointed out that the PIB is higher level than the MIB because the MIB defines the behavior of a particular router while the PIB can be applied uniformly to a set of devices. Further, he pointed out that a PIB is lower level than the Policy Schema, which describes the high level policies.
The main differences between SMI and the PIB are: 1. PIB modules start with PIB-DEFINITIONS, instead of DEFINITIONS, to identify as PIB 2. Policy Rule Classes are tables not scalers. 3. Policy Rule Instances are row instances. There is also a object type for the PIB allowing polices to be downloaded and installed independently. MAX-ACCESS and conformance clauses not used. Keith believes that PIBs can be mapped to MIBs. This could be used to use SNMP to query policies or a means for passing information sent via SNMP to the PDP. However, there is no clear application for this yet.
Roles are a means for grouping interfaces, devices or services together to allow a single policy to be applied to a number of devices simultaneously. Filter, Filter Group and Classifier classes are used in the proposed DiffServ MIB. There are also concepts for describing the semantics of the Queues as to whether it is WRR, WFQ, etc. There is also the capability to classify and manipulate the MAC layer header. The draft has three components (Framework, IP, and 802.1).
Brian Carpenter: use of the term Queue is somewhat contentious in the DiffServ group. However, using the term Class is overloaded in the context of schemas and PIBs (ie. Classes and Instances).
Agenda
COPS Client MIB
QoS PIB
COPS-PR
RSVP Reservation Status Policy Element
Required COPS Security