Internet Draft                                         Bala Rajagopalan
Document: <draft-bala-mplamps-03.txt>                     Tellium, Inc.
This draft expires on June, 20, 2002


       MPLampS: Electricity over IP (with an MPLS control plane)


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


1. Abstract

   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 [2] (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 drafts. 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 countless
   number of unimplementable drafts. This document illustrates the
   key ingredients that go into producing any "foo-over-MPLS" draft
   and may be used as a template for all such work.



Rajagopalan               Expires on 6/20/02                         1

                      draft-bala-mplamps-03.txt



2. Conventions used in this document

   The key words "MUST", "MUST NOT", "DO", "DON'T", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
   "MAY BE" and "OPTIONAL" in this document do not mean anything.


3. Pre-requisite for reading this document

   <Template note: This section on pre-requisite MUST be present in any
   foo-over-MPLS 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.

4. Introduction

   <Template note: In this section, a rationale for "foo-over-MPLS" is
   cooked up>

   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 document).
   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.



Rajagopalan               Expires on 6/20/02                         2

                      draft-bala-mplamps-03.txt


5. Terminology

   <Template note: Any respectable "foo-over-MPLS" draft SHOULD have a
   terminology section>

   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".

   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 protocol.

   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
   protocol.

   OSPF: Often Seizes-up in multiPle area conFigurations - a
   hierarchical IP routing protocol.

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

   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.



Rajagopalan               Expires on 6/20/02                         3

                      draft-bala-mplamps-03.txt



6. Background

   <Template note: This section must give a damning account of the
   current state of foo and then conclude by noting that foo-over-MPLS
   is the solution>

   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
   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
      environment.
   6. COPS will be used to support accounting and policy.

   After jotting these points down, we felt better. We then noted down
   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
      (and justify it by pointing out that since electricity enables IP
      networking, it's within the scope of IETF to work on controlling
      electricity distribution. Such novel arguments are the
      cornerstone of some of the Sub-IP work).

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

Rajagopalan               Expires on 6/20/02                         4

                      draft-bala-mplamps-03.txt


7. Electricity Encoding

   <Template note: This and the next two sections are difficult ones,
   since they get into the technical details. Readers MUST satisfy the
   pre-requisites mentioned in Section 3 to be able to read the document 
   further>

   The Discrete Voltage Encoding (DVE) scheme has been specified in ITU
   standard G.110/230V [3] 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 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 used for
   achieving synchronization and end-to-end control. We leave draft
   writing opportunities in the RTP area to our friends and colleagues.

8. MPLampS Architecture

8.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 it 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
   proposal:

   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

Rajagopalan               Expires on 6/20/02                         5

                      draft-bala-mplamps-03.txt


   message with new objects) for the electric 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.

8.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 draft. 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 peer.


8.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 drafts will describe
   the details.

8.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 drafts on this. Specifically, BGP-
   support for VPNs is an area we're presently eyeing with interest.

9.  Multicast

   <Template Note: Multicast is an obvious area for generating numerous
   impractical drafts. Every foo-over-MPLS draft SHOULD lay the
   groundwork for future drafts on 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

Rajagopalan               Expires on 6/20/02                         6

                      draft-bala-mplamps-03.txt


   usually the case that lamps are turned on in neighboring houses at
   around the same time (usually at dusk) [4]. 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.

   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 drafts on these topics as time progresses.


10. Security Considerations

   <Template Note: The following statement MUST be present in all foo-
   over-MPLS drafts>

   This document MUST be secured in a locked cabinet to prevent it from
   being disposed off with the trash.


11. Summary

   <Template Note: Acknowledge the lack of details in the current document
   and conclude with the dire warning that future drafts will provide
   more details>

   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 drafts, unfortunately, will attempt to provide these details.


Rajagopalan               Expires on 6/20/02                         7

                      draft-bala-mplamps-03.txt


12. References

   1.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   2.  "SONET/SDH Circuit Emulation Service Over MPLS (CEM)
       Encapsulation," Work in Progress.

   3.  International Tarriffed Utilities association draft standard,
       ITU G.110/230V, "Discrete Voltage Encoding", March, 1999.

   4.  International Tarriffed Utilities association technical report,
       ITU (SG-55) TR-432-2000, "Empirical Models for Energy
       Utilization", September, 2000.


13. 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.


14. Author's Address

   Bala Rajagopalan
   Tellium, Inc.
   2 Crescent Place
   Ocean Port, NJ 07757
   Phone: 732-923-4237
   Email: braja@tellium.com























Rajagopalan               Expires on 6/20/02                         8