Subject: Re: int-serv over e.g. ATM

From: [email-masked] (Mark W Garrett)
Date: Thu, 9 Nov 1995 15:44:25 -0500

Juha,
 > .... 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?

 > ....so my rule would
 > be "switch always when you can and route if you can't", i.e., that
 > shortcut would be the default.

I don't see any architectural problem here.  Unless you're
saying that routing needs to explicitly know something about
QOS.  That's a nice concept, but I don't think we're there
yet.  (Is there a philosophical or architectural argument
against having IP routing account for QOS/TM requirements
some time in the future?)  RSVP now works under the
assumption that routing is distinct and preceeds the
resource reservation.

If you are saying a good implementation of the edge box
should be able to pick the direct path rather than an
circuitous one, well, that's obvious.  I think you
misunderstand something about rsvp.  You don't have to go
through a router to be using the rsvp/int-serv functionality
for QOS.  The case where the host interface knows that there
is a direct ATM path with appropriate QOS to the destination
and it uses that route, is a perfectly good, if degenerate,
instance of rsvp.

 > 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

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.
(Maybe there's a more complex answer to this, but I think
that's right to first order.)

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 10 Nov 1995 09:58:53 +0200

I think you

yes, i know that rsvp doesn't require a router on the 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".

i have to read yakov's draft and see how it relates to this.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 10 Nov 1995 12:52:15 +0200

jon,

so when the rsvp gets the reservation request from the application, it
as its first job sends an nhrp query regarding the destination address
and then places the call to whatever nhrp returned, which may be the
address of the final destination or that of a router on a possible
shortcuted path?

-- juha

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 10 Nov 95 09:58:56 +0000

>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

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 10 Nov 95 11:45:08 +0000

juha

i think the actual operation of the nhrp is below the level of the
rsvp api...

 jon