RSVP Minutes
43rd IETF in Orlando, FL
Steven Berson
Thursday December 10 1300-1500
RSVP Working Group Minutes
A. WORKING GROUP STATUS
------------------------
Three documents still need to go to Working Group Last Call: the
Diagnostics draft, the tunnels draft, and the Integrity draft. The
Diagnostics and Integrity drafts should be ready to go to last call
after this meeting. A problem that has come up with the tunnels spec
will be discussed.
The Opengroup has published the RAPI interface. An HTML version is
available on the web as
http://www.opengroup.org/publications/catalog/c809.htm
Postscript and printed versions are available for a nominal charge.
B. DIAGNOSTICS DRAFT
---------------------
Lixia Zhang talked about draft-ietf-rsvp-diagnostics-05.txt on RSVP
Diagnostic messages. There were some minor text changes and lots of
polishing since the last IETF. The only technical change is an added
description of the limitation of the current approach. To get around
the ``black holes'' caused by RSVP routers that do not support
Diagnostic functions, RSVP diagnostic design uses traceroute to find
the next RSVP+diagnostic node after the blackhole; this approach works
well with multicast reservations but breaks in case of asymmetric
unicast routes. These limitations are described in the draft.
There is an implementation available at UCLA at:
http://irl.cs.ucla.edu/
The meeting agreed to advance this specification to Working Group
Last Call.
C. INTEGRITY DRAFT
-------------------
Bob Lindell talked about draft-ietf-rsvp-md5-07.txt on RSVP
cryptographic authentication. RSVP provides integrity and
authentication (but not confidentiality), with protection against
replays. Lindell summarized key management issues: (1) keys have
lifetimes, (2) the key identifier names both the key and the algorithm,
(3) keys are distributed Out-Of-Band (OOB), and (4) keys need to be
distributed to all next hops. The last issue affects large LANs.
Changes in the draft include: (1) Key ID now need only be unique per
sender, not globally unique, (2) a handshake-OK flag has been added,
(3) the spec now defines a key-management abstract interface, and (4)
challenge and response messages are now distinct. The new handshake-OK
flag is set by a sender that is prepared to respond to a challenge from
the receiver; this handshake is needed to securely establish an initial
sequence number for integrity objects. If the handshake-OK bit is not
set, the receiver can avoid waiting a full timeout period for a
response that will never come.
There are several competing design goals, particularly
auto-configuration, that make in-band key distribution desirable. The
issue that held back the draft was the key replay problem, which is now
addressed. Some people also want the document to include some key
management provisions, which the current draft leaves for other
documents (and probably for other WGs). The meeting consensus was
that a combined draft would be better, but that the WG should go ahead
with a last call on the current draft if it takes too long to write the
combined draft. The decision was to give Fred Baker and Tim Moore two
months to update the draft; otherwise, the current draft will go to
last call, and key management will be in a separate draft.
D. TUNNELS
-----------
John Wroclawski (representing the int-serv working group, as well as
being a co-author) has noted one problem in
draft-ietf-rsvp-tunnel-01.txt. The problem concerns the dynamic
binding of end-to-end RSVP sessions to pre-configured RSVP sessions
over an IP-in-IP tunnel. The current draft assumes that the end-to-end
PATH messages carry enough information to choose among multiple tunnel
sessions. John pointed out, however, that RSVP semantics requires that
the receving end be able to make this binding decision dynamically.
That is to say, the binding should be determined only when the
reservation message from the receiver arrives.
Discussion centered around whether the current draft can go to last
call with only a description of the issue, or whether a solution for
the issue is required at this stage. Lixia pointed out that the
design goal is *simple* support for RSVP reservations over IP
tunnels; because the RSVP sessions over the tunnel are set up through
a management interface, the policies regarding which end-to-end
session can use which tunnel session are presumably made at the same
time. Hence the current design does not go as far as providing
the receiver the ability to dynamically change the binding. The
consensus was that it was OK to go to last call with a clear
description of the issues, but it would be desirable to solve the
problem if a simple solution exists. The decision was that Lixia
Zhang and Andreas Terzis at UCLA would have up to two months to revise
the draft to solve these problems; otherwise, the draft will go to
last call with only an added description of the issues.
E. RSVP AND DIFF-SERV
---------------------
John Wroclawski talked about the relationship of RSVP and Int-Serv to
Diff-Serv. This issue was initially raised in the diffserv WG (and in
the aggregation work presented in this working group in Chicago), but
parts of the work are being transferred to the RSVP and the ISSLL WGs.
The current work is in the following drafts:
draft-ietf-diffserv-rsvp-01.txt
draft-bernet-diffedge-01.txt
draft-berson-rsvp-aggregation-00.txt
draft-guerin-aggreg-rsvp-00.txt
In one model, a diff-serv cloud can simply be treated as a single
logical link. It was agreed that ISSLL WG will undertake the design of
this approach and the definition of mappings of Int-Serv services onto
Diff-Serv services that it requires. This approach also has two
short-term issues that are specific to the RSVP WG: how to pass RSVP
messages without processing through parts of a diffserv cloud, and how
to use the DCLASS object to pass diffserv class information.
However, this model has important restrictions with respect to support
for multicast and heterogeneous reservations, issues that have been
central to Int-Serv and RSVP. Resolving these issues appears to
involve protocol design in which limited amounts of RSVP-like flow
state will be required at points inside the cloud. This design ought
to take place within the RSVP WG. Another RSVP WG issue is how (and
if) to do admission control within the cloud as suggested in the
aggregation drafts. There was general consensus that the RSVP working
group should be looking at aggregated flows, using diff-serv as one
mechanism. However, the WG charter will need to be updated.
There was some confusion about what the DCLASS object is. It is
supposed to be like the TCLASS object used in the SBM draft
(draft-ietf-issll-is802-sbm-07.txt), but Yoram Bernet took an action
item to write up the DCLASS/TCLASS objects and mail it to the WG.
F. MPLS
--------
Lou Berger talked about draft-ietf-mpls-rsvp-lsp-tunnel-00.txt, which
discusses extending RSVP for use with MPLS. Basically, there will be
a large number of RSVP messages in a large MPLS cloud, and message
processing might take up too much router time. This draft proposes a
series of changes to RSVP to reduce message load. These changes
include having message IDs, ACKing all messages by message ID, and
using HELLO messages to verify that neighboring routers are alive.
It uses these facilities to provide local hard state for RSVP
signaling.
There was no general consensus on this proposal. Some felt that these
proposed changes add a lot of complexity without a clear need. Others
felt that it is the right direction to move.
G. PARAMETER-BASED ADMISSION CONTROL (PBAC)
--------------------------------------------
Marc Greis talked about draft-greis-aggregation-with-pbac-00.txt which
uses measurements as well as aggregate reservation data to do
admission control for an aggregated RSVP. He showed simulation data
that showed a more conservative admission control at a cost of a small
number of extra messages.
H. SCRAPI
----------
Bob Lindell talked about draft-lindell-rsvp-scrapi-01.txt which
describes a simplified API for RSVP, based on RAPI. SCRAPI does not
require an application to specify detailed flow specs or callbacks.
SCRAPI uses two main calls, scrapi_sender() and scrapi_receiver(),
which take simpler parameters than RAPI and use defaults for other
parameters. SCRAPI provides no detailed error messages; instead, it
returns a 3-valued reservation status, green (success), yellow
(pending), or red (error). Several applications using SCRAPI are
distributed as part of ISI's RSVP applications release (see
http://www.isi.edu/rsvp/release.html). There are still some issues:
CONFIRM messages are not reliable, and the error model for multicast
can still be complex.