This chapter covers the following topics that you will need to master as a CCNA:

•

This section describes

the history of OSI and its relevance to networking in the new millennium. In addition,

this section covers the meaning and usefulness of each layer, the interactions of the

layers, and the encapsulation of data.

•

Routers and switches are mainly concerned with

protocols similar to the OSI network and data link layers, and sometimes with the

transport layer. This section covers the pertinent details of the transport layer,

including connectionless and connection-oriented operation, error recovery, flow

control, buffering, and windowing.

•

Routers, switches, and bridges use data link layer

concepts, both on LAN and WAN connections. This section discusses the data link

functions of arbitration, addressing, error detection, and encapsulation.

•

The network layer defines the core concepts used

by routers. This section discusses network layer addressing and routing in depth.

In years past, the need to understand the Open Systems Interconnection (OSI) reference

model for networking grew rapidly. The U.S. government passed laws requiring vendors to

support OSI software on their systems, or the government would no longer buy the systems.

Several vendors even predicted that the global Internet would evolve toward using the OSI

protocols instead of TCP/IP. As the century turns, however, OSI has been implemented

on a much smaller scale than predicted. Few vendors push their OSI software solutions,

if they even have them. However, several components of the OSI model are popularly

implemented today. For example, OSI network service access point (NSAP) network layer

addresses are often used for signaling in Asynchronous Transfer Mode (ATM) networks.

However, full seven-layer OSI implementations are relatively rare today.

So, why have a whole chapter on OSI? As a CCNA, you’ll be expected to learn and interpret

new technologies and protocols. The OSI seven-layer reference model is an excellent point

of reference for describing the concepts and functions behind these new technologies.

References to Layer 2 switching and Layer 3 switching, which are popular topics today,

refer to the comparison between Layers 2 and 3 of the OSI model. Cisco courses make

generous use of the OSI model as reference for comparison with other network protocol

implementations. So, this chapter will not actually help you understand OSI fully, but rather

it will discuss OSI functions in comparison with popularly implemented protocols.

By taking the following steps, you can make better use of your study time:

•

Keep your notes and the answers for all your work with this book in one place, for

easy reference.

•

Take the “Do I Know This Already?” quiz, and write down your answers. Studies

show that retention is significantly increased through writing down facts and

concepts, even if you never look at the information again.

•

Use the diagram in Figure 3-1 to guide you to the next step.

Chapter 3: OSI Reference Model & Layered Communication

The purpose of the “Do I Know This Already?” quiz is to help you decide what parts of this

chapter to use. If you already intend to read the entire chapter, you do not necessarily need to

answer these questions now.

This 12-question quiz helps you determine how to spend your limited study time. The quiz is

sectioned into four smaller four-question “quizlets,” which correspond to the four major

headings in the “Foundation Topics” section of the chapter. Figure 3-1 outlines suggestions on

how to spend your time in this chapter. Use Table 3-1 to record your score.

1 The OSI, TCP/IP, and NetWare Protocol

Architectures

1 to 4

2 OSI Transport Layer Functions 5 to 8

3 OSI Data Link Layer Functions 9 to 12

4 OSI Network Layer Functions 13 to 16

All questions 1 to 16

“Do I Know This Already?” Quiz

Name the seven layers of the OSI model.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What is the main purpose(s) of Layer 3?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What is the main purpose(s) of Layer 2?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What OSI layer typically encapsulates using both a header and a trailer?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Describe the features required for a protocol to be considered connectionless.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Describe the features required for a protocol to be considered connection-oriented.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Chapter 3: OSI Reference Model & Layered Communication

In a particular error-recovering (reliable) protocol, the sender sends three frames,

labeled 2, 3, and 4. On its next sent frame, the receiver of these frames sets an

acknowledgment field to 4. What does this typically imply?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Name three connection-oriented protocols.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Name three terms popularly used as synonyms for MAC address.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

What portion of a MAC address encodes an identifier representing the manufacturer

of the card?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Are DLCI addresses defined by a Layer 2 or a Layer 3 protocol?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

How many bits are present in a MAC address?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

“Do I Know This Already?” Quiz

How many bits are present in an IPX address?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Name the two main parts of an IP address. Which part identifies the “group” of which

this address is a member?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Describe the differences between a routed protocol and a routing protocol.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Name at least three routed protocols.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

The answers to the “Do I Know This Already?” quiz are found in Appendix A, “Answers to the

‘Do I Know This Already?’ Quizzes and Q&A Sections,” on page 708. The suggested choices

for your next step are as follows:

•

—Read the entire chapter. This includes the “Foundation Topics”

and “Foundation Summary” sections, the Q&A section, and the scenarios at the end of the

chapter.

•

—Review the subsection(s) of the “Foundation Topics” part of

this chapter, based on Table 3-1. Then, move into the “Foundation Summary” section, the

quiz, and the scenarios at the end of the chapter.

•

—Begin with the “Foundation Summary” section, and then go to the

Q&A section and the scenarios at the end of the chapter.

•

—If you want more review on these topics, skip to the

“Foundation Summary” section and then go to the Q&A section and the scenarios at the

end of the chapter. Otherwise, move to the next chapter.

Chapter 3: OSI Reference Model & Layered Communication

Four topics of particular importance for the CCNA exam are covered in this chapter:

•

—Expect questions on the functions of each layer and examples at each

layer in the CCNA exam.

•

—This section is important to properly understand LAN switching.

•

—This section is important to properly understand routing.

•

—This section is important to properly understand end-to-end

transport.

The last three sections all use the terminology discussed in the first section.

To pass the CCNA exam, you must be conversant in a protocol specification with which you are

very unlikely to have any hands-on experience. The difficulty these days when using the OSI

protocol specifications as a point of reference is that almost no one uses those specifications.

You cannot typically walk down the hall and see a computer whose main, or even optional,

networking protocols are defined by OSI.

OSI is the Open Systems Interconnection reference model for communications. OSI is a rather

well-defined set of protocol specifications with many options for accomplishing similar tasks.

Some participants in OSI’s creation and development wanted it to become

networking

protocol used by all applications. The U.S. government went so far as to require OSI support

on every computer it would buy (as of a certain date in the early 1990s) via an edict called the

Government OSI Profile (GOSIP), which certainly gave vendors some incentive to write OSI

code. In fact, in my old IBM days, the company even had charts showing how the TCP/IP

installed base would start declining by 1994, how OSI installations would take off, and how OSI

would be

protocol from which the twenty-first century Internet was built. (In IBM’s defense,

moving the world to OSI may have been yet another case of “You just can’t get there from

here.”)

What is OSI today? Well, the protocols are still in existence and are used around the world, to

some degree. The U.S. government reversed its GOSIP directive officially in May 1994, which

was probably the final blow to the possibility of pervasive OSI implementations. Cisco routers

will route OSI. OSI NSAP addresses are used in Cisco ATM devices for signaling. Digital

Equipment’s DECnet Phase V uses several portions of OSI, including the network layer (Layer

3) addressing and routing concepts. More often than not, however, the OSI model now is mainly

used as a point of reference for discussing other protocol specifications.

The OSI, TCP/IP, and NetWare Protocol Architectures

The OSI model consists of seven layers, each of which can (and typically does) have several

sublayers. Cisco requires that CCNAs demonstrate an understanding of each layer as well as

the protocols that correspond to each OSI layer. The names of the OSI model layers and their

main functions are simply good things to memorize. And frankly, if you want to pursue your

Cisco certifications beyond CCNA, these names and functional areas will come up continually.

The upper layers of the OSI model (application, presentation, and session—Layers 7, 6, and 5)

are oriented more toward services to the applications. The lower four layers (transport, network,

data link, and physical—Layers 4, 3, 2, and 1) are oriented more toward the flows of data from

end to end through the network. CCNAs work mostly with issues in the lower layers, in

particular with Layer 2, upon which switching is based, and Layer 3, upon which routing is

based. Table 3-2 diagrams the seven OSI layers, with a thorough description and a list of

example protocols.

Application

(Layer 7)

An application that communicates with other computers

is implementing OSI application layer concepts. The

application layer refers to communications services to

applications. For example, a word processor that lacks

communications capabilities would not implement code

for communications, and word processor programmers

would not be concerned about OSI Layer 7. However, if

an option for transferring a file were added, then the word

processor would need to implement OSI Layer 7 (or the

equivalent layer in another protocol specification).

Telnet, HTTP, FTP,

WWW browsers, NFS,

SMTP gateways

(Eudora, CC:mail),

SNMP, X.400 mail,

FTAM

Presentation

(Layer 6)

This layer’s main purpose is defining data formats, such

as ASCII text, EBCDIC text, binary, BCD, and JPEG.

Encryption is also defined by OSI as a presentation layer

service. For example, FTP enables you to choose binary

or ASCII transfer. If binary is selected, the sender and

receiver do not modify the contents of the file. If ASCII is

chosen, the sender translates the text from the sender’s

character set to a standard ASCII and sends the data. The

receiver translates back from the standard ASCII to the

character set used on the receiving computer.

JPEG, ASCII, EBCDIC,

TIFF, GIF, PICT,

encryption, MPEG,

MIDI

Chapter 3: OSI Reference Model & Layered Communication

Session

(Layer 5)

The session layer defines how to start, control, and end

conversations (called sessions). This includes the control

and management of multiple bidirectional messages so

that the application can be notified if only some of a

series of messages are completed. This allows the

presentation layer to have a seamless view of an

incoming stream of data. The presentation layer can be

presented with data if all flows occur in some cases. For

example, an automated teller machine transaction in

which you withdraw cash from your checking account

should not debit your account, and then fail, before

handing you the cash, recording the transaction even

though you did not receive money. The session layer

creates ways to imply which flows are part of the same

session and which flows must complete before any are

considered complete.

RPC, SQL, NFS,

NetBios names,

AppleTalk ASP, DECnet

SCP

Transport

(Layer 4)

Layer 4 includes the choice of protocols that either do or

do not provide error recovery. Multiplexing of incoming

data for different flows to applications on the same

host (for example, TCP sockets) is also performed.

Reordering of the incoming data stream when packets

arrive out of order is included.

TCP, UDP, SPX

Network

(Layer 3)

This layer defines end-to-end delivery of packets. To

accomplish this, the network layer defines logical

addressing so that any endpoint can be identified. It also

defines how routing works and how routes are learned so

that the packets can be delivered. The network layer also

defines how to fragment a packet into smaller packets to

accommodate media with smaller maximum transmission

unit sizes. (Note: Not all Layer 3 protocols use

fragmentation.) The network layer of OSI defines most of

the details that a Cisco router considers when routing. For

example, IP running in a Cisco router is responsible for

examining the destination IP address of a packet,

comparing that address to the IP routing table,

fragmenting the packet if the outgoing interface requires

smaller packets, and queuing the packet to be sent out to

the interface.

IP, IPX, AppleTalk DDP

The OSI, TCP/IP, and NetWare Protocol Architectures

Some protocols define details of multiple layers. For example, because the TCP/IP application

layer correlates to OSI Layers 5 through 7, the Network File System (NFS) implements

elements matching all three layers. Likewise, the 802.3, 802.5, and Ethernet standards define

details for the data link and physical layers.

CCNAs deal with many aspects of Layers 1 through 4 on a daily basis. However, the upper

layers are not as important to CCNAs. In addition, most networking people know what the OSI

model is but do not need to memorize everything about it. Table 3-2 shows plenty of detail and

explanation for a more in-depth idea of the OSI model components. If you are daunted by the

task of memorizing all the examples in Table 3-2, you can refer to Table 3-3, which offers a

Data link

(Layer 2)

The data link (Layer 2) specifications are concerned with

getting data across one particular link or medium. The

data link protocols define delivery across an individual

link. These protocols are necessarily concerned with the

type of media in question; for example, 802.3 and 802.2

are specifications from the IEEE, which are referenced

by OSI as valid data link (Layer 2) protocols. These

specifications define how Ethernet works. Other

protocols, such as High-Level Data Link Control

(HDLC) for a point-to-point WAN link, deal with the

different details of a WAN link. As with other protocol

specifications, OSI often does not create any original

specification for the data link layer but instead relies on

other standards bodies such as IEEE to create new

standards for the data link layer and the physical layer.

IEEE 802.3/802.2,

HDLC, Frame Relay,

PPP, FDDI, ATM, IEEE

802.5/ 802.2

Physical

(Layer 1)

These physical layer (Layer 1) specifications, which are

also typically standards from other organizations that are

referred to by OSI, deal with the physical characteristics

of the transmission medium. Connectors, pins, use of

pins, electrical currents, encoding, and light modulation

are all part of different physical layer specifications.

Multiple specifications are sometimes used to complete

all details of the physical layer. For example, RJ-45

defines the shape of the connector and the number of

wires or pins in the cable. Ethernet and 802.3 define the

use of wires or pins 1, 2, 3, and 6. So, to use a category 5

cable, with an RJ-45 connector for an Ethernet

connection, Ethernet and RJ-45 physical layer

specifications are used.

EIA/TIA-232, V.35,

EIA/TIA- 449, V.24,

RJ45, Ethernet, 802.3,

802.5, FDDI, NRZI,

NRZ, B8ZS

Chapter 3: OSI Reference Model & Layered Communication

more condensed description of the layer characteristics and examples. This table is taken

directly from Cisco’s ICND course, so if you are just not willing to try and remember all of

Table 3-2, the information in Table 3-3 is a good compromise. (ICND is the instructor-led

course in the official CCNA training path.)

Many benefits can be gained from the process of breaking up the functions or tasks of

networking into smaller chunks, called layers, and defining standard interfaces between these

layers. One obvious benefit is that the individual protocols or layers are less complex and

therefore can be defined in great detail. The following list summarizes the benefits of layered

protocol specifications:

•

Humans can discuss and learn about the many details of a protocol specification easier.

•

Standardized interfaces among layers facilitates modular engineering. Different products

can provide functions of only some layers (such as a router with Layers 1 to 3), or some

products could supply parts of the functions of the protocol (such as Microsoft TCP/IP

built into Win95, or the Eudora e-mail application providing TCP/IP application layer

support).

Application (Layer 7) User interface Telnet, HTTP

Presentation (Layer 6) How data is presented

Special processing, such as encryption

JPEG, ASCII, EBCDIC

Session (Layer 5) Keeping data separate from different

applications

Operating systems and

application access

scheduling

Transport (Layer 4) Reliable or unreliable delivery

Multiplexing

TCP, UDP, SPX

Network (Layer 3) Logical addressing, which routers use for path

determination

IP, IPX

Data link (Layer 2) Combination of bits into bytes, and bytes into

frames

Access to the media using MAC address

Error detection and error recovery

802.3/802.2, HDLC

Physical (Layer 1) Moving of bits between devices

Specification of voltage, wire speed, and cable

pin-outs

EIA/TIA-232, V.35

The OSI, TCP/IP, and NetWare Protocol Architectures

•

A better environment for interoperability is created.

•

Reduced complexity allows easier program changes and faster product evolution.

•

Each layer can define headers and trailers around the user data. Anyone examining these

headers or trailers for troubleshooting can find the header or trailer for Layer

and know

what type of information should be found.

•

One layer uses the services of the layer immediately below it. Therefore, remembering

what each layer does is easier. (For example, the network layer needs to deliver data from

end to end. To do this, it uses data links to forward data to the next successive device along

that end-to-end path.)

CCNAs frequently deal with the concepts of layer interaction and encapsulation, particularly

because routers build new data link headers and trailers to encapsulate the packets they route.

The process of how layers interact on the same computer, as well as how the same layer

processes on different computers communicate with each other, is all interrelated. The software

or hardware products implementing the logic of some of the OSI protocol layers provide two

general functions:

•

Each layer provides a service to the layer above it in the protocol specification.

•

Each layer communicates some information with the same layer’s software or hardware

on other computers. In some cases, the other computer is connected to the same media; in

other cases, the other computer is on the other end of the network.

In the coming pages, you will learn more about each of these two functions.

Interactions Between Adjacent Layers on the Same Computer

To provide services to the next higher layer, a layer must know about the standard interfaces

defined between layers. These interfaces include definitions of what Layer

+1 must provide

to Layer

to get services, as well as what information Layer

must provide back to Layer

+1.

Figure 3-2 presents a graphical representation of two computers and provides an excellent

backdrop for a discussion of interactions between layers on the same computer.

Chapter 3: OSI Reference Model & Layered Communication

the user. Each layer creates a header and passes the data down to the next layer. (The arrows in

Figure 3-2, Step 1, denote the passing of data between layers.) Passing the data down to the next

layer implies that the lower layer needs to perform some services for the higher layer; to

perform these services, the lower layer adds some information in a header or trailer. For

example, the transport layer hands off its data and header; the network layer adds a header with

the correct destination network layer address so that the packet can be delivered to the other

computer.

From each layer’s perspective, the bits after that layer’s header are considered to be data. For

instance, Layer 4 considers the Layer 5, 6, and 7 headers, along with the original user data, to

be one large data field.

After the application creates the data, the software and hardware implementing each layer

perform their work, adding the appropriate header and trailer. The physical layer can use the

media to send a signal for physical transmission, as shown in Step 2 in Figure 3-2.

Upon receipt (Step 3), Host B begins the adjacent layer interactions on Host B. The right side

of Figure 3-2 shows an arrow pointing next to the computer (Step 4), signifying that the

received data is being processed as it goes up the protocol stack. In fact, thinking about what

each layer does in the OSI model can help you decide what information could be in each header.

The following sequence outlines the basics of processing at each layer and shows how each

lower layer provides a service to the next higher layer. Consider the receipt of data by the host

on the right side of Figure 3-2:

places the received binary pattern into a buffer. It notifies the data

link layer that a frame has been received after decoding the

incoming signal into a bit stream. Therefore, Layer 1 has provided

delivery of a stream of bits across the medium.

the trailer to determine whether errors occurred in transmission

(error detection). If an error has occurred, the frame is discarded.

not.) The data link address(es) are examined so that Host B can

decide whether to process the data further. If the data is addressed

to host B, the data between the Layer 2 header and trailer is given

to the Layer 3 software. The data link has delivered the data across

that link.

the address is Host B’s address, processing continues (logical

addressing) and the data after the Layer 3 header is given to the

transport layer (Layer 4) software. Layer 3 has provided the

service of end-to-end delivery.

(Layer 4), the counters identifying this piece of data are encoded

in the Layer 4 header along with acknowledgment information

(error recovery). After error recovery and reordering of the

incoming data, the data is given to the session layer.

of messages is completed. For example, this data could be

meaningless if the next four exchanges are not completed. The

Layer 5 header could include fields signifying that this is a middle

flow in a chain, not an ending flow. After the session layer ensures

that all flows are completed, it passes the data after the Layer 5

header to the Layer 6 software.

formats. For example, if the data is binary instead of character

data, the header denotes that fact. The receiver does not attempt to

convert the data using the default ASCII character set of Host B.

Typically, this type of header is included only for initialization

flows, not with every message being transmitted (data formats).

After the data formats have been converted, the data (after the

Layer 6 header) is then passed to the application layer (Layer 7)

software.

can examine the true end-user data. This header signifies

agreement to operating parameters by the applications on Host A

and Host B. The headers are used to signal the values for all

parameters; therefore, the header typically is sent and received at

application initialization time only. For example, for file transfer,

the size of the file to be transferred and the file formats used would

be communicated (application parameters).

Interactions Between the Same Layers on Different Computers

functions. For example, the transport layer (Layer 4) can send data, but if another computer

does not acknowledge that the data was received, the sender will not know when to perform

error recovery. Likewise, the sending computer encodes a destination network layer address

(Layer 3) 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

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

Figure 3-3 provides a conceptual perspective on the 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; 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.

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

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 header and data are placed between the Layer 2 header and the Layer 2

trailer. The physical layer does not use encapsulation because it does not use headers or trailers.

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:

creates the application header and places the data behind it. This

data structure is passed to the presentation layer.

the data behind it. This data structure is passed to the session layer.

behind it. This data structure is passed to the transport layer.

behind it. This data structure is passed to the network layer.

behind it. This data structure is passed to the data link layer.

behind it. The data link trailer is added to the end of the structure.

This data structure is passed to the physical layer.

the frame.

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

However, encapsulation by each layer does not happen (typically) for each transmission of data

by the application. Normally, Layers 5 through 7 use headers during initialization (and on

occasion after initialization), but in most flows, there is no Layer 5, 6, or 7 header. This is

because there is no new information to exchange for every flow of data.

An analogy can help in this case. A friend of mine from church spent several summers teaching

English in a communist country. When I wrote to her, she assumed that I would write in English,

but I could not write about “church” without the sensors tossing the letter. So, we agreed on

encryption before she left. Under our code, God was called “Phil,” and I could write things such

as, “I saw Fred at Phil’s house yesterday, and he said hi.” I still had to address the letters before

I mailed them, just like the lower OSI layers need to exchange some information for every piece

of data sent. I didn’t need to repeat what “Phil” really meant in each letter, just like the upper

layers do not need to repeat encryption rules.

Previous CCNA exams referred to a five-step process for encapsulation. This included the

typical encapsulation by the transport, network, and data link layers as steps 2 through 4 in the

process. The first step was the application’s creation of the data, and the last step was the

physical layer’s transmission of the bit stream. In case any questions remain in the CCNA

question database referring to a five-step encapsulation process, the following list provides the

details and explanation.

bits that include the headers and trailers for that layer, as well as the encapsulated data. For

instance, an IP packet is an L3PDU, which includes the IP header and any encapsulated data.

to send.

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

The L4PDU is created here.

network layer creates the network header, which includes the

network layer address, and places the data (L4PDU) behind it. In

other words, the L3PDU is created here.

link layer creates the data link header, places the data (L3PDU)

behind it, and places the data link trailer at the end. In other words,

the L2PDU is created here.

medium to transmit the frame.

This five-step process happens to match the TCP/IP network model very well. Figure 3-4

depicts the concept; the numbers shown represent each of the five steps.

Two of the most pervasively deployed protocols are TCP/IP and Novell NetWare; these also are

the two key protocol architectures covered on the CCNA exam. TCP/IP and NetWare are

covered in much more detail in the upcoming chapters.

This short section compares TCP/IP, Novell, and OSI. The goal is to provide some insight into

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

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

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

a Layer 3 protocol because its functions most closely match OSI’s Layer 3. Both IP and IPX

define logical addressing, routing, the learning of routing information, and end-to-end delivery

rules.

As with OSI Layers 1 and 2 (physical and data link, respectively), the lower layers of each stack

simply refer to other well-known specifications. For example, the lower layers all support the

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

for ISDN, and the Frame Relay protocols specified by the Frame Relay Forum, ANSI, and the

ITU. The protocol stacks can accommodate other evolving Layer 1 and Layer 2 specifications

more easily by referring to emerging international standards rather than trying to evolve these

standards themselves.

The transport layer (Layer 4) defines several functions. Two important features covered in this

chapter are error recovery and flow control. Routers discard packets for many reasons,

including bit errors, congestion that has caused a lack of buffer space, and instances in which

no correct routes are known. The transport layer can provide for retransmission (error recovery)

and can help avoid congestion (flow control).

Transport layer protocols are typically categorized as either connectionless or connectionoriented,

so CCNAs deal with the concepts of connectionless and connection-oriented

protocols on a regular basis. This next section compares the two and provides some explanation

for the functions of each. Error recovery and flow control are covered in the section “How Error

Recovery Is Accomplished.”

connotations inside the world of networking protocols. However, the typical connotation can be

a bit misleading. For instance, most people correlate connection-oriented protocols with

reliable or error-recovering protocols because the two features are often implemented by a

single protocol. However, connection-oriented protocols do not have to provide error recovery,

and error-recovering protocols do not have to be connection-oriented.

First, some basic definitions are in order:

Connection-oriented protocol: A protocol that either requires an exchange of messages

before data transfer begins or has a required pre-established correlation between two

endpoints.

Connectionless protocol: A protocol that does not require an exchange of messages and

that does not require a pre-established correlation between two endpoints.

The definitions are sufficiently general so that all cases can be covered. TCP is connectionoriented

because a set of three messages must be completed before data is exchanged. Likewise,

SPX is connection-oriented. Frame Relay, when using PVCs, does not require any messages be

sent ahead of time, but it does require predefinition in the Frame Relay switches, establishing a

connection between two Frame Relay attached devices. ATM PVCs are also connectionoriented,

for similar reasons.

As mentioned earlier, connection-oriented protocols are often assumed to also perform error

recovery. However, Frame Relay and ATM are two examples in which the protocols are

connection-oriented but the protocol does not provide error recovery. Table 3-4 provides some

