ISO/IEC 4396-1:2023 システム間の通信と情報交換 | ページ 7

6 分散管理システム (DMS) の概要

6.1 一般

DMS には 3 つの形式があります。

• a) 1 つ以上の DIF の要素をリモートで管理するための DAF 管理システムは、本書ではネットワーク管理システムまたは NM 分散管理システム (DMS) と呼ばれます (5.2 を参照)
• b)特定の目的に使用される DAF のコレクションを管理するための DAF 管理システム。アプリケーション管理システムまたは AM-DMS とも呼ばれます (5.3 を参照)
• c)特定の名前空間を管理するための DAF 管理システムは、名前空間管理 DAF, または NSM-DMS (5.4 を参照) です。

すべての処理システム、アプリケーション プロセス、および IPC プロセスは、何らかの形式の DMS によって管理され、非 DMS DAF によって使用されるすべてのリソースは、これらの DMS によって監視されます。 DMS によって管理される要素の集合は DMS ドメインと呼ばれます。 DAF または DIF が単一の DMS ドメインによって全体として管理される必要はありませんが、管理される場合があります。ただし、DAP または IPC プロセスは 1 つだけの DMS によって管理されます。すべてのメンバー IPC プロセスが異なる DMS のドメインに分類される DIF が存在するwhere があります。唯一の中央またはマスターの役割を、それ自体が配布された DIF の開始に関連付けることができます。たとえば、複数の (N-1)-DIF にわたる新しい DIF を必要とする DIF アロケーター リクエストに応答して DIF の作成を開始することは、1 つの DAP によって管理されます。

ほとんどのローカル DIF アロケータ リクエスト、つまりこの処理システム上の DAP によって生成されたリクエストは、実際の解決のために NSM-DMS に転送されます。アプリケーション (DAP) または DAF を担当する DMS はローカル リポジトリを維持し、既存または新規の DIF に参加するための IPC プロセスを作成するための資格情報を持ちます。一方、ホストはより多くの用途に使用されますが、検索を容易にするために、最近使用したアプリケーションのローカル キャッシュを維持する可能性があります。

6.2 ネットワーク管理 DMS (NM-DMS)

DIF を構成する IPC プロセスは、その動作と監視する条件に関する情報を交換しますが、一般に、ネットワークを構成する DIF の動作を外部から監視することも必要です。メンバーはローカルな最適化に到達するかもしれませんが、多くの場合、「外部」の視点なしでグローバルな最適化を発見することはより複雑です。

これらのシステムでは、制御は自動化されなければなりません。中央集中型システムが効果を発揮するには、イベントの発生や状態の変化があまりにも早く行われています。さらに、分散システムの性質により、常にパーティショニングの可能性が開かれます。したがって、分散システムは中央制御なしでもフェイルセーフが可能であるはずです。管理の目的は監視と修復であり、制御ではありません。

NM-DMS は、新しい設定の展開やパフォーマンスの監視など、監視と修復の従来の機能を実行します。 DAF モデルは、分散型 (自律型) から集中型 (従来型) までの範囲全体を表すネットワーク管理に適用できます。どちらも必須です。前述したように、分散アルゴリズムの経験により、局所的な最適値を見つける能力は示されていますが、必ずしも全体的な最適値を見つけることができるわけではありません。自然の導きにより、適度な複雑さが、神経節または真の中枢神経系のいずれかの観点から、情報処理の集中をもたらし始めます。今日のネットワークと分散アプリケーションは、このスペクトルのより複雑でない端に近いものですが、アーキテクチャにより、制御された調査が可能になります。空間。特に、このアーキテクチャがテレメトリ機能と管理機能を独立して分散しているという事実は、特に興味深いものであり、トレードオフと何が可能かを調査するための優れたツールとなっています。

従来の集中型ネットワーク管理アーキテクチャでは、NM-DMS は、管理機能を提供する 1 つ以上の DAP と、テレメトリを提供する他の DAP で構成される異種 DAF になります。管理 DAP は、ネットワーク管理内の役割やタスクを細分化したり、サブドメインの管理や相互の冗長性を提供したりできます。一般的な DMS には、イベント管理、構成管理、障害管理、リソース管理などの通常のタスクがあります。これには、焦点をボックスから分散システム モデルに移すという利点もあります。

NM-DMS DAP には、データの収集と前処理という従来のエージェントの役割機能があります。エージェントは、そのドメイン内の処理システム内のすべての IPC プロセス (および関連する DAP) の DAF 管理タスクにアクセスできます。制約はありませんが、NM-DAF には、ドメイン内の DIF または DAF を持つ各処理システムを監視するための「エージェント DAP」が 1 つある可能性があります。 NM-DMS ドメイン内の各 DAF または DIF の DAF 管理タスクは、一種の「サブエージェント」です。管理エージェントは、障害が発生した場合にその DMS または代替 DMS を探すように設計されている場合があります。 NM-DMS がそのすべての資産を管理するために最上位の DIF 上で動作する必要はなく、管理ドメイン内のすべてのリソースにアクセスするのに十分な範囲を持つ DIF 上で動作することのみが必要です。

上で述べたように、IPC プロセスは一度に 1 つの管理ドメインにのみ存在します。これは、1 つの NM-DAF だけが IPC プロセスの動作を変更できることを意味します。

同じ処理システム内で異なる DIF を担当する複数の MA が存在する可能性があり、たとえば、DIF を VPN として作成し、その「所有者」による管理を許可することができます。ネットワーク設計者は注意してください。これらの MA の要件を満たす処理システムは 1 つだけです。 1 つの MA (および管理システム) には、競合を解決したり、他の MA の機能を制限したりする権限が与えられます。

一般に、DIF の IPC プロセスは、いつでも 1 人のマネージャーによって管理されます。他のマネージャには、システムを読み取る、つまり監視する許可が与えられる場合がありますが、書き込む、つまり構成を変更することはできません。管理システムには、管理ドメインを定義し、その構成を変更するためのメカニズムが備わります。

