Ethernet Networking- P2 ppsx

However, before we can look at the physical layer in depth, you need to know how the upper layers of the TCP/IP protocol stack operate.. However, because bits flow between machines only

The number of bits that can travel together at the same time represents the

bandwidth of the transmission medium If we can increase the bandwidth,

we can increase the throughput without changing the maximum physical transfer speed of bits down the wire Fiber optic cabling, for example, is very fast not only because each bit can travel at the speed of light, but be- cause so many tiny glass fibers can be bound together into a single cable to provide a high bandwidth

Ethernet Standards

The types of Ethernet about which you have just read are defined in a set

of standards prepared by the Institute of Electrical and Electronic Engi- neers (IEEE) The committee in charge of the standards for LANs is known

as IEEE LAN 802, and the group within it that handles media access con- trois standards as 802.3 Each 802.3 standard describes a method for media access control and the transmission media that should be supported

Note: Although the name of the IEEE may not suggest that the organization has anything to do with computing, keep

in mind that the IEEE predates computers It has evolved

to encompass a wide range of computing standards and applications

Although in most cases you won't be concerned directly with the specifi- cations themselves and the rather strange numbering scheme that goes along with them, you may find that equipment and cable vendors use the standard numbers to identify the type of Ethernet for which a product is ap- propriate You should therefore at least be familiar with the type of Ether- net each standard represents This book identifies the standards that accompany each type of Ethernet cabling as we explore hardware details

in the following chapters

A Bit of Ethernet History

Originally, Ethernet was the brainchild of one person: Robert Metcalfe In the early 1970s, while working at Xerox PARC on the "office of the future" project, Metcalfe was intrigued by a radio network in Hawaii known as AlohaNet One problem faced by AlohaNet's media access control was that its maximum effeciency was 17 percent: That is, a maximum of 17 percent of the transmission units sent actually reached their destination According to Metcalfe, the unreceived portions of the transmissions were

"lost in the ether."

Metcalfe developed an alternative media access control method that al- lowed up to 90 percent of the transmission units to reach their destination Originally known as "experimental Ethernet," it transferred up to 3 Mbps

As you can see in Metcalfe's original drawing in Figure 1-6, he refers to the cabling along with data travel as "the ether," hence the name Ethernet

Figure 1-6:

Metcalfe)

Bob Metcalfe' s original drawing for Ethernet (Courtesy of Bob

Note: Bob Metcalfe went on to found the 3Com Corpora- tion and currently is a networking pundit and guru His columns appear in InfoWorld and elsewhere

The first Ethernet specifications were published in 1980 by a consortium

of commercial hardware vendors ~ Digital Equipment Corporation (now

a part of Compaq Corp.), Intel, and Xerox (DIX) By that time, the trans- mission speed had been increased tO 10 Mbps

The IEEE adopted Ethernet as a LAN standard and published its initial specifications as 10BASE5 in 1983 Later, Ethernet was also endorsed as

a standard by the ISO Ethernet is therefore an international standard for one way in which nodes on a LAN can gain access to transmission media Throughout its history, Ethernet has moved to faster and faster standards:

1986: The standard for 10BASE2 was approved, still running

at 10 Mpbs

1991: The standard for 10BASE-T was approved Although still running at 10 Mpbs, it used copper wiring, making it much easier to handle than earlier standards

Note: For more information on these earlier Ethernet standards, see Appendix A

1995: The standard for 100 Mpbs Ethemet was approved This

is the slowest speed in general use today

1998: The standard for 1000 Mbps (Gigabit) Ethernet using fi- ber optic cable was approved

1999: The standard for 1000 Mbps Ethemet using copper wire was approved

2002: The standard for 10,000 Mbps (10 Gigabit) Ethemet was approved This type of Ethemet is for wide area rather than lo- cal area networks

As of early 2007, standards committees were beginning to explore the pos- sibilities for 40 Gigabit and 100 Gigabit Ethernet, although speeds beyond

1 Gigabit currently aren't designed for use in local area networks

How TCP/IP and Ethernet Work

Regardless of the type of Ethernet you choose, the basic way in which data are packaged to travel over the network and the way in which devices gain access to the network media remain the same In this chapter we will there- fore look at both the packaging of the data and the way that Ethernet pro- vides media access control

However, before we can look at the physical layer in depth, you need to know how the upper layers of the TCP/IP protocol stack operate This knowledge forms the basis for understanding how devices such as switches and routers determine where to send packets of information

