IETF-76, Hiroshima, Nov 2009
ROLL Working Group MeetingIETF-76, Nov 2009, Hiroshima
Routing Metrics used for Path Calculation in Low Power and Lossy Networks
Draft-ietf-roll-routing-metrics-03
JP Vasseur [email protected], Mijeom Kim [email protected]. Pister [email protected]
Contents
• Introductions
• Objects Formats– Object Common Header Format– Node Metric Format– Link Metric Format– Objective Function Format
• Next work
IETF-76, Hiroshima, Nov 2009
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
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
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
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
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
Hop Count Object
IETF-76, Hiroshima, Nov 2009
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
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
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 / (Df * Dr) where
Df : the measured probability that a packet is received by the neighbor
Dr: the measured probability that the acknowledgment packet is successfully received
IETF-76, Hiroshima, Nov 2009
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
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
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