[Roll] DT update -- MUSTs

[Tim Winter <[e-mail]>]

WG,

With the recent discussions regarding MUSTs, trade-offs, and how to
reconcile the 4 different requirements documents into one protocol, I do
hope that this update provides some useful insights into how the DT
is proceeding.

Here is a list of extracted MUSTs, with some categorization, along with
uncategorized SHOULDs.

Please do carefully note the following:
        1) The source requirements documents contain much more background
text and detail for interpreting the meaning and intent of the MUSTs than
appears in this summary list.  This summary list is quite simply keyed off
of MUSTs (and SHOULDs) in the requirements documents.  This list can be
used like an index, but the requirements documents give further context
which is important for detailed interpretation, and the requirements
documents are authoritative.
        2) The categories presented here may be considered a very coarse
grouping.  The intent was to begin to place the 4 requirements documents
side by side in a way that is meaningful to begin interpretation, but is
not intended to be a precise taxonomy.  Similarly, please do not place too
much meaning in the category names per se, they are perhaps coarse, but the
intent is that the grouped functionalities are related.  Finally, the
coarse groupings may well produce `overlap' in some cases.
	3) In some places [editorial comments] are added that do not
appear in the original drafts.

The design team underwent an exercise of going through and discussing
these requirements, and at a first cut asked `can this requirement _not_ be
satisfied?'.  This exercise provides further familiarization with the
requirements as well as a crude `reality check' if you will.

So far, no requirement is clearly ruled out, and there is a basis to
continue the discussion of what a routing protocol solution to meet these
requirements will look like.

It is also clear when we look at these requirements that an attempt to find
or meet an intersection between all of them is very challenging.
Nevertheless, it is not our intended approach to pick and choose, e.g. we
do not want to say `let us define a protocol that will satisfy XXX in
HOME, but at the cost of YYY in INDUSTRIAL'.  We are tasked clearly to try
and define _one_ protocol to satisfy _all_ of the requirements.  Perhaps
as the process continues it will become clear and necessary that such a
`hard' trade-off needs to be made to resolve some fundamental conflict, but
it would be very premature to say such things at this point.  If such a
trade-off emerges and becomes inevitable, there will most certainly be very
careful discussion and justification to be made.

This is the inspiration behind the approach we are taking:
        1) define a basic core protocol + optional extensions
        2) allow the protocol to be parameterized
-> such that the implementor has the ability to make appropriate detailed
trade-offs with the guidance of applicability statements as appropriate to
the target application/platform.

It is our hope that by following this approach we have a protocol which
provides a practical and implementable framework in which can be made
proper and measured compromises with respect to different applications.

We do hope not to end up with a duck ;)

More updates to come as the work proceeds.

Regards,

-Tim


---------------------------------------------------------------------------

-  Categorized MUSTs
        Sources:
                draft-ietf-roll-urban-routing-reqs-05.txt
                draft-ietf-roll-indus-routing-reqs-05.txt
                draft-ietf-roll-building-routing-reqs-05.txt
                draft-ietf-roll-home-routing-reqs-06.txt

---------------------------------------------------------------------------


A. General:
-----------
A.1
URBAN:      For the latter [patches/updates], the protocol(s) MUST support
            multi- and any-cast addressing.

A.2
URBAN:      Routing protocols activated in urban sensor networks MUST
            support unicast (traffic is sent to a single field device),
            multicast (traffic is sent to a set of devices that are
            subscribed to the same multicast group), and anycast (where
            multiple field devices are configured to accept traffic sent
            on a single IP anycast address) transmission schemes.

A.3
BUILDING:   Routing MUST support anycast, unicast, and multicast.

A.4
BUILDING:   A network device MUST be able to communicate in a peer-
            to-peer manner with any other device on the network. Thus, the
            routing protocol MUST provide routes between arbitrary hosts
            within the appropriate administrative domain.

A.5
BUILDING:   The routing protocol MUST support a metric of route  quality
            and optimize path selection according to such metrics within
            constraints established for links along the paths.

A.6
BUILDING:   In such cases [sleeping nodes], the routing protocol MUST
            discover the capability of a node to act as a proxy  during
            path calculation; then deliver the packet to the assigned
            proxy for later delivery to the sleeping device upon its next
            awakened cycle.

B. Traffic Flows:
-----------------
                  [        Node -> (thru) LBR  ]
                  [  (thru) LBR -> Node        ]
                  [        Node -> Node        ]

B.1
URBAN:      The routing protocol MUST be able to accommodate traffic
            bursts by dynamically computing and selecting multiple paths
            towards the same destination.

B.2
INDUSTRIAL: 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.

B.3
INDUSTRIAL: 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.


C. Autonomous Configuration/Management/Reliability:
----------------------------------------
C.1
URBAN:      To this end, the routing protocol(s) MUST provide a set of
            features including 0-configuration at network ramp-up,
            (network-internal) self- organization and configuration due to
            topological changes, and the ability to support
            (network-external) patches and configuration updates.

C.2
INDUSTRIAL: 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.

C.3
INDUSTRIAL: The routing algorithm MUST be able to generate different
            routes with different characteristics (e.g. optimized
            according to difference cost, etc...).

C.4
INDUSTRIAL: 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.

C.5
BUILDING:   It MUST be possible to fully commission network devices
            without requiring any additional commissioning device (e.g.
            laptop).

C.6
BUILDING:   Devices referencing data in the replaced device MUST be  able
            to reference data in its replacement without being
            reconfigured to refer to the new device.  Thus, such a
            reference cannot be a hardware identifier, such as the MAC
            address, nor a hard-coded route.  If such a reference is an IP
            address, the replacement device MUST be assigned the IP
            addressed previously bound to the replaced device. Or if the
            logical equivalent of a hostname is used for the reference, it
            must be translated to the replacement IP address.

C.7
HOME:       Thus the routing protocol designed for home automation
            networks MUST provide a set of features including zero-
            configuration of the routing protocol for a new node to be
            added to the network. From a routing perspective,
            zero-configuration means that a node can obtain an  address
            and join the network on its own, without human intervention.

C.8
HOME:       The routing protocol MUST support the ability to isolate a
            misbehaving node thus preserving the correct operation of the
            overall network.


D. Scalability:
---------------
D.1
URBAN:      The routing protocol(s) MUST be capable of supporting the
            organization of a large number of sensing nodes into regions
            containing on the order of 10^2 to 10^4 sensing nodes each.

D.2
URBAN:      The routing protocol(s) MUST be scalable so as to  accommodate
            a very large and increasing number of nodes without
            deteriorating selected performance parameters below
            configurable thresholds.

D.3
BUILDING:   The routing protocol MUST be able to support networks  with at
            least 2000 nodes supporting at least 1000 routing devices and
            1000 non-routing device.  Subnetworks (e.g. rooms, primary
            equipment) within the network must support upwards to 255
            sensors and/or actuators.

D.4
HOME:       The routing protocol MUST support 250 devices in the  network.


E. Performance:
---------------
E.1
INDUSTRIAL: 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.

E.2
INDUSTRIAL: The routing algorithm MUST respond to normal link failure
            rates with routes that meet the Service requirements
            (especially latency) throughout the routing response.  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).

E.3
HOME:       The routing protocol MUST provide mobility with convergence
            time below 0.5 second if only the sender has moved.

E.4
HOME:       Sleeping nodes may appear to be non-responsive. The routing
            protocol MUST take into account the delivery time to a
            sleeping target node. The wake-up interval of a sleeping  node
            MUST be less than one second.

E.5
HOME:       The routing protocol MUST converge within 0.5 second if no
            nodes have moved.

E.6
HOME:       The routing protocol MUST converge within 2 seconds if the
            destination node of the packet has moved.


F. Constraint-based Routing:
----------------------------
F.1
URBAN:      To this end, the routing protocol(s) MUST support parameter
            constrained routing, where examples of such parameters (CPU,
            memory size, battery level, etc.) have been given in the
            previous paragraph.  In other words the routing protocol MUST
            be able to advertise node capabilities that will be
            exclusively used by the routing protocol engine for routing
            decision.

F.2
INDUSTRIAL: 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.

F.3
INDUSTRIAL: 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.

F.4
BUILDING:   The routing protocol MUST take into account device
            characteristics such as power budget.

F.5
HOME:       The routing protocol MUST support constraint-based routing
            taking into account node properties (CPU, memory, level of
            energy, sleep intervals, safety/convenience of changing
            battery).


G. Security:
------------
G.1
URBAN:      The U-LLN network MUST deny any node who has not been
            authenticated to the U-LLN and authorized to participate to
            the routing decision process.

G.2
URBAN:      Mechanisms MUST be in place to deny any node which  attempts
            to take malicious advantage of self-configuration and self-
            organization procedures.

G.3
URBAN:      A node MUST authenticate itself to a trusted node that is
            already associated with the U-LLN before the former can take
            part in self-configuration or self-organization.

G.4
URBAN:      A node that has already authenticated and associated with  the
            U-LLN MUST deny, to the maximum extent possible, the
            allocation of resources to any unauthenticated peer.

G.5
URBAN:      The routing protocol(s) MUST deny service to any node which
            has not clearly established trust with the U-LLN.

G.6
URBAN:      To this end, routing protocol(s) proposed in the context of
            U-LLNs MUST support authentication and integrity measures and
            SHOULD support confidentiality (routing security) measures.

G.7
INDUSTRIAL: The routing MUST be configured and managed using secure
            messages and protocols that prevent outsider attacks and limit
            insider attacks from field devices installed in insecure
            locations in the plant.

G.8
BUILDING:   Authentication policy and updates MUST be routable
            over-the-air.

G.9
BUILDING:   Data encryption of packets MUST optionally be supported  by
            use of either a network wide key and/or application key.

G.10
BUILDING:   The routing protocol MUST allow routing a packet encrypted
            with an application key through forwarding devices that
            without requiring each node in the path have the application
            key.

G.11
BUILDING:   The encryption policy MUST support encryption of the  payload
            only or the entire packet.

G.12
BUILDING:   Due to the limited resources of an LLN, the security  policy
            defined within the LLN MUST be able to differ from that of the
            rest of the IP network within the facility yet packets MUST
            still be able to route to or through the LLN from/to these
            networks.

G.13
BUILDING:   The routing protocol MUST gracefully handle routing  temporal
            security updates (e.g. dynamic keys) to sleeping devices on
            their 'awake' cycle to assure that sleeping devices can
            readily and efficiently access then network.

G.14
HOME:       The routing protocol chosen for ROLL MUST allow for low-
            power, low-cost network devices with limited security needs.

G.15
HOME:       Protection against unintentional inclusion in neighboring
            networks MUST be provided.



---------------------------------------------------------------------------

---------------------------------------------------------------------------

---------------------------------------------------------------------------

-  Uncategorized SHOULDs
---------------------------------------------------------------------------

draft-ietf-roll-building-routing-reqs

---------------------------------------------------------------------------

5.1.3. Local Testing

Routing should allow for temporary ad hoc paths to be established that are
            updated as the network physically and functionally expands.

5.3.1. Mobile Device Requirements

To minimize network dynamics, mobile devices SHOULD not be allowed  to act
            as forwarding devices (routers) for other devices in the LLN.

A mobile device that moves within an LLN SHOULD reestablish end-to- end
            communication to a fixed device also in the LLN within 2
            seconds. The network convergence time should be less than 5
            seconds once the mobile device stops moving.

A mobile device that moves outside of an LLN SHOULD reestablish end-
            to-end communication to a fixed device in the new LLN within 5
            seconds.  The network convergence time should be less than 5
            seconds once the mobile device stops moving.

A mobile device that moves outside of one LLN into another LLN  SHOULD
            reestablish end-to-end communication to a fixed device in the
            old  LLN within 10 seconds.  The network convergence time
            should be less than 10 seconds once the mobile device stops.

A mobile device that moves outside of one LLN into another LLN  SHOULD
            reestablish end-to-end communication to another mobile device
            in the new LLN within 20 seconds.  The network convergence
            time should be less than 30 seconds once the mobile devices
            stop moving.

A mobile device that moves outside of one LLN into another LLN  SHOULD
            reestablish end-to-end communication to a mobile device in the
            old LLN within 30 seconds.  The network convergence time
            should be less than 30 seconds once the mobile devices stop
            moving.

5.4.1. Limited Processing Power for Non-routing Devices.

The software size requirement for non-routing devices (e.g. sleeping
            sensors and actuators) SHOULD be implementable in 8-bit
            devices with no more than 128KB of memory.

5.4.2. Limited Processing Power for Routing Devices

The software size requirements for routing devices (e.g. room controllers)
            SHOULD be implementable in 8-bit devices with no more than
            256KB of flash memory.

5.6.2. Route Tracking

Route diagnostics SHOULD be supported providing information such as path
            quality; number of hops; available alternate active paths with
            associated costs.  Path quality is the relative measure of
            'goodness' of the selected source to destination path as
            compared to alternate paths.  This composite value may be
            measured as a function of hop count, signal strength,
            available power, existing active paths or  any other criteria
            deemed by ROLL as the path cost differentiator.

5.7.1. Path Cost

[...] These metrics SHOULD reflect metrics such as signal strength,
            available bandwidth, hop count, energy availability and
            communication error rates.

5.7.3. Route Redundancy

The routing layer SHOULD be configurable to allow secondary and tertiary
            paths to be established and used upon failure of the  primary
            path.

5.7.4. Route Discovery Time

If route discovery occurs during packet transmission time, it SHOULD NOT
            add more than 120ms of latency to the packet delivery time.

5.7.5. Route Preference

Route cost algorithms SHOULD allow the installer to optionally  select
            'preferred' paths based on the known spatial layout of the
            communicating devices.

---------------------------------------------------------------------------

draft-ietf-roll-home-routing-reqs

---------------------------------------------------------------------------

<EMPTY>

---------------------------------------------------------------------------

roll-indus-routing-reqs

---------------------------------------------------------------------------
-
In fast control, tens of milliseconds of latency is typical.

[...]

For these reasons, 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.

[ A route that connects a field device to a plant application may have
            multiple paths that go through more than one  LLN access
            point.  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
            availability of each path in a multipath route can change over
            time.  Hence, it is important to measure the availability on a
            per-path basis and select a path (or paths) according to the
            availability requirements. ]

The routing protocol SHOULD support broadcast or multicast addressing.

The routing protocol SHOULD support the wireless worker with fast network
            connection times of a few of seconds, and low command and
            response latencies to the plant behind the LLN access points,
            to applications, and to field devices.  The routing protocol
            SHOULD  also support the bandwidth allocation for bulk
            transfers between the  field device and the handheld device of
            the wireless worker.  The routing protocol SHOULD support
            walking speeds for maintaining network connectivity as the
            handheld device changes position in the wireless network.

The routing protocol SHOULD NOT require to preprovision information  about
            the environment where the node will be deployed.  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.

In industrial plants it must be assumed that the field devices have
            marginal physical security and might be compromised.  The
            routing protocol SHOULD  limit the risk incurred by one node
            being compromised, for instance by proposing non congruent
            path for a given route and balancing the traffic across the
            network.

The routing protocol SHOULD compartmentalize the trust placed in field
            devices so that a compromised field device does not destroy
            the security of the whole network.

---------------------------------------------------------------------------
-
draft-ietf-roll-urban-routing-reqs-04

---------------------------------------------------------------------------
-
The routing protocols(s) SHOULD support the organization of a large number
            of nodes into regions of configurable size.

Routing within urban sensor networks SHOULD require the U-LLN nodes to
            dynamically compute, select and install different paths
            towards a same destination, depending on the nature of the
            traffic.  Such functionality in support of, for example, data
            aggregation, may  imply to use some mechanisms to mark/tag the
            traffic for appropriate routing decision using the IPv6 packet
            format (e.g. use of DSCP,  Flow Label) based on an upper layer
            marking decision.

The protocol(s) SHOULD also support the formation and identification of
            groups of field devices in the network.

The routing protocol(s) SHOULD be able to dynamically adapt, e.g. through
            the application of appropriate routing metrics, to ever-
            changing conditions of communication (possible degradation of
            QoS, variable nature of the traffic (real time vs. non real
            time, sensed data vs. alerts), node mobility, a combination
            thereof, etc.)

The routing protocol(s) SHOULD be able to dynamically compute,  select and
            possibly optimize the (multiple) path(s) that will be used by
            the participating devices to forward the traffic towards the
            actuators and/or a LBR according to the service-specific and
            traffic-specific QoS, traffic engineering and routing security
            policies that will  have to be enforced at the scale of a
            routing domain (that is, a set of networking devices
            administered by a globally unique entity), or a region of such
            domain (e.g. a metropolitan area composed of clusters of
            sensors).

To this end, local network dynamics SHOULD NOT impact the entire network
            to be re-organized or re-reconfigured; however, the network
            SHOULD be locally optimized to cater for the encountered
            changes. The routing protocol(s) SHOULD support appropriate
            mechanisms in order to be informed of the association,
            disassociation, and disappearance of nodes.  The routing
            protocol(s) SHOULD support appropriate updating mechanisms in
            order to be informed of changes  in connectivity.  The routing
            protocol(s) SHOULD use this information  to initiate protocol
            specific mechanisms for reorganization and reconfiguration as
            necessary to maintain overall routing efficiency. Convergence
            and route establishment times SHOULD be significantly lower
            than the smallest reporting interval.

Differentiation SHOULD be made between node disappearance, where the node
            disappears without prior notification, and user or node-
            initiated disassociation ("phased-out"), where the node has
            enough time to inform the network about its pending removal.

The routing protocol(s) SHOULD also support the ability to route according
            to different metrics (one of which could e.g. be latency).

The routing protocol(s) SHOULD support defense against DoS attacks and
            other attempts to maliciously or inadvertently cause the
            routing protocol(s) mechanisms to over consume the limited
            resources of LLN nodes, e.g. by constructing forwarding loops
            or causing excessive routing protocol overhead traffic, etc.

The U-LLN SHOULD NOT interface with any external network which has not
            established trust. The U-LLN SHOULD be capable of limiting the
            resources granted in support of an external network so as not
            to be vulnerable to DoS.

---------------------------------------------------------------------------