Subject: [multimob] Comparing the proposals for basic multicast support

From: Stig Venaas <[email-masked]>
Date: Fri, 16 Oct 2009 14:11:01 -0700

I think we need to get some discussion started on the various
proposals for basic multicast support. Basically the proposals
that are aimed at fulfilling our first charter milestone:

     Nov 2009 - Initial version of a document explaining the use
     of multicast in PMIPv6

Here is what I would like to see from people that are submitting
proposals they believe are candidates for this milestone.

o You should request a slot and present it in Hiroshima. If there
   are drafts where none of the authors can be present, please let
   us know. To request a slot, email Behcet and me.

o Please soon send an email to the list summarising your proposal,
   and its pros and cons.

When describing the proposal, I think it could be interesting
to hear how it deals with some of the following points:

o What is the additional functionality required of MAGs and LMAs

o Bandwidth usage (e.g. if multiple nodes join the same groups)

o MTU, with various tunneling techniques, MTU may be an issue

o Handover, within a MAG, between MAGs

o Can a MN source multicast? (I'm not sure whether this is a
   requirement, but nice to have IMO)

I guess there are other points I haven't thought of. I would
be interested to hear what else.

I hope by doing this, we can get some data points to better
compare the proposals, and get some good discussion started
before we meet in Hiroshima.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 17 Oct 2009 16:19:11 +0200

Dear Stig & all,

thanks for stimulating a discussion to meet essential key points. We are 
happy to catch your trigger and provide the info for our draft 
http://www.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt 

[Proposal Summary:]

Objective and guideline of this proposal is the deployment of multicast 
on PMIPv6 domains with the help of standardized protocols and functions, 
only. No new messages, entities or functions have been defined in this 
draft.
The key step is to deploy MLD proxy instances on MAGs for each LMA-MAG 
tunnel uplink. Then MAG acts as a proxy and LMA as a standard multicast 
querier.

Pros: Multicast service with a good deal of traffic aggregation can be 
achieved by using standardized solutions.

Cons: Traffic need not be fully optimized. It may happen that a MAG 
receives duplicated multicast data from different LMAs, as well as 
transmit duplicate streams down the wireless links. There is no path to 
multicast reception without an LMA, as standard PMIPv6 traffic streams 
are bound to LMA-MAG tunnels.

[Bandwidths usage:]

Depending on their association to LMAs, multiple MNs may receive the 
same multicast stream, or may initiate redundant forwarding via distinct 
LMAs.

[MTU-Size:]

As data is transmitted via LMA-MAG tunnels, MTU-size issues may arise 
according to tunnel MTU-sizes. For a discussion on the MTU-size issues 
we refer to the problem statement: 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

[Handovers:]

Handover operations remain in full analogy to standard PMIPv6 (use same 
tunnel and binding states), so the performance of unicast should equally 
apply to the multicast case.

[Multicast source support:]

There is no explicit support for mobile multicast sources - this was out 
of scope from the charter. There will be easy ways to extend the 
solution to sender mobility (and we can add a remark on that), but with 
the charter in mind, we concentrated on multicast receivers ;)

[Additional Point: Link Model]

PMIPv6 is currently bound to a point-to-point link model, which is 
actually not very advantageous for group communication. The draft 
discussed here (in its current version 2) eliminated the addiction to 
the point-to-point link model. It equally applies to shared links, once 
the PMIPv6 spec extends to a larger domain of wireless technologies.

That's our contribution in brief - we'll be very grateful for input that 
helps to improve the document!

Thomas

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Oct 2009 10:59:20 -0700

> http://www.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt 

Great Thomas! I hope others will do the same. And also that people will
review your draft and give comments on it, including discussion of the
points below. See below for more comments.
> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

Right. One point here is whether the multicast MTU is lower than the
unicast MTU (whether further tunneling/encap is used).

> the charter in mind, we concentrated on multicast receivers ;)

I should not have mentioned that. My mistake. So feel free to ignore
this one. Personally, I find this an interesting point, but we should
not discuss it now.

> helps to improve the document!

Thanks,

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 20 Oct 2009 22:10:21 +0200

Hi Stig,

> unicast MTU (whether further tunneling/encap is used).

This is not the case: the same tunnel is used, so that the multicast MTU 
is transparent when compared with unicast (e.g., by path MTU discovery).

>> There is no explicit support for mobile multicast sources - this was 
>> out of scope from the charter. There will be easy ways to extend the 
>> solution to sender mobility (and we can add a remark on that), but 
>> with the charter in mind, we concentrated on multicast receivers ;)
> 
:-) So do I - but we can keep these topics for later work in Multimob ;)

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: "Seil Jeon" <[email-masked]>
Date: Fri, 23 Oct 2009 16:06:25 +0900

Dear Stig & multimob folks,

Thanks for giving the chance to describe our solution as some key points.

I provide the information for our draft http://tools.ietf.org/html/draft-
sijeon-multimob-mms-pmip6-00

Core solution is not changed. But, as soon as, I will upload -01 version
draft describing more detailed than -00 version.

But, for the multimob folks, I want to respond as request first.

1. [Proposal Summary]
 : Our solution is based on local routing scenario in
http://tools.ietf.org/html/draft-deng-multimob-pmip6-requirement-02.
   PMIPv6 multicasting service can be provided by LMA using tunneling
technique. It means that LMA has multicast routing function.
   It is useful and basic solution. However, it may introduce some
optimization problem (i.e., tunnel convergence, ..) and unpredictable
exception.

   For more simple structure and implementation, I propose that a MAG that
having IGMP/MLD forwarding proxy 
   function is connected to the multicast router. So, it does not tunnel
mechanism and can avoid tunnel convergence problem.
   And also, it can avoid unpredictable exception by not using bi-