example protocols and tells whether they are connection-oriented and error-recovering.

The most typical option is for a protocol to be connectionless and not perform error recovery,

or to be connection-oriented and to also perform error recovery. In fact, many connectionoriented

protocols exchange information important to error recovery when the connection is

established.

header or trailer with a frame check sequence (FCS) or similar field can be used to detect bit

errors in the PDU. Error detection uses the FCS to detect the error, which results in discarding

the PDU. However, error recovery implies that the protocol reacts to the lost data and somehow

causes the data to be retransmitted. An example of error recovery is shown later in this section.

documentation.

In the context of previous Cisco official courses, reliable, error-recovering protocols were

always defined as also being connection-oriented. In the current ICND course, part of the

official Cisco CCNA training path, those references have been removed. If you are studying

using an older ICRC or CRLS course book, pay particular attention to the comparisons made

about connection orientation and error recovery in this book.

Connection-oriented Yes LLC type 2 (802.2), TCP (TCP/IP), SPX

(NetWare), X.25

Connection-oriented No Frame Relay virtual circuits, ATM virtual

connections, PPP

Connectionless Yes TFTP, NetWare NCP (without Packet Burst)

Connectionless No UDP, IP, IPX, AppleTalk DDP, most Layer 3

protocols, 802.3, 802.5

The following litany describes the attitude of the current Cisco course books on error recovery:

to number and acknowledge the data. 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 to signify that data was received.

error-recovery algorithms require the sender 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.

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

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

signals 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.

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 similar 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

means that the acknowledgment number in the header identifies 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. Also, 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.

Because Barney is expecting packet number 2 next, what could Fred do? Two choices exist.

Fred could send numbers 2 and 3 again, or Fred could send number 2 and wait, hoping that

Barney’s next acknowledgment will say 4, indicating that Barney just got number 2 and already

had number 3 from earlier.

Finally, error recovery typically uses two sets of counters: one to count data in one direction,

and one to count data in the opposite direction. So, when Barney acknowledges packet number

field that identifies the data in Barney’s packet. For instance, assume in Figure 3-8 that the

previous packet Barney had sent was number 5. The packet shown in the figure would be

labeled 6.

Table 3-5 summarizes the concepts behind error recovery and lists the behavior of three popular

error-recovery protocols.

Flow control is the process of controlling the rate at which a computer sends data. Depending

on the particular protocol, both the sender and the receiver of the data (as well as any

intermediate routers, bridges, or switches) might participate in the process of controlling the

flow from sender to receiver.

Flow control is needed because data is discarded when congestion occurs. A sender of data

might be sending the data faster than the receiver can receive the data, so the receiver discards

the data. Also, the sender might be sending the data faster than the intermediate switching

devices (switches and routers) can forward the data, also causing discards. Packets can be lost

due to transmission errors as well. This happens in every network, sometimes temporarily and

sometimes regularly, depending on the network and the traffic patterns. The receiving computer

can have insufficient buffer space to receive the next incoming frame, or possibly the CPU is

too busy to process the incoming frame. Intermediate routers might need to discard the packets

based on temporary lack of buffers or processing as well.

Flow control attempts to reduce unnecessary discarding of data. Comparing flows when flow

control is used, and when it is not used, is helpful for understanding why flow control can be

useful. Without flow control, some PDUs are discarded. If some reliable protocol in use

happens to implement error recovery, then the data is re-sent. The sender keeps sending as fast

as possible. With flow control, the sender can be slowed down enough that the original PDU

can be forwarded to the receiving computer, and the receiving computer can process the PDU.

Flow-control protocols do not prevent the loss of data due to congestion; these protocols simply

reduce the amount of lost data, which in turn reduces the amount of retransmitted traffic, which

hopefully reduces overall congestion. However, with flow control, the sender is artificially

slowed or throttled so that it sends data less quickly than it could without flow control.

The CCNA exam requires that you be familiar with three features, or methods, of implementing

flow control:

Acknowledges data in both directions? Yes Yes Yes

Uses forward acknowledgment? Yes Yes Yes

Counts bytes or frame/packets? Bytes Packets Frames

Necessitates resending of all data, or

just one part and wait when resending?

One and wait Resend all Resend all

Buffering

data can be held until processed. No attempt is made to actually slow the transmission rate of

the sender of the data. In fact, buffering is such a common method of dealing with changes in

the rate of arrival of data that most of us would probably just assume that it is happening.

However, some older documentation refers to “three methods of flow control,” of which

buffering is one of the methods, so be sure to remember it as a separate function.

Congestion Avoidance

receiving the data notices that its buffers are filling. This causes either a separate PDU, or field

in a header, to be sent toward the sender, signaling the sender to stop transmitting. Figure 3-9

shows an example.

“Hurry up and wait” is a popular expression used to describe the process used in this congestion

avoidance example. This process is used by Synchronous Data Link Control (SDLC) and Link

Access Procedure, Balanced (LAPB) serial data link protocols.

A preferred method might be to get the sender to simply slow down instead of stopping

altogether. This method would still be considered congestion avoidance, but instead of

signaling the sender to stop, the signal would mean to slow down. One example is the TCP/IP

Internet Control Message Protocol (ICMP) message “Source Quench.” This message is sent by

the receiver or some intermediate router to slow the sender. The sender can slow down gradually

until “Source Quench” messages are no longer received.

Windowing

amount of data the sender can send without getting an acknowledgment. If no acknowledgment

is received by the time the window is filled, then the sender must wait for acknowledgment.

Figure 3-10 shows an example. The slanted lines indicate the time difference between sending

a PDU and its receipt.

In this example, the sender has a window of three frames. After the receiver acknowledges the

receipt of frame 1, frame 4 can be sent. After a time lapse, the acknowledgment for frames 2

and 3 are received, which is signified by the frame sent by the receiver with the acknowledgment

field equal to 4. So, the sender is free to send two more frames—frames 5 and 6—

before another acknowledgment is received.

Flow Control Summary

One of Cisco’s goals for CCNA and its other certifications is to ensure that passing means that

you really understand the technology rather than simply understanding how to pass a particular

exam. Focusing on understanding the concepts, as always, gives you a chance to get the exam

questions correct. Table 3-6 summarizes the flow control terms and provides examples of each

type. Memorizing these terms should help trigger your memory of flow-control concepts.

As a CCNA, you’ll need to understand both the abstract concepts about the OSI layers and

particular instances of such protocols. This section focuses on more of the abstract concepts.

Chapter 4, “Bridges/Switches and LAN Design,” and Chapter 8, “WAN Protocols and

Design,” provide more details about particular data link protocols, as well as their configuration

in the IOS.

This section examines four different protocols: Ethernet, Token Ring, HDLC, and Frame Relay.

A generalized definition of the function of a data link protocol will be used to guide you through

the comparison of these four data link protocols. This definition could be used to examine any

other data link protocol. The four components of this definition of the functions of data link

(Layer 2) protocols are as follows:

is sent.

successfully.

link header. This feature is included in a subset of data link protocols.

Ethernet and Token Ring are two popular LAN Layer 2 protocols. These protocols are defined

by the IEEE in specifications 802.3 and 802.5, respectively. Because 802.3 and 802.5 define

how a station accesses the media, the IEEE calls these protocols Media Access Control (MAC)

protocols. Also, both 802.3 and 802.5 call for the use of another IEEE specification as a separate

part of the data link layer, namely 802.2 Logical Link Control (LLC). 802.2 is purposefully

designed to provide functions common to both Ethernet and Token Ring, whereas 802.3 and

802.5 were designed specifically for data link functions pertinent to either Ethernet or Token

Ring topologies, respectively.

a while (the letters DIX represent Digital, Intel, and Xerox). DIX Version 2 defines similar

functions to both the 802.3 and 802.2 specifications.

Buffering N/A N/A

Congestion Avoidance Stop/Start, RNR, Source Quench SDLC, LAPB, LLC2

Windowing N/A TCP, SPX, LLC2

HDLC is the default data link protocol (encapsulation) on Cisco routers serial interfaces. Frame

Relay headers are coincidentally based on the HDLC specification, but Frame Relay was

created for multiaccess networks (with more than two devices). The clear differences between

Frame Relay and HDLC provide a good backdrop to examine the functions of the data link

layer (Layer 2).

Arbitration is needed only when there are instants in time during which it is not appropriate to

send data across the media. LANs were originally defined as a shared media on which each

