Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 02 Feb 2010 23:07:13 +0100

Hi Thomas,

of course, you explain well. Nevertheless you assume that the scenario 
I provide requires new mobility-related signalling, but I think this is 
not necessary the case.

For instance, following the mechanism you describe in your draft for 
the MN handover (figure 2), once the MN attaches to MAG2 in your 
picture, this MAG2 would bind the LMA which serves unicast taffic to 
MN. The next step would be to send an MLD Query to MN, and, after 
receiving the corresponding MLD report, according to the scenario I 
propose, the MAG2 would send the multicast Join message (if the 
multicast content is not already subscribed by any other MN attached to 
MAG2) towards the LMA which serves the multicast traffic to all the 
MAGs in the PMIPv6 domain (called LMA2 in my example in the previous 
mail). As consequence, the LMA2 would start forwarding the content to 
MAG2. The reception of the multicast content by the previous MAG, lets 
call it MAG1, would be finished according to the periodic messages of 
the multicast protocols. The LMA designated to forward the multicast 
traffic remains always the same along the PMIPv6 domain, and the MAGs 
configure their MLD proxy upstream interface towards that LMA. This 
LMA, apart of acting as normal LMA for a subset of the MNs in the 
domain, becomes the Multicast Mobility Anchor for all the MNs in the 
domain.

In other words, the multicast protocols (MLD in this case) could do the 
job for following the MN's movement. I think that no new mobility 
signalling is necessary needed. So, this scenario could cover the two 
objectives that you highlighted (no additional infrastructure for 
multicast, and no additional mobility management procedures for 
multicast).

Do you agree?

Regards,

Luis

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Feb 2010 14:32:11 -0800 (PST)

----- Original Message ----
> From: Luis M. Contreras <[email-masked]>
> To: Thomas C. Schmidt <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, February 2, 2010 4:07:13 PM
> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01
> 
> Hi Thomas,
> 
> of course, you explain well. Nevertheless you assume that the scenario I provide 
> requires new mobility-related signalling, but I think this is not necessary the 
> case.
> 
> For instance, following the mechanism you describe in your draft for the MN 
> handover (figure 2), once the MN attaches to MAG2 in your picture, this MAG2 
> would bind the LMA which serves unicast taffic to MN. The next step would be to 
> send an MLD Query to MN, and, after receiving the corresponding MLD report, 
> according to the scenario I propose, the MAG2 would send the multicast Join 
> message (if the multicast content is not already subscribed by any other MN 
> attached to MAG2) towards the LMA which serves the multicast traffic to all the 
> MAGs in the PMIPv6 domain (called LMA2 in my example in the previous mail). As 
> consequence, the LMA2 would start forwarding the content to MAG2. The reception 
> of the multicast content by the previous MAG, lets call it MAG1, would be 
> finished according to the periodic messages of the multicast protocols. The LMA 
> designated to forward the multicast traffic remains always the same along the 
> PMIPv6 domain, and the MAGs configure their MLD proxy upstream interface towards 
> that LMA. This LMA, apart of acting as normal LMA for a subset of the MNs in the 
> domain, becomes the Multicast Mobility Anchor for all the MNs in the domain.
> 

Sorry but this is getting repetitive.
Can you please refer to the conversation we had with Juan Carlos, Stig and myself on Multicast LMA?

> In other words, the multicast protocols (MLD in this case) could do the job for 
> following the MN's movement. I think that no new mobility signalling is 
> necessary needed. So, this scenario could cover the two objectives that you 
> highlighted (no additional infrastructure for multicast, and no additional 
> mobility management procedures for multicast).

Let me quote Stig here:

Looking at other solutions is interesting, but it is outside the
current charter. Hopefully it is something we can look at in the future.

Regards,

Behcet

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 03 Feb 2010 10:50:59 +0100

> Stig and myself on Multicast LMA?

Hi Behcet,

I personally think that your dual role of carter chair and co-author of 
one of the proposed solutions is not the best position to moderate this 
technical discussion.

Regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 03 Feb 2010 17:11:43 +0100

Hi Luis,

first of all I agree that the solution commonly called "dedicated 
multicast LMA" does not require mobility-specific signaling for 
multicast, provided there is only a single "dedicated multicast LMA". 
There is nothing but multicast joins initiated by queries of the MAGs, 
"mobility" is handled by the dynamics of multicast routing. This is 
actually what was meant by "Remote Subscription" in the original RFC3775 ;)

This is due to a separate multicast delivery layer (provided via 
separate tunnels and the "dedicated multicast LMA" ) which is 
responsible to provide multicast at "the access routers" (called MAGs). 
The solution is in parallel to, but not integrated with PMIPv6.

