7    RSVP アプリケーション・プログラミング・インタフェース

RSVP (ReSerVation Protocol) はネットワーク層プロトコルです。 これによって,インターネット・アプリケーションは,特定アプリケーションのデータ・ストリームまたはフロー (単向通信のユニキャストとマルチキャストのいずれも) に対して,より高いサービス品質 (QoS) を要求できます。 アプリケーションは,一般には,省略時の値である最善の配送ができない場合 (たとえば,ビデオやオーディオなど) に,RAPI (RSVP Application Programming Interface) を用いてより高い QoS を要求します。 アプリケーションが要求できる QoS のタイプは,Internet Integrated Services で定義されています。

この章の説明は,次の事項について理解していることを前提としています。

この章で説明する内容は,次のとおりです。

7.1    ネットワークのサービス品質

アプリケーションがインターネットのネットワークに要求する帯域幅は増え続けているため,ネットワークの帯域幅を増やしても一時的な解決策にしかなりません。 新しいリアルタイムのアプリケーションは,帯域幅の増大と短い待ち時間の両方を要求しています。 明らかに,ネットワーク内での帯域幅の使用を管理するメカニズムが必要になっています。

現在,最善の 配信サービスを使用する IP ネットワークでは,すでに受動的な帯域幅管理を行っています。 送信キューが満杯,すなわちネットワークのトラフィックが高くて輻輳している場合,パケットは通知なしで捨てられます。 上位レベルのプロトコルにはこのデータ損失を検出するものもありますが,検出できないものもあります。

サービス品質 (QoS) とは,一般にネットワークの帯域幅を実際に管理するという考え方に伴って用いられる熟語です。 このシナリオでは,ネットワークの要素すべて (ホスト,アプリケーション,ルータなど) とネットワークのプロトコル層すべてが協調して,ネットワーク内のエンド間のトラフィックとサービスが堅実に実行されるようにします。 リアルタイム・アプリケーション用のネットワーク帯域幅が予約され,同時に最善の配送用のトラフィックのためにも十分な帯域幅が保持されます。

7.2    ネットワークのサービス品質の構成要素

このオペレーティング・システムでのネットワークのサービス品質の主要な構成要素には,次のものがあります。

これらの構成要素は互いに協調してネットワークの QoS を提供しています。 以下の各節で,この構成要素それぞれについて説明します。

7.2.1    Traffic Control

このオペレーティング・システムでは,Traffic Control サブシステムは RFC 2211 で定義されているとおりに Controlled-Load サービスを実現しています。 このサービスでは,負荷を軽減したネットワーク・インタフェースにより,最善の配送に近い QoS のアプリケーション・データ・フローを実現しています。 Traffic Control サブシステムには,次のような構成要素があります。

Traffic Control は,イーサネットと FDDI インタフェースでサポートされています。

7.2.2    RSVP

RSVP は,RFC 2205 で定義されるネットワーク・シグナリング・プロトコルです。 これには,ローカル・システムとネットワークで帯域幅を予約するメカニズムがあります。 このオペレーティング・システムでは,RSVP は rsvpd デーモンという形で実現されています。 このデーモンは,RSVP が有効なアプリケーションとの通信を行い,RSVP メッセージを送信し,RSVP メッセージの受信と処理を行います。 rsvpd デーモンは Traffic Control サブシステムを用いて,特定のネットワーク・インタフェースに対するフローとフィルタのインストールと変更を行います。

7.2.3    RAPI

RAPI は,rsvpd デーモンとの通信のためにより高い QoS を必要とするローカル・アプリケーションを有効にします。 RAPI ルーチンを使用すると,アプリケーションはローカル・システムでリソース (帯域幅) を予約したり,ネットワークの他のノードにサービスを通知したり,その両方も行えるようになります。 このオペレーティング・システムでは,The Open Group が発行している Resource ReSerVation Protocol API (RAPI) で定義されているとおりに,RAPI を実現しています。 この技術標準を,この節と一緒にお読みください。 サポートされているルーチンのリストとその説明については,7.5 節を参照してください。

7.2.4    構成要素の相互運用

RSVP には,次のような規則があります。

アプリケーションは送信側にも受信側にもなります。

一般的なシナリオでは,リモート・ホストはローカル・アプリケーションと通信して,データの受信を依頼します。 ローカル・アプリケーションが自分をデータ送信側であると宣言した場合,次のようなイベントが発生することがあります。

  1. アプリケーションが RAPI インタフェースを通じて rsvpd との通信を開始する。

  2. アプリケーションが送信トラフィックまたはフローの特性 (帯域幅の上限と下限,遅延,ジッタなど) を rsvpd に渡す。 このような特性を,Tspec といいます。 デーモンには Adspec も渡されます。

  3. rsvpd デーモンがこの情報を含む PATH メッセージを作成し,それを Traffic Control に渡す。 rsvpd デーモンと Traffic Control との相互作用は,要求しているアプリケーションには見えません。

  4. Traffic Control が,予約に必要な帯域幅がローカル・アダプタにあるかどうかを判断する。 存在する場合には,Traffic Control はメッセージを伝送します。 ユニキャスト・アドレスにもマルチキャスト・アドレスにも伝送できます。

  5. RSVP が有効な各ルータで,Traffic Control は,直前のソース・アドレス (送信側のすぐ上流のホップ) で PATH メッセージを更新し,ノード上にある QoS 制御サービスに依存する Adspec を変更し,メッセージを下流のデスティネーションに伝送する。

  6. 受信側で,rsvpd は Tspec と Adspec を RAPI を通じて受信側アプリケーションに渡す。

上記のリストは,実行される手順を要約したものです。 手順がさらに必要になることもあります。

ローカル・アプリケーションが予約の要求を行おうとする (自分を受信側と宣言) と,次のようなイベントが発生することがあります。

  1. アプリケーションが RAPI インタフェースを通じて rsvpd デーモンとの通信を開始する。

  2. アプリケーションが,受信側が予測するトラフィック (Tspec),必要な QoS レベル (Rspec),パケットに対するトランスポート・プロトコルおよびポート番号 (filter spec) を rsvpd に渡す。 Rspec および Tspec は,フロー記述子すなわち flowspec と見なされます。

    また,Rspec はルータまたはホストでパケットのスケジューリングを制御するメカニズムとしても使用されます。 また,filter spec はパケットの分類を制御して,どの送信側のデータ・パケットが対応する QoS を受けるかを判断します。

  3. rsvpd デーモンがこの情報を含む RESV メッセージを作成し,それを Traffic Control に渡す。 rsvpd デーモンと Traffic Control との相互作用は,要求しているアプリケーションには見えません。

  4. Traffic Control が,予約に必要な帯域幅がローカル・アダプタにあるかどうかを判断する。 存在する場合には,Traffic Control は PATH メッセージ内のソース・アドレスを用いてメッセージを上流に伝送します。

  5. RSVP が有効な各ルータで,Traffic Control は,予約要求を認証し,Tspecs および Flowspec で要求された必要なリソースを割り当てる。 認証に失敗した場合や十分なリソースがない場合,ルータは受信側に RSVP エラーを返します。

  6. RSVP が有効な最後のルータで,要求が受理されると,ルータは RSVP 確認メッセージを受信側に返す。

  7. RSVP セッション・データの送信側のそれぞれで,RSVP はマージした Flowspec オブジェクトをアプリケーションに渡す。 これによって,要求の送信側とデータ・パスのプロパティを通知します。

  8. 送信側は,RSVP 予約パラメータに同意する場合は RSVP を介して予約を受諾し,個別のデータ接続を用いて受信側へのデータを送信し始める。

上記のリストは,実行される手順を要約したものです。 手順がさらに必要になることもあります。

異なる受信者からの予約がインターネット内で共有される方法の詳細は,予約スタイルという予約パラメータで制御されています。 いろいろな予約スタイルについての詳細は,RFC 2205 を参照してください。

7.3    Traffic Control

Traffic Control サブシステムは,次のタスクを実行します。

詳細は, iftcntl(8) を参照してください。 システムのトラフィック制御を有効にする際の情報については,『ネットワーク管理ガイド:接続編』を参照してください。

7.4    RSVP

RSVP は QoS を特定の IP データ・フローまたはセッションに割り当てます。 これは,マルチポイント - マルチポイントでも,ポイント - ポイントでもかまいません。 RSVP セッション は,トランスポート・プロトコル,IP デスティネーション・アドレス,デスティネーション・ポートによって定義されます。 マルチキャスト・セッションに対するデータ・パケットを受信するには,ホストは,それに対応する IP マルチキャスト・グループに属していなければなりません。 セッションには送信側が複数であることもあり,デスティネーションがマルチキャスト・アドレスであれば,受信側も複数です。

以降の節では,オペレーティング・システムの RSVP 構成要素と,rsvpd デーモンでの動作について説明します。

7.4.1    RSVP の構成要素

オペレーティング・システムの RSVP 構成要素は次のとおりです。

7.4.2    rsvpd デーモン

rsvpd デーモンは次の機能を実行します。

rsvpd は,RSVP メッセージをネットワークから受信すると,ローカルのインタフェース・データベースに対して確認を行い,認証またはプロトコル・エラーを処理します。 要求が有効であれば,rsvpd デーモンは以下の動作をします。

デーモンのオプションについての詳細は rsvpd(8) を参照してください。 rsvpd の開始と停止についての詳細は,『ネットワーク管理ガイド:接続編』 を参照してください。

7.5    RSVP アプリケーション・プログラミング・インタフェース

RAPI (RSVP Application Programming Interface) によって,アプリケーションは rsvpd デーモンとの通信を確立でき,自分をデータの受信側,データの送信側,またはその両方として宣言できます。

