Subject: [multimob] Charter for Multimob

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 18 May 2009 07:31:19 -0700 (PDT)

Multimob folks,
  Here is the charter version 01 based on Thomas' road map.
Please post your comments on the list.

Behcet

---

From: Liu Hui <[email-masked]>
Date: Tue, 19 May 2009 11:49:24 +0800

I have a few comments on the charter:
 
1. The sentence  "The WG needs to ascertain whether..." is a useful and
general guidence to the work of the group. It should not be restricted
within the descriptions of IGMP/MLD parts.  I suggest moving it ahead as the
second paragraph of the charter, combined with the sentence "It is a goal of
Multimob...".  The new second paragraph looks as following (with capital
words indicating the modification):
 
" The WG needs to ascertain whether the existing solutions are sufficient to
solve THESE PROBLEMS, and if not, come up with better solutions. It is a
goal of Multimob to ascertain backward compatibility with the current
implementations of MULTICAST AND MOBILE IP protocols. Message structures
supported in the current deployments will not be modified. "
 
2. For IGMP/MLD part, I feel too many words are explained for "dormant mode"
.  Because this is only one aspect of this area,  I suggest not to propose
it to so important a level.  Instead, more general descriptions may be
provided.  An example is given as:
 
"IGMP/MLD is originally defined for wired networks with shared links.  They
are to be evaluated the necessity to take the extention, modificaiton and
enhancement to make them applicable to wireless and mobile environment, and
to various wireless link types.  The aspects of wireless link
characteristics, mobile communication features, battery-saving, fast
join/leave, and etc. are to be considered when making this adaptability."
 
3. The passage of "The unicast mobility protocols ..." only lists the
current state and problem, but does not gives some specific plan as PMIP
does.  I suggest add a sentence "Feasible solutions solving the above
problems are to be explored" or the like to the end.  And It is better to
put this passage after the PMIP one because the latter has more specific
plan and if this is done,  the "The unicast mobility protocols ..." should
be changed to "Other unicast mobility protocols..."  
 
Please check if they are appropriate.
 
Best Regards,
Liu Hui

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Behcet Sarikaya
Sent: 2009年5月18日 22:31
To: [email-masked]
Subject: [multimob] Charter for Multimob

Multimob folks,
 
Behcet

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 19 May 2009 08:03:03 +0100

Liu, Becheret,

I read  the charter proposal, but it took me a little while to
understand exactly what was in scope or not, so I tried a little
rewording... Here is a reworked version of the proposed charter text. I
tried to keep the style simple and in line with other charters I had seen.

Please see if any of this is improved or not, and do feel free to copy
this (or parts of this) into your charter proposal.

Best wishes,

Gorry

Liu Hui wrote:
> within the descriptions of IGMP/MLD parts.  I suggest moving it ahead as 
> the second paragraph of the charter, combined with the sentence "It is a 
> goal of Multimob...".  The new second paragraph looks as following (with 
> capital words indicating the modification):
>  
> " The WG needs to ascertain whether the existing solutions are 
> sufficient to solve THESE PROBLEMS, and if not, come up with better 
> solutions. It is a goal of Multimob to ascertain backward compatibility 
> with the current implementations of MULTICAST AND MOBILE IP protocols. 
> Message structures supported in the current deployments will not be 
> modified. "
>  
> 2. For IGMP/MLD part, I feel too many words are explained for "dormant 
> mode" .  Because this is only one aspect of this area,  I suggest not to 
> propose it to so important a level.  Instead, more general descriptions 
> may be provided.  An example is given as:
>  
> "IGMP/MLD is originally defined for wired networks with shared links.  
> They are to be evaluated the necessity to take the extention, 
> modificaiton and enhancement to make them applicable to wireless and 
> mobile environment, and to various wireless link types.  The aspects of 
> wireless link characteristics, mobile communication features, 
> battery-saving, fast join/leave, and etc. are to be considered when 
> making this adaptability."
>  
> problems are to be explored" or the like to the end.  And It is better 
> to put this passage after the PMIP one because the latter has more 
> specific plan and if this is done,  the "The unicast mobility protocols 
> ..." should be changed to "Other unicast mobility protocols..." 
>  
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Behcet Sarikaya
>     *Sent:* 2009年5月18日 22:31
>     *To:* [email-masked]
>     *Subject:* [multimob] Charter for Multimob
> 
>     Multimob folks,
> ------------------------------------------------------------------------
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

