Full HTML for

Basic foilset Part II of RSVP Reservation Protocol

Given by Marek Podgorny,Nancy McCracken at CPS640 Internet and Multimedia Technologies on Spring 98. Foils prepared 15 April 98
Outside Index Summary of Material

This advanced discussion describes
RSVP Protocol and Messages
Merging Flowspecs
RSVP's Soft State
Teardown
Confirmations
RSVP Tunneling
RSVP Host Model

Table of Contents for full HTML of Part II of RSVP Reservation Protocol

 Denote Foils where HTML is sufficient
1 Reservation Protocol RSVP - Part II
2 RSVP Protocol Mechanisms
3 RSVP Protocol Mechanisms
4 RSVP Messages
5 RSVP Protocol Messages
6 RSVP Protocol Messages
7 RSVP Protocol Messages
8 RSVP Protocol Messages
9 RSVP Protocol Messages
10 Merging Flowspecs
11 Merging Flowspecs
12 RSVP's Soft State
13 RSVP's Soft State
14 RSVP's Soft State
15 Teardown
16 Confirmations
17 Confirmations
18 RSVP Tunneling
19 RSVP's Host model
20 RSVP's Host model
21 RSVP's Host Model
22 RSVP's Host Model

Outside Index Summary of Material

HTML version of Basic Foils prepared 15 April 98

Foil 1 Reservation Protocol RSVP - Part II

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
CPS640 Network and Multimedia Technologies
Spring 1998
Marek Podgorny
Nancy McCracken
HTML version of Basic Foils prepared 15 April 98

Foil 2 RSVP Protocol Mechanisms

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
RSVP Messages
  • Two basic RSVP message types: Resv and Path.
    • Each receiver host sends RSVP reservation request (Resv) messages upstream towards the senders.
    • Resv messages must follow exactly the reverse of the routes the data packets will use, upstream to all the sender hosts included in the sender selection.
    • Resv messages are delivered to the sender hosts themselves so that the hosts can set up appropriate traffic control parameters for the first hop.
HTML version of Basic Foils prepared 15 April 98

Foil 3 RSVP Protocol Mechanisms

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
RSVP Messages
  • Two basic RSVP message types: Resv and Path.
    • Each RSVP sender host transmits RSVP Path messages downstream along the uni-/multicast routes provided by the routing protocol(s), following the paths of the data.
    • Path messages store "path state" in each node along the way. This path state includes at least the unicast IP address of the previous hop node, which is used to route the Resv messages hop-by-hop in the reverse direction.
HTML version of Basic Foils prepared 15 April 98

Foil 4 RSVP Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Path messages are sent with the same source and destination addresses as the data, so that they will be routed correctly through non-RSVP clouds.
Resv messages are sent hop-by-hop. Each RSVP-speaking node forwards a Resv message to the unicast address of a previous RSVP hop.
HTML version of Basic Foils prepared 15 April 98

Foil 5 RSVP Protocol Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Path message: additional information:
  • Sender Template
    • Sender Template describes the format of data packets that the sender will originate. This template is in the form of a filter spec that could be used to select this sender's packets from others in the same session on the same link.
    • at present, only the sender IP address and optionally the UDP/TCP sender port can be specified
  • Sender Tspec
    • (Required) Sender Tspec which defines the traffic characteristics of the data stream that the sender will generate. Tspec is used by traffic control to prevent over-reservation or unnecessary Admission Control failure on upstream links.
HTML version of Basic Foils prepared 15 April 98

Foil 6 RSVP Protocol Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Adspec: a Path message may optionally carry a package of OPWA advertising information.
  • An Adspec received in a Path message is passed to the local traffic control, which returns it updated
  • The updated version is then forwarded in Path messages sent downstream.
  • Sender Tspec is never changed, Adspec may be changed by intermediate nodes
  • Adspec includes both parameters describing the properties of the data path (availability of specific QoS services) and parameters required by specific QoS control services to operate correctly.
  • Adspec is finally passed to the application via RSVP API.
HTML version of Basic Foils prepared 15 April 98

Foil 7 RSVP Protocol Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Resv Messages anatomy
  • Flow descriptor consists of flowspec and filter spec
  • Flow is defined a set of packets traversing the network all of which are covered by the same request for QoS
  • Flowspec consists of two sets of parameters: Rspec and Tspec
    • Rspec defines desired QoS
    • Tspec describes the data flow
  • Hmmm - what is this supposed to mean?
HTML version of Basic Foils prepared 15 April 98

Foil 8 RSVP Protocol Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Tspec and Rspec (Traffic and Reservation Specs)
  • Tspec has two incarnations: Receiver_Tspec in Resv messages and Sender_Tspec in Path messages
  • Tspec is is a description of the traffic pattern for which service is being requested
  • Tspec is one side of a "contract" between the data flow and the service.
  • Service module agrees to provide a specific QoS if and only if the flow's data traffic remains conformant to the Tspec
  • Example: upper bound on the peak rate
HTML version of Basic Foils prepared 15 April 98

Foil 9 RSVP Protocol Messages

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Sender and Receiver Tspec
  • Receiver Tspec is a basis for the "contract" between the flow and the service
  • Sender Tspec is used to verify Receiver Tspec to avoid excessive reservations
Rspec - Reservation Specification
  • Usually invokes a particular service class
  • Contents of the request depends on the service and is of little interest to RSVP (but not in general!)
HTML version of Basic Foils prepared 15 April 98

Foil 10 Merging Flowspecs

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
a single physical interface may receive multiple reservation requests from different next hops for the same session and with the same filter spec
RSVP should install only one reservation on that interface. The installed reservation should have an effective flowspec that is the "largest" of the flowspecs requested by the different next hops
Similarly, a Resv message forwarded to a previous hop should carry a flowspec that is the "largest" of the flowspecs requested by the different next hops
in certain cases the "smallest" is taken rather than the largest.
HTML version of Basic Foils prepared 15 April 98

Foil 11 Merging Flowspecs

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Flowspec merging requires calculation of the "largest" of a set of flowspecs.
  • Flowspecs are generally multi- dimensional vectors (they may contain both Tspec and Rspec components, each of which may itself be multi-dimensional), it may not be possible to strictly order two flowspecs.
  • For example, if one request calls for a higher bandwidth and another calls for a tighter delay bound, one is not "larger" than the other. In such a case, instead of taking the larger, RSVP must compute and use a third flowspec that is at least as large as each.
  • Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, calculations above are actually performed by traffic control. The definition and implementation of the rules for comparing flowspecs are outside the definition of RSVP
HTML version of Basic Foils prepared 15 April 98

Foil 12 RSVP's Soft State

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
RSVP soft state is created and periodically refreshed by Path and Resv messages.
  • The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval.
  • State may also be deleted by an explicit "teardown" message.
  • At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward Path and Resv refresh messages to succeeding hops.
  • When a route changes, the next Path message will initialize the path state on the new route, and future Resv messages will establish reservation state there
    • the state on the now-unused segment of the route will time out.
HTML version of Basic Foils prepared 15 April 98

Foil 13 RSVP's Soft State

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
RSVP sends its messages as IP datagrams with no reliability enhancement:
  • Periodic transmission of refresh messages by hosts and routers is expected to handle the occasional loss of an RSVP message.
    • If the effective cleanup timeout is set to K times the refresh timeout period, then RSVP can tolerate K-1 successive RSVP packet losses without falsely erasing a reservation.
The state maintained by RSVP is dynamic:
  • To change the set of senders Si or to change any QoS request, a host simply starts sending revised Path and/or Resv messages. The result will be an appropriate adjustment in the RSVP state in all nodes along the path.
HTML version of Basic Foils prepared 15 April 98

Foil 14 RSVP's Soft State

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
In steady state, refreshing is performed hop-by-hop, to allow merging.
  • When the received state differs from the stored state, the stored state is updated.
  • If this update results in modification of state to be forwarded in refresh messages, these refresh messages must be generated and forwarded immediately, so that state changes can be propagated end-to-end without delay.
  • Propagation of a change stops when and if it reaches a point where merging causes no resulting state change.
    • This minimizes RSVP control traffic due to changes and is essential for scaling to large multicast groups.
HTML version of Basic Foils prepared 15 April 98

Foil 15 Teardown

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Two types of RSVP teardown message:
  • PathTear message travels towards all receivers downstream from its point of initiation and deletes path state, as well as all dependent reservation state, along the way.
  • ResvTear message deletes reservation state and travels towards all senders upstream from its point of initiation.
