From multimob-bounces@ietf.org Thu May 15 09:40:41 2008 Return-Path: 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 60B643A67B6; Thu, 15 May 2008 09:40:41 -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 055E93A67B6 for ; Thu, 15 May 2008 09:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 Mi2Bwo5Y-vCE for ; Thu, 15 May 2008 09:40:21 -0700 (PDT) Received: from web84304.mail.re1.yahoo.com (web84304.mail.re1.yahoo.com [69.147.74.183]) by core3.amsl.com (Postfix) with SMTP id 2327A3A63D3 for ; Thu, 15 May 2008 09:40:18 -0700 (PDT) Received: (qmail 46143 invoked by uid 60001); 15 May 2008 16:38:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=D3kwtpw1KYz2gRDAq+C/21pU8ajTi7OiOfe9YxEwKc4st6d4p6wpPioDu5Ff3MuHQ6b8u7tTySupn89LWwtEDzCcBcw0OH4GfFOmBtXViLfQKBH6w5sF+4gACD4PwQex/ry/E2eqk6Dtpl9E/rFeNQzNRK1D+TGLX2ndDF8u9no=; X-YMail-OSG: uH1BM04VM1l.JNHE8dMeIDn_.vp4IefnDv.HqxbJ1TLSeFhKiFyRYk9dqLNOhNTcxhjqXuHc98PWUkn5.1TY030OUAuFMg.q7tScSw-- Received: from [12.52.72.73] by web84304.mail.re1.yahoo.com via HTTP; Thu, 15 May 2008 09:38:51 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 15 May 2008 09:38:51 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <986442.46044.qm@web84304.mail.re1.yahoo.com> Subject: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680518297==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0680518297== Content-Type: multipart/alternative; boundary="0-1394048364-1210869531=:46044" --0-1394048364-1210869531=:46044 Content-Type: text/plain; charset=us-ascii Hi all, 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. Regards, Behcet --0-1394048364-1210869531=:46044 Content-Type: text/html; charset=us-ascii
Hi all,
  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.

Regards,

Behcet
--0-1394048364-1210869531=:46044-- --===============0680518297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0680518297==-- From multimob-bounces@ietf.org Thu May 15 11:12:01 2008 Return-Path: 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 7C27D28C0FC; Thu, 15 May 2008 11:12:01 -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 40C1128C0D9 for ; Thu, 15 May 2008 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 F-iDCwFGbGK0 for ; Thu, 15 May 2008 11:11:59 -0700 (PDT) Received: from mx6.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by core3.amsl.com (Postfix) with ESMTP id A157E28C0FC for ; Thu, 15 May 2008 11:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJUZLEiNFgqa/2dsb2JhbACvLQ Received: from osiris.informatik.haw-hamburg.de (HELO mailgate.informatik.haw-hamburg.de) ([141.22.10.154]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 May 2008 20:10:53 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 72C8E4000F9; Thu, 15 May 2008 20:10:53 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09360-01-7; Thu, 15 May 2008 20:10:53 +0200 (CEST) Received: from [192.168.178.21] (e178150226.adsl.alicedsl.de [85.178.150.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id BA0AA4000F5; Thu, 15 May 2008 20:10:52 +0200 (CEST) Message-ID: <482C7CAA.5000301@informatik.haw-hamburg.de> Date: Thu, 15 May 2008 20:10:50 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Behcet Sarikaya References: <986442.46044.qm@web84304.mail.re1.yahoo.com> In-Reply-To: <986442.46044.qm@web84304.mail.re1.yahoo.com> X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 all, well, we already provided a proposal to specification in = http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6 We sort of appointed to combine this with Hitoshi's draft to bring = together all mobility related MLD extensions. This seems to make sense, = as there are rather few issues with IGMP/MLD and it does not appeal to = me to split minors over many documents. Best regards, Thomas Behcet Sarikaya wrote: > Hi all, > 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, e= tc. > = > Please post your opinions. > = > Regards, > = > Behcet > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri May 16 02:28:36 2008 Return-Path: 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 7753A28C159; Fri, 16 May 2008 02:28:36 -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 B202E3A6875 for ; Fri, 16 May 2008 02:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_222000=1.508] 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 DWQmIibmWEdJ for ; Fri, 16 May 2008 02:28:30 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [IPv6:2001:200:0:8801:203:47ff:fedf:73cc]) by core3.amsl.com (Postfix) with ESMTP id B0F933A6835 for ; Fri, 16 May 2008 02:28:01 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) (authenticated bits=0) by pione.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id m4FGtT5C016915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 01:55:30 +0900 Date: Fri, 16 May 2008 02:16:18 +0900 (JST) Message-Id: <20080516.021618.48519059.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <986442.46044.qm@web84304.mail.re1.yahoo.com> References: <986442.46044.qm@web84304.mail.re1.yahoo.com> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org > 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 From multimob-bounces@ietf.org Fri May 16 06:08:10 2008 Return-Path: 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 46D5528C194; Fri, 16 May 2008 06:08:10 -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 5857728C193 for ; Fri, 16 May 2008 06:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 YW5cQLX30jpK for ; Fri, 16 May 2008 06:08:07 -0700 (PDT) Received: from soportemv.com (correo.soportemv.com [80.81.115.248]) by core3.amsl.com (Postfix) with ESMTP id 3609F28C1CA for ; Fri, 16 May 2008 06:08:04 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 May 2008 15:07:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD HLD Message Thread-Index: Aci3NzlVgQBD6T9fTzaePn6Yzt46owAG3D+x References: <986442.46044.qm@web84304.mail.re1.yahoo.com> <20080516.021618.48519059.asaeda@sfc.wide.ad.jp> From: "Alvaro Fernandez" To: "Hitoshi Asaeda" , , Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597362786==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0597362786== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B755.D49AB962" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B755.D49AB962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 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. =20 I am not a Mobile IP expert, but from what I know: =20 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 =20 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. =20 So, my doubts are =20 is HMIPv6 a successful technology? is it really being implemented by ISP? =20 Best regards Alvaro =20 ________________________________ 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 ------_=_NextPart_001_01C8B755.D49AB962 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [multimob] MLD HLD Message=0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
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.
=0A=
 
=0A=
I am not a Mobile IP expert, = but from what I know:
=0A=
 
=0A=
1. 3GPP2 (USA) uses Mobile IP = but not HMIPv6
=0A=
2. 3GPP (Europe) uses = something similar to Proxy Mobile IP draft and still doesn't support = Mobile IP
=0A=
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
=0A=
 
=0A=
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.
=0A=
 
=0A=
So, my doubts are
=0A=
 
=0A=
is HMIPv6 a successful = technology?
=0A=
is it really being = implemented by ISP?
=0A=
 
=0A=
Best regards
=0A=

Alvaro
=0A=
 
=0A=

=0A=
=0A= 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

=0A=
=0A=

>   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

------_=_NextPart_001_01C8B755.D49AB962-- --===============0597362786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0597362786==-- From multimob-bounces@ietf.org Fri May 16 06:20:43 2008 Return-Path: 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 6268528C1DC; Fri, 16 May 2008 06:20:43 -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 3AADC28C1DC for ; Fri, 16 May 2008 06:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_222000=1.508] 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 ln04qndQh3vS for ; Fri, 16 May 2008 06:20:41 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [IPv6:2001:200:0:8801:203:47ff:fedf:73cc]) by core3.amsl.com (Postfix) with ESMTP id F3F9128C1D6 for ; Fri, 16 May 2008 06:20:40 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) (authenticated bits=0) by pione.sfc.wide.ad.jp (8.13.1/8.13.1) with ESMTP id m4GD13UJ010986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 22:01:05 +0900 Date: Fri, 16 May 2008 22:22:03 +0900 (JST) Message-Id: <20080516.222203.88715380.asaeda@sfc.wide.ad.jp> To: Alvaro@soportemv.com From: Hitoshi Asaeda In-Reply-To: References: <986442.46044.qm@web84304.mail.re1.yahoo.com> <20080516.021618.48519059.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Alvaro, > is HMIPv6 a successful technology? > is it really being implemented by ISP? Here, we'd like to ask whether "MLD hold" message is useful in general multicast for mobility support or not. We may want to discuss mobile protocol itself later, but now let's think of MLD extension, especially MLD hold operation. I'd support this MLD hold operation in my MLD extension draft if many of you agree. Thanks, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri May 16 06:30:55 2008 Return-Path: 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 AD85128C1AA; Fri, 16 May 2008 06:30:55 -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 1187928C1AA for ; Fri, 16 May 2008 06:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 icK2mnWOgO09 for ; Fri, 16 May 2008 06:30:53 -0700 (PDT) Received: from mx3.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by core3.amsl.com (Postfix) with ESMTP id A26EF28C193 for ; Fri, 16 May 2008 06:30:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK8pLUiNFgqa/2dsb2JhbACuFA Received: from osiris.informatik.haw-hamburg.de (HELO mailgate.informatik.haw-hamburg.de) ([141.22.10.154]) by mail3.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2008 15:30:46 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id F406B4000F9; Fri, 16 May 2008 15:30:45 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16244-03-2; Fri, 16 May 2008 15:30:45 +0200 (CEST) Received: from [192.168.178.21] (e178144180.adsl.alicedsl.de [85.178.144.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 2E3D94000F8; Fri, 16 May 2008 15:30:45 +0200 (CEST) Message-ID: <482D8C82.6010602@informatik.haw-hamburg.de> Date: Fri, 16 May 2008 15:30:42 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hitoshi Asaeda References: <986442.46044.qm@web84304.mail.re1.yahoo.com> <20080516.021618.48519059.asaeda@sfc.wide.ad.jp> <20080516.222203.88715380.asaeda@sfc.wide.ad.jp> In-Reply-To: <20080516.222203.88715380.asaeda@sfc.wide.ad.jp> X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: Alvaro@soportemv.com, multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, yes: this MLD-hold function is useful for HMIPv6, but by no means tight = to this. It enables / supports a (listener) proxy function, which fits = well into the HMIPv6 architecture ... as it does into 3GPP regional = router architecture ... Best, Thomas Hitoshi Asaeda wrote: > Hi Alvaro, > = >> is HMIPv6 a successful technology? >> is it really being implemented by ISP? > = > Here, we'd like to ask whether "MLD hold" message is useful in general > multicast for mobility support or not. > = > We may want to discuss mobile protocol itself later, but now let's > think of MLD extension, especially MLD hold operation. > I'd support this MLD hold operation in my MLD extension draft if many > of you agree. > = > Thanks, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri May 16 06:39:50 2008 Return-Path: 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 4622028C18D; Fri, 16 May 2008 06:39:50 -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 AFA0528C182 for ; Fri, 16 May 2008 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 aUhv+RRcK8Z0 for ; Fri, 16 May 2008 06:39:47 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 99E983A67A1 for ; Fri, 16 May 2008 06:39:47 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m4GDdeJI000955 for ; Fri, 16 May 2008 08:39:42 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 08:39:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 09:39:39 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD HLD Message Thread-Index: Aci3VeSZ+eRbw4k5RAifEbQxn96vhgAAxlnA References: From: "Desire Oulai" To: X-OriginalArrivalTime: 16 May 2008 13:39:40.0228 (UTC) FILETIME=[4A580040:01C8B75A] Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org 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 From multimob-bounces@ietf.org Fri May 16 06:41:52 2008 Return-Path: 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 B87833A68FF; Fri, 16 May 2008 06:41:52 -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 DAAFB3A68FF for ; Fri, 16 May 2008 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 dOyyAFdyXvDl for ; Fri, 16 May 2008 06:41:50 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 099803A67A5 for ; Fri, 16 May 2008 06:41:49 -0700 (PDT) Received: (qmail 33786 invoked by uid 60001); 16 May 2008 13:41:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=5FgKzhxbqBDwKt/lqWg9RunfX9ANf6JsoiiJbnkFI+V7w+i5Bl2c1U08aEaCSliTu+NG5eEbglG8xJuixR6XKjIicafrljbbBOL5xhrraTs7vJoFB113yOro9+27ZpepnyBbrL3nGbqJC3fZUfFufHBEgxQ1S/1Yt76h1Df89Ic=; X-YMail-OSG: UFmXwc0VM1nK2cAfKmmmjTcLSo.1J7i1mLVcIBfr4aH.yG2jNHElXMNjBV3IsfVdZZMEZdvUxfzegMoPDMUlCmpikKp_fM52pCEFoA-- Received: from [72.158.100.2] by web84306.mail.re1.yahoo.com via HTTP; Fri, 16 May 2008 06:41:40 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Fri, 16 May 2008 06:41:40 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <127168.33711.qm@web84306.mail.re1.yahoo.com> Subject: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0047225730==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0047225730== Content-Type: multipart/alternative; boundary="0-1404195887-1210945300=:33711" --0-1404195887-1210945300=:33711 Content-Type: text/plain; charset=us-ascii Hi all, I was wondering if there is any standardization of the use of MLD/IGMP in Multicast/Broadcast (MBMS) subsystem of 3GPP? Regards, Behcet --0-1404195887-1210945300=:33711 Content-Type: text/html; charset=us-ascii
Hi all,
  I was wondering if there is any standardization of the use of MLD/IGMP in Multicast/Broadcast (MBMS) subsystem of 3GPP?

