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
- 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