Network Working Group B. Rajagopalan Request for Comments: 3251 Tellium, Inc. Category: Informational 1 April 2002 IP 送電 このメモの位置付け このメモはインターネットコミュニティのための情報を提供する。これはい かなる種類のインターネット標準を規定するものではない。このメモの配布 に制限はない。 著作権表示 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 「ほとんど無意味な電灯スイッチ」(Mostly Pointless Lamp Switching 略し て MPLampS)は、(MPLSの制御面を用いて)IP越しに電気を供給するためのアー キテクチャである。うちの営業部門の連中に言わせると、MPLampS は、劇的 に安価に、配電と利用を容易にし、かつ電気供給の制御管理を向上させる可 能性があるのだそうだ。この文書は、 SONET/SDH over IP/MPLS とかその類 の業績(著者の方、ごめんね)に刺激されたものである。過去のその手の業績 を読んだ人は、頭をかきむしりながら「次は何だよ、全く…」とぶつぶつ不 平を漏らしてきたと思われるが、この文書はその質問に答えるものである。 また、この文書が書かれたのはみんなへのサービスのためでもある。「IP下 位層」の領域は、伝統的なIPネットワークの範囲外である技術に対しても、 複雑な IETF ドキュメントを記述できる公平な機会を形作ってきた。ひょっ としたら、この機会を活用し高い認知度を達成するにはどのようにすればよ いのだろうか、と不思議に思っていた人も多いかも知れない。このゴールに 向けて、「ほげほげ over MPLS」(つまり何らかの技術をMPLSで制御する) と いうトピックは、実装不能な文書を数限りなく生産するためには非常に適し ていると我々は判断した。この文書は、いろんな「ほげほげ over MPLS」文 書の生産を開始させ、そのような作業のテンプレートとして使えるようにす るための鍵となる成分を明らかにしたものである。 1. この文書で使用されている約束事 この文書中で使用される次のキーワード、"MUST"(しなければならない)、 "MUST NOT"(してはならない)、 "DO"(する)、 "DON'T"(しない)、 "REQUIRED"(必須)、 "SHALL"(すべし)、 "SHALL NOT"(すべからず)、 "SHOULD"(した方が良い)、 "SHOULD NOT"(しない方が良い)、 "RECOMMENDED"(推奨)、 "MAY"(しても良い)、 "MAY BE"(たぶん)、 "OPTIONAL"(省略可)は、特に意味は無い。 Rajagopalan Informational [Page 1] RFC 3251 Electricity over IP 1 April 2002 2. この文書を読むために必要な前提要件 この文書を読んでいると、読者はあちこちで、「これ何の意味があるの?」と か「そんなことできるの?」とか「この著者のアタマは大丈夫なんだろうか?」 といった疑問を呈したくなる衝動に駆られるかもしれない。この文書の読者 は、これらの疑問を抑制し先を読み続ける能力を持っていなくてはならない。 それ以外には、この文書を読むために特定の技術についての予備知識を持っ ている必要はない。場合によっては(今読んでる文書も含まれるのだが)、読 者は特定の技術の予備知識を持っていないことが必須とされる(REQUIRED)。 3. はじめに 最近我々の注目を引きつけたことは、なんと電気の供給ネットワークは IP ネットワークではない! ということである。この衝撃のニュースによるショッ クから立ち直った後に、我々は以下の考えが思い浮かんだ。 1. 電気の供給は、何らかの時代遅れの技術を元にしているに違いない(この 文書では以下「過去の供給システム」(Legacy Distribution System 略し て LDS)と呼ぶ)。 2. LDS はインターネット技術を元にしていない、ということは、二つの異なっ たネットワーク(電気とIP)を運用、管理しなければならない、ということ になる。この結果、非効率で、コストがかかり、官僚的な腐敗を生み出し てしまう(そしてカリフォルニアの大停電を引き起こすかもしれない。我々 はこれを、シミュレーションしながら検証を行っている最中である。学生 の修士論文の一部なんだけど)。 3. 上記の意味するところは、電気とインターネットトラフィックの両方を配 送するために、ただ一つのネットワーク技術(すなわちIP) を使うべきで ある、ということだ。 4. この分野における業績を他の誰よりも早くあげるために、インターネット ドラフトを書かなくてはならない。 5. そのようなドラフトはさらに他のドラフトを作成するために使用されるか もしれない。すると我々(と CCAMP や MPLS など他に関連するワーキング グループ)はさらにもう一年仕事が保証される。 6. こうやって書かれたドラフトは、我々の会社のウェブページの「技術白書」 セクションに掲示され、我々が革命的な先駆者であることを宣言すること になるのだ。 そういうわけでこの文書が誕生した。 4. 用語 MPLampS: 「ほとんど無意味な電灯スイッチ」(Mostly Pointless Lamp Switching) - この文書で提案するアーキテクチャ。 電灯(Lamp): MPLampS アーキテクチャにおける終端システム(IETF における 終端システムの概念とは噛み合わないが、もちろん我々はそんなことは気に しない(DON'T))。 LER: 低電圧電気受容器(Low-voltage Electricity Receptor) - 「電灯」の 凝った言い回し。 Rajagopalan Informational [Page 2] RFC 3251 Electricity over IP 1 April 2002 ES: 電源(Electricity source) - 発電機。 LSR: 負荷スイッチルータ(Load-Switching Router) - 電気供給コアネットワー クにおいて使用される MPLampS 機器。 LDS: 「過去の供給システム」(Legacy Distribution System) - MPLampS が 置き換えようとしている、劣等な電気供給技術。 RSVP: 「かなり滅茶苦茶なものなのに、ルータメーカが押し付けてくるんだ」 (Rather Screwed-up, but router Vendors Push it) - IP 信号プロトコルの 一つ。 RSVP-TE: 料金表拡張付き RSVP(RSVP with Tariff Extensions) - RSVP を MPLampS に適用したもの。規制のない新たな公共設備において使われる予定。 CRLDP: 「頼む、お願いだから、RSVP を使わないでくれ」(for CRying out Loud, Don't do rsvP) - 別の IP 信号プロトコル OSPF: 「あちこちですぐ動かなくなってしまう構成」(Often Seizes-up in multiPle area conFigurations) - 階層型 IP ルーティングプロトコル ISIS: 「OSPF ではなく、もうちょっと何とか長生きしそうなもの」- 別のルー ティングプロトコル OSPF-TE, ISIS-TE: 料金表拡張つきの OSPF と ISIS。 COPS: 警官。Common Open Policy Service プロトコルを滑り込ませる可能性 について、いたるところを捜し回る連中。 VPN: 電圧保護ネットワーク(Voltage Protected Network) - 複数のサイトを 持つ顧客に対し、他の顧客からの干渉による電圧変動をほとんど起こさずに 電気の供給を受けることができるもの。 IP下位層(SUB-IP): 「何でもIPに置き換えちゃおう」(SUBstitute IP everywhere) - 従来のIPネットワークの範囲外であった技術領域(例えば MPLampS)についても IETF が口出ししていこうとする活動。 ITU: 国際公共料金協会(International Tariffed Utilities association) - 公共設備の取引グループの一つで、その活動は IETF からよく無視される。 5. 背景 我々は、電気供給技術領域の背景について徹底的に調査した。そこで我々が 発見したことの驚きと言ったら、そう、例えば、風呂に入っている最中に、 風呂の中に剥き出しの交流 230 ボルトの電線を突っ込まれたような衝撃であっ た。簡単に言うと、電気は広大に広がるLDS 上を、ただの一つのルータも (LSR も何も)使わずに発電、供給されているのである! さらに、このネット ワークの装置の制御はほとんど人手であり、トラックで走り回っている連中 Rajagopalan Informational [Page 3] RFC 3251 Electricity over IP 1 April 2002 によって行われているのである。 なぜこんなネットワークがこの 21 世紀の 世の中に存在しうるのか、疑問に思った我々は、直ちに紙と鉛筆を取り出し、 LDS ネットワークと実績あるインターネット技術を統合するためのシナリオ を描き出した。我々の提案の重要なポイントは以下の点である。 1. IP パケットは、電気を離散化・デジタル化した形式で配送する。 2. 各パケットは、電気を行き先(例えば、IPアドレスを持つ装置)に、要求に 応じて(オンデマンドで)配送する。 3. LDSの中核内部や末端の敷地内でパケットをスイッチするために、MPLS 制 御を使用するものとする。このアーキテクチャのことを「ほとんど無意味 な電灯スイッチ」(MPLampS)と呼ぶ。 4. MPLampS のアーキテクチャモデルは、電気を消費する装置(「電灯」と呼 ぶ)は別個の制御面によって操作されるオーバーレイモデルと、電灯と電 気供給ネットワークが同一の制御面を使用するピアモデルの両者に適合す る。 5. 規制が無くなった環境において電気の流れの経路を確立するため、 RSVP-TE (料金表拡張付きRSVP) を使用する。 6. 会計処理と施策をサポートするために、COPS を使用する。 これらのポイントを書き留めたところで、だいぶ気分がすっきりした。そし てこの提案方式の直接的な利点を以下に書き出した。 1. LDS 内のスイッチと変圧器は、LSR によって置き換えられる。この結果、 新たなルータの市場が生まれる。 2. 電気はインターネット越しにルーティングされるため、現在電気が通じて いなくともインターネットキオスクならある、という遠隔地(例えばイン ドの山奥とか)にも電気を供給することができる。 3. 電気技術者は、より高給取りの IP ネットワーク管理者に取って代わられ る。 4. そして IETF は、また別の、関連が無かった技術領域に口出しできるよう になる。 以下では、技術的な問題点を、漠然とした内容で記述する。 6. 電気エンコード方式 離散型電圧エンコーディング(Discrete Voltage Encoding 略してDVE) 方式 は、電源電圧をデジタル化するための ITU 標準として G.110/230V [2] で規 定されている。その概要を述べると、発電機などの電源(ES)は、電圧と電流 をエンコードする DV エンコーダに接続され、そこからビットストリームが 生成される。このビットストリームは IP パケットによって、さまざまな行 き先(低電圧電気受容器 LER と呼ぶ)に要求に応じて供給される。目的地にお いては、受信したビットストリームを元に、DVデコーダが正しい電圧と電流 を生成する。同期を行ったりエンド・エンド間制御を行うために実時間転送 プロトコル(Real-time Transport Protocol 略して RTP)が利用可能であるか どうかについては、今後決定していく。このRTP の領域についてのドラフト を書くチャンスは、我々の同僚達のために残しておくことにする。 Rajagopalan Informational [Page 4] RFC 3251 Electricity over IP 1 April 2002 7. MPLampS アーキテクチャ 7.1 概要 LDS においては、電気の長距離転送は高電圧によって行われている。この電 圧は、電気の流れが各地域の供給ネットワークに入っていくに従って段階的 に減圧され、最終的に LER には標準電圧(例えば110V)で供給される。つまり、 LDS は階層型ネットワークであるということである。これは即ち、転送ネッ トワーク内における電気のルーティングを行うために、 OSPF や ISIS を拡 張できる可能性が開けているということだ。だがしかし、この生産的なイン ターネットドラフトの領域について深く追求したくなる欲望を今は我慢して、 後の楽しみに取っておこう。ここでは、MPLampS を使ったIPベースの電気供 給ネットワークにおいての、供給の制御に関する議論のみに制限することと する。 MPLampS においては、電圧はラベルと同じ意味を持つ。供給ネットワークの 中では、各スイッチ機材や変圧器は「負荷スイッチルータ」(LSR) として表 現される。電気を運んでいる各IPパケットの流れには、その電圧に対応して ラベルが割り与えられる。そうして、電気の供給は、供給ネットワークの中 の電気の流れをラベル(電圧)でスイッチングするという作業に単純化するこ とができるのである。供給ネットワーク内におけるスイッチ機材の設定は RSVP-TE を通して行われ、要求に応じた電気の提供を行う。 ここまでの記述では、まるで雲を掴むようで馬鹿げている内容であることは、 我々も認める。以下の例では、本提案の実現性に関する読者の疑念を晴らそ うとすることはせずに、さらに(無駄な)詳細について追記していこうと思う。 例: 電灯をオンにする 電灯は、判断力のある装置(例えば、MPLampS 制御面をもつ(電灯)スイッチ) により制御されることが前提となっている。電灯をオンにすることによって、 このスイッチから電気供給源に対して RSVP-TE 要求(新規オブジェクトを持 つPATH メッセージ)が発行される。このPATH メッセージは、ES に向かって ネットワークを通り抜けていく。その応答として、 LSR 内でのラベルの対応 付けをセットアップするRESV メッセージが発行される。そして最終的に、確 立されたパスに沿って電気の供給が開始される。この処理は全体で数秒以内 に完了すると思われるので、この点において MPLampS アーキテクチャは、湿っ たマッチ棒でろうそくに点火するよりも明らかに優位性を持っていると言え る。 Rajagopalan Informational [Page 5] RFC 3251 Electricity over IP 1 April 2002 7.2 オーバーレイモデル対ピアモデル 前述したように、二つの制御面モデルを考慮する必要がある。オーバーレイ モデルにおいては、電灯と供給ネットワークは異なる制御面を利用する。ピ アモデルにおいては、同一の制御面が使用される。両者の対比としてさまざ まな論点が存在するが、これらは今後登場する枠組みの文書において議論さ れていくだろう。ここでは、LSR メーカーの方のよりマシな判断に対抗して、 電灯のメーカーはピアモデルの方を好んでいる、という所見を述べるにとど めておく。しかしながら我々は、それぞれのモデルの有用性に関わらず、双 方の陣営に満足してもらいたいと考えている。従って、MPLampS は両方のモ デルをサポートし、またオーバーレイモデルからピアモデルへの移行のシナ リオもサポートすることをここに記しておく。 7.3 コアネットワーク内でのルーティング 上記での階層型供給システムについての記述によれば、OSPF と ISIS に適切 な拡張を行うことによって適用できる可能性を開いている。我々はこれらの コンセプトについて、電圧束、料金表の複数地域拡張、絶縁 LSA といった形 で既に作業を行っているので、読者は安心してもよい。詳細については今後 の文書で記述されていくだろう。 7.4 電圧保護ネットワーク(VPN) VPN は、複数のサイトを持つ顧客に対し、他の顧客からの干渉による電圧変 動をほとんど起こさずに電気の供給を受けることができるようにするもので ある。もし VPN を行う可能性を持っていなければ、MPLampS アーキテクチャ 全体はただのガラクタである、と主張する人は間違いなく存在する。どんな 場合であれ、VPN は今日ではホットな話題であり、我々はこれに関してあら ゆる文書でも記述する意思がある、ということを読者に警告しておく。特に、 VPN への BGP サポートは、今我々が興味を持って注目している分野である。 8. マルチキャスト 電気の必要性は非常に広域であり、かつ特定の時間は局所的であることが観 測されている。ITU 第55研究グループは、この現象について10年間以上も研 究を続けており、仮報告書を発行している。この報告書によれば、ある家で 電灯が点灯されると、たいてい同じくらいの時刻(通常、夕暮れ時)に近所の 家でも電灯が点灯する、と述べられている [3]。この観測結果は、信号メカ ニズムのスケーラビリティと重大な関連を持っている。特に、供給ネットワー クは、何万という要求を同時に扱うことができなくてはならないのである。 もしマルチキャスト配送が利用できれば、信号制御の負荷は低減できるであ ろう。簡単に言うと、電気の要求は電灯から発電機まで遠路はるばる送信さ れるのではなく、他の電灯のために既に設定されたパス中にある最初の LSR によって処理されるのである。 Rajagopalan Informational [Page 6] RFC 3251 Electricity over IP 1 April 2002 これをサポートするためには、アプリケーションにおいてマルチキャストルー ティングプロトコルと RSVP-TE の共有予約スタイルの両方をサポートするこ とが要求とされ、またMPLampS のマルチキャスト転送モードの開発が必要と される。我々は現在、以下のマルチキャストルーティングプロトコルを研究 している。 ・ DVMRP: 離散型電圧マルチキャストルーティングプロトコル(Discrete Voltage Multicast Routing Protocol) - このプロトコルは既存の電圧ルー ティングプロトコルに手を加えたものであるが、どれか一つの電灯がオンに されたときに、全ての電灯に電気が供給されてしまうという危険性を持って いる。これではスイッチの使い方が間違いなくうざったいものになってしま うだろう - すなわち、定期的に全ての電灯が点灯し、必要のない電灯は毎回 手動でスイッチをオフにしなければならないのだ。 その他のプロトコルで我々が最終的に検討しているものは、「電流ベース木 構造」(Current-Based Tree 略して CBT) と、「実用上不適切なマルチキャ スト」(Practically Irrelevant Multicast 略して PIM) である。我々が非 常に関心を持っている課題はマルチキャストスコープである。我々としては 電気の供給を、一つのクリスマスツリーから街中全部のクリスマスツリーに 至るまで、幅広いスコープでサポートしたいと考えている。言うまでもなく、 このトピックについては、その時が来れば詳細な文書が数多く書かれるであ ろう。 9. セキュリティに関する考察 この文書は、書類棚に鍵をかけて保管しなければならない(MUST)。ゴミと一 緒に捨てられてしまうことがないようにするためである。 10. まとめ この文書は「ほとんど無意味な電灯スイッチ」(MPLampS)、すなわちIP上での 電気供給アーキティクチャの背後にある動機付けと高レベルな概念を記述し たものである。MPLampS はその電気供給ネットワークにおいて、DVE(離散型 電圧エンコーディング)と MPLS の制御面を利用している。この文書は高い可 読性を持つという役割を果たすのが狙いであるため、MPLampS の詳細につい て多くは深入りしていない。残念ではあるが、将来的には数多くの文書が、 これらの詳細を提供しようと企てることになるだろう。 11. 参考文献 1. A. Malis 他、 「MPLS(CEM) カプセル化上の SONET/SDH 回路エミュレー ションサービス」、インターネットドラフト、作業中。 2. 国際公共料金協会ドラフト標準、ITU G.110/230V, 「離散型電圧エンコー ディング」、1999年3月。 3. 国際公共料金協会技術報告書、ITU (SG-55) TR-432-2000、「エネルギー 利用に関する経験的モデル」、2000年9月。 Rajagopalan Informational [Page 7] RFC 3251 Electricity over IP 1 April 2002 12. 免責事項 この文書において表明された意見は著者自身の意見である。例のごとく、会 社の意見は占有財産であり機密情報であるので、適宜機密保持契約を結ぶこ とによってのみ入手することができる。 13. 著者の連絡先 Bala Rajagopalan Tellium, Inc. 2 Crescent Place Ocean Port, NJ 07757 Phone: 732-923-4237 EMail: braja@tellium.com Rajagopalan Informational [Page 8] RFC 3251 Electricity over IP 1 April 2002 14. 著作権表示全文 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. Rajagopalan Informational [Page 9]