1. RSVP WG 13th July 1999 1 RSVP State Reduction (consensus proposal) http://www.ietf.org/internet-drafts/draft-berger-rsvp- refresh-reduct-03.txt 45th IETF, Oslo, Norway Lou Berger - LabN consulting Der-Hwa Gan - Juniper Networks George Swallow - Cisco Systems Ping Pan - Lucent (Reported by Andrew Smith - Extreme Networks)

2. RSVP WG 13th July 1999 2 Design Goals Reduce volume of RSVP messages in steady state Improve latency in the face of unreliable RSVP signaling … of course, more reliable transmission would be a good thing too (e.g. use high precedence, layer-2 priority) Cannot do this by just playing with refresh intervals - the 2 goals above require adjustment in opposite directions

3. RSVP WG 13th July 1999 3 RSVP Interim Meeting - April Consensus on 4 mechanisms: Message “bundling” MessageID object Message ACK/NACK object and message Summary Refresh message Not sure about... State compression with simple “state signature” Berger/Gan/Swallow/Pan - see later State compression with possible partial state recovery Wang/Terzis/Zhang - see later

4. RSVP WG 13th July 1999 4 RSVP Bundle Message Set of normal RSVP messages, bundled together in a single IP datagram with header header has a new RSVP message type “Bundle” new RSVP flag to advertise “bundle capable” node can contain any RSVP messages that need to go to the same next RSVP hop (no nesting of other Bundle messages though) Just reduces number of messages - that’s all Cannot use for M’cast Path/PathTear unless know that routing next hop is RSVP node and it is a point-to-point interface

5. RSVP WG 13th July 1999 5 MESSAGE_ID Extension New MESSAGE_ID object 32-bit increasing ID with 24-bit epoch number contain “Summary_Capable” flag (see later) MESSAGE_ID is shorthand for complete state Add this to original “trigger” RSVP Path/Resv messages to identify the session In subsequent Srefresh messages, MESSAGE_ID implies “state for this session has not changed”

6. RSVP WG 13th July 1999 6 MESSAGE_ID ACK Extension New MESSAGE_ID ACK object similar to MESSAGE_ID syntax 1 new message type: “Ack” contains only MESSAGE_ID ACK objects use when there is no other convenient message going there Supports acknowledgements for reliability ACK_Desired flag in MESSAGE_ID object can be set to request an ACK Refresh_NACK flag to deny knowledge (see later) Can use faster initial refresh timer with exponential backoff

7. RSVP WG 13th July 1999 7 MESSAGE_ID ACK issues Just say “Multicast” need to randomise ACKs for multicast Path/PathTear generator of the ACK request should only expect a single ACK although it may get more must continue to send normal Path refresh messages in order to handle new receivers on session RSRR needs to indicate now may next hops

8. RSVP WG 13th July 1999 8 Summary-Refresh Extension New “Srefresh” RSVP message contains a list of MESSAGE_ID objects for sessions to be refreshed acts as either Path or Resv refresh Typically only include those sessions that share same Destination IP But may include more sessions if know next hop is RSVP capable and sessions are unicast if know next hop is RSVP capable and interface is pt-to-pt NACK indicates you must use normal RSVP