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