Subject: [Roll] DT update -- MUSTs

From: Tim Winter <[email-masked]>
Date: Thu, 14 May 2009 22:09:44 -0400

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.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 May 2009 08:39:58 +0200

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 :
> 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 
>  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.
> 
>  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.
> 
> 
>  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
> 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.
> 
> -  Categorized MUSTs Sources: 
> 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
> 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
> B.2 INDUSTRIAL: The routing protocol MUST be able to compute paths of
> 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.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 
> C.3 INDUSTRIAL: The routing algorithm MUST be able to generate 
> different routes with different characteristics (e.g. optimized 
> 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 
> 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 
> 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 
> 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
> G.4 URBAN:      A node that has already authenticated and associated 
> with  the U-LLN MUST deny, to the maximum extent possible, the 
> 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.
> 
> 
> 
> Routing should allow for temporary ad hoc paths to be established 
> that are updated as the network physically and functionally expands.
> 
> 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.
> 
> seconds.  The network convergence time should be less than 5 seconds 
> once the mobile device stops moving.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>  sensors and actuators) SHOULD be implementable in 8-bit devices with
>  no more than 128KB of memory.
> 
> 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
> 
> 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.
> 
> 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
> 
>  - 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 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.
> 
> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 15 May 2009 09:56:12 +0200

Hi Alex,

> 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.

> 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.

>> 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
>> -  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
>> 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
>> B. Traffic Flows: ----------------- [        Node -> (thru) LBR  ]  
>> [ (thru) LBR -> Node        ] [        Node -> Node        ]
>> the routing protocol(s) MUST provide a set of features including 0- 
>> configuration at network ramp-up, (network-internal) self-  
>> on Network Layer abstractions of the underlying link attributes/ 
>> metric that may change dynamically.
>> reachable network).  The protocol also MUST support the  
>> distribution of configuration from a centralized management  
>> controller if operator-initiated configuration change is allowed.
>> C.6 BUILDING:   Devices referencing data in the replaced device  
>> MUST be  able to reference data in its replacement without being  
>> D.4 HOME:       The routing protocol MUST support 250 devices in  
>> the network.
>> 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.5 HOME:       The routing protocol MUST converge within 0.5  
>> second if no nodes have moved.
>> F. Constraint-based Routing: ---------------------------- F.1  
>> 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.
>> context of U-LLNs MUST support authentication and integrity  
>> measures and SHOULD support confidentiality (routing security)  
>> measures.
>> G.13 BUILDING:   The routing protocol MUST gracefully handle  
>> routing temporal security updates (e.g. dynamic keys) to sleeping  
>> devices on
>> G.14 HOME:       The routing protocol chosen for ROLL MUST allow  
>> for low- power, low-cost network devices with limited security needs.
>> 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
>> 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
>> important to measure the availability on a per-path basis and  
>> select a path (or paths) according to the availability  
>> requirements. ]
>> configuration from a centralized management controller if operator- 
>> initiated configuration
>> change is allowed.
>> to dynamically compute, select and install different paths towards  
>> a same destination, depending on the nature of the traffic.  Such  
>> The protocol(s) SHOULD also support the formation and  
>> identification of groups of field devices in the network.
>> Differentiation SHOULD be made between node disappearance, where  
>> the node disappears without prior notification, and user or node-  
>> and other attempts to maliciously or inadvertently cause the  
>> resources of LLN nodes, e.g. by constructing forwarding loops or  
>> causing excessive routing protocol overhead traffic, etc.
>> _______________________________________________ Roll mailing list [email-masked] 
>>  https://www.ietf.org/mailman/listinfo/roll
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Tue, 19 May 2009 11:38:02 +0200

Hi Alex,

> Or is the link energy completely out of scope?

It would be useful to know what the WG thinks about link energy metrics.

Here is my take on it. Node energy metric is undoubtedly needed, in  
many cases, one may want to avoid a node that is battery operated or  
running our of battery, we are all in sync with this. Now with regards  
to link energy metrics, this is by far less obvious. Why would you  
care knowing that the energy required to transmit 1 bit is X over a  
link L1 and 2*X over a link L2? It might very well be that the node  
connected to L2 has no energy constraint by contrast with the node  
connected to L1 being battery operated.

Thoughts ?

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 May 2009 12:11:50 +0200

JP Vasseur a écrit :
>> 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.
>> 
>> I do find reqs for energy as constraints of the node device: level
>>  of energy, energy of the node, power available, power budget, etc.
>> 
>> 

I am very interested on all WG oppinions on link energy metric.

>  running our of battery, we are all in sync with this. Now with 
> regards to link energy metrics, this is by far less obvious. Why 
> would you care knowing that the energy required to transmit 1 bit is
>  X over a link L1 and 2*X over a link L2?

My first impression: because typical cost metrics are _link_
metrics, not node metrics - the hop count is the number of links, not of
nodes (a 3 node topology uses a 2 hop count metric - the number of links).

More often than not the parameters advertised in Router Advertisements
of OSPF and ICMP are link parameters: link MTU, link prefix.

It sounds attractive to reuse the same link concept for energy.

Prior publications making think link energy is relevant:

              Callaway, E., "Secure Low-Power Operation of Wireless
              Sensor Networks", Intelligent Systems, January 2004.

Mentions transmission of a packet with a particular 15.4 transceiver to
be 56 micro-Joules, and is computed relative to the number of bits
transmitted.

               L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy
               Mobile Wireless Networks Revisited", June 2001.

Explicitely assumes that "a transmission between node u and v takes
power p(uv) [...]".

               IEEE Global Telecommunications Conference, Globecom '03,
               "Measurement and Characterization of Link Quality Metrics
               in Energy Constrained Wireless Sensor Networks", 2003.

Mentions that the energy to transmit a packet is proportional to
'link inefficiency', and this latter (not the energy) is defined as a
metric.

> It might very well be that the node connected to L2 has no energy 
> constraint by contrast with the node connected to L1 being battery 
> operated.

There seems indeed to be a decoupling between the energy left to a node, 
its battery level, its consumption patterns - and the energy needed to 
send an MTU-sized packet on a link.

They could be both needed, I can't easily say, because the
NP-completeness issue: routing according to metric "link-energy" _and_
metric "node-energy" may be NP-hard to do.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Tue, 19 May 2009 14:38:06 +0200

but again, this does not really answer *the* question: why should the  
routing protocol take link energy into account during path computation ?

On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote:

> There seems indeed to be a decoupling between the energy left to a  
> node, its battery level, its consumption patterns - and the energy  
> needed to send an MTU-sized packet on a link.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 May 2009 16:42:00 +0200

>  routing protocol take link energy into account during path

For example to identify a path requiring less energy to transceive a
packet, than another path.

> Why would you care knowing that the energy required to transmit 1 bit
> is X over a link L1 and 2*X over a link L2? [...] It might very well
> be that the node connected to L2 has no energy constraint by contrast
> with the node connected to L1 being battery operated.

For the same reasons an existing rt protocol cares about the number of 
hops, link bandwidth, link MTU, link prefix, and less about the nodes' 
MIPS, RAM.  By analogy.

Alex

>>> 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? 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?
>>> Here is my take on it. Node energy metric is undoubtedly needed,
>>> in many cases, one may want to avoid a node that is battery
>>> operated or running our of battery, we are all in sync with this.
>>> Now with regards to link energy metrics, this is by far less
>>> obvious. Why would you care knowing that the energy required to
>>> transmit 1 bit is X over a link L1 and 2*X over a link L2?
>> 
>> metrics, not node metrics - the hop count is the number of links,
>> not of nodes (a 3 node topology uses a 2 hop count metric - the
>> number of links).
>> 
>> More often than not the parameters advertised in Router
>> Advertisements of OSPF and ICMP are link parameters: link MTU, link
>> prefix.
>> 
>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor
>> Networks", Intelligent Systems, January 2004.
>> 
>> Mentions transmission of a packet with a particular 15.4
>> transceiver to be 56 micro-Joules, and is computed relative to the
>> number of bits transmitted.
>> 
>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile
>> Wireless Networks Revisited", June 2001.
>> 
>> "Measurement and Characterization of Link Quality Metrics in Energy
>> Constrained Wireless Sensor Networks", 2003.
>> 
>> 'link inefficiency', and this latter (not the energy) is defined as
>> a metric.
>> 
>>>  constraint by contrast with the node connected to L1 being
>>> battery operated.
>> 
>> NP-completeness issue: routing according to metric "link-energy"
>> _and_ metric "node-energy" may be NP-hard to do.
>> 
>> Alex
>> 
>> 
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 19 May 2009 18:09:59 +0200

but again, back to my example, this may not help:

> For the same reasons an existing rt protocol cares about the number  
> of hops, link bandwidth, link MTU, link prefix, and less about the  
> nodes' MIPS, RAM.  By analogy.
>
> Alex
>
>>> They could be both needed, I can't easily say, because the NP- 
>>> completeness issue: routing according to metric "link-energy"