Table of Contents Classical IP over ATM versus LAN Emulation
TCP/IP Tutorial and Technical Overview

2.14 TCP/IP and OSI

Figure - TCP/IP and OSI shows an attempt to position the different TCP/IP and OSI architectural layers, but be aware of the basic differences discussed below.

Figure: TCP/IP and OSI - Functional positioning of the layers.

2.14.1 Differences

One can only functionally position the internet model to the ISO OSI model because basic differences exist such as:

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:

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. 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. 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. 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. 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. 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.

Table of Contents Data Link Switching: Switch-to-Switch Protocol