From multimob-bounces@ietf.org Wed May 23 17:08:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqy4F-0000sN-4D; Wed, 23 May 2007 17:08:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqy4E-0000ox-J3 for multimob@ietf.org; Wed, 23 May 2007 17:08:22 -0400 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hqy4D-0004Nx-8u for multimob@ietf.org; Wed, 23 May 2007 17:08:22 -0400 Received: (qmail 16751 invoked by uid 60001); 23 May 2007 21:08:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Z+oG59fWXpwmXTTqHIawA0gcNzjXueJ+rj5yVawitO/pi48/JIvMY9/r2qGl35yQhgfWll4r+AxBkmcQtzEaAhlmIxwx3KfrWhqCtq1dH55GFDb4W4mmOeQQ7yf+zn4HXh6AQRLUi0K+Vev3zhCTbMXDw72bDYI/C8SIDVJ3bJg=; Received: from [206.16.17.212] by web84106.mail.mud.yahoo.com via HTTP; Wed, 23 May 2007 14:08:20 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Wed, 23 May 2007 14:08:20 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <671264.15535.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [multimob] What is multicast mobility? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 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="===============1787216792==" Errors-To: multimob-bounces@ietf.org --===============1787216792== Content-Type: multipart/alternative; boundary="0-845027169-1179954500=:15535" --0-845027169-1179954500=:15535 Content-Type: text/plain; charset=ascii Hello Folks, Suresh, Thomas and I initiated this activity and now I would like to propose a work plan and get your comments and reactions. Item 1. Work on MLDv2 extensions. This work will concentrate on the router part and will involve how to track per-host multicast listener status and build per host context. Per host multicast listener context block, etc. will be defined. Item 2. Base protocol MIPv6 extensions on handling multicast sessions such as bandwidth inefficiency inherent in the home agent's unicasting multicast packets through the tunnel. Item 3. Handoff survival of local (at a foreign link) multicast sessions will be taken up in the context of care-of address based multicast group subscriptions. We solicit draft submissions in the above or related areas for IETF-69 as well as discussions on the mailing list so that we can organize an adhoc BOF meeting in Chicago. Any comments? Regards, Behcet --0-845027169-1179954500=:15535 Content-Type: text/html; charset=ascii
Hello Folks,
  Suresh, Thomas and I initiated this activity and now I would like to propose a work plan and get your comments and reactions.
 
Item 1.
Work on MLDv2 extensions. This work will concentrate on the router part and will involve how to track
per-host multicast listener status and build per host context. Per host multicast listener
context block, etc. will be defined.

Item 2.
Base protocol MIPv6 extensions on handling multicast sessions such as bandwidth inefficiency inherent in the home agent's unicasting  multicast packets through the tunnel.

Item 3.
Handoff survival of local (at a foreign link) multicast sessions will be taken up in the context of care-of address based multicast group subscriptions.


  We solicit draft submissions in the above or related areas for IETF-69 as well as discussions on the mailing list so that we can organize an adhoc BOF meeting in Chicago.

  Any comments?

Regards,

Behcet

