On 6/26/06, gabriel montenegro <[EMAIL PROTECTED]> wrote:
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
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.
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.
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.
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.
OK. Thanks, -Samita
----- Original Message ---- From: Samita Chakrabarti <[EMAIL PROTECTED]> To: Mario Mao <[EMAIL PROTECTED]> Cc: [email protected] Sent: Saturday, June 24, 2006 5:24:38 PM Subject: Re: [6lowpan] Comments about the use of Multicast Ability Hello Mario: > 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. > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
