RFC 3251 - Electricity over IP and EDOS attack


Network Working Group                                     B. Rajagopalan

Request for Comments: 3251                                 Tellium, Inc.

Category: Informational                                     1 April 2002



                          Electricity over IP


Status of this Memo


   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.


Copyright Notice


   Copyright (C) The Internet Society (2002).  All Rights Reserved.




   Mostly Pointless Lamp Switching (MPLampS) is an architecture for

   carrying electricity over IP (with an MPLS control plane).  According

   to our marketing department, MPLampS has the potential to

   dramatically lower the price, ease the distribution and usage, and

   improve the manageability of delivering electricity.  This document

   is motivated by such work as SONET/SDH over IP/MPLS (with apologies

   to the authors).  Readers of the previous work have been observed

   scratching their heads and muttering, "What next?".  This document

   answers that question.


   This document has also been written as a public service.  The "Sub-

   IP" area has been formed to give equal opportunity to those working

   on technologies outside of traditional IP networking to write

   complicated IETF documents.  There are possibly many who are

   wondering how to exploit this opportunity and attain high visibility.

   Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS

   control for random technologies) as highly amenable for producing a

   countless number of unimplementable documents.  This document

   illustrates the key ingredients that go into producing any "foo-

   over-MPLS" document and may be used as a template for all such work.


1. Conventions used in this document


   The key words "MUST", "MUST NOT", "DO", "DON'T", "REQUIRED", "SHALL",


   and "OPTIONAL" in this document do not mean anything.







Rajagopalan                  Informational                      [Page 1]


RFC 3251                  Electricity over IP               1 April 2002



2. Pre-requisite for reading this document


   While reading this document, at various points the readers may have

   the urge to ask questions like, "does this make sense?", "is this

   feasible?," and "is the author sane?".  The readers must have the

   ability to suppress such questions and read on.  Other than this, no

   specific technical background is required to read this document.  In

   certain cases (present document included), it may be REQUIRED that

   readers have no specific technical background.


3. Introduction


   It was recently brought to our attention that the distribution

   network for electricity is not an IP network!  After absorbing the

   shock that was delivered by this news, the following thoughts

   occurred to us:


   1. Electricity distribution must be based on some outdated technology

      (called "Legacy Distribution System" or LDS in the rest of the


   2. An LDS not based on the Internet technology means that two

      different networks (electricity and IP) must be administered and

      managed.  This leads to inefficiencies, higher cost and

      bureaucratic foul-ups (which possibly lead to blackouts in

      California.  We are in the process of verifying this using

      simulations as part of a student's MS thesis).

   3. The above means that a single network technology (i.e., IP) must

      be used to carry both electricity and Internet traffic.

   4. An internet draft must be written to start work in this area,

      before someone else does.

   5. Such a draft can be used to generate further drafts, ensuring that

      we (and CCAMP, MPLS or another responsible working group) will be

      busy for another year.

   6. The draft can also be posted in the "white papers" section of our

      company web page, proclaiming us as revolutionary pioneers.


   Hence the present document.


4. Terminology


   MPLampS: Mostly Pointless Lamp Switching - the architecture

   introduced in this document.


   Lamp: An end-system in the MPLampS architecture (clashes with the

   IETF notion of end-system but of course, we DON'T care).


   LER: Low-voltage Electricity Receptor - fancy name for "Lamp".





Rajagopalan                  Informational                      [Page 2]


RFC 3251                  Electricity over IP               1 April 2002



   ES: Electricity source - a generator.


   LSR: Load-Switching Router - an MPLampS device used in the core

   electricity distribution network.


   LDS: Legacy Distribution System - an inferior electricity

   distribution technology that MPLampS intends to replace.


   RSVP: Rather Screwed-up, but router Vendors Push it - an IP signaling



   RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS,

   to be used in the new deregulated utilities environment.


   CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling



   OSPF: Often Seizes-up in multiPle area conFigurations - a

   hierarchical IP routing protocol.


   ISIS: It's not oSpf, yet It somehow Survives - another routing



   OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.


   COPS: Policemen.  Folks who scour all places for possibilities to

   slip in the Common Open Policy Service protocol.


   VPN: Voltage Protected Network - allows a customer with multiple

   sites to receive electricity with negligible voltage fluctuation due

   to interference from other customers.


   SUB-IP: SUBstitute IP everywhere - an effort in the IETF to get

   involved in technical areas outside of traditional IP networking

   (such as MPLampS).


   ITU: International Tariffed Utilities association - a utilities trade

   group whose work is often ignored by the IETF.


5. Background


   We dug into the electricity distribution technology area to get some

   background.  What we found stunned us, say, with the potency of a

   bare 230V A/C lead dropped into our bathtub while we were still in

   it.  To put it simply, electricity is generated and distributed along

   a vast LDS which does not have a single router in it (LSR or

   otherwise)!  Furthermore, the control of devices in this network is

   mostly manual, done by folks driving around in trucks.  After




Rajagopalan                  Informational                      [Page 3]


RFC 3251                  Electricity over IP               1 April 2002



   wondering momentarily about how such a network can exist in the 21st

   century, we took a pencil and paper and sketched out a scenario for

   integrating the LDS network with the proven Internet technology.  The

   fundamental points we came up with are:


   1. IP packets carry electricity in discrete, digitized form.

   2. Each packet would deliver electricity to its destination (e.g., a

      device with an IP address) on-demand.

   3. MPLS control will be used to switch packets within the core LDS,

      and in the edge premises.  The architecture for this is referred

      to as Mostly-Pointless Lamp Switching (MPLampS).

   4. The MPLampS architectural model will accommodate both the overlay

      model, where the electricity consuming devices (referred to as

      "lamps") are operated over a distinct control plane, and the peer

      model, in which the lamps and the distribution network use a

      single control plane.

   5. RSVP-TE (RSVP with Tariff Extensions) will be used for

      establishing paths for electricity flow in a de-regulated


   6. COPS will be used to support accounting and policy.


   After jotting these points down, we felt better.  We then noted the

   following immediate advantages of the proposed scheme:


   1. Switches and transformers in the LDS can be replaced by LSRs,

      thereby opening up a new market for routers.

   2. Electricity can be routed over the Internet to reach remote places

      which presently do not have electricity connections but have only

      Internet kiosks (e.g., rural India).

   3. Electrical technicians can be replaced by highly paid IP network

      administrators, and

   4. The IETF can get involved in another unrelated technology area.


   In the following, we describe the technical issues in a vague manner.


6. Electricity Encoding


   The Discrete Voltage Encoding (DVE) scheme has been specified in ITU

   standard G.110/230V [2] to digitize electrical voltages.  In essence,

   an Electricity Source (ES) such as a generator is connected to a DV

   encoder that encodes the voltage and current, and  produces a bit

   stream.  This bit stream can be carried in IP packets to various

   destinations (referred to as LERs - Low-voltage Electricity

   Receptors) on-demand.  At the destination, a DV decoder produces the

   right voltage and current based on the received bit stream.  It is to

   be determined whether the Real-time Transport Protocol (RTP) can be






Rajagopalan                  Informational                      [Page 4]


RFC 3251                  Electricity over IP               1 April 2002



   used for achieving synchronization and end-to-end control.  We leave

   draft writing opportunities in the RTP area to our friends and



7. MPLampS Architecture


7.1  Overview


   In an LDS, the long-haul transmission of electricity is at high

   voltages.  The voltage is stepped down progressively as electricity

   flows into local distribution networks and is finally delivered to

   LERs at a standard voltage (e.g., 110V).  Thus, the LDS is a

   hierarchical network.  This immediately opens up the possibility of

   OSPF and ISIS extensions for routing electricity in a transmission

   network, but we'll contain the urge to delve into these productive

   internet draft areas until later.  For the present, we limit our

   discussion merely to controlling the flow of electricity in an IP-

   based distribution network using MPLampS.


   Under MPLampS, a voltage is equated to a label.  In the distribution

   network, each switching element and transformer is viewed as a load-

   switching router (LSR).  Each IP packet carrying an electricity flow

   is assigned a label corresponding to the voltage.  Electricity

   distribution can then be trivially reduced to the task of label

   (voltage) switching as electricity flows through the distribution

   network.  The configuration of switching elements in the distribution

   network is done through RSVP-TE to provide electricity on demand.


   We admit that the above description is vague and sounds crazy.  The

   example below tries to add more (useless) details, without removing

   any doubts the reader might have about the feasibility of this



   Example: Turning on a Lamp


   It is assumed that the lamp is controlled by an intelligent device

   (e.g, a (light) switch with an MPLampS control plane).  Turning the

   lamp on causes the switch to issue an RSVP-TE request (a PATH message

   with new objects) for the electricity flow.  This PATH message

   traverses across the network to the ES.  The RESV message issued in

   return sets up the label mappings in LSRs.  Finally, electricity

   starts flowing along the path established.  It is expected that the

   entire process will be completed within a few seconds, thereby giving

   the MPLampS architecture a distinct advantage over lighting a candle

   with a damp match stick.







Rajagopalan                  Informational                      [Page 5]


RFC 3251                  Electricity over IP               1 April 2002



7.2  Overlay vs Peer Models


   As noted before, there are two control plane models to be considered.

   Under the overlay model, the lamps and the distribution network

   utilize distinct control planes.  Under the peer model, a single

   control plane is used.  A number of arguments can be made for one

   model versus the other, and these will be covered in the upcoming

   framework document.  We merely observe here that it is the lamp

   vendors who prefer the peer model against the better judgement of the

   LSR vendors.  We, however, want to please both camps regardless of

   the usefulness of either model.  We therefore note here that MPLampS

   supports both models and also migration scenarios from overlay to



7.3 Routing in the Core Network


   The above description of the hierarchical distribution system

   immediately opens up the possibility of applying OSPF and ISIS with

   suitable extensions.  The readers may rest assured that we are

   already working on such concepts as voltage bundling, multi-area

   tariff extensions, insulated LSAs, etc.  Future documents will

   describe the details.


7.4 Voltage Protected Networks (VPNs)


   VPNs allow a customer with multiple sites to get guaranteed

   electricity supply with negligible voltage fluctuations due to

   interference from other customers.  Indeed, some may argue that the

   entire MPLampS architecture may be trashed if not for the possibility

   of doing VPNs.  Whatever be the case, VPNs are a hot topic today and

   the readers are forewarned that we have every intention of writing

   several documents on this.  Specifically, BGP-support for VPNs is an

   area we're presently eyeing with interest.


8. Multicast


   It has been observed that there is a strong spatial and temporal

   locality in electricity demand.  ITU Study Group 55 has studied this

   phenomenon for over a decade and has issued a preliminary report.

   This report states that when a lamp is turned on in one house, it is

   usually the case that lamps are turned on in neighboring houses at

   around the same time (usually at dusk) [3].  This observation has a

   serious implication on the scalability of the signaling mechanism.

   Specifically, the distribution network must be able to handle tens of

   thousands of requests all at once.  The signaling load can be reduced

   if multicast delivery is used.  Briefly, a request for electricity is

   not sent from the lamp all the way to an ES, but is handled by the

   first LSR that is already in the path to another lamp.




Rajagopalan                  Informational                      [Page 6]


RFC 3251                  Electricity over IP               1 April 2002



   Support for this requires the application of multicast routing

   protocols together with RSVP-TE shared reservation styles and the

   development of MPLampS multicast forwarding mode.  We are currently

   studying the following multicast routing protocol:


   o DVMRP: Discrete Voltage Multicast Routing Protocol - this protocol

   works over existing voltage routing protocols but the danger here is

   that electricity is delivered to all lamps when any one lamp is

   turned on.  Indeed, the switching semantics gets annoying - all lamps

   get turned on periodically and those not needed must be switched off

   each time manually.


   Other protocols we will eventually consider are Current-Based Tree

   (CBT) and Practically Irrelevant Multicast (PIM).  An issue we are

   greatly interested in is multicast scope: we would like support for

   distributing electricity with varying scope, from lamps within a

   single Christmas tree to those in entire cities.  Needless to say, we

   will write many detailed documents on these topics as time



9. Security Considerations


   This document MUST be secured in a locked cabinet to prevent it from

   being disposed off with the trash.


10. Summary


   This document described the motivation and high level concepts behind

   Mostly Pointless Lamp Switching (MPLampS), an architecture for

   electricity distribution over IP.  MPLampS utilizes DVE (discrete

   voltage encoding), and an MPLS control plane in the distribution

   network.  Since the aim of this document is to be a high-visibility

   place-holder, we did not get into many details of MPLampS.  Numerous

   future documents, unfortunately, will attempt to provide these



11. References


   1. A. Malis, et al., "SONET/SDH Circuit Emulation Service Over MPLS

      (CEM) Encapsulation", Internet Draft, Work in Progress.


   2. International Tarriffed Utilities association draft standard, ITU

      G.110/230V, "Discrete Voltage Encoding", March, 1999.


   3. International Tarriffed Utilities association technical report,

      ITU (SG-55) TR-432-2000, "Empirical Models for Energy

      Utilization", September, 2000.





Rajagopalan                  Informational                      [Page 7]


RFC 3251                  Electricity over IP               1 April 2002



12. Disclaimer


   The opinions expressed in this document are solely the author's.

   Company's opinions, as always, are proprietary and confidential and

   may be obtained under appropriate NDAs.


13. Author's Address


   Bala Rajagopalan

   Tellium, Inc.

   2 Crescent Place

   Ocean Port, NJ 07757

   Phone: 732-923-4237

   EMail: [email protected]






































Rajagopalan                  Informational                      [Page 8]


RFC 3251                  Electricity over IP               1 April 2002



14. Full Copyright Statement


   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document and translations of it may be copied and furnished to

   others, and derivative works that comment on or otherwise explain it

   or assist in its implementation may be prepared, copied, published

   and distributed, in whole or in part, without restriction of any

   kind, provided that the above copyright notice and this paragraph are

   included on all such copies and derivative works.  However, this

   document itself may not be modified in any way, such as by removing

   the copyright notice or references to the Internet Society or other

   Internet organizations, except as needed for the purpose of

   developing Internet standards in which case the procedures for

   copyrights defined in the Internet Standards process must be

   followed, or as required to translate it into languages other than



   The limited permissions granted above are perpetual and will not be

   revoked by the Internet Society or its successors or assigns.


   This document and the information contained herein is provided on an









   Funding for the RFC Editor function is currently provided by the

   Internet Society.




















Rajagopalan                  Informational                      [Page 9]


Could it be possible to kill a botnet using this project and the memo.
memo: http://www.ietf.org/rfc/rfc3251.txt



Published by:

Reza Rafati's picture

Reza Rafati

Hi, I'm the founder of Cyberwarzone and i'm here to collect and share a lot of information. So stay tuned!

The Netherlands

My website