--0-845027169-1179954500=:15535-- --===============1787216792== 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://www1.ietf.org/mailman/listinfo/multimob --===============1787216792==-- From multimob-bounces@ietf.org Thu May 24 01:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr6EX-0002sF-Hk; Thu, 24 May 2007 01:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr6EV-0002sA-Pw for multimob@ietf.org; Thu, 24 May 2007 01:51:31 -0400 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr6EU-0002dq-6l for multimob@ietf.org; Thu, 24 May 2007 01:51:31 -0400 Received: from localhost (net56-dhcp-1662.sfc.keio.ac.jp [133.27.63.126]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 503B54CCBB; Thu, 24 May 2007 14:51:28 +0900 (JST) Date: Thu, 24 May 2007 14:54:46 +0900 (JST) Message-Id: <20070524.145446.35472147.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com Subject: Re: [multimob] What is multicast mobility? From: Hitoshi Asaeda In-Reply-To: <671264.15535.qm@web84106.mail.mud.yahoo.com> References: <671264.15535.qm@web84106.mail.mud.yahoo.com> X-Mailer: Mew version 5.1 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimob-bounces@ietf.org Hello Behcet, > Item 1. > Work on MLDv2 extensions. This work will concentrate on the router > part and will involve how to track > per-host multicast listener status and build per host context. Per > host multicast listener > context block, etc. will be defined. As you may know, the standard specification of MLDv2 is very complex for regular or low-cost mobile terminals. In fact, MBONED WG has been working on the "Lightweight IGMPv3 and MLDv2" specification. http://www.ietf.org/internet-drafts/draft-ietf-mboned-lightweight-igmpv3-mldv2-00.txt This spec mainly aims to simplify the protocol spec by eliminating an EXCLUDE filter-mdoe operation from the standard protocols and corresponding message types. These protocols would also reduce the implementation costs, while they keep interoperability with the standard protocols. We are currently working for the implementation design and its actual implementations. If you are interested in this proposal, you may want to read the I-D. We'd welcome your comment. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu May 24 05:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrA2U-00015t-2P; Thu, 24 May 2007 05:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrA2S-00015k-Dx for multimob@ietf.org; Thu, 24 May 2007 05:55:20 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrA2R-0001sD-Sn for multimob@ietf.org; Thu, 24 May 2007 05:55:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1180000518!5446301!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 8971 invoked from network); 24 May 2007 09:55:18 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-13.tower-128.messagelabs.com with SMTP; 24 May 2007 09:55:18 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l4O9pXXY020748; Thu, 24 May 2007 02:51:33 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l4O9pWhR003606; Thu, 24 May 2007 04:51:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4O9pUME003523; Thu, 24 May 2007 04:51:31 -0500 (CDT) Message-ID: <4655601D.2010903@gmail.com> Date: Thu, 24 May 2007 11:51:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [multimob] What is multicast mobility? References: <671264.15535.qm@web84106.mail.mud.yahoo.com> In-Reply-To: <671264.15535.qm@web84106.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000742-1, 22/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimob-bounces@ietf.org Behcet Sarikaya wrote: > Hello Folks, Suresh, Thomas and I initiated this activity and now I > would like to propose a work plan and get your comments and > reactions. > > Item 1. Work on MLDv2 extensions. This work will concentrate on the > router part and will involve how to track per-host multicast listener > status and build per host context. Per host multicast listener > context block, etc. will be defined. Sorry, isn't MLDv2 router implementation already keeping track of listener status? > Item 2. Base protocol MIPv6 extensions on handling multicast sessions > such as bandwidth inefficiency inherent in the home agent's > unicasting multicast packets through the tunnel. What could the HA do? Not unicast the multicast packets through the tunnel? > Item 3. Handoff survival of local (at a foreign link) multicast > sessions will be taken up in the context of care-of address based > multicast group subscriptions. What's the influence of re-subscribing a new CoA upon each movement, on the infrastructure routing? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu May 24 09:06:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrD0v-0004EL-LL; Thu, 24 May 2007 09:05:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrD0u-0004EF-Df for multimob@ietf.org; Thu, 24 May 2007 09:05:56 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrD0t-0007AD-8J for multimob@ietf.org; Thu, 24 May 2007 09:05:56 -0400 Received: by an-out-0708.google.com with SMTP id c17so35598anc for ; Thu, 24 May 2007 06:05:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lexzXglufY3KFX8AR2I6uY+wr+1mawB5K8q9gRKZPfX6GZKzGVovgWrGfInAIkqy3kUOoanBAsYq7F/Mv343XoGq4M4NCoXQ5gJZJcjHkZpW/e5LP4DiyxinvIU70iJMQwZtGYiUyHhUjVxViD6EwQwA1HDduWBiTSoPiOd6Xpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GoTIbFqp5NLvm3uDdWAMbR2sbuH3ny2S0JNlZY5auh/tDpJ0VejMc0Z6/rR32Rwr8SPNC+AENDA2n9bJog+Bet4lGOymffd+4Oc8AZSyz76VWQaDiUV1kU98oP7TvtADzl5e+c7+q6P6lbeV9esy1aWdNk9XmCIFO9W3/IRnS1s= Received: by 10.78.201.10 with SMTP id y10mr476001huf.1180011948373; Thu, 24 May 2007 06:05:48 -0700 (PDT) Received: by 10.78.159.1 with HTTP; Thu, 24 May 2007 06:05:48 -0700 (PDT) Message-ID: <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com> Date: Thu, 24 May 2007 16:05:48 +0300 From: "Decoy M" To: "Alexandru Petrescu" Subject: Re: [multimob] What is multicast mobility? In-Reply-To: <4655601D.2010903@gmail.com> MIME-Version: 1.0 References: <671264.15535.qm@web84106.mail.mud.yahoo.com> <4655601D.2010903@gmail.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0741135011==" Errors-To: multimob-bounces@ietf.org --===============0741135011== Content-Type: multipart/alternative; boundary="----=_Part_70947_15843336.1180011948314" ------=_Part_70947_15843336.1180011948314 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 5/24/07, Alexandru Petrescu wrote: > > Behcet Sarikaya wrote: > > Hello Folks, Suresh, Thomas and I initiated this activity and now I > > would like to propose a work plan and get your comments and > > reactions. > > > > Item 1. Work on MLDv2 extensions. This work will concentrate on the > > router part and will involve how to track per-host multicast listener > > status and build per host context. Per host multicast listener > > context block, etc. will be defined. > > Sorry, isn't MLDv2 router implementation already keeping track of > listener status? [Decoy] I think most of th routers doesnt keep track of the indivisual multicast listeners but they just check whether some bosyis interested in the multicast channel or not. So explicit Host tracking may not be required. This requires table maintainance and other work as each and every Host information needs to be stored and maintained. > Item 2. Base protocol MIPv6 extensions on handling multicast sessions > > such as bandwidth inefficiency inherent in the home agent's > > unicasting multicast packets through the tunnel. > > What could the HA do? Not unicast the multicast packets through the > tunnel? > > > Item 3. Handoff survival of local (at a foreign link) multicast > > sessions will be taken up in the context of care-of address based > > multicast group subscriptions. > > What's the influence of re-subscribing a new CoA upon each movement, on > the infrastructure routing? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob > ------=_Part_70947_15843336.1180011948314 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 5/24/07, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Behcet Sarikaya wrote:
> Hello Folks, Suresh, Thomas and I initiated this activity and now I
> would like to propose a work plan and get your comments and
> reactions.
>
> Item 1. Work on MLDv2 extensions. This work will concentrate on the
> router part and will involve how to track per-host multicast listener
> status and build per host context. Per host multicast listener
> context block, etc. will be defined.

Sorry, isn't MLDv2 router implementation already keeping track of
listener status?
 
[Decoy] I think most of th routers doesnt keep track of the indivisual multicast listeners but they just check whether some bosyis interested in the multicast channel or not. So explicit Host tracking may not be required. This requires table maintainance and other work as each and every Host information needs to be stored and maintained.

> Item 2. Base protocol MIPv6 extensions on handling multicast sessions
> such as bandwidth inefficiency inherent in the home agent's
> unicasting multicast packets through the tunnel.

What could the HA do?  Not unicast the multicast packets through the tunnel?

> Item 3. Handoff survival of local (at a foreign link) multicast
> sessions will be taken up in the context of care-of address based
> multicast group subscriptions.

What's the influence of re-subscribing a new CoA upon each movement, on
the infrastructure routing?

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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

