Subject: Re: RSVP and ATM

From: [email-masked]
Date: Thu, 15 Aug 96 17:21:27 EDT

FROM: ED ELLESSON, RALVM6(ELLESSON) / [email-masked]
*** Resending note of 08/15/96 09:47
      Networking Systems Architecture, C70/B664
      P.O. 12195, Research Triangle Park, NC 27709
Subject: Re: RSVP and ATM
Joachim,

LAN switching technologies are being developed to deal with:

>802.5 really only places a maximum on the amount of time
>until a given transmitter can transmit its next packet.
>unless the number of stations on the ring are limited,
>truly reserving bandwidth greater than 16Mbs/Number of Stations
>(B) is not possible.

So that, the following summary will no longer apply:

>I think the situation is summarized as follows.

>If there is a LAN technology like Ethernet or Token ring (where
>Reserved Bandwidth > B) in the RSVP path, RSVP does not reserve
>real time bandwidth.  As Ethernet is the most common networking
>technology, I am not sure why people are spending time developing
>RSVP.  In my experience, providers use LAN technologies in the
>construction of their clouds.  Thus, providers will not be able to
>provide even soft real time service.

>Joachim Martillo

In fact, not all ISP interconnection points use traditional LAN
technology.  What about PacBell's San Francisco NAP?  I think we
can look forward to more ATM at ISP interconnection points as
ISP's continue to deploy switched infrastructures interconnecting
routers, ISR/CSR's, and demand continues to grow for realtime
reserved services enabled by RSVP and Integrated Services.

I don't think you should restrict your analysis of the value of
RSVP/Integrated Services to what is currently deployable on today's
LAN's and ISP infrastructure.  The industry is moving very quickly
to be able to support the RSVP mechanisms at layer three, with
the necessary support at layer two.  This positions ATM quite nicely,
I think, to support RSVP flows, as Ohta-san has pointed out.

---

From: [email-masked]
Date: Thu, 15 Aug 96 16:56:39 EDT

FROM: ED ELLESSON, RALVM6(ELLESSON) / [email-masked]
      Networking Systems Architecture, C70/B664
      P.O. 12195, Research Triangle Park, NC 27709
Subject: Re: RSVP and ATM
I agree with Roch Guerin, why don't we move this discussion to the
int-serv list, Joachim?  Your question really has to do with
how RSVP and Integrated Services will be mapped to Ethernet and
and other LAN technologies.  That work is being done in the ISSLL
(Integrated Services over Specific Link Layers) working group.  In fact,
there is a mailing list specifically for ISSLL, which may be even more
appropriate.  See http://www.ietf.org/html.charters/issll-charter.html
for info on how to join the list.

BTW, many commercial campus networks are upgrading to LAN switching.  As
realtime applications continue to gain in popularity, I expect we will
see more and more single segment/single workstation full duplex LAN
switch implementations, or, at least, fewer workstations per segment,
which is already happening.  This means that CSMA/CD and shared LAN's
will be less of a problem for predictable reserved flow performance.  See
the ISSLL archive for work being done to take advantage of this trend.

Regards,
Ed Ellesson
Emerging Technologies, Networking Architecture
T-444-4115, 919-254-4115 / FAX Number: T-444-5410, 919-254-5410
*** Forwarding note from SMTP2   --IINUS1   08/15/96 15:59 ***
=========================================================================
(5.65c/5.61+local-25)
	id <AA23225>; Thu, 15 Aug 1996 11:17:42 -0700
Received: by emout17.mail.aol.com (8.6.12/8.6.12) id OAA01630; Thu, 15 Aug
1996 14:17:39 -0400
Date: Thu, 15 Aug 1996 14:17:39 -0400
From: [email-masked]
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RSVP and ATM
Sender: [email-masked]
Precedence: bulk

In a message dated 96-08-15 12:25:50 EDT, [email-masked] writes:

> I do not think this discussion is very enlightenting -- or enlightened --
>  and it is outside the purpose of the RSVP WG mailing list.  Please take
>  the discussion to some other list.

The discussion has been extremely enlightening.

1)  The goal of RSVP is soft real time service.

2) But soft real time service is not obtainable on a single LAN or
LAN-like link.

3) The more LAN or LAN-like links in the RSVP path, the less likely
the promised real time service is to be delivered.

4) Yet, RSVP service is to be governed by a pricing policy which
regulators and customers will accept even though the likelihood of
actually providing soft real time service as promised seems fairly
unlikely.

So what am I missing?

Joachim Martillo
Inventor of the VLAN
President
Telford Tools, Inc.
"Garage Mechanics for the I-Way"
17 Pleasant Hill Ave.
Dorchester/Mattapan, MA 02126-2813
V:  617-298-1617
F:  617-298-1745
E:  [email-masked]

---

From: David Oran <[email-masked]>
Date: Fri, 16 Aug 1996 11:35:26 -0400

>the ISSLL archive for work being done to take advantage of this trend.
LAN switching does make the problem somewhat simpler since you no longer
have a shared single medium with an unknown number of stations using an
unpredictable amount of the media capacity, but the problem by no means goes
away. This is because you can configure a switched LAN such that the
upstream bandwidth is less than the aggregate bandwidth coming into the
switch from downstream. If every switch is a router and is RSVP-capable,
then you don't have a subnet bandwidth management problem by definition
since all links are point-to-point and terminate in routers. On the other
hand, most LAN switching configurations have most of the swtches be only
bridges, and you still need to do something gather load information from the
switches and to tell them how to detect and schedule flows.

Dave Oran.
-----------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Phone: 508-264-2048 or 508-263-2705
EMail: [email-masked]