RFC3251 日本語訳

3251 Electricity over IP. B. Rajagopalan. April 1 2002. (Format: TXT=18994 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

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

Rajagopalanがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3251年のTellium Inc.カテゴリ: 情報の2002年4月1日

                          Electricity over IP

IPの上の電気

Status of this Memo

この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)インターネット協会(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.

ほとんどPointless Lamp Switching(MPLampS)は、IP(MPLS制御飛行機がある)の上まで電気を運ぶための構造です。 私たちの営業部によると、MPLampSには、劇的に値段を下げて、分配と用法を緩和して、電気を渡す管理可能性を改良する可能性があります。 このドキュメントはSonet/SDHのような仕事で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.

また、このドキュメントは社会奉仕として書かれています。 複雑なIETFドキュメントを書くために技術に取り組むものへの等しい機会を伝統的なIPネットワークの外に与えるために「サブIP」領域を形成してあります。 ことによるとどのようにこの機会を利用して、高い視度に達するかと思っている多くがあります。 この目標に向かって、私たちは、「foo過剰MPLS」(または、無作為の技術のためのMPLSコントロール)の話題を無数の数の非実行可能ドキュメントを製作するのに非常に従順であるとみなします。 このドキュメントは、「foo過剰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"、「必須NOT」、「してください」、“DON'T"が「必要です」、“SHALL"、「」、“SHOULD"、「」 「あるかもしれない」「5月」、「推薦され」て、およびこのドキュメントがそうしない「任意」のコネが何か意味しないべきであるかをさせましょう。

Rajagopalan                  Informational                      [Page 1]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[1ページ]のRFC3251電気

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.

様々なポイントのこのドキュメントに読者を読み込むのにおいて、質問をする衝動、「これは理解できますか?」、「これは可能ですか?」、および「作者は気が確かですか?」があるかもしれませんが。 読者には、そのような質問を抑圧して、読み続ける能力がなければなりません。 これ以外に、どんな特定の技術的なバックグラウンドも、このドキュメントを読むのに必要ではありません。 ある場合には(現在のドキュメントを含んでいる)、読者にはどんな特定の技術的なバックグラウンドもないのは、REQUIREDであるかもしれません。

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)を管理されて、経営しなければならないことを意味します。 これは非能率、より高い費用、および官僚の混乱状態に通じます。(ことによると、カリフォルニアで停電に通じます。 学生のMS論文の一部としてシミュレーションを使用することでこれについて確かめることの途中に私たちはいます。). 3. 上記は、電気とインターネットトラフィックの両方を運ぶのに、ただ一つのネットワーク技術(すなわち、IP)を使用しなければならないことを意味します。 4. 他の誰かが書く前にこの領域で就業するためにインターネット草稿を書かなければなりません。 5. さらなる草稿を発生させるのにそのような草稿を使用できます、私たち(そして、CCAMP、MPLSまたは別の責任があるワーキンググループ)が確実にもう1年に忙しくなるようにして。 6. また、弊社のウェブページの「白書」セクションに草稿を掲示できます、革命のパイオニアとして私たちを宣言して。

   Hence the present document.

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

4. Terminology

4. 用語

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

MPLampS: ほとんど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).

ランプ: MPLampS構造(もちろん私たちだけがそうしないエンドシステム注意のIETF概念との衝突)のエンドシステム。

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

LER: 低電圧Electricity Receptor--「ランプ」のために名前を気に入ってください。

Rajagopalan                  Informational                      [Page 2]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[2ページ]のRFC3251電気

   ES: Electricity source - a generator.

ES: 電気源--ジェネレータ。

   LSR: Load-Switching Router - an MPLampS device used in the core
   electricity distribution network.

LSR: 負荷を切り換えるRouter--コア電気流通機構に使用されるMPLampS装置。

   LDS: Legacy Distribution System - an inferior electricity
   distribution technology that MPLampS intends to replace.

LDS: 遺産Distribution System--MPLampSが置き換えるつもりである劣った電気分配技術。

   RSVP: Rather Screwed-up, but router Vendors Push it - an IP signaling
   protocol.

RSVP: ラザーはScrewed上昇して、唯一のルータはVendors Pushです。それ--IPシグナリングプロトコル。

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

RSVP-Te: Tariff ExtensionsとRSVP--、RSVP適合、MPLampSに関しては、新しさで使用されるのはユーティリティ環境を規制緩和しました。

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

CRLDP: CRyingに関しては、出ているLoud、ドンはrsvPをしません--別のIPシグナリングプロトコル。

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

OSPF: Seizes multiPle領域でしばしば上がっているconFigurations--階層的なIPルーティング・プロトコル。

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

イシス: それはoSpf、しかし、どうにかItではありません。Survives--別のルーティング・プロトコル。

   OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.

OSPF-Te、イシス-Te: 関税拡大のOSPFとイシス。

   COPS: Policemen.  Folks who scour all places for possibilities to
   slip in the Common Open Policy Service protocol.

巡査: 警察官。 滑る可能性にすべての場所を捜し回らせる人々がCommonオープン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: 電圧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).

サブIP: いたる所のSUBstitute IP--伝統的なIPネットワーク(MPLampSなどの)の外でテクニカルエリアにかかわるためのIETFでの努力。

   ITU: International Tariffed Utilities association - a utilities trade
   group whose work is often ignored by the IETF.

ITU: 国際Tariffed Utilities協会--仕事がしばしば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

私たちは、何らかのバックグラウンドを得るために電気分配技術領域に掘りました。 私たちがまだそれにいた間、私たちがたとえば、むき出しの230V A/Cリードの力で私たちを気絶させるのがわかったものは私たちの浴槽を中に落としました。 簡単に言えば、電気は、(LSRかそうではありません)であるのにそれのただ一つのルータを持っていない広大なLDSに沿って発生して、分配されます! その上、トラックで乗り回す人々によって行われて、このネットワークにおける、装置のコントロールはほとんど手動です。 後

Rajagopalan                  Informational                      [Page 3]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[3ページ]のRFC3251電気

   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:

しばらくそのようなネットワークが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無意味なLamp Switching(MPLampS)と呼ばれます。 4. MPLampSの建築モデルはオーバレイモデルと同輩モデルの両方に対応するでしょう。そこでは、電気消費装置が異なった制御飛行機の上で操作されます(「ランプ」と呼ばれます)。(そこでは、ランプと流通機構が単一管理飛行機を使用します)。 5. RSVP-TE(Tariff Extensionsと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のスイッチと変圧器をLSRsに取り替えて、その結果、ルータの新しい市場を開放できます。 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

Discrete Voltage Encoding(DVE)計画は、電気電圧をデジタル化するためにITUの標準のG.110/230V[2]で指定されました。 本質では、ジェネレータなどのElectricity Source(ES)は電圧と電流をコード化して、流れを少し起こすDVエンコーダに接続されます。 IPパケットで様々な目的地までこのビットストリームを運ぶことができる、(呼ばれる、LERs--低電圧Electricity Receptors) 要求に応じて。 目的地で、DVデコーダは容認されたビットストリームに基づく正しい電圧と電流を発生させます。 レアル-時間Transportプロトコル(RTP)が断固とすることができるか否かに関係なく、それは断固とすることになっています。

Rajagopalan                  Informational                      [Page 4]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[4ページ]のRFC3251電気

   used for achieving synchronization and end-to-end control.  We leave
   draft writing opportunities in the RTP area to our friends and
   colleagues.

同期と終わりからエンドへのコントロールを達成するのにおいて、使用されています。 私たちは私たちの友人と同僚への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)で最終的にLERsに渡します。 したがって、LDSは階層的なネットワークです。 これはすぐに、送電網でルーティング電気のためのOSPFとイシスの拡大の可能性を開けますが、私たちは、より遅れるまでこれらの産出力があるインターネット草稿部門を調べる衝動を含むでしょう。 当分、私たちは単に議論を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.

知的装置(e.g、MPLampS制御飛行機がある(軽い)のスイッチ)によってランプが制御されると思われます。 ランプをつけるのに、スイッチは電気流動を求めるRSVP-TE要求(新しい物があるPATHメッセージ)を出します。 このPATHメッセージは横切ってネットワークをESに横断します。 代わりに発行されたRESVメッセージはLSRsのラベルマッピングをセットアップします。 最終的に、電気は確立された経路に沿って流れ始めます。 全体の過程が数秒以内に完了すると予想されます、その結果、湿っているマッチ棒でキャンドルを点けるより異なった利点をMPLampS構造に与えます。

