RSVP / Resource Reservation Protocol

■ RSVP。Resource Reservation Protocol。

  IPネットワーク上のエンドホスト間で
  ネットワーク上の資源(帯域、バッファ、CPU等)を動的に予約して、
  通信品質を確保できるようにするシグナリングプロトコル。
  IETFにより、RFC2205に規定されている。

  RSVPによる資源予約を利用すれば、
  テレビ会議などのリアルタイム性を要求するアプリケーションと、
  FTPファイル転送などのバースト転送型アプリケーションとを、
  同一のIPネットワーク上で混在させた状態で、
  後者よりも前者のトラフィックを優先させることができる。

  RSVPは、OSI参照モデルのトランスポート層に位置付けられるが、
  実際のデータ転送は行なわず、主にセッション層の仕事をしている。
  またIPv4、IPv6の両方のプロトコルスタックで動作し、
  IPユニキャスト、IPマルチキャストの両方で利用可能である。

  RSVPはあくまで、ホストとルータ、またはルータ同士が、
  QoS制御に必要な情報を交換するためのプロトコルに過ぎない。
  実際にルータ上でQoSを保証するためのアルゴリズム
  (トラフィック制御、ポリシー制御)とは独立している。
  こうしたQoS保証の仕組みは、個々のルータの実装に任されている。

■ RSVPの基本動作

  (1) Pathメッセージ

    最初に、RSVPの送信側(マルチメディアサーバ)が、
    RSVP受信側(クライアント)に向けて、Pathメッセージを送信する。
    ネットワーク上の各ルータは、有効なPathメッセージを読み込むと、
    自身のPath状態を設定して、メッセージを下流に転送する。

    各ルータのPath状態には、Pathメッセージのコピーと、
    前ホップルータのIPアドレスが格納されているる。
    この情報は、あとで受信側ホストがホップを逆に辿り、
    送信元ホストにResvメッセージを送信する時に使用される。

  (2) Resvメッセージ

    データの受信者となる各アプリケーションは、
    送信側からのPathメッセージを受け取ると、
    必要とするサービス品質に応じて、ネットワーク資源の予約を
    要求するリクエスト(Resvメッセージ)を送信する。

    Resvメッセージが各ルータに到達すると、
    各ホップは、発信したホストに対して、
    要求されたサービス品質の提供が可能か否かを応答する。
    予約が許可する場合は、物理的な帯域幅を割り当てる。
    さらにこのResvメッセージを上流のルータに転送する。

    こうしてResvメッセージは、Pathメッセージと
    同じホップを逆順に辿って、トラフィックの発信源まで溯る。
    すべてのホップで品質の確保が可能な場合には、
    要求されたサービス品質を保証するエンド・ツー・エンドの
    パイプラインが形成される。

  (3) ソフトステート
 
    RSVPは、予約した経路のステータスを維持するために、
    送受信ホスト間で、定期的にPath/Resvメッセージ
    (リフレッシュメッセージ)を送りあう仕組みになっている。
    もしも、一定時間リフレッシュメッセージが来ない場合には、
    ステータスは自動的にタイムアウトし、削除される。

    このように一定時間、通信相手の生存確認ができない場合は、
    何らかの障害状態に陥ったと判断し、接続から切離すモデルを、
    一般にソフト・ステート型の状態管理と呼ぶ。
    RSVPでは、ソフトステート型の状態管理を行なう。

■ シンプレックス

  RSVPによる資源予約は、フロー単位で行なわれる。
  すなわち、送信者から受信者へ、または受信者から送信者への、
  片方向のデータフローに対してのみ資源予約を行なう。
  このため、もしも双方向の資源を予約したい場合は、
  送信者と受信者の両方向から別個に資源予約する必要がある。

以上。

2003/08/19 pm