TCP/IP Protocols

Well, I've finally finished this page. Hell of a lot of work, but judging by your feedback - it's been well worth it. I am glad many people are finding these pages useful. As these pages progress, they will become more technical, as I slowly introduce you into the ever changing world of the Internet. Please be patient as there is alot of work in typing, and collecting my thoughts. ANY constructive criticism is highly expected. Pleasant reading...

If you wish to skip all the blurb following, please scroll down to the end of this page for additional sites & info.

Internet Protocol

The Internet Protocol (IP) is a primary protocol of the OSI model, as well as an integral part of TCP/IP (as the name suggests). Although the word "Internet" appears in the protocol's name, it is not restricted to use with the Internet. It is true that all machines on the Internet will use or understand IP, but IP can be used on dedicated networks that have no relation to Internet at all. IP defines a protocol, not a connection.

The Internet Protocol's main tasks are the addressing of datagrams of information between computers and managing the fragmentation process of these datagrams. The protocol has a formal definition of the layout of a datagram of information and the formation of a header composed of information about the datagram. IP is responsible for the routing of a datagram, determining where it will be sent, as well as alternate routes in case of problems.

Another important aspect of IP's purpose has to do with "unreliable" delivery of a datagram. Unreliable in the IP sense means that the delivery of the datagram is not guaranteed, because it may get delayed, misrouted, or mangled in the breakdown and reassembly of message fragments. Internet Protocol has nothing to do with flow control or reliability: There is no inherent capability to verify that a sent message is correctly received. IP does not have a checksum for the data contents of a datagram, only for the header information. The verification and flow control tasks are left to other components in the layer model. (For that matter, IP doesn't even properly handle the forwarding of datagrams. IP has the capability to make a guess as to the best routing to move a datagram to the next node along a path, but does not inherently verify that the chosen path is the fastest or most efficient route.) Part of the IP system defines how gateways manage datagrams, how and when they should produce error messages, and how to recover from problems that may arise.

Previously, you saw how data can be broken into smaller sections for transmission and then reassembled at another location. IP provides for a maximum packet size of 65,535 bytes. The protocol has the capability to automatically divide a datagram of information into smaller datagrams if necessary, using the principles you saw in my first and second web page.

When the first datagram of a larger message that has been divided arrives at the destination, a reassembly timer is started. If all the pieces of the entire datagram are not received by the time the timer has reached a predetermined value, all the datagrams that have been received are discarded. The receiving machine knows the order in which the pieces are to be reassembled because of a field in the IP header. One consequence of this process is that a fragmented message has a lower chance of arrival than an unfragmented message, which is why most applications try to avoid fragmentation whenever possible.

The Internet Protocol is connectionless, meaning it doesn't worry about which nodes a datagram passes through along the path, or even at which machines the datagram starts and ends. This information is in the header, but the process of analysing and passing on a datagram has nothing to do with IP analysing the sending and receiving IP addresses. IP handles the addressing of a datagram with the full 32-bit Internet address, even though the transport protocol addresses use 8 bits.

The Internet Protocol Datagram Header

It is tempting to compare the Internet Protocol to a hardware network such as Ethernet because of the basic similarities in packaging information. In my last web page, you saw how Ethernet assembles a frame by combining the application data with a header block containing address information. The Internet Protocol does the same, except the contents of the header are specific to that protocol. When Ethernet receives an IP-assembled datagram, it adds its header to the front to create a frame - a process called encapsulation. The primary difference is that Ethernet's header contains the physical addresses of the destination machine, whereas the IP header contains the IP addresses. You may recall that the translation between the two addresses is performed by the Address Resolution Protocol.

Encapsulation is the process of adding something to the start (and sometimes the end) of data. It provides details about the data that is enclosed.

The datagram is the transfer unit used by IP, sometimes more specifically called an Internet datagram, or IP datagram. The Internet Protocol header uses six 32-bit words (24 bytes) when all the optional fields are included. The shortest header uses five words (20 bytes). To understand all the fields in the header, it is useful to remember that IP has no hardware dependence but must account for all versions of IP software it can encounter. The IP header layout is shown schematically in Figure 1. The different fields in the IP header can now be examined in more detail.

ip_header.gif - 3.1 K

Figure 1 - The IP header layout

Version Number

This is a 4-bit field that contains the IP version number the protocol software supports. The version number is required so that receiving software will know how to decode the rest of the header, which changes with each new release of the IP standards. The current version is 4.

Part of the protocol stipulates that the receiving software must first check the version number before proceeding. If the software cannot handle the version, it rejects the datagram.