21

Network Data Transmission

The data that travel over a network can be serial or parallel With serial

data transmission, each bit (a 0 or 1 value) travels single file Parallel data transmission sends rows of bits, 32, 64, 128, or more at a time As you may remember from Chapter 1, the bandwidth of a data communications chan- nel relates to the number of bits per unit time (usually a second) that arrive

at their destination, thus the term bits per second for the speed of a data

communications network

It might seem at first that parallel transmission is faster than serial

t r a n s m i s s i o n ~ a n d it i s ~ b u t we use serial transmission over data com- munications networks because there is a major drawback to parallel transmission~interference that gets worse over distance Let's assume that you have a cable designed to carry 32 bits in parallel Because each wire in the cable can carry only one bit at a time, you need to bundle 32 wires together to obtain the desired bandwidth (If they aren't close togeth-

er, it will be next to impossible to fit a connector to them.)

Unfortunately, the wires in the cable tend to leak signals to one another The closer the wires are bound and the longer they get, the worse the inter- ference Therefore, parallel transmission of this type (using a flat ribbon cable) is only good for very short distances, such as a few feet Today we

use it most commonly for connecting peripherals such as disk drives inside

a system box

The speed of a serial t r a n s m i s s i o n ~ t h e speed at which data reach their

d e s t i n a t i o n ~ i s affected by many factors, including the following:

The maximum physical speed that the wire can carry a signal

Note: When we speak of "wire" in this context, we mean copper wire and fiber optics

The speed at which a new signal can be placed on the wire This

is an effect of the equipment that places signals on the wire, as well as the method for giving hardware control of the wire The ratio of overhead bits to data bits (The more overhead bits you have, the lower the data throughput.)

Major TCP/IP Protocols

In a practical sense, you don't need to know anything about networking protocols to plug the right wires into the fight interconnection hardware However, if you really want to know how your equipment works, then you'll want to understand the material in this section It looks at how pro- tocols stacks work in general and how the major TCP/IP protocols work specifically

The Operation of a Protocol Stack

The protocols in a protocol stack are organized so that protocols that pro- vide similar functions are grouped into a single layer As you saw in Chap- ter 1, the original TCP/IP provided four layers (It has no physical layer.) However, the lower two layers of the original four have been replaced with protocols that were originally part of the OSI protocol stack

The exchange of bits occurs only at the Physical layer The remaining lay- ers are software protocols Conceptually, each layer communicates with the matching layer on the machine with which it is exchanging messages,

as in Figure 2-1 However, because bits flow between machines only at the Physical layer, the actual communication is down one protocol stack, across the Physical layer, and up the receiving protocol stack (see Figure 2-2)

The top three layers in the TCP/IP protocol stack are independent of the hardware a network is using The remaining layers, however, are hard- ware-dependent, often meaning that there will be multiple sets of protocol specifications corresponding to different types of hardware

As a message moves down the protocol stack on the sending machine, it is

encapsulated: Each software layer below the Application layer adds a header (and possibly a trailer) to the message before passing it down On the receiving end, each layer strips off the header (and trailer, if present) before passing the message up to the next layer By the time the message reaches the Application layer on the destination machine, it has been re- stored to is original state

Application layer Transport layer Internet layer _ 1Logical_U nk _Con~_.ol

Internet layer

._ _.Logical_ U n.nk _Con_.~ol _

~ ~~~yer

Physical layer Figure 2-1" Logical protocol communication

Application layer Transport layer Internet layer _ Logical Link Control MAC layer

Physical layer

, , ,

Application layer Transport layer Internet layer _ _Logi~_.].l Link _controls ' _ MAC layer Physical layer Figure 2-2: The actual path for protocol communication

The Application Layer

The Application layer handles the interaction with the end user All mes- sages originate there Commonly, the Application layer sends a string of text down to the Transport layer, which begins the encapsulation process .Frequently used Application layer protocols are summarized in Table 2-1

In most cases, the specifications for a protocol include the syntax and com- mands to be used when formulating the message For example, to retrieve

Table 2-1" Frequently Used TCP/IP Application Layer Protocols

Acronym Name Purpose

HTTP Hypertext Transport

Protocol

SMTP Simple Mail Transport Protocol

MIME Multipurpose Internet

Domain Name Server

Manage the interaction between Web clients (browsers) and Web servers

Transfer e-mail messages between client (e- mail client software) and e-mail server as well as between servers

