I think that a protocol like SMF (draft-ietf-manet-smf-02.txt) for
non-group based simple multicast would be appropriate for 6lowpan. The
SMF draft deals mainly with duplicate packet detection (DPD). Though
it should be used in conjunction with another algorithm to determine
an optimized relay set.
That brings me to another point, to support mutlicast I think the
adaptation layer should have a sequence number for multicast packets.
This will be used to detect duplicate packets. SMF defines a IPv6 hop
by hop option to assist DPD, this field should be integrated into the
shim layer.
Ian Chakeres
On 5/20/06, Mario Mao <[EMAIL PROTECTED]> wrote:
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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