Rajagopalan                  Informational                      [Page 5]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[5ページ]のRFC3251電気

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とイシスを適用する可能性を開けます。 電圧バンドリング(マルチ領域関税拡大)がLSAsなどを絶縁して、読者は、私たちが既にそのような概念に取り組んでいると安心するかもしれません。 将来のドキュメントは詳細について説明するでしょう。

7.4 Voltage Protected Networks (VPNs)

7.4 電圧はネットワークを保護しました。(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.

VPNsによって、複数のサイトをもっている顧客は他の顧客から干渉による取るにたらない電圧変動に伴う電力供給が保証されるようになります。 本当に、或るものはVPNsをする可能性がなければ、全体のMPLampS構造が破壊されるかもしれないと主張するかもしれません。 何でもに、いてください。ケース、今日、VPNsは最新の話題であり、読者は私たちにはこれのいくつかのドキュメントを書くあらゆる意志があると前もって警告されます。 明確に、VPNsの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 Study Group55は10年間以上の間、この現象を研究していて、仮報告書を発行しました。 このレポートは、ランプが1軒の家でつけられているとき、通常、ランプがほぼ同じくらいの時間(通常夕暮れ)[3]の隣接している家でつけられているのが、事実であると述べます。 この観測はシグナル伝達機構のスケーラビリティに重大な意味を持っています。 明確に、流通機構は何万もの要求を一気に扱うことができなければなりません。 マルチキャスト配送が使用されているなら、シグナリング負荷は減少できます。 簡潔に、電気を求める要求は、ランプからいっぱいにESに送られませんが、別のランプには経路に既にある最初のLSRによって扱われます。

Rajagopalan                  Informational                      [Page 6]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[6ページ]のRFC3251電気

   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: 離散的なVoltage Multicastルート設定プロトコル--このプロトコルは既存の電圧ルーティング・プロトコルの上で働いていますが、どんなランプもつけるとき、すべてのランプに電気を渡すという危険がここにあります。 本当に、切り換え意味論は煩わしくなります--その都度、手動でランプが定期的で回させて、ものが必要としなかったすべてを消さなければなりません。

   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 Tree(CBT)とPractically Irrelevant Multicast(PIM)です。 私たちが大いに興味を持っている問題はマルチキャスト範囲です: 私たちは、異なった範囲で単一のクリスマスツリーの中のランプから全体の都市のそれらまで電気を分配するサポートが欲しいと思います。 言うまでもなく、私たちは時の進むにつれてこれらの話題の多くの詳細なドキュメントを書くつもりです。

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.

このドキュメントはMostly Pointless Lamp Switching(MPLampS)(IPの上の電気分配のための構造)の後ろで動機と高い平らな概念について説明しました。 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。 Malis、他、「Sonet/SDHサーキットエミュレーションサービスオーバーMPLS(CEM)カプセル化」、インターネットDraft、ProgressのWork。

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

2. 国際Tarriffed Utilities協会草稿規格、ITU G.110/230V、「離散的な電圧コード化」、1999年3月。

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

3. 国際Tarriffed Utilities協会技術報告書、ITU(SG-55)TR-432-2000、「エネルギー利用のための経験的モデル」、2000年9月。

Rajagopalan                  Informational                      [Page 7]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[7ページ]のRFC3251電気

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.

本書では述べられた意見は唯一作者のものです。 会社の意見をいつものように独占であって、秘密であり、適切なNDAsの下で得るかもしれません。

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の三日月形場所海洋港、ニュージャージー07757電話: 732-923-4237 メールしてください: braja@tellium.com

Rajagopalan                  Informational                      [Page 8]

RFC 3251                  Electricity over IP               1 April 2002

IP2002年4月1日の間のRajagopalanの情報[8ページ]のRFC3251電気

14. Full Copyright Statement

14. 完全な著作権宣言文

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

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Rajagopalan                  Informational                      [Page 9]

Rajagopalan情報です。[9ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ATAN2関数 2つの引数から逆タンジェント(アークタンジェント)を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る