Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-mjkim-roll-routing-metrics-00 IETF-72 - Dublin - July 2008 Mijeom Kim JP Vasseur Hakjin Chong

IETF 72 – July Dublin Introduction-1 Motivation of the document –Unique characteristics of LLNs –Typical routing metrics such as hop counts or link metrics are not sufficient for LLNs –A new set of required link and node metrics suitable to LLNs needs to be specified ROLL WG item –Nov 2008 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Classification of routing metrics –Link versus Node metrics –Qualitative versus quantitative –Dynamic or static

IETF 72 – July Dublin Introduction-2 Routing metrics for LLNs is a critical topic Need to be cautious !!! May be tempting to define a plethora of metrics … but not always implementable and usable in a deployed network Use of dynamic metrics have been studied and experimented in the past (ARPANET: first average delays, revised metrics) Dynamic metrics => Use of energy … The challenge is not to define metrics but to compute these metrics. This first revision list potential candidates

IETF 72 – July Dublin A first list of Node and Link Routing Attributes Node metric –Computational resources –Residual Energy (dynamic) –Current workload (dynamic) –Node latency –Data Aggregation attribute –Node degree Dynamicity –Node reliability Link metrics –Bandwidth –Reliability (Quality) –Propagation delay –Set of costs (missing from the ID)

Node Metrics/Attributes Most node attributes may be taken as static in LLN –Require quite resources to get exact values and update them periodically –Use of dynamic metrics is subject to routing instabilities Critical parameters like residual power –Need to be considered dynamic and monitored continuously –Need multi-threshold schemes to avoid constant routing changes Highly heterogeneous nodes in LLNs –More capable and stable nodes need to assist the most constrained ones for network lifetime extension and efficient network operations –Node metrics SHOULD be carefully maintained and utilized –Need constrained-based routing IETF-72 – July Dublin

Open Issues Consideration of routing efficiency and stability –Routing should be lightweight for resource saving in constrained networks –Need to care about the dynamic nature of some metrics and their implication on routing stability Traffic flow requirement –Applicable metrics are dependent on application and traffic flow requirements –Different applications or Service Level Agreement (SLA) might demand different routing metric combination –May need Multi-topology routing based on the traffic flow requirements using different set of metrics Metric weights exploitation –Metric weights should be decided according to applications and data flows –Applicable metrics or optimized weights may need to be changed on demand Metrics related to security IETF-72 – July Dublin

Next Steps Too soon to ask for WG adoption Please review and comment Proposed approach: Any metric missing Be very cautious of not mandating metrics if not required (think protocol !). Define the MUST, SHOULD, MAY, … IETF-72 – July Dublin

Back-up slides

Residual Energy (Node metric) Why –Power is highly precious resource in battery powered LLNs –To maintain energy balance among nodes for maximum network lifetime Treated as a relative value –Considering statistical node lifetime and role of the node in the network –Constrained-based routing is needed Generally, taken as a dynamic metric –Most battery operated devices have ability to estimate the remaining energy –Initial energy status can be considered as a static metric when monitoring energy status demands quite resources IETF-72 – July Dublin

Current workload (Node Metric) Why –Data processing along the data path is required –Queuing delays must be minimized for highly sensitive traffic Difficult to be measured and compared –Also difficult to express in a quantitative form –Putting the workload as a "heavy" or "light" one bit metric can be good IETF-72 – July Dublin

Node latency (Node Metric) The time span from the arrival time to the departure time of a given packet at a node –Primarily made up of packet processing time and packet transmission time High correlation with other metrics –Heavy workload increases node latency –Abundant computational resources reduce node latency IETF-72 – July Dublin

Data Aggregation attribute Data aggregation and fusion –Aggregation aims to reduce the amount of data –Fusion involves more complicated processing to improve accuracy of data Data aggregation/fusion can be performed –Due to data correlation –Especially in urban applications where sensor nodes collect environmental information High directional data flow is expected in a regular basis Challenges –Capturing time and location dependent correlation among sensed data from nodes on the possible routes –In-network processing may have high complexity IETF-72 – July Dublin

Node degree (Node Metric) Node degree –Number of neighbors that can send a message to the node directly –Neighbors are nodes located within the transmission range of the node A high node degree, generally –Is helpful for quick route recovery when the next hop node on the route cannot be accessible Node degree has to be carefully utilized in routing decision –A node with a high degree has a high possibility to have heavy workload in a busy network IETF-72 – July Dublin

Dynamicity (Node Metric) Measured by many different factors such as –Mobility –Transmission range –Duty cycle –The rate at which node joins and leaves the network Directly affects the network topology and connectivity –May trigger route reestablishment process –Less dynamic nodes should be preferred for path selection –Classifying nodes into static and dynamic can be helpful May be a static or dynamic metric –When dynamic, the network administrator will have to use consistent metric values IETF-72 – July Dublin

Node reliability (Node Metric) Deeply related to node dynamicity –Node reliability deteriorates as node dynamicity increases –Node reliability is a wider concept than node dynamicity Node dynamicity metric can be covered by node reliability metric A crucial metric –Nodes in LLNs may stay in a sleep mode most of the time A sleeping node should not be an intermediate node Status of a node must be monitored or can be anticipated –Residual energy of a node should be predictable To avoid the node’s battery out during routing process Hard to be estimated or monitored –A specific function needs to be defined IETF-72 – July Dublin

Link Attributes Link attributes in static LLNs –Can be considered as static ones Challenging to update them in a real-time manner Quite time- and energy-consuming work –Static LLNs have also variables like appearance of obstacles and signal interference Link attributes in dynamic LLNs –May need to take these attributes as dynamic metrics Values of dynamic metrics –Cannot be obtained easily –To use historical data and average them within a specified time window. IETF-72 – July Dublin

Bandwidth (Link Metric) Can be taken as a link capacity metric –In case of wireless link, the link capacity is shared among nodes in a single wireless link Can be evaluated as nodes’ communicational capability IETF-72 – July Dublin

Reliability – Quality (Link Metric) Can be measured by –Bit Error Rate (BER) –Mean Time Between Failures (MTBF) –Link churn (the rate at which links change between good and bad) Closely related to node reliability especially in wireless LLNs –Two nodes which form a link affect directly to the link reliability Also influenced by other factors like –Unexpected obstacles –Temporary interference An essential routing metric –Change of link quality directly affects network connectivity –Increasing link and node reliability together enhances route robustness IETF-72 – July Dublin

Propagation delay (Link Metric) Is the time taken for the packet to traverse the link from the source node to the target node –Path (route) latency is made up of nodes’ latency and links’ propagation delay on the path Can be obtained by making average from historical data IETF-72 – July Dublin