リソース予約プロトコル

リソース予約プロトコル（RSVP）は、統合サービスモデルを使用してネットワーク全体でリソースを予約するように設計されたトランスポート層^{[ 1 ]}プロトコルです。RSVPはIPv4またはIPv6上で動作し、マルチキャストまたはユニキャストデータフローのリソース予約を受信側から開始する設定を提供します。アプリケーションデータを転送しませんが、インターネット制御メッセージプロトコル（ICMP）やインターネットグループ管理プロトコル（IGMP）などの制御プロトコルに似ています。RSVPはRFC 2205で説明されています。IPプロトコル番号は46です。 

RSVPは、ホストとルーターがアプリケーションデータストリームに対して特定のレベルのサービス品質（QoS）を要求または提供するために使用できます。RSVPは、アプリケーションがどのようにリソースを予約し、不要になった予約済みリソースをどのように解放するかを定義します。RSVP操作は通常、パス上の各ノードでリソースが予約される結果となります。RSVPはルーティングプロトコルではありませんが、現在および将来のルーティングプロトコルとの相互運用性を考慮して設計されています。

2003年、テレトラフィックエンジニアリングの開発はRSVPからRSVP-TEへと移行した。Next Steps in Signaling（NSIS）はRSVPの後継として提案された。

1. RSVPは、送信者から1つ以上の受信者への一方向のみのトラフィックストリームであるシンプレックスフローのリソースを要求します。 ^{[ 2 ]}
2. RSVPはルーティングプロトコルではありませんが、現在および将来のルーティングプロトコルと連携して動作します。
3. RSVPは受信者指向であり、データフローの受信者がそのフローのリソース予約を開始および維持します。
4. RSVPは、ホストとルーターのリソース予約のソフトステート（各ノードでの予約は定期的な更新が必要）を維持することで、ネットワークの変化に対する動的な自動適応をサポートします。
5. RSVPは複数の予約スタイル（予約オプションのセット）を提供し、さまざまな用途に合わせてプロトコルの改訂で将来的にスタイルを追加することも可能です。
6. RSVPは、RSVPからは見えないトラフィックおよびポリシー制御パラメータを転送および維持します。

RSVPの基本概念は、もともと1993年に提案された。^{[ 3 ]}

RSVPについては、IETFが作成した一連のRFC文書に記載されています。

• RFC 2205：バージョン1の機能仕様は、IETFによってRFC 2205（1997年9月）で記述されました。バージョン1では、リソースの可用性のみに基づくアドミッション（トラフィック）制御へのインターフェースが記述されています。その後、RFC2750でアドミッション制御のサポートが拡張されました。 
• RFC 2210 では、制御負荷 RFC 2211 および保証 RFC 2212 QoS 制御サービスにおける RSVP の使用法を定義しています。詳細は「統合サービス」を参照してください。また、RFC 2205 で RSVP によって定義されているデータ オブジェクト (リソース予約情報を含む) の使用方法とデータ フォーマットも定義しています。 
• RFC 2211は、制御負荷サービスを提供するために必要なネットワーク要素の動作を規定している。 
• RFC 2212は、保証されたQoSサービスを提供するために必要なネットワーク要素の動作を規定しています。 
• RFC 2750は、RSVPにおける汎用的なポリシーベースのアクセス制御をサポートするための提案された拡張機能について説明しています。この拡張機能には、ポリシーオブジェクトの仕様とポリシーイベントの処理に関する説明が含まれています。（2000年1月） 
• RFC 3209、「RSVP-TE: LSPトンネルのためのRSVPの拡張」（2001年12月）。 
• RFC 3473、「汎用マルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張機能」（2003年1月）。 
• RFC 3936 「リソース予約プロトコル（ RSVP ）の変更手順」（2004年10月）では、現在のベストプラクティスについて説明し、RSVPの変更手順を規定しています。 
• RFC 4495「リソース予約フローの帯域幅を削減するためのリソース予約プロトコル（RSVP）の拡張」（2006年5月）は、既存の予約を破棄するのではなく、その帯域幅を削減できるようにRSVPを拡張しています。 
• RFC 4558、「ノードIDベースのリソース予約プロトコル（RSVP）Hello：明確化声明」（2006年6月）。 

RSVP予約モデルの2つの重要な概念は、フロー仕様とフィルタ仕様です。

