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

From: "David Rahusen" <[email-masked]>
Date: Wed, 7 Jun 2006 09:48:39 +0200

Hi all,

I'm pretty new to this WG, so please correct me if I've been overlooking
anything.
I agree with Mario, that another protocol or even more complexity isn't
reasonable for low power nodes. But multicast may be a useful solution for
some applications.

In case of different PANs within one network, it is possible to transmit
messages to anyone of a single PAN: Isn't it multicast? We know that all
associated nodes within this PAN are directly reachable by the appropriate
coordinator. The main problem is, to reach this PAN (multi-hop). So my
question is: Is it possible to specify a flag within the header of the
adaptation layer to indicate, whether this message is a multicast message or
not? Therefore this message could be routed and transmitted as unicast to
the appropriate PAN coordinator. In case this flag is set, the coordinator
broadcasts the message within the PAN. Otherwise, the message is directed to
the coordinator itself.

Please let me know if I'm totally wrong or this may be an approach.

Best regards,
David

-----Ursprüngliche Nachricht-----
Von: Ian Chakeres [mailto:[email-masked]] 
Gesendet: Sonntag, 21. Mai 2006 18:01
An: Mario Mao; [email-masked]
Betreff: Re: [6lowpan] Comments about the use of Multicast Ability

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-masked]> 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-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>

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

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

---

From: Mario Mao <[email-masked]>
Date: Wed, 7 Jun 2006 20:22:18 +0800

6LowPANer:

As David mentioned, mulitcast is definitely needed in 6LowPAN. My previous
comments just want to give out some idea about the problem using MAC 
multicast. In the matter of fact, our lab have introduced an controlled flooding 
to solve the IP multicast problem recently.

The flooding way is simple: all IP packet with multicast destination address will
 be encapsuled in an adaptation Broadcast Frame. However, the format of 
adaptation Broadcast Frame is somewhat different from the standard header 
format. The modified format showed below.

                1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | LF|  prot_type    |M|B| rsv   |Payload (or MD/Broadcast Hdr)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As the figure showed, a "B" bit is added(replacing one rsv bit). When the "B" 
bit is set, a Broadcast Field will be included in the frame immediately following
 the LoWPAN header. If there is a Broadcast Field, we will call the 
adaptation frame as a Broadcast Frame. The "Broadcast" field is defined as 
follows

                1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |S|Broad Radius |Sequence Number|Source Address, followed by...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

S: 0 if use EUI-64 address, or 1 if use 16-bit address.
Broad Radius: Broadcast Radius, 7 bits, should be decrement by each 
broadcast relay node, if it is decremented to 0, discard the frame.
Sequence Number: A 8-bit number to identify different Broadcast Frame from
the same source node. The originator will increment the field after each 
sending.
Source Address: The Originator's MAC address.

With the support of the "Broadcast" field, an originator or a relay node will 
send the Broadcast Frame like that: first, deliver the frame to all Coordinator 
and Routers around using MAC broadcast(with the MAC destination address
 set to 0xFFFF, just need broadcast once), then, if there are End Devices in 
the node's neighbor table, unicast the frame to them one by one. Besides, to 
avoid broadcast storm, a Broadcast Record Table will be needed. The table will 
record the Source Address and Sequence Number in "Broadcast" field of each 
received Broadcast Frame after re-broadcasting it first(End Device don't need
 to re-broadcasting). Sequentially, a Broadcast Valid Time will be initialized for 
the newly added Broadcast Record Entry. Then, before the entry is timed out 
(Broadcast Valid Time is decremented to 0), all Broadcast Frame with the same 
Source Address and Sequence Number should be discarded but not relayed.

In practice, with the relatively simple way, the controlled flooding could just 
solve the problem of how to multicasting. We find it still a high-costing method
 to broadcast periodic Multicast IP packet(like Router Advertisement, 
RFC2461). So, more details about the up-layer protocol(especially about 
NDP) need be considered. For example, using an dynamic advertising 
algorithm to reduce the broadcast times.

