af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD) (09/18/89)
It seems that one of the first practical results of the OSI (1) effort will be the deployment of Message Handling Systems based on the X.400 CCITT recommendations (2). The MHS is defined at layer 7 ; in strict OSI logic, it is expected to use the services of an OSI presentation layer (which I was told it does *not*, even in a full OSI setup :_) ). In order to use some current network infrastructure, operation of a X.400 MHS on top of TCP (which, when applying the OSI RM to the DDN suite (3), generally ends up at layer 4, but who needs layers 5 and 6 when one has TCP :-) ) will probably be commonplace in the (near) future. The question : is there any work going on to define a standard way to do this, in order to allow implementations of X.400 conforming to the CCITT recommendations, operating on TCP implementations conforming to the relevant RFC's, to interoprate ? In one word, the reverse of RFC 1090. Thank you in advance for any relevant comments. /AF (1) please, no wasting of network ressources and readers time arguing about OSI vs ISO, or about the distinction between the RM and the actual protocols, etc. (2) please etc etc about the OSIness of the CCITT, or the fact that one should perhaps write X.4xx, etc. (3) please ....... about the correctness of doing so. Alain FONTAINE +--------------------------------+ Universite Catholique de Louvain | If your mail software barks at | Service d'Etudes Informatiques | my address, you may try : | Batiment Pythagore | | Place des Sciences, 4 | FNTA80@BUCLLN11.BITNET | B-1348 Louvain-la-Neuve, BELGIUM +--------------------------------+ phone +32 (10) 47-2625
mrose@CHEETAH.NYSER.NET (Marshall Rose) (09/18/89)
RFC 1006 (ISO Transport Service on top of the TCP) published in May, 1987, describes a technique that can be used to host any OSI which ultimately uses OSI transport on top of TCP/IP-based internets. The advantage of this particular approach is two-fold: first, rfc1006 provides an emulation of the OSI transport service, as such the OSI application is completely unaware that it is running in an TCP/IP-based environment. From the practical perspective, this means no change in your code. Considering that application code is easily two orders of magnitude more complex, harder to debug, etc., than the lower layers, this is a win. Second, because the underlying paradigm is that of the OSI transport service, you can build a "transport service bridge" between networks with different transport services (e.g., TCP/IP, TP0/X.25, and TP4/CLNP). This bridge effectively shuffles packets between the different networks allowing me, e.g., to have my TCP/IP-only host exchange an X.400 message with an X.25-only host, providing that somewhere there is a dual-homed host running both TCP and X.25 that both hosts can reach. Of course such a bridge theoretically introduces some performance and reliability considerations, but in practice, this hasn't been noticable. A couple of implementations of rfc1006 have been running for a few years now. The original one (mine) has been running in the Internet since March of 1987. Right now, there are several sites running FTAM, VT, MHS, and OSI Directory, in the Internet right now. Of these four, the Directory is the most notable (MHS is still in beta and not widely distributed), as NYSERNet has been sponsoring a white pages pilot for the last couple of months which uses OSI Directory on top of TCP/IP. Summary: problem solved. /mtr