メッセージには大きく分けて2種類あります。

• パスメッセージ（パス）

パスメッセージは送信元ホストからデータパスに沿って送信され、パス上の各ノードにパスの状態を保存します。

パス状態には、前のノードのIPアドレスといくつかのデータオブジェクトが含まれます。

1. 送信者テンプレートは、Filterspec ^{[ 4 ]}の形式で送信者データの形式を記述します。
2. データフローのトラフィック特性を記述する送信側tspec
3. 広告データを含むadspec（詳細はRFC 2210を参照）。

• 予約メッセージ ( resv )

resvメッセージは、受信側ホストから送信側ホストへ逆方向のデータパスに沿って送信されます。各ノードにおいて、resvメッセージのIP宛先アドレスは逆方向パス上の次のノードのアドレスに、IP送信元アドレスは逆方向パス上の前のノードのアドレスに変更されます。

resvメッセージには、フローが必要とするリソースを識別するflowspecデータオブジェクトが含まれています。

RSVPメッセージに含まれるデータオブジェクトは、任意の順序で送信できます。RSVPメッセージおよびデータオブジェクトの完全なリストについては、RFC 2205を参照してください。

特定のQoSを持つデータフローを送信する必要のあるRSVPホストは、30秒ごとにRSVPパスメッセージを送信します。このメッセージは、動作中のルーティングプロトコルによって事前に確立されたユニキャストまたはマルチキャスト経路に沿って伝送されます。パスメッセージがRSVPを理解しないルーターに到着した場合、そのルーターはメッセージの内容を解釈せずにメッセージを転送し、フロー用のリソースを予約しません。

受信を希望する側は、対応するresv （ reserveの略）メッセージを送信し、そのメッセージは送信元まで経路をたどります。resvメッセージにはflowspecが含まれています。resvメッセージにはfilterspecオブジェクトも含まれており、flowspecで定義された要求されたQoSを受け取るパケットを定義します。単純なfilterspecは、送信元のIPアドレスと、オプションでUDPまたはTCPポートのみで構成されます。ルーターがRSVP resvメッセージを受信すると、次の処理を実行します。

1. リクエストパラメータに基づいて予約を行います。アドミッションコントロールはリクエストパラメータを処理し、選択されたデータパケットのサブセットを正しく処理するようにパケット分類器に指示するか、上位レイヤーとパケット処理の方法について交渉します。サポートできない場合は、拒否メッセージがリスナーに通知されます。
2. リクエストを上流（送信者方向）に転送します。各ノードでは、転送ノードによってresvメッセージ内のflowspecを変更できます（たとえば、マルチキャストフロー予約の場合、予約リクエストをマージできます）。
3. ルーターはフローの性質を保存し、必要に応じてフロー仕様に基づいてポリシングを設定します。

一定時間応答がない場合、予約はタイムアウトとなりキャンセルされます。これにより、送信側または受信側のシステムがクラッシュしたり、予約をキャンセルせずにシャットダウンされたりした場合に発生する問題を解決できます。

誠実さ

RSVPメッセージには、メッセージの内容と共有キーをメッセージダイジェストアルゴリズム（一般的にはMD5 ）で組み合わせたメッセージダイジェストが付加されます。このキーは、整合性チャレンジ要求 と整合性チャレンジ応答という2種類のメッセージを使用して配布および確認できます。

エラー報告

ノードがエラーを検出すると、エラーコードを含むエラーメッセージが生成され、逆方向の経路を通って送信元へと伝播される。

出欠確認の流れに関する情報

2種類の診断メッセージにより、ネットワークオペレーターは特定のフローに関するRSVP状態情報を要求できます。

診断施設

パスに沿ってRSVPの状態に関する情報を収集できるようにする標準規格の拡張。^{[ 5 ]}

• 「リソース予約プロトコル」。Cisco。2017年7月5日にオリジナルからアーカイブ済み。2011年2月16日に取得。
• Naveen Joy (2002-06-17). "RSVPは質の高いサービスを提供する" . Network World . 2013-06-29のオリジナルからアーカイブ済み。2012-02-14に取得。
• 「RSVPプロジェクト」。南カリフォルニア大学情報科学研究所。 2017年4月27日時点のオリジナルからアーカイブ済み。