Re: [MEXT] New Text for home link detection in RFC3775bis

"Charles E. Perkins" <charles.perkins@earthlink.net> Wed, 09 July 2008 23:02 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570AF3A689E; Wed, 9 Jul 2008 16:02:18 -0700 (PDT)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255833A67FE for <mext@core3.amsl.com>; Wed, 9 Jul 2008 16:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFKYCTMwjMkO for <mext@core3.amsl.com>; Wed, 9 Jul 2008 16:02:15 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A9DF83A67B0 for <mext@ietf.org>; Wed, 9 Jul 2008 16:02:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PhotlbZ+vYmZQ+JS8i+6pnn70cvsKRIITw2q9oN2nnNt7F6He04SlN5nOAaWhwEV; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [75.26.137.116] (helo=[10.166.255.10]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1KGig8-0006W0-39; Wed, 09 Jul 2008 19:02:28 -0400
Message-ID: <48754383.6050608@earthlink.net>
Date: Wed, 09 Jul 2008 16:02:27 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: mohamed.kassilahlou@orange-ftgroup.com
References: <486B8EDD.4070807@ericsson.com><b6d6bbe00807021101y223a8dc3tcba5152e4bdf8a91@mail.gmail.com> <486BC5C4.8000900@ericsson.com> <BBBE5BAA3B351C488C415EA662EA8840053AD9BE@ftrdmel2>
In-Reply-To: <BBBE5BAA3B351C488C415EA662EA8840053AD9BE@ftrdmel2>
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e23fff292341705a01e0a08717d13035350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 75.26.137.116
Cc: mext@ietf.org
Subject: Re: [MEXT] New Text for home link detection in RFC3775bis
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Hello Kassi,

I have gone through your proposal.  It seems to be a valid
summary of many actions taken by the mobile node when
encountering a new link.

However, I think it amounts to an abbreviation of material
that is found elsewhere within RFC3775 (e.g., section 4.1)
and RFC 5026.  As such, I do not think it is focussed on the
specific issues that have been raised with home link detection,
but instead is much more generalized and thus harder for me
to pinpoint the need.

Perhaps you could consider whether the text proposed by
Suresh is sufficient for the particular issue under discussion.
If not, and you can suggest some revised wording, that would
be appreciated.

Regards,
Charlie P.



mohamed.kassilahlou@orange-ftgroup.com wrote:
>
> Hi all,
>
> I hope that the following can hepl:
>
>  If the MN has no configuration then A otherwise B.
>
> A: Bootstrap
>
> o The MN has neither IP address, nor the HA IP address, nor home IP 
> prefix,
>
> o The MN connects to a network, obtains a link IP prefix and acquires 
> or forms an IP address (MN@)
>
> o The MN discovers the HA IP address and its home IP prefixes
>
> o The MN compares the prefix of its IP address (MN@) with the home IP 
> prefixes
>
>             - If those prefixes match then the MN is in its home
>             network, HoA=MN@, and the HA is the HA for this HoA. The
>             MN initiates IP sessions with classical routing.
>
>             - If not then the MN is in a foreign network, CoA=MN@, the
>             HA is a HA for the MN. The MN will form a HoA from home
>             prefixes or will request a HoA from the HA and will
>             exchange a BU/BA with the HA. The MN initiates IP sessions
>             using MIP.
>
> B. Handover
>
> o The MN has a HoA, the HA IP address and its home IP prefixes
>
> o The MN connects to the network and obtains a link IP prefix
>
> o The MN compares the link IP prefix with the HoA IP prefix
>
>             - If those prefixes match then the MN is in its home network
>
>                                     + If the MN has no CoA: It means
>                                     that the MN is always on its home
>                                     network. It has made no IP
>                                     handover therefore it does not
>                                     need to send a BU. The MN
>                                     continues its IP sessions with
>                                     classical routing.
>
>                                     + If the MN already has a CoA: It
>                                     means that the MN returns at its
>                                     home network then it has to sends
>                                     a BU to deregister. The MN
>                                     continues its IP sessions with
>                                     classical routing.
>
>             - If the prefixes do not match then the MN is in a foreign
>             network
>
>                                     + if the MN has no CoA: It means
>                                     that the MN comes from its home
>                                     network then it forms (or
>                                     acquires) a CoA with the link
>                                     prefix on which it has just
>                                     connected and sends a BU to its
>                                     HA. The MN continues its IP
>                                     sessions using MIP.
>
>                                     + If the MN already has a CoA:
>
>                                                 * If the link prefixes
>                                                 and the CoA prefix
>                                                 match: It means that
>                                                 the MN is always on
>                                                 the same foreign
>                                                 network. It has made
>                                                 no IP handover
>                                                 therefore it does not
>                                                 need to send a BU. The
>                                                 MN continues its IP
>                                                 sessions using MIP.
>
>                                                 * If the link prefixes
>                                                 and the CoA prefix do
>                                                 not match: it means
>                                                 that the MN has made
>                                                 IP handover towards
>                                                 another foreign
>                                                 network therefore it
>                                                 has to form (or
>                                                 acquire) a CoA with
>                                                 the link prefix on
>                                                 which it has just
>                                                 connected and to send
>                                                 a BU to its HA to
>                                                 update its
>                                                 registration. The MN
>                                                 continues its IP
>                                                 sessions using MIP.
>
> o Note that when the mobile node connects on a new visited network it 
> may need to discover the HA of this network if available. The mobile 
> node may have to use this HA for next IP sessions.
>
> Sincerly,
>
> Kassi
>
>
> -----Message d'origine-----
> De : mext-bounces@ietf.org [_mailto:mext-bounces@ietf.org_] De la part 
> de Suresh Krishnan
> Envoyé : mercredi 2 juillet 2008 20:16
> À : fan zhao
> Cc : mext@ietf.org
> Objet : Re: [MEXT] New Text for home link detection in RFC3775bis
>
> Hi Fan,
>    Sounds like a good idea.
>
> Cheers
> Suresh
>
> fan zhao wrote:
> > Hi Suresh,
> >
> > I have a quick comment:
> > the Home Link Detection is not only performed during handover, but
> > also during initial attach. The new text is proposed into section
> > 11.5.4.  "Returning Home", which seems to me that the new text only
> > applies to the handover case.
> >
> > Therefore, my oponion is to have a new (sub)section called "Home Link
> > Detection" somewhere, and refer to this new section in section 11.5.4.
> > What do you think?
> >
> > Sincerely,
> > fan
> >
> > On Wed, Jul 2, 2008 at 7:21 AM, Suresh Krishnan
> > <suresh.krishnan@ericsson.com> wrote:
> >> The WG had consensus to fold in text from draft-krishnan-mext-hld
> >> into RFC3775bis. Here is the proposed text for doing so. Feel free 
> to edit.
> >>
> >>
> >>
> >> This change is made in Section 11.5.4
> >>
> >> OLD TEXT
> >> ========
> >>   A mobile node detects that it has returned to its home link through
> >>   the movement detection algorithm in use (Section 11.5.1), when the
> >>   mobile node detects that its home subnet prefix is again on-link.
> >>
> >> NEW TEXT
> >> ========
> >>   When an MN detects that it has arrived on a new link using the
> >>   movement detection algorithm in use (Section 11.5.1) it performs the
> >>   following steps to determine if it is on the home link.
> >>
> >>   o  The MN performs the procedure described in Section 11.5.2 and
> >>      configures an address referred to as the Current MN Address (CMA).
> >>      It also stores all the on-link prefix(es) received in the RA along
> >>      with their prefix lengths in a conceptual list called the Current
> >>      Link Prefix List (CLPL).
> >>
> >>   o  If the home prefix has been statically pre-configured on the MN
> >>      it checks if the home prefix matches one of the prefixes in the
> >>      CLPL. If it does, the MN concludes that it has returned home.
> >>
> >>   o  If the home prefix has not been statically configured the MN uses
> >>      some form of bootstrapping procedure (e.g. RFC5026) to determine
> >>      the home prefix. It then checks if the home prefix matches one of
> >>      the prefixes in the CLPL. If it does, the MN concludes that it has
> >>      returned home.
> >>
> >> _______________________________________________
> >> MEXT mailing list
> >> MEXT@ietf.org
> >> _https://www.ietf.org/mailman/listinfo/mext_
> >>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> _https://www.ietf.org/mailman/listinfo/mext_
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>   

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext