Internet Draft Bala Rajagopalan Document: <draft-bala-mplamps-00.txt> Tellium, Inc. This draft expires on March, 8, 2001 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). MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve manageability of delivering electricity. This draft is motivated by such drafts as SONET/SDH over IP/MPLS [2,3] (with apologies to their authors). Readers of the previous drafts have been observed scratching their heads and muttering, "What next?". This draft answers that question. This draft has also been written as a public service. It was recently announced that the routing area will consider work items of the form "foo-over-MPLS". There are possibly many who are wondering how to exploit this opportunity and write random drafts to achieve prominence in the MPLS area. This draft 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 3/8/01 1 draft-bala-MPLampS-00.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> At various points in this draft, 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 draft. In certain cases (present draft included), it is 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 draft). 2. An LDS not based on the Internet technology means two different networks (electricity and IP)_to administer and manage. This leads to inefficiency, higher cost and bureaucratic foul-ups (which possibly results in black-outs in New York city. 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 the 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 visionaries. Hence the present draft. Rajagopalan Expires on 3/8/01 2 draft-bala-MPLampS-00.txt 5. Terminology <Template note: Any respectable "foo-over-MPLS" draft SHOULD have a terminology section> MPLampS: Mostly Pointless Lamp Switching - the architecture we introduce in this draft. Lamp: An end-system in the MPLampS architecture (clashes with the IETF notion of end-system but of course, we MUST NOT care). LER: Low-voltage Electrical Receptor - fancy name for "Lamp" ES: Electrical source - a generator. LSR: Load-Switching Router - an MPLampS device used in the core electrical network. LDS: Legacy Distribution System - an inferior electrical 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, but 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 COPS protocol. VPN: Voltage Protected Network - allows a customer with multiple sites to receive electricity with negligible voltage fluctuation due to interference from other customers. BGP: Basically General Purpose - a flexible TCP application used for interdomain routing, multicast, VPN support, etc. E-BGP: Electrical BGP - the protocol used under MPLampS for VPN support. ITU: International Tariffed Utilities association - a utilities standards group whose work is often ignored by the IETF. Rajagopalan Expires on 3/8/01 3 draft-bala-MPLampS-00.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 for a minute about how such a network can exist in the 21st century, we got a pencil and paper and sketched out a scenario for integrating 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, since we believe that there will be a COPS proposal sooner or later (whether we want it or not). 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 H1-B workers (to administer the network). 4. IETF can claim supremacy in another unfamiliar technology area. In the following, we describe the technical issues in a vague manner. Rajagopalan Expires on 3/8/01 4 draft-bala-MPLampS-00.txt 7. Electricity Encoding <Template note: This and the next section 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 draft further> The Discrete Voltage Encoding (DVE) scheme has been specified in [4] to digitize electrical voltages. In essence, an Electricity Source (ES) such as a generator, is connected to a DV encoder that quantizes the voltage and produces a bit stream. This bit stream can be packed into IP packets and sent to destinations (referred to as LERs - Low-voltage Electrical Receptors) on-demand. At the destination, a DV decoder produces the right voltage based on the received bit stream. It is to be determined whether 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 electrical network, 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. As per GMPLS [5] principles, 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 message with new objects) for the electric flow. This path message Rajagopalan Expires on 3/8/01 5 draft-bala-MPLampS-00.txt traverses across the network to the ES. The Resv message issued in return sets up the label mappings in LSRs. Finally, the 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 The description of various control plane interconnection scenarios will be covered in an upcoming framework draft. 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, power-constraints in route computation, Shared Risk Loading Groups (SRLGs) etc. Future drafts will describe the details. 8.4 Voltage Protected Networks (VPNs) VPNs allow a customer with multiple sites to get guaranteed electric 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, VPN is a hot topic today and the readers are forewarned that we have every intention of writing several drafts on this. Specifically, E-BGP for VPNs is an area weÆre presently putting some interns to work on. 9. Security Considerations <Template Note: The following statement MUST be present in all foo- over-MPLS drafts> This draft MUST be printed and secured in a locked cabinet to prevent it from being disposed off with the trash. 10. Summary <Template Note: Acknowledge the lack of details in the current draft and conclude with the dire warning that future drafts will provide more details> This draft described the motivation and high level concepts behind Mostly Pointless Lamp Switching (MPLampS), an architecture for electricity distribution over IP. MPLampS utilizes DVE, the discrete voltage encoding, and an MPLS control plane in the distribution network. Since the aim of this draft is only to be a high-visibility Rajagopalan Expires on 3/8/01 6 draft-bala-MPLampS-00.txt place-holder, we did not get into specific details of MPLampS. Numerous future drafts, however, will provide these details. 11. References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. "SONET Synchronous Transport Signal over IP," draft-boyle-sts-ip- 00.txt, Work in Progress. 3. "SONET/SDH Circuit Emulation Service Over MPLS (CEM)," draft- malis-sonet-ces-mpls-00.txt, Work in Progress. 4. ITU G.423E Discrete Voltage Encoding (final spec.), 1999. 5. "Generalized MPLS - Signaling Functional Description," draft- ashwood-generalized-mpls-signaling-00.txt. 12. Disclaimer The opinions expressed in this draft are solely the authorÆs. CompanyÆs opinions, on the other hand, 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: braja@tellium.com Rajagopalan Expires on 3/8/01 7