Loading article…
再帰的インターネットワークアーキテクチャ (RINA)は、現在主流のインターネットプロトコルスイートのアーキテクチャに代わるものとして提案された新しいコンピュータネットワークアーキテクチャです。RINA の背後にある原理は、ジョン・デイが2008 年に著した『Patterns in Network Architecture: A return to Fundamentals』で初めて発表されました。[ 1 ]この著作は、TCP/IPの 35 年間の歴史から得られた教訓、 OSIの失敗の教訓、 CYCLADES、DECnet、Xerox Network Systemsなど過去 数十年の他のネットワーク技術の教訓を考慮に入れた、新たな出発点です。RINA の基本的な原理は、コンピュータネットワークは単なるプロセス間通信(IPC) であり、階層化は機能に基づいて特殊なプロトコルを使用するのではなく、単一の繰り返し使用されるプロトコルセットを使用して、範囲/規模に基づいて行うべきであるということです。 RINAは、あるレイヤのプロトコルインスタンスと、上位および下位レイヤのプロトコルインスタンスとの間で、BGP、OSPF 、 ARPなどのプロトコルに現在特有のネットワーク機能を効果的に具体化する新しい概念とエンティティを介してインターフェースします。このようにして、RINAは、RTPやUDPなどの追加の専用プロトコルを必要とせずに、モビリティ、マルチホーミング、サービス品質などの機能をサポートし、自律システムやNATなどの概念を必要とせずに、ネットワーク管理を簡素化できると主張しています。
RINA は、あらゆる状況に適用できるコンピュータ ネットワークの一般原則を解明しようとする取り組みの結果です。RINA は、非公式には IPC モデルとして知られるモデルの具体的なアーキテクチャ、実装、テスト プラットフォーム、そして最終的な展開ですが、ネットワークだけでなく、あらゆる分散アプリケーションに適用できる概念や結果も扱っています。分散アプリケーションから生まれたため、用語のほとんどはネットワークではなくアプリケーション開発から来ていますが、 RINAの基本原則がネットワークを IPC に還元することであることを考えると、これは理解できます。
RINAの基本要素は分散アプリケーションプロセス（DAP）であり、これは多くの場合、ホスト上のプロセスに対応します。図1に示すように、2つ以上のDAPが分散アプリケーションファシリティ（DAF）を構成します。これらのDAPは、共通分散アプリケーションプロトコル（CDAP）を使用して通信し、オブジェクトの形式で構造化データを交換します。これらのオブジェクトは、リソース情報ベース（RIB）に構造化されており、RIBはオブジェクトに命名規則と論理的な構成を提供します。CDAPは、リモートDAPのオブジェクトに対して、作成、削除、読み取り、書き込み、開始、停止の6つの基本操作を提供します。
情報交換を行うには、DAP は、特定の範囲で IPC サービスを提供および管理する役割を担う基盤となる施設を必要とします。この施設は、分散 IPC 施設 (DIF) と呼ばれる別の DAF です。DIF を使用すると、DAP は、対象となる DAP の名前と、データ損失や遅延の制限、順序付き配信または順不同配信、信頼性などの QoS パラメータを指定するだけで、1 つ以上の DAP にフローを割り当てることができます。たとえば、DAP は使用している DIF を信頼していない可能性があり、そのため、SDU保護モジュールを介してデータをフローに書き込む前に、暗号化するなどしてデータを保護する場合があります。DIF の DAP は、IPC プロセス (IPCP) と呼ばれます。IPCP は、図 3 に示す一般的な DAP 構造に加えて、IPC を提供および管理するための特定のタスクを備えています。これらのタスクは、図 4 に示すように、複雑さが増し頻度が減る順に、次の 3 つのカテゴリに分類できます。
したがって、ほとんどの現代のネットワークモデルでは、DAFはアプリケーション層に対応し、DIFはその直下の層に対応します。そして、前述の3つのタスクカテゴリは、ネットワーク運用だけでなく、ネットワーク管理や認証（後述するように責任範囲に若干の調整はあるものの）といったタスクの大部分に対応します。
DIF は DAF であるため、それ自体が他の下位 DIF を使用し、ワイヤとジャックを制御する物理層 DIF まで続きます。これが RINA の再帰の由来です。すべての RINA 層は同じ構造とコンポーネントを持ち、同じ機能を提供します。異なるのは、スコープ、構成、またはポリシーのみです (オペレーティングシステムのメカニズムとポリシーの分離を反映しています)。[ 3 ]図 2 に示すように、RINA ネットワークは通常、スコープが拡大する DIF で構成されます。図 3 は、Web を RINA でどのように構成できるかの例を示しています。最上位層はアプリケーションに最も近い層で、電子メールまたは Web サイトに対応します。最下位層は上位層のトラフィックを集約および多重化し、ISPバックボーンに対応します。マルチプロバイダ DIF (パブリック インターネットなど) は、ISP 層の上に浮遊します。このモデルでは、3 種類のシステムが区別されます。DAP を含むホスト、層内部の内部ルータ、そして、境界ルーターは、レイヤーの端に位置し、パケットが1つ上のレイヤーまたは下のレイヤーへ移動する場所です。
要するに、RINAはPDUとSDUの概念を維持しつつ、機能による階層化ではなく、スコープによる階層化を採用しています。各階層は異なる責任範囲ではなく、異なる規模に対応しており、単一のポイントツーポイントイーサネット接続からWebに至るまで適用できるように設計されています。したがって、RINAは可能な限り多くの理論を再利用し、アドホックなプロトコル設計の必要性を排除することで、ネットワークの構築、管理、運用における複雑さを軽減することを目指しています。
前述のように、IP アドレスはマルチホーミングとモビリティを効率的に実現するには低レベルすぎる識別子であり、ルーティング テーブルも必要以上に大きくなってしまいます。RINA の文献は、ジェリー・ソルツァーのアドレス指定と命名に関する一般的な理論に従っています。ソルツァーによれば、アプリケーション、ノード、接続点、パスの 4 つの要素を識別する必要があります。[ 4 ]アプリケーションは 1 つ以上のノードで実行でき、ネットワーク内での識別情報を失うことなく、あるノードから別のノードに移動できる必要があります。ノードは一対の接続点に接続でき、ネットワーク内での識別情報を失うことなく、それらの間を移動できる必要があります。ディレクトリはアプリケーション名をノード アドレスにマッピングし、ルートはノード アドレスと接続点のシーケンスです。これらのポイントは図 4 に示されています。
Saltzerはオペレーティングシステムからモデルを着想したが、RINAの開発者たちは、同じノードペア間に複数のパスが存在する可能性のあるインターネットワーク（ましてやネットワーク全体）には、このモデルをそのまま適用することはできないと結論付けた。彼らの解決策は、経路をノードのシーケンスとしてモデル化することである。各ホップにおいて、それぞれのノードはパケットを次のノードに転送するために最も適切な接続ポイントを選択する。したがって、RINAは2段階のプロセスでルーティングを行う。まず、ノードアドレスのシーケンスとして経路を計算し、次に、各ホップに対して適切な接続ポイントを選択する。これらが転送テーブルを生成する手順であり、転送は依然として単一のルックアップで実行される。さらに、負荷分散のためにマルチホーミングを活用するために、最後のステップをより頻繁に実行することもできる。
この命名構造では、名前が慎重に選択された特性を持っている場合、モビリティとマルチホーミングが本質的にサポートされます[ 5 ] 。
この命名規則を再帰的な階層構造を持つRINAに適用すると、アプリケーション名をノードアドレスにマッピングすることは、ノードアドレスをアタッチメントポイントにマッピングすることと類似しているという結論が得られます。簡単に言えば、どの階層においても、上位階層のノードはアプリケーションと見なすことができ、下位階層のノードはアタッチメントポイントと見なすことができます。
インターネットプロトコルスイートでは、一般的に、他のプロトコルで側面が重複しているかどうか、したがってそれらをポリシーにできるかどうかに関係なく、プロトコルは独立して設計されるべきであると規定されています。RINAは、オペレーティングシステムにおけるメカニズムとポリシーの分離をプロトコル設計に適用することで、これを回避しようとしています。[ 6 ]各DIFは、異なるクラスのサービス品質を提供し、DIFが低レベルの場合は物理メディアの特性に、DIFが高レベルの場合はアプリケーションの特性に適応するために、異なるポリシーを使用します。
RINAは、1981年にリチャード・ワトソンによって開発されたDelta-Tプロトコル[ 7 ]の理論を採用しています。ワトソンの研究によると、信頼性の高い転送のための十分条件は、3つのタイマーを境界付けることです。Delta-Tは、この仕組みの一例であり、接続の確立や切断は行いません。同じ研究では、TCPが既にこれらのタイマーを動作に使用しているため、Delta-Tは比較的単純であるとも指摘しています。ワトソンの研究はまた、同期とポート割り当ては別々の機能であるべきであり、ポート割り当てはレイヤ管理の一部であり、同期はデータ転送の一部であるべきだと示唆しています。
セキュリティに対応するため、RINA では各 DIF/DAF にセキュリティ ポリシーを指定することを要求しており、その機能は図 5 に示されています。これにより、アプリケーションだけでなく、バックボーンやスイッチング ファブリック自体も保護できます。パブリック ネットワークは、セキュリティ ポリシーが何も行わない特別なケースです。これは小規模ネットワークではオーバーヘッドを引き起こす可能性がありますが、レイヤーがセキュリティ メカニズムを調整する必要がないため、大規模ネットワークでは拡張性が高くなります。現在のインターネットでは、RINA よりも約 5 倍多くの個別のセキュリティ エンティティが必要になると推定されています。[ 8 ]セキュリティ ポリシーでは、認証メカニズムを指定することもできます。これにより、DAF または DIF に参加できない DAP または IPCP は送信または受信できないため、ファイアウォールやブラックリストは不要になります。また、DIF は IPCP アドレスを上位レイヤーに公開しないため、中間者攻撃の多くの種類を防ぐことができます。
Delta-Tプロトコル自体の設計、特にそのシンプルさを重視した設計も要因の一つです。例えば、このプロトコルにはハンドシェイクがないため、SYNフラッド攻撃のように偽造可能な制御メッセージや悪用可能な状態が存在しません。また、同期メカニズムによって異常な動作と侵入試行との相関性が高まり、攻撃の検出がはるかに容易になります。[ 9 ]
RINAのような根本的に新しいネットワークアーキテクチャの出発点は、現在のネットワークアーキテクチャ、特に図6に示すインターネットプロトコルスイートとその機能階層では、実用的かつ妥協のない解決策が見当たらない以下の問題を解決しようとする試み、あるいはそれに対する対応である。
これらの問題は今日でははるかに顕著になっているが、インターネットプロトコルスイートが設計された環境であるARPANETの初期から、前例や事例は存在していた。
1972年、ティンカー空軍基地[ 15 ]は冗長性のために2つの異なるIMPへの接続を希望した。ARPANETの設計者は、ホストアドレスがホストが接続されているIMPポート番号のアドレス（電話から借用）であるため、この機能をサポートできないことに気づいた。ARPANETでは、同じホストの2つのインターフェースは異なるアドレスを持つ。つまり、アドレスはホストを識別するには低レベルすぎた。
初期の TCP バージョンでは、エラー制御とフロー制御 (現在の TCP) およびリレーと多重化 (IP) の機能が同じプロトコルで実行されていました。1978 年に TCP は IP から分離されましたが、2 つのレイヤーは同じ範囲でした。1987 年までに、ネットワーク コミュニティは IP の断片化の問題を十分に認識しており、有害であると考えるほどでした。[ 16 ]しかし、TCP と IP が相互依存しているという兆候として理解されていませんでした。
1981年、リチャード・ワトソンは、信頼性の高いトランスポートの基本理論[ 17 ]を提示しました。この理論によれば、接続管理には最大パケット寿命（MPL）の小さな係数で制限されたタイマーのみが必要です。この理論に基づいて、ワトソンらは、ハンドシェイクなしで3つのタイマーを制限するだけで接続の状態を決定できるDelta-tプロトコル[ 7 ]を開発しました。一方、TCPは明示的なハンドシェイクと、より限定的なタイマーベースの接続状態管理の両方を使用しています。
1972 年初頭、黎明期のネットワーク研究コミュニティを結集するために国際ネットワークワーキンググループ(INWG) が設立されました。INWG が最初に成し遂げた仕事の 1 つは、国際ネットワークトランスポートプロトコルの投票であり、これは 1976 年に承認されました。 [ 18 ]注目すべきことに、選択されたオプションは、他のすべての候補と同様に、範囲が拡大する 3 つのレイヤー (データリンク (さまざまな種類の物理メディアを処理するため)、ネットワーク (さまざまな種類のネットワークを処理するため)、インターネットワーク (ネットワークのネットワークを処理するため)) で構成されるアーキテクチャを持ち、各レイヤーは独自のアドレス空間を持っていました。TCP/IP が導入されたとき、ARPANET 上で動作していたときは、ホスト IMP プロトコルの上にインターネットワーク レイヤーで動作していました。しかし、 NCP が停止されると、TCP/IP がネットワークの役割を引き継ぎ、インターネットワーク レイヤーは失われました。[ 19 ]これは、管理を容易にするために IP アドレス空間の範囲を分割して再利用する、今日の自律システムと NAT の必要性を説明しています。
IPアドレスよりも上位のアドレスが必要であることは、1970年代半ばから十分に認識されていました。しかし、アプリケーション名は導入されず、DNSは設計・展開され、アプリケーションの識別には引き続き既知のポート番号が使用されていました。WebとHTTPの登場によりアプリケーション名の必要性が生じ、URLが誕生しました。しかし、URLにはIPインターフェースのDNS名とTCPポート番号が含まれているため、各アプリケーションインスタンスがコンピュータの物理インターフェースと特定のトランスポート接続に結び付けられ、マルチホーミングとモビリティの問題がアプリケーションにまで及んでしまいます。
データグラムネットワークにおける輻輳制御の問題は1970年代から80年代初頭にかけて知られていたが、[ 10 ] [ 20 ] 1986年の輻輳崩壊はインターネットを驚かせた。さらに悪いことに、採用された輻輳制御、つまりいくつかの修正を加えたイーサネット輻輳回避方式がTCPに組み込まれた。
1988年、IABはインターネットの初期ネットワーク管理プロトコルとしてSNMPを使用し、後にCMIPのオブジェクト指向アプローチに移行することを推奨した。[ 21 ] SNMPはネットワーク管理において後退であり、必要なより高度なアプローチが実装されるまでの暫定的な措置として正当化されたが、移行は実現しなかった。
1992 年、IAB はIPv4ベースのインターネットのスケーリング問題(アドレス空間の消費とルーティング情報の爆発) を解決するための一連の勧告を作成しました。 3 つのオプションが提案されました。CIDRを導入して問題を軽減する、CLNPに基づいて IP (IPv7) の次のバージョンを設計する、または命名、アドレス指定、ルーティングの研究を続ける、です。[ 22 ] CLNP は OSI ベースのプロトコルで、インターフェースではなくノードにアドレスを付けるものでした。ARPANET に遡る古いマルチホーミング問題を解決し、ルーティング情報の集約を改善しました。 CIDRが導入されましたが、IETF はCLNP に基づく IPv7 を受け入れませんでした。 IAB はその決定を再検討し、IPng プロセスが開始され、最終的にIPv6になりました。 IPng のルールの 1 つは、インターフェースに名前を付け続ける IP アドレスの意味を変更しないことで、マルチホーミング問題を永続化しました。[ 13 ]
2008年にPNAの本が出版されてから2014年まで、RINAの研究開発作業が数多く行われてきました。ルイ・プーザンにちなんで名付けられたプーザン協会として知られる非公式グループ[ 23 ]が、いくつかの国際的な取り組みを調整しています。
ボストン大学のRINA研究チームは、アブラハム・マッタ教授、ジョン・デイ教授、ルー・チトクシェフ教授が率いており、RINA の基礎の研究を継続し、Java 用の UDP/IP 上でオープンソースのプロトタイプ実装を開発し[ 24 ] [ 25 ] 、GENIインフラストラクチャ上で実験を行うために、国立科学財団と EC から多数の助成金を受けています。 [ 26 ] [ 27 ] BU は Pouzin Society のメンバーでもあり、FP7 IRATI および PRISTINE プロジェクトに積極的に貢献しています。さらに、BU は RINA の概念と理論をコンピュータ ネットワークのコースに取り入れています。
IRATIは、i2CAT、Nextworks、iMinds、Interoute、ボストン大学の5つのパートナーによるFP7資金提供プロジェクトです。イーサネット上のLinux OS向けにオープンソースのRINA実装を開発しました。[ 28 ] [ 29 ]
PRISTINEは、FP7の資金提供を受けたプロジェクトで、WIT-TSSG、i2CAT、Nextworks、Telefónica I+D、Thales、Nexedi、B-ISDN、Atos、オスロ大学、Juniper Networks、ブルノ大学、IMT-TSP、CREATE-NET、iMinds、UPCの15のパートナーが参加しています。主な目的は、RINAのプログラマビリティの側面を探求し、輻輳制御、リソース割り当て、ルーティング、セキュリティ、ネットワーク管理のための革新的なポリシーを実装することです。
IRINAはGÉANT3 +オープンコールで資金提供を受け、iMinds、WIT-TSSG、i2CAT、Nextworksの4つのパートナーと共同でプロジェクトを進めています。IRINAの主な目的は、次世代NRENおよびGÉANTネットワークアーキテクチャの基盤として、再帰型インターネットワークアーキテクチャ（RINA）の利用を研究することです。IRINAはIRATIプロトタイプをベースに構築されており、RINAを現在のネットワーク技術の最先端および研究中の関連する新規アーキテクチャと比較し、NRENシナリオでRINAをより効果的に活用する方法のユースケーススタディを実施し、研究の実験室での試行結果を紹介します。