[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Simplified REAP description
- To: shim6 <shim6@psg.com>
- Subject: Simplified REAP description
- From: Erik Nordmark <erik.nordmark@sun.com>
- Date: Thu, 27 Oct 2005 09:44:49 -0700
- User-agent: Mozilla Thunderbird 1.0.6 (X11/20050720)
I tried to describe REAP without resorting to a state machine
description (based on my understanding from the message exchanges in the
draft) and this description seems a lot simpler than the state machine
(which could very well be due to me not understanding the state machine).
Erik
----
First we have the FBD logic, which is basically that when a host receives
a payload packet and the FBD timer isn't running, it sets a 3 second timer.
If it sends any packet (payload, or shim6 control packet) then this timer
is cleared. Should the timer fire, it sends a FBD keepalive (called payload
reception in REAP).
Thus reception of a FBD keepalive will not by itself cause the sending
of a FBD keepalive.
The assumptions is that we have things that trigger going into an explore
phase. The triggers are:
- sending a packet and not receiving anything (payload, keepalive, or
other shim6 control packet) within 10 seconds
- receving a REAP Probe message with iseeyou=no
- what there is a local indication that a local locator is no longer
usable
(in that case it would make sense to also tell the peer to not even try
that locator, e.g. somehow include the semantics of a preference
option?)
Once the context has entered the explore phase, it continues to explore
until it finds a working locator pair, i.e. until it receives a REAP
probe with iseeyou=yes.
The only time it would abandon the explore is when the context is garbage
collected e.g. due to it not being used by a ULP any more.
With this approach, the rules for handling the complete protocol
becomes something like this.
Receiving a payload packet
--------------------------
If the keepalive timer isn't running, then start it.
Stop the send timer (if it was running).
Receiving a keepalive or other shim6 control packet
---------------------------------------------------
Stop the send timer (if it was running).
Sending a packet (payload, keepalive, or other control packet)
--------------------------------------------------------------
Stop the keepalive timer (if it was running).
Only for a payload packet:
If the send timer isn't already running, start it.
Timeout due to having received but not sent
-------------------------------------------
When the keepalive timer fires (after 3 seconds),
we send a FBD keepalive (a payload reception report).
Timeout due to having sent but not received
-------------------------------------------
When the send timer fires (after 10 seconds), we enter the explore phase
and start exploring by sending an event with iseeyou=no.
(We don't do this if we are already in the explore phase.)
Receiving a packet with iseeyou=no
----------------------------------
If the context is already in explore phase, ignore the packet.
(From a congestion control perspective, it is presumably ok to use the
reception of such a packet as a "self-clock" and use it to send another
Probe
packet, independent of the binary exponential backoff for Probe packets sent
when no Probe was received.)
Otherwise, enter the explore phase and send the first Probe.
Receiving a packet with iseeyou=yes
-----------------------------------
If this is a "payload reception report", then it is just a FBD keepalive and
is handled as any shim6 control packet above (resetting timers).
If it is an "event reception report", it indicates that we can terminate
the
explore phase.
If the host has not yet sent a "iseeyou=yes" event report, it needs to
send one in response to this packet.
---