Multicast Mobility (multimob)

Chairs:
TBD

Internet Area (int) Directors:
Jari Arkko <[email-masked]>
Mark Townsley <[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 a set of protocol extensions and provide guidance appropriate for IPv4 and IPv6 multicast in a mobile environment. It will consider both source specific multicast (SSM)  and any source multicast (AMS) multicast models.

The scope of work will be limited to group management and mobile IP protocols - proxied or client-based. Work requiring modifications of multicast routing protocols (PIM-SM, PIM-DM, etc.) is out of scope. Specific goals are:

- Provide guidance and specify methods for multi-homing support for multicast.  
- Specify IGMP/MLD extensions methods for reducing join/leave latency.
- Specify a dormant mode operation for IGMPv3/MLDv2.
- Update PMIPv6 to support IPv4 multicast, remote subscription and fast handover. 

Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile environments. 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).  The working group will assess existing solutions for group management, and determine if these methods are sufficient, it will define best current practice for selection of timer values and protocol parameters. If not, it shall propose new solutions as updates to existing protocols (including possible introduction of additional message types). It is a goal for the working group to ensure backward compatibility with the current implementations of group management protocols. Message structures supported in current deployed networks will not be modified.

Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile IPv4) provide basic multicast support and enable mobile nodes to perform bi-directional tunneling and receive multicast traffic anchored at the home agent. However, such basic support suffers from the 'avalanche' problem as the home agents replicate the packets and unicast them to the mobile nodes as well as from non-optimal, triangular routing, 'remote subscription' suffers from possible loss of data during handovers. The WG will address these issues within the context of PMIPv6.

Proxy Mobile IPv6 (PMIPv6) does not currently support multicasting. Basic support for multicast with bi-directional tunneling will be documented for PMIPv6 (with no new message types or  changes to the message parameters). PMIPv6 will be extended to also support multicasting with IPv4. Finally, PMIPv6 basic multicast support will be extended to support remote subscription and fast handover.

A multi-homed mobile node may join a multicast group using two interfaces and receive multicast data in duplicate, which should be avoided. The working group will define multi-homing support for multicast, including multicast flow binding. 

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 on multihoming support for multicast as a BCP RFC.
- Submit a document on minimal deployment for PMIPv6 remote subscription for multicast as a BCP RFC

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

Recharter or close working group.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 19 May 2009 17:36:25 +0900 (JST)

Hi,

> The Multicast mobility (multimob) will develop a set of protocol
> extensions and provide guidance appropriate for IPv4 and IPv6
> multicast in a mobile environment. It will consider both source
> specific multicast (SSM)  and any source multicast (AMS) multicast
> models.

s/AMS/ASM/

> - Provide guidance and specify methods for multi-homing support for

I don't know if multihoming support is included in the charter.

> - Specify IGMP/MLD extensions methods for reducing join/leave latency.

This is ok.

> - Specify a dormant mode operation for IGMPv3/MLDv2.

A "dormant mode operation" is unclear, or rather unnecessary to be
mentioned. In my sense, mobile nodes in dormant mode do not care (and
do not receive) any signal (and hence it is unnecessary to consider
any protocol operation).
Something like tuning or optimization of IGMP/MLD protocol behaviors
would be reasonable here?

> - Update PMIPv6 to support IPv4 multicast, remote subscription and

- Provide guidance for multicast service support without protocol
  modification
- Specify PMIPv6 extensions to support IPv6 multicast including
  remote subscription and fast handover
- Specify PMIPv6 extensions to support IPv4 multicast
  or
  Provide guidance for supporting IPv4 multicast
  (I don't know if IPv4 multicast in PMIPv6 is included or not, but
  according to the discussions in this ML, someone seems to be very
  interested in it.)

> Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile
> environments. 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).

Just "e.g. concerving battery power, minimizing the latency for
joining and leaving a group in support of movement" is fine for me.

...snip...

> A multi-homed mobile node may join a multicast group using two
> interfaces and receive multicast data in duplicate, which should be
> avoided. The working group will define multi-homing support for
> multicast, including multicast flow binding. 

I'm not sure, but I may doubt multihoming support for multicast is
focused on this group.

Regards,
--
Hitoshi Asaeda

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 19 May 2009 11:00:54 +0200

Hi Gorry,

  thanks for optimizing the charter ;)!

  Typo:

  * 1st para.: AMS -> ASM

  Questions @all:

  * 3th para.: "Update PMIPv6 to support IPv4 multicast [...]" - 
transition scenarios are a new work item?? Who want to work on this?

  * Maybe one should switch para. 5 and 6: "Proxy Mobile IPv6 does not 
currently support multicasting [...]" should be discussed before the 
optimization of the tunnel convergence problem.

Cheers
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Tue, 19 May 2009, Gorry Fairhurst wrote:

> >     *Sent:* 2009Äê5ÔÂ18ÈÕ 22:31
> >     *To:* [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 19 May 2009 10:07:34 +0100

A few thoughts on your comments...

Gorry

>> specific multicast (SSM)  and any source multicast (AMS) multicast
Oh yes!

> I don't know if multihoming support is included in the charter.

We need to decide - this appears several times. I included it since, it 
was on the proposed charter that I read.

If we request this iun our charter, I think this need a little more 
clarification. Multihoming for receivers? For senders? Is this only for 
mobility? - A little more scope may help us understand whether this 
makes a good charter item. Our suspect our AD will have views too on this.

> would be reasonable here?
I have no opinion on dormant mode - anyone wish to speak on why we need 
to reduce signaling in dormant mode?

I think tuning and optimisation and tuning sound weak - I'd prefer the 
goal to be recommendations for deployment in a mobile environment.

> - Provide guidance for multicast service support without protocol
... Is this really a goal?
> - Specify PMIPv6 extensions to support IPv4 multicast
... sounds ok
>   according to the discussions in this ML, someone seems to be very
... sounds vague?

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 19 May 2009 18:38:43 +0900 (JST)

> ... Is this really a goal?

Not for me.:)
But the candidate charter proposed Thomas included both "Multicast
listener deployment in PMIPv6: BCP" and "Multicast listener
optimizations in PMIPv6 extensions: Exp or PS", and hence I thought
there was some concensus to focus on both and you meant the former one
here.

> >   remote subscription and fast handover

Good.

> >   according to the discussions in this ML, someone seems to be very

Maybe.
I personally think supporting IPv4 multicast in PMIPv6 is not urgent
and can be postponed, but someone may have strong opinion to include
it at this time, right?

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 19 May 2009 15:33:05 +0200

Hi Gorry, Hitoshi et al.,

sorry for joining the discussion late.

A general remark, at first:

The elevation of PMIPv6 by "Proxy Mobile IPv6 (PMIPv6) does not 
currently support multicasting." is somewhat misleading ... and - as 
stated in the following charter sentence - not really true.

Instead, I would suggest to reword like follows:

"Current mobility extension protocols like PMIPv6, FMIPv6, HMIPv6 ... do 
not support multicasting explicitely. In particular, the current PMIPv6 
specification does not allow for unencapsulated, continued multicast 
reception at the mobility-agnostic mobile node."

> there was some concensus to focus on both and you meant the former one

Well, this discussion is going somewhat off the road: "- Provide 
guidance for multicast service support without protocol
  modification" is certainly not a goal. In defining a document list, I 
was proposing a strategy for preparing documents. This was not a list of 
goals ;)

> and can be postponed, but someone may have strong opinion to include

There are statements in RFC 5213 request simulatneous IPv4 support. 
Anyway, I guess this is not really a big issue ...

Regarding Multihoming:

The statement
"A multi-homed mobile node may join a multicast group using two 
interfaces and receive multicast data in duplicate, which should be 
avoided."
seems to lead to the wrong problem. An MN would most likely not 
accidentally subscribe to a group on all its interfaces. The more 
interesting affair seems to be an efficient per-interface subscription 
management in the case of multihomed mobility. In other words: "what 
should the MN do to optimize service, resource consumption and overall 
performance."

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: Gorry Fairhurst <[email-masked]>
Date: Tue, 19 May 2009 16:25:00 +0100

I'd be happy for someone to make a new charter proposal drawing together 
  the various inputs for this round, ... We're getting there...

I'm busy currently, so I can't do this over the next few days. I would 
however be happy to comment more when we next get a stable version.

Gorry