[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °