IETF Logo Mail Archive

Re: int-serv over e.g. ATM

Craig Partridge <craig@aland.bbn.com> Tue, 07 November 1995 00:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26376; 6 Nov 95 19:39 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa26372; 6 Nov 95 19:39 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 TAA23726; Mon, 6 Nov 1995 19:04:36 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id TAA29008 for rolc-out; Mon, 6 Nov 1995 19:04:41 -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 TAA28999 for <rolc@nexen.com>; Mon, 6 Nov 1995 19:04:36 -0500
Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id SAA23663 for <rolc@nexen.com>; Mon, 6 Nov 1995 18:51:00 -0500
Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id PAA06949; Mon, 6 Nov 1995 15:59:16 -0800 (PST)
Message-Id: <199511062359.PAA06949@aland.bbn.com>
To: berson@isi.edu
cc: mwg@faline.bellcore.com, int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu
Subject: Re: int-serv over e.g. ATM
In-reply-to: Your message of Mon, 06 Nov 95 14:20:46 -0800. <199511062220.AA11759@mex.isi.edu>
Date: Mon, 06 Nov 95 15:59:15 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig@aland.bbn.com>
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/

    The RSVP group at ISI is looking at these issues.  Right now we are
    concentrating on the second issue ("reference configurations" other
    than #1).  We will be talking about our status in the IP over ATM
    working group meeting at the Dallas IETF.

Steve:
    
    Now that's interesting, since I've always thought IP QoS over ATM
was an INT SERV problem to solve.  Basically RSVP (like any other
reservation protocol) tells the IP layer what service it wants, and the
IP layer negotiates with ATM to get the right thing underneath.

    Why is RSVP directly involved with ATM?  (I'm curious here, not
trying to pick a turf war -- trying to understand where our architectural
views differ).

Craig

v2.8.7 | Report a Bug | By Email