ネットワーク管理は、「制御ではなく監視と修復」として特徴付けられます。従来の監視および修復機能は次のとおりです。

• イベント管理 (EM) – 要求されていない CDAP 書き込みが NMS に到着したときに、主に RIB デーモンによって処理されます。 EM は主に、すべてのイベントの信頼できるログと、受信した情報に他の管理アプリケーションがアクセスできるようにするサブスクリプション サービスで構成されます。
• 構成管理 (CM) – ネットワーク構成の作成、保守、アクティブ化をサポートします。ネットワークには、ピーク/オフ時間、休日、週末など、ネットワークに対して複数の構成が定義されていることがよくあります。多くの場合、構成は、ある構成を別の構成に完全に置き換えるのではなく、既存の構成に基づいて定義されます。このような場合、構成の維持期間が長くなるほど自然に発生する構成のドリフトに注意することが重要です。構成移行の開始点が互換性のない方法で移動した可能性があります。これはアクティベーションが開始される前に解決される必要があります。アクティベーションは、指示されたツリーウォークとして簡単に自動化されます。
• パフォーマンス管理 (PM) - 管理エージェントから集約データを読み取り、程度は低いですがイベント ストリームを読み取ることで、ネットワークのパフォーマンスを監視します。通常、この情報はすぐに行動を起こす必要はありません。即時応答は通常、各層の自律機能によって処理されます。通常、このデータは、ネットワークで使用されているポリシーをさらに調整するために使用されます。
• 危機管理 (CrM) - イベント ストリームに入ってくるデータの主な用途は危機管理です。イベント ストリーム データは、主にサービス拒否攻撃や、火災や洪水などのネットワーク資産に関連する物理的災害の検出と対策に使用されます。これらの状況に対してアクティブ化できる代替構成が存在する可能性があります。
• 障害管理 (FM) – 非常に小さな管理ドメイン (テスト対象の機器) を持つ 1 つ以上の個別のネットワーク管理ステーション。 FM には、特定の特性を持つトラフィック ストリームを生成するための専用ツール、デバイスの動作を観察するためのプローブなどもあります。
• Homonuculus – ネットワークの集中監視が行われるオペレーター コントロール センターをサポートするために使用されるアプリケーションのセット。おそらく管理ドメインごとにこれらが 1 つあり、相互にバックアップできるはずです。
• 調整と計画 - ネットワークの長期的かつグローバルな健全性を監視する最高レベルのネットワーク管理プレーン。パフォーマンスと障害データの分析が処理され、導入前に改善案が提案され、テストされます。

ネットワークは不確実性の低い企業であり、その状態を確実に維持するのがネットワーク管理の仕事です。

6.3 アプリケーション管理 DMS (AM-DMS)

基本的に、すべてのアプリケーション管理システムは、現状ではポイント ソリューションです。例としては、ユーティリティ管理システム (ガス、光、水道)、プロセス制御、工場オートメーションなどが挙げられます。プロセス制御は、最も未開発の領域の 1 つであるはずです。大規模な化学プラントや石油プラントの設計と建設はかなりその場限りであり、ネットワーク化はさらにその場限りです。事故を封じ込め、連鎖的な壊滅的な結果を防ぐように設計されたアーキテクチャにより、より高い安全性を導入する大きなチャンスがあります。

DIF 割り当て (およびその他の機能) が処理システムに固有のものとして説明されていない理由は、まさに AM-DMS のためです。たとえこれらが独自の DIF を管理する NM-DMS によって提供されていたとしても、独自の IPC リソースを管理する完全なパッケージを形成するような AM-DMS 製品が必要であることは容易に想像できます。

6.4 名前空間管理 DMS (NSM-DMS)

分散環境で名前空間を管理するには、名前が一義的に保たれ、効率的に解決できるように調整する必要があります。 Saltzer が^{[ 5]} で指摘しているように、名前を解決するには、「名前が与えられた特定のコンテキスト内でオブジェクトを見つける」必要があります。これには、名前空間 NS _A 名前から、その名前がバインドされているオブジェクトまたは NS _B ここで, は A と同じである可能性があり、B を (おそらく再帰的に) 解決すると、オブジェクト、つまり間接化またはエイリアシング。したがって、一部のシステム (おそらくすべて) に名前を割り当てる権限が与えられます。

小規模な分散環境の場合、この管理はかなり分散化され、名前解決は徹底的な検索によって実現できます。名前を解決した情報の場所が見つかると、今後の検索を短縮するためにローカルにキャッシュされる場合があります。分散環境が拡大するにつれて、検索時間を短縮するために、階層割り当てなどの名前自体のヒントをよく使用して、これらのキャッシュがどのようにさらに編成されるかは簡単にわかります。大規模な環境では、分散データベースは完全または部分的な複製と命名規則、つまりトポロジー構造、および検索を短縮するための検索ルールを使用して編成される場合があり、名前空間の管理がさらに必要になります。

NSM 機能は、全体または一部が DAF の機能となる場合があります。ネームスペース管理の機能は次のとおりです。

• a)要求名の解決が許可されている DAP, つまり NSM のユーザーを認証します。
• b)名前空間のサブセットの割り当て権限の委任を含め、名前に関する RIB 内のエントリ (おそらく管理責任を持つエントリのみ) を変更できる DAP を認可および認証する。
• c)名前空間からオブジェクトにバインドされていない名前を割り当てます。
• d)要求者による将来の割り当て、つまり命名権限の委任、およびその割り当て解除のために、バインドされていない名前のセットを割り当てます。
• e)リクエストを容易にするための転送テーブルを含む、NSM によって使用される複製された RIB を更新および維持するためのポリシーを実装します。
• f)命名規則と検索ルールに従って名前を解決します。
• g)リクエストの資格情報をチェックして、名前を解決できるかどうかを判断します。そして
• h) NSM またはそれを使用して作成された関数がタスクを完了できるようにする結果を返します。

この機能はスタンドアロンの DAF である場合もありますが、より一般的には、DMS 内の DAF, 目的固有の DAF, または DIF 内の DAF として発生します。 NSM 機能の最も一般的な 2 つの使用法は、DIF アロケータとフロー アロケータとしてです。

NSM の主な目的は、名前をタイムリーに解決することです。この操作の結果は、オブジェクトまたは別の名前になる可能性があります。結果が名前である場合、これは通常「間接化」と呼ばれるものであり、その結果の解決が必要になります。結果の名前は、同じ名前空間に存在する場合もあれば、異なる名前空間に存在する場合もあります。これは、別の NSM を参照することを意味します。厳密に言えば、NSM は名前のみを返すことができます。 「オブジェクトに解決する」とは、オブジェクトが存在where 処理システム内で明確な名前に解決すると解釈されます。

小規模な NSM-DAF では、サーバー機能とリポジトリ機能を組み合わせることができます。クエリを処理するサーバーと割り当てを処理するサーバーの区別には、最小限、アクセス制御権限の違い、または個別のサブ DAF など、いくつかの形式があります。 NSM は共生 DAF であることが多いため、セキュリティ要件に応じて、実装ではその機能 (RIB など) をホスト DAF に統合する場合があります。

リポジトリ DAP は、効率的な名前解決を維持するために必要な RIB の配布とレプリケーションを管理します。割り当て DAP は、ほとんどの場合、別の DMS の機能になります。ほとんどの場合、名前空間の側面を管理する権限は、任意のアプリケーションではなく DMS 機能に与えられることに注意してください。これには間違いなく例外がありますが、このようにモデル化すると、単にそのような退化したケースが作成されるだけです。

割り当て DAP は、名前空間のサブセットをその管理下で NSM に委任することを要求することもできます。これらは、名前空間の子 NSM 全体を構成できます。明らかに、親 NSM が名前空間のサブセット、たとえば名前付けツリーのブランチの名前付け権限を委任するwhere 、この構造は子またはサブ NSM-DAF として全体または部分的に繰り返される可能性があります。 NSM の親子関係には、配布と複製を子内でのみ行う必要があるという要件はありませんが、親、祖父母、およびその他の子が含まれる場合があります。

ネームスペース管理機能は、特定のネームスペース関連サービスを構築するために使用されます。これは、必要に応じて、他の管理 DAF または特定のアプリケーション DAF または DIF に組み込まれます。他の場所で説明されているように、フロー アロケーターは DIF 内で NSM を使用します。 NSM 機能を使用して、分散データベースまたはフェデレーテッド データベースのデータ ディクショナリを作成できます。

6.5 DIF アロケータ

6.5.1 一般

NSM の主な用途は、DIF アロケーター (DA) の構築です。 DIF アロケータは、IPC 境界で、アプリケーションが名前によって宛先にリソースを割り当てることを要求するだけであるという特性から自然に生じます。要求側アプリケーションは、要求された宛先アプリケーションがwhere あるかを知る必要はありません。 IPC モデルを分散ケースに拡張する段階で、N 個のシステムが直接接続されているケースを考慮すると、この特性を維持するための機能が必要になります。これは IPC の一部ですが、どの「ワイヤ」 (どの DIF) を使用するかを決定するのは DIF の外にあります。第 4 項では、これは IPC リソース管理 (IRM) でした。

アプリケーションが AP 名を使用して割り当てリクエストを IRM に送信すると、IRM は、このアプリケーションが利用可能な DIF のいずれかでアプリケーションに到達可能かどうかを判断し、到達可能であれば 1 つが選択され、割り当ては通常どおり処理されます。

ただし、目的のアプリケーションが利用可能な DIF のいずれにもない場合、この関数がピア IRM にクエリを実行するのは完全に合理的であり、ピア IRM には他のアプリケーションとは異なる DIF が存在する可能性があります。見つかった場合は、新しい DIF を作成して通信を可能にすることができます。この関数は DIF アロケータと呼ばれます。これは一連の DIF にまたがる場合があり、次の 2 つの主要な機能があります。

• a)要求された DIF または DAF をサポートする、この IRM では利用できない DIF を検索します。
• b)既存の DIF を結合するか、新しい DIF を作成して、要求されたアプリケーションと要求側のアプリケーションの両方が IPC を割り当てられるように、DIF を利用できるようにします。これには、DIF アロケータが DIF の作成を調整 (またはネゴシエート) する必要がある場合があります。

DA はピア DA と通信し、新しい「トップレベル」DIF を作成する手段を見つけようとします。作成されると、Allocate リクエストは通常​​どおり処理されます。 DA がその機能を実行するには、名前空間管理のインスタンスを使用する必要があります。名前は DAF または DIF の場合があることに注意してください。後者の場合、IRM は指定された DIF への参加を試みます。 DIF アロケータは「新しい DIF のファインダー」です。 DIF アロケータは、スタンドアロン DAF, DMS に埋め込まれた DAF, または DIF 内にある場合があります。

これは事実上、ネットワーク ジェネレーター機能です。ネットワークは外部のアドホックな手段によって構築できますが、DIF アロケーターは、ユーザーの要求に基づいて有機的にネットワークを再帰的に構築する手段を提供します。繰り返しますが、RINA モデルは非常に便利であるように見えますし、非常に便利である可能性がありますが、RINA モデルは単一の権威ある DIF-Allocator に対する要件を課していませんし、課す手段もありません。また、このモデルは、唯一の DIF-Allocator が存在することを想定していません。 1つ。

6.5.2 DIF アロケータ構造体

すべてのアプリケーションの IRM が DIF アロケーターのメンバーである場合、スケーリングに大きな問題が発生する可能性があります。ただし、すべての DAP またはアプリケーション プロセスが一度に DIF-Allocator サービスを必要とする可能性がある一方、この問題を軽減する制約を課す要因が他にもあることを認識することが重要です。

• a)一般的なネットワークでは、少数の IRM だけが多様な DIF を利用できます。つまり、ほとんどの IRM は 1 つの DIF のみを使用するか、同じ DIF にアクセスできます。
• b)すべてのアプリケーションが名前を登録する権限を持っているわけではありません。
• c)すべてのアプリケーションが新しい DIF にリソースを割り当てる権限を持っているわけではありません。

これらの最後の 2 つの機能は、オペレーティング システム DM, NM-DMS, またはアプリケーション DMS に割り当てられる可能性が高くなります。この仮定を採用することにより、例外を縮退ケースとして受け入れることができます。したがって、大多数の IRM は DA サービスのみを要求します。これは、驚くことではないが名前空間管理の構造を模倣する DIF-Allocator DAF の構造を意味します。

IPC リソース管理 (IRM) が IPC リソースを名前に割り当てるように要求され、アクセスできる DIF 上で要求されたアプリケーションが見つからない場合、クライアント ユーザーとして DIF アロケーターから新しい DIF を要求します (IRM と同様) NSM クエリ DAP)その後、DA は、アプリケーションをサポートする DIF の検索と、基礎となるリソースを担当する介在 DMS とのネゴシエーションを管理して、新しい DIF を割り当てるか、既存の DIF に参加するか、あるいはその両方を行い、要求側と要求側の両方が利用できる単一の DIF が存在するようにします。要求されたアプリケーションは IPC に使用できます。

DIF アロケータは、NSM を組み込んだ DAF であり、NSM と同様の構造を持っています。 DIF アロケータは隣接する DIF 上にないアプリケーションを検索するため。 DIF-Allocator DAP (DA-DAP) は、要求と応答を処理できるwhere に中継する必要があります。これは、転送テーブルのセットが 2 つあることを意味します。

• 名前解決要求を次のリポジトリ DA-r-DAP に転送するための転送テーブル FT-検索ルールに従って、次の NSM-r-DAP は必ずしも 1 ホップ離れているわけではないためです。
• 転送テーブル。宛先 DA-DAP が 1 ホップ離れていない場合、FT-n は NSM-r-DAP 間の 1 つ以上の DA-DAP を介して PDU を転送する必要があります。

したがって、DA-DAF 内には重要な 2 つの異なるグラフがあります。1 つは検索ルールとリポジトリのキャッシュ戦略によって定義されたグラフ、もう 1 つは DA-DAP の接続性のグラフです。 FT は、リポジトリをフラット、リング、階層、またはその他の構造に編成できます。 FT-n によって暗示されるグラフは、送信者から宛先への PDU の転送を容易にする、つまり従来のルーティングに近づけるために別個の同義語のセットを使用する場合があります。

DA-DAF のコンポーネントは NSM のコンポーネントとよく似ています。ほとんどのアプリケーションの IRM は、DIF アロケーターから新しい DIF を要求し、使用するために DIF を作成することしかできません。ほとんどの場合、アプリケーションが存在するドメインを担当する DMS が、登録関連の機能をすべて実行します。登録プロセスにより、アプリケーションの名前とそれらをサポートする DIF が、さまざまなプロパティとともに DA-DAF で使用できるようになります。

一部の DAP は、名前解決のための分散データベースの維持に特化している場合があります。これらの DAP が直接接続されている必要はありません。 FT-s 転送テーブルは検索の接続性を定義しますが、FT-n は次の検索場所に到達するために仲介者を介して PDU を転送する必要がある場合があります。

さまざまな機能がすべての DAP に必要なわけではなく、これらの機能の一部は外部機能を内部動作から分離するために使用される場合があります。クエリおよび登録サーバー機能をサポートする DAP は、ローカル キャッシュが存在する可能性があることを示すために完了したものとして示されています。環境によっては、機能を組み合わせても要件を満たすことを選択する場合があります。

この説明ではアプリケーションについて言及しましたが、DIF アロケータは DAF だけでなく DIF も見つけるために使用できます。また、この説明では DIF が常に作成されることを暗示していますが、そうでない場合もあります。場合によっては、DA-DAF は、IPC プロセスに既存の DIF に参加するように指示することで、必要な「最上位層」を作成できる場合があります。

6.5.3 操作

DA は、アプリケーションのペアの DIF を作成するように要求されると、まず目的の DAF を見つける必要があります。フロー割り当て要求は、DIF が提供するパラメータで強化されます。これらは、適切な DMS によって提供されるか、利用可能な DIF のパラメーターおよび DMS が DIF 作成に関して持つポリシーから派生します。 IRM は、サポートするアプリケーション名と QoS キューブではなく QoS パラメータの範囲 (許容値) を指定して DIF の作成を要求します。これは、共通の名前空間管理機能を使用した従来の検索として始まります。これには、次のリポジトリに到達するために多数の DAP を介してリクエストを中継する必要がある場合がありますが、アプリケーションをサポートする DIF が見つかると、DA はその DMS および新しい DIF をサポートするために必要な DIF の DMS とネゴシエートするか、直接交渉します。システムを既存の DIF に参加させます。

DNS やリクエスタなどの機能とは異なり、サポートする DIF にアクセスできます。これにより、アプリケーションが存在するかどうかを返すことにより、アプリケーションのセキュリティが損なわれないことも保証されます。要求元のアプリケーションの資格情報がアクセスを許可しない場合は、「見つかりません」が返されます。検索が成功したら、次のステップは、少なくとも要求元のアプリケーションと要求されたアプリケーションをサポートする DIF を作成することです。これは、既存の DIF を結合するか、新しい DIF を作成するか、あるいは DIF の作成と結合を組み合わせることによって実行できます。

既存の DIF に参加するため、または新しい DIF のメンバーとなるための IPC プロセスを作成するには、大量のリソースの割り当てとそのための権限が必要であることを考慮すると、DA-DAF は AM, NM, およびオペレーティング プロセスと連携して仲介者として機能します。システム DAF は、既存の DIF を拡張したり、新しい DIF を作成したりするための適切なリソースを担当します。 DA-DAF は、適切な管理 DAF に特定の処理システムで IPC プロセスを作成するよう要求し、DIF に参加するように指示します。明らかに、Create-DIF リクエストには新しい DIF のパラメータを含める必要があります。これには、サポートされる QoS キューブ、DIF グラフの最小平均次数、コストなどのパラメータが含まれる場合があります (ただしこれらに限定されません)新しい DIF が作成されると、DIF アロケーターは要求元の IRM に応答を返し、IRM は割り当て要求を続行できます。 DIF アロケータは、新しい DIF を IRM に自発的に通知することもあります。

単一の管理ドメイン内で DIF を作成すると、異なる管理ドメインとのネゴシエーションの考慮事項がスキップされ、新しい DIF の管理ドメイン内での IPC プロセスの作成に直接進みます。

さまざまなプロパティを持つ DIF を作成するアルゴリズムは、今後しばらく研究のテーマとなるでしょう。特に興味深いのは、平均次数が 2 を超える DIF を作成するアルゴリズムです。ただし、単純なケースも考えられます。新しい DIF を作成する場合、既存の上位 DIF のボーダー ルーターに新しい IPC プロセスを作成する必要があります。取るべき明らかなアプローチは次のとおりです。

• 要求されたアプリケーションを持つ DIF B を見つけた DIF アロケーターは、DIF B を (N-1)-DIF として使用してアプリケーションをサポートする処理システム上に IPC プロセスを作成します。その後、DA は応答を送り返し、DIF 作成応答のリターン パスに沿ってボーダー ルーターで IPC プロセスを作成します。
• 要求されたアプリケーションの DIF を見つけた DIF アロケーター DAP は、その RIB を参照して、新しい DIF に含まれるノードのセットを構築します。新しい DIF のシードとして機能する新しい IPC プロセスを作成します。次に、新しい DIF に参加するための指示を含む Create IPC-Process コマンドをセット内の各ノードに送信します。

null の場合やブートストラップの場合ここで, 処理システムが最初の DIF に参加しています。考慮すべきケースは 3 つあります。

• a) Shim DIF の使用: 既存のレガシー メディア プロトコルに対して、RINA は Shim DIF を採用します。 Shim DIF は、既存のメディア標準に、このメディアのプロパティを持つ DIF と同じ API 動作を持たせるために必要な最小限の機能を提供します。 Shim DIF は、既存のメディア プロトコルを「拡張」しようとはしません。この場合、登録は従来のプロトコルの手順に従います。通常の DIF 操作はそれ以上で機能します。
• b)ポイントツーポイント メディア上で直接動作する DIF: この場合、何らかのアドホックな最初の PDU があるか、またはポイントツーポイント メディアの端、つまりワイヤ上のプロセスが存在すると想定されます。 RINA の入学手続きを待っています。これは、M-Connect とも呼ばれる CACE-Connect から始まります。これらの条件を考慮すると、通常の登録で手順を進めることができます。
• c)マルチアクセスメディア上で直接動作する DIF: この場合、メディアのもう一方の「端」の通信相手を区別するために、機器のシリアル番号などの一意の識別子が利用可能であると想定されます。アドホックの最初の PDU がこの情報を伝送するか、「他端」がこの「一意の識別子」を宛先アプリケーション名として持つ CACE-Connect PDU を期待します。ソース アプリケーション名も、メディアの範囲内で一意であることがわかっている必要があります。ソース固有の識別子は、DIF への参加を要求している IPC プロセスを識別します。宛先の一意の識別子は、参加している DIF または DIF のメンバーである IPC プロセスのいずれかを指定できます。

この交換を使用して、メディア上に DIF を作成することも、この DIF 内のアドレスの割り当てなどの通常の手順を使用して既存の DIF に参加することもできます。ただし、同じメディア上およびメディアの範囲内で異なる DIF 間のトラフィックを区別するには、引き続き「一意の識別子」が必要になります。実際、マルチアクセス メディア自体には非常に最小限の Shim DIF が存在します。

参考文献

6.2 Network Management DMS (NM-DMS)

While the IPC-Processes that comprise the DIF are exchanging information on their operation and the conditions they observe, it is generally necessary to also have an outside window into the operation of DIFs comprising the network. While the members may reach a local optimization, it is often more complex to discover global optimizations without an “outside” perspective.

In these systems, control shall be automatic. Events are happening far too fast and state is changing too rapidly for a centralized system to be effective. Furthermore, the nature of distributed systems always opens the possibility for partitioning. Hence, it should be possible for distributed systems to fail-safe without central control. The purpose of Management is to monitor and repair, not to control.

A NM-DMS will perform the traditional functions of monitor and repair, e.g. deploying new configurations and monitoring performance. The DAF model can be applied to network management to represent the whole range from distributed (autonomic) to centralized (traditional). Both are required. As noted, experience with distributed algorithms has shown an ability to find local optima, but not always global optima. If nature guides, modest complexity begins to lead to concentrations of information processing, either in terms of ganglia or a true central nervous system. While today’s networks and distributed applications are closer to the less complex end of this spectrum, the architecture allows controlled investigation of the space. In particular, the fact that this architecture distributes the telemetry and management functions independently, makes it especially interesting and an excellent tool for investigating the trade-offs and what is possible.

In the traditional centralized network management architecture, an NM-DMS would be a heterogeneous DAF consisting of one or more DAPs providing management functions, with other DAPs providing telemetry. The management DAPs can be subdividing roles or tasks within network management or providing management for sub-domains and redundancy for each other. A typical DMS has the usual tasks of event management, configuration management, fault management, resource management, etc. This also has the advantage of shifting the focus away from boxes to a distributed system model.

The NM-DMS DAPs has the traditional agent role function of collecting and pre-processing data. The Agent will have access to the DAF Management task of all IPC-Processes (and associated DAPs) in the processing systems that are in its domain. While there is no constraint, it is likely that an NM-DAF would have one “Agent DAP” for monitoring in each processing system with a DIF or DAF in its domain. The DAF Management task of each DAF or DIF in the NM-DMS domain is a kind of “sub-agent.” A Management Agent may be designed to seek out its DMS or alternate DMSs in the event of failures. There is no requirement that the NM-DMS shall operate over the topmost DIF in order to manage all of its assets, only that it operates over a DIF with sufficient scope to access all resources in its management domain.

As noted above, IPC-Processes are in one and only one management domain at a time. This means that only one NM-DAF has the ability to modify the behaviour of the IPC-Process.

It is possible for there to be multiple MAs responsible for different DIFs in the same processing system. For example, DIFs can be created as VPNs and can be allowedto be managed by their “owners”. The network designer shall be careful. There is only one processing system to meet the requirements of these MAs. One MA (and management system) shall be empowered to resolve conflicts or to bound the capabilities of other MAs.

In general, an IPC-Process in a DIF can be managed by one and only one manager at any particular time. Other managers may be given permission to read, i.e. observe, the system but not write to it, i.e. change configuration. Management systems will have mechanisms for defining management domains and changing their composition.

Network Management is characterized as “Monitor and Repair, but not Control”. The traditional monitor and repair functions are:

• Event Management (EM) – primarily handled by the RIB Daemon when unsolicited CDAP Writes arrive at the NMS. EM consists primarily of the authoritative log of all events and a subscription service that allows other management applications access to the information as it arrives.
• Configuration Management (CM) – supports the creation, maintenance, and activation of network configurations. Networks often have multiple configurations defined for a network, e.g. peak/off hour, holiday or weekend. Configurations will be often defined based on an existing configuration, rather than wholesale replacement of one configuration with another. In these cases, it is important to be aware of configuration-drift which naturally occurs the longer a configuration is in place. The starting point of a configuration transition may have moved in an incompatible way. This shall be resolved before activation begins. Activation is easily automated as a directed tree-walk.
• Performance Management (PM) - monitors the performance of the network by reading aggregated data from Management Agents and to a lesser degree the event stream. This information is generally not for immediate action. Immediate response is generally handled by the autonomic functions in the layers. Normally this data is used to further refine the policies being used by the network.
• Crisis Management (CrM) - primary use of the data coming in the event stream is for crisis management. The event stream data will be used primarily for detecting and countering denial of service attacks, as well as physical disaster associated with network assets, e.g. fire, flood. There can be alternate configurations for these situations that can be activated.
• Fault Management (FM) – one or more distinct Network Management Stations with very small management domains, i.e. the equipment being tested. FM also has specialized tools for generating traffic streams with given characteristics, probes for observing device behaviour, etc.
• Homonuculus – the set of applications used to support the operator control centre from which the central monitoring of the network is done. There is probably one of these per management domain and they should be able to back each other up.
• Coordination and Planning – the highest level of the network management planes that monitors at the long term and global health of the network. Analysis of performance and fault data is processed, and improvements proposed and tested before deployment.

The network is a low uncertainty enterprise and it is the job of network management to ensure that it stays that way.

6.3 Application Management DMS (AM-DMS)

Essentially all application management systems, such as they are, are point solutions. Examples include, e.g. utility management systems (gas, light and water), process control, factory automation. Process control should be one of the most untapped areas. The design and construction of large chemical or petroleum plants is fairly ad-hoc and the networking even more so. There is a major opportunity to introduce greater safety with architectures designed to contain accidents and prevent cascading catastrophic results.

The reason the DIF Allocation (and other functions) are not described as being unique to a processing system is precisely for AM-DMSs. It is easy to imagine the need to have an AM-DMS product such that it formed a complete package that managed its own IPC resources, even though these were provided by a NM-DMS managing its own DIFs.

6.4 Name Space Management DMS (NSM-DMS)

Management of a name space in a distributed environment requires coordination to ensure that the names remain unambiguous and can be resolved efficiently. Resolving a name as Saltzer noted in^[5], requires “locating an object in a given context given its name.” This requires a mapping from a name in name space, NS_A either to the object the name is bound to or to a name in NS_B ここで, B may be the same as A, such that resolving B (perhaps recursively) yields an object, i.e. indirection or aliasing. Hence, some systems (perhaps all) shall be given the authority to assign names.

For small, distributed environments, this management can be fairly decentralized and name resolution can be achieved by exhaustive search. Once found, the location of the information that resolved the name may be cached locally in order to shorten future searches. It is easy to see how, as the distributed environment grows, these caches would be further organized often using hints in the name itself, such as hierarchical assignment, to shorten search times. For larger environments, distributed databases may be organized with full or partial replication and naming conventions, i.e. topological structure, and search rules to shorten the search, requiring more management of the name space.

The NSM functionality can be in whole or in part, a function of any DAF. The functions of Name-Space Management are the following:

• a) authenticate DAPs that are allowed request names to be resolved, i.e. users of NSM;
• b) authorize and authenticate DAPs that are allowed to modify entries in the RIB about names (presumably only those for which it has management responsibility), including delegating authority for assignment of subsets of the name space;
• c) assign an unbound name from the Name Space to an object;
• d) assign an unbound set of names for future assignment by the requestor, i.e. delegation of naming authority, as well as its de-assignment;
• e) implement policies for updating and maintaining the replicated RIB used by NSM, including the forwarding tables for facilitating requests;
• f) resolve names by following the naming conventions and search rules;
• g) check credentials of requests to determine if the name can be resolved; and
• h) return a result that allows the NSM or the function created using it to complete its task.

This function may be a stand-alone DAF but more commonly will occur as a DAF within a DMS, a purpose specific DAF, or in a DIF. The two most common uses of the NSM functionality are as the DIF Allocator and the Flow-Allocator.

