From multimob-bounces@ietf.org Mon Oct 01 01:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcDkv-0005Tz-QV; Mon, 01 Oct 2007 01:23:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcDku-0005T1-2E for multimob@ietf.org; Mon, 01 Oct 2007 01:23:44 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcDkt-0006wx-DK for multimob@ietf.org; Mon, 01 Oct 2007 01:23:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7B53B1986B9 for ; Mon, 1 Oct 2007 08:23:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0D0F219865D for ; Mon, 1 Oct 2007 08:23:41 +0300 (EEST) Message-ID: <4700845A.7000704@piuha.net> Date: Mon, 01 Oct 2007 08:23:38 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [multimob] FW: comments on the BOF proposal 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 This is one of the comments we've received in a directorate review of the BOF proposal: > Currently the BOF seems to be about creating a generic work basket of > multicast + mobility enhancements for various situations, and I > predict that most people would only be interested in a subset of WG > products which might pose a few management challenges. Before work > would be chartered I suppose some focusing would be needed. > > "IGMPv3/MLDv2 is originally defined for wired networks with shared > links. In mobile envorinments, the link is point-to-point. Also mobile > nodes have to save battery by entering into the dormant mode. Dormant > mode operation needs to be supported. There are also concerns related > to the latency of joins and leaves that IGMPv3/MLDv2 provides. The > latency needs to be minimized. In Multimob these issues will be > addressed and IGMPv3/MLDv2 for mobile environments will be standardized." > > So what is being proposed here? Documenting already > implemented/deployed fast join/fast leave extensions? Increasing the > timer values to support dormant mode? The first item is not mobility > specific and the fate of these two solutions should not be tied > together (e.g., I'd be interested in working with fast leave/join but > not dormant mode stuff). > > "- In route optimization (RO) mode, a mobile node can communicate > directly with the corresponding node (CN) without going through its > home agent. RO mode establisment with the multicast source node as CN > will be investigated. A problem statement will first be developed and > any solution space possibilities will be explored and the solution > will be standardized." > > I don't understand how this applies. The current BOF proposal > restricts itself to receiver mobility. However, multicast sources > just send out their data, they have no knowledge of receivers. Adding > such knowledge goes against this principle (there has been one attempt > in the past but it was discontinued due to lack of interest [1]), and > I do not see what the source could do about it (certainly tunneling > from source to MNs is even less scalable than today). > > As such I would be comfortable with this direction of work only if > modifications at the multicast source were explicitly out of scope. > > "It is also a goal of the new working group to possibly standardize an > agent based solution to reduce time delay and overhead effort e.g. on > path re-construction. Both traffic and movement characteristic based > and local agent based approaches to deciding on bidirectional > tunnelling or remote subscription will be considered." > > What does 'agent based solution' refer to? Without prior knowledge of > the work it's not clear, but it doesn't sound good if it would mean > changes to multicast routing protocols. > > As a general comment about the whole BOF proposal, maybe it would be > best to spell out outright that modifications to (non-mobility > related) multicast routers and multicast routing protocols are out of > scope. > > [1] > http://tools.ietf.org/html/draft-ietf-magma-msnip-05 Thoughts, responses? Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Oct 01 03:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFcz-0000tf-O0; Mon, 01 Oct 2007 03:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFcy-0000ta-5M for multimob@ietf.org; Mon, 01 Oct 2007 03:23:40 -0400 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcFcr-00078R-Po for multimob@ietf.org; Mon, 01 Oct 2007 03:23:40 -0400 Received: from mailgate.informatik.haw-hamburg.de (isis2.informatik.haw-hamburg.de [141.22.10.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 874FD63701 for ; Mon, 1 Oct 2007 09:21: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 24661-02-8; Mon, 1 Oct 2007 09:21:51 +0200 (CEST) Received: from [192.168.178.22] (e178166238.adsl.alicedsl.de [85.178.166.238]) (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 0645B3C00102; Mon, 1 Oct 2007 09:21:50 +0200 (CEST) Message-ID: <4700A006.9080206@informatik.haw-hamburg.de> Date: Mon, 01 Oct 2007 09:21:42 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [multimob] FW: comments on the BOF proposal References: <4700845A.7000704@piuha.net> In-Reply-To: <4700845A.7000704@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Hi, please see comments inline: Jari Arkko wrote: >> "IGMPv3/MLDv2 is originally defined for wired networks with shared >> links. In mobile envorinments, the link is point-to-point. Also mobile >> nodes have to save battery by entering into the dormant mode. Dormant >> mode operation needs to be supported. There are also concerns related >> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The >> latency needs to be minimized. In Multimob these issues will be >> addressed and IGMPv3/MLDv2 for mobile environments will be standardize= d." >> >> So what is being proposed here? Documenting already >> implemented/deployed fast join/fast leave extensions? Increasing the >> timer values to support dormant mode? The first item is not mobility >> specific and the fate of these two solutions should not be tied >> together (e.g., I'd be interested in working with fast leave/join but >> not dormant mode stuff). >> At first, the prerequisites should be revised: The statement "In mobile=20 envorinments, the link is point-to-point." is not generally valid. Fast join/leave extensions of IGMPv3/MLDv2 tend to raise debates - so=20 there might be demands to clarify/document/work out protocol enhancements= . As for the dormant mode: I guess the timescales of IGMPv3/MLDv2 and=20 dormant mode invocation at mobile devices are quite distinct - so I have=20 doubts about relevant issues here. >> "- In route optimization (RO) mode, a mobile node can communicate >> directly with the corresponding node (CN) without going through its >> home agent. RO mode establisment with the multicast source node as CN >> will be investigated. A problem statement will first be developed and >> any solution space possibilities will be explored and the solution >> will be standardized." >> >> I don't understand how this applies. The current BOF proposal >> restricts itself to receiver mobility. However, multicast sources >> just send out their data, they have no knowledge of receivers. Adding >> such knowledge goes against this principle (there has been one attempt >> in the past but it was discontinued due to lack of interest [1]), and >> I do not see what the source could do about it (certainly tunneling >> from source to MNs is even less scalable than today). >> There is an emerging problem statement from IRTF/mobopts, which=20 discusses these subjects: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps An immediate transfer of MIPv6 RO to multicast is of course beyond=20 reach. However, there are proposals around that improve multicast source=20 mobility without relying on receiver knowledge. >> As such I would be comfortable with this direction of work only if >> modifications at the multicast source were explicitly out of scope. >> I don't see the evidence of the emphasis here: In an end-to-end=20 signaling scheme, why should a multicast-aware mobility stack not modify=20 sender behavior? If this is handled in a router-agnostic fashion, no=20 fundamental difference to related protocols (e.g., MIPv6) occurs to me? Nevertheless you are right: A working group dealing with receiver=20 mobility, only, is unaffected by any of these issues. >> "It is also a goal of the new working group to possibly standardize an >> agent based solution to reduce time delay and overhead effort e.g. on >> path re-construction. Both traffic and movement characteristic based >> and local agent based approaches to deciding on bidirectional >> tunnelling or remote subscription will be considered." >> >> What does 'agent based solution' refer to? Without prior knowledge of >> the work it's not clear, but it doesn't sound good if it would mean >> changes to multicast routing protocols. >> Mobile multicast protocols, which are assisted by some sort of=20 mobility-aware route entity, commonly are referred to as "agent based". Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the ARs=20 play the role of "agents". There are many more such agent functions=20 suggested, so one likes to summarize these under one term. >> As a general comment about the whole BOF proposal, maybe it would be >> best to spell out outright that modifications to (non-mobility >> related) multicast routers and multicast routing protocols are out of >> scope. >> :-) This will steer work within the realm of deployability. Conversely, there are tough parts in the mobile multicast regime and to=20 me it would make a lot of sense, if mobility related thinking will be=20 injected into future mcast routing protocol development - bi-dir PIM may=20 be a good starting point here. Thomas --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Oct 01 04:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGzC-0008Im-2L; Mon, 01 Oct 2007 04:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGzA-0008Fy-Fg for multimob@ietf.org; Mon, 01 Oct 2007 04:50:40 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcGz4-0001No-5S for multimob@ietf.org; Mon, 01 Oct 2007 04:50:40 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 1 Oct 2007 10:50: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); Mon, 1 Oct 2007 10:50:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [multimob] implementations and deployments? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Oct 2007 10:50:04 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A4016232CD@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <46FB62F1.1000402@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] implementations and deployments? Thread-Index: AcgA3IyWZhEjlZvTTfetAmRzha7rXwDKMZ6w From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 01 Oct 2007 08:50:05.0495 (UTC) FILETIME=[10032470:01C80408] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 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 Dear Jari, all Doing 'applied research' on the topic of mobile multicast within the = framework of a cooperative EU project (DAIDALOS) on behalf of fixed and = mobile operator Deutsche Telekom (T-Home/T-Mobile) reflects interest in = development of efficient measures to provide multicast traffic (e.g. = personalised IPTV, multi-player gaming, near-video on demand etc.) to = mobile users e.g. passengers in vehicles (trains, planes, cars, ...). An implementation of multicast support for NEMO protocol was done on a = Linux-operated testbed. Additionally multicast for ad-hoc networks and integration of broadcast = technology is in scope of the project. AFAIK at the moment there are no specific plans for deployment but = depending on expected increased customer interest in mobile data = services we are investigating potential saving in radio resources and = system capacity, reduction in effort, increase performance and QoS.=20 Kind regards Dirk v. Hugo =20 Mobile & Wireless Solutions Line of Business Products & Services Systems Integration, BU Telco T-Systems Enterprise Services GmbH Deutsche-Telekom-Allee 7, D-64295 Darmstadt Germany Tel +49 6151 937-2536 Fax +49 6151 937-4611 Mailto:dirk.hugo@t-systems.com Internet: http://www.t-systems.com=20 =20 -----Urspr=FCngliche Nachricht----- Von: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Gesendet: Donnerstag, 27. September 2007 10:00 An: multimob@ietf.org Betreff: [multimob] implementations and deployments? Hi, Who are the people interested in this effort? Are they researchers or people planning to deploy this technology in some network? Are there implementations, if so on what platforms? Are there deployment plans? Which of the big mobile networks that we have today (say, 3GPP, 3GPP2, Wimax) are planning to employ a multicast mobility feature (at L3) in their future networks? Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Oct 03 11:53: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 1Id6Wh-0005GJ-TD; Wed, 03 Oct 2007 11:52:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id6Wg-00054d-OZ for multimob@ietf.org; Wed, 03 Oct 2007 11:52:42 -0400 Received: from web84101.mail.mud.yahoo.com ([68.142.206.188]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Id6WT-0006Ge-BY for multimob@ietf.org; Wed, 03 Oct 2007 11:52:30 -0400 Received: (qmail 4229 invoked by uid 60001); 3 Oct 2007 15:52:28 -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=S+kv2ZD9MMuqvfOczmFBwuGD2O6sUpnGqLcGM9GhCqGk+vjfMgSrbbronesVyCjGvwQGvlWp/djTmzcJXK3xnEsSoGi8sAT3hdMTECjnk5ObLeqyefVsJHAlfnolSCBi23hIRh8PMDQiKJN8mKOAN2RT32pMyS+x7cDf8SnZ4Ys=; X-YMail-OSG: TTBkbcgVM1n.34tBc61.aVgQygNGPICgzrxp9HDjFPqTByPFys7cPvLmYcf.EYVBYQ1xdAmnhdyyfRKSrIg9qt2ouQp2NrkFqPLkQwOU7WagbY8- Received: from [206.16.17.212] by web84101.mail.mud.yahoo.com via HTTP; Wed, 03 Oct 2007 08:52:28 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Wed, 3 Oct 2007 08:52:28 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [multimob] FW: comments on the BOF proposal To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <793594.887.qm@web84101.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: 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="===============1007010396==" Errors-To: multimob-bounces@ietf.org --===============1007010396== Content-Type: multipart/alternative; boundary="0-354262620-1191426748=:887" --0-354262620-1191426748=:887 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,=0A Based on the comments below, we will update the charter and p= ost the version online soon.=0A Those who are writing drafts for Multimob,= 00 draft submission deadline is more than a month away but please submit y= our draft earlier and make sure to announce it and have it discussed on the= mailing list.=0A=0ARegards,=0A=0ABehcet & Suresh=0A=0A----- Original Messa= ge ----=0AFrom: Thomas C. Schmidt =0ATo:= Jari Arkko =0ACc: multimob@ietf.org=0ASent: Monday, = October 1, 2007 2:21:42 AM=0ASubject: Re: [multimob] FW: comments on the BO= F proposal=0A=0AHi,=0A=0Aplease see comments inline:=0A=0AJari Arkko wrote:= =0A=0A>> "IGMPv3/MLDv2 is originally defined for wired networks with shared= =0A>> links. In mobile envorinments, the link is point-to-point. Also mobil= e=0A>> nodes have to save battery by entering into the dormant mode. Dorman= t=0A>> mode operation needs to be supported. There are also concerns relate= d=0A>> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The= =0A>> latency needs to be minimized. In Multimob these issues will be=0A>> = addressed and IGMPv3/MLDv2 for mobile environments will be standardized."= =0A>>=0A>> So what is being proposed here? Documenting already=0A>> implem= ented/deployed fast join/fast leave extensions? Increasing the=0A>> timer = values to support dormant mode? The first item is not mobility=0A>> specif= ic and the fate of these two solutions should not be tied=0A>> together (e.= g., I'd be interested in working with fast leave/join but=0A>> not dormant = mode stuff).=0A>>=0AAt first, the prerequisites should be revised: The stat= ement "In mobile =0Aenvorinments, the link is point-to-point." is not gener= ally valid.=0A=0AFast join/leave extensions of IGMPv3/MLDv2 tend to raise d= ebates - so =0Athere might be demands to clarify/document/work out protocol= enhancements.=0A=0AAs for the dormant mode: I guess the timescales of IGMP= v3/MLDv2 and =0Adormant mode invocation at mobile devices are quite distinc= t - so I have =0Adoubts about relevant issues here.=0A=0A>> "- In route opt= imization (RO) mode, a mobile node can communicate=0A>> directly with the c= orresponding node (CN) without going through its=0A>> home agent. RO mode e= stablisment with the multicast source node as CN=0A>> will be investigated.= A problem statement will first be developed and=0A>> any solution space po= ssibilities will be explored and the solution=0A>> will be standardized."= =0A>>=0A>> I don't understand how this applies. The current BOF proposal= =0A>> restricts itself to receiver mobility. However, multicast sources=0A= >> just send out their data, they have no knowledge of receivers. Adding=0A= >> such knowledge goes against this principle (there has been one attempt= =0A>> in the past but it was discontinued due to lack of interest [1]), and= =0A>> I do not see what the source could do about it (certainly tunneling= =0A>> from source to MNs is even less scalable than today).=0A>>=0A=0AThere= is an emerging problem statement from IRTF/mobopts, which =0Adiscusses the= se subjects:=0Ahttp://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps=0A= =0AAn immediate transfer of MIPv6 RO to multicast is of course beyond =0Are= ach. However, there are proposals around that improve multicast source =0Am= obility without relying on receiver knowledge.=0A=0A>> As such I would be c= omfortable with this direction of work only if=0A>> modifications at the mu= lticast source were explicitly out of scope.=0A>>=0A=0AI don't see the evid= ence of the emphasis here: In an end-to-end =0Asignaling scheme, why should= a multicast-aware mobility stack not modify =0Asender behavior? If this is= handled in a router-agnostic fashion, no =0Afundamental difference to rela= ted protocols (e.g., MIPv6) occurs to me?=0A=0ANevertheless you are right: = A working group dealing with receiver =0Amobility, only, is unaffected by a= ny of these issues.=0A=0A>> "It is also a goal of the new working group to = possibly standardize an=0A>> agent based solution to reduce time delay and = overhead effort e.g. on=0A>> path re-construction. Both traffic and movemen= t characteristic based=0A>> and local agent based approaches to deciding on= bidirectional=0A>> tunnelling or remote subscription will be considered."= =0A>>=0A>> What does 'agent based solution' refer to? Without prior knowle= dge of=0A>> the work it's not clear, but it doesn't sound good if it would = mean=0A>> changes to multicast routing protocols.=0A>>=0A=0AMobile multicas= t protocols, which are assisted by some sort of =0Amobility-aware route ent= ity, commonly are referred to as "agent based".=0AExamples would be extensi= ons to HMIPv6 or FMIPv6, where a MAP or the ARs =0Aplay the role of "agents= ". There are many more such agent functions =0Asuggested, so one likes to s= ummarize these under one term.=0A=0A>> As a general comment about the whole= BOF proposal, maybe it would be=0A>> best to spell out outright that modif= ications to (non-mobility=0A>> related) multicast routers and multicast rou= ting protocols are out of=0A>> scope.=0A>>=0A=0A:-) This will steer work wi= thin the realm of deployability.=0A=0AConversely, there are tough parts in = the mobile multicast regime and to =0Ame it would make a lot of sense, if m= obility related thinking will be =0Ainjected into future mcast routing prot= ocol development - bi-dir PIM may =0Abe a good starting point here.=0A=0ATh= omas=0A=0A-- =0A=0A=B0 Prof. Dr. Thomas C. Schmidt=0A=B0 HAW Hamburg, Dept.= Informatik=0A=B0 University of Applied Sciences=0A=B0 Berliner Tor 7, D 20= 099 Hamburg=0A=B0 Germany, Fon: +49-40-42875-8157=0A=B0 http://www.informat= ik.haw-hamburg.de/~schmidt=0A=0A___________________________________________= ____=0Amultimob mailing list=0Amultimob@ietf.org=0Ahttps://www1.ietf.org/ma= ilman/listinfo/multimob=0A=0A=0A=0A=0A --0-354262620-1191426748=:887 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,
  Based on the comments below, we wi= ll update the charter and post the version online soon.
  Those who= are writing drafts for Multimob, 00 draft submission deadline is more than= a month away but please submit your draft earlier and make sure to announc= e it and have it discussed on the mailing list.

