A Quick Guide to TCP/IP

N.B. This article was originally written in 1996 and was intended as an introduction for mainframe personnel to the world of TCP/IP. Although it may not reflect the latest technology it is still relevant to the communication protocols currently in use. If you have no idea what TCP/IP is then it is (in the most general terms) the connection method used to transmit and receive data between computers linked by the Internet and related networks. If you would like to read a full selection of my network related documentation then please feel free to me. See the SNA page for a TCP/IPers guide to SNA.

Contents

• 1.0 General Background
• 2.0 Basic Internetworking Concepts
• 2.1 The Concept of "Layering"
• 2.2 Comparison to the OSI Model
• 2.3 Packet Movement within the TCP/IP Stack
• 2.4 Internetwork Addresses
• 2.5 Internet Gateway Connections
• 2.6 The TCP/IP Protocol Suite
• 2.7 TCP versus UDP
• 2.8 Sockets Programming, APIs and RPCs
• 2.9 Operator Commands in the TCP/IP Environment

1.0 General Background

Transmission Control Protocol/Internet Protocol (TCP/IP) is a suite of protocols designed to allow communication between networks regardless of the technologies implemented in each network. The concept that underlies the creation and development of TCP/IP is that of internetworking, a topic which has recently developed as a major focus of commercial, technological and cultural interest. However, within the area of business applications there are undoubted benefits and fundamental changes to be considered.

The explosion in network design in the late 1960s and 70s led to the development of multiple network models (e.g. packet switching, collision detection LANs, hierarchical networks, etc.), as well as the emergence of protocol layering (allowing data exchange between applications). This evolution has led to the creation of multifarious physical network designs as transports for many different protocols. Considered individually these networks are proven designs; unfortunately the downside of this vast proliferation has been the development of a great many diverse networks which are isolated from one another due to physical differences and non-standard protocols. These issues are addressed by the principle of internetworking, i.e. the definition of a set of protocols to allow inter-application communication regardless of underlying network technology and operating systems.

Contemporary to these developments the (American) Defense Advanced Research Projects Agency (DARPA) instigated research into network connectivity with a view to creating a large network. The requirement was for a network that could link sites of various platforms and operating systems and that could withstand the loss of major components (e.g. in the event of a "nuclear incident" as it is referred to in RFC 1000 - The History of the Internet & TCP/IP, more details on the history of the Internet are available here). The robust functionality of the network was provided by dynamic re-routing, i.e. automatic routing around lost hosts in the network.

In 1978 DARPA adopted TCP/IP as their standard protocol for the handling of internetwork communication, via a backbone known as ARPANET. In 1983 TCP/IP became the mandatory suite of protocols for anyone wishing to connect to the ARPANET. Originally this network could only support 256 addresses (the maximum number possible from 8 bit addressing). The adoption of different classes of networks (Class A, B or C) and addressing based on dotted decimal notation has greatly increased the number of possible addresses.

The original network has proliferated globally into a plethora of sites providing a huge array of information and services based on the ubiquitous Internet. The network itself is overseen by the Internet Activities Board (IAB) and this body sets the standards for TCP/IP. Under the IAB are several groups, two of which are charged with the future development of TCP/IP - the Internet Engineering Steering Group (IESG) and the Internet Research Task Force (IRTF). The standards that define the Internet and TCP/IP are referred to as RFCs (Request For Comments) and these are available online (go to the Internet Society website for full details). References to RFCs are commonplace in TCP/IP; we have already mentioned the text RFC 1000.

As well as achieving the original connectivity goals, TCP/IP concepts are at the core of the development of client/server based systems. The traditional mainframe has also found new areas of development along the lines of client/server relationships, as well as the emerging data-warehousing approach. TCP/IP also played a large role in the emergence of UNIX based systems and this networking capability is one of the most notable features of the UNIX systems. Whichever data-processing solution does emerge ahead of it's competitors in the next few years it would appear that TCP/IP will be fundamental to it.

2.0 BasicInternetworking Concepts

2.1 TCP/IP - The Concept of "Layering"

An important fundamental idea that defines the internetwork architecture is the concept of layering. Below is a model representing layering when applied specifically to TCP/IP.

This concept is also known as modularity. The above architectural model can be broken down as follows;

• IP - Internet Protocol. Resides in the internetwork layer; handles addressing and basic network connectivity.
• TCP - Transmission Control Protocol. Resides in the transport layer; handles error checking, packet sequencing and performs host to host dialogue to confirm these.
• UDP - User Datagram Protocol. Resides in the transport layer; as with TCP this handles the IP to Application layer connections, but is not as reliable as TCP (see TCP vs UDP section below).
• ICMP - Internet Control Message Protocol. Resides in the transport layer; used for network specific messages such as network error codes. ICMP is used by the PING command.
• ARP - Address Resolution Protocol. Resides in the internetwork layer; each host maintains an ARP table (see section 2.4 Internetwork Addresses). ARP provides the information that is displayed via the NETSTAT command and works in tandem with IP.
• RARP - Reverse Address Resolution Protocol. Resides in the internetwork layer; gets information from the hardware's network interface card (i.e. the opposite of ARP).
• FTP - File Transfer Protocol. Resides in the application layer; downloads or uploads files between hosts.
• TFTP - Trivial File Transfer Protocol. Resides in the application layer; down-line loads files from one host to another.
• telnet - Resides in the application layer. Protocol (but also a service and an application) used for terminal emulation and remote logon (usually by emulating a DEC VT100).
• tn3270 - Resides in the application layer. Version of telnet that emulates an IBM 3270-type terminal.
• SMTP - Simple Mail Transfer Protocol. Resides in the application layer; used for e-mail.
• NTP - Network Time Protocol. Synchronises the network time.
• NNTP - Network News Transfer Protocol. Resides in the application layer; performs transfers between news servers and then onto clients.
• BOOTP - Boot Protocol. Resides in the application layer; used for remote booting of host from across the network, e.g. DEC/VMS nodes.
• DHCP - Dynamic Host Configuration Protocol. Resides in the application layer; a housekeeping protocol that enables sharing of addresses between hosts. This is done via a recyclable pool of addresses.

  There are also two gateway (or router) specific protocols;

