The application layer (Layer 7) processes the final header and then can examine the true end-u...

04.35700737 CH03 Page 83 Wednesday, February 17, 1999 2:45 PM



The OSI, TCP/IP, and Novell NetWare Network Protocol Architectures



83



address in the network layer header. If the intervening routers do not cooperate by performing

their network layer tasks, the packet will not be delivered to the true destination.

To interact with the same layer on another computer, each layer defines a header and in some

cases a trailer. Headers and trailers are additional data bits, created by the sending computer’s

software or hardware that are placed before or after the data given to Layer N by Layer N+1.

The information needed for the layer to communicate with the same layer process on the other

computer is encoded in the header and trailer. The receiving computer’s Layer N software or

hardware interprets the headers and trailers created by the other computer’s Layer N, learning

how Layer N’s processing is being handled in this case.

Figure 3-3 provides a conceptual perspective on the concept of same-layer interactions. The

application layer on Host A communicates with the application layer on Host B. Likewise, the

transport, session, and presentation layers on Host A and Host B also communicate. The bottom

three layers of the OSI model have to do with delivery of the data; Router 1 is involved in that

process. Host A’s network, physical, and data link layers communicate with Router 1, and

likewise, Router 1 communicates with Host B’s physical, data link, and network layers. Figure

3-3 provides a visual representation of the same-layer interaction concepts.

Figure 3-3 Same Layer Interactions on Different Computers

Host A



Host B



Application



Application



Presentation



Presentation



Session



Session



Transport



Transport

Network



Network



Data Link



Data Link



Data Link



Physical



Physical



Physical



Router 1



NA2603q3



Network



Data Encapsulation

The concept of placing data behind headers (and before trailers) for each layer is typically

called encapsulation by Cisco documentation. As seen previously in Figure 3-2, when each

layer creates its header, it places the data given to it by the next higher layer behind its own

header, thereby encapsulating the higher layer’s data. In the case of a data-link (Layer 2)

protocol, the Layer 3 data is placed between the Layer 2 header and Layer 2 trailer. The physical

layer does not use encapsulation because it does not use headers or trailers.



04.35700737 CH03 Page 84 Wednesday, February 17, 1999 2:45 PM



84



Chapter 3: Understanding the OSI Reference Model



Again referring to Figure 3-2, Step 1, the following list describes the encapsulation process

from user creation of the data, until the physical signal is encoded at Step 2:

1. The applications create the data.

2. The application layer creates the application header and places the data behind it.

3. The presentation layer creates the presentation header and places the data behind it.

4. The session layer creates the session header and places the data behind it.

5. The transport layer creates the transport header and places the data behind it.

6. The network layer creates the network header and places the data behind it.

7. The data-link layer creates the data-link header and places the data behind it.

8. The physical layer encodes a signal onto the medium to transmit the frame.



The previous eight-step process is accurate and meaningful for the seven-layer OSI model.

However, CCNA exam objective 5 uses a slightly different view of the process. (This different

view is based on the ICRC course.) The “five steps of data encapsulation” from the previous

objective are in the following list:

1. Create the data.

2. Package the data for transport. In other words, the transport layer creates the transport



header and places the data behind it.

3. Add the destination network layer address to the data. In other words, the network layer



creates the network header and places the data behind it.

4. Add the destination data-link address to the data. In other words, the data-link layer



creates the data-link header and places the data behind it.

5. Transmit the bits. In other words, the physical layer encodes a signal onto the medium to



transmit the frame.

CCNA exam objective 5 basically modifies the steps of encapsulation to match with TCP/IP.

With the TCP/IP model, after the application negotiated parameters, the headers used will be a

TCP or UDP header, an IP header, and then an appropriate data-link header or trailer. The

addition of those three headers makes up the middle three steps in the five-step process

according to the course. The first step is the application handing the data to the transport layer

(TCP or UDP). The final (fifth) step is the physical layer encoding the signal onto the media.

Figure 3-4 depicts the concept; the numbers shown represent each of the five steps.



04.35700737 CH03 Page 85 Wednesday, February 17, 1999 2:45 PM



The OSI, TCP/IP, and Novell NetWare Network Protocol Architectures



