|
|
It is useful to understand how TCP/IP operates in conjunction with other protocols so that the management of TCP/IP is clearer (you learn about managing a TCP/IP network in the next few days). You might find that some material today is repeated from earlier days, or rephrased slightly to present a different approach to the subject. In a sense, today acts as a summary, albeit incomplete, of the TCP/IP system as a whole.
To round out the day, I look at the miscellaneous optional services provided through TCP/IP. Most are dedicated to a simple task, but they do serve their purpose well and use TCP/IP, hence their inclusion here.
The layers of a TCP/IP protocol, as well as most other OSI-model protocols, are designed to be independent of each other, enabling mixing of protocols. When a message is to be sent over the network to a remote machine, each protocol layer builds on the packet of information sent from the layer above, adding its own header and then passing the packet to the next lower layer. After being received over the network (packaged in whatever network format is required), the receiving machine passes the packet back up the layers, removing the header information one layer at a time.
Replacing any layer in the protocol stack requires that the new protocols can internetwork with the other layers, as well as perform all the required functions of that layer (for example, duplicating the services of the replaced protocol). Also, performing duplicate operations in more than one layer (redundant operations) should be avoided for obvious reasons.
To examine the internetworking of the layers and the substitution or addition of others, a simple installation can be used as a starting point. Figure 8.1 shows a simple layered architecture using TCP and IP with the Ethernet network. Figure 8.1 also shows the assembly of Ethernet packets as they pass from layer to layer.
Figure 8.1. A simple layered architecture.
As you saw earlier in this book, the process begins with a message of some form from an Upper Layer Protocol (ULP) which itself is passing a message from an application. As the message is passed to TCP, it adds its own header information and passes to the IP layer, which does the same. When the IP message is passed to the Ethernet layer, Ethernet adds its own information at the front and back of the message and sends the message out over the network.
Although this simple model might seem ideal, in practice it has a few problems. Most importantly, it requires IP to interface directly with the Ethernet layer. This interface is not a clean one; it has many connections that break from the ideal layered architecture.
The operating system itself is not a single layer but runs throughout the entire layered architecture with connections to each layer. The interfaces between the each layer's protocols differ depending on the host machine, but it is convenient to ignore the operating system's influence for simplicity.
Figure 8.2. Network architecture.
The LAN involves some additional layers. The Logical Link Control (LLC) layer is an interface between the IP layer and the network layers. There are several kinds of LLC configurations, but it is sufficient at this point to know its basic role as a buffer between the network and IP layers either as a simple system for a connectionless service or as an elaborate system for a connection-based service. LLC is usually used with the High-Level Data Link Control (HDLC) link standard. For connectionless service, this uses an unnumbered information (UI) message frame, whereas connection-based services can use the asynchronous balanced mode (ABM) message frame, both supported by HDLC. The configuration of LLC with respect to TCP/IP is important.
The Media Access Control (MAC) layer was mentioned briefly on Day 2, "TCP/IP and the Internet." MAC is responsible for managing traffic on the network, such as collision detection and transmission times. It also handles timers and retransmission functions. MAC is independent of the network medium but is dependent on the protocol used on the network.
The physical layer in the Network architecture is composed of several services. The Attachment Unit Interface (AUI) provides an attachment between the machine's physical layer and the network medium. Typically, the AUI is where the network ports or jacks are located.
The Medium Attachment Unit (MAU) is composed of two parts: the Physical Medium Attachment (PMA) and the Medium Dependent Interface (MDI), both of which can be considered as separate parts as shown in the figure. The MAU is responsible for managing the connection of the machine to the LAN medium itself, as well as providing basic data integrity checking and network medium monitoring. The MAU has functions that check the signal quality from the network and test routines for verifying the network's correct operation.
When these layers are added to the layered architecture for a protocol stack, the IP-Ethernet layer is separated. This is shown in Figure 8.3. This type of configuration is more common than the one shown in Figure 8.1 and is usually called the IP/802 configuration (because Ethernet is defined by the IEEE 802 specification).
Figure 8.3. TCP/IP with LLC/MAC.
The IP/802 LAN can be connectionless using a simple form of LLC called LLC Type 1, which supports unnumbered information (UI). The LLC and MAC layers help separate IP from the physical layer. More headers are added to the message packet, but these have useful information. The LLC header has both source and destination service access points (SAP) in it to identify the layers above.
UDP is frequently used instead of TCP in this type of network. UDP is not as complex as TCP, so the entire network's complexity is reduced. However, UDP has no message integrity functionality built in, so a different form of LLC (called LLC Type 2) is used that implements these functions. LLC Type 2 provides the data integrity functionality that TCP usually provides, such as sequencing, transfer window management, and flow control. The disadvantage is that these functions are now below the IP layer, instead of above it. In case of fatal problems with the LLC layer, this can result in problems that must be dealt with in the application layer itself.
Figure 8.4. The NetBIOS Network architecture.
Three Internet port numbers are allocated for NetBIOS. These are for the NetBIOS name service (port 137), datagram service (port 138), and session service (port 139). There is also the provision for a mapping between Internet's Domain Name Service (DNS) and the NetBIOS Name Server (NBNS). (DNS is covered in detail on Day 11, "Domain Name Service.") The NetBIOS Name Server is used to identify PCs that operate in a NetBIOS area. In the interface between NetBIOS and TCP, a mapping between the names is used to produce the DNS name.
IP can be configured to run above NetBIOS, eliminating TCP or UDP entirely and running NetBIOS as a connectionless service. In this case, NetBIOS takes over the functions of the TCP/UDP layer, and the upper layer protocols must have the data integrity, packet sequencing, and flow control functions. This is shown in Figure 8.5. In this architecture, NetBIOS encapsulates IP datagrams. Strong mapping between IP and NetBIOS is necessary so that NetBIOS packets reflect IP addresses. (To do this, NetBIOS codes the names as IP.nnn.nnn.nnn.nnn.)
Figure 8.5. Running IP above NetBIOS.
This type of network requires that the upper layer protocols (ULPs) handle all the necessary features of the TCP protocol, but the advantage is that the network architecture is simple and efficient. For some networks, this type of approach is well suited, although the development of suitable ULPs can be problematic at times.
XNS can use IP, as shown in Figure 8.6. The Sequenced Packet Protocol (SPP) is above the IP layer, providing some TCP function, although it is not as complete a protocol. In the ULP layer is the Courier protocol, which provides presentation and session layer services.
Figure 8.6. The XNS Network architecture.
XNS uses the term Internet Transport Protocols to refer to the set of protocols used, including IP. Among the protocols is the Routing Information Protocol (RIP) and an error protocol similar to the Internet Control Message Protocol (ICMP).
Figure 8.7. The IPX Network architecture.
The stacking of the layers (with IPX above UDP) ensures that the UDP and IP headers are not affected, with the IPX information encapsulated as part of the usual message process. As with other network protocols, a mapping is necessary between the IP address and the IPX addresses. IPX uses network and host numbers of 4 and 6 bytes, respectively. These are converted as they are passed to UDP.
It is possible to reconfigure the network to use IPX networks by using TCP instead of UDP and substituting the connectionless LLC Type 1 protocol. This results in the architecture shown in Figure 8.8. When using this layer architecture, IP addresses are mapped using ARP.
Figure 8.8. An IPX-based Network architecture.
Figure 8.9. The ARCnet-based Network architecture.
A special placement of the IP datagram behind the client data area of the ARCnet header ensures that IP compatibility is maintained if the message must pass out of the ARCnet network (through a converter). IP addresses are mapped to ARCnet addresses using ARP. The protocol also supports RARP to some extent.
FDDI's addressing scheme is similar to other Ethernet networks, requiring a simple mapping, as seen with the Ethernet system. IP and ARP can both be used over FDDI. IP is used with the LLC Type 1 connectionless service.
The frame size for FDDI is set to 4,500 bytes, including the header and other framing information. After that is taken into account, there are 4,470 bytes available for data. (The Internet RFC for FDDI defines 4,096 bytes for data and 256 bytes for header layers above the MAC layer.) This large packet size can cause problems for some gateways, so routing for FDDI packets must be carefully chosen to prevent truncation or corruption of the packet by a gateway that can't handle the large frame size. In case of doubt, FDDI packets should be reduced in size to 576 data bytes.
Figure 8.10. The X.25-based Network architecture.
X.25 is not often used on a LAN, but it is used as a connection to a packet-switched network. An Internet RFC defines the rules for X.25 IP-based packet switching, including the limits for IP datagram sizes (576 bytes) and virtual circuits.
Figure 8.11. The ISDN-based Network architecture.
ISDN uses a more complex architecture than most networks, replacing gateways and routers with terminal adapters and ISDN nodes. These perform the equivalent functions but have a more rigid (and complex) internal architecture. The details are not relevant here, so the interested reader is referred to a good ISDN book.
SMDS using IP supports multiple logical IP subnetworks (LISs), which can be managed separately but treated as a single unit by SMDS. This method requires all the subnetworks to have to same IP address. The architecture of the SMDS layers is quite complex, so they are not covered in detail here. SMDS uses LLC Type 1 frames.
The router, gateway, or other device that accesses the high-speed network is more complex as well. Called a terminal adapter (as with ISDN), it provides a sophisticated interface between user layers and adaptation layers, which are application-specific. From the terminal adapter, traffic is passed to the ATM service, which provides switching and multiplexing services.
Windows 95 refines the network architecture used in Windows for Workgroups and Windows NT, resulting in better performance and reliability, as well as catering to the demands of different network requirements such as multiple protocol support. Because Windows 95 supports many different network protocols in 16- and 32-bit Virtual Mode Driver (VxD) versions, the architecture must provide the flexibility to accommodate a number of structures.
The Windows 95 architecture is layered; a layered architecture is the most common networking structure (such as OSI and TCP/IP). The network architecture used in Windows 95 is known as Microsoft's Windows Open Services Architecture (WOSA). WOSA was developed to enable applications to work with several different network types, and it includes a set of interfaces designed to enable coexistence of several network components.
The networking software components of Windows 95 are shown in their respective layers in Figure 8.12. Many of the network components are familiar from earlier versions of Windows for Workgroups, Windows NT, or other operating systems and communications protocols. I look at each layer in the Windows 95 architecture in a little more detail so that the function of each component is better understood. Because 32-bit applications are becoming dominant with Windows 95 and Windows NT, I'll look at them in this section. Older 16-bit applications are treated slightly differently, but the principles are the same.
Figure 8.12. The Windows 95 networking software architecture showing the components.
Windows 95's support for multiple protocols is achieved through the Network Driver Interface Specification (NDIS), which is a superset of the NDIS used in Windows for Workgroups and Windows NT. The NDIS 3.1 driver has three parts: the protocol itself (which can be implemented by third-party vendors) and protocol manager, the MAC or mini-port, and the mini-port wrapper. The NDIS protocol manager loads and unloads protocols as needed.
The version of NDIS included with Windows 95 adds plug-and-play enhancements and new mini-drivers. The plug-and-play capability is added to the protocol manager and the Media Access Control (MAC) layer, letting network drivers load and unload dynamically. The mini-driver (which is compatible with the mini-driver models used in Windows NT 3.5) decreases the amount of code that must be written to support a network adapter.
Windows 95 enables support for many network servers concurrently. This is an improvement over Windows for Workgroups 3.11, which enabled only its own network and one additional network. The server support of Windows 95 is provided by the Network Provider Interface (NPI). Using multiple network protocols at the same time, you can set up a Windows 95 machine to use TCP/IP for UNIX networks, and NetBEUI or IPX/SPX for local PC networks, if you want. Alternatively, as you see on Day 10, "Setting Up a Sample TCP/IP Network: DOS and Windows Clients," you can set Windows 95 to be a pure TCP/IP-based machine.
| Service | Port | Description |
| Active Users | 11 | Returns the names of all users on the remote system |
| Character Generator | 19 | Returns all printable ASCII characters |
| Daytime | 13 | Returns the date and time, day of the week, and month of the year |
| Discard | 9 | Discards all received messages |
| Echo | 7 | Returns any messages |
| Quote of the Day | 17 | Returns a quotation |
| Time | 37 | Returns the time since January 1, 1900 (in seconds) |
The TCP Character Generator monitors port 19, and upon connection ignores all input and sends a stream of characters back until the connection is broken. The order of characters is fixed. The UDP Character Generator service monitors port 19 for an incoming datagram (remember, UDP doesn't create connections) and responds with a datagram containing a random number of characters. Up to 512 characters can be sent.
Although this service might seem useless, it does have diagnostic purposes. It can ensure that a network can transfer all 95 printable ASCII characters properly, and it can also be used to test printers for their capability to print all the characters.
Both TCP and UDP versions monitor port 13 and, upon receipt of a datagram, return the message. The Daytime service can be used for several purposes, including setting system calendars and clocks to minimize variations. It also can be used by applications.
The Discard service might seem pointless, but it can be useful for routing test messages during system setup and configuration. It can also be used by applications in place of a discard service of the operating system (such as /dev/null in UNIX).
The Echo service provides very good diagnostics about the proper functioning of the network and the protocols themselves. The reliability of transmissions can be tested this way, too. Turnaround time from sending to receiving the echo provides useful measurements of response times and latency within the network.
The Time service is often used for synchronizing network machines or for setting clocks within an application.
$ telnet merlin 7 Trying... Connected to merlin.tpci.com Escape character is '^T'. This is a message This is a message Isn't this exciting? Isn't this exciting? <Ctrl+T> $ telnet merlin 13 Trying... Connected to merlin.tpci.com Escape character is '^T'. Tues Jun 21 10:16:45 1994 Connection closed. $ telnet merlin 19 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefg "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefgh #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghi $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghij %&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijk &'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijkl '()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijklm <Ctrl+T> $In this example, a connection to port 7 starts an Echo session. Everything typed by the user is echoed back immediately, unchanged. Then a connection to port 13 provides the Daytime service, showing the current date and time. The connection is broken by the service once the data is sent. Finally, the Character Generator is started. Both the Echo and Character Generator services were terminated with the Telnet break sequence of Ctrl+T.
I have also looked at several protocols that round out the TCP/IP family. These are mostly basic services, but they are essential to the proper operation of a TCP/IP-based network.
The MAC layer handles traffic for the network, including collisions and timers. The MAC is independent of the network's physical medium, but its exact role and implementation depend on the network protocols.
What is the difference between LLC Type 1 and LLC Type 2?
Logical Link Control (LLC) Type 1 is a simpler form that supports unnumbered information, designed for TCP. LLC Type 2 is for UDP and offers message integrity functionality.
What is XNS?
XNS is the Xerox Network System, a networking design that Xerox released to the public domain. Because XNS is essentially free, it has gained a lot of support. XNS supports Ethernet.
What is ISDN?
The Integrated Services Digital Network is a packet-switched high-speed network that supports broadband (many channel) communications.
Why is a simple network protocol like the Character Generator supported?
As simple as it may be, the Character Generator protocol (and many others like it) is used for basic tasks and queries that would require much more complex coding and operations when performed as part of a larger protocol. The Character Generator protocol is useful for testing communications. It is small, fast, easy to implement, and easy to understand.
