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

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 2 Jul 2011 09:43:19 -0700 (PDT)

It will nice to write all these issues in a draft and present them in Quebec.
There is still time to submit such a draft as -00 by Monday night. 
We can have a slot to discuss  it as part of tunnel convergence solutions 
section of our session.

Regards,

Behcet

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

---

From: Stig Venaas <[email-masked]>
Date: Thu, 07 Jul 2011 14:42:14 -0700

On 6/30/2011 9:07 AM, Romdhani, Imed wrote:
> 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 location of the HA or equivalent entity in the home network (closeness to Ingress router);
> - 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.

Right, so looking at the current basic solution vs direct routing, the
choice depends on where the source is and where it can be received.

If you want to receive multicast from your home provider, then the
basic solution would work.

If you want to receive multicast available locally, then the direct
routing would work, hopefully.

If you are visiting another network, you can only receive multicast
from your home provider as direct routing, if they have a multicast
peering.

Looking at the solution of some kind of dedicated router, as in the
so-called multicast LMA. This would work if the different home
providers all have peerings with the one operating the dedicated
router.

These may also be combined. Maybe there is both home and local
content that should be available.

Or something along these lines. So we may need to either pick a
specific scenario and come up with a solution for that, or come
up with a few different scenarios and solutions, and the different
deployments can choose what is right for them.

Stig

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
> Sent: 30 June 2011 16:36
> To: [email-masked]
>    Let us get back to this thread and continue to discuss the issues involved on
> To me the issue is separating unicast and multicast flow paths from the MAG-LMA
> Can we have a solution that is faithful to the base solution and solves all the
> problems?
>> 2011/4/1 Thomas C. Schmidt<[email-masked]>
>>
>> Hi Luis, Seil,
>>>
>> [thomas] The problem with direct routing as a "general solution" is that it is
>> routing might end up with a poor choice of content services, in particular with
>
>>> 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,
>
> mail. As I mentioned in previous comment, this is serious issue. In my opinion,
> downstream interface you always need to have one single proxy instance and this
>> host. So I guess, a solution for this scenario is not possible using a standard
>
> 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.
>
> 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.
> 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.
>