Loading article…
エンドツーエンドの原則は、コンピュータ ネットワークの設計フレームワークです。この原則に従って設計されたネットワークでは、信頼性やセキュリティなどの特定のアプリケーション固有の機能を保証するには、それらの機能がネットワークの通信エンド ノードに存在する必要があります。ネットワークを確立するために存在するゲートウェイやルーターなどの中間ノードは、効率を向上させるためにこれらの機能を実装できますが、エンドツーエンドの正確性を保証することはできません。
後にエンドツーエンド原則と呼ばれるようになるものの本質は、1960年代のパケット交換ネットワークに関するドナルド・デイヴィスの研究に含まれていました。ルイ・プーザンは、 1970年代にCYCLADESネットワークでエンドツーエンド戦略の使用を開拓しました。[1]この原則は、1981年にサルツァー、リード、クラークによって初めて明確に表現されました。[2] [a]エンドツーエンド原則の意味は、最初の表現以来、継続的に再解釈されてきました。また、エンドツーエンド原則の注目すべき定式化は、1981年のサルツァー、リード、クラークの画期的な論文以前にも見られます。[3]
この原則の基本的な前提は、エンド アプリケーションで必要な特定の機能を通信サブシステムに追加することによるメリットは急速に減少するということです。エンド ホストは、正確性を保つためにこれらの機能を実装する必要があります。[b]特定の機能を実装すると、その機能が使用されるかどうかに関係なく、リソースのペナルティが発生します。また、ネットワークで特定の機能を実装すると、その機能が必要かどうかに関係なく、すべてのクライアントにこれらのペナルティが追加されます。
コンセプト
エンドツーエンド原則の背後にある基本的な概念は、何らかの通信手段を介して相互に通信する2 つのプロセスの場合、その手段から得られる信頼性がプロセスの信頼性要件と完全に一致するとは期待できないということです。特に、重要なサイズのネットワークで分離された通信プロセスの非常に高い信頼性要件を満たすか上回ることは、エンドツーエンドの肯定的な確認応答と再送信 (PARまたはARQと呼ばれる) によって必要なレベルの信頼性を得るよりもコストがかかります。[c]言い換えると、中間ノードよりもネットワークのエンドホストのメカニズムによって、一定のマージンを超える信頼性を得る方がはるかに簡単です。[d]特に、後者がエンドホストの制御下になく、エンドホストに責任を負わない場合です。[e]無限の再試行を伴うエンドツーエンドの肯定的な確認応答は、データを一方のエンドからもう一方のエンドに正常に送信できる確率が 0 を超える任意のネットワークから、任意の高い信頼性を得ることができます。[f]
エンドツーエンドの原則は、エンドツーエンドのエラー制御と訂正、およびセキュリティ以外の機能には適用されません。たとえば、遅延やスループットなどの通信パラメータについては、エンドツーエンドの議論を単純に行うことはできません。2001 年の論文で、Blumenthal と Clark は次のように述べています。「当初から、エンドツーエンドの議論はエンドポイントで正しく実装できる要件を中心に展開されていました。ネットワーク内での実装が要件を満たす唯一の方法である場合、エンドツーエンドの議論はそもそも適切ではありません。」[7] : 80
エンドツーエンド原則はネット中立性の原則と密接に関連しており、時にはその直接的な前身と見なされることもあります。[8]
歴史
1960 年代、ポール バランとドナルド デイビスは、 ARPANET以前のネットワークの詳細化において、信頼性についてコメントしました。バランの 1964 年の論文では、「信頼性と生のエラー率は二次的なものです。ネットワークは、いずれにしても大きな損害を覚悟して構築する必要があります。強力なエラー除去方法があります。」と述べています。 [9] : 5 さらに、デイビスはエンドツーエンドの原則の本質を捉え、1967 年の論文で、ネットワークのユーザーがエラー制御を自分で用意すると述べています。「ネットワークのすべてのユーザーが何らかのエラー制御を自分で用意し、これにより、失われたパケットを簡単に表示できると考えられます。このため、パケットの損失は、十分にまれであれば許容できます。」[10] : 2.3
ARPANETは、バランとデイヴィスが以前に提唱したいくつかの概念を実装した、最初の大規模な汎用パケット交換ネットワークでした。[11] [12]
デイヴィスは、単一のパケットスイッチを備えたローカルエリアネットワークを構築し、広域データグラムネットワークのシミュレーションに取り組んだ。[13] [14] [15]これらのアイデアを基に、ARPANET での実装を改良しようとしたルイ・プザンのCYCLADESネットワークは、 [15] 広域ネットワークでデータグラムを実装し、ネットワーク自体の集中サービスではなく、ホストがデータの信頼性の高い配信を担当するようにした最初のネットワークであった。 [1]このネットワークで実装された概念は、TCP/IPアーキテクチャに採用されている。[16]
アプリケーション
アルパネット
ARPANET は、エンドツーエンドの原則のいくつかの重要な側面を実証しました。
- パケット交換は、いくつかの論理機能を通信エンドポイントにプッシュします。
- 分散ネットワークの基本的な前提がパケット交換である場合、並べ替えや重複検出などの機能は、必然的にそのようなネットワークの論理エンドポイントに実装する必要があります。その結果、ARPANET には 2 つの異なるレベルの機能が備わっています。
- 下位レベルは、隣接するネットワークノード間のデータパケットの転送に関係します（インターフェースメッセージプロセッサまたはIMPと呼ばれます）。
- データ伝送のエンドツーエンドのさまざまな側面に関係する上位レベル。[g]
- エンドツーエンドの原則に関する論文の著者の一人であるデイブ・クラークは、次のように結論づけています。「パケットの発見はエンドツーエンドの議論の結果ではありません。パケットの成功こそがエンドツーエンドの議論に意味を持たせるのです。」[19] : スライド 31
- エンドツーエンドの確認応答と再送信メカニズムがなければ、任意の信頼性の高いデータ転送は不可能である
- ARPANET は、ネットワークの任意の 2 つのエンドポイント間で信頼性の高いデータ転送を提供するように設計されました。これは、コンピュータと近くの周辺機器間の単純な I/O チャネルによく似ています。[h]パケット転送の潜在的な障害を修復するために、通常の ARPANET メッセージは、肯定応答と再送信スキームを使用して 1 つのノードから次のノードに渡されました。ハンドオーバーが成功した後、メッセージは破棄され、[i]パケット損失の場合の送信元から宛先への再送信は考慮されませんでした。しかし、多大な努力にもかかわらず、初期の ARPANET 仕様で想定されていた完全な信頼性は提供できないことが判明しました。これは、ARPANET が当初の 4 ノード トポロジをはるかに超えて成長したときに、ますます明らかになった現実です。[j]このように、ARPANET は、真のエンドツーエンドの信頼性を追求するネットワーク ベースのホップバイホップ信頼性メカニズムの固有の限界を強く示しました。[k]
- 信頼性、レイテンシ、スループットのトレードオフ
- 完全な信頼性を追求すると、データ伝送の他の関連パラメータ、特に遅延とスループットが損なわれる可能性があります。これは、信頼性よりも予測可能なスループットと低遅延を重視するアプリケーションにとって特に重要です。典型的な例は、インタラクティブなリアルタイム音声アプリケーションです。このユースケースは、ARPANET で、さまざまな信頼性対策を省いた生のメッセージ サービスを提供することで対応され、エンド ホストに高速で低遅延のデータ伝送サービスを提供しました。[l]
プロトコル
インターネット プロトコル(IP) は、配信の保証がないコネクションレス型データグラム サービスです。インターネットでは、ほぼすべての通信に IP が使用されています。エンドツーエンドの確認応答と再送信は、IP の上位にあるコネクション指向の伝送制御プロトコル(TCP) が担当します。IP と TCP の機能分割は、エンドツーエンドの原則をトランスポート プロトコル設計に適切に適用する例です。
ファイル転送
エンドツーエンドの原則の例として、分散ネットワークの 2 つのエンドポイント間での、任意に信頼できるファイル転送が挙げられます。このネットワークのサイズは、一定ではなく、一定ではありません。[3] 2 つのエンドポイントが完全に信頼できる転送を実現する唯一の方法は、データ ストリーム全体のチェックサムを 送信して確認することです。このような設定では、パフォーマンスを最適化する目的でのみ、より低レベルのチェックサムおよび確認応答 ( ACK /NACK) プロトコルが正当化されます。これらのプロトコルは、大多数のクライアントには役立ちますが、この特定のアプリケーションの信頼性要件を満たすには不十分です。したがって、徹底的なチェックサムはエンドポイントで行うのが最善であり、ネットワークはすべてのクライアントに対して比較的低いレベルの複雑さと妥当なパフォーマンスを維持します。[3]
制限事項
エンドツーエンド原則の最も重要な制限は、中間ノードではなくアプリケーション エンドポイントに機能を配置するという基本的な前提を実装するのが簡単ではないことです。
エンドツーエンドの原則の限界の例としては、モバイルデバイス、例えばモバイルIPv6が挙げられます。[27]サービス固有の複雑さをエンドポイントに押し付けると、デバイスがネットワークチャネルに信頼性の低いアクセスを持つ場合に、モバイルデバイスで問題が発生する可能性があります。[28]
IPv4ではアドレス枯渇対策としてNAT（ネットワークアドレス変換）が利用されているが、このNATの追加によりネットワークの透過性が低下するというさらなる問題も見られる。[29] IPv6の導入により、ユーザーは再び一意の識別子を持つようになり、真のエンドツーエンドの接続が可能になった。一意の識別子は物理アドレスに基づく場合もあれば、ホストによってランダムに生成される場合もある。[30]
エンドツーエンドの原則は、調整関連の機能を、最終的にはアプリケーション層までさらに高いレベルに押し上げることを提唱しています。その前提は、アプリケーション レベルの情報によって、アプリケーションのエンドポイント間で柔軟な調整が可能になり、調整がまさに必要なものとなるため、パフォーマンスが向上するというものです。このことから、各アプリケーションを、エンドポイント間の望ましい調整をサポートする独自のアプリケーション固有のプロトコルを介してモデル化するというアイデアが生まれ、その一方で、単純な下位層の通信サービスのみを想定しています。このアイデアは、広くアプリケーション セマンティクス (意味) として知られています。
マルチエージェントシステムは、アプリケーションセマンティクスに基づくアプローチを提供し、基盤となる通信サービスからのメッセージの順序付けや配信の保証を必要とせずに分散アプリケーションを便利に実装できるようにします。これらのアプローチの基本的な考え方は、情報プロトコル[31]を介してアプリケーションエンドポイント間の調整をモデル化し、そのプロトコルに基づいてエンドポイント (エージェント) を実装することです。情報プロトコルは、損失のある順序付けされていない通信サービス上で実行できます。情報プロトコルと関連するプログラミングモデルに基づくミドルウェアは、基盤となるネットワークからのメッセージ受信を抽象化し、エンドポイントプログラマがメッセージを送信するためのビジネスロジックに集中できるようにします。
参照
注記
- ^ 1981年の論文[2]は1984年に更新版としてACMのTOCSに掲載された。[3] [4]
- ^ Saltzer、Reed、Clark の論文からの全文引用は、次の通りです。[3]「通信を含むシステムでは、通常、通信サブシステムの周囲にモジュール境界を描き、通信サブシステムとシステムの他の部分との間の堅固なインターフェイスを定義します。そうすると、機能のリストがあり、各機能は、通信サブシステム、そのクライアント、ジョイント ベンチャー、またはおそらく冗長的に、それぞれ独自のバージョンを実行するなど、いくつかの方法で実装できることが明らかになります。この選択について推論する際に、アプリケーションの要件は、次のクラスの議論の基礎となります。問題の機能は、通信システムのエンドポイントに立つアプリケーションの知識と支援によってのみ、完全に正しく実装できます。したがって、問題の機能を通信システム自体の機能として提供することは不可能であり、さらに、通信システムのすべてのクライアントのパフォーマンスが低下します。(通信システムによって提供される機能の不完全なバージョンが、パフォーマンスの向上に役立つ場合があります。) 低レベルの機能実装に反対するこの論理的根拠を、エンドツーエンドの議論と呼びます。」 （278ページ）。
- ^ 実際、ローカルエリアネットワークでも通信障害の可能性はゼロではありません。「ネットワークの制御戦略に関係なく、より高いレベルでの信頼性に注意を払う必要があります」。[5]
- ^ 経済学的に言えば、ネットワークの信頼性を高めるための限界費用は、エンド ホストで同じ信頼性を高めるための限界費用を上回ります。ネットワーク内の信頼性向上の経済的に効率的なレベルは、具体的な状況によって異なりますが、決してゼロにはほど遠いものです。 [3]「明らかに、ネットワークの信頼性を向上させるための下位レベルでの努力は、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。(p. 281)」
- ^ 強制力のある契約上の救済手段があるにもかかわらず、中間リソースが非決定論的な方法で共有されるネットワークでは、完全な信頼性を保証することは不可能です。せいぜい、統計的なパフォーマンスの平均を引用することくらいでしょう。
- ^ より正確には: [6]「THM 1: 再試行回数が無制限で正しく機能する PAR プロトコルでは、メッセージの配信に失敗したり、メッセージを紛失したり、重複したりすることはありません。COR 1A: 再試行回数が有限で正しく機能する PAR プロトコルでは、メッセージを紛失したり、重複したりすることはなく、メッセージの配信に失敗する確率は送信者によって任意に小さくすることができます。」(p. 3)。
- ^ ARPANET RFQ [17] (47 ページ以降)に従って、ARPANET は概念的に特定の機能を分離しました。BBN が 1977 年の論文で指摘しているように、 [18]「ARPA ネットワークの実装では、メッセージをパケットに分割する手法を使用して、多数のホップを経由する長い送信で発生する遅延を最小限に抑えます。ARPA ネットワークの実装では、特定のホスト ペア間で複数のメッセージが同時に転送されることも許可されます。ただし、複数のメッセージとメッセージ内のパケットは、宛先 IMP に順序どおりに到着しない可能性があり、IMP または回線が破損している場合は重複が発生する可能性があります。ARPA ネットワークの送信元から宛先への送信手順のタスクは、宛先でパケットとメッセージを並べ替え、重複を除去し、メッセージのすべてのパケットが到着したら、メッセージを宛先ホストに渡して、エンドツーエンドの確認応答を返すことです。(284 ページ)。」
- ^この要件は ARPANET RFQに明記されており、「ネットワークのユーザーである ARPA 契約業者の観点から見ると、通信サブネットは自己完結型の施設であり、そのソフトウェアとハードウェアはネットワーク契約業者によって保守されます。相互接続ソフトウェアの設計では、サブネットへのデータの出し入れに I/O 規則を使用するだけでよく、サブネット操作の詳細には関与する必要はありません。特に、信頼性の高いネットワーク パフォーマンスを保証するために必要なエラー チェック、障害検出、メッセージ スイッチング、障害回復、回線スイッチング、キャリア障害、キャリア品質評価は、ネットワーク契約業者の唯一の責任です。」[17] : 25
- ^ ウォルデンは1972年の論文で、「各IMPは、パケットが正しく受信されたという次のIMPから肯定的な確認応答を受け取るまで、パケットを保持します。確認応答を受け取った場合、すべては順調です。IMPは、次のIMPがパケットの責任を負っていることを認識し、送信側のIMPはパケットのコピーを破棄できます。」と述べています。[20] : 11
- ^ 1973 年までに、BBN は、ARPANET 内部の完全な信頼性という当初の目標は達成不可能であることを認めました。「当初、ネットワーク設計でエラーが発生しやすいのは通信回路だけであると考えられていました。IMP のモデム インターフェイスには、そのようなエラーを「ほぼすべて」検出するための CRC チェックサムが装備されています。ホスト インターフェイス、IMP プロセッサ、メモリ、インターフェイスを含むシステムの残りの部分はすべてエラーがないと考えられていました。私たちは、経験に照らしてこの立場を再評価する必要がありました。 」 [21] : 1 実際、メトカーフが 1973 年までにまとめているように、「ARPANET では、何世紀にもわたってこの割り当て (1 年間に 1 つの未検出の送信ビット エラー) を満たすのに十分なビット エラーが発生しています。」[22] : 7–28 また、BBN レポート 2816 [23] : 10 ff も参照してください。 ARPANET を運用しています。
- ^ ちなみに、ARPANET は、エンドツーエンドの信頼性メカニズムのコストと、それによって得られる利点とのトレードオフについて、良い例を示しています。仕様では、2 つのエンドポイント間で同時に最大 8 つのホスト レベル メッセージが送信され、各メッセージの最大長は 8000 ビットを超えるとされていたため、真のエンドツーエンドの信頼性メカニズムは当時、法外なコストがかかったはずです。宛先 IMP からの確認応答がない場合に備えて、すべてのデータのコピーを保持して再送信できるようにするために必要なメモリの量は、費用がかかりすぎて価値がありませんでした。ホストベースのエンドツーエンドの信頼性メカニズムについては、一般的なホスト レベル プロトコル (ホスト間プロトコル) にかなりの複雑さが加わることになります。ホスト間信頼性メカニズムの望ましさはRFC 1 で明確に述べられましたが、議論の末に廃止されました (ただし、上位レベルのプロトコルやアプリケーションでは、当然ながら、そのようなメカニズムを独自に実装することは自由でした)。当時の議論の詳細については、Bärwolff 2010、[24] pp. 56-58とその中の注釈、特に注釈151と163を参照。
- ^ パケット音声に関する初期の実験は 1971 年に遡り、1972 年までにこのテーマに関するより正式な ARPA の研究が開始されました。RFC 660 (p. 2) に記載されているように、 [ 25] 1974 年に BBN は ARPANET に raw メッセージ サービス (Raw Message Interface、RMI) を導入しました。これは主にホストがパケット音声アプリケーションを実験できるようにするためでしたが、インターネットワーク通信の可能性を考慮して、このような機能の使用も認めていました (BBN レポート 2913 [26]の 55 ページ以降を参照)。Bärwolff 2010、[24]の 80-84 ページと、そこに含まれる大量のメモも参照してください。
参考文献
- ^ ab リチャード・ベネット（2009年9月）。「変化のための設計：エンドツーエンドの議論、インターネットの革新、そしてネット中立性の議論」（PDF）。情報技術とイノベーション財団。pp. 7、11 。 2017年9月11日閲覧。
- ^ ab Saltzer, JH, DP Reed、DD Clark (1981)「システム設計におけるエンドツーエンドの議論」。第 2 回国際分散コンピューティング システム会議の議事録。フランス、パリ。1981 年 4 月 8 ～ 10 日。IEEE コンピュータ ソサエティ、pp. 509 ～ 512。
- ^ abcdef JH Saltzer ; DP Reed ; DD Clark (1984年11月1日). 「システム設計におけるエンドツーエンドの議論」(PDF) . ACM Transactions on Computer Systems . 2 (4): 277–288. doi :10.1145/357401.357402. ISSN 0734-2071. S2CID 215746877. Wikidata Q56503280 . 2022年4月5日閲覧。
- ^ Saltzer, JH (1980). システム設計におけるエンドツーエンドの議論。コメント要求 No. 185、MIT コンピュータサイエンス研究所、コンピュータシステム研究部門。(オンラインコピー)。
- ^ Clark, DD, KT Pogran, DP Reed (1978). 「ローカルエリアネットワーク入門」. Proceedings of the IEEE 66.11, pp. 1497–1517.
- ^ Sunshine、CA (1975)。通信プロトコル設計の問題 - 形式的正確性。ドラフト。INWG プロトコル ノート 5。IFIP WG 6.1 (INWG)。(CBI からのコピー)。
- ^ Blumenthal, MS および DD Clark (2001)。「インターネットの設計を再考する: エンドツーエンドの議論と Brave World」。ACM Transactions on Internet Technology 1.1、pp. 70–109。(オンラインのプレ出版バージョン)。
- ^ Alexis C. Madrigal & Adrienne LaFrance (2014年4月25日)。「ネット中立性：論争の的となったアイデアへのガイド（および歴史）」。The Atlantic 。 2014年6月5日閲覧。
ネット中立性というこのアイデアは、ローレンス・レッシグが「エンドツーエンド」のe2e原則と呼んでいたものです。
- ^ Baran, P. (1964). 「分散通信ネットワークについて」. IEEE Transactions on Communications 12.1、pp. 1–9。
- ^ Davies, DW, KA Bartlett, RA Scantlebury、および PT Wilkinson (1967)。「リモート端末で迅速な応答を提供するコンピュータ向けデジタル通信ネットワーク」。SOSP '67: Proceedings of the First ACM Symposium on Operating System Principles。テネシー州ガトリンバーグ。1967 年 10 月 1 ～ 4 日。ニューヨーク州ニューヨーク: ACM、pp. 2.1 ～ 2.17。
- ^ 「インターネットがいかにして脆弱になったかの本当の話」ワシントンポスト。2015年5月30日時点のオリジナルからアーカイブ。 2020年2月18日閲覧。
歴史家たちは、ウェールズの科学者ドナルド・W・デイヴィスとアメリカのエンジニア、ポール・バランに重要な洞察力があるとしている。
- ^ ARPANET の歴史: 最初の 10 年間(PDF) (レポート)。Bolt、Beranek & Newman Inc. 1981 年 4 月 1 日。183 ページ中 13、53 ページ。2012 年 12 月 1 日にオリジナルからアーカイブ。
通信回線でコンピュータを相互接続する技術的な問題は別として、コンピュータ ネットワークの概念は、理論的な観点からさまざまな場所で検討されてきました。特に注目すべきは、1960 年代初頭に Rand Corporation の Paul Baran らが行った「分散通信について」という研究です。また、1960 年代半ばにイギリスの国立物理学研究所で Donald Davies らが行った研究も注目に値します。... ARPANET の開発に影響を与えた初期のもう 1 つの主要なネットワーク開発は、イギリスのミドルセックスにある国立物理学研究所で DW Davies のリーダーシップの下で行われました。
- ^ C. ヘンプステッド、W .ワージントン( 2005)。20世紀技術百科事典。Routledge。ISBN 9781135455514
パケット ネットワークのシミュレーション作業も NPL グループによって実施されました
。 - ^ Clarke, Peter (1982). パケットおよび回線交換データネットワーク(PDF) (博士論文). ロンドン大学インペリアル・カレッジ・オブ・サイエンス・テクノロジー、電気工学部。「NPL で実際に構築されたパケット交換ネットワークは、ローカル コンピューティング施設間の通信用ですが、さらに大規模なネットワークでシミュレーション実験もいくつか行われています。この作業の概要は [69] に報告されています。この作業は、英国の大部分にデータ通信設備を提供できる規模のネットワークを調査するために実施されました。その後、Davies [70] が考案した「等式」フロー制御と呼ばれるフロー制御方法を使用して実験が行われました。NPL で実施されたシミュレーション作業は、多くの点で、ARPA のネットワーク理論研究のほとんどよりも現実的でした。」
- ^ ab Pelkey, James. 「8.3 CYCLADES ネットワークと Louis Pouzin 1971-1972」。起業家資本主義とイノベーション: 1968-1988 年のコンピューター通信の歴史。2021-06-17 にオリジナルからアーカイブ。2021-11-21に取得。Pouzin
は、Arpanet よりも単純なパケット交換ネットワークの設計という仕事に戻りました。... [Davies] は [広域] データグラム ネットワークのシミュレーションをいくつか行っていましたが、実際に構築したことはなく、技術的には実行可能と思われました。
- ^ 「インターネットの第5の男」。エコノミスト。2013年12月13日。2017年9月11日閲覧。
1970年代初頭、プザン氏はフランス、イタリア、イギリスを結ぶ革新的なデータネットワークを作成した。そのシンプルさと効率性は、数十台ではなく数百万台のマシンを接続できるネットワークへの道を示した。このネットワークはサーフ博士とカーン博士の想像力をかき立て、彼らはその設計の一部を、現在インターネットを動かしているプロトコルに取り入れた。
- ^ ab Scheblik, TJ, DB Dawkins、および Advanced Research Projects Agency (1968)。ARPA コンピュータ ネットワークの RFQ。見積依頼。Advanced Research Projects Agency (ARPA)、国防総省 (DoD)。(オンライン コピーはWayback Machineで 2011-08-15 にアーカイブされています)。
- ^ McQuillan, JM および DC Walden (1977)。「ARPA ネットワーク設計の決定」。Computer Networks 1.5、pp. 243–289。(オンライン コピー)。Crowther ら (1975) の論文に基づいています。この論文は BBN レポート 2918 に基づいており、BBN レポート 2918 は BBN レポート 2913 からの抜粋で、どちらも 1974 年のものです。
- ^ Clark, DD (2007)。アプリケーション設計とエンドツーエンドの議論。MIT Communications Futures Program 隔年会議。ペンシルベニア州フィラデルフィア。2007 年 5 月 30 ～ 31 日。プレゼンテーション スライド。(オンライン コピー)。
- ^ DC、ウォールデン (1972)。 「インターフェイス メッセージ プロセッサ、そのアルゴリズム、およびその実装」。掲載: AFCET Journées d'Études: Réseaux de Calculateurs (コンピュータ ネットワークに関する AFCET ワークショップ)。パリ、フランス。 1972 年 5 月 25 ～ 26 日。フランス経済経済技術協会 (AFCET)。 (オンラインコピー)。
- ^ McQuillan, JM (1973). IMP におけるソフトウェア チェックサムとネットワークの信頼性。RFC 528。 歴史的。NWG。
- ^ Metcalfe, RM (1973)。「パケット通信」。博士論文。マサチューセッツ州ケンブリッジ: ハーバード大学。オンライン コピー (改訂版、MIT コンピュータ サイエンス研究所技術レポート 114 として出版)。主に MIT Project MAC および Xerox PARC で執筆。
- ^ Bolt、Beranek、Newman Inc. (1974)。Arpa コンピュータ ネットワーク用のインターフェイス メッセージ プロセッサ。BBN レポート 2816。四半期技術レポート No.5、1974 年 1 月 1 日から 1974 年 3 月 31 日まで。Bolt、Beranek、Newman Inc. (BBN)。(BBN 提供の個人コピー)。
- ^ ab Bärwolff, M. (2010). 「インターネットにおけるエンドツーエンドの議論: 原則、実践、理論」。オンラインおよび Createspace/Amazon で自費出版 (PDF、正誤表など)
- ^ Walden, DC (1974) IMP および IMP/ホスト インターフェースへのいくつかの変更。RFC 660。 歴史的。NWG。
- ^ BBN (1974)。 Arpa コンピュータ ネットワーク用のインターフェイス メッセージ プロセッサ。 BBN レポート 2913。 四半期技術レポート No. 7、1974 年 7 月 1 日から 1974 年 9 月 30 日まで。 Bolt、Beranek、および Newman Inc. (BBN)。
- ^ J. Kempf、 R . Austein (2004 年 3 月)。中間層の台頭とエンドツーエンドの将来: インターネット アーキテクチャの進化に関する考察。IETF ネットワーク ワーキング グループ。doi : 10.17487 / RFC3724。RFC 3724 。
- ^ 「CNF プロトコル アーキテクチャ」。フォーカス プロジェクト。Winlab、ラトガース大学。2016 年 6 月 23 日時点のオリジナルよりアーカイブ。2016 年5 月 23 日閲覧。
- ^ Ward, Mark (2012-09-14). 「ヨーロッパ、古いインターネットアドレス制限に達する」BBCニュース2017年2月28日閲覧。
- ^ Steve Deering および Bob Hinden、IETF の IP 次世代ワーキング グループの共同議長 (1999 年 11 月 6 日)。「IPv6 アドレス プライバシーに関する声明」。2017 年 2 月 28 日閲覧。
- ^ 「情報駆動型インタラクション指向プログラミング: BSPL、驚くほどシンプルなプロトコル言語」(PDF) 。2013年4 月 24 日閲覧。