[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
- [Monami6] Comments on draft-petander-mip6-mbb-00.… Christian Vogt
- Re: [Monami6] Comments on draft-petander-mip6-mbb… Henrik Petander
- Re: [Monami6] Comments on draft-petander-mip6-mbb… Christian Vogt