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

Christian Vogt <chvogt@tm.uka.de> Wed, 19 October 2005 07:00 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7wT-0005c3-Gi; Wed, 19 Oct 2005 03:00:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7wR-0005by-Al for monami6@megatron.ietf.org; Wed, 19 Oct 2005 03:00:51 -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 DAA25647 for <monami6@ietf.org>; Wed, 19 Oct 2005 03:00:41 -0400 (EDT)
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+pgkgEVN3ojvI5naubdX7B2xQQS3q6pu0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES884-00016F-Pn for monami6@ietf.org; Wed, 19 Oct 2005 03:12:56 -0400
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1ES7wG-0007EK-Lj; Wed, 19 Oct 2005 09:00:45 +0200
Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1ES7wD-00025y-EJ; Wed, 19 Oct 2005 09:00:37 +0200
Message-ID: <4355EF14.8060403@tm.uka.de>
Date: Wed, 19 Oct 2005 09:00:36 +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
Subject: Re: [Monami6] Comments on draft-petander-mip6-mbb-00.txt
References: <43553B5F.6060601@tm.uka.de> <36cb7a210510181701m2a11cb3bn8d8d97071a1ee43@mail.gmail.com>
In-Reply-To: <36cb7a210510181701m2a11cb3bn8d8d97071a1ee43@mail.gmail.com>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
X-Spam-Score: -16.9 (----------------)
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: tm-ro2@tm.uka.de, Monami6 WG <monami6@ietf.org>
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="===============0595249130=="
Sender: monami6-bounces@ietf.org
Errors-To: monami6-bounces@ietf.org

Hi Henrik,

 > Actually we assume only that MN performs MIPv6 handoff at this time.
 > L2 handoff and IPv6 link attachment can be performed before the MIPv6
 > handoff, if MN is capable of connecting to both the old and new access
 > router simultaneously, which is required for make-before-break
 > handoffs, which our draft focuses on. In successful make-before-break
 > handoffs the delays of L2 handoff and IPv6 link attachment do not lead
 > to packet loss. The handoff procedure for a make-before-break handoff
 > would be:

ok, if the MN has multiple interfaces, it can set up the 2nd interface
at any time btw. BU transmission and BA reception.

However, you can do a make-before-break handoff even with a single
interface.  This is actually what we did in
draft-vogt-mobopts-early-binding-updates-00.txt.

Nonetheless, the scope of your draft is two interfaces, I see this.  And
given that you are using two interfaces, you can do a care-of-address
test on the 2nd while communicating with the 1st.

I agree with the rest of your comments.

Take care!

- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


Henrik Petander wrote:
> Hi Christian,
>
> Thanks for reading the draft and commenting it. Replies to your
> comments are inline.
>
> On 10/19/05, Christian Vogt <chvogt@tm.uka.de> wrote:
>
>>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).
>
>
> Actually we assume only that MN performs MIPv6 handoff at this time.
> L2 handoff and IPv6 link attachment can be performed before the MIPv6
> handoff, if MN is capable of connecting to both the old and new access
> router simultaneously, which is required for make-before-break
> handoffs, which our draft focuses on. In successful make-before-break
> handoffs the delays of L2 handoff and IPv6 link attachment do not lead
> to packet loss. The handoff procedure for a make-before-break handoff
> would be:
>
> 1) Find a suitable next AR using idle interface A, while using
> interface B for active communications via old AR.
> 2) Perform L2 handoff and IPv6 link attachment on interface A with new AR
> 3) Perform MIPv6 handoff to switch traffic to new interface.
>
> In the draft we focus only on 3), since 1) and 2) can be done with the
> existing protocol specs for IPv6 (in handoffs to foreign networks). I
> hope this clarifies the intent of our draft.
>
>
>>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.
>
>
> This is true in the case of break-before-make handoffs, in which MN
> loses connectivity with its old AR before establishing connectivity
> with a new one. However, for make-before-break handoffs L2 handoff
> delay does not have a direct connection with packet loss, only on the
> probability of being able to finish the handoff before connectivity at
> the old CoA ends.
>
>
>>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.
>
>
> Thanks for the pointer. If your draft is used with make-before-break
> handoffs, it will reduce the time required for handoff. Shortened
> handoff time increases the probability of a make-before-break handoff
> finishing before the connectivity at old CoA ends.
>
> Best regards,
> Henrik


_______________________________________________
Monami6 mailing list
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6