As per Relevance of the word distribution, we have this rfc below:
Network Working Group B.
Request for Comments: 3251 Tellium, Inc
Category: Informational 1 April 2002
Electricity over
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
Mostly Pointless Lamp Switching (MPLampS) is an architecture
carrying electricity over IP (with an MPLS control plane).
to our marketing department, MPLampS has the potential
dramatically lower the price, ease the distribution and usage,
improve the manageability of delivering electricity. This
is motivated by such work as SONET/SDH over IP/MPLS (with
to the authors). Readers of the previous work have been
scratching their heads and muttering, "What next?". This
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
on technologies outside of traditional IP networking to
complicated IETF documents. There are possibly many who
wondering how to exploit this opportunity and attain high visibility
Towards this goal, we see the topics of "foo-over-MPLS" (or
control for random technologies) as highly amenable for producing
countless number of unimplementable documents. This
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
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
While reading this document, at various points the readers may
the urge to ask questions like, "does this make sense?", "is
feasible?," and "is the author sane?". The readers must have
ability to suppress such questions and read on. Other than this,
specific technical background is required to read this document.
certain cases (present document included), it may be REQUIRED
readers have no specific technical background
3.
It was recently brought to our attention that the
network for electricity is not an IP network! After absorbing
shock that was delivered by this news, the following
occurred to us
1. Electricity distribution must be based on some outdated
(called "Legacy Distribution System" or LDS in the rest of
document).
2. An LDS not based on the Internet technology means that
different networks (electricity and IP) must be administered
managed. This leads to inefficiencies, higher cost
bureaucratic foul-ups (which possibly lead to blackouts
California. We are in the process of verifying this
simulations as part of a student's MS thesis).
3. The above means that a single network technology (i.e., IP)
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
we (and CCAMP, MPLS or another responsible working group) will
busy for another year
6. The draft can also be posted in the "white papers" section of
company web page, proclaiming us as revolutionary pioneers
Hence the present document
4.
MPLampS: Mostly Pointless Lamp Switching - the
introduced in this document
Lamp: An end-system in the MPLampS architecture (clashes with
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
electricity distribution network
LDS: Legacy Distribution System - an inferior
distribution technology that MPLampS intends to replace
RSVP: Rather Screwed-up, but router Vendors Push it - an IP
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
protocol
OSPF: Often Seizes-up in multiPle area conFigurations -
hierarchical IP routing protocol
ISIS: It's not oSpf, yet It somehow Survives - another
protocol
OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions
COPS: Policemen. Folks who scour all places for possibilities
slip in the Common Open Policy Service protocol
VPN: Voltage Protected Network - allows a customer with
sites to receive electricity with negligible voltage fluctuation
to interference from other customers
SUB-IP: SUBstitute IP everywhere - an effort in the IETF to
involved in technical areas outside of traditional IP
(such as MPLampS).
ITU: International Tariffed Utilities association - a utilities
group whose work is often ignored by the IETF
5.
We dug into the electricity distribution technology area to get
background. What we found stunned us, say, with the potency of
bare 230V A/C lead dropped into our bathtub while we were still
it. To put it simply, electricity is generated and distributed
a vast LDS which does not have a single router in it (LSR
otherwise)! Furthermore, the control of devices in this network
mostly manual, done by folks driving around in trucks.
Rajagopalan Informational [Page 3]
RFC 3251 Electricity over IP 1 April 2002
wondering momentarily about how such a network can exist in the 21
century, we took a pencil and paper and sketched out a scenario
integrating the LDS network with the proven Internet technology.
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.,
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
to as Mostly-Pointless Lamp Switching (MPLampS).
4. The MPLampS architectural model will accommodate both the
model, where the electricity consuming devices (referred to
"lamps") are operated over a distinct control plane, and the
model, in which the lamps and the distribution network use
single control plane
5. RSVP-TE (RSVP with Tariff Extensions) will be used
establishing paths for electricity flow in a de-
environment
6. COPS will be used to support accounting and policy
After jotting these points down, we felt better. We then noted
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
which presently do not have electricity connections but have
Internet kiosks (e.g., rural India).
3. Electrical technicians can be replaced by highly paid IP
administrators,
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
The Discrete Voltage Encoding (DVE) scheme has been specified in
standard G.110/230V [2] to digitize electrical voltages. In essence
an Electricity Source (ES) such as a generator is connected to a
encoder that encodes the voltage and current, and produces a
stream. This bit stream can be carried in IP packets to
destinations (referred to as LERs - Low-voltage
Receptors) on-demand. At the destination, a DV decoder produces
right voltage and current based on the received bit stream. It is
be determined whether the Real-time Transport Protocol (RTP) can
Rajagopalan Informational [Page 4]
RFC 3251 Electricity over IP 1 April 2002
used for achieving synchronization and end-to-end control. We
draft writing opportunities in the RTP area to our friends
colleagues
7. MPLampS
7.1
In an LDS, the long-haul transmission of electricity is at
voltages. The voltage is stepped down progressively as
flows into local distribution networks and is finally delivered
LERs at a standard voltage (e.g., 110V). Thus, the LDS is
hierarchical network. This immediately opens up the possibility
OSPF and ISIS extensions for routing electricity in a
network, but we'll contain the urge to delve into these
internet draft areas until later. For the present, we limit
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
network, each switching element and transformer is viewed as a load
switching router (LSR). Each IP packet carrying an electricity
is assigned a label corresponding to the voltage.
distribution can then be trivially reduced to the task of
(voltage) switching as electricity flows through the
network. The configuration of switching elements in the
network is done through RSVP-TE to provide electricity on demand
We admit that the above description is vague and sounds crazy.
example below tries to add more (useless) details, without
any doubts the reader might have about the feasibility of
proposal
Example: Turning on a
It is assumed that the lamp is controlled by an intelligent
(e.g, a (light) switch with an MPLampS control plane). Turning
lamp on causes the switch to issue an RSVP-TE request (a PATH
with new objects) for the electricity flow. This PATH
traverses across the network to the ES. The RESV message issued
return sets up the label mappings in LSRs. Finally,
starts flowing along the path established. It is expected that
entire process will be completed within a few seconds, thereby
the MPLampS architecture a distinct advantage over lighting a
with a damp match stick
Rajagopalan Informational [Page 5]
RFC 3251 Electricity over IP 1 April 2002
7.2 Overlay vs Peer
As noted before, there are two control plane models to be considered
Under the overlay model, the lamps and the distribution
utilize distinct control planes. Under the peer model, a
control plane is used. A number of arguments can be made for
model versus the other, and these will be covered in the
framework document. We merely observe here that it is the
vendors who prefer the peer model against the better judgement of
LSR vendors. We, however, want to please both camps regardless
the usefulness of either model. We therefore note here that
supports both models and also migration scenarios from overlay
peer
7.3 Routing in the Core
The above description of the hierarchical distribution
immediately opens up the possibility of applying OSPF and ISIS
suitable extensions. The readers may rest assured that we
already working on such concepts as voltage bundling, multi-
tariff extensions, insulated LSAs, etc. Future documents
describe the details
7.4 Voltage Protected Networks (VPNs
VPNs allow a customer with multiple sites to get
electricity supply with negligible voltage fluctuations due
interference from other customers. Indeed, some may argue that
entire MPLampS architecture may be trashed if not for the
of doing VPNs. Whatever be the case, VPNs are a hot topic today
the readers are forewarned that we have every intention of
several documents on this. Specifically, BGP-support for VPNs is
area we're presently eyeing with interest
8.
It has been observed that there is a strong spatial and
locality in electricity demand. ITU Study Group 55 has studied
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
usually the case that lamps are turned on in neighboring houses
around the same time (usually at dusk) [3]. This observation has
serious implication on the scalability of the signaling mechanism
Specifically, the distribution network must be able to handle tens
thousands of requests all at once. The signaling load can be
if multicast delivery is used. Briefly, a request for electricity
not sent from the lamp all the way to an ES, but is handled by
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
protocols together with RSVP-TE shared reservation styles and
development of MPLampS multicast forwarding mode. We are
studying the following multicast routing protocol
o DVMRP: Discrete Voltage Multicast Routing Protocol - this
works over existing voltage routing protocols but the danger here
that electricity is delivered to all lamps when any one lamp
turned on. Indeed, the switching semantics gets annoying - all
get turned on periodically and those not needed must be switched
each time manually
Other protocols we will eventually consider are Current-Based
(CBT) and Practically Irrelevant Multicast (PIM). An issue we
greatly interested in is multicast scope: we would like support
distributing electricity with varying scope, from lamps within
single Christmas tree to those in entire cities. Needless to say,
will write many detailed documents on these topics as
progresses
9. Security
This document MUST be secured in a locked cabinet to prevent it
being disposed off with the trash
10.
This document described the motivation and high level concepts
Mostly Pointless Lamp Switching (MPLampS), an architecture
electricity distribution over IP. MPLampS utilizes DVE (
voltage encoding), and an MPLS control plane in the
network. Since the aim of this document is to be a high-
place-holder, we did not get into many details of MPLampS.
future documents, unfortunately, will attempt to provide
details
11.
1. A. Malis, et al., "SONET/SDH Circuit Emulation Service Over
(CEM) Encapsulation", Internet Draft, Work in Progress
2. International Tarriffed Utilities association draft standard,
G.110/230V, "Discrete Voltage Encoding", March, 1999.
3. International Tarriffed Utilities association technical report
ITU (SG-55) TR-432-2000, "Empirical Models for
Utilization", September, 2000.
Rajagopalan Informational [Page 7]
RFC 3251 Electricity over IP 1 April 2002
12.
The opinions expressed in this document are solely the author's
Company's opinions, as always, are proprietary and confidential
may be obtained under appropriate NDAs
13. Author's
Bala
Tellium, Inc
2 Crescent
Ocean Port, NJ 07757
Phone: 732-923-4237
EMail: braja@tellium.
Rajagopalan Informational [Page 8]
RFC 3251 Electricity over IP 1 April 2002
14. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rajagopalan Informational [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
