1. IETF-76, Hiroshima, Nov 2009 ROLL Working Group Meeting IETF-76, Nov 2009, Hiroshima Routing Metrics used for Path Calculation in Low Power and Lossy Networks Draft-ietf-roll-routing-metrics-03 JP Vasseur jpv@cisco.com, Mijeom Kim mjkim@kt.comjpv@cisco.commjkim@kt.com K. Pister pister@eecs.berkeley.edu

2. Contents Introductions Objects Formats –Object Common Header Format –Node Metric Format –Link Metric Format –Objective Function Format Next work IETF-76, Hiroshima, Nov 2009

3. Introduction Main objective: to propose a flexible mechanism for the advertisement of routing metrics and constraints used by RPL Constraints and metrics –Constraint: used as a “filter” to prune links and nodes that do not satisfy specific properties –Metric: a quantitative value that is used to evaluate the path quality, also referred to as the path cost The best path: the path with the lowest cost with respect to some metrics that satisfies all constraints (if any) and is also called the shortest constrained path The set of routing objects is signaled along the DAG computed by RPL via an Objective Function (OF) IETF-76, Hiroshima, Nov 2009

4. Object Common Header Formats C = 1: Constraint, 0: metric O = 1: Optional (only for constraints) A = 0x00: Additive, 0x01: maximum, 0x02: minimum (only for aggregated metrics) G = 1: Global, 0: local (metrics are always global) R = 1: Recorded along the path, 0: aggregated (only for metrics) IETF-76, Hiroshima, Nov 2009

5. Node State And Attributes Object O Flag: indicates that the node is Overloaded (Overload bit) A Flag: indicates that the node can act as a traffic Aggregator IETF-76, Hiroshima, Nov 2009

6. Node Energy Object NE (Node Energy) sub-object format T (node Type): 0x00: main powered, 0x01: battery powered, 0x02: powered by a scavenger I (Included): only for constraints, = 1: must be included, = 0: must be excluded E (Estimation): when set, the E-E field is valid E-E (Estimated-Energy): 8-bit field indicating the estimated percentage of remaining energy on the node IETF-76, Hiroshima, Nov 2009

7. E-E field in NE object Encode the energetic Happiness of both battery powered and scavenging nodes –For scavenging nodes, H is the power provided by the scavenger divided by the power consumed by the application, H=P_in/P_out, in units of percent –For battery powered devices, H is the current expected lifetime divided by the desired minimum lifetime Examples –Given the average power consumption, H is the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power consumption, H=P_max/P_now –Given the estimated energy in the battery, E_bat and the total elapsed lifetime, t, H is the total stored energy remaining versus the target energy remaining: H= E_bat / [E_0 (T-t)/T]. IETF-76, Hiroshima, Nov 2009

8. Hop Count Object IETF-76, Hiroshima, Nov 2009

9. Throughput and Latency Object Throughput: 32 bits, encoded in 32 bits in IEEE floating point format, expressed in bytes per second Latency: 32 bits, encoded in 32 bits in IEEE floating point format, expressed in milliseconds IETF-76, Hiroshima, Nov 2009

10. Link Reliability – LQL (Link Quality Level) LQL Object Format LQL Type 1 sub-object format for recorded metrics » » - Val: = 0: undetermined, 1: the highest link » quality LQL Type 2 sub-object format for aggregated metrics –Sum (A = 0x00), maximum (A = 0x01), or minimum (A = 0x02) IETF-76, Hiroshima, Nov 2009

11. Link Reliability – EXT (Expected Transmission Count) ETX: the number of transmissions a node expects to make to a destination in order to successfully deliver a packet ETX Object Format and ETX sub-object format –ETX: 8 bits, encoded in 8 bits in IEEE floating point format –Example: ETX= 1 / (D f * D r ) where D f : the measured probability that a packet is received by the neighbor D r : the measured probability that the acknowledgment packet is successfully received IETF-76, Hiroshima, Nov 2009

12. Link Color Object LC Object Format LC Type 1 sub-object format for global recorded metrics LC Type 2 sub-object format for constraints IETF-76, Hiroshima, Nov 2009

13. Objective Function OF (Objective Function) –Specify how the routing metric and constraints should be used to reach specific objectives –Used by a node to select its parent during the DAG building construction process OCP (Objective Code Point) Object –Used to specify the OF and is carried within the DAG Metric Container object (must appear first than other metric objects) –OCP Object Format IETF-76, Hiroshima, Nov 2009

14. Next Work Detailed metrics formats and (when needed) metric setting/updating schemes –Specification of optional TLV fields and flags Detailed Objective Function (OCP) Object Setting Clear Distinction of Constraints and Metrics (including usage) –Constraints should be specified in OF? Co-evolve with the RPL IETF-76, Hiroshima, Nov 2009