Subject: draft minutes for Oslo WG meeting

From: Lixia Zhang <[email-masked]>
Date: Sun, 12 Sep 1999 23:21:18 -0700

When I promised to get this done last Tue, I grossly under-estimated the time
needed.  Anyway, here's a draft, comments and corrections appreciated.

Lixia
-----------------------------------
RSVP Working Group minutes
45th IETF in Oslo, Norway

RSVP WG met once in Oslo.  The meeting was chaired by Lixia Zhang, the
minutes prepared by Lixia Zhang

================================
TUESDAY, July 13 1999, 0900-1130
WG MEETING AGENDA:

I. SHORT PRESENTATIONS
   RSVP and Integrated Services with IPv6 Flow Labels 
                           (Bob Lindell on behalf of Berson)
   Changes to the DCLASS object (Yoram Bernet)
II. INTERIM MEETING RESULTS
   Briefing on the interim meeting result (Lixia Zhang)
   Recommended RSVP changes based on consensus
          from the interim meeting (Andrew Smith)
   RSVP refresh overhead reduction by Hello messages
                                            (Lou Berger)
   RSVP refresh overhead reduction by state compression
                                           (Lixia Zhang)
III. DISCUSSIONS:
   What protocol changes should be considered for standardization? 
   What for further experiments?
IV. DISCUSSIONS ON THE WG FUTURE: are we done?    

Required readings:
- Working group interim meeting minutes
- draft-yuhara-rsvp-refresh-00.txt
- draft-berson-rsvp-ipv6-fl-00.txt
- draft-berger-rsvp-refresh-reduct-03.txt
- draft-wang-rsvp-state-compression-02.txt
================================
I-a: RSVP and Integrated Services with IPv6 Flow Labels
     Bob Lindell (on behalf of Berson), ISI.
Bob Lindell gave an informational presentation enlisting a few perceived
issues
in RSVP's use of IPv6 flow labels. First, if not all IPv6 routers support the
use of flow labels, to facilitate incremental deployment one needs to define a
new FILTER_SPEC format which contains both the IPv6 flow label and the source
port.  In addition, there is no IPv6 API specified for an RSVP implementation
to acquire a flow label.  If the routing of a packet depends on the flow
label,
to make RSVP messages follow the same way as data packets the RSVP
interface to
routing will need access to the flow label.  Furthermore, use of flow label
may
raise security issues if a node can spoof a flow label (and source address) to
get preferred service or for a denial-of-service attack.

I-b: Changes to the DCLASS object
     Yoram Bernet, Microsoft.
Yoram Bernet also gave a short informational presentation on the
progress of DCLASS object definition to facilitate the use of RSVP in
diffserv context.  This work is currently being pursued for 
standardization in ISSLL WG.

II. RSVP WG INTERIM MEETING RESULTS

