Subject: Re: [multimob] Thoughts on PMIP Optimized Routing

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 01 Apr 2011 11:19:06 +0200

Hi Luis, Seil,

some additional remarks marked by [thomas]

On 31.03.2011 23:03, Luis M. Contreras wrote:
> Hi Seil,
> more discussion below:
>
>     "Seil" => You don't see the benefit. why? ISPs are now making a
>     pitch for building and getting their own contents from public
>     broadcasters, cable broadcasters, ... so on. Obiviously, this is
>     inevitable trend to achieve competiveness from other ISPs. That will
>     be getting serious more than now. And as I presented in my
>     slot, this concept is reflected at MBMS architecture of 3GPP SAE.
>     Only appropriate manner needs to be handled between home and visited
>     network. About that, the draft will be updated.
>        In M-LMA, how about local contents?
>
> Luis>> It is just my personal view in this interesting and necessary
> debate opened byThomas. I would like to distinguish two concepts: remote
> content distributed locally, and local content distributed locally. In
> the first case, I don't see the benefit. I think that the simplest way
> to deliver the service is through M-LMA. In the second case, I agree
> that it seems more optimal to use direct routing. But, in my opinion,
> the direct routing can not be consider as the main solution, but an
> ocassional optimization scenario in case the content is local to the
> visited domain (probably the most common is that a MN usually will
> demand contents from its Home Network, because the user maintains a
> service contract its Home Operator). I think it is the same idea than in
> the unicast case regarding the routing optimization: it is an
> optimization case for a more general solution (which I believe it is the
> M-LMA approach).
>

[thomas] The problem with direct routing as a "general solution" is that 
it is unrealistic to assume all multicast traffic, which is globally 
available, is routed directly into an access network of an operator. 
This will most likely only be the case for content streams the operator 
is willing to offer to its customers, e.g., selected IPTV channels ... 
So relying purely on the direct routing might end up with a poor choice 
of content services, in particular with changing offers between access 
network operators.

However, the benefit of local routing in the "remote content distributed 
locally"-scenario seems obvious to me: The operator somehow (CDN, 
PtP-Stream ...) guides the content into its access network and then 
simply turns on multicast routing (this is what wired operators do 
today). This will result in full scaling, no tunnels or extra boxes 
involved and at least optimizes Capex, but typically Opex, as well 
(depending on Mcast route management brains).

The M-LMA, as mentioned many times, is an extra box that needs to handle 
all streams simultaneously and redistribute them via tunnels. This leads 
to a scaling bottleneck, traffic multiplication in the access network 
(including waste of bandwidth) and efforts in semi-manual configurations ...

>       * Coexistence of home/remote content retrieval (e.g., by the base
>     solution) and access from local multicast routing. Thus a MAG would
>     need to distinguish (preconfigured) local group subscriptions from
>     non-local content.
>
>         Luis>> This is not possible with current functionality on MAG as
>         MLD proxy. It is only possible to define one upstream interface,
>         so the operator would be forced to permanently choose between
>         local or remote multicast for all kind of traffic.
>
>     "Seil" => Yes, it's possible. Only one upstream interface is
>     available but "per single MLD proxy instance". So, the choice will
>     not be forced to operators.
>
> Luis>> I don't think so. According to base solution, the MN is
> associated to an MLD proxy instance as a function of the LMA it is bound
> to. That is, the association to an MLD instance is previous to the MLD
> Report processing. So, the MAG doesn't know the required content (local
> or remote) before associating the MN to a proxy instance. As
> consequence, the operator is forced to choose between using an MLD proxy
> pointing to the M-LMA or another one pointing to local MR for all kind
> of traffic, and for all the MNs associated to the same LMA.
>

[Thomas] In my understanding, Luis is correct here. Upstream interfaces 
of RFC4605 MLD proxies cannot distinguish between different groups. For 
one downstream interface you always need to have one single proxy 
instance and this instance only can have one upstream interface. As the 
downstream interface corresponds to a link with an MN, this MN can 
either receive local or remote content.

This is not what we want: we want to distinguish traffic per group, not 
per host. So I guess, a solution for this scenario is not possible using 
a standard MLD proxy function. It is of course easy to achieve by making 
MAGs PIM (SM or BIDIR) routers and configuring RPs per group(-range).

Best wishes,

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: Tue, 5 Apr 2011 12:52:04 +0900

Hi Luis,

Thanks for your comments.

Now, this discussion is getting more interesting.

Please see below "Seil"

2011/4/1 Luis M. Contreras <[email-masked]>

> Hi Seil,
>
> more discussion below:
>
>
>> "Seil" => You don't see the benefit. why? ISPs are now making a pitch for
>> building and getting their own contents from public broadcasters, cable
>> broadcasters, ... so on. Obiviously, this is inevitable trend to achieve
>> competiveness from other ISPs. That will be getting serious more than
>> now. And as I presented in my slot, this concept is reflected at MBMS
>> architecture of 3GPP SAE. Only appropriate manner needs to be handled
>> between home and visited network. About that, the draft will be updated.
>>
> Luis>> It is just my personal view in this interesting and necessary debate
> opened byThomas. I would like to distinguish two concepts: remote content
> distributed locally, and local content distributed locally. In the first
> case, I don't see the benefit. I think that the simplest way to deliver the
> service is through M-LMA. In the second case, I agree that it seems more
> optimal to use direct routing. But, in my opinion, the direct routing can
> not be consider as the main solution, but an ocassional optimization
> scenario in case the content is local to the visited domain (probably the
> most common is that a MN usually will demand contents from its Home Network,
> because the user maintains a service contract its Home Operator). I think it
> is the same idea than in the unicast case regarding the routing
> optimization: it is an optimization case for a more general solution (which
> I believe it is the M-LMA approach).
>

"Seil" => Thank you for your comment. Regarding on remote content retrieval
from home network, that is needed to be clearly presented in our draft. But,
it is one of the issues to be considered in routing optimization item. As
you guess, there are several methods like multicasting gateway, P2P, and so
on... to interconnect home/visited network. But regarding on the methods, as
I said before, it is better to discuss it later in updated our draft.

Merely, what I would like to say, the tunnel convergence problem handled in
current multimob charter comes from "multicast traffic" storm for a
thousands of channels and users. The truth of the matter is how to
effectively reduce and distribute multicast traffic. From that point of
view, local routing concept crucially matters. M-LMA is required to handle a
lot of channels and replicate the packet. It leads to heavy load on M-LMA,
and potentially it has single point of failure. This issue appears much
serious than tunnel convergence.

>> solution) and access from local multicast routing. Thus a MAG would need to
>> distinguish (preconfigured) local group subscriptions from non-local
>> content.
>>
>>>
>>> Luis>> This is not possible with current functionality on MAG as MLD
>>> proxy. It is only possible to define one upstream interface, so the operator
>>> would be forced to permanently choose between local or remote multicast for
>>> all kind of traffic.
>>>
>>
>>  "Seil" => Yes, it's possible. Only one upstream interface is available
>> but "per single MLD proxy instance". So, the choice will not be forced to
>> operators.
>>
>
> Luis>> I don't think so. According to base solution, the MN is associated
> to an MLD proxy instance as a function of the LMA it is bound to. That is,
> the association to an MLD instance is previous to the MLD Report processing.
> So, the MAG doesn't know the required content (local or remote) before
> associating the MN to a proxy instance. As consequence, the operator is
> forced to choose between using an MLD proxy pointing to the M-LMA or another
> one pointing to local MR for all kind of traffic, and for all the MNs
> associated to the same LMA.
>
>

"Seil" => It seems that my response was not enough. First, one upstream
interface is possible per single MLD proxy instance on MN. But several MLD
proxy instance could be operated on an MAG like base solution. It was my
answer.

Regarding coexistence of home/remote content retrieval, it seems to me that
you probably pointed out local source directly connected to MAG as described
in our presentation. But this means optional usage depending on operator's
network. Basically, it is assumed that all the contents (remote/local) are
retrieved from MR.

>
>>  "Seil" => Actually, M-LMA should not be said "LMA" as pointed out in the
>> meeting because there's no PMIP action with a MAG and no information related
>> to MNs. And I wonder only one M-LMA is enough to connect with MAGs in
>> visited domain because M-LMA must be managed by certain operator.
>>
>
> Luis>> I'm not totally agree with this (it is my personal opinion). I think
> that establishing a tunnel following PMIPv6 procedures can be considered a
> PMIP action. Furthermore, all other stuff related with security,
> authentication, heartbeat, load balancing, etc, etc, defined in PMIPv6 can
> be applicable in an straightforward manner. It is true that there is no
> information per MN, but the protocol procedures of PMIPv6 are wider than
> this.
>

"Seil" => I don't think so. Main function of the LMA is to provide session
anchoring to MNs. As you mentioned that there is no information and no
managing per MN, in my opinion, there's no reason to be said "M-LMA". PBU
signal is used for mobility binding or mobility session update for
individual MN. Protocol procedure is a means to an end and it seemed to me
end disappeared. It has the strong impression of "Multicast Traffic
Distributor" rather than "M-LMA". So, this is no longer PMIPv6 tunnel, in my
opinion, I thnink special bearer is correct for multicast traffic delivery.

>
> Regarding the number of M-LMAs per visited domain, I consider possible that
> different Home providers connect to a common Visited Network, each of them
> managing its own M-LMA, and sharing (or not) the MAGs placed in the Visited
> network.
>

>>  "Seil" => In terms of "traffic distribution", hitoshi's approach is
>> better than M-LMA. And local routing is the best among them.
>>
>
> Luis>> I need to study this to provide a comparison.
>
> Thanks all for this enriching discussion,
>
> best regards,
>
> Luis
>

Thanks and your regards,

Seil Jeon

---

From: seil jeon <[email-masked]>
Date: Tue, 5 Apr 2011 13:46:11 +0900

Hi, Thomas,

Thanks for your useful comment.

Please see below "Seil"

2011/4/1 Thomas C. Schmidt <[email-masked]>

> [thomas] The problem with direct routing as a "general solution" is that it
> is unrealistic to assume all multicast traffic, which is globally available,
> is routed directly into an access network of an operator. This will most
> likely only be the case for content streams the operator is willing to offer
> to its customers, e.g., selected IPTV channels ... So relying purely on the
> direct routing might end up with a poor choice of content services, in
> particular with changing offers between access network operators.
>
> locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Stream
> ...) guides the content into its access network and then simply turns on
> multicast routing (this is what wired operators do today). This will result
> in full scaling, no tunnels or extra boxes involved and at least optimizes
> Capex, but typically Opex, as well (depending on Mcast route management
> brains).
>
> all streams simultaneously and redistribute them via tunnels. This leads to
> a scaling bottleneck, traffic multiplication in the access network

"Seil" => I agree this comment as my response to Luis's comment in previous
mail. As I mentioned in previous comment, this is serious issue. In my
opinion, it might be an instance of the biter getting bitten.

> [Thomas] In my understanding, Luis is correct here. Upstream interfaces of
> RFC4605 MLD proxies cannot distinguish between different groups. For one
> downstream interface you always need to have one single proxy instance and
> this instance only can have one upstream interface. As the downstream
> interface corresponds to a link with an MN, this MN can either receive local
> or remote content.
>
> This is not what we want: we want to distinguish traffic per group, not per
> host. So I guess, a solution for this scenario is not possible using a
> standard MLD proxy function. It is of course easy to achieve by making MAGs
> PIM (SM or BIDIR) routers and configuring RPs per group(-range).
>
>
"Seil" => Considering the structure where several sources connect to an MAG,
it could be a good candidate.

> Thomas

Thanks for your useful comment again.

It would encourage the progress of our discussion.

Your regards,

Seil Jeon