Subject: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 14 Jan 2010 18:59:39 -0500

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: <[email-masked]>
Date: Mon, 18 Jan 2010 16:15:21 +0100

Dear Juan Carlos, Guang and Akbar,

Thank you for submitting a revised concise version of your draft. By using a similar reference scenario as Thomas the direct comparison between different approaches is greatly simplified.

I am not sure whether a single Multicast-LMA really simplifies the tree structure so much for application of RFC4605 and MAG as MLD proxy (sect. 3.4) because for each MN-LMA association (which remains fixed throughout a connection if I remember correctly) there is therefore also only one LMA for the actual MAG to choose. So for each MLD-proxy instance it looks like a simple tree structure ... And for each MAG like several trees

But this relation is the reason for successful replication minimization - if I apply your consideration of Fig. 4/5 to the scenario of Thomas' evaluation (draft I-D.schmidt-multimob-pmipv6-mcast-deployment)  with 1 Mio MNs, 200 MAGs and 4 LMAs plus an additional Multicast-LMA then setting 1 (1 Mio. distinct group subscriptions) results in same traffic for both scenarios (4 Mio packets), but for setting 2 (all subscriptions to same group) it adds up to 1000805 vs. 1000202 packets, in favour of the dedicated Multicast-LMA. (I hope the calculation is correct and obvious ;-))
 
What remains still open for me is the issue of stream replication leverage (for scalability reasons) which seems difficult to achieve for the dedicated Multicast-LMA approach.

Just my 2 c(omm)ents.

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Zuniga, Juan Carlos
Gesendet: Freitag, 15. Januar 2010 01:00
An: [email-masked]
Betreff: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01

Dear all,

Best regards,

-----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 

Abstract:

The IETF Secretariat.

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

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 19 Jan 2010 17:23:01 -0500

Hi Dirk,

Thank you for your valuable comments and questions.
We have some answers below.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, 18 January, 2010 10:15 AM
> To: Zuniga, Juan Carlos
> Cc: [email-masked]
> Subject: AW: [multimob] FW: New Version Notification fordraft-zuniga-
> multimob-smspmip-01
> 
> Thank you for submitting a revised concise version of your draft. By
> using a similar reference scenario as Thomas the direct comparison
> between different approaches is greatly simplified.
> 
> I am not sure whether a single Multicast-LMA really simplifies the
tree
> structure so much for application of RFC4605 and MAG as MLD proxy
> (sect. 3.4) because for each MN-LMA association (which remains fixed
> throughout a connection if I remember correctly) there is therefore
> also only one LMA for the actual MAG to choose. So for each MLD-proxy
> instance it looks like a simple tree structure ... And for each MAG
> like several trees
> 

In our draft (sect 3.4) we stated that the single Multicast-LMA
architecture "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]".  To be more explicit, we meant to refer to, for
example, the following from [RFC4605, section 1.2] - "There are no other
multicast routers except the proxy devices within the tree, and the root
of the tree is expected to be connected to a wider multicast
infrastructure".

So our view of the single Multicast-LMA architecture, is that it maps
nicely to RFC4605, in that there is clearly only one root for the
multicast tree per PMIPv6 domain (namely the single Multicast-LMA).  And
obviously each MAG will connect back only to this single root of the
single Multicast-LMA.  Finally, each of the MAG-to-(single Multicast
LMA) tunnel interface defines an MLD proxy domain at the MAG, containing
all downstream links to multicast MNs.

Does this clarify your point about "And for each MAG like several
trees"?

> But this relation is the reason for successful replication
minimization
> - if I apply your consideration of Fig. 4/5 to the scenario of Thomas'
> evaluation (draft I-D.schmidt-multimob-pmipv6-mcast-deployment)  with
1
> Mio MNs, 200 MAGs and 4 LMAs plus an additional Multicast-LMA then
> setting 1 (1 Mio. distinct group subscriptions) results in same
traffic
> for both scenarios (4 Mio packets), but for setting 2 (all
> subscriptions to same group) it adds up to 1000805 vs. 1000202
packets,
> in favour of the dedicated Multicast-LMA. (I hope the calculation is
> correct and obvious ;-))
> 

