[要約] RFC 5984は、ESPベースの転送を使用してIPネットワークのスループットを向上させるためのガイドラインです。このRFCの目的は、ESPベースの転送を実装することで、ネットワークの性能を向上させることです。
Independent Submission K-M. Moller
Request for Comments: 5984 1 April 2011
Category: Experimental
ISSN: 2070-1721
Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding
ESPベースの転送を伴うIPネットワークのスループットの増加：ESPBasedForwarding
Abstract
概要
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.
このドキュメントは、ESPベースの転送を使用することにより、IPネットワークの無限帯域幅に到達する実験的な方法を提案しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5984.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5984で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Experiments with Black Fiber . . . . . . . . . . . . . . . 3
2.2. Schrodinger's Cat Experiment . . . . . . . . . . . . . . . 3
3. ESP-Based Forwarding . . . . . . . . . . . . . . . . . . . . . 4
3.1. Principle of Operation . . . . . . . . . . . . . . . . . . 4
3.2. Architectural Components . . . . . . . . . . . . . . . . . 4
3.2.1. DPAUI . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. PPG . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. IID . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.4. CFE . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.5. PPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.6. ND . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. End User Considerations . . . . . . . . . . . . . . . . . . . . 7
5. TCP Slow-Start Considerations . . . . . . . . . . . . . . . . . 7
6. Market Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Mechanisms for efficient packet forwarding has evolved over the past years. The demand for bandwidth is always increasing. Instead of optimizing forwarding performance and link capacity in an incremental fashion, we propose a brand new concept in packet forwarding that will provide unsurpassed end user performance regardless of link capacity, distance, and number of hops.
効率的なパケット転送のメカニズムは、過去数年間にわたって進化してきました。帯域幅の需要は常に増加しています。転送パフォーマンスとリンク容量を漸進的に最適化する代わりに、リンク容量、距離、ホップ数に関係なく、卓越したエンドユーザーパフォーマンスを提供するパケット転送の新しいコンセプトを提案します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
During the past years, there have been a lot of improvements made in the domain of packet forwarding. Both software and hardware optimizations combined with increased link capacities have cut down round-trip times. Despite these improvements, many users find themselves frustrated since their demand for bandwidth has increased faster than the supply.
過去数年間、パケット転送のドメインで多くの改善が行われてきました。ソフトウェアとハードウェアの両方の最適化とリンク容量の増加により、往復時間が短縮されました。これらの改善にもかかわらず、多くのユーザーは、帯域幅の需要が供給よりも速く増加しているため、イライラしています。
The current incremental approach to lower latency and increase capacity will soon reach the end of the road. The reason for this has been known for some time and is stated in RFC 1925 [RFC1925] clause 2:
レイテンシを低くし、容量を増加させるための現在の増分アプローチは、すぐに道路の終わりに到達します。この理由はしばらく知られており、RFC 1925 [RFC1925]条項2に記載されています。
"(2) No matter how hard you push and no matter what the priority, you can't increase the speed of light."
「（2）どんなに激しく押しても、優先順位に関係なく、光の速度を上げることはできません。」
Our research has finally been able to circumvent this boundary by the development of zero-latency network paths.
私たちの研究は、ゼロ遅延ネットワークパスの開発により、ついにこの境界を回避することができました。
Inspired by RFC 1072 [RFC1072], where a network containing a long, fat pipe is called LFN (pronounced "elephan(t)"), we will refer to an internet path with zero-latency as "infinitely fat", and a network containing this path as "IFN" (pronounced "infan(t)").
長い脂肪パイプを含むネットワークがLFN（「Elephan（T）」と発音）と呼ばれるRFC 1072 [RFC1072]に触発され、ゼロ遅延のインターネットパスを「無限に脂肪」と呼び、ネットワークを参照します。このパスを「IFN」（「インファン（T）」と発音）として含める。
Before the invention of this new forwarding principle, several experimental methods were tried. We have chosen to share our failed attempts in order help others avoid the same mistakes that we encountered. The following two methods have been dismissed:
この新しい転送原則の発明の前に、いくつかの実験方法が試されました。失敗した試みを共有することを選択しました。次の2つの方法が却下されました。
o Black Fiber o Schrodinger's cat experiment
o 黒繊維Oシュロディンガーの猫実験
Attempting to push the speed-of-light limitation by means of using black fiber looked promising at first. Shortly after initiating the experiment, lack of light was detected in the black fiber. This was interpreted as proof of successful data transmission faster than the speed of light. After popping the champagne, the following problems were detected:
黒い繊維を使用して軽速制限をプッシュしようとすると、最初は有望に見えました。実験を開始した直後、黒い繊維で光の不足が検出されました。これは、光の速度よりも速いデータ送信の証明として解釈されました。シャンパンをポップした後、次の問題が検出されました。
1. No data reached the receiver. 2. The fiber was not connected at the transmitting side.
1. 受信機に届くデータはありませんでした。2.繊維は送信側で接続されていませんでした。
This clearly spoiled the mood of the party.
これは明らかに党の気分を台無しにしました。
The Schrodinger's netcat experiment was based on an attempt to implement the method described by E. Schrodinger [Schrodinger35]. The original procedure includes locking up cats in boxes with radioactive materials and poisonous gas. Data communication capabilities were added to the experiment, by using netcat. The research team was dumbfounded by the notion that the cat experiment seemed to work and not work at the same time. This was also confirmed by a friend of Wigner's [Wigner].
SchrodingerのNetCat実験は、E。Schrodinger[Schrodinger35]によって記述された方法を実装する試みに基づいていました。元の手順には、放射性材料と有毒ガスを備えた箱に猫をロックすることが含まれます。NetCatを使用して、データ通信機能が実験に追加されました。研究チームは、猫の実験が機能し、同時に機能しないように見えるという概念にumb然としていました。これは、ウィグナーの[ウィグナー]の友人によっても確認されました。
A detailed analysis of the experiment indicated that the probability vectors collapsed whenever traffic was sent to the box. The conclusion was that this approach would only work without traffic, thus eliminating all practical applications.
実験の詳細な分析では、トラフィックがボックスに送信されるたびに確率ベクトルが崩壊したことが示されました。結論は、このアプローチはトラフィックなしでのみ機能し、すべての実用的なアプリケーションを排除するということでした。
Experiments with ESP-based (Extra Sensory Perception) forwarding has proved to successfully remove the limitation in RFC 1925 [RFC1925].
ESPベースの（余分な感覚知覚）転送を使用した実験は、RFC 1925 [RFC1925]の制限を正常に除去することが証明されています。
The foundation for the ESP-based forwarding scheme is to reduce latency by means of precognitive datagram detection and generation. By applying this technology, latency will not only reach zero, but might even become negative.
ESPベースの転送スキームの基礎は、予後のデータグラムの検出と生成によってレイテンシを減らすことです。この技術を適用することにより、レイテンシはゼロに達するだけでなく、負になる可能性さえあります。
Experiments performed by Benjamin Libet [Libet85] regarding the readiness potential (Bereitschaftspotential) concludes that the end user latency from impulse to the conscious mind is approximately 350 - 400 ms. In order to reach the highest possible data transport without confusing the end user, it is important to take this latency into consideration.
ベンジャミンリベット[Libet85]が準備の可能性について実施した実験（BereitschaftSpotential）は、衝動から意識へのエンドユーザーの遅延が約350〜400ミリ秒であると結論付けています。エンドユーザーを混乱させることなく、可能な限り最高のデータ輸送に到達するには、この遅延を考慮に入れることが重要です。
Traffic between the end user and the server reaches the ESP-enabled router. Inside the ESP-based router, the data stream is first analyzed by the DPAUI (Deep Packet And User Inspection). The DPAUI sends a signal to the PPG (Deep Packet And User Inspection), which generates uplink IP datagrams supported by the IID (Infinite Improbability Drive). The generated IP datagram is sent to the CFE (Clairvoyant Forwarding Engine) that forwards the datagram. Finally, the "real" uplink, the end user datagram is received and forwarded to the ND (Null Device).
エンドユーザーとサーバー間のトラフィックは、ESP対応ルーターに到達します。ESPベースのルーター内では、データストリームが最初にDPAUIによって分析されます（ディープパケットとユーザー検査）。DPAUIは、PPG（ディープパケットとユーザー検査）に信号を送信します。これにより、IID（無限の不可drive）でサポートされているアップリンクIPデータグラムが生成されます。生成されたIPデータグラムは、データグラムを転送するCFE（Clairvoyant転送エンジン）に送信されます。最後に、「リアル」アップリンク、エンドユーザーデータグラムが受信され、ND（nullデバイス）に転送されます。
The current ESP-based forwarding architecture includes the following components:
現在のESPベースの転送アーキテクチャには、次のコンポーネントが含まれています。
o DPAUI o PPG o IID o CFE o PPS o ND
o dpaui o ppg o iid o cfe o pps o nd
The DPAUI (Deep Packet And User Inspection) monitors the data streams for all individual users. The DPAUI is implemented by means of implementing a learning agent that analyzes each individual user. The output from the DPAUI is a signal that indicates that an IP datagram will be sent by the end user within a couple of seconds.
DPAUI（ディープパケットとユーザー検査）は、すべての個々のユーザーのデータストリームを監視しています。DPAUIは、個々のユーザーを分析する学習エージェントを実装することにより実装されます。DPAUIからの出力は、数秒以内にIPデータグラムがエンドユーザーによって送信されることを示す信号です。
The purpose of the PPG (Precognitive Packet Generator) is to generate the IP datagram that the end user will trigger to be sent. In order to craft such a datagram, the PPG will perform a lookup based on the offset and length parameters generated by the IID. The PPG will generate the future packet by means of the function:
PPG（予言的なパケットジェネレーター）の目的は、エンドユーザーが送信するトリガーがトリガーするIPデータグラムを生成することです。このようなデータグラムを作成するために、PPGはIIDによって生成されたオフセットと長さのパラメーターに基づいてルックアップを実行します。PPGは、関数によって将来のパケットを生成します。
struct mbuf * CopyDatagramFromPi( insane long offset, unsigned int len);
struct mbuf * copydatagramfrompi（非常識な長いオフセット、符号なしのint len）;
The CopyDatagramFromPi() function will return a pointer to an mbuf containing the IP datagram. The offset value and len matches a corresponding offset and length in the decimal set for pi that contains the bit pattern for the future datagram. This method of operation will reduce the complex matter of precognitive packet generation to a simple lookup.
CopyDatagramFrompi（）関数は、IPデータグラムを含むMBUFへのポインターを返します。オフセット値とLENは、将来のデータグラムのビットパターンを含むPIの小数点セットの対応するオフセットと長さと一致します。この動作方法により、予測的なパケット生成の複雑な問題が簡単な検索に減ります。
Concerns have been raised that the full decimal set of pi requires an infinite amount of memory. This might have a negative effect on the manufacturing cost of the router. These concerns were successfully managed by using a perfectly circular buffer. This reduced the previous stated memory requirements at least by half.
PIの小数点以下のセットには、無限の量のメモリが必要であるという懸念が提起されています。これは、ルーターの製造コストに悪影響を与える可能性があります。これらの懸念は、完全に円形のバッファーを使用して成功裏に管理されました。これにより、以前の記載されていたメモリ要件が少なくとも半分に減少しました。
The purpose of the IID (Infinite Improbability Drive) is to assist the PPG and PPS with improbable probabilities (and the other way around). The IID was originally invented by Douglas Adams [Adams79]. The original implementation was based on hooking up the logic circuits of a Bambleweeny 57 sub-meson Brain to an atomic vector plotter suspended in a strong Brownian motion producer (i.e., a nice hot cup of tea).
IIDの目的（無限の不可能性ドライブ）は、PPGとPPSをありそうもない確率（およびその逆）で支援することです。IIDはもともとダグラス・アダムス[Adams79]によって発明されました。元の実装は、強力なブラウンモーションプロデューサー（つまり、素敵なホットカップのお茶）に吊り下げられた原子ベクトルプロッターにバンブルウイングサブメソンの脳の論理回路を接続することに基づいていました。
The research team struggled with the implementation of the strong Brownian motion producer. As a matter of fact, the majority of the research budget was wasted before it was fully conceived that a warm cup of tea and router equipment rarely mix.
研究チームは、強力なブラウンモーションプロデューサーの実施に苦労しました。実際のところ、研究予算の大部分は、温かいお茶とルーターの機器がめったに混ざらないと完全に考慮される前に無駄になりました。
Aided by the gastronomical department (working on Bistromathic Drive), the research team managed to attach a brownie on top of a radio controlled hovercraft full of eels. This not only caused a lot of noise and disarray, but also a sufficient amount of Brownian motion. The research team is still working on an entirely software-based solution. Hopefully, the eel-filled hovercraft will soon be replaced with a different type of python script.
美食部門（Bistromathic Driveに取り組んでいる）の助けを借りて、研究チームは、ウナギでいっぱいのラジオ管理ホバークラフトの上にブラウニーを添付することができました。これは、多くの騒音と混乱を引き起こしただけでなく、十分な量のブラウン運動を引き起こしました。研究チームは、完全にソフトウェアベースのソリューションに取り組んでいます。うまくいけば、ウナギに満ちたホバークラフトがまもなく異なるタイプのPythonスクリプトに置き換えられることを願っています。
After the IP datagram has been produced by the PPG, the CFE (Clairvoyant Forwarding Engine) will attempt to find the right route. Since the route might not exist yet, direct access to a routing table might result in routing errors.
IPデータグラムがPPGによって生成された後、CFE（Clairvoyant転送エンジン）は適切なルートを見つけようとします。ルートはまだ存在しない可能性があるため、ルーティングテーブルへの直接アクセスにより、ルーティングエラーが発生する可能性があります。
The implementation of the CFE is very straightforward: any off-the-shelf routing stack with a routing table and a routing daemon can be used. A standard Ouija board is simply put on top of the routing table. For each datagram, the CFE initiates an Ouija board session that will establish a connection with the routing deamons. The CFE will seek guidance for the future of the IP datagram and then send it along for a low cost, to meet a tall, dark server rack.
CFEの実装は非常に簡単です。ルーティングテーブルとルーティングデーモンを備えた既製のルーティングスタックを使用できます。標準のOuijaボードは、ルーティングテーブルの上に置かれています。各データグラムについて、CFEはルーティングディーモンとの接続を確立するOUIJAボードセッションを開始します。CFEは、IPデータグラムの将来のガイダンスを求めて、それを低コストで送信して、背の高い暗いサーバーラックを満たします。
The PPS (Pre-Preemptive Scheduler) is synchronized by means of an NTP connection to the IID based NTP server. This ensures that the ESP process will execute ten seconds ahead of local time (layman's term: "into the future"). This value should ensure operation even with very long Round Trip Times and should also include the readiness potential of the end user.
PPS（プリプリエンプティブスケジューラ）は、IIDベースのNTPサーバーへのNTP接続によって同期されます。これにより、ESPプロセスが現地時間より10秒前に実行されることが保証されます（レイマンの用語：「未来」）。この値は、非常に長い往復時間があっても操作を確保する必要があり、エンドユーザーの準備可能性も含める必要があります。
The pre-preemptive scheduler not only provides a separate user space, but a separate dimension for the code to execute in. The dimension alignment is based on string theory and has been implemented in the language C, simply by including the library string.h and then using strcpy to copy the PPS function pointer into an eleven-dimensional array.
プリプリエンプティブスケジューラは、個別のユーザースペースを提供するだけでなく、コードを実行するための個別のディメンションを提供します。ディメンションアライメントは文字列理論に基づいており、ライブラリ文字列を含めるだけで言語cに実装されています。次に、strcpyを使用して、PPS関数ポインターを11次元配列にコピーします。
After a little time, less than the 'end user to server' Round-trip time (RTT), the real end user datagram will reach the ingress side of the ESP-based router, since the datagram has already been sent, routed and returned. The datagram is directly routed to the ND (Null Device) and the ingress packet counter is decremented.
データグラムが既に送信、ルーティング、返されたため、「エンドユーザーからサーバーへのエンドユーザー」の往復時間（RTT）よりも少ないと、実際のエンドユーザーデータグラムはESPベースのルーターの侵入側に到達します。。データグラムはND（nullデバイス）に直接ルーティングされ、イングレスパケットカウンターが減少します。
Experimentation showed that the ND is a perfect source of entropy and is able to store all digits of pi. The research team had great hopes of reducing the memory footprint for the PPG even further, but ran into problems with read access times.
実験により、NDはエントロピーの完全なソースであり、PIのすべての数字を保存できることが示されました。研究チームは、PPGのメモリフットプリントをさらに削減することを非常に期待していましたが、読み取りアクセス時間の問題に遭遇しました。
The ND is readily available in most operating systems.
NDは、ほとんどのオペレーティングシステムで容易に利用できます。
End user considerations and differentiated traffic classes:
エンドユーザーの考慮事項と差別化されたトラフィッククラス：
1. In order to facilitate a pleasant end user gaming experience, packets destined for the spinal cord (i.e., force feedback information, etc.) must be delayed by 350 ms in order to synchronize with the traffic that is routed by the end user to the cerebrum and cortex.
1. 心地よいエンドユーザーゲームエクスペリエンスを促進するために、脊髄専用のパケット（つまり、フォースフィードバック情報など）を350ミリ秒遅らせる必要があります。および皮質。
2. RFC 1216 [RFC1216], Section 3.3 states that "bad news travels fast". This means that additional delay must be introduced when the end user is browsing on news sites. Negative latency might make the end user suspect that the news is even worse than indicated by the news sites.
2. RFC 1216 [RFC1216]、セクション3.3は、「悪いニュースが速く移動する」と述べています。これは、エンドユーザーがニュースサイトで閲覧しているときに追加の遅延を導入する必要があることを意味します。負の遅延により、エンドユーザーは、ニュースサイトで示されているよりもニュースがさらに悪いと疑うかもしれません。
3. Machine-to-Machine (M2M) communication might experience reduced performance due to difficulties for the DPAUI to work correctly. When the concept starts working for M2M communication, this can be used as an indication that a technological singularity might be near.
3. Machine-to-Machine（M2M）通信は、DPAUIが正しく機能するのが難しいため、パフォーマンスの低下を経験する可能性があります。コンセプトがM2M通信で動作し始めると、これは技術的特異性が近づいている可能性があることを示すことができます。
The lack of RTT of IFNs might cause some problems with TCP slow-start. More precisely, it will most likely not be slow at all. This might be handled by implementing a congestion avoidance mechanism, but will need further study.
IFNSのRTTの欠如は、TCPスロースタートにいくつかの問題を引き起こす可能性があります。より正確には、それはおそらくまったく遅くないでしょう。これは、混雑回避メカニズムを実装することで処理される場合がありますが、さらなる研究が必要になります。
Unfortunately, we foresee that this product will never be ready for the market. This is especially true for the Pre-preemptive Scheduler, which by nature, will always be slightly ahead of its time.
残念ながら、この製品が市場に備えないことは決してないと予測しています。これは、特にプリエンプティブスケジューラに当てはまります。これは、本質的には常にその時代をわずかに上回っています。
o Introducing an end user RTT delay of zero might cause crashes in badly implemented TCP/IP stacks. This is because division by zero might occur when calculating bandwidth-delay product.
o エンドユーザーのRTTゼロの遅延を導入すると、ひどく実装されたTCP/IPスタックでクラッシュが発生する可能性があります。これは、帯域幅遅延製品を計算するときにゼロによる分割が発生する可能性があるためです。
o ESP forwarding of traffic generated by psychics might lead to problems with recursiveness.
o サイキックによって生成されたトラフィックのESP転送は、再帰の問題につながる可能性があります。
o Lawful Intercept of the Deep User and Intention Inspection might violate personal integrity.
o 深いユーザーの合法的な傍受と意図検査は、個人の完全性に違反する可能性があります。
o Terrorist organizations might exploit the "bad news travels fast" loophole in RFC 1216 [RFC1216].
o テロ組織は、RFC 1216 [RFC1216]で「悪いニュースが速く移動する」抜け穴を悪用する可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Adams79] Adams, D., "Hitchhiker's guide to the galaxy.", 1979.
[Adams79] Adams、D。、「Hitchhiker's Guide to the Galaxy」、1979。
[Libet85] Libet, B., "Unconscious cerebral initiative and the role of conscious will in voluntary action.", 1985.
[Libet85] Libet、B。、「無意識の脳のイニシアチブと自発的行動における意識意志の役割」、1985。
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
[RFC1072] Jacobson、V。およびR. Braden、「長距離パスのTCP拡張」、RFC 1072、1988年10月。
[RFC1216] Richard, P. and Kynikos, "Gigabit network economics and paradigm shifts", RFC 1216, April 1991.
[RFC1216]リチャード、P。およびキニコス、「ギガビットネットワークエコノミクスとパラダイムシフト」、RFC 1216、1991年4月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925] Callon、R。、「Twelve Networking Truths」、RFC 1925、1996年4月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、 "Socks Protocolバージョン5"、RFC 1928、1996年3月。
[Schrodinger35] Schrodinger, E., "The Present Situation In Quantum Mechanics", 1935, <http://www.tu-harburg.de/rzt/rzt/it/QM/cat.html>.
[Schrodinger35] Schrodinger、E。、「量子力学の現在の状況」、1935、<http://www.tu-harburg.de/rzt/rzt/it/qm/cat.html>。
[Wigner] Wikipedia, "Wikipedia: Wigner's friend.", <http://en.wikipedia.org/wiki/Wigner's_friend>.
[Wigner] Wikipedia、「Wikipedia：Wigner's Friend」、<http://en.wikipedia.org/wiki/wigner's_friend>。
Author's Address
著者の連絡先
Karl-Magnus Moller Tankesaft
Karl-Magnus Moller Tankesaft
EMail: kalle@tankesaft.se