Subject: Re: [6lowpan] Comments about the use of Multicast Ability

From: gabriel montenegro <[email-masked]>
Date: Sat, 24 Jun 2006 10:20:04 -0700 (PDT)

I also have strong misgivings about adding more functionality like this and look to folks
implementing this (like yourselves) to provide feedback on how practical this all is. At any rate, the
current spec is clear that the multicast support is optional (it is, after all, an optimization).

-gabriel

----- Original Message ----
From: Mario Mao <[email-masked]>
To: [email-masked]
Sent: Saturday, May 20, 2006 4:40:16 AM
Subject: [6lowpan] Comments about the use of Multicast Ability

               Hi all:
      There is some comments about   recently introduced Multicast ability. 
  
    I have read Format-02 document   and the Carsten's mail about addressing map 
  for 16-bit addresses. I think it is a good solution for the address   confusion problem. 
  However, looks like there needs other precondition to make Multicast work   properly
  and effectively in 6LowPAN. 

    First condition is   the MAC filter, as I mentioned in last mail, IEEE 802.15.4
  MAC can't fliter Multicast frame,  the reception and rejection   algorithm are descripted
  as bellow in specification:
- If a destination PAN identifier is   included in the frame, it shall match macPANId or
  shall be the broadcast PAN identifier (0 x ffff).
- If a short   destination address is included in the frame, it shall match either
  macShortAddress or the broadcast address (0 x ffff). Otherwise, if an   extended
  destination address is included in the frame, it shall match   aExtendedAddress.
    According to this algorithm, when the   MAC layer of some 802.15.4 node receive
  a frame with Multicast destination address, how will it judge the frame   should be
  handled but not be discarded? For 802.15.4 MAC PIB could just hold one   64-bits
  EUI-64 address and one 16-bits short address(for node's unicast address),   may be
  the only way to get Multicast frame is to set the MAC sublayer to   promiscuous mode.
  By doing this job, Adaptation Layer could get all of frame arrived in MAC   sublayer
  and filter what it want by itself, including Multicast   frame.
    Unfortunately, the solution for the previous   problem also cause another problem.
  That is how to foward the Multicast frame to right destinations(group   members). The
  document "6LoWPAN Meeting 65 IETF Dallas Format Document changes"
  mentioned following possible method: dumb flooding, controlled flooding and   unicasting
  to the PAN COORDINATOR. As my understanding, all three above still   need
  802.15.4 MAC broadcast and Adapatation Layer broadcast flooding relay to   make
  all possible receiver get Multicast frame. The requirement of Adapatation   Layer
  broadcast flooding relay is because not all of 802.15.4 node will be in the   broadcast
  range of the sender in Mesh Topology, unlike in Ethernet. So, maybe we   should need
  an Adaptation Multicast Route Potocol(like PIM-SM in Internet) to build a   Multicast
  Tree when some node join some Multicast group. After the Multicast tree has   been
  built, node in the tree will know where are the group members in and how to   forward
  Multicast frame to them.
    In the matter of fact, we   could also use the special Multicast address in a much
  simple way, that is just make Adaptation Layer be a Multicast frame filter.   In this way,
  IPv6 Layer will tell Adaptation Layer which Multicast group it has joined,   and
  Adaptation Layer will discard the frame not belong to these groups before   handing it
  to IP Layer. However, if we want the sepcial Multicast address really do   some work,
  controlled forwarding in Multicast Tree may be necessary. Otherwise, node   will fill
  Multicast MAC address in Adaptation or MAC header but could only   broadcast
  Multicast frame to all the node in the PAN.

      Actually, I think 6LowPANers will find a good way to solve the multicast   problem
  eventually. But what I want to say is does it worth? For 802.15.4 MAC don't   support
  multicast, we have to do all the work in Adaptation Layer. In LowPAN node,   resource
  is limited(except energy, memory for code is tight either). If we make the   protocol
  more complex, more code space will be needed. Take the platform we are   using as an
  example, the Freescale MC9S08GB60 MCU has 60K Flash for code,   hardware
  driver and 802.15.4 MAC library(supplied by Freescale) will take at least   33K,
  current Adaptation Layer will take about 12K(including Route and Topology   Maintenance),
  this means only 15K is left for IPv6, NDP and up-layer. For our lab has   implemented
  an IPv6/IPv4 dual protocol stack in ARM platform before, we consider 15K   code
  space is very tight for a reduced IPv6 stack. The point is, if we could   just use MAC
  broadcast to let IP Multicast work well, why not just do it? If we add more   and more
  function to Adaptation Layer, I really worry about a low power and low cost   device
  having the ability to run it.
   
      Thanks.    
  Regards,
   
  Mario Mao 

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan