Industrial Routing Requirements in Low-Power and Lossy Networks
RFC 5673
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Ross Callon; former steering group member) Yes
I think that this document does quite a good job of describing the requirements in a way that can be understood by a routing expert who is not knowledgeable in industrial networks. Thanks!
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
Here's a solicited review from Thomas Clausen:
The requirements documents present a highly "desirable" set of
properties for routing protocols -- which may not all concurrently be
attainable.
The requirements documents themselves do not try to balance all these
requirements. This balancing is currently with a DT, which is
trying to (i) understand the depth of the requirements and (ii)
understand how to balance these and (iii) make progress towards an
acceptable solution, which may involve not satisfying all requirements
concurrently, but suitable subsets covering all requirements sufficient
for the deployments. The DT seems to be on a good track and making rapid
progress.
The context of "sensors" is well known in the wg, but is not
explained quite as well in the documents as they could be; it might
help justify some of the requirement.
The various roll routing requirement documents lists no less
than 46 "MUST-requirements" and about 30 "SHOULD-requirements".
It s not clear to me that all can be satisfied (individually
or at the same time). Currently, the groups seems to be going
through motions of figuring out "how little can we get away
with doing and still claim to be satisfying the MUSTs". For
example, "can we get away with full-flooding and receiver filtering,
and still say we satisfy the multicast requirements?"
My 10000ft comments are:
The wg is in some respects giving the impression of
chasing a "pie in the sky": essentially, aiming for
zero-control-traffic, zero-state, zero-footprint
zero-cost-algorithms -- while getting full IP routing
(unicast, multicast both), instant convergence,
shortest paths, QoS, managing networks with 10^5
routers .... -- I'd love to be able to design such a
routing protocol.....
This is the distinct impression that reading the
documents gives, when paired with some previous
experience in building wireless routing
protocols. Speaking to the various authors of ROLL wg
I-Ds and the wg in general, gives a different picture,
and it's unfortunate that this is not captured in the
documents.
The "routing requirements" documents could be a good
first-step, outlining the characteristics of the
"ideal" protocol (pretty much as stated in previous
paragraph), but a lot of work is required to try to
arbiter what priorities these "dream properties" have,
such that reasonable trade-offs can be made. The
documents do not really help in making this arbitration
- we've spent a lot of time and effort trying to
understand what the different MUST/SHOULDs really
mean....it's a good exercise as such, but I would have
wished that the process leading to these documents had
gone through that exercise, though.
It seems that ROLL is departing in some important ways
from IP routing, e.g. with hard convergence
constraints, and intimate linking of transport and
"routing protocol events" -- see below. My gut feeling
tells me that it's a layer violation of the dangerous
kind.
My main comment is, that as a protocol smith, the
document doesn't really help me do my job -- I still do
not believe that I could design a protocol in which I
could identify to which extend I'd satisfied or not a
large amount of the "MUSTs" -- there seems to be a lot
of room for / need for interpretation. Which, in my
book, should not be the case for MUSTs. (Are
MUST/SHOULD even appropriate in an informational of
this nature?)
My second-main concern is, that I do (still) not think
that the area that ROLL tries to act within is
well-specified. On the list, there has been a lot of
discussion in the past (pre-SF) where some things were
made clear, e.g. "moores law means smaller, not faster,
sensors", and "resources of all kind -- battery, state,
cycles, net -- are very constrained, thing <4KB
mem". Certainly, if that is the case, the requirements
are closer to "pie in the sky" -- but this document,
and indeed any ROLL document, contains nothing to
either confirm or rebut this.
If anything, then that would be a Good Thing(TM) to
state somewhere clearly?
Details to the industrial routing req. doc:
Document: The routing protocol MUST be able to compute
paths of not-necessarily-equal cost toward a given
destination so as to enable load balancing across a
variety of paths.
..... The routing protocol MUST be able to compute
a set of unidirectional routes with
potentially different costs that are
composed of one or more non-congruent paths.
Comment: It's not clear if this entails that (a form
of) MTR is a requirement (and, if so, how it is
thought done, considering memory constraints), if
the routing protocol is expected to provide
disjoint paths (in Wireless, that's not exactly
trivial to do, considering interference)
Document: The routing protocol MUST route on paths that
are changed to appropriately provision the
application requirements. The routing protocol
MUST support the ability to recompute paths based
on Network Layer abstractions of the underlying
link attributes/metric that may change dynamically.
Comment: I'm not sure what "changed to appropriately
provision the application requirements" means. Nor
the rest of that sentence.
Document: The routing protocol MUST enable the full
discovery and setup of the environment (available
links, selected peers, reachable network). The
protocol also MUST support the distribution of
configuration from a centralized management
controller if operator-initiated configuration
change is allowed.
Comment: "full discovery and setup of the environment"
sounds like it is required to maintain "full
topology" of the network. Which. it would appear,
is in stark conflict with the memory constraints.
It is not clear if this is what is meant, at least
I have not understood it.
The latter sentence indicates that some sort of
"central intelligence" might be charged with doing
RT calculations for everybody and distributing them
to the individual routers. It is not clear to me if
that is the case, but side-discussions seem to
indicate that this is the intent, even if the words
are not written to this effect clearly.
Document: The routing algorithm MUST find the
appropriate route(s) and report success or failure
within several minutes, and SHOULD report success
or failure within tens of seconds. ....
The routing algorithm MUST respond to normal link
failure rates with routes that meet the Service
requirements (especially latency) throughout the
routing response.
Comment: IOW, the Routing Protocol convergence time
must be bounded by some (arbitrary?) number? What
does "reporting success or failure" mean, is this a
transport-issue, an issue of "having paths within
xx seconds, or signaling to the app?" or something
else?
Document: The routing algorithm SHOULD always be in the
process of recalculating the route in response to
changing link statistics. The routing algorithm
MUST recalculate the paths when field devices
change due to insertion, removal or failure, and
this recalculation MUST NOT cause latencies greater
than the specified constraints (typically seconds
to minutes).
Comment: The "SHOULD always" is somewhat at odds with
the "convergence" property. The ROLL wg seems to be
targeting a DV protocol, and the "always be in the
process of recalculating..." strikes me as for a DV
protocol to imply "not converging".
The second part of this text seems directly at odds
with the first, by listing a set of events where
paths are to be recalculated. If so, what does it
mean when it "SHOULD always" be in the process of
recalculating?
What is "the route"?
Document: The routing protocol MUST also support
different metric types for each link used to
compute the path according to some objective
function (e.g. minimize latency) depending on the
nature of the traffic.
Comment: I would assume that this translates into
class-of-service / MTR or some such thing, but
asking [the wg participants] about this, resulted
in a "well, it may not be what we want exactly", so
I do not quite understand what....
Document: The routing algorithm MUST support
node-constrained routing (e.g. taking into account
the existing energy state as a node constraint).
Node constraints include power and memory, as well
as constraints placed on the device by the user,
such as battery life. Comment: Which is it?
Continued ("SHOULD always be in the process of
recalculating the route") CPU-cycle-drain, or
power-conservation?
Comment: The security requirements seem to be hard to
satisfy, given the ressources of the individual
routers.
Document: ...the ROLL routing infrastructure is
required to compute and update constrained routes
on demand, and it can be expected that this model
will become more prevalent for field device to
field device connectivity as well as for some field
device to Infrastructure devices over time.
Comment: Not that I have anything against on-demand
routing, but (i) it's not how IP best-effort is
usually done, (ii) it may put undue strain on the
intermediate routers, or even the src
(buffering). I am not sure that "on-demand" routes
should be a requirement, but could be an element of
a solution?
Document: The routing protocol SHOULD support broadcast
or multicast addressing.
Comment: The "or" leaves me bewilded. If I do
broadcast, is that sufficient?
Document: The routing protocol SHOULD also support the
bandwidth allocation for bulk transfers between the
field device and the handheld device of the
wireless worker.
Comment: If this is 1-1 proximity bulk, then OK - if it
is across-the-network bulk with resource
reservation, then I am again given the supposed
constrained characteristics of the devices and
media, sceptical if this is doable.
Again, I cite that proper QoS is really hard in a
broadcast wireless medium, and that environmental
noise (e.g. a microwave oven) makes it virtually
impossible to do anything but very soft QoS.
Document: The routing protocol SHOULD support walking
speeds for maintaining network connectivity as the
handheld device changes position in the wireless
network.
Comment: This is, interestingly, one of the very very
few places that mobility is mentioned in ROLL
documents. A lot of the other constraints above
becomes orders of magnitude more complex (both
realistically and theoretically) when things aren't
static. I just note that most often the wg seems to
respond with "Ohh, sensors are static, which is why
we do not consider mobility as an important
component in our protocol design". It's a good
thing to have it there, but I am not sure that all
the above can be solved with this present
requirement.
Comment: There're scattered security pieces in the
document. The "limited ressources" that are assumed
are worrying, considering the expectations that are
put up, and considering the limited success we've
had with rtg security in the past. But, a
SEC-AD/SECDIR may be better positioned to comment
on that than I.
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
I agree with Tim's COMMENT about the explicit impact of security issues on a ROLL routing protocol. More generally, the document might be improved by clearer and more explicit separation and identification of the industrial ROLL environment and the requirements derived from that environment for a ROLL protocol. For example, section 4.1 is titled "Service Parameters" (no mention of requirements), but it includes some RFC 2119 terminology requirements in the last two paragraphs. Sections 5 through 9 all include requirements, but only some of them include "Requirements" in the title. As I expect this document is mostly for the use of the roll WG in meeting its charter milestones, the fact that the roll WG has forwarded the document to us for publication implies that it meets their requirements. So, I'm happy to accept the document as is if the WG finds it useful.
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
section 11. Security s/Security/Security Considerations/ s/encrypted with unique/encrypted with statistically unique/ Section 11 also does not explore the implications of these security requirements for the routing protocol itself. This is a more serious omission, and I considered making this a DISCUSS. However, the roll wg has recently indicated that it was ready to begin work on a security framework, and this topic can reasonably be addressed there. I would suggest adding a statement that "Implications of these security requirements for the routing protocol itself are a topic for future work."