Re: int-serv over e.g. ATM

Curtis Villamizar <curtis@ans.net> Thu, 09 November 1995 04:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00410; 8 Nov 95 23:17 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa00406; 8 Nov 95 23:17 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 WAA08040; Wed, 8 Nov 1995 22:49:26 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id WAA26830 for rolc-out; Wed, 8 Nov 1995 22:59:49 -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 WAA26821 for <rolc@nexen.com>; Wed, 8 Nov 1995 22:59:44 -0500
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id WAA08022 for <rolc@nexen.com>; Wed, 8 Nov 1995 22:45:43 -0500
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id WAA01614; Wed, 8 Nov 1995 22:54:59 -0500
Message-Id: <199511090354.WAA01614@brookfield.ans.net>
To: Juha Heinanen <jh@lohi.dat.tele.fi>
cc: Mark W Garrett <mwg@faline.bellcore.com>, deering@parc.xerox.com, int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu
Reply-To: curtis@ans.net
Subject: Re: int-serv over e.g. ATM
In-reply-to: Your message of "Wed, 08 Nov 1995 19:54:53 +0200." <30A0EEED.3269@lohi.dat.tele.fi>
Date: Wed, 08 Nov 1995 22:54:50 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
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/

In message <30A0EEED.3269@lohi.dat.tele.fi>fi>, Juha Heinanen writes:
> 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

This doesn't make sense.  The application should know what QoS it
needs and should not be trying to decide whether to shortcut an NBMA.
If it crosses two different NBMA clouds with different media types
ans/or different network equipment, it may make sense to shortcut one,
but not the other.  Similarly, depending on the route it takes, it may
make sense to shortcut or not to.  By specifying the QoS, the decision
can be made at network element at the border of each NBMA (which may
be the host in a special case).

Curtis