CURRENT_MEETING_REPORT_
Reported by Lixia Zhang/Xerox PARC and Robert Braden/USC-ISI
Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)
The RSVP Working Group met on Wednesday and Thursday. The primary
objective of the meeting was to review and discuss the major revision to
the protocol specification that resulted from the San Jose meeting, with
the intent of moving towards standardization.
Review of Revised Functional Specification
Bob Braden gave a presentation on the revised Functional Specification,
emphasizing the changes from the November 1994 draft (04). The new
draft is: draft-ietf-rsvp-spec-05.ps, .txt.
Modifications/additions:
o RSVP session: `generalized port' is (UDP/TCP) port.
o Flowspec: Rspec and Tspec.
o Filterspec: `generalized port' is (UDP/TCP) port.
o If link layer is active (e.g., ATM), the traffic scheduler does
whatever is necessary to obtain desired QoS from link (e.g., use
signaling protocol).
o Added OPWA.
o Dynamic filter style moved to appendix: high priority study.
o Format of RSVP messages completely changed to small fixed header
followed by sequence of variable-length typed objects.
Issue from Berson: Whether to forward a Resv message when an error is
found, is still open. Note that reservation error may still occur even
with OPWA.
Issue: Recovery from routing changes: should we do local recovery, or
end-to-end? The argument for local recovery is protocol simplicity; no
additions are necessary. Arguments for end-to-end recovery are: (1)
RSVP cannot recover faster than the underlying routing protocol's
reaction time, and (2) local recovery has the danger of making
reservation along wrong paths. Comment from Farinacci: We have
experienced that in PIM implementation -- whenever topology changes,
hosts often rejoin the multicast group through wrong interface, and have
to readjust later.
Fixed header includes length, since we did not include a pseudo-header.
Question: Is pseudo header a good thing anyway? (The audience seemed
to reached consensus of not using pseudo-header). It was noted that the
explicit message length field is redundant, since it can be easily
derived by parsing the objects in the message.
Issue: Why not just define one filter type instead of two? Braden:
allows different address families: currently IPv4 and IP6, in the
future perhaps IPX, etc.
Issue from Ajit: RSVP interface has to be redesigned to match the
latest multicast routing release. Braden: Yes, RSVP has a
routing-dependent adaptation module to interface to routing. Farinacci:
Better not to design a protocol based only on the implementation one
knows today.
Have one credential per sender in Path messages, but only one credential
per reservation -- this is due to resv merging, in order to scale.
In WF style, an optional filter specification is allowed, to support
partial wildcarding: e.g., (host,*) or (*,port), as well as a full
wildcard sender (*,*). Not clear this is useful, but it is an easy
generalization.
Issue: How to compute merge sender_Tspecs in order to compute
reservation = MIN(Tspec, sender_Tspec). It seems that they must be
summed. Question: why should different receiver and sender Tspec be
allowed? Braden: to prevent over-reservation on access links.
Question: Who is working on the RSVP/routing interface issue now?
Braden: Daniel Zappala, with Deborah Estrin. Will make sure document
is presented to the working group.
Presentations on Two Major Open Issues
Issue One: Wildcard Filter Looping
Steve Berson presented a review and proposed solution to the two
problems posed by the wildcard filter style (more generally, by any
style with wildcard scope) with looped topologies: unwanted
reservations, and self-refreshing loops. This was joint work with
Daniel Zappala.
Their proposed solution: Record the upstream senders for each outgoing
link and carry that sender list in each Resv message going upstream. If
the underlying multicast routing protocol uses shared trees, then this
information not necessary.
The main issue with the proposed solution is scalability: it causes a
linear increase in the size/number of Resv messages with the number of
senders. However, Zappala and Berson pointed out that its scaling is
the same as the scaling of Path messages and of (source-tree-based)
multicast routing.
Braden introduced a related proposal: Add a new reservation style,
``shared explicit.'' This style would allow a receiver to explicitly
list the senders to use a shared reservation. It would also be possible
for the application to call for a wildcard SE reservation, with the RSVP
daemon filling in the complete sender list from the path state. The
result would be exactly analogous to a WF reservation using the
Zappala/Berson scheme.
There was a lengthy discussion of the issues. Wroclawski strongly
objected to the proposed WF modification, due to scaling. He suggested
that it could seriously impact possible future applications. Others in
the room attempted to construct alternative solutions (and there were
later claims of success, although no alternative has yet been
documented).
Issue: our application requires reservation ACK. Braden: Can be added
into OPWA messages.
There seemed to be general agreement that the SE style (without the
wildcard) was a useful feature that should be in the specification.
There was not a clear consensus on what to do about wildcard filters.
Zhang argued for taking some time to look for a better solution.
Issue Two: IP6 Flow Label in RSVP
Lixia Zhang presented a proposal on how to support IP6 flow labels in
RSVP, to speed packet classification. IP6 flow labels have the
constraint: all packets carrying the same flow label must have the same
source and destination address. This limits the use of flow labels to
demultiplexing packet streams within each source host.
She proposed that a flow label could simply replace the port number and
protocol ID fields in an RSVP filter specification. There was general
agreement with this approach.
Implementation Status and Vendor Plans
o Prototype RSVP daemon: Steve Berson, ISI
Release 2.1 of the RSVP code was released on 17 March. The rsvpd
in 2.1 is functionally the same as release 2.01, but 2.1 has many
updates and fixes. Release 2.1 also includes the modified
applications from MIT and a modified mrouted.
o Applications using RSVP: Bobby Minnear, MIT
MIT has updated their Tk/Tcl-based RSVP interface program tkrsvp to
use the new API. This supports RSVP reservations for vat, for
example. They have also modified nv to support RSVP. This code is
part of the latest ISI release.
o Traffic control kernel using RSVP: John Wroclawski, MIT
MIT has done a FreeBSD implementation of a traffic control kernel,
including CSZ scheduling with link-sharing.
o Solaris implementation: Don Hoffman, Sun
The Solaris RSVP+CBQ version of the release 2.01 RSVP code is
available now on the net. Releast 2.1 will be available very soon.
o Bay Networks: John Krawczyk
Bay Networks is implementing multiple sources of reservation
information: RSVP, ST2, and static configuration for reserved
flows. Their architecture will have these sources as parallel
inputs to the scheduler. Their timetable:
- Ship ST2 implementation by summer (September)
- Ship RSVP implementation by fall (October)
o Cisco: Dino Farinacci
Multicast routing has been widely deployed inside Cisco (PIM), they
plan to ship WFQ by July, and RSVP by the end of the year.
Discussion of More Open Issues
o Flowspec format
Braden suggested that the format of flowspecs should be defined by
the INTSERV Working Group, with an appropriate indirection in the
RSVP specification.
Issue: since one cannot leave a hole in real code, whose
responsibility it is to define a minimal flowspec that vendors can
implement now?
o More on WF style looping
Zhang: Some progress has been made towards resolving WF loop
problems. The basic idea is that: (1) PATH messages do not loop
themselves; (2) if RESV messages are made to reverse the paths of
PATH messages precisely (this is not done in the current
specification), they will be loop-free and travel no further than
PATH messages.
o UDP encapsulation revisited
Presentation by Braden: UDP encapsulation turned out to be more
complex than expected. Two different well-known multicast
addresses need to be used for encapsulation.
UDP encapsulation allowed RSVP to work through PARC firewall (their
security people did not link a new IP type, but they understood how
to handle UDP packets with given address and port numbers). But
there was a multicast tunnel, which required a special provision:
unicasting Path messages from host to first-hop router.
Question by Wroclawski: Getting worried about hack after hack,
hence losing architectural oversight. Please summarize all the
hacks that have been proposed so far in one place for assessment.
Question by Baker: Why not just UDP encapsulations everywhere and
forget protocol ID 46? Farinacci: Would make it much harder/less
efficient to grab RSVP packets in routers.
o Functionality and reliability issues
- Require RPF check on received messages?
- Do we need to send more than one copy of teardown messages?
- How to use IP6 flowIDs? [Resolved earlier.]
o Security issues
- Security data
- Do we need credential for teardown? [The answer seemed to be
no.]
- What if a credential changes?
Question: What is needed for Version 1 specification in terms of
security considerations?
- RSVP needs the same integrity check used by routing protocols
today.
- There was some discussion of credentials. USC/ISI and MIT are
working on the administrative model for credentials. There is
a note that will be distributed to the working group.
Question: Should the credential issue be left for future study
or defined now? (Lots of discussion).
Advanced Reservations
o Using RSVP for advanced reservations: Mikael Degermark, University
of Lulea, Sweden
Question: Receivers may not be all turned on yet when you make
reservations one month in advance, and the topology may also change
in between. Therefore RSVP does not seem to be the right vehicle
for advanced reservations in the way as the authors have proposed.
Response: RSVP messages can be sent very slowly in advance of the
event.
o The `RBONE' proposal for using RSVP in the MBONE: Steve Casner, ISI
Comments: A proper analogy between advanced reservation and RSVP
is airline reservations: airlines make advanced reservations by
selling tickets, air traffic controller controls the real traffic.
Issue: Would the proposed advanced reservations motivate people to
all make advanced reservations? What would be the impact?