Editor's Note: These minutes have not been edited. Transport Area RSVP Working Group Minutes of the Resource Reservation Setup Protocol Working Group (RSVP) Reported by: Bob Braden/USC-ISI Tuesday April 8, 1997 A. Last Call and RSVP Applicability Statement: Scott Bradner The 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: scaleability, 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 WG 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. B. 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 contribued a short list of changes already incorporated in the IPSEC extension document rsvp-ext-07.txt. C. 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 availably shortly in the ISI distribution; it is being produced by UCLA and ISI in collaboration. D. 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 grouip. 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. E. 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, and 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 design supports two kinds of reservations over 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 Munich IETF. 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. F. 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. G. 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 A. 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 was being started to consider tunnels in general, and that this draft should be input to that group. B. 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. C. 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. D. 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.