|
Previous
|
Content
|
Next
|
|
| 1.3.- RSVP
Protocol Mechanisms |
|
 |
|
| RSVP Messages |
| Next figure illustrates RSVP's model of
a router node. |
|
|
| There are two fundamental RSVP message
types: Resv and Path. |
| Each receiver sends RSVP reservation
request (Resv) messages upstream towards the senders.
These messages follow exactly the reverse path the data packets will use.
Going upstream they create and maintain "reservation state" in each
node along the path(s). When Resv messages finally reach the senders,
each sender host transmits RSVP Path messages downstream along the
uni-/multicast routes provided by the routing protocol(s), following the
paths of the data. These Path messages store "path state" in
each node along the way. |
| The path state includes the unicast IP
address of the previous hop node used to route the Resv message
hop-by-hop in the reverse direction, and the following additional
information: |
- A Sender Template, which describes the format of data packets
the sender will originate. This template is in the form of a filter
spec used to select sender's packets from others in the same session
on the same link. The sender template has the same power and format
as the Resv message's filter spec. It specifies the sender IP
address and optionally the UDP/TCP sender port.
- A Sender Tspec, which defines the traffic characteristics of
the data flow the sender will generate. This information is used to
prevent over-reservation and Admission Control failures.
- An OPWA advertising information known as an "Adspec".
This information is passed to the local control traffic, which returns it
adecuately updated; the updated version is then forwarded downstream in
Path messages.
|
|
|
|
| Path messages are sent with the same
source and destination address as the data, so that they are routing
correctly through non-RSVP clouds. Resv messages are sent
hop-by-hop; each RSVP-node forwards a Resv message to the
unicast address of a previous RSVP hop. |
| Merging Flowspecs |
| A Resv message forwarded to a previous
hop carries a flowspec that is the "largest" of the
flowspecs requested by the next hops to which the data flow will be
sent. The flowspecs have been merged. Another case is when there are
multiple reservation requests from different next hops for the same session
and having the same filter spec; then RSVP should install only
one reservation on that interface. Again, the installed reservation will
have an effective flowspec being the largest of the flowspec
requested. Since flowspecs are opaque to RSVP, the rules for
comparing them must be defined and implemented outside RSVP proper. |
| Flowspecs contain Tspec and
Rspec components, each of which may be multi-dimensional. Then, 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, there is no exist a larger one. In this case, the merging routing
must be able to return a third flowspec that is at least as large as
each. This is known as the "least upper bound" (LUB). When a
flowspec at least as small is needed, this is known as the "greatest
lower bound" (GLB). |
| The steps to calculate the effective
flowspec (Re,Te), where Re is the effective Rspec
and Te is the effective Tspec, are: |
- An effective flowspec is determined for the outgoing interface.
Flowspecs from different next hops are merged by computing the
LUB of the flowspecs. The result is a flowspec opaque to
RSVP consisting of a pair (Re,Resv_Te), where Re is
the effective Rspec and Resv_Te is the effective Tspec.
- A service-specific calculation of Path_Te, i.e., the sum of all
Tspecs that were supplied in Path messages from different
previous hops is performed.
- (Re, Resv_Te) and Path_Te are passed to traffic control
where it computes the effective flowspec as the "minimum" of
Path_Te and Resv_Te, in a service-dependent manner.
|
| Soft State |
| RSVP takes a "soft state"
approach where soft state are created in routers and hosts which are
periodically refreshed by Path and Resv messages. Any state is
deleted if no matching refresh messages are received before the expiration
of a "cleanup timeout" interval. States may also be explicitly
deleted by a "teardown" message. |
| Path and Resv messages are
idempotent. When a route changes, the next Path message will
initializae the path state on the new route, and future Resv
messages will establish reservation states there. States on previous
now unused segments will timeout. |
| RSVP messages are IP datagrams
with no reliability enhacement. Refresh messages are expected to handle any
occasional loss of messages. If the cleanup timeout is set to K
times the refresh timeout period, then up to K-1 succesive
packet losses can be tolerated. Anyway, some minimal bandwidth should be
guaranteed to RSVP messages to protect them against congestion
losses. |
| States are dynamics. To update them, a host
simply starts sending revised Path and/or Resv messages. The
result will be an appropriate adjustment on state in all nodes along the
path; unused state will timeout if not previously torn down. |
| In steady state, states are refreshed
hop-by-hop to allow merging. When a new received state differs
from the stored state, the old one is updated. If this update results in
modification of state to be forwarded in refresh messages, these messages
are generated and forwarded inmediately, so that changes propagate
end-to-end asap. |
| State changes propagation stop when a point is
reached where merging causes no resulting state change. This minimize
control traffic due to changes and improve scaling. |
| One state received on a particular interface
I* should never be forwarded out the same interface. Also, state that is
forwarded out interface I* must be computed using only state that
arrive on interfaces different from I*. And finally, state from
Resv messages received from outgoing interface Io should be
forwarded to incoming interface Ii only if Path messages from
Ii are forwarded to Io. |
| Teardown |
|
Teardown messages remove path or reservation state
inmediately. Although it is not necessary at all, it is recommended that all
end hosts send a teardown request as soon as an application finished. |
|
There are two types of teardown messages, PathTear and
ResvTear. A PathTear message travels downstream from sender
toward all receivers deleting path state and dependent reservation
state. A ResvTear message travels upstream from receiver towards
all senders deleting reservation state. |
|
A teardown request may be initiated either by an application
in an end system (sender or receiver), or by a router as the result of
state timeout or service preemption. Once initiated, it must be
forwarded hop-by-hop without delay. |
|
Like all other messages, teardown requests are not delivered
reliable. Any loss will not cause a failure because the unused state
will eventually time out even though it is not explicitly deleted, if a
router fails to receive a teardown message beyond the loss point. |
|
For path state, the granularity for teardown is a
single sender. For reservation state, the granularity is an
individual filter spec. |
|
Errors |
|
There are two error messages, ResvErr and PathErr. PathErr
are sent upstream to the sender that created the error; they do not
change path state in the nodes through which they pass. |
|
ResvErr are more complex. Since a request that fails may be the
result of merging a number of requests, a reservation error must be
reported to all of the responsible receivers. Merging heterogeneous requests
creates a difficult known as the "killer-reservation" problem, in
which one request could deny service to another. There are two
killer-reservation problems. |
- Called KR-I, arises when there is already a reservation Q0
in place. If another receiver now makes a larger reservation
Q1>Q0, the result of merging both may be rejected by admission
control in some upstream node. This must not deny
service to Q0. Then, when admission control fails for a
reservation request, any existing reservation must be left
in place.
- Called KR-II, is the converse. A receiver making a
reservation Q1 is persistent even though its admission has been
rejected for Q1 in some node. This must not prevent a different
receiver from now establishing a smaller reservation Q0 that would
suceed if not merged with Q1. In this case, a ResvErr message
establishes in each node an state called "blockade", which modifies
the merging procedure to omit the offending flowspec
(Q1) from the merge, allowing a smaller request to be forwarded and
established.
|
|
A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of
the failure point for the following reasons: |
- There are two possible reasons for a receiver persisting in a failed
reservation: 1) it is polling for resources availability
along the entire path, or 2) it wants to obtain the desire QoS
along as much of the path as possible. Then, in the second case, and
perhaps in the first case, it will want to hold onto the reservations it
has made downstream from the failure.
- If these downstream reservations were not retained, the protocol
responsiveness to certain transient failures would be impaired. Suppose a
route that "flaps" to an alternate route that is congested, so an
existing reservation suddenly fails, then quickly recovers to the original
route. The blockade state in each downstream router must not
remove the state or prevent its inmediat refresh.
- If we did not refresh the downstream reservations, they might
time out, to be restored every Tb seconds (where Tb is the
blockade timeout interval). Such intermittent behavior migth be
very disturbed for users.
|
|
Confirmation |
|
To request a confirmation a 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 its
confirmation-request object is forwarded upstream. If the Rj's
reservation-request is equal to or smaller than the reservation in place
on a node, its Resv is not forwarded further but if a
confirmation-request object is present, a ResvConf message is
sent back to Rj. |
|
This confirmation mechanism has the following consequences: |
- Any reservation request will result in either a ResvErr or a
ResvConf message sent back to the receiver from each sender. The
ResvConf message is end-to-end.
- The receipt of a ResvConf gives no guarantees. A ResvConf
message may be received followed by a ResvErr message.
|
|
Policy Control |
|
|
|
|
Previous
|
Content
|
Next
|