One can only functionally position the internet model to the ISO OSI model because basic differences exist such as:
In the internet protocol suite, a layer represents a reasonable packaging of function.
The ISO view, on the other hand, treats layers as rather narrow functional groups, attempting to force modularity by requiring additional layers for additional functions.
In the TCP/IP protocols, a given protocol can be used by other protocols within the same layer, whereas in the OSI model two separate layers would be defined in such circumstances. Examples of such "horizontal dependencies" are FTP, which uses the same common representation as TELNET on the "application layer," and ICMP, which uses IP for sending its datagrams on the "internetwork" layer.
In practice, what we are discussing here is the difference between a de jure standard, OSI, and a de facto standard, TCP/IP. The focus in the TCP/IP world is on agreeing on a protocol standard which can be made to work in diverse heterogeneous networks. The focus in the OSI world has always been more on the standard than the implementation of the standard.
Efficiency and feasibility. The OSI norms tend to be prescriptive (for instance the "layer N" must go through "all layers below it"), whereas the TCP/IP protocols are descriptive, and leave a maximum of freedom for the implementers. One of the advantages of the TCP/IP approach is that each particular implementation can use operating system-dependent features, generally resulting in a greater efficiency (fewer CPU cycles, more throughput for similar functions), while still ensuring "interoperability" with other implementations.
Another way to see this is that most of the internet protocols have first been developed (coded and tested), before being "described" in an RFC (usually by the implementer) which clearly shows the feasibility of the protocols.
2.14.2 The Internet World and OSI
The Department of Defense (DoD), funder of the original ARPANET research, made a statement on OSI in January '88, based on the Government OSI Profile (GOSIP) of April 22, 1987.
The following is an excerpt from the statement, which is published in RFC 1039 - A DoD Statement on OSI: "... It is intended to adopt the OSI protocols as a full co-standard with the DoD protocols when GOSIP is formally approved as a Federal Information Processing Standard. Two years thereafter, the OSI protocols would become the sole mandatory interoperable protocol suite; however, a capability for interoperation with DoD protocols would be provided for the expected life of systems supporting the DoD protocols. ..."
A lot of study has already been done by the internet world on possible transitions and coexistence of the protocols. The following list is a series of RFCs already issued for that purpose:
RFC 983 - ISO Transport Services on Top of the TCP.
RFC 1006 - ISO Transport Services on Top of the TCP - Version 3.
RFC 1039 - A DoD Statement on Open Systems Interconnection Protocols.
RFC 1069 - Guidelines for the Use of Internet IP Addresses in the ISO Connectionless-Mode Network Protocol.
RFC 1085 - ISO Presentation Services on Top of the TCP/IP-based Internets.
RFC 1086 - ISO-TP0 Bridge between TCP and X.25.
RFC 1090 - SMTP on X.25.
RFC 1161 - SNMP over OSI.
RFC 1195 - Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.
RFC 1238 - CLNS MIB for Use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542).
RFC 1240 - OSI Connectionless Transport Services on top of UDP: Version 1.
RFC 1308 - Executive Introduction to Directory Services using the X.500 Protocol.
RFC 1309 - Technical Overview of Directory Services using the X.500 Protocol.
RFC 1327 - Mapping between X.400 (1988)/ISO 10021 and RFC 822.
RFC 1328 - X.400 1988 to 1984 Downgrading.
RFC 1330 - ESCC X.500/X.400 Task Force. Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet Community.
RFC 1430 - A Strategic Plan for Deploying an Internet X.500 Directory Service.
RFC 1487 - X.500 Lightweight Directory Access Protocol.
RFC 1488 - The X.500 String Representation of Standard Attribute Syntaxes.
RFC 1491 - A Survey of Advanced Usages of X.500.
RFC 1562 - Naming Guidelines for the AARNet X.500 Directory Service.
RFC 1567 - X.500 Directory Monitoring MIB.
RFC 1608 - Representing IP Information in the X.500 Directory.
RFC 1609 - Charting Networks in the X.500 Directory.
RFC 1617 - Naming and Structuring Guidelines for X.500 Directory Pilots.
RFC 1629 - Guidelines for OSI NSAP Allocation in the Internet.
RFC 1632 - A Revised Catalog of Available X.500 Implementations.
RFC 1684 - Introduction to White Pages Services based on X.500.
RFC 1706 - DNS NSAP Resource Records.
RFC 1729 - Using the Z39.50 Information Retrieval Protocol in the Internet Environment.
RFC 1781 - Using the OSI Directory to Achieve User Friendly Naming.
2.14.3 TCP/IP and OSI Coexistence Considerations
If your goal is TCP/IP-OSI coexistence, with an eye toward eventually going to pure OSI, you basically have five choices, which fall into two general categories: protocol-based and services-based.
Protocol-based approaches include dual stacks, application-layer gateways and transport-layer gateways. Services-based approaches include transport-service bridges and network tunnels.
126.96.36.199 Dual Stacks - The Simple Approach
The simplest way to integrate TCP/IP and OSI is to put both protocol stacks in every machine on the network.
Figure: Dual Stacks
Although this is a relatively straightforward approach, it involves a fundamental drawback: two networks will be running over the same set of wires, but the two sets of protocol cannot interoperate. Users are forced to choose between them. This disadvantage of having two separate networks can be an advantage. Those users who want to use TCP/IP can use TCP/IP, those who want to use OSI can use OSI. Another advantage is that an existing TCP/IP network will not be disturbed. But, dual stacks are memory-intensive, and they have to be put on every machine on the TCP/IP-OSI networks.
188.8.131.52 Application-Layer Gateways - The DoD Approach
This approach eliminates a major drawback of dual stacks (lack of application internetworking). The application-layer gateways convert protocol data units (PDU) from one stack's application protocol to the other's. With application-layer gateways it is possible to communicate from any TCP/IP system to any OSI system. It is not necessary to choose between protocols, because either application protocol will work on either stack.
Figure: Application-Layer Gateway Node
Another advantage of application-layer gateways is that you do not have to add anything to, or otherwise modify, the end systems. This is because the application-layer gateway (which includes both protocol stacks) sits between the systems and handles all of the protocol conversion. But you will often lose functionality in the conversion from one application protocol to another because of imperfect mapping between the two protocols, mainly when going from OSI to TCP/IP applications. This is because OSI applications have richer functionalities. Another disadvantage of application-layer gateways is that they produce bottlenecks that will cause performance degradation if your gateway is not powerful enough.
184.108.40.206 Transport-Layer Gateways - The Wrong Approach
Figure: Transport-Layer Gateway Node
CLNP stands for ConnectionLess Network Protocol (see figure above).
If you have an environment with the TCP transport protocol on one side and the OSI TP4 transport protocol on the other, you need a software mechanism that dynamically translates TCP packets into TP4 packets. This approach is considered to be wrong because no applications support TCP on one end and TP4 on the other, and because the addresses change on either part of the gateway, which involves loss of directories services.
The three approaches examined so far focus on protocol conversion. However, it is possible to virtually ignore the protocol itself and to concentrate on emulating services. This is where transport-service bridges and network tunnels come into play.
220.127.116.11 Transport-Service Bridges - The ISODE Approach
Figure: Transport-Service Bridge Node
ISODE stands for International Standards Organization Development Environment. It is a publicly available collection of library routines and programs that implement OSI upper-layer services.
In a TCP-to-TP4 example, a transport-service bridge would make the TCP service look like a TP4 service. You accomplish this by emulating the TP4 service. With transport-service bridges you can run OSI applications over TCP/IP networks. One advantage of this approach is that you can use just one application protocol-OSI. Only the underlying layers need change between the two environments. A transport-service bridge is essentially a router that copies PDUs, as opposed to translating them. RFC 1006 defines the way to produce OSI transport services on top of TCP. The main disadvantage of this approach is that you do not have end-to-end (source to destination) checksum. In the example of TCP-to-TP4 environment, you have a TCP checksum on the source side of the transport-service bridge and a TP4 checksum on the destination side. Like gateways, transport-service bridges introduce a single point of failure. You can use transport-service bridges not only for TCP/IP-to-OSI implementations but also for OSI-to-OSI integration jobs. For example, OSI includes different transport protocols, such as TP0 for wide area networks and TP4 for local area networks. Transport-service bridges are viable candidates for linking those different OSI transports.
18.104.22.168 Network Tunnels - The Difficult Approach
Figure: Network Tunnels
This approach eliminates the single point of failure and gives you end-to-end checksums. Network tunnels are one level down from the transport-service bridge approach. Instead of transport-service emulation, they use packet-level service emulation. Network tunnels operate at the network layer instead of at the transport layer. They encapsulate OSI CLNP packets in IP packets and run them over IP networks. Network tunnels are essentially CLNP routers.
Network tunnels provide end-to-end checksums, a high degree of transparency, but they require OSI CLNP-based networks and are difficult to implement.