Provide format conversation for e-mail extensions so they can travel over a TCP/IP network

Handle e-mail transfer Manage the mapping of domain names to IP addresses

File Transfer Protocol

Network News Transfer Protocol

Transfer files Exchange Internet news articles between servers and clients

a Web page, a Web browser formats a GET command, which includes the URL of the page to be retrieved

Users rarely interact with the application layer protocol directly Instead, applications present a more user-friendly interface to the user and then for- mulate the communications command out of sight

The Transport Layer

The Transport layer contains two protocols" TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) They are fundamentally dif- ferent in the way in which they operate TCP provides a virtual connection between the communicating Transport layers and is suitable for long mes- sages; UDP does not provide a virtual connection and is used mostly for short messages

Transmission Control Protocol

TCP is known as a connection-oriented protocol because it establishes a logical circuit between sender and recipient that stays intact for the dura- tion of a communications session It is also known as a reliable protocol because it provides both error correction and detection

The heart of TCP's operation is its three-way handshake for establishing a connection, which works in the following manner:

1 The sender transmits a segments with a SYN (Synchronization of Se- quence Numbers) request (a request to open a virtual connection be- tween the two machines) The sender chooses an ISN (Initial Sequence Number), either a 0 or some random number, that it sends in the initial SYN request

2 The destination replies with a SYN containing the sender' s original se- quence number and an ACK (Acknowledge) containing the sender's original sequence number plus 1 (The segments may not arrive at the destination in the correct order, so the sequence numbers are essential

to reassembling the message They are also unique identifiers for each segment.)

3 The source responds with an ACK and the connection is established

A similar process gives TCP its reliability and error correction ability Each segment that TCP sends is acknowledged by the recipient with an ACK segment This ensures reliability; if the sender doesn't receive the ACK message within a specified amount of time, it retransmits the seg- ment This also provides error correction for segments dropped when other layers and/or protocols detected errors in them The beauty of having TCP handle the error correction is that lower level protocols need to worry only about error detection

Because each segment received must be acknowledged, TCP is a verbose protocol, at least compared to UDP It also is not a particularly fast protocol compared to UDP because it requires an extra exchange of messages When TCP receives a message from the Application layer, it attaches a header to the message, creating a segment You can find the structure of a segment in Figure 2-3 The application layer message appears in the Data field; the rest of the segment is the header The header fields are summa- rized in Table 2-2

0 15 31

Source port I Destination port

Sequence number Acknowledgment number

Data

Offset I Reserved I Flags I Window

