The OSI isn’t a physical model, though. Rather, it’s a set of guidelines that application developers can use to create and implement applications that run on a network. It also provides a framework for creating and implementing networking standards, devices, and internetworking schemes.
The OSI has seven different layers, divided into two groups. The top three layers define how the applications within the end stations will communicate with each other and with users. The bottom four layers define how data is transmitted from end to end. Figure 1.7 shows the three upper layers and their functions, and Figure 1.8 shows the four lower layers and their functions.
When you study Figure 1.7, understand that the user interfaces with the computer at the Application layer and also that the upper layers are responsible for applications communicating between hosts. Remember that none of the upper layers knows anything about networking or network addresses. That’s the responsibility of the four bottom layers.
In Figure 1.8, you can see that it’s the four bottom layers that define how data is transferred through a physical wire or through switches and routers. These bottom layers also determine how to rebuild a data stream from a transmitting host to a destination host’s application.
Figure 1.9 shows a summary of the functions defined at each layer of the OSI model. With this in hand, you’re now ready to explore each layer’s function in detail.
Voice over IP and Video over IP on a network
The main purpose of the Host-to-Host layer is to shield the upper-layer applications from the complexities of the network. This layer says to the upper layer, “Just give me your data stream, with any instructions, and I’ll begin the process of getting your information ready to send.”
The following sections describe the two protocols at this layer:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
By understanding how TCP and UDP work, you can interpret the impact of applications on networks when using Voice and Video Over IP.
Transmission Control Protocol (TCP)
Transmission Control Protocol (TCP) takes large blocks of information from an application and breaks them into segments. It numbers and sequences each segment so that the destination’s TCP stack can put the segments back into the order the application intended. After these segments are sent, TCP (on the transmitting host) waits for an acknowledgment of the receiving end’s TCP virtual circuit session, retransmitting those that aren’t acknowledged.
Before a transmitting host starts to send segments down the model, the sender’s TCP stack contacts the destination’s TCP stack to establish a connection. What is created is known as a virtual circuit. This type of communication is called connection-oriented. During this initial handshake, the two TCP layers also agree on the amount of information that’s going to be sent before the recipient’s TCP sends back an acknowledgment. With everything agreed upon in advance, the path is paved for reliable communication to take place.
TCP is a full-duplex, connection-oriented, reliable, and accurate protocol, but establishing all these terms and conditions, in addition to error checking, is no small task. TCP is very complicated and, not surprisingly, costly in terms of network overhead. And since today’s networks are much more reliable than those of yore, this added reliability is often unnecessary.
User Datagram Protocol (UDP)
If you were to compare the User Datagram Protocol (UDP) with TCP, the former is basically the scaled-down economy model that’s sometimes referred to as a thin protocol. Like a thin person on a park bench, a thin protocol doesn’t take up a lot of room—or in this case, much
bandwidth on a network.
UDP doesn’t offer all the bells and whistles of TCP either, but it does do a fabulous job of transporting information that doesn’t require reliable delivery—and it does so using far fewer network resources. (UDP is covered thoroughly in Request for Comments 768.)
There are some situations in which it would definitely be wise for developers to opt for UDP rather than TCP. Remember the watchdog SNMP up there at the Process/Application layer? SNMP monitors the network, sending intermittent messages and a fairly steady flow of status updates and alerts, especially when running on a large network. The cost in overhead to establish, maintain, and close a TCP connection for each one of those little messages would reduce what would be an otherwise healthy, efficient network to a dammed-up bog in no time!
Another circumstance calling for UDP over TCP is when reliability is already handled at the Process/Application layer. Network File System (NFS) handles its own reliability issues, making the use of TCP both impractical and redundant. But ultimately, it’s up to the application developer to decide whether to use UDP or TCP, not the user who wants to transfer data faster.
UDP does not sequence the segments and does not care in which order the segments arrive at the destination. But after that, UDP sends the segments off and forgets about them. It doesn’t follow through, check up on them, or even allow for an acknowledgment of safe arrival—complete abandonment. Because of this, it’s referred to as an unreliable protocol. This does not mean that UDP is ineffective, only that it doesn’t handle issues of reliability.
Further, UDP doesn’t create a virtual circuit, nor does it contact the destination before delivering information to it. Because of this, it’s also considered a connectionless protocol. Since UDP assumes that the application will use its own reliability method, it doesn’t use any. This gives an application developer a choice when running the Internet Protocol stack: TCP for reliability or UDP for faster transfers.
So if you’re using Voice over IP (VoIP), for example, you really don’t want to use UDP, because if the segments arrive out of order (very common in IP networks), they’ll just be passed up to the next OSI (DoD) layer in whatever order they’re received, resulting in some seriously garbled data. On the other hand, TCP sequences the segments so they get put back together in exactly the right order—something that UDP just can’t do.
Key Concepts of Host-to-Host Protocols
Since you’ve seen both a connection-oriented (TCP) and connectionless (UDP) protocol in action, it would be good to summarize the two here. Table 1.1 highlights some of the key concepts that you should keep in mind regarding these two protocols. You should memorize this table.
No comments:
Post a Comment