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.