State machine / failure detection / rehoming support

<john.loughney@nokia.com> Mon, 17 January 2005 13:02 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Mon, 17 Jan 2005 13:05:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: State machine / failure detection / rehoming support
Date: Mon, 17 Jan 2005 15:02:51 +0200
Message-ID: <FBA7FB88A51E804BA4A111CDFD2DE638089CE6@esebe105.NOE.Nokia.com>
Thread-Topic: Mailing list and draft charter for new multihoming BOF/WG
Thread-Index: AcT6OASVnrKzuIpQSSm/ESY+F71JQQCW8e3g
From: john.loughney@nokia.com
To: shim6@psg.com

Following on my previous mail,

I'd suggest considering some of the material in the "Multi6 Failure Detection" draft,
http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt	
be taken as a base for the deliverable: "failure & rehoming event description" / 
"state machine."  However, I'd suggest that Section 5 which actually defines a
state machine is would better fit a protocol state machine discription and be
in the main protocol document.  Additionally, I'd much rather have the draft
generalized into a failure & rehoming detection draft.  

Its reasonable to think that a host might have some watchdog associated with a 
particular path, and when the path is available, the shim6 protocol might want
to rehome to that particular path. A scenario is that there can be a failure
on a particular path, so when the failure is detected, the shim6 switches to
another path.  After the original path is repaired, the host might like to rehome
to it.  This is something that SCTP does, for example.

Comments?
John