Re: [multimob] MLD HLD Message

<pierrick.seite@orange-ftgroup.com> Fri, 16 May 2008 14:10 UTC

Return-Path: <multimob-bounces@ietf.org>
X-Original-To: multimob-archive@optimus.ietf.org
Delivered-To: ietfarch-multimob-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4AB28C1AE; Fri, 16 May 2008 07:10:15 -0700 (PDT)
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAB63A6A28 for <multimob@core3.amsl.com>; Fri, 16 May 2008 07:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
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 e7xfCw3xCROr for <multimob@core3.amsl.com>; Fri, 16 May 2008 07:10:12 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id E5D493A6B0F for <multimob@ietf.org>; Fri, 16 May 2008 07:10:11 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 16:10:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 16 May 2008 16:10:05 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD104CE3DE4@ftrdmel1>
In-Reply-To: <D373F8710ACBA6419BF0B7A5177691CC04850384@ecamlmw720.eamcs.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [multimob] MLD HLD Message
Thread-Index: Aci3VeSZ+eRbw4k5RAifEbQxn96vhgAAxlnAAAEUwEA=
References: <mailman.150.1210943289.4954.multimob@ietf.org> <D373F8710ACBA6419BF0B7A5177691CC04850384@ecamlmw720.eamcs.ericsson.se>
From: pierrick.seite@orange-ftgroup.com
To: desire.oulai@ericsson.com, multimob@ietf.org
X-OriginalArrivalTime: 16 May 2008 14:10:05.0360 (UTC) FILETIME=[8A350B00:01C8B75E]
Subject: Re: [multimob] MLD HLD Message
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

Hi,

Just to clarify: actually DSMIP is only proposed for inter-system mobility between WLAN and 3GPP accesses.

Pierrick

> -----Message d'origine-----
> De : multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la
> part de Desire Oulai
> Envoyé : vendredi 16 mai 2008 15:40
> À : multimob@ietf.org
> Objet : Re: [multimob] MLD HLD Message
> 
> Hi Alvaro,
> 
>  Just to clarify that 3GPP also uses DSMIP6 which is a "MIPv6 with IPv4
> support". I agree that it is better to focus first on solutions for
> MIPv6 and PMIPv6. These solutions could be extended later.
> 
> Best Regards
> 
> Desire
> 
> > -----Original Message-----
> > From: multimob-bounces@ietf.org
> > [mailto:multimob-bounces@ietf.org] On Behalf Of
> > multimob-request@ietf.org
> > Sent: May 16, 2008 9:08 AM
> > To: multimob@ietf.org
> > Subject: multimob Digest, Vol 13, Issue 4
> >
> > Hi,
> >
> > Just some comments: I read the draft about multicast and
> > HMIPv6 and I have a doubt about if HMIPv6 is a succcesful
> > technology or not.
> >
> > I am not a Mobile IP expert, but from what I know:
> >
> > 1. 3GPP2 (USA) uses Mobile IP but not HMIPv6 2. 3GPP (Europe)
> > uses something similar to Proxy Mobile IP draft and still
> > doesn't support Mobile IP 3. IMS (IP Multimedia Subsytem) is
> > expecting the Proxy Mobile IPv6 draft to reach RFC status.
> > This technology is considered "critical" for IMS. IMS is
> > based on IPv6 but I think it still doesn't support Mobile IP
> > ( I am not sure about this) Both 3GPP and 3GPP2 are going to
> > implement IMS
> >
> > Of course, Mobile IP can be used not only in Mobile Phones.
> > It can be used with WIFI, Wimax or other wireless
> > technologies. But I think it's better one solution for
> > muticast Mobile IP that could be also used with 3GPP, 3GPP2 and IMS.
> >
> > So, my doubts are
> >
> > is HMIPv6 a successful technology?
> > is it really being implemented by ISP?
> >
> > Best regards
> >
> > Alvaro
> >
> >
> > ________________________________
> >
> > De: multimob-bounces@ietf.org en nombre de Hitoshi Asaeda
> > Enviado el: jue 15/05/2008 19:16
> > Para: sarikaya@ieee.org; behcetsarikaya@yahoo.com
> > CC: multimob@ietf.org
> > Asunto: Re: [multimob] MLD HLD Message
> >
> >
> >
> > >   We had a discussion on where MLD/IGMP Hold message needs to be
> > > specified. There are two options: either it is specified in
> > MLD/IGMP
> > > Mobile draft or in individual protocol extension draft(s) for
> > > HMIP/MIP, etc.
> > >
> > >   Please post your opinions.
> >
> > Maybe I should clarify.
> >
> > I sent a mail to the multimob ML on Apr.14.
> >
> > Thomas proposed MLD hold message in;
> > http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6
> >
> > It assumes the use of MLD hold message with HMIP6.
> > On the other hand, MLD hold message might be useful for fast
> > handover scenario in general, because MLD hold asks to the
> > upstream mrouter or proxy (i.e. MAPs or HA) to keep join
> > state during MN's movement and recover the multicast session
> > after MN's movement.
> >
> > On the other hand, one may think that MLD hold state is not
> > mandatory as the general MLD extension, because the fast
> > handover would be much faster than the time of membership
> > expiration maintained by MLD. This means even if MN does not
> > send any MLD message to his upstream router or proxy, he can
> > recover the multicast session quickly since he can move to
> > the new mobile network very fast (i.e. faster than MLD
> > expiration time).
> > I don't know if it's always true or not.
> >
> > So now, I'd like to hear your opinions.
> > If MLD hold is useful especially (or only) for HMIP, then MLD
> > hold specification would be kept in the above HMIP draft.
> > If it is useful to propose it as the MLD extension as the
> > general function, I'm happy to work for defining the
> > specification in the MLD extension draft with Thomas.
> >
> > Thank you for your input.
> > --
> > Hitoshi Asaeda
> > _______________________________________________
> > multimob mailing list
> > multimob@ietf.org
> > https://www.ietf.org/mailman/listinfo/multimob
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> > http://www.ietf.org/pipermail/multimob/attachments/20080516/61
> > 14d603/attachment.htm
> >
> > ------------------------------
> >
> > _______________________________________________
> > multimob mailing list
> > multimob@ietf.org
> > https://www.ietf.org/mailman/listinfo/multimob
> >
> >
> > End of multimob Digest, Vol 13, Issue 4
> > ***************************************
> >
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob