Re: [Roll] DT update -- MUSTs

Hi Alex,

On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote:

> Tim, thanks for the update - that's hard work.
>
> A side remark about one particular interest: the req list doesn't seem
> to include a metric for energy of the link: energy necessary to send a
> packet on the link, or energy radiated in the air, or similar.
>
> Or I can't find it - is there one?

First a general but important comment: Requirements document are  
extremely important "guidelines". We (as a WG) may have to conclude  
that a MUST cannot be satisfied, which is perfectly acceptable as long  
as we document the rationale.

Answering your question, a link energy metric will be discussed in the  
context of the Metric I-D (where all metrics for the routing protocols  
will be defined) and does not have to be listed on the requirements  
list. If the WG thinks that we need it, we will work on it.

>
> I do find reqs for energy as constraints of the node device: level of
> energy, energy of the node, power available, power budget, etc.
>
> Or is the link energy completely out of scope?
>

It is not. Let's see whether we all think that this is required.

Cheers.

JP.

> Thanks,
>
> Alex
>
> Tim Winter a écrit :
>> 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.
>> ---------------------------------------------------------------------------
>> _______________________________________________ Roll mailing list Roll@ietf.org 
>>  https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

Re: [Roll] DT update -- MUSTs - energy for link metric?