• RIP - Routing Information Protocol; specific to hardware involved.
• OSPF - Open Shortest Path First; specific to hardware involved.

  2.7 TCP vs UDP

  At the transport layer TCP and UDP are usually the most active protocols. RPC (Remote Procedure Calls) traffic can use either protocol and each one has relative strengths. UDP messages are smaller and more efficient than TCP messages. UDP does not provide error checking or guaranteed delivery, under UDP these operations are handled by the application layer. TCP, by contrast, does provide these controls and therefore the application does not have to. However TCP packets are considerably larger and result in greater network traffic. Refer to the next section for further information regarding RPC and sockets programming.

  2.8 Sockets Programming, APIs & RPCs

  Sockets Programming

  When a TCP/IP is started on one host and asks for a connection to a remote host the following steps are invoked;

  1. At the application level your client (the TCP/IP application running on your host) creates a socket. A socket is required on each host for a valid connection (i.e. two sockets per connection) and each host will keep track of the sockets it is currently using. Each socket contains -

  • the numeric IP address of the local host
  • the local port number
  • the port number of the TCP/IP service on the remote host
  
  Each socket is uniquely numbered and valid only for the duration of the connection. The socket number is recycled when the connection is completed.

  2. The local host sends a connection request to the server application on the remote host, asking for permission to use the remote service. Within this initial request will be the remote host's IP address, the port number of the requested service and the local socket (i.e. the originating socket from the first host) number.

  3. The remote host creates his own socket to use for the duration of the connection. The remote host then replies with an acknowledgement which contains it's own socket information, directed back to the originating socket address.

  4. A connection has now been established and confirmed. The client application on the originating host can then use the remote server application. When the connection is terminated both hosts will then recycle the port addresses on which the sockets had existed.

  APIs and RPCs

  Once a connection is established the actual data transfer can take place. The Application Programming Interface (API) describes the interfaces a program must use to call TCP/IP functions. Functions are standard programs supplied with the TCP/IP software (although you can supplement these with your own bespoke functions). These functions are stored in libraries; under Windows and NetWare these are termed dynamic link libraries (DLLs). Parameters may be required for a chosen function. For each function the API description lists the number of parameters required, in which order the parameters must appear and the data-type of each parameter.

  In addition to APIs, Remote Procedure Calls (RPCs) function in much the same way but on different hosts, i.e. the calling program and the called routine reside on different hosts. An RPC follows a similar routine to that described above for sockets with the communication optimised for better performance. RPCs lie at the heart of the client/server relationship.

  Sockets, APIs and RPCs are very much part of the programmer's responsibility and unless you are involved in application development in any detail then knowledge of these topics will not be prerequisite to a good understanding of TCP/IP.

  2.9 Operator Commands in the TCP/IP Environment

  The TCP/IP suite does provide various commands and methods that can be used in problem determination exercises (which is handy, they are used frequently). Any user can employ these commands to check what the network is (or is not) doing. The most often used commands are;

  • The PING Command - The PING command (it stands for Packet Internet Groper) is used to send ICMP (Internet Control Message Protocol) packets from one host to another. Ping transmits packets using the ICMP ECHO_REQUEST command and expects an ICMP ECHO_REPLY.
  • Usage: ping IP address or Hostname
  
  
  • The TRACEROUTE Command - The traceroute command is used to trace the route that a packet takes to reach its destination. This command works by using the time to live (TTL) filed in the IP packet. Note that the exact syntax of tracert is system dependent.
  • Usage: tracert IP or Hostname
  
  
  • The NETSTAT Command - This command is used to query the network subsystem regarding certain types of information. Different types of information will be received depending on the switches used in conjunction with this command.
  • Usage: netstat [switch]
  • Switches:
    • -A Shows the addresses of any associated protocol control blocks.
    • -a Will show the status of all sockets. Sockets associated with network server processes are normally not shown.
    • -i Shows the state of the network interfaces.
    • -m Prints the network memory usage.
    • -n Causes netstat to show actual addresses as opposed to hostnames or network names.
    • -r Prints the routing table.
    • -s Tells netstat to show the per protocol statistics.
    • -t Replaces the queue length information with timer information.
      
  
  
  • The ARP Command - The arp command will display internet to ethernet (IP to MAC) address translations which is normally handled by the ARP protocol. When the hostname is the only parameter, this command will display the correct ARP entry for that hostname.
  • Usage: ARP hostname
  
  
  • The FINGER Command - By default, finger will list the login name, full name, terminal name, and write status (shown as a "*" before the terminal name if write permission is denied), idle time, login time, office location, and phone number (if known) for each current user connected to the network. N.B. many systems have disabled this command as it raises some security issues.
  • Usage: finger username@domain
  
  Note that all the commands have a wide range of switches (optional parameters that will alter the nature of the information displayed) and only NETSTAT has these listed here. If you wish to learn more about these commands (and related commands) then try this site.