Figure A: TCP/IP's structure is related to the OSI model.
Communication between systems conforming to the OSI model takes place on an assembly line. One system assembles a packet through all seven layers from application to physical and then sends the packet to another system. Ideally, the other system receives the packet at the physical layer and can push the packet up to the application layer, disassembling part of the packet at each layer.
You can compare the seven layers of the OSI models to seven managers with unique job responsibilities. Each layer cannot act autonomously but rather has to coordinate its efforts with those layers above and below it.
Metaphorically speaking, TCP/IP adopted this management philosophy in spirit, but changed some management titles and positions. TCP/IP delegated the management responsibilities of the presentation and session layers to the application layer. The transport layer kept its job, while upper management asked the network layer to learn some new Internet skills. The data link and physical layers merely changed their respective titles to network interface and hardware to reflect the attitudes of the TCP/IP mission statement.
TCP/IP's application layer
As we mentioned, TCP/IP integrates the functionality of the OSI models session, presentation, and application layers into the application layer. Lets look at what the session and presentation layers in the OSI model do and see how they relate to TCP/IP's application layer.
The responsibilities of the OSI model's session layer are similar to those of a secretary who coordinates office meetings, appointments, and phone conversations with the superiors (the application and presentation layers). The superiors are often busy communicating with someone else and can't always be reached. So, the secretary must prioritize incoming and outgoing messages. This can mean putting people on hold, calling people back, rescheduling meetings, and so on.
The presentation layer is best described as the application layer's official spokesperson. He has the tact and poise it takes to interpret incoming messages (formatting data) into useful information that the application layer understands. The application layer takes advantage of the spokesperson's skills by letting him convert words to meaningful data (unformatting information) that the secretary (session layer) will understand.
The application layer contains useful network programs that you, the user, will understand. The application layer takes orders from you when it comes to tasks such as transferring files, checking your email, or using software that incorporates TCP/IP's network access capabilities. In TCP/IP, these applications also perform the duties of the session and presentation layers via Windows Sockets.
TCP/IP's transport layer
Understanding the transport layer in TCP/IP means knowing the TCP and UDP protocols. In an office environment, it's like deciding which postal courier to use, Federal Express or the US Mail. Federal Express is known for its on-time performance, accuracy, reliability, and delivery of parcels while the US Mail we associate with mere delivery (ideally). In a similar comparison, TCP monitors and controls data that's sent across the network while UDP doesn't. Applications use UDP when they monitor their own communication and don't need the control and overhead of TCP.
TCP/IP's Internet layer
As shown in Figure A, OSI's network layer corresponds to TCP/IP's Internet layer. Here, TCP/IP routes packets using four protocols: IP (Internet protocol), ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol), and RARP (Reverse Address Resolution Protocol). NT doesn't support RARP, which allows systems that don't have an Internet address to obtain one. Each protocol routes packets a certain way. Just as a postal service will route packages in envelopes, bags, or boxes, depending on the type and amount of the shipment, so the type and amount of data you're sending or receiving will help you determine which routing protocol to use.
TCP/IP's network interface layer
The network interface layer corresponds to the OSI model's data link layer. The data link layer defines the rules for sending and receiving data between two networked systems. Similarly, the network interface layer acts as a filter between the Internet layer and the hardware layer, converting data into a standardized format that each can understand. Just as Federal Express can use ground, air, sea, and electronic transmission of packages, TCP/IP can use many popular network technologies like Ethernet, Token Ring, and FDDI to transmit its packets. That's one reason why TCP/IP is so popular.
TCP/IP's hardware layer
The hardware layer refers to the circuits, resistors, nuts, and bolts of your physical network, including your FDDI, Token Ring, and Ethernet cards. This component has less to do with TCP/IP and more with how your networking hardware works. Just as Federal Express isn't going to invest its hard-earned delivery dollars in faulty planes, trains, and automobiles, you're not going to apply equipment to your network that doesn't work with your hardware and software (like TCP/IP).
That administrative hassle--Internet addresses
As we mentioned, TCP/IP routes data through the network from system to system. How does it know where to go? The answer is Internet addresses (often called IP addresses). Everything that communicates through TCP/IP has to have an Internet address, including workstations, printers, and routers. Internet addresses help TCP/IP deliver messages through complicated pathways via routers.
Postal couriers have specific addresses to deliver mail to and they also have various locations where they store mail. Similarly, in TCP/IP, the end systems have delivery addresses where packets should be sent, while the routers maintain the intermediate locations that the packets are sent through.
Also, just as postal couriers use intermediate locations for mail that's being delivered to more than one address, routers are capable of sending packets to multiple locations.
What Internet addresses look like, where they come from, and how to get one
Generally, Internet addresses are comprised of three sections, as shown in Figure B. The address type refers to five (at present) types of addresses you can use: classes A through E. The network identifier identifies the TCP/IP network. The host identifier identifies the individual system on the network. No matter what the class, each address is 32 bits long.
Figure B: Internet addresses contain three sections.
To get the class address you must divide the 32-bit address into four groups of eight bits each. Then you convert these binary 8-bit groupings (octets) to decimal and separate them with a period. For example, we can convert the following 32 bits into four groups of eight:
01110000011001100110010000000001
01110000 01100110 01100100 00000001
This is a class A address. An address is class A when the first bit equals 0, class B when the first two bits equal 10, class C when the first three bits equal 110, and class D when the first four bits equal 1110 (class E is still unknown). Now, we'll convert these bits to decimals and separate the decimal numbers with periods, like so:
120.51.50.1
Since this is a class A address, 120 is the network identifier while 51.50.1 is the system address. If this were a class B address, 120.51 would be the network identifier and 50.1 the host identifier. If it were a class C address, 120.51.50 would be the network identifier and 1 the host identifier. If it were a class D address, 120.51.50.1 would be the network identifier with no host identifier.
You have a lot more room for hosts than network identifiers in a class A address. In fact, the number of networks you can maintain per class type is inversely proportional to the number of hosts you have. Microsoft's TCP/IP documentation clarifies this point by using the class comparison shown in Table A.
Table A: Class comparison
Class | Available networks | Available hosts per net |
A | 126 | 6,777,214 |
B | 16,384 | 5,534 |
C | 2,097,151 | 54 |
Therefore, if you're administering very large networks with many hosts, you need a class A address. Most organizations have class B addresses that use LAN distributed network technology. You'd generally use class C addresses for small networks and class D addresses for multicasting. Class E addresses are still experimental.
Note: Multicasting is a way to distribute a one-to-many messaging scheme via the class D address. This becomes important in such areas as video conferencing because it reduces the bandwidth necessary to transmit video and radio transmissions. For example, a test project between CNN and Intel would allow users connected to Ethernet to watch Headline News and CNN. |
Notice that a multicast transmission is a one-way transmission (traffic) from the sender to many receivers (class D addresses don't have a host ID necessary for two-way communication).
When you assign an Internet address to the system, you also need to give the
system a subnet mask. TCP/IP uses a subnet mask when it wants to connect two addresses together. TCP/IP applies the subnet mask to determine if both addresses are on the same network. A subnet mask acts as a filter that strains all other information away from the Internet address so that only the host identifier remains. A subnet mask also comprises 32 bits.
For example, subnet mask 255.0.0.0 is for class A addresses, 255.255.0.0 is for class B, 255.255.255.0 is for class C, and 255.255.255.255 is for class D. We'll use the class A subnet mask to show how TCP/IP determines whether two class A addresses, 120.51.50.1 and 120.63.54.5, are on the same network. We'll filter each address (in binary) with the class A subnet mask using the logical AND operator just as TCP/IP would.
The subnet mask strained the host identifier to reveal the network identifier for each class A address. As you can see, the end result of each AND operation on each address is identical. Therefore, each Internet address is on the same network. After TCP/IP verifies this equality, it can set up a connection where the two systems and those addresses can begin to transfer information.
Copyright © 1999, ZD Inc. All rights reserved. ZD Journals and the ZD Journals logo are trademarks of ZD Inc. Reproduction in whole or in part in any form or medium without express written permission of ZD Inc. is prohibited. All other product names and logos are trademarks or registered trademarks of their respective owners.