RSVP (ReSerVation Protocol) はネットワーク層プロトコルです。 これによって,インターネット・アプリケーションは,特定アプリケーションのデータ・ストリームまたはフロー (単向通信のユニキャストとマルチキャストのいずれも) に対して,より高いサービス品質 (QoS) を要求できます。 アプリケーションは,一般には,省略時の値である最善の配送ができない場合 (たとえば,ビデオやオーディオなど) に,RAPI (RSVP Application Programming Interface) を用いてより高い QoS を要求します。 アプリケーションが要求できる QoS のタイプは,Internet Integrated Services で定義されています。
この章の説明は,次の事項について理解していることを前提としています。
IETF Integrated Services (RFC 1633)
RSVP プロトコル (RFC 2205)
RSVP および Integrated Services (RFC 2210)
Controlled-Load Service (RFC 2211)
C プログラミング言語
この章で説明する内容は,次のとおりです。
ネットワークのサービス品質の概要
ネットワークの QoS 構成要素についての説明
RSVP アプリケーション・プログラミング・インタフェース (RAPI) ルーチンについての説明
アプリケーションがインターネットのネットワークに要求する帯域幅は増え続けているため,ネットワークの帯域幅を増やしても一時的な解決策にしかなりません。 新しいリアルタイムのアプリケーションは,帯域幅の増大と短い待ち時間の両方を要求しています。 明らかに,ネットワーク内での帯域幅の使用を管理するメカニズムが必要になっています。
現在,最善の 配信サービスを使用する IP ネットワークでは,すでに受動的な帯域幅管理を行っています。 送信キューが満杯,すなわちネットワークのトラフィックが高くて輻輳している場合,パケットは通知なしで捨てられます。 上位レベルのプロトコルにはこのデータ損失を検出するものもありますが,検出できないものもあります。
サービス品質 (QoS) とは,一般にネットワークの帯域幅を実際に管理するという考え方に伴って用いられる熟語です。
このシナリオでは,ネットワークの要素すべて (ホスト,アプリケーション,ルータなど) とネットワークのプロトコル層すべてが協調して,ネットワーク内のエンド間のトラフィックとサービスが堅実に実行されるようにします。
リアルタイム・アプリケーション用のネットワーク帯域幅が予約され,同時に最善の配送用のトラフィックのためにも十分な帯域幅が保持されます。
7.2 ネットワークのサービス品質の構成要素
このオペレーティング・システムでのネットワークのサービス品質の主要な構成要素には,次のものがあります。
Traffic Control
RSVP
RAPI
これらの構成要素は互いに協調してネットワークの QoS を提供しています。
以下の各節で,この構成要素それぞれについて説明します。
7.2.1 Traffic Control
このオペレーティング・システムでは,Traffic Control サブシステムは RFC 2211 で定義されているとおりに Controlled-Load サービスを実現しています。 このサービスでは,負荷を軽減したネットワーク・インタフェースにより,最善の配送に近い QoS のアプリケーション・データ・フローを実現しています。 Traffic Control サブシステムには,次のような構成要素があります。
Admission control -- ローカルのシステム・インタフェースに要求された帯域幅があり,フローとフィルタをインストールしていることを確認します。
Packet classifier -- 出力 IP ヘッダとインストールしたフィルタを照合します。
Packet rate enforcer -- 各出力フローが,合意した境界内にあることを保証します。
iftcntl
ユーティリティ --
手動でフローを設定し,存在しているフローとフィルタを表示します。
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 構成要素の相互運用
送信側 (またはデータ・ソース) -- IP ソース・アドレスおよびソース・ポートにより定義。
受信側 -- トランスポート・プロトコル,IP デスティネーション・アドレス,デスティネーション・ポートにより定義。
アプリケーションは送信側にも受信側にもなります。
一般的なシナリオでは,リモート・ホストはローカル・アプリケーションと通信して,データの受信を依頼します。 ローカル・アプリケーションが自分をデータ送信側であると宣言した場合,次のようなイベントが発生することがあります。
アプリケーションが RAPI インタフェースを通じて
rsvpd
との通信を開始する。
アプリケーションが送信トラフィックまたはフローの特性 (帯域幅の上限と下限,遅延,ジッタなど) を
rsvpd
に渡す。
このような特性を,Tspec
といいます。
デーモンには Adspec も渡されます。
rsvpd
デーモンがこの情報を含む PATH メッセージを作成し,それを Traffic Control に渡す。
rsvpd
デーモンと Traffic Control との相互作用は,要求しているアプリケーションには見えません。
Traffic Control が,予約に必要な帯域幅がローカル・アダプタにあるかどうかを判断する。 存在する場合には,Traffic Control はメッセージを伝送します。 ユニキャスト・アドレスにもマルチキャスト・アドレスにも伝送できます。
RSVP が有効な各ルータで,Traffic Control は,直前のソース・アドレス (送信側のすぐ上流のホップ) で PATH メッセージを更新し,ノード上にある QoS 制御サービスに依存する Adspec を変更し,メッセージを下流のデスティネーションに伝送する。
受信側で,rsvpd
は Tspec と Adspec を RAPI を通じて受信側アプリケーションに渡す。
上記のリストは,実行される手順を要約したものです。 手順がさらに必要になることもあります。
ローカル・アプリケーションが予約の要求を行おうとする (自分を受信側と宣言) と,次のようなイベントが発生することがあります。
アプリケーションが RAPI インタフェースを通じて
rsvpd
デーモンとの通信を開始する。
アプリケーションが,受信側が予測するトラフィック (Tspec),必要な QoS レベル (Rspec),パケットに対するトランスポート・プロトコルおよびポート番号 (filter spec) を
rsvpd
に渡す。
Rspec および Tspec は,フロー記述子すなわち
flowspec
と見なされます。
また,Rspec はルータまたはホストでパケットのスケジューリングを制御するメカニズムとしても使用されます。 また,filter spec はパケットの分類を制御して,どの送信側のデータ・パケットが対応する QoS を受けるかを判断します。
rsvpd
デーモンがこの情報を含む RESV メッセージを作成し,それを Traffic Control に渡す。
rsvpd
デーモンと Traffic Control との相互作用は,要求しているアプリケーションには見えません。
Traffic Control が,予約に必要な帯域幅がローカル・アダプタにあるかどうかを判断する。 存在する場合には,Traffic Control は PATH メッセージ内のソース・アドレスを用いてメッセージを上流に伝送します。
RSVP が有効な各ルータで,Traffic Control は,予約要求を認証し,Tspecs および Flowspec で要求された必要なリソースを割り当てる。 認証に失敗した場合や十分なリソースがない場合,ルータは受信側に RSVP エラーを返します。
RSVP が有効な最後のルータで,要求が受理されると,ルータは RSVP 確認メッセージを受信側に返す。
RSVP セッション・データの送信側のそれぞれで,RSVP はマージした Flowspec オブジェクトをアプリケーションに渡す。 これによって,要求の送信側とデータ・パスのプロパティを通知します。
送信側は,RSVP 予約パラメータに同意する場合は RSVP を介して予約を受諾し,個別のデータ接続を用いて受信側へのデータを送信し始める。
上記のリストは,実行される手順を要約したものです。 手順がさらに必要になることもあります。
異なる受信者からの予約がインターネット内で共有される方法の詳細は,予約スタイルという予約パラメータで制御されています。
いろいろな予約スタイルについての詳細は,RFC 2205
を参照してください。
7.3 Traffic Control
Traffic Control サブシステムは,次のタスクを実行します。
インタフェース・パラメータを保持する承認制御メカニズムを実現する。 パラメータには,デバイスのピーク出力レート,Controlled-Load サービスに予約できる帯域幅のパーセンテージ,同時フローの最大数などがあります。
アプリケーションが,flowspec よりも速いレートでデータを出さないようにする。
rsvpd
デーモンと
iftcntl
コマンドのインタフェースをとって,フローとフィルタのインストールと削除を行う。
すべての出力パケットヘッダと既存の filter spec を照合し,どの出力キューにパケットを置くかを判断する。
詳細は,
iftcntl
(8)7.4 RSVP
RSVP は QoS を特定の IP データ・フローまたはセッションに割り当てます。 これは,マルチポイント - マルチポイントでも,ポイント - ポイントでもかまいません。 RSVP セッション は,トランスポート・プロトコル,IP デスティネーション・アドレス,デスティネーション・ポートによって定義されます。 マルチキャスト・セッションに対するデータ・パケットを受信するには,ホストは,それに対応する IP マルチキャスト・グループに属していなければなりません。 セッションには送信側が複数であることもあり,デスティネーションがマルチキャスト・アドレスであれば,受信側も複数です。
以降の節では,オペレーティング・システムの RSVP 構成要素と,rsvpd
デーモンでの動作について説明します。
7.4.1 RSVP の構成要素
オペレーティング・システムの RSVP 構成要素は次のとおりです。
/usr/sbin/rsvpd
--
RSVP デーモン。
/usr/sbin/rsvpstat
--
リソース予約状態を表示するプログラム
/usr/shlib/librsvp.so
--
RSVP ライブラリ
/usr/include/rapi_lib.h
--
RAPI の定義
/usr/include/rapi_err.h
--
RSVP および RAPI のエラー定義
raw IP ソケットで,受信 RSVP メッセージをリッスンする。
RAPI (RSVP Application Programming Interface) を通じて,ローカル・ホストのアプリケーションと通信する。
オペレーティング・システムの Traffic Control サブシステムとのインタフェースをとる。
rsvpd
は,RSVP メッセージをネットワークから受信すると,ローカルのインタフェース・データベースに対して確認を行い,認証またはプロトコル・エラーを処理します。
要求が有効であれば,rsvpd
デーモンは以下の動作をします。
RSVP セッションとフローの動きを見る。
フローに対するリソース予約を処理する。
rsvpd
に登録されている場合,RSVP メッセージをローカルのアプリケーションに渡す。
ローカル・ホストのインタフェースに照合しないデスティネーション・アドレスを持つRSVP パケットを,次のホップに経路指定する。
デーモンのオプションについての詳細は
rsvpd
(8)rsvpd
の開始と停止についての詳細は,『ネットワーク管理ガイド:接続編』 を参照してください。
7.5 RSVP アプリケーション・プログラミング・インタフェース
RAPI (RSVP Application Programming Interface) によって,アプリケーションは
rsvpd
デーモンとの通信を確立でき,自分をデータの受信側,データの送信側,またはその両方として宣言できます。
アプリケーションは次のものから構成されます。
開発者が作成したメインの関数
RSVP プロトコル作業を実行する RSVP ライブラリ・ルーチン
RSVP コールバックを処理するために開発者が作成した関数
以降の節では,サポートされているルーチンと,開発者が RSVP 対応のアプリケーションを作成するために実行する必要がある手順について説明します。
7.5.1 サポートされているルーチン
クライアント・ライブラリ・サービス --
アプリケーション・プログラムと
rsvpd
デーモンの間の通信を実現するルーチン
RAPI フォーマッティング・ルーチン -- 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 インタフェースを実装しなければなりません。
このプロセスを,次の手順で説明します。
rapi.h
ヘッダ・ファイルをインクルードする。
このファイルは,アプリケーションが RAPI を使用するために必要なデータ構造体,定数,関数プロトタイプをすべて定義しています。
RAPI 呼び出しをコーディングする。
rsvpd
デーモンとの通信を初期化するために RAPI を呼び出すコードを作成します。
RSVP イベントを受信するコールバック・ルーチンを作成します。
アプリケーションの実行とテストを行う。
アプリケーションをコンパイルしたら,それを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)