device must wait until the appropriate time to send data. The specifications for these data link

protocols define how to arbitrate the use of the physical medium.

Ethernet uses the carrier sense multiple access collision detect (CSMA/CD) algorithm for

arbitration. The basic algorithm for using an Ethernet when there is data to be sent consists of

the following steps:

With Token Ring, a totally different mechanism is used. A free-token frame rotates around the

ring while no device has data to send. When sending, a device claims the free token, which

really means changing bits in the 802.5 header to signify “token busy.” The data is then placed

onto the ring after the Token Ring header. The basic algorithm for using a Token Ring when

there is data to be sent consists of the following steps:

data, and send the data onto the ring.

frame, after completing a full revolution around the ring, the

sender removes the data from the ring.

frame.

The algorithm for Token Ring does have other rules and variations, but these are beyond the

depth of what is needed for the CCNA exam. Network Associates (the “Sniffer” people) have

an excellent class covering Token Ring in detail. To find out more about these classes, go to

www.nai.com.

With HDLC, arbitration is a nonissue today. HDLC is used on point-to-point links, which are

typically full-duplex (four-wire) circuits. In other words, either endpoint can send at any time.

From a physical perspective, Frame Relay is comprised of a leased line between a router and

the Frame Relay switch. These links are also typically full-duplex links, so no arbitration is

needed. The Frame Relay network is shared among many data terminal equipment (DTE)

devices, whereas the access link is not shared, so arbitration of the medium is not an issue.

of the bits being examined and discussed. Figure 3-11 shows frames for the four data link

protocols.

Cisco requires that CCNAs master the formats and meanings of data link and network layer

addresses. Addressing is needed on LANs because there can be many possible recipients of

must ask the question, “Is this frame meant for me?”

With Ethernet and Token Ring, the addresses are very similar. Each uses Media Access Control

(MAC) addresses, which are 6 bytes long and are represented as a 12-digit hexadecimal

number. Table 3-7 summarizes most of the details about MAC addresses.

MAC Media Access Control. 802.3 (Ethernet) and 802.5 (Token

Ring) are the MAC sublayers of these two LAN data link

protocols.

HDLC includes a meaningless address field because it is used only on point-to-point serial

links. The recipient is implied; if one device sent a frame, the other device is the only possible

intended recipient.

defines a data-link connection identifier (DLCI), which identifies each VC. For example, in

Figure 3-12, the Frame Relay switch to which router Timbuktu is connected receives frames;

the switch forwards the frame to either Kalamazoo or East Egypt based on the DLCI, which

identifies each VC. So, Timbuktu has one physical connection but multiple logical connections.

Ethernet address, NIC address, LAN

address, Token Ring address, card

address

Other names often used instead of MAC address. These

terms describe the 6-byte address of the LAN interface card.

Burned-in address The 6-byte address assigned by the vendor making the card.

It is usually burned in to a ROM or EEPROM on the LAN

card and begins with a 3-byte Organizationally Unique

Identifier (OUI) assigned by the IEEE.

Locally administered address Via configuration, an address that is used instead of the

burned-in address.

Unicast address Fancy term for a MAC that represents a single LAN

interface.

Broadcast address An address that means “all devices that reside on this LAN

right now.”

Multicast address Not valid on Token Ring. On Ethernet, a multicast address

implies some subset of all devices currently on the LAN.

Functional address Not valid on Ethernet. On Token Ring, these addresses are

reserved to represent the device(s) on the ring performing a

particular function. For example, all source-route bridges

supply the ring number to other devices; to do so, they each

listen for the Ring Parameter Server (RPS) functional

address.

Error detection is simply the process of learning whether bit errors occurred during the

the result of a mathematical formula applied to the data in the frame. The FCS value calculated

and sent by the sender should match the value calculated by the receiver. All four data links

discussed in this section contain an FCS field in the frame trailer.

Error detection does not imply recovery; most data links, including 802.5 Token Ring and 802.3

Ethernet, do not provide error recovery. In these two cases, however, an option in the 802.2

protocol, called LLC type 2, does perform error recovery. (SNA and NetBIOS are the typical

higher-layer protocols in use that request the services of LLC2.)

Finally, the fourth part of a data link identifies the contents of the data field in the frame. Figure

3-13 helps make the usefulness of this feature apparent.

When PC1 receives data, does it give the data to the TCP/IP software or the NetWare client

software? Of course, that depends on what is inside the data field. If the data came from the

Novell server, then PC1 hands the data off to the NetWare client code. If the data comes from

the Sun FTP server, PC1 hands it off to the TCP/IP code.

Ethernet and Token Ring 802.2 LLC provide a field in its header to identify the type of data in

the data field.

PC1 receives frames that basically look like the two shown in Figure 3-14. Each data link

header has a field with a code that means IP, or IPX, or some other designation defining the type

of protocol header that follows. The first item to examine in the header is the 802.2 DSAP field.

In the first frame in Figure 3-14, the destination service access point (DSAP) field has a value

of E0, which means that the next header is a Novell IPX header. In the second frame, the DSAP

field is AA, which implies that a SNAP header follows. Next, the type field in the Subnetwork

Access Protocol (SNAP) header, which has a value of 0800, signifies that the next header is an

