INTERNET
インターネット最新テクノロジー：第7回

通信路上のルーターに品質確保の設定をする

帯域を予約して通信品質を確保する

RSVP（Resource ReSerVation Protocol）のがRSVP なのだ。

RSVPの動作
では、RSVP はどのようなことをしているのだろうか。クライアントとサーバーが通信をする場合、クライアントからサーバーに対して通最近、インターネット電話やビデオ会議システムといったアプリケーションの実用化が現信の要求が送られる。一般のサーバーはその要実味を帯びてきた。音声や画像の圧縮技術の進歩に加え、規格の標準化も進んでい求を受け、サービスを開始するが、RSVP 対る。ビデオカメラなどのハードウェアも高性能なものから小型軽量のものまで、かなり充実

応のサーバーはRSVPのパスメッセージ（図A）してきている。そして、この流れを急速に進める可能性がある最新の技術が登場した。帯をクライアントに対して送る。パスメッセージ

域を予約して、通信のクオリティーを確保するのに使用される「RSVP」である。では、には宛先情報（SESSION OBJECT）、最終

RSVPとはどんな技術なのか、これで何が変わるのか、これらをまとめて検証してみよう。

RSVPホップアドレス（RSVP̲HOP OBJECT）、予約のリフレッシュ間隔情報（TIME̲VALUES

NTTデータ通信株式会社
技術開発本部オープンシステムセンター
ネットワーク技術担当

OBJECT）などが含まれている。時には、送信元の情報（SENDER̲TEMPLATE OBJECT）

木幡 康弘 kohata@open.rd.nttdata.co.jp

やサーバー側からのQoS に関するオファー（FLOWSPEC OBJECT）などが含まれることもある。このパスメッセージはサーバーからク
ライアントにデータが流れる経路にそって転送る交換機は1 台ではなく、数台になる。交換

され、経路上のRSVP 対応ルーターで解釈さ機間でも情報交換をして、うまく相手の電話れて、サーバー側からクライアントにパスメッRSVP（Resource ReSerVation Protocol）機を担当している交換機までの接続を行う。

セージが送られたことが記憶される。とは、QoSのためのシグナリングのプロトコル

たとえば、それがアメリカの交換機かもしれなRSVP 対応のクライアントはサーバー側からである。一般の電話での通話を考えてみよう。

いし、最近であれば携帯電話の交換機かもしのパスメッセージを受け取ると、必要に応じて電話をかけようとするときには、受話器を取れない。交換機は、要求に従って、電話がかメッセージからサーバーがオファーしたQoSのる。
「ツー」という発信音が聞こえたら、交換かっていることを知らせるために電話機を鳴ら値を読みだし、これを考慮して手前のルーター機に通話相手の番号を伝えるためにダイアルす。電話が鳴ると、相手が受話器を取り、会にQoS の依頼を行うリザーブメッセージ（図する。交換機では、伝えられた番号に従って、話が始まる。この場合の電話機間の回線を接B）を送る。リザーブメッセージには、宛先情相手の電話機を担当している交換機までの回続する手順をシグナリングという。これと同様

報（SESSION OBJECT）、最終 RSVP ホッ線の電気的な接続を行う。通常、間にはさまに、サーバーとクライアント間の通信のために、プアドレス（RSVP̲HOP OBJECT）、予約のRSVPはシグナリングの技術

リフレッシュ間隔情報（T I M E ̲ V A L U E SOBJECT）、 予約方式（ STYLE OBJECT）が含まれる。さらに、予約方式によって、予約する品質の値（FLOWSPEC OBJECT）やフィルタ情報（FILTER̲SPEC OBJECT）なども含まれる。パスメッセージがサーバーからクライアントに送られるのに対して、リザーブメッセージは、パスメッセージと同じ経路を戻る必要があるので、バケツリレー方式で送られる。リザーブメッセージを受けたルーターは、

330 INTERNET magazine 1997/7

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

図 A ： RSVP パスメッセージの例

リザーブメッセージに対応するパスメッセージ

2

共通ヘッダ

を記憶しているか、要求されたQoS を提供す

0
タイプ：1
未定
TTL
SESSIOM オブジェクト長：24

