Re: int-serv over e.g. ATM

Mark W Garrett <mwg@faline.bellcore.com> Thu, 09 November 1995 21:16 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20155; 9 Nov 95 16:16 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa20151; 9 Nov 95 16:16 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id PAA13446; Thu, 9 Nov 1995 15:47:10 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id PAA06635 for rolc-out; Thu, 9 Nov 1995 15:50:45 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id PAA06625 for <rolc@nexen.com>; Thu, 9 Nov 1995 15:50:34 -0500
Received: from faline.bellcore.com (faline.bellcore.com [128.96.39.9]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id PAA13320 for <rolc@nexen.com>; Thu, 9 Nov 1995 15:36:25 -0500
Received: (from mwg@localhost) by faline.bellcore.com (8.6.9/8.6.10) id PAA00221; Thu, 9 Nov 1995 15:44:25 -0500
Date: Thu, 9 Nov 1995 15:44:25 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark W Garrett <mwg@faline.bellcore.com>
Message-Id: <199511092044.PAA00221@faline.bellcore.com>
To: int-serv@isi.edu, jh@lohi.dat.tele.fi, rolc@nexen.com, rsvp@isi.edu
Subject: Re: int-serv over e.g. ATM
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

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.			mwg@faline.bellcore.com
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------