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
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 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
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
> 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
