NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Robert Braden <braden@isi.edu
Lixia Zhang <lixia@parc.xerox.com
Allison Mankin <mankin@isi.edu
Allyn Romanow <allyn@eng.sun.com
General Discussion:rsvp@isi.edu
To Subscribe: rsvp-request@isi.edu
Archive: ftp://ftp.isi.edu/rsvp/rsvp.mail
Description of Working Group:
RSVP is a resource reservation setup protocol for the Internet. Its major features include: (1) the use of ``soft state'' in the routers, (2) receiver-controlled reservation requests, (3) flexible control over sharing of reservations and forwarding of subflows, and (4) the use of IP multicast for data distribution.
The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internet standards track. The working group will also serve as a meeting place and forum for those developing and experimenting with RSVP implementations.
The task of the RSVP Working Group, creating a robust specification for real-world implementations of RSVP, will require liaison with two other efforts: (1) continuing research and development work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of real-time applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups.
Goals and Milestones:
· Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
· RSVP Cryptographic Authentication
· RSRR: A Routing Interface For RSVP
· RSVP Management Information Base
· RSVP Extensions for IPSEC Data Flows
· RSVP Diagnostic Messages
· Local Policy Modules (LPM): Policy Control for RSVP
· Policy Control for RSVP: Architectural Overview
· RSVP Extensions for Policy Control
· Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules
· RSVP Extensions for CIDR Aggregated Data Flows
· Designing Tunnels for Interoperability with RSVP
· Open Outsourcing Policy Service (OOPS) for RSVP
· Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment
Minutes of the Resource Reservation Setup Protocol (RSVP) Working Group
Reported by: Bob Braden/USC-ISI
Tuesday April 8, 1997
I. Last Call and RSVP Applicability Statement: Scott BradnerThe IESG has issued IETF Last Calls for entering Integrated Services (Guaranteed and Controlled Load) and RSVP into the Internet standards track as Proposed Standards. Scott Bradner, Area Director for Transport, discussed the Applicability Statement (AS) draft rsvp-intserv-analysis-00.txt, which is being submitted as part of this Last Call. An AS "specifies how, and under what circumstances, one or more Technical Specifications may be applied." The IESG felt that an RSVP AS is required to align community expectations with the limitations of current knowledge and experience with Integrated Services and RSVP.
The AS deals with three main issues: scalability, security, and policy. The import of the AS is to urge caution about immediate large-scale deployment of these specifications in the general Internet. However, they can be immediately useful in more restricted environments such as within particular ISPs or corporate networks ("intranets").
The IESG requested that the Integrity Extension Draft rsvp-md5-02.txt be updated with the latest on MD5-like security digests and replay protection. Fred Baker will review the changes needed with the Security AD, and in consultation with the RSVP Working Group chairs will determine whether the changes can be made within the framework of the current Last Call.
Bradner also noted that the RSVP Working Group must be cautious in dealing with the policy area, to avoid imposing illegal constraints on business practices. The scope of allowable IETF discussions of charging models is under consideration by the POISSON working group.
II. Document Updates: Bob Braden
Braden presented a list of errata on the ID14 RSVP specification that will be fixed at the end of the Last Call period, before the text is submitted for publication as an RFC. Tim O'Malley and Lou Berger contributed a short list of changes already incorporated in the IPSEC extension document rsvp-ext-07.txt.
III. Diagnostic Message: Lixia Zhang
Zhang summarized the status of development of the RSVP Diagnostic message. A new version of the specification will be published shortly. She clarified that there are up to three parties involved in RSVP diagnosis: the requester (client) node, the "last-hop" node, and the sender node. The requester can be any third-party host that is not on the network path to be diagnosed. The requester sends a DREQ message to the last-hop; the DREQ is forwarded towards the sender, collecting diagnostic information, and the reply message DREP is returned to the requester.
She outlined a simple scheme using traceroute to cross diagnosis gaps caused by RSVP-capable nodes that have not implemented the Diagnostic message. She also described an implementation problem of interactions between an RSVP daemon and a diagnostic client program, when both expect to receive "raw" protocol 46 packets. The problem exists in various forms under different operating systems. One suggestion to avoid the problem is to use UDP encapsulation for returning the DREP to the requester host.
Subsequent discussion included the following points.
· DREQ should collect Policy Data objects. This will be handled by allowing the set of collected objects to be open-ended.
· DREQ should be able to request a specific set of objects to be included in reply.
· It may be useful to provide information compression for objects that keep unchanged in successive nodes.
· The provision for sending DREP messages using multicast in order to penetrate firewalls is useful only for specific type of firewalls that permit all multicast packets. The meeting consensus was that this protocol provision is not necessary and should be removed.
An implementation of the latest Diagnostic spec is expected to be available shortly in the ISI distribution; UCLA and ISI are producing it in collaboration.
IV. CIDR Prefix Extension: Jim Boyle
Boyle discussed RSVP Extensions to add CIDR prefixes to SESSION, FILTER_SPEC, and SENDER_TSPEC objects, suggested by the LSMA Working Group. He described the motivation for this extension to support large-scale distributed simulations. He noted a possible ambiguity and suggested it be resolved by using longest-match.
V. RSVP Tunnel Support: Lixia Zhang
Zhang reported on continuing work by John Krawczyk, John Wroclawski, Andreas Terzis and herself to support RSVP reservations over IP-in-IP tunnels. The basic approach is to keep the current implementation unchanged for best-effort packet forwarding over the tunnel; use UDP encapsulation for packets with reservations (in special cases where all traffic in the tunnel is entitled for reservation, one may save the overhead of UDP encapsulation and use IP-in-IP encapsulation only). The current RSVP tunnel design supports two kinds of reservations a tunnel:
1. A one-to-one mapping between tunnel and end-to-end RSVP reservation, the reservation over the tunnel is created automatically by receiving end-to-end RSVP messages, and
2. A one-to-many mapping between the tunnel RSVP session and end-to-end sessions. In this case the tunnel reservation is created by a network management interface beforehand, and the amount of reserved bandwidth can be either fixed or variable according to the sum of end-to-end RSVP requests over the tunnel.
UCLA has started an implementation effort on RSVP tunneling support, and we expect the current design to be further refined based on the implementation experience. We expect to finish the first prototype implementation before the
Zhang clarified a question raised from the floor about "multicast tunneling" support. All existing IP-in-IP tunnels are point-to-point; "multicast tunnel" is a new and interesting concept that is yet to be defined. We do plan to, possibly in collaboration with others, define the concept and then develop RSVP support accordingly.
VI. Service Replacement: Lee Breslau
Breslau summarized a scheme for handling heterogeneity of deployed services. The scheme does not require changes to RSVP, but it does require some modifications to the Integrated Services data objects.
VII. Standardization of RSVP API: Don Hoffman and Yoram Bernet
Hoffman described an effort by XNET, part of Open Group (see www.opengroup.org) to define a standardized API for RSVP and Integrated Services. They propose to base this standard on the RAPI API of the ISI distribution. After the input document is edited into X/Open format and before it is submitted to XNET, it will be circulated to the RSVP working group mailing list for comments.
Bernet talked briefly about a general effort to define a QoS interface for WINSOCK2. The intent is to produce a protocol-independent interface, but it must at least match the requirements of RSVP. The spec is available from: ftp://ftp.microsoft.com/bussys/winsock/winsock2/wsgqos.doc.
Wednesday April 9, 1997
I. Action on General Tunnel Requirements Document
Based upon working group discussions last year, John Krawczyk wrote a short draft rsvp-tunnels-interop-00.txt explaining the requirements on any tunneling scheme to properly support integrated services. It was pointed out that a new working group is being started to consider tunnels in general, and that this draft should be input to that group.
II. RSVP Policy Control Extensions: Shai Herzog
Herzog discussed his draft rsvp-policy-ext-02.txt, defining proposed extensions to RSVP for policy. Although this work seems relatively mature, there was some sentiment in the working group not to push it too fast towards last call. The work on the Policy Server may result in changes to this document.
It was pointed out that the current document includes both material destined for the standards track and informational material. The author was asked to split apart these two different aspects into different documents.
III. Policy Server Specification: Shai Herzog
Herzog discussed his draft rsvp-policy-oops-00.ps, .txt, which defines the OOPS (Open Outsourcing Policy Service). This is a protocol that a router can use to query a policy server to exert policy control over RSVP reservations. His document does not attempt to define any specific policies, but instead it provides a general communication capability between a router and a policy server.
Herzog pointed out that a policy server might be used by other components besides RSVP, and therefore it might be appropriate to set up a separate working group to develop its specification. A straw poll of those present showed that a substantial majority of those who voted were in favor of a separate working group.
IV. Light-Weight Flow Admission Protocol (LFAP): Paul Amsden
Paul Amsden gave a brief overview of the protocol of a protocol that was designed with very similar goals to Herzog's OOPS protocol. It is described in the Informational RFC2124, "The Cabletron Light-Weight Flow Admission Protocol Specification, Version 1." Both LFAP and OOPS should be considered as input to the design of a standard policy server protocol.
2. RSVP Extensions for Policy Control
6. RSVP Applicability Statement
8. XNET Standardization of RSVP API (RAPI) t