Previous

Content

Next 

1.2.- RSVP Reservation Services

  
Data Flows
RSVP defines a "session" to be a data flow defined by the triple: (DestAddress, ProtocolId [, DstPort]), where DestAddress is the IP destination address of the data packets and may be unicast or multicast, ProtocolID is the IP protocol ID, and the optional parameter DstPort is a "generalized destination port", i.e., some further demultiplexing point in the transport or application protocol layer. It could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information. However, the basic protocol documented here supports only UDP/TCP ports as generalized ports. Note that it is not strictly necessary to include DstPort in the session definition when DestAddress is multicast, since different sessions can always have different multicast addresses. However, DstPort is necessary to allow more than one unicast session addressed to the same receiver host.
RSVP treats each session independently, and when this document omits the implied qualification, we are talking about the "same session".
Reservation Model
A RSVP reservation request consists of a "flowspec" plus a "filter spec"; the pair is called a "flow descriptor". The flowspec specifies a desired QoS. The filter spec, together with a session specification, defines the set of data packets (the flow) to receive the QoS defined by the flowspec.
The flowspec is used to set parameters in the node's packet scheduler or other link layer mechanism, while the filter spec is used to set parameters in the packet classifier. Data packets that do not match any of the filter specs for the session are handled as best-effort traffic.  

The flowspec in a reservation request will generally include a service class and two sets of numeric parameters: (1) an "Rspec" (R for `reserve') that defines the desired QoS, and (2) a "Tspec" (T for `traffic') that describes the data flow.
In the interest of simplicity (and to minimize layer violation), the basic filter spec format defined in the present RSVP specification has a very restricted form: sender IP address and optionally the UDP/TCP port number SrcPort.

Because the UDP/TCP port numbers are used for packet classification, each router must be able to examine these fields. This raises some potential problems.
  1. It is necessary to avoid IP fragmentation of a data flow for which a resource reservation is desired. RFC 2210 specifies a procedure for applications using RSVP facilities to compute the minimum MTU over a multicast tree and return the result to the senders.
     
  2. IP-level Security may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security is described in RFC 2207.

There are some other consideration related to IPv6. Have a look to the original document. L.B.
RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs."downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. See below. LB.

At each intermediate node, a reservation request triggers two general actions, as follows:
  1. Make a reservation on a link
     
      The RSVP process passes the request to admission control and policy control. If either test fails, the reservation is rejected and the RSVP process returns an error message to the appropriate receiver(s). If both succeed, the node sets the packet classifier to select the data packets defined by the filter spec, and it interacts with the appropriate link layer to obtain the desired QoS defined by the flowspec.

    The detailed rules for satisfying an RSVP QoS request depend upon the particular link layer technology in use on each interface. For a simple leased line, the desired QoS will be obtained from the packet scheduler in the link layer driver, for example. If the link-layer technology implements its own QoS management capability, then RSVP must negotiate with the link layer to obtain the requested QoS. Note that the action to control QoS occurs at the place where the data enters the link-layer medium, i.e., at the upstream end of the logical or physical link, although an RSVP reservation request originates from receiver(s) downstream.
         		  
  2. Forward the request upstream
     
      A 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.

    The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by- hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be "merged" as reservations travel upstream.    		  
When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. 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 need not be forwarded further; 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 all the way to the sender(s).

The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path either accepts or rejects the request. This scheme provides no easy way for a receiver to find out the resulting end-to-end service. Therefore, RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA). With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. The results ("advertisements") are delivered by RSVP to the receiver hosts and perhaps to the receiver applications. The advertisements may then be used by the receiver to construct, or to dynamically adjust, an appropriate reservation request.
Reservation Styles
A reservation request can be:
  1. distinct:
     
      where an individual and distinct reservation is made for packets of each upstream sender.
         		  
  2. shared:
     
      where a shared or common reservation is made for packets of all selected upstream senders.
         		  
  3. explicit:
     
      where an "explicit" list of all requested senders is done; here each filter spec must match exactly one sender.
         		  
  4. wildcard:
     
      where a "wildcard" that implicit select all the senders is done; here no filter spec is needed.  