The primary purpose of an NSM is to resolve names in a timely manner. The result of this operation may be either an object, or another name. When the result is a name, this is what is normally called “indirection” and will require resolution of that result. The resulting name may be in the same name space or a different name space, which would mean consulting a different NSM. Strictly speaking, the NSM can only return a name. “Resolving to an object” shall be interpreted as resolving to a name that is unambiguous within the processing system where the object resides.

In smaller NSM-DAFs, the Server and Repository functions may be combined. The distinction between Servers that handle Query and Servers that handle Assignment may take several forms: minimal, differences in access control permissions, or distinct sub-DAFs. Because NSMs are often symbiotic DAFs, depending on the security requirements, implementations may integrate their functionality, e.g. RIB, into the host DAF.

Repository DAPs manage the distribution and replication of the RIB required to maintain efficient name resolution. Assignment-DAPs will, in most cases, be a function of another DMS. It is worth noting that in most cases the authority to manage aspects of a name space will not be given to arbitrary Applications but to DMS functions. There will undoubtedly be exceptions to this, however, modelling it this way will simply make those degenerate cases.

An Assignment DAP may also request to have a subset of the name space delegated to an NSM under its management. These can constitute entire child NSM of the name space. Clearly, in the case where a parent NSM delegates a naming authority for a subset of the namespace, e.g. a branch of the naming tree, this structure may be repeated in whole or in part as a child or sub-NSM-DAF. There is no requirement in the parent/child relation of NSMs that requires distribution and replication be limited to occurring within the child but may include parents and grandparents and other children.

The Name Space Management functionality is used to build specific namespace related services. It is incorporated into other Management DAFs or specific applications DAFs or DIFs as required. As described elsewhere, the Flow-Allocator is a use of NSM within a DIF. The NSM functionality can be used to create the Data Dictionary for a distributed or federated database.

6.5 DIF allocator

6.5.1 General

A major application of NSMs is the construction of a DIF-Allocator (DA). The DIF-Allocator arises naturally from the property, that at the IPC boundary, an Application merely requests that resources be allocated with the Destination by name. The Requesting Application does not need to know where the Requested Destination Application is. At the step in extending the IPC Model to the distributed case, when the case of N systems directly connected is considered, a function is required to maintain this property. While it is part of IPC, it is outside the DIFs to determine which “wire” (which DIF) to use. In Clause 4, this was IPC Resource management (IRM).

When an Application submits an Allocate Request to the IRM with an AP-Name, the IRM determines if the application is reachable on any of the DIFs available to this application and if so, one is selected and the Allocate is processed normally.

But if the desired application is not on one of the available DIFs, it is perfectly reasonable that this function queries its peer IRMs, which may have different DIFs with other applications on them. If it is found, then a new DIF can be created to enable the communication. This function is called the DIF-Allocator. It may span a set of DIFs and has two major functions:

• a) to find the DIF that supports the requested DIFs or DAFs, that is not available to this IRM;
• b) to make available a DIF by either joining existing DIFs or creating new DIFs such that both the requested and requesting Applications can allocate IPC. This can require the DIF Allocator to moderate (or negotiate) the creation of DIFs.

The DA communicates with its peer DAs and attempts to find the means to create a new “top level” DIF. Once it is created, the Allocate request is handled normally. For the DA to perform its function it shall use an instance of Name Space Management. Note that the name may be of a DAF or a DIF. In the latter case the IRM would attempt to join the named DIF. The DIF-Allocator is a ‘finder of new DIFs.’ A DIF-Allocator may be a stand-alone DAF, one embedded in a DMS, or within a DIF.

This is, in effect, the network generator function. While networks can be constructed by external ad hoc means, the DIF-Allocator provides the means for the recursive construction of networks organically based on user demand. Again, while it can appear to be, and it can be, quite useful, the RINA Model does not impose a requirement for a single authoritative DIF-Allocator, nor is there any means to impose one, nor does this model assume there is only one.

6.5.2 DIF allocator structure

If the IRM of every application were a member of a DIF-Allocator this can create a huge scaling problem. However, it is important to recognize that while every DAP or application process can need DIF-Allocator services at one time or another, there are other factors that impose constraints that mitigate this problem:

• a) in a typical network, only a few IRMs will have a diversity of DIFs available to it, i.e. most IRMs will have to only one DIF or have access to the same DIFs;
• b) not every application would have the permissions to register names;
• c) not every application would have the permissions to allocate the resources for a new DIF.

These last two capabilities would more likely be assigned to Operating System DMSs (outside of the scope of this document), NM-DMSs, or Application-DMSs. By adopting this assumption, exceptions can be accommodated as degenerate cases. Thus, the vast majority of IRMs will only request DA services. This implies a structure for the DIF-Allocator DAF that not surprisingly mimics the structure of Name Space Management.

When the IPC Resource management (IRM) is requested to allocate IPC resources to a name, and it fails to find the requested application on any DIF it has access to, it will request a new DIF from DIF Allocator as a Client user (similar to the NSM Query-DAP). The DA will then manage finding a DIF that supports the application and the negotiations with the intervening DMSs with responsibility for the underlying resources to either allocate a new DIF or to join existing DIFs or both such that there is a single DIF that both the requesting and requested applications can use for IPC.

A DIF-Allocator is a DAF that incorporates an NSM and has a similar structure to an NSM. Since DIF-Allocator shall find applications that are not on adjacent DIFs. The DIF-Allocator DAPs (DA-DAPs) will need to relay requests and responses to where they can be processed. This implies that there are two sets of forwarding tables:

• a forwarding table, FT-s, for a name resolution request to forward to the next repositories, DA-r-DAPs, according to the search rules, and because the next NSM-r-DAP is not necessarily one hop away;
• a forwarding table, FT-n is required to forward PDUs through one or more of the DA-DAPs between the NSM-r-DAPs when the destination DA-DAPs aren’t one hop away.

Thus, there are two different graphs within the DA-DAF that are important: the graph defined by the search rules and the caching strategy of the repositories, and the graph of the connectivity of the DA-DAPs. The FT-s may organize the repositories into a flat, ring, hierarchical, or other structure. The graph implied by the FT-n may use a separate set of synonyms to facilitate forwarding PDUs from sender to destination, i.e. closer to traditional routing.

