Re: int-serv over e.g. ATM

Juha Heinanen <jh@lohi.dat.tele.fi> Fri, 10 November 1995 08:30 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06782; 10 Nov 95 3:30 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa06778; 10 Nov 95 3:30 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 DAA15798; Fri, 10 Nov 1995 03:05:12 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id DAA11887 for rolc-out; Fri, 10 Nov 1995 03:11:48 -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 DAA11878 for <rolc@nexen.com>; Fri, 10 Nov 1995 03:11:44 -0500
Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.64.161]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id DAA04622 for <rolc@nexen.com>; Fri, 10 Nov 1995 03:09:36 -0500
Received: (from jh@localhost) by lohi.dat.tele.fi (8.6.12/8.6.12) id JAA23121; Fri, 10 Nov 1995 09:58:53 +0200
Date: Fri, 10 Nov 1995 09:58:53 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Juha Heinanen <jh@lohi.dat.tele.fi>
Message-Id: <199511100758.JAA23121@lohi.dat.tele.fi>
To: mwg@faline.bellcore.com
CC: int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu, rolc@nexen.com
In-reply-to: <199511092044.PAA00221@faline.bellcore.com> (mwg@faline.bellcore.com)
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/ 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.

yes, i know that rsvp doesn't require a router on the path.

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

yes, but if the rsvp routing protocol can't tell to the host that there
is an rsvp capable path all the way to the destination, the source has
to probe it by trying to make an rsvp reservation, which is equivalent
to sending an nbma arp.  so, it would make sense also in this case to
apply the rule "shortcut always if you can and route if you can't".

i have to read yakov's draft and see how it relates to this.

-- juha