Re: [multimob] Comparing the proposals for basic multicast support

["Thomas C. Schmidt" <[e-mail]>]

Hi Guang,

sorry for replying late!

Lu, Guang wrote:

>> Does Figure 3 omit MLD queries, as well? If not, why should a MN send
>> an
>> MLD report subsequent to re-attachment?
> [Guang-JC] All MLD queries were omitted in the figures for simplicity. MN can also send unsolicited reports.
>

O.K. - but why should an MN send unsolicited reports? There is no 
motivation for a PMIP MN to do anything different from an immobile node ...

>> Another remark on presentation: you skip additional LMAs that may be
>> around for other MNs. In doing so, the draft expresses the misleading
>> intuition of a uniquely defined path from MAGs to 'the' LMA - in
>> PMIPv6,
>> there is need for a mapping.
> [Guang-JC] Since the call flows illustrated one LMA, we showed one LMA only in the architecture figure. We can add another LMA in Figure 1, but that LMA would not be used in the call flows and that might also create confusion.
> 

The point I tried to make: you need to consider an explicit association 
between MN and LMA. Otherwise, the MAG does not know where to forward 
reports to ...

>>    Section 4:
>>
>> In this section you contribute the proposal to concentrate all
>> multicast
>> channels on one dedicated LMA. This approach obsoletes a MN <-> LMA
>> mapping at MAGs in the case of multicast and resolves redundant traffic
>> possibly arriving at one MAG. In eliminating the tunnel convergence
>> problem at the MAG, you place the burden at the LMA and may encounter
>> the traditional tunnel convergence problem of a HA in the bi-
>> directional
>> tunneling approach (see
>> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09). The
>> scalability constraint arises from the burden at the LMA to serve
>> \sum_{i in MAGs}{Mcast-Streams-at-MAG_i} simultaneously. A large number
>> of MAGs with various mcast listeners is your problem here, while a
>> large
>> number of MNs attached at one MAG, but associated to different LMAs is
>> the problem of the solution in
>> [draft-schmidt-multimob-pmipv6-mcast-deployment-02].
> [Guang-JC] The tunnel convergence issue, as you said, is a traditional issue with PMIP. Actually the dedicated multicast LMA architecture can help to avoid tunnel convergence, and control the traffic load at LMA. For example, one multicast tunnel can be used instead of multiple unicast tunnels for multicast traffic.

Well, the tunnel convergence, or avalanche problem is a well known 
*collection* of occurrences in any home-tunneling mobility approach, not 
only in PMIP. If you want to use a point-to-multipoint tunnel, then your 
access network needs to be multicast capable, but then you can of course 
- see section 5.2.2 in 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09


>>
>> This section I don't really understand: you call for HO-triggers
>> without
>> specifying them. Do you just speak about L2 triggers at re-attachment?
>> This I believe is independent of multicast, outside the scope of
>> Multimob and solved elsewhere, anyway.
>> Do you speak about a L3 trigger of re-attachment? This actually is
>> present in PMIP with the RtrSol. There is nothing new then.
>> Or do you speak about fast predictive handovers (as indicated between
>> the lines)? Then you should look at
>> http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-09, but multicast
>> considerations for fast handovers are still out of scope from the
>> charter.
> [Guang-JC] We used a general term of "HO Trigger" to refer to any kind of triggers regarding to HO before re-attachments. These triggers can be in different forms, such as L2 triggers, or a command from the network, etc. We are aware of such discussions within other groups. Our purpose is not to propose such triggers, but to illustrate how such information can be used in PMIP to facilitate HO for multicast services. Also, draft-ietf-mipshop-pfmipv6-09 proposes a tunnel between pMAG and nMAG for traffic forwarding. We propose to pass the control information only, not the data between the network nodes.

O.K., interesting.

>> In section 6.2, you consider a "fast join" send by the MN on
>> re-attachment. This actually requires an active participation of the MN
>> in the PMIP HO process - and is violating the key objective of PMIP to
>> leave mobility operations at the network side.
> [Guang-JC] In our view, this does not require the MN to participate in the HO process. It only requires that the MN is "aware" that a new interface is up, which is usually available at a host.

I don't see this as a matter of opinion: if a link of an IPv6 interface 
comes up, the only standard activity I know of is RtrSol and DAD. Why 
should an MN send a "jast join"? A stationary node wouldn't ...

> 
>> In summary, I would extract the "dedicated LMA for multicast" as the
>> valid contribution, which you jointly propose with
>> [draft-contreras-multimob-msd-00]. There should probably follow a
>> discussion on
>>
>>   a) Deployment issues: Would a separate Multicast LMA be a feasible
>> deployment path
>>      that is preferred over multicast traffic arriving through standard
>> LMAs for unicast?
>>
>>   b) Scalability issues: What is the more severe scalability concern,
>> many MAGs being
>>      served by a single LMA (tunnel convergence problem at the LMA), or
>> many LMAs serving
>>      a single MAG (tunnel convergence problem at the MAG)?
>>
>> Thanks for bringing this up!
> [Guang-JC] We will be very glad to discuss more with the group in Hiroshima!
> 

Yes, there certainly are a couple of design choices to be discussed face 
to face. But we can be happy to have so many proposals around - it 
appears as if all possible directions for a solution are under 
observation, now.

Best regards,

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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °