Subject: [multimob] FW: PMIPv6 extension for multicast

From: "Seil Jeon" <[email-masked]>
Date: Fri, 22 Jul 2011 15:28:49 +0900

Hi Behcet and folks,

The approach of PIM-SM on a MAG proposed by hitoshi may be one of routing
optimization solutions.. 
However, regarding on the using native multicast infrastructure, several
options may be possible.

A MLD proxy and a MR can be integrated into a one box (MAG) or a MLD proxy
can be separated from a MAG.
Former case is hitoshi's idea, of course it is not a "MLD proxy instance"
but "MLD instance" on downstream of MN-side. Latter case will be our direct
routing solution.

Relating to the tunnel between MR on MAG and MR on LMA, hitoshi uses GRE
tunnel but any tunnel could be used.
In direct routing, if we assume that a MR (MR-1) is placed on LMA, a MR (MR-
2) connected to a MAG can be connected with MR-1 through any tunnel
mechanism.

Except that what kinds of MR protocol we will use or which tunneling
mechanism is more proper, overally they look similar.

So, I would like to discuss about the several options using native
infrastructure.

Best your regards,

Seil Jeon

---------------------------------------------------------
 
Soongsil Univ. Ubiquitous Network Research Center (SUNRC)
 
511 Sangdo-dong, Dongjak-gu, Seoul
 
Tel. +82-2-820-0841
 
Homepage: http://sites.google.com/site/seiljeon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Behcet Sarikaya
Sent: Thursday, July 21, 2011 1:27 AM
To: Hitoshi Asaeda; [email-masked]
Cc: [email-masked]
Subject: Re: [multimob] PMIPv6 extension for multicast

Hi Hitoshi,
If PIM-SM at the MAG and LMA does not require any protocol extensions, then
I think this piece of your draft becomes an alternative to the base
solution.

So this could have been a better "base" solution. Why then we did not
consider it maybe about a year ago?

Regards,

Behcet

> >>>     And if the upstream router is the LMA, the  M-tunnel is
> >>> generated and used for mulicast transmission.   Actualy, the LMA is
> >>> also a direct neighbor of the MAG in this  scenario.  I don't 
> >>> understand the necessity of the  M-tunnel.  The direct routing  
> >>> does not work in this  scenario?  Or the M-tunnel is used for 
> >>> other purposes, like  fast handover?
> >>
> >>I cannot understand the statement, "the  LMA is also a direct 
> >>neighbor of the MAG in this  scenario".
> >>M-Tunnel is a virtual (i.e. tunnel) link. It is used to  make LMA as 
> >>an MAG's neighbor router in the routing protocol.
> > 
> > Here, I am concerned that how the LMA becomes the upstream  router.
> > I think that the LMA is connected with the MAG directly if the  LMA
> > are selected as the upstream router by the RPF algorithm.   If  not,
> > the LMA becomes the upstream router when the MAG has not  neighbor 
> > router that does supports PIM-SM?
> 
> Still I cannot  understand what point you are concerned.
> 
> But let me assume that your  concern is related to the sequence of 
> M-Tunnel establishment and PIM neighbor  discovery.
> 
> If M-Tunnel is not established between LMA and MAG, MAG  cannot 
> discover LMA as one of the PIM neighbor routers according to  
> multicast channel subscription requests given by its downstream nodes
(i.e.  MNs).
> Therefore M-Tunnel must be set up between LMA and MAG prior to  PIM 
> neighbor discovery.
> 
> This is mentioned in section 4 such  as;
> 
>   "M-Tunnel is established between PIM-SM capable LMA and  MAG.  It is
>    established in a bootstrap phase of MAG (without  detecting a
>    multicast channel subscription request from a mobile  node) and kept
>    while the MAG is running."
> 
> Hope this  helps.
> 
> Regards,
> --
> Hitoshi  Asaeda
> _______________________________________________
> multimob mailing  list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
> 
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob