RFC 6272
Internet Protocols for the Smart Grid
Pages: 66
Informational
Informational
Part 4 of 4 – Pages 58 to 66
Appendix A. Example: Advanced Metering Infrastructure
This appendix provides a worked example of the use of the Internet Protocol Suite in a network such as the Smart Grid's Advanced Metering Infrastructure (AMI). There are several possible models. Figure 6 shows the structure of the AMI as it reaches out towards a set of residences. In this structure, we have the home itself and its Home Area Network (HAN), the Neighborhood Area Network (NAN) that the utility uses to access the meter at the home, and the utility access network that connects a set of NANs to the utility itself. For the purposes of this discussion, assume that the NAN contains a distributed application in a set collectors, which is of course only one way the application could be implemented. --- A thermostats, appliances, etc | ------+----------------------------------- | | |"HAN" | <--- Energy Services Interface (ESI) | +---+---+ | | Meter | Meter is generally an ALG between the AMI and the HAN | +---+---+ V \ --- \ A \ | / | \ | / | "NAN" +--+-+-+---+ Likely a router but could | |Collector | be a front-end application V +----+-----+ gateway for utility --- \ A \ | / | \ | / |"AMI" +--+-+-+--+ | | AMI | | | Headend | V +---------+ --- Figure 6: The HAN, NAN, and Utility in the Advanced Metering Infrastructure There are several questions that have to be answered in describing this picture, which given possible answers yield different possible models. They include at least: o How does Demand Response work? Either:
* The utility presents pricing signals to the home,
* The utility presents pricing signals to individual devices
(e.g., a Pluggable Electric Vehicle),
* The utility adjusts settings on individual appliances within
the home.
o How does the utility access meters at the home?
* The AMI Headend manages the interfaces with the meters,
collecting metering data and passing it on to the appropriate
applications over the Enterprise Bus, or
* Distributed application support ("collectors") might access and
summarize the information; this device might be managed by the
utility or by a service between the utility and its customers.
In implementation, these models are idealized; reality may include
some aspects of each model in specified cases.
The examples include:
1. Appendix A.2 presumes that the HAN, the NAN, and the utility's
network are separate administrative domains and speak application
to application across those domains.
2. Appendix A.3 repeats the first example, but presuming that the
utility directly accesses appliances within the HAN from the
collector.
3. Appendix A.4 repeats the first example, but presuming that the
collector directly forwards traffic as a router in addition to
distributed application chores. Note that this case implies
numerous privacy and security concerns and as such is considered
a less likely deployment model.
A.1. How to Structure a Network
A key consideration in the Internet has been the development of new
link layer technologies over time. The ARPANET originally used a BBN
proprietary link layer called BBN 1822 [r1822]. In the late 1970's,
the ARPANET switched to X.25 as an interface to the 1822 network.
With the deployment of the IEEE 802 series technologies in the early
1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE
802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of
various kinds, Frame Relay, and ATM. A key issue in this evolution
was that the applications developed to run on the Internet use APIs
related to the IPS, and as a result require little or no change to continue operating in a new link layer architecture or a mixture of them. The Smart Grid is likely to see a similar evolution over time. Consider the Home Area Network (HAN) as a readily understandable small network. At this juncture, technologies proposed for residential networks include IEEE P1901, various versions of IEEE 802.15.4, and IEEE 802.11. It is reasonable to expect other technologies to be developed in the future. As the Zigbee Alliance has learned (and as a resulted incorporated the IPS in Smart Energy Profile 2.0), there is significant value in providing a virtual address that is mapped to interfaces or nodes attached to each of those technologies.
Utility NAN / / +----+-----+ +--+ +--+ +--+ | Meter | |D1| |D2| |D3| +-----+----+ ++-+ ++-+ ++-+ | | | | ----+-+-------+----+----+---- IEEE 802.15.4 | +--+---+ |Router+------/------ Residential Broadband +--+---+ | ----+---------+----+----+---- IEEE P1901 | | | ++-+ ++-+ ++-+ |D4| |D5| |D6| +--+ +--+ +--+ A thermostats, appliances, etc | ------+----------------+------------------ |"HAN" | | | +---+---+ +---+---+ | |Router | | Meter | | |or EMS | | | V +---+---+ +---+---+ --- | --- \ | ^ \ | / | |"NAN" \ | / ---+--- | +--+-+-+---+ / \ | |"Pole Top"| | Internet| v +----+-----+ \ / --- ------- Figure 7: Two Views of a Home Area Network There are two possible communication models within the HAN, both of which are likely to be useful. Devices may communicate directly with each other, or they may be managed by some central controller. An example of direct communications might be a light switch that directly commands a lamp to turn on or off. An example of indirect communications might be a control application in a Customer or Building that accepts telemetry from a thermostat, applies some form of policy, and controls the heating and air conditioning systems. In addition, there are high-end appliances in the market today that use residential broadband to communicate with their manufacturers, and obviously the meter needs to communicate with the utility.
Figure 7 shows two simple networks, one of which uses IEEE 802.15.4 and IEEE 1901 domains, and one of which uses an arbitrary LAN within the home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 1901, IEEE 802.11, or anything else that made sense in context. Both show the connectivity between them as a router separate from the energy management system (EMS). This is for clarity; the two could of course be incorporated into a single system, and one could imagine appliances that want to communicate with their manufacturers supporting both a HAN interface and a WiFi interface rather than depending on the router. These are all manufacturer design decisions.A.1.1. HAN Routing
The HAN can be seen as communicating with two kinds of non-HAN networks. One is the home LAN, which may in turn be attached to the Internet, and will generally either derive its prefix from the upstream ISP or use a self-generated Unique Local Addressing (ULA). Another is the utility's NAN, which through an ESI provides utility connectivity to the HAN; in this case the HAN will be addressed by a self-generated ULA (note, however, that in some cases ESI may also provide a prefix via DHCP [RFC3315]). In addition, the HAN will have link-local addresses that can be used between neighboring nodes. In general, an HAN will be comprised of both 802.15.4, 802.11, and possibly other networks. The ESI is a node on the user's residential network, and will not typically provide stateful packet forwarding or firewall services between the HAN and the utility network(s). In general, the ESI is a node on the home network; in some cases, the meter may act as the ESI. However, the ESI must be capable of understanding that most home networks are not 802.15.4 enabled (rather, they are typically 802.11 networks), and that it must be capable of setting up ad hoc networks between various sensors in the home (e.g., between the meter and say, a thermostat) in the event there aren't other networks available.A.1.2. HAN Security
In any network, we have a variety of threats and a variety of possible mitigations. These include, at minimum: Link Layer: Why is your machine able to talk in my network? The WiFi SSIDs often use some form of authenticated access control, which may be a simple encrypted password mechanism or may use a combination of encryption and IEEE 802.1X+EAP-TLS Authentication/
Authorization to ensure that only authorized communicants can use
it. If a LAN has a router attached, the router may also implement
a firewall to filter remote accesses.
Network Layer: Given that your machine is authorized access to my
network, why is your machine talking with my machine? IPsec is a
way of ensuring that computers that can use a network are allowed
to talk with each other, may also enforce confidentiality, and may
provide VPN services to make a device or network appear to be part
of a remote network.
Application: Given that your machine is authorized access to my
network and my machine, why is your application talking with my
application? The fact that your machine and mine are allowed to
talk for some applications doesn't mean they are allowed to for
all applications. (D)TLS, https, and other such mechanisms enable
an application to impose application-to-application controls
similar to the network layer controls provided by IPsec.
Remote Application: How do I know that the data I received is the
data you sent? Especially in applications like electronic mail,
where data passes through a number of intermediaries that one may
or may not really want munging it (how many times have you seen a
URL broken by a mail server?), we have tools (DKIM, S/MIME, and
W3C XML Signatures to name a few) to provide non-repudiability and
integrity verification. This may also have legal ramifications:
if a record of a meter reading is to be used in billing, and the
bill is disputed in court, one could imagine the court wanting
proof that the record in fact came from that meter at that time
and contained that data.
Application-specific security: In addition, applications often
provide security services of their own. The fact that I can
access a file system, for example, doesn't mean that I am
authorized to access everything in it; the file system may well
prevent my access to some of its contents. Routing protocols like
BGP are obsessed with the question "what statements that my peer
made am I willing to believe", and monitoring protocols like SNMP
may not be willing to answer every question they are asked,
depending on access configuration.
Devices in the HAN want controlled access to the LAN in question for
obvious reasons. In addition, there should be some form of mutual
authentication between devices -- the lamp controller will want to
know that the light switch telling it to change state is the right
light switch, for example. The EMS may well want strong
authentication of accesses -- the parents may not want the children
changing the settings, and while the utility and the customer are routinely granted access, other parties (especially parties with criminal intent) need to be excluded.A.2. Model 1: AMI with Separated Domains
With the background given in Appendix A.1, we can now discuss the use of IP (IPv4 or IPv6) in the AMI. In this first model, consider the three domains in Figure 6 to literally be separate administrative domains, potentially operated by different entities. For example, the NAN could be a WiMAX network operated by a traditional telecom operator, the utility's network (including the collector) is its own, and the residential network is operated by the resident. In this model, while communications between the collector and the Meter are normal, the utility has no other access to appliances in the home, and the collector doesn't directly forward messages from the NAN upstream. In this case, as shown in Figure 7, it would make the most sense to design the collector, the Meter, and the EMS as hosts on the NAN -- design them as systems whose applications can originate and terminate exchanges or sessions in the NAN, but not forward traffic from or to other devices. In such a configuration, Demand Response has to be performed by having the EMS accept messages such as price signals from the "pole top", apply some form of policy, and then orchestrate actions within the home. Another possibility is to have the EMS communicate with the ESI located in the meter. If the thermostat has high demand and low demand (day/night or morning/day/evening/night) settings, Demand Response might result in it moving to a lower demand setting, and the EMS might also turn off specified circuits in the home to diminish lighting. In this scenario, Quality of Service (QoS) issues reportedly arise when high precedence messages must be sent through the collector to the home; if the collector is occupied polling the meters or doing some other task, the application may not yield control of the processor to the application that services the message. Clearly, this is either an application or an Operating System problem; applications need to be designed in a manner that doesn't block high precedence messages. The collector also needs to use appropriate NAN services, if they exist, to provide the NAN QoS it needs. For example, if WiMax is in use, it might use a routine-level service for normal exchanges but a higher precedence service for these messages.
A.3. Model 2: AMI with Neighborhood Access to the Home
In this second model, let's imagine that the utility directly accesses appliances within the HAN. Rather than expect an EMS to respond to price signals in Demand Response, it directly commands devices like air conditioners to change state, or throws relays on circuits to or within the home. +----------+ +--+ +--+ +--+ | Meter | |D1| |D2| |D3| +-----+----+ ++-+ ++-+ ++-+ | | | | ----+-+-------+----+----+---- IEEE 802.15.4 | +--+---+ | +------/------ NAN |Router| | +------/------ Residential Broadband +--+---+ | ----+--+------+----+----+---- IEEE P1901 | | | | +-+-+ ++-+ ++-+ ++-+ |EMS| |D4| |D5| |D6| +---+ +--+ +--+ +--+ Figure 8: Home Area Network In this case, as shown in Figure 8, the Meter and EMS act as hosts on the HAN, and there is a router between the HAN and the NAN. As one might imagine, there are serious security considerations in this model. Traffic between the NAN and the residential broadband network should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning. One of the biggest threats may be a legal or at least a public relations issue; if the utility intentionally disables a circuit in a manner or at a time that threatens life (the resident's kidney dialysis machine is on it, or a respirator, for example), the matter might make the papers. Unauthorized access could be part of juvenile pranks or other things as well. So one really wants the appliances to only obey commands under strict authentication/authorization controls. In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the router. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class
described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.A.4. Model 3: Collector Is an IP Router
In this third model, the relationship between the NAN and the HAN is either as in Appendix A.2 or Appendix A.3; what is different is that the collector may be an IP router. In addition to whatever autonomous activities it is doing, it forwards traffic as an IP router in some cases. Analogous to Appendix A.3, there are serious security considerations in this model. Traffic being forwarded should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning -- but this time at the utility mainframe. Unauthorized access is likely similar to other financially-motivated attacks that happen in the Internet, but presumably would be coming from devices in the HAN that have been co-opted in some way. One really wants the appliances to only obey commands under strict authentication/authorization controls. In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the collector. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.Authors' Addresses
Fred Baker Cisco Systems Santa Barbara, California 93117 USA EMail: fred@cisco.com David Meyer Cisco Systems Eugene, Oregon 97403 USA EMail: dmm@cisco.com