From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3251.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc3251.txt (limited to 'doc/rfc/rfc3251.txt') diff --git a/doc/rfc/rfc3251.txt b/doc/rfc/rfc3251.txt new file mode 100644 index 0000000..bc5725c --- /dev/null +++ b/doc/rfc/rfc3251.txt @@ -0,0 +1,507 @@ + + + + + + +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. + +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 (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", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY BE" + 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 + 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. + +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 + 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. + +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 + environment. + 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 + colleagues. + +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 + 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 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 + peer. + +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 + progresses. + +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 + details. + +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: braja@tellium.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 + English. + + 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 + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rajagopalan Informational [Page 9] + -- cgit v1.2.3