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. 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. [snip..] > > 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 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. > Alex > Thanks again for your valuable comments. I'm working on revision to apply your considerations and comments. :) I will soon upload it. But please feel free to give your opinion in any moment. :) -eunah -eunah _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
