リソース予約プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

RSVP自体が通信ネットワークに展開されることはめったにありません。[要出典] 2003年、開発努力は通信トラヒック工学のためにRSVPからRSVP-TEにシフトされました。Next Steps in Signaling(NSIS)は、RSVPの代替案として提案されました。

主な属性

  1. RSVPは、シンプレックスフローのリソースを要求します。送信者から1つ以上の受信者への一方向のみのトラフィックストリームです。
  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は、制御負荷RFC2211および保証されたRFC2212QoS制御サービスでのRSVPの使用を定義しています。統合サービスの詳細また、RFC 2205でRSVPによって定義されたデータオブジェクト(リソース予約情報を保持する)の使用法とデータ形式を定義します。
  • RFC  2211は、Controlled-Loadサービスを提供するために必要なネットワーク要素の動作を指定しています。
  • RFC  2212は、保証されたQoSサービスを提供するために必要なネットワーク要素の動作を指定しています。
  • RFC  2750は、 RSVPで一般的なポリシーベースのアドミッションコントロールをサポートするために提案された拡張機能について説明しています。拡張機能には、ポリシーオブジェクトの仕様と、ポリシーイベントの処理に関する説明が含まれていました。(2000年1月)。
  • RFC  3209、「RSVP-TE:LSPトンネルのRSVPへの拡張」(2001年12月)。
  • RFC  3473、「Generalized Multi-Protocol Label Switching(GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering(RSVP-TE)Extensions」(2003年1月)。
  • RFC  3936リソースリソースプロトコルRSVP )を変更するための手順」(2004年10月)では、現在のベストプラクティスについて説明し、RSVPを変更するための手順を指定しています
  • RFC  4495「予約フローの帯域幅を削減するためのリソース予約プロトコル(RSVP)拡張」(2006年5月)は、RSVPを拡張して、予約を破棄する代わりに既存の予約の帯域幅を削減できるようにします。
  • RFC  4558、「ノードIDベースのリソース予約プロトコル(RSVP)Hello:A Clarification Statement」(2006年6月)。

重要な概念

RSVP予約モデルの2つの重要な概念は、flowspecfilterspecです。

Flowspec

RSVPは、フロー用のリソースを予約します。フローは、宛先アドレス、プロトコルID、およびオプションで宛先ポートによって識別されます。マルチプロトコルラベルスイッチング(MPLS)では、フローはラベルスイッチングパス(LSP)として定義されます。RSVPは、フローごとに、フローに必要な特定のサービス品質(QoS)も識別します。このQoS情報はflowspecと呼ばれ、RSVPはflowspecをアプリケーションからパスに沿ってホストとルーターに渡します。次に、これらのシステムはflowspecを分析して、リソースを受け入れて予約します。フロースペックは次のもので構成されます。

  1. サービスクラス
  2. 予約仕様-QoSを定義します
  3. トラフィック仕様-データフローについて説明します

Filterspec

filterspecは、flowspecの影響を受けるパケットのセット(つまり、 flowspecで定義されたQoSを受信するためのデータパケット)を定義します。filterspec通常、ノードによって処理されるすべてのパケットのサブセットを選択します。選択は、パケットの任意の属性(たとえば、送信者のIPアドレスとポート)に依存する可能性があります。

現在定義されているRSVP予約スタイルは次のとおりです。

  1. 固定フィルター-特定のフロー用にリソースを予約します。
  2. 明示的共有-複数のフロー用にリソースを予約し、すべてがリソースを共有します
  3. ワイルドカードフィルター-フローを指定せずに、一般的なタイプのフロー用にリソースを予約します。すべてのフローがリソースを共有します

RSVP予約要求は、flowspecfilterspecで構成され、そのペアはflowdescriptorと呼ばれますflowspecはノードでパケットスケジューラのパラメータを設定し、filterspecパケット分類器でパラメータを設定します。

メッセージ