------=_Part_70947_15843336.1180011948314-- --===============0741135011== 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://www1.ietf.org/mailman/listinfo/multimob --===============0741135011==-- From multimob-bounces@ietf.org Thu May 24 15:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJE7-0004Mn-St; Thu, 24 May 2007 15:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJE6-0004Mh-CX for multimob@ietf.org; Thu, 24 May 2007 15:43:58 -0400 Received: from web84110.mail.mud.yahoo.com ([68.142.206.197]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrJE5-0003l7-Sz for multimob@ietf.org; Thu, 24 May 2007 15:43:58 -0400 Received: (qmail 94984 invoked by uid 60001); 24 May 2007 19:43:57 -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=iT6ouXsjUWs82rjARqh+0BFb0XMHlA8+Ja4M0sno85iOS5QNarAVSCZFdnWAKoIFF/zkBqCj9ZelsC74HcIHsxAaZipw+2gcVK3+6jcHY2UMeNSX3fEtnsa/elLSI/kslTHu8LLne2sW4jNrhjwoXt2lJAfg1QVxeIA0q7Fgvd0=; X-YMail-OSG: gK7GAIgVM1liBF47NBy2VCz3t6mKsoPQ0MHkzoB_fDMUgeOEUFHIH3HXjTPmVDwHNkvEPS0a7JateQpJAmL7Uzn4__NSmF_F5fAg Received: from [206.16.17.212] by web84110.mail.mud.yahoo.com via HTTP; Thu, 24 May 2007 12:43:57 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Thu, 24 May 2007 12:43:57 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [multimob] What is multicast mobility? To: Alexandru Petrescu MIME-Version: 1.0 Message-ID: <316117.94498.qm@web84110.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 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="===============0955396207==" Errors-To: multimob-bounces@ietf.org --===============0955396207== Content-Type: multipart/alternative; boundary="0-439915850-1180035837=:94498" --0-439915850-1180035837=:94498 Content-Type: text/plain; charset=ascii Hi Alex, See inline. Regards, --behcet ----- Original Message ---- From: Alexandru Petrescu To: Behcet Sarikaya Cc: multimob@ietf.org Sent: Thursday, May 24, 2007 4:51:25 AM Subject: Re: [multimob] What is multicast mobility? Behcet Sarikaya wrote: > Hello Folks, Suresh, Thomas and I initiated this activity and now I > would like to propose a work plan and get your comments and > reactions. > > Item 1. Work on MLDv2 extensions. This work will concentrate on the > router part and will involve how to track per-host multicast listener > status and build per host context. Per host multicast listener > context block, etc. will be defined. Sorry, isn't MLDv2 router implementation already keeping track of listener status? > Item 2. Base protocol MIPv6 extensions on handling multicast sessions > such as bandwidth inefficiency inherent in the home agent's > unicasting multicast packets through the tunnel. What could the HA do? Not unicast the multicast packets through the tunnel? [behcet] What about looking into this in more detail and come up with a problem statement? > Item 3. Handoff survival of local (at a foreign link) multicast > sessions will be taken up in the context of care-of address based > multicast group subscriptions. What's the influence of re-subscribing a new CoA upon each movement, on the infrastructure routing? [behcet] I know a few drafts on this, but no problem statement. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob --0-439915850-1180035837=:94498 Content-Type: text/html; charset=ascii
Hi Alex,
See inline.

Regards,

--behcet

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: multimob@ietf.org
Sent: Thursday, May 24, 2007 4:51:25 AM
Subject: Re: [multimob] What is multicast mobility?

Behcet Sarikaya wrote:
> Hello Folks, Suresh, Thomas and I initiated this activity and now I
> would like to propose a work plan and get your comments and
> reactions.
>
> Item 1. Work on MLDv2 extensions. This work will concentrate on the
> router part and will involve how to track per-host multicast listener
> status and build per host context. Per host multicast listener
> context block, etc. will be defined.

Sorry, isn't MLDv2 router implementation already keeping track of
listener status?

> Item 2. Base protocol MIPv6 extensions on handling multicast sessions
> such as bandwidth inefficiency inherent in the home agent's
> unicasting multicast packets through the tunnel.

What could the HA do?  Not unicast the multicast packets through the tunnel?

[behcet] What about looking into this in more detail and come up with a problem statement?


> Item 3. Handoff survival of local (at a foreign link) multicast
> sessions will be taken up in the context of care-of address based
> multicast group subscriptions.

What's the influence of re-subscribing a new CoA upon each movement, on
the infrastructure routing?

[behcet] I know a few drafts on this, but no problem statement.

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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

