1 / 8

Lou Berger - LabN consulting Der-Hwa Gan - Juniper Networks George Swallow - Cisco Systems

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

brone
Download Presentation

Lou Berger - LabN consulting Der-Hwa Gan - Juniper Networks George Swallow - Cisco Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RSVP State Reduction(consensus proposal)http://www.ietf.org/internet-drafts/draft-berger-rsvp-refresh-reduct-03.txt45th 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. 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 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 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. 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. 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. 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. 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

More Related