Re: VCC cost models .... (was Re: Limits on SVCCs)

Keith McCloghrie <kzm@cisco.com> Tue, 30 April 1996 06:11 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06831; 30 Apr 96 2:11 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa06827; 30 Apr 96 2:11 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id CAA26828; Tue, 30 Apr 1996 02:04:37 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id CAA27956 for rolc-out; Tue, 30 Apr 1996 02:03:00 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id CAA27945 for <rolc@nexen.com>; Tue, 30 Apr 1996 02:02:56 -0400 (EDT)
Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id CAA22171 for <rolc@nexen.com>; Tue, 30 Apr 1996 02:02:54 -0400 (EDT)
Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id XAA23790; Mon, 29 Apr 1996 23:02:47 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <199604300602.XAA23790@foxhound.cisco.com>
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
To: Andrew Smith <fddi1-ncd@baynetworks.com>
Date: Mon, 29 Apr 1996 23:02:47 -0700
Cc: dhc2@gte.com, gja@bellcore.com, rolc@nexen.com
In-Reply-To: <9604292339.AA29264@milliways-le0.engwest> from "Andrew Smith" at Apr 29, 96 04:39:41 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to rolc-request@nexen.com, submissions to rolc@nexen.com
X-Info: Email archive at ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
X-Info: Hypermail archive at http://cell-relay.indiana.edu/mail/archives/rolc/
X-Info: FTP archive at ftp://ftp.nexen.com/pub/rolc/

> This, in a nutshell, is one of the big NHRP issues: the client is in a 
> position to know how much it wants to pay for the connection but the network 
> is the only place that knows how much it will cost. With NHRP as the
> signaling protocol, there is no way to set up a mutually beneficial deal.
> Even worse than this is a situation with an intervening "low-cost"
> proxy-client
> which probably does not communicate any form of cost information with the real
> client (who is the one with the open wallet).
 
If the "real client" is an NBMA-attached host, then presumably the only
way it can get any "cost" information is to implement the NBMA's routing
protocol, e.g., PNNI, but to have hosts implement routing protocols is
contrary to our networking paradigm.

If the "real client" is, say, an Ethernet-attached host and there's a
router between the Ethernet and the NBMA network, then it's not clear
to me how the router can communicate "cost" information to the host,
but whatever method is used would seem to be independent of NHRP.

If there's an MPOA "low-cost" Edge-device between the Ethernet and the
NBMA network, then that Edge-device is part of a distributed router,
and that distributed router is responsible for communicating the same
"cost" information (whatever it might happen to be) to the host.  So, I
don't see the significance of the cost of the intervening device.

Keith.