Munich IETF Proceedings

Transport Area
RSVP Working Grouip

Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)

Reported by: Bob Braden/USC-ISI

Tuesday August 12, 1997

I. Status Report: Bob Braden, Scott Bradner

The Transport Area director Scott Bradner briefly presented the current
status of the RSVP Internet Drafts.  Contrary to previous report, the
IESG approval of these documents as Proposed Standards had been held up
by a few minor issues.  The only issue still open at the time of the
meeting concerned the IPSEC Extension document: the IESG requested a
more explicit statement of how the VDstPort field should be assigned.
The proposed fix was to include an "IANA Considerations" section,
specifying a division of the field values into fixed and dynamically
assigned ranges, with directions to the IANA on how to assign values
from the fixed range.  There being no objection from the document
authors or from the Working Group, this proposal was adopted.  As a
result, the RSVP documents should all advance into the standards
track.

The RAPI application interface, defined in the ISI interface, has been
submitted to XOPEN for possible standardization by that body.  This was
initiated and is being pursued by Don Hoffman of Sun.  An XOPEN draft
has been produced and is awaiting editing.

A first stage of a survey of current and planned implementations of
RSVP and integrated services has been completed.  This initial effort
was substantial, and has more than 20 entries.  We are grateful to Gene
Gaines and Luca Salgarelli for the work they have put into this.  The
draft has been distributed on the rsvp-test mailing list, and it is
planned to be available on a Web page.

II.  Status of Tunneling and Diagnosis Drafts: Lixia Zhang

The diagnostic message specification has gone through another cycle of
cleanup and has two new object types added:

- In response to comments received from Menphis meeting, a new SELECT
  object is defined to allow a diagnostic requester to specify the
  types of RSVP objects to be collected in the diagnostic reply.  This
  new SELECT object consists of a list of [C-Class, C-type] pairs.

- In order to be able to perform diagnosis recursively over an RSVP 
  tunnel, a new TUNNEL object is defined that consists of two session 
  objects.  This object is used when the path of an RSVP session contains 
  one or more IP-in-IP tunnels and both ends of a tunnel support RSVP 
  tunneling.  The first session object specifies the end-to-end RSVP 
  session S1, and the second one specifies the RSVP session over the 
  tunnel S2 that S1 maps to (that is, over the tunnel S1's flow is 
  supported by S2's reservation).  When an RSVP diagnostic request is 
  received by an Rexit router, Rexit attaches to the DREQ a TUNNEL 
  object.  Thus the diagnostic client can easily identify the existence 
  of RSVP tunneling, and invoke RSVP diagnosis over the RSVP tunnel 
  session whenever needed.

Lixia Zhang also reported the status of specification and
implementation of RSVP over IP-in-IP tunnels.  We are finishing a new
version of the specification taking into account the input from Memphis
IETF, in particular some valuable comments from Tim O'Malley.  UCLA is
finishing the first prototype implementation that runs on freeBSD
2.2.2, with IP- in-IP tunnel code from University of Portland, and
using CBQ for packet scheduling.  Our implementation supports both
automatic RSVP tunnel session setup by end-to-end RSVP sessions and
configured RSVP sessions over the tunnel for aggregate traffic flow.
We plan to release the code before December IETF.

We also learned recently that KDD R & D Lab in Japan has carried out a
second, independent implementation for RSVP over IP tunnels.  The
implementation runs on freeBSD 2.2.1, using a simplified version of WFQ
for packet scheduling.

III.  Future of RSVP Working Group: Discussion

As co-chair, Bob Braden reviewed the history, goals, and
accomplishments of the RSVP working group.  In summary, the goals of
the working group have basically been met, and most of the protocol
documents under development will soon be Proposed Standards.

The Working Group then agreed to go dormant, until the time comes to
consider the documents for Draft Standard.  The rsvp and rsvp-test
mailing lists will remain in place for discussion of the protocols
and implementations.

IV. Routing and Reservations: Roch Guerin

Roch Guerin summarized the Internet Draft:  "Extended RSVP-routing
Interface" (draft-guerin-ext-rsvp-routing-intf-00.txt).  He suggested
that RSVP should support service differentiation by path, i.e., the
path should be determined in part by the service requested.  For this
purpose, he suggested that the RSVP/routing interface be broadened, so
that (1) RSVP will pass *all* information that might possibly be
relevant to QoS routing, including the IP and transport headers,
T_specs, and Adspecs, and (2) there will be a more general event
notification mecahnism between RSVP and routing.

Guerin also discussed the draft "Setting up Reservations on Explicit Paths
Using RSVP (draft-guerin-expl-path-rsvp-00.txt).  RSVP can be extended
to support explicit routing of data, by carrying opaque routing
objects.

Brief audience discussion pointed out that RSVP may not always be in
use when service differentiation by path is required.  It was also
suggeted that higher-level architectural issues should be considered
before detailed RSVP-specific features are defined.

V. RSVP Experience in Commercial Internet Trials: Mark Baugher

Mark Baugher gave a very interesting report on a joint effort by cisco,
Intel, and MCI to evaluate commercial feasibility of Internet
multimedia services.  These tests were conducted over the MCI SMDS
service and over the internal Intel ATM testbed.  During these trials,
RSVP was successfully tested on the MCI SMDS testbed.

A total of 6 application tools from 3 vendors/sources were converted to
use RSVP.  They found that about one person-month was typically
required to design,implement, and test RSVP support in an application.
He noted that application developers often implemented the wrong data
rate for their applications, so that some mechanism for rate adjustment
is necessary.

Among his conclusions were: (1) better workload generators and tools
are needed for testing end-to-end delay; and (2) multicasting through
firewalls in a major problem.