Eunsook "Eunah" Kim a écrit :
Alex, Thanks again. :) I put my answers in line.
Thanks for the message. I mainly agree with you. I commented on
some of the text, below.
Some high-level questions: -is there a requirement to connect a
6LoWPAN network to the Internet?
Do you mean in terms of routing? Or a general view of 6LoWPAN?
The birth of 6LoWPAN is to make the Low-power low rate network
(based on IEEE 802.15.4) look like an IPv6 link.
If you only meant routing, the reachability can be achieved by
mesh routing (or mesh switching in your comment below) or
route-over.
I don't know if it answers your question.
If a network running 6LoWPAN routing system (designed according to
6lowpan-routing-requirements) is connected to the Internet - will
anything break?
Basically, no I don't think so. But, I would like to explain two
scenarios to consider. Let's consider the network like this: (a
6lowpan:A)--(gateway/ER)--(outside ipv6 network:B)
1. mesh-under: every node in A does routing (switching/forwarding/or
other proper term) with MAC address within A. It is not directly do
routing to a node in B. This mechanism is used for this limited
situation, and many existing sensor networks based on 802.15.4 have
been deployed fitting in the concept.
Makes sense to me, providfed the 6lowpanA) network is always connected
at the left of that particular gatewayER, never elsewhere.
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.
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.
I would like to know it helps you to understand better.
Will the 6LoWPAN addressing architecture be local to the network,
or integrated in the Internet.
Both are supported. As Hamid already explained, the current 6LoWPAN
format documents (RFC 4944 and HC1) supports both link-local and
global addressing.
[snip..]
On the other hand, the route-over approach relies on IP
routing and therefore supports routing over possibly various
types of interconnected links (see also Figure 1).
At several places in the draft, when link 'types', device
'types' are mentioned, I'm tempted to believe 6LoWPAN considers
links other than 802.15.4 links? Is it so? Should 6LoWPAN
routing protocol work also with aseptic point-to-point links?
Or are the 'types' limited within the relatively large scope of
802.3 compatible MACs (I believe 802.15.4 and 802.16 to fit
within).
This is of paramount importance in setting the scope.
Oh, link 'type'. ;) Currently 6lowpan is clearly based on
802.15.4, although some talks that 6LoWPAN can run on top of
other radios with similar characteristics. And, for route-over
(as ROLL WG is working on), the benefit which have been insisted
is that the routing mechanism is link-independent. Mesh-under of
6lowpan is 802.15.4 dependent. But I don't know what is 'aseptic'
point to point links.
Sorry, I meant 'aseptic' to say point-to-point links over which ND
is not run actually, no need for ND nor DAD. They have specific
ways in which the IPv6 link-local address is formed. They're often
independent on the link layer technology. PPP over IPv6 (RFC) is
an example.
Oh, we need ND, and you already know the draft. :)
a. Network Properties:
* Number of Devices, Density and Network Diameter: These
parameters usually affect the routing state directly (e.g.
the number of entries in a routing table or neighbor list).
Especially in large and dense networks, policies must
What is 'large' and 'dense'? Is it about physical dimensions?
Or IP dimensions?
It is about physical dimensions.
I think Diameter has a physical sense only if it's a circle. I
don't think networks have a physical shape of a circle. I may be
wrong though.
I also need to check. Maybe Carles (one of the co-authors who works
on routing parameters) can answer it? ;)
[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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