We agree with your calculation and we had the same conclusion. 
 
For setting "1. All MNs participate in distinct multicast groups",
combined Unicast/Multicast LMA (draft-schmidt) and dedicated multicast
LMA (draft-zuniga) have the same traffic. 
For setting "2. All MNs join the same multicast group", dedicated
multicast LMA is better since it reduces the number of replications. 

Based on the above analysis, the tables in Appendix B of draft-schmidt
could be extended to include the extra information as follows:

Setting 1:
The combined Unicast/Multicast LMA have 4 LMAs, each with 250,000
streams, so on the network side, it is the same as dedicated multicast
LMA, which has 1,000,000 streams at the dedicated LMA.
 
+===================+================+===================+==============
=========
         | PMIP multicast    | # of redundant | # of sim. streams |# of
sim. Streams      |
         | scheme            | streams at MAG | at each LMA/LMA-M |in
network for all LMAs|       
 
+===================+================+===================+==============
=========|
         | Combined Unicast/ |          0     |      250,000      |
1,000,000         |
         | Multicast LMA     |                |                   |
|
 
+-------------------+----------------+-------------------+--------------
---------+
         | Dedicated         |          0     |    1,000,000      |
1,000,000         |
         | Multicast LMA     |                |                   |
|
 
+-------------------+----------------+-------------------+--------------
---------+

Setting 2: 
Due to the traffic replication at MAG, the combined unicast/multicast
LMA produces a total of 800 streams between all LMAs and MAGs. The
dedicated LMA configuration only requires 200. 
 
+===================+================+===================+==============
=========
         | PMIP multicast    | # of redundant | # of sim. streams | # of
sim. Streams     |
         | scheme            | streams at MAG | at each LMA/LMA-M |in
network for all LMAs|
 
+===================+================+===================+==============
=========|
         | Combined Unicast/ |          4     |           50      |
800            |
         | Multicast LMA     |                |                   |
|
 
+-------------------+----------------+-------------------+--------------
---------|
         | Dedicated         |          0     |          200      |
200            |
         | Multicast LMA     |                |                   |
|
 
+-------------------+----------------+-------------------+--------------
---------+

Best regards,

Juan Carlos, Akbar and Guang

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jan 2010 14:41:27 -0800 (PST)

Hi Juan Carlos,

----- Original Message ----
> From: "Zuniga, Juan Carlos" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Tue, January 19, 2010 4:23:01 PM
> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01
> 
> Hi Dirk,
> 

Just a reminder: Multicast-LMA separates MN from its LMA, so it is not remote subscription. As we discussed in some earlier thread on the list, there are problems arising from deviating from remote subscription. That's why the charter requires the work to employ remote subscription.

Regards,

Behcet

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 20 Jan 2010 15:47:00 -0500

Hi Behcet,

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Tuesday, 19 January, 2010 5:41 PM
> To: Zuniga, Juan Carlos
> Cc: [email-masked]
> Just a reminder: Multicast-LMA separates MN from its LMA, so it is not
> remote subscription. As we discussed in some earlier thread on the
> list, there are problems arising from deviating from remote
> subscription. That's why the charter requires the work to employ
remote
> subscription.

As previously discussed, the Multicast-LMA approach is actually
following remote subscription:

http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html 

- the term "Remote Subscription" as defined in the literature (-> see
problem statement) was coined as counterpart to "home subscription"
(HA-Tunneling). All the approaches we have been discussing in Hiroshima
are of type "remote subscription".

Regards,

Juan Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Jan 2010 13:20:07 -0800 (PST)

Hi Juan Carlos,

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Wed, January 20, 2010 2:47:00 PM
> Subject: RE: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01
> 
> Hi Behcet,
> 
> 

