RFC 3251

Electricity over IP ⚡🔌

Okay bestie, this one is RFC 3251 from the Network Working Group 🦋. It was written by B. Rajagopalan of Tellium, Inc., it's dated 1 April 2002 (iykyk 💀), and its category is Informational. The title block doesn't list anything it obsoletes or updates ✨.

Status of This Memo 💅

Lowkey the vibe here is "this is just info, not a standard" 🫶. It provides information for the Internet community, it does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌈.

Copyright Notice 🎀

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌸

Okay so the main character here is Mostly Pointless Lamp Switching (MPLampS) 💡, an architecture for carrying electricity over IP with an MPLS control plane. Our marketing department says it could dramatically lower the price, make distribution and usage way easier, and level up how manageable electricity delivery is 📈. This doc is inspired by SONET/SDH over IP/MPLS (sorry to those authors 🙈). Readers of that earlier work were seen scratching their heads and going "What next?" 💀. This document answers that question ✨.

This document is also a public service 🧚. The "Sub-IP" area was formed to give equal opportunity to folks working on technologies outside of traditional IP networking to write complicated IETF documents 📝. Lots of people are wondering how to exploit this opportunity and get high visibility 👀. Our take is that topics like "foo-over-MPLS" (or MPLS control for random technologies) are super amenable to producing a countless number of unimplementable documents 😭. This document shows the key ingredients that go into any "foo-over-MPLS" document, so feel free to use it as a template for all that work 💖.

1. Conventions used in this document ✨

Quick note bestie: 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 literally do not mean anything 💀🙈.

2. Pre-requisite for reading this document 🧚

Okay so while you're reading, you might get the urge to ask stuff like "does this make sense?", "is this feasible?", and "is the author sane?" 😭. Readers must have the ability to suppress those questions and keep going 💅. Other than that, no specific technical background is needed to read this 🌸. In certain cases (this 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 that shock, we had these thoughts:

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 Internet technology means 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 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" ✨.
• 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 🙃.

---

Part 1 of 2 wraps here 🎀. Part 2 picks up at section 5 (Background) and goes all the way through 7.2 💖 so stay tuned bestie 🫶✨

7.3 Routing in the Core Network ✨

Okay so, this hierarchical distribution system is literally giving OSPF and ISIS energy 🧚. We could apply both with suitable extensions, and honestly that's so exciting. Just know we're already cooking up ideas like voltage bundling, multi-area tariff extensions, and insulated LSAs 🔥. Future documents will spill all the details, bestie 💅.

7.4 Voltage Protected Networks (VPNs) 💜

VPNs let a customer with multiple sites get guaranteed electricity supply with negligible voltage fluctuations, even when other customers are interfering. Some people might say the entire MPLampS architecture gets trashed if we can't do VPNs 💀. Whatever the case, VPNs are a hot topic right now, so consider yourself forewarned 🙈. We fully intend to write several documents on this. BGP support for VPNs is something we're eyeing with real interest 👀✨.

8. Multicast 🦋

Okay, here's the tea 🍓. There is a strong spatial and temporal locality in electricity demand. ITU Study Group 55 has studied this for over a decade and issued a preliminary report 📚. The report says that when a lamp turns on in one house, lamps in neighboring houses usually turn on at around the same time, usually at dusk [3]. This has a serious impact on the scalability of the signaling mechanism 😭. The distribution network has to handle tens of thousands of requests all at once. The signaling load can be reduced if multicast delivery is used 🫶. Basically, a request for electricity doesn't travel all the way from the lamp to an ES. It gets handled by the first LSR that's already on the path to another lamp ✨.

Supporting this takes multicast routing protocols, RSVP-TE shared reservation styles, and the development of MPLampS multicast forwarding mode 🧚. We are currently studying this multicast routing protocol:

• DVMRP: Discrete Voltage Multicast Routing Protocol. This protocol works over existing voltage routing protocols, but the danger is that electricity gets delivered to all lamps when any one lamp is turned on 😬. The switching semantics get really annoying. All lamps turn on periodically, and the ones not needed have to be switched off manually each time 🙄.

Other protocols we'll eventually consider are Current-Based Tree (CBT) and Practically Irrelevant Multicast (PIM) 💅. We're super interested in multicast scope. We'd love support for distributing electricity with varying scope, from lamps within a single Christmas tree all the way to those in entire cities 🎄🌈. Needless to say, we'll write many detailed documents on these topics as time goes on 🔥.

9. Security Considerations 🔐

⚠️ This document MUST be secured in a locked cabinet to prevent it from being disposed off with the trash. No cap, this is serious 😭.

10. Summary 🎀

This document covered the motivation and high-level concepts behind Mostly Pointless Lamp Switching (MPLampS), an architecture for electricity distribution over IP ✨. MPLampS uses DVE (discrete voltage encoding) and an MPLS control plane in the distribution network 🧚. The whole point of this document is to be a high-visibility placeholder, so we didn't get into many details of MPLampS 🙈. Numerous future documents, unfortunately, will try to provide those 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.

12. Disclaimer 🙃

The opinions in this document are solely the author's. Company 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

14. Full Copyright Statement ⚖️

Legal bestie moment 🫶. This section has to stay word for word, so here it is in full:

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. Thank you, Internet Society 🥰✨.