分享
 
 
 

RFC3251 - Electricity over IP

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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.

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".

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

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

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.

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.

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.

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

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 RFCEditor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有