diff options
Diffstat (limited to 'doc/rfc/rfc8036.txt')
| -rw-r--r-- | doc/rfc/rfc8036.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc8036.txt b/doc/rfc/rfc8036.txt new file mode 100644 index 0000000..a748a5f --- /dev/null +++ b/doc/rfc/rfc8036.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Cam-Winget, Ed. +Request for Comments: 8036 Cisco Systems +Category: Standards Track J. Hui +ISSN: 2070-1721 Nest + D. Popa + Itron, Inc + January 2017 + + + Applicability Statement for + the Routing Protocol for Low-Power and Lossy Networks (RPL) in + Advanced Metering Infrastructure (AMI) Networks + +Abstract + + This document discusses the applicability of the Routing Protocol for + Low-Power and Lossy Networks (RPL) in Advanced Metering + Infrastructure (AMI) networks. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8036. + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Cam-Winget, et al. Standards Track [Page 1] + +RFC 8036 RPL Applicability for AMI January 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Out-of-Scope Requirements . . . . . . . . . . . . . . . . 4 + 2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4 + 3. Description of AMI Networks for Electric Meters . . . . . . . 4 + 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5 + 4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7 + 4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7 + 4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8 + 4.3. RPL Applicability per Smart Grid Traffic Characteristics 9 + 5. Layer-2 Applicability . . . . . . . . . . . . . . . . . . . . 9 + 5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9 + 5.2. IEEE Power Line Communication (PLC) Technology . . . . . 9 + 6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10 + 7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11 + 7.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . 11 + 7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11 + 7.1.4. Objective Function . . . . . . . . . . . . . . . . . 12 + 7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12 + 7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 13 + 7.2. Description of Layer-2 Features . . . . . . . . . . . . . 13 + 7.2.1. IEEE 1901.2 PHY and MAC Sub-layer Features . . . . . 13 + 7.2.2. IEEE 802.15.4 (Amendments G and E) PHY and MAC + Features . . . . . . . . . . . . . . . . . . . . . . 14 + 7.2.3. IEEE MAC Sub-layer Security Features . . . . . . . . 15 + 7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17 + 7.4. Recommended Configuration Defaults and Ranges . . . . . . 17 + 7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17 + 7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18 + 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 9.1. Security Considerations during Initial Deployment . . . . 20 + 9.2. Security Considerations during Incremental Deployment . . 20 + 9.3. Security Considerations Based on RPL's Threat Analysis . 20 + 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 11.2. Informative references . . . . . . . . . . . . . . . . . 22 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + + + +Cam-Winget, et al. Standards Track [Page 2] + +RFC 8036 RPL Applicability for AMI January 2017 + + +1. Introduction + + Advanced Metering Infrastructure (AMI) systems enable the + measurement; configuration; and control of energy, gas, and water + consumption and distribution; through two-way scheduled, + on-exception, and on-demand communication. + + AMI networks are composed of millions of endpoints, including meters, + distribution automation elements, and eventually Home Area Network + (HAN) devices. They are typically interconnected using some + combination of wireless and power line communications, thus forming + the so-called Neighbor Area Network (NAN) along with a backhaul + network providing connectivity to "command-and-control" management + software applications at the utility company back office. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +1.2. Required Reading + + [surveySG] gives an overview of Smart Grid architecture and related + applications. + + A NAN can use wireless communication technology, which is based on + the IEEE 802.15.4 standard family: more specifically, the Physical + Layer (PHY) amendment [IEEE.802.15.4g] and the Media Access Control + (MAC) sub-layer amendment [IEEE.802.15.4e], which are adapted to + smart grid networks. + + NAN can also use Power Line Communication (PLC) technology as an + alternative to wireless communications. Several standards for PLC + technology have emerged, such as [IEEE.1901.2]. + + NAN can further use a mix of wireless and PLC technologies to + increase the network coverage ratio, which is a critical requirement + for AMI networks. + + + + + + + + + + + +Cam-Winget, et al. Standards Track [Page 3] + +RFC 8036 RPL Applicability for AMI January 2017 + + +1.3. Out-of-Scope Requirements + + The following are outside the scope of this document: + + o Applicability statement for RPL [RFC6550] in AMI networks composed + of battery-powered devices (i.e., gas/water meters). + + o Applicability statement for RPL in AMI networks composed of a mix + of devices powered by alternating current (i.e., electric meters) + and battery-powered meters (i.e., gas/water meters). + + o Applicability statement for RPL storing mode of operation in AMI + networks. + +2. Routing Protocol for LLNs (RPL) + + RPL provides routing functionality for mesh networks that can scale + up to thousands of resource-constrained devices that are + interconnected by low-power and lossy links and communicate with the + external network infrastructure through a common aggregation point(s) + (e.g., an LLN Border Router, or LBR). + + RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at + an LBR, ensures loop-free routing, and provides support for alternate + routes as well as for a wide range of routing metrics and policies. + + RPL was designed to operate in energy-constrained environments and + includes energy-saving mechanisms (e.g., Trickle timers) and energy- + aware metrics. RPL's ability to support multiple different metrics + and constraints at the same time enables it to run efficiently in + heterogeneous networks composed of nodes and links with vastly + different characteristics [RFC6551]. + + This document describes the applicability of RPL non-storing mode (as + defined in [RFC6550]) to AMI deployments. The Routing Requirements + for Urban Low-Power and Lossy Networks [RFC5548] are applicable to + AMI networks as well. The terminology used in this document is + defined in [RFC7102]. + +3. Description of AMI Networks for Electric Meters + + In many deployments, in addition to measuring energy consumption, the + electric meter network plays a central role in the Smart Grid since + the device enables the utility company to control and query the + electric meters themselves and can serve as a backhaul for all other + devices in the Smart Grid, e.g., water and gas meters, distribution + automation, and HAN devices. Electric meters may also be used as + + + + +Cam-Winget, et al. Standards Track [Page 4] + +RFC 8036 RPL Applicability for AMI January 2017 + + + sensors to monitor electric grid quality and to support applications + such as electric vehicle charging. + + Electric meter networks can be composed of millions of smart meters + (or nodes), each of which is resource constrained in terms of + processing power, storage capabilities, and communication bandwidth + due to a combination of factors including regulations on spectrum + use; on meter behavior and performance; and on heat emissions within + the meter, form factor, and cost considerations. These constraints + result in a compromise between range and throughput with effective + link throughput of tens to a few hundred kilobits per second per + link, a potentially significant portion of which is taken up by + protocol and encryption overhead when strong security measures are in + place. + + Electric meters are often interconnected into multi-hop mesh + networks, each of which is connected to a backhaul network leading to + the utility company network through a network aggregation point, + e.g., an LBR. + +3.1. Deployment Scenarios + + AMI networks are composed of millions of endpoints distributed across + both urban and rural environments. Such endpoints can include + electric, gas, and water meters; distribution automation elements; + and HAN devices. + + Devices in the network communicate directly with other devices in + close proximity using a variety of low-power and/or lossy link + technologies that are both wireless and wired (e.g., IEEE 802.15.4g, + IEEE 802.15.4e, IEEE 1901.2, and [IEEE.802.11]). In addition to + serving as sources and destinations of packets, many network elements + typically also forward packets and thus form a mesh topology. + + In a typical AMI deployment, groups of meters within physical + proximity form routing domains, each in the order of a 1,000 to + 10,000 meters. Thus, each electric meter mesh typically has several + thousand wireless endpoints with densities varying based on the area + and the terrain. + + + + + + + + + + + + +Cam-Winget, et al. Standards Track [Page 5] + +RFC 8036 RPL Applicability for AMI January 2017 + + + | + +M + | + M M M M | M + /-----------\ /---+---+---+---+--+-+- phase 1 + +----+ ( Internet ) +-----+ / M M M M + |MDMS|---( )----| LBR |/----+----+----+----+---- phase 2 + +----+ ( WAN ) +-----+\ + \----------/ \ M M M M + \--+--+----+-+---+----- phase 3 + \ M M + +--+---+-- + <-----------------------------> + RPL + + Figure 1: Typical NAN Topology + + A typical AMI network architecture (see Figure 1) is composed of a + Meter Data Management System (MDMS) connected through an IP network + to an LBR, which can be located in the power substation or somewhere + else in the field. The power substation connects the households and + buildings. The physical topology of the electrical grid is a tree + structure, either due to the three different power phases coming + through the substation or just to the electrical network topology. + Meters (represented by a M in the previous figure) can also + participate in a HAN. The scope of this document is the + communication between the LBR and the meters, i.e., the NAN segment. + + Node density can vary significantly. For example, apartment + buildings in urban centers may have hundreds of meters in close + proximity, whereas rural areas may have sparse node distributions and + may include nodes that only have a small number of network neighbors. + Each routing domain is connected to the larger IP infrastructure + through one or more LBRs, which provide Wide Area Network (WAN) + connectivity through various traditional network technologies, e.g., + Ethernet, cellular, private WAN based on Worldwide Interoperability + for Microwave Access (WiMAX), and optical fiber. Paths in the mesh + between a network node and the nearest LBR may be composed of several + hops or even several tens of hops. Powered from the main line, + electric meters have less energy constraints than battery powered + devices, such as gas and water meters, and can afford the additional + resources required to route packets. + + As a function of the technology used to exchange information, the + logical network topology will not necessarily match the electric grid + topology. If meters exchange information through radio technologies + such as in the IEEE 802.15.4 family, then the topology is a meshed + + + + +Cam-Winget, et al. Standards Track [Page 6] + +RFC 8036 RPL Applicability for AMI January 2017 + + + network where nodes belonging to the same Destination-Oriented DAG + (DODAG) can be connected to the grid through different substations. + If narrowband PLC technology is used, it will more or less follow the + physical tree structure since crosstalk may allow one phase to + communicate with the other. This is particularly true near the LBR. + Some mixed topology can also be observed since some LBRs may be + strategically installed in the field to avoid all the communications + going through a single LBR. Nevertheless, the short propagation + range forces meters to relay the information. + +4. Smart Grid Traffic Description + +4.1. Smart Grid Traffic Characteristics + + In current AMI deployments, metering applications typically require + all smart meters to communicate with a few head-end servers that are + deployed in the utility company data center. Head-end servers + generate data traffic to configure smart data reading or initiate + queries and use unicast and multicast to efficiently communicate with + a single device (i.e., Point-to-Point (P2P) communications) or groups + of devices respectively (i.e., Point-to-Multipoint (P2MP) + communication). The head-end server may send a single small packet + at a time to the meters (e.g., a meter read request, a small + configuration change, or a service-switch command) or a series of + large packets (e.g., a firmware download across one or even thousands + of devices). The frequency of large file transfers (e.g., firmware + download of all metering devices) is typically much lower than the + frequency of sending configuration messages or queries. Each smart + meter generates Smart Metering Data (SMD) traffic according to a + schedule (e.g., periodic meter reads) in response to on-demand + queries (e.g., on-demand meter reads) or in response to some local + event (e.g., power outage or leak detection). Such traffic is + typically destined to a single head-end server. The SMD traffic is + thus highly asymmetric, where the majority of the traffic volume + generated by the smart meters typically goes through the LBRs, and is + directed from the smart meter devices to the head-end servers in a + Mesh Peer-to-Peer (MP2P) fashion. Current SMD traffic patterns are + fairly uniform and well understood. The traffic generated by the + head-end server and destined to metering devices is dominated by + periodic meter reads while traffic generated by the metering devices + is typically uniformly spread over some periodic read time-window. + + Smart metering applications typically do not have hard real-time + constraints, but they are often subject to bounded latency and + stringent service level agreements about reliability. + + + + + + +Cam-Winget, et al. Standards Track [Page 7] + +RFC 8036 RPL Applicability for AMI January 2017 + + + Distribution Automation (DA) applications typically involve a small + number of devices that communicate with each other in a P2P fashion + and may or may not be in close physical proximity. DA applications + typically have more stringent latency requirements than SMD + applications. + + There are also a number of emerging applications such as electric + vehicle charging. These applications may require P2P communication + and may eventually have more stringent latency requirements than SMD + applications. + +4.2. Smart Grid Traffic QoS Requirements + + As described previously, the two main traffic families in a NAN are: + + A) Meter-initiated traffic (Meter-to-Head-End - M2HE) + + B) Head-end-initiated traffic (Head-End-to-Meter - HE2M) + + B1) request is sent in P2P to a specific meter + + B2) request is sent in multicast to a subset of meters + + B3) request is sent in multicast to all meters + + The M2HE are event based while the HE2M are mostly command response. + In most cases, M2HE traffic is more critical than HE2M one, but there + can be exceptions. + + Regarding priority, traffic may also be divided into several classes: + + C1) High-Priority Critical traffic for Power System Outage, Pricing + Events, and Emergency Messages require a 98%+ packet delivery + under 5 s (payload size < 100 bytes) + + C2) Critical Priority traffic for Power Quality Events and Meter + Service Connection and Disconnection requires 98%+ packet + delivery under 10s (payload size < 150 bytes) + + C3) Normal Priority traffic for System Events including Faults, + Configuration, and Security requires 98%+ packet delivery under + 30 s (payload size < 200 bytes) + + C4) Low Priority traffic for Recurrent Meter Reading requires 98%+ + packet 2-hour delivery window 6 times per day (payload size < + 400 bytes) + + + + + +Cam-Winget, et al. Standards Track [Page 8] + +RFC 8036 RPL Applicability for AMI January 2017 + + + C5) Background Priority traffic for firmware/software updates + processed to 98%+ of devices within 7 days (average firmware + update is 1 MB) + +4.3. RPL Applicability per Smart Grid Traffic Characteristics + + The RPL non-storing mode of operation naturally supports upstream and + downstream forwarding of unicast traffic between the DODAG root and + each DODAG node, and between DODAG nodes and the DODAG root, + respectively. + + The group communication model used in smart grid requires the RPL + non-storing mode of operation to support downstream forwarding of + multicast traffic with a scope larger than link-local. The DODAG + root is the single device that injects multicast traffic, with a + scope larger than link-local, into the DODAG. + +5. Layer-2 Applicability + +5.1. IEEE Wireless Technology + + IEEE amendments 802.15.4g and 802.15.4e to the standard IEEE 802.15.4 + have been specifically developed for smart grid networks. They are + the most common PHY and MAC layers used for wireless AMI networks. + IEEE 802.15.4g specifies multiple modes of operation (FSK, OQPSK, and + OFDM modulations) with speeds from 50 kbps to 600 kbps and allows for + transport of a full IPv6 packet (i.e., 1280 octets) without the need + for upper-layer segmentation and reassembly. + + IEEE Std 802.15.4e is an amendment to IEEE Std 802.15.4 that + specifies additional Media Access Control (MAC) behaviors and frame + formats that allow IEEE 802.15.4 devices to support a wide range of + industrial and commercial applications that were not adequately + supported prior to the release of this amendment. It is important to + notice that IEEE 802.15.4e does not change the link-layer security + scheme defined in the last two updates to IEEE Std 802.15.4 (e.g., + 2006 and 2011 amendments). + +5.2. IEEE Power Line Communication (PLC) Technology + + IEEE Std 1901.2 specifies communications for low frequency (less than + 500 kHz) narrowband power line devices via alternating current and + direct current electric power lines. IEEE Std 1901.2 supports indoor + and outdoor communications over a low voltage line (the line between + transformer and meter, which is less than 1000 V) through a + transformer of low-voltage to medium-voltage (1000 V up to 72 kV) and + through a transformer of medium-voltage to low-voltage power lines in + + + + +Cam-Winget, et al. Standards Track [Page 9] + +RFC 8036 RPL Applicability for AMI January 2017 + + + both urban and in long distance (multi-kilometer) rural + communications. + + IEEE Std 1901.2 defines the PHY layer and the MAC sub-layer of the + data link layer. The MAC sub-layer endorses a subset of IEEE + Std 802.15.4 and IEEE 802.15.4e MAC sub-layer features. + + The IEEE Std 1901.2 PHY layer bit rates are scalable up to 500 kbps + depending on the application requirements and type of encoding used. + + The IEEE Std 1901.2 MAC layer allows for transport of a full IPv6 + packet (i.e., 1280 octets) without the need for upper-layer + segmentation and reassembly. + + IEEE Std 1901.2 specifies the necessary link-layer security features + that fully endorse the IEEE 802.15.4 MAC sub-layer security scheme. + +6. Using RPL to Meet Functional Requirements + + The functional requirements for most AMI deployments are similar to + those listed in [RFC5548]. This section informally highlights some + of the similarities: + + o The routing protocol MUST be capable of supporting the + organization of a large number of nodes into regions containing on + the order of 10^2 to 10^4 nodes each. + + o The routing protocol MUST provide mechanisms to support + configuration of the routing protocol itself. + + o The routing protocol SHOULD support and utilize the large number + of highly directed flows to a few head-end servers to handle + scalability. + + o The routing protocol MUST dynamically compute and select effective + routes composed of low-power and lossy links. Local network + dynamics SHOULD NOT impact the entire network. The routing + protocol MUST compute multiple paths when possible. + + o The routing protocol MUST support multicast and unicast + addressing. The routing protocol SHOULD support formation and + identification of groups of field devices in the network. + + + + + + + + + +Cam-Winget, et al. Standards Track [Page 10] + +RFC 8036 RPL Applicability for AMI January 2017 + + + RPL supports the following features: + + o Scalability: Large-scale networks characterized by highly directed + traffic flows between each smart meter and the head-end servers in + the utility network. To this end, RPL builds a Directed Acyclic + Graph (DAG) rooted at each LBR. + + o Zero-touch configuration: This is done through in-band methods for + configuring RPL variables using DIO (DODAG Information Object) + messages and DIO message options [RFC6550]. + + o The use of links with time-varying quality characteristics: This + is accomplished by allowing the use of metrics that effectively + capture the quality of a path (e.g., Expected Transmission Count + (ETX)) and by limiting the impact of changing local conditions by + discovering and maintaining multiple DAG parents (and by using + local repair mechanisms when DAG links break). + +7. RPL Profile + +7.1. RPL Features + +7.1.1. RPL Instances + + RPL operation is defined for a single RPL instance. However, + multiple RPL instances can be supported in multi-service networks + where different applications may require the use of different routing + metrics and constraints, e.g., a network carrying both SMD and DA + traffic. + +7.1.2. DAO Policy + + Two-way communication is a requirement in AMI systems. As a result, + nodes SHOULD send Destination Advertisement Object (DAO) messages to + establish downward paths from the root to themselves. + +7.1.3. Path Metrics + + Smart metering deployments utilize link technologies that may exhibit + significant packet loss and thus require routing metrics that take + packet loss into account. To characterize a path over such link + technologies, AMI deployments can use the ETX metric as defined in + [RFC6551]. + + Additional metrics may be defined in companion RFCs. + + + + + + +Cam-Winget, et al. Standards Track [Page 11] + +RFC 8036 RPL Applicability for AMI January 2017 + + +7.1.4. Objective Function + + RPL relies on an Objective Function for selecting parents and + computing path costs and rank. This objective function is decoupled + from the core RPL mechanisms and also from the metrics in use in the + network. Two objective functions for RPL have been defined at the + time of this writing, Objective Function 0 (OF0) [RFC6552] and + Minimum Rank with Hysteresis Objective Function (MRHOF) [RFC6719], + both of which define the selection of a preferred parent and backup + parents and are suitable for AMI deployments. + + Additional objective functions may be defined in companion RFCs. + +7.1.5. DODAG Repair + + To effectively handle time-varying link characteristics and + availability, AMI deployments SHOULD utilize the local repair + mechanisms in RPL. Local repair is triggered by broken link + detection. The first local repair mechanism consists of a node + detaching from a DODAG and then reattaching to the same or to a + different DODAG at a later time. While detached, a node advertises + an infinite rank value so that its children can select a different + parent. This process is known as "poisoning" and is described in + Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a + local DODAG, doing so in AMI for electric meters is of little benefit + since AMI applications typically communicate through an LBR. After + the detached node has made sufficient effort to send a notification + to its children that it is detached, the node can rejoin the same + DODAG with a higher rank value. The configured duration of the + poisoning mechanism needs to take into account the disconnection time + that applications running over the network can tolerate. Note that + when joining a different DODAG, the node need not perform poisoning. + The second local repair mechanism controls how much a node can + increase its rank within a given DODAG version (e.g., after detaching + from the DODAG as a result of broken link or loop detection). + Setting the DAGMaxRankIncrease to a non-zero value enables this + mechanism, and setting it to a value of less than infinity limits the + cost of count-to-infinity scenarios when they occur, thus controlling + the duration of disconnection applications may experience. + +7.1.6. Multicast + + Multicast support for RPL in non-storing mode are being developed in + companion RFCs (see [RFC7731]). + + + + + + + +Cam-Winget, et al. Standards Track [Page 12] + +RFC 8036 RPL Applicability for AMI January 2017 + + +7.1.7. Security + + AMI deployments operate in areas that do not provide any physical + security. For this reason, the link-layer, transport-layer, and + application-layer technologies utilized within AMI networks typically + provide security mechanisms to ensure authentication, + confidentiality, integrity, and freshness. As a result, AMI + deployments may not need to implement RPL's security mechanisms; they + MUST include, at a minimum, link-layer security such as that defined + by IEEE 1901.2 and IEEE 802.15.4. + +7.2. Description of Layer-2 Features + +7.2.1. IEEE 1901.2 PHY and MAC Sub-layer Features + + The IEEE Std 1901.2 PHY layer is based on OFDM modulation and defines + a time frequency interleaver over the entire PHY frame coupled with a + Reed Solomon and Viterbi Forward Error Correction for maximum + robustness. Since the noise level in each OFDM subcarrier can vary + significantly, IEEE 1901.2 specifies two complementary mechanisms + that allow fine-tuning of the robustness/performance tradeoff + implicit in such systems. More specifically, the first (coarse- + grained) mechanism defines the modulation from several possible + choices (robust (super-ROBO, ROBO), BPSK, QPSK, and so on). The + second (fine-grained) mechanism maps the subcarriers that are too + noisy and deactivates them. + + The existence of multiple modulations and dynamic frequency exclusion + renders the problem of selecting a path between two nodes non-trivial + as the possible number of combinations increases significantly, e.g., + use a direct link with slow robust modulation or use a relay meter + with fast modulation and 12 disabled subcarriers. In addition, IEEE + 1901.2 technology offers a mechanism (adaptive tone map) for periodic + exchanges on the link quality between nodes to constantly react to + channel fluctuations. Every meter keeps a state of the quality of + the link to each of its neighbors by either piggybacking the tone + mapping on the data traffic or by sending explicit tone map requests. + + The IEEE 1901.2 MAC frame format shares most in common with the IEEE + 802.15.4 MAC frame format [IEEE.802.15.4]. A few exceptions are + described below. + + o The IEEE 1901.2 MAC frame is obtained by prepending a Segment + Control Field to the IEEE 802.15.4 MAC header. One function of + the Segment Control Field is to signal the use of the MAC + sub-layer segmentation and reassembly. + + + + + +Cam-Winget, et al. Standards Track [Page 13] + +RFC 8036 RPL Applicability for AMI January 2017 + + + o IEEE 1901.2 MAC frames use only the 802.15.4 MAC addresses with a + length of 16 and 64 bits. + + o The IEEE 1901.2 MAC sub-layer endorses the concept of Information + Elements, as defined in [IEEE.802.15.4e]. The format and use of + Information Elements are not relevant to the RPL applicability + statement. + + The IEEE 1901.2 PHY frame payload size varies as a function of the + modulation used to transmit the frame and the strength of the Forward + Error Correction scheme. + + The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY + settings in use (e.g., bandwidth, modulation, tones, etc). As quoted + from the IEEE 1901.2 specification: + + For CENELEC A/B, if MSDU size is more than 247 octets for robust + OFDM (ROBO) and Super-ROBO modulations or more than 239 octets for + all other modulations, the MAC layer shall divide the MSDU into + multiple segments as described in 5.3.7. For FCC and ARIB, if the + MSDU size meets one of the following conditions: a) For ROBO and + Super-ROBO modulations, the MSDU size is more than 247 octets but + less than 494 octets, b) For all other modulations, the MSDU size + is more than 239 octets but less than 478 octets. + +7.2.2. IEEE 802.15.4 (Amendments G and E) PHY and MAC Features + + IEEE Std 802.15.4g defines multiple modes of operation, where each + mode uses different modulation and has multiple data rates. + Additionally, the 802.15.4g PHY layer includes mechanisms to improve + the robustness of the radio communications, such as data whitening + and Forward Error Correction coding. The 802.15.4g PHY frame payload + can carry up to 2048 octets. + + IEEE Std 802.15.4g defines the following modulations: Multi-Rate and + Multi-Regional FSK (MR-FSK), MR-OFDM, and MR-O-QPSK. The (over-the- + air) bit rates for these modulations range from 4.8 to 600 kbps for + MR-FSK, from 50 to 600 kbps for MR-OFDM, and from 6.25 to 500 kbps + for MR-O-QPSK. + + The MAC sub-layer running on top of a 4g radio link is based on IEEE + 802.15.4e. The 802.15.4e MAC allows for a variety of modes for + operation. These include: + + o Timetimeslotslotted Channel Hopping (TSCH): specifically designed + for application domains such as process automation + + + + + +Cam-Winget, et al. Standards Track [Page 14] + +RFC 8036 RPL Applicability for AMI January 2017 + + + o Low-Latency Deterministic Networks (LLDN): for application domains + such as factory automation. + + o Deterministic and Synchronous Multi-channel Extension (DSME): for + general industrial and commercial application domains that + includes channel diversity to increase network robustness. + + o Asynchronous Multi-channel Adaptation (AMCA): for large + infrastructure application domains. + + The MAC addressing scheme supports short (16-bit) addresses along + with extended (64-bit) addresses. These addresses are assigned in + different ways and are specified by specific standards organizations. + Information Elements, Enhanced Beacons, and frame version 2, as + defined in IEEE 802.15.4e, MUST be supported. + + Since the MAC frame payload size limitation is given by the 4g PHY + frame payload size limitation (i.e., 2048 bytes) and MAC layer + overhead (headers, trailers, Information Elements, and security + overhead), the MAC frame payload MUST able to carry a full IPv6 + packet of 1280 octets without upper-layer fragmentation and + reassembly. + +7.2.3. IEEE MAC Sub-layer Security Features + + Since the IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer + and fully endorses the security scheme defined in 802.15.4, we only + focus on the description of the IEEE 802.15.4 security scheme. + + The IEEE 802.15.4 specification was designed to support a variety of + applications, many of which are security sensitive. IEEE 802.15.4 + provides four basic security services: message authentication, + message integrity, message confidentiality, and freshness checks to + avoid replay attacks. + + The 802.15.4 security layer is handled at the media access control + layer, below the 6LowPAN (IPv6 over Low-Power Wireless Personal Area + Network) layer. The application specifies its security requirements + by setting the appropriate control parameters into the radio/PLC + stack. IEEE 802.15.4 defines four packet types: beacon frames, data + frames, acknowledgment frames, and command frames for the media + access control layer. The 802.15.4 specification does not support + security for acknowledgement frames; data frames, beacon frames, and + command frames can support integrity protection and confidentiality + protection for the frames' data field. An application has a choice + of security suites that control the type of security protection that + is provided for the transmitted MAC frame. Each security suite + offers a different set of security properties and guarantees, and + + + +Cam-Winget, et al. Standards Track [Page 15] + +RFC 8036 RPL Applicability for AMI January 2017 + + + ultimately offers different MAC frame formats. The 802.15.4 + specification defines eight different security suites, outlined + below. We can broadly classify the suites by the properties that + they offer: no security, encryption only (AES-CTR), authentication + only (AES-CBC-MAC), and encryption and authentication (AES-CCM). + Each category that supports authentication comes in three variants + depending on the size of the Message Authentication Code that it + offers. The MAC can be either 4, 8, or 16 bytes long. Additionally, + for each suite that offers encryption, the recipient can optionally + enable replay protection. + + o Null = No security + + o AES-CTR = Encryption only, CTR mode + + o AES-CBC-MAC-128 = No encryption, 128-bit MAC + + o AES-CBC-MAC-64 = No encryption, 64-bit MAC + + o AES-CCM-128 = Encryption and 128-bit MAC + + o AES-CCM-64 = Encryption and 64-bit MAC + + o AES-CCM-32 = Encryption and 32-bit MAC + + Note that AES-CCM-32 is the most commonly used cipher in these + deployments today. + + To achieve authentication, any device can maintain an Access Control + List (ACL), which is a list of trusted nodes from which the device + wishes to receive data. Data encryption is done by encryption of + Message Authentication Control frame payload using the key shared + between two devices or among a group of peers. If the key is to be + shared between two peers, it is stored with each entry in the ACL + list; otherwise, the key is stored as the default key. Thus, the + device can make sure that its data cannot be read by devices that do + not possess the corresponding key. However, device addresses are + always transmitted unencrypted, which makes attacks that rely on + device identity somewhat easier to launch. Integrity service is + applied by appending a Message Integrity Code (MIC) generated from + blocks of encrypted message text. This ensures that a frame cannot + be modified by a receiver device that does not share a key with the + sender. Finally, sequential freshness uses a frame counter and key + sequence counter to ensure the freshness of the incoming frame and + guard against replay attacks. + + A cryptographic Message Authentication Code (or keyed MIC) is used to + authenticate messages. While longer MICs lead to improved resiliency + + + +Cam-Winget, et al. Standards Track [Page 16] + +RFC 8036 RPL Applicability for AMI January 2017 + + + of the code, they also make the packet size larger and thus take up + bandwidth in the network. In constrained environments such as + metering infrastructures, an optimum balance between security + requirements and network throughput must be found. + +7.3. 6LowPAN Options + + AMI implementations based on IEEE 1901.2 and 802.15.4 (amendments g + and e) can utilize all of the IPv6 Header Compression schemes + specified in Section 3 of [RFC6282] and all of the IPv6 Next Header + compression schemes specified in Section 4 of [RFC6282], if reducing + over the air/wire overhead is a requirement. + +7.4. Recommended Configuration Defaults and Ranges + +7.4.1. Trickle Parameters + + Trickle [RFC6206] was designed to be density aware and perform well + in networks characterized by a wide range of node densities. The + combination of DIO packet suppression and adaptive timers for sending + updates allows Trickle to perform well in both sparse and dense + environments. Node densities in AMI deployments can vary greatly, + from nodes having only one or a handful of neighbors to nodes having + several hundred neighbors. In high-density environments, relatively + low values for Imin may cause a short period of congestion when an + inconsistency is detected and DIO updates are sent by a large number + of neighboring nodes nearly simultaneously. While the Trickle timer + will exponentially backoff, some time may elapse before the + congestion subsides. While some link layers employ contention + mechanisms that attempt to avoid congestion, relying solely on the + link layer to avoid congestion caused by a large number of DIO + updates can result in increased communication latency for other + control and data traffic in the network. To mitigate this kind of + short-term congestion, this document recommends a more conservative + set of values for the Trickle parameters than those specified in + [RFC6206]. In particular, DIOIntervalMin is set to a larger value to + avoid periods of congestion in dense environments, and + DIORedundancyConstant is parameterized accordingly as described + below. These values are appropriate for the timely distribution of + DIO updates in both sparse and dense scenarios while avoiding the + short-term congestion that might arise in dense scenarios. Because + the actual link capacity depends on the particular link technology + used within an AMI deployment, the Trickle parameters are specified + in terms of the link's maximum capacity for transmitting link-local + multicast messages. If the link can transmit m link-local multicast + packets per second on average, the expected time it takes to transmit + a link-local multicast packet is 1/m seconds. + + + + +Cam-Winget, et al. Standards Track [Page 17] + +RFC 8036 RPL Applicability for AMI January 2017 + + + DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that + the Trickle Imin is at least 50 times as long as it takes to + transmit a link-local multicast packet. This value is larger than + that recommended in [RFC6206] to avoid congestion in dense urban + deployments as described above. + + DIOIntervalDoublings: AMI deployments SHOULD set + DIOIntervalDoublings such that the Trickle Imax is at least 2 + hours or more. + + DIORedundancyConstant: AMI deployments SHOULD set + DIORedundancyConstant to a value of at least 10. This is due to + the larger chosen value for DIOIntervalMin and the proportional + relationship between Imin and k suggested in [RFC6206]. This + increase is intended to compensate for the increased communication + latency of DIO updates caused by the increase in the + DIOIntervalMin value, though the proportional relationship between + Imin and k suggested in [RFC6206] is not preserved. Instead, + DIORedundancyConstant is set to a lower value in order to reduce + the number of packet transmissions in dense environments. + +7.4.2. Other Parameters + + o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in + 8 bits of resolution (e.g., for the ETX metric). + + o To enable local repair, AMI deployments SHOULD set MaxRankIncrease + to a value that allows a device to move a small number of hops + away from the root. With a MinHopRankIncrease of 256, a + MaxRankIncrease of 1024 would allow a device to move up to 4 hops + away. + +8. Manageability Considerations + + Network manageability is a critical aspect of smart grid network + deployment and operation. With millions of devices participating in + the smart grid network, many requiring real-time reachability, + automatic configuration, and lightweight-network health monitoring + and management are crucial for achieving network availability and + efficient operation. RPL enables automatic and consistent + configuration of RPL routers through parameters specified by the + DODAG root and disseminated through DIO packets. The use of Trickle + for scheduling DIO transmissions ensures lightweight yet timely + propagation of important network and parameter updates and allows + network operators to choose the trade-off point with which they are + comfortable with respect to overhead vs. reliability and timeliness + of network updates. The metrics in use in the network along with the + Trickle Timer parameters used to control the frequency and redundancy + + + +Cam-Winget, et al. Standards Track [Page 18] + +RFC 8036 RPL Applicability for AMI January 2017 + + + of network updates can be dynamically varied by the root during the + lifetime of the network. To that end, all DIO messages SHOULD + contain a Metric Container option for disseminating the metrics and + metric values used for DODAG setup. In addition, DIO messages SHOULD + contain a DODAG Configuration option for disseminating the Trickle + Timer parameters throughout the network. The possibility of + dynamically updating the metrics in use in the network as well as the + frequency of network updates allows deployment characteristics (e.g., + network density) to be discovered during network bring-up and to be + used to tailor network parameters once the network is operational + rather than having to rely on precise pre-configuration. This also + allows the network parameters and the overall routing protocol + behavior to evolve during the lifetime of the network. RPL specifies + a number of variables and events that can be tracked for purposes of + network fault and performance monitoring of RPL routers. Depending + on the memory and processing capabilities of each smart grid device, + various subsets of these can be employed in the field. + +9. Security Considerations + + Smart grid networks are subject to stringent security requirements, + as they are considered a critical infrastructure component. At the + same time, they are composed of large numbers of resource-constrained + devices interconnected with limited-throughput links. As a result, + the choice of security mechanisms is highly dependent on the device + and network capabilities characterizing a particular deployment. + + In contrast to other types of LLNs, in smart grid networks both + centralized administrative control and access to a permanent secure + infrastructure are available. As a result, smart grid networks are + deployed with security mechanisms such as link-layer, transport- + layer, and/or application-layer security mechanisms; while it is best + practice to secure all layers, using RPL's secure mode may not be + necessary. Failure to protect any of these layers can result in + various attacks; a lack of strong authentication of devices in the + infrastructure can lead to uncontrolled and unauthorized access. + Similarly, failure to protect the communication layers can enable + passive (in wireless mediums) attacks as well as man-in-the-middle + and active attacks. + + As this document describes the applicability of RPL non-storing mode, + the security considerations as defined in [RFC6550] also apply to + this document and to AMI deployments. + + + + + + + + +Cam-Winget, et al. Standards Track [Page 19] + +RFC 8036 RPL Applicability for AMI January 2017 + + +9.1. Security Considerations during Initial Deployment + + During the manufacturing process, the meters are loaded with the + appropriate security credentials (keys and certificates). The + configured security credentials during manufacturing are used by the + devices to authenticate with the system and to further negotiate + operational security credentials for both network and application + layers. + +9.2. Security Considerations during Incremental Deployment + + If during the system operation a device fails or is known to be + compromised, it is replaced with a new device. The new device does + not take over the security identity of the replaced device. The + security credentials associated with the failed/compromised device + are removed from the security appliances. + +9.3. Security Considerations Based on RPL's Threat Analysis + + [RFC7416] defines a set of security considerations for RPL security. + This document defines how it leverages the device's link-layer and + application-layer security mechanisms to address the threats as + defined in Section 6 of [RFC7416]. + + Like any secure network infrastructure, an AMI deployment's ability + to address node impersonation and active man-in-the-middle attacks + rely on a mutual authentication and authorization process. To enable + strong mutual authentication, all nodes, from smart meters to nodes + in the infrastructure, must have a credential. The credential may be + bootstrapped at the time the node is manufactured but must be + appropriately managed and classified through the authorization + process. The management and authorization process ensures that the + nodes are properly authenticated and behaving or 'acting' in their + assigned roles. + + Similarly, to ensure that data has not been modified, confidentiality + and integrity at the suitable layers (e.g., the link layer, the + application layer, or both) should be used. + + To provide the security mechanisms to address these threats, an AMI + deployment MUST include the use of the security schemes as defined by + IEEE 1901.2 (and IEEE 802.15.4) with IEEE 802.15.4 defining the + security mechanisms to afford mutual authentication, access control + (e.g., authorization), and transport confidentiality and integrity. + + + + + + + +Cam-Winget, et al. Standards Track [Page 20] + +RFC 8036 RPL Applicability for AMI January 2017 + + +10. Privacy Considerations + + Privacy of information flowing through smart grid networks are + subject to consideration. An evolving set of recommendations and + requirements are being defined by different groups and consortiums; + for example, the U.S. Department of Energy issued a document [DOEVCC] + defining a process and set of recommendations to address privacy + issues. As this document describes the applicability of RPL, the + privacy considerations as defined in [PRIVACY] and [EUPR] apply to + this document and to AMI deployments. + +11. References + +11.1. Normative References + + [IEEE.1901.2] + IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz) + Narrowband Power Line Communications for Smart Grid + Applications", IEEE 1901.2-2013, + DOI 10.1109/ieeestd.2013.6679210, December 2013, + <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6679208>. + + [IEEE.802.15.4] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Part 15.4: Low-Rate Wireless Personal Area + Networks (LR-WPANs)", IEEE 802.15.4-2011, + DOI 10.1109/ieeestd.2011.6012487, September 2011, + <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6012485>. + + [IEEE.802.15.4e] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Part 15.4: Low-Rate Wireless Personal Area + Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE + 802.15.4e-2012, DOI 10.1109/ieeestd.2012.6185525, April + 2012, <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6185523>. + + [IEEE.802.15.4g] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Part 15.4: Low-Rate Wireless Personal Area + Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) + Specifications for Low-Data-Rate, Wireless, Smart Metering + Utility Networks", IEEE 802.15.4g-2012, + DOI 10.1109/ieeestd.2012.6190698, April 2012, + <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6190696>. + + + +Cam-Winget, et al. Standards Track [Page 21] + +RFC 8036 RPL Applicability for AMI January 2017 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., + Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, + JP., and R. Alexander, "RPL: IPv6 Routing Protocol for + Low-Power and Lossy Networks", RFC 6550, + DOI 10.17487/RFC6550, March 2012, + <http://www.rfc-editor.org/info/rfc6550>. + + [surveySG] Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., + Cecati, C., and G. Hancke, "A Survey on Smart Grid + Potential Applications and Communication Requirements", + IEEE Transactions on Industrial Informatics Volume 9, + Issue 1, pp. 28-42, DOI 10.1109/TII.2012.2218253, February + 2013. + +11.2. Informative references + + [DOEVCC] "Voluntary Code of Conduct (VCC) Final Concepts and + Principles", January 2015, + <http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Conc + epts%20and%20Principles%202015_01_08%20FINAL.pdf>. + + [EUPR] "Information for investors and data controllers", June + 2016, <https://ec.europa.eu/energy/node/1748>. + + [IEEE.802.11] + IEEE, "IEEE Standard for Information technology-- + Telecommunications and information exchange between + systems Local and metropolitan area networks--Specific + requirements Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) Specifications", + IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, March + 2012, <https://standards.ieee.org/getieee802/ + download/802.11-2012.pdf>. + + [PRIVACY] Thaler, D., "Privacy Considerations for IPv6 Adaptation + Layer Mechanisms", Work in Progress, draft-ietf-6lo- + privacy-considerations-04, October 2016. + + [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and + D. Barthel, Ed., "Routing Requirements for Urban Low-Power + and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May + 2009, <http://www.rfc-editor.org/info/rfc5548>. + + + + +Cam-Winget, et al. Standards Track [Page 22] + +RFC 8036 RPL Applicability for AMI January 2017 + + + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, + March 2011, <http://www.rfc-editor.org/info/rfc6206>. + + [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 + Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, + DOI 10.17487/RFC6282, September 2011, + <http://www.rfc-editor.org/info/rfc6282>. + + [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., + and D. Barthel, "Routing Metrics Used for Path Calculation + in Low-Power and Lossy Networks", RFC 6551, + DOI 10.17487/RFC6551, March 2012, + <http://www.rfc-editor.org/info/rfc6551>. + + [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing + Protocol for Low-Power and Lossy Networks (RPL)", + RFC 6552, DOI 10.17487/RFC6552, March 2012, + <http://www.rfc-editor.org/info/rfc6552>. + + [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with + Hysteresis Objective Function", RFC 6719, + DOI 10.17487/RFC6719, September 2012, + <http://www.rfc-editor.org/info/rfc6719>. + + [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and + Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January + 2014, <http://www.rfc-editor.org/info/rfc7102>. + + [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., + and M. Richardson, Ed., "A Security Threat Analysis for + the Routing Protocol for Low-Power and Lossy Networks + (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, + <http://www.rfc-editor.org/info/rfc7416>. + + [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power + and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, + February 2016, <http://www.rfc-editor.org/info/rfc7731>. + + + + + + + + + + + + + +Cam-Winget, et al. Standards Track [Page 23] + +RFC 8036 RPL Applicability for AMI January 2017 + + +Acknowledgements + + Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden + were contributors and noted as authors in earlier versions of this + document. The authors would also like to acknowledge the review, + feedback, and comments of Jari Arkko, Dominique Barthel, Cedric + Chauvenet, Yuichi Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas + Dejean, and JP Vasseur. + +Authors' Addresses + + Nancy Cam-Winget (editor) + Cisco Systems + 3550 Cisco Way + San Jose, CA 95134 + United States of America + + Email: ncamwing@cisco.com + + + Jonathan Hui + Nest + 3400 Hillview Ave + Palo Alto, CA 94304 + United States of America + + Email: jonhui@nestlabs.com + + + Daniel Popa + Itron, Inc + 52, rue Camille Desmoulins + Issy les Moulineaux 92130 + France + + Email: daniel.popa@itron.com + + + + + + + + + + + + + + + +Cam-Winget, et al. Standards Track [Page 24] + |