Header Lengths

This 4-bit field reflects the total length of the IP header, given in 32-bit words. The shortest header is five words, but the use of optional fields may increase the header size. To properly decode the header, IP must know when the header ends and the data begins, which is why this field is included. (There is no start-of-data marker.)

Type of Service

The 8-bit service type field instructs IP how to process the datagram properly. The field's 8 bits are read and assigned, as shown in Figure 2. The first 3 bits indicate the datagram's precedence, with a value from 0 (normal) through 7 (network control). The higher the number, the more important the datagram. Most implementations of TCP/IP and practically all hardware that uses TCP/IP ignores this field, treating all datagrams with the same priority.

type_of_service.gif - 1.0 K

Figure 2 - The 8-bit service type field layout

The next 3-bit flags control the delay, throughput, and reliability of the datagram. If the bit is set to 0, the setting is normal. A bit set to 1 implies low delay, high throughput, and high reliability in order of the flags. The last 2 bits of the field are not used.

For most purposes, the values of all the bits in the service type field are set to 0 because differences in delay, throughput, and reliability between machines are virtually non-existent unless a special network has been established. Although these flags would be useful in establishing the best routing method for a datagram, no currently available UNIX-based IP system bothers to evaluate the bits in these fields. (Although it is conceivable that the code could be modified for high-security or high-reliability networks.)

Datagram Length

This field gives the total length of the datagram, including the header, in bytes. The length of the data area itself can be computed by subtracting the header length from this value. The size of the total datagram length field is 16 bits, hence the 65,535 bytes maximum length of a datagram (including the header). This field is used to determine the length to be passed to the transport protocol to set the total frame length.

Identification

This field holds a number that is a unique identifier created by the sending node. This number is required when reassembling fragmented messages, ensuring that the fragments of one message are not intermixed with others.

Flags