--0-439915850-1180035837=:94498-- --===============0955396207== 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://www1.ietf.org/mailman/listinfo/multimob --===============0955396207==-- From multimob-bounces@ietf.org Sun May 27 21:29:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsU2q-0007co-9y; Sun, 27 May 2007 21:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsU2p-0007cg-Bn for multimob@ietf.org; Sun, 27 May 2007 21:29:11 -0400 Received: from m5-84.163.com ([202.108.5.84]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HsU2k-0004lY-NR for multimob@ietf.org; Sun, 27 May 2007 21:29:11 -0400 Received: from sunguan (unknown [218.249.29.40]) by smtp4 (Coremail) with SMTP id wKjRDrCr5gRYMFpGkRZ_BA==.57070S2; Mon, 28 May 2007 09:28:56 +0800 (CST) Date: Mon, 28 May 2007 09:28:56 +0800 From: "Tony" To: "multimob@ietf.org" Organization: Beijing JiaoTong University X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-Coremail-Antispam: 1U3Yxn0WfASr-VFAUDIcSsGvfJTRUUUj1CY0x0Ix7I2Y4AK6r Wj6F1UMxkIecxEwVAFwVWkM4xvF2IEb7IF0Fy264kE64k0F24lnxkEFVAIw20F6cxK64vI FxWl6VACY4xI67k04243AwCjxxvEw4WlFcxC0VAYjxAxZF0Ex2IqxwC2zVA0820Y0xCF62 I06xkIj41l4x8a6c8ajcxJM4kE64xI4xA0e2IEY21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1l Yx0Ex4A2jsIE14v26r1j6r4UM7AC8VAFwI0_Jr0_Gr1lb4IE77IF4wAFIxvE14AKwVWUJV WUGwAqx4xG64xvF2IEw4CE5I8CrVC2j2Wlc7Ca8VAvwVA2a4k0FcxrM7k0a2IF6r1Un29K B7ZKAUJUUUUUnxnvy29KBjDU0xZFpf9x07juksgUUUUU129KBjvJXoWxuryfKrykZw45JF y7Kr1Dtrb_yoWrJw1UprsxJF13Kr18J34UAw18A34qvr1YyrW8trWUtr98G3W8JryDAw1U tF45tr1rZFyDGryYkw45tr1UCry5Wr15Aw7== Message-Id: <465A305A.1EC37D.18480@m5-84.163.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [multimob] Re: multimob Digest, Vol 2, Issue 4 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: guanjian8632@163.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1081118102==" Errors-To: multimob-bounces@ietf.org --===============1081118102== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo+TWVzc2FnZTogMQ0KPkRhdGU6IFRodSwgMjQgTWF5IDIwMDcgMTY6MDU6NDggKzAzMDANCj5G cm9tOiAiRGVjb3kgTSIgPGRlY295NzdAZ21haWwuY29tPg0KPlN1YmplY3Q6IFJlOiBbbXVsdGlt b2JdIFdoYXQgaXMgbXVsdGljYXN0IG1vYmlsaXR5Pw0KPlRvOiAiQWxleGFuZHJ1IFBldHJlc2N1 IiA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4NCj5DYzogbXVsdGltb2JAaWV0Zi5vcmcN Cj5NZXNzYWdlLUlEOg0KPgk8NDk1ZDc0M2QwNzA1MjQwNjA1ajc3YzQ3ZTlhbDM5ZTY5NmZkZDM5 OWU0ZmRAbWFpbC5nbWFpbC5jb20+DQo+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0 PSJpc28tODg1OS0xIg0KPg0KPk9uIDUvMjQvMDcsIEFsZXhhbmRydSBQZXRyZXNjdSA8YWxleGFu ZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pg0KPj4gQmVoY2V0IFNhcmlrYXlhIHdy b3RlOg0KPj4gPiBIZWxsbyBGb2xrcywgU3VyZXNoLCBUaG9tYXMgYW5kIEkgaW5pdGlhdGVkIHRo aXMgYWN0aXZpdHkgYW5kIG5vdyBJDQo+PiA+IHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBhIHdvcmsg cGxhbiBhbmQgZ2V0IHlvdXIgY29tbWVudHMgYW5kDQo+PiA+IHJlYWN0aW9ucy4NCj4+ID4NCj4+ ID4gSXRlbSAxLiBXb3JrIG9uIE1MRHYyIGV4dGVuc2lvbnMuIFRoaXMgd29yayB3aWxsIGNvbmNl bnRyYXRlIG9uIHRoZQ0KPj4gPiByb3V0ZXIgcGFydCBhbmQgd2lsbCBpbnZvbHZlIGhvdyB0byB0 cmFjayBwZXItaG9zdCBtdWx0aWNhc3QgbGlzdGVuZXINCj4+ID4gc3RhdHVzIGFuZCBidWlsZCBw ZXIgaG9zdCBjb250ZXh0LiBQZXIgaG9zdCBtdWx0aWNhc3QgbGlzdGVuZXINCj4+ID4gY29udGV4 dCBibG9jaywgZXRjLiB3aWxsIGJlIGRlZmluZWQuDQo+Pg0KPj4gU29ycnksIGlzbid0IE1MRHYy IHJvdXRlciBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5IGtlZXBpbmcgdHJhY2sgb2YNCj4+IGxpc3Rl bmVyIHN0YXR1cz8NCj4NCj4NCj5bRGVjb3ldIEkgdGhpbmsgbW9zdCBvZiB0aCByb3V0ZXJzIGRv ZXNudCBrZWVwIHRyYWNrIG9mIHRoZSBpbmRpdmlzdWFsDQo+bXVsdGljYXN0IGxpc3RlbmVycyBi dXQgdGhleSBqdXN0IGNoZWNrIHdoZXRoZXIgc29tZSBib3N5aXMgaW50ZXJlc3RlZCBpbg0KPnRo ZSBtdWx0aWNhc3QgY2hhbm5lbCBvciBub3QuIFNvIGV4cGxpY2l0IEhvc3QgdHJhY2tpbmcgbWF5 IG5vdCBiZSByZXF1aXJlZC4NCj5UaGlzIHJlcXVpcmVzIHRhYmxlIG1haW50YWluYW5jZSBhbmQg b3RoZXIgd29yayBhcyBlYWNoIGFuZCBldmVyeSBIb3N0DQo+aW5mb3JtYXRpb24gbmVlZHMgdG8g YmUgc3RvcmVkIGFuZCBtYWludGFpbmVkLg0KPg0KPj4gSXRlbSAyLiBCYXNlIHByb3RvY29sIE1J UHY2IGV4dGVuc2lvbnMgb24gaGFuZGxpbmcgbXVsdGljYXN0IHNlc3Npb25zDQo+PiA+IHN1Y2gg YXMgYmFuZHdpZHRoIGluZWZmaWNpZW5jeSBpbmhlcmVudCBpbiB0aGUgaG9tZSBhZ2VudCdzDQo+ PiA+IHVuaWNhc3RpbmcgbXVsdGljYXN0IHBhY2tldHMgdGhyb3VnaCB0aGUgdHVubmVsLg0KPj4N Cj4+IFdoYXQgY291bGQgdGhlIEhBIGRvPyAgTm90IHVuaWNhc3QgdGhlIG11bHRpY2FzdCBwYWNr ZXRzIHRocm91Z2ggdGhlDQo+PiB0dW5uZWw/DQoJSEEgY2FuIHJlY29yZCB0aGUgTU4gaW5mb3Jt YXRpb24gYW5kIG1haW50YWluIE1OJ3MgTUxEIHN0YXRlIGV0Yy4gRm9yd2FyZGluZw0KdGhlIG11 bHRpY2FzdCBkYXRhIHRocm91Z2ggdW5pY2FzdCB0dW5uZWwgaXMganVzdCBvbmUgbW9iaWxlIG11 bHRpY2FzdCBzY2hlbWUuDQo+PiA+IEl0ZW0gMy4gSGFuZG9mZiBzdXJ2aXZhbCBvZiBsb2NhbCAo YXQgYSBmb3JlaWduIGxpbmspIG11bHRpY2FzdA0KPj4gPiBzZXNzaW9ucyB3aWxsIGJlIHRha2Vu IHVwIGluIHRoZSBjb250ZXh0IG9mIGNhcmUtb2YgYWRkcmVzcyBiYXNlZA0KPj4gPiBtdWx0aWNh c3QgZ3JvdXAgc3Vic2NyaXB0aW9ucy4NCj4+DQo+PiBXaGF0J3MgdGhlIGluZmx1ZW5jZSBvZiBy ZS1zdWJzY3JpYmluZyBhIG5ldyBDb0EgdXBvbiBlYWNoIG1vdmVtZW50LCBvbg0KPj4gdGhlIGlu ZnJhc3RydWN0dXJlIHJvdXRpbmc/DQogICBJZiB0aGUgTmV3IEFSIHdoaWNoIE1OIGF0dGFjaGVk IGhhcyB0aGUgbXVsdGljYXN0IGdyb3VwIHN0YXRlIHRoYXQgTU4gc3Vic2NyaWJlZCwgdGhlIA0K bXVsdGljYXN0IGRpc3J1cHRpb24gdGltZSBpcyBzaG9ydCAoMTAwfjIwMG1zKS4gd2hpbGUgaWYg TmV3IEFSIGRvZXNuJ3QgaGF2ZSB0aGUgZ3JvdXANCnN0YXRlcywgaXQgd2lsbCB0YWtlIGEgbG9u ZyB0aW1lIHRvIHJlam9pbiB0aGUgZ3JvdXBzLg0KIA0KCU91ciBncm91cCBpcyB3b3JraW5nIG9u IGltcGxlbWVudGF0aW9uIG9mIG1vYmlsZSBtdWx0aWNhc3QgaW4gcmVhbCBhcHBpbGljYXRpb24g cmVjZW50bHkuDQpXZWxjb21lIGV2ZXJ5b25lIHRvIGRpc2N1c3MuDQo+PiBBbGV4DQo+Pg0KPj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IFRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBieSB0aGUg TWVzc2FnZUxhYnMgRW1haWwgU2VjdXJpdHkgU3lzdGVtLg0KPj4gRm9yIG1vcmUgaW5mb3JtYXRp b24gcGxlYXNlIHZpc2l0IGh0dHA6Ly93d3cubWVzc2FnZWxhYnMuY29tL2VtYWlsDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IG11bHRpbW9iIG1haWxpbmcgbGlzdA0KPj4gbXVsdGltb2JAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9iDQo+Pg0K Pi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KPkFuIEhUTUwgYXR0YWNo bWVudCB3YXMgc2NydWJiZWQuLi4NCj5VUkw6IGh0dHA6Ly93d3cxLmlldGYub3JnL3BpcGVybWFp bC9tdWx0aW1vYi9hdHRhY2htZW50cy8yMDA3MDUyNC9lMzhjMDM1NC9hdHRhY2htZW50Lmh0bWwN Cj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm11bHRpbW9iIG1haWxpbmcgbGlzdA0K Pm11bHRpbW9iQGlldGYub3JnDQo+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXVsdGltb2INCj4NCj4NCj5FbmQgb2YgbXVsdGltb2IgRGlnZXN0LCBWb2wgMiwgSXNzdWUg NA0KPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQoNCj0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJIA0KoaGhoaGhoaGhoaGhoaGhoVRv bnkNCqGhoaGhoaGhoaGhoaGhoaFndWFuamlhbjg2MzJAMTYzLmNvbQ0KoaGhoaGhoaGhoaGhoaGh oaGhoaEyMDA3LTA1LTI4DQogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KIHwJTkdJUkMsIEJlaWppbmcgSmlhb1RvbmcgVW5pdmVyc2l0eQl8DQogfAlCZWlKaW5nLCBD aGluYSwxMDAwNDQJCQkJfA0KIHwJSHR0cDovL3d3dy5uanR1LmVkdS5jbgkJCQl8DQogKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQo= --===============1081118102== 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://www1.ietf.org/mailman/listinfo/multimob --===============1081118102==-- From multimob-bounces@ietf.org Tue May 29 03:11:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsvro-0008S1-VK; Tue, 29 May 2007 03:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsvro-0008Rw-DC for multimob@ietf.org; Tue, 29 May 2007 03:11:40 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsvrk-0006JZ-Ps for multimob@ietf.org; Tue, 29 May 2007 03:11:40 -0400 Received: by py-out-1112.google.com with SMTP id a25so3243914pyi for ; Tue, 29 May 2007 00:11:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Yk50LzIndoDNEQldcjKyXJeG9yEfFp/ENs17QcN3johgyFM22G2irZTPhQ9wWJBCu9NQr351iukR0YLKGw/bSX+PKIJ2u9/Y1KOoa2IVKrLgP8TfPoUsFS9EkvHxd056TNA2Tfnm/7UJa29WXWzM+zEZsgkvWpnyEbnxBqusrNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=keebhjQTp35fypRnZMxUMiFupxXYluMJBGCKcTyY7J0f8V1bVh+aK5CbuQygJS7PrQ/V4g366Sx6Iqbswwj1l9h7+kKp+QS0uPv4nhRpe2W9YxYAIKYsoMQI4KuYx/eMF6OwcvauNCIMLC2ste0y6Q7cQ2WST+D3CtT1xrxfEI0= Received: by 10.65.214.19 with SMTP id r19mr12193224qbq.1180422695582; Tue, 29 May 2007 00:11:35 -0700 (PDT) Received: by 10.65.176.15 with HTTP; Tue, 29 May 2007 00:11:35 -0700 (PDT) Message-ID: Date: Tue, 29 May 2007 16:11:35 +0900 From: "Jong-Hyouk Lee" To: guanjian8632@163.com Subject: Re: [multimob] Re: multimob Digest, Vol 2, Issue 4 In-Reply-To: <465A305A.1EC37D.18480@m5-84.163.com> MIME-Version: 1.0 References: <465A305A.1EC37D.18480@m5-84.163.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1586040606==" Errors-To: multimob-bounces@ietf.org --===============1586040606== Content-Type: multipart/alternative; boundary="----=_Part_94262_3174451.1180422695536" ------=_Part_94262_3174451.1180422695536 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Tony. I'd like to ask you. In the previous e-mail, you mentioned that your group is working on implementation of mobile multicast in real appilication. Is it based on MIPL stack? Is there any specific documents or guideline? I don't think so. What is your guideline? I just want to know because I seem to have forgotten big one. Cheers. On 5/28/07, Tony wrote: > > > >Message: 1 > >Date: Thu, 24 May 2007 16:05:48 +0300 > >From: "Decoy M" > >Subject: Re: [multimob] What is multicast mobility? > >To: "Alexandru Petrescu" > >Cc: multimob@ietf.org > >Message-ID: > > <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com> > >Content-Type: text/plain; charset="iso-8859-1" > > > >On 5/24/07, Alexandru Petrescu wrote: > >> > >> Behcet Sarikaya wrote: > >> > Hello Folks, Suresh, Thomas and I initiated this activity and now I > >> > would like to propose a work plan and get your comments and > >> > reactions. > >> > > >> > Item 1. Work on MLDv2 extensions. This work will concentrate on the > >> > router part and will involve how to track per-host multicast listener > >> > status and build per host context. Per host multicast listener > >> > context block, etc. will be defined. > >> > >> Sorry, isn't MLDv2 router implementation already keeping track of > >> listener status? > > > > > >[Decoy] I think most of th routers doesnt keep track of the indivisual > >multicast listeners but they just check whether some bosyis interested in > >the multicast channel or not. So explicit Host tracking may not be > required. > >This requires table maintainance and other work as each and every Host > >information needs to be stored and maintained. > > > >> Item 2. Base protocol MIPv6 extensions on handling multicast sessions > >> > such as bandwidth inefficiency inherent in the home agent's > >> > unicasting multicast packets through the tunnel. > >> > >> What could the HA do? Not unicast the multicast packets through the > >> tunnel? > HA can record the MN information and maintain MN's MLD state etc. > Forwarding > the multicast data through unicast tunnel is just one mobile multicast > scheme. > >> > Item 3. Handoff survival of local (at a foreign link) multicast > >> > sessions will be taken up in the context of care-of address based > >> > multicast group subscriptions. > >> > >> What's the influence of re-subscribing a new CoA upon each movement, on > >> the infrastructure routing? > If the New AR which MN attached has the multicast group state that MN > subscribed, the > multicast disruption time is short (100~200ms). while if New AR doesn't > have the group > states, it will take a long time to rejoin the groups. > > Our group is working on implementation of mobile multicast in real > appilication recently. > Welcome everyone to discuss. > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www1.ietf.org/mailman/listinfo/multimob > >> > >-------------- next part -------------- > >An HTML attachment was scrubbed... > >URL: > http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/attachment.html > > > >------------------------------ > > > >_______________________________________________ > >multimob mailing list > >multimob@ietf.org > >https://www1.ietf.org/mailman/listinfo/multimob > > > > > >End of multimob Digest, Vol 2, Issue 4 > >************************************** > > > > = = = = = = = = = = = = = = = = = = = = > > Tony > guanjian8632@163.com > 2007-05-28 > +--------------------------------------+ > | NGIRC, Beijing JiaoTong University | > | BeiJing, China,100044 | > | Http://www.njtu.edu.cn | > +--------------------------------------+ > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob > > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_94262_3174451.1180422695536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Tony.
 
