Re: [Roll] DT update -- MUSTs

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?

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?

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
> 

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