The flags field is a 3-bit field, the first bit of which is left unused. The remaining 2 bits are dedicated to flags called DF (Don't Fragment) and MF (More Fragments), which control the handling of the datagrams when fragmentation is desirable.

If the DF flag is set to 1, the datagram cannot be fragmented under any circumstances. If the current node cannot send the datagram on without fragmenting it, and this bit is set to 1, the datagram will be discarded and an error message will be sent back to the sending device.

If the MF flag is set to 1, the current datagram is followed by more packets (often called subpackets), which must be reassembled to re-create the full message. The last fragment, that is sent as part of the larger message, has its MF flag set to 0 (off) so that the receiving device will know when to stop waiting for datagrams. Because the order of the fragments arrival may not correspond to the order in which they send, the MF flag is used in conjunction with the Fragment Offset (see the next section) to indicate to the receiving device the full extent of the message.

Fragment Offset

If the MF (More Fragments) flag bit is set, the fragment offset contains the position in the complete message of the submessage contained within the current datagram. This enables IP to reassemble fragmented packets in the proper order.

Offsets are always given relative to the beginning of the message. This is a 13-bit field, so offsets are calculated in units of 8 bytes, corresponding to the maximum packet length of 65,535 bytes.

Time to Live (TTL)

This field gives the amount of time in seconds that a datagram may remain on the network before it is discarded. This is set (usually to 15 or 30 seconds) by the sending node.

The TCP/IP standards stipulate that the field must be decreased by at least one second for each node that processes the packet, even if the processing time was less than one second. Also, when a datagram is received by a gateway, the arrival time is tagged so that if the datagram must wait to be processed, that time counts against its TTL. Hence, if a gateway is particularly overloaded and can't get to the datagram in short order, the timer may expire while awaiting processing and the datagram abandoned.

If the field becomes 0, the datagram must be discarded by the current node; but a message is sent to the sending machine if the packet is dropped. This rule prevents packets from endlessly circulating through networks.

Transport Protocol

This field holds the identification number of the transport protocol to which the packet has been handed. The numbers are defined by the Network Information Center. There are currently about 50 protocols. ICMP is number 1, and TCP is number 6. The full list of numbers is not necessary here.

Header Checksum

The number in this field is a checksum for the protocol header field (but not the data fields) to enable faster processing. Because the Time to Live (TTL) field is decremented at each node, the checksum also will change. The algorithm takes the ones-complement of the 16-bit sum of all 16-bit words.

This is a fast, efficient algorithm, but it will miss some unusual circumstances such as the loss of an entire 16-bit word that contains only 0s. However, because the data checksums used by both TCP and UDP cover the entire packet, these types of errors usually can be caught because the frame is assembled for the network transport.

Sending Address and Destination Address

These fields contain the 32-bit IP addresses of the sending and destination devices. These fields are established when the datagram is created and are not altered during the routing.

Options

The Options field is optional, composed of several different codes of variable length. If more than one option is used in the datagram, the options appear consecutively in the IP header. All the options are controlled by a byte that is usually divided into three fields: a 1-bit copy flag, a 2-bit option class, and a 5-bit option number. The copy flag is used to stipulate how the option is handled when fragmentation is necessary in a gateway. When the bit is set to 0, the option should be copied only to the first datagram but not to subsequent ones. If the bit is set to 1, the option is copied to all the datagrams.

The option class and option number indicate the type of option and its particular value. At present, there are only two option classes set. (With only 2 bits to work with in the field, a maximum of four options could be set.) When the value is 0, the option applies to datagram or network control. A value of 2 means it is for debugging or administration purposes. Values of 1 and 3 are unused. Currently supported values for the option class and number are given in Table 1.

Option Class	Option Number	Description
0	0	Marks the end of the option list.
0	1	No option (used for padding)
0	2	Security options (military purpose only)
0	3	Loose source routing
0	7	Activates routing record (adds fields)
0	9	Strict source routing
2	4	Timestamping active (adds fields)

Table 1 - Valid option class & numbers for IP headers

Of most interest to you, are options that enable the routing and timestamps to be recorded. These are used to provide a record of a datagram's passage across the internetwork, which can be useful for diagnostic purposes. Both these options add information to a list contained within the datagram. (The timestamp has an interesting format: It is expressed in milliseconds since midnight, Universal Time. Unfortunately, because most systems have widely differing time settings - even when corrected to Universal Time - the timestamps should be treated with a little suspicion.)

There are two kinds of routing indicated within the options field: loose and strict. Loose routing provides a series of IP addresses that the machine must pass through, but it enables any route to get to each of these addresses (usually gateways). Strict routing enables no deviations from the specified route. If the route can't be followed, the datagram is abandoned. Strict routing is frequently used to test routes but rarely for transmission of user datagrams.

Padding

The content of the padding area depends on the options selected. The padding is usually used to ensure that the datagram header is a round number of bytes.

A Datagram's Life

When an application must send a datagram out on the network, it performs a few simple steps. First, it constructs the IP datagram within the legal lengths stipulated by the local IP implementation. The checksum is calculated for the data and then the IP header is constructed. Next, the first "hop" of the route to the destination must be determined to route the datagram to the destination machine directly over the local network, or to a gateway if the internetwork is used. If routing is important, this information is added to the header using an option. Finally, the datagram is passed to the network for its manipulation of the datagram.

As a datagram passes along the internetwork, each gateway performs a series of tests. After the network layer has stripped off its header, the gateway calculates the checksum and verifies the integrity of the datagram. If the checksums don't match, the datagram is discarded and an error message is returned to the sending device. Next, the time-to-live field is decremented and checked. If the datagram has expired, again it is discarded and an error message is sent. After determining the next hop of the route, either by analysis of the target address or from a specified routing instruction within the options field of the IP header, the datagram is rebuilt with the new time-to-live value and new checksum.

If fragmentation is necessary because of an increase in the datagram's length or a limitation in the software, the datagram is divided and new datagrams with the correct header information are assembled. If a routing or timestamp is required, it is added as well. Finally, the datagram is passed back to the network layer.

When the datagram is finally received at the destination device, the system performs a checksum calculation and, assuming the two sums match, checks to see if there are other fragments. If more datagrams are required to reassemble the entire message, the system waits, meanwhile running a timer to ensure that the datagrams arrive within a reasonable time. Even if all the parts of the larger message have arrived but the device can't reassemble them before the time-to-live timer reaches 0, the datagram is discarded and an error message is returned to the sender. Finally, the IP header is stripped off and the message passed up the layers. If a reply was required, it is then generated and sent back to the sending device.

When extra information is added to the datagram for routing or timestamp recording, the length can increase. Handling all these conditions is part of the Internet Protocol's forte, for which practically every problem has a resolution system.

Internet Control Message Protocol (ICMP)

In my previous two web pages, I showed how problems can occur in routing. Time-to-live may expire, fragmented datagrams may not arrive with all segments intact, a gateway may misroute a datagram, and so on. Letting the sending device know of a problem with the datagram is important, as is correctly handling error conditions within the network routing itself. It is for this task that the Internet Control Message Protocol (ICMP) was developed.

ICMP is an error-reporting system. It is an integral part of the Internet Protocol and must be included in every implementation. This provides for consistent, understandable error messages and signals across the different versions. It is useful to think of ICMP as one IP package talking to another IP package across the network: In other words, ICMP is the IP communications system. Messages generated by ICMP are treated by the rest of the network as any other datagram. ICMP messages have a header built in the same manner as a user applications' and are not differentiated until a receiving machine processes the datagram properly.

In almost all cases, error messages sent by ICMP are routed back to the original datagram's sending machine. This is because only the sender's and destination devices' IP addresses are included in the header; and because the error won't mean anything to the destination device, the sender is the logical recipient of the error message. The sender can then determine from the ICMP message the type of error that occurred and establish how to best resend the failed datagram.

ICMP messages go through two encapsulations: when they are incorporated into a regular IP datagram and then into the networkframe. This is shown in Figure 3. ICMP headers have a different format than IP headers, and the format differs slightly depending on the type of message. However, all ICMP headers start with the same three fields: a message type, a code field, and a checksum for the ICMP message. Figure 4 shows the layout of the ICMP message.

Usually, any ICMP message that is reporting a problem with delivery also will include the header and first 64 bits of the data field from the datagram for which the problem occurred. Including the 64 bits of the original datagram accomplishes two things. It enables the sending device to match the datagram fragment to the original datagram by comparison. Also, because most of the protocols involved are defined at the start of the datagram, the inclusion of the original datagram fragment allows for some diagnostics.

ICMP.gif - 2.4 K

Figure 3 - Two-step encapsulating an ICMP message

ICMP_message.gif - 1.6 K

Figure 4 - The layout of an ICMP message

The 8-bit message type field can have one of the following values.

Value	Description
0	Echo Reply
3	Destination Not Reachable
4	Source Quench
5	Redirection Required
8	Echo Request
11	Time-To-Live Exceeded
12	Parameter Problem
13	Timestamp Request
14	Timestamp Reply
15	Information Request (now obsolete)
16	Information Reply (now obsolete)
17	Address Mask Request
18	Address Mask Reply

The code field expands on the message type. The checksum is calculated in the same manner as the IP header checksum.

The layout of the ICMP message is slightly different for each type. Figure 5 shows the layouts of each type of ICMP message header. The Destination Unreachable and Time Exceeded messages are self-explanatory, although they are used in other circumstances, too, such as when a datagram must be fragmented but the Don't Fragment bit flag is set. This would result in a Destination Unreachable message.

header_layouts.gif - 9.1 K

Figure 5 - ICMP message header layouts

The Source Quench message is used to control the rate at which datagrams are transmitted, although this is a very rudimentary form of flow control. When a device receives a Source Quench message, it should reduce the transmittal rate over the network until the Source Quench messages cease. The messages are typically generated by a gateway or host that has either a full receiving buffer or has slowed the processing of incoming datagrams because of other factors. If the buffer is full, the device is supposed to issue a Source Quench message for each datagram that is discarded. Some implementations will issue Source Quench messages when the buffer exceeds a certain percentage to slow down reception of new datagrams and enable the device to clear the buffer.

Redirection messages are sent to a gateway in the path when a better route is available. For example, if a gateway has just received a datagram from another gateway but on checking its datafiles finds a better route, it will send the redirection message back to that gateway with the IP address of the better route. When a redirection message is sent, an integer is placed in the code field of the header to indicate the conditions for which the rerouting apply. A value of 0 means that datagrams for any device on the destination network should be redirected. A value of 1 indicates that only datagrams for the specific device should be rerouted. A value of 2 implies that only datagrams for the network with the same type of service (read from one of the IP header fields) should be rerouted. Finally, a value of 3 reroutes only for the same host with the same type of service.

The Parameter Problem message is used whenever a semantic or syntactic error has been encountered in the IP header. This can happen when options are used with incorrect arguments. When a Parameter Problem message is sent back to the sending device, the Parameter field in the ICMP error message contains a pointer to the byte in the IP header that caused the problem. (See Figure 5 above.)

Request or reply types are commonly used for debugging purposes. When a request is sent, a device or gateway down the path will send a reply back to the specified device. These request-reply pairs are useful for identifying routing problems, failed gateways, or network cabling problems. The simple act of processing an ICMP message also acts as a check of the network, because each gateway or device along the path must correctly decode the headers and then pass the datagram along. Any failure along the way could be with the implementation of the IP software. A commonly used request-reply system is the ping command. The ping command sends a series of requests and waits for replies.

Timestamp requests and replies enable the timing of message passing along the network to be monitored. When combined with strict routing, this can be useful in identifying bottlenecks. Address mask requests and replies are used for testing within a specific network or subnetwork.

Gateway-to-Gateway Protocols

Gateways need to know what is happening to the rest of the network in order to route datagrams properly and efficiently. This includes not only routing information but also the characteristics of subnetworks. For example, if one gateway is particularly slow but is the only access method to a subnetwork, other gateways on the network can tailor the traffic to suite.

A gateway-to-gateway protocol is used to exchange routing information between devices. It is important to not confuse routing information, which contains addresses, topology, and details on routing delays, with the algorithms used to make routing information. Usually the routing algorithms are fixed within a gateway and not modified. Of course, as the routing information changes, the algorithm will adapt the chosen routes to reflect the new information.

Gateway-to-gateway protocols are primarily for autonomous (self-complete) networks. An autonomous system uses gateways that are connected in one large network, such as one might find in a large corporation. There are two kinds of gateways that must be considered in an autonomous network. The gateways between smaller subnetworks help tie the small systems into the larger corporate network, but the gateways for each subnetwork are usually under the control of one system (usually in the IS department). These gateways are considered autonomous because the connections between gateways is constant and seldom changes. These gateways communicate through an interior gateway protocol, or IGP.

Large internetworks such as the Internet are not as static as corporate systems. Gateways may change constantly as the subsidiary networks make changes and the communications routes between gateways are more subject to change, too. For widely spread companies, there may be gateways spread throughout the country (or the world) that are all part of the same corporate network but use the Internet to communicate. The communications between these gateways is slightly different than when they are all physically connected together. These gateways communicate through an exterior gateway protocol, or EGP.

There are fewer rules governing IGPs than EGPs simply because the IGP can handle custom-developed applications and protocols within its local network. When Internet is used for gateway-to-gateway communications, the messages must conform to the internetwork standards. Also, when connecting two subnetworks, it is possible to send only one message to the subnetwork gateway through EGP, which can then be duplicated, modified, and propagated to all gateways on the internal system using IGP. EGP has formalised rules governing its use.

Since EGP was developed to enable remote systems to exchange routing information and status messages, the protocol is heavily based in requests or commands followed by replies. The four EGP commands and their possible responses are shown in Table 2.

Command Name	Command Description	Response Name	Response Description
Request	Request that a neighbour become a gateway	Confirm/Refuse	Agree or refuse the request
Cease	Request the termination as a neighbour	Cease-Ack	Agree to termination
Hello	Request confirmation of routing to neighbour (neighbour reachability)	IHU	Confirms the routing
Poll	Request the neighbour provide network information (network information reachability)	Update	Provides network

Table 2 - EGP Command

To understand Table 2 properly, you must understand the concept of neighbour to an internetwork. Gateways are neighbours if they share the same subnetwork. They may be gateways to the same network (such as Internet) or work with different networks. When the two want to exchange information, they must first establish communications between each other; the two gateways are essentially agreeing to exchange routing information. This process is called neighbour acquisition.

Don't think that neighbour means that networks have to be next to each other. They are connected by a gateway, but the networks can be on different continents. The term neighbour has to do with connections, not geography

The process of becoming neighbours is formal, because one gateway may not wish to become a neighbour at that particular time (for any number of reasons but usually because the gateway is busy). It begins with a Request, which is followed by either an acceptance (Confirm) or refusal (Refuse) from the second machine. If the two gateways are neighbours, either can break the relationship with a Cease message.

After two gateways become neighbours, they assure each other that they are still in contact by occasionally sending a Hello message, to which the second gateway responds with an IHU (I Heard You) message as soon as possible. These Hello-IHU messages can be sent at any time, and with several gateways involved on a network the number of Hello messages can become appreciable as the gateways continue to remain in touch. This process is called neighbour reachability.

The other message pair sent by EGP is network reachability, in which case one gateway sends a Poll message and expects an Update message in response. The response contains a list of networks that can be reached through that gateway with a number representing the number of hops that must be made to reach the networks. By assembling the Update messages from different neighbors, a gateway can decide the best route to send a datagram.

Finally, there is an error message that is returned whenever the gateway cannot understand an incoming EGP message.

The layout of the different messages used by EGP are shown in Figure 6. The fields have the following meanings described after Figure 6.

EGP_message.gif - 4.96 K

Figure 6 - EGP Message Format

Version Number - the EGP release number
Type - the type of message
Code - the subtype of message (Table 3)
Status - combined with "code", provides more information (Table 3)
Checksum - checksum of the entire message
System Number - an assigned number identifying the system
Sequence Number - an incremental number that is used for all command response pairs to ensure the pairs match

The reason field of the error message may contain on eof the following integers:

0 - Unspecified error
1 - Bad EGP header
2 - Bad EGP data field
3 - Reachability information not available
4 - Excessive polling
5 - No response received to a poll

Through a combination if the message type, code, and ststus fields, the purpose and meaning of the EGP message can be more accurately determined. Table 3 shows all codes and status values.

Type	Description	Code	Description	Status	Description
1	Update	0		0	Indeterminate
				1	Up
				2	Down
				128	Unsolicited
2	Poll	0		0	Indeterminate
				1	Up
				2	Down
3	Neighbour Acquisition	0	Request	0	Not specified
		1	Confirm	1	Active mode
		2	Refuse	2	Passive mode
		3	Cease	3	Insufficient Resources
		4	Cease-Ack	4	Prohibited
				5	Shutting Down
				6	Parameter Problem
				7	Protocol Violation
5	Neighbour	0	Hello	0	Indeterminate
		1	I Heard You	1	Up
				2	Down
8	Error	0		0	Indeterminate
				1	Up
				2	Down
				128	Unsolicited

Table 3 - EGP messages

The Status field can indicate whether a gateway is up or down. In the down state, the gateway will not perform any routing. The Neighbour Acquisition status indicator can show whether the machine is active or passive. When passive, the gateway will not generate any Hello commands, but it will respond to them. At least one neighbor has to be in the active state to issue the Hellos.

When a list of networks and their distances must be added to an EGP header, it is done in the format shown in Figure 7. The number of distances in the list is specified, followed by entries with the same format giving the distance (number of hops) to the gateway, the number of networks that can be reached through that gateway, and the network addresses. The number of internal and external gateways in the EGP header tell the gateway how many entries are in the list.

EGP_header.gif - 2.98 K

Figure 7 - Routing Information in an EGP header

Using EGP, gateways can update each other and keep their routing tables current. A similar scheme is used for IGP, although the messages can be custom designed by the network manager and application development team because they are not transmitted over the Internet.

Internet Protocol Support in Different Environments

The University of California at Berkeley was given a grant in the early 1980s to modify its UNIX operating system to included support for the Internet Protocol. The BSD4.2 UNIX release already offered support for TCP and IP, as well as the Simple Mail Transfer Protocol (SNMP) and Address Resolution Protocol (ARP); but funded by DARPA's funds, BSD4.3 was developed to provide more complete support.

The BSD4.2 support for IP was quite good but proved to be limited to use in small local area networks. To increase the capabilities, BSD added retransmission capabilities, time-to-live information, and redirection messages. Other features were added, too, but these changes enable BSD4.3 to work with larger networks, internetworks (connections between different networks) and wide area networks connected by leased lines.

With the strong support for IP amongst the UNIX community, it was inevitable that manufacturers of other software operating systems would produce software that allowed their machines to interconnect to the UNIX IP system.

I intend to examine several different hardware and software systems, focusing on the most widely used. Much of this will be of interest only if you have the particular platform discussed (DEC VAX users tend not to care about interconnectivity to IBM SNA platforms), so you can be selective about the sections you read. In some cases, you will use one package (from each platform) as an application example and for screen captures. These products are mentioned in the following few paragraphs now and will be covered in more detail when they are actually used.

MS-DOS

PCs came onto the scene when TCP/IP was already in common use, so it was not surprising to find interconnection software rapidly introduced. In many ways, the PC was a perfect platform as a stand-alone machine with access through a communications package to other, larger, systems. The PC was perfect for a client/server environment.

There are many PC-based versions of TCP/IP. The most widely used packages come from FTP Software, The Wollongong Group, and Beame and Whiteside Software, Inc. All the packages feature interconnection to other machines using TCP/IP, whereas most add other useful features list FTP and mail routing.

FTP Software's PC/TCP is one of the most widely used. PC/TCP supports the major network interfaces: Packet Driver, IBM's Adapter Support Interface (ASI), Novell's Open Data Link Interface (ODI), and Microsoft/3Com's Network Driver Interface Specification (NDIS). All four LAN interfaces are discussed in more detail in the section titled "Local Area Networks," towards the end of this web page.

The design of PC/TCP covers all seven layers of the OSI model, developed in such a manner that components can be configured as required to support different transport mechanisms and applications. Typically, the Packet Driver, ASI, ODI, or NDIS module has a generic PC/TCP kernel on top of it, with the PC/TCP application on top of that.

PC/TCP enables the software to run both TCP/IP and another protocol, such as DECnet, Novell NetWare, and LAN Manager, simultaneously. This can be useful for enabling a PC to work within a small LAN workgroup, as well as within a larger network, without switching software.

Microsoft Windows

There are several TCP/IP products appearing for Microsoft's Windows, most of which are ports of DOS products. Although these tend to work well, a totally Windows designed product tends to have a slight edge in terms of integration with the Windows environment. Some later versions of Windows (such as Windows for Workgroups and the upcoming Windows 4.0) have some TCP/IP capabilities built in to the distribution software.

One Windows-designed product is NetManage's Chameleon TCP/IP for Windows. It offers a complete port of TCP/IP and additional software utilities to enable a PC that is running Windows to integrate into a TCP/IP network. Chameleon offers terminal emulation, Telnet, FTP, electronic mail, DNS directory services, and NFS capabilities. There are several versions of Chameleon, depending on whether NFS is required or not.

Windows NT

Windows NT is ideally suited for TCP/IP because it is designed to act as a server and gateway. Although Windows NT is not inherently multiuser, it does work well as a TCP/IP access device. Windows NT includes support for the TCP/IP protocols as a network transport, although the implementation does not include all the utilities usually associated with TCP/IP.

Among the add-on products available for Windows NT, NetManage's Chameleon32 a popular package. Similar to the Microsoft Windows version, Chameleon32 offers versions for NFS. The behavior of Chameleon32 is very similar to the Windows version.

OS/2

IBM's OS/2 platform has a strong presence in corporations because of the IBM reputation and OS/2's solid performance. Not surprisingly, TCP/IP products are popular in these installations. Although OS/2 differs from DOS in many ways, it is possible to run DOS-based ports of TCP/IP software under OS/2. A better solution is to run a native OS/2 application. Several TCP/IP OS/2-native implementations are available, including a solid product from IBM itself.

Macintosh

Except for versions of UNIX that run on the Macintosh, the Macintosh and UNIX worlds have depended on versions of TCP/IP to keep them connected. With many corporations now wanting their investment in Macintosh computer to serve double duty as X terminals onto UNIX workstations, TCP/IP for the Mac has become even more important.

Macintosh TCP products are available in several forms, usually as an add-on application or device driver for the Macintosh operating system. An alternative is Tenon Intersystem's MachTen product line, which enables a UNIX kernel and the Macintosh operating system to co-exist on the same machine, providing compatibility between UNIX and the Macintosh file system and Apple events.

The AppleTalk networking system enables Macs and UNIX machines to interconnect to a limited extent, although this requires installation of AppleTalk software on the UNIX host - something many system administrators are reluctant to do. Also, because AppleTalk is not as fast and versatile as Ethernet and other network transports, this solution is seldom favoured.

A better solution is simply to install TCP/IP on the Macintosh using one of several commercial packages available. Apple's own MacTCP software product can perform the basic services but must be coupled with software from other vendors for the higher-layer applications. MacTCP also requires a Datagram Delivery Protocol to Internet Protocol (DDP-to-IP) router to handle the sending and receiving of DPP and IP datagrams.

Apple's MacTCP functions by providing the Physical through Transport layers of the architecture. MacTCP allows for both LocalTalk and Ethernet hardware and supports both IP and TCP, as well as a number of other protocols. Running on top of MacTCP is the third-party application, which uses MacTCP's function calls to provide the final application for the user. Functions such as Telnet and FTP protocols are supported with add-on software, too.

DEC

Digital Equipment Corporation's minicomputers were for many years a mainstay in scientific and educational research, so an obvious development for DEC and third-party software companies was to introduce IP software. Most DEC machines run either VMS or Ultrix (DEC's licensed version of UNIX). Providing IP capabilities to Ultrix was a matter of duplicating the code developed at Berkeley, but VMS was not designed for IP type communications, relying instead on DEC's proprietary network software.

