[要約] RFC 3251は、電力をIPネットワーク上で転送するためのプロトコルを提案しています。その目的は、電力供給の効率化と制御の向上を実現することです。

Network Working Group                                     B. Rajagopalan
Request for Comments: 3251                                 Tellium, Inc.
Category: Informational                                     1 April 2002
        

Electricity over IP

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.

Copyright(C)The Internet Society(2002)。全著作権所有。

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.

ほとんどポイントレスランプスイッチング(MPLampS)は、(MPLSコントロールプレーンを使用して)IPを介して電力を伝送するためのアーキテクチャです。マーケティング部門によると、MPLampSは価格を劇的に下げ、配電と使用を容易にし、電力供給の管理性を向上させる可能性を秘めています。このドキュメントは、SONET / SDH over IP / MPLS(作成者に謝罪)などの作業によって動機付けられています。前作の読者は、頭を掻き回して「次は何?」とつぶやいているのが観察されています。このドキュメントはその質問に答えます。

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.

このドキュメントは、公共サービスとしても作成されています。 「サブIP」領域は、複雑なIETF文書を作成するために従来のIPネットワーキング以外のテクノロジーに取り組んでいる人々に平等な機会を与えるために形成されました。この機会を利用して高い視認性を実現するにはどうすればいいのかと考えている人も多いでしょう。この目標に向けて、「foo-over-MPLS」(またはランダムテクノロジーのMPLSコントロール)のトピックは、無数の実装不可能なドキュメントを生成するのに非常に適していると考えています。このドキュメントは、「foo-over-MPLS」ドキュメントを作成するための主要な要素を示し、そのようなすべての作業のテンプレートとして使用できます。

1. Conventions used in this document
1. このドキュメントで使用される規則

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」、「DO N'T」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」このドキュメントの「MAY BE」および「OPTIONAL」は何も意味しません。

2. Pre-requisite for reading this document
2. このドキュメントを読むための前提条件

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
3. はじめに

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:

最近、電力の配電ネットワークはIPネットワークではないことに注意が向けられました。このニュースによってもたらされた衝撃を吸収した後、次のような考えが私たちに起こりました。

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.

1. 配電は、いくつかの古い技術(「レガシー配電システム」またはLDSと呼ばれます)に基づく必要があります。 2.インターネット技術に基づいていないLDSは、2つの異なるネットワーク(電気とIP)を管理および管理する必要があることを意味します。これは、非効率性、コストの上昇、官僚的な反則につながります(カリフォルニアでの停電につながる可能性があります。現在、学生の修士論文の一部としてシミュレーションを使用してこれを検証しています)。 3.上記は、電力とインターネットトラフィックの両方を伝送するために、単一のネットワークテクノロジー(IP)を使用する必要があることを意味します。 4.他の誰かが行う前に、この領域で作業を開始するためにインターネットドラフトを作成する必要があります。 5.そのようなドラフトは、さらなるドラフトを生成するために使用でき、私たち(およびCCAMP、MPLSまたは別の責任あるワーキンググループ)がさらに1年間忙しいことを保証します。 6.ドラフトは、当社のWebページの「ホワイトペーパー」セクションに投稿して、私たちを革命的な先駆者として宣言することもできます。

Hence the present document.

したがって、現在のドキュメント。

4. Terminology
4. 用語

MPLampS: Mostly Pointless Lamp Switching - the architecture introduced in this document.

MPLampS:ほとんど意味のないランプスイッチング-このドキュメントで紹介されているアーキテクチャ。

Lamp: An end-system in the MPLampS architecture (clashes with the IETF notion of end-system but of course, we DON'T care).

ランプ:MPLampSアーキテクチャのエンドシステム(エンドシステムのIETFの概念と衝突しますが、もちろん気にしません)。

LER: Low-voltage Electricity Receptor - fancy name for "Lamp".

LER:低電圧電気受容器-「ランプ」の仮名。

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:ややねじ込まれているが、ルーターベンダーがプッシュする-IPシグナリングプロトコル。

RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS, to be used in the new deregulated utilities environment.

RSVP-TE:関税拡張付きのRSVP-MPLampSのRSVP適応。新しい規制緩和されたユーティリティ環境で使用されます。

CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling protocol.

CRLDP:大声でCRyアウトする場合は、rsvPを行わない-別のIPシグナリングプロトコル。

OSPF: Often Seizes-up in multiPle area conFigurations - a hierarchical IP routing protocol.

OSPF:多くの場合、マルチプルエリア構成で捕捉-階層型IPルーティングプロトコル。

ISIS: It's not oSpf, yet It somehow Survives - another routing protocol.

ISIS:それは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:電圧保護ネットワーク-複数のサイトを持つ顧客が、他の顧客からの干渉によるごくわずかな電圧変動で電力を受け取ることができます。

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:あらゆる場所で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
5. バックグラウンド

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 A / Cの裸のリード線の効力は、浴槽にいながら、浴槽に落ちました。簡単に言うと、1つのルーター(LSRまたはその他)を持たない広大なLDSに沿って電力が生成および分配されます。さらに、このネットワーク内のデバイスの制御は、ほとんどが手動で行われ、トラックで運転している人々によって行われます。 21世紀にこのようなネットワークがどのように存在するのかを少しの間考えた後、鉛筆と紙を取り、LDSネットワークと実証済みのインターネットテクノロジーを統合するためのシナリオをスケッチしました。私たちが思いついた基本的なポイントは次のとおりです。

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.

1. IPパケットは、個別のデジタル化された形式で電気を運びます。 2.各パケットは、オンデマンドで宛先(IPアドレスを持つデバイスなど)に電力を供給します。 3. MPLS制御は、コアLDS内およびエッジ構内でパケットをスイッチングするために使用されます。このためのアーキテクチャは、Mostly-pointless Lamp Switching(MPLampS)と呼ばれています。 4. MPLampSアーキテクチャモデルは、電力消費デバイス(「ランプ」と呼ばれる)が個別のコントロールプレーン上で動作するオーバーレイモデルと、ランプと配電ネットワークが単一の使用するピアモデルの両方に対応します。コントロールプレーン。 5.規制緩和された環境での電気の流れの経路を確立するために、RSVP-TE(料金延長付きのRSVP)が使用されます。 6. COPSは、会計とポリシーをサポートするために使用されます。

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.

1. LDSのスイッチとトランスはLSRに置き換えることができるため、ルーターの新しい市場を開拓できます。 2.電気をインターネット経由でルーティングして、現在電気接続はなく、インターネットキオスクしかない遠隔地(インドの田舎など)に到達できます。 3.電気技術者は、高額なIPネットワーク管理者に置き換えることができます。4。IETFは、関連のない別の技術領域に関与できます。

In the following, we describe the technical issues in a vague manner.

以下では、技術的な問題について漠然と説明します。

6. Electricity Encoding
6. 電気エンコーディング

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)スキームは、電圧をデジタル化するためにITU標準G.110 / 230V [2]で指定されています。本質的に、発電機などの電気源(ES)は、電圧と電流をエンコードし、ビットストリームを生成するDVエンコーダーに接続されます。このビットストリームは、IPパケットでさまざまな宛先(LER-低電圧電気受容体と呼ばれる)にオンデマンドで伝送できます。宛先では、DVデコーダーが受信したビットストリームに基づいて適切な電圧と電流を生成します。リアルタイムトランスポートプロトコル(RTP)を使用して同期とエンドツーエンド制御を実現できるかどうかを判断する必要があります。 RTP分野でのドラフト作成の機会は、友人や同僚に任せています。

7. MPLampS Architecture
7. MPLampSアーキテクチャ
7.1 Overview
7.1 概観

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
7.2 オーバーレイモデルとピアモデル

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つのモデルに対して他のモデルに対して多くの議論を行うことができ、これらは次のフレームワークドキュメントでカバーされます。ここでは、LSRベンダーのより良い判断に対してピアモデルを好むのはランプベンダーであることをここで単に観察します。ただし、どちらのモデルの有用性にも関係なく、両方のキャンプを満足させたいと考えています。したがって、MPLampSは両方のモデルをサポートし、オーバーレイからピアへの移行シナリオもサポートすることに注意してください。

7.3 Routing in the Core Network
7.3 コアネットワークでのルーティング

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)
7.4 電圧保護ネットワーク(VPN)

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
8. マルチキャスト

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.

電力需要には強い空間的および時間的局所性があることが観察されています。 ITU研究グループ55はこの現象を10年以上研究しており、暫定報告書を発行しています。このレポートは、ある家でランプがオンにされるとき、それは通常、ほぼ同時に(通常は夕暮れ時に)ランプが隣接する家でオンにされるケースであると述べています[3]。この観察は、シグナリングメカニズムのスケーラビリティに深刻な影響を与えます。具体的には、配信ネットワークは一度に数万のリクエストを処理できる必要があります。マルチキャスト配信を使用すると、シグナリングの負荷を軽減できます。簡単に言うと、電気の要求はランプからESまでずっと送信されるのではなく、別のランプへのパスにすでにある最初のLSRによって処理されます。

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:

これをサポートするには、RSVP-TE共有予約スタイルと一緒にマルチキャストルーティングプロトコルを適用し、MPLampSマルチキャスト転送モードを開発する必要があります。現在、次のマルチキャストルーティングプロトコルを調査しています。

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.

o DVMRP:離散電圧マルチキャストルーティングプロトコル-このプロトコルは既存の電圧ルーティングプロトコル上で機能しますが、ここでの危険は、いずれかのランプがオンになっているときにすべてのランプに電力が供給されることです。実際、切り替えのセマンティクスは煩わしくなります。すべてのランプが定期的にオンになり、不要なランプは毎回手動でオフにする必要があります。

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.

最終的に検討する他のプロトコルは、Current-Based Tree(CBT)とPractically Unrelevant Multicast(PIM)です。私たちが非常に関心を寄せている問題はマルチキャストスコープです。1つのクリスマスツリー内のランプから都市全体のランプまで、さまざまなスコープで電力を分配するためのサポートが必要です。言うまでもなく、時間の経過とともに、これらのトピックに関する多くの詳細なドキュメントを作成します。

9. Security Considerations
9. セキュリティに関する考慮事項

This document MUST be secured in a locked cabinet to prevent it from being disposed off with the trash.

このドキュメントは、ゴミ箱に捨てられないように、ロックされたキャビネットに固定する必要があります。

10. Summary
10. 概要

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を介した配電のアーキテクチャである、Mostly Pointless Lamp Switching(MPLampS)の背後にある動機と高レベルの概念について説明しました。 MPLampSは、DVE(離散電圧エンコーディング)、および配電ネットワークのMPLSコントロールプレーンを利用します。このドキュメントの目的は、視認性の高いプレースホルダーになることなので、MPLampSの詳細についてはあまり触れませんでした。残念ながら、多くの将来のドキュメントがこれらの詳細を提供しようと試みます。

11. References
11. 参考文献

1. A. Malis, et al., "SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation", Internet Draft, Work in Progress.

1. A.マリ他、「MPLS(CEM)カプセル化によるSONET / SDH回線エミュレーションサービス」、インターネットドラフト、作業中。

2. International Tarriffed Utilities association draft standard, ITU G.110/230V, "Discrete Voltage Encoding", March, 1999.

2. International Tarriffed Utilities Associationドラフト標準、ITU G.110 / 230V、「Discrete Voltage Encoding」、1999年3月。

3. International Tarriffed Utilities association technical report, ITU (SG-55) TR-432-2000, "Empirical Models for Energy Utilization", September, 2000.

3. International Tarriffed Utilities Association Technical Report、ITU(SG-55)TR-432-2000、 "Empirical Models for Energy Utilization"、2000年9月。

12. Disclaimer
12. 免責事項

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
13. 著者のアドレス

Bala Rajagopalan Tellium, Inc. 2 Crescent Place Ocean Port, NJ 07757 Phone: 732-923-4237 EMail: braja@tellium.com

Bala Rajagopalan Tellium、Inc. 2 Crescent Place Ocean Port、NJ 07757電話:732-923-4237メール:braja@tellium.com

14. 完全な著作権表示

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

Copyright(C)The Internet Society(2002)。全著作権所有。

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.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。