IP header. RFC 1700, the “Assigned Numbers” RFC (http://www.isi.edu/in-notes/rfc1700.txt),

lists the SAP and SNAP Type field values and the protocol types they imply.

Similarly, HDLC and Frame Relay need to identify the contents of the data field. Of course, it

is atypical to have end-user devices attached to either of these types of data links. In this case,

routers provide an example more typically found in most WAN environments, as shown in

Figure 3-15.

Referring to the top part of Figure 3-15, if Barney is using FTP to transfer files to the Sun system

and is also connected to the NetWare server (Fred) using IPX, then Barney will generate both

TCP/IP and NetWare IPX traffic. As this traffic passes over the HDLC controlled link, R2 will

need to know whether an IP or IPX packet follows the HDLC header. Mainly, this is so that the

router can find the Layer 3 destination address, assume its length (32 bits or 80 bits), perform

table lookup in the correct routing table (ID or IPX), and make the correct routing decision.

HDLC does not provide a mechanism to identify the type of packet in the data field. IOS adds

a proprietary 2-byte field immediately after the HDLC header that identifies the contents of the

data. As shown in the bottom of Figure 3-15, the intervening Frame Relay switches do not care

what is inside the data field. The receiving router, R2, does care for the same reasons that R2

cares when using HDLC—that is, the receiving router needs to know whether an IP or IPX

packet follows the Frame Relay header. Frame Relay headers originally did not address this

issue, either, because the headers were based on HDLC. However, the IETF created a

specification called RFC 1490 that defined additional headers that followed the standard Frame

Relay header. These headers include several fields that can be used to identify the data so that

the receiving device knows what type is hidden inside.

The ITU and ANSI picked up the specifications of RFC 1490 and added it to their official Frame

Relay standards: ITU T1.617 Annex F and ANSI Q.933 Annex E, respectively.

Figure 3-16 shows the fields that identify the type of protocol found in the data field.

As seen in Figure 3-16, a protocol type field comes after the HDLC control field. In the Frame

Relay example, four different options exist for identifying the type of data inside the frame.

RFC 2427, which obsoletes RFC 1490, provides a complete reference and is useful reading for

those of you moving on to CCNP certification (www.isi.edu/in-notes/rfc2427.txt). (“Obsoletes”

in the RFC world implies that a newer document has superceded it but does not necessarily

mean that all or most of the original RFC has been changed.)

Table 3-8 summarizes the different choices for encoding protocol types for each of the four

data link protocols. Notice that the length of some of these fields is only 1 byte, which

historically has led to the addition of other headers. For example, the SNAP header contains a

2-byte type field because a 1-byte DSAP field is not big enough to number all the available

options for what type of protocol is inside the data.

Table 3-9 summarizes the basic functions of data link protocols:

802.3 Ethernet and

802.5 Token Ring

DSAP 802.2 header 1 byte

802.3 Ethernet and

802.5 Token Ring

SSAP 802.2 header 1 byte

802.3 Ethernet and

802.5 Token Ring

Protocol Type SNAP header 2 bytes

Ethernet (DIX) Ethertype Ethernet header 2 bytes

HDLC Cisco proprietary

protocol id field

Extra Cisco header 2 bytes

Frame Relay RFC 2427 NLPID RFC 1490 1 byte

Frame Relay RFC 2427 L2 or L3 Protocol ID Q.933 2 bytes each

Frame Relay RFC 2427 SNAP Protocol Type SNAP Header 2 bytes

Arbitration CSMA/CD

Algorithm (part of

MAC)

Token passing

(part of MAC)

— —

Addressing Source and

destination MAC

addresses

Source and

destination MAC

addresses

Single 1-byte

address;

unimportant on

point-to-point links

DLCI used to

identify virtual

circuits

Error Detection FCS in trailer FCS in trailer FCS in trailer FCS in trailer

Identifying

contents of

data

802.2 DSAP, SNAP

header, or

Ethertype, as

needed

802.2 DSAP or

SNAP header, as

needed

Proprietary Type

field

RFC 1490/2427

headers, with

NLPID, L2 and

L3 protocol IDs,

or SNAP header

These two functions are intertwined and are best understood by considering both at the same

time.

Network layer (Layer 3) addressing will be covered in enough depth to describe IP, IPX, and

AppleTalk addresses. Also, now that data link and network layer addresses have been covered

in this chapter, this section undertakes a comparison of the two as well.

Routing can be thought of as a three-step process, as seen in Figure 3-17. Thinking about

routing in these three separate steps helps make some of the details more obvious. However,

most people will not think of routing as a three-step process when going about their normal

jobs—this is just a tool to make a few points more clearly.

Step 1: Sending Data to a Nearby Router

The creator of the data, who is also the sender of the data, decides to send data to a device in

another group. A mechanism must be in place so that the sender knows of some router on a

a data link frame across the medium to the nearby router; this frame includes the packet in the

data portion of the frame. That frame uses data link (Layer 2) addressing in the data link header

to ensure that the nearby router receives the frame.

Step 2: Routing Data Across the Network

The routing table for that particular network layer protocol type is nothing more than a list of

network layer address groupings. As shown in Table 3-10 later in this section, these groupings

vary based on the network layer protocol type. The router compares the destination network

layer address in the packet to the entries in the routing table in memory, and a match is made.

This matching entry in the routing table tells this router where to forward the packet next.

Any intervening routers repeat the same process. The destination network layer (Layer 3)

address in the packet identifies the group in which the destination resides. The routing table is

searched for a matching entry, which tells this router where to forward the packet next.

Eventually, the packet is delivered to the router connected to the network or subnet of the

destination host, as previously shown in Figure 3-17.

Step 3: Delivering Data to the End Destination

When the packet arrives at a router sharing a data link with the true destination, the router and

the destination of the packet are in the same L3 grouping. That final router can forward the data

directly to the destination. As usual, a new data link header and trailer are created before a frame

(which contains the packet that made the trip across the entire network) can be sent on to the

media. This matches the final step (Step 3), as previously shown in Figure 3-17.

A Comment About Data Links

Because the routers build new data link headers and trailers, and because the new headers

contain data link addresses, the routers must have some way to decide what data link addresses

to use. An example of how the router determines which data link address to use is the IP Address

Resolution Protocol (ARP) protocol. ARP is used to dynamically learn the data link address of

some IP host.

An example specific to TCP/IP will be useful to solidify the concepts behind routing. Imagine

that PC1 is sending packets to PC2. (If you do not understand the basics of IP addressing

already, you may want to bookmark this page and refer to it after you have reviewed Chapter 5,

which covers IP addressing.) Figure 3-18 provides an example network so that you can review

the routing process.

The logic behind the earlier three-step routing process is described in the following steps. Steps

A and B that follow describe the first of the three routing steps in this example. Steps C, D, E,

F, and G correspond to Step 2. Finally, Step H corresponds to routing Step 3.

configured. The default router defined on some host is the router

to which that host forwards packets that are destined for subnets

other than the directly attached subnet. Alternatively, PC1 can

learn of R1’s IP address using Dynamic Host Configuration

Protocol (DHCP). Because DHCP is not mentioned for the CCNA

exam, you can assume that a default router of 10.1.1.100 is

configured on PC1 and that it is R1’s Ethernet IP address.

finish building the Ethernet header (see Figure 3-18). In the case

of TCP/IP, the ARP process is used to dynamically learn R1’s

MAC address. (See Chapter 5 for a discussion of ARP.) When

R1’s MAC address is known, PC1 completes the Ethernet header

with the destination MAC address being R1’s MAC address.

consider. First, the incoming frame (Ethernet interface) is

processed only if the Ethernet FCS is passed and the router’s MAC

address is in the destination address field. Then, the appropriate

packet is in the data portion of the frame. At this point, R1 discards

the Ethernet header and trailer.

table for network 168.1.0.0, the network of which PC2 is a

member. In this case, the route in R1 references 168.1.0.0 and lists

R1’s serial interface as the interface by which to forward the

packet.

place around the IP packet. Because HDLC data link uses the

same address field every time, no process like ARP is needed to

allow R1 to build the HDLC header.

frame. The HDLC FCS is checked; the type field is examined to

learn that the packet inside the frame is an IP packet, and then the

HDLC header and trailer are discarded. The IP routing table in R2

is examined for network 168.1.0.0, and a match is made. The entry

directs R2 to forward the packet to its Frame Relay serial

interface. The routing entry also identifies the next router’s IP

address—namely R3’s IP address on the other end of the Frame

Relay VC.

algorithm, R2 must build a Frame Relay header and trailer. Before

it can complete the task, the correct DLCI for the VC to R3 must

be decided. In most cases today, the dynamic Inverse ARP process

will have associated R3’s IP address with the DLCI R2 uses to

send frames to R3. (See Chapter 8 for more details on Inverse ARP

and Frame Relay mapping.) With that mapping information, R2

can complete the Frame Relay header and send the frame to R3.

R2 before it, R3 checks the FCS in the data link trailer, looks at

the type field to decide whether the packet inside the frame is an

IP packet, and then discards the Frame Relay header and trailer.

The routing table entry for 168.1.0.0 shows that the outgoing

interface is R3’s Token Ring interface. However, there is no next

router IP address because there is no need to forward the packet to

another router. R3 simply needs to build a Token Ring header and

trailer and forward the frame that contains the original packet to

PC2. Before R3 can finish building the Token Ring header, an IP

ARP must be used to find PC2’s MAC address (assuming that R3

doesn’t already have that information in its IP ARP cache).

Cisco requires that CCNAs master the details of Layer 3 addressing, both the concepts and the

particulars of IP and IPX. One key feature of network layer addresses is that they were designed

to allow logical grouping of addresses. In other words, something about the numeric value of

an address implies a group or set of addresses, all of which are considered to be in the same

Network layer addresses are also grouped based on physical location in a network. The rules

differ for some network layer protocols, but the grouping concept is identical for IP, IPX, and

AppleTalk. In each of these network layer protocols, all devices with addresses in the same

group cannot be separated from each other by a router that is configured to route that protocol,

respectively. Stated differently, all devices in the same group (subnet/network/cable range)

must be connected to the same data link; for example, all devices must be connected to the same

Ethernet.

Routing relies on the fact that Layer 3 addresses are grouped together. The routing tables for

each network layer protocol can reference the group, not each individual address. Imagine an

Ethernet with 100 Novell clients. A router needing to forward packets to any of those clients

needs only one entry in its IPX routing table. If those clients were not required to be attached

to the same data link, and if there was no way to encode the IPX network number in the IPX

address of the client, routing would not be capable of using just one entry in the table. This basic

fact is one of the key reasons that routers, using routing as defined by a network layer (Layer

3), can scale to allow tens and hundreds of thousands of devices.

With that in mind, most network layer (Layer 3) addressing schemes were created with the

following goals:

the designers imagined the protocol would be used.

duplication exists.

considered to be in the same group.

A great analogy for this concept of network addressing is the addressing scheme used by the

U.S. Postal Service. Instead of getting involved with every small community’s plans for what

to name new streets, the Post Office simply has a nearby office with a ZIP code. The rest of the

post offices in the country are already prepared to send mail to new businesses and residences

on the new streets; they care only about the ZIP code, which they already know. It is the local

postmaster’s job to assign a mail carrier to deliver and pick up mail on those new streets. There

may be hundreds of Main Streets in different ZIP codes, but as long as there is just one per ZIP

code, the address is unique—and with an amazing percentage of success, the U.S. Postal

Service delivers the mail to the correct address.

Example Layer 3 Address Structures

Each Layer 3 address structure contains at least two parts. One (or more) part at the beginning

of the address works like the ZIP code and essentially identifies the grouping. All instances of

addresses with the same value in these first bits of the address are considered to be in the same

group—for example, the same IP subnet or IPX network or AppleTalk cable range. The last part

of the address acts as a local address, uniquely identifying that device in that particular group.

Table 3-10 outlines several Layer 3 address structures.

IP 32 Network or subnet

(variable, between 8

and 30 bits)

Host (variable, between

2 and 24 bits)

IPX 80 Network (32) Node (48)

For more information about IP and IPX addresses, refer to Chapter 5.

Routing Protocols

Conveniently, the routing tables in the example based on Figure 3-18 all had the correct routing

information already in their routing tables. In most cases, these entries are built dynamically by

any other protocol. With routing protocols, however, the goal is not to help with end-user data

delivery—the end goal is to fill the routing table with all known destination groups and with the

best route to reach each group.

A technical description of the logic behind two underlying routing protocol algorithms,

IPX are listed in Chapter 6, “Routing.”

Nonroutable Protocols

In the early and mid-1990s, one of the reasons that Cisco sold a lot of routers is that the IOS

could route more Layer 3 protocols than most—if not all—competitors. However, some

protocols are not routable. To support those, Cisco supported and evolved variations of bridging

to support nonroutable protocols.

What makes a protocol nonroutable? Basically, a protocol stack that does not define an OSI

Layer 3 equivalent, including a logical Layer 3 address structure, cannot be routed. To be fair,

because the answer to the question “Is a protocol routable?” for any particular protocol is more

of a geek-party discussion, there are no hard and fast rules that govern what has to be true for a

protocol to be considered routable. As this chapter shows, however, forwarding packets

(L3PDUs) based on a destination Layer 3 equivalent address involves routing; a protocol stack

with no Layer 3 is considered nonroutable.

AppleTalk 24 Network (16)

(Consecutively

numbered values in this

field can be combined

into one group, called a

cable range.)

Node (8)

OSI Variable Many formats, many

sizes

Domain Specific Part

(DSP) (typically 56,

including NSAP)

If a protocol is not routable, then bridging must be enabled to support those protocols. (Bridging

concepts are covered in Chapter 4.) To support nonroutable protocols over WAN links, some

other protocol must be used, such as encapsulated transparent bridging and data link switching

(a form of remote bridging for SNA and NetBIOS).

The details of how to support nonroutable protocols is beyond the scope of CCNA. What is

reasonably expected to be in the scope of CCNA is to know the most popular nonroutable

protocols. Consider Table 3-11, which lists protocols that some people consider to be

nonroutable:

DEC LAT and NetBIOS (sometimes referred to as NetBEUI, for NetBIOS End User Interface)

are definitely nonroutable. IBM’s SNA has two general categories: Subarea SNA is the

traditional Mainframe DataCenter SNA, and Advanced Peer-to-Peer Networking (APPN) is a

newer, more easily routable variation. Both are routable, have Layer 3 addressing, and can be

routed by products you can purchase today. However, be careful—Cisco folklore has it that

SNA is not routable. If CCNA exam questions touch on this topic, focus on the context and be

sure to remember that LAT and NetBIOS are truly nonroutable.

This section, however, presents an anecdote that may help you remember the difference

the instructor certification process, who emphasize that the instructors should be creative in the

use of tools to help students remember important details. After I tried this story during

certification, it was propagated by other instructors. I am curious—if you have heard this story

or a variation, please let me know when you heard it and from whom (wendell@lacidar.com).

DEC Local Area Transport

(LAT)

No No

NetBIOS No No

SNA (Traditional Subarea SNA) Yes; routed by IBM products

running VTAM and NCP

No

SNA (APPN) Yes Yes

The Story of Ted and Ting

Ted and Ting both work for the same company at a facility in Snellville, Georgia. They work in

the same department; their job is to make lots of widgets. (Widgets are imaginary products; the

not the topic of discussion.)

Ted worked quickly and was a hard worker. In fact, because he was a very intense person, Ted

tended to make more widgets than anyone else in Snellville, including Ting. Ted also liked to

have everything he needed instantly available when and where he wanted it so that he could

make the widgets more quickly.

Ting, on the other hand, also worked very hard but was much more of a planner. He tended to

think first and then act. Ting planned very well and had all supplies well stocked, including all

the instructions needed to make the different kinds of widgets. In fact, all the information about

how to build each type of widget was on a table by his door. He had a problem with the table

getting “reallocated” (that is, stolen), so he applied a nonremovable label with the words

“Ting’s Table” to the surface so that he could find the table in case someone stole it.

It turns out that Ted’s productivity was in part a result of sitting next to Ting. In fact, Ted often

was ready to make the next widget but needed something, such as the instruction sheet for a

particular unique widget. By swinging into Ting’s office, Ted could be back at it in just a few

seconds. In fact, part of the reason Ting kept the instruction sheets on Ting’s Table by the door

was that he was tired of Ted always interrupting him looking for something.

Well, Ted got lots of bonuses for being the most productive worker, and Ting did not. Being fair,

though, Ted realized that he would not be as successful without Ting, so Ted shared his bonuses

with Ting. (Hey, it’s an imaginary story!)

Then one day the president decided to franchise the company because it was the best widgetmaking

company in the world. The president, Dr. Rou, decided to make a manual to be used by

all the franchisees to build their business. So, Dr. Rou went to the most productive widgetmaker,

Ted, and asked him what he did every day. Along the way, Dr. Rou noticed that Ted went

next door a lot. So, being the bright guy that he was, Dr. Rou visited Ting next and asked him

what he did.

The next day Dr. Rou emerged with the franchise manual. Being an ex-computer networking

professional, he had called the manual “Protocols for Making Widgets.” One part of the

protocol defined how Ted made widgets very fast. Another part described how Ting kept

everything needed by Ted at arm’s length, including all the instructions Ted needed. It even

mentioned Ting’s Table as the place to store the instruction sheets. To give credit where credit

was due—but not too much credit—the names of these protocols were:

and used by the routing process to forward the packets of the routed protocol.

The Foudation Summary is a collection of tables and figures that provide a convenient review

of many key concepts in this chapter. For those of you already comfortable with the topics in

this chapter, this summary could help you recall a few details. For those of you who just read

this chapter, this review should help solidify some key facts. For any of you doing your final

prep before the exam, these tables and figures will be a convenient way to review the day before

the exam.

Table 3-12 lists the OSI layer functions and provides examples for each layer, taken directly

from the ICND course.

Table 3-13 provides some example protocols and shows whether they are connection-oriented

and error-recovering.

Application (Layer 7) User interface Telnet, HTTP

Presentation (Layer 6) How data is presented

Special processing, such as encryption

JPEG, ASCII, EBCDIC

Session (Layer 5) Keeping data from different applications separate Operating systems and

application access

scheduling

Transport (Layer 4) Reliable or unreliable delivery

Error correction before retransmit

TCP, UDP, SPX

Network (Layer 3) Logical addressing, which routers use for path

determination

IP, IPX

Data link (Layer 2) Combination of bits into bytes, and bytes into

frames

Access to the media using MAC address

Error detection, not correction

802.3/802.2, HDLC

Physical (Layer 1) Moving of bits between devices

Specification of voltage, wire speed, and cable

pin-outs

EIA/TIA-232, V.35

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

Connection-oriented Yes LLC type 2 (802.2), TCP (TCP/IP), SPX

(NetWare), X.25

Connection-oriented No Frame Relay virtual circuits, ATM virtual

connections, PPP

Connectionless Yes TFTP, NetWare NCP (without Packet Burst)

Connectionless No UDP, IP, IPX, AppleTalk DDP, most Layer 3

protocols, 802.3, 802.5

Table 3-14 summarizes the concepts behind error recovery and lists the behavior of three

popular error-recovery protocols.

Acknowledges data in both directions? Yes Yes Yes

Provides forward acknowledgment? Yes Yes Yes

Counts bytes or frame/packets? Bytes Packets Frames

Necessitates resending of all data, or

just one part and wait when resending?

One and wait Resend all Resend all

Table 3-15 summarizes the flow control terms and provides examples of each of the three types

of flow control.

Table 3-16 summarizes most of the details about MAC addresses.

Buffering — —

Congestion avoidance Stop/Start, RNR, Source Quench SDLC, LAPB, LLC2

Windowing — TCP, SPX, LLC2

MAC Media Access Control. 802.3 (Ethernet) and 802.5 (Token

Ring) are the MAC sublayers of these two LAN data link

protocols.

Ethernet address, NIC address, LAN

address, Token Ring address, card

address

Other names often used instead of MAC address. These

terms describe the 6-byte address of the LAN interface card.

Burned-in address The 6-byte address assigned by the vendor making the card.

It is usually burned in to a ROM or EEPROM on the LAN

card, and it begins with a 3-byte Organizationally Unique

Identifier (OUI) assigned by the IEEE.

Locally administered address Via configuration, an address that is used instead of the

burned-in address.

Unicast address Fancy term for a MAC that represents a single LAN

interface.

Broadcast address An address that means “all devices that reside on this LAN

right now.”

Multicast address Not valid on Token Ring. On Ethernet, a multicast address

implies some subset of all devices currently on the LAN.

Functional address Not valid on Ethernet. On Token Ring, these addresses are

reserved to represent the device(s) on the ring performing a

particular function. For example, all source-route bridges

supply the ring number to other devices. To do so, they each

listen for the Ring Parameter Server (RPS) functional

address.

Table 3-17 summarizes the different choices for encoding protocol types for each of the four

data link protocols covered in this chapter.

Table 3-18 summarizes the basic functions of data link protocols.

Ethernet and Token Ring DSAP 802.2 header 1 byte

Ethernet and Token Ring SSAP 802.2 header 1 byte

Ethernet and Token Ring Protocol Type SNAP header 2 bytes

Ethernet (DIX) Ethertype Ethernet header 2 bytes

HDLC Cisco proprietary

protocol id field

Extra Cisco header 2 bytes

Frame Relay RFC 1490 NLPID RFC1490 1 byte

Frame Relay RFC 1490 L2 or L3 Protocol ID Q.933 2 bytes each

Frame Relay RFC 1490 SNAP Protocol Type SNAP header 2 bytes

Arbitration CSMA/CD

algorithm (part of

MAC)

Token passing

(part of MAC)

— —

Addressing Source and

destination MAC

addresses

Source and

Destination MAC

addresses

Single 1-byte

address;

unimportant on

point-to-point links

DLCI used to

identify virtual

circuits

Error detection FCS in trailer FCS in trailer FCS in trailer FCS in trailer

Identifying

contents of

“data”

802.2 DSAP, SNAP

header, or

Ethertype, as

needed

802.2 DSAP, or

SNAP header, as

needed

Proprietary Type

field

RFC 1490

headers, with

NLPID, L2 and

L3 protocol IDs,

or SNAP header

Table 3-19 outlines several Layer 3 address structures.

Figure 3-20 illustrates the construction of frames, packets, and segments and shows the

different layers’ perspectives on what is considered to be the data.

IP 32 Network or subnet (variable,

between 8 and 30 bits)

Host (variable, between 2 and 24

bits)

IPX 80 Network (32) Node (48)

AppleTalk 24 Network (16) (Consecutively

numbered values in this field

can be combined into one

group, called a cable range.)

Node (8)

OSI Variable Many formats, many sizes DSP (typically 56, including NSAP)

As mentioned in Chapter 1, “All About the Cisco Certified Network Associate Certification,”

the questions and scenarios in this book are more difficult than what you should experience on

the actual exam. The questions do not attempt to cover more breadth or depth than the exam;

however, they are designed to make sure that you know the answer. Rather than allowing you

to derive the answer from clues hidden inside the question itself, the questions challenge your

understanding and recall of the subject. Questions from the “Do I Know This Already?” quiz

from the beginning of the chapter are repeated here to ensure that you have mastered the

chapter’s topic areas. Hopefully, these questions will help limit the number of exam questions

on which you narrow your choices to two options and then guess.

The answers to these questions can be found in Appendix A, on page 710.

a physical interface to a network. Use the OSI model as an example.

4. On its next sent frame, the receiver of these frames sets an acknowledgment field to 4.

What does this typically imply?

card?

address is a member of?

address is a member of?

address is a member of?

choose to send a packet to this router instead of directly to the destination host?

host choose to send a packet to this router instead of directly to the destination host?

Given the network in Figure 3-22 and the address table in Table 3-20, perform the tasks that

follow. This scenario uses an imaginary Layer 3 addressing structure as a method to review

concepts. When in doubt, concentrate on the concepts. Also, the imaginary Layer 3 used in this

example is here only to allow you to concentrate on the concepts instead of a particular

protocol; there is no need to memorize this scheme or expect questions like this on the exam.

A E0 group-1.local-A

A S0 group-2.local-A

A S1 group-5.local-A

B S0 group-2.local-B

B E0 group-3.local-B

Create the routing table in Router A; assume that all parts of the network are up and working

properly. Table 3-21 provides an empty routing table to record your answers.

C E0 group-3.local-C

C T0 group-4.local-C

D S0 group-5.local-D

D E0 group-6.local-D

E S0 group-5.local-E

E E0 group-7.local-E

D’Artagnan group-1.local-M

Aramis group-4.local-M

Porthos group-6.local-M

Athos group-7.local-M

D’Artagnan sends a packet to Aramis (source group-1.local-M, destination group-4.local-M).

D’Artagnan sends this packet inside an Ethernet frame to Router A. Given this information,

determine the following:

to Aramis.

router?

D’Artagnan?

D’Artagnan sends a packet to Porthos (source group-1.local-M, destination group-6.local-M).

D’Artagnan sends this packet inside an Ethernet frame to Router A. Given this information,

determine the following:

to Porthos.

router?

D’Artagnan?

Based on the network design illustrated in Figure 3-22, Task 1 for Scenario 3-1 asks you to

create the routing table in Router A; assume that all parts of the network are up and working

properly. The routing table for Router A is as follows:

Based on the network design illustrated in Figure 3-22, Task 2 for Scenario 3-1 states that

D’Artagnan sends a packet to Aramis (source group-1.local-M, destination group-4.local-M).

D’Artagnan sends this packet inside an Ethernet frame to Router A. The following are the

solutions to exercises 1 through 4 for Task 2.

In Router A:

In Router B:

group-1 Ethernet 0 —

group-2 serial 0 —

group-3 serial 0 group-2.local-B

group-4 serial 0 group-2.local-B

group-5 serial 1 —

group-6 serial 1 group-5.local-D

group-7 serial 1 group-5.local-E

group-2 serial 0 —

group-4 serial 0 group-2.local-B

group-3 Ethernet 0 —

group-4 Ethernet 0 group-3.local-C

In Router C:

HDLC header and adds an Ethernet header. Router C discards the Ethernet header and

adds a Token Ring header.

places Router C’s Ethernet MAC address into the destination address field. Router C

places Aramis’s Token Ring MAC address into the destination address field.

tables show the routes needed for both directions; the routes with asterisks signify routes

required for the routes back to D’Artagnan.

In Router A:

In Router B:

In Router C:

group-4 Token Ring 0 —

group-1* Ethernet 0 —

group-2 serial 0 —

group-4 serial 0 group-2.local-B

group-1* serial 0 group-2.local-A

group-2* serial 0 —

group-3 Ethernet 0 —

group-4 Ethernet 0 group-3.local-C

group-1* Ethernet 0 group-3.local-B

group-3* Ethernet 0 —

group-4 Token ring 0 —

Based on the network design illustrated in Figure 3-22, Task 3 for Scenario 3-1 states that

D’Artagnan sends a packet to Porthos (source group-1.local-M, destination group-6.local-M).

D’Artagnan sends this packet inside an Ethernet frame to Router A. The following are the

solutions to exercises 1 through 4 for Task 3.

In Router A:

In Router D:

the Frame Relay header and adds an Ethernet header.

address field in the header. Router D places Porthos’s Ethernet MAC address into the

destination address field.

tables show the routes needed for both directions; the routes with asterisks signify routes

required for the routes back to D’Artagnan.

In Router A:

group-5 serial 1 —

group-6 serial 1 group-5.local-D

group-6 Ethernet 0 —

group-1* Ethernet 0 —

group-5 serial 1 —

group-6 serial 1 group-5.local-D

In Router D:

group-1* serial 0 group-5.local-A

group-5* serial 0 —

group-6 Ethernet 0 —