CURRENT_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 met on Monday and Tuesday. The objectives of the meeting were to review and discuss the major technical issues in RSVP, and to make decisions on what features should be included in version 1. Bob Braden chaired these meetings, and Daniel Zappala acted as scribe. Implementation and Demonstration Reports The meeting began with brief reports on the status of prototype implementations of RSVP, and a summary of the demonstration of RSVP last October at the MM 1994 conference in San Francisco. o Prototype RSVP Implementation: Steve Berson (ISI) ISI made two limited releases in August and October 1994; the second was used in MM 1994 demonstration (see below). These releases included an RSVP daemon, rsvpd, and modified vat and nv versions that invoke it. In the second release, the following features were added to the rsvpd implementation: support for Rel 3.3 (pruning) version of DVMRP multicast, immediate reservation teardown, and improved error handling. The next RSVP release, planned for January 1995, will include data structure reorganization, an API that matches the current spec, UDP encapsulation (to allow hosts without special RSVP kernel to run RSVP), and support little-endian host byte order. o Solaris Port of RSVP Implementation: Michael Speer (Sun Microsystems) Sun has ported ISI RSVP daemon into Solaris 2.4. It supports the Sun/UCL/LBL CBQ packet scheduler in the kernel. It also has hooks for CSZ scheduler, but this will not be useful until someone ports the CSZ scheduler to Solaris. o John Wroclawski (MIT) and Bob Braden (ISI) Wroclawski and Braden summarized a demonstration of RSVP and packet scheduling that was staged at the MultiMedia 1994 conference in San Francisco last October. It used a DARTnet-based packet scheduling kernel implementing a simplified CSZ algorithm -- essentially simple priority-based scheduling, with no link sharing. Admission control used peak rate allocation. This scheduler has been packaged for routine use in DARTnet. Action Item Reports At the Toronto meeting, an extensive review of open technical issues in RSVP resulted in a number of people taking study action items. Reporting on these actions took the majority of the first working group session. Each report concluded with a recommendation. See the slides for more details. Negotiation Interface: Scott Shenker, Xerox PARC The negotiation interface determines what the host says to the network, and what the network says to the host; it is a host interface, not an application interface. Shenker reviewed the current one-pass model, the two-pass model, and his proposed One-Pass-With-Advertising (OPWA) model. Each has the following advantages and problems: o Current one-pass model - Problem: Does not support delay-bounded services very well. o Two-Pass Model - Advantage: Host can specify desired end-to-end delay/jitter, and network can report on resulting delay/jitter. - Problem: Effort/performance tradeoffs are not visible to an application. - Problem: It adds significant additional complexity and state, and may be contrary to the robustness promised by the soft state design of RSVP. o OPWA Model - Advantage: Effort/performance tradeoffs are visible. - Advantage: Adds little additional complexity to RSVP, and fits naturally into RSVP model. - Problems: (see slides) Shenker recommended that (1) One-Pass is insufficient, (2) ``advertisement'' be a basic part of the service definition, (3) we proceed to develop and test a prototype of OPWA, reporing back at the next IETF, and (4) research continue on two-pass approaches. Filter Spec Representation: John Wroclawski, MIT (See ``Filter Specification'' and following slides). Wroclawski reviewed the design issues for the represention of RSVP filter specs, that are used to select the packets that are to receive a particular QoS. The current format, essentially a mask-value pair to select ``generalized ports,'' is both too general and not general enough. He discussed the design issues raised by multi-part flows, such as hierarchically-encoded video. Wroclawski recommended (1) that the current mask-value format should be abandoned, (2) that either a ``protocol-aware'' format or a procedural language should be adopted. For IP, a protocol-aware format would mean simply IP source/destination address and transport-protocol ports; it would also provide hooks for other internetwork-layer protocols. Lixia Zhang observed that for unicast case one can do negotiation; do not need generalized ports in that case either. Support For Hierarchically-Encoded Flows: Lixia Zhang, Xerox PARC At the last meeting, there was a lively discussion of the use of multiple multicast groups (MMG), one group for each substream of a hierarchically-encoded flow; this would allow less general filters. Zhang carefully reviewed all the design issues and the lessons learned. The disadvantages of MMG are: (1) if different substreams follow different trees, there may be substantial jitter that may last forever, (2) the most important traffic might get the highest loss rate, and (3) the increased number of multicast groups increases multicast routing overhead. The advantages of MMG are: (1) It provides a convenient restraint on bandwidth selection, which can prevent naive users from making silly reservation requestion and simplifes reservation merging; (2) it provides finer control granularity for multicast routing. Earlier RSVP discussions had not taken into account the possibility that some receivers of a given multicast flow may use best-effort delivery while others make reservations. In this situation, RSVP does not have the information to decide when to drop unwanted datagrams, and we must leave this entirely to routing. Zhang recommended that MMG be used for layer-encoded flows. We must make the decision whether this will be mandatory; if not, then RSVP must cope with applications that choose to use one mcast group, which means it must be able to do general merging of flowspecs. Routing Support for Resource Reservations: Deborah Estrin, USC/ISI Estrin discussed the routing and interface functionality needed to support resource reservation. 1. Using alternate, explicit route when a reservation is rejected. Careful design of routing protocol is required to avoid deadlocks and routing black holes from alternate-path joins. RSVP at a host must be able to request an alternate route from routing. In addition, RSVP at each node must supply the reservation status of each upstream link to routing; with this information, routing can avoid re-routing a branch that is already in use; such re-routing, if allowed, could disript the QoS to existing group members. 2. Pin routes for reserved flows that require stability. To support route pinning, two new flags should be passed from RSVP to routing. The Stability flag asks routing to preserve QoS during unicast route changes. The Delegation flag gives routing liberty to provide stability any way it wants, e.g. by ``smooth transition.'' If the Delegation flag is off, then routing should provide stability by pinning. The Delegation flag may have to be off when OPWA is in use, since when a route changes, the end host will not be involved to re-adjust the service level based upon the OPWA advertisement along the new route. 3. Inactive route state to support channel selection. The Dynamic Filter reservation style of RSVP provides standby reservations so that channels can be switched without further admission control. To support this efficiently, routing should have the ability to turn off data forwarding while maintaining the routing state along particular paths. RSVP would make source-specific deactivate/activate requests of routing. 4. Bundling of routes for related flows. If MMG (see above) is used, it will be desirable to have an ability to force a set or ``bundle'' of related multicast groups to use the same distribution tree. RSVP would request route bundling of specified group addresses. Routing could use explicit routes to implement bundling preference; however, it would need more mechanism to do guaranteed bundling (not recommended). Estrin recommended that (1) and (2) should be made requirements for routing, and that (3) and (4) need further study and research. She announced that an Internet Draft on these issues will soon be available. Daniel Zappala is currently doing detailed design, implementation of these routing features in DARTNET. Killer Reservations: Steve Berson, ISI Berson explained how a simple change can be made to RSVP to prevent the killer reservation problem from affecting existing reservations. This is done by allowing the current reservation to stay in place when a larger reservation is rejected. Other, less important, problems are described in the note he sent to the working group earlier. Access Control: Bob Braden, ISI The working group must address the issue of access control for RSVP. Whether there is rationing, charging, government fiat, or whatever, the net will need to use access control to determine who can make reservations. The issues involve politics and economics, as well as technical issues. Shai Herzog at USC/ISI is looking into these issues and will report at later meetings. Firewall Architecture: Michael Speer, Sun Microsystems Speer presented, on behalf of Don Hoffman, ideas on how to use RSVP through a security firewall. The goals are to maintain the concept of a flow over a firewall, to allow data packets using a reservation through the firewall, and to authenticate control messages before passing them on, and to use RSVP to provide resource management within a firewall. He discussed two classes of firewall: filtering routers and proxy routers. He took an action to provide an Internet Draft on these issues by the next RSVP teleconference. New RSVP Technical Issues Presentations were made on some new RSVP design issues. UDP Encapsulation: Bob Braden, ISI RSVP is designed to send its control messages as IP datagrams using protocol number 46. This implies kernel changes to capture protocol 46 and to send to specific interface without routing. At least in the short term, installation of RSVP in hosts will be impeded by the requirement for kernel changes. Braden proposed a scheme to allow UDP encapsualation of RSVP messages between an end host and its first-hop router. Selection of the proper mode can be done ``automagically.'' In discussion, the working group expressed a strong preference to be able to support both encapsulated and ``raw'' modes intermixed on a single LAN, although this will require duplicate RSVP control packets. Braden took an action to update his specification accordingly. IPv6 Conversion: Bob Braden, ISI There are three issues in converting RSVP to IPv6: (1) bigger addresses, (2) variable length IP headers, and (3) flow IDs. It appears that (1) and (2) are easy, so Braden concentrated on discussing flow IDs in RSVP. There are three possibilities for fitting flow IDs into RSVP: (a) flow IDs are a hint for routers, and RSVP does not know about them; (b) flow IDs are carried in PATH messages only; or (c) flow IDs are carried in both PATH and RESV messages. There was no resolution of the best choice. Daniel Zappala pointed out that in case (c), Wildcard Filter reservations can be handled by a ``wildcard'' flow ID in Resv messages. Lixia Zhang took an action item to consider these issues further. Management Controls: Fred Baker, Cisco Systems Baker discussed management controls for RSVP, including configuration of RSVP process attributes and interface attributes, viewing reservation state, and monitoring the rate of important and interesting RSVP events. He is assembling a small group of people interested in following up on the management issues in RSVP. Recommendations to Multicast Working Group The RSVP Working Group needs to formalize the routing requirements for resource reservation, as input to routing working groups of the IETF. We should solicit support for the needed functionality from all unicast and multicast routing protocols, not just some of the protcols such as PIM. Deborah Estrin and Daniel Zappala took an action to write up a draft document on RSVP routing requirements. Decisions on Version 1 RSVP Capabilities The working group co-chairs proposed a revised schedule: good draft of the RSVP version 1 spec by the April 1995 IETF, with the aim of submitting as a Proposed Standard after the July 1995 IETF. To enable progress, the working group discussed which features should be in the version 1 spec, and which can be left for a later revision. There was lively discussion, but decisions were reached, as reflected in the following table. _______________________________________________________ | RSVP Features V1 V2 | |______________________________________________________| | A. Advanced Interface to routing | | 1. Alternate routing N optional? | | 2. Fast reservation recovery hps Y | | 3. Route pinning N Y | | 4. Bundling of routes N Y? | | 5. Inactive route state (DF) N ? | | B. Session Group Y? Y | | C. Drop flag in Path message N N | | D. IPv6 support | | 1. Big addresses Y Y | | 2. Flow Id support be Y | | E. Filter spec formats: | | 1. (mask,val) N N | | 2. Protocol-specific format Y Y | | 3. Pseudo-machine N ? | | F. Styles | | 1. WF, FF Y Y | | 2. DF hps Y? | | 3. Merging WF with DF or FF N N | | 4. Other styles N Probably | | G. Negotiation Models | | 1. OPWA (1-pass w/advertising) be Y? | | 2. Two-Pass ffs ? | | H. General container transport ? Y | | 1. RSVP msg syntax Y Y | | 2. All-purpose resv protocol N ? | |______________________________________________________| | Key: | | hps = ``high-priority study'' | | be = ``best effort'' | | ffs = ``for further study'' | |______________________________________________________| There was discussion of some of the features: A. Advanced Interface to routing For the most part, an advanced routing interface is to be left for version 2, or at least ``1.5.'' However, fast reservation recovery is a high priority study item; routing should notify RSVP of route failure/change, and RSVP should use this notification to trigger an immediate refresh to adapt to the route change. B. Session Group Wroclawski presented his idea for a ``session group'' within RSVP, motivated by earlier presentations by himself and Lixia Zhang on MMG. It was decided that this should probably be in version 1, if we can design and document it. C. Drop flag in Path message Agreed that the current Drop Flag in PATH messages should be omitted, since routing should decide whether to forward packets (see earlier discussion by Lixia Zhang). Even if RSVP did have the drop/best-effort capability, it should be part of the QoS description in a Tspec, not a separate flag in the Path message. D. IPv6 support Should make a best-effort attempt to put flow ID support in version 1.1. It is very unsettled as to what flow IDs mean in IPv6, but probably can use them as a hint for routing. We need to worry about transition problem and inter-operation. E. Filter spec formats If a new major transport protocol should emerge, we can always put out a new filterspec format type to match. However, new transport protocols may conveniently put their ports in the same place as UDP. F. Styles WF, FF should both be in version 1, although some problems with WF need to be ironed out. Noted that could fake WF by turning into a new FF style that allows sharing, but do not pursue this now. There was some question as to whether DF should be optional or not in version 1, or to version 2. Dave Clark suggested that DF is important to allow hosts with a small incoming pipe to watch a few sources; however, this can be done with FF. Daniel Zappala questioned whether the standby reservation capability of DF has been shown to be necessary. G. Negotiation Models It was noted that the INTSERV Working Group recommends that RSVP incorporate advertising into version 1 of RSVP. The RSVP Working Group agreed to make a best effort try.