The IP over ATM Mailing List Archive by date

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >
 >>  
 >>  >       Title     : Application REQuested IP over ATM (AREQUIPA)            
 >>  >       Author(s) : W. Almesberger, J. Le Boudec, P. Oechslin
 >> 
 >> 
 >> this reminds me a lot of an idea in UK protocols of the early 80s
 >> called 'yellow book',which basically allowed support of "onward
 >> addressing" of calls
 >> 
 >> basically what you want is for a "haning" tuple at the active and
 >> passive host ends to be bound and what arequipa provides is an API
 >> (and some suggestions for ATMARP extension echanisms ) to support t
 >> 
 >> i would prefer the API to simply look like the yellow book idea-
 >> basically, invenet a new "socket address family" called AREQUIPA, and
 >> allow it to consist of
 >> IP address+ application port + atm address
 >> 
 >> then you can connect, bind, accpet and getperername on it. and all is
 >> well, you have your 'combined address and call setup and singlaing'
 >> interface, without any change to the applications
 >> 
 >> then you could even use Juha's DNS support for atm addresses to enable
 >> applicatiosn that are name based to ue this "as is"
 >> 
 >> maybe?
 >> 
 >> comments?
 >> 
 >> cheers
 >
 >Jon,
 
 >We don't want to define another family of sockets. We want to give a
 >mechanism to provide application to application QoS on normal TCP or
 >UDP sockets or any other end points.


thats what i am proposing - not another family of socktes, but just of
dadresses

sockaddr_arequpa = (string form" ipaddr+atmaddr+qos

then the API is unchanged, and applications just connect, or bind, on
these new addresses

in the absence of rsvp, and with a signle local IP to atm interface,
and a single Large Cloud, this uses DNS to disseminate the required
info
and combines the "signaling" with the rolc problem

with rsvp, you could accomodate multiple hops with IP over atm - and
ou still dont have to change the application - you simply insert your
rsvp.dll in between the applt and the netly, and away you go....

you can even change the applic later to repeatedly call bind() or
connect() with different QoS (and remove the atmaddr part of the
concat string too:-) if you have a pure rsvp-able path with
renegoiation and the 
connect( calls map onto new PATH messages, and the bind() ones onto
RESV ones...and you have a neatoh lightweiht signalling API

mind you, if you wanted to also give an upcall to get network
congestion exlicit rate info, i don't fany doing that with sigio, but
in winsock, with asynch socket calls, it might be quite easy to add
later, but i digress.....:-)

 >Arequipa just tells your IP over ATM implementation to open a direct ATM 
 >connection between two given hosts, with a given QoS, and for the exclusive 
 >use by a given pair of sockets. Once you have done the Arequipa system call, 
 >you can open TCP or UDP sockets and profit from the requested QoS. 

me too:-)

 >Basically you get what NHRP and RSVP would give you for point to point 
 >connections between IP hosts in an ATM network. The advantage is that you 
 >don't need any support from the network, neither RSVP routers nor the 
 >deployment of NHRP. 

me too...my NHRP is DNS based, but then its hiden fro mthe App, so it
could use any actal protocol...just like IP can use ARP or other 
 >
 >With Arequipa, two applications which want to exchange data with
 >guaranteed QoS do not require external help for address
 >resolution. Since they will initially negociate the QoS parameters and
 >the socktes to be used, they can as well exchange their ATM
 >addresses. If they don't trust each other they can still use extended
 >DNS or NHRP to verify the addresses.


oh, i see - its a two phase thing - but what about call setup latency
- surely for many things you might want to use this for (e.g.
performant web access) this would be too slow?
anyhow with my approach, you  could always do a 

connect(IPaddr)
where the other end does a list(ipaddr, atmaddr, qos) and then the
client end does a 
getpeername(&newaddr+qos)
and recalls connect(IPaddr+atmaddr+qos)

all within the simple existing framework!!

cheers

cheers

 jon