Subject: [multimob] Fw: WG Action: Mobility Multicast (multimob)

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 9 Sep 2009 13:55:34 -0700 (PDT)

Hello all,

  We look forward to working with Multimob folks.
Profiting the occasion, we thank previous co-chairs
Suresh Krishnan
Brian Haberman and
Gorry Fairhurst

for their contributions towards the formation of the WG.

Regards,

Stig & Behcet

----- Forwarded Message ----
> From: IESG Secretary <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Sent: Wednesday, September 9, 2009 2:30:01 PM
> Subject: WG Action: Mobility Multicast (multimob) 
> 
> A new IETF working group has been formed in the Internet Area.  For
> additional information, please contact the Area Directors or the WG
> Chairs.
> 
> Mobility Multicast (multimob)
> ---------------------------------------------------
> Current Status: Active Working Group
> 
> Chairs:
> 
> Stig Venaas 
> Bechet Sarikaya < [email-masked]>
> 
> Internet Area Directors:
> 
> Jari Arkko 
> Ralph Droms 
> 
> Internet Area Advisor:
> Jari Arkko 
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/multimob
> Archive:
> http://www.ietf.org/mail-archive/web/multimob/current/maillist.html
> 
> Description of Working Group:
> 
> The Multicast mobility (multimob) working group provides guidance for
> supporting multicast in a mobile environment. The scope of work will
> be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener
> mobility. Work requiring modifications to mobility protocols and
> IGMPv3/MLDv2 is out of scope in this first stage of this working group.
> Modifications to multicast routing protocols are out of scope.
> 
> Specific goals for the group are:
> - Document how multicast can be supported in a Proxy Mobile IPv6
> environment
> - Document the configuration of IGMPv3/MLDv2 in mobile environments
> 
> The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213
> does not describe how to support multicast. Some forms of multicast
> support can, however, be built in the involved nodes by using existing
> capabilities of multicast protocols and the underlying mobility
> protocols. The first task of the working group is to document such
> solutions for PMIPv6. This work will not require any additions or
> changes to message types and parameters specified in RFC 5213, and
> must assume an unmodified mobile host. The work will employ the remote
> subscription model. This is a mechanism by which a mobile node joins a
> multicast group and receives multicast data forwarded via the local
> mobility anchor.
> 
> IGMPv3/MLDv2 has been specified for wired networks with shared links.
> Mobile nodes have needs that are specific to wireless networks and
> mobility (e.g. entering a dormant mode to conserve battery power,
> minimizing the latency for joining and leaving a group in support of
> movement).
> 
> The second task of the WG is to assess existing solutions for group
> management, and determine to what extent these methods are sufficient
> in a mobile environment. This will include recommending appropriate
> selection of timer values and protocol parameters.
> 
> In performing its work, the working group will work closely with both
> the mobility community (NETLMM and NETEXT WGs) and the multicast
> community (MBONED WG). The group will consider both source specific
> multicast and any source multicast multicast models.
> 
> Future work, subject to rechartering, may study/evaluate extensions to
> support PMIPv6 optimizations to address the avalanche problem and fast
> handover and extensions to IGMPv3/MLDv2 to support better operation in
> mobile environments.
> 
> Goals and Milestones:
> 
> Nov 2009 Initial version of a document explaining the use of multicast
> in PMIPv6
> Nov 2009 Initial version of a document on how to tune IGMPv3/MLDv2 for
> mobility
> Apr 2010 Submit a document explaining the use of multicast in PMIPv6,
> for publication as either Informational or Best Current Practice
> Apr 2010 Submit a document on how to tune IGMPv3/MLDv2 for mobility,
> for publication as either Informational or Best Current Practice
> Jun 2010 Decision to include additional optimization work involving
> extensions to PMIPv6
> Jun 2010 Decision to include additional optimization work involving
> extensions to IGMPv3 or MLDv2
> Jun 2010 Recharter based on the above decisions (or close the group if
> no new work is needed)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Sep 2009 14:05:09 -0700

Hi all

> for their contributions towards the formation of the WG.

Most of you probably have no idea who I am. I will now be
chairing this group together with Behcet. While I have not
been visible, I have been following the previous work and
appreciate the efforts the people above, Behcet and the
rest of you already have made.

My background is mainly multicast. I have been working on
multicast for years, and it is also what I mostly do as a
day job. I now work for Cisco, while until a few months ago
I've been more in the academic world.

I look forward to working with you all, and our first meeting
as a wg.

Stig

---

From: <[email-masked]>
Date: Thu, 10 Sep 2009 18:28:57 +0200

Hi Stig and Behcet,
Welcome and congratulations to successful WG approval and election as chair! I really appreciate your experience in multicast and moble environments, respectively ...  And expect some good progress we will thus make for the official start in Hiroshima.
As I understand from the charter we should now focus on improving the existing drafts for WG approval as version 00 in November, right?

So we have to decide which of the existing solution drafts to merge and adapt to achieve those documents ... My personal impression is that while for a 'document explaining the use of multicast in PMIPv6' we have several existing proposals available, for the second one dealing with 'how to tune IGMPv3/MLDv2 for Mobility' there are only the following ones, or did I miss something?
http://www.ietf.org/internet-drafts/draft-asaeda-multimob-igmp-mld-optimization-00.txt 
http://www.ietf.org/internet-drafts/draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt 

Thanks and best regards

Viele Grüße,
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Stig Venaas
Gesendet: Mittwoch, 9. September 2009 23:05
An: Behcet Sarikaya
Cc: [email-masked]
Betreff: Re: [multimob] Fw: WG Action: Mobility Multicast (multimob)

Hi all

Stig

> Stig & Behcet
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 11 Sep 2009 01:45:45 +0900 (JST)

Hi Dirk,

> So we have to decide which of the existing solution drafts to merge
> and adapt to achieve those documents ... My personal impression is
> that while for a 'document explaining the use of multicast in
> PMIPv6' we have several existing proposals available, for the second
> one dealing with 'how to tune IGMPv3/MLDv2 for Mobility' there are
> only the following ones, or did I miss something?

The former one describes how to tune IGMPv3/MLDv2 for mobility and
does not propose any protocol extension/modfication.
The latter one describes IGMPv3/MLDv2 protocol extensions for fast
packet forwarding after handover.
Hence, only the former one is the target for the current charter.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 10 Sep 2009 19:07:47 +0200

Hi Dirk & all,

> As I understand from the charter we should now focus on improving the existing drafts for WG approval as version 00 in November, right?

I guess we should: charter enforces a very tight schedule.

> So we have to decide which of the existing solution drafts to merge and adapt to achieve those documents ... My personal impression is that while for a 'document explaining the use of multicast in PMIPv6' we have several existing proposals available, 

 From my knowledge of numerous existing PMIPv6 Multicast drafts, there 
is only one that deploys multicast without protocol modifications:
http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment-01

The document has already received a number of substantial reviews that 
are accounted for in the current version.

As we will prepare a major update prior to Hiroshima, we very much 
encourage further comments and reviews. We are urged for a fast 
convergence process.

Best regards,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Sep 2009 10:24:25 -0700

Thomas C. Schmidt wrote:
>> As I understand from the charter we should now focus on improving the 
>> existing drafts for WG approval as version 00 in November, right?
>>
> 

Indeed the schedule is really tight, so that should be the goal. It
might even be good to get a couple of rounds of updates of the drafts
before our meeting if possible.

If you plan to update the drafts, please publish a new revision of
the drafts as soon as you can (but not as wg drafts yet). Then
ideally we can get another round of comments and updates before the
meeting.

This of course also requires the rest of us to review those documents.

I must confess I need to read the documents again to be able to give
more detailed comments myself.

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 10 Sep 2009 11:49:58 -0700 (PDT)

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Thursday, September 10, 2009 12:07:47 PM
> Subject: Re: [multimob] Fw: WG Action: Mobility Multicast (multimob)
> 
> Hi Dirk & all,
> 
> > As I understand from the charter we should now focus on improving the existing 
> drafts for WG approval as version 00 in November, right?
> > 
> 
> > So we have to decide which of the existing solution drafts to merge and adapt 
> to achieve those documents ... My personal impression is that while for a 
> 'document explaining the use of multicast in PMIPv6' we have several existing 
> proposals available, 
> 
> From my knowledge of numerous existing PMIPv6 Multicast drafts, there is only 
> one that deploys multicast without protocol modifications:

Currently there are several drafts including this one.
We need to give equal consideration for all, I think with my chair hat off.

Regards,

Behcet

> 
> The document has already received a number of substantial reviews that are 
> accounted for in the current version.
> 
> As we will prepare a major update prior to Hiroshima, we very much encourage 
> further comments and reviews. We are urged for a fast convergence process.
> 
> Best regards,
> 
> Thomas
> 
> >

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 25 Sep 2009 21:14:26 +0900

Hi.. Thomas..

I have already read you draft.. -mcast-deployment-01.txt

There are message source and destination address from LMA to MN, and MN to LMA.

But, how multicast packets can be transmitted?

Your opinion is same as http://tools.ietf.org/html/draft-krishnam-multimob-pmip6basicmcast-solution-00.txt ?

I want to know how tunneled multicast packet are treated.

Best Regards,

Seil Jeon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas C. Schmidt
Sent: Friday, September 11, 2009 2:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [multimob] Fw: WG Action: Mobility Multicast (multimob)

Hi Dirk & all,

> that while for a 'document explaining the use of multicast in PMIPv6' 
> we have several existing proposals available,

 From my knowledge of numerous existing PMIPv6 Multicast drafts, there is only one that deploys multicast without protocol modifications:
http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment-01

The document has already received a number of substantial reviews that are accounted for in the current version.

As we will prepare a major update prior to Hiroshima, we very much encourage further comments and reviews. We are urged for a fast convergence process.

Best regards,

Thomas

>> Profiting the occasion, we thank previous co-chairs Suresh Krishnan 
>> Brian Haberman and Gorry Fairhurst
>>
> Most of you probably have no idea who I am. I will now be chairing 
> this group together with Behcet. While I have not been visible, I have 
> been following the previous work and appreciate the efforts the people 
> above, Behcet and the rest of you already have made.
> 
> My background is mainly multicast. I have been working on multicast 
> for years, and it is also what I mostly do as a day job. I now work 
> for Cisco, while until a few months ago I've been more in the academic 
> world.
> 
> I look forward to working with you all, and our first meeting as a wg.
> 
> Stig
> 
>> Regards,
>>
>> Stig & Behcet

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 25 Sep 2009 15:10:56 +0200

Hi Seil,

> I have already read you draft.. -mcast-deployment-01.txt
Thanks & thanks for commenting. I suppose you speak about 
http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment-01

> There are message source and destination address from LMA to MN, and MN to LMA.
I'm not sure what you mean. But of course, yes. There are source and 
destination addresses. But there is no tunnel between  LMA and MN. 
Actually, an MN in PMIP should not see a reason to initiate a tunnel 
with the LMA.

> But, how multicast packets can be transmitted?

Well, as stated in the draft: The LMA will receive multicast data by 
whatever means (out of scope for this document). It will forward this 
data to the tunnel interfaces with MAGs, from which it previously 
received corresponding JOINs at. Here it is assumed that the LMA is 
somehow a multicast-aware router (Proxy or DR).

Mcast data will then arrive at the MAGs (on their upstream interface of 
the corresponding proxy instance). It will decapsulate and forward on 
those downstream interfaces that have appropriate mcast fowarding states.

> Your opinion is same as http://tools.ietf.org/html/draft-krishnam-multimob-pmip6basicmcast-solution-00.txt ?

I suppose you speak about 
http://tools.ietf.org/html/draft-krishnan-multimob-pmip6basicmcast-solution-00

There has been a longer discussion on the list. The difference with this 
approach is twofold: First, 
draft-krishnan-multimob-pmip6basicmcast-solution does define new 
protocol operations, so it is not a BCP-type. Second, there is some 
'surprising' use of a tunnel: A unidirectional tunnel enforced to the MN.
> I want to know how tunneled multicast packet are treated.
The LMA-MAG tunneling I just tried to explain above. If encapsulated 
packets with a unicast outer header are transmitted via any of those 
entities, they should be treated as unicast - just standard packet 
forwarding.

Did I answer your questions?

Thanks,

Thomas

--

---

From: "Seil Jeon" <[email-masked]>
Date: Sat, 26 Sep 2009 15:33:35 +0900

Thank you for quick response.

As you know, it means that there are description paragraph.. 

message address from LMA to MAG, from MAG to MN, and .. etc.

Definitely, I got your point.

Best Regards,

Seil Jeon 

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Friday, September 25, 2009 10:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [multimob] Fw: WG Action: Mobility Multicast (multimob)

Hi Seil,

> There are message source and destination address from LMA to MN, and MN to LMA.
I'm not sure what you mean. But of course, yes. There are source and destination addresses. But there is no tunnel between  LMA and MN. 
Actually, an MN in PMIP should not see a reason to initiate a tunnel with the LMA.

> But, how multicast packets can be transmitted?

Well, as stated in the draft: The LMA will receive multicast data by whatever means (out of scope for this document). It will forward this data to the tunnel interfaces with MAGs, from which it previously received corresponding JOINs at. Here it is assumed that the LMA is somehow a multicast-aware router (Proxy or DR).

Mcast data will then arrive at the MAGs (on their upstream interface of the corresponding proxy instance). It will decapsulate and forward on those downstream interfaces that have appropriate mcast fowarding states.

There has been a longer discussion on the list. The difference with this approach is twofold: First, draft-krishnan-multimob-pmip6basicmcast-solution does define new protocol operations, so it is not a BCP-type. Second, there is some 'surprising' use of a tunnel: A unidirectional tunnel enforced to the MN.
> I want to know how tunneled multicast packet are treated.
The LMA-MAG tunneling I just tried to explain above. If encapsulated packets with a unicast outer header are transmitted via any of those entities, they should be treated as unicast - just standard packet forwarding.

Thanks,

Thomas

>> this group together with Behcet. While I have not been visible, I 
>> have been following the previous work and appreciate the efforts the 
>> people above, Behcet and the rest of you already have made.
>>
>> for Cisco, while until a few months ago I've been more in the 
>> academic world.
>>

--