アプリケーションは次のものから構成されます。

以降の節では,サポートされているルーチンと,開発者が RSVP 対応のアプリケーションを作成するために実行する必要がある手順について説明します。

7.5.1    サポートされているルーチン

RAPI は次のものから構成されています。

表 7-1 には,サポートされているクライアント・ライブラリ・サービス・ルーチンと,その説明があります。 ルーチンとその構文およびパラメータについての詳細な説明は,各ルーチンのリファレンス・ページを参照してください。

表 7-1:  クライアントのライブラリ・サービス・ルーチン

ルーチン 説明
rapi_session(3) RAPI セッションをローカルに作成する。
rapi_reserve(3) セッションに対するリソースの予約を作成,変更,削除する。
rapi_sender(3) 送信側のデータ・フロー・パラメータを定義,再定義,削除する。
rapi_strerror(3) RAPI エラー・コードをエラー・メッセージ文字列にマップする。
rapi_version(3) オペレーティング・システムで使用されている RAPI のバージョン番号を返す。
rapi_release(3) RAPI セッションをクローズし,すべてのリソース予約を削除する。
rapi_dispatch(3) RAPI イベントをディスパッチする。
rapi_getfd(3) RAPI セッションに対応するファイル記述子を取得する。
rapi_event_rtn_t(3) 着信した非同期 RSVP イベントを受信するためのユーザ作成ルーチン。

RSVP 要求は,QoS のタイプを記述するオブジェクトを含んでいます。 RAPI フォーマッティング・ルーチンは,アプリケーションが RAPI オブジェクトの内容を表示できるようにします。 表 7-2 には,サポートされている RAPI フォーマッティング・ルーチンとその説明があります。 ルーチンとその構文およびパラメータについての詳細な説明は,各ルーチンのリファレンス・ページを参照してください。

表 7-2:  RAPI フォーマッティング・ルーチン

ルーチン 説明
rapi_fmt_adspec(3) 指定した RAPI Adspec を,指定アドレスおよび指定長のバッファにフォーマットする。
rapi_fmt_filtspec(3) 指定した RAPI filter spec を,指定アドレスおよび指定長のバッファにフォーマットする。
rapi_fmt_flowspec(3) 指定した RAPI flowspec を,指定アドレスおよび指定長のバッファにフォーマットする。
rapi_fmt_tspec(3) 指定した RAPI Tspec を,指定アドレスおよび指定長のバッファにフォーマットする。

RAPI オブジェクト,プロトコル動作,RAPI の戻り値についての詳細は,The Open Group が発行している Resource ReSerVation Protocol API (RAPI) Technical Standard を参照してください。

7.5.2    RAPI 対応アプリケーションの作成

UNIX アプリケーションを提供しているアプリケーション開発者として,RSVP インタフェースを実装しなければなりません。

このプロセスを,次の手順で説明します。

  1. rapi.h ヘッダ・ファイルをインクルードする。 このファイルは,アプリケーションが RAPI を使用するために必要なデータ構造体,定数,関数プロトタイプをすべて定義しています。

  2. RAPI 呼び出しをコーディングする。

    rsvpd デーモンとの通信を初期化するために RAPI を呼び出すコードを作成します。

    RSVP イベントを受信するコールバック・ルーチンを作成します。

  3. アプリケーションの実行とテストを行う。

7.5.2.1    アプリケーションのリンク

アプリケーションをコンパイルしたら,それをlibrsvp.so 共有可能ライブラリまたは librsvp.a スタティック・ライブラリのいずれかとリンクします。 このライブラリには,アプリケーションと rsvpd デーモンの間の通信を有効にするプロトコルの実現 (RAPI) が含まれています。

7.5.3    RAPI アプリケーションのデバッグ

アプリケーションのテストとデバッグを行う場合,rsvpd-d フラグを付けて実行することができます。 これにより,デーモンは強制的にエラー・メッセージとデバッグ出力を /var/rsvp/rsvpd_dbg.log ファイルに書き込みます。

また,rsvpstat を実行して,接続が行われているか,予約が守られているかを確認することもできます。 ローカル・システム上でアクティブな RSVP セッションをモニタするには,次のコマンドを入力します。

# /usr/sbin/rsvpstat

省略時,rsvpstat コマンドは,このシステムでアクティブになっているすべての RSVP セッション,送信側,受信側を表示します。 情報にはセッション番号,デスティネーション・アドレス,IP プロトコル,ポート番号,セッションに対する PATH および RESV 状態の番号が含まれます。

送信側からの実際の PATH メッセージの内容などの送信側の情報を表示するには,次のコマンドを入力します。

# /usr/sbin/rsvpstat -Sv

受信側からの実際の RESV メッセージの内容などの受信側の情報を表示するには,次のコマンドを入力します。

# /usr/sbin/rsvpstat -Rv

詳細は, rsvpstat(8) を参照してください。