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
- int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM berson
- Re: int-serv over e.g. ATM Craig Partridge
- Re: int-serv over e.g. ATM Craig Partridge
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM berson
- Re: int-serv over e.g. ATM Lixia Zhang
- Re: int-serv over e.g. ATM Steve Deering
- Re: int-serv over e.g. ATM Alagu Periyannan
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Walter Milliken
- Re: int-serv over e.g. ATM Steve Deering
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Juha Heinanen
- Re[2]: int-serv over e.g. ATM Charlie Tai
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Jon Crowcroft
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Jon Crowcroft
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM John Krawczyk
- Re: int-serv over e.g. ATM Noel Chiappa
- Re: int-serv over e.g. ATM Andrew Smith
- Re: int-serv over e.g. ATM Andrew Smith
- Re: int-serv over e.g. ATM Curtis Villamizar