再帰的インターネットワークアーキテクチャ

再帰的ネットワーク間アーキテクチャ(RINA) は、現在主流となっているインターネットプロトコルスイートのアーキテクチャに代わるものとして提案された新しいコンピュータネットワークアーキテクチャです。RINA の背後にある原理は、John Dayが2008 年に出版した著書「Patterns in Network Architecture: A return to Fundamentals」で初めて発表されました。^{[1]この作業は新たな出発点であり、}TCP/IPの 35 年間の存在から得られた教訓、 OSIの失敗から得られた教訓、そしてCYCLADES、DECnet、Xerox Network Systemsなど、過去数十年間の他のネットワーク技術から得られた教訓を考慮に入れています。RINA の基本原理は、コンピュータネットワークはプロセス間通信(IPC)にすぎず、階層化は機能に基づいて特殊なプロトコルを使用するのではなく、範囲/規模に基づいて単一の繰り返しプロトコルセットを使用する必要があるというものです。ある層のプロトコルインスタンスは、現在BGP、OSPF、ARPなどのプロトコルに固有のネットワーク機能を効果的に具体化する新しい概念とエンティティを介して、上位層および下位層のプロトコルインスタンスとインターフェイスします。このようにして、 RINA は、 RTPやUDPなどの追加の専用プロトコルを必要とせずに、モビリティ、マルチホーミング、サービス品質などの機能をサポートするとともに、自律システムやNATなどの概念を必要とせずにネットワーク管理を簡素化できると主張しています。

概要

RINA は、あらゆる状況に当てはまるコンピュータネットワーキングの一般原則を解明する取り組みの結果です。RINA は、非公式には IPC モデル^[2]として知られるモデルの特定のアーキテクチャ、実装、テストプラットフォーム、および最終的な展開です。ただし、ネットワーキングだけでなく、あらゆる分散アプリケーションに適用される概念と結果も扱っています。分散アプリケーションから来ているため、用語のほとんどはネットワーキングではなくアプリケーション開発から来ていますが、RINA の基本原則がネットワーキングを IPC に縮小することであることを考えると、これは理解できます。

RINA の基本エンティティは分散アプリケーションプロセス (DAP) であり、これは多くの場合、ホスト上のプロセスに対応します。図 1 に示すように、2 つ以上の DAP が分散アプリケーションファシリティ (DAF) を構成します。これらの DAP は、共通分散アプリケーションプロトコル (CDAP) を使用して通信し、オブジェクトの形式で構造化データを交換します。これらのオブジェクトは、リソース情報ベース (RIB) で構造化され、命名スキーマと論理組織を提供します。CDAP は、リモート DAP のオブジェクトに対して、作成、削除、読み取り、書き込み、開始、停止という 6 つの基本操作を提供します。^{[引用が必要]}

情報を交換するには、DAP には、特定の範囲で IPC サービスの提供と管理を行う基盤となる機能が必要です。この機能は、分散 IPC 機能 (DIF) と呼ばれる別の DAF です。DIF を使用すると、DAP は、対象の DAP の名前と、データ損失と遅延の制限、順序付きまたは順序外の配信、信頼性などの必要な QoS パラメータを指定するだけで、1 つ以上の DAP にフローを割り当てることができます。たとえば、DAP は使用している DIF を信頼していない可能性があるため、SDU保護モジュールを介してフローに書き込む前に、たとえば暗号化してデータを保護することがあります。DIF の DAP は、IPC プロセス (IPCP) と呼ばれます。これらは、図 3 に示すのと同じ汎用 DAP 構造を持ち、さらに IPC を提供および管理するための特定のタスクがあります。図 4 に示すように、これらのタスクは、複雑さが増し、頻度が減る順に、次の 3 つのカテゴリに分類できます。^{[引用が必要]}

データ転送、
データ転送制御と
レイヤー管理。

したがって、ほとんどの現代のネットワークモデルでは、DAF はアプリケーション層に対応し、DIF はすぐ下の層に対応します。また、前の 3 つのタスクカテゴリは、ネットワーク操作だけでなく、ネットワーク管理や認証 (以下で説明するように、責任の調整は多少ありますが) のタスクの大部分に対応します。^{[引用が必要]}

DAF である DIF は、配線やジャックを制御する物理層 DIF に至るまで、他の基礎となる DIF 自体を使用します。これが RINA の再帰の由来です。すべての RINA 層は同じ構造とコンポーネントを持ち、同じ機能を提供します。異なるのは、スコープ、構成、またはポリシーのみです (オペレーティングシステムにおけるメカニズムとポリシーの分離を反映しています)。 ^[3]図 2 に示すように、RINA ネットワークは通常、スコープが増加する DIF で構成されます。図 3 は、RINA を使用して Web を構成する方法の例を示しています。最上位層はアプリケーションに最も近い層で、電子メールまたは Web サイトに対応します。最下位層は、ISPバックボーンに対応して、上位層のトラフィックを集約および多重化します。マルチプロバイダー DIF (パブリックインターネットなど) は、ISP 層の上に浮かんでいます。このモデルでは、3 種類のシステムが区別されます。DAP を含むホスト、層の内部にある内部ルーター、境界ルータは、パケットが 1 つのレイヤーを上下するレイヤーの端にあります。

