doc: Add RFC documents

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]
+