チェックサムメッセージ長クラス：1
タイプ：2

る余裕があるかをチェックし、条件が満たされSESSION

あて先アドレス（IPv6）なければ、RSVP のエラーメッセージを送り返プロトコル番号フラグ
RSVP̲HOP オブジェクト長：24

し、OK ならばパスメッセージの経路をさかのあて先ポート
クラス：3
タイプ：2

ぼるように、1 つ手前のルーターにリザーブメ
RSVP̲HOPッセージを送る。こうして、パスメッセージが最終ホップ・アドレス（IPv6）

通った経路、すなわちサーバー側からクライア

最終ホップに対する論理的インタフェースハンドル
クラス：5TIME̲VALUES オブジェクト長：8
リフレッシュ間隔（単位：ミリ秒）

TIME̲VALUES

ント側にデータが流れるであろう経路上のルーターに次々にリザーブメッセージが伝えられ、

タイプ：1

図 B ： RSVP 予約要求メッセージの例

経路上で品質の確保が行われるのである。

2共通ヘッダアプリケーションの通信が行われている間、

0
タイプ：2
TTL
未定
SESSIOM オブジェクト長：24

チェックサムメッセージ長クラス：1
タイプ：2

パスメッセージとそれに対応するリザーブメッ
あて先アドレス（IPv6）SESSION

セージは、指定されたリフレッシュ間隔で送出プロトコル番号フラグ
RSVP̲HOP オブジェクト長：24され続ける。これは、経路上のリソースを長時あて先ポート
クラス：3
タイプ：2間確保し続けないようにするために、また、IP
最終ホップ・アドレス（IPv6）

RSVP̲HOP

パケットの転送経路が変更になったときには、最終ホップに対する論理的インタフェースハンドル
クラス：5TIME̲VALUES オブジェクト長：8
タイプ：1
リフレッシュ間隔（単位：ミリ秒）
クラス：5
タイプ：1
STYLE オブジェクト長：8
スタイルオプションベクタ
フラグ
クラス：9
FLOWSPEC オブジェクト長タイプ

速やかにその経路上の品質を確保するためにTIME̲VALUES行われているのである。

STYLE

品質確保の必要がなくなったときには、サーバーとクライアントのいずれかから確保終了のFLOWSPECFLOWSPEC オブジェクト

メッセージを送り、リソースの開放が行われる。

クラス：10FILTER̲SPEC オブジェクト：24
FILTER̲SPEC

RSVPの効果

タイプ：3

送信元アドレス（IPv6）
0

フロー・ラベル

では、RSVP ができると何が変わるのだろう
RSVP オブジェクトの詳細か。現在のインターネットやイントラネットの番号オブジェクト0

NULL

べての通信が平等に扱われる。マルチメディア

1

SESSION系のビデオコンファレンスの通信もファイル転3

RSVP̲HOP

45

TIME̲VALUES

6ERROR̲SPEC

7SCOPE89

FLOWSPEC

10FITER̲SPEC

11SENDER̲TEMPLATE

121314SENDER̲TSPEC

15RESV̲CONFIRM

ようなTCP/IP ベースのネットワークでは、す送の通信も、まったく同様に扱われてしまうのだ。しかし、これでは、アプリケーションの特質によって要求する品質を満たすことができない。たとえば、ファイル転送なら、他のアプリケーションが使っていない瞬間を見はからって断続的にデータを流すことでも目的は達成でSTYLE

し、インターネット電話やビデオコンファレンスソフトなどの対話型のアプリケーションではそうはいいかない。しゃべりかけてから相手が答えるのに数秒もかかるようでは、会話がぎこ

12
1
2

INTEGRITY

きる。途中の連続性はどうでもよく、最終的に転送にかかる時間が短ければいいのだ。しかタイプ

ADSPECPOLICY̲DATA

1
12
12
1
12
12
3
1
2
3
2
2
1
12

詳細