I'd like to ask you. In the previous e-mail, you mentioned that your group is working on implementation of mobile multicast in real appilication. Is it based on MIPL stack? Is there any specific documents or guideline? I don't think so.
 
What is your guideline? I just want to know because I seem to have forgotten big one.
 
Cheers.  

 
On 5/28/07, Tony <guanjian8632@163.com> wrote:

>Message: 1
>Date: Thu, 24 May 2007 16:05:48 +0300
>From: "Decoy M" < decoy77@gmail.com>
>Subject: Re: [multimob] What is multicast mobility?
>To: "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
>Cc: multimob@ietf.org
>Message-ID:
>       <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com >
>Content-Type: text/plain; charset="iso-8859-1"
>
>On 5/24/07, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
>>
>> Behcet Sarikaya wrote:
>> > Hello Folks, Suresh, Thomas and I initiated this activity and now I
>> > would like to propose a work plan and get your comments and
>> > reactions.
>> >
>> > Item 1. Work on MLDv2 extensions. This work will concentrate on the
>> > router part and will involve how to track per-host multicast listener
>> > status and build per host context. Per host multicast listener
>> > context block, etc. will be defined.
>>
>> Sorry, isn't MLDv2 router implementation already keeping track of
>> listener status?
>
>
>[Decoy] I think most of th routers doesnt keep track of the indivisual
>multicast listeners but they just check whether some bosyis interested in
>the multicast channel or not. So explicit Host tracking may not be required.
>This requires table maintainance and other work as each and every Host
>information needs to be stored and maintained.
>
>> Item 2. Base protocol MIPv6 extensions on handling multicast sessions
>> > such as bandwidth inefficiency inherent in the home agent's
>> > unicasting multicast packets through the tunnel.
>>
>> What could the HA do?  Not unicast the multicast packets through the
>> tunnel?
       HA can record the MN information and maintain MN's MLD state etc. Forwarding
