The IP over ATM Mailing List Archive by date

[Steve Jackowski <stevej@NetManage.COM>]

Park Jeong,



>
>The trend of the methods providing QoS service to IP over ATM is to
>make ST-II (or RSVP) run over ATM.
>By my understanding, ATM signaling has the facility that ST serves.
>Then there are large overheads when ST runs over AAL

Current ATM signalling can encompass much of what ST2 does.  This is 
described in my ID as embedded signalling and was done in the Berkom 
implementation by IBM and in a demo by us.  The main problems with 
embedded signalling at this point are that it requires regeneration of 
flow specifications at ATM endpoints and that it is difficult to 
implement in multipoint environments.

As far as ST overhead is concerned, there is only and 8 byte header 
per packet.  All signalling is done on separate shared channels so 
there is no real signalling overhead.  Our performance benchmarks show 
ST as approaching the theoretical maximum for the cards and drivers.

>
>I know, ST do not constrain the type of network layer, os ST can 
operate
>over the network consisted of serveral types.
>But we can assume a network system, e.g, ATM Backbone for LAN or LAN
>internetworking through public ATM network. In this environment,
>IP runs only over ATM.

It was clearly the dream of the ATM community to convert every network 
to ATM, but this is not realistic.  Cells have more than 10% overhead. 
  As such, in closed networks (FDDI, SONET, etc), I don't need or want 
ATM.  ATM shines in the wide area backbone where we have a great deal 
of switching.  You can't ignore the significance of the subnets, or 
the different networking technologies found there. QoS does need to be 
end to end. In the real world you'd be surprised how much local 
provisioning and policing is required to ensure QoS.
>
>I doute the necessity of supporting QoS th (sub)LAN, if it is 
necessary,
>it should be better to propose another method fitted on the LAN type.
>And in either case, the interoperating functions between ATM and LAN 
>can solve the problems in low cost.
>
The fact is that the LAN or subnet as well as the workstation egress 
point are the weak links in end to end QoS.  A reservation protocol, 
(ST or RSVP) can assist in QoS on the LAN and work with routers and 
switches to provide consistent end to end signalling.

Even in a pure ATM network, reservation protocols can permit sharing 
of VCs and their associated bandwidth.  That is, as QoS requirements 
change, reservation protocols can maximize the usage of the links and 
VCs as well as minimize the setup overhead. 

>In this environment, a new protocol - is on the same layer of IP - 
may
>be suggested, that uses the ATM signaling to reserve resource, to do 
etc.
>Since at P-NNI and B-ICI AAL has the responsibility of supporting the
>functions, such as routing, the new protocol operates at end-system 
>at ATM fabric.

Right now I think ATM signalling is insufficient for this purpose.  
Since ATM is only one technology among many  (depending on 
environment), it would not do well to propagate its weaknesses 
universally. 

IMHO, ATM is important in the wide area, could be useful in certain 
local areas, but is not the ultimate answer for all networking.  Thus, 
use ATM signalling where ATM works the best and use reservation 
protocols to ensure end to end QoS and proper resource provisioning.

Steve
-------------------------------------
Name: Steve Jackowski
E-mail: stevej@netmanage.com (Steve Jackowski)
Phone: (408) 439-6834
Date: 03/27/96
Time: 17:00:34

This message was sent by Chameleon 
-------------------------------------