1 / 11

Shim6 Reachability Detection

This document discusses the reachability detection mechanism in Shim6, including the use of keepalives and probe packets for detecting failures and maintaining bidirectional reachability.

donaldmarshall
Télécharger la présentation

Shim6 Reachability Detection

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. draft-ietf-shim6-reach-detect-01.txt IETF64, shim6 wg, Vancouver, 2005-11-11 • John Loughney (presenting) • Iljitsch van Beijnum (slides)

  2. (un)reachability • Assume list of potentially reachable local addresses of appropriate scope • Addresses for correspondent and their preferences are known from shim context establishment/signalling

  3. preferences • Preference for each address determined by: • "Strong" value p1: higher is always better • "Weak" value p2: determines load balancing weight relative to other addresses with same p1 value • Administrative interface undefined as yet

  4. unidirectional reachability • Relatively uncommon for normal failures • But: assuming bidirectional reachability when it's unidirectional is deadly • Ingress filtering can easily create unidirectional reachability • So: work with unidirectional paths

  5. keepalives • Detect failures through keepalives • Keepalive: IPv6 + 8 byte shim6 header • Keepalives suppressed when: • No incoming data traffic (= context idle) • Already normal outgoing traffic • So only keepalives for unidirectional protocols + some active/idle transitions

  6. quick vs full • Keepalive interval 10 seconds • When one keepalive missed: quick reachability check with current address pair • When quick check fails: full exploration • Quick vs full: packet format largely the same, quick is shorter (fewer struct_p's)

  7. packet format • Encapsulated in shim6 header (allow for reuse in other protocols) • Refer to both probes received from other side as well as probes we sent but haven't been acknowledged • Probe references through "struct_p" • Type/action bits include "request reply"

  8. fields • Housekeeping: type/action (8 bits), number of probes sent and received (both 8 bits), optional data length (8 bits) • struct_p for this probe • 0 or more struct_p for probes sent earlier • 0 or more struct_p for probes received • Options

  9. struct_p • Probe structure: • source locator (128 bits) • destination locator (128 bits) • sent timestamp (32 bits, in ms) • time since reception (32 bits, in ms) • nonce (32 bits) • seqnum (32 bits)

  10. granularity • Keepalives are ULID-to-ULID (per context) • Address pair probing is host-to-host • So contexts put address pairs in "to test" host-wide pool (until context idle 240 sec) • Test pairs with highest p1 preference first • When working address pair found: keep testing pairs with at least one better p1

  11. timing • Currently: • Limit probes to average of 60 per 300 seconds host-wide • But use aggressive timeouts (starting at 200 ms) first 15 - 20 seconds • Is too conservative for busy hosts, though

More Related