DEC's networking software is the Digital Network Architecture (DECnet). The first widely used version was DECnet Phase IV (introduced in 1982), which used industry standard protocols for the lower layers but was proprietary in the upper layers. The 1987 release of DECnet Phase V provided a combined DECnet IV and OSI system that allowed new OSI protocols to be used within the DECnet environment.

DEC announced the ADVANTAGE-NETWORKS in 1991 as an enhancement of DECnet Phase V, adding support for the Internet Protocols. With the ADVANTAGE-NETWORKS, users could choose between the older, DEC-specific DECnet, OSI, or IP schemes. ADVANTAGE-NETWORKS is DECs attempt to provide interoperability, providing the DEC-exclusive DECnet system for LAN use, and the TCP/IP and OSI systems for WANs and system interconnection between different hardware types.

Users of VMS systems can connect to the UNIX environment in several ways. The easiest is to use a software gateway between the VMS machine and a UNIX machine. DEC's TCP/IP for VMS performs this function, as do several third-party software solutions, such as the Kermit protocol from Columbia University, Wollongong Group's WIN/TCP, and TGV's MultiNet. The advantage of the third-party communications protocol products like Kermit is that they don't have to be connected to a UNIX machine, because any operating system that supports the communications protocol will work.

ADVANTAGE-NETWORKS users have more options available, many from DEC. Because the protocol is already embedded in the network software, it makes the most sense to simply use it because it comes if it fits into the system architecture. Because of internal conversion software, ADVANTAGE-NETWORKS can connect from a DECnet machine using either the DECnet or the OSI protocols.