Based on these possibilities, three (3) reservation styles are defined as is shown in the next figure:

  1. Fixed-Filter (FF) Style
     
    The FF style implies the options: "distinct" reservations and "explicit" sender selection. Thus, 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.
         		  
      Symbolically, we can represent an elementary FF reservation request 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 at the same time, using a list of flow descriptors: FF( S1{Q1}, S2{Q2}, ...)
         		  
      The total reservation on a link for a given session is the `sum' of Q1, Q2, ... for all requested senders.
         		  
  2. Shared Explicit (SE) Style
     
    The SE style implies the options: "shared" reservation and "explicit" sender selection. Thus, an SE-style reservation creates a single reservation shared by selected upstream senders. Unlike the WF style (see below), the SE style allows a receiver to explicitly specify the set of senders to be included.

    We can represent an SE reservation request containing a flowspec Q and a list of senders S1, S2, ... by: SE( (S1,S2,...){Q} )
         		  
  3. Wildcard-Filter (WF) Style
     
    The WF style implies the options: "shared" reservation and "wildcard" sender selection. Thus, a WF-style reservation creates a single reservation shared by flows from all upstream senders. 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. A WF-style reservation  is propagated upstream towards all sender hosts, and it automatically extends to new senders as they appear.

    Symbolically, we can represent a WF-style reservation request by: WF( * {Q})

    where the asterisk represents wildcard sender selection and Q represents the flowspec.    		  
Shared reservations (WF, SE), are appropriate for those multicast applications in which multiple data sources are unlikely to 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). On the other hand, the FF style, which creates distinct reservations for the flows from different senders, is appropriate for video signals.
The RSVP rules disallow merging of shared reservations with distinct reservations, since these modes are fundamentally incompatible. They also disallow merging explicit sender selection with wildcard sender selection, since this might produce an unexpected service for a receiver that specified explicit selection. As a result of these prohibitions, WF, SE, and FF styles are all mutually incompatible.
  It would seem possible to simulate the effect of a WF reservation using the SE style. When an application asked for WF, the RSVP process on the receiver host could use local 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.
Examples of Styles

The figure above represents a router having two incoming interfaces a and b and two outgoing interfaces c and d. There are three upstream senders. S1 which packets arrive through previous hop to interface a, and S2, S3, which packets arrive through previous hop to interface b. There are three downstream receivers: packets bound for R1 are routed via outgoing interface c, and packets bound for R2 and R3 are routed via outgoing interface d. We also assume that interface d is connected to a broadcast LAN (where replication occurs) and that R2 and R3 are reached via different next hop routers. Finally, we assume that packets from each Si are routed to both outgoing interfaces.
In the examples below, B represents one unit of some base resource quantity (i.e., bandwidth). The "Receives" column shows the reservation requests received over interfaces c and d; the "Reserves" column shows the resulting reservation state for each interface; finally, the "Sends" column shows the reservation requests that are sent upstream to previous hops connecting to interfaces a and b.
Let's see now the different examples of styles:

This figure shows the WF (Wildcard-Filter) style. Explanation is as follows: next hop to the right of interface c requested 4B from receiver R1, and next hop to the right of interface d requested 3B and 2B from receivers R2 and R3 respectively. The request on interface c is then 4B, and the two request on interface d are merged into one effective flowspec 3B. Reservations on interfaces c and d must be merged in order to forward requests upstream, as a result, the larger flowspec 4B (on interface c) is forwarded upstream to each previous hop.

This figure shows the FF (Fixed-Filter) style. Each reservation received on interfaces c and d is individual in the sender being requested and the resources being solicited; on interface c, the reservations are copied identically because sender are different. On interface d, because we have two requests for sender S1, the larger of them is selected to be applied. On the other hand, the two requests for sender S1 are merged into the single request FF(S1{4B}). This request is sent to interface a's previous hop.

This figure shows the SE (Shared-Explicit) style. When these reservations are merged, the resulting filter spec is the union of the original filter specs, and the resulting flowspec is the largest of them.

In this new example, packets from sender S2 and S3 are not forwarded to interface c (suppose there exist a shortest path to R1 not traversing node c) This is represented in the top of the figure. In the bottom the WF style reservation is shown. Since there is no route from b to c, the reservation forwarded out interface b considers only reservations on interface d.
   

Previous

Content

Next