summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3251.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3251.txt')
-rw-r--r--doc/rfc/rfc3251.txt507
1 files changed, 507 insertions, 0 deletions
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]
+