Subject: RE: (ION) IP over ATM message delivery question

From: manujp <[email-masked]>
Date: Fri, 24 Apr 98 17:57:00 PDT

In the scenario of 1 host sending to 2 different endsystems , you would   
have 2 scv's . A more interesting
scenario, would be if you have 2 flows of 400 Mbps and 100 Mbps between a   
pair of hosts.
That (correct me if I'm wrong) would involve setting up 2 svc's.

regards,
 -Manu

 -----Original Message-----
From: owner-ion [SMTP:[email-masked]]
Sent: Friday, April 24, 1998 12:00 PM
To: ion
Subject: (ION) IP over ATM message delivery question

Hi !

I have a question regarding the IP over ATM. I would appreciate any
comment !

If I have an IP message, after the addressing problem is solved, how is
the IP message sent to the destination (supposing it is in the same
ATM network) ?
A SVC is probably established, but what happen after the message is
transmitted ? Is the VC closed ? If I want to send a 500Mb/s stream
between 2 ATM hosts using IP, how are the things going ? Is there
an adaptive algorithm for creating/closing channels between the 2
hosts ? Where I can find the parameters of this algorithm if this is
the case ? Is this a standard or is implementation dependent ?
And what if I have 2 streams, first of 400MB/s between host1
and host2, and the second of 100MB/s between host1 and host3 ?
How is the bandwidth split in this case ? Is it any place where
I can find any documentation about this ?

Thank you in advance, and sorry if this is a stupid or a FA question.
Im am quite new in this domain (and on this list).

Regards,
Florin Lohan

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Albert Manfredi <[email-masked]>
Date: Fri, 24 Apr 1998 10:12:40 -0400

> That (correct me if I'm wrong) would involve setting up 2 svc's.

I don't think that would typically be the case. Not with RFC 1577 or
LANE, at any rate. I mean, what in IP or other normal Layer 3
protocol would know to set up a higher rate SVC? All these data
protocols see is that a path to the destination exists, and go ahead
and use that path.

Perhaps, _if_ you postulate some sort of kludgey RSVP-ATM QoS
mapping, a different SVC would be set up.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Albert Manfredi <[email-masked]>
Date: Sun, 26 Apr 1998 17:21:16 -0400

Tal Anker wrote:
> 
> On Fri, 24 Apr 1998, Albert Manfredi wrote:
> 
> > manujp wrote:
> > >
> > protocols see isthat a path to the destination exists, and go ahead
> > and use that path.
> >
> You could also consider "Application REQuested IP over ATM (AREQUIPA) -
> RFC 2170" that describe a way for the application to establish a
> connection for their exclusive use (it requires no extra service like NHRP
> or RSVP).

True, but AREQUIPA is hardly a standard IP application. In fact, one
should probably not consider it IP at all. It is a way for IP over
ATM end stations to tell each other "Hey, I am actually ATM, why
don't we use ATM instead of IP?"

Bert

---

From: Tal Anker <[email-masked]>
Date: Sun, 26 Apr 1998 13:34:41 +0300 (IDT)

- Tal.
-----------------------------------------------------------
Institute of Computer Science
The Hebrew University of Jerusalem,
Givat Ram, Jerusalem 91904
Israel

Phone: +972-2-6585706
Fax  : +972-2-6585439

---

From: Florin Lohan <[email-masked]>
Date: Tue, 28 Apr 1998 17:58:45 +0300

Thank you all for your answers. I found lots of articles due to your answers,
I did not have the time to read them all, but I will !
I also have found the answer to my question (and actually to some questions
derived from the answer), so for those of you interested in the subject, I will
describe here shortly how the classical IP over ATM works:

There is only one virtual channel between 2 hosts. This is normal, because
IP is connection less and when the ATM receives an IP message it does not
know if there is an internet connection between the hosts. And the ATM does
not know if another message will come for the same address and if another
message comes the ATM does not know if it belongs to the same connection
(if there is one) or not !
When a IP message is send over ATM, a VC is opened. The allocated
bandwidth for the channel is 0, so it will be served with the lower priority.
Therefore, IP connection requests are never refused.
So, a 400Mb/s IP over ATM stream can work just fine on a 622Mb/s ATM
link (if the computer is powerful enough) but if in the same computer another
application makes a 300Mb/s channel request, the bandwidth for the IP
connection will drop significantly !
The question deriving from here is "How can someone reserve a bandwidth for
an IP over ATM connection ? (so to have guaranteed QoS)" The answer is
"It can not do that only with classical IP over ATM". Other solutions like
AREQIPA or RSVP can give an answer to this. But there are also drawbacks
with each of them. As far as I know, AREQIPA needs a connect mechanism,
so one would need a way to "guess" the bandwidth for some UDP transmissions.
This can happen if one would like to send a stream using RTP (that is based on
UDP) but does not know apriori the stream bandwidth (this can be true for
RSVP also, but I do not know for sure right now). I also do not know if and
how RSVP works with ATM (the mechanism).
It seems to me that RSVP is a long term solution, because it works also on IP
networks (without ATM). The AREQIPA can be considered as a short-term
solution, until the RSVP will be fully implemented and available.
Please correct me if I am wrong.
Regards,
Florin

---

From: Steven Berson <[email-masked]>
Date: Tue, 28 Apr 1998 10:33:31 -0700 (PDT)

On Tue, 28 Apr 1998, Florin Lohan wrote:

[ ... a short summary of classical IP over ATM omitted ... ]

> how RSVP works with ATM (the mechanism).

There has been a lot of work in the Integrated Services for Specific
Link Layers (ISSLL) Working Group on this question.  Take a look at

	draft-ietf-issll-atm-framework-03.txt

for the basic approach.

Steve