RSVP memo

end-to-end QoS model, mimic of circuit-switched network

RSVP is signaling protocol to request certain QoS capabilities from the networks

PSTN と比べるとコール中にnetworkを予約し、コール後に開放する形。
DiffServ QoS model とは反対の考え方

RSVP の中心となる考え方は Flow (a unidirectional stream of packets)
Host X -> Host Y
Host X sends RSVP request (PATH message) to nearest router
 = asks to establish QoS-aware path downstream to Host Y

Requestを受信したrouterは PATH message 内の parameter と available resourceを比較し、すべてokの場合は requestをさらに Host Y に近い routerに転送する。
最後には Host Yに到達し、HostY は Reservation request (RESV message) を Host Xへ
応答する。

Path 内のそれぞれのrouterは要求された QoS parameterが提供可能かどうか確認する、
そして、Requestを上流へ転送する

Senderが Reserve messageを受信すると、いよいよ senderがデータを QoS-capable pathに沿って送る準備ができることを知る。

各routerでは事前にQoS parameterが設定されている。
Flow は unidirectional であることから、2つの reservationがそれぞれの報告に必要になる、packet交換が双方向である場合は。

integrated Services model の場合は、Best Effort, Guaranteed Rate and Controlled Loadが提供される
Best Effort: Qos treatmentを要求しない
Guaranteed Rate: 帯域と遅延のFlowを提供、最も厳しい要求の type of service
Controlled Load: 軽い負荷のネットワークで使われる。帯域は保証されるが、遅延は無保証。

RSVP Reservation: Flowspec と Filterspec
Flowspec: Rspec と Tspec structure から成る
Rspec (Reservation specification) は Class of Service で、予約要求を定義
Tspec (Traffic specification) は Traffic計測のための Token Bucket parameterを定義。 average rateや Burst sizeを定義
これらの structures は Receiverから上流の Senderへのrequestの一部
SenderからのRSVP path は Tspec structureが入っており、それにより経路上のrouterは自分たちのリソースが new flowの bitrateを収容できるか確認する。

Filterspec Structure は sender filterを定義
基本的に、Receiverが準備した reservationをどのリソースが使うことを許されるか、を指定。
通常は communicationは1:1であるが、複数のReceiverに送りたいとき、そして、
それを1つの Reservationをshareしたいときも考えられる。例えば、
many-to-many の conferenceなど。

3つのタイプのfilterがあり、 Fixed Filter (FF), Shared Explicit (SE) and Wildcard Filter (WF).
FF は1つのはっきりとしたreservationを利用するソースが特定されていて、Tspec structure parameter (rate, burst, etc) は single flow にだけ適用される
複数のsenderが居る場合には、receiverは1つずつ別々のreservationを確立する必要がある。

SEは複数のはっきりとしてソースが同じ reservationを使うように特定される。receiverは送信元の IP Address を reservation message 内で指定する

WF はどの senderも reservation を利用することができる。IP Addressの特定は不要。


RSVPはscalabilityに欠ける。Nの二乗のflowが必要になるからである。
しかし、receiverがmulticastの場合には、 RSVPは "reservation merging"という機能が使える。
これは複数の受信者が同じmulticast groupを共有しており、同じsenderに対して reservationを作成する場合、senderへ向かう tree に沿って、上流へ propagateする。
その他の機能拡張は aggregate reservationsが追加されたことであるが、standard RSVP仕様では実装されない。

RSVP は soft-state protocol である。つまり router は RSVP reservationを保持するが、それは routerが RSVP PATH/RESV messageを受信している間だけ。
default では all routerはmessageをバラバラに、30秒間隔で送信。もしも router が特定の RSVP state を持って居る場合、PATH と RESV messageを送りつづけることになる。
もし、PATH が上流から、RESV が下流側から重心されなくなったら、routerは持っていたstateをtimeoutさせる。

RSVP configurationは単純で、single command で RSVP bandwidth と per-flow bandwidth を定義する。 ip rsvp bandwidth
このコマンドは RSVP を enable にし、さらに利用可能にする bandwidth も指定する。
RSVPを interfaceで有効にしないと、routerはRSVP messageをその interface上では
acceptも originateもしない。


上述のコマンドのparameterをどれかでも省略すると、defaultでは interface bandwidth の75%をRSVPに使用し、同量をper-flowでも使用する。