Lixia Zhang presented a brief overview of the interim meeting, which
was held on April 29, 1999 hosted by cisco, and 20 people attended
(see the meeting minutes for details
http://www.isi.edu/rsvp/sanjose.interim.meeting/mins9904).  The focus of
the meeting was on RSVP protocol performance improvement.  Specifically,
the WG was looking for mechanisms to minimize the delay in state 
setup/removal, and minimize the overhead in soft-state refreshment.  The
solution to the first issue is adding to the RSVP protocol an 
acknowledgment option, as first proposed by Berger et. al.  Soft-state
and ACK complement, rather than conflict, with each other. ACK assures
quick retransmission upon losses to propagate state changes promptly,
while soft-state is the last resort against all unexpected failure in 
checking state consistency and removing orphaned reservation.  The 
proposed solution to the second issue includes a range of different
approaches, as exploited by the remaining presentations.

Andrew Smith of Extreme Networks summarized the interim meeting
recommendations.  There were consensus on enhancing RSVP performance 
with four mechanisms:
- Message bundling
  When the link MTU is much larger than normal RSVP message size,
  one may bundle multiple RSVP messages in one to send to the
  next hop RSVP neighbor.  Bundling is a simple way to reduce the
  number of system interruptions in RSVP message handling.
- Message-ID object
  This is an optional option that may be sent in any RSVP message.
  The ID is a 32-bit increasing integer, together with a 24-bit epoch
  number. The epoch number changes after a reboot. An RSVP node can
  include a Message-ID object in a message and set an ACK_requested
  flag to solicit an acknowledgment from the receiving end.
- Message acknowledgment.
  Together with message-ID object we also define a message-ID-ACK
  object, which can be picky-backed on any RSVP message.
  We also define a new RSVP message type "ACK", which contains only the<<
  ACK object, for acknowledgment purpose when picky-backing is
  unavailable.
- Summary refresh messages
  Assuming that each RSVP session maintains the Message-ID of the last
  message of the session, this summary scheme proposes to use the
  message-ID as a short-hand in RSVP refreshes.  Combined with the
  message bundling idea, this approach can substantially reduce the
  number of RSVP refresh messages.
The above proposed changes can be introduced in a way that is 
completely backward compatible with the current RSVP spec for unicast
RSVP sessions.  Multicast sessions introduce open issues in message
bundling and acknowledgments.

George Swallow of cisco presented several proposals to the problem
Of refresh overhead reduction.  One approach (as described in 
draft-berger-rsvp-refresh-reduct-03.txt) is to eliminate periodic
RSVP state refresh entirely.  After an RSVP session is set up, a node
sets "Last_refresh" flag in the acknowledgment message to its neighbor.
Neighboring RSVP nodes exchange periodic hello messages only, assuming
that the RSVP state is intact in absence of node failures.  When an
RSVP node detects a neighbor failure and recovery, it sends original
RSVP refreshes to the neighbor for all the existing RSVP sessions.  
This scheme effectively turns RSVP to a hard-state protocol, which
requires explicit TEARDOWN messages to remove stale reservation state.
Some issues remain open, such as when a session changed path particiall,
how one may prevent an explicit TEARDOWN message from traveling too far
to tear down unchanged portion of the path.

George also described in detail an enhanced summary refresh approach.
Refresh object for unicast session includes 4-byte source address, and 
For multicast session both source and destination addresses.  He
suggested that we drop both the hello (i.e. hard-state) and message
bundling proposals, and focus the refresh overhead reduction effort
on use of summary messages.  George further proposed a 2-level scheme
of summary messages to effectively eliminate the concern about 
the overhead (look back, I did not fully understand the 2-level
scheme, hope George can provide a description here -- LZ)

A short discussion followed George's presentation.  Questions raised
regarding message bundling of different sessions, operational
experience for any of the proposed schemes (none has had any real
world experience), whether hosts necessarily support any of the 
proposed features given they mostly serve scaling purpose at the core
of the network, the potential complexity of a multiple level scheme,
and the impact of long lasting sessions (e.g. when used in MPLS) on
the design.

As the last speaker on proposed changes to RSVP, Lixia Zhang presented 
a refresh overhead reduction scheme by state compression.  Basically,
each RSVP router R groups the RSVP state by the neighbors the state is
sent to.  For each neighbor, R hashes all the shared sessions onto a
hash table, then computes a checksum over the state of one or more RSVP 
sessions hashed to each table entry.  R may choose either send to the 
neighbor this stream of checksums from the hash table in place of normal
RSVP refreshes, or further reduce the size of exchange by building a
tree structure on top of the hash table and send to the neighbor only
the top of the tree as one compressed digest message for refresh purposes.

III. After some discussion, the WG reached consensus to 
(1)move 4 of the proposed protocol changes (MESSAGE_ID object, 
   ACK option, message bundling, and use of shorthand state ID in 
   refreshes) to standard ASAP.
(2)terminate or dormant the WG (or going dormant?) after finishing (1).
(3)Other proposed changes, such as hello+last_refresh (Berger), use
of state compression in refreshes (UCLA), and the hierarchical
state summary (Swallow) will be further pursued individually, 
and be brought to IETF for standardization when they are ready.

Action (1) is expected to be done via mailing list soon after Oslo.
no interim meeting is scheduled at this time.

-----------------