INTERIM_MEETING_REPORT_

Reported by Daniel Zappala/USC-ISI and Robert Braden/USC-ISI

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

The RSVP Working Group held an MBONE/DARTnet teleconference on 27
October 1994


Agenda

   o Brief recap of Multimedia 1994 demo
   o Progress reports on action items from Toronto


Brief Recap of Multimedia 1994 Demo

Bob Braden, Steve Berson, and Lixia Zhang commented on the recent demo
of RSVP and traffic control at the MM 1994 conference in San Francisco.
The demo was well-received.  It used a DARTnet kernel that supported a
subset of CSZ scheduling (only Predictive service), the new 3.3 IP
multicasting (``prune beta''), and an RSVP daemon.  The demonstration
showed that intense background traffic in DARTnet would break up VAT
speech, but that with an RSVP reservation in place, the realtime traffic
arrived unscathed.

Stephen Casner inquired whether there were plans to rerun this demo for
the IETF in San Jose.


Progress Reports on Action Items from Toronto

The meeting discussed the statements of progress that had been sent out
to the working group mailing list prior to this meeting.


Negotiation Model:  Scott Shenker

Scott Shenker reported that there is still disagreement concerning his
One-Pass-With-Advertising service model (OPWA, presented in Toronto).
The model question has been separated from the question of mechanism to
carry the advertising (e.g., Path messages or routing messages).

Bob Braden suggested that the RSVP Working Group ask the INTSERV Working
Group for a recommendation about the negotiation model.  John Wroclawski
suggested that the question should be:  if advertising is used, how will
RSVP do it?  Does RSVP contain a mechanism for collecting advertising
data hop-by-hop data?

There was some consensus that the necessary RSVP mechanism for OPWA
should be designed.



Routing Interface:  Daniel Zappala, Deborah Estrin, Scott Shenker

Using wb, Deborah Estrin went through slides outlining the four major
functions needed by reservations, and the routing mechanisms needed to
support those functions.  She emphasized that these functions are still
up for discussion.

Lixia Zhang commented that the RSVP Working Group needs to discuss
whether these are the correct functions/requirements, and then present
the requirements to the IDMR Working Group.  Then it can design
appropriate RSVP mechanisms.

Daniel Zappala, Deborah Estrin, and Scott Shenker will present a draft
version of a document discussing the routing requirements for the IETF
at San Jose.



Access Control:  Dave Clark

Deborah Estrin suggested that access control needs an RSVP
authentication mechanism.  She pointed out that this may be related to
work being done by Shai Herzog on multicast costing.

John Wroclawski suggested that there is a wide range of opinions
concerning what access control needs to do, and that policy affects the
technical discussion.  Policy input is needed.  For example, some people
want the granularity of saying that they want to see every sender except
for `X.'

Lixia Zhang stated that she is thinking about short-term solutions with
a transition to a longer-term authentication plan.  She would like to
work on this and will cooperate with Shai Herzog if he is interested.

Lixia said that the working group needs to develop some requirements for
RSVP. Bob Braden said that RSVP has a variable-length, transparent field
for this purpose, so perhaps the protocol has all it needs.  However,
John Wroclawski suggested that this field needs to be changed on a
per-hop basis, depending on the output of a policy mechanism.  There was
agreement that this is a general requirement for RSVP.



Filter Spec Representation:  Bob Braden and John Wroclawski

Referenced the distributed document regarding a completely general
filterspec.



``Killer Reservations'':  Steve Berson

Steve Berson summarized his note, which proposed several mechanisms to
help solve this problem.

There was some confusion as to whether the flowspec carries an
end-to-end delay or a hop-by-hop delay.  It was agreed that the flowspec
carries an end-to-end delay, but that each node treats it as a
hop-by-hop delay.


MMG versus Filters:  Lixia Zhang

Lixia Zhang stated that this topic was misnamed because really there is
no proposed change to how filters work.  This is actually just using
multiple multicast groups (MMG) to handle substreams for layered
encoding.


     There is an unsolved issue with RSVP concerning how to treat
     packets that do not match a filter.  Should they be forwarded
     as best-effort traffic, or be dropped?  The mechanism currently
     in the RSVP specification (Path messages carry forward/drop
     bit) does not allow downstream best-effort receivers to
     register their desire for forwarding.  This dilemma is resolve
     by MMG, in which the (multicast) routing protocol determines
     whether data packets get forwarded.  If a packet does get
     forwarded, RSVP filters still determine what level of service
     it receives.


John Wroclawski asked whether there might still be situations when RSVP
might specify that packets that do not match a filter are dropped,
rather than forwarded as best-effort.  The rest of the meeting did not
think this was a possibility.

One open issue is whether PATH messages can be forwarded when the
routing state is inactive.  Currently, Path messages are needed to
establish forwarding state for RESV messages, but in the future this
need may go away.  Because PATH messages look just like data packets, it
would be hard to deliver them over inactive routes (assuming data
packets are dropped over inactive routes).

Lixia promised to revise her note on the subject.


Firewall Architecture:  Don Hoffman

Don Hoffman summarized his draft on firewalls.  There are two methods
for doing firewalls:  (1) using a ``screening'' (filtering) router and
(2) using a proxy relay (application gateway).  There are two different
ways to handle RSVP and multicast traffic for each of these methods of
constructing a firewall.  A screening router may run an RSVP daemon,
whereas a proxy relay would have to have an application look at the
messages.

Don has built an application for a proxy relay that allows RTP-based
streams and vat traffic through the firewall.  He will report more fully
on the subject in the San Jose meeting.