Cell Relay Archive

[myoung@calon.com]

In <3lngre$t5l@harbinger.cc.monash.edu.au>, jwb@capek.rdt.monash.edu.au (Jim Breen) writes:
>myoung@calon.com writes:
>
>>In <3kt1j8$fbd@harbinger.cc.monash.edu.au>, jwb@capek.rdt.monash.edu.au (Jim Breen) writes:
>>>No-one (that I am aware of) in the ATMF or IETF is looking at the idea
>>>of TCP running directly over ATM VCs, because it really violates the
>>>generally accepted principles of interworking 
>
>>What to we mean a "principle"? Is this an axiom based upon the definition
>>of a VC?  Is it a physical limitation of a VC?  What is it about the
>>physical nature of a VC, besides some voted upon axioms, which make
>>it inappropriate to run a transport layer directly on top of it?
>
>Nothing really to do with VCs, except that not everyone has them. The 
>whole reason for have an interworking protocol, implemented on top of
>heaps of physical networks (of which ATM is just one), is to enable
>end-end carriage of ULPs such as TCP without it having to fuss about
>the underlying physical network(s). This is what I meant by "accepted 
>principles of interworking". We can do away with this, when and only when,
>all the known universe is on the one communication system.
Well again, if we start with the assumption that ATM virtual circuits
belong to the physical layer, then every thing you say follows.  

Let us skip this assumption for the moment, and ask what axiomization do
need to internetwork VCs with IP, or IPX?  Well first axiom is that
VC is no longer part of the physical layer.  Now given this premise, we
can define a gateway having a set IP address and a ATM endpoint address.
Now we need only add enough data in the ATM connection to identify the IP
address within the IP network, then assign a bidirectional mapping
between one of the set of IP addresses and the VC.

Please don't do this however.  I prefer to keep ATM defined as a
physical layer at this point.

Matt Young

>
>Feel free to run TCP on top of ATM, HDLC, Ethernet, etc. etc., but it will
>not be able to interwork with end-systems outside your own network.
>-- 
>Jim Breen          [$@%8%`!&%V%j!<%s(J@$@%b%J%7%eBg3X(J]
>Department of Robotics & Digital Technology. Monash University. 
>Clayton VIC 3168 Australia (p) +61 3 905 3298 (f) +61 3 905 3574  
>j.breen@rdt.monash.edu.au   [http://www.rdt.monash.edu.au/~jwb/]