Session Maintenance and Tear-Down
After a session is initiated, it is maintained on the routers as a soft state.With a soft
state session, the path connecting two end stations can be renegotiated without
consultation with those end stations.This contrasts with a circuit-switched network,
where the connection between two end stations is a hard connection, and
when a failure occurs, the connection is broken.
This soft state session must be refreshed by periodic Path and Resv messages;
otherwise, it will be terminated after a cleanup timeout interval. RSVP’s default
interval for this cleanup timeout is some multiple of the period of the Path and
Resv messages.Therefore, if the router misses a single Path or Resv refresh, it will
not terminate the session.This kind of tolerance is necessary, since there is no
preferential QoS treatment for RSVP messages inherent to the protocol.These
messages are sent as best effort unless some provision has been made otherwise,
such as DiffServ.While this is generally not necessary, in an environment where
the traffic receiving the reservations is extremely critical (such as might be the
case on a trading floor or other financial institution), it might be best to err on
the side of caution.
NOTE
This is a good time to make mention of the fact that any AVVID, QoS or
other network deployment should always be fully tested in a lab environment,
and then tested in a noncritical subset of the production network
before large-scale deployment is considered. Only after the solution has
performed to specifications in both of these environments should it be
considered ready for production deployment.
www.syngress.com
Advanced QoS for AVVID Environments • Chapter 8 231
These soft states are dynamic in response to route changes in the network,
changes in senders or receivers, or changes in the requested QoS.There is no real
difference between the process of initiating a new reservation and refreshing an old
one. In both cases, the Path message is built with the previous hop and next hop
information, and the Resv statement is adjusted with any new QoS requirements.
NOTE
The refresh interval presents a potential problem when the routing
changes across an IP network. If a route change causes any change to
the shortest path for an active flow, packets will be forwarded over the
new route as best effort until Path and Resv messages are sent along this
new path. When this occurs, it is possible that there may not be the necessary
resources to complete the RSVP session. In this case, it is up to the
application to decide whether to terminate the session or continue besteffort
delivery. While Video traffic is somewhat forgiving, this behavior
can cause significant problems for voice, therefore, implementing RSVP
in this way may not give your traffic the desired results (i.e., good
quality) in an unstable network or one with frequent routing changes.
Good implementations of RSVP will issue tear-down messages when the
reservation is no longer needed, instead of waiting for the cleanup timeout to
remove the session.There are two types of tear-down messages: PathTear and
ResvTear. PathTear messages, like Path messages, flow in the downstream direction,
whereas ResvTear messages, like Resv messages, flow upstream. In addition
to clients issuing immediate requests for tear-downs, routers detecting a session
timeout or a loss of resources will send their own tear-down messages to
upstream (ResvTear) and downstream (PathTear) neighbors.