はじめに
- この文書は RFC3251 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
- 「IPで電力を配送」するアイデアを紹介(?)しています(「電力線でIPを通す」のではないです、念のため)
Electricity over IP(電力 over IP)
- Network Working Group
- Request for Comments: 3251
- Category: Informational
- B. Rajagopalan
- Tellium, Inc.
- 1 April 2002
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.
MPLampS (Mostly Pointless Lamp Switching) は、電力を IP で運ぶためのアーキテクチャ (MPLS 制御プレーンを使用する) である。
我々のマーケティング部門によると、MPLampS は電気を運ぶ際の価格を劇的に下げ、流通や利用を容易にし、管理性を向上させる可能性があるとしている。
この文書は SONET/SDH over IP/MPLS のような仕事から動機づけられている (著者には申し訳ないが)。
以前の仕事の読者は、頭をかきむしり、「次は何だ?」とつぶやいているのが観察されている。
本書はその疑問に答えるものである。
この文書はまた、公共サービスとして書かれたものである。
「Sub-IP」エリアは、従来の IP ネットワーク以外の技術に携わる人々にも、複雑な IETF 文書を書く平等な機会を与えるために形成されたものである。
この機会を利用し、高い知名度を得るにはどうしたらよいか、悩んでいる人も多いことだろう。
この目標に向けて、私達は「foo-over-MPLS」 (またはランダムな技術のための MPLS 制御) のトピックが、無数の実装不可能なドキュメントを作成するのに非常に適していると考えている。
この文書は、「foo-over-MPLS」文書を作成するための重要な要素を示しており、そのような作業のためのテンプレートとして使用することができる。
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.
本書におけるキーワード「MUST」「MUST NOT」「DO」「DON'T」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「MAY BE」「OPTIONAL」は何ら意味を持たない。
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.
このドキュメントを読んでいると、「これは意味があるのか」「これは実現可能なのか」「著者は正気なのか」といった疑問を投げかけたい衝動に駆られることがあるはずだ。
そのような疑問を抑えて読み進める力が必要である。
それ以外には、このドキュメントを読むのに特別な技術的背景は必要ない。
場合によっては(この文書も含めて)、読者が特定の技術的背景を持たないことが要求(REQUIRED)されるかもしれない。
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:
- Electricity distribution must be based on some outdated technology (called "Legacy Distribution System" or LDS in the rest of the document).
- 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).
- The above means that a single network technology (i.e., IP) must be used to carry both electricity and Internet traffic.
- An internet draft must be written to start work in this area, before someone else does.
- 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.
- 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.
先日、「電力の配電網は IP ネットワークではない」というニュースが飛び込んできた。
この衝撃を受け、我々は次のように考えた。
- 配電網は時代遅れの技術 (以降、「Legacy Distribution System」または「LDS」と呼ぶ) をベースにしているに違いない。
- LDS がインターネット技術に基づかないということは、2 つの異なるネットワーク (電気とIP) を管理・運用する必要がある。 これは、非効率、高コスト、官僚的な失敗をもたらす (カリフォルニアの停電につながる可能性がある。 現在、学生の修士論文でシミュレーションによる検証を行っているところである)
- 上記は、電力とインターネットの両方のトラフィックを伝送するために、単一のネットワーク技術 (すなわち、IP) を使用しなければならないことを意味する。
- インターネット・ドラフトは、他の誰かがやる前に、この分野での作業を開始するために書かれなければならない。
- このようなドラフトは、さらなるドラフトを生成するために使用することができ、我々 (およびCCAMP、MPLSまたは他の担当ワーキンググループ) は、もう1年間忙しくなることを保証する。
- そのドラフトは、私たちの会社のWebページの「ホワイトペーパー」セクションに掲載し、我々が革命的なパイオニアであることを宣言することもできる。
そこで、今回の文書である。
4. Terminology(用語解説)
MPLampS: Mostly Pointless Lamp Switching - the architecture introduced in this document.
MPLampS: Mostly Pointless Lamp Switching (ほとんど無意味なランプ切り替え) ―― このドキュメントで紹介されているアーキテクチャ。
Lamp: An end-system in the MPLampS architecture (clashes with the IETF notion of end-system but of course, we DON'T care).
Lamp: MPLampS アーキテクチャのエンドシステム (IETF のエンドシステムの概念と衝突するが、もちろん、気にしない)。
LER: Low-voltage Electricity Receptor - fancy name for "Lamp".
LER: Low-voltage Electricity Receptor (低電圧電力受容体) ―― 「Lamp」の仮の名前。
ES: Electricity source - a generator.
ES: 電力源 ―― 発電機。
LSR: Load-Switching Router - an MPLampS device used in the core electricity distribution network.
LSR: Load-Switching Router (負荷切替ルーター) ―― MPLampS デバイスで、コア配電網で使用される。
LDS: Legacy Distribution System - an inferior electricity distribution technology that MPLampS intends to replace.
LDS: Legacy Distribution System ―― MPLampS が置き換えようとする劣悪な配電技術。
RSVP: Rather Screwed-up, but router Vendors Push it - an IP signaling protocol.
RSVP: Rather Screwed-up, but router Vendors Push it (むしろめちゃくちゃだが、ルーターベンダーはそれを推す) ―― IP シグナリングプロトコル。
RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS, to be used in the new deregulated utilities environment.
RSVP-TE: RSVP with Tariff Extensions (料率拡張を伴うRSVP) ―― MPLampS のために RSVP を適応させ、規制緩和された新しい電力会社環境で使用される。
CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling protocol.
CRLDP: CRying out Loud, Don't do rsvP (大声で泣いて、RSVP しないこと) ―― IPシグナリング・プロトコルの一つ。
OSPF: Often Seizes-up in multiPle area conFigurations - a hierarchical IP routing protocol.
OSPF: Often Seizes-up in multiPle area conFigurations (マルチプルエリア構成でしばしば破綻する) ―― 階層型IPルーティングプロトコル。
ISIS: It's not oSpf, yet It somehow Survives - another routing protocol.
ISIS: It's not oSpf, yet It somehow Survives (OSPF ではないのに、なんとか生き残る) ―― もう一つのルーティングプロトコル。
OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.
OSPF-TE、ISIS-TE: OSPF と ISIS に料率拡張を施したもの。
COPS: Policemen. Folks who scour all places for possibilities to slip in the Common Open Policy Service protocol.
COPS: 警察官。 Common Open Policy Serviceプロトコルをすり込む可能性を求めてあらゆる場所を探し回る人たち。
VPN: Voltage Protected Network - allows a customer with multiple sites to receive electricity with negligible voltage fluctuation due to interference from other customers.
VPN: Voltage Protected Network (電圧保護ネットワーク) ―― 複数のサイトを持つ顧客が、他の顧客からの干渉による電圧変動を無視して電気を受け取ることができるようにすること。
SUB-IP: SUBstitute IP everywhere - an effort in the IETF to get involved in technical areas outside of traditional IP networking (such as MPLampS).
SUB-IP: SUBstitute IP everywhere (どこでもIPで代用) ―― 従来のIPネットワーク以外の技術分野 (MPLampSなど) に関与しようとする IETF の取り組み。
ITU: International Tariffed Utilities association - a utilities trade group whose work is often ignored by the IETF.
ITU: International Tariffed Utilities association (国際料率事業協会) ―― 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:
配電技術の分野に踏み込み、その背景を調査した。
その結果、例えば交流 230V のリード線を浴槽に落とした時のような衝撃を受けた。
簡単に言うと、電気は広大な LDS で発電・配電されており、そこにはルーター(LSR など)は1つもないということだ!
しかも、このネットワーク上の機器の制御は、ほとんどがトラックで走り回る人たちの手作業で行われているのである。
このようなネットワークが 21 世紀に存在するのか、ちょっと疑問に思い、紙と鉛筆を持って、LDS ネットワークと実績あるインターネット技術を統合するシナリオを書き出してみた。
その基本的なポイントは、次のとおりである。
- IP packets carry electricity in discrete, digitized form.
- Each packet would deliver electricity to its destination (e.g., a device with an IP address) on-demand.
- 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).
- 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.
- RSVP-TE (RSVP with Tariff Extensions) will be used for establishing paths for electricity flow in a de-regulated environment.
- COPS will be used to support accounting and policy.
- IP パケットは電気を離散的にデジタル化した形で伝送する。
- 各パケットは、オンデマンドで電気を目的地 (例えば、IP アドレスを持つ機器) に届けることができる。
- コア LDS 内やエッジ構内のパケット切り替えには、MPLS 制御が使われる。 このアーキテクチャは、MPLampS (Mostly-Pointless Lamp Switching) と呼ばれる。
- MPLampS のアーキテクチャモデルは、電力を消費する機器 (「ランプ(lamp)」と呼ぶ) を個別の制御プレーンで操作するオーバーレイモデルと、ランプと配電網が単一の制御プレーンを使用するピアモデルの両方に対応する。
- RSVP-TE (RSVP with Tariff Extensions) は、規制緩和された環境において、電力フローのパスを確立するために使用される予定である。
- アカウンティングとポリシーのサポートに COPS が使用される。
After jotting these points down, we felt better.
We then noted the following immediate advantages of the proposed scheme:
これらの点を書き留めて、我々は気が楽になった。
そして、この方式がもたらす直接的なメリットとして、次のようなことを挙げた:
- Switches and transformers in the LDS can be replaced by LSRs, thereby opening up a new market for routers.
- 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).
- Electrical technicians can be replaced by highly paid IP network administrators, and
- The IETF can get involved in another unrelated technology area.
In the following, we describe the technical issues in a vague manner.
- LDS 内のスイッチやトランスを LSR に置き換えることで、ルーターの新たな市場を開拓することができる。
- 現在、電気が通っておらず、インターネットキオスクしかないような遠隔地 (例:インドの農村部) に、インターネット経由で電気を送ることができる。
- 電気技術者は、高給取りの IP ネットワーク管理者に取って代わられる可能性がある。
- IETF が無関係な別の技術分野に関与できる。
以下、技術的な問題点を漠然と記述する。
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.
DVE (Discrete Voltage Encoding; 離散的電圧エンコード)方式は、ITU 規格 G.110/230V [2] に規定されている電力電圧のデジタル化方式である。
要するに、発電機などの電力源 (ES) を DV エンコーダーに接続し、電圧と電流をエンコードして、ビットストリームを生成する。
このビットストリームは、IP パケットでさまざまな宛先 (LER:Low-Voltage Electricity Receptorと呼ばれる) にオンデマンドで運ぶことができる。
送信先では、DV デコーダが受信したビットストリームをもとに、適切な電圧と電流を生成する。
同期とエンドツーエンドの制御を実現するために、RTP (Real-time Transport Protocol) を使用できるかどうかは、これから決定される。
RTP の分野でのドラフト執筆の機会は、友人や同僚に任せる。
7. MPLampS Architecture(MPLampS アーキテクチャ)
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.
LDS では、長距離の送電は高電圧で行われる。
電圧は、電気が地域の配電網に流れるにつれて徐々に下げられ、最終的に標準電圧 (例えば 110V) で LER に供給される。
このように、LDS は階層的なネットワークである。
このことは、送電ネットワークで電気をルーティングするための OSPF と ISIS の拡張の可能性があるが、これらの生産的なインターネットドラフト領域を掘り下げる衝動は後ほどまで抑えておく。
現時点では、単に MPLampS を使用して IP ベースの配電網で電気の流れを制御することに議論を限定する。
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.
MPLampS では、電圧はラベルと等価である。
配電網では、各開閉器や変圧器を負荷切替ルータ (LSR) と見なす。
電力フローを運ぶ各 IP パケットには、電圧に対応するラベルが割り当てられる。
配電は、配電網を流れる電気のラベル(電圧)を切り替える作業に自明化することができる。
配電網のスイッチング素子の設定は、オンデマンドで電気を供給するために、RSVP-TE を通じて行われる。
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.
上記の説明は曖昧であり、クレイジーに聞こえることを認める。
以下の例は、この提案の実現可能性について読者が抱く疑念を取り除くことなく、さらに (無駄な) 詳細を付け加えようとするものである。
例:ランプを点灯させる
ランプはインテリジェントデバイス (例えば、MPLampS 制御プレーンを持つ (照明) スイッチ) によって制御されていると仮定する。
ランプを点灯させると、スイッチは電気の流れのために RSVP-TE リクエスト (新しいオブジェクトを含む PATH メッセージ) を発行する。
この PATH メッセージは、ネットワークを介して ES に伝わります。
返って発行された RESV メッセージは、LSR のラベルマッピングをセットアップする。
最後に、確立された経路に沿って電気が流れ始める。
このプロセス全体が数秒以内に完了することが期待されており、それによって MPLampS アーキテクチャは、湿ったマッチ棒でロウソクに火をつけるよりも明らかに有利になる。
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.
前述したように、2つの制御プレーンモデルを検討する必要がある。
オーバーレイモデルでは、ランプと配信ネットワークは個別の制御プレーンを使用する。
ピアモデルでは、単一の制御プレーンが使用される。
1つのモデルともう1つのモデルについて、多くの議論を行うことができるが、これらは次のフレームワーク文書でカバーされる内容である。
ここでは、LSR ベンダーのより良い判断に反して、ランプベンダーがピアモデルを好んでいることを観察するだけにする。
しかし、私たちは、どちらのモデルが有用であるかにかかわらず、両陣営を喜ばせたいと考えている。
したがって、MPLampS は両方のモデルをサポートし、オーバーレイからピアへの移行シナリオもサポートすることをここに記す。
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.
以上のように、階層型配電システムについて説明すると、OSPF と ISIS を適切に拡張して適用する可能性がある。
読者は、電圧バンドル、マルチエリア料金拡張、絶縁 LSA などの概念にすでに取り組んでいることに安心するだろう。
詳細は今後のドキュメントで説明する予定である。
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.
VPN を使えば、複数の拠点を持つ顧客が、他の顧客からの干渉による電圧変動を無視できるほど保証された電力供給を受けることができる。
実際、VPN の可能性がなければ、MPLampS のアーキテクチャ全体がゴミになるかもしれないと主張する人もいるかもしれない。
いずれにせよ、VPN は現在ホットな話題であり、読者の皆様には、この件についていくつかのドキュメントを書くつもりであることを予めお断りするものである。
特に、VPN の BGP サポートは、現在、我々が関心をもって注目している分野である。
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:
- 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.
電力需要には強い空間的・時間的な局所性があることが確認されている。
ITU 研究会 55 は、この現象を 10 年以上にわたって研究し、速報を発表した。
この報告書によると、ある家でランプが点灯すると、通常、近隣の家でもほぼ同じ時間(通常、夕暮れ時)にランプが点灯するとのことである [3]。
この観測は、信号伝達機構のスケーラビリティに重大な影響を与える。
具体的には、配信ネットワークは、一度に数万件の要求を処理できなければならない。
マルチキャスト配信を利用すれば、シグナリング負荷を軽減することができる。
簡単に説明すると、電力の要求はランプから ES まで送られるのではなく、すでに別のランプまでの経路にある最初の LSR で処理される。
これをサポートするには、RSVP-TE 共有予約スタイルと一緒にマルチキャストルーティングプロトコルを適用し、MPLampS マルチキャスト転送モードを開発することが必要である。
現在、以下のマルチキャストルーティングプロトコルを研究している。
- DVMRP: Discrete Voltage Multicast Routing Protocol - このプロトコルは既存の電圧ルーティングプロトコル上で動作するが、ここでの危険は、あるランプがオンになったときにすべてのランプに電気が供給されることである。 実際、スイッチングセマンティクスは厄介なもので、すべてのランプは定期的にオンになり、不要なランプはその都度手動でオフにしなければならない。
私たちが最終的に検討する他のプロトコルは、CBT (Current-Based Tree) とPIM (Practically Irrelevant Multicast; 実際上無関係なマルチキャスト) である。
1本のクリスマスツリーの中のランプから街全体のランプまで、さまざまなスコープで電気を配信することをサポートしたい。
もちろん、これらの課題については、今後、詳細なドキュメントを作成する予定である。
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.
本文書は、IP 電力流通のためのアーキテクチャである MPLampS (Mostly Pointless Lamp Switching) の動機と上位概念について述べたものである。
MPLampS は DVE (discrete voltage encoding) と MPLS 制御プレーンを配電網に利用する。
本文書の目的は、視認性の高いプレースホルダーであるため、MPLampS の詳細にはあまり触れなかった。
将来の数多くの文書が、残念なことに、これらの詳細を提供することを試みるだろう。
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.
本書で述べられた意見は、あくまでも著者個人のものである。
会社の意見は、いつものように所有権のある機密事項であり、適切な NDA の下で入手することができる。
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 RFC Editor function is currently provided by the
Internet Society.