Checksum [ Urgent pointer

Options I Padding

Data

Figure 2-3" The structure of a TCP segment

Table 2-2: Fields in a TCP header

Source Port 16 bits

Destination Port 16 bits

Sequence Number 32 bits

A number acknowledging the receipt of a segment It is set to the number of the next octet the recipient expects to receive

Table 2-2: Fields in a TCP header (Continued)

Not used currently Set to zero

URG: Read Urgent Pointer field ACK: Read Acknowledgment field PSH: Push function

RST: Connection reset SYN: Synchronize FIN: Last segment in the set

A message digest (see Chapter 12 for details)

An offset into the Data field indicating where urgent data begin Read only if the URG flag is set

A collection of information about the segment, including the maximum segment size

Extra space added to ensure that the Data field begins on a 32-bit boundary

a An octet is an 8-bit byte In the early days of computing, a byte wasn't necessarily 8-bits We therefore carry over the term octet in data communications for historical reasons

TCP manages its error correction in the following way:

1 Establish a virtual connection using the three-way handshake (See Chapter 6 for details.)

2 Send the first data-carrying segment (This will actually be the fourth segement, since the first three were used to set up the connection.)

3 When the segment is received, the recipient counts the number of oc- tets in the Data field and adds 1 This will be the value of the next se- quence number

4 Place the computed next sequence number in the Acknowledgment field of a segment and send it back to the sender

5 If the source does not receive the acknowledgment segment in a preset amount of time, retransmit the segment

User Datagram Protocol

UDP does not provide error correction and is therefore an unreliable pro- tocol In other words, delivery of packets is not guaranteed UDP data- grams are transmitted without provision for an acknowledgment Because there is no virtual connection between sender and receiver, UDP is also said to be connectionless

Although it might seem that UDP's unreliability might make it unsuitable for much use, it is actually able to carry a number of Application layer pro- tocol messages (TCP carries about 80 percent of Internet traffic; UDP car- ties the rest.) The most common Application layer protocols carried by UDP datagrams can be found in Table 2-3

Table 2-3: Application Layer Protocols Carried by UDP Datagrams

Acronym Name Comments

Proprietary

Proprietary

SNMP Simple Network Management

Protocol RIP

Updates the routing tables in routers Maps IP addresses to domain names

Because UDP doesn't require the error correction segments used by TCP,

it is faster than TCP It is therefore also well suited to streaming media, where retransmitting a corrupted segment won't provide any benefits

The Internet Layer

Like the Transport layer, the Internet layer has only two protocols" IP (In- ternet Protocol) and ICMP (Internet Control Message Protocol) The latter

is used to carry IP control messages It is IP, however, that forms the back-

bone of the TCP/IP protocol stack because every data-carrying message passes through it

IP is connectionless, and therefore unreliable (Remember that it doesn't need to do error correction because TCP is taking care of that.) IP does er- ror detection, however It uses a checksum to verify that a message was re- ceived without alteration If it determines that the message was altered, it discards the message Because the Transport layer on the receiving ma- chine will never receive the message, the Transport layer on the sending machine won't receive an acknowledgment for the packet, triggering a re- transmission

IP receives a segment from the Transport layer It adds its own header and footer, creating a packet, which it then sends to the Data Link layer IP also handles fragmentation, the splitting and reassembly of packets based on the largest packet size a network can handle In addition, IP takes care of packet routing

Note: Most routers don't have an entire TCP/IP protocol stack, but only the bottom layers, stopping with the Inter- net layer They don't need the Transport and Application layers because they can route packets using IP

An IP packet encapsulates an entire Transport layer segment, placing the segment (including the Transport layer header) into its Data field, as in Fig- ure 2-4 The uses of the fields in the header are summarized in Table 2-4 Many of the fields in the IP header deal with fragmentation, which occurs because different types of networks have different limits on the size of pack- ets they can carry When a router receives a packet that is too large for the network over which it must send a packet, it extracts the data portion of the original packet and breaks it into chunks Then it adds a complete IP header

to each chunk, creating a message fragment A packet may be fragmented many times before it reaches its destination However, the fragments are not reassembled into the message until all fragments have been received by the destination machine This is because all fragments may not travel by the same route to reach their destination In addition, differences in the speed

of network links may cause the fragments to arrive out of order

0 15 31

Header ] Type of service [ Totalpacketlength Version Length

Identification [Flags[ Fragment offset

Source IP address Destination IP address Options Data Figure 2-4: The structure of an IP packet

The Logical Link Control Layer

The Logical Link Control (LLC) layer provides the major interface be- tween the hardware below and the software layers above Because it sits between the protocols in the MAC layer that regulate access to transmis- sion media and the rest of the protocol stack, the LLC layer lets the upper layers communicate with any form of transmission media in the same way The LLC layer receives an IP packet from the Intemet layer and formats it

into frames, the units that will be sent across the physical media The orga- nization of a flame, however, depends on the type of MAC protocol that will be used This means that the LLC is hardware-dependent, unlike the upper layers in the protocol stack

LLC layer protocols include specifications for the flames of many types of physical networks, including Ethemet, Token Ring (rarely used today be- cause it has become nearly impossible to find parts to maintain the

Table 2-4: The Header Fields in an IP Packet

IP Header Length 4 bits

Type of Service 8 bits

Total Packet Length 16 bits

Identification 16 bits

Fragment Offset 13 bits

Time to Live 8 bits

The number of 32-bit words in the header

The type of service requested This field currently is very rarely used

Number of octets in the entire packet (header and data)

If the packet is part of a set of fragments, a value that, when combined with the source IP address, uniquely identifies this fragment

Flags that provide fragmentation information If the third bit is set, there are additional fragments for the packet If the second bit is set, the packet is not to be fragmented The position of this fragment in the original packet, indicated by the number of octets it begins from the start

of the original packet

The maximum number of router hops allowed for the packet The purpose of this value is to keep a packet from circulating forever around the network Each router decrements this value by one

The type of Transport layer protocol segment being carded by the packet

The IP address of the originator of the message

The IP address of the message's intended recipient

Used occasionally today but usually left empty because many routers drop datagrams with nonempty options

hardware), and FDDI (Fiber Distributed Data Interface) LLC also includes WAN protocols such as ATM, Frame Relay, SONET, X.25, and PPP (Point- to-Point protocol, used for communication between dial-up modems)