85



Figure 3-4 TCP/IP Headers and Trailers

1.



Data



2.



TCP Data



Transport



IP



TCP Data



Internet



IP



TCP Data



3.



LH



LT



Network

Interface

NA260303



4.



Application



5.



Some common terminology is needed to discuss the data that a particular layer is processing.

Layer N PDU (protocol data unit) is a term used to describe a set of bytes that includes the Layer

N header and trailer, all headers encapsulated, and the user data. From Layer N’s perspective,

the higher layer headers and the user data forms one large data or information field. A few other

terms also describe some of these PDUs. The Layer 2 PDU (including the data-link header and

trailer) is called a frame. Similarly, the Layer 3 PDU is called a packet, or sometimes a

datagram. Finally, the Layer 4 PDU is called a segment. Figure 3-5 illustrates the construction

of frames, packets, and segments and the different layers’ perspectives on what is considered to

be the data.

Figure 3-5 Frames, Packets, and Segments

Data



IP



LH



Segment



Data



Packet



IP



Data



LT



Frame



The TCP/IP and NetWare Protocols

Two of the most pervasively deployed protocols are TCP/IP and NetWare. Not coincidentally,

they are the two most important protocols you need to know to pass the CCNA exam. Each of

these are covered in detail in Chapters 5, “Network Protocols: Understanding the TCP/IP Suite

and Novell NetWare Protocols;” 6, “Understanding Routing;” and 7, “Understanding Network

Security.”



04.35700737 CH03 Page 86 Wednesday, February 17, 1999 2:45 PM



86



Chapter 3: Understanding the OSI Reference Model



In this short section, TCP/IP, Novell, and OSI are compared. The goal is to provide some

insights into what some popularly used terminology really means. In particular, routing is

defined as a Layer 3 process; in this section, we will review how that term relates to TCP/IP and

NetWare.

For perspective, Figure 3-6 shows the layers of these two protocols as compared with OSI.

Figure 3-6 OSI, TCP/IP, and NetWare Protocols

OSI



TCP/IP



NetWare



Application



SAP, NCP



Application

Presentation

Session

Transport



TCP



UDP



SPX



IP, ARP, ICMP



IPX



Data Link



Network

Interface



MAC

Protocols



Physical



NA260305



Network



As Figure 3-6 illustrates, the IP and IPX protocols most closely match the OSI transport layer—

Layer 3. Many times, even on the CCNA exam, IP and IPX will be called Layer 3 protocols.

Clearly, IP is in TCP/IP’s Layer 2, but for consistent use of terminology, it is commonly called

a Layer 3 protocol. Both IP and IPX define logical addressing, routing, the learning of routing

information, and end-to-end delivery rules.

The lower layers of each stack, as with OSI Layers 1 and 2 (physical and data link, respectively), simply refer to other well-known specifications. For example, the lower layers all

support the IEEE standards to Ethernet and Token Ring, the ANSI standard for FDDI, the ITU

standard for ISDN, and the Frame Relay protocols that are specified by the Frame Relay Forum,

ANSI, and the ITU.



04.35700737 CH03 Page 87 Wednesday, February 17, 1999 2:45 PM



Connection-Oriented Protocols, Connectionless Protocols, and Flow Control



87



Connection-Oriented Protocols, Connectionless

Protocols, and Flow Control

CCNA Objectives Covered in This Section

2



Describe connection-oriented network service and connectionless network service, and

identify the key differences between them.



6



Define flow control and describe the three basic models used in networking.



This section addresses two interrelated CCNA objectives. Definitions are needed for all the

terms. Also, a solid understanding of how connection-oriented protocols work is necessary to

understand flow control fully. Finally, in objective 6, the “three basic models used in

networking” needs some clarification.



Connection-Oriented Versus Connectionless Protocols

The terms connection-oriented and connectionless have some relatively well-known

connotations inside the world of networking protocols. Table 3-2 summarizes what is meant by

each.

Table 3-2



Connection-Oriented Versus Connectionless Protocols

Type



Functions



Examples



Connection-oriented



Error Recovery (reliability)



LLC type 2 (802.2), TCP (TCP/IP), SPX

