[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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
