Dear Alex, Thank you very much for your detail comments. I think your comments help us clarify many points on the draft. I'm just about to leave to other town for a domestic biz trip. I will get back to you asap. Thanks,
-eunah On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu <[email protected]> wrote: > [Where should I post this message, to 6LoWPAN or to ROLL list? Both?] > > Dear WG members, > > draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement, > some Scenarios and a set of Routing Requirements. Generally I find it a > well written document, with many meaningful details. > > There are very many parts of this document to which I silently agree, > even some parts I wholehartedly agree. I like the distinction > route-above mesh-under, and many other parts too. > > Some high-level questions: > -is there a requirement to connect a 6LoWPAN network to the Internet? > -is the 6LoWPAN using addressing architecture and longest-prefix match > based routing as in the Internet? > -how many interfaces will a 15.4 device have potentially? > > 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... > >> 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 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? > >> 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. > >> 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. > > 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). > >> 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? > >> 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? > >> IP-based low-power WPAN technology is still in its early stage of > > 'WPAN'? > >> 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? > > 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). > > Is the addressing architecture for 6LoWPAN networks planned? > > Is the addressing architecture following the Internet model? > >> 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. > >> * 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)? > >> [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. > > 'Efficient routing of data packets' - is it also efficient search in the > routing table? That may be part of 'routing' too. > >> possibliy > > Nit: iy > >> [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. > >> 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. > >> [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? > >> Some routing protocols are aware of the hop count of a path. > > I think all of them are, no? > >> 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? > >> 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? > >> [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. > >> 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? > >> 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'? > >> [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. > >> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" >> messages. > > ND doesn't send Hello messages, but NS, NA, RS and RA. > >> [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. > > Nit: 'MAC sub-layer' appears only once and in the figure they're > all 'layers'. > > Alex > > _______________________________________________ > Roll mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