Hope these ideas will do some help.

Regards,

Mario Mao

----- Original Message ----- 
From: "David Rahusen" <[email-masked]>
To: "'Ian Chakeres'" <[email-masked]>; "'Mario Mao'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 07, 2006 3:48 PM
Subject: AW: [6lowpan] Comments about the use of Multicast Ability

Hi all,

Best regards,
David

-----Ursprüngliche Nachricht-----
Von: Ian Chakeres [mailto:[email-masked]] 
Gesendet: Sonntag, 21. Mai 2006 18:01
An: Mario Mao; [email-masked]
Betreff: Re: [6lowpan] Comments about the use of Multicast Ability

Ian Chakeres

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sat, 24 Jun 2006 17:24:38 -0700

> algorithm to reduce the broadcast times.

Please refer to
 http://www.ietf.org/internet-drafts/draft-chakrabarti-6lowpan-ipv6-nd-01.txt

For the IPv6 neighbor discovery multicast and signaling optimization
 in 802.15.4 networks. Thus we don't need multicast to work to run IPv6
on 802.15.4.
This is simple to implement and does not require much additional code.
This fits well with 802.15.4 network topologies.
We have several presentations of this draft in last IETFs; the wg thinks this
work is important enough to move forward. Please provide your comments.
Will be also interested to find out if anyone is willing to implement
this draft?

Thanks,
-Samita

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 26 Jun 2006 00:35:54 -0700 (PDT)

Does your draft show that one does not need multicast to work for IPv6? Or does it show that
one does not need multicast for ND? Admittedly, perhaps the main motivation to run multicast
is ND, but there may be other reasons to run it as well as broadcast. I think what Mario et al
have been experimenting with is a more general multicast/broadcast facility. Ian also mentioned
this, though he suggested a mechanism (adaptation of MANETs SMF) different from what Mario suggested.
Ian had suggested a sequence number of 16 bits, whereas Mario's experimenting with 8. 

Given that we now have address ranges, we can have different mesh delivery formats apply to
different address ranges. I added some text to limit the applicability of the current mesh delivery
format to cases when the destination address is a unicast address. I don't think we are ready to
fully specify how a broadcast or multicast delivery mechanism should work. This is probably best
done in a separate document. At any rate, I added a format for mesh delivery of broadcast/multicast
packets which just adds a sequence number field, but left the full spec as out of scope.

-gabriel

----- Original Message ----
From: Samita Chakrabarti <[email-masked]>
To: Mario Mao <[email-masked]>
Cc: [email-masked]
Sent: Saturday, June 24, 2006 5:24:38 PM
Subject: Re: [6lowpan] Comments about the use of Multicast Ability

Please refer to

Thanks,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 26 Jun 2006 19:27:44 -0700

> one does not need multicast for ND? Admittedly, perhaps the main motivation

Yes. The latter. 6lowpan-ND draft shows that IPv6 ND can be run in a
non-multicast or non-broadcast network.
I did not mean to say that multicast is not needed at all for 6lowpan network.
In IPv6, AFAIK, multicast is mostly needed for ND purpose including the RA/RS.
However, there are other protocols on IPv6 that require multicast capability.
So, I think researching into multicast capability for 6lowpan is a good idea.
However, the comment was specifically about ND and my mail was answering
that section of the comment. 6lowpan-ND solution is an easy extension to IPv6 ND
and available now.

> Ian had suggested a sequence number of 16 bits, whereas Mario's

MANET SMF multicast is related to multicast routing. MANET is also introducing
something called NHDP (Neighborhood Discovery Protocol) which helps
a node to discover its neighborhood up to 2 hops away.
So, these are different than link multicat capability that IPv6 ND requires for
address assignment and router advertisement and so on.

> packets which just adds a sequence number field, but left the full spec as

OK.

Thanks,
-Samita