TCP/IP Reference Model

From the starting itself the major goal of the design issues were to connect the multiple networks in a seamless way and this was later known to be “TCP/IP Reference Model”. The internet protocol suite came from work done by DARPA in the early 1970s. Kahn and Cerf had soon worked out a fundamental reformulation, where the differences between network protocols were hidden by using a common internetwork protocol, and instead of the network being responsible for reliability, as in the ARPANET, the hosts became responsible. DARPA then contracted with BBN, Stanford, and The University College London to develop operational versions of the protocol on different hardware platforms. Four versions were developed — TCP v1, TCP v2, a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 — the standard protocol still in use on the Internet today.

Now we will have a look into the layers that our reference model consists of. Derived from the OSI structure we have only four layers in the TCP/IP reference model. We can consider the layers in the OSI are merged together to form the layers in TCP/IP. The IP suite uses encapsulation to provide abstraction of protocols and services. Generally a protocol at a higher level uses a protocol at a lower level to help accomplish its aims. The layers near the top are logically closer to the user while those near the bottom are logically closer to the physical transmission of the data. Each layer has an upper layer protocol and a lower layer protocol (except the top/bottom protocols, of course) that either use said layer's service or provide a service, respectively. Viewing layers as providing or consuming a service is a method of abstraction to isolate upper layer protocols from the nitty gritty detail of transmitting bits over, say, ethernet and collision detection while the lower layers avoid having to know the details of each and every application and its protocol.

This abstraction also allows upper layers to provide services that the lower layers cannot, or choose not, to provide. For example, IP is designed to not be reliable and is a best effort delivery protocol. This means that all transport layer must address whether or not to provide reliability and to what degree. UDP provides data integrity (via a checksum) but does not guarantee delivery; TCP provides both data integrity and delivery guarantee (by retransmitting until the receiver receives the packet).This model is in some ways lacking.

1. For multipoint links with their own addressing systems (e.g. ethernet) an address mapping protocol is needed. Such protocols can be considered to be below IP but above the existing link system.
2. ICMP & IGMP operate on top of IP but does not transport data like UDP or TCP.
3. The SSL/TLS library operates above the transport layer (utilizes TCP) but below application protocols.
4. The link is treated like a black box here. This is fine for discussing ip (since the whole point of IP is it will run over virtually anything) but is less helpful when considering the network as a whole.

Note: The upper layer protocol (ULP) refers to the more abstract protocol when performing encapsulation whereas the lower layer protocol (LLP) refers to the more specific protocol when performing encapsulation. For example In the internet protocol suite, IP is the lower layer protocol to UDP and TCP; likewise UDP and TCP are two upper layer protocols for IP.

OSI Reference Model

So we have seen the different kind of networks available (not all, other we will cover later). We get a small idea what is the meaning of each type of network. As we procced we will be learning more about the structure and their standatds. So in order to understand these variations in structure and the standards we will be starting what are the layers in the OSI and the TCP/IP model and do all these depend on each other.To start with we will proceed with the OSI layer model.

OSI Reference Model

This model was developed on the proposal given by International Standards Organization which was in a sense first effort to standardize the protocols used in the various layers. It is well known that OSI has seven layers.Earlier networking was completely vendor-developed and proprietary, with protocol standards such as SNA and DECnet. OSI was a new industry effort, attempting to get everyone to agree to common network standards to provide multi-vendor interoperability. It was common for large networks to support multiple network protocol suites, with many devices unable to talk to other devices because of a lack of common protocols between them. Many of the protocols and specifications in the OSI stack are long-gone or have been superseded, such as token-bus media, CLNP packet delivery, FTAM file transfer, and X.400 e-mail. Some of them are still alive like X.500 directory srtucture because the original unwieldy protocol has been stripped away and effectively replaced with LDAP.

 

The principles that were applied to arrive at the seven layers can be briefly summerized as follows:

1. A layer should be created where a different abstrction is needed.
2. Each layer should perform a well defined fuction.
3. The function of each layer should be chosen with an eye towards defining internationally standardized protocols
4. The layer boundaries should be chosen to minimize the information flow across the interfaces.
5. The number of layers should be large enough that distinct functions need not be thrown together in the same layer out of necessity and small enough that the architecture does not become unwieldy.

    

   Note: OSI model itself is not a network architecture because it does not specify the exact services and protocols to be used in each layer. It just tells what each layer should do.

   The collapse of the OSI project in 1996 severely damaged the reputation and legitimacy of the organizations involved, especially ISO. This model is now overshadowed by the TCP/IP model.

   In the next sections we will be covering what layers are there in the network and there fuctionalities but this will be in reference to the TCP/IP model.