TCP/IP: What's in the Stack?

In 1982, the Reston, Va.-based Internet Engineering Task Force (www.ietf.org) standardized the transmission control protocol/Internet protocol (TCP/IP) suite of protocols.

But, the first implementation of the TCP/IP suite—published in the early 1970s by the U.S. Department of Defense’s Defense Advanced Research Projects Agency (DARPA,www.darpa.mil)—was in the Berkeley Software Distribution, developed by the University of California-Berkeley (www.berkeley.edu) soon after DARPA published the protocols suite.

Nearly a decade later, the International Organization for Standardization (ISO,www.iso.ch) published the Open System Interconnection (OSI). The OSI model has a seven-layered “stack” of protocols defining various parts of what has come to be known as Ethernet networking, expanding upon the original four-layer stack of TCP/IP, says Todd Montgomery, a lecturer in the Lane Department of Computer Science and Electrical Engineering in West Virginia University’s (www.wvu.edu) College of Engineering and Mineral Resources, Morgantown, W.Va.

The TCP/IP stack just defines link, internetwork, transport and application. The OSI stack defines physical, data link, network, transport, session, presentation and application.

The inevitable comparison between TCP/IP and OSI is easy, explains Montgomery. The TCP/IP applications layer encompasses both the OSI application and presentation layers. “The reason for that is the IETF agreed that it’s the applications protocol’s responsibility to represent data,” Montgomery says. TCP/IP’s transport layer includes the transport and session layers in OSI. That is because the individual transport protocol has responsibility to handle session management issues, he explains.

“TCP / IP的网络层是一个有效的same as the network layer in the OSI model,” Montgomery says. And the TCP/IP’s data-link layer effectively encompasses the data-link and physical layers in the OSI.

Send a message

To explain the TCP/IP model’s layers and their functions, he uses an example of actually sending Web page contents to a browser. This starts with a Web server, which has a particular page to send, he says. From top down in the TCP/IP stack, the datagram (information packet) first comes into the application layer. “The server adds a protocol header, which is for HTTP (hypertext transmission protocol),” explains Montgomery, who is also chief architect for Warrenville, Ill.-based 29West (www.29west.com), a high-speed messaging services provider.

有很多应用的核心协议ons layer, he says. Besides HTTP, some with which people are familiar include simple mail-transfer protocol (SMTP), simple network-management protocol (SNMP) and file-transfer protocol (FTP), he says. “These protocols get users the most bang for their bucks.” Then the applications layer sends the datagram down to the transport layer, where the TCP adds a TCP header. “The core protocols here (in the transport layer) are UDP (user datagram protocol) and TCP,” Montgomery explains. This tells the packet how to go.

Next, the transport layer sends the datagram down to the network layer, where the IP adds an IP address to the datagram. This is the “where to go.” Regarding core protocols at this layer, Montgomery says, “For the IETF, IP is pretty much it. There is also an ICMP, which is Internet control message protocol. It does a lot error reporting and some diagnostics.”

In the next-to-last step, the network layer sends the datagram down to the data-link layer, where the media, such as industrial Ethernet, adds its own header, he explains. “Ethernet also puts a trailer onto the datagram for transmission error detection.” The core protocols at this layer include Ethernet and the Institute of Electrical and Electronics Engineers (www.ieee.org) 802.XX standards. “You may see things such as ATM, asynchronous transfer mode. These three are the predominant protocols on the data-link layer.”

Then the message is sent from the stack on the network, which can be either the Internet or a company’s intranet, Montgomery says.

C. Kenna Amos,ckamosjr@earthlink.net, is an Automation World contributing editor.

More in Networks