A teardown request may be initiated either by sender or receiver, or by a router as the result of state timeout.
  • State change will be propagated immediately to the next node, but only if there will be a net change after merging. As a result, an ResvTear message will prune the reservation state back (only) as far as possible.
HTML version of Basic Foils prepared 15 April 98

Foil 16 Confirmations

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
To request a confirmation for its reservation request, receiver Rj includes in the Resv message a confirmation request object containing Rj's IP address.
  • At each merge point, only the largest flowspec and any accompanying confirmation-request object is forwarded upstream.
  • If the reservation request from Rj is equal to or smaller than the reservation in place on a node, its Resv is not forwarded further
    • If the Resv included a confirmation-request object, a ResvConf message is sent back to Rj.
HTML version of Basic Foils prepared 15 April 98

Foil 17 Confirmations

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Confirmation mechanism implications:
  • A new reservation request with a flowspec larger than any in place for a session will normally result in either a ResvErr or a ResvConf message back to the receiver from each sender. In this case, the ResvConf message will be an end-to-end confirmation.
  • The receipt of a ResvConf gives no guarantees:
    • Assume the first two reservation requests from receivers R1 and R2 arrive at the node where they are merged.
    • R2, whose reservation was the second to arrive at that node, may receive a ResvConf from that node while R1's request has not yet propagated all the way to a matching sender and may still fail.
    • Thus, R2 may receive a ResvConf although there is no end-to-end reservation in place. R2 may also receive a ResvConf followed by a ResvErr.
HTML version of Basic Foils prepared 15 April 98

Foil 18 RSVP Tunneling

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
RSVP must provide correct protocol operation across an arbitrary "cloud" of non-RSVP routers.
  • If such a cloud has sufficient capacity, it may still provide acceptable realtime service.
  • RSVP automatically tunnels through non-RSVP clouds since routing and reservation functions are independent
    • When a Path message traverses a non-RSVP cloud, it carries to the next RSVP-capable node the IP address of the last RSVP-capable router before entering the cloud. This effectively constructs a tunnel through the cloud for Resv messages, which can then be forwarded directly to the next RSVP- capable router on the path(s) back towards the source.
HTML version of Basic Foils prepared 15 April 98

Foil 19 RSVP's Host model

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
Before a session can be created, the session identification, comprised of DestAddress and perhaps the generalized destination port, must be assigned and communicated to all the senders and receivers by some out-of-band mechanism.
How this is done is not part of the RSVP specification
For multicast sessions, IGMP may be used
HTML version of Basic Foils prepared 15 April 98

Foil 20 RSVP's Host model

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
When an RSVP session is being set up, the following events happen at the end systems.
  • 1. A receiver joins the multicast group specified by DestAddress, using IGMP.
  • 2. A potential sender starts sending RSVP Path messages to the DestAddress.
  • 3. A receiver application receives a Path message.
  • 4. A receiver starts sending appropriate Resv messages, specifying the desired flow descriptors.
  • 5. A sender application receives a Resv message.
  • 6. A sender starts sending data packets.
HTML version of Basic Foils prepared 15 April 98

Foil 21 RSVP's Host Model

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
1. and 2. may happen in either order.
Suppose that a new sender starts sending data (6) but there are no multicast routes because no receivers have joined the group (1).
  • The data will be dropped at some router node until receivers(s) appear.
Suppose that a new sender starts sending Path messages (2) and data (6) simultaneously, and there are receivers but no Resv messages have reached the sender yet.
  • The initial data may arrive at receivers without the desired QoS. The sender could mitigate this problem by awaiting arrival of the first Resv message (5); however, receivers that are farther away may not have reservations in place yet.
HTML version of Basic Foils prepared 15 April 98

Foil 22 RSVP's Host Model

From Part II of RSVP Reservation Protocol CPS640 Internet and Multimedia Technologies -- Spring 98. *
Full HTML Index
If a receiver starts sending Resv messages (4) before receiving any Path messages (3), RSVP will return error messages to the receiver.
The receiver may simply choose to ignore such error messages, or it may avoid them by waiting for Path messages before sending Resv messages.
A specific application program interface (API) for RSVP is not defined in its protocol spec since it may be host system dependent.
© Northeast Parallel Architectures Center, Syracuse University, npac@npac.syr.edu

If you have any comments about this server, send e-mail to webmaster@npac.syr.edu.

Page produced by wwwfoil on Sun Nov 29 1998