Regards,

Behcet
--0-1404195887-1210945300=:33711-- --===============0047225730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0047225730==-- From multimob-bounces@ietf.org Fri May 16 07:10:15 2008 Return-Path: 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 ; 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 ; 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 ; 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: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD HLD Message Thread-Index: Aci3VeSZ+eRbw4k5RAifEbQxn96vhgAAxlnAAAEUwEA= References: From: To: , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la > part de Desire Oulai > Envoy=E9=A0: vendredi 16 mai 2008 15:40 > =C0=A0: multimob@ietf.org > Objet=A0: 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 From multimob-bounces@ietf.org Fri May 16 07:15:46 2008 Return-Path: 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 8F41F28C1E0; Fri, 16 May 2008 07:15:46 -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 3FD5228C1E0 for ; Fri, 16 May 2008 07:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8nC5sMneuuPg for ; Fri, 16 May 2008 07:15:44 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0025C28C0E4 for ; Fri, 16 May 2008 07:15:43 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m4GEFcp6031657 for ; Fri, 16 May 2008 09:15:38 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 09:15:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 10:15:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multimob Digest, Vol 13, Issue 9 Thread-Index: Aci3XpxgJ+A4i4/hSvSytNRPyaJXSwAAFZuA References: From: "Desire Oulai" To: X-OriginalArrivalTime: 16 May 2008 14:15:38.0588 (UTC) FILETIME=[50D399C0:01C8B75F] Subject: Re: [multimob] multimob Digest, Vol 13, Issue 9 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Pierrick, You are right but it is used for all non-3GPP accesses in a 3GPP evolved system, not only for WLAN. 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 10:10 AM > To: multimob@ietf.org > Subject: multimob Digest, Vol 13, Issue 9 > > 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 > > > End of multimob Digest, Vol 13, Issue 9 > *************************************** > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri May 16 07:28:18 2008 Return-Path: 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 6B0DC28C1FA; Fri, 16 May 2008 07:28:18 -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 DA14028C1E0 for ; Fri, 16 May 2008 07:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 dFmVHxSixgEn for ; Fri, 16 May 2008 07:28:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 37D5928C0D9 for ; Fri, 16 May 2008 07:28:12 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 16 May 2008 16:28:06 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 16:28:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 16 May 2008 16:28:05 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A403A9D13A@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <127168.33711.qm@web84306.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD/IGMP in 3GPP? Thread-Index: Aci3WphYdoVFWPeOQoyHjipQ3N6dnwABVKdA From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 16 May 2008 14:28:06.0017 (UTC) FILETIME=[0E543710:01C8B761] Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660291087==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0660291087== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B761.0DFDA8C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B761.0DFDA8C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, as far as I found for Rel. 8 it is planned to include in 3GPP TS 34.108: = ' Common test environments for User Equipment (UE); Conformance testing' = Test Procedures for MBMS Testing (IGMP and MLD) and in 3G TS 23.246 (all = releases) 'Multimedia Broadcast/Multicast Service (MBMS); Architecture = and functional description' an MBMS multicast service activation = procedure is described where the UE sends an IGMP (IPv4) or MLD (IPv6) = Join message ... to signal its interest in receiving a particular = multicast MBMS bearer service identified by an IP multicast address. = Correspondingly for Deactivation the Leave message ("means Leave Group = message in RFC 2236 for IGMP (IPv4) and Multicast Listener Done in = RFC2710 for MLD (IPv6)") is foreseen. (to be found at = http://www.3gpp.org/ftp/Specs/latest/Rel-8/23_series/23246-810.zip)=20 =20 Best regards=20 Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Freitag, 16. Mai 2008 15:42 An: multimob@ietf.org Betreff: [multimob] MLD/IGMP in 3GPP? =20 Hi all, I was wondering if there is any standardization of the use of MLD/IGMP = in Multicast/Broadcast (MBMS) subsystem of 3GPP? Regards, Behcet ------_=_NextPart_001_01C8B761.0DFDA8C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

as far as I = found for Rel. 8 it is planned to include in 3GPP TS 34.108: ‘ Common test = environments for User Equipment (UE); Conformance testing’ Test Procedures for = MBMS Testing (IGMP and MLD) and in 3G TS 23.246 (all releases) = ‘Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional = description’ an MBMS multicast service activation procedure is described where the UE = sends an IGMP (IPv4) or MLD (IPv6) Join message … to signal its interest = in receiving a particular multicast MBMS bearer service identified by an IP multicast address. Correspondingly for Deactivation the Leave message = (“means Leave Group message in RFC 2236 for IGMP (IPv4) and Multicast Listener = Done in RFC2710 for MLD (IPv6)”) is foreseen.

(to be found at = http://www.3gpp.org/ftp/Specs/latest/Rel-8/23_series/23246-810.zip= )

 

Best regards

Dirk 

-----Urspr=FCngliche = Nachricht-----
Von: = multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya
Gesendet: Freitag, 16. = Mai 2008 15:42
An: multimob@ietf.org
Betreff: [multimob] = MLD/IGMP in 3GPP?

 

Hi all,
  I was wondering if there is any standardization of the use of = MLD/IGMP in Multicast/Broadcast (MBMS) subsystem of 3GPP?

Regards,

Behcet

------_=_NextPart_001_01C8B761.0DFDA8C6-- --===============0660291087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0660291087==-- From multimob-bounces@ietf.org Fri May 16 07:37:17 2008 Return-Path: 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 3610C3A6B32; Fri, 16 May 2008 07:37:17 -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 C689D28C1A9 for ; Fri, 16 May 2008 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 gofbuj7MuK5N for ; Fri, 16 May 2008 07:37:15 -0700 (PDT) Received: from mx6.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by core3.amsl.com (Postfix) with ESMTP id 674D728C0EB for ; Fri, 16 May 2008 07:37:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOs4LUiNFgqa/2dsb2JhbACuCg Received: from osiris.informatik.haw-hamburg.de (HELO mailgate.informatik.haw-hamburg.de) ([141.22.10.154]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2008 16:37:07 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 0DCDC4000F9; Fri, 16 May 2008 16:37:08 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18897-03-2; Fri, 16 May 2008 16:37:07 +0200 (CEST) Received: from [192.168.178.21] (e178144180.adsl.alicedsl.de [85.178.144.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 19E934000F8; Fri, 16 May 2008 16:37:07 +0200 (CEST) Message-ID: <482D9C10.5060500@informatik.haw-hamburg.de> Date: Fri, 16 May 2008 16:37:04 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Von-Hugo, Dirk" References: <1B309B6DC3B05440ACC14187BCB308A403A9D13A@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <1B309B6DC3B05440ACC14187BCB308A403A9D13A@S4DE8PSAAGM.mitte.t-com.de> X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Dirk et al., so this praises prominence ... but let's focus on quality. I guess we should work on solutions that are of general functionality = and applicability. Including 3GPP/MBMS/IMS ..., but not exclusively = tailored to it. Actually, we all don't know what will happen in case the predicted = arrives, i.e., operators loose control of the end systems. Cheers, Thomas Von-Hugo, Dirk wrote: > Dear all, > = > as far as I found for Rel. 8 it is planned to include in 3GPP TS 34.108: = > =91 Common test environments for User Equipment (UE); Conformance testing= =92 = > Test Procedures for MBMS Testing (IGMP and MLD) and in 3G TS 23.246 (all = > releases) =91Multimedia Broadcast/Multicast Service (MBMS); Architecture = > and functional description=92 an MBMS multicast service activation = > procedure is described where the UE sends an IGMP (IPv4) or MLD (IPv6) = > Join message =85 to signal its interest in receiving a particular = > multicast MBMS bearer service identified by an IP multicast address. = > Correspondingly for Deactivation the Leave message (=93means Leave Group = > message in RFC 2236 for IGMP (IPv4) and Multicast Listener Done in = > RFC2710 for MLD (IPv6)=94) is foreseen. > = > (to be found at = > http://www.3gpp.org/ftp/Specs/latest/Rel-8/23_series/23246-810.zip) > = > = > = > Best regards > = > Dirk = > = > -----Urspr=FCngliche Nachricht----- > *Von:* multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] *Im = > Auftrag von *Behcet Sarikaya > *Gesendet:* Freitag, 16. Mai 2008 15:42 > *An:* multimob@ietf.org > *Betreff:* [multimob] MLD/IGMP in 3GPP? > = > = > = > Hi all, > I was wondering if there is any standardization of the use of MLD/IGMP = > in Multicast/Broadcast (MBMS) subsystem of 3GPP? > = > Regards, > = > Behcet > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri May 16 07:41:59 2008 Return-Path: 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 AE0FE28C126; Fri, 16 May 2008 07:41:59 -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 D984228C126 for ; Fri, 16 May 2008 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 IF24ISWBBFJ9 for ; Fri, 16 May 2008 07:41:55 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DE0E93A6B24 for ; Fri, 16 May 2008 07:41:54 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0Y00MTLU5P47@usaga04-in.huawei.com> for multimob@ietf.org; Fri, 16 May 2008 09:41:49 -0500 (CDT) Received: from xiayangsong ([10.124.12.53]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K0Y004L3U5O6K@usaga04-in.huawei.com> for multimob@ietf.org; Fri, 16 May 2008 09:41:49 -0500 (CDT) Date: Fri, 16 May 2008 09:41:47 -0500 From: Frank Xia To: "Thomas C. Schmidt" , Behcet Sarikaya Message-id: <00c901c8b762$f8cf91d0$350c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <986442.46044.qm@web84304.mail.re1.yahoo.com> <482C7CAA.5000301@informatik.haw-hamburg.de> Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1874094148==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1874094148== Content-type: multipart/alternative; boundary="Boundary_(ID_ZViyd2b07IKgo+pLl7akyg)" This is a multi-part message in MIME format. --Boundary_(ID_ZViyd2b07IKgo+pLl7akyg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgQWxsDQoNCldlIGFsc28gdXNlZCBNTEQgSExEIG1lc3NhZ2UgaW4gb3VyIGRyYWZ0DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQteGlhLW11bHRpbW9iLWh5YnJpZC9kcmFmdC14 aWEtbXVsdGltb2ItaHlicmlkLTAwLnR4dC4NCg0KVGhpcyBkcmFmdCBoYXMgYmVlbiBwcmVzZW50 ZWQgaW4gbGFzdCBJRVRGIG1lZXRpbmcuDQoNCkJSDQpGcmFuaw0KICAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBUaG9tYXMgQy4gU2NobWlkdCANCiAgVG86IEJlaGNldCBT YXJpa2F5YSANCiAgQ2M6IG11bHRpbW9iQGlldGYub3JnIA0KICBTZW50OiBUaHVyc2RheSwgTWF5 IDE1LCAyMDA4IDE6MTAgUE0NCiAgU3ViamVjdDogUmU6IFttdWx0aW1vYl0gTUxEIEhMRCBNZXNz YWdlDQoNCg0KICBIaSBhbGwsDQoNCiAgd2VsbCwgd2UgYWxyZWFkeSBwcm92aWRlZCBhIHByb3Bv c2FsIHRvIHNwZWNpZmljYXRpb24gaW4gDQogIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNjaG1pZHQtd2FlaGxpc2NoLW1obWlwdjYNCg0KICBXZSBzb3J0IG9mIGFwcG9pbnRlZCB0 byBjb21iaW5lIHRoaXMgd2l0aCBIaXRvc2hpJ3MgZHJhZnQgdG8gYnJpbmcgDQogIHRvZ2V0aGVy IGFsbCBtb2JpbGl0eSByZWxhdGVkIE1MRCBleHRlbnNpb25zLiBUaGlzIHNlZW1zIHRvIG1ha2Ug c2Vuc2UsIA0KICBhcyB0aGVyZSBhcmUgcmF0aGVyIGZldyBpc3N1ZXMgd2l0aCBJR01QL01MRCBh bmQgaXQgZG9lcyBub3QgYXBwZWFsIHRvIA0KICBtZSB0byBzcGxpdCBtaW5vcnMgb3ZlciBtYW55 IGRvY3VtZW50cy4NCg0KICBCZXN0IHJlZ2FyZHMsDQoNCiAgVGhvbWFzDQoNCiAgQmVoY2V0IFNh cmlrYXlhIHdyb3RlOg0KICA+IEhpIGFsbCwNCiAgPiAgIFdlIGhhZCBhIGRpc2N1c3Npb24gb24g d2hlcmUgTUxEL0lHTVAgSG9sZCBtZXNzYWdlIG5lZWRzIHRvIGJlIA0KICA+IHNwZWNpZmllZC4g VGhlcmUgYXJlIHR3byBvcHRpb25zOiBlaXRoZXIgaXQgaXMgc3BlY2lmaWVkIGluIE1MRC9JR01Q IA0KICA+IE1vYmlsZSBkcmFmdCBvciBpbiBpbmRpdmlkdWFsIHByb3RvY29sIGV4dGVuc2lvbiBk cmFmdChzKSBmb3IgSE1JUC9NSVAsIGV0Yy4NCiAgPiANCiAgPiAgIFBsZWFzZSBwb3N0IHlvdXIg b3BpbmlvbnMuDQogID4gDQogID4gUmVnYXJkcywNCiAgPiANCiAgPiBCZWhjZXQNCiAgPiANCiAg PiANCiAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgPiANCiAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICA+IG11bHRpbW9iIG1haWxpbmcgbGlzdA0KICA+ IG11bHRpbW9iQGlldGYub3JnDQogID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tdWx0aW1vYg0KDQogIC0tIA0KDQogILAgUHJvZi4gRHIuIFRob21hcyBDLiBTY2htaWR0 DQogILAgSEFXIEhhbWJ1cmcsIERlcHQuIEluZm9ybWF0aWsNCiAgsCBVbml2ZXJzaXR5IG9mIEFw cGxpZWQgU2NpZW5jZXMNCiAgsCBCZXJsaW5lciBUb3IgNywgRCAyMDA5OSBIYW1idXJnLCBHZXJt YW55DQogILAgRm9uOiArNDktNDAtNDI4NzUtODQ1MiwgRmF4OiAtODQwOQ0KICCwIGh0dHA6Ly93 d3cuaW5mb3JtYXRpay5oYXctaGFtYnVyZy5kZS9+c2NobWlkdA0KICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBtdWx0aW1vYiBtYWlsaW5nIGxpc3QN CiAgbXVsdGltb2JAaWV0Zi5vcmcNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tdWx0aW1vYg0K --Boundary_(ID_ZViyd2b07IKgo+pLl7akyg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4zMjQzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhpIEFsbDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+V2UgYWxzbyB1c2VkIE1MRCBITEQgbWVzc2FnZSBpbiBvdXIgZHJh ZnQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ PEEgDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvZHJhZnQvZHJhZnQteGlhLW11bHRpbW9i LWh5YnJpZC9kcmFmdC14aWEtbXVsdGltb2ItaHlicmlkLTAwLnR4dCI+aHR0cDovL3Rvb2xzLmll dGYub3JnL2RyYWZ0L2RyYWZ0LXhpYS1tdWx0aW1vYi1oeWJyaWQvZHJhZnQteGlhLW11bHRpbW9i LWh5YnJpZC0wMC50eHQ8L0E+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+VGhpcyBkcmFmdCBoYXMgYmVlbiBwcmVzZW50ZWQgaW4gbGFz dCBJRVRGIA0KbWVldGluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPkJSPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPkZyYW5rPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHls ZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9C PiANCiAgPEEgdGl0bGU9c2NobWlkdEBpbmZvcm1hdGlrLmhhdy1oYW1idXJnLmRlIA0KICBocmVm PSJtYWlsdG86c2NobWlkdEBpbmZvcm1hdGlrLmhhdy1oYW1idXJnLmRlIj5UaG9tYXMgQy4gU2No bWlkdDwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPXNhcmlrYXlhQGllZWUub3JnIA0KICBocmVmPSJtYWlsdG86 c2FyaWtheWFAaWVlZS5vcmciPkJlaGNldCBTYXJpa2F5YTwvQT4gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPW11bHRp bW9iQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86bXVsdGltb2JAaWV0Zi5vcmciPm11bHRpbW9i QGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgTWF5IDE1LCAyMDA4IDE6MTAgUE08L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9C PiBSZTogW211bHRpbW9iXSBNTEQgSExEIE1lc3NhZ2U8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ SGkgYWxsLDxCUj48QlI+d2VsbCwgd2UgYWxyZWFkeSBwcm92aWRlZCBhIHByb3Bvc2FsIHRvIA0K ICBzcGVjaWZpY2F0aW9uIGluIDxCUj48QSANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2NobWlkdC13YWVobGlzY2gtbWhtaXB2NiI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2NobWlkdC13YWVobGlzY2gtbWhtaXB2NjwvQT48QlI+PEJSPldlIA0K ICBzb3J0IG9mIGFwcG9pbnRlZCB0byBjb21iaW5lIHRoaXMgd2l0aCBIaXRvc2hpJ3MgZHJhZnQg dG8gYnJpbmcgPEJSPnRvZ2V0aGVyIA0KICBhbGwgbW9iaWxpdHkgcmVsYXRlZCBNTEQgZXh0ZW5z aW9ucy4gVGhpcyBzZWVtcyB0byBtYWtlIHNlbnNlLCA8QlI+YXMgdGhlcmUgDQogIGFyZSByYXRo ZXIgZmV3IGlzc3VlcyB3aXRoIElHTVAvTUxEIGFuZCBpdCBkb2VzIG5vdCBhcHBlYWwgdG8gPEJS Pm1lIHRvIHNwbGl0IA0KICBtaW5vcnMgb3ZlciBtYW55IGRvY3VtZW50cy48QlI+PEJSPkJlc3Qg cmVnYXJkcyw8QlI+PEJSPlRob21hczxCUj48QlI+QmVoY2V0IA0KICBTYXJpa2F5YSB3cm90ZTo8 QlI+Jmd0OyBIaSBhbGwsPEJSPiZndDsmbmJzcDsmbmJzcDsgV2UgaGFkIGEgZGlzY3Vzc2lvbiBv biANCiAgd2hlcmUgTUxEL0lHTVAgSG9sZCBtZXNzYWdlIG5lZWRzIHRvIGJlIDxCUj4mZ3Q7IHNw ZWNpZmllZC4gVGhlcmUgYXJlIHR3byANCiAgb3B0aW9uczogZWl0aGVyIGl0IGlzIHNwZWNpZmll ZCBpbiBNTEQvSUdNUCA8QlI+Jmd0OyBNb2JpbGUgZHJhZnQgb3IgaW4gDQogIGluZGl2aWR1YWwg cHJvdG9jb2wgZXh0ZW5zaW9uIGRyYWZ0KHMpIGZvciBITUlQL01JUCwgZXRjLjxCUj4mZ3Q7IA0K ICA8QlI+Jmd0OyZuYnNwOyZuYnNwOyBQbGVhc2UgcG9zdCB5b3VyIG9waW5pb25zLjxCUj4mZ3Q7 IDxCUj4mZ3Q7IA0KICBSZWdhcmRzLDxCUj4mZ3Q7IDxCUj4mZ3Q7IEJlaGNldDxCUj4mZ3Q7IDxC Uj4mZ3Q7IDxCUj4mZ3Q7IA0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+Jmd0OyANCiAgPEJSPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBt dWx0aW1vYiANCiAgbWFpbGluZyBsaXN0PEJSPiZndDsgPEEgDQogIGhyZWY9Im1haWx0bzptdWx0 aW1vYkBpZXRmLm9yZyI+bXVsdGltb2JAaWV0Zi5vcmc8L0E+PEJSPiZndDsgPEEgDQogIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2IiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2I8L0E+PEJSPjxCUj4tLSANCiAg PEJSPjxCUj6wIFByb2YuIERyLiBUaG9tYXMgQy4gU2NobWlkdDxCUj6wIEhBVyBIYW1idXJnLCBE ZXB0LiBJbmZvcm1hdGlrPEJSPrAgDQogIFVuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2llbmNlczxC Uj6wIEJlcmxpbmVyIFRvciA3LCBEIDIwMDk5IEhhbWJ1cmcsIA0KICBHZXJtYW55PEJSPrAgRm9u OiArNDktNDAtNDI4NzUtODQ1MiwgRmF4OiAtODQwOTxCUj6wIDxBIA0KICBocmVmPSJodHRwOi8v d3d3LmluZm9ybWF0aWsuaGF3LWhhbWJ1cmcuZGUvfnNjaG1pZHQiPmh0dHA6Ly93d3cuaW5mb3Jt YXRpay5oYXctaGFtYnVyZy5kZS9+c2NobWlkdDwvQT48QlI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+bXVsdGltb2IgDQogIG1haWxpbmcgbGlzdDxC Uj48QSBocmVmPSJtYWlsdG86bXVsdGltb2JAaWV0Zi5vcmciPm11bHRpbW9iQGlldGYub3JnPC9B PjxCUj48QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t dWx0aW1vYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYjwv QT48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_ZViyd2b07IKgo+pLl7akyg)-- --===============1874094148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1874094148==-- From multimob-bounces@ietf.org Fri May 16 12:47:22 2008 Return-Path: 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 EE14228C26E; Fri, 16 May 2008 12:47:22 -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 6AAFC3A6B9E for ; Fri, 16 May 2008 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 L5uWYmXm5TU9 for ; Fri, 16 May 2008 12:47:20 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 9517A3A68A0 for ; Fri, 16 May 2008 12:47:20 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11396506; Fri, 16 May 2008 15:47:15 -0400 Message-Id: From: Marshall Eubanks To: Behcet Sarikaya In-Reply-To: <127168.33711.qm@web84306.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 16 May 2008 15:47:14 -0400 References: <127168.33711.qm@web84306.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.919.2) Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Yes, there is a lot, which if I remember correctly is in 26.346 and just references the IETF RFCs. http://www.3gpp.org/FTP/Specs/html-info/26346.htm Is there some issue in particular you are interested in ? Marshall On May 16, 2008, at 9:41 AM, Behcet Sarikaya wrote: > Hi all, > I was wondering if there is any standardization of the use of MLD/ > IGMP in Multicast/Broadcast (MBMS) subsystem of 3GPP? > > Regards, > > Behcet > _______________________________________________ > 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 From multimob-bounces@ietf.org Tue May 20 20:43:17 2008 Return-Path: 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 C219228C393; Tue, 20 May 2008 20:43:17 -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 1F1573A6CDA for ; Tue, 20 May 2008 20:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 q54qHt6LsmGo for ; Tue, 20 May 2008 20:43:14 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id 1DAAB28D384 for ; Tue, 20 May 2008 09:13:45 -0700 (PDT) Received: (qmail 42189 invoked by uid 60001); 20 May 2008 16:13:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PC0kFCNzpZPvcQmSj0Q8ma2UeMaNIkaA4Zkshu6Rw43Ol6yl97BRkqbHHRUkb9hLdA40jdudZV0brJyz08knkrcmVmwCOPDsJpOR4bURyezeTJi7NLcFJtXmeDr7hgfsc9f6su2SaHuar9GEsLFtKM7aICVKcofSgTAy5JzytbE=; X-YMail-OSG: lu2laCAVM1nPmnY3vlgJCMttSfZxaoqir_a.9ksLZGAGHTlef_ur7fbKXfk8gOCoyw-- Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Tue, 20 May 2008 09:13:44 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 20 May 2008 09:13:44 -0700 (PDT) From: Behcet Sarikaya To: Desire Oulai MIME-Version: 1.0 Message-ID: <214310.42105.qm@web84303.mail.re1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0379059135==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0379059135== Content-Type: multipart/alternative; boundary="0-1128349702-1211300024=:42105" --0-1128349702-1211300024=:42105 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Desir=E9.=0A=0AWe invite members to write solution drafts and submit= them to Multimob. The sooner the better .=0A=0ASuresh & Behcet=0A=0A----- = Original Message ----=0AFrom: Desire Oulai =0ATo= : Behcet Sarikaya ; multimob@ietf.org=0ASent: Tuesday, M= ay 20, 2008 10:08:14 AM=0ASubject: RE: [multimob] MLD HLD Message=0A=0A DIV= {=0AMARGIN:0px;}=0AHi,=0A =0A As I said, my view is that the primarily fo= cus =0Ashould be MIPv6 and PMIPv6. Then, DSMIPv6 and PMIPv6-IPv4 support co= uld be =0Atackled later in order to provide v4 support.=0A =0ABest Regards= =0A =0ADesire=0A=0A From: Behcet Sarikaya [mailto:behcetsarikaya@yah= oo.com] =0ASent: May 20, 2008 10:35 AM=0ATo: Desire Oulai; multimob@ietf.= org=0ASubject: Re: [multimob] MLD HLD Message=0A=0A=0A =0A So shoul= d Multimob concentrate on MIPv6, PMIPv6 and DSMIPv6 solutions? =0AWhat ab= out v4 solutions?=0A=0A=0A=0ARegards,=0A=0ABehcet=0A=0A ----- Original M= essage ----=0AFrom: Desire Oulai =0ATo: multim= ob@ietf.org=0ASent: Friday, May 16, 2008 8:39:39 AM=0ASubject: Re: [multi= mob] MLD HLD Message=0A=0AHi Alvaro,=0A=0AJust to clarify that 3GPP also = uses DSMIP6 which is a "MIPv6 with IPv4=0Asupport". I agree that it is be= tter to focus first on solutions for=0AMIPv6 and PMIPv6. These solutions = could be extended later.=0A=0ABest Regards=0A=0ADesire=0A=0A> -----Origin= al Message-----=0A> From: multimob-bounces@ietf.org =0A> [mailto:multimob= -bounces@ietf.org] On Behalf Of =0A> multimob-request@ietf.org=0A> Sent= : May 16, 2008 9:08 AM=0A> To: multimob@ietf.org=0A> Subject: multimob Di= gest, Vol 13, Issue 4=0A> =0A> Hi,=0A> =0A> Just some comments: I read t= he draft about multicast and =0A> HMIPv6 and I have a doubt about if HMIP= v6 is a succcesful =0A> technology or not.=0A> =0A> I am not a Mobile IP= expert, but from what I know:=0A> =0A> 1. 3GPP2 (USA) uses Mobile IP bu= t not HMIPv6 2. 3GPP (Europe) =0A> uses something similar to Proxy Mobile= IP draft and still =0A> doesn't support Mobile IP 3. IMS (IP Multimedia = Subsytem) is =0A> expecting the Proxy Mobile IPv6 draft to reach RFC stat= us. =0A> This technology is considered "critical" for IMS. IMS is =0A> ba= sed on IPv6 but I think it still doesn't support Mobile IP =0A> ( I am no= t sure about this) Both 3GPP and 3GPP2 are going to =0A> implement IMS= =0A> =0A> Of course, Mobile IP can be used not only in Mobile Phones. = =0A> It can be used with WIFI, Wimax or other wireless =0A> technologies.= But I think it's better one solution for =0A> muticast Mobile IP that co= uld be also used with 3GPP, 3GPP2 and IMS.=0A> =0A> So, my doubts are=0A= > =0A> is HMIPv6 a successful technology?=0A> is it really being impleme= nted by ISP?=0A> =0A> Best regards=0A> =0A> Alvaro=0A> =0A> =0A> ____= ____________________________=0A> =0A> De: multimob-bounces@ietf.org en no= mbre de Hitoshi Asaeda =0A> Enviado el: jue 15/05/2008 19:16=0A> Para: sa= rikaya@ieee.org; behcetsarikaya@yahoo.com=0A> CC: multimob@ietf.org=0A> A= sunto: Re: [multimob] MLD HLD Message=0A> =0A> =0A> =0A> > We had a di= scussion on where MLD/IGMP Hold message needs to be =0A> > specified. The= re are two options: either it is specified in =0A> MLD/IGMP =0A> > Mobile= draft or in individual protocol extension draft(s) for =0A> > HMIP/MIP, = etc.=0A> >=0A> > Please post your opinions.=0A> =0A> Maybe I should clar= ify.=0A> =0A> I sent a mail to the multimob ML on Apr.14.=0A> =0A> Thomas= proposed MLD hold message in;=0A> http://tools.ietf.org/html/draft-schmi= dt-waehlisch-mhmipv6=0A> =0A> It assumes the use of MLD hold message with= HMIP6.=0A> On the other hand, MLD hold message might be useful for fast = =0A> handover scenario in general, because MLD hold asks to the =0A> upst= ream mrouter or proxy (i.e. MAPs or HA) to keep join =0A> state during MN= 's movement and recover the multicast session =0A> after MN's movement.= =0A> =0A> On the other hand, one may think that MLD hold state is not =0A= > mandatory as the general MLD extension, because the fast =0A> handover = would be much faster than the time of membership =0A> expiration maintain= ed by MLD. This means even if MN does not =0A> send any MLD message to hi= s upstream router or proxy, he can =0A> recover the multicast session qui= ckly since he can move to =0A> the new mobile network very fast (i.e. fas= ter than MLD =0A> expiration time).=0A> I don't know if it's always true = or not.=0A> =0A> So now, I'd like to hear your opinions.=0A> If MLD hol= d is useful especially (or only) for HMIP, then MLD =0A> hold specificati= on would be kept in the above HMIP draft.=0A> If it is useful to propose = it as the MLD extension as the =0A> general function, I'm happy to work f= or defining the =0A> specification in the MLD extension draft with Thomas= .=0A> =0A> Thank you for your input.=0A> --=0A> Hitoshi Asaeda=0A> ______= _________________________________________=0A> multimob mailing list=0A> m= ultimob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A> = =0A> =0A> -------------- next part --------------=0A> An HTML attachment = was scrubbed...=0A> URL: =0A> http://www.ietf.org/pipermail/multimob/attach= ments/20080516/61=0A> 14d603/attachment.htm =0A> =0A> -------------------= -----------=0A> =0A> _______________________________________________=0A> = multimob mailing list=0A> multimob@ietf.org=0A> https://www.ietf.org/mail= man/listinfo/multimob=0A> =0A> =0A> End of multimob Digest, Vol 13, Issue= 4=0A> ***************************************=0A> =0A_________________= ______________________________=0Amultimob mailing list=0Amultimob@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A=0A=0A=0A=0A --0-1128349702-1211300024=:42105 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Desir=E9.

We invite members to write sol= ution drafts and submit them to Multimob. The sooner the better .

Suresh = & Behcet

----- Original Message ----
From: Desire Oul= ai <desire.oulai@ericsson.com>
To: Behcet Sarikaya <sarikaya@ie= ee.org>; multimob@ietf.org
Sent: Tuesday, May 20, 2008 10:08:14 AMSubject: RE: [multimob] MLD HLD Message

=0A=0A=0A =0A=0A=0A=0A
Hi,
=0A
 
=0A
  As I said, my view is that the primarily focus =0Ashould = be MIPv6 and PMIPv6. Then, DSMIPv6 and PMIPv6-IPv4 support could be = =0Atackled later in order to provide v4 support.
=0A 
=0A
Best Regards
=0A
 
=0A
Desire

=0A=0A
=0A
=0A From: Behcet Sarikaya =0A= [mailto:behcetsarikaya@yahoo.com]
Sent: May 20, 2008 10:35 =0A= AM
To: Desire Oulai; multimob@ietf.org
Subject: Re: = =0A [multimob] MLD HLD Message

=0A
=0A =0A
So =0A should Multimob concentrate on MIPv6, PMIPv6 and= DSMIPv6 solutions?
What =0A about v4 solutions?



Regard= s,

Behcet

=0A
----- =0A Original Message ----
Fr= om: Desire Oulai =0A <desire.oulai@ericsson.com>
To: multimob@iet= f.org
Sent: Friday, =0A May 16, 2008 8:39:39 AM
Subject: Re: [multim= ob] MLD HLD Message

Hi =0A Alvaro,

Just to clarify that 3GPP= also uses DSMIP6 which is a "MIPv6 =0A with IPv4
support". I agree tha= t it is better to focus first on solutions =0A for
MIPv6 and PMIPv6. Th= ese solutions could be extended later.

Best =0A Regards

Desi= re

> -----Original Message-----
> From: multimob-bounces@ietf.org =0A
> = [mailto:multimob-bounces@= ietf.org] On =0A Behalf Of
> multimob-request@ietf.org
> =0A Sent: May 16, 20= 08 9:08 AM
> To: multimob@ietf.org<= /a>
> Subject: =0A multimob Digest, Vol 13, Issue 4
>
>= Hi,
> 
> =0A Just some comments: I read the draft about= multicast and
> HMIPv6 and I =0A have a doubt about if HMIPv6 is a= succcesful
> technology or =0A not.
> 
> I am no= t a Mobile IP expert, but from what I =0A know:
> 
> 1. = 3GPP2 (USA) uses Mobile IP but not HMIPv6 2. =0A 3GPP (Europe)
> us= es something similar to Proxy Mobile IP draft and =0A still
> doesn= 't support Mobile IP 3. IMS (IP Multimedia Subsytem) is =0A
> expec= ting the Proxy Mobile IPv6 draft to reach RFC status.
> =0A This te= chnology is considered "critical" for IMS. IMS is
> based on =0A IP= v6 but I think it still doesn't support Mobile IP
> ( I am not sure = =0A about this) Both 3GPP and 3GPP2 are going to
> implement =0A I= MS
> 
> Of course, Mobile IP can be used not only in Mobi= le =0A Phones.
> It can be used with WIFI, Wimax or other wireless =
> =0A technologies. But I think it's better one solution for
&g= t; muticast =0A Mobile IP that could be also used with 3GPP, 3GPP2 and IMS= .
>  =0A
> So, my doubts are
> 
> is H= MIPv6 a successful =0A technology?
> is it really being implemented = by ISP?
>  =0A
> Best regards
>
> Alvaro> 
>
> =0A ________________________________
>=
> De: multimob-bo= unces@ietf.org en =0A nombre de Hitoshi Asaeda
> Enviado el: ju= e 15/05/2008 19:16
> =0A Para: sar= ikaya@ieee.org; behcets= arikaya@yahoo.com
> =0A CC: mu= ltimob@ietf.org
> Asunto: Re: =0A [multimob] MLD HLD Message
= >
>
>
> >  We =0A had a discussion on wher= e MLD/IGMP Hold message needs to be
> > =0A specified. There are= two options: either it is specified in
> MLD/IGMP =0A
> >= ; Mobile draft or in individual protocol extension draft(s) for =0A
&g= t; > HMIP/MIP, etc.
> >
> >  Please post your =0A= opinions.
>
> Maybe I should clarify.
>
> I sen= t a =0A mail to the multimob ML on Apr.14.
>
> Thomas propose= d MLD hold =0A message in;
> http://t= ools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6
> =0A
>= ; It assumes the use of MLD hold message with HMIP6.
> On the =0A ot= her hand, MLD hold message might be useful for fast
> handover =0A = scenario in general, because MLD hold asks to the
> upstream mrouter= or =0A proxy (i.e. MAPs or HA) to keep join
> state during MN's mo= vement and =0A recover the multicast session
> after MN's movement.=
>
> =0A On the other hand, one may think that MLD hold state= is not
> mandatory =0A as the general MLD extension, because the f= ast
> handover would be much =0A faster than the time of membership=
> expiration maintained by MLD. This =0A means even if MN does not=
> send any MLD message to his upstream router =0A or proxy, he can=
> recover the multicast session quickly since he can =0A move to <= br>> the new mobile network very fast (i.e. faster than MLD =0A
>= ; expiration time).
> I don't know if it's always true or =0A not.>
> So now, I'd like to hear your opinions.
> If MLD =0A = hold is useful especially (or only) for HMIP, then MLD
> hold =0A = specification would be kept in the above HMIP draft.
> If it is usefu= l =0A to propose it as the MLD extension as the
> general function,= I'm happy =0A to work for defining the
> specification in the MLD = extension draft =0A with Thomas.
>
> Thank you for your input= .
> --
> =0A Hitoshi Asaeda
> __________________________= _____________________
> =0A multimob mailing list
> multimob@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/multimob
> =0A
>
= > -------------- next part --------------
> An HTML =0A attachmen= t was scrubbed...
> URL:
> = http://www.ietf.org/pipermail/multimob/attachments/20080516/61
> = =0A 14d603/attachment.htm
>
> ------------------------------=
> =0A
> _______________________________________________
&= gt; multimob =0A mailing list
> mu= ltimob@ietf.org
> https://www.ietf.org/mailman= /listinfo/multimob
> =0A
>
> End of multimob Diges= t, Vol 13, Issue 4
> =0A ***************************************
= > =0A
_______________________________________________
multimob m= ailing =0A list
multimob@ietf.org=
https://www.ietf.org/mailman/listinfo/multimob


--0-1128349702-1211300024=:42105-- --===============0379059135== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0379059135==-- From multimob-bounces@ietf.org Tue May 20 20:57:12 2008 Return-Path: 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 49A563A7229; Tue, 20 May 2008 20:57:12 -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 C46513A7213 for ; Tue, 20 May 2008 20:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 2-DWvZqPYB8j for ; Tue, 20 May 2008 20:57:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 732BF28CEC8 for ; Tue, 20 May 2008 08:08:26 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m4KF8FSW014555; Tue, 20 May 2008 10:08:15 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 10:08:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 11:08:14 -0400 Message-ID: In-Reply-To: <499986.93086.qm@web84315.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD HLD Message thread-index: Aci6hrns3fOx65BhRoSL5wu4/zKlFwABBufQ References: <499986.93086.qm@web84315.mail.re1.yahoo.com> From: "Desire Oulai" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 20 May 2008 15:08:15.0533 (UTC) FILETIME=[542A2DD0:01C8BA8B] Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816949343==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0816949343== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BA8B.537CC359" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BA8B.537CC359 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 As I said, my view is that the primarily focus should be MIPv6 and PMIPv6. Then, DSMIPv6 and PMIPv6-IPv4 support could be tackled later in order to provide v4 support. =20 Best Regards =20 Desire ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: May 20, 2008 10:35 AM To: Desire Oulai; multimob@ietf.org Subject: Re: [multimob] MLD HLD Message =09 =09 So should Multimob concentrate on MIPv6, PMIPv6 and DSMIPv6 solutions?=20 What about v4 solutions? =09 =09 =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: Desire Oulai To: multimob@ietf.org Sent: Friday, May 16, 2008 8:39:39 AM Subject: Re: [multimob] MLD HLD Message =09 Hi Alvaro, =09 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. =09 Best Regards =09 Desire =09 > -----Original Message----- > From: multimob-bounces@ietf.org=20 > [mailto:multimob-bounces@ietf.org] On Behalf Of=20 > multimob-request@ietf.org > Sent: May 16, 2008 9:08 AM > To: multimob@ietf.org > Subject: multimob Digest, Vol 13, Issue 4 >=20 > Hi, > =20 > Just some comments: I read the draft about multicast and=20 > HMIPv6 and I have a doubt about if HMIPv6 is a succcesful=20 > technology or not. > =20 > I am not a Mobile IP expert, but from what I know: > =20 > 1. 3GPP2 (USA) uses Mobile IP but not HMIPv6 2. 3GPP (Europe)=20 > uses something similar to Proxy Mobile IP draft and still=20 > doesn't support Mobile IP 3. IMS (IP Multimedia Subsytem) is=20 > expecting the Proxy Mobile IPv6 draft to reach RFC status.=20 > This technology is considered "critical" for IMS. IMS is=20 > based on IPv6 but I think it still doesn't support Mobile IP=20 > ( I am not sure about this) Both 3GPP and 3GPP2 are going to=20 > implement IMS > =20 > Of course, Mobile IP can be used not only in Mobile Phones.=20 > It can be used with WIFI, Wimax or other wireless=20 > technologies. But I think it's better one solution for=20 > muticast Mobile IP that could be also used with 3GPP, 3GPP2 and IMS. > =20 > So, my doubts are > =20 > is HMIPv6 a successful technology? > is it really being implemented by ISP? > =20 > Best regards >=20 > Alvaro > =20 >=20 > ________________________________ >=20 > De: multimob-bounces@ietf.org en nombre de Hitoshi Asaeda=20 > 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 >=20 >=20 >=20 > > We had a discussion on where MLD/IGMP Hold message needs to be=20 > > specified. There are two options: either it is specified in=20 > MLD/IGMP=20 > > Mobile draft or in individual protocol extension draft(s) for=20 > > HMIP/MIP, etc. > > > > Please post your opinions. >=20 > Maybe I should clarify. >=20 > I sent a mail to the multimob ML on Apr.14. >=20 > Thomas proposed MLD hold message in; > http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6 >=20 > It assumes the use of MLD hold message with HMIP6. > On the other hand, MLD hold message might be useful for fast=20 > handover scenario in general, because MLD hold asks to the=20 > upstream mrouter or proxy (i.e. MAPs or HA) to keep join=20 > state during MN's movement and recover the multicast session=20 > after MN's movement. >=20 > On the other hand, one may think that MLD hold state is not=20 > mandatory as the general MLD extension, because the fast=20 > handover would be much faster than the time of membership=20 > expiration maintained by MLD. This means even if MN does not=20 > send any MLD message to his upstream router or proxy, he can=20 > recover the multicast session quickly since he can move to=20 > the new mobile network very fast (i.e. faster than MLD=20 > expiration time). > I don't know if it's always true or not. >=20 > So now, I'd like to hear your opinions. > If MLD hold is useful especially (or only) for HMIP, then MLD=20 > hold specification would be kept in the above HMIP draft. > If it is useful to propose it as the MLD extension as the=20 > general function, I'm happy to work for defining the=20 > specification in the MLD extension draft with Thomas. >=20 > Thank you for your input. > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > http://www.ietf.org/pipermail/multimob/attachments/20080516/61 > 14d603/attachment.htm=20 >=20 > ------------------------------ >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 >=20 > End of multimob Digest, Vol 13, Issue 4 > *************************************** >=20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob =09 ------_=_NextPart_001_01C8BA8B.537CC359 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
  As I said, my view is that the primarily = focus=20 should be MIPv6 and PMIPv6. Then, DSMIPv6 and PMIPv6-IPv4 support = could be=20 tackled later in order to provide v4 support.
 
Best Regards
 
Desire

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: May 20, 2008 10:35=20 AM
To: Desire Oulai; multimob@ietf.org
Subject: = Re:=20 [multimob] MLD HLD Message

So=20 should Multimob concentrate on MIPv6, PMIPv6 and DSMIPv6 solutions? =
What=20 about v4 solutions?



Regards,

Behcet

-----=20 Original Message ----
From: Desire Oulai=20 <desire.oulai@ericsson.com>
To: multimob@ietf.org
Sent: = Friday,=20 May 16, 2008 8:39:39 AM
Subject: Re: [multimob] MLD HLD = Message

Hi=20 Alvaro,

Just to clarify that 3GPP also uses DSMIP6 which is a = "MIPv6=20 with IPv4
support". I agree that it is better to focus first on = solutions=20 for
MIPv6 and PMIPv6. These solutions could be extended = later.

Best=20 Regards

Desire

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

------_=_NextPart_001_01C8BA8B.537CC359-- --===============0816949343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0816949343==-- From multimob-bounces@ietf.org Tue May 20 20:58:07 2008 Return-Path: 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 8A5B73A735D; Tue, 20 May 2008 20:58:07 -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 2B75A3A6FFF for ; Tue, 20 May 2008 20:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 Cv2CdqdsA3tD for ; Tue, 20 May 2008 20:58:03 -0700 (PDT) Received: from web84315.mail.re1.yahoo.com (web84315.mail.re1.yahoo.com [69.147.74.194]) by core3.amsl.com (Postfix) with SMTP id 7E4A528CABB for ; Tue, 20 May 2008 07:35:09 -0700 (PDT) Received: (qmail 93788 invoked by uid 60001); 20 May 2008 14:35:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=ntx9jn51opUWp1Xv39d1y3WdSI0uEAWj2gwK6fzinc5FlUPv9TrB1F9nhUMiu3eNeSdR/saU1UWG8IqPd2Z2j37cBXeKe6EKo0xFDBzoXOfFPlfzH4ZBbeAg+mFqk4FnsY0wqB1E76feahlfCwq8TJhi4CHwbtb+15GHsa+a+w8=; X-YMail-OSG: 5OWafo4VM1mGVlDAPJ.ha3Dg5rbYxmOzDcW40CEqgYqNNHCEYmhuaf.zmjInENQJd76wZLcPg8EY.17G8toW.o5yB41zLq2idsI3DwdQ5ffLGSEFjDAEWQaOZ_c- Received: from [206.16.17.212] by web84315.mail.re1.yahoo.com via HTTP; Tue, 20 May 2008 07:35:09 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 20 May 2008 07:35:09 -0700 (PDT) From: Behcet Sarikaya To: Desire Oulai , multimob@ietf.org MIME-Version: 1.0 Message-ID: <499986.93086.qm@web84315.mail.re1.yahoo.com> Subject: Re: [multimob] MLD HLD Message X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713191456==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1713191456== Content-Type: multipart/alternative; boundary="0-1960489837-1211294109=:93086" --0-1960489837-1211294109=:93086 Content-Type: text/plain; charset=us-ascii So should Multimob concentrate on MIPv6, PMIPv6 and DSMIPv6 solutions? What about v4 solutions? Regards, Behcet ----- Original Message ---- From: Desire Oulai To: multimob@ietf.org Sent: Friday, May 16, 2008 8:39:39 AM Subject: 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 --0-1960489837-1211294109=:93086 Content-Type: text/html; charset=us-ascii
So should Multimob concentrate on MIPv6, PMIPv6 and DSMIPv6 solutions?
What about v4 solutions?



Regards,

Behcet

----- Original Message ----
From: Desire Oulai <desire.oulai@ericsson.com>
To: multimob@ietf.org
Sent: Friday, May 16, 2008 8:39:39 AM
Subject: 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

--0-1960489837-1211294109=:93086-- --===============1713191456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1713191456==-- From multimob-bounces@ietf.org Wed May 21 07:50:41 2008 Return-Path: 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 85D623A69A1; Wed, 21 May 2008 07:50:41 -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 DDF353A69A1 for ; Wed, 21 May 2008 07:50:40 -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=[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 axbZzSWbZl+s for ; Wed, 21 May 2008 07:50:37 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 92EDA3A6811 for ; Wed, 21 May 2008 07:50:36 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1949290tib.25 for ; Wed, 21 May 2008 07:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hFvh0t0MFRSv59Qc6NJ42EwlhIq1ZvgSOYugIvmqifQ=; b=T/hgn8mKV6GhlGQb7G3pnqLjxkMVysgI4akNdCawsEJ76vSmR13tFyXlztkOZXP8igungHf/BRFQLeZgj5iqbvpvDV7QnPbX9REmjaEBQJltEYNcp0TwxoYACH6Zthp/sQ8eOuf4n0qMpStgi4clh6Lf7WMZBfz03CLROH9FsZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K1ptIiTdi85on/gEaH9/fsOIiQ6XnXM01UtZuDzrOURKie80B9SZKpqebBWt4MCzO8SseGKaJzRfrKc+ANt9YZhtR/zysEArjSzkaImQF7I1goDvpRyt4eZyvbzjOeM47NwTsCJ74wWo838K11ygZrT5EucD4JU6wVnJRWLBuMU= Received: by 10.110.28.15 with SMTP id b15mr1281330tib.26.1211381436853; Wed, 21 May 2008 07:50:36 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Wed, 21 May 2008 07:50:36 -0700 (PDT) Message-ID: <1d38a3350805210750i3e1eecabycf4da216abac9b3@mail.gmail.com> Date: Wed, 21 May 2008 22:50:36 +0800 From: "Hui Deng" To: "Marshall Eubanks" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <127168.33711.qm@web84306.mail.re1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org I am just reminding that MBMS doesn't have any IP mobility protocol there, -Hui _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu May 22 02:18:21 2008 Return-Path: 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 E3E9328C135; Thu, 22 May 2008 02:18:21 -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 B35173A6ADB for ; Thu, 22 May 2008 02:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 aC7xMHOqTxqT for ; Thu, 22 May 2008 02:18:21 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id A9E033A6ADE for ; Thu, 22 May 2008 02:18:20 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 11:18:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 11:18:22 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D09A@SEHAN021MB.tcad.telia.se> In-Reply-To: <1d38a3350805210750i3e1eecabycf4da216abac9b3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MLD/IGMP in 3GPP? Thread-Index: Aci7UhRspJJTVXNjSfePrGkrk0hvrgAlnKxg References: <127168.33711.qm@web84306.mail.re1.yahoo.com> <1d38a3350805210750i3e1eecabycf4da216abac9b3@mail.gmail.com> From: To: , X-OriginalArrivalTime: 22 May 2008 09:18:25.0016 (UTC) FILETIME=[C9AAF780:01C8BBEC] Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Hui, We could argue that GTP, is a mobility protocol as much e.g. PMIP is. Anyway, the bottom line is that as long as the MN stays inside 3GPP access system where MBMS is defined, mobility is hidden from entities participating to the multicast delivery. Cheers, Jouni -- Jouni Korhonen TeliaSonera > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org] On Behalf Of Hui Deng > Sent: 21. toukokuuta 2008 17:51 > To: Marshall Eubanks > Cc: multimob@ietf.org > Subject: Re: [multimob] MLD/IGMP in 3GPP? > > > I am just reminding that MBMS doesn't have any IP mobility > protocol there, > > -Hui > _______________________________________________ > 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 From multimob-bounces@ietf.org Thu May 22 02:56:22 2008 Return-Path: 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 0501528C12E; Thu, 22 May 2008 02:56:22 -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 C0DE53A6941 for ; Thu, 22 May 2008 02:56:20 -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=[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 0GiYrg2xS-EV for ; Thu, 22 May 2008 02:56:20 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 9B1CD3A6ADB for ; Thu, 22 May 2008 02:56:19 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2372575tib.25 for ; Thu, 22 May 2008 02:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cmIhcLQk30wpDmdB46MDdccP8paKPAvbDYtW4xr0VOQ=; b=BVO68dsKlwghK0seJ/DUetwznvDs3Cbe83V0xxuse6rR+ZlUh4AyfSteMmTpZMZxivFWtSgkLsOI6iQ8dtD0Kd4l9USIcvb/UrKeCl1hPipgEYtxh95yQW5LK7SzHa2om7EiMU+77BmpvJ2m6pYjTZUEkwNA4XV/hz7meBO9l4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TqvBn//P57ghpwDzNsIL/d+gMCTzPOumJ9ZozHxGtYBCGqUCRxTv9tStNFjYjXy3p0cEyejy95+A8hhvCC4Jh2GW8EjLL6/ZmBwS4iEsVUPOROUMRPpVIq9sLKNnA74iqI8OTVfV+MJVkSiOCdMn07ifdmt8ovacthiGhXlbhEU= Received: by 10.110.41.17 with SMTP id o17mr1414308tio.5.1211450181360; Thu, 22 May 2008 02:56:21 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Thu, 22 May 2008 02:56:21 -0700 (PDT) Message-ID: <1d38a3350805220256r122810ebt1911c874c34aed44@mail.gmail.com> Date: Thu, 22 May 2008 17:56:21 +0800 From: "Hui Deng" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D09A@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <127168.33711.qm@web84306.mail.re1.yahoo.com> <1d38a3350805210750i3e1eecabycf4da216abac9b3@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D09A@SEHAN021MB.tcad.telia.se> Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi, Jouni, You are right, we could treat GTP as a kind of mobility protocol, but there layer 2 mobility will decide handover, network(GTP) just do the follow work, thanks for the discussion. Regards, -Hui 2008/5/22 : > Hi Hui, > > We could argue that GTP, is a mobility protocol as much e.g. PMIP is. > Anyway, the bottom line is that as long as the MN stays inside 3GPP > access system where MBMS is defined, mobility is hidden from entities > participating to the multicast delivery. > > Cheers, > Jouni > > -- > Jouni Korhonen > TeliaSonera > >> -----Original Message----- >> From: multimob-bounces@ietf.org >> [mailto:multimob-bounces@ietf.org] On Behalf Of Hui Deng >> Sent: 21. toukokuuta 2008 17:51 >> To: Marshall Eubanks >> Cc: multimob@ietf.org >> Subject: Re: [multimob] MLD/IGMP in 3GPP? >> >> >> I am just reminding that MBMS doesn't have any IP mobility >> protocol there, >> >> -Hui >> _______________________________________________ >> 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 From multimob-bounces@ietf.org Thu May 22 08:04:35 2008 Return-Path: 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 F32F53A6B29; Thu, 22 May 2008 08:04:34 -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 5430528C2AA for ; Thu, 22 May 2008 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 M7szk2a4Et84 for ; Thu, 22 May 2008 08:04:32 -0700 (PDT) Received: from web84312.mail.re1.yahoo.com (web84312.mail.re1.yahoo.com [69.147.74.191]) by core3.amsl.com (Postfix) with SMTP id 188DE28C2A3 for ; Thu, 22 May 2008 08:04:32 -0700 (PDT) Received: (qmail 70089 invoked by uid 60001); 22 May 2008 15:04:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=itCpY2HpWHjDV70i96sYolFYvqSZWBYsf0xX/1FK6yxNd0jWKvePJXiRWH850xMMCV1mNwxqNFO7iR9cMFG+7BrT9XEbCqz53KiJKMSNY59EG/0nMQENJX7reF73io2gwt1c5agSkWDKRSD8w8bX90dZ+cXbu6c+PaoQwJtJsKM=; X-YMail-OSG: jNlrj3gVM1kQLF_mnpzsaOCHkPgZ1fV8TgOi2BxzyU_Njer2hfd8EsOXR.epW9tZPHGE2_rxnDOduIb8.Vfs163PrBw02SzR_E5oZ4uhhwSxIEf7qJD90rXg.Qk- Received: from [206.16.17.212] by web84312.mail.re1.yahoo.com via HTTP; Thu, 22 May 2008 08:04:35 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 22 May 2008 08:04:35 -0700 (PDT) From: Behcet Sarikaya To: Hui Deng , jouni.korhonen@teliasonera.com MIME-Version: 1.0 Message-ID: <705749.69451.qm@web84312.mail.re1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] MLD/IGMP in 3GPP? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0718273326==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0718273326== Content-Type: multipart/alternative; boundary="0-997569598-1211468675=:69451" --0-997569598-1211468675=:69451 Content-Type: text/plain; charset=us-ascii Hui, Jouni, 3GPP recently embraced IETF mobility protocols like PMIP6 and DSMIP6 which are more relevant to Multimob. Regards, Behcet ----- Original Message ---- From: Hui Deng To: jouni.korhonen@teliasonera.com Cc: multimob@ietf.org Sent: Thursday, May 22, 2008 4:56:21 AM Subject: Re: [multimob] MLD/IGMP in 3GPP? Hi, Jouni, You are right, we could treat GTP as a kind of mobility protocol, but there layer 2 mobility will decide handover, network(GTP) just do the follow work, thanks for the discussion. Regards, -Hui 2008/5/22 : > Hi Hui, > > We could argue that GTP, is a mobility protocol as much e.g. PMIP is. > Anyway, the bottom line is that as long as the MN stays inside 3GPP > access system where MBMS is defined, mobility is hidden from entities > participating to the multicast delivery. > > Cheers, > Jouni > > -- > Jouni Korhonen > TeliaSonera > >> -----Original Message----- >> From: multimob-bounces@ietf.org >> [mailto:multimob-bounces@ietf.org] On Behalf Of Hui Deng >> Sent: 21. toukokuuta 2008 17:51 >> To: Marshall Eubanks >> Cc: multimob@ietf.org >> Subject: Re: [multimob] MLD/IGMP in 3GPP? >> >> >> I am just reminding that MBMS doesn't have any IP mobility >> protocol there, >> >> -Hui >> _______________________________________________ >> 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 --0-997569598-1211468675=:69451 Content-Type: text/html; charset=us-ascii
Hui, Jouni,
  3GPP recently embraced IETF mobility protocols like PMIP6 and DSMIP6 which are more relevant to Multimob.

Regards,

Behcet

----- Original Message ----
From: Hui Deng <denghui02@gmail.com>
To: jouni.korhonen@teliasonera.com
Cc: multimob@ietf.org
Sent: Thursday, May 22, 2008 4:56:21 AM
Subject: Re: [multimob] MLD/IGMP in 3GPP?

Hi, Jouni,

You are right, we could treat GTP as a kind of mobility protocol,
but there layer 2 mobility will decide handover, network(GTP) just do
the follow work,

thanks for the discussion.
Regards,

-Hui

2008/5/22  <jouni.korhonen@teliasonera.com>:
> Hi Hui,
>
> We could argue that GTP, is a mobility protocol as much e.g. PMIP is.
> Anyway, the bottom line is that as long as the MN stays inside 3GPP
> access system where MBMS is defined, mobility is hidden from entities
> participating to the multicast delivery.
>
> Cheers,
>        Jouni
>
> --
> Jouni Korhonen
> TeliaSonera
>
>> -----Original Message-----
>> From: multimob-bounces@ietf.org
>> [mailto:multimob-bounces@ietf.org] On Behalf Of Hui Deng
>> Sent: 21. toukokuuta 2008 17:51
>> To: Marshall Eubanks
>> Cc: multimob@ietf.org
>> Subject: Re: [multimob] MLD/IGMP in 3GPP?
>>
>>
>> I am just reminding that MBMS doesn't have any IP mobility
>> protocol there,
>>
>> -Hui
>> _______________________________________________
>> 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

--0-997569598-1211468675=:69451-- --===============0718273326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0718273326==--