Slashdot Mirror
April Fools Wrap Up
Thanks for the usual April Fools Day flame- every year people fall for it.
It never ceases to amaze me how angry and venomous, yet utterly clueless
a few people can be despite the blatant obviousness of the joke.
Lastly, jfengel sent us the annual April Fools RFC: RFC3251 describes "Electricity over IP" and RFC3252 on "Binary Lexical Octet Ad-hoc Transport" reformulates IP to work over XML."
...ya wanna turn on anonymous posting again?
Dragging people kicking and screaming into reality since 1996.
Today, every story you posted was fake. There was no subtly. In addition, there was little originality; most of what's posted has been done already in one form or another. One subtle 4-1 joke, such as the advertized story of the day at /. , would have been good. Having a Slashback with a summary of 4-1 jokes around the web including the Google one and the Debian one would have been a nice evening wrapup. But having every single story for a 24hr period as fake is not funny, particularly *if* certain real stories happened today (I didn't see any, so consider yourself lucky).
Next time, take it easy. Make it subtle and find something that you *know* will get a humor-filled response by those that don't read the story, and you'll get much fewer flames and many more smiles.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Slashdot effect hits hard. :-)
Fetch hits harder
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.
How is it that real news, the "Stuff that matters", as it were, seems to completely dry up on April 1? What real, interesting stories were eschewed to bring us all this "fun" April Fools entertainment? Where is the News?
This was the 50s. No one ate pasta at the time. It would be like me telling your average American that rambutans grow in the ground like carrots or potatoes. It is only obvious in retrospect because in the 70s pasta was the nouveau cuisine and has now become a deeply entrenched part of our culture.
How about having a slashdot poll for the best joke, I guess the award should go to Qt-Console, at least it got some people compile and run it ..
The best April Fool's joke I saw today was when visiting http://www.artbell.com For maximum effectiveness, use IE on a Windows box when you view it.