図 3. 複数のインターネットワークをサポートする複数の RINA ネットワーク。

つまり、RINA は PDU と SDU の概念を維持していますが、機能別に階層化するのではなく、スコープ別に階層化しています。レイヤーは異なる責任ではなく異なるスケールに対応しており、モデルは単一のポイントツーポイントイーサネット接続から Web まで適用できるように特別に設計されています。したがって、RINA は可能な限り多くの理論を再利用し、アドホックプロトコル設計の必要性を排除して、ネットワークの構築、管理、およびプロセスにおける運用の複雑さを軽減する試みです。^{[引用が必要]}

命名、アドレス指定、ルーティング、モビリティ、マルチホーミング

上で説明したように、IP アドレスは、マルチホーミングとモビリティを効率的に基盤とする識別子としては低レベルすぎるだけでなく、ルーティングテーブルを必要以上に大きくする必要があります。RINA の文献は、アドレス指定と命名に関するJerry Saltzerの一般理論に従っています。Saltzer によると、識別する必要があるのは、アプリケーション、ノード、接続ポイント、パスの 4 つの要素です。 ^[4]アプリケーションは 1 つ以上のノードで実行でき、ネットワーク内で ID を失うことなく、あるノードから別のノードに移動できる必要があります。ノードは 1 組の接続ポイントに接続でき、ネットワーク内で ID を失うことなく、それらの間を移動できる必要があります。ディレクトリは、アプリケーション名をノードアドレスにマップし、ルートはノードアドレスと接続ポイントのシーケンスです。これらのポイントを図 4 に示します。

Saltzer はオペレーティングシステムからモデルを採用しましたが、RINA の著者は、同じノードペア (ネットワーク全体は言うまでもなく) 間に複数のパスが存在する可能性があるインターネットワークには、それをきれいに適用できないと結論付けました。彼らの解決策は、ルートをノードのシーケンスとしてモデル化することです。各ホップで、それぞれのノードは、パケットを次のノードに転送するための最も適切な接続ポイントを選択します。したがって、RINA ルートは 2 段階のプロセスで実行されます。最初に、ノードアドレスのシーケンスとしてルートが計算され、次に各ホップで適切な接続ポイントが選択されます。これらは、転送テーブルを生成するための手順です。転送は、依然として 1 回のルックアップで実行されます。さらに、最後の手順は、負荷分散のためにマルチホーミングを利用するために、より頻繁に実行できます。^{[引用が必要]}

この命名構造では、名前が慎重に選択された特性を持つ場合、モビリティとマルチホーミングが本質的にサポートされます^{[5] 。}

アプリケーション名は場所に依存せず、アプリケーションを移動できるようにします。
ノードアドレスは場所に依存しますが、経路には依存しません。
接続ポイントは本質的にルートに依存します。

この命名方式を再帰層を持つ RINA に適用すると、アプリケーション名をノードアドレスにマッピングすることは、ノードアドレスを接続ポイントにマッピングすることに類似しているという結論が導き出されます。簡単に言えば、どの層でも、上位層のノードはアプリケーションとして、下位層のノードは接続ポイントとして見ることができます。

プロトコル設計

インターネットプロトコルスイートでは、一般的に、プロトコルは、他のプロトコルで重複している側面があるかどうか、したがって、これらをポリシーにできるかどうかに関係なく、独立して設計されることが規定されています。RINA は、オペレーティングシステムにおけるメカニズムとポリシーの分離をプロトコル設計に適用することで、これを回避しようとしています。^[6]各 DIF は、異なるポリシーを使用して、異なるクラスのサービス品質を提供し、DIF が低レベルの場合には物理メディアの特性に、DIF が高レベルの場合にはアプリケーションの特性に適応します。

^{RINA は、1981 年にリチャードワトソンが開発した Delta-T プロトコル[7]}の理論を使用しています。ワトソンの研究によると、信頼性の高い転送を行うには、3 つのタイマーをバインドすることが十分条件です。Delta-T は、これがどのように機能するかを示す例です。Delta-T には接続のセットアップやティアダウンがありません。同じ研究では、TCP がすでにこれらのタイマーを使用して動作しているため、Delta-T が比較的シンプルになっていることも指摘されています。ワトソンの研究によると、同期とポート割り当ては別個の機能である必要があり、ポート割り当てはレイヤー管理の一部であり、同期はデータ転送の一部であるべきです。

安全

セキュリティに対応するため、RINA では各 DIF/DAF にセキュリティポリシーを指定することを要求します。その機能は図 5 に示されています。これにより、アプリケーションだけでなく、バックボーンやスイッチングファブリック自体も保護できます。パブリックネットワークは、セキュリティポリシーが何も行わない特殊なケースにすぎません。小規模ネットワークではオーバーヘッドが発生する可能性がありますが、レイヤーがセキュリティメカニズムを調整する必要がないため、大規模ネットワークではより適切に拡張できます。現在のインターネットでは、RINA よりも約 5 倍多くの個別のセキュリティエンティティが必要であると推定されています。^[8]とりわけ、セキュリティポリシーでは認証メカニズムを指定することもできます。これにより、DAF または DIF に参加できない DAP または IPCP は送信も受信もできないため、ファイアウォールやブラックリストは不要になります。DIF は、IPCP アドレスを上位レイヤーに公開しないため、さまざまな中間者攻撃を防止できます。

シンプルさを重視した Delta-T プロトコル自体の設計も要因の 1 つです。たとえば、このプロトコルにはハンドシェイクがないため、偽造される可能性のある制御メッセージや、SYN フラッドのように悪用される可能性のある状態はありません。同期メカニズムにより、異常な動作と侵入の試みとの相関性も高まり、攻撃の検出がはるかに容易になります。^[9]

背景

RINA のような根本的に新しい、異なるネットワークアーキテクチャの出発点は、現在のネットワークアーキテクチャ、特に図 6 に示すインターネットプロトコルスイートとその機能階層化では実用的または妥協のないソリューションが見つからない次の問題を解決または対応しようとすることです。

伝送の複雑さ: IPとTCP を分離すると非効率になり、IP の断片化を防ぐために実行されるMTU 検出が最も明らかな症状です。
パフォーマンス: TCP自体はハンドシェイクにかなり大きなオーバーヘッドを伴い、 SYNフラッドなどの脆弱性も引き起こします。また、TCPはパケットドロップによって自身を抑制し、輻輳を回避します。つまり、輻輳制御は完全にリアクティブであり、プロアクティブでも予防的でもないということです。これは大きなバッファと悪影響を及ぼし、バッファブロートを引き起こします。^[10]
マルチホーミング: IP アドレスとポート番号は、2 つの異なるネットワークでアプリケーションを識別するには低レベルすぎます。DNS では、ホスト名は単一の IP アドレスとポート番号の組み合わせに解決される必要があり、アイデンティティではなくエイリアスになるため、この問題を解決できません。 LISPでも、i) ルーティングにロケータ (IP アドレス) を使用していること、ii) スコープ内のすべてのエンティティが識別子によって位置指定されるという誤った区別に基づいていることから、この問題を解決できません。 ^[11]さらに、独自のスケーラビリティの問題も発生します。^[12]
モビリティ: IP アドレスとポート番号も、ネットワーク間を移動するアプリケーションを識別するには低レベルすぎるため、スマートフォンなどのモバイルデバイスでは問題が複雑になります。モバイル IP は解決策ではありますが、実際には問題を完全に気付アドレスに移し、IP トンネルを導入して複雑さを伴います。
管理: IP アドレスの低レベルの性質は、複数のアドレス、またはアドレス範囲が単一のホストに割り当てられることを促し、^[13]割り当てに圧力をかけ、枯渇を加速させます。NAT はアドレス枯渇を遅らせるだけで、さらに多くの問題を引き起こす可能性があります。同時に、インターネットプロトコルスイートのアーキテクチャの機能階層化により、2 つのスコープしか残されていないため、インターネットの管理の細分化が複雑になり、自律システムという人工的な概念が必要になります。OSPFとIS-IS は比較的問題が少ないですが、拡張性が低く、大規模なネットワークとドメイン間ルーティングにはBGPを使用する必要があります。
セキュリティ: IP アドレス空間自体の性質上、IP アドレスの追加や削除を行うための、物理的に接続を阻止する以外に設定可能なポリシーがないため、セキュリティは脆弱です。TLSとIPSec はソリューションを提供しますが、複雑さを伴います。ファイアウォールとブラックリストは圧倒的な負荷に弱いため、拡張性がありません。「[...] 経験上、プロトコルスイートにセキュリティを追加するには、最初からアーキテクチャに組み込まれていなければなりません。」^[14]

これらの問題は今日でははるかに深刻に見られるようになっていますが、インターネットプロトコルスイートが設計された環境である ARPANETのほぼ初期から、前例や事例が存在していました。

1972年: ARPANETでマルチホーミングがサポートされなくなった

1972年、ティンカー空軍基地^[15]は冗長性のために2つの異なるIMPへの接続を望んでいました。ARPANETの設計者は、ホストアドレスがホストが接続されているIMPポート番号のアドレス（電話から借用）であるため、この機能をサポートできないことに気付きました。ARPANETでは、同じホストの2つのインターフェイスは異なるアドレスを持っていました。つまり、アドレスはホストを識別するには低レベルすぎました。

1978年: TCPがIPから分離

初期のTCPバージョンでは、エラーとフロー制御（現在のTCP）と中継と多重化（IP）の機能を同じプロトコルで実行していました。1978年にTCPはIPから分離されましたが、2つの層の範囲は同じでした。1987年までに、ネットワークコミュニティはIPフラグメンテーションの問題を十分に認識し、有害であると考えるようになりました。^[16]しかし、TCPとIPが相互に依存していることは症状として理解されていませんでした。

1981年: ワトソンの基本的な成果は無視された

リチャード・ワトソンは1981年に信頼性の高いトランスポートの基本理論^[17]を提示しました。この理論では、接続管理には最大パケット寿命(MPL)の小さな係数で制限されたタイマーのみが必要です。この理論に基づいて、ワトソンらはDelta-tプロトコル^[7]を開発しました。これにより、ハンドシェイクなしで、3つのタイマーを制限するだけで接続の状態を判断できます。一方、TCPは明示的なハンドシェイクと、より限定されたタイマーベースの接続状態管理の両方を使用します。

1983年: インターネットワーク層が消失

1972 年の初めに、初期のネットワーク研究コミュニティをまとめるために、国際ネットワーク作業グループ(INWG) が設立されました。同グループが達成した初期のタスクの 1 つは、国際ネットワークトランスポートプロトコルの投票で、これは 1976 年に承認されました。 ^[18]注目すべきことに、選択されたオプションは、他のすべての候補と同様に、範囲が拡大する 3 つの層で構成されたアーキテクチャを持っていました。データリンク (さまざまな種類の物理メディアを処理するため)、ネットワーク (さまざまな種類のネットワークを処理するため)、およびインターネットワーク (ネットワークのネットワークを処理するため) で、各層には独自のアドレス空間がありました。TCP/IP が導入されたとき、ARPANET 上で実行される場合は、ホスト IMP プロトコルの上にあるインターネットワーク層で実行されていました。しかし、 NCPがシャットダウンされると、TCP/IP がネットワークの役割を引き継ぎ、インターネットワーク層は失われました。^[19]このため、今日では、管理を容易にするために IP アドレス空間の範囲を分割して再利用する自律システムと NAT が必要です。

1983年: アドレスを修正する最初の機会を逃す

IP アドレスより上位のアドレスの必要性は、1970 年代半ばからよく理解されていました。しかし、アプリケーション名は導入されず、DNS が設計および導入され、アプリケーションの識別には引き続き既知のポートが使用されました。Web とHTTPの出現により、アプリケーション名の必要性が生じ、URL が生まれました。しかし、URL には IP インターフェイスの DNS 名と TCP ポート番号が含まれるため、各アプリケーションインスタンスがコンピューターの物理インターフェイスと特定のトランスポート接続に結び付けられ、マルチホーミングとモビリティの問題がアプリケーションに波及します。^{[引用が必要]}

1986年: 混雑の崩壊がインターネットを驚かせる

データグラムネットワークにおける輻輳制御の問題は1970年代から80年代初頭にかけて知られていましたが、^[20]^[21] 1986年の輻輳の崩壊はインターネットを驚かせました。さらに悪いことに、採用された輻輳制御（イーサネット輻輳回避方式に若干の修正を加えたもの）がTCPに組み込まれました。

1988年: ネットワーク管理は後退

1988年にIABは、インターネットの初期ネットワーク管理プロトコルとしてSNMPを使用し、後にオブジェクト指向アプローチのCMIPに移行することを推奨しました。^[22] SNMPはネットワーク管理における後退であり、必要なより洗練されたアプローチが実装されるまでの一時的な手段として正当化されましたが、移行は実現しませんでした。

1992年: アドレスを修正する2度目の機会を逃す

1992年、IABは、IPv4ベースのインターネットのスケーリング問題、すなわちアドレス空間の消費とルーティング情報の爆発的増加を解決するための一連の勧告を作成した。提案された選択肢は3つあった。問題を軽減するためにCIDRを導入する、 CLNPに基づいてIPの次期バージョン（IPv7）を設計する、または命名、アドレス指定、ルーティングの研究を継続する。^[23] CLNPは、インターフェースではなくノードをアドレス指定するOSIベースのプロトコルであり、ARPANETにまで遡る古いマルチホーミング問題を解決し、より優れたルーティング情報の集約を可能にした。CIDRは導入されたが、IETFはCLNPに基づくIPv7を受け入れなかった。IABは決定を再考し、IPngプロセスが開始され、IPv6で最高潮に達した。IPngのルールの1つは、IPアドレスのセマンティクスを変更しないことだった。IPアドレスはインターフェースに名前を付与し続け、マルチホーミング問題が永続化する。^[13]

研究プロジェクト

2008年のPNA本の出版から2014年まで、RINAの研究開発作業は数多く行われてきました。ルイ・プーザンにちなんで名付けられたプーザン協会^[24]と呼ばれる非公式のグループが、いくつかの国際的な取り組みを調整しています。

BU 研究チーム

