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.