Re: int-serv over e.g. ATM

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>fi>, Juha Heinanen writes:
> curtis,
> 
> you say that a border box to an nbma (which can be the source itself)
> can determine whether to shortcut by looking into the qos request only.
> 
> lets assume that you have a atm lan with 500 hosts and one single
> router.  let also assume that the hosts don't all share a common address
> prefix.  now if a wants to talk to b and a and b have different address
> prefixes, how can the source figure out by looking into qos only if it
> should send the the rsvp request to the router or create a direct vc?

This is the blind leading the blind, so ... please excuse me if the
details aren't quite right.  Here is how I would envision this being
accomplished.

Regardless of the mechanisms that come into play in setting up a path,
there needs to be a way to determine if a given path can support the
additional capacity.

In your example the router with 500 hosts would no longer be able to
support additional VCs or provide the QoS or media capacity to the
router may saturate.  If the host did not have apriori knowledge that
the QoS could not be granted, it would try to use RSVP.  In RSVP the
repient initiates reservation.  When RESV is sent, either a PATH or
PERR is returned.  If PERR is returned, a direct connection can be set
up.  If the host (or a router acting on the behelf of a host not
directly connected to the NBMA) did know apriori that a shared VC or a
hop by hop path cannot accomodate a certain QoS, the step of probing
the lower cost path with RESV can be skipped and a VC set up
immediately, and then a RESV sent to confirm (in case the other end is
off NBMA and still cannot be reached with the requested QoS).

Once set up, the VC would continue to be used.

> if everybody would always go through the router, the router would be
> very soon swamped and couldn't serve any more flows.  so my rule would
> be "switch always when you can and route if you can't", i.e., that
> shortcut would be the default.

This is one heuristic that could be used as the "a priori information"
used to set up a direct connection without even trying an indirect
connection.  The heuristic might be "never trust this particular
router if you want a certain level of QoS".

On the other hand, SVCs may cost money.  If the router is set up well
it will require that some capacity is reserved for non-QoS traffic for
things like DNS and it will be set up to admit QoS VCs only until
their is risk of not being able to sustain the load.  If you are
sitting at the host and don't think the router is well set up and does
this, you can simply configure the layer sitting bnetween RSVP and ATM
to always go for the VC first, and always return PERR if you get a
RESV on a shared VC from the router.

If you can often use either a shared VC to the router (shared with
other traffic from the same router) or use a VC to that router rather
than a direct VC all the way, you might still get the QoS you want and
reduce your costs when the router is lightly loaded, and get the QoS
you want when rejected using a direct VC.

> by the way, if there are several routers on the path, how can the source
> be sure that the routers all support rsvp?  does rsvp routing protocol
> provide information about the whole path to the source?
> 
> -- juha

I think that just came up on the RSVP list.  RSVP can be forwarded to
non-RSVP portions of the topology that are believed (by the local
administrators) to be mostly uncongested and capable of supporting a
given QoS.  The argument was made that end systems need to know that
this decision was made.  IMO this should never occur (forwarding RSVP
through a non-RSVP portion of topology) if the Rspec was for any form
of guarenteed service (unless it was certain that the reservation
could be met, due to something like gross overprovisioning).  If the
Rspec was for a predictive service, then it is really a judgement
call, prefereably made based on very reliable basis.  But I'm speaking
here about something that shouldn't be since I'm only a lurker on RSVP.

Curtis