directional tunnel with LMA.

   To reduce handover latency due to IGMP/MLD action after MN's handoff, we
propose context transfer between MAG-to-MAG 
   for pre-reporting to multicast router. (RFC 5213 also assumes context
transfer mechanism for inter-technology handoff.)

   In the perspective of operators, we think that it would be appropriate
solution.

2. [Bandwidth Usage]
 : A LMA is not involved with multicasting action because a MAG is directly
connected to multicast router.
   So, the MAG does not receive duplicate and redundant packets.

3. [MTU size]
 : We do not use tunneling techniques. So, MTU issue may be not happen.

4. [Multicast Source Support]
 : Explicitly, I do not consider multicast source support. However, 
   And our solution is related to remote-subscription

5. [Tunnel Convergence]
 : A MAG is connected to only one multicast router. So, it can avoid the
tunnel convergence problem.

Thanks for careful reading.

I am quite open comments of multimob friends.

Best Regards,

Seil Jeon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stig Venaas
Sent: Saturday, October 17, 2009 6:11 AM
To: [email-masked]
Subject: [multimob] Comparing the proposals for basic multicast support

I think we need to get some discussion started on the various proposals for
basic multicast support. Basically the proposals that are aimed at
fulfilling our first charter milestone:

Here is what I would like to see from people that are submitting proposals
they believe are candidates for this milestone.

When describing the proposal, I think it could be interesting to hear how
it deals with some of the following points:

I guess there are other points I haven't thought of. I would be interested
to hear what else.

I hope by doing this, we can get some data points to better compare the
proposals, and get some good discussion started before we meet in Hiroshima.

Stig

---

From: "Lu, Guang" <[email-masked]>
Date: Fri, 23 Oct 2009 14:27:50 -0400

Hello all,

Below you will find some more information about our draft: 
http://tools.ietf.org/html/draft-zuniga-multimob-smspmip-00 

We will be glad to present this proposal at the meeting, and please let
us know if you have any questions or comments.

[Summary] 
The draft discusses how multicast services and mobility can be supported
using the current Proxy Mobile IPv6, IGMP/MLD protocols. The draft
consists of three parts: 
*	First, the draft describes scenarios to initiate multicast
services, and inter-MAG mobility using one LMA
*	Second, the draft proposes an improved multicast support using a
dedicated LMA for multicast services
*	Third, the draft discusses enhanced multicast mobility support
utilizing handover triggers  

Pros: 
The draft covers both the basic and improved solutions using the current
protocols. 
The basic multicast support (section 3) can work independently as a
solution. 
The use of dedicated multicast LMA (section 4) solves the issue of
duplicate subscription and multicast traffic redundancy.  
In addition, the draft discusses various methods to enhance multicast
mobility and MLD/IGMP (section 5&6). 
 
Cons:
Enhanced mobility depends on the availability of handover triggers, and
exchange of information between PMIPv6 nodes.

[What is the additional functionality required of MAGs and LMAs]
MAG is the multicast proxy, and LMA as multicast router (or proxy), as
defined in RFC 4605.

[Bandwidth usage] 
The proposed dedicated multicast LMA approach can largely reduce traffic
redundancy and bandwidth usage.

[MTU, with various tunneling techniques, MTU may be an issue]
The draft does not affect the MTU issue.

[Handover]
The draft discusses how multicast mobility can be supported for
inter-MAG handover, using procedures defined in PMIPv6.  

Best regards,

Guang and Juan Carlos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stig Venaas
Sent: Friday, October 16, 2009 5:11 PM
To: [email-masked]
Subject: [multimob] Comparing the proposals for basic multicast support

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 23 Oct 2009 15:26:53 -0700 (PDT)

Hi Thomas,

Please see below.

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: Stig Venaas <[email-masked]>
> Cc: [email-masked]
> Sent: Sat, October 17, 2009 9:19:11 AM
> Subject: Re: [multimob] Comparing the proposals: draft-schmidt-multimob-pmipv6-mcast-deployment
> 
> Dear Stig & all,
> 
> thanks for stimulating a discussion to meet essential key points. We are happy 
> to catch your trigger and provide the info for our draft 
> Objective and guideline of this proposal is the deployment of multicast on 
> PMIPv6 domains with the help of standardized protocols and functions, only. No 
> new messages, entities or functions have been defined in this draft.
> The key step is to deploy MLD proxy instances on MAGs for each LMA-MAG tunnel 
> uplink. Then MAG acts as a proxy and LMA as a standard multicast querier.
> 
> Pros: Multicast service with a good deal of traffic aggregation can be achieved 
> by using standardized solutions.
> 
> Cons: Traffic need not be fully optimized. It may happen that a MAG receives 
> duplicated multicast data from different LMAs, as well as transmit duplicate 
> streams down the wireless links. There is no path to multicast reception without 
> an LMA, as standard PMIPv6 traffic streams are bound to LMA-MAG tunnels.
> 
> [Bandwidths usage:]
> 
> Depending on their association to LMAs, multiple MNs may receive the same 
> multicast stream, or may initiate redundant forwarding via distinct LMAs.
> 
> [MTU-Size:]
> 
> As data is transmitted via LMA-MAG tunnels, MTU-size issues may arise according 
> to tunnel MTU-sizes. For a discussion on the MTU-size issues we refer to the 
> problem statement: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps
> 
> [Handovers:]
> 
> Handover operations remain in full analogy to standard PMIPv6 (use same tunnel 
> and binding states), so the performance of unicast should equally apply to the 
> multicast case.
> 
> There is no explicit support for mobile multicast sources - this was out of 
> scope from the charter. There will be easy ways to extend the solution to sender 
> mobility (and we can add a remark on that), but with the charter in mind, we 
> concentrated on multicast receivers ;)
> 
> PMIPv6 is currently bound to a point-to-point link model, which is actually not 
> very advantageous for group communication. The draft discussed here (in its 
> current version 2) eliminated the addiction to the point-to-point link model. It 
> equally applies to shared links, once the PMIPv6 spec extends to a larger domain 
> of wireless technologies.

There are proposals to run PMIPv6 on shared links such as WiFi. In those proposals (not in draft format but just some ideas), PMIPv6 still works based on point-to-point link model but on the shared link. For example RAs are sent to each MN separately, i.e. point-to-point link is emulated on a shared link.

I just wanted to clarify this point before I forget.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Oct 2009 01:43:03 +0200

Dear Guang and Juan Carlos,

we've read your draft and thought about it. Here are our comments:

On the overall, we read your draft as a review on existing PMIPv6 
multicast extensions that include some additional modifications and some 
inexact generalizations. In summary it appears like an exploration of a 
possible design space - is this what you intended?

Further on, you sketch several concurrent multicast mobility solutions, 
but this procedure is not well reflected in your document structure. So 
it is somewhat hard to sort out what statement belongs to which approach 
under consideration.

Finally, this work is grounded on the problems analyzed and 
characterized in
[I-D.irtf-mobopts-mmcastv6-ps]
               Schmidt, T.C., Waehlisch, M., Fairhurst, G.,
               "Multicast Mobility in MIPv6: Problem Statement and Brief 
Survey",
               draft-irtf-mobopts-mmcastv6-ps-09 (work in progress), 
October 2009,

as well as on the discussions initiated by the problem statement work. 
So IMO it makes a lot of sense to give reference to the state of work 
you rely on.

In detail:

In section 3 you state
"In order to manage multicast traffic terminated on an MN, the LMA would 
need to keep the multicast status for every MN subscribing to a content."
This seems as wrong as it is for any multicast router in a multicast 
enabled network. PMIP does not change the world here.

Section 4 (first paragraph):

You require that any MN requests multicast services only after it has 
registered within a specific PMIP domain. This - aside from technical 
questions - appears odd to me: If a user watches IPTV on some train 
station (fixed network) and intends to continue while boarding the train 
(PMIP domain), and does so while later changing into another train of a 
different company (a new PMIP domain), there are no obvious reasons why 
this should not work.

Section 5:

You state "the LMA will not play any specific role in the multicast 
traffic management"
This is inconsistent with solutions you describe later, e.g., a 
multicast-specific dedicated LMA ...

Section 6.1:

You describe a scenario, where MAGs have an uplink to one dedicated 
multicast-specific LMA: "In this draft, just one MLD proxy instance is 
considered to be running in the MAG, and as consequence, just one 
interface can be defined as upstream interface."

A corresponding deployment would be as follows: Operators have a PMIP 
(unicast) domain and add (and statically pre-configure at MAGs) an 
additional multicast LMA that serves all groups. This is a set-up not 
considered so far, but may be feasible for operators???

==> Operator comments should debate on that.

Section 6.2:

You write "... In that case, the multicast distribution tree could be 
extended over the
    tunnel between MAG and LMA, once that tunnel has been set up."

Below you state that no MTU issues arise. This is inconsistent.

Section 7.1.:

You emphasize that an MLD general query at the MAG wasts resources. We 
would debate that and argue that it is negligible. Keeping in mind that 
PMIP operates on router solicitations / router advertisements, an MLD 
query (which could run in parallel) does by no means bend the resource 
consumption of an MN on handover.

Section 7.2.:

You rely on an autonomous context transfer mechanism between MAGs. 
Thereby you refer to a context transfer in 
[draft-sijeon-multimob-mms-pmip6] which is not well defined, and later 
to RFC 4067. IMHO the problem is not solved that easily. PMIP defines an 
explicit context transfer for "MN's policy profile" that does not cover 
multicast. RFC 4067 is an abstract protocol that does not define 
explicit messaging for multicast context transfer. So I don't see that 
the current specs do allow for multicast context transfer without any 
protocol extensions. Rather, an indication is given on "what to do in 
future work" - which we perfectly agreed upon. This work however is out 
of scope from the charter for now.

Section 7.3.:

You propose an pMAG-assisted handover in the following way: pMAG 
receives multicast traffic via the LMA, then forwards traffic to nMAg 
via the LMA again. This leads to a traffic flow of the form:

    mcast source ===> LMA ==> pMAG ==> LMA ==> nMAG ==> MN,

which is of obvious Zig-Zag form. The already published solutions 
propose a direct flow via a tunnel (which is quickly erected), and are 
thus much more efficient.

So I wonder what the benefit of this "recurved flow" solution should be?

Finally you state below: "Enhanced mobility depends on the availability 
of handover triggers,..." - I wonder how this relates to your draft and 
the problem? L2 triggers are beneficial for the base handover 
management, but multicast operations sit on top of it. As described in 
the problem statement, you cannot expect multicast to be faster than 
L2/L3 attachment, but the issue of protocol design is to define 
solutions that are not significantly slower!

Hope I hit some of your open points.

Best regards,

Thomas

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Oct 2009 01:50:02 +0200

Hi Behcet,

> I just wanted to clarify this point before I forget.
Yes, it is not difficult to imagine PMIP solutions on a shared link
model, even though RFC 5213 is bound to PtP links.

The issue I wanted to point out is that the multicast extension model in
charge of this draft is not bound to mechanisms  of the PtP link model -
it should transfer to shared link solutions without changes.

Thanks,

Thomas
--

---

From: "Lu, Guang" <[email-masked]>
Date: Fri, 23 Oct 2009 22:26:57 -0400

Dear Thomas, 

I read through your comments and quotes from the draft. It seems to me
that you are referring to another draft that was submitted recently,
except that the dedicated multicast LMA is proposed in our draft. Here
is the link of our draft. 

Could you please verify it? 

Best Regards,
Guang

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 7:43 PM
To: Lu, Guang
Cc: Stig Venaas; [email-masked]
Subject: Re: [multimob] Comparing the proposals for basic multicast
support

under consideration.

Survey",

In detail:

In section 3 you state

need to keep the multicast status for every MN subscribing to a
content."
This seems as wrong as it is for any multicast router in a multicast 
enabled network. PMIP does not change the world here.

Section 5:

Section 6.1:

Section 6.2:

Section 7.1.:

Section 7.2.:

Section 7.3.:

Best regards,

Thomas

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Oct 2009 12:30:31 +0200

Dear Guang,

indeed, you are right. I got confused with the large number of upcoming
documents :-(, which all exhibit a large overlap in the proposed design
space.

What I was referring to is draft draft-contreras-multimob-msd-00.txt, see
http://www.ietf.org/id/draft-contreras-multimob-msd-00.txt

by Luis M. Contreras, Carlos J. Bernardos, and Ignacio Soto of UC3M.

So everything I wrote applies to the above document and not to your draft.

Sorry for the confusion - that was just a mistake.

To make up for the confusion, I'll try to do a review on your draft asap ;)

Thanks & best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Oct 2009 19:38:23 +0200

Hi Guang and Juan Carlos,

here comes the "real review" - sorry for the previous mismatch.

I read through your draft and have the following comments:

   Section 3:

Here you sketch in brief what has been detailed out in previous work.
Does Figure 3 omit MLD queries, as well? If not, why should a MN send an 
MLD report subsequent to re-attachment?
Another remark on presentation: you skip additional LMAs that may be 
around for other MNs. In doing so, the draft expresses the misleading 
intuition of a uniquely defined path from MAGs to 'the' LMA - in PMIPv6, 
there is need for a mapping.

   Section 4:

In this section you contribute the proposal to concentrate all multicast 
channels on one dedicated LMA. This approach obsoletes a MN <-> LMA 
mapping at MAGs in the case of multicast and resolves redundant traffic 
possibly arriving at one MAG. In eliminating the tunnel convergence 
problem at the MAG, you place the burden at the LMA and may encounter 
the traditional tunnel convergence problem of a HA in the bi-directional 
tunneling approach (see 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09). The 
scalability constraint arises from the burden at the LMA to serve 
\sum_{i in MAGs}{Mcast-Streams-at-MAG_i} simultaneously. A large number 
of MAGs with various mcast listeners is your problem here, while a large 
number of MNs attached at one MAG, but associated to different LMAs is 
the problem of the solution in 
[draft-schmidt-multimob-pmipv6-mcast-deployment-02].

Furthermore, as written earlier:

   Section 5:

This section I don't really understand: you call for HO-triggers without 
specifying them. Do you just speak about L2 triggers at re-attachment? 
This I believe is independent of multicast, outside the scope of 
Multimob and solved elsewhere, anyway.
Do you speak about a L3 trigger of re-attachment? This actually is 
present in PMIP with the RtrSol. There is nothing new then.
Or do you speak about fast predictive handovers (as indicated between 
the lines)? Then you should look at 
http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-09, but multicast 
considerations for fast handovers are still out of scope from the charter.

  Section 6:

You propose two "MLD enhancements": In 6.1 you sketch a predictive JOIN 
- this again is a brick of a (generally much more complex) fast handover 
scenario (s.o.).
In section 6.2, you consider a "fast join" send by the MN on 
re-attachment. This actually requires an active participation of the MN 
in the PMIP HO process - and is violating the key objective of PMIP to 
leave mobility operations at the network side.

In summary, I would extract the "dedicated LMA for multicast" as the 
valid contribution, which you jointly propose with 
[draft-contreras-multimob-msd-00]. There should probably follow a 
discussion on

  a) Deployment issues: Would a separate Multicast LMA be a feasible 
deployment path
     that is preferred over multicast traffic arriving through standard 
LMAs for unicast?

  b) Scalability issues: What is the more severe scalability concern, 
many MAGs being
     served by a single LMA (tunnel convergence problem at the LMA), or 
many LMAs serving
     a single MAG (tunnel convergence problem at the MAG)?

Thanks for bringing this up!

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 24 Oct 2009 19:45:24 +0200

Hi Thomas,

thanks for reviewing the draft and give some comments.

Despite some of them mix concepts and ideas coming from 
draft-zuniga-multimob-smspmip-00, I will try to clarify those referring 
totally to draft-contreras-multimob-msd-00. Please, see my comments 

>> enabled network. PMIP does not change the world here.

With this text I try to say that, regarding multicast traffic, the LMA 
does not know initially which content is subscribed by each MN because 
it is not the first hop router for the MN. The LMA requires some 
information to correctly deliver any multicast content to the MN 
subscribing it. In an scenario where the MAG acts as MLD proxy and the 
LMA acts as multicast router, the MAG provides a (summarized) view of 
the MN subscriptions. In any other scenario, some other mechanism is 
needed to transfer MN multicast status to the LMA. In this way, for 
instance draft-krishnan-multimob-pmip6basicmcast-solution-00 proposes 
to tunnel towards LMA the MLD messages originated by MNs. I do not 
prejudge the validity of the LMA to forward the multicast traffic, I 
just highlight that it needs additional information to do that because 
it is not the firs-hop router as seen by the MNs, as any other 
multicast router in a multicast enabled network.

>> You require that any MN requests multicast services only after it 
>> has registered within a specific PMIP domain. This - aside from 
>> technical questions - appears odd to me: If a user watches IPTV on 
>> some train station (fixed network) and intends to continue while 
>> boarding the train
>>
>> (PMIP domain), and does so while later changing into another train 
>> of a different company (a new PMIP domain), there are no obvious 
>> reasons why this should not work.
>>

What I mean with that sentence is that the MN should be registered 
before requesting (in case the multicast service was not initiated in 
the past) or receiving (in case the multicast service was already 
requested) the multicast traffic. This is a way of ignoring MN's MLD 
signalling for an MN entering the network, or in the period comprised 
between a detachment and an re-attachment events (in other words, MLD 
signalling is ignored once the PBU/PBA messages are interexchanged 
between MAG and LMA). If we don't ignore such signalling e.g. during 
handover events, some inconsistencies could appear related to the 
multicast traffic.
Furthermore, from a network operator point of view, I guess any 
operator would like to register in advance any user to be serviced, 
mainly to bill it accordingly to the network use.

>> multicast-specific dedicated LMA ...

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00.

>> multicast-specific LMA: "In this draft, just one MLD proxy instance 
>> is considered to be running in the MAG, and as consequence, just one 
>> A corresponding deployment would be as follows: Operators have a 
>> PMIP (unicast) domain and add (and statically pre-configure at MAGs) 
>> an additional multicast LMA that serves all groups. This is a set-up 
>> not considered so far, but may be feasible for operators???
>>

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00.

>> Section 6.2:
>>
>> You write "... In that case, the multicast distribution tree could 
>> be extended over the

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00 (no reference is done to MTU in my 
draft).

>> Section 7.1.:
>>
>> You emphasize that an MLD general query at the MAG wasts resources. 
>> We would debate that and argue that it is negligible. Keeping in 
>> mind that PMIP operates on router solicitations / router 
>> advertisements, an MLD query (which could run in parallel) does by 
>> no means bend the resource consumption of an MN on handover.
>>

I agree it is necessary to evaluate the impact. It could be negligible, 
of course, but it is a fact that it wastes radio resources. Note that 
the MLD query is done for every MN entering a MAG domain, not only 
those with active subscription.

>> [draft-sijeon-multimob-mms-pmip6] which is not well defined, and 
>> later to RFC 4067. IMHO the problem is not solved that easily. PMIP 
>> defines an
>>
>> explicit context transfer for "MN's policy profile" that does not 
>> cover multicast. RFC 4067 is an abstract protocol that does not 
>> define explicit messaging for multicast context transfer. So I don't 
>> see that the current specs do allow for multicast context transfer 
>> without any protocol extensions. Rather, an indication is given on 
>> "what to do in future work" - which we perfectly agreed upon. This 
>> work however is out of scope from the charter for now.
>>

I take your point, I think it needs further ellaboration to understand 
well the impacts in the network and in the protocols.

>> receives multicast traffic via the LMA, then forwards traffic to 
>> nMAg via the LMA again. This leads to a traffic flow of the form:
>>
>> propose a direct flow via a tunnel (which is quickly erected), and 
>> are thus much more efficient.
>>

Not exactly. The pMAG can play the role of MLD proxy or the role of 
multicast router. In the later case the flow will be:

mcast source ==> pMAG ==> LMA ==> nMAG ==> MN

In the former, in case of the LMA is the multicast router, the scenario 
will be as you described, but in a generic way the flow will be:

mcast source ===> multicast router ==> pMAG ==> LMA ==> nMAG ==> MN

>> So I wonder what the benefit of this "recurved flow" solution should be?

The main benefit is an immediate delivery of the multicast flow. The MN 
will have the flow just after registration in nMAG. Further 
improvements to the zig-zag delivery can be expected with protocols 
extensions/modifications. By now, the zig-zag is the price to pay for 
immediate delivery of the multicast traffic.

>> Finally you state below: "Enhanced mobility depends on the 
>> availability of handover triggers,..." - I wonder how this relates 
>> to your draft and the problem? L2 triggers are beneficial for the 
>> base handover management, but multicast operations sit on top of it. 
>> As described in the problem statement, you cannot expect multicast 
>> to be faster than L2/L3 attachment, but the issue of protocol design 
>> is to define solutions that are not significantly slower!
>>

I think you refer to draft-zuniga-multimob-smspmip-00.

>> Hope I hit some of your open points.

Thanks again for your comments.

Best regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Oct 2009 22:47:44 +0200

Hi Luis,

Luis M. Contreras wrote:

> totally to draft-contreras-multimob-msd-00. Please, see my comments below:
>
Yes, sorry: Actually the mix was between your draft and the mail of 
Guang and Juan Carlos.

I will try to clarify below, where useful.

> instance draft-krishnan-multimob-pmip6basicmcast-solution-00 proposes to 
> tunnel towards LMA the MLD messages originated by MNs. I do not prejudge 
> the validity of the LMA to forward the multicast traffic, I just 
> highlight that it needs additional information to do that because it is 
> not the firs-hop router as seen by the MNs, as any other multicast 
> router in a multicast enabled network.

Yes, we certainly agree that the LMA needs forwarding information - 
however, they need not be MN/receiver-specific, as  in general multicast 
routers do not need receiver-specific states.

>>> (PMIP domain), and does so while later changing into another train of 
>>> a different company (a new PMIP domain), there are no obvious reasons 
>>> why this should not work.
>>>
> 
> Furthermore, from a network operator point of view, I guess any operator 
> would like to register in advance any user to be serviced, mainly to 
> bill it accordingly to the network use.
> 

I tried to question this statement, because its implications remained 
unclear to me. If you just assume that operators may deny service 
without AAA, then we agree. The general scenario is that multicast 
operations follow unicast binding.
If you however imply to exclude mcast services from inter-domain 
transfer, then your assumption most likely is beyond general believe.

> draft-contreras-multimob-msd-00.
I don't think so, but I may not have understood your section 6 correctly.

In section 6.1 you state "In this draft, just one MLD proxy instance is
    considered to be running in the MAG, and as consequence, just one
    interface can be defined as upstream interface."

There are essentially two ways to deal with this setup:

  a) Direct multicast routing as previously proposed in 
[draft-sijeon-multimob-mms-pmip6-00].
     This would not be new and has had several discussions on the list.

  b) A dedicated uplink to *one* LMA that serves for all multicast. This 
was my point of
     discussion and arguments have been extended in my previous mail to 
Guang and Juan Carlos.

So I'm still not sure which scenario you have in mind - however, 
arguments are given about both.

>>> We would debate that and argue that it is negligible. Keeping in mind 
>>> that PMIP operates on router solicitations / router advertisements, 
>>> an MLD query (which could run in parallel) does by no means bend the 
>>> resource consumption of an MN on handover.
>>>
> 
> the MLD query is done for every MN entering a MAG domain, not only those 
> with active subscription.
> 

Yes, sure, as RtrSol and RtrAdv is done. The difference on a shared link 
would be the number of answers: A general query (as of RFC 3810) may be 
answered by all nodes on that link. With point-to-point air links, there 
is of course only one answer and the waste (in case of no active 
subscription) is about 50 octets.

> mcast source ===> multicast router ==> pMAG ==> LMA ==> nMAG ==> MN

O.K., this again depends on your routing scenario (I previously asked 
about). However, even if the pMAG acts as multicast router, traffic 
normally arrives from outside the mobile access network and thus crosses 
it three times.

> will have the flow just after registration in nMAG. Further improvements 
> to the zig-zag delivery can be expected with protocols 

Mhmm, are you sure this is faster? MLD querying can be quick (with 
appropriate timers) and in parallel to Binding updates, so the time 
needed for multicast traffic to arrive does not really exceed 
RTT(nMAG-LMA). In your approach, I would calculate RTT(nMAG-LMA), as 
well, as traffic needs to arrive at the nMAG from LMA after a Binding 
Update. Buffering at the LMA may avoid packet loss in both scenarios.

Now I hopefully have met your draft entirely ;)

Best wishes & hope to see you in Hiroshima,

Thomas
--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sun, 25 Oct 2009 20:41:37 +0100

Hi Thomas,

just for clarification, please, see below some additional comments

>>>> Section 5:
>>>>
>>>> You state "the LMA will not play any specific role in the 
>>>> multicast traffic management"
>  b) A dedicated uplink to *one* LMA that serves for all multicast. 
> This was my point of
>     discussion and arguments have been extended in my previous mail 
> to Guang and Juan Carlos.
>

I see that the scenario (a) could contain the scenario (b); in other 
words, the scenario (b) can be seen as a particular case of scenario 
(a).

>> In the former, in case of the LMA is the multicast router, the 
>> scenario will be as you described, but in a generic way the flow 
>> will be:
>>
> normally arrives from outside the mobile access network and thus 
> crosses it three times.
>

Right, but note that the flow is not permanent, it crosses temporally 
the mobile access network just to deliver asap the multicast content to 
the MN after a handover.

>> The main benefit is an immediate delivery of the multicast flow. The 
>> MN will have the flow just after registration in nMAG. Further 
>> extensions/modifications. By now, the zig-zag is the price to pay 
>> for immediate delivery of the multicast traffic.
>>
>

I think that pMAG-assisted handover would take just (RTT(nMAG-LMA)/2) 
because it is not required any message in the direction nMAG -> LMA. 
The encapsulated multicast flow goes follows the direction LMA -> nMAG 
withou any previous signalling message in the reverse direction.

> Now I hopefully have met your draft entirely ;)

Thanks again for your comments

Best regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 25 Oct 2009 23:36:22 +0100

Hi again Luis,

  ... and some quick replies, likewise for clarification:

> words, the scenario (b) can be seen as a particular case of scenario (a).

No: Scenario (a) describes native multicast routing throughout the PMIP 
access network, while scenario (b) is built upon dedicated (unicast) 
tunnels (*MAG-LMA_mcast) for multicast traffic forwarding. These two 
cases are quite distinct - and I believe it is important to explicitly 
state what exact scenario your draft addresses.

> because it is not required any message in the direction nMAG -> LMA. The 
> encapsulated multicast flow goes follows the direction LMA -> nMAG 
I guess you would need a Proxy Binding Update (from nMAG to LMA), so 
that completes the RTT.

Best regards,

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 26 Oct 2009 11:15:01 +0100

Hi all,

please find our input for this request:

[Proposal description: ]
This draft defines a comprehensive architecture for multicast traffic 
delivery in a PMIPv6 domain without any protocol modifications or 
extensions. The draft extends existing proposals in three ways:
1) The draft provides an integrated vision of multicast service 
delivery together with unicast standard process according to RFC5213. 
This draft establish that every MN demanding multicast services should 
be previously registered in the PMIPv6 domain based on a unicast IP as 
described in RFC5213. Furthermore, any MLD message originated by the MN 
will be discarded by the network until the registration process is 
finished, and/or once a detachment procedure is initiated.
2) It is considered the extension of the MAG role to be also a fully 
enabled multicast router, thus allowing for multicast tree 
optimizations and an efficient distribution of multicast contents.
3) A new solution for minimising multicast service disruption on the 
handover event between MAGs is introduced. Basically, it takes 
advantage on the fact that the MN keeps the same IP as it moves in the 
PMIPv6, being always reachable through the LMA. So, the previous MAG 
can be able to temporally forward (via the LMA) a copy of the multicast 
content within an unicast flow towards the new location of the MN, once 
it is registered again in some point of the network. That flow is 
delivered as soon as the MAG is signalled by the LMA with a PBA message.
Identified pros:
- immediate delivery of multicast flow to the new MN location after handover.
- sequential procedure integrating multicast and unicast serive in 
PMIPv6 domains (no multicast signalling is processed until the MN 
unicast registration is done, or after MN deregistration is notified).
- the MAG is not restricted to play only an MLD proxy role.
Identified cons:
- the network temporally supports more traffic (that motivated by 
multicast flow redirection from pMAG to nMAG) to help the MN handover 
process.
- the MAGs need to implement additional functionality.

[Additional functionality required at MAG: ]
Once the previous-MAG receives a Proxy Binding Ack (PBA) message from 
the LMA confirming that the MN has been detached from its 
point-to-point link, it should be able to encapsulate the multicast 
flow in a unicast message addressed to the MN (MN-HoA) and forward it 
to the LMA, which will know the new location when the MN registers 
again. Such flow will be temporally active, so the previous-MAG should 
implement a timer associated to it.
The new-MAG should be able to decapsulate the forwarded flow by 
removing unicast flow headers and delivering the original multicast 
content as is (with multicast source and group addresses).

[Additional functionality required at LMA: ]
No additional functionality is required at LMA.

[Bandwidth usage: ]
Additional bandwith usage in intrinsic to the new method porposed to 
assist MN handover, due that the multicast flow is redirected from 
previous-MAG to new-MAG. This new method implies an additional 
bandwidth consumption in the network per MN. This additional bandwidth 
consumption is temporal to support just the handover process.
This additional bandwidth is needed on the link between (previous and 
new) MAG  and LMA. Once protocol extensions or modifications are 
allowed, signalling messages could be defined to minimize the 
additional bandwidth usage.

[MTU-size: ]
The new solution proposed to support handover through unicast delivery 
of the original multicast flow implies the use of the tunnel between 
the previous-MAG and the LMA, and also between the LMA and the new-MAG. 
The packet format used to deliver the original multicast flow will need 
three IP headers: one corresponding to the external tunnel between MAG 
and LMA, another one corresponding to the internal tunnel between 
previous-MAG and MN, and the last one which is the header of the 
original multicast flow.

[Handover within a MAG: ]
The handover within a MAG has no impact in the network. It is managed 
internally by the MAG.

[Handover between MAGs: ]
The handover between MAGs is as described above.

Thanks,

Best regards,

Luis

> before we meet in Hiroshima.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Luis M. Contreras
Profesor Asociado
Dpto. de Ingeniería Telemática
Universidad Carlos III de Madrid
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Lu, Guang" <[email-masked]>
Date: Wed, 28 Oct 2009 17:00:01 -0400

Hi Thomas, 

Thank you for reviewing our draft and providing comments. Please see our replies embedded below.

Best regards
Guang & Juan Carlos

> From: Thomas C. Schmidt [mailto:[email-masked]]
> Sent: Saturday, October 24, 2009 1:38 PM
> To: Lu, Guang
[Guang-JC] We read the existing drafts. This section meant to explain our view of the basic solutions, as suggested in the charter. It is good that solutions from different drafts are converging.

> MLD report subsequent to re-attachment?
[Guang-JC] All MLD queries were omitted in the figures for simplicity. MN can also send unsolicited reports.

> there is need for a mapping.
[Guang-JC] Since the call flows illustrated one LMA, we showed one LMA only in the architecture figure. We can add another LMA in Figure 1, but that LMA would not be used in the call flows and that might also create confusion.

> [draft-schmidt-multimob-pmipv6-mcast-deployment-02].
[Guang-JC] The tunnel convergence issue, as you said, is a traditional issue with PMIP. Actually the dedicated multicast LMA architecture can help to avoid tunnel convergence, and control the traffic load at LMA. For example, one multicast tunnel can be used instead of multiple unicast tunnels for multicast traffic.

> considerations for fast handovers are still out of scope from the
[Guang-JC] We used a general term of "HO Trigger" to refer to any kind of triggers regarding to HO before re-attachments. These triggers can be in different forms, such as L2 triggers, or a command from the network, etc. We are aware of such discussions within other groups. Our purpose is not to propose such triggers, but to illustrate how such information can be used in PMIP to facilitate HO for multicast services. Also, draft-ietf-mipshop-pfmipv6-09 proposes a tunnel between pMAG and nMAG for traffic forwarding. We propose to pass the control information only, not the data between the network nodes.

> - this again is a brick of a (generally much more complex) fast
[Guang-JC] We wanted to state how the multicast JOIN procedure can be enhanced in general. It can be based on other work, say the fast handover solutions.

> leave mobility operations at the network side.
[Guang-JC] In our view, this does not require the MN to participate in the HO process. It only requires that the MN is "aware" that a new interface is up, which is usually available at a host.

> Thanks for bringing this up!
[Guang-JC] We will be very glad to discuss more with the group in Hiroshima!

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 Oct 2009 09:55:39 -0700 (PDT)

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Sent: Fri, October 23, 2009 5:32:11 PM
> >> PMIPv6 is currently bound to a point-to-point link model, which is actually 
> not very advantageous for group communication. The draft discussed here (in its 
> > There are proposals to run PMIPv6 on shared links such as WiFi. In those 
> proposals (not in draft format but just some ideas), PMIPv6 still works based on 
> point-to-point link model but on the shared link. For example RAs are sent to 
> each MN separately, i.e. point-to-point link is emulated on a shared link.
> > 
> Yes, it is not difficult to imagine PMIP solutions on a shared link model, even 
> though RFC 5213 is bound to PtP links.
> 
> The issue I wanted to point out is that the multicast extension model in charge 
> of this draft is not bound to mechanisms  of the PtP link model - it should 
> transfer to shared link solutions without changes.

I don't know. 

Do you think that MLD Proxy at the MAG can identify and deliver correctly the data packets from LMA to the MN based on possibly arbitrarily assigned link-local addresses (with possibility of high collision) it has in its state?

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 21:47:48 +0100

Hi Guang,

sorry for replying late!

> [Guang-JC] All MLD queries were omitted in the figures for simplicity. MN can also send unsolicited reports.

O.K. - but why should an MN send unsolicited reports? There is no 
motivation for a PMIP MN to do anything different from an immobile node ...

> [Guang-JC] Since the call flows illustrated one LMA, we showed one LMA only in the architecture figure. We can add another LMA in Figure 1, but that LMA would not be used in the call flows and that…

The point I tried to make: you need to consider an explicit association 
between MN and LMA. Otherwise, the MAG does not know where to forward 
reports to ...

> [Guang-JC] The tunnel convergence issue, as you said, is a traditional issue with PMIP. Actually the dedicated multicast LMA architecture can help to avoid tunnel convergence, and control the traff…

Well, the tunnel convergence, or avalanche problem is a well known 
*collection* of occurrences in any home-tunneling mobility approach, not 
only in PMIP. If you want to use a point-to-multipoint tunnel, then your 
access network needs to be multicast capable, but then you can of course 
- see section 5.2.2 in 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09

> [Guang-JC] We used a general term of "HO Trigger" to refer to any kind of triggers regarding to HO before re-attachments. These triggers can be in different forms, such as L2 triggers, or a command…

O.K., interesting.

> [Guang-JC] In our view, this does not require the MN to participate in the HO process. It only requires that the MN is "aware" that a new interface is up, which is usually available at a host.

I don't see this as a matter of opinion: if a link of an IPv6 interface 
comes up, the only standard activity I know of is RtrSol and DAD. Why 
should an MN send a "jast join"? A stationary node wouldn't ...

> [Guang-JC] We will be very glad to discuss more with the group in Hiroshima!

Yes, there certainly are a couple of design choices to be discussed face 
to face. But we can be happy to have so many proposals around - it 
appears as if all possible directions for a solution are under 
observation, now.

Best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 22:01:10 +0100

Hi Behcet,

sorry for answering late.

> Do you think that MLD Proxy at the MAG can identify and deliver correctly the data packets from LMA to the MN based on possibly arbitrarily assigned link-local addresses (with possibility of high c…

Yes, it always can on the basis of PMIP, I believe. If you regard 
section 6.8 of RFC5213, then you see that an LMA needs to take 
precautions of link-local address collisions. Otherwise, the problem is 
already with PMIP, not specifically with Multicast. In addition, address 
collisions on a local link do not appear very likely to me anyway - or 
is there any reason, why several MNs/MAGs should pick a single address 
out of the 2^64 collection?

Cheers,

Thomas

--

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 30 Oct 2009 14:09:30 -0700 (PDT)

> Yes, it always can on the basis of PMIP, I believe. If you regard section 6.8 
> of RFC5213, then you see that an LMA needs to take precautions of link-local 
> address collisions. Otherwise, the problem is already with PMIP, not 
> specifically with Multicast. In addition, address collisions on a local link 
> do not appear very likely to me anyway - or is there any reason, why several 
> MNs/MAGs should pick a single address out of the 2^64 collection?
>

Yes. Proxy Mobile IPv6 protocol ensures there is no link-local address
collision between the mobile node and the mobile access gateways on
any of the access links. Multiple approaches, a simplest requiring a
fixed link-local address of the MAG on all the p2p links in the
entire Proxy Mobile IPv6 domain. This will ensure, the mobile node
once generates a link-local address and completes the DAD procedure,
there will never be collision on any of the links it ends up after
a handoff.

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Oct 2009 14:43:47 -0700 (PDT)

Hi Sri,
  Thanks for your mail :).

I agree with your comment, however PMIPv6's attention is to avoid collision between MAG and MN because they are on the link. I don't think it goes over all MN's, because it is not a shared link where on a shared link, DAD avoids any collisions between MNs.

Regards,

Behcet

----- Original Message ----
> From: Sri Gundavelli <[email-masked]>
> To: Thomas C. Schmidt <[email-masked]>
> Cc: Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Fri, October 30, 2009 4:09:30 PM
> specifically with Multicast. In addition, address collisions on a local link do 
> not appear very likely to me anyway - or is there any reason, why several

---

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Oct 2009 15:05:46 -0700

> I agree with your comment, however PMIPv6's attention is to avoid collision between MAG and MN because they are on the link. I don't think it goes over all MN's, because it is not a shared link whe…

My understanding is you can be sure that all MAGs are using different
link-local addresses, and that no MN has the same link-local address
as any MAG (talking about link-local addresses for use on the link
between MN and MAG).

There is a remote chance that two MNs have the same link-local
address, but then they would be on different links.

Wrt MLD proxy in general, there is no requirement for hosts to have
different link-local addresses as long as they are on different links.

The proxy state is which interfaces it has received MLD reports on for
the different groups. Actually the proxy doesn't even need to care about
individual hosts, unless explicit tracking is desired.

Stig

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 30 Oct 2009 15:09:57 -0700 (PDT)

Hi Behcet,

That is correct. It does not ensure the domain-wide uniqueness of
the link-local address, with all MN's in scope, the scope is always
a MN and the the set of MAG's in that domain where the uniqueness
is established.

Sri