At the upcoming IETF 78 meeting, the Routing over Low power and Lossy Networks (RoLL) Working Group – co-chaired by Arch Rock CTO Dr. David Culler – will review the IPv6 Routing Protocol for Low power and Lossy Networks (RPL) core draft prior to an expected “last call.” Acceptance – after potential modifications – will mean the protocol specifications would be published as a Request for Comment (RFC) and be implemented by vendors.

IP routing is a key feature for the Smart Grid industry. By implementing RPL, the Advanced Metering Infrastructure (AMI) will benefit from basic IP routing characteristics such as:

• Dynamic discovery of network paths and destination “reachability”
• Ability to adapt to logical network topology changes, equipment failures or network outages “on the fly”
• Independence from data-link-layer technologies
• Different AMI networks’ exit paths through multiple edge routers for high availability and load balancing

Why is a new routing protocol necessary when several protocols – RIP, OSPF and IS-IS – have already been specified, implemented and deployed? Because smart meters are a typical example of “constrained” nodes as defined by the RoLL WG routing requirements documents (RFC 5548, 5673, 5826 and 5867). Constrained nodes are those

• Built with limited processing power, memory and sometimes energy when operating on batteries
• Interconnected through a low-data-rate network interface and potentially vulnerable to communication instability and low packet delivery rates
• Potentially having a mix of roles, being able to act as “host” (generating traffic) and “router” (both forwarding and generating RPL traffic).

Considering the wide variety of use cases, link types and metrics, RPL has been designed to separate packet processing and forwarding in the generic RPL core document from routing optimization objectives in the Routing Metrics and Objective Functions documents.

Some useful RPL terminology:

• Directed Acyclic Graph (DAG): A directed graph with all its edges oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes.
• DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition all DAGs must have at least one DAG root and all paths must terminate at a DAG root.
• Destination Oriented DAG (DODAG): A DAG rooted at a single destination - i.e., at a single DAG root (the DODAG root) with no outgoing edges.
• DODAG root: the DAG root of a DODAG.

Key RPL characteristics:

• Upward routes – a node running RPL will join a DODAG by discovering neighbors that are members of the DODAG of interest, identifying a set of parents and maintaining upward routes to the DAG root.
• Downward routes – a node running RPL will discover and maintain downward routes. Downward routes support P2MP flows from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow to a DODAG root through an upward route, then away from the DODAG Root to a destination through a downward route.The RPL specification describes the two modes an RPL instance may choose for maintaining downward routes. In the first mode, called “storing,” nodes store downward routing tables for their sub-DODAG. Each hop on a downward route in a storing network examines its routing table to decide on the next hop. In the second mode, called “non-storing,” nodes do not store downward routing tables. Downward packets are routed with source routes populated by a DODAG Root.
• Loop avoidance – rank-based data path validation mechanisms for detecting loops when they do occur, avoiding problems such as count-to-infinity
• Data-path validation using a new IPv6 Hop-by-Hop Option to detect possible loops within a
  DODAG.
• Trickle timer to manage advertisement transmissions, allowing new information to spread on the scale of link-layer transmission times while sending only a few messages per hour when information does not change.
• Objective Functions – defines how RPL nodes select and optimize routes within an RPL instance to honor a given deployment’s particular routing objective or constraint. Objective Function design leverages the routing metrics. An Objective Function 0 uses the abstract properties exposed in RPL messages to maximize connectivity.
• Routing metrics used to compute the best or shortest constrained path
  A routing metric can be additive or multiplicative, and reports the following:
  • Node state and attribute – information on node characteristics such as CPU overload, lack of memory and other conditions
  • Node energy – determining if a “longer” path that traverses mains-powered nodes or nodes equipped with energy scavenging is preferable to a “shorter” path through battery-operated nodes
  • Hop count – the number of nodes traversed along the path
  • Link throughput – the range of throughput that the link can handle in addition to the currently available throughput
  • Link latency – similar to throughput but for latency
  • Link quality level – link reliability from unknown to highest link quality level
  • Link ETX – the number of transmissions a node expects to make to a destination to successfully deliver a packet
  • Link color – an administrative 10-bit static link constraint used to avoid or attract specific links for specific traffic types

The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) represents a powerful tool for scalable deployment of Advanced Metering Infrastructures. In addition, AMI Edge Router(s) will insure connectivity with the IP infrastructure from utilities or Internet service providers though one of the following methods:

• Root node on the infrastructure side in a larger RPL domain
• Route redistribution between RPL and other routing protocols running in the infrastructure
• Secure tunnel’s end-point to constrain access through a single aggregation point

We will monitor and report later on what happens at IETF 78.

Reference:
RoLL documents: http://datatracker.ietf.org/wg/roll/

Tags: PhyNet-Grid, RoLL, RPL, smart-grid

This entry was posted on Tuesday, July 13th, 2010 at 10:12 am and is filed under Standards, smart-grid. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.