tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6272


Internet Protocols for the Smart Grid

Part 4 of 4, p. 58 to 66
Prev RFC Part


prevText      Top      Up      ToC       Page 58 
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

   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:

Top      Up      ToC       Page 59 
      *  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

   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

Top      Up      ToC       Page 60 
   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

   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.

Top      Up      ToC       Page 61 
                   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.

Top      Up      ToC       Page 62 
   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

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

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/

Top      Up      ToC       Page 63 
      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

Top      Up      ToC       Page 64 
   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

   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.

Top      Up      ToC       Page 65 
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
                 |      +------/------ 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

Top      Up      ToC       Page 66 
   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

   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


   David Meyer
   Cisco Systems
   Eugene, Oregon  97403