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

Henrik Petander <henrik.petander@gmail.com> Wed, 19 October 2005 00:01 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1P5-0000Kq-5x; Tue, 18 Oct 2005 20:01:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1P3-0000KX-6m for monami6@megatron.ietf.org; Tue, 18 Oct 2005 20:01:57 -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 UAA08058 for <monami6@ietf.org>; Tue, 18 Oct 2005 20:01:48 -0400 (EDT)
Received: from xproxy.gmail.com ([66.249.82.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES1ag-0000Eo-9k for monami6@ietf.org; Tue, 18 Oct 2005 20:13:58 -0400
Received: by xproxy.gmail.com with SMTP id t13so991539wxc for <monami6@ietf.org>; Tue, 18 Oct 2005 17:01:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZnoW0/rqQZJBKVgpSZW09y22qCL9f/f1Qi02ouQCdgwsZxT/swpKMC368KW+7tQvHHeDJpy1IV/qqtM0OlVThNdcGtbEc1rut0W0pegTkQy/am6w4I245iN54OPufiqLsK+83Y1XEmoEpG9/CShSICDrhsdfXNim3G4/q0/HsHQ=
Received: by 10.70.29.5 with SMTP id c5mr613wxc; Tue, 18 Oct 2005 17:01:56 -0700 (PDT)
Received: by 10.70.66.17 with HTTP; Tue, 18 Oct 2005 17:01:54 -0700 (PDT)
Message-ID: <36cb7a210510181701m2a11cb3bn8d8d97071a1ee43@mail.gmail.com>
Date: Wed, 19 Oct 2005 10:01:54 +1000
From: Henrik Petander <henrik.petander@gmail.com>
To: Monami6 WG <monami6@ietf.org>
Subject: Re: [Monami6] Comments on draft-petander-mip6-mbb-00.txt
In-Reply-To: <43553B5F.6060601@tm.uka.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43553B5F.6060601@tm.uka.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: quoted-printable
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>
Sender: monami6-bounces@ietf.org
Errors-To: monami6-bounces@ietf.org

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