the multicast data through unicast tunnel is just one mobile multicast scheme.
>> > Item 3. Handoff survival of local (at a foreign link) multicast
>> > sessions will be taken up in the context of care-of address based
>> > multicast group subscriptions.
>>
>> What's the influence of re-subscribing a new CoA upon each movement, on
>> the infrastructure routing?
  If the New AR which MN attached has the multicast group state that MN subscribed, the
multicast disruption time is short (100~200ms). while if New AR doesn't have the group
states, it will take a long time to rejoin the groups.

       Our group is working on implementation of mobile multicast in real appilication recently.
Welcome everyone to discuss.
>> Alex
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> _______________________________________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www1.ietf.org/mailman/listinfo/multimob
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/attachment.html
>
>------------------------------
>
>_______________________________________________
>multimob mailing list
>multimob@ietf.org
>https://www1.ietf.org/mailman/listinfo/multimob
>
>
>End of multimob Digest, Vol 2, Issue 4
>**************************************
>

= = = = = = = = = = = = = = = = = = = =

Tony
guanjian8632@163.com
2007-05-28
+--------------------------------------+
|      NGIRC, Beijing JiaoTong University      |
|      BeiJing, China,100044                           |
|      Http://www.njtu.edu.cn                          |
+--------------------------------------+


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




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_94262_3174451.1180422695536-- --===============1586040606== 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://www1.ietf.org/mailman/listinfo/multimob --===============1586040606==-- From multimob-bounces@ietf.org Tue May 29 05:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsxjn-00037H-Rt; Tue, 29 May 2007 05:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsxjm-000379-U1 for multimob@ietf.org; Tue, 29 May 2007 05:11:30 -0400 Received: from mx1.mimos.my ([192.228.137.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsxji-0007vd-BY for multimob@ietf.org; Tue, 29 May 2007 05:11:30 -0400 MIME-Version: 1.0 From: Shariq Haseeb In-Reply-To: References: To: Thread-Topic: MIPL Based Multicast Thread-Index: Aceh0U00xkFyufz7QAC+YDPddcPlRA== Message-ID: <19D0161D-4FA6-44B6-AD2C-CB3C3F5169EA@mimectl> X-Mailer: Microsoft Outlook Web Access 6.5.7638.1 X-MimeCtl: Produced By Microsoft Exchange V6.5.7638.1 Date: Tue, 29 May 2007 17:11:12 +0800 X-Spam-Score: 0.7 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Subject: [multimob] MIPL Based Multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527175699==" Errors-To: multimob-bounces@ietf.org --===============0527175699== Content-Type: multipart/alternative; boundary="_63578182-619B-4174-94EC-54DDA58CC8DE_" --_63578182-619B-4174-94EC-54DDA58CC8DE_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jong-Hyouk, I would just like to give my comments on Multicast and MIPL. I have done so= me work on mobile multicast with MIPL. What specific areas or applications = of multicast are you interested in? MIPL is a good implementation. I feel it is a very stable MIPv6 implementat= ion. Rgds, Shariq From: multimob-request@ietf.org Sent: Tue 5/29/2007 3:11 PM To: multimob@ietf.org Subject: multimob Digest, Vol 2, Issue 7 Send multimob mailing list submissions to multimob@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/multimob or, via email, send a message with subject or body 'help' to multimob-request@ietf.org You can reach the person managing the list at multimob-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of multimob digest..." Today's Topics: 1. Re: Re: multimob Digest, Vol 2, Issue 4 (Jong-Hyouk Lee) ---------------------------------------------------------------------- Message: 1 Date: Tue, 29 May 2007 16:11:35 +0900 From: "Jong-Hyouk Lee" Subject: Re: [multimob] Re: multimob Digest, Vol 2, Issue 4 To: guanjian8632@163.com Cc: multimob@ietf.org Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Dear Tony. I'd like to ask you. In the previous e-mail, you mentioned that your group is working on implementation of mobile multicast in real appilication. Is i= t based on MIPL stack? Is there any specific documents or guideline? I don't think so. What is your guideline? I just want to know because I seem to have forgotte= n big one. Cheers. On 5/28/07, Tony wrote: > > > >Message: 1 > >Date: Thu, 24 May 2007 16:05:48 +0300 > >From: "Decoy M" > >Subject: Re: [multimob] What is multicast mobility? > >To: "Alexandru Petrescu" > >Cc: multimob@ietf.org > >Message-ID: > > <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail.com> > >Content-Type: text/plain; charset=3D"iso-8859-1" > > > >On 5/24/07, Alexandru Petrescu wrote: > >> > >> Behcet Sarikaya wrote: > >> > Hello Folks, Suresh, Thomas and I initiated this activity and now I > >> > would like to propose a work plan and get your comments and > >> > reactions. > >> > > >> > Item 1. Work on MLDv2 extensions. This work will concentrate on the > >> > router part and will involve how to track per-host multicast listene= r > >> > status and build per host context. Per host multicast listener > >> > context block, etc. will be defined. > >> > >> Sorry, isn't MLDv2 router implementation already keeping track of > >> listener status? > > > > > >[Decoy] I think most of th routers doesnt keep track of the indivisual > >multicast listeners but they just check whether some bosyis interested i= n > >the multicast channel or not. So explicit Host tracking may not be > required. > >This requires table maintainance and other work as each and every Host > >information needs to be stored and maintained. > > > >> Item 2. Base protocol MIPv6 extensions on handling multicast sessions > >> > such as bandwidth inefficiency inherent in the home agent's > >> > unicasting multicast packets through the tunnel. > >> > >> What could the HA do? Not unicast the multicast packets through the > >> tunnel? > HA can record the MN information and maintain MN's MLD state etc. > Forwarding > the multicast data through unicast tunnel is just one mobile multicast > scheme. > >> > Item 3. Handoff survival of local (at a foreign link) multicast > >> > sessions will be taken up in the context of care-of address based > >> > multicast group subscriptions. > >> > >> What's the influence of re-subscribing a new CoA upon each movement, o= n > >> the infrastructure routing? > If the New AR which MN attached has the multicast group state that MN > subscribed, the > multicast disruption time is short (100~200ms). while if New AR doesn't > have the group > states, it will take a long time to rejoin the groups. > > Our group is working on implementation of mobile multicast in real > appilication recently. > Welcome everyone to discuss. > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> _______________________________________________ > >> multimob mailing list > >> multimob@ietf.org > >> https://www1.ietf.org/mailman/listinfo/multimob > >> > >-------------- next part -------------- > >An HTML attachment was scrubbed... > >URL: > http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/att= achment.html > > > >------------------------------ > > > >_______________________________________________ > >multimob mailing list > >multimob@ietf.org > >https://www1.ietf.org/mailman/listinfo/multimob > > > > > >End of multimob Digest, Vol 2, Issue 4 > >************************************** > > > > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D > > Tony > guanjian8632@163.com > 2007-05-28 > +--------------------------------------+ > | NGIRC, Beijing JiaoTong University | > | BeiJing, China,100044 | > | Http://www.njtu.edu.cn | > +--------------------------------------+ > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob > > --=20 Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/multimob/attachments/20070529/7a18fc90/= attachment.html ------------------------------ _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob End of multimob Digest, Vol 2, Issue 7 ************************************** ------------------------------------------------------------------ - - - DISCLAIMER: This e-mail (including any attachments) may contain confidential information. If you are not the intended recipient, you are hereby notified that any dealing, review, distribution, printing, copying or use of this e-mail is strictly prohibited. If you have received this email in error, please notify the sender or MIMOS Berhad immediately and delete the original message. Opinions, conclusions and other information in this e-mail that do not relate to the official business of MIMOS Berhad and/or its subsidiaries shall be understood as neither given nor endorsed by MIMOS Berhad and/or its subsidiaries and neither MIMOS Berhad nor its subsidiaries accepts responsibility for the same. All liability arising from or in connection with computer viruses and/or corrupted e-mails is excluded to the fullest extent permitted by law. --_63578182-619B-4174-94EC-54DDA58CC8DE_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jong-Hyouk,
 
