Re: int-serv over e.g. ATM

[Jon Crowcroft <[e-mail]>]

 >   This is again a non-problem, at least architecturally.  The
 >   link going toward a portion of the Internet which doesn't
 >   have rsvp can only carry best-effort traffic.  It's like
 >   connecting TM4.0 capable ATM switches to UNI3.1 switches.
 >   You just don't have ABR capability available on that path.
 
 >yes, but if the rsvp routing protocol can't tell to the host that there
 >is an rsvp capable path all the way to the destination, the source has
 >to probe it by trying to make an rsvp reservation, which is equivalent
 >to sending an nbma arp.  so, it would make sense also in this case to
 >apply the rule "shortcut always if you can and route if you can't".

 juha

if RSVP can operate over a multihop IP path, at each hop there is an
interface between RSVP and either an IP QoS queueing element, or a
shim that carries thru the local request to the link (or whatever)
level QoS queueing element....this shim is only there at the RSVP
reservation time, and is not something invoked per packet - once the
mapping from packet pattern to flow spec is in place, the forwarding
engine/scheduler is ready to roll on every packet...

the "shortcut" you propose only applies to the shim between RSVP and
(say Q.2931) the lower level where there is one - why bother removing
it?

it just makes the code ugly...and less portable..

 jon