IBM's SNA

IBM's Systems Network Architecture (SNA) is in widespread use for both mainframes and minicomputers. Essentially all IBM equipment provides full support for IP and TCP, as well as many other popular protocols. There is native IBM software available for each machine, and several third-party products have appeared (usually at a lower cost than IBM's).

IBM's UNIX version, AIX (which few people know stands for Advanced Interactive Executive), has the TCP/IP software built in, enabling any machine that can run AIX (from workstation to large minicomputer) to interconnect through IP with no additional software. The different versions of AIX have slightly different support, so users should check before blindly trying to connect AIX machines.

For large systems like mainframes, IBM has the 3172 Interconnect Controller, which sits between the mainframe and a network. The 3172 is a hefty box that handles high-speed traffic between a mainframe channel and the network, offloading the processing for the communications aspect from the mainframe processor. It can connect to Ethernet or Token Ring networks and through additional software to DEC's DECnet.

IBM mainframes running either MVS or VM can run software appropriately called TCP/IP for MVS and TCP/IP for VM. These products provide access from other machines running TCP/IP to remotely access the mainframe operating system, usually over a LAN. The software enables the calling machine (actually the client in a client/server scheme) to act as a 3270-series terminal to MVS or VM. FTP is provided for file transfers with automatic conversion from EBCDIC to ASCII. An interface to PROFS is available. Both TCP/IP software products support SMTP for electronic mail.

