Re: int-serv over e.g. ATM

Juha Heinanen <jh@lohi.dat.tele.fi> Wed, 08 November 1995 20:54 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18213; 8 Nov 95 15:54 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18209; 8 Nov 95 15:54 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 PAA04701; Wed, 8 Nov 1995 15:11:39 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA22094 for rolc-out; Wed, 8 Nov 1995 14:45:02 -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 OAA22078 for <rolc@nexen.com>; Wed, 8 Nov 1995 14:44:58 -0500
Received: from lohi (lohi.dat.tele.fi [131.177.104.142]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA04438 for <rolc@nexen.com>; Wed, 8 Nov 1995 14:31:00 -0500
Received: from taimen.dat.tele.fi (taimen [193.167.64.98]) by lohi (8.6.12/8.6.12) with SMTP id TAA08810; Wed, 8 Nov 1995 19:55:11 +0200
Message-ID: <30A0EEED.3269@lohi.dat.tele.fi>
Date: Wed, 08 Nov 1995 19:54:53 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi.dat.tele.fi>
X-Mailer: Mozilla 2.0b1J (Windows; I; 32bit)
MIME-Version: 1.0
To: Mark W Garrett <mwg@faline.bellcore.com>
CC: deering@parc.xerox.com, int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu
Subject: Re: int-serv over e.g. ATM
References: <199511081543.KAA09611@faline.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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/

trying to summarize:

- application uses int-serv to express its traffic needs

- these needs are conveyed via rsvp to ip components (routers, if any on 
the path, plus the destination host)

how should the originating host decide whether to set up a direct 
connection to the destination over atm or whether to use the router path 
assuming that both are possible?  clearly making the decision based on 
whether the destination shares a common address prefix with the source 
doesn't make any sense.  one solution might be to include such a directive 
in the api and carry it in rsvp so that also routers on the path would 
know if it makes sense to try to shortcut the path.

if this makes sense, how can we get the shotcut bit into rsvp?

-- juha