Re: int-serv over e.g. ATM

Juha Heinanen <jh@lohi> Thu, 09 November 1995 16:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14667; 9 Nov 95 11:39 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14663; 9 Nov 95 11:38 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 LAA10793; Thu, 9 Nov 1995 11:11:07 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id LAA02651 for rolc-out; Thu, 9 Nov 1995 11:19:13 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id LAA02641 for <rolc@nexen.com>; Thu, 9 Nov 1995 11:19:06 -0500
Received: from lohi (lohi.dat.tele.fi [193.167.64.161]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id LAA19166 for <rolc@nexen.com>; Thu, 9 Nov 1995 11:17:00 -0500
Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id RAA07244; Thu, 9 Nov 1995 17:28:19 +0200
Date: Thu, 9 Nov 1995 17:28:19 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi>
Message-Id: <199511091528.RAA07244@lohi.dat.tele.fi>
To: curtis@ans.net
CC: mwg@faline.bellcore.com, deering@parc.xerox.com, int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu
In-reply-to: <199511090354.WAA01614@brookfield.ans.net> (curtis@ans.net)
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/

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?

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.

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