The components of the DA-DAF are much as they are in the NSM. The IRM of most applications will only be able to request a new DIF from the DIF-Allocator and have a DIF created for their use. In most cases, the DMS responsible for the domain in which Applications exist will perform all registration related functions. The registration process makes the names of applications and their supporting DIFs along with various properties available to the DA-DAF.

Some DAPs may be dedicated to maintaining the distributed database for resolving names. There is no requirement that these DAPs are directly connected. The FT-s forwarding tables define the connectivity of the search, but the FT-n may be required to forward PDUs through intermediaries to get to the next place to search.

The various functions are not all required in all DAPs and some of these may be used for isolating external functions from internal operation. The DAPs supporting Query and Registration Server functions are shown as complete to indicate that local caching may be present. Some environments may choose to combine functions and still meet their requirement.

While this description has referred to applications, the DIF-Allocator may be used to find DIFs as well as DAFs. Also, while this description implies that DIFs are always created, they may not be. In some cases, the DA-DAF may be able to create the necessary “top layer” by instructing IPC-Processes to join an existing DIF.

6.5.3 Operations

When the DA is requested to create a DIF for a pair of applications, it first has to find the desired DAF. The flow allocation request will be augmented with parameters that a DIF shall provide. These will either be provided by the appropriate DMS or derived from the parameters of the available DIFs as well as the policies the DMS has on DIF creation. The IRM requests a Create DIF specifying the application name that it shall support and the ranges (tolerance) of QoS parameters, not the QoS-cubes. This begins as a traditional search using the common Name Space Management functions. Although this can require relaying the request through a number of DAPs to get to the next Repository, once a DIF is found that supports the application, the DA shall negotiate with its DMS and the DMSs of any DIFs required to support a new DIF or direct systems to join an existing DIF.

Unlike functions such as DNS or X.500, a DA-DAF search is concluded only when the management domain responsible for the requested application or DIF is found, i.e. the search terminates when the credentials of the requesting Application can be checked to determine if the requestor has access to the supporting DIF. This also ensures that the security of the application is not compromised, by returning whether or not the application exists. If the requesting application’s credentials do not allow access, “not found” is returned. Once a successful search is concluded, the next step is to create a DIF that supports at least the requesting and requested applications. This may be done either by joining existing DIFs or by creating a new DIF or by some combination of creating and joining DIFs.

Given that creating IPC-Processes to join existing DIFs or to be members of new DIFs requires the allocation of significant resources and the permissions to do so, the DA-DAF will act as the mediator in conjunction with the AM-, NM- and Operating System-DAFs responsible for appropriate resources to extend existing DIFs or to create new ones. The DA-DAF will request the appropriate Management DAF to create of IPC-Processes in specific processing systems and instruct them to join a DIF. Clearly, the Create-DIF request will have to include parameters for the new DIF. This may involve parameters such as (but not limited to): QoS-cubes supported, minimum average degree of the DIF graph, cost. When the new DIF is created, the DIF-Allocator will return a response to the requesting IRM, which may proceed with its Allocate Request. The DIF-Allocator may also spontaneously notify the IRM of a new DIF.

Creating a DIF within a single Management Domain simply skips the considerations of negotiating with different management domains and goes straight to creating the IPC-Processes within the Management Domain for the new DIF.

Algorithms for creating DIFs with various properties will be a topic of research for some time to come. Of special interest will be algorithms for creating DIFs with average degrees greater than two. However, the straightforward cases can be considered. In creating a new DIF, a new IPC-Process will need to be created at Border Routers of the existing top rank DIFs. The following are obvious approaches to be taken:

• The DIF-Allocator having found a DIF, B, with the requested Application, creates an IPC-Process on the processing system that supports the application using the DIF B as the (N-1)-DIF. The DA then sends a response back, creating an IPC-Processes at the Border Routers along the return path of the Create DIF Response.
• The DIF-Allocator DAP, which found the DIF with the requested application, consults its RIB and constructs a set of nodes to be in the new DIF. It creates a new IPC-Process to serve as the seed for the new DIF. It then sends Create IPC-Process commands to each node in the set with instructions to join the New DIF.

There is also the null case or bootstrap case ここで, a processing system is joining its first DIF. There are three cases to be considered:

• a) The use of a Shim DIF: For existing legacy media protocols, RINA employs a Shim DIF. A Shim DIF provides the minimal functionality necessary to make an existing media standard have the same API behaviour as a DIF with the properties of this media. A Shim DIF makes no attempt to “enhance” the existing media protocol. In this case, enrolment will follow the procedures of the legacy protocol. Normal DIF operations will work above that.
• b) A DIF operating directly on point-to-point media: In this case, it is assumed that there is either some ad hoc first PDU or that the process on the end of the point-to-point media, i.e. a wire, is expecting a RINA enrolment procedure. This will begin with CACE-Connect, also referred to as an M-Connect. Given these conditions the procedure can progress with normal enrolment.
• c) A DIF operating directly over a multi-access media: In this case, it is assumed that some unique identifier, e.g. an equipment serial number, is available to distinguish correspondents at the other “end” of the media. Either an ad hoc first PDU will carry this information or the “other ends” will be expecting a CACE-Connect PDU with this “unique identifier” as the Destination Application name. The Source Application name will also have to be known to be unique within the scope of the media. The source unique identifier shall identify the IPC-Process that is requesting to join the DIF. The destination unique identifier may name either the DIF being joined or an IPC-Process that is a member of the DIF.

This exchange can now be used to either create a DIF on top of the media or join an existing DIF using the normal procedures, including the assignment of addresses within this DIF. However, the “unique identifiers” will still be required to distinguish traffic between different DIFs on the same media and within the scope of the media. There is, in effect, a very minimal Shim DIF over the multi-access media itself.

Bibliography