Mod-el: noun: 1–structural design, 2–a miniature representation, 3–an example for emulation or imitation The Merriam-Webster Dictionary Basic network architecture and construction is a good starting point when trying to understand how communication systems function, even though the topic is a bit dull. Architectures are typically based on a model showing how protocols and functions fit together. Historically, there have been many models used for this purpose, including, but not limited to, Systems Network Architecture (SNA-IBM), AppleTalk, Novell Netware (IPX/SPX), and the Open System Interconnection (OSI) model. Most of these have gone the way of the dodo due to the popularity of TCP/IP. TCP/IP stands for Transmission Control Protocol/Internet Protocol and represents a suite of protocols used on almost all modern communication systems. As the name suggests, this is the language of the Internet. This chapter focuses on the practical TCP/IP model, using the OSI model as a reference point. A model is a way to organize a system’s functions and features to define its structural design. A design can help us understand how a communication system accomplishes tasks to form a protocol suite. To help us wrap our heads around models, communication systems are often compared to the postal system (Figure 1-1). Imagine writing a letter and taking it to the post office. At some point, the mail is sorted and then delivered via some transport system to another post office. From there, it is sorted and given to a mail carrier for delivery to the destination. The letter is handled at several points along the way. Each part of the system is trying to accomplish the same thing—delivering the mail. But each section has a particular set of rules to obey. While in transit, the truck follows the rules of the road as the letter is delivered to the next point for processing. Inspectors and sorters ensure the mail is metered and safe, without much concern for traffic lights or turn signals.
A communication system is not much different, since messages created on a computer are processed and delivered, with each piece of equipment involved performing some function and obeying certain rules for transmission. Figure 1-2 depicts a typical scenario in which two computers are connected by their network cards via a networking device. Two people are communicating using an application such as an instant messaging or email program. At some point, we have to decide exactly how to handle this communication. After all, when you mail that letter, you cannot address the envelope in some arbitrary language or ignore zip codes, just as the mail truck driver cannot drive on the wrong side of the road.
So, how is the job of each device or connection determined? An application at the user level should not be responsible for choosing the encoding sequence or the signal type used between the client and server. The letter doesn’t decide to go by air or boat. Similarly, the network interface card (NIC) is not in the business of message header construction, just as the mail sorting system doesn’t care if you use pen or pencil when writing a letter.
Models are routinely organized in a hierarchical or layered structure. Each layer has a set of functions to perform. Protocols are created to handle these functions, and therefore, protocols are also associated with each layer. The protocols are collectively referred to as a protocol suite. The lower layers are often linked with hardware, and the upper layers with software. For example, Ethernet operates at Layers 1 and 2, while the File Transfer Protocol (FTP) operates at the very top of the model. This is true for both the TCP/IP and OSI models. Network traffic can also be viewed in terms of these layers, many of which can actually be seen using a packet capture tool like Wireshark. In Figure 1-3, the major layers of the TCP/IP model are displayed in a message going to a web server.
Before we go too far, let’s do a little reality check. A model describes the entire structure. At the beginning of the chapter, I stated that many networking models “have gone the way of the dodo.” There may have been good ideas in each, but everyone ended up using one model in particular—TCP/IP. For example, both Apple and IBM initially developed their own protocol suites, but converted to TCP/IP due to its popularity. This section explains the historical use of models and provides a more modern viewpoint.
Even a simple communication system is a complicated environment in which thousands or even millions of transactions occur daily. Interconnected systems are considerably more complex. A single electrical disturbance or software configuration error can prevent completion of these transactions.
Models provide a starting point for determining what must be done to enable communication or to figure out how systems using different protocols might connect to each other. They also help in troubleshooting problems. For example, how would a Novell NetWare client running IPX/SPX communicate with an IBM AS/400 over a TCP/IP-based network? Figure 1-4 depicts a scenario in which several different platforms might be required to interact with each other. Windows nodes are based on the TCP/IP protocol suite but, if required, can run Novell NetWare client software for network authentication. Novell developed internetworking and transport protocols called IPX and SPX. At the other end of the network, the IBM mainframe communicates via the protocols used in the SNA model. Imagine the programming and extra effort required to maintain all of the transactions between these separate architectures.
Another example is a network of Apple computers running AppleTalk while connecting to a network of Windows machines running TCP/IP.
As I’ve said, TCP/IP is the prevalent architecture today. The complexities of interplatform communication are dramatically reduced with TCP/IP. Protocol systems such as AppleTalk, NetWare, and SNA are considered legacy. However, understanding protocol layers on a particular communications device or how processes might interact on the network are still critically important ideas. When troubleshooting standard problems or potential security threats, the models and their associated layers offer logical reference points to begin the process. One would not start looking at the routing protocols if the link light was dark.
The OSI model is called a reference model. This means this particular model provides a method by which standards and protocols can be compared in order to assist in connectivity and consistency. Developers can use a reference model to understand how transmissions are framed and create methods to translate between systems.
The OSI basic model is standardized in ISO/IEC (International Standards Organization/International Electrotechnical Commission) 7498, which includes most of the definitions used here. These two organizations have actually created a Joint Technical Committee (JTC) that handles the issues associated with information technology. This model was developed in collaboration with the ITU-T and has also been printed as ITU-T Recommendation X.200. The ITU-T is the International Telecommunications Union—Telecom sector. Now that we’ve had our fill of acronyms, on to the standard.
The first version of ISO/IEC 7498 was written in 1984. This was replaced in 1994 by version 2, with additional corrections after that date. ISO/IEC 7498 has four parts:
Part 1—The Basic Model
Part 2—Security Architecture
Part 3—Naming and Addressing
Part 4—Management Framework
This section examines the basic model, which is defined in Section 6 of 7498-1 as having seven layers: Application, Presentation, Session, Transport, Network, Data Link, and Physical. Figure 1-5 depicts these layers and the connection to a similarly structured open system. An open system is one that adheres to this architecture.
Section 6 of the document also includes the guiding principles for layers, such as:
Not creating so many as to make the engineering of the system difficult
Reducing the number of interactions across a layer boundary
Collecting similar functions and separating fundamentally different functions
Identifying those that may receive a benefit by being based in hardware or software
Additionally, the OSI framework includes as its goals the improvement of current standards, flexibility, and the quality of being “open,” which simply means that systems have mutually adopted accepted standards for the exchange of information. Each layer defined in 7498-1 includes details about the functions and processes occurring at that layer. It is worth noting that this ISO/IEC/ITU-T document specifically states:
It is not the intent of this reference model to either serve as an implementation specification or to be a basis for appraising the conformance of actual implementations or to provide a sufficient level of detail to define precisely the services and protocols of the interconnection architecture.
So, the OSI model does not specify protocols, services, or rules to be used in a communication system, but it does detail the ideas and processes that may be required. Section 7 of 7498-1 provides some particulars for each of the layers, and these are summarized next (if you are driving heavy machinery, be careful!):
Application (Layer 7)Provides the sole means for the application to access the OSI environment (OSIE) with no layer above it. The functions are divided into connection mode and connectionless mode. Connection mode facilities include quality of service (QoS), security, identification of the parties, error control, and mode of dialogue. Connectionless facilities are essentially a subset of those already mentioned, without error control and some security.
Presentation (Layer 6)Handles the representation and preservation of the data provided by the Application Layer entities. Specifically, the Presentation Layer is focused on syntax that is acceptable to both ends and facilitates access to the layers above and below.
Session (Layer 5)Specifies both full-duplex and half-duplex modes of operation. This layer provides the means (setup and teardown) for communicating nodes to synchronize and manage the data passed between them. A mapping is provided between the Transport Layer and Session Layer (session service access point) addresses. Support is present for many-to-one session-to-transport addresses. The bulk of the responsibilities at this layer involve connection-oriented transmissions, but connectionless transmissions are also supported.
Transport (Layer 4)Protocols at this layer are end-to-end between communicating OSI nodes and deal primarily with low-cost and reliable transfer of data. A single Transport Layer address may be associated with many session addresses and provides the performance required by each session entity. Basic functions include transport connection establishment, release, data transfer, and QoS. While this layer is not responsible for routing, it does map to Network Layer addressing. All modes handle error control, but when running in connection-oriented mode, sequence control is required.
Network (Layer 3)Provides the means for managing network connections between open systems. This layer is not responsible for negotiating QoS settings, but rather focuses on routing between networks and subnetworks. Network Layer addresses uniquely identify transport entities. The Network Layer is also responsible for error control, sequencing, and mapping to the data link addresses.
Data Link (Layer 2)Responsible for the construction of the data link connection between Network Layer entities. The addresses used are unique within the open system set of devices. Like most of the OSI layers, connectionless and connection-oriented modes are utilized. In addition to interfacing with the Network Layer, the data link connection can be built upon one or more Physical Layer interfaces.
Physical (Layer 1)As in most models, the OSI Physical Layer contains the electrical, mechanical, and functional means to establish physical connections between Layer 2 devices. The interface is largely determined by the medium, but the bit-level transmissions must be organized into their physical service data units.
It is common to limit the discussion of the OSI reference model to the seven layer specifications. While these ideas have been discussed here, the OSI model also provides potentially valuable insight into the design and implementation of networking models and protocols. The architects of this model spent a lot of time thinking about and enumerating those items demanded at each layer and what is necessary for each to communicate with the layers immediately above and below it. As an example, Section 5 of 7498-1 includes discussion on the various aspects of layering. These include but are not limited to the following:
Communication between peer entities, including the following:
Modes of communication (connection or connectionless)
Relationships between services provided at each adjacent layer boundary
Mode conversion functions (Transport and Network Layers, primarily)
Identifiers such as N-address—unambiguous names used to identify a set of service access points at a particular layer
Properties of service access points
Definitions and descriptions of data units
Elements of layer operation:
Connections to/from
Multiplexing
Flow control
Segmentation
Sequencing
Acknowledgment
Protocol selection
Negotiation mechanisms
Connection establishment and release
Quality of service
Error detection
Along with these generalized aspects of communication within a layer model, further discussion regarding each individual layer is included where appropriate. For example, the section dedicated to the Transport Layer details connection establishment/release, data transfer, functions within the layer, addressing, multiplexing/splitting, and management. Where necessary (where a one-to-one mapping between services/addresses is not always present), a layer description will include details about the negotiation of the connections between the layers or even sublayers.
So far we’ve examined a layered model and outlined the responsibilities of each layer. What about the actual protocols? For every protocol used in the TCP/IP model, there is a corresponding (and perhaps more complex) version in the OSI/ITU-T architecture. For ease of access to the reference material, this section refers to the ITU-T X series of standards.
As stated previously, the model itself is described in ITU-T X.200. While the layers are also described, more-detailed specifications are contained within X.211−X.217bis. These additional documents are similar to RFCs for individual protocols in that they provide the rules and guidelines for those actually developing protocols, including state diagrams and primitive definitions. For both the Network and Transport Layers, special attention is paid to connectionless and connection-based communication. One of the major differences between these two forms of transmission is controlling the flow of information between endpoints. It is interesting that the two Layer 4 protocols used today—TCP and the User Datagram Protocol (UDP)—are differentiated from each other in the exact same way, with TCP characterized as connection-oriented while UDP is connectionless. TCP is very concerned with sequence numbers and ensuring that all packets arrive at the destination. UDP is not.
Figure 1-6 is from ITU-T X.220 and shows the protocols to be used. The original diagram is quite large, so only a portion of it is shown here. While a bit old (written in 1993), it does provide some insight into the structure of the model. Many of the protocols are outdated, but we can see the modularity of the protocol stack that aids in subsystem replacement. For example, at the lower layers, X.25 has been replaced by Frame Relay and ATM. These, in turn, have been replaced by the transmission standards we use today.
As a practical matter, OSI/ITU-T protocols are not seen nearly as often as the protocols specified for use in the TCP/IP model, although there are exceptions. Some wide area network (WAN) connections continue to use these specifications, and, of course, we still have traditional telephony systems. Perhaps one of the best examples of an ITU-T standard that continues to survive even as more and more communications shift to TCP/IP is in the area of Voice over IP (VoIP). H.323, Q.931, and G.711 are still a big part of contemporary VoIP transmissions, as shown in Figure 1-7. H.225 is part of H.323.
The Internet and almost all networks in use today have standardized on the TCP/IP model. It is often referred to as the language of the Internet, because applications are typically built around this protocol suite. Figure 1-8 shows the TCP/IP model and some of the more well-known protocols and corresponding layers. At Layer 4 (the Transport Layer), there are actually two protocols present—TCP and UDP. While this model shares its name with the former, many operations are based on UDP, so Layer 4 is shared by the two protocols. Layers 1 and 2 are governed by the local area network protocol, but Layer 3 belongs to IP, with Internet Control Message Protocol (ICMP) and Internet Group Membership Protocol (IGMP) components of IP-based operations.
The TCP/IP model does not specify any particular protocol to be run at the lower (LAN) layers. Historically, networks have been built upon many technologies, including Fiber Distributed Data Interface (FDDI), LocalTalk, Token Ring, Ethernet, and wireless protocols from the 802.11 family of standards. Today, only Ethernet and 802.11 in their various forms survive, and even these have eliminated certain variations. For example, Ethernet based on coaxial cable and 802.11 frequency hopping are almost nonexistent.
In a typical network, most of the decisions regarding protocols—at least for Layers 1−4—are made for you, and the real variation is in the applications you choose to deploy. This argument can even be made for advanced technologies such as voice communications, where traditional circuit-switched telephone systems are quickly being replaced by VoIP. The dominance of the TCP/IP model can be demonstrated using a tool within Wireshark. Examining the protocol distribution for a particular network segment reveals a picture (shown in Figure 1-9) of the protocols in use.
On the left is packet capture data from a Windows machine and on the right is data from a Mac OS platform. Nearly 100 percent of the Layer 3 traffic caught is IPv4, with a small amount of IPv6. At Layer 4, TCP and UDP dominate, with ARP and 802.1x contributing. Missing from the data collected are protocols from any other model.
Comparing the TCP/IP and OSI models, it can be said that the functions are the same but the structure is different. Figure 1-10 shows a side-by-side comparison of the OSI and TCP/IP model layers. Layers 5–7 of the OSI model map to Layer 5 of the TCP/IP model.
The TCP/IP model is presented in RFCs 1122 and 1123. These documents, released in 1989, provide the same level of detail encompassed in the ISO/IEC standard. An examination of the standard dates, historical deployments, and the difference in complexity between the two models provides insight into the adoption of TCP/IP over the OSI model. If you survived reading the earlier OSI section, you might be left with the impression that the OSI model is very complex in comparison to TCP/IP. A quick look at the “companion” RFCs that go along with RFCs 1122 and 1123 also reveals a significant level of complexity. To quote from RFC 1122:
This RFC enumerates standard protocols that a host connected to the Internet must use, and it incorporates by reference the RFCs and other documents describing the current specifications for these protocols. It corrects errors in the referenced documents and adds additional discussion and guidance for an implementor.
For each protocol, this document also contains an explicit set of requirements, recommendations, and options. The reader must understand that the list of requirements in this document is incomplete by itself; the complete set of requirements for an Internet host is primarily defined in the standard protocol specification documents, with the corrections, amendments, and supplements contained in this RFC.
As with the OSI model, each layer of the TCP/IP model has a particular set of responsibilities. While most of these are defined in RFC 1122, those for the Application Layer come from RFC 1123. One significant difference between the two models is that RFC 1122 does specify particular protocols at the various layers. What follows are some of the major requirements of what must occur at each layer:
ApplicationThe top TCP/IP layer combines the OSI Application and Presentation Layers and includes user-based and support/management protocols. Items at this layer must do the following:
Support flexibility (naming and length) in hostnames
Map domain names appropriately
Handle DNS errors
Telnet, FTP, Trivial FTP, the Simple Mail Transport Protocol (SMTP), and the Domain Name System (DNS) all have more specific additional requirements.
TransportThis layer provides end-to-end communication services based on either TCP (connection-oriented) or UDP (connectionless). TCP is much more concerned with sequence numbers and handshaking than UDP. Items at this layer must do the following:
Pass IP options and Internet Control Message Protocol messages to the Application Layer
Be able to handle and manipulate checksums
Support IP addresses, including local and wildcard addresses, such as broadcast, multicast, and unicast destinations
Treat window size as an unsigned number
Manage window size effectively and allow 0 window size
Support urgent data and a pointer to the last octet of the urgent data
Support TCP options
Gracefully handle opening of connections
Silently discard improper connection requests
Handle retransmissions per recommended algorithms
Follow recommended procedures when generating ACKs (acknowledgments)
Gracefully handle connection failures
The Internet Layer specifies the use of IP, ICMP, and the Internet Group Management Protocol. Operationally, this is a connectionless “best effort” protocol concerned with addressing, type of service (ToS), security, and fragmentation. It relies on upper-layer protocols for accurate delivery. Items in this layer must do the following:
Handle remote multihoming
Meet the appropriate gateway specification, if used
Discard improper IP and ICMP packets
Properly handle all forms of addressing, including subnets
Maintain packet IDs
Support ToS and reassembly
Support source routing options
This is the network interface, and includes framing and media access to communicate directly with the network to which it is attached. Items at this layer must:
Clear the ARP cache
Prevent ARP floods
Send and receive RFC 894−encapsulated datagrams (should also support IEEE 802)
Use ARP on Ethernet and IEEE 802 networks
Report Link Layer broadcasts to the Internet Layer
Receive IP ToS values
Typically, the network interface card or port defines the Physical Layer. Each LAN protocol has within its specification the electrical and mechanical characteristics for communication on the link. These include items such as voltage level, encoding, pin assignments, and the shape of the interface.
Not all of the requirements were actually implemented in protocol suites running on hosts and network equipment. For example, IP hosts were intended to be much more active in detecting gateway or next hop failures. The reality is that if a gateway fails, hosts simply can’t communicate to destinations outside their networks.
The models discussed in this chapter are usually drawn from the top layer (Application) down. Wireshark displays them in reverse order, as shown in Figure 1-11, where the protocols corresponding to Layers 1–5 are identified. This packet happens to be from a VoIP conversation. Starting from the bottom of the model, we see Ethernet Type II (also called Ethernet Type 2 or Ethernet II). Ethernet as a protocol exists at Layers 1 and 2, with Layer 2 defining the frame (error control, addressing, etc.) and the Ethernet network interface defining the Physical Layer (Layer 1) characteristics.
In addition, Layer 2 LAN protocols can be split into two major areas: Logical Link Control (LLC) and Media Access Control (MAC). These become sublayers within the model. LLC functions include frame construction, error control, and addressing. The MAC layer defines line discipline and network transmission. Specifically, this includes a method for determining which node is in line to communicate and for how long. Figure 1-12 depicts these TCP/IP sublayers. Sublayers are also found in the OSI model.
Encapsulation is the method by which the various layers interact and pass information up and down the protocol stack. A message generated by an application must be formatted for transmission. On the sending node, the upper layer places packaging around the message that describes the application used to generate the message. This is called the header. The package and header are then passed to the next layer down. Each layer completes its own required encapsulation operation, which includes a header.
By the time the message reaches the bottom of the protocol stack, it has several of these wrappers. This process is the encapsulation. For ease of processing, each header contains information regarding the contents. Thus, the Ethernet header provides some indication that it has encapsulated IP, the IP header indicates that it is carrying TCP, and so on. Basic encapsulation and the encapsulation specific to the packet in Figure 1-11 are shown in Figure 1-13.
At the receiving node, the same process occurs, but in reverse. Each layer, beginning with the lowest, processes the appropriate information and strips off the outermost wrapper before handing the message to the next layer up. This continues as the message travels up the stack until the last bit of packaging is removed. This process is called de-encapsulation.
The packet shown in Figure 1-14 has been expanded to reveal the headers. Each layer contains a code identifying the content of the encapsulated data. Ethernet uses the code 0800 to indicate that IP is encapsulated. At Layer 3, IP uses code 17 to show that it has encapsulated UDP. At Layer 4, UDP uses port numbers to direct the data to the proper process or application. The receiver uses this information to properly parse and de-encapsulate the data.
Addressing used within networked systems can also be tied to layers and equipment, as shown in Figure 1-14. Some protocols require addressing as part of their basic operation. For example, an Ethernet switch processes Layer 2 frames, which contain addresses called hardware or MAC addresses. For example, the source MAC address in Figure 1-14 is 00:11:25:43:49:97. The Internet Protocol uses IP addresses at Layer 3, and these are processed by routers. In this case, the source is 192.168.1.1 and the destination is 239.255.255.250. Both TCP and UDP communicate via port numbers at Layer 4. Thus, a TCP/UDP message possesses not only the port numbers necessary to communicate with an application, but also the IP and MAC addresses necessary to complete the transmission. Understanding relationships like these better prepares the network administrator to build, troubleshoot, or secure the infrastructure. For example, if the administrator is concerned about port scanning at Layer 4, it is unlikely that solutions will be found by working with the network switches down at Layer 2.
Layering the model can also provide a picture of device responsibilities. Each device on a network is designed for a particular task. They have different levels of intelligence and process traffic in a variety of ways. Applying the layers to equipment makes the impact on traffic and the capabilities of the devices at a particular location easier to understand. Routers and switches form the building blocks of almost any network. While they have many individual features and can be configured for a variety of functions, they all provide the same basic services when you plug them in, regardless of the vendor. The relationship between devices, addressing, and the layers is outlined in Figure 1-15.
Switches operate at Layer 2 and forward LAN frames based upon the MAC addresses contained within those frames. They also perform error checking for each frame. Switches provide some measure of network segmentation, since the processing of MAC addresses will result in network traffic control. Switches have a variety of management features, such as support for SNMP and virtual local area networks (VLANs).
Routers operate at Layer 3 and process IP packets. They will read Layer 2 frames when their MAC addresses appear in the frames, but their main function is to get IP packets to the proper destination. In so doing, the router calculates the IP header checksum and can act on any QoS or fragmentation information the packet contains. Many routers also support advanced features such as firewalling, virtual private network (VPN) termination, authentication, and network address translation (NAT).
The term gateway has several meanings. Routers and network hosts are configured with a default gateway, but this is actually a router. It is called a default gateway because this is the network path to the rest of the world. The more traditional gateway existing at Layer 4 is a device used to convert between systems that do not share the same networking model. This type of environment is depicted in Figure 1-4, and requires protocol translation for network nodes to communicate. We might say this sort of thing is another legacy item, but with the emergence of VoIP, the gateway is making a comeback. The language of the public switched telephone network (PSTN) is Signaling System 7 (SS7). A gateway that understands both TCP/IP and SS7 is required if an IP-based VoIP phone is to communicate with a traditional telephone.
Not all devices fit neatly into boxes. An access point is sometimes referred to as a wireless hub because it broadcasts certain kinds of traffic everywhere. However, like an Ethernet switch, the access point not only is aware of MAC addresses but also uses them to make some forwarding decisions. More recently, the emergence of multilayer switching has blurred the line between processing frames at Layer 2 and some of the higher-level functions like routing. Figure 1-16 provides an example of how these devices and addresses interact within the confines of the protocol layers.
The OSI and TCP/IP models provide an architecture in which the functions and rules for communication, addressing, and equipment are organized. The OSI model is standardized in ITU-T X.200, and the companion documents X.211−X.217 and X.220 provide the specifications for the developers and protocols. The TCP/IP model is described in RFC 1122, which lists the required protocols for hosts that communicate on the network.
The OSI model, now primarily considered a reference model, is in limited use. The TCP/IP model is the language of the Internet. Adoption of IP-based communication in many systems, such as VoIP, will further marginalize the OSI model’s use—a factor not lost on major companies like Apple and Novell, which have adopted the TCP/IP model.
Modern practitioners and researchers will be well served by an understanding of standards for communication requirements in widely varying conditions. These architectures help us to better understand the evolution of communication standards.
ISO/IEC 7498-1: “Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model”
ITU-T X.200: “Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model”
ITU-T X.220: “Use of X200-Series Protocols in CCITT Applications”
RFC 1122: “Requirements for Internet Hosts—Communication Layers”
RFC 1123: “Requirements for Internet Hosts—Application and Support”
What is the name of the process by which an upper-layer protocol is wrapped up in a lower-layer protocol?
Name four communication models.
What two documents specify the standardization of the OSI model?
How many layers are in the OSI and TCP/IP models, respectively?
Name the layers of the OSI model.
Name the layers of the TCP/IP model.
What two documents present and detail the use of the TCP/IP model?
There are two forms of communication described in both standards. These forms are predominantly part of Layers 3 and 4. What are they?
Network administrators typically have the ability to use whatever protocols they wish, regardless of the layer in question. True or false?
One big difference between the documentation of the TCP/IP and OSI standards is that the TCP/IP RFC specifies the protocols to be used and the OSI ITU-T model documentation does not. True or false?
For each address type or device, specify its proper layer (Layer 2, Layer 3, or Layer 4):
Switch
Router
Gateway
MAC address
IP address
Port number
Encapsulation
TCP/IP, OSI, SNA, AppleTalk, Novell (IPX/SPX)
ISO/IEC 7498 and ITU-T X.200
7, 5
Application, Presentation, Session, Transport, Network, Data Link, Physical
Application, Transport, Internet, Data Link, Physical
RFCs 1122 and 1123
Connection-mode (oriented) and connectionless-mode
False
True
a) Layer 2, b) Layer 3, c) Layer 4, d) Layer 2, e) Layer 3, f) Layer 4
Materials: Wireshark and a network connection Start a capture. Complete several different transactions from your computer. Stop the capture and examine the individual packets. Find examples of the following: ARP, ICMP, TCP, UDP, and IPv6. Describe these packets in terms of their encapsulation or protocol stacks.
Materials: Wireshark and a network connection
Start a capture and allow it to run for several minutes (the longer, the better).
Complete as many different transactions from your computer as possible.
From the Statistics menu in Wireshark, select Protocol Hierarchy.
Examine the distribution of protocols and attempt to determine the models used and the level of traffic specific to each protocol. What is the most common upper-layer protocol? What caused it to be generated?
Using the models discussed in this chapter as references, develop a series of rules or parameters that describe a conversation between two people who have never met. Considerations might include the mode of communication, language, nonverbal communication, access method, body language, expressions, speed, and parameter negotiation.
Get Packet Guide to Core Network Protocols now with the O’Reilly learning platform.
O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.