Subject: [multimob] Thoughts on PMIP Optimized Routing

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 30 Jun 2011 08:35:40 -0700 (PDT)

Hi all,
  Let us get back to this thread and continue to discuss the issues involved on 
the solutions for tunnel convergence problem.

Currently we have two proposals (somewhat quoting from Thomas' email)
- direct routing (just enable multicast forwarding on MAGs 
assuming MAGs are in the local multicast cloud)  
- home tunneling (just 
perform multicast subscription to one LMA/Multicast DR called M-LMA).

What are the issues? (again quoting Thomas)

* the two operations are mixed
* MN moves between PMIP-domains.

To me the issue is separating unicast and multicast flow paths from the MAG-LMA 
that we have in the base solution.

Can we have a solution that is faithful to the base solution and solves all the 
problems?
 Is such a design feasible? worth looking into?
I am saying this because Mobile IPv6 spec says that if you have multicast 
locally available which corresponds to the local routing solution we have, go 
and use it and does not elaborate much.

Regards,

Behcet
>
>Hi, Thomas,
> 
>Thanks for your useful comment.
> 
>Please see below "Seil"
>
>
> 
>2011/4/1 Thomas C. Schmidt <[email-masked]>
>
>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 ...  
 
"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.

     * 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).
>
>
 
"Seil" => Considering the structure where several sources connect to an MAG, 
it could be a good candidate.

Best wishes, 
>Thomas

---

From: "Romdhani, Imed" <[email-masked]>
Date: Thu, 30 Jun 2011 17:07:28 +0100

Dear all,

In my opinion, there is no optimal solution to this problem as it depends on several constraints:

- The location of the multicast source (Within the home network or elsewhere);
- The scope of distribution;
- The location of the HA or equivalent entity in the home network (closeness to Ingress router);
- The number and the mobility pattern of the mobile receivers;
- and the availability and the accessibility of the same multicast service in visited networks.

Even inside the home network, when the home subscription method is used and both the source and the receivers are located outside, we may have a duplication of tunnels snaking within the home domain and carrying the same content towards remote mobile receivers. These tunnels may take the same route or different routes. In other words, the multicast traffic enters natively the home domain (down to the HA or equivalent) and leaves in tunnel mode (from the same or different egress points) the home domain to the receivers.

So, we may just limit our work by making some suggestions how to improve each specific scenario.

Kind regards,
Imed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 30 June 2011 16:36
To: [email-masked]
Subject: [multimob] Thoughts on PMIP Optimized Routing

Hi all,

Regards,

Behcet

 

 

Best wishes, 
>Thomas
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.

This message is intended for the addressee(s) only
and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. 
Edinburgh Napier University does not accept liability for any loss or
damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. 

Edinburgh Napier University is a registered Scottish
charity.
Registration number SC018373