受信者はこれを無視する
IPv4 セッション（フローのあて先）
IPv6 セッション（フローのあて先）
IPv4 前ホップおよび次のホップのアドレス
IPv6 前ホップおよび次のホップのアドレス
鍵付きMD5 認証データ
パスおよび予約のリフレッシュの頻度
IPv4 システムからのエラー情報
IPv6 システムからのエラー情報
ワイルドカード方式の予約リフレッシュメッセージが適用されるIPv4 ホストのリスト
ワイルドカード方式の予約リフレッシュメッセージが適用されるIPv6 ホストのリスト
予約方式
従来のフロー仕様
intserv が制定しているフロー仕様
フローとしてIPv4 アドレスと送信元ポートを適用するフィルタ仕様
フローとしてIPv6 アドレスと送信元ポートを適用するフィルタ仕様
フローとしてIPv6 アドレスとフローラベルを適用するフィルタ仕様
フローとしてIPv4 アドレスと送信元ポートを適用する送信者
フローとしてIPv6 アドレスと送信元ポートを適用する送信者
フローとしてIPv6 アドレスとフローラベルを適用する送信者
intserv が制定しているエンコードルール
intserv が制定しているフォーマットフローに対するポリシー情報・詳細未定
IPv4 アドレスを適用する受信者
IPv6 アドレスを適用する受信者D

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

INTERNET magazine 1997/7331

RSVPが生きるアプリケーションちなくなってしまう。

確保の仕組みであると言える。これによって、このようなアプリケーションのために、要求重要性の高いアプリケーションにリソースを割する品質を必要なときにだけ確保することにより当てることが可能になるのである（図E）。って、アプリケーションの動作をスムーズにすることができるのである。品質を要求するのは

RSVPの今後マルチメディア系のアプリケーションばかりで

図 C ： Intel 社のProShare ビデオ会議 2000
j http://www.intel.co.jp/jp/comm-net/proshare/index.htm

図 D：住友金属工業株式会社のRemotely
Possible/32
j http://www.avalan.com/rp/rp30feat.html

はない。イントラネットやエクストラネットでRSVP はIETF で標準化が進められている。

は、業務のためのアプリケーションが通信を行RSVPに関する標準化の検討は大きく分けて3う可能性もある。決済や予約の確認などのトつの事柄に分かれる。1 つ目は、品質確保のランザクション系のアプリケーションや受発注ために指定できるパラメーターの制定に関するなどの場合には、通信の時間は少なくても、そ議論だ。これは、「intserv」という委員会との瞬間には確実に通信できる必要がある。こ「issll」という委員会でそれぞれ行われている。のような通信を行うときには、RSVPで通信路intserv で議論されている内容はまとまりつつを確保することで、より確実な通信が可能とあるが、issll での議論はintserv の定義したパなるのである。さらに、ネットワーク管理などラメーターを、実際の通信メディアにどのようのリモート操作にも応用ができる。遠隔地かに対応づけるかを検討しているところで、まだらネットワーク機器の設定をする場合に、ネッまだ議論が必要だ。2つ目は、これらのintservトワークが混んでいると操作ができない場合がなどが定めたパラメーターを使って、ネットワある。最近の傾向として、サーバーにウィンドークに要求を伝えるシグナリングのプロトコル

ウズNT を採用する場合があるが、NT サーバとしてのRSVP である。これは、「rsvp」といーのコンソールをネットワーク経由で遠隔地にう委員会で議論されている。4 月のIETF で議表示させて、そこで操作を行うことも多くなっ論を終了するという話もある。最新の仕様は、てきた。この場合にも、ネットワークにある程スペック15で、1997年5月1日付で改定され度の帯域がないと操作はできない。このようなている。3つ目が、QoSのためのポリシーやルときに、RSVP で帯域を確保することで、操ーティングに関する議論で、「qosr」という委作を容易にし、運用を円滑に行えるようにな員会で検討されている。この件に関する検討るのである（図C、図D）。

は始まったばかりで、これからさまざまな問題が解決されることが期待されている。

他の手段でも要求する品質を確保できる。
従来のシステムでは、このような要求の高いサービスは、別に通信路を設けることで品質を

RSVPの課題満たしてきた。しかし、これには無駄が多いことも分かってきている。また、通信路は共有しRSVPにはいくつかの大きな課題がある。先ても要求する品質を確保できるメディアも存在に述べたように、RSVP は通信路上の機器をしている。フレームリレーやATMなどがこれにセットアップするだけのプロトコルである。実当たる。しかし、これらのメディアは、確保す際にトラフィックをコントロールするための機るための設定が必要で、確保したい瞬間を利構は規定していない。つまり、「パケットの送用者の判断で指定できないという欠点がある出を調整する機能がすでにある」ことを前提のだ。RSVPはアプリケーションが必要に応じに、その機能を利用するための仕組みとして定て要求を行うため、たとえ、同じサーバーとク義されているのである。現在のネットワーク機ライアント間の通信であっても、確保しなけれ器の大半は、トラフィックコントロールの機能ばならない通信とそうでない通信とを区別するが未整備なので、この部分が整備される必要ことができる。そういう点で、より柔軟な品質があるのだ。次に、大規模な通信路中には多D

332 INTERNET magazine 1997/7

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D参考文献

数の中継器が存在している。この中継器では、展をもたらす技術であることも事実である。整経路が複数に分かれる場合がありえるが、こ備という面では、米国のプロバイダーであるのような複数の経路の分岐点にあたる「中継MCIやBBNがRSVPに関する実験を行ってい<draft-ietf-rsvp-md5-02.txt>
RSVP Cryptographic Authentication器」がRSVPをサポートしていないと、そこまる。国内のプロバイダーはまだ取り組みが遅れ<draft-ietf-rsvp-mib-05.txt>
RSVP Management Information Base

での経路分しかQoSが保証されない。つまり、ているが、WIDE プロジェクトなどでは、RT-<draft-berger-rsvp-ext-07.txt>
RSVP Extensions for IPSEC Data Flows<draft-ietf-rsvp-spec-15.txt>
Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification

ネットワーク側がRSVP対応になっていないとBONE（Real Time Back Bone）と呼ばれる<draft-ietf-intserv-rsvp-use-01.txt>
The Use of RSVP with IETF Integrated Services

効果が出ないのである。さらに、RSVPはクラ広域実験が始まりつつある。制御という面で<draft-ietf-intserv-ctrl-load-svc-04.txt>
Specification of the Controlled-Load Network Element Service

イアントが品質確保の要求を出すプロトコルでも、リソース確保のポリシーを提案する文書ある。すなわち、利用者側に主導権がある仕や、QoS ルーティングに関する検討のための組みなのだ。このような場合、利用者の言いワーキンググループができるなど、さまざまな値で品質を提供すると、一部の利用者の独占取り組みが行われている。NTT データでも状態や、デッドロックのためにすべての利用者

RSVP をサポートした環境で、ネットワーク提が利用できない状態に陥る可能性などが指摘

供者側が主導権を持つことができるような仕組されている。ネットワーク側の整備は必須であみに関する研究開発が行われている。

るが、整備された機能の使用は利用者側に主現時点で、RSVPをサポートした製品はあま導権があるような仕組みなのである。これらのり手に入らないが、6 月に行われる「Interop点で、RSVPは難しい面を持っているのである+Networld '97 Tokyo」では、各社がRSVPと言える。

対応のルーターやアプリケーションを展示する

上記のような問題を抱えるRSVP だが、利<draft-ietf-intserv-guaranteed-svc-07.txt>
Specification of Guaranteed Quality of Service<draft-ietf-intserv-mib-05.txt>
Integrated Services Management Information Base<draft-ietf-intserv-guaranteed-mib-03.txt>
Integrated Services Management Information Base Guaranteed
Service Extensions

予定だ。今後、急速にRSVP のサポートが進用環境が整えばインターネットにより一層の発むことを期待したい。

図 E ：帯域を予約して、データの品質を確保するRSVP

128K
128K
ちょうだいちょうだい128K くらい必要ですよ

128K
だって128K
だって

a予約のために必要なメッセージの送信

128K
だって
d予約された通信路

A

A

B

B
ルータ

ルータ
その他はみんなで分けてねCC
Cさんのファイル転送の分

D

AさんとBさんのビデオカンファレンスの分

D`

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

INTERNET magazine 1997/7333

［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.