HELP! * GREY=local Full HTML for

LOCAL foilset RSVP -- Reservation Protocol

Given by Marek Podgorny at Large Web Application Class, CPS600/640 Fall 1997 on Fall Semester 97. Foils prepared 17 Feb 1997
Abstract * Foil Index for this file

See also color IMAGE
This module discusses details of the Reservation Protocol (RSVP)
RSVP is a part of the Integrated Services Model for Internet
RSVP is a tool to establish Quality of Service over traditional packet networks

Table of Contents for full HTML of RSVP -- Reservation Protocol

1 RSVP: Reservation Protocol
2 Abstract
3 What is RSVP
4 RSVP Basic Functionality
5 RSVP: A Receiver-Oriented Protocol
6 RSVP: A Receiver-Oriented Protocol (Continued)
7 RSVP Basic Functionality
8 RSVP Operational Principles
9 RSVP Operational Principles (Continued)
10 RSVP Operational Principles (Continued)
11 RSVP Operational Principles (Continued)
12 RSVP Operational Principles (Continued)
13 RSVP Data Flows
14 RSVP Data Flows (Continued)
15 RSVP Reservation Model
16 RSVP Reservation Model (Continued)
17 RSVP Reservation Model (Continued)
18 RSVP Reservation Model (Continued)
19 RSVP Reservation Model (Continued)
20 RSVP Reservation Model (Continued)
21 RSVP Reservation Model (Continued)
22 RSVP Reservation Model (Continued)
23 RSVP Reservation Styles (Continued)
24 RSVP Reservation Styles (Continued)
25 RSVP Reservation Styles (Continued)
26 RSVP Reservation Styles (Continued)
27 RSVP Reservation Styles (Continued)
28 RSVP Reservation Styles (Continued)
29 RSVP Reservation Styles (Continued)
30 RSVP Reservation Styles
31 RSVP Reservation Styles (Continued)
32 RSVP Reservation Styles (Continued)
33 Examples of Reservation Styles
34 Examples of Reservation Styles (Continued)
35 Examples of Reservation Styles
36 Examples of Reservation Styles (Continued)
37 Examples of Reservation Styles
38 Examples of Reservation Styles
39 Examples of Reservation Styles
40 RSVP: A list of outstanding issues

This table of Contents Abstract

HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 1 RSVP: Reservation Protocol

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Supporting Quality of Service over Packet Networks
Marek Podgorny
NPAC
Syracuse University
111 College Place
Syracuse
New York 13244-4100
Based on Internet Draft: RSVP-SPEC-10
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 2 Abstract

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
This module discusses details of the Reservation Protocol (RSVP)
RSVP is a part of the Integrated Services Model for Internet
RSVP is a tool to establish Quality of Service over traditional packet networks
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 3 What is RSVP

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP is a network control protocol that will allow Internet applications to obtain special qualities-of-service for their data flows.
  • This will generally require reserving resources along the data path(s).
  • RSVP is a component of the future "integrated services" Internet, which will provide both best-effort and real-time qualities of service
  • When an application in a host requests a specific QoS for its data stream, RSVP is used to deliver the request to each router along the path(s) of the data stream and to maintain router and host state to provide the requested service.
  • Although RSVP was developed for setting up resource reservations, it is easily adaptable to transport other kinds of network control information along data flow paths.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 4 RSVP Basic Functionality

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
RSVP supports multicast or unicast simplex data delivery. RSVP is fundamentally designed for multicasting as well as unicasting, and it treats data flow as one directional. It distinguishes the roles of data sender (e.g., hosts H1, H2) from data receiver (hosts H3, H4, H5), although in many cases the same application will play both roles.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 5 RSVP: A Receiver-Oriented Protocol

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP is receiver-oriented.
  • To efficiently handle heterogeneous receivers and dynamic group membership, RSVP makes receivers responsible for requesting resource reservations. Each receiver can request a QoS that is tailored to its particular requirement, by sending RSVP reservation messages upstream towards the senders.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 6 RSVP: A Receiver-Oriented Protocol (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
RSVP reservation messagesflowing upstream. Just as thedata branches out in routers R1, R3, and R4, so the reservation messages going upstream are "merged". A single reservation message need only flow upstream until it is merged with another reservation.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 7 RSVP Basic Functionality

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP handles heterogeneous receivers.
  • Different hosts on the same multicast delivery tree may have different capabilities and therefore need different QoS.
RSVP adapts to changing group membership as well as changing routes.
  • For dynamic adaptability and robustness, RSVP maintains "soft state" in the routers. The only permanent state is in the end systems, which periodically send their RSVP control messages to refresh the router state. In the absence of refresh, RSVP state in routers will time out and be deleted.
RSVP is not a routing protocol.
  • The RSVP daemon consults the local routing protocol(s) to obtain routes. RSVP is designed to operate with existing and future unicast and multicast routing protocols. A host sends IGMP messages to join a multicast group, but it uses RSVP messages to reserve resources along the delivery path(s) from that group.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 8 RSVP Operational Principles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
A QoS request from an application is passed to the local RSVP implementation (user daemon). RSVP passes the request to all the nodes along the reverse data path to the destination.
  • RSVP provides transparent operation through routers that do not support it.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 9 RSVP Operational Principles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
At each node, RSVP applies a local decision procedure (admission control) to the QoS request.
  • If admission control succeeds, it sets the parameters to the Classifier and Packet Scheduler to obtain the desired QoS. If admission control fails at any node, RSVP returns an error indication to the application.
Each router in the path capable of resource reservation will pass incoming data packets to a Packet Classifier and then queue them in a Packet Scheduler.
  • The Packet Classifier determines the route and the QoS class for each packet. The Scheduler allocates a particular outgoing link for packet transmission.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 10 RSVP Operational Principles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
For QoS-active link-layer media the packet scheduler is responsible for negotiation with the link layer to obtain the QoS requested by RSVP.
  • Mapping to the link layer QoS may be accomplished in a number of possible ways; the details will be medium-dependent. On a QoS-passive medium such as a leased line, the scheduler itself allocates packet transmission capacity. The scheduler may also allocate other system resources such as CPU time or buffers.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 11 RSVP Operational Principles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP is designed to scale well for very large multicast groups.
  • Since both the membership of a large group and the topology of large multicast trees may change with time, the RSVP design assumes that router state for traffic control will be built and destroyed incrementally. Hence, RSVP uses "soft state" in the routers, i.e., RSVP sends periodic refresh messages to maintain the state along the reserved path; in absence of refreshes, the state will automatically time out and be deleted.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 12 RSVP Operational Principles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP reserves resources for simplex data streams, i.e., it reserves resources in only one direction on a link
  • A sender is logically distinct from a receiver. However, the same application may act as both sender and receiver.
RSVP mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast delivery paths.
  • RSVP transfers reservation parameters as opaque data (except for certain well-defined operations on the data), which it simply passes to admission control and to the Packet Scheduler and Classifier for interpretation.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 13 RSVP Data Flows

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP defines a "session" as a data flow with a particular destination and transport-layer protocol.
  • The destination of a session is generally defined by DestAddress, the IP destination address of the data packets, and possibly by DstPort, a "generalized destination port". RSVP treats each session independently.
  • DestAddress is a group address for multicast delivery or the unicast address of a single receiver. DstPort could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 14 RSVP Data Flows (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
For unicast transmission, there will be a single destination host but there may be multiple senders; RSVP can set up reservations for multipoint to single point transmission.
Multicast distribution forwards a copyof each data packet from a sender Si to every receiver Rj; a unicast distribution session has a single receiver R. Each sender Si may be running in a unique Internet host, or a single host may containmultiple senders, distinguished by generalized source ports.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 15 RSVP Reservation Model

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
An elementary RSVP reservation request consists of a "flowspec" and a "filter spec"; this pair is called a "flow descriptor".
  • The flowspec specifies a desired QoS. It is used to set parameters to the node's packet scheduler, assuming that admission control succeeds.
  • The filter spec, together with a session specification, defines the set of data packets -- the "flow" -- to receive the QoS defined by the flowspec. Filter spec is used to set parameters in the packet classifier.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 16 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
Data packets that are addressed to a particular session but do not match any of the filter specs for that session are handled as best-effort traffic.
Please, note "upstream" and "downstream" convention!
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 17 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
The flowspec in a reservation request will generally include a service class and two sets of numeric parameters:
  • An "Rspec" (R for `reserve') that defines the desired QoS,
  • A "Tspec" (T for `traffic') that describes the data flow.
  • The formats and contents of Tspecs and Rspecs are determined by the integrated service model, and are generally opaque to RSVP.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 18 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Filter specs may select arbitrary subsets of the packets in a given session.
  • Subsets might be defined in terms of
    • Senders (i.e., sender IP address and generalized source port),
    • A higher-level protocol
    • Any fields in any protocol headers in the packet.
    • Example: filter specs might be used to select different subflows in a hierarchically-encoded signal by selecting on fields in an application-layer header.
    • Current RSVP software does not yet support this option.
  • Because the UDP/TCP port numbers are used for packet classification, each router must be able to examine these fields.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 19 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
RSVP reservation request messages originate at receivers and are passed upstream towards the sender. At each intermediate node, two general actions are taken:
  • Make a reservation
    • The request is passed to admission control and policy control.
    • If either test fails, the reservation is rejected and RSVP returns an error message to the appropriate receiver.
    • If both succeed, the node uses the flowspec to set up the packet scheduler for the desired QoS and the filter spec to set the packet classifier to select the appropriate data packets.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 20 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Forward the request upstream
  • The reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request.
Forwarded reservation request may differ from the request that it received from downstream:
  • Reservations for the same sender from different downstream branches of the tree are "merged" as reservations travel upstream; a node forwards upstream only the reservation request with the "maximum" flowspec.
  • Reservation might be purposefully modified by traffic control.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 21 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
The receiver sending a reservation request can request a confirmation message.
  • A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater than that being requested.
  • At that point, the arriving request is merged with the reservation in place and the node may then send a reservation confirmation message back to the receiver.
  • Note that the receipt of a confirmation is only a high-probability indication, not a guarantee, that the requested service is in place. This uncertainity results from possible security policies.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 22 RSVP Reservation Model (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
The basic RSVP reservation model is "one pass":
  • This scheme provides no easy way for a receiver to find out the resulting end-to-end service.
  • RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA)
  • With OPWA, RSVP control packets are sent downstream to gather information that may be used to predict the end- to-end QoS. The results are delivered by RSVP to the receiver hosts. The results may then be used by the receiver to dynamically adjust the reservation request.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 23 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
A reservation request includes a set of options which are collectively called the reservation "style".
  • Distinct or shared: the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else make a single reservation that is "shared" among all packets of selected senders.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 24 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
Senders' selection: an "explicit" list of all selected senders, or a "wildcard" that implicitly selects all the senders to the session.
  • Explicit sender-selection reservation: each filter spec must match exactly one sender
  • Wildcard sender-selection: no filter spec is needed.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 25 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Wildcard-Filter (WF) Style
  • The WF style implies the options: "shared" reservation and "wildcard" sender selection.
  • WF-style reservation creates a single reservation into which flows from all upstream senders are mixed. This reservation may be thought of as a shared "pipe", whose "size" is the largest of the resource requests from all receivers, independent of the number of senders using it.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 26 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
A WF-style reservation is propagated upstream towards all sender hosts, and automatically extends to new senders as they appear.
Symbolically, a WF-style reservation request is represented by:
WF( * {Q} )
Where the asterisk represents wildcard sender selection and Q represents the flowspec.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 27 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Fixed-Filter (FF) Style
  • The FF style implies the options: "distinct" reservations an "explicit" sender selection.
    • An elementary FF-style reservation request creates a distinct reservation for data packets from a particular sender, not sharing them with other senders' packets for the same session.
    • The total reservation on a link for a given session is the total of the FF reservations for all requested senders. On the other hand, FF reservations requested by different receivers Rj but selecting the same sender Si must be merged to share a single reservation.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 28 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Symbolically, an elementary FF reservation request is represented by:
  • FF( S{Q} )
Where S is the selected sender and Q is the corresponding flowspec; the pair forms a flow descriptor.
  • RSVP allows multiple elementary FF-style reservations to be requested a the same time, using a list of flow descriptors: FF( S1{Q1} , S2{Q2} , ...)
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 29 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Shared Explicit (SE) Style
  • The SE style implies the options: "shared" reservation and "explicit" sender selection.
    • An SE-style reservation creates a single reservation into which flows from all upstream senders are mixed. However, like the FF style, the SE style allows a receiver to explicitly specify the set of senders.
  • We can represent an SE reservation request containing a flowspec Q and a list of senders S1, S2, ... by:
    • SE( (S1,S2,...){Q} )
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 30 RSVP Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Both WF and SE styles create shared reservations, appropriate for those multicast applications whose properties make it unlikely that multiple data sources will transmit simultaneously.
  • Packetized audio is an example of an application suitable for shared reservations; since a limited number of people talk at once, each receiver might issue a WF or SE reservation request for twice the bandwidth required for one sender (to allow some over-speaking).
  • The FF style, which creates independent reservations for the flows from different senders, is appropriate for video signals.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 31 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
The RSVP rules disallow:
  • Merging of shared reservations with distinct reservations, since these modes are fundamentally incompatible.
  • Merging explicit sender selection with wildcard sender selection, since this might produce an unexpected service for a receiver that specified explicit selection.
  • Therefore, WF, SE, and FF styles are all mutually incompatible.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 32 RSVP Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Is it possible to simulate the effect of a WF reservation using the SE style?
  • When an application asked for WF, the RSVP daemon on the receiver host could use local path state to create an equivalent SE reservation that explicitly listed all senders.
  • However, an SE reservation forces the packet classifier in each node to explicitly select each sender in the list, while a WF allows the packet classifier to simply "wild card" the sender address and port. When there is a large list of senders, a WF style reservation can therefore result in considerably less overhead than an equivalent SE style reservation. For this reason, both SE and WF are included in the protocol.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 33 Examples of Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
Two incoming interfaces (A and B) through which data streams will arrive
Two outgoing interfaces (C and D) through which data will be forwarded
Three upstream senders (S1 - S3). Packets from sender S1 (S2 and S3) arrive through previous hop A (B, respectively).
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 34 Examples of Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Three downstream receivers. Packets bound for R1 (R2 and R3) are routed via outgoing interface C (D, respectively).
It is furthermore assumed that R2 and R3 arrive via different next hops.This illustrates the effect of a non-RSVP cloud or a broadcast LAN on interface D.
Multicast setup: data packets from each Si are routed to both outgoing interfaces
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 35 Examples of Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
Example of the WF style
  • Two possible merging situations.
    • Each of the two next hops on interface D results in a separate RSVP reservation request.
    • These two requests are merged into the effective flowspec 3B, which is used to make the reservation on interface D.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 36 Examples of Reservation Styles (Continued)

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
To forward the reservation requests upstream, the reservations on the interfaces C and D are merged; as a result, the larger flowspec 4B is forwarded upstream to each previous hop.
  • B is an arbitrary QoS parameter in all following examples
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 37 Examples of Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
Fixed-Filter (FF) style reservations.
  • The flow descriptors for senders S2 and S3, received from outgoing interfaces C and D, are packed into the request forwarded to previous hop B.
  • The three different flow descriptors for sender S1 are merged into the single request FF( S1{4B} ), which is sent to previous hop A.
  • For each outgoing interface, there is a separate reservation for each source that has been requested, but this reservation is shared among all the receivers that made the request.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 38 Examples of Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
An example of Shared-Explicit (SE) style reservations.
  • When SE-style reservations are merged, the resulting filter spec is the union of the original filter specs.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 39 Examples of Reservation Styles

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * Critical Information in IMAGE
Full HTML Index
The three earlier examples assumed that data packets from S1, S2, and S3 are routed to both outgoing interfaces.
  • Let's assume that data packets from S2 and S3 are not forwarded to interface C, e.g., because the network topology provides a shorter path for these senders towards R1, not traversing this node.
  • The table below shows WF style reservations under this assumption. Since there is no route from B to C, the reservation forwarded out interface B considers only the reservation on interface D.
HELP! * GREY=local HTML version of LOCAL Foils prepared 17 Feb 1997

Foil 40 RSVP: A list of outstanding issues

From Reservation Protocol Large Web Application Class, CPS600/640 Fall 1997 -- Fall Semester 97. * See also color IMAGE
Full HTML Index
We have only discussed the principal features of the RSVP protocol. We have not discussed any actual implementation details and we have also omitted the following important architectural issues:
  • Rules for Merging Flowspecs
  • Router Soft State description
  • Teardown of connections
  • Support for local Policy and Security
  • Automatic RSVP Tunneling
  • Description of the Host Model
All these details can be found in the Internet Draft documents.
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 Feb 23 1997