ボストン大学のRINA研究チームは、アブラハム・マッタ教授、ジョン・デイ教授、ルー・チトクシェフ教授が率いており、 RINAの基礎研究の継続、Java用UDP/IPを介したオープンソースのプロトタイプ実装の開発^[25]^[26]、およびGENIインフラストラクチャ上での実験を行うために、国立科学財団とECから多数の助成金を受けています。 ^[27]^[28]ボストン大学はPouzin Societyのメンバーでもあり、FP7 IRATIおよびPRISTINEプロジェクトに積極的に貢献しています。これに加えて、ボストン大学はRINAの概念と理論をコンピュータネットワークコースに取り入れています。

FP7 イラティ

IRATIは、FP7の資金提供を受けたプロジェクトで、i2CAT、Nextworks、iMinds、Interoute、ボストン大学の5つのパートナーが参加しています。イーサネット上のLinux OS用のオープンソースRINA実装を開発しました。^[29]^[30]

FP7 プリスティン

PRISTINE は、FP7 資金提供プロジェクトで、15 のパートナーが参加しています: WIT-TSSG、i2CAT、Nextworks、Telefónica I+D、Thales、Nexedi、B-ISDN、Atos、オスロ大学、Juniper Networks、ブルノ大学、IMT-TSP、CREATE-NET、iMinds、UPC。その主な目標は、RINA のプログラマビリティの側面を調査し、輻輳制御、リソース割り当て、ルーティング、セキュリティ、ネットワーク管理の革新的なポリシーを実装することです。^{[引用が必要]}

GÉANT3+ オープンコール優勝者 IRINA

IRINA はGÉANT3 + 公募により資金提供を受けており、iMinds、WIT-TSSG、i2CAT、Nextworks の 4 つのパートナーと共同でプロジェクトを行っています。IRINA の主な目標は、次世代の NREN および GÉANT ネットワークアーキテクチャの基盤としての再帰的ネットワークアーキテクチャ (RINA) の使用を研究することです。IRINA は IRATI プロトタイプに基づいており、RINA を現在のネットワークの最先端技術および研究中の関連するクリーンスレートアーキテクチャと比較し、NREN シナリオで RINA をより効果的に使用する方法についてのユースケーススタディを実行し、研究の実験室試験を紹介します。^{[引用が必要]}

参照

プロトコル戦争

参考文献