I would just like to give my com= ments on Multicast and MIPL. I have done some work on mobile multicast with= MIPL. What specific areas or applications of multicast are you interested = in?
 
MIPL is a good implementation. I= feel it is a very stable MIPv6 implementation.
 
Rgds,
Shariq


From: multimob-request@ietf.org
S= ent: Tue 5/29/2007 3:11 PM
To: multimob@ietf.org
Subjec= t: multimob Digest, Vol 2, Issue 7

Send multimob mailing list submis=
sions to
	multimob@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/multimob
or, via email, send a message with subject or body 'help' to
	multimob-request@ietf.org

You can reach the person managing the list at
	multimob-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of multimob digest..."


Today's Topics:

   1. Re:  Re: multimob Digest, Vol 2, Issue 4 (Jong-Hyouk Lee)


----------------------------------------------------------------------

Message: 1
Date: Tue, 29 May 2007 16:11:35 +0900
From: "Jong-Hyouk Lee" <jonghyouk@gmail.com>
Subject: Re: [multimob] Re: multimob Digest, Vol 2, Issue 4
To: guanjian8632@163.com
Cc: multimob@ietf.org
Message-ID:
	<f54070070705290011k3b8c9a81j7674452195eee8a9@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Dear Tony.

I'd like to ask you. In the previous e-mail, you mentioned that your group
is working on implementation of mobile multicast in real appilication. Is i=
t
based on MIPL stack? Is there any specific documents or guideline? I don't
think so.

What is your guideline? I just want to know because I seem to have forgotte=
n
big one.

Cheers.


On 5/28/07, Tony <guanjian8632@163.com> wrote:
>
>
> >Message: 1
> >Date: Thu, 24 May 2007 16:05:48 +0300
> >From: "Decoy M" <decoy77@gmail.com>
> >Subject: Re: [multimob] What is multicast mobility?
> >To: "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
> >Cc: multimob@ietf.org
> >Message-ID:
> >       <495d743d0705240605j77c47e9al39e696fdd399e4fd@mail.gmail=
.com>
> >Content-Type: text/plain; charset=3D"iso-8859-1"
> >
> >On 5/24/07, Alexandru Petrescu <alexandru.petrescu@gmail.com>=
; wrote:
> >>
> >> Behcet Sarikaya wrote:
> >> > Hello Folks, Suresh, Thomas and I initiated this activit=
y and now I
> >> > would like to propose a work plan and get your comments =
and
> >> > reactions.
> >> >
> >> > Item 1. Work on MLDv2 extensions. This work will concent=
rate on the
> >> > router part and will involve how to track per-host multi=
cast listener
> >> > status and build per host context. Per host multicast li=
stener
> >> > context block, etc. will be defined.
> >>
> >> Sorry, isn't MLDv2 router implementation already keeping trac=
k of
> >> listener status?
> >
> >
> >[Decoy] I think most of th routers doesnt keep track of the indivi=
sual
> >multicast listeners but they just check whether some bosyis intere=
sted in
> >the multicast channel or not. So explicit Host tracking may not be
> required.
> >This requires table maintainance and other work as each and every =
Host
> >information needs to be stored and maintained.
> >
> >> Item 2. Base protocol MIPv6 extensions on handling multicast =
sessions
> >> > such as bandwidth inefficiency inherent in the home agen=
t's
> >> > unicasting multicast packets through the tunnel.
> >>
> >> What could the HA do?  Not unicast the multicast packets thro=
ugh the
> >> tunnel?
>        HA can record the MN information and maintain MN's MLD state et=
c.
> Forwarding
> the multicast data through unicast tunnel is just one mobile multicast
> scheme.
> >> > Item 3. Handoff survival of local (at a foreign link) mu=
lticast
> >> > sessions will be taken up in the context of care-of addr=
ess based
> >> > multicast group subscriptions.
> >>
> >> What's the influence of re-subscribing a new CoA upon each mo=
vement, on
> >> the infrastructure routing?
>   If the New AR which MN attached has the multicast group state that M=
N
> subscribed, the
> multicast disruption time is short (100~200ms). while if New AR doesn'=
t
> have the group
> states, it will take a long time to rejoin the groups.
>
>        Our group is working on implementation of mobile multicast in r=
eal
> appilication recently.
> Welcome everyone to discuss.
> >> Alex
> >>
> >>
> >> _____________________________________________________________=
_________
> >> This email has been scanned by the MessageLabs Email Security=
 System.
> >> For more information please visit http://www.messagelabs.com/=
email
> >> _____________________________________________________________=
_________
> >>
> >> _______________________________________________
> >> multimob mailing list
> >> multimob@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/multimob
> >>
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL:
> http://www1.ietf.org/pipermail/multimob/attachments/20070524/e38c0354/=
attachment.html
> >
> >------------------------------
> >
> >_______________________________________________
> >multimob mailing list
> >multimob@ietf.org
> >https://www1.ietf.org/mailman/listinfo/multimob
> >
> >
> >End of multimob Digest, Vol 2, Issue 4
> >**************************************
> >
>
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D
>
> Tony
> guanjian8632@163.com
> 2007-05-28
> +--------------------------------------+
> |      NGIRC, Beijing JiaoTong University      |
> |      BeiJing, China,100044                           |
> |      Http://www.njtu.edu.cn                          |
> +--------------------------------------+
>
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www1.ietf.org/mailman/listinfo/multimob
>
>


--=20
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/multimob/attachments/20070529/7a18fc90/=
attachment.html

------------------------------

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


End of multimob Digest, Vol 2, Issue 7
**************************************

------------------------------------------------------------------
-
-
-
DISCLAIMER:

This e-mail (including any attachments) may contain confidential
information. If you are not the intended recipient, you are hereby
notified that any dealing, review, distribution, printing, copying
or use of this e-mail is strictly prohibited. If you have received
this email in error, please notify the sender or MIMOS Berhad
immediately and delete the original message. Opinions, conclusions
and other information in this e-mail that do not relate to the
official business of MIMOS Berhad and/or its subsidiaries shall be
understood as neither given nor endorsed by MIMOS Berhad and/or its
subsidiaries and neither MIMOS Berhad nor its subsidiaries accepts
responsibility for the same. All liability arising from or in
connection with computer viruses and/or corrupted e-mails is
excluded to the fullest extent permitted by law.

--_63578182-619B-4174-94EC-54DDA58CC8DE_-- --===============0527175699== 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://www1.ietf.org/mailman/listinfo/multimob --===============0527175699==-- From multimob-bounces@ietf.org Thu May 31 10:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtlOr-00044z-5K; Thu, 31 May 2007 10:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtlOp-000446-7x; Thu, 31 May 2007 10:13:11 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtlOn-0007FJ-UP; Thu, 31 May 2007 10:13:11 -0400 Received: from e178167171.adsl.alicedsl.de ([85.178.167.171] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1HtlOn-000K36-4B; Thu, 31 May 2007 16:13:09 +0200 Message-ID: <465ED88D.4090309@fhtw-berlin.de> Date: Thu, 31 May 2007 16:15:41 +0200 From: Thomas C Schmidt User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: mobopts , multimob@ietf.org, mipshop Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [multimob] New ID: Multicast Mobility in MIPv6: Problem Statement X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimob-bounces@ietf.org Hi all, we submitted the first version of the RG ID of the problem statement draft on extending Multicast to Mobility. It should be in the ID directory soon and can immediatly be downloaded under: http://www.realmv6.org/papers/draft-irtf-mobopts-mmcastv6-ps-00.txt As we are preparing for an extension regarding layer 2 issues for Chicago: Does anybody have (or have a pointer to) *802.16 Wimax* point-to-multipoint experiments resp. measurements? Details: Multicast Mobility in MIPv6: Problem Statement and Brief Survey Abstract In this document we discuss mobility extensions to current IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues are summarized. The principal approaches to the multicast mobility problems are outlined subsequently. The new document contains a number of clarification, language fixes and minor additions. Looking forward to your hints & discussions! See you in Chicago, thomas _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob