Subject: [multimob] Charter update

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 02 Jul 2009 16:00:20 +0100

I hope we are finally there.

Behcet and I propose to post the version of the Charter below to our 
ADs. We think we took account of all comments we received (on and off 
list), but have had to make a few small compromises.

If you find corrections needed to wording or something significant, let 
us know. There is a hard deadline of 12:00 noon, GMT for this feedback, 
after which we'll send to our ADs.

Thanks to all who engaged in this process,

Gorry & Behcet

----

Multicast Mobility (multimob)

Chairs:
Gorry Fairhurst <[email-masked]>
Behcet Sarikaya <[email-masked]>

Internet Area (int) Directors:
Jari Arkko <[email-masked]>
Ralph Droms <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Security Area Advisor:
Marshall Eubanks <[email-masked]>.

Mailing Lists:
General Discussion: [email-masked]
Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob

Description of Working Group

The Multicast mobility (multimob) will develop protocol extensions
and provide guidance for supporting IPv6 (and also IPv4)
multicast in a mobile environment. It will consider both source
specific multicast (SSM) and any source multicast (ASM) multicast
models. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP
protocols and listener mobility. Work requiring modifications of
multicast routing protocols is out of scope.

Specific goals are:
- Specify PMIPv6 extensions to support IPv6 multicast including remote 
subscription and fast handover.
- Specify IGMP/MLD extensions methods for mobility.

The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not
explicitly define support for multicast. The WG will work on solutions 
for multicast support in PMIPv6. It will document basic support for 
multicast with remote subscription. Such basic support will not require 
any additions or changes to RFC 5213 specified message types and 
parameters, and will assume an unmodified mobile host.  Remote
subscription is a mechanism by which a mobile node joins a multicast
group and receives multicast data forwarded via the local mobility
anchor. If required, basic multicast support may be extended to support 
optimizations to address the avalanche problem and fast handover.

IGMPv3/MLDv2 has been specified for wired networks with
shared links. Mobile nodes also have other needs (e.g.  entering a
dormant mode to conserve battery power, minimising the latency for
joining and leaving a group in support of movement). Mobile nodes also 
have other needs that are specific to wireless networks and mobility.

The WG will assess existing solutions for group management, and
determine if these methods are sufficient in a mobile environment.
This will include recommending appropriate selection of timer values
and protocol parameters. If current methods are not sufficient, the WG
shall specify updates to existing protocols. It is a goal for the WG to
ensure backward compatibility with current implementations of
group management protocols. New IGMP/MLD message types
may be specified to optimize mobile performance. Since these
could be ignored, dropped or improperly forwarded by existing hosts,
switches, routers and proxies, these will not be necessary for proper
IGMP/MLD performance, albeit with a partial or total loss of the
intended performance optimization in deployments that do not fully
support them.

Future work, subject to approval, may study/evaluate whether extensions 
are needed for the client-based mobility protocols (Mobile IPv6 and 
Dual-Stack Mobile IPv6). Future work may also include protocol 
extensions to support source mobility  and methods to allow a 
multi-homed mobile node to join multicast groups and direct multicast 
flows to appropriate local interfaces.

In performing this work, the Multimob working group will work closely
with NETLMM working group and will coordinate work on IGMP/MLD
extensions with the MBONED working group.

GOALS and MILESTONES:

Six months:
- Submit a document explaining use of multicast in PMIPv6, for 
publication as an INFO/BCP RFC.
- Submit a document on how to tune MLD for mobility, for publication as 
an INFO/BCP RFC.

One year:
- Submit a document on extensions for multicast mobility in PMIPv6 as an 
EXP/PS RFC.
- Submit a document on IGMP/MLD extensions for multicast mobility as an 
EXP/PS RFC.

Recharter or close working group.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 3 Jul 2009 00:23:55 +0300

Hi Gorry, Behcet,

Thanks for the new revised charter! It looks mostly fine to me.  
However, I still have few minor nits ;) Comments again prefixed with  
[JiK].

Cheers,
	Jouni

On Jul 2, 2009, at 6:00 PM, Gorry Fairhurst wrote:

> ADs. We think we took account of all comments we received (on and  
> off list), but have had to make a few small compromises.
>
> If you find corrections needed to wording or something significant,  
> let us know. There is a hard deadline of 12:00 noon, GMT for this  
> feedback, after which we'll send to our ADs.
>
> - Specify PMIPv6 extensions to support IPv6 multicast including  
> remote subscription and fast handover.
> explicitly define support for multicast. The WG will work on  
> solutions for multicast support in PMIPv6. It will document basic  
> support for multicast with remote subscription. Such basic support  
> will not require any additions or changes to RFC 5213 specified  
> message types and parameters, and will assume an unmodified mobile  
> host.  Remote
> anchor. If required, basic multicast support may be extended to  
> support optimizations to address the avalanche problem and fast  
> handover.
>
> joining and leaving a group in support of movement). Mobile nodes  
> also have other needs that are specific to wireless networks and  
> mobility.

[JiK] The above paragraph seems to be a bit off. I'd propose the  
following editorial change:

"IGMPv3/MLDv2 has been specified for wired networks with
  shared links. Mobile nodes also have other needs that are specific
  to wireless networks and mobility (e.g.  entering a dormant mode to
  conserve battery power, minimising the latency for joining and
  leaving a group in support of movement)."

> Future work, subject to approval, may study/evaluate whether  
> extensions are needed for the client-based mobility protocols  
> (Mobile IPv6 and Dual-Stack Mobile IPv6). Future work may also  
> include protocol extensions to support source mobility  and methods  
> to allow a multi-homed mobile node to join multicast groups and  
> direct multicast flows to appropriate local interfaces.

[JiK] Can't multi-homed host/mobile nodes already join multicast  
groups? Also, I think a "clever" multi-homed host can direct multicast  
flows between its interfaces with a stock MLDv[12]. So, what's the  
beef here?

> - Submit a document on how to tune MLD for mobility, for publication  
> as an INFO/BCP RFC.
>
> One year:
> - Submit a document on extensions for multicast mobility in PMIPv6  
> as an EXP/PS RFC.
> - Submit a document on IGMP/MLD extensions for multicast mobility as  
> an EXP/PS RFC.
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 2 Jul 2009 15:25:55 -0700 (PDT)

Hi Jouni,

> > joining and leaving a group in support of movement). Mobile nodes also have 
> other needs that are specific to wireless networks and mobility.
> 
> [JiK] The above paragraph seems to be a bit off.. I'd propose the following 
> editorial change:
> 

OK. This looks better, we'll update the charter as requested.

> > Future work, subject to approval, may study/evaluate whether extensions are 
> needed for the client-based mobility protocols (Mobile IPv6 and Dual-Stack 
> Mobile IPv6). Future work may also include protocol extensions to support source 
> mobility  and methods to allow a multi-homed mobile node to join multicast 
> groups and direct multicast flows to appropriate local interfaces.
> 
> [JiK] Can't multi-homed host/mobile nodes already join multicast groups? Also, I 
> think a "clever" multi-homed host can direct multicast flows between its 
> interfaces with a stock MLDv[12]. So, what's the beef here?

This is future work. We don't know at the moment how things will evolve. But maybe the work could involve the definition of a "clever" multi-homed host and related protocol modifications. 
Or some other things related to multicast flows. 
We suggest keeping it as future work?

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 3 Jul 2009 11:32:23 +0300

Behcet,

> Hi Jouni,

[snip]

>>> extensions are
>> groups? Also, I
> This is future work. We don't know at the moment how things will  
> evolve. But maybe the work could involve the definition of a  
> "clever" multi-homed host and related protocol modifications.

I am fine with the other future work listen in the above paragraph. I  
just don't see immediately what work there could be related to multi- 
homed hosts and moving multicast feeds between its interfaces (be  
those of the same access technology or different). As of today a multi- 
homed host can join and leave multicast groups independently on each  
of its interface. That can be controlled on the application level  
(i.e. the "clever" host).

Maybe there is something to optimize in an multi-access tech multi- 
homed host case that I am not aware of. At minimum I would suggest to  
rephrase the:
"...and methods to allow a multi-homed mobile node to join multicast  
groups and direct multicast flows to appropriate local interfaces"

to

"...and optimizations to direct multicast flows to appropriate  
interfaces in a multi-homed host"

Cheers,
	Jouni

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 03 Jul 2009 10:03:38 +0100

The first change looks good, and I believe we have all benefited from 
the discussions on the charter.

I agree with Behcet, let's make the change in your last email.

I'm not sure we need the last change proposed at the end of this email. 
Specifically I am not keen on unpacking or detailing the future work 
paragraph - If the main scope of work is addreseed, I would expect there 
to be much more experience of interactions and implications on v4 and v6 
stacks. I would also very much expect a future rechartering process to 
discuss exactly what is needed in this space.

I'd suggest avoid fine-tuning the wording here.

Gorry

jouni korhonen wrote:
>> evolve. But maybe the work could involve the definition of a "clever" 
>> multi-homed host and related protocol modifications.
> just don't see immediately what work there could be related to 
> multi-homed hosts and moving multicast feeds between its interfaces (be 
> those of the same access technology or different). As of today a 
> multi-homed host can join and leave multicast groups independently on 
> each of its interface. That can be controlled on the application level 
> Maybe there is something to optimize in an multi-access tech multi-homed 
> host case that I am not aware of. At minimum I would suggest to rephrase 
> the:

---

From: jouni korhonen <[email-masked]>
Date: Fri, 3 Jul 2009 12:20:09 +0300

Ok, fair enough.

Cheers,
	Jouni

On Jul 3, 2009, at 12:03 PM, Gorry Fairhurst wrote:

> The first change looks good, and I believe we have all benefited  
> from the discussions on the charter.
>
> I'm not sure we need the last change proposed at the end of this  
> email. Specifically I am not keen on unpacking or detailing the  
> future work paragraph - If the main scope of work is addreseed, I  
> would expect there to be much more experience of interactions and  
> implications on v4 and v6 stacks. I would also very much expect a  
> future rechartering process to discuss exactly what is needed in  
> this space.
>
>> I am fine with the other future work listen in the above paragraph.  
>> I just don't see immediately what work there could be related to  
>> multi-homed hosts and moving multicast feeds between its interfaces  
>> (be those of the same access technology or different). As of today  
>> a multi-homed host can join and leave multicast groups  
>> independently on each of its interface. That can be controlled on  
>> the application level (i.e. the "clever" host).
>> homed host case that I am not aware of. At minimum I would suggest  
>> to rephrase the:
>> "...and methods to allow a multi-homed mobile node to join  
>> multicast groups and direct multicast flows to appropriate local  
>> interfaces"
>> to

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 03 Jul 2009 11:20:23 +0200

Hi Gorry & Jouni,

> I'd suggest avoid fine-tuning the wording here.
This appears quite convincing to me: Once we have worked on the subject 
& in the group for some while and intensity, a rechartering discussion 
will most likely be aware of additional experiences and insights, also 
from the work of the other mobility groups.

So I agree with Gorry to not dive to deeply into the issues of a future 
rechartering ...

Best regards,

Thomas

>> (be those of the same access technology or different). As of today a 
>> Maybe there is something to optimize in an multi-access tech 
>> multi-homed host case that I am not aware of. At minimum I would 
>> suggest to rephrase the:

-- 

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 °