I would like to raise a concern about the Mesh Delivery Field
definition in Section 11 of the format document. While the actual
mesh routing protocol is appropriately outside the scope of the
6lowpan Format document, that format needs provide the raw structure
upon which rough consensus and running code can be flourish. We
know that low power wireless mesh routing is technically tricky and
strongly influenced by target traffic load, power management profile,
network design, and so on. Thus, it is reasonable to expect that the
consensus building and technical refinement process will require
on-going experience with protocol and implementation alternatives.
The 6lowpan format document should support this process, although it
should not dictate its conclusion.
Based on past experience with IP layer 3 routing and with past
internally routed links, we can establish a few primary goals for the
expressiveness of the 6lowpan Mesh Delivery Field.
(1) It should support the visibility into the routed 15.4 cloud
necessary to develop, debug, diagnose, and manage the 15.4 cloud.
(2) It should support the ability to define, develop and compare
routing protocols and possibly support the presence of multiple
protocols for widely differing usage cases.
(3) It needs to be possible for nodes to communicate with other nodes
in the cloud in order to discover and negotiate joining the cloud
without joining the cloud a priori through some mechanism that is
opaque to IP and above.
(1) has historically been addressed through various forms of source
routing. It should be possible to do the equivalent of traceroute
through the 15.4 mesh and this should be accessible in some form through IP so
higher layers can be built to perform the management. The current
Mesh Delivery Field definition seems to prohibit any form of source routing.
It assumes that the routing tables are all set up and correct so that
the forwarder can "swizzle" the destination address field of the 15.4
header with a table entry. (The experience of IP over ATM and the
thousands of pages of the Q83b signalling protocol required to set up
all the tables in advance ought to give us a little pause here.) The
idea of supporting table-driven routing and thereby separating the
route formation from the forwarding engine is a good one, but there
needs to be enough expressive power to support the protocols that will
establish and manage those tables (rather than relying on an opaque
out-of-band signaling mechanism) and there needs to be the ability to
query and validate those tables without relying on out-of-band
mechanisms.
(2) has historically be addressed with protocol identifiers and
options. As we went through the various RIP, OSPF, etc. we didn't
need to go back and redefine the format documents. There was enough
expressiveness for topology formation and routing to evolve. Not all
networks need to support all protocols. That has been the network
designers' determination. The underlying structure provided the
primitives, allowing solutions (and consensus) to evolve. We want to
avoid creating a "winner take all" structure where there is no room
for evolution and development. It is possible that AODV, or TinyAODV,
or DSR, or GPSR or possibly one of several other alternatives is the right
solution. However, there is little evidence of one having clear superiority at
this time, despite numerous high profile efforts. We should be defining the
canvas upon which competing alternatives can be defined and vetted.
(3) has historically been addressed by a limited ability to
communicate on the link to a crudely defined set of nodes in order to
bootstrap the discovery, join, address assignment, negotiation, etc.
Most successful links under IP look either like a broadcast medium or
a point-to-point link (a degenerative broadcast). This allows ARP,
RARP, BOOTP, DHCP, etc. to gain higher level accessibility and
addressibility through the link. Links that require complex
signaling, discovery, joining and coordnation below the link layer,
including ATM, Bluetooth (piconets and scatter nets), and IRDA have
proved onerous for IP and have been relegated to far less general
usage scenarios - such as the desktop USB replacement. Even though
the radio is a broadcast medium, the challenge in a routed link is
that the link is not by default a link-wide broadcast phy. There
are two natural notions of "broadcast" in a lowpan. (i) The physical
neighbors that happen to receive a transmission because they are close
enough to pick up the signal and have their radios turned on to
receive. (ii) The entire collection of nodes that can be reached by a
multihop dissemination (flood). Both of these are extremely useful in
bootstrapping higher levels, including routing, and should be
addressed in the format document. Additionally, it is not
neccessary to use the 802.15.4 beaconing mechanism to bring up IP over
a 15.4 link. Providing some forms of broadcast using data frames
makes the 802.15.4 format much more like 802.11 and other links that
have proved very suitable for IP. Few, if any, of the public 15.4 routing layers developed
by the TinyOS community utilize beacon packets.
The recognition that the current Mesh Delivery field may be to restrictive
is intimated by the need to define a second form of the header for
multicast (and link local broadcast) that includes a sequence number.
The mesh header field type is defined by whether the destination
address is unicast or multicast. The document states that the use of
such a sequence number is out of scope. However, the observation that
that extra information may need to be included depending on how
packets are routed further suggests that more careful format
definition is needed to support future development of mesh routing.
Have folks who have been developing mesh layers for lowpan6 felt that
the existing Mesh Delivery Field is too restrictive?
David E. Culler
UC Berkeley
[EMAIL PROTECTED]
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
