On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu <[email protected]> wrote: > > [I cut ROLL from the distribution list, because it seems I post too much > on the ROLL list] > > Thanks for the message. I mainly agree with you. I commented on some of the > text, below. > > Eunsook "Eunah" Kim a écrit : > [...] >>> >>> 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? > >>> -is the 6LoWPAN using addressing architecture and longest-prefix match >>> based routing as in the Internet? >> >> Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental. > > > >> >> Although the header compression format is updating in 6lowpan now, you >> can find a basic needs of 6lowpan in the RFC. >> If I shortly explain, an IPv6 Interface Identifier is obtained from >> the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local >> address for an IEEE 802.15.4 interface is formed by appending the >> Interface Identifier to a certain prefix (see Section 6 and Section 7 >> of RFC 4944). With regard to routing, I understand the answer is 'yes' >> in the case of route-over. >> Please kindly let me know if you already checked the RFC and your >> intention from the question was different from my answer. :) > > Yes, thanks for posting rfc4944, I checked it. > > Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or > exact-match (as some VLAN switch protocols do). > > Will the 6LoWPAN addressing architecture be local to the network, or > integrated in the Internet.
RFC4944's HC1 supports both link-local and global addressing i.e. all 128 bits can be carried inline or the elided suffix can be derived from lower-layers. The new HC scheme also supports both types of addressing. > > How is a link-local scoped solicited node multicast address mapped into an > 802.15.4 address? > > rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast address. > > But rfc4291 says a solicited node multicast address has the rightmost 3 > octets as significant (FF02:0:0:0:0:1:FFXX:XXXX). > > Will NS/NA and DAD work ok on these links? > The new HC format can handle this scenario http://tools.ietf.org/html/draft-ietf-6lowpan-hc it supports compression of the Solicited-Node Multicast Address (FF02::1:FFXX:XXXX). >>> -how many interfaces will a 15.4 device have potentially? >>> >> >> Well, currently, as I follow up, one interface only for a sensor node >> in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4 >> + 802.11 or others). > > Well a sensor node which is supposed to do routing with only one interface > will be different than a PC doing routing with two interfaces (the typical > case). > >>> Following are detail questions and comments. I believe they're not as >>> important as the items mentioned above. >>> >>>> 1. Problem Statement >>> >>> Is this _the_ problem statement or should I better go read >>> draft-ietf-6lowpan-problem-08? They differ largely... >> >> First of all, just for your information, draft-ietf-6lowpan-problem-08 >> is now RFC 4919. > > Ok, thanks. > >> The section 1, problem statement of our draft is focusing on routing >> in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including >> a brief requirement as you refered in the below. >> >>>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3]) >>>> briefly mentions four requirements on routing protocols; >>>> >>>> (a) low overhead on data packets >>>> >>>> (b) low routing overhead >>> >>> What is routing more generally? Is it the act a router performs when >>> presenting with a packet, searching in a routing table, maybe exploring >>> its ND structures, maybe sending ND messages and then emitting the packet? >>> >>> Or is it exchanging IP datagrams containing prefixes and metrics and >>> reachability information, such that nodes have a common view of the >>> network paths? >> >> I would say that it include all the functionalities needed for the >> selection of a path from source to destination. >> However, I should be careful use the term 'router' here. >> Although 6lowpan nodes may perform such routing functionality for the >> reachability, it's different from traditional term of 'router'. >> In route-over, they call 6lowpan nodes performing routing as 'routers' >> - One radio hop is a single IP link. >> However, in mesh-under, only one 6lowpan router exists in one 6lowpan >> (ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link. >> To cover the both case, please understand in this way; 6LoWPAN node >> may perform such a 'routing-related functionalities'. >> >>> I think this is worth discussing, in order to better target what the >>> work should follow this problem statement and reqs. >>> >>> Are the low overhead requirements put on the database construction >>> messages? Or on the individual act of forwarding a packet? >> >> I would say 'on both'. > > Ok. > >>>> 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. > >>>> The most significant consequence of mesh-under routing is that routing >>>> would be directly based on the IEEE 802.15.4 standard, > > >> >>> >>> Which 'routing' is directly based on 802.15.4 standard? The 'IP >>> routing' is based on that standard? This brings back to defining what >>> routing is. >>> >> >> Ah~ I think we should change the wording. I meant that the >> requirements of 6lowpan routing inherit the stringent characterisitcs >> of 802.15.4. I will change the text to make it clear. Thanks. :) > > Sure. > >>> Maybe better call 'mesh-under routing' 'mesh-under switching'. >>> >>> IP routing and addressing may be fundamentally different than mesh-under >>> addressing and switching - in the way hosts get and maintain their >>> addresses and in the way routers/switches search their databases (exact >>> match vs longest-prefix). >>> >> >> Agreed. Either term is okay by me. Just due to the specific >> characteristics of 6lowpan configuration, >> multi-hop path selection can be achieved in mesh-under. I will ask >> others if mesh-under switching is better to be clarified. > > Ok. > >>>> When a route-over protocol is built in the IPv6 layer, the Dispatch value >>>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or >>>> uncompressed IPv6, followed by the IPv6 header. >>> >>> Sorry, I can't parse this. >>> >>> A route-over protocol would act both at IP layer and >>> application/transport layers. Depends what a routing protocol is. For >>> example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is >>> over UDP. >>> >>> 'followed by'... when reading left to right or reverse? >>> >> >> When I read the text again, it can be confusing. I will try to rephrase it. >> 6LoPWAN provides compressed or uncompressed IPv6 header. >> It just wants to explain the relationship between 6lowpan header and >> routing header. >> You will get the information from RFC 4944. > > Ok. > >>>> For route-over, a default route to the ER could be inserted into the >>>> routing system. >>> >>> In the routing system of the 6LoWPAN network? Or in the routing system >>> of the fixed Internet network? >> >> 6lowpan. I will also try to rephrase it to be clear. thanks. :) > > Sure, it answers my question. > >>>> IP-based low-power WPAN technology is still in its early stage of >>> >>> 'WPAN'? >>> >> wireless personal area network. >> 6lowpan = IPv6 over Low power WPAN. But, actually i think it's better >> to just use 6LoWPAN, to keep the consistancy of the document. >> I will change it. > > Ok, I meant to say WPAN surprisingly appears there first, without explanation. > >>>> 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. > >>> Density sounds as a physical characteristic (many devices in a small >>> area) whereas Diameter sounds as a pure IP term (max number of IP hops). >>> >>> The number of entries in the routing table mostly depends on the planned >>> addressing architecture. One can have a very high-diameter network with >>> a very hierarchical addressing structures, many default routes, and very >>> few entries in the routing tables (maybe only 1 per hop). >>> >> >> I fully agree with you. I will discuss woth co-authors and modify the >> text, since in the case of appropriate hierarchical addressing >> structures, what the text of the draft says may not be true. > > Sure, thanks. > >>> Is the addressing architecture for 6LoWPAN networks planned? >>> >>> Is the addressing architecture following the Internet model? >>> >> >> can be both, i think. It's dependent on 6lowpan scenario. >> >>>> b. Node Parameters: >>> >>> How many interfaces does a 6LoWPAN node typically have? This is of >>> paramount importance deciding whether any type of repeating/bridging >>> needs to happen. >> >> In my view, currently one interface for 15.4, for normal 6lowpan nodes. > > This is a distinguishing characteristic, routing with only one interface. > >>>> * Throughput: The maximum user data throughput of a bulk data >>>> transmission between a single sender and a single receiver through an >>>> unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows >>>> [19]: [...] >>>> >>>> In the case of 915 MHz band: >>> >>> Sorry, for my clarification: is 915MHz the width of band centered on >>> the 2.4GHz mentioned above? Or is it the central frequency (thus >>> replacing the "2.4GHz" mentioned above)? >> >> it is the central frequency. > > Ok. > >>>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by >>>> the efficient use of control packets (e.g., minimize expensive multicast >>>> which cause broadcast to the entire LoWPAN) and by the efficient routing of >>>> data packets. >>> >>> YEs, but multicast may be more efficient than broadcast - is it >>> sufficient? I think it is sufficient to rely on multicast and avoid >>> unnecessary duplication such as in broadcast. >>> >> >> multicast may be more efficient. However, 802.15.4 does not support >> multicast. >> for 6lowpan's view, IP multicast is expensive in terms of energy usage >> for 6lowpan nodes. > > Ok. > >>> 'Efficient routing of data packets' - is it also efficient search in the >>> routing table? That may be part of 'routing' too. >>> >> >> Good point. :) >> >>>> possibliy >>> >>> Nit: iy >> >> thanks. ;) >> >>>> [R03] 6LoWPAN routing protocol control messages SHOULD not create >>>> fragmentation of physical layer (PHY) frames. >>> >>> Err... I think PHY frames aren't fragmented... not sure I understand >>> this requirement? >>> >>> Sounds as if one wants an UDP control packets to not be sent in several >>> pieces, because of overhead involved fragmenting/reassembling. >>> >>> Then make sure first IP doesn't fragment. >>> >> >> It means 6lowpan packet should not occur fragmentation. text will be >> modified to make it clear. thanks. >> >>>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE >>>> 802.15.4 frame size [81bytes]. >>> >>> Is this a requirement on the mesh-under link-layer switching protocol? >>> Or on the 'route-above' protocol? If the latter - I think this >>> requirement is a violation of layer independence :-) >>> >>> It sounds very special to me to limit the size of the messages of an IP >>> routing protocol. >>> >>> Knowing that IP can fragment too. >> >> Yes, I know your argument. :) But it's 6lowpan specific requirement, >> and as I know many 6lowpaners are agreed on this one. I got a comment >> from one roll routing requirement author that this requirement can be >> considered in roll as well. I may make a chance to see you to explain >> some detail of 6lowpan before the meeting, if you are interested in? >> ;) >> >>>> [R05] The design of routing protocols for 6LoWPANs must consider the >>>> end-to-end latency requirements of applications and IEEE 802.15.4 link >>>> latency characteristics. >>> >>> 'Routing'? Or 'Transport'? end-to-end is what Transport typically >>> takes care of, not routing. >>> >>> If Routing: which routing? The forwarding ahppening at a node? Or the >>> convergence time? The exchange of routing messages? >>> >> >> Erm.. maybe we should consider your comments more deeply. Carles, one >> of the authors suggested to remove 'end-to-end' from the text. The >> text meant all the mechanisms that are used to perform routing >> functions. > > I agree. > >>>> Some routing protocols are aware of the hop count of a path. >>> >>> I think all of them are, no? >> >> The text is to explain that simple hop-count is not enough for >> 6lowpan. There exist Link quality based routing metrics than number of >> hops. > > Ok. > >>>> In homes, buildings, or infrastructure, some nodes will be installed >>>> with mains power. Such power-installed nodes MUST be >>> >>> If they have mains power - will they use Power-Line Communications? >>> >> >> Not necessarily. For communication with sensors/actuators, 802.15.4 >> radio communication is used, but supported by affluent power instead >> of small battery.. >> >>>> Building monitoring applications, for instance, require that the mobile >>>> devices SHOULD be capable of leaving (handing-off) from an old >>>> network joining onto a new network within 15 seconds [17]. >>> >>> Should such a mobile device change its IP address or is it free to >>> change it? >>> >> >> Actually, I don't aware such a case that 6lowpan nodes need to change >> the IP address yet. >> We just give the example of ROLL documents which are targeting >> specific applications, to explain some relavent work. > > Ok. > >>>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns; >>>> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid >>>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN. >>> >>> It's called multicast at link-layer too (802.3); thus it avoids >>> unnecessary packet duplication, thus it avoids duplication of >>> broadcasted packets and thus avoids excessive traffic. >>> >>> If we talk IPv6 and recent link layers then I mostly forget the term >>> 'broadcast' and use multicast instead. >>> >> >> As I explained before, we would like to avoid IP multicast. I will >> revise the text to make it clear as 'IP multicast'. >> >>>> 6LoWPAN routing protocols should be designed with the consideration of >>>> forwarding packets from/to multiple sources/destinations. >>> >>> Sorry, what do you mean? An IP packet with multiple src fields? >>> >> >> No, it means that some applications may have multiple sources that >> transmit data to one destination; or a single source may transmit data >> to several destination nodes; etc. > > That's much clearer. > >>>> Current WG drafts in the ROLL working group explain that the workload >>>> or traffic pattern of use cases for 6LoWPANs tend to be highly >>>> structured, unlike the any- to-any data transfers that dominate typical >>>> client and server workloads. >>> >>> Sorry, what do you mean by 'any-to-any' data transfers? Any >>> relationship to 'IP anycast'? >> >> No. but if IP anycast is used, it will be one way to implement >> any-to-any data transfer. >> >>>> [R14] 6LoWPAN protocols SHOULD support secure delivery of control >>>> messages. A minimal security level can be achieved by utilizing AES- >>>> based mechanism provided by IEEE 802.15.4. >>> >>> Isn't AES superstrong and thus computation intensive and thus >>> energy intensive? >>> >>> Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in >>> constrained environments. >>> >> >> The IEEE 802.15.4 specification mandates support of AES. So, it is >> given as an example of secure mechanism utilized from 802.15.4 >> features. >> >>>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >>>> messages. >>> >>> ND doesn't send Hello messages, but NS, NA, RS and RA. >> >> Ah~ Good point. we will make it clear for the revision. >>>> >>>> [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. > > Alex > > >>> Nit: 'MAC sub-layer' appears only once and in the figure they're >>> all 'layers'. >>> >>> Alex >> >> Thanks. we will change it. ;) >> >> Thank you very much to spend your time to review the documents. >> We will gather a bit more comments and will soon post the revision >> applying your comments. >> Your comments are always appreciated. :) >> >> Best Regards, >> -eunah >> >> >>> _______________________________________________ >>> Roll mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/roll >>> >> > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan Regards, Hamid _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