^ ネットワークアーキテクチャのパターン：基本への回帰、ジョン・デイ（2008）、プレンティス・ホール、ISBN 978-0-13-225242-3 ^{[ページが必要]}
^ Day, John; Matta, Ibrahim; Mattar, Karim (2008)。「ネットワーキングは IPC: より良いインターネットへの指針」。2008 ACM CoNEXT カンファレンス - CONEXT '08 の議事録。pp. 1–6。doi :10.1145 / 1544012.1544079。ISBN 978-1-60558-210-8.S2CID 3287224 。
^ Mattar, Karim; Matta, Ibrahim; Day, John; Ishakian, Vatche; Gursun, Gonca (2008 年 7 月 12 日)。宣言型トランスポート: トランスポートプロトコルの設計は不要、指定するポリシーのみ (レポート)。hdl : 2144/1707。
^ J. Saltzer .ネットワーク宛先の命名とバインドについて。RFC 1498 (情報)、1993 年 8 月
^ Ishakian , Vatche; Akinwumi, Joseph; Esposito, Flavio; Matta, Ibrahim (2012 年 7 月)。「再帰的インターネットアーキテクチャにおけるモビリティとマルチホーミングのサポートについて」。Computer Communications。35 ( 13): 1561–1573。doi :10.1016/j.comcom.2012.04.027。hdl : 2144 / 3809。S2CID 3036132 。
^ Hansen, Per Brinch (1970 年4 月)。「マルチプログラミングシステムの核」。Communications of the ACM。13 ( 4): 238–241。doi :10.1145/362258.362278。S2CID 9414037 。
^ ab Watson, RW (1981年12月4日). Delta-tプロトコル仕様: 作業草案 (レポート). doi : 10.2172/5542785 .
^ Small, Jeremiah (2012).ネットワークセキュリティのパターン: 再帰的なネットワーク間アーキテクチャネットワークのセキュリティ保護におけるアーキテクチャの複雑さの分析(論文). hdl :2144/17155.
^ Boddapati, Gowtham; Day, John; Matta, Ibrahim; Chitkushev, Lou (2012). 「クリーンスレートインターネットアーキテクチャのセキュリティの評価」2012 第 20 回 IEEE 国際ネットワークプロトコル会議 (ICNP)。pp. 1–6。doi : 10.1109/ ICNP.2012.6459947。ISBN 978-1-4673-2447-2. S2CID 7500711。
^ Pouzin, L. (1981 年 4 月)。「パケット交換データネットワークにおけるフロー制御の方法、ツール、および観察」IEEE Transactions on Communications 29 ( 4): 413–426. doi :10.1109/TCOM.1981.1095015。
^ Day, John (2008). Loc/Id 分割が解決策ではない理由(PDF) (レポート).^{[自費出版元? ]}
^ D. Meyer と D. Lewis。ロケータ/ID 分離のアーキテクチャ上の意味。https://tools.ietf.org/html/draft-meyer-loc-id-implications-01
^ ab R. Hinden および S. Deering。「IP バージョン 6 アドレス指定アーキテクチャ」。RFC 4291 (ドラフト標準)、2006 年 2 月。RFC 5952、6052 により更新
^ D. Clark、L. Chapin、V. Cerf、R. Braden、R. Hobby。将来のインターネットアーキテクチャに向けて。RFC 1287 (情報)、1991 年 12 月
^ Fritz. E Froehlich、Allen Kent (1992)。「ARPANET、国防データネットワーク、およびインターネット」。Froehlich /Kent 電気通信百科事典。第 5 巻。CRC プレス。p. 82。ISBN 978-0-8247-2903-5。
^ケント、カリフォルニア州; Mogul、JC (1987)。「断片化は有害であると考えられる」。コンピュータ通信技術のフロンティアに関する ACM ワークショップの議事録。pp . 390–401。doi :10.1145/55482.55524。ISBN 978-0-89791-245-7. S2CID 10042690。
^ Watson, Richard W (1981). 「信頼性の高いトランスポートプロトコル接続管理におけるタイマーベースのメカニズム」.コンピュータネットワーク. 5 (1): 47–56. doi :10.1016/0376-5075(81)90031-3.
^ McKenzie, Alexander (2011). 「INWG とインターネットの構想: 目撃証言」. IEEE Annals of the History of Computing . 33 : 66–71. doi :10.1109/MAHC.2011.9. S2CID 206443072.
^ Day, John (2011). 「一体どうやってレイヤーを失うのか!?」2011 未来のネットワークに関する国際会議pp. 135–143. doi :10.1109/NOF.2011.6126673. ISBN 978-1-4577-1607-2. S2CID 15198377。
^ Pouzin, L. (1981 年 4 月)。「パケット交換データネットワークにおけるフロー制御の方法、ツール、および観察」IEEE Transactions on Communications 29 ( 4): 413–426. doi :10.1109/TCOM.1981.1095015。
^ Lam; Lien (1981 年 10 月)。「入力バッファ制限によるパケット通信ネットワークの輻輳制御 - シミュレーション研究」IEEE Transactions on Computers。C - 30 (10): 733–742。doi :10.1109/TC.1981.1675692 。
^ インターネットアーキテクチャ委員会。インターネットネットワーク管理標準の開発に関する IAB 勧告。RFC 1052、1988 年 4 月
^ インターネットアーキテクチャ委員会。IP バージョン 7 ** ドラフト 8 **。ドラフト IAB IPversion7、1992 年 7 月
^ Russell, Andrew L.; Schafer, Valérie (2014). 「ARPANET とインターネットの影: 1970 年代の Louis Pouzin と Cyclades ネットワーク」.テクノロジーと文化. 55 (4): 880–907. doi :10.1353/tech.2014.0096. S2CID 143582561. Project MUSE 562835.
^ Esposito, Flavio; Wang, Yuefeng; Matta, Ibrahim; Day, John (2013 年 4 月)。サービスとしての動的レイヤーのインスタンス化(PDF)。USENIX ネットワークシステムの設計と実装に関するシンポジウム (NSDI '13)。
^ Wang, Yuefeng; Matta, Ibrahim ; Esposito, Flavio; Day, John (2014 年 7 月 28 日)。「ProtoRINA の紹介: 再帰ネットワークポリシーをプログラミングするためのプロトタイプ」。ACM SIGCOMM Computer Communication Review。44 (3): 129–131。doi : 10.1145 /2656877.2656897。S2CID 1007699。
^ Wang, Yuefeng; Esposito, Flavio; Matta, Ibrahim ( 2013). 「GENI テストベッドを使用した RINA のデモンストレーション」。2013年第 2 回 GENI 研究教育実験ワークショップ。pp. 93–96。doi :10.1109 / GREE.2013.26。ISBN 978-0-7695-5003-9. S2CID 6735043。
^ Wang, Yuefeng; Matta, Ibrahim; Akhtar, Nabeel ( 2014). 「GENI 上で ProtoRINA を使用したルーティングポリシーの実験」。2014年第 3 回 GENI 研究教育実験ワークショップ。pp. 61–64。doi :10.1109 / GREE.2014.11。ISBN 978-1-4799-5120-8. S2CID 16799199。
^ ヴライデルス、サンダース;スタッセンス、ディミトリ。コル、ディディエ。サルヴェストリーニ、フランチェスコ。グラサ、エドゥアルド。ターザン、ミケル。レオナルド・ベルヘジオ（2014年3月）。「再帰的インターネットアーキテクチャのプロトタイプ作成: IRATI プロジェクトのアプローチ」。IEEE ネットワーク。28 (2)：20～25。土井：10.1109/MNET.2014.6786609。hdl : 1854/LU-5730910。S2CID 7594551。
^ ヴライデルス、サンダース;スタッセンス、ディミトリ。コル、ディディエ。サルヴェストリーニ、フランチェスコ。マフィオーネ、ヴィンチェンツォ。ベルヘジオ、レオナルド。ターザン・ロレンテ、ミケル。ガストン、ベルナト。グラサ、エドゥアルド (2014)。「再帰的インターネットワークアーキテクチャプロトタイプの実験的評価」。 2014 IEEE グローバルコミュニケーションカンファレンス。 2017 ～ 2022 ページ。土井：10.1109/GLOCOM.2014.7037104。hdl :1854/LU-5955523。ISBN 978-1-4799-3512-3. S2CID 13462659。

外部リンク

プーザン協会のウェブサイト: http://pouzinsociety.org
IRATI ウェブサイトの RINA 教育ページ (http://irati.eu/education/ からオンラインで利用可能)
TSSG が運営する RINA ドキュメントリポジトリ。http://rina.tssg.org でオンラインで入手可能。
IEEE Globecom 2014 カンファレンスでの RINA チュートリアルは、http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014 からオンラインで入手できます。

[PNA-1] ネットワークアーキテクチャのパターン：基本への回帰、ジョン・デイ（2008）、プレンティス・ホール、ISBN 978-0-13-225242-3 ^{[ページが必要]}

[2] Day, John; Matta, Ibrahim; Mattar, Karim (2008)。「ネットワーキングは IPC: より良いインターネットへの指針」。2008 ACM CoNEXT カンファレンス - CONEXT '08 の議事録。pp. 1–6。doi :10.1145 / 1544012.1544079。ISBN 978-1-60558-210-8.S2CID 3287224 。

[3] Mattar, Karim; Matta, Ibrahim; Day, John; Ishakian, Vatche; Gursun, Gonca (2008 年 7 月 12 日)。宣言型トランスポート: トランスポートプロトコルの設計は不要、指定するポリシーのみ (レポート)。hdl : 2144/1707。

[Saltzer-4] ^ J. Saltzer .ネットワーク宛先の命名とバインドについて。RFC 1498 (情報)、1993 年 8 月

[5] ^ Ishakian , Vatche; Akinwumi, Joseph; Esposito, Flavio; Matta, Ibrahim (2012 年 7 月)。「再帰的インターネットアーキテクチャにおけるモビリティとマルチホーミングのサポートについて」。Computer Communications。35 ( 13): 1561–1573。doi :10.1016/j.comcom.2012.04.027。hdl : 2144 / 3809。S2CID 3036132 。

[policy-6] ^ Hansen, Per Brinch (1970 年4 月)。「マルチプログラミングシステムの核」。Communications of the ACM。13 ( 4): 238–241。doi :10.1145/362258.362278。S2CID 9414037 。

[deltat-7] Watson, RW (1981年12月4日). Delta-tプロトコル仕様: 作業草案 (レポート). doi : 10.2172/5542785 .

[8] Small, Jeremiah (2012).ネットワークセキュリティのパターン: 再帰的なネットワーク間アーキテクチャネットワークのセキュリティ保護におけるアーキテクチャの複雑さの分析(論文). hdl :2144/17155.

[9] Boddapati, Gowtham; Day, John; Matta, Ibrahim; Chitkushev, Lou (2012). 「クリーンスレートインターネットアーキテクチャのセキュリティの評価」2012 第 20 回 IEEE 国際ネットワークプロトコル会議 (ICNP)。pp. 1–6。doi : 10.1109/ ICNP.2012.6459947。ISBN 978-1-4673-2447-2. S2CID 7500711。

[10] Pouzin, L. (1981 年 4 月)。「パケット交換データネットワークにおけるフロー制御の方法、ツール、および観察」IEEE Transactions on Communications 29 ( 4): 413–426. doi :10.1109/TCOM.1981.1095015。

[lispno-11] Day, John (2008). Loc/Id 分割が解決策ではない理由(PDF) (レポート).^{[自費出版元? ]}

[lispis-12] D. Meyer と D. Lewis。ロケータ/ID 分離のアーキテクチャ上の意味。https://tools.ietf.org/html/draft-meyer-loc-id-implications-01

[IPv6-13] R. Hinden および S. Deering。「IP バージョン 6 アドレス指定アーキテクチャ」。RFC 4291 (ドラフト標準)、2006 年 2 月。RFC 5952、6052 により更新

[14] ^ D. Clark、L. Chapin、V. Cerf、R. Braden、R. Hobby。将来のインターネットアーキテクチャに向けて。RFC 1287 (情報)、1991 年 12 月

[tinker-AFB-15] Fritz. E Froehlich、Allen Kent (1992)。「ARPANET、国防データネットワーク、およびインターネット」。Froehlich /Kent 電気通信百科事典。第 5 巻。CRC プレス。p. 82。ISBN 978-0-8247-2903-5。

[16] ^ケント、カリフォルニア州; Mogul、JC (1987)。「断片化は有害であると考えられる」。コンピュータ通信技術のフロンティアに関する ACM ワークショップの議事録。pp . 390–401。doi :10.1145/55482.55524。ISBN 978-0-89791-245-7. S2CID 10042690。

[watson1981a-17] Watson, Richard W (1981). 「信頼性の高いトランスポートプロトコル接続管理におけるタイマーベースのメカニズム」.コンピュータネットワーク. 5 (1): 47–56. doi :10.1016/0376-5075(81)90031-3.

[:0-18] McKenzie, Alexander (2011). 「INWG とインターネットの構想: 目撃証言」. IEEE Annals of the History of Computing . 33 : 66–71. doi :10.1109/MAHC.2011.9. S2CID 206443072.

[lostlayer-19] Day, John (2011). 「一体どうやってレイヤーを失うのか!?」2011 未来のネットワークに関する国際会議pp. 135–143. doi :10.1109/NOF.2011.6126673. ISBN 978-1-4577-1607-2. S2CID 15198377。

[20] Pouzin, L. (1981 年 4 月)。「パケット交換データネットワークにおけるフロー制御の方法、ツール、および観察」IEEE Transactions on Communications 29 ( 4): 413–426. doi :10.1109/TCOM.1981.1095015。

[21] Lam; Lien (1981 年 10 月)。「入力バッファ制限によるパケット通信ネットワークの輻輳制御 - シミュレーション研究」IEEE Transactions on Computers。C - 30 (10): 733–742。doi :10.1109/TC.1981.1675692 。

[22] インターネットアーキテクチャ委員会。インターネットネットワーク管理標準の開発に関する IAB 勧告。RFC 1052、1988 年 4 月

[23] インターネットアーキテクチャ委員会。IP バージョン 7 ** ドラフト 8 **。ドラフト IAB IPversion7、1992 年 7 月

[24] Russell, Andrew L.; Schafer, Valérie (2014). 「ARPANET とインターネットの影: 1970 年代の Louis Pouzin と Cyclades ネットワーク」.テクノロジーと文化. 55 (4): 880–907. doi :10.1353/tech.2014.0096. S2CID 143582561. Project MUSE 562835.

[25] Esposito, Flavio; Wang, Yuefeng; Matta, Ibrahim; Day, John (2013 年 4 月)。サービスとしての動的レイヤーのインスタンス化(PDF)。USENIX ネットワークシステムの設計と実装に関するシンポジウム (NSDI '13)。

[26] ^ Wang, Yuefeng; Matta, Ibrahim ; Esposito, Flavio; Day, John (2014 年 7 月 28 日)。「ProtoRINA の紹介: 再帰ネットワークポリシーをプログラミングするためのプロトタイプ」。ACM SIGCOMM Computer Communication Review。44 (3): 129–131。doi : 10.1145 /2656877.2656897。S2CID 1007699。

[27] ^ Wang, Yuefeng; Esposito, Flavio; Matta, Ibrahim ( 2013). 「GENI テストベッドを使用した RINA のデモンストレーション」。2013年第 2 回 GENI 研究教育実験ワークショップ。pp. 93–96。doi :10.1109 / GREE.2013.26。ISBN 978-0-7695-5003-9. S2CID 6735043。

[28] ^ Wang, Yuefeng; Matta, Ibrahim; Akhtar, Nabeel ( 2014). 「GENI 上で ProtoRINA を使用したルーティングポリシーの実験」。2014年第 3 回 GENI 研究教育実験ワークショップ。pp. 61–64。doi :10.1109 / GREE.2014.11。ISBN 978-1-4799-5120-8. S2CID 16799199。

[29] ヴライデルス、サンダース;スタッセンス、ディミトリ。コル、ディディエ。サルヴェストリーニ、フランチェスコ。グラサ、エドゥアルド。ターザン、ミケル。レオナルド・ベルヘジオ（2014年3月）。「再帰的インターネットアーキテクチャのプロトタイプ作成: IRATI プロジェクトのアプローチ」。IEEE ネットワーク。28 (2)：20～25。土井：10.1109/MNET.2014.6786609。hdl : 1854/LU-5730910。S2CID 7594551。

[30] ヴライデルス、サンダース;スタッセンス、ディミトリ。コル、ディディエ。サルヴェストリーニ、フランチェスコ。マフィオーネ、ヴィンチェンツォ。ベルヘジオ、レオナルド。ターザン・ロレンテ、ミケル。ガストン、ベルナト。グラサ、エドゥアルド (2014)。「再帰的インターネットワークアーキテクチャプロトタイプの実験的評価」。 2014 IEEE グローバルコミュニケーションカンファレンス。 2017 ～ 2022 ページ。土井：10.1109/GLOCOM.2014.7037104。hdl :1854/LU-5955523。ISBN 978-1-4799-3512-3. S2CID 13462659。