メッセージには主に2つのタイプがあります。

  • パスメッセージ(path
パスメッセージは、データパスに沿って送信者ホストから送信され、パスに沿った各ノードのパス状態を格納ます
パスの状態には、前のノードのIPアドレスといくつかのデータオブジェクトが含まれます。
  1. Filterspecの形式で送信者データの形式を説明する送信者テンプレート[4]
  2. データフローのトラフィック特性を記述する送信者tspec
  3. 広告データを運ぶadspec(詳細については、RFC 2210を参照してください)。
  • 予約メッセージ(resv
resvメッセージは、リバースデータパスに沿って受信者から送信者ホストに送信されます各ノードで、resvメッセージのIP宛先アドレスはリバースパス上の次のノードのアドレスに変更され、IP送信元アドレスはリバースパス上の前のノードアドレスのアドレスに変更されます。
resvメッセージには、フローに必要なリソースを識別するflowspecデータオブジェクトが含まれています。

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

操作

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

それらを聞きたい人は、対応するresvreserveの略)メッセージを送信します。このメッセージは、送信者までのパスをたどります。resvメッセージにはflowspecが含まれてますresvメッセージにもfilterspecオブジェクトがあります。フロースペックで定義された要求されたQoSを受信するパケットを定義します。単純なフィルター仕様は、送信者のIPアドレスと、オプションでそのUDPまたはTCPポートだけです。ルータがRSVPresvメッセージを受信すると、次のようになります。

  1. リクエストパラメータに基づいて予約してください。アドミッションコントロールは要求パラメータを処理し、パケット分類子にデータパケットの選択されたサブセットを正しく処理するように指示するか、パケット処理の実行方法を上位層とネゴシエートすることができます。サポートできない場合は、拒否メッセージが送信され、リスナーに通知されます。
  2. リクエストをアップストリームに転送します(送信者の方向に)。各ノードで、resvメッセージのflowspecを転送ノードで変更できます(たとえば、マルチキャストフロー予約の場合、予約要求をマージできます)。
  3. 次に、ルータはフローの性質を保存し、オプションでそのフロー仕様に従ってポリシングを設定します。

一定時間何も聞こえない場合、予約はタイムアウトになり、キャンセルされます。これにより、送信者または受信者のいずれかがクラッシュした場合、または最初に予約をキャンセルせずにシャットダウンされた場合の問題が解決されます。

その他の機能

威厳
RSVPメッセージには、メッセージダイジェストアルゴリズム(通常はMD5 )を使用してメッセージコンテンツと共有キーを組み合わせて作成されたメッセージダイジェストが追加されますキーは、整合性チャレンジ要求整合性チャレンジ応答の2つのメッセージタイプを使用して配布および確認できます
エラー報告
ノードがエラーを検出すると、エラーメッセージがエラーコードとともに生成され、送信者へのリバースパスでアップストリームに伝播されます。
RSVPフローに関する情報
2種類の診断メッセージにより、ネットワークオペレータは特定のフローに関するRSVP状態情報を要求できます。
診断施設
ユーザーがパスに沿ってRSVP状態に関する情報を収集できるようにする標準の拡張。[5]

RFC

参考文献

  1. ^ ギャレット、アビバ; ドレナン、ゲイリー; モリス、クリス(2002)。ジュニパーネットワークスのフィールドガイドおよびリファレンスp。583. ISBN 9780321122445
  2. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  3. ^ Zhang、L.、Deering、S.、Estrin、D.、Shenker、S。、およびD. Zappala、「RSVP:A New Resource ReSerVation Protocol」、IEEEネットワーク、1993年9月
  4. ^ Lixia、Zhang; スティーブ、バーソン; シャイ、ヘルツォーク; スギ、ジャミン(1997年9月)。Resource ReSerVation Protocol(RSVP)-バージョン1の機能仕様p。19. doi10.17487 / RFC2205RFC2205_
  5. ^ RSVP診断メッセージ土井10.17487 / RFC2745RFC2745_
  • ジョン・エバンス; Clarence Filsfils(2007)。マルチサービスネットワークへのIPおよびMPLSQoSの導入:理論と実践モーガンカウフマン。ISBN 978-0-12-370549-5

外部リンク