Re: IP modifications for ATM

[Bryan Gleeson <[e-mail]>]

Tony,

>
>Hello everyone
>
>My intent is not to fuel another debate, but simply for my own
>understanding.   I have posed the following question at the ATM Year '96
>but did not obtain a clear answer:
>
>With all the work that has been proposed to modify the IP protocol suite
>(i.e., RSVP MARS, .... etc) to give QoS and signalling capabilities among
>others, has there been any thought to let IP know the concept of virtual
>circuits?
>

Yes - Classical IP ! There is nothing in 1577 which mandates that AAL5
frames are transmitted at link speed. In fact if I have a mix of 155Mbit
hosts and 25Mbit hosts in one network then it is essential, given the lack of
buffering in first generation ATM switches / concentrators, to slow down a 
155M host if it is talking to a 25M host, by traffic shaping down to 25Mbits. 
Even modest bursts at 155 can cause havoc with some ATM 25M switches. UNI 3.x 
doesn't provide for PCR negotiation (UNI 4.0 does). One way of achieving this 
is to have 2 LISs - one for 155M and another for 25M hosts. "Server" machines 
have an interface onto both LISs. UNI 4.0 allows this negotiation on a
per VCC basis. This is needed as a general solution as even if both ends 
are on 155M links there could be a 45M link in the middle somewhere.

It is this ability in client / server networks for a server to adjust
on an individual basis to each client across a large switched network
with different link speeds that differentiates ATM from shared media 
/ frame switched solutions. Whether you need this feature depends on lots 
of things and the details of a specific environment and traffic patterns.


>In other words, can the IP hardware interface drivers be modified such it
>can recognize the presence of either an ATM-based underlying network
>(NMBA), or a LAN-based network (CSMA/CD, TR, ... ).  If it sees an
>ATM-based network,  then it sends the traffic at a VC rate, rather than at
>the link speed.
>The purpose would be to increase the throughput of IP over ATM traffic
>not to provide QoS, since sending traffic at VC rate might decrease the
>probability of packet discards at the relatively smaller ingress buffers on
>the ATM switch, thus decreasing re-transmitts.
>

I think it is "stumps up and back to the clubhouse" for the ip-atm list as such
now that ion has arrived, and further discussion should probably take place
there. It did have a pretty good innings though ....

Bryan Gleeson
Cisco.