Eunsook "Eunah" Kim a écrit :
Dear Alex,
There are misunderstanding, so I would like to clarify them. Thanks.
2. route-over: basically, it should be the same as traditional
IPv6 routing, except the gateway needs to work on
compression/decompression of IP/UDP.. headers.
I was not aware of that constraint. You seem to imply the
'route-over' capability requires the use of Header Compression. I
will have to check the HC 6LoWPAN draft.
Oh, no. ROUTING mechanism WON"T require header
compression/decompression. Routing will be included after IP/UDP, or
where the routing protocol is designed in. I just gave you an example
of 6lowpan network to communicate with non-6lowpan. Just what I want
to say was you need decoding 6lowpan_header for the communication.
It's not the routing role.
Will the 6LoWPAN router use longest-prefix match (as IP
protocols do) or exact-match (as some VLAN switch protocols
do).
In route-over, every intermediate node which performs routing
fucntions is called 6lowpan router. I didn't see a runing
route-over solution for 6LoWPAN yet. In my opinion, it will use
as IP protocols do. (I understand that's the concept of
route-over. I think ROLL people may answer it more clearly) In
mesh-under, generally, one IPv6 router exists in one 6lowpan.
6lowpan nodes in the lowpan will perform routing functions but
not use IPv6 address. Whole 6lowpan is one IPv6 link, and the
IPv6 router of 6lowpan will act as a normal IPv6 router to
communicate with other IPv6 router outside of the 6lowpan, but
the functionality for inside of 6lowpan routing would differ (not
use IPv6 addresses).
I wouldn't call the route-over 'routing' (or perform routing
functions) if it didn't use IP addresses. It's confusing.
Mesh-under doesn't use IP address. Route-over uses IP address. As I
understand, Route-over for LoWPAN or LLNs is the same like other IP
based routing. So far, mesh-under was widely-understood way to make a
multi-hop connection in LoWPAN, and ROLL was born to make IP based
routing for it. So it uses IP address for routing.
I think we're in principle in agreement on this one.
[snip..]
[R18] If the routing protocol functionality includes
enabling IP multicast, then it may want to employ
coordinator roles, if any, as relay points of
group-targeting messages instead of using link-layer
multicast (broadcast).
link-layer multicast no broadcast.
I don't know if 'link-layer multicast' is a proper term when
802.15.4 does not provide multicast.
Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN.
I mean it would be difficult to revive the 'broadcast' concept
back into IPv6 documents, I suppose.
Yes, i also think that it's great if 802.15.4 supports link-layer
multicast. As it does not, 6lowpan wants to avoid IP multicast
which causes link broadcast as much as possible. I should think
what else term can be used instead of broadcast if it is not
acceptable termniology.
Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff'
address, whereas multicast means '33:33:0:0:0:X' address. Anything
different has too many meanings.
I would actually appreciate a lot if this link-layer multicast
requirement went back to IEEE 802.15.4 instead of being addresses
in an IETF draft. It risks being specified for the sake of
specifying it, but implementations may simply go on and not use
neither broadcast nor multicast.
Just some thoughts.
Alex
6lowpan is on 802.15.4, and IP multicast will go all nodes in the
lowpan which is energy-expensive for lowpan nodes.
You mean broadcast (not multicast)?
Broadcast may happen as you say: a broadcast message goes to all nodes
in the lowpan. But multicast happens differently: the multicast message
goes only to the nodes having previously subscribed for it.
The same multicast concept is valid for link-layer and for IP.
In this sense, multicast may be less energy-intensive than broadcast.
I can understand 802.15.4 doesn't provide link-layer multicast, but I
can't understand why.
Thus, i think such a restraint of all-nodes receiving packets is
necessary to be considered when we design a solution for lowpan. And,
in my opinion, this is well-agreed issue for 6lowpaners. (RFC 4944
also mentioned it)
I think there may be a misunderstanding with rfc4944. It is not clear
in rfc4944 whether or not link-layer multicast is available or not in
802.15.4, and whether the rfc4944 adaptation layer provides link-layer
multicast or not, to the IPv6 stack.
If we avoid to say broadcasting issue, can you help me to find how we
contain such a requirement, based on IETF conventional way? :)
Sorry, I don't know precisely :-)
First, I am trying to identify whether a conventional IEEE 802.3
multicast-capable MAC is specified to run somehow over IEEE 802.15.4.
And if yes, then maybe that is all that is needed for an IPv6 stack
running over 802.15.4 links, by reusing more of the rfc2464
IPv6-over-Ethernet.
If not, and if 802.15.4 doesn't want to specify the link-layer multicast
behaviour, then maybe the adaptation layer would specify the link-layer
multicast behaviour.
In all this, I think a liaison person to IEEE 802.15.4 group could
provide advice. Maybe that person is already determined.
Until a working link-layer multicast behaviour is specified for 802.15.4
links, ND can only work as ptp link. And DHCPv6, SLAAC (stateless
autoconf) and OSPF too - only ptp links.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
