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.