Local Area Networks

LANs are an obvious target for TCP/IP, because TCP/IP helps solve many interconnection problems between different hardware and software platforms. To run TCP/IP over a network, the existing network and transport layer software must be replaced with TCP/IP, or the two merged together in some manner so that the LAN protocol can carry TCP/IP information within its existing protocol (encapsulation).

Whichever solution is taken for the lower layer, a higher-layer interface also must be developed, which will reside in the equivalent of the data link layer, communicating between the higher-layer applications and the hardware. This interface enables the higher layers to be independent of the hardware when using TCP/IP, something that many popular LAN operating systems are not currently able to claim.

There are three interfaces (which have been mentioned by name earlier) currently in common use. The Packet Driver interface was the first interface developed to meet these needs. 3Com Corporation and Microsoft developed the Network Driver Interface Specification (NDIS) for OS/2 and 3Com's networking software. NDIS provides a driver to communicate with the networking hardware and a protocol driver that acts as the interface to the higher layers. Novell's Open Data Link Interface (ODI) is similar to NDIS.

For single-vendor, PC-based networks, there are several dedicated TCP/IP packages available, such as Novell's LAN Workplace, designed to enable any NetWare system to connect to a LAN using an interface hardware card and a software driver.

As well, there is an enormous amount of literature available on this topic. In particular the following books are worthwhile which can be bought from McGills here in Melbourne.

A good reference web site is as follows:- http://www.lantronix.com/htmfiles/mrktg/catalog/et.htm

TCP/IP illustrated Volumes 1, 2 & 3, by W. Richard Stevens (Addison-Wesley),
ISBN 0-201-63346-9

TCP/IP Network Administration, by Craig Hunt (O'Reilly & Associates),
ISBN 0-937175-82-X

Teach Yourself TCP/IP, by Timothy Parker, Ph.D. (SAMS Publishing),
ISBN 0-672-30549-6

Please

me and tell me if you liked my TCP information, or even if you have any contributing sites on similar info that I can include here.

Click here to go back to my Technical Page or here for the next 'TCP/IP In More Detail' burst (otherwise this page would be too long!!)

This page has been accessed times.

Last revised: Friday, 04 July 1997