[Monami6] Comments on draft-petander-mip6-mbb-00.txt

Christian Vogt <chvogt@tm.uka.de> Tue, 18 October 2005 18:14 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvyV-0008RQ-Rk; Tue, 18 Oct 2005 14:14:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERvyT-0008PC-H7 for monami6@megatron.ietf.org; Tue, 18 Oct 2005 14:14:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20137 for <monami6@ietf.org>; Tue, 18 Oct 2005 14:14:00 -0400 (EDT)
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18sx3mbTLJl65GMs48zudhStdNdf5XW6co=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERwA3-0006AS-8R for monami6@ietf.org; Tue, 18 Oct 2005 14:26:07 -0400
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1ERvyG-0008Ca-U0; Tue, 18 Oct 2005 20:14:00 +0200
Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1ERvyF-0000oG-9F; Tue, 18 Oct 2005 20:13:55 +0200
Message-ID: <43553B5F.6060601@tm.uka.de>
Date: Tue, 18 Oct 2005 20:13:51 +0200
From: Christian Vogt <chvogt@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: henrik.petander@nicta.com.au, eranga.perera@nicta.com.au
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
X-Spam-Score: -17.4 (-----------------)
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: Mark Doll <doll@tm.uka.de>, TM-RO2 <tm-ro2@tm.uka.de>, monami6@ietf.org
Subject: [Monami6] Comments on draft-petander-mip6-mbb-00.txt
X-BeenThere: monami6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Monami6 WG <monami6@ietf.org>
List-Id: Monami6 WG <monami6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/monami6>
List-Post: <mailto:monami6@ietf.org>
List-Help: <mailto:monami6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1974096646=="
Sender: monami6-bounces@ietf.org
Errors-To: monami6-bounces@ietf.org

Hi Henrik, hi Eranga,

I took a good look at draft-petander-mip6-mbb-00.txt.  These are very
valuable considerations indeed.  A few comments below.

You assume that the MN affects the L2 handoff at the time it receives
the (first) Binding Acknowledgement (BA).  Note, however, that
performing the L2 handoff right upon sending the Binding Update (BU)
would mitigate the issue with binding inconsistencies at the MN and the
CN.  All packets that a CN/HA would send/tunnel to the MN prior to
processing the BU would be lost at the old care-of address (CoA).

If the L2 handoff takes a long time, initiating it as early as this
would be ok, since the MN would loose packets during the L2 handoff anyway.

But I agree that deferring the L2 handoff until BA reception has a
higher potential, especially when L2 handoffs become faster than they
are today.

You have to be a bit careful with correspondent registrations, though,
since those require a return-routability procedure.  I noticed that you
are doing research with multiple interfaces, which allows you to check a
new CoA while remaining attached to the old link.  But if the MN has a
single interface only, it will not be able to run a CoA test from the
old link.

You may want to take a look at the following draft, however:

   draft-vogt-mobopts-early-binding-updates-00.txt

This draft---in particular section 4, 7th paragraph and
onwards---defines how a single-interfaced MN can use Early Binding
Updates and Credit-Based Authorization for handoff anticipation and
proactive Mobile IPv6 signaling.  Here is a nutshell view:

(1)  The MN performs proactive HoA tests while communicating at the old
link.

(2)  When it detects that a handoff is imminent, the MN sends an Early
Binding Update (EBU) to each of its CNs.

(3)  The MN continues to communicate through the old CoA, at the old
link, until it receives the first Early Binding Acknowledgement (EBA).

(4)  The MN hands off to the new link.

(5)  The MN resumes communications through the new CoA.

(6)  The MN performs a concurrent care-of-address test with the each of
its CNs and subsequently sends a standard BU to each of them.

Some comments:

(a)  EBUs do not provide reachability confirmation, since no CoA test is
done to protect them, but...

(b)  ...CNs use Credit-Based Authorization to prevent misuse of EBUs and
protect the period until a concurrent CoA test is done and a standard BU
is received.

(c)  Credit-Based Authorization also prevents misuse of Alternate CoA
options, which in this case contain CoAs that differ from the IPv6
source address.

(d)  According to your draft, a CN must keep the old-CoA binding after
receiving an EBU.  A bit different than in your draft, the CN can
release that binding once it receives a standard BU.

(e)  A MN is assumed to learn about the prefixes used on the new link
through external mechanisms.

Best regards,
- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
_______________________________________________
Monami6 mailing list
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6