You should see my reply to that message in which I added another qualification which was bi-directional tunneling. 

You are taking it out of context.

The point is this: Multicast-LMA does not actually have to an LMA. It is in fact an upstream multicast router, so LMA is a misnomer for that entity. This means that mobility of MN is not handled by the entity, i.e. MN's LMA which is unicast LMA in your draft. The charter is very clear on this.

IGMP/MLD Proxy is remote-subscription if the unicast and multicast traffic of MN are handled by the same LMA. You have to support many LMAs because MNs may have different LMAs, e.g. due to roaming.

We discussed this in a later thread with Thomas already you can check the archive.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Jan 2010 13:31:24 -0800

>> are of type "remote subscription".

There is some confusion regarding "remote subscription" as I see it. I
believe it is generally used as a counterpart to "home subscription" as
you say.

My understanding is then that in PMIP, the (unicast) LMA can be thought
of as the HA. If we then use the (unicast) LMA also for multicast, then
that should probably be called "home subscription".

While using some other infrastructure, e.g. the access network
infrastructure (or say a tunnel to some other router than the (unicast)
LMA), would then be "remote subscription".

However, in the charter, it says:

    The work will employ the remote subscription model. This is a
    mechanism by which a mobile node joins a multicast group and receives
    multicast data forwarded via the local mobility anchor.

I think "remote subscription" may not be correct here (at least with
the definitions discussed above), but the second sentence is pretty
clear.

I think when "remote subscription" was used in the charter text, it
might have been as a counter part to "local subscription". As in,
not using the local infrastructure (e.g. the access network), but
rather something remote.

It would be a good idea if we all used the same terms. I think it is
pretty clear what the intention of the charter text is though.

Of course I was not involved in writing the charter texts, so I would
be happy to be corrected if my understanding is wrong.

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 20 Jan 2010 23:12:20 +0100

Hi Stig & Juan Carlos,

> be happy to be corrected if my understanding is wrong.

 From my understanding you are both perfectly right: the general term in 
the literature was somewhat abused in the charter text. However, this is 
not a real complication, since - as Stig pointed out - the dedication of 
the charter text is clear: it tried to avoid restriction to the trivial 
solution, where multicast routing is done in parallel to PMIP.

 From that perspective, I don't see a point for disagreement here. A 
"home subscription" or bi-directional tunneling between MN and LMA is 
infeasible, as the MN won't cooperate in tunneling. Pure local multicast 
routing (without assistance of MAGs) is infeasible, as well, since the 
MN won't actively renew subscriptions after handoff.

Everything else that uses the PMIP infrastructure correctly is IMHO a 
"PMIP-compliant remote subscription". And within the charter text.

Aside from this: competition is open on the best and most feasible 
solution, not on glorifying the wording of the charter ;)

Cheers,

Thomas

-- 

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Jan 2010 14:48:44 -0800

Behcet Sarikaya wrote:
[...]
> IGMP/MLD Proxy is remote-subscription if the unicast and multicast traffic of MN are handled by the same LMA. You have to support many LMAs because MNs may have different LMAs, e.g. due to roaming.

I agree that the term LMA is not good, if all you are doing is receiving
multicast via a tunnel from a remote router. With the term LMA I think
of it in PMIP terms where I would expect the PMIP protocol to be used
between the MAG and the LMA...

If the MAG is using a multicast router for upstream connectivity, and it
is not the (unicast) LMA, then it is using multicast connectivity
outside of the PMIP infrastructure. Whether that is a local router
physically connected to the MAG or a remote router connected via a
tunnel, is not a significant difference I think.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Jan 2010 15:13:33 -0800

> "PMIP-compliant remote subscription". And within the charter text.

But if you are using the MAG, then the question is where the MAG gets
multicast from. There are several options. But the charter is quite
clear when it says:

This is a mechanism by which a mobile node joins a multicast group and
receives multicast data forwarded via the local mobility anchor.

And when it says "the local mobility anchor", it is clear to me that it
is the LMA unicast is received from. There is (at least currently)
nothing else called LMA in the PMIP architecture.

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

Stig

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 27 Jan 2010 22:53:18 +0100

My thoughts on this:

>>
>> Everything else that uses the PMIP infrastructure correctly is IMHO 
>> a "PMIP-compliant remote subscription". And within the charter text.
>

I think that the limitation on receiving the multicast traffic via the 
LMA is certainly artificial. What is the real benefit obtained with 
this limitation?

I can understand the requirement of remote (or non-local) subscription 
of the multicast traffic as a way of isolating the local network from 
the traffic intrinsics of the home network. But this does not 
necessarily means that the multicast traffic must reach the MN through 
its serving LMA. We can confine the multicast traffic in the PMIPv6 
domain infrastructure withoud being forced to deliver it through the 
MN's LMA. Let me ellaborate more on this.

A certain MAG can be connected to several LMAs, namely LMA1, LMA2 and 
LMA3, for instance. We can consider three different MNs, MN1, MN2 and 
MN3 which are respectively bound to LMA1, LMA2 and LMA3 for the 
forwarding of their respective unicast traffic. But, additionally, we 
can consider that one of those three LMA, e.g. LMA2, is the box in 
charge of delivering multicast traffic for all of the considered MNs in 
the domain, resulting that the multicast traffic for MN1, MN2 and MN3 
reaches the nodes via LMA2. The multicast traffic will be always under 
control of the same MAG serving MN1, 2 and 3.

I think that this idea adheres the charter's spirit of constraining the 
multicast traffic within the PMIPv6 infrastructure entities, while 
opens the possibilities of getting a more optimal solution for 
multicast delivery in PMIPv6 domains.

Regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 30 Jan 2010 23:29:58 +0100

Dear Luis,

Luis M. Contreras wrote:
> LMA is certainly artificial. What is the real benefit obtained with this 
> limitation?
> 
My understanding of this objective and of the charter is that PMIPv6
infrastructure should be taken as granted, as the things that are
deployed, and a multicast service should be enabled just on top of it.
This makes sense from two perspectives:
(i) At first, multicast will come at no additional infrastructure
costs/efforts.
(ii) second, every multicast operation will/must be integrated into PMIP
mobility management; in particular, no additional handover operations
should be required for multicast.

> MN's LMA. Let me ellaborate more on this.

A problem you seem to struggle with arises from this confusion with the
term "remote subscription". Being (somehow) remote is not equivalent to
being integrated into the existing mobility management.

> control of the same MAG serving MN1, 2 and 3.

Yes, but this requires a separate multicast mobility management. If MN1
is associated with LMA1 and receives multicast via LMA2, then its
changing the association with the MAG does not lead to multicast traffic
following the MN to the new MAG (see the problem statement
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09). In fact
for this example, as LMA2 may be serving several MNs (associated with
different LMAs), its MCAST flows could not even be simply redirected.
Instead, a new mobility-related signaling would be needed to initiate or
terminate multicast data transmission from this LMA to all the MAGs.

The idea of the current charter is to identify solutions without this
need. In a sense this charter is quite clever, because the open option
of freely introducing a new control plane would give rise to solutions
that are much more efficient than your thoughts, but much less
compatible with the PMIPv6 unicast routing.

> multicast traffic within the PMIPv6 infrastructure entities, while opens 
> the possibilities of getting a more optimal solution for multicast 
> delivery in PMIPv6 domains.
> 

Yes and no: as stated above, if we were free to define whatever
signaling we wanted, we could design a good multicast layer that is
fully independent of PMIP. However, the idea is to extract a minimal
solution that allows PMIP operators to enable multicast without radical
(but rather minimal) changes to whatever they have put in place.

Could I explain the difference well enough?

Thanks,

Thomas
--