Thus we previously had this discussion about the name "dedicated 
multicast LMA": actually, this cannot be an LMA with PMIP-specific 
binding states (it could not even maintain them correctly), but rather 
is a multicast Designated Router with some tunnel interfaces.

Correspondingly, I'm personally not convinced about this as an 
independent approach to PMIP multicast, but rather believe that a 
special case is presented, being part of a generic scenario I would call 
"multicast infrastructure present at the access routers" (e.g., MAGs).

IMHO, such a scenario looks like a multicast routing infrastructure that 
reaches MAGs either
  * directly (as presented by Seil), or
  * via MLD proxies (as proposed by Zuniga et al. and by you), or
  * via some Mcast routing protocol (e.g., PIM) that is possibly 
extended by tunnels, or
  * by a (possibly dynamic) mixture using AMT in region without native 
routing

Thus, I would rather look at this range of solutions in a broader sense, 
and may be identify characteristics and implications a native multicast 
infrastructure imposes on PMIPv6 mobility handover performance of 
multicast listeners.

Cheers,

Thomas

Luis M. Contreras wrote:
> Hi Thomas,
> 
> of course, you explain well. Nevertheless you assume that the scenario I 
> provide requires new mobility-related signalling, but I think this is 
> not necessary the case.
> 
> For instance, following the mechanism you describe in your draft for the 
> MN handover (figure 2), once the MN attaches to MAG2 in your picture, 
> this MAG2 would bind the LMA which serves unicast taffic to MN. The next 
> step would be to send an MLD Query to MN, and, after receiving the 
> corresponding MLD report, according to the scenario I propose, the MAG2 
> would send the multicast Join message (if the multicast content is not 
> already subscribed by any other MN attached to MAG2) towards the LMA 
> which serves the multicast traffic to all the MAGs in the PMIPv6 domain 
> (called LMA2 in my example in the previous mail). As consequence, the 
> LMA2 would start forwarding the content to MAG2. The reception of the 
> multicast content by the previous MAG, lets call it MAG1, would be 
> finished according to the periodic messages of the multicast protocols. 
> The LMA designated to forward the multicast traffic remains always the 
> same along the PMIPv6 domain, and the MAGs configure their MLD proxy 
> upstream interface towards that LMA. This LMA, apart of acting as normal 
> LMA for a subset of the MNs in the domain, becomes the Multicast 
> Mobility Anchor for all the MNs in the domain.
> 
> multicast, and no additional mobility management procedures for multicast).
> 
> Do you agree?
> 
> Regards,
> 
> Luis
> 

-- 

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: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Feb 2010 08:29:17 -0800 (PST)

I hereby would like to ask Thomas to remove my name from his draft.

Thank you.

Behcet

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Sent: Wed, February 3, 2010 3:50:59 AM
> Behcet Sarikaya dijo:
> I personally think that your dual role of carter chair and co-author of one of 
> the proposed solutions is not the best position to moderate this technical 
> discussion.
> 
> Regards,
> 
> Luis

---

From: Stig Venaas <[email-masked]>
Date: Wed, 03 Feb 2010 13:00:45 -0800

> multicast, and no additional mobility management procedures for multicast).

As I see it there are two aspects here. If we just look at mobility,
MLD, state on MAG etc. then I think the above describes pretty well both
the "multicast from (unicast) LMA" case, and the "multicast-specific
LMA" case. In fact, I think that if we ignore the upstream interface,
the multicast aspects are identical.

The difference as I see it, is what is the upstream interface. Based on
what the charter says, we should have a solution where it is the tunnel
to the (unicast) LMA of the MN. However, it is only a minor difference,
and I think quite easy, to optionally say that the upstream could be
something else (another LMA (the (unicast) LMA of some other MNs) or a
link to some other multicast router.

I think maybe we could say that it is the same solution, just with a
non-standard/non-default choice of upstream interface.

Regarding multicast LMA, I find it a bit confusing using that name.
The signalling would I think, not be the same as for unicast. E.g.,
you wouldn't have a binding for each of the multicast MNs I think.

I certainly see benefits in using a single upstream interface for all
MNs (as in a single multicast LMA if using that term). Again, referring
to the charter, we should have a basic solution where we use the LMAs
and have same path for unicast and multicast. But as I wrote above, it
is a very minor difference to allow something else. The only difference
I see when implementing it, is how you choose the upstream interface.
And, that you only need one MLD proxy instance if you have the same
upstream interface for all MNs.

Personally I don't see a problem with briefly saying in the basic
solution spec that it may be useful to allow a different choice of
upstream interface or something like that. But it may be better to
have a separate document for a more thorough discussion, like different
alternatives, pros and cons etc. The basic solution should be according
to the charter, and not have any unnecessary complexity.

Stig

> Do you agree?
> 
> Regards,
> 
> Luis
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

---

From: Stig Venaas <[email-masked]>
Date: Wed, 03 Feb 2010 14:04:32 -0800

Hi

I've read through your draft and got some comments.

The discussion in 3.2 on multicast establishment could need some more
details, and may also be a bit inaccurate. Some of this is clarified
and explained better in 3.3.

Regarding MLD. MLD signaling will take place also when multicast
service is not needed, at least for link-local groups. If the MN
needs multicast services (as in receiving non link-local groups),
it will send reports for those. That may also happen before the
MN sends router solicitation.

I think after the arrow for "Unicast Traffic" you should add an
arrow for MLD General Query.

Then the node will send MLD Report (also if it does not need
multicast services). Any reports for non-link local (site-local, global
etc) multicast groups should then be aggregated.

You say the aggregated MLD Report is sent before establishing the
multicast tunnel. But shouldn't this report go through the multicast
tunnel? A multicast router (the LMA here), should receive the report
on the interface where it is to send multicast.

Regarding establishing the multicast tunnel. This tunnel would I
think be created either when the first MN that needs multicast
service arrives, or if it is dedicated for multicast it might make
sense to set it up initially, even before there are any MNs.

3.3 looks fine.

In 3.4 it says:

    One of the main advantages of the proposed architecture of a
    dedicated multicast LMA, and MAGs acting as a Proxy MLD, is that it
    allows a PMIPv6 domain to closely follow a simple multicast tree
    topology for Proxy MLD forwarding (cf., sections 1.1 and 1.2 of
    [RFC4605]).

I guess I agree with this. Alternatively with multiple upstreams,
you would basically have a set of trees. And in our case, the sum of
those would still be a tree... You would then still do 4605, but
multiple instances to handle the different upstreams.

I think the main advantage is that you save bandwidth by having
a dedicated multicast LMA when MNs using different LMAs join
the same group.

You may also say that the total of the resources required on the
LMAs is reduced, at least the total amount of state in the LMAs
may be reduced. The dedicated multicast LMA may get more state
than if it was not dedicated though.

Another big advantage is that not all the LMAs need multicast
capability and connectivity.

I have one question though. With more and more use of VPNs,
private addressing (RFC 1918) etc, and also site-local
multicast. Is it obvious that all MNs should get the same
content on the same group address?

As an example, could it be that one MN (subscribing to a
particular service, or belonging to some other operator
whatever) joins the group 239.255.1.1 to join some specific
content, while another MN should be able to join the same
group to receive something else?

I don't know enough of PMIP usage to say whether that is
a valid scenario or not. But if it is, then I think you
need different LMAs for the two MNs.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 03 Feb 2010 23:57:43 +0100

Dear Juan Carlos, Guang and Akbar,

only today I found time to read and review your draft - sorry for being 
late.

Regarding the general solution of a "dedicated multicast LMA", please 
see my comments sent to Luis today.

A couple comments on section 3.4:

You solely adopted the view of the one extremal case presented in 
http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment 
, namely the case of MNs subscribed to the same multicast group, but 
associated to different LMAs. This is only the one side of the coin.

In this case, it already was acknowledged that a single, common upstream 
router (the DR misleadingly called "dedicated multicast LMA") is 
optimal, provided multicast is tunneled to the MAGs.

However, your wording
   "In general, it can be seen that the extra multiplication of packets
    in the combined unicast/multicast LMA topology will be proportional
    to the number of LMAs, and the number of MNs (in a given MAG)
    associated to different LMAs."
is misleadingly imprecise: In fact, the extra replication of traffic is 
proportional to the number of LMAs that MNs are associated with while 
attached to the same MAG, and while being subscribed to the same 
multicast group. This number should typically be small, as an LMA is a 
highly aggregated entity.

Correspondingly, the multicast tree structure is indeed simplified for a 
single group, but for multiple groups, different trees are in use 
anyway, and the root at multiple LMAs may lead to a better balance of 
multicast traffic in the access network.

A similar argument holds of course for the scaling and avalanche 
problems at the "multicast tunnel router" (LMA2) as already outlined in 
draft-schmidt-multimob-pmipv6-mcast-deployment.

Scaling or efficiency arguments between the two solutions IMHO always 
break down to the question about the ratio of MNs : MAGs : LMAs. 
draft-zuniga-multimob-smspmip reduces the dependency on LMA 
multiplicities, while draft-schmidt-multimob-pmipv6-mcast-deployment 
reduces the dependency on MAG multiplicities. But the common 
understanding of PMIP expects the number of LMAs to be small, while MAGs 
(access routers) may be deployed at higher numbers.

Doesn't it make sense to regard the full picture?

Best regards,

Thomas

Zuniga, Juan Carlos wrote:
> Dear all,
> 
> We have just submitted a new version of draft-zuniga-multimob-smspmip
> including the feedback received from the group at the IETF76 Hiroshima
> meeting and the mailing list.
> 
> http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt
> 
> We look forward to receiving your comments.
> 
> Best regards,
> 
> Juan Carlos, Guang and Akbar
> 
> 
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Thursday, January 14, 2010 5:14 PM
> To: Rahman, Akbar
> Cc: Zuniga, Juan Carlos; Lu, Guang
> Subject: New Version Notification for draft-zuniga-multimob-smspmip-01 
> 
> 
> A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been
> successfuly submitted by Akbar Rahman and posted to the IETF repository.
> 
> Filename:	 draft-zuniga-multimob-smspmip
> Revision:	 01
> Title:		 Support Multicast Services Using Proxy Mobile IPv6
> Creation_date:	 2010-01-14
> WG ID:		 Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> This document describes how multicast mobility services can be
> supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener
> Discovery (MLD) [RFC3810], and Internet Group Management Protocol
> (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for
> multicast listener mobility. It proposes the use of a dedicated Local
> Mobility Anchor as the topological anchor point for multicast
> traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy.
> There are no impacts to the Mobile Node to support multicast listener
> mobility.
>  
> 
> 
> 
> The IETF Secretariat.
> 
> 

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Feb 2010 15:58:41 -0800 (PST)

Hello folks,

  Multicast LMA, Local MR or variations of these aim to support the multicast service independent of mobility. From MN point of view Multicast LMA is not a Local Mobility Anchor. 
  
  Remote subscription as defined in the current charter requires the LMA (certainly the LMA with which MN is registered) to provide the multicast service. This provides a capability to provide unicast and multicast mobility support.

  We are not looking for an optimal solution, just a base solution. In the next steps we might need to identify what is not optimal in the base solution and look for optimizing things. That will come next. Can multicast mobility be not supported some other ways in the above "locally available multicast" approaches (and Many other questions that might come to your mind or my mind)? Maybe so but again that will come next. 

  That said, the base solution may already be providing some good optimizations like avoiding avalanche problem as Jari said in his message. 

Regards,

Behcet

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: "Zuniga, Juan Carlos" <[email-masked]>
> Cc: [email-masked]
> Sent: Wed, February 3, 2010 4:57:43 PM
> Subject: Re: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01
> 
> only today I found time to read and review your draft - sorry for being late.
> 
> Regarding the general solution of a "dedicated multicast LMA", please see my 
> comments sent to Luis today.
> 
> http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment , 
> namely the case of MNs subscribed to the same multicast group, but associated to 
> different LMAs. This is only the one side of the coin.
> 
> In this case, it already was acknowledged that a single, common upstream router 
> (the DR misleadingly called "dedicated multicast LMA") is optimal, provided 
> multicast is tunneled to the MAGs.
> 
> However, your wording
> proportional to the number of LMAs that MNs are associated with while attached 
> to the same MAG, and while being subscribed to the same multicast group. This 
> number should typically be small, as an LMA is a highly aggregated entity.
> 
> Correspondingly, the multicast tree structure is indeed simplified for a single 
> group, but for multiple groups, different trees are in use anyway, and the root 
> at multiple LMAs may lead to a better balance of multicast traffic in the access 
> network.
> 
> A similar argument holds of course for the scaling and avalanche problems at the 
> "multicast tunnel router" (LMA2) as already outlined in 
> Scaling or efficiency arguments between the two solutions IMHO always break down 
> to the question about the ratio of MNs : MAGs : LMAs. 
> draft-zuniga-multimob-smspmip reduces the dependency on LMA multiplicities, 
> while draft-schmidt-multimob-pmipv6-mcast-deployment reduces the dependency on 
> MAG multiplicities. But the common understanding of PMIP expects the number of 
> LMAs to be small, while MAGs (access routers) may be deployed at higher numbers.
> 
> > From: IETF I-D Submission Tool [mailto:[email-masked]] Sent: Thursday, 
> January 14, 2010 5:14 PM
> > To: Rahman, Akbar

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 04 Feb 2010 15:46:57 +0100

Hi Thomas,

just for clarification

> separate tunnels and the "dedicated multicast LMA" ) which is

it can be considered that the same tunnel is used to transport both 
unicast traffic (for the MN subset served by "dedicated multicast LMA") 
and multicast one. This maybe could need a tunnel pre-configuration, of 
course (to prevent that the tunnel is already established even if any 
MN of the subset served by that LMA is present in the network).

Regards,

Luis

---

From: Stig Venaas <[email-masked]>
Date: Thu, 04 Feb 2010 08:31:28 -0800

>   We are not looking for an optimal solution, just a base solution. In the next steps we might need to identify what is not optimal in the base solution and look for optimizing things. That will co…

FWIW, this is how I interpret the charter as well. I wrote something
along these lines a week ago or something.

Stig