(NetWare), X.25



Connection-oriented



Pre-established pathing



X.25 Virtual Circuits (X.25), Frame Relay

Virtual Circuits (no error recovery), ATM

Virtual connections



Connectionless



Simple delivery of data; no

overhead for error recovery or

set-up flows to establish a

path. No error recovery, no

pre-established connections



IPX (NetWare), UDP (TCP/IP), IP

(TCP/IP), LLC type 1 (802.2)



As you might have noticed, two characteristics cause a protocol to be considered connectionoriented: error recovery and a pre-established path through a network. A particular protocol

need only have one or the other characteristic to be called a connection-oriented protocol.

Many people confuse error detection with error recovery. Any header or trailer with a Frame

Check Sequence (FCS) or similar field can be used to detect bit errors in the PDU (that is error

detection that results in discarding the PDU). However, error recovery implies that the protocol



04.35700737 CH03 Page 88 Wednesday, February 17, 1999 2:45 PM



88



Chapter 3: Understanding the OSI Reference Model



reacts to the lost data and somehow causes the data to be retransmitted. An example of error

recovery is shown later in this section.



NOTE



Some documentation refers to the terms connected or connection-oriented. These terms are

used synonymously. You will most likely see the use of the term connection-oriented in Cisco

documentation.



In the context of the Cisco official courses, connection-oriented protocols are typically

discussed in the same context as reliable protocols or error recovery protocols. The following

litany describes the attitude of the course books on error recovery, which of course is a good

perspective to remember for the exam.

The following list describes the general process used for error recovery. The list is followed by

an example.

1. Protocols providing error recovery are by definition connection oriented and use some



initialization flows to create an agreement for a connection.

2. The protocol implementing the connection defines headers; for example, TCP provides



error recovery and defines a TCP header. The headers used by that protocol have some

numbering and acknowledgment fields to both acknowledge data and notice when it has

been lost in transmission. The endpoints that are sending and receiving data use the fields

in this header to identify that data was sent and signify that data was received.

3. A sender of data will want an acknowledgment of the data. When an error occurs, many



error recovery algorithms require the sender of data to send all data, starting with the

lost data. To limit the negative effect of having to resend lots of data, a window of

unacknowledged data, which can be dynamic in size, is defined. This window defines

the maximum amount of data that can be sent without getting an acknowledgment.

The translation of the preceding litany is that reliable error recovering protocols are connection

oriented; however, not all connection-oriented protocols are error recovering. For example,

TCP is connection oriented, and provides error recovery. Frame Relay is connection oriented

because of the pre-established virtual circuit, but it does no error recovery.



How Error Recovery Is Accomplished

Regardless of which protocol specification performs the error recovery, they all work in

basically the same way. Generically, the transmitted data is labeled or numbered. After receipt,

the receiver will signal back to the sender that the data was received, using the same label or

number to identify the data. Figure 3-7 summarizes the operation.



04.35700737 CH03 Page 89 Wednesday, February 17, 1999 2:45 PM



Connection-Oriented Protocols, Connectionless Protocols, and Flow Control



89



Figure 3-7 Forward Acknowledgment

Fred



Barney



10,000

Bytes

of Data



Network



S=1



S=2



S=3

R=4



A260306



Got 1st 3,

give me

#4 next.



As Figure 3-7 illustrates, the data is numbered, as shown with the numbers 1, 2, and 3. These

numbers are placed into the header used by that particular protocol; for example, the TCP

header contains such numbering fields. When Barney sends his next frame to Fred, Barney

acknowledges that all three frames were received by setting his acknowledgment field to 4. The

number 4 refers to the next data to be received, which is called forward acknowledgment. This

means that the acknowledgment number in the header states the next data that is to be received,

not the last one received. (In this case, 4 is next to be received.)

In some protocols, such as LLC2, the numbering always starts with zero. In other protocols,

such as TCP, the number is stated during initialization by the sending machine. Some protocols

count the frame/packet/segment as “1”; others count the number of bytes sent. In any case, the

basic idea is the same.

Of course, error recovery has not been covered yet. Take the case of Fred and Barney again, but

notice Barney’s reply in Figure 3-8.