Regards,

Behc= et & Suresh

----- Original Message ----
From: Thomas = C. Schmidt <schmidt@informatik.haw-hamburg.de>
To: Jari Arkko <= jari.arkko@piuha.net>
Cc: multimob@ietf.org
Sent: Monday, October = 1, 2007 2:21:42 AM
Subject: Re: [multimob] FW: comments on the BOF proposal

Hi,

please see comments inline:

Jari Ar= kko wrote:

>> "IGMPv3/MLDv2 is originally defined for wired ne= tworks with shared
>> links. In mobile envorinments, the link is p= oint-to-point. Also mobile
>> nodes have to save battery by enteri= ng into the dormant mode. Dormant
>> mode operation needs to be su= pported. There are also concerns related
>> to the latency of join= s and leaves that IGMPv3/MLDv2 provides. The
>> latency needs to b= e minimized. In Multimob these issues will be
>> addressed and IGM= Pv3/MLDv2 for mobile environments will be standardized."
>>
>= ;> So what is being proposed here?  Documenting already
>= ;> implemented/deployed fast join/fast leave extensions?  Incr= easing the
>> timer values to support dormant mode?  The= first item is not mobility
>> specific and the fate of these two solutions should not be tied
>> together (e.g., I'd be = interested in working with fast leave/join but
>> not dormant mode= stuff).
>>
At first, the prerequisites should be revised: The = statement "In mobile
envorinments, the link is point-to-point." is not = generally valid.

Fast join/leave extensions of IGMPv3/MLDv2 tend to = raise debates - so
there might be demands to clarify/document/work out = protocol enhancements.

As for the dormant mode: I guess the timescal= es of IGMPv3/MLDv2 and
dormant mode invocation at mobile devices are qu= ite distinct - so I have
doubts about relevant issues here.

>= > "- In route optimization (RO) mode, a mobile node can communicate
&= gt;> directly with the corresponding node (CN) without going through its=
>> home agent. RO mode establisment with the multicast source nod= e as CN
>> will be investigated. A problem statement will first be developed and
>> any solution space possibilities will b= e explored and the solution
>> will be standardized."
>><= br>>> I don't understand how this applies.  The current BOF= proposal
>> restricts itself to receiver mobility.  How= ever, multicast sources
>> just send out their data, they have no = knowledge of receivers. Adding
>> such knowledge goes against this= principle (there has been one attempt
>> in the past but it was d= iscontinued due to lack of interest [1]), and
>> I do not see what= the source could do about it (certainly tunneling
>> from source = to MNs is even less scalable than today).
>>

There is an em= erging problem statement from IRTF/mobopts, which
discusses these subje= cts:
http://= tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

An immediate = transfer of MIPv6 RO to multicast is of course beyond
reach. However, t= here are proposals around that improve multicast source
mobility withou= t relying on receiver knowledge.

>> As such I would be comfort= able with this direction of work only if
>> modifications at the m= ulticast source were explicitly out of scope.
>>

I don't se= e the evidence of the emphasis here: In an end-to-end
signaling scheme,= why should a multicast-aware mobility stack not modify
sender behavior= ? If this is handled in a router-agnostic fashion, no
fundamental diffe= rence to related protocols (e.g., MIPv6) occurs to me?

Nevertheless = you are right: A working group dealing with receiver
mobility, only, is= unaffected by any of these issues.

>> "It is also a goal of the new working group to possibly standardize an
>> agent base= d solution to reduce time delay and overhead effort e.g. on
>> pat= h re-construction. Both traffic and movement characteristic based
>&g= t; and local agent based approaches to deciding on bidirectional
>>= ; tunnelling or remote subscription will be considered."
>>
>= ;> What does 'agent based solution' refer to?  Without prior k= nowledge of
>> the work it's not clear, but it doesn't sound good = if it would mean
>> changes to multicast routing protocols.
>= ;>

Mobile multicast protocols, which are assisted by some sort of=
mobility-aware route entity, commonly are referred to as "agent based"= .
Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the A= Rs
play the role of "agents". There are many more such agent functions =
suggested, so one likes to summarize these under one term.

>> As a general comment about the whole BOF proposal, m= aybe it would be
>> best to spell out outright that modifications = to (non-mobility
>> related) multicast routers and multicast routi= ng protocols are out of
>> scope.
>>

:-) This will= steer work within the realm of deployability.

Conversely, there are= tough parts in the mobile multicast regime and to
me it would make a l= ot of sense, if mobility related thinking will be
injected into future = mcast routing protocol development - bi-dir PIM may
be a good starting = point here.

Thomas

--

=B0 Prof. Dr. Thomas C. Schmidt=
=B0 HAW Hamburg, Dept. Informatik
=B0 University of Applied Sciences=
=B0 Berliner Tor 7, D 20099 Hamburg
=B0 Germany, Fon: +49-40-42875-8= 157
=B0 http://www.inform= atik.haw-hamburg.de/~schmidt

___________________________________= ____________
multimob mailing list
multimob@ietf.org
https://ww= w1.ietf.org/mailman/listinfo/multimob

--0-354262620-1191426748=:887-- --===============1007010396== 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 --===============1007010396==-- From multimob-bounces@ietf.org Fri Oct 05 10:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ido0p-0000YH-FE; Fri, 05 Oct 2007 10:18:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ido0p-0000Y5-4I for multimob@ietf.org; Fri, 05 Oct 2007 10:18:43 -0400 Received: from m5-84.163.com ([202.108.5.84]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ido0n-0006dM-C1 for multimob@ietf.org; Fri, 05 Oct 2007 10:18:43 -0400 Received: from sunguan (unknown [218.249.29.40]) by smtp4 (Coremail) with SMTP id wKjRDrA7HQWxRwZHGXV_CQ==.31715S2; Fri, 05 Oct 2007 22:18:25 +0800 (CST) Date: Fri, 5 Oct 2007 22:18:25 +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-VFAUDIcSsGvfJTRUUUjV8FxVCF77xC6IxKo4 kEV4ylYx0Ex4A2jsIE14v26r4j6F4UM4xvF2IEb7IF0Fy264kE64k0F24lnxkEFVAIw20F 6cxK64vIFxWl6VACY4xI67k04243AwC2zVAF1VAY17CE14v26r1j6r15Mx02cVAKzwACY4 xI67k04243AVC20s07MI8E67x28xkI4xCE0xIEc2x0rwCF72vE52k0Y41lw4CEF2IF47xS 0VAv8wAFxVCaYxvI4VCIwcAKzIAtM2kK6IIYrcxKn4CE548m6r1fJF4UZwCY0x0Ix7I2Y4 AK64vIr41lc2xSY4AK67AK6ry5M7AC8VAFwI0_Jr0_Gr1lYx0E2Ix0cI8IcVAFwI0_JrI_ Jrylb4IE77IF4wAFIxvE14AKwVWUJVWUGwAqx4xG64xvF2IEw4CE5I8CrVC2j2Wlc7Ca8V AvwVCFzxkY4VCS07ylb7Iv0xC_JrUanT9S1TB71UUUUUUa7-sFnT9fnUUI43ZEXa7IU50P fPUUUUUFnT9fnV15pFy7Gr43Xry8Kw1rCry5uFy7toXrpF45trg_uFyvvFykGr1UXr47t3 W3JwsxCrZrW3yDGF18X3y0qF43Z342yr4DCrnFyFZxZw1fXrZrZr9xG3ZxX34Sv34ag Message-Id: <470647B5.0996B3.17520@m5-84.163.com> X-Spam-Score: 4.9 (++++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [multimob] Re: FW: comments on the BOF proposal (Tony) 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="===============1405555386==" Errors-To: multimob-bounces@ietf.org --===============1405555386== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgZXZlcnlvbmUNCg0KDQo+SmFyaSBBcmtrbyB3cm90ZToNCj4NCj4+PiAiSUdNUHYzL01MRHYy IGlzIG9yaWdpbmFsbHkgZGVmaW5lZCBmb3Igd2lyZWQgbmV0d29ya3Mgd2l0aCBzaGFyZWQNCj4+ PiBsaW5rcy4gSW4gbW9iaWxlIGVudm9yaW5tZW50cywgdGhlIGxpbmsgaXMgcG9pbnQtdG8tcG9p bnQuIEFsc28gbW9iaWxlDQo+Pj4gbm9kZXMgaGF2ZSB0byBzYXZlIGJhdHRlcnkgYnkgZW50ZXJp bmcgaW50byB0aGUgZG9ybWFudCBtb2RlLiBEb3JtYW50DQo+Pj4gbW9kZSBvcGVyYXRpb24gbmVl ZHMgdG8gYmUgc3VwcG9ydGVkLiBUaGVyZSBhcmUgYWxzbyBjb25jZXJucyByZWxhdGVkDQo+Pj4g dG8gdGhlIGxhdGVuY3kgb2Ygam9pbnMgYW5kIGxlYXZlcyB0aGF0IElHTVB2My9NTER2MiBwcm92 aWRlcy4gVGhlDQo+Pj4gbGF0ZW5jeSBuZWVkcyB0byBiZSBtaW5pbWl6ZWQuIEluIE11bHRpbW9i IHRoZXNlIGlzc3VlcyB3aWxsIGJlDQo+Pj4gYWRkcmVzc2VkIGFuZCBJR01QdjMvTUxEdjIgZm9y IG1vYmlsZSBlbnZpcm9ubWVudHMgd2lsbCBiZSBzdGFuZGFyZGl6ZWQuIg0KPj4+DQo+Pj4gU28g d2hhdCBpcyBiZWluZyBwcm9wb3NlZCBoZXJlPyAgRG9jdW1lbnRpbmcgYWxyZWFkeQ0KPj4+IGlt cGxlbWVudGVkL2RlcGxveWVkIGZhc3Qgam9pbi9mYXN0IGxlYXZlIGV4dGVuc2lvbnM/ICBJbmNy ZWFzaW5nIHRoZQ0KPj4+IHRpbWVyIHZhbHVlcyB0byBzdXBwb3J0IGRvcm1hbnQgbW9kZT8gIFRo ZSBmaXJzdCBpdGVtIGlzIG5vdCBtb2JpbGl0eQ0KPj4+IHNwZWNpZmljIGFuZCB0aGUgZmF0ZSBv ZiB0aGVzZSB0d28gc29sdXRpb25zIHNob3VsZCBub3QgYmUgdGllZA0KPj4+IHRvZ2V0aGVyIChl LmcuLCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIHdpdGggZmFzdCBsZWF2ZS9qb2luIGJ1 dA0KPj4+IG5vdCBkb3JtYW50IG1vZGUgc3R1ZmYpLg0KPj4+DQo+W1Rob21hc10gQXQgZmlyc3Qs IHRoZSBwcmVyZXF1aXNpdGVzIHNob3VsZCBiZSByZXZpc2VkOiBUaGUgc3RhdGVtZW50ICJJbiBt b2JpbGUgDQo+ZW52b3Jpbm1lbnRzLCB0aGUgbGluayBpcyBwb2ludC10by1wb2ludC4iIGlzIG5v dCBnZW5lcmFsbHkgdmFsaWQuDQo+DQo+W1Rob21hc10gRmFzdCBqb2luL2xlYXZlIGV4dGVuc2lv bnMgb2YgSUdNUHYzL01MRHYyIHRlbmQgdG8gcmFpc2UgZGViYXRlcyAtIHNvIA0KPnRoZXJlIG1p Z2h0IGJlIGRlbWFuZHMgdG8gY2xhcmlmeS9kb2N1bWVudC93b3JrIG91dCBwcm90b2NvbCBlbmhh bmNlbWVudHMuDQo+DQo+W1Rob21hc10gQXMgZm9yIHRoZSBkb3JtYW50IG1vZGU6IEkgZ3Vlc3Mg dGhlIHRpbWVzY2FsZXMgb2YgSUdNUHYzL01MRHYyIGFuZCANCj5kb3JtYW50IG1vZGUgaW52b2Nh dGlvbiBhdCBtb2JpbGUgZGV2aWNlcyBhcmUgcXVpdGUgZGlzdGluY3QgLSBzbyBJIGhhdmUgDQo+ ZG91YnRzIGFib3V0IHJlbGV2YW50IGlzc3VlcyBoZXJlLg0KDQpJIHRoaW5rIHRoZSBrZXkgcG9p bnQgb2YgSUdNUHYzL01MRHYyIGluIG1vYmlsZSBlbnZvcmlubWVudHMgaXMgdGhlIHRyYW5zZmVy IG9mIA0KbXVsdGljYXN0IHN0YXRlcyBmb3IgbW9iaWxlIHN1YnNjcmliZXJzIChyZWNlaXZlcnMg b3Igc291cmNlcykuIFRoZSBjdXJyZW50IElHTVB2My8NCk1MRHYyIGlzIGxpbmstbG9jYWwsIGFu ZCB0aGVzZSBtZXNzYWdlcyBjYW4gbm90IGJlIHRyYW5zbWl0dGVkIHRvIHRoZSBvdGhlciBzdWJu ZXRzIA0Kd2hlbiBNTiBtb3Zlcy4gUGVyaGFwcywgd2UgbmVlZCB0byBtYWtlIHNvbWUgY2hhbmdl IHRvIHN1cHBvcnQgbW9iaWxlIHN1YnNjcmliZXJzLg0KPg0KPj4+ICItIEluIHJvdXRlIG9wdGlt aXphdGlvbiAoUk8pIG1vZGUsIGEgbW9iaWxlIG5vZGUgY2FuIGNvbW11bmljYXRlDQo+Pj4gZGly ZWN0bHkgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBub2RlIChDTikgd2l0aG91dCBnb2luZyB0aHJv dWdoIGl0cw0KPj4+IGhvbWUgYWdlbnQuIFJPIG1vZGUgZXN0YWJsaXNtZW50IHdpdGggdGhlIG11 bHRpY2FzdCBzb3VyY2Ugbm9kZSBhcyBDTg0KPj4+IHdpbGwgYmUgaW52ZXN0aWdhdGVkLiBBIHBy b2JsZW0gc3RhdGVtZW50IHdpbGwgZmlyc3QgYmUgZGV2ZWxvcGVkIGFuZA0KPj4+IGFueSBzb2x1 dGlvbiBzcGFjZSBwb3NzaWJpbGl0aWVzIHdpbGwgYmUgZXhwbG9yZWQgYW5kIHRoZSBzb2x1dGlv bg0KPj4+IHdpbGwgYmUgc3RhbmRhcmRpemVkLiINCj4+Pg0KPj4+IEkgZG9uJ3QgdW5kZXJzdGFu ZCBob3cgdGhpcyBhcHBsaWVzLiAgVGhlIGN1cnJlbnQgQk9GIHByb3Bvc2FsDQo+Pj4gcmVzdHJp Y3RzIGl0c2VsZiB0byByZWNlaXZlciBtb2JpbGl0eS4gIEhvd2V2ZXIsIG11bHRpY2FzdCBzb3Vy Y2VzDQo+Pj4ganVzdCBzZW5kIG91dCB0aGVpciBkYXRhLCB0aGV5IGhhdmUgbm8ga25vd2xlZGdl IG9mIHJlY2VpdmVycy4gQWRkaW5nDQo+Pj4gc3VjaCBrbm93bGVkZ2UgZ29lcyBhZ2FpbnN0IHRo aXMgcHJpbmNpcGxlICh0aGVyZSBoYXMgYmVlbiBvbmUgYXR0ZW1wdA0KPj4+IGluIHRoZSBwYXN0 IGJ1dCBpdCB3YXMgZGlzY29udGludWVkIGR1ZSB0byBsYWNrIG9mIGludGVyZXN0IFsxXSksIGFu ZA0KPj4+IEkgZG8gbm90IHNlZSB3aGF0IHRoZSBzb3VyY2UgY291bGQgZG8gYWJvdXQgaXQgKGNl cnRhaW5seSB0dW5uZWxpbmcNCj4+PiBmcm9tIHNvdXJjZSB0byBNTnMgaXMgZXZlbiBsZXNzIHNj YWxhYmxlIHRoYW4gdG9kYXkpLg0KPj4+DQo+DQo+W1Rob21hc10gVGhlcmUgaXMgYW4gZW1lcmdp bmcgcHJvYmxlbSBzdGF0ZW1lbnQgZnJvbSBJUlRGL21vYm9wdHMsIHdoaWNoIA0KPmRpc2N1c3Nl cyB0aGVzZSBzdWJqZWN0czoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRm LW1vYm9wdHMtbW1jYXN0djYtcHMNCj4NCj5bVGhvbWFzXSBBbiBpbW1lZGlhdGUgdHJhbnNmZXIg b2YgTUlQdjYgUk8gdG8gbXVsdGljYXN0IGlzIG9mIGNvdXJzZSBiZXlvbmQgDQo+cmVhY2guIEhv d2V2ZXIsIHRoZXJlIGFyZSBwcm9wb3NhbHMgYXJvdW5kIHRoYXQgaW1wcm92ZSBtdWx0aWNhc3Qg c291cmNlIA0KPm1vYmlsaXR5IHdpdGhvdXQgcmVseWluZyBvbiByZWNlaXZlciBrbm93bGVkZ2Uu DQo+DQoNCj4+PiBBcyBzdWNoIEkgd291bGQgYmUgY29tZm9ydGFibGUgd2l0aCB0aGlzIGRpcmVj dGlvbiBvZiB3b3JrIG9ubHkgaWYNCj4+PiBtb2RpZmljYXRpb25zIGF0IHRoZSBtdWx0aWNhc3Qg c291cmNlIHdlcmUgZXhwbGljaXRseSBvdXQgb2Ygc2NvcGUuDQo+Pj4NCj4NCj5bVGhvbWFzXSBJ IGRvbid0IHNlZSB0aGUgZXZpZGVuY2Ugb2YgdGhlIGVtcGhhc2lzIGhlcmU6IEluIGFuIGVuZC10 by1lbmQgDQo+c2lnbmFsaW5nIHNjaGVtZSwgd2h5IHNob3VsZCBhIG11bHRpY2FzdC1hd2FyZSBt b2JpbGl0eSBzdGFjayBub3QgbW9kaWZ5IA0KPnNlbmRlciBiZWhhdmlvcj8gSWYgdGhpcyBpcyBo YW5kbGVkIGluIGEgcm91dGVyLWFnbm9zdGljIGZhc2hpb24sIG5vIA0KPmZ1bmRhbWVudGFsIGRp ZmZlcmVuY2UgdG8gcmVsYXRlZCBwcm90b2NvbHMgKGUuZy4sIE1JUHY2KSBvY2N1cnMgdG8gbWU/ DQo+DQo+W1Rob21hc10gTmV2ZXJ0aGVsZXNzIHlvdSBhcmUgcmlnaHQ6IEEgd29ya2luZyBncm91 cCBkZWFsaW5nIHdpdGggcmVjZWl2ZXIgDQo+bW9iaWxpdHksIG9ubHksIGlzIHVuYWZmZWN0ZWQg YnkgYW55IG9mIHRoZXNlIGlzc3Vlcy4NCj4NCk1vYmlsZSBzb3VyY2UgaXMgYW4gaW1wb3J0YW50 IGlzc3VlIGluIG1vYmlsZSBtdWx0aWNhc3QsIHdoaWxlIElNTyBtb2JpbGUgDQpyZWNlaXZlciBp cyBtb3JlIGltcG9ydGFudCBmb3Igc29tZSBhcHBsaWNhdGlvbnMuDQoNCj4+PiAiSXQgaXMgYWxz byBhIGdvYWwgb2YgdGhlIG5ldyB3b3JraW5nIGdyb3VwIHRvIHBvc3NpYmx5IHN0YW5kYXJkaXpl IGFuDQo+Pj4gYWdlbnQgYmFzZWQgc29sdXRpb24gdG8gcmVkdWNlIHRpbWUgZGVsYXkgYW5kIG92 ZXJoZWFkIGVmZm9ydCBlLmcuIG9uDQo+Pj4gcGF0aCByZS1jb25zdHJ1Y3Rpb24uIEJvdGggdHJh ZmZpYyBhbmQgbW92ZW1lbnQgY2hhcmFjdGVyaXN0aWMgYmFzZWQNCj4+PiBhbmQgbG9jYWwgYWdl bnQgYmFzZWQgYXBwcm9hY2hlcyB0byBkZWNpZGluZyBvbiBiaWRpcmVjdGlvbmFsDQo+Pj4gdHVu bmVsbGluZyBvciByZW1vdGUgc3Vic2NyaXB0aW9uIHdpbGwgYmUgY29uc2lkZXJlZC4iDQo+Pj4N Cj4+PiBXaGF0IGRvZXMgJ2FnZW50IGJhc2VkIHNvbHV0aW9uJyByZWZlciB0bz8gIFdpdGhvdXQg cHJpb3Iga25vd2xlZGdlIG9mDQo+Pj4gdGhlIHdvcmsgaXQncyBub3QgY2xlYXIsIGJ1dCBpdCBk b2Vzbid0IHNvdW5kIGdvb2QgaWYgaXQgd291bGQgbWVhbg0KPj4+IGNoYW5nZXMgdG8gbXVsdGlj YXN0IHJvdXRpbmcgcHJvdG9jb2xzLg0KPj4+DQo+DQo+W1Rob21hc11Nb2JpbGUgbXVsdGljYXN0 IHByb3RvY29scywgd2hpY2ggYXJlIGFzc2lzdGVkIGJ5IHNvbWUgc29ydCBvZiANCj5tb2JpbGl0 eS1hd2FyZSByb3V0ZSBlbnRpdHksIGNvbW1vbmx5IGFyZSByZWZlcnJlZCB0byBhcyAiYWdlbnQg YmFzZWQiLg0KPkV4YW1wbGVzIHdvdWxkIGJlIGV4dGVuc2lvbnMgdG8gSE1JUHY2IG9yIEZNSVB2 Niwgd2hlcmUgYSBNQVAgb3IgdGhlIEFScyANCj5wbGF5IHRoZSByb2xlIG9mICJhZ2VudHMiLiBU aGVyZSBhcmUgbWFueSBtb3JlIHN1Y2ggYWdlbnQgZnVuY3Rpb25zIA0KPnN1Z2dlc3RlZCwgc28g b25lIGxpa2VzIHRvIHN1bW1hcml6ZSB0aGVzZSB1bmRlciBvbmUgdGVybS4NCg0KQWNjb3JkaW5n IHRvIHRoZSBkcmFmdDogaHR0cDovL2lldGZyZXBvcnQuaXNvYy5vcmcvYWxsLWlkcy9kcmFmdC16 aGFuZy1tdWx0aW1vYi1tZW1jYXN0LXBzLTAwLnR4dA0KSSB0aGluayBhbmVudCBpcyByZWZlcnJl ZCB0byB0aGUgIk11bHRpY2FzdCBmb3J3YXJkZXIiIC4NCg0KPj4+IEFzIGEgZ2VuZXJhbCBjb21t ZW50IGFib3V0IHRoZSB3aG9sZSBCT0YgcHJvcG9zYWwsIG1heWJlIGl0IHdvdWxkIGJlDQo+Pj4g YmVzdCB0byBzcGVsbCBvdXQgb3V0cmlnaHQgdGhhdCBtb2RpZmljYXRpb25zIHRvIChub24tbW9i aWxpdHkNCj4+PiByZWxhdGVkKSBtdWx0aWNhc3Qgcm91dGVycyBhbmQgbXVsdGljYXN0IHJvdXRp bmcgcHJvdG9jb2xzIGFyZSBvdXQgb2YNCj4+PiBzY29wZS4NCj4+Pg0KPg0KPltUaG9tYXNdIDot KSBUaGlzIHdpbGwgc3RlZXIgd29yayB3aXRoaW4gdGhlIHJlYWxtIG9mIGRlcGxveWFiaWxpdHku DQo+DQo+W1Rob21hc10gQ29udmVyc2VseSwgdGhlcmUgYXJlIHRvdWdoIHBhcnRzIGluIHRoZSBt b2JpbGUgbXVsdGljYXN0IHJlZ2ltZSBhbmQgdG8gDQo+bWUgaXQgd291bGQgbWFrZSBhIGxvdCBv ZiBzZW5zZSwgaWYgbW9iaWxpdHkgcmVsYXRlZCB0aGlua2luZyB3aWxsIGJlIA0KPmluamVjdGVk IGludG8gZnV0dXJlIG1jYXN0IHJvdXRpbmcgcHJvdG9jb2wgZGV2ZWxvcG1lbnQgLSBiaS1kaXIg UElNIG1heSANCj5iZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgaGVyZS4NCg0KUmlnaHQsIHRoZSBj dXJyZW50IG1vYmlsZSBtdWx0aWNhc3QgaXMgb25seSB1c2VkIGluIHRoZSBhY2Nlc3MgbmV0d29y a3MsIGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiANCnRoZSBtdWx0aWNhc3Qgcm91dGluZyBwcm90 b2NvbHMuDQoNCj4NCj4/UHJvZi4gRHIuIFRob21hcyBDLiBTY2htaWR0DQo+P0hBVyBIYW1idXJn LCBEZXB0LiBJbmZvcm1hdGlrDQo+P1VuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2llbmNlcw0KPj9C ZXJsaW5lciBUb3IgNywgRCAyMDA5OSBIYW1idXJnDQo+P0dlcm1hbnksIEZvbjogKzQ5LTQwLTQy ODc1LTgxNTcNCj4/aHR0cDovL3d3dy5pbmZvcm1hdGlrLmhhdy1oYW1idXJnLmRlL35zY2htaWR0 DQo+DQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tdWx0aW1vYiBtYWlsaW5n IGxpc3QNCj5tdWx0aW1vYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL211bHRpbW9iDQo+DQo+DQo+RW5kIG9mIG11bHRpbW9iIERpZ2VzdCwgVm9sIDcs IElzc3VlIDINCj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCgkJCSANCqGhoaGhoaGhoaGhoaGh oaFUb255DQqhoaGhoaGhoaGhoaGhoaGhZ3VhbmppYW44NjMyQDE2My5jb20NCqGhoaGhoaGhoaGh oaGhoaGhoaGhMjAwNy0xMC0wNQ0KICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCiB8CU5HSVJDLCBCZWlqaW5nIEppYW9Ub25nIFVuaXZlcnNpdHkJfA0KIHwJQmVpSmlu ZywgQ2hpbmEsMTAwMDQ0CQkJCXwNCiB8CUh0dHA6Ly93d3cubmp0dS5lZHUuY24JCQkJfA0KICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0K --===============1405555386== 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 --===============1405555386==-- From multimob-bounces@ietf.org Fri Oct 05 11:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idoou-0004tD-UB; Fri, 05 Oct 2007 11:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idoot-0004t8-WB for multimob@ietf.org; Fri, 05 Oct 2007 11:10:28 -0400 Received: from mer-w2003-6.napier-mail.napier.ac.uk ([146.176.223.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idoom-0000U3-0o for multimob@ietf.org; Fri, 05 Oct 2007 11:10:27 -0400 Received: from EVS1.napier-mail.napier.ac.uk (Not Verified[146.176.222.4]) by mer-w2003-6.napier-mail.napier.ac.uk with NetIQ MailMarshal 6.0 Service Pack 1a (v6, 0, 3, 33) id ; Fri, 05 Oct 2007 16:09:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [multimob] Re: FW: comments on the BOF proposal (Tony) Date: Fri, 5 Oct 2007 16:09:58 +0100 Message-ID: <735F04A99D358E468A16EDB64FC04555051E9546@EVS1.napier-mail.napier.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Re: FW: comments on the BOF proposal (Tony) Thread-Index: AcgHWufQWIL6sozQS360/zvTvRK5fwAAba3w From: "Romdhani, Imed" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: 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 Dear All, Please see my comments bellow. They are preceded by "[Imed]": >Jari Arkko wrote: > >>> "IGMPv3/MLDv2 is originally defined for wired networks with shared >>> links. In mobile envorinments, the link is point-to-point. Also mobile >>> nodes have to save battery by entering into the dormant mode. Dormant >>> mode operation needs to be supported. There are also concerns related >>> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The >>> latency needs to be minimized. In Multimob these issues will be >>> addressed and IGMPv3/MLDv2 for mobile environments will be standardized." >>> >>> So what is being proposed here? Documenting already >>> implemented/deployed fast join/fast leave extensions? Increasing the >>> timer values to support dormant mode? The first item is not mobility >>> specific and the fate of these two solutions should not be tied >>> together (e.g., I'd be interested in working with fast leave/join but >>> not dormant mode stuff). >>> >[Thomas] At first, the prerequisites should be revised: The statement "In mobile >envorinments, the link is point-to-point." is not generally valid. > >[Thomas] Fast join/leave extensions of IGMPv3/MLDv2 tend to raise debates - so >there might be demands to clarify/document/work out protocol enhancements. > >[Thomas] As for the dormant mode: I guess the timescales of IGMPv3/MLDv2 and >dormant mode invocation at mobile devices are quite distinct - so I have >doubts about relevant issues here. [Tony]: I think the key point of IGMPv3/MLDv2 in mobile envorinments is the transfer of multicast states for mobile subscribers (receivers or sources). The current IGMPv3/MLDv2 is link-local, and these messages can not be transmitted to the other subnets when MN moves. Perhaps, we need to make some change to support mobile subscribers. [Imed]: The current specification of Mobile IP and especially MIPv6 (RFC3775) states in Sections 10.4.3 and 11.3.4 that every home agent should support the multicast group membership control protocols. In addition, in order to obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node (MN). This means that the home agent could be a capable multicast router with Querying feature or an MLD proxy. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows (i.e. unicast) between the mobile node and home agent. The problems that rise here are: (1) the periodicity of MLD Query messages and (2) the response delay experienced by an MN to renew his membership after the handover while it is away. In other words, periodic transmission seems to be power consuming for an MN as only a single and unique MN is targeted at the tunnel end-point. Periodic transmission is designed to broadcast link-local MLD queries where the number of potential receivers is unknown. The second problem is inherited from the fact that an MN should register first its CoA and also wait an MLD query message to be received from his home agent before being authorised to send back his MLD report message. I do believe that it will be more reasonable to remove the second condition and allow an MN to send its BU and an MDL report messages simultaneously without waiting for an MLD query to be sent by the home agent after each handover. The home agent could maintain a state that indicates that the MN has already received at least one MLD query independently of its handover instances. >>> "- In route optimization (RO) mode, a mobile node can communicate >>> directly with the corresponding node (CN) without going through its >>> home agent. RO mode establisment with the multicast source node as CN >>> will be investigated. A problem statement will first be developed and >>> any solution space possibilities will be explored and the solution >>> will be standardized." >>> >>> I don't understand how this applies. The current BOF proposal >>> restricts itself to receiver mobility. However, multicast sources >>> just send out their data, they have no knowledge of receivers. Adding >>> such knowledge goes against this principle (there has been one attempt >>> in the past but it was discontinued due to lack of interest [1]), and >>> I do not see what the source could do about it (certainly tunneling >>> from source to MNs is even less scalable than today). >>> > >[Thomas] There is an emerging problem statement from IRTF/mobopts, which >discusses these subjects: >http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps > >[Thomas] An immediate transfer of MIPv6 RO to multicast is of course beyond >reach. However, there are proposals around that improve multicast source >mobility without relying on receiver knowledge. > >>> As such I would be comfortable with this direction of work only if >>> modifications at the multicast source were explicitly out of scope. >>> > >[Thomas] I don't see the evidence of the emphasis here: In an end-to-end >signaling scheme, why should a multicast-aware mobility stack not modify >sender behavior? If this is handled in a router-agnostic fashion, no >fundamental difference to related protocols (e.g., MIPv6) occurs to me? > >[Thomas] Nevertheless you are right: A working group dealing with receiver >mobility, only, is unaffected by any of these issues. > Mobile source is an important issue in mobile multicast, while IMO mobile receiver is more important for some applications. >>> "It is also a goal of the new working group to possibly standardize an >>> agent based solution to reduce time delay and overhead effort e.g. on >>> path re-construction. Both traffic and movement characteristic based >>> and local agent based approaches to deciding on bidirectional >>> tunnelling or remote subscription will be considered." >>> >>> What does 'agent based solution' refer to? Without prior knowledge of >>> the work it's not clear, but it doesn't sound good if it would mean >>> changes to multicast routing protocols. >>> > >[Thomas]Mobile multicast protocols, which are assisted by some sort of >mobility-aware route entity, commonly are referred to as "agent based". >Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the ARs >play the role of "agents". There are many more such agent functions >suggested, so one likes to summarize these under one term. According to the draft: http://ietfreport.isoc.org/all-ids/draft-zhang-multimob-memcast-ps-00.txt I think anent is referred to the "Multicast forwarder" . >>> As a general comment about the whole BOF proposal, maybe it would be >>> best to spell out outright that modifications to (non-mobility >>> related) multicast routers and multicast routing protocols are out of >>> scope. >>> > >[Thomas] :-) This will steer work within the realm of deployability. > >[Thomas] Conversely, there are tough parts in the mobile multicast regime and to >me it would make a lot of sense, if mobility related thinking will be >injected into future mcast routing protocol development - bi-dir PIM may >be a good starting point here. [Tony] Right, the current mobile multicast is only used in the access networks, and it is independent of the multicast routing protocols. [Imed] I do agree with Thomas. The impact of source mobility could affect the efficiency of some routing protocols. For instance, when a source is mobile and it sends traffic to many-to-many multicast group, multicast designated forwarders have to be aware of its mobility to update the forwarding entries in their routing tables and if necessary update the access lists to allow a continuous transmission of multicast traffic after each handover completion. > >?Prof. Dr. Thomas C. Schmidt >?HAW Hamburg, Dept. Informatik >?University of Applied Sciences >?Berliner Tor 7, D 20099 Hamburg >?Germany, Fon: +49-40-42875-8157 >?http://www.informatik.haw-hamburg.de/~schmidt > > > >------------------------------ > >_______________________________________________ >multimob mailing list >multimob@ietf.org >https://www1.ietf.org/mailman/listinfo/multimob > > >End of multimob Digest, Vol 7, Issue 2 >************************************** = = = = = = = = = = = = = = = = = = = = 　　　　　　　　Tony 　　　　　　　　guanjian8632@163.com 　　　　　　　　　　2007-10-05 +--------------------------------------+ | NGIRC, Beijing JiaoTong University | | BeiJing, China,100044 | | Http://www.njtu.edu.cn | +--------------------------------------+ This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 05 14:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdruQ-0006UN-0A; Fri, 05 Oct 2007 14:28:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdruN-0005ov-K2 for multimob@ietf.org; Fri, 05 Oct 2007 14:28:19 -0400 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdruK-0007Ji-65 for multimob@ietf.org; Fri, 05 Oct 2007 14:28:17 -0400 Received: from mailgate.informatik.haw-hamburg.de (isis2.informatik.haw-hamburg.de [141.22.10.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 7310562079; Fri, 5 Oct 2007 20:28:14 +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 18789-01-6; Fri, 5 Oct 2007 20:28:12 +0200 (CEST) Received: from [141.45.6.199] (unknown [141.45.6.199]) (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 468CB3C00294; Fri, 5 Oct 2007 20:28:12 +0200 (CEST) Message-ID: <4706823A.1060603@informatik.haw-hamburg.de> Date: Fri, 05 Oct 2007 20:28:10 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Romdhani, Imed" Subject: Re: [multimob] Re: FW: comments on the BOF proposal (Tony) References: <735F04A99D358E468A16EDB64FC04555051E9546@EVS1.napier-mail.napier.ac.uk> In-Reply-To: <735F04A99D358E468A16EDB64FC04555051E9546@EVS1.napier-mail.napier.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: multimob@ietf.org, guanjian8632@163.com 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 Dear Imed et all, please see comments inline. Romdhani, Imed wrote: >> Jari Arkko wrote: >> >>>> "IGMPv3/MLDv2 is originally defined for wired networks with shared >>>> links. In mobile envorinments, the link is point-to-point. Also mobi= le >>>> nodes have to save battery by entering into the dormant mode. Dorman= t >>>> mode operation needs to be supported. There are also concerns relate= d >>>> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The >>>> latency needs to be minimized. In Multimob these issues will be >>>> addressed and IGMPv3/MLDv2 for mobile environments will be standardi= zed." >>>> >>>> So what is being proposed here? Documenting already >>>> implemented/deployed fast join/fast leave extensions? Increasing th= e >>>> timer values to support dormant mode? The first item is not mobilit= y >>>> specific and the fate of these two solutions should not be tied >>>> together (e.g., I'd be interested in working with fast leave/join bu= t >>>> not dormant mode stuff). >>>> >> [Thomas] At first, the prerequisites should be revised: The statement = "In mobile=20 >> envorinments, the link is point-to-point." is not generally valid. >> >> [Thomas] Fast join/leave extensions of IGMPv3/MLDv2 tend to raise deba= tes - so=20 >> there might be demands to clarify/document/work out protocol enhanceme= nts. >> >> [Thomas] As for the dormant mode: I guess the timescales of IGMPv3/MLD= v2 and=20 >> dormant mode invocation at mobile devices are quite distinct - so I ha= ve=20 >> doubts about relevant issues here. >=20 > [Tony]: I think the key point of IGMPv3/MLDv2 in mobile envorinments is= the transfer of multicast states for mobile subscribers (receivers or so= urces). The current IGMPv3/MLDv2 is link-local, and these messages can no= t be transmitted to the other subnets when MN moves. Perhaps, we need to = make some change to support mobile subscribers. >=20 [Thomas] IGMPv3/MLDv2 is not used at sources. > [Imed]: The current specification of Mobile IP and especially MIPv6 (RF= C3775) states in Sections 10.4.3 and 11.3.4 that every home agent should = support the multicast group membership control protocols. In addition, in= order to obtain the mobile node's current multicast group membership the= home agent must periodically transmit MLD Query messages through the tun= nel to the mobile node (MN). This means that the home agent could be a ca= pable multicast router with Querying feature or an MLD proxy. The MLD pac= kets between the mobile node and the home agent are encapsulated within t= he same tunnel header used for other packet flows (i.e. unicast) between = the mobile node and home agent. >=20 > The problems that rise here are: (1) the periodicity of MLD Query messa= ges and (2) the response delay experienced by an MN to renew his membersh= ip after the handover while it is away. In other words, periodic transmis= sion seems to be power consuming for an MN as only a single and unique MN= is targeted at the tunnel end-point. Periodic transmission is designed t= o broadcast link-local MLD queries where the number of potential receiver= s is unknown. The second problem is inherited from the fact that an MN sh= ould register first its CoA and also wait an MLD query message to be rece= ived from his home agent before being authorised to send back his MLD rep= ort message. I do believe that it will be more reasonable to remove the s= econd condition and allow an MN to send its BU and an MDL report messages= simultaneously without waiting for an MLD query to be sent by the home a= gent after each handover. The home agent could maintain a state that indi= cates that the MN has already received a t l > east one MLD query independently of its handover instances. >=20 [Thomas] You are referring to bi-directional tunneling through the HA,=20 here. In this case, and in other tunneling scenarios, e.g., HMIPv6, we=20 indeed have a point-to-point link and MLD queries by routers are an=20 effort redundant to MIPv6 binding management (except for lost MLD=20 listener reports). How do you conclude that MLD Joins are only allowed in response to=20 membership queries? RFC 3775 states in section 10.4.3 "These [MLD listener report] messages=20 are issued whenever the mobile node decides to enable reception of=20 packets for a multicast group or in response to an MLD Query from the=20 home agent." - which seems perfectly reasonable to me and does not imply=20 any such restriction ?? As for the sequential signaling (BU -> BACK -> JOIN/MLD): this may be=20 easily resolved by piggybacking the BU, I guess. > =20 >=20 >>>> "- In route optimization (RO) mode, a mobile node can communicate >>>> directly with the corresponding node (CN) without going through its >>>> home agent. RO mode establisment with the multicast source node as C= N >>>> will be investigated. A problem statement will first be developed an= d >>>> any solution space possibilities will be explored and the solution >>>> will be standardized." >>>> >>>> I don't understand how this applies. The current BOF proposal >>>> restricts itself to receiver mobility. However, multicast sources >>>> just send out their data, they have no knowledge of receivers. Addin= g >>>> such knowledge goes against this principle (there has been one attem= pt >>>> in the past but it was discontinued due to lack of interest [1]), an= d >>>> I do not see what the source could do about it (certainly tunneling >>>> from source to MNs is even less scalable than today). >>>> >> [Thomas] There is an emerging problem statement from IRTF/mobopts, whi= ch=20 >> discusses these subjects: >> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps >> >> [Thomas] An immediate transfer of MIPv6 RO to multicast is of course b= eyond=20 >> reach. However, there are proposals around that improve multicast sour= ce=20 >> mobility without relying on receiver knowledge. >> >=20 >>>> As such I would be comfortable with this direction of work only if >>>> modifications at the multicast source were explicitly out of scope. >>>> >> [Thomas] I don't see the evidence of the emphasis here: In an end-to-e= nd=20 >> signaling scheme, why should a multicast-aware mobility stack not modi= fy=20 >> sender behavior? If this is handled in a router-agnostic fashion, no=20 >> fundamental difference to related protocols (e.g., MIPv6) occurs to me= ? >> >> [Thomas] Nevertheless you are right: A working group dealing with rece= iver=20 >> mobility, only, is unaffected by any of these issues. >> > Mobile source is an important issue in mobile multicast, while IMO mobi= le=20 > receiver is more important for some applications. >=20 >>>> "It is also a goal of the new working group to possibly standardize = an >>>> agent based solution to reduce time delay and overhead effort e.g. o= n >>>> path re-construction. Both traffic and movement characteristic based >>>> and local agent based approaches to deciding on bidirectional >>>> tunnelling or remote subscription will be considered." >>>> >>>> What does 'agent based solution' refer to? Without prior knowledge = of >>>> the work it's not clear, but it doesn't sound good if it would mean >>>> changes to multicast routing protocols. >>>> >> [Thomas]Mobile multicast protocols, which are assisted by some sort of= =20 >> mobility-aware route entity, commonly are referred to as "agent based"= . >> Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the A= Rs=20 >> play the role of "agents". There are many more such agent functions=20 >> suggested, so one likes to summarize these under one term. >=20 > According to the draft: http://ietfreport.isoc.org/all-ids/draft-zhang-= multimob-memcast-ps-00.txt > I think anent is referred to the "Multicast forwarder" . >=20 >>>> As a general comment about the whole BOF proposal, maybe it would be >>>> best to spell out outright that modifications to (non-mobility >>>> related) multicast routers and multicast routing protocols are out o= f >>>> scope. >>>> >> [Thomas] :-) This will steer work within the realm of deployability. >> >> [Thomas] Conversely, there are tough parts in the mobile multicast reg= ime and to=20 >> me it would make a lot of sense, if mobility related thinking will be=20 >> injected into future mcast routing protocol development - bi-dir PIM m= ay=20 >> be a good starting point here. >=20 > [Tony] Right, the current mobile multicast is only used in the access n= etworks, and it is independent of the multicast routing protocols. >=20 > [Imed] I do agree with Thomas. The impact of source mobility could affe= ct the efficiency of some routing protocols. For instance, when a source = is mobile and it sends traffic to many-to-many multicast group, multicast= designated forwarders have to be aware of its mobility to update the for= warding entries in their routing tables and if necessary update the acces= s lists to allow a continuous transmission of multicast traffic after eac= h handover completion. >=20 [Thomas] You are referring to Source Specific Multicast here. Yes, I=20 agree. In any approach, which is not equivalent to bi-directional=20 tunneling, unmodified SSM source filters will prevent packet forwarding=20 down an established distribution tree when CoA's change. Best wishes, thomas --=20 =C2=B0 Prof. Dr. Thomas C. Schmidt =C2=B0 HAW Hamburg, Dept. Informatik =C2=B0 University of Applied Sciences =C2=B0 Berliner Tor 7, D 20099 Hamburg =C2=B0 Germany, Fon: +49-40-42875-8157 =C2=B0 http://www.informatik.haw-hamburg.de/‾schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 11 10:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzSs-0006nL-Ny; Thu, 11 Oct 2007 10:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzSq-0006RL-J5 for multimob@ietf.org; Thu, 11 Oct 2007 10:56:40 -0400 Received: from web84115.mail.mud.yahoo.com ([68.142.206.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfzSg-0005Oi-AQ for multimob@ietf.org; Thu, 11 Oct 2007 10:56:36 -0400 Received: (qmail 51324 invoked by uid 60001); 11 Oct 2007 14:56:14 -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=oKh4LnmgEaS6QoXwLneAMvatSEWWgnr0R5DH9EqwFt+HFbthRC0Gb0mjm6ekbWpKE1k0hH75twqY1f89tSd4ihpHx6PW0DF+vJ1OsI3K1SJvt43dzLfp9NL5FTJQpNalCuFNFUsnZ3UqfoMcVgLdkfH01hGK3sIFnw2CDaWFftc=; X-YMail-OSG: k1YmZYYVM1kLVxoOD9DdAnlOD2NTjQni9LivEV.jslxZeGWtjze1BQU8lJ7FlGWPeHDGj8LraYVhF.K.gWBbNYJDHp0xZ0x4XQrvCzhfAGZ7z0gz890- Received: from [206.16.17.212] by web84115.mail.mud.yahoo.com via HTTP; Thu, 11 Oct 2007 07:56:14 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Thu, 11 Oct 2007 07:56:14 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <681381.50244.qm@web84115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [multimob] Revised draft charter text 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="===============1145926228==" Errors-To: multimob-bounces@ietf.org --===============1145926228== Content-Type: multipart/alternative; boundary="0-1004186055-1192114574=:50244" --0-1004186055-1192114574=:50244 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable has been posted at:=0Ahttp://www-etud.iro.umontreal.ca/‾sarikaya/multimob/= =0A=0AComments welcome.=0A=0AChairs,=0A=0ASuresh and Behcet=0A=0A=0A=0A=0A --0-1004186055-1192114574=:50244 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
has been posted at:
http://www-etud.iro.umontreal.ca/‾sarikaya/multimob/=

Comments welcome.

Chairs,

Suresh and Behcet
=

--0-1004186055-1192114574=:50244-- --===============1145926228== 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 --===============1145926228==-- From multimob-bounces@ietf.org Thu Oct 11 12:29: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 1Ig0u3-00010Y-Uo; Thu, 11 Oct 2007 12:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0u2-0000yN-9F for multimob@ietf.org; Thu, 11 Oct 2007 12:28:50 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig0u0-0004iP-P5 for multimob@ietf.org; Thu, 11 Oct 2007 12:28:49 -0400 Received: from localhost (101-162.mm.internet2.edu [198.202.101.162]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 0F6634DA1B; Fri, 12 Oct 2007 01:28:45 +0900 (JST) Date: Fri, 12 Oct 2007 01:29:32 +0900 (JST) Message-Id: <20071012.012932.59664496.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com Subject: Re: [multimob] Revised draft charter text From: Hitoshi Asaeda In-Reply-To: <681381.50244.qm@web84115.mail.mud.yahoo.com> References: <681381.50244.qm@web84115.mail.mud.yahoo.com> X-Mailer: Mew version 5.2 on Emacs 22.1 / 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Hi Behcet, The candidate charter says; "There are currently deployed extensions to reduce the join and leave latencies." Could you tell me what is the "deployed extensions" in above sentense? Or could you just give me the pointer? Thanks, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 11 18:01:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig66E-0003AO-TZ; Thu, 11 Oct 2007 18:01:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig66D-0003AI-CB for multimob@ietf.org; Thu, 11 Oct 2007 18:01:45 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig66C-0006No-W0 for multimob@ietf.org; Thu, 11 Oct 2007 18:01:45 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9BM0Va7011007; Thu, 11 Oct 2007 17:00:32 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 17:00:31 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 17:00:31 -0500 Message-ID: <470E9D50.7060401@ericsson.com> Date: Thu, 11 Oct 2007 18:01:52 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Hitoshi Asaeda Subject: Re: [multimob] Revised draft charter text References: <681381.50244.qm@web84115.mail.mud.yahoo.com> <20071012.012932.59664496.asaeda@sfc.wide.ad.jp> In-Reply-To: <20071012.012932.59664496.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2007 22:00:31.0275 (UTC) FILETIME=[241C5FB0:01C80C52] 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 Hi Hitoshi, There are proprietary extensions to IGMP and LMD that can reduce leave latencies under certain conditions. e.g Cisco Fast Leave and Riverstone enhanced IGMP. The goal of this text is to solicit input from proprietary implementations in the form of a draft in order to discuss them as possible solutions. Thanks Hitoshi Asaeda wrote: > Hi Behcet, > > The candidate charter says; > > "There are currently deployed extensions to reduce the join and leave > latencies." > > Could you tell me what is the "deployed extensions" in above sentense? > Or could you just give me the pointer? > Thanks, > -- > Hitoshi Asaeda > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 12 00:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBqc-0006TI-82; Fri, 12 Oct 2007 00:10:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBqb-0006SZ-MM for multimob@ietf.org; Fri, 12 Oct 2007 00:10:01 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgBqb-0002mF-3i for multimob@ietf.org; Fri, 12 Oct 2007 00:10:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPS00HPN67I7I@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 12 Oct 2007 12:09:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JPS00HN967HN2@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 12 Oct 2007 12:09:18 +0800 (CST) Received: from prashant7175 ([10.18.5.160]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JPS000UU67G45@szxml03-in.huawei.com> for multimob@ietf.org; Fri, 12 Oct 2007 12:09:17 +0800 (CST) Date: Fri, 12 Oct 2007 09:38:58 +0530 From: Prashant Jhingran Subject: RE: [multimob] Revised draft charter text In-reply-to: <470E9D50.7060401@ericsson.com> To: 'Suresh Krishnan' , 'Hitoshi Asaeda' Message-id: <001401c80c85$9d5e0f30$a005120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgMUolG/GHuDiR6QNq04IKomxpeNwAMqjMA X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: multimob@ietf.org X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prashantj@huawei.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimob-bounces@ietf.org Hi, Huawei has also has a similar mecahnism in order to avoid leave latency. As per my understanding IP TV providers require it most. Regards, Prashant Jhingran Huawei Technologies +91 - 80 - 41117676 Ext - 1458 +91 - 9448927814 ============================================ " Peace means an undivided mind; OM SHANTI !" - www.artoflivingresearch.org =========================================== This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ===================EOM=========================== -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] Sent: Friday, October 12, 2007 3:32 AM To: Hitoshi Asaeda Cc: multimob@ietf.org Subject: Re: [multimob] Revised draft charter text Hi Hitoshi, There are proprietary extensions to IGMP and LMD that can reduce leave latencies under certain conditions. e.g Cisco Fast Leave and Riverstone enhanced IGMP. The goal of this text is to solicit input from proprietary implementations in the form of a draft in order to discuss them as possible solutions. Thanks Hitoshi Asaeda wrote: > Hi Behcet, > > The candidate charter says; > > "There are currently deployed extensions to reduce the join and leave > latencies." > > Could you tell me what is the "deployed extensions" in above sentense? > Or could you just give me the pointer? > Thanks, > -- > Hitoshi Asaeda > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 12 04:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgG9w-000760-JQ; Fri, 12 Oct 2007 04:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgG9v-0006qb-0s for multimob@ietf.org; Fri, 12 Oct 2007 04:46:15 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgG9o-0002Kq-Ez for multimob@ietf.org; Fri, 12 Oct 2007 04:46:15 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 12 Oct 2007 10:45:37 +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, 12 Oct 2007 10:45:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [multimob] Revised draft charter text Date: Fri, 12 Oct 2007 10:45:36 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A4016232F9@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <681381.50244.qm@web84115.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Revised draft charter text Thread-Index: AcgMGZMKeNMC5lUdSSquAZ/DwyrUiwAkkFFA From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 12 Oct 2007 08:45:37.0006 (UTC) FILETIME=[428638E0:01C80CAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: 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="===============0650376200==" Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0650376200== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80CAC.4226058B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80CAC.4226058B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, concerning the issue=20 > It is also a goal of the new working group to possibly standardize an = agent based solution to > reduce time delay and overhead effort e.g. on path re-construction. = Both traffic and movement > characteristic based and local agent based approaches to deciding on = bidirectional=20 > tunnelling or remote subscription will be considered. =20 I have submitted a draft on 'Agent-based NEMO Multicast' for discussion = on the ML which should provisionally be available at = http://www3.ietf.org/proceedings/staging/draft-von-hugo-multimob-agents-0= 0.txt =20 Comments are more than welcome! =20 However, I have to admit that at the moment the analysis part is still = missing ;-( =20 Kind regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Gesendet: Donnerstag, 11. Oktober 2007 16:56 An: multimob@ietf.org Betreff: [multimob] Revised draft charter text =20 has been posted at: http://www-etud.iro.umontreal.ca/‾sarikaya/multimob/ = =20 Comments welcome. Chairs, Suresh and Behcet =20 ------_=_NextPart_001_01C80CAC.4226058B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = all,

concerning the = issue

> It is also = a goal of the new working group to possibly standardize an agent based solution = to

> reduce time = delay and overhead effort e.g. on path re-construction. Both traffic and = movement

> = characteristic based and local agent based approaches to deciding on bidirectional =

> tunnelling = or remote subscription will be considered.

 

I have submitted = a draft on ‘Agent-based NEMO Multicast’ for discussion on the ML = which should provisionally be available at http://www3.ietf.org/proceedings/staging/draft-von-hugo-mu= ltimob-agents-00.txt

 

Comments are = more than welcome!

 

However, I have = to admit that at the moment the analysis part is still missing = ;-(

 

Kind = regards

Dirk =

-----Urspr=FCngliche = Nachricht-----
Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Gesendet: Donnerstag, 11. = Oktober 2007 16:56
An: multimob@ietf.org
Betreff: [multimob] = Revised draft charter text

 

has been = posted at:
http://www-etud.iro.umontreal.ca/‾sarikaya/multimob/
Comments welcome.

Chairs,

Suresh and Behcet

 

------_=_NextPart_001_01C80CAC.4226058B-- --===============0650376200== 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 --===============0650376200==-- From multimob-bounces@ietf.org Fri Oct 12 10:08:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLBG-0001pB-7c; Fri, 12 Oct 2007 10:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLBF-0001iP-Js for multimob@ietf.org; Fri, 12 Oct 2007 10:07:57 -0400 Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgLB4-0006NW-1y for multimob@ietf.org; Fri, 12 Oct 2007 10:07:51 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.106.219]) by omta01sl.mx.bigpond.com with ESMTP id <20071012140709.RDTF26650.omta01sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com> for ; Fri, 12 Oct 2007 14:07:09 +0000 Received: from PC20005 ([124.190.106.219]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071012140709.KDXS20737.oaamta02sl.mx.bigpond.com@PC20005>; Fri, 12 Oct 2007 14:07:09 +0000 From: "Hesham Soliman" To: Date: Sat, 13 Oct 2007 00:06:57 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgM2Sa5evw7+6RORfGT0iwYVGYB9w== X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [multimob] review of draft-irtf-mobopts-mmcast- 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 Hi all, I reviewed Thomas' problem statement draft. One of the few times I don't have any comments on a draft :) I think it's very well written and serves as a good reference for the current state of the art. I also find the comprehensive references very useful. I hope this can be used as a base for a charter (if there is a WG) or a guideline for further work in this area in IETF. Hesham _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 12 11:57:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMsf-0005Mo-US; Fri, 12 Oct 2007 11:56:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMse-00050f-MG for multimob@ietf.org; Fri, 12 Oct 2007 11:56:52 -0400 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgMsW-00063Y-2T for multimob@ietf.org; Fri, 12 Oct 2007 11:56:44 -0400 Received: from mailgate.informatik.haw-hamburg.de (isis2.informatik.haw-hamburg.de [141.22.10.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 5655E620A8; Fri, 12 Oct 2007 17:56:40 +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 31559-01-5; Fri, 12 Oct 2007 17:56:40 +0200 (CEST) Received: from [141.22.26.203] (unknown [141.22.26.203]) (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 C5A673C0012C; Fri, 12 Oct 2007 17:56:39 +0200 (CEST) Message-ID: <470F9936.7090700@informatik.haw-hamburg.de> Date: Fri, 12 Oct 2007 17:56:38 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [multimob] review of draft-irtf-mobopts-mmcast- References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: multimob@ietf.org, mobopts@irtf.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 Hi Hesham, thanks for too many flowers ;) In prior discussions you pointed at a more detailed/explicit listing of=20 future steps, so that this can serve as input for future work items ...=20 we'll fix that. thomas Hesham Soliman wrote: > Hi all,=20 >=20 > I reviewed Thomas' problem statement draft. One of the few times I don'= t > have any comments on a draft :) I think it's very well written and serv= es as > a good reference for the current state of the art. I also find the > comprehensive references very useful. I hope this can be used as a base= for > a charter (if there is a WG) or a guideline for further work in this ar= ea in > IETF.=20 >=20 > Hesham >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/‾schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Oct 15 03:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKFs-0003j5-12; Mon, 15 Oct 2007 03:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKFr-0003j0-BM for multimob@ietf.org; Mon, 15 Oct 2007 03:20:47 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhKFp-0004dc-PL for multimob@ietf.org; Mon, 15 Oct 2007 03:20:47 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 15 Oct 2007 09:20:38 +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); Mon, 15 Oct 2007 09:20:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: AW: [multimob] FW: comments on the BOF proposal X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 15 Oct 2007 09:20:37 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A4016232FF@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <343692.20310.qm@web84102.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [multimob] FW: comments on the BOF proposal Thread-Index: AcgMtlBmkdSwXE7ZT22tFGU2BqsMDACRWSAQ From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 15 Oct 2007 07:20:38.0328 (UTC) FILETIME=[E2B6F380:01C80EFB] X-Spam-Score: -1.0 (-) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 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="===============1883436439==" Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1883436439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80EFB.E255FE69" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80EFB.E255FE69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 just to inform you that my already announced draft is now officially available at http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt =20 Agent-based multicast support for moving networks (NEMO) =20 Best regards Dirk =20 ------_=_NextPart_001_01C80EFB.E255FE69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 
just to inform =
you that my already announced draft is now officially available at =
http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-a=
gents-00.txt

Agent-based multicast support for moving networks (NEMO)

 

Best = regards

Dirk

 

------_=_NextPart_001_01C80EFB.E255FE69-- --===============1883436439== 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 --===============1883436439==-- From multimob-bounces@ietf.org Mon Oct 15 19:11:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhZ4M-0002kR-3S; Mon, 15 Oct 2007 19:09:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhZ4K-0002kJ-Tf for multimob@ietf.org; Mon, 15 Oct 2007 19:09:52 -0400 Received: from web84111.mail.mud.yahoo.com ([68.142.206.198]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhZ4K-00063N-8Y for multimob@ietf.org; Mon, 15 Oct 2007 19:09:52 -0400 Received: (qmail 33326 invoked by uid 60001); 15 Oct 2007 23:09:51 -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=1ovl6SvQd8MFXOUdr3x6N3TBtJcbYwaVW8/DV2/3Nfyi2XKGw5T0BsijI4f6460S6JgAEgUhHDSd6v5DW7NqqNl7+9gb6xL4SXQVAHXGVd+SLOwIxOu6E24kvKKRE3wg/Mop5vOPKMxiGsf8d4v31VOYUeVeCbwlgyMapNuMy/o=; X-YMail-OSG: _t9Eyo0VM1nl5kIdHCeZBbRBp6kgtdP3xlpnVffrMDNnNU76o4PMwat99Ah4nG8T1LLVgcWZyOCeYpd.rvq2wSdmm8B.Ayg9qcfRwmrwpiEsnFlG_9E- Received: from [206.16.17.212] by web84111.mail.mud.yahoo.com via HTTP; Mon, 15 Oct 2007 16:09:51 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Mon, 15 Oct 2007 16:09:51 -0700 (PDT) From: Behcet Sarikaya To: "Von-Hugo, Dirk" , multimob@ietf.org MIME-Version: 1.0 Message-ID: <676414.30250.qm@web84111.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [multimob] comments on draft-von-hugo-multimob-agents 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="===============1360580476==" Errors-To: multimob-bounces@ietf.org --===============1360580476== Content-Type: multipart/alternative; boundary="0-2036677585-1192489791=:30250" --0-2036677585-1192489791=:30250 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Dirk,=0A Regarding Reference 9 in your draft, you said:=0ACorresponding= multicast traffic received at the MAA is subsequently =0A forwarded by t= he MAA back to the MR via the bi-directional tunnel. =0A This MLD-proxy f= unctionality has been described for the HA as MAA in =0A [9].=0AHowever, = in [9], MLD-proxy functionality is defined for routing multicast traffic in= side NEMO in case where MNNs are more than one hop away from MR.=0A=0AIn Fi= g. 1, you have:=0A | Decision on new MCR (DMA) |=0Awhat is the di= fference between an AR and a DMA? Is DMA another AR? How is the decision ma= de?=0A=0ARegards,=0A=0ABehcet=0A=0A----- Original Message ----=0AFrom: "Von= -Hugo, Dirk" =0ATo: multimob@ietf.org=0ASent: Mond= ay, October 15, 2007 2:20:37 AM=0ASubject: AW: AW: [multimob] FW: comments = on the BOF proposal=0A=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0ADear = all,=0A=0A=0A=0A=0A just to inform you that my already announced draft is n= ow officially available at http://ietfreport.isoc.org/all-ids/draft-von-hug= o-multimob-agents-00.txt=0A=0AAgent-based multicast support for moving netw= orks (NEMO)=0A=0A=0A=0A =0A=0A=0ABest regards=0A=0A=0ADirk=0A=0A=0A =0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A --0-2036677585-1192489791=:30250 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi Dirk,
  Regarding Reference 9 in your draft= , you said:
Corresponding multicast traffic received at the MAA is subse= quently
   forwarded by the MAA back to the MR via the bi-dir= ectional tunnel.
   This MLD-proxy functionality has been des= cribed for the HA as MAA in
   [9].
However, in [9], MLD-p= roxy functionality is defined for routing multicast traffic inside NEMO in = case where MNNs are more than one hop away from MR.

In Fig. 1, you h= ave:
     |      Decision o= n new MCR (DMA)  |
what is the difference between an AR and a DMA? = Is DMA another AR? How is the decision made?

Regards,

Behcet

----- Original Message = ----
From: "Von-Hugo, Dirk" <Dirk.Hugo@t-systems.com>
To: multi= mob@ietf.org
Sent: Monday, October 15, 2007 2:20:37 AM
Subject: AW: A= W: [multimob] FW: comments on the BOF proposal

=0A=0A=0A =0A =0A=0A<= style>=0A=0A=0A=0A=0A=0A
=0A=0A

Dear = all,

=0A=0A
=0A=0A
 
just to inform you that my already announced draft i=
s now officially available at http://ietfreport.isoc.org/all-ids/draft=
-von-hugo-multimob-agents-00.txt

Age=
nt-based multicast support for moving networks (NEMO)
=0A=0A=0A=0A

 = ;

=0A=0A

Best regards

=0A= =0A

Dirk

=0A=0A

 

=0A=0A
=0A=0A
= =0A=0A
=0A=0A
=0A=0A

--0-2036677585-1192489791=:30250-- --===============1360580476== 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 --===============1360580476==-- From multimob-bounces@ietf.org Tue Oct 16 04:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihhiz-0007aR-TN; Tue, 16 Oct 2007 04:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihhiu-0007PZ-6F for multimob@ietf.org; Tue, 16 Oct 2007 04:24:20 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ihhir-0001Xm-2q for multimob@ietf.org; Tue, 16 Oct 2007 04:24:20 -0400 X-VirusChecked: Checked X-Env-Sender: Christophe.Janneteau@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1192523050!25478210!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27792 invoked from network); 16 Oct 2007 08:24:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 16 Oct 2007 08:24:10 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l9G8OAKK027113 for ; Tue, 16 Oct 2007 01:24:10 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l9G8O9S5008773 for ; Tue, 16 Oct 2007 03:24:09 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l9G8O8ua008753 for ; Tue, 16 Oct 2007 03:24:08 -0500 (CDT) Received: from [10.161.201.129] ([10.161.201.129]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 16 Oct 2007 09:24:04 +0100 Message-ID: <47147526.5060009@motorola.com> Date: Tue, 16 Oct 2007 10:24:06 +0200 From: Christophe Janneteau User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [multimob] comments on draft-von-hugo-multimob-agents References: <676414.30250.qm@web84111.mail.mud.yahoo.com> In-Reply-To: <676414.30250.qm@web84111.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 08:24:04.0671 (UTC) FILETIME=[E9E28CF0:01C80FCD] X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "Von-Hugo, Dirk" , 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 Hi Behcet, Just one clarification about the draft listed as reference [9] (i.e.draft-janneteau-nemo-multicast-mldproxy-00.txt - now expired). You are right it describes the use of MLD-Proxy functionality inside the NEMO. But [9] also briefly mentions the possible use of MLD-Proxy on the HA in situation where the bi-directionnal tunnel between MR and HA needs to be used to convey multicast traffic (for instance when the local access router the MR is attached to is not multicast-capable). One key advantage of using MLD-proxy functionality on the Home Agent is that this function is "multicast routing protocol" independent; which may ease its deployment. Section 4.2 of [9] reads: "If the mobile network moves to a foreign link where multicast is not supported, MR can still maintain ongoing multicast sessions by performing re-subscription to the group, with MLD Report messages, through the MR-HA bi-directional tunnel. Several approaches can be envisaged for the multicast support on the HA. It can be configured as a multicast router, or simply as an MLD-proxy. In the later case, the HA would then issue its own MLD Reports towards the multicast-enabled Border Router (BR) on the MR's home link." I suppose Dirk was referring to this function. Christophe Behcet Sarikaya wrote: > Hi Dirk, > Regarding Reference 9 in your draft, you said: > Corresponding multicast traffic received at the MAA is subsequently > forwarded by the MAA back to the MR via the bi-directional tunnel. > This MLD-proxy functionality has been described for the HA as MAA in > [9]. > However, in [9], MLD-proxy functionality is defined for routing > multicast traffic inside NEMO in case where MNNs are more than one hop > away from MR. > > In Fig. 1, you have: > | Decision on new MCR (DMA) | > what is the difference between an AR and a DMA? Is DMA another AR? How > is the decision made? > > Regards, > > Behcet > > ----- Original Message ---- > From: "Von-Hugo, Dirk" > To: multimob@ietf.org > Sent: Monday, October 15, 2007 2:20:37 AM > Subject: AW: AW: [multimob] FW: comments on the BOF proposal > > Dear all, > > > > just to inform you that my already announced draft is now officially available at http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt > > Agent-based multicast support for moving networks (NEMO) > > > > Best regards > > Dirk > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Oct 16 05:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiQZ-0000qy-N6; Tue, 16 Oct 2007 05:09:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiQX-0000oA-W2 for multimob@ietf.org; Tue, 16 Oct 2007 05:09:26 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhiQX-0002qD-Bg for multimob@ietf.org; Tue, 16 Oct 2007 05:09:25 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 16 Oct 2007 11:09:20 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 11:09:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [multimob] comments on draft-von-hugo-multimob-agents Date: Tue, 16 Oct 2007 11:09:18 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A40162330C@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <676414.30250.qm@web84111.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] comments on draft-von-hugo-multimob-agents Thread-Index: AcgPgQSuBvJK3p0QT9ejZrhYOdeWsgAUCsMA From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 16 Oct 2007 09:09:19.0279 (UTC) FILETIME=[3BEADBF0:01C80FD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: 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="===============1590584873==" Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1590584873== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80FD4.3B94A725" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80FD4.3B94A725 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Behcet, =20 you are right that [9] mainly describes the MLD proxying within the NEMO = and I should have instead pointed to the draft referenced there as [1] = where MLD proxy is introduced (the later RFC 4605 on 'IGMP/MLD-based = Multicast Forwarding ('IGMP/MLD Proxying')') but within [9] already the = MR tunnel was introduced by saying=20 'If the mobile network moves to a foreign link where multicast is not supported, MR can still maintain ongoing multicast sessions by performing re-subscription to the group, with MLD Report messages, through the MR-HA bi-directional tunnel. Several approaches can be envisaged for the multicast support on the HA. It can be configured as a multicast router, or simply as an MLD-proxy.' =20 Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for = Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is = introduced in draft-zhang-mipshop-multicast-dma-03.txt). MAA may be a DMA or the HA or a future AR - the decision is made based = on criteria as most efficient routing paths or less tree re-construction = effort etc. =20 Kind regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Gesendet: Dienstag, 16. Oktober 2007 01:10 An: von Hugo, Dirk; multimob@ietf.org Betreff: [multimob] comments on draft-von-hugo-multimob-agents =20 Hi Dirk, Regarding Reference 9 in your draft, you said: Corresponding multicast traffic received at the MAA is subsequently=20 forwarded by the MAA back to the MR via the bi-directional tunnel.=20 This MLD-proxy functionality has been described for the HA as MAA in=20 [9]. However, in [9], MLD-proxy functionality is defined for routing = multicast traffic inside NEMO in case where MNNs are more than one hop = away from MR. In Fig. 1, you have: | Decision on new MCR (DMA) | what is the difference between an AR and a DMA? Is DMA another AR? How = is the decision made? Regards, Behcet ----- Original Message ---- From: "Von-Hugo, Dirk" To: multimob@ietf.org Sent: Monday, October 15, 2007 2:20:37 AM Subject: AW: AW: [multimob] FW: comments on the BOF proposal Dear all, =20 just to inform you that my already announced draft is now officially = available at = http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt = =20 Agent-based multicast support for moving networks (NEMO) =20 Best regards Dirk =20 =20 ------_=_NextPart_001_01C80FD4.3B94A725 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Behcet,

 

you are right = that [9] mainly describes the MLD proxying within the NEMO and I should have = instead pointed to the draft referenced there as [1] where MLD proxy is = introduced (the later RFC 4605 on 'IGMP/MLD-based Multicast Forwarding ('IGMP/MLD = Proxying')’) but within [9] already the MR tunnel was introduced by saying =

=A0=A0 ‘If = the mobile network moves to a foreign link where multicast is

=A0=A0 not = supported, MR can still maintain ongoing multicast sessions by

=A0=A0 = performing re-subscription to the group, with MLD Report messages,

=A0=A0 through = the MR-HA bi-directional tunnel.=A0 Several approaches can be

=A0=A0 envisaged = for the multicast support on the HA.=A0 It can be

=A0=A0 = configured as a multicast router, or simply as an MLD-proxy.’

 

Sorry, DMA in = Fig. 1 is a typo – it should read more generally MAA for Multicast Anchor = Agent (expression DMA for Dynamic Multicast Agent is introduced in = draft-zhang-mipshop-multicast-dma-03.txt).

MAA may be a DMA = or the HA or a future AR – the decision is made based on criteria as most efficient routing paths or less tree re-construction effort = etc.

=A0=

Kind = regards

Dirk =

-----Urspr=FCngliche = Nachricht-----
Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Gesendet: Dienstag, 16. = Oktober 2007 01:10
An: von Hugo, Dirk; multimob@ietf.org
Betreff: [multimob] = comments on draft-von-hugo-multimob-agents

 

Hi Dirk,
  Regarding Reference 9 in your draft, you said:
Corresponding multicast traffic received at the MAA is subsequently
   forwarded by the MAA back to the MR via the bi-directional = tunnel.
   This MLD-proxy functionality has been described for the HA = as MAA in
   [9].
However, in [9], MLD-proxy functionality is defined for routing = multicast traffic inside NEMO in case where MNNs are more than one hop away from = MR.

In Fig. 1, you have:
     |      Decision on new = MCR (DMA)  |
what is the difference between an AR and a DMA? Is DMA another AR? How = is the decision made?

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <Dirk.Hugo@t-systems.com>
To: multimob@ietf.org
Sent: Monday, October 15, 2007 2:20:37 AM
Subject: AW: AW: [multimob] FW: comments on the BOF = proposal

Dear all,

 
just to inform =
you that my already announced draft is now officially available at =
http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-a=
gents-00.txt



Agent-based multicast support for moving networks (NEMO)

 

Best regards

Dirk

 

 

------_=_NextPart_001_01C80FD4.3B94A725-- --===============1590584873== 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 --===============1590584873==-- From multimob-bounces@ietf.org Tue Oct 16 05:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihib3-0007Aa-Oo; Tue, 16 Oct 2007 05:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihib2-0007A9-5e for multimob@ietf.org; Tue, 16 Oct 2007 05:20:16 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihiav-00037J-RU for multimob@ietf.org; Tue, 16 Oct 2007 05:20:16 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 16 Oct 2007 11:19:46 +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); Tue, 16 Oct 2007 11:19:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [multimob] comments on draft-von-hugo-multimob-agents Date: Tue, 16 Oct 2007 11:19:45 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A40162330E@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <47147526.5060009@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] comments on draft-von-hugo-multimob-agents Thread-Index: AcgPzvRlG8QqBCCiSPi4JdGkpWuGtgABtuzw From: "Von-Hugo, Dirk" To: , X-OriginalArrivalTime: 16 Oct 2007 09:19:46.0456 (UTC) FILETIME=[B1BE7980:01C80FD5] X-Spam-Score: -1.0 (-) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Hi Christophe, quite right, thanks for your quick clarification!=20 regards Dirk=20 Hi Behcet, Just one clarification about the draft listed as reference [9] (i.e.draft-janneteau-nemo-multicast-mldproxy-00.txt - now expired). You are right it describes the use of MLD-Proxy functionality inside the NEMO. But [9] also briefly mentions the possible use of MLD-Proxy on the HA in situation where the bi-directionnal tunnel between MR and HA needs to be used to convey multicast traffic (for instance when the local access router the MR is attached to is not multicast-capable). One key advantage of using MLD-proxy functionality on the Home Agent is that this function is "multicast routing protocol" independent; which may ease its deployment. Section 4.2 of [9] reads: "If the mobile network moves to a foreign link where multicast is not supported, MR can still maintain ongoing multicast sessions by performing re-subscription to the group, with MLD Report messages, through the MR-HA bi-directional tunnel. Several approaches can be envisaged for the multicast support on the HA. It can be configured as a multicast router, or simply as an MLD-proxy. In the later case, the HA would then issue its own MLD Reports towards the multicast-enabled Border Router (BR) on the MR's home link." I suppose Dirk was referring to this function. Christophe Behcet Sarikaya wrote: > Hi Dirk, > Regarding Reference 9 in your draft, you said: > Corresponding multicast traffic received at the MAA is subsequently > forwarded by the MAA back to the MR via the bi-directional tunnel. > This MLD-proxy functionality has been described for the HA as MAA in > [9]. > However, in [9], MLD-proxy functionality is defined for routing > multicast traffic inside NEMO in case where MNNs are more than one hop > away from MR. >=20 > In Fig. 1, you have: > | Decision on new MCR (DMA) | > what is the difference between an AR and a DMA? Is DMA another AR? How > is the decision made? >=20 > Regards, >=20 > Behcet >=20 > ----- Original Message ---- > From: "Von-Hugo, Dirk" > To: multimob@ietf.org > Sent: Monday, October 15, 2007 2:20:37 AM > Subject: AW: AW: [multimob] FW: comments on the BOF proposal >=20 > Dear all, >=20 > =20 >=20 > just to inform you that my already announced draft is now officially available at http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt >=20 > Agent-based multicast support for moving networks (NEMO) >=20 > =20 >=20 > Best regards >=20 > Dirk >=20 > =20 >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Oct 16 15:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhsIU-0007rS-TF; Tue, 16 Oct 2007 15:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhsIT-0007rL-TV for multimob@ietf.org; Tue, 16 Oct 2007 15:41:45 -0400 Received: from web84103.mail.mud.yahoo.com ([68.142.206.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IhsIL-00023N-Bk for multimob@ietf.org; Tue, 16 Oct 2007 15:41:45 -0400 Received: (qmail 37949 invoked by uid 60001); 16 Oct 2007 19:41:21 -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=if8CWaCXpiWi/OQ6unC4rDTvrkg6fyASb9mM3Vt3dks1bT/HRB2KGdLWtNWzBzYjCogWwAoAnQ3UHxbCEvVUVN1IDsDrKy8Og4gH5IuvqMRi1+rV4xdkjtsd9RvTF6ujUstM/SE4huMfsJbn9Pv9cLVCrLXqZkAY/qE0riOgpEA=; X-YMail-OSG: p376hl4VM1lxyH.fGlDokJaKQ5cgyBEvhOA31e1We.nG1FT96BfejKWOhqy_B1kmSVIo_m6GTxUgQEHrWYQZDSbmy_cPDZHaCU5GuG42Oc5QPa_pXDk- Received: from [206.16.17.212] by web84103.mail.mud.yahoo.com via HTTP; Tue, 16 Oct 2007 12:41:21 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Tue, 16 Oct 2007 12:41:21 -0700 (PDT) From: Behcet Sarikaya Subject: Re: AW: [multimob] comments on draft-von-hugo-multimob-agents To: "Von-Hugo, Dirk" MIME-Version: 1.0 Message-ID: <447491.31864.qm@web84103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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="===============1089812176==" Errors-To: multimob-bounces@ietf.org --===============1089812176== Content-Type: multipart/alternative; boundary="0-1093309007-1192563681=:31864" --0-1093309007-1192563681=:31864 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My comments inline.=0A=0ARegards,=0A=0ABehcet=0A=0A----- Original Message -= ---=0AFrom: "Von-Hugo, Dirk" =0ATo: sarikaya@ieee.= org; multimob@ietf.org=0ASent: Tuesday, October 16, 2007 4:09:18 AM=0ASubje= ct: AW: [multimob] comments on draft-von-hugo-multimob-agents=0A=0A=0A=0A= =0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0ADear Behcet,=0A=0A=0A =0A=0A=0Ayou are righ= t that [9]=0Amainly describes the MLD proxying within the NEMO and I should= have instead=0Apointed to the draft referenced there as [1] where MLD prox= y is introduced (the=0Alater RFC 4605 on 'IGMP/MLD-based Multicast Forwardi= ng ('IGMP/MLD Proxying')=92) =0A=0A=0A=0A>>OK, agreed, maybe [1] is a bette= r reference in this case.=0A=0A=0A=0Abut within [9] already the MR tunnel w= as introduced by saying =0A=0A=0A =91If the mobile=0Anetwork moves to a f= oreign link where multicast is=0A=0A=0A not supported, MR can=0Astill mai= ntain ongoing multicast sessions by=0A=0A=0A performing re-subscription= =0Ato the group, with MLD Report messages,=0A=0A=0A through the MR-HA bi-= directional=0Atunnel. Several approaches can be=0A=0A=0A envisaged for t= he=0Amulticast support on the HA. It can be=0A=0A=0A configured as a=0Am= ulticast router, or simply as an MLD-proxy.=92=0A=0A=0A =0A=0A=0ASorry, DMA= in Fig. 1 is a=0Atypo =96 it should read more generally MAA for Multicast = Anchor Agent (expression=0ADMA for Dynamic Multicast Agent is introduced in= draft-zhang-mipshop-multicast-dma-03.txt).=0A=0A=0AMAA may be a DMA or the= =0AHA or a future AR =96 the decision is made based on criteria as most=0Ae= fficient routing paths or less tree re-construction effort etc.=0A=0A=0A=0A= =0A>>If MR moves to another AR then this is a good time to change MAA. If M= R's rate of change becomes high then change to HA with RS. =0A=0ASo maybe a= more rigid text can be written for the decision algorithm?=0A=0A The probl= em is if MR does not move. Is there a good reason to change MAA?=0A=0A=0A= =0A=0A=0A=0AKind regards=0A=0A=0A=0A=0A=0ADirk =0A=0A=0A-----Urspr=FCnglich= e Nachricht-----=0A=0AVon: Behcet Sarikaya=0A[mailto:behcetsarikaya@yahoo.c= om] =0A=0AGesendet: Dienstag, 16. Oktober=0A2007 01:10=0A=0AAn: von Hugo, D= irk;=0Amultimob@ietf.org=0A=0ABetreff: [multimob] comments on=0Adraft-von-h= ugo-multimob-agents=0A=0A=0A =0A=0A=0A=0A=0A=0A=0AHi=0ADirk,=0A=0A Regardi= ng Reference 9 in your draft, you said:=0A=0ACorresponding multicast traffi= c received at the MAA is subsequently =0A=0A forwarded by the MAA back to= the MR via the bi-directional tunnel.=0A=0A=0A This MLD-proxy functional= ity has been described for the HA as MAA=0Ain =0A=0A [9].=0A=0AHowever, i= n [9], MLD-proxy functionality is defined for routing multicast=0Atraffic i= nside NEMO in case where MNNs are more than one hop away from MR.=0A=0A=0A= =0AIn Fig. 1, you have:=0A=0A | Decision on new MCR=0A(DMA) |=0A= =0Awhat is the difference between an AR and a DMA? Is DMA another AR? How i= s the=0Adecision made?=0A=0A=0A=0ARegards,=0A=0A=0A=0ABehcet=0A=0A=0A=0A=0A= -----=0AOriginal Message ----=0A=0AFrom: "Von-Hugo, Dirk" =0A=0ATo: multimob@ietf.org=0A=0ASent: Monday, October 15, 2007 2:2= 0:37 AM=0A=0ASubject: AW: AW: [multimob] FW: comments on the BOF proposal= =0A=0A=0A=0A=0ADear all,=0A=0A=0A=0A=0A just to inform you that my already = announced draft is now officially available at http://ietfreport.isoc.org/a= ll-ids/draft-von-hugo-multimob-agents-00.txt=0A=0A=0A=0AAgent-based multica= st support for moving networks (NEMO)=0A=0A=0A=0A =0A=0A=0ABest regards=0A= =0A=0ADirk=0A=0A=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A = =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A --0-1093309007-1192563681=:31864 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
My comments inline.

Regards,

Behcet
<= br>
----- Original Message ----
From: "Von-Hugo, Dirk" <Dirk.H= ugo@t-systems.com>
To: sarikaya@ieee.org; multimob@ietf.org
Sent: = Tuesday, October 16, 2007 4:09:18 AM
Subject: AW: [multimob] comments on= draft-von-hugo-multimob-agents

=0A=0A=0A =0A =0A=0A= =0A=0A=0A=0A
=0A=0A

Dear Behcet,

=0A=0A

 

= =0A=0A

you are right that [9]=0Amainly describes the MLD proxying within th= e NEMO and I should have instead=0Apointed to the draft referenced there as= [1] where MLD proxy is introduced (the=0Alater RFC 4605 on 'IGMP/MLD-based= Multicast Forwarding ('IGMP/MLD Proxying')=92)


=

>>OK, agreed, maybe [1] is a better referen= ce in this case.
<= span style=3D"font-size: 10pt; font-family: Arial; color: navy;" lang=3D"EN= -GB">


but within [9] already the M= R tunnel was introduced by saying

=0A=0A

   =91= If the mobile=0Anetwork moves to a foreign link where multicast is

=0A=0A

   not supported, MR can=0Astill maintain ongoing= multicast sessions by

=0A=0A

   performing re-s= ubscription=0Ato the group, with MLD Report messages,

=0A= =0A

   through the MR-HA bi-directional=0Atunnel.  Several a= pproaches can be

=0A=0A

   envisaged for the=0A= multicast support on the HA.  It can be

=0A=0A

 = ;  configured as a=0Amulticast router, or simply as an MLD-proxy.=92

=0A=0A

 

=0A=0A

Sorry, DMA in Fig. 1 = is a=0Atypo =96 it should read more generally MAA for Multicast Anchor Agen= t (expression=0ADMA for Dynamic Multicast Agent is introduced in draft-zhan= g-mipshop-multicast-dma-03.txt).

=0A=0A

MAA may be a DMA o= r the=0AHA or a future AR =96 the decision is made based on criteria as mos= t=0Aefficient routing paths or less tree re-construction effort etc.=

=0A=0A


>>I= f MR moves to another AR then this is a good time to change MAA. If MR's ra= te of change becomes high then change to HA with RS.

=

So maybe a more= rigid text can be written for the decision algorithm?

 The problem is if MR does not move. Is there a good re= ason to change MAA?


=0A=0A=0A=0A

= Kind regards

=0A=0A
=0A=0A

Dirk

=0A=0A

-----Urspr=FCn= gliche Nachricht-----
=0AVon: Behcet Sarikaya=0A[mailto:behcetsarikaya@yahoo.com]
=0AGesendet: Dienstag, 16. Oktober=0A2= 007 01:10
=0AAn: von Hu= go, Dirk;=0Amultimob@ietf.org
=0AB= etreff: [multimob] comments on=0Adraft-von-hugo-multimob-agents<= /span>

=0A=0A

Hi= =0ADirk,
=0A  Regarding Reference 9 in your draft, you said:
=0A= Corresponding multicast traffic received at the MAA is subsequently
=0A=    forwarded by the MAA back to the MR via the bi-directional tun= nel.=0A
=0A   This MLD-proxy functionality has been described = for the HA as MAA=0Ain
=0A   [9].
=0AHowever, in [9], MLD-= proxy functionality is defined for routing multicast=0Atraffic inside NEMO = in case where MNNs are more than one hop away from MR.
=0A
=0AIn Fig.= 1, you have:
=0A     |     = ; Decision on new MCR=0A(DMA)  |
=0Awhat is the difference between = an AR and a DMA? Is DMA another AR? How is the=0Adecision made?
=0A
= =0ARegards,
=0A
=0ABehcet

=0A=0A
=0A=0A

-----=0AOriginal Message ----
=0AFrom: "Von-Hugo, Dirk" <D= irk.Hugo@t-systems.com>
=0ATo: multimob@ietf.org
=0ASent: Monday, = October 15, 2007 2:20:37 AM
=0ASubject: AW: AW: [multimob] FW: comments = on the BOF proposal

=0A=0A
=0A=0A

Dear all,

=0A=0A
=0A=0A
 
just to inform you that my alread=
y announced draft is now officially available at http://ietfreport.iso=
c.org/all-ids/draft-von-hugo-multimob-agents-00.txt
=0A
=0AAgent-based multicast support for moving networks (NE=
MO)
=0A=0A
=0A=0A

 

=0A=0A

Best regards

=0A=0A

Dirk

=0A= =0A

 

=0A=0A
=0A=0A
=0A= =0A
=0A=0A
=0A=0A
=0A=0A

 

=0A=0A
=0A=0A
=0A=0A=0A=0A

--0-1093309007-1192563681=:31864-- --===============1089812176== 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 --===============1089812176==-- From multimob-bounces@ietf.org Wed Oct 17 08:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8Nr-0005OA-Mp; Wed, 17 Oct 2007 08:52:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8Nq-0005Nj-2y for multimob@ietf.org; Wed, 17 Oct 2007 08:52:22 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8Np-00040G-91 for multimob@ietf.org; Wed, 17 Oct 2007 08:52:22 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 17 Oct 2007 14:52:10 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 14:52:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents Date: Wed, 17 Oct 2007 14:52:09 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A401623312@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <447491.31864.qm@web84103.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [multimob] comments on draft-von-hugo-multimob-agents Thread-Index: AcgQLLTokhqPs6j/T2u7gpp620pcDQAjpWVg From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 17 Oct 2007 12:52:09.0946 (UTC) FILETIME=[87DE7BA0:01C810BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 320ddee61cb2d39f489e9191ae3fdc8c 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="===============1084998891==" Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1084998891== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C810BC.8786178B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C810BC.8786178B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline Sincerely =20 Dirk =20 -----Urspr=FCngliche Nachricht----- Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Gesendet: Dienstag, 16. Oktober 2007 21:41 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: AW: [multimob] comments on draft-von-hugo-multimob-agents =20 My comments inline. Regards, Behcet ----- Original Message ---- From: "Von-Hugo, Dirk" To: sarikaya@ieee.org; multimob@ietf.org Sent: Tuesday, October 16, 2007 4:09:18 AM Subject: AW: [multimob] comments on draft-von-hugo-multimob-agents Dear Behcet, =20 you are right that [9] mainly describes the MLD proxying within the NEMO = and I should have instead pointed to the draft referenced there as [1] = where MLD proxy is introduced (the later RFC 4605 on 'IGMP/MLD-based = Multicast Forwarding ('IGMP/MLD Proxying')')=20 =20 >>OK, agreed, maybe [1] is a better reference in this case. DH: I will change this in version 01=20 =20 but within [9] already the MR tunnel was introduced by saying=20 'If the mobile network moves to a foreign link where multicast is not supported, MR can still maintain ongoing multicast sessions by performing re-subscription to the group, with MLD Report messages, through the MR-HA bi-directional tunnel. Several approaches can be envisaged for the multicast support on the HA. It can be configured as a multicast router, or simply as an MLD-proxy.' =20 Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for = Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is = introduced in draft-zhang-mipshop-multicast-dma-03.txt). MAA may be a DMA or the HA or a future AR - the decision is made based = on criteria as most efficient routing paths or less tree re-construction = effort etc. =20 >>If MR moves to another AR then this is a good time to change MAA. If = MR's rate of change becomes high then change to HA with RS.=20 DH: It depends - changing to a new MAA after each move to a new AR = should be avoided. E.g. in case the new AR is only a few hops away from = the old a tunnel between old AR as MAA and the MR via the new AR may be = more efficient, especially if there are other subscribers to same MC = groups present at old AR.=20 =20 So maybe a more rigid text can be written for the decision algorithm? =20 The problem is if MR does not move. Is there a good reason to change = MAA? DH: Similarly - if all other subscribers at the current AR move to a new = one it may be more efficient also fort he static MR to change MAA to = that new AR - because of the plurality of subscriptions. =20 DH: However I have to admit that we had in mind also MC transmissions = from the MR, where a tree update means much more effort - for pure MC = listeners this may no more hold true. =20 =20 Kind regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Gesendet: Dienstag, 16. Oktober 2007 01:10 An: von Hugo, Dirk; multimob@ietf.org Betreff: [multimob] comments on draft-von-hugo-multimob-agents =20 Hi Dirk, Regarding Reference 9 in your draft, you said: Corresponding multicast traffic received at the MAA is subsequently=20 forwarded by the MAA back to the MR via the bi-directional tunnel.=20 This MLD-proxy functionality has been described for the HA as MAA in=20 [9]. However, in [9], MLD-proxy functionality is defined for routing = multicast traffic inside NEMO in case where MNNs are more than one hop = away from MR. In Fig. 1, you have: | Decision on new MCR (DMA) | what is the difference between an AR and a DMA? Is DMA another AR? How = is the decision made? Regards, Behcet ----- Original Message ---- From: "Von-Hugo, Dirk" To: multimob@ietf.org Sent: Monday, October 15, 2007 2:20:37 AM Subject: AW: AW: [multimob] FW: comments on the BOF proposal Dear all, =20 just to inform you that my already announced draft is now officially = available at = http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt = =20 Agent-based multicast support for moving networks (NEMO) =20 Best regards Dirk =20 =20 =20 ------_=_NextPart_001_01C810BC.8786178B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please see inline

Sincerely

 

Dirk

 

-----Urspr=FCngliche = Nachricht-----
Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Gesendet: Dienstag, 16. = Oktober 2007 21:41
An: von Hugo, Dirk
Cc: multimob@ietf.org
Betreff: Re: AW: = [multimob] comments on draft-von-hugo-multimob-agents

 

My comments inline.

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <Dirk.Hugo@t-systems.com>
To: sarikaya@ieee.org; multimob@ietf.org
Sent: Tuesday, October 16, 2007 4:09:18 AM
Subject: AW: [multimob] comments on = draft-von-hugo-multimob-agents

Dear Behcet,

 

you are right that [9] mainly describes the MLD proxying = within the NEMO and I should have instead pointed to the draft referenced there as = [1] where MLD proxy is introduced (the later RFC 4605 on 'IGMP/MLD-based = Multicast Forwarding ('IGMP/MLD Proxying')’)

 

>>OK, agreed, maybe [1] is a better reference in this = case.

DH: I will = change this in version 01

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

but within [9] already the MR tunnel was introduced by = saying

   ‘If the mobile network moves to a foreign = link where multicast is

   not supported, MR can still maintain ongoing = multicast sessions by

   performing re-subscription to the group, with = MLD Report messages,

   through the MR-HA bi-directional tunnel.  = Several approaches can be

   envisaged for the multicast support on the = HA.  It can be

   configured as a multicast router, or simply as = an MLD-proxy.’

 

Sorry, DMA in Fig. 1 is a typo – it should read more generally MAA for Multicast Anchor Agent (expression DMA for Dynamic = Multicast Agent is introduced in = draft-zhang-mipshop-multicast-dma-03.txt).

MAA may be a DMA or the HA or a future AR – the = decision is made based on criteria as most efficient routing paths or less tree re-construction effort etc.

 

>>If MR moves to another AR then = this is a good time to change MAA. If MR's rate of change becomes high then = change to HA with RS.

= DH: It depends – changing to a new MAA after each move to a new AR should = be avoided. E.g. in case the new AR is only a few hops away from the old a = tunnel between old AR=A0 as MAA and the MR via the new AR may be more efficient, = especially if there are other subscribers to same MC groups present at old AR. =

=  

So maybe a more rigid text can be = written for the decision algorithm?

 

 The problem is if MR does not move. Is there a good reason to = change MAA?

DH: Similarly = – if all other subscribers at the current AR move to a new one it may be more = efficient also fort he static MR to change MAA to that new AR – because of = the plurality of subscriptions.

 

DH: However I = have to admit that we had in mind also MC transmissions from the MR, where a tree = update means much more effort – for pure MC listeners this may no more hold = true. =A0

 

Kind regards

Dirk

-----Urspr=FCngliche = Nachricht-----
Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Gesendet: Dienstag, 16. = Oktober 2007 01:10
An: von Hugo, Dirk; multimob@ietf.org
Betreff: [multimob] = comments on draft-von-hugo-multimob-agents

 

Hi Dirk,
  Regarding Reference 9 in your draft, you said:
Corresponding multicast traffic received at the MAA is subsequently
   forwarded by the MAA back to the MR via the bi-directional = tunnel.
   This MLD-proxy functionality has been described for the HA = as MAA in
   [9].
However, in [9], MLD-proxy functionality is defined for routing = multicast traffic inside NEMO in case where MNNs are more than one hop away from = MR.

In Fig. 1, you have:
     |      Decision on new = MCR (DMA)  |
what is the difference between an AR and a DMA? Is DMA another AR? How = is the decision made?

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <Dirk.Hugo@t-systems.com>
To: multimob@ietf.org
Sent: Monday, October 15, 2007 2:20:37 AM
Subject: AW: AW: [multimob] FW: comments on the BOF = proposal

Dear all,

 
just to inform =
you that my already announced draft is now officially available at =
http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-a=
gents-00.txt









Agent-based multicast support for moving =
networks (NEMO)

 

Best regards

Dirk

 

 

 

------_=_NextPart_001_01C810BC.8786178B-- --===============1084998891== 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 --===============1084998891==-- From multimob-bounces@ietf.org Thu Oct 18 07:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiTWT-0002Hm-DB; Thu, 18 Oct 2007 07:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiTWS-00027g-5o for multimob@ietf.org; Thu, 18 Oct 2007 07:26:40 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiTWJ-0003yV-PF for multimob@ietf.org; Thu, 18 Oct 2007 07:26:37 -0400 Received: from e178153244.adsl.alicedsl.de ([85.178.153.244] helo=mw-thinkpad) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42 (FreeBSD)) id 1IiTWX-00049n-Bz; Thu, 18 Oct 2007 13:26:45 +0200 Date: Thu, 18 Oct 2007 13:26:22 +0200 From: Matthias Waehlisch To: "Von-Hugo, Dirk" Subject: Re: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents In-Reply-To: <1B309B6DC3B05440ACC14187BCB308A401623312@S4DE8PSAAGM.mitte.t-com.de> Message-ID: References: <1B309B6DC3B05440ACC14187BCB308A401623312@S4DE8PSAAGM.mitte.t-com.de> X-X-Sender: mw@mail1.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Hi Dirk, some quick comments on your draft: In the abstract you mentioned, that the draft "describes an approach to support mobile IPv6 multicast listeners and senders located within a moving network (NEMO)." Why have to be the senders and listeners MIPv6 aware? As far as I understand, your suggestion does not require this assumption. You are not looking at dedicated moving nodes, you are looking at the network. In section 2.1 is said, that "Advantage of this approach is that the access network infrastructure is less affected by required update of functionality." Can you elaborate that? On Wed, 17 Oct 2007, Von-Hugo, Dirk wrote: > Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for > Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is > introduced in draft-zhang-mipshop-multicast-dma-03.txt). > Than you have to remove NEMO-HA and AR, because they can also be a MAA. Nevertheless I don't understand in detail the meaning of figure 1. You want to sketch the message flow between NEMO-MR and MAA. I think that the transition from HA to another MAA is sufficient, as every other change of decision should show the same. Btw: You should not send a "MLD done", if you refer to MLDv2. It's just for backward compatiblity. And you should introduce MCR, which means probably Multicast router... Why does the NEMO-MR send a MLD query to the DMA/MAA? And the last question: How does the NEMO-MR know to switch sending multicast data from, e.g. in fig. 1, NEMO-HA to AR? It's not obviously uninterruptible. Cheers matthias -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/‾mw :. http://www.link-lab.net _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 18 10:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWGH-0002mQ-5c; Thu, 18 Oct 2007 10:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiWGE-0002lC-RQ for multimob@ietf.org; Thu, 18 Oct 2007 10:22:06 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiWG8-0003VN-CK for multimob@ietf.org; Thu, 18 Oct 2007 10:22:06 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 18 Oct 2007 16:21:41 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Oct 2007 16:21:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents Date: Thu, 18 Oct 2007 16:21:40 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A401623317@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents Thread-Index: AcgRefKwXJ0gTbTtRMGxdf/tvlmjRAAFJKAA From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 18 Oct 2007 14:21:41.0371 (UTC) FILETIME=[33E6A4B0:01C81192] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Dear Matthias, thank you for the comments. See my responses inline - hope that = clarifies: Kind regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Matthias Waehlisch [mailto:mw@link-lab.net]=20 Gesendet: Donnerstag, 18. Oktober 2007 13:26 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: AW: AW: [multimob] comments on = draft-von-hugo-multimob-agents Hi Dirk, some quick comments on your draft: In the abstract you mentioned, that the draft "describes an approach = to=20 support mobile IPv6 multicast listeners and senders located within a=20 moving network (NEMO)." Why have to be the senders and listeners MIPv6=20 aware? As far as I understand, your suggestion does not require this=20 assumption. You are not looking at dedicated moving nodes, you are = looking=20 at the network. DH: you are right - I should have said "describes an approach to support multicast listeners and senders = located within a moving IPv6 network (NEMO)." In section 2.1 is said, that "Advantage of this approach is that the=20 access network infrastructure is less affected by required update of=20 functionality." Can you elaborate that? DH: The idea is to bind this mobile multicast feature to the MR = functionality instead of the need to update every AR in any network with = the intelligence to decide on best suited MAA. That is the approach = followed in draft-zhang-mipshop-multicast-dma-03.txt. =20 On Wed, 17 Oct 2007, Von-Hugo, Dirk wrote: > Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for = > Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is=20 > introduced in draft-zhang-mipshop-multicast-dma-03.txt). >=20 Than you have to remove NEMO-HA and AR, because they can also be a = MAA.=20 Nevertheless I don't understand in detail the meaning of figure 1. DH: Exactly - or I may remove MAA completely from the figure which = should visualise potential MAA changes during MR movement and say in an = explanatory text that MAA functionality will change between NEMO-HA and = AR and any other properly suited entity. You want to sketch the message flow between NEMO-MR and MAA. I think=20 that the transition from HA to another MAA is sufficient, as every other = change of decision should show the same. Btw: You should not send a "MLD = done", if you refer to MLDv2. It's just for backward compatiblity. And = you=20 should introduce MCR, which means probably Multicast router... Why does=20 the NEMO-MR send a MLD query to the DMA/MAA? DH: I'll check this and introduce the acronym. MLD query is used to = learn about current subscription status at potential MAA to re-use = existing Multicast subscriptions and to derive the distance between MR = and MAA for decision on best suited MAA. And the last question: How does the NEMO-MR know to switch sending=20 multicast data from, e.g. in fig. 1, NEMO-HA to AR? It's not obviously=20 uninterruptible. DH: I hope I understood the questions correctly: In case the MR does not = move for a long enough time period (e.g. when a train stops at the = station) it decides to switch to AR as MAA to follow remote subscription = mode because then routing is optimised. Of course in this case the old = multicast tree with NEMO-HA as root has to be re-constructed and = replaced by a new tree with AR as root. Advantage of the switch has to = exceed the disadvantage due to potential data loss and time delay during = this process. That is a challenge which still has to be solved ...=20 Cheers matthias =20 -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 = Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, = mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/‾mw :. http://www.link-lab.net _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 19 06:42:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipJT-0007kv-3L; Fri, 19 Oct 2007 06:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IipJR-0007Xp-2N for multimob@ietf.org; Fri, 19 Oct 2007 06:42:41 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IipJI-0001B4-Rk for multimob@ietf.org; Fri, 19 Oct 2007 06:42:39 -0400 Received: from e178180009.adsl.alicedsl.de ([85.178.180.9] helo=mw-thinkpad) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42 (FreeBSD)) id 1IipJT-000BaS-Cb; Fri, 19 Oct 2007 12:42:43 +0200 Date: Fri, 19 Oct 2007 12:42:21 +0200 From: Matthias Waehlisch To: "Von-Hugo, Dirk" Subject: Re: AW: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents In-Reply-To: <1B309B6DC3B05440ACC14187BCB308A401623317@S4DE8PSAAGM.mitte.t-com.de> Message-ID: References: <1B309B6DC3B05440ACC14187BCB308A401623317@S4DE8PSAAGM.mitte.t-com.de> X-X-Sender: mw@mail1.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.7 (+) 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 Hi Dirk, On Thu, 18 Oct 2007, Von-Hugo, Dirk wrote: > You want to sketch the message flow between NEMO-MR and MAA. I think > that the transition from HA to another MAA is sufficient, as every other > change of decision should show the same. Btw: You should not send a "MLD > done", if you refer to MLDv2. It's just for backward compatiblity. And > you should introduce MCR, which means probably Multicast router... Why > does the NEMO-MR send a MLD query to the DMA/MAA? > > DH: I'll check this and introduce the acronym. MLD query is used to > learn about current subscription status at potential MAA to re-use > existing Multicast subscriptions and to derive the distance between MR > and MAA for decision on best suited MAA. > Yes, but maybe you can write something in the draft about the tradeoff between distance, subscription state and handover rate. You should also explain, why the MR does not send a MLD query to the AR in the figure. Cheers matthias -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/‾mw :. http://www.link-lab.net _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Oct 23 11:31:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLi8-0007X0-BL; Tue, 23 Oct 2007 11:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLi6-0007Th-0z for multimob@ietf.org; Tue, 23 Oct 2007 11:30:26 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkLhy-00063k-LD for multimob@ietf.org; Tue, 23 Oct 2007 11:30:26 -0400 Received: by an-out-0708.google.com with SMTP id c5so478720anc for ; Tue, 23 Oct 2007 08:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=4TM11nE/+GsNZRjytRcdg035ClM6slQK2V5AkIHyKrk=; b=IrBRJvJZoL++V848rAkyY8MSdvyoI8076xFkQ/h4M/dmPTGO6HdqgTSfORR1Tq9QjwDE4/AZi63LDGO++Ontb9TZAXSc12wgzb279Xj/q9FMpVaMs01C7eKWji565k7mRaj5ZbhU2OeTKVeUFwYfgCpSMDoZIwQJQ9KM/vPfPac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iR+flYujGYre/mQbqmdcRVlMUQCDKrb8OA30SpgaSQ+BrA7YVkEmyMa1PaH0XSebgFX96xRRiUty/BYNCtzXwmp0ASrX10mIxG/mKh9AMYAdno+KXCojvSLD33U/6/MBNRVIiER9IFS5IXgbo9CVvuJMSAlaeoU0i14lPtFZgBE= Received: by 10.142.242.8 with SMTP id p8mr1968278wfh.1193153388490; Tue, 23 Oct 2007 08:29:48 -0700 (PDT) Received: by 10.143.166.2 with HTTP; Tue, 23 Oct 2007 08:29:48 -0700 (PDT) Message-ID: <1d38a3350710230829s3aaabd1ag8133af5aadf42661@mail.gmail.com> Date: Tue, 23 Oct 2007 23:29:48 +0800 From: "Hui Deng" To: multimob@ietf.org, "denghui@chinamobile.com" Subject: Re: [multimob] implementations and deployments? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 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 We are interested in both Mobile multicast related issue and mobile ip related multicast which could support mobile IPTV, we will write the follow-up ID soon. thanks -Hui (China Mobile) Hi, Who are the people interested in this effort? Are they researchers or people planning to deploy this technology in some network? Are there implementations, if so on what platforms? Are there deployment plans? Which of the big mobile networks that we have today (say, 3GPP, 3GPP2, Wimax) are planning to employ a multicast mobility feature (at L3) in their future networks? Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 25 09:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2le-0006ge-2N; Thu, 25 Oct 2007 09:28:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2lc-0006gY-Vg for multimob@ietf.org; Thu, 25 Oct 2007 09:28:57 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2lc-0006jw-DZ for multimob@ietf.org; Thu, 25 Oct 2007 09:28:56 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 15:28:54 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 15:28:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents Date: Thu, 25 Oct 2007 15:28:52 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A401623333@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents Thread-Index: AcgSPMJDgJOCB0+GS/SBGBRcKDpD4wEzfgDg From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 25 Oct 2007 13:28:53.0142 (UTC) FILETIME=[FC618360:01C8170A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: bsarikaya@huawei.com, 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 Dear all, today I have submitted an update of the draft incorporating most of your = issues - I hope. As I will be out of office the next 3 weeks I surely will not be able to = work on this topic until IETF-70 deadline. Until it is published officially you may find version 01 at = http://www3.ietf.org/proceedings/staging/draft-von-hugo-multimob-agents-0= 1.txt=20 Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Matthias Waehlisch [mailto:mw@link-lab.net]=20 Gesendet: Freitag, 19. Oktober 2007 12:42 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: AW: AW: AW: [multimob] comments on = draft-von-hugo-multimob-agents Hi Dirk, On Thu, 18 Oct 2007, Von-Hugo, Dirk wrote: > You want to sketch the message flow between NEMO-MR and MAA. I think = > that the transition from HA to another MAA is sufficient, as every = other=20 > change of decision should show the same. Btw: You should not send a = "MLD=20 > done", if you refer to MLDv2. It's just for backward compatiblity. And = > you should introduce MCR, which means probably Multicast router... Why = > does the NEMO-MR send a MLD query to the DMA/MAA? >=20 > DH: I'll check this and introduce the acronym. MLD query is used to=20 > learn about current subscription status at potential MAA to re-use=20 > existing Multicast subscriptions and to derive the distance between MR = > and MAA for decision on best suited MAA. >=20 Yes, but maybe you can write something in the draft about the tradeoff = between distance, subscription state and handover rate. You should also=20 explain, why the MR does not send a MLD query to the AR in the figure. Cheers matthias =20 -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. = link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 = Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, = mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/‾mw :. http://www.link-lab.net _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 25 09:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2rH-0003K6-Ec; Thu, 25 Oct 2007 09:34:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2rF-0003JY-ID for multimob@ietf.org; Thu, 25 Oct 2007 09:34:45 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2rF-0006ru-10 for multimob@ietf.org; Thu, 25 Oct 2007 09:34:45 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP for multimob@ietf.org; Thu, 25 Oct 2007 15:34:43 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 15:34:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Oct 2007 15:34:43 +0200 Message-Id: <1B309B6DC3B05440ACC14187BCB308A401623334@S4DE8PSAAGM.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-von-hugo-multimob-agents-01 Thread-Index: AcgXC4WTeVdr0HngRtC727D+VhM7FAAAGg8A From: "Von-Hugo, Dirk" To: X-OriginalArrivalTime: 25 Oct 2007 13:34:43.0439 (UTC) FILETIME=[CD2C97F0:01C8170B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [multimob] WG: New Version Notification for draft-von-hugo-multimob-agents-01 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 Dear all, FYI Thanks Dirk=20 A new version of I-D, draft-von-hugo-multimob-agents-01.txt has been successfuly submitted by Dirk von Hugo and posted to the IETF repository. Filename: draft-von-hugo-multimob-agents Revision: 01 Title: Agent-based multicast support for moving networks (NEMO) Creation_date: 2007-10-25 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document describes an approach to support multicast listeners and=20 senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile=20 Network Nodes (MNNs). The MR handles all routing related tasks to=20 provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also=20 subscribes to multicast groups and forwards emerging multicast traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the=20 multicast tree. In the MR a corresponding functionality is defined=20 which decides on the location of the specific agent to be used for a=20 distinct multicast traffic. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119 [1]. =20 The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 26 13:09:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSey-0006PP-Vz; Fri, 26 Oct 2007 13:07:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlSex-0006NG-83 for multimob@ietf.org; Fri, 26 Oct 2007 13:07:47 -0400 Received: from web84109.mail.mud.yahoo.com ([68.142.206.196]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IlSew-0000q9-JY for multimob@ietf.org; Fri, 26 Oct 2007 13:07:47 -0400 Received: (qmail 56223 invoked by uid 60001); 26 Oct 2007 17:07:46 -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=P/NQprbMx8HVUISXJhl+fbviK9U3/ABbhlkBjMGwieXdlGT4jd6SYCMNrAmEwldQxWKz0qVoO8cqwPPmq+jsupRVKTtWD9EotDqQOVkAYuSpkJCApsSwheiFqVkggbtdORE/KB9iJR+5/sND+qDfuipQet8SRB2lEpZTT1isc/o=; X-YMail-OSG: VsinNq4VM1mZ3PdhEjx4vwQzjpxdE6gNwoIyfLOwUoM_sEIm1IR998qBQfjfjG.fwc3o7YhP6YVzcacSYQm8GHcWsS.ijxFJFaFR52TeGWq7_n2m8y8- Received: from [206.16.17.212] by web84109.mail.mud.yahoo.com via HTTP; Fri, 26 Oct 2007 10:07:45 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134.12 Date: Fri, 26 Oct 2007 10:07:45 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <964132.54506.qm@web84109.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [multimob] draft-von-hugo-multimob-agents-01 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="===============0450313855==" Errors-To: multimob-bounces@ietf.org --===============0450313855== Content-Type: multipart/alternative; boundary="0-1400000034-1193418465=:54506" --0-1400000034-1193418465=:54506 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dirk's new draft is at =0Ahttp://www.ietf.org/internet-drafts/draft-von-hug= o-multimob-agents-01.txt=0A=0ARegards,=0A=0ABehcet=0A=0A----- Original Mess= age ----=0AFrom: "Von-Hugo, Dirk" =0ATo: multimob@= ietf.org=0ASent: Thursday, October 25, 2007 8:34:43 AM=0ASubject: [multimob= ] WG: New Version Notification for draft-von-hugo-multimob-agents-01 =0A=0A= Dear all,=0AFYI=0AThanks=0ADirk =0A=0A=0AA new version of I-D, draft-von-hu= go-multimob-agents-01.txt has been=0Asuccessfuly submitted by Dirk von Hugo= and posted to the IETF=0Arepository.=0A=0AFilename: draft-von-hugo-mul= timob-agents=0ARevision: 01=0ATitle: Agent-based multicast supp= ort for moving networks=0A(NEMO)=0ACreation_date: 2007-10-25=0AWG ID: = Independent Submission=0ANumber_of_pages: 11=0A=0AAbstract:=0AThis d= ocument describes an approach to support multicast listeners and =0Asenders= located within a moving IPv6 network (NEMO). A NEMO=0Ais built up by at le= ast one Mobile Router (MR) and a set of Mobile =0ANetwork Nodes (MNNs). Th= e MR handles all routing related tasks to =0Aprovide connectivity between t= he MNNs and an access network=0A=0Aincluding mobility management. Correspo= ndingly the MR also =0Asubscribes to multicast groups and forwards emerging= multicast=0A traffic on behalf of a MNN.=0AFor optimised routing of multic= ast data a hierarchical multicast=0A=0Aagent is introduced as a logical ent= ity providing an anchor to the =0Amulticast tree. In the MR a correspondin= g functionality is defined =0Awhich decides on the location of the specific= agent to be used for a =0Adistinct multicast traffic.=0A=0A=0AConventions = used in this document=0AThe key words "MUST", "MUST NOT", "REQUIRED", "SHAL= L", "SHALL NOT", =0A"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTI= ONAL" in this =0Adocument are to be interpreted as described in RFC-2119 [1= ].=0A =0A=0A=0A=0AThe IETF Secretariat.=0A=0A=0A=0A________________________= _______________________=0Amultimob mailing list=0Amultimob@ietf.org=0Ahttps= ://www1.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A=0A --0-1400000034-1193418465=:54506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Dirk's new draft is at
http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-agents-= 01.txt

Regards,

Behcet

----- Origin= al Message ----
From: "Von-Hugo, Dirk" <Dirk.Hugo@t-systems.com>To: multimob@ietf.org
Sent: Thursday, October 25, 2007 8:34:43 AM
S= ubject: [multimob] WG: New Version Notification for draft-von-hugo-multimob= -agents-01

Dear all,
FYI
Thanks
Dirk


A ne= w version of I-D, draft-von-hugo-multimob-agents-01.txt has been
success= fuly submitted by Dirk von Hugo and posted to the IETF
repository.

Fi= lename:     draft-von-hugo-multimob-agents
Revision:=      01
Title:      &n= bsp;  Agent-based multicast support for moving networks
(NEMO)
C= reation_date:     2007-10-25
WG ID:   = ;      Independent Submission
Number_of_pages: = 11

Abstract:
This document describes an approach to support multi= cast listeners and
senders located within a moving IPv6 network (NEMO).= A NEMO
is built up by at least one Mobile Router (MR) and a set of Mobi= le
Network Nodes (MNNs).  The MR handles all routing related = tasks to
provide connectivity between the MNNs and an access network
including mobility management.  Correspondingly the MR also =
subscribes to multicast groups and forwards emerging multicast
traffic on behalf of a MNN.
For optimised routing of mult= icast data a hierarchical multicast

agent is introduced as a logical= entity providing an anchor to the
multicast tree.  In the MR= a corresponding functionality is defined
which decides on the location= of the specific agent to be used for a
distinct multicast traffic.
=

Conventions used in this document
The key words "MUST", "MUST NO= T", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
document are to be interpreted as d= escribed in RFC-2119 [1].




The IETF Secretariat.

=

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

--0-1400000034-1193418465=:54506-- --===============0450313855== 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 --===============0450313855==-- From multimob-bounces@ietf.org Tue Oct 30 18:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImzND-0001FQ-SN; Tue, 30 Oct 2007 18:15:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImzNC-0001FD-Cl for multimob@ietf.org; Tue, 30 Oct 2007 18:15:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImzNC-0005Fa-0b for multimob@ietf.org; Tue, 30 Oct 2007 18:15:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5D695198677; Wed, 31 Oct 2007 00:15:45 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0D9DA198676; Wed, 31 Oct 2007 00:15:45 +0200 (EET) Message-ID: <4727AD10.2050005@piuha.net> Date: Wed, 31 Oct 2007 00:15:44 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Rajeev Koodli Subject: [multimob] Multicast mobility discussions in Vancouver 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 Hi all, We have gone through our BOF proposals and decided what to do about each one. You will have time to talk about multicast mobility in Vancouver. However, I did not grant a separate BOF slot for this. I have asked Rajeev Koodli to arrange a discussion in the MOBOPTS RG, and to have the RG eventually provide a recommendation on what work in this space appears stable enough to proceed to standardization. Rajeev promised to do this (thanks!) and he indicated that we are talking about ‾ 1 hour of meeting time devoted to this. Please work with Rajeev on the details, work on drafts, continue discussion on what should be standardized in this space, etc. Once the RG delivers this recommendation I feel more comfortable about chartering BOFs/WGs on this topic. Also, I would like to receive more information on the potential deployment interest for this technology. For instance, are any of the IPTV or mobile TV related efforts employing multicast over IP layer mobility, and what do the relevant providers/vendors/consortiums need? What are their priorities among the different possible work items? Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob