Ethernet Frame Types and Ethernet Design

Ethernet Frame Types and Ethernet Design
Lesson 3

Ethernet is the term that is casually applied to a number of very different data link implementations.

You will hear people refer to "Ethernet" and they might be referring to the original DEC, Intel, and Xerox implementation of Version 1 or Version 2 Ethernet. This, in a sense, is the "true" definition of "Ethernet". DIX Novell 802.2 SNAP

When the IEEE built the standards in 1984 the term "Ethernet" was broadly applied to them as well. Today we talk about "Fast Ethernet" and, although this technology bears many similarities to its predecessors, the engineering technology has changed dramatically.

Ethernet is a DataLink Technology
Whatever you call it, this is a Data Link technology - responsible for delivering a frame of bits from one network interface to another - perhaps through a repeater, switch, or bridge.

Ethernet Frame Formats

Before we investigate the frame formats in detail lets have a quick look at what frame formats look like.

IEEE 802.3 with LLC 802.2 ethernet frame structure (Length)
Ethernet II / DIX ethernet frame structure (Type) Ethernet SNAP frame structure with SNAP field ( Type )

When somebody tells me that they are running Ethernet on their network, I inevitably have to ask: "Which Ethernet?". Currently, there are many versions of the Ethernet Frame Format in the commercial marketplace, all subtly different, and not necessarily compatible with each other.

The explanation for the many types of Ethernet Frame Formats currently on the marketplace lies in Ethernet's history.

In 1972, Work on the original version of Ethernet, Ethernet Version 1, began at the Xerox Palo Alto Research Center PARC. Version 1 Ethernet was released in 1980 by a consortium of companies consisting of DEC, Intel, and Xerox. DIX

In the same year, the IEEE meetings on Ethernet began.

In 1982, the DIX (DEC/Intel/Xerox) consortium Released Version II Ethernet, and since then, it has almost completely replaced Version I in the marketplace. DIX Ethernet = Version II Ethernet

In 1983, Novell NetWare '86 was released, with a proprietary frame format based on a preliminary release of the spec.

Two years later, when the final version of the spec was released, it had been modified to include the LLC Header. Making NetWare's proprietary format incompatible.

Finally, the SNAP format was created to address backwards compatibility issues between Version 2 and Ethernet. SubNetwork Access Protocol

As you can see, the large number of players in the Ethernet world has created a number of different choices. The bottom line is this:

Either a particular software / hardware driver supports a particular frame format, or it doesn't.

Typically, Novell stations can support any of the frame formats While TCP/IP stations will support only one, although there are no hard and fast rules in Networking.

Before we investigate the specific fields in the different types of Ethernet frames. Lets take a quick look at what is sent prior to the Frame on the DataLink “The Preeamble”

The Preamble Before the Frame arrives….

The Preamble Before the Frame arrives….
Regardless of the frame type being used… The means of digital signal encoding on an Ethernet network is the same.

The Preamble On an idle Ethernet network, there is no signal.
Because each station has its own oscillating clock, the communicating stations have to have some way to "synch up" their clocks and thereby agree on how long one bit time is.

The Preamble The preamble facilitates this.
The preamble consists of 8 bytes = 32 bits of alternating ones and zeros, ending in 11

The Preamble A station on an Ethernet network detects the change in voltage that occurs when another station begins to transmit, and uses the preamble to "lock on" to the sending station's clock signal.

The Preamble Because it takes some amount of time for a station to "lock on", the receiver does not know how many bits of the preamble have gone by. For this reason, we say that the preamble is "lost" in the "synching up" process.

The Preamble No part of the preamble ever enters the adapter's memory buffer. Once locked on, the receiving station waits for the 11 that signals that the Ethernet frame follows.

The Preamble Most modern Ethernet adapters are guaranteed to achieve a signal lock within 14 bit-times.

The Different Flavours of Ethernet
While the preamble is common to every type of Ethernet, what follows it is certainly not. The major types of Ethernet Frame Format are: Next I will present you with the names of the 4 types of ethernet frames. Don’t worry we will be looking at each in much depth soon. 

Frame Type – Novel Type CISCO

Frame Type – Novel Type CISCO IEEE – Ethernet – LLC

Frame Type – Novel Type CISCO IEEE – Ethernet – LLC Version II - Ethernet II ARPA

Frame Type – Novel Type CISCO IEEE – Ethernet – LLC Version II - Ethernet II ARPA IEEE802.3 Snap – SNAP – Ethernet Snap

Frame Type – Novel Type CISCO IEEE – Ethernet – LLC Version II - Ethernet II ARPA IEEE802.3 Snap – SNAP – Ethernet Snap 802.2 RAW – Ethernet Novell

Just make a mental note for now that----
Min Frame size = 64bytes = 512 bits Max Frame size = 1518 bytes Reasons why later …….

Lets now look at the 1st Frame type mentioned
IEEE = Ethernet = LLC Remember this is the one the IEEE took 2 years to ratify.

IEEE Frame Format (with LLC which is described by IEEE802.2)

= 14 bytes = 3 bytes 4 bytes The Specification defines a 14 byte Data Link Header followed by a 3 byte LLC (Logical Link Control) Header that is defined by the Specification. Remember that---- Min Frame size = 64bytes 64 – 14 – 3 – 4 = 43 bytes payload min

IEEE802.3 The receiver now having locked on to the preeamble counts in bytes 0 thru 5 Offset 0-5: The Destination Address The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of FF.FF.FF.FF.FF.FF specifies a Broadcast Message that is read in by all receiving Ethernet adapters.

IEEE802.3 The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter, and are specific to the vendor. The Destination Address format is identical in all implementations of Ethernet. Link to ethernet vedor codes

Vendor Codes examples 00000C Cisco 009004 3Com 00A024 3com
Intel 0090B1 Cisco 00902B Cisco Ethernet Switches and Light Streams 0090F2 Cisco Ethernet Switches and Light Streams 00000C Cisco 0090AB Cisco 00A000 Bay Networks Ethernet switch 00A040 Apple (PCI Mac)

IEEE802.3 Offset 6-11: The Source Address The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card. The Source Address format is identical in all implementations of Ethernet.

IEEE802.3 Offset 12-13: Length Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame, not including the preamble, 32 bit CRC, DLC addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes total length, and no longer than 1518 bytes total length.

IEEE802.3 Offset 12-13: Length cont--- (Bytes 13 and 14)
After the preamble the "IEEE802.3 Length" field. Also the "Ethernet Type" Values are managed by XEROX The Length is used to determine the length of the data contained herein the frame. Length of data can be no longer than 1497 (1518 – 21 header bytes) If Length > 1500 then it cannot be a Length descriptor, hence it is a “Type” field and hence part of an Ethernet II or DIX frame

More right now on this Length v Type field
EtherTypes point to upper layer applications Types are used by Ethernet II / DIX You know its not a length value being described by octet because the all Ethertype values are greater than 0x5DC or 1500 decimal !! 1500 is the max size a Data field could hold for all Ethernet flavours! 802.3 Does not use octets for upper layer identification ! (DIX does not have 3byte LLC hence = 1500  ) It uses a SNAP field …More on SNAP in a minute.

These values below are > than 0x05DC (1500)
Ethertype examples Link to Ethernet 'Ethertypes / Length codes' 0x0000-0x05DC IEEE802.3 Length Field (0.:1500.) Any value at octet in the range above indicate a Length field hence IEEE802.3 frame! These values below are > than 0x05DC (1500) 0x0800 DOD Internet Protocol (IP) 0x0806 Address Resolution Protocol (ARP) 0x809B EtherTalk (AppleTalk over Ethernet)

IEEE802.3 Following the Data Link Header is the Logical Link Control Header.

IEEE802.3 Following the Data Link Header is the Logical Link Control Header. The purpose of the LLC header is to provide a "hole in the ceiling" of the Data Link Layer By specifying into which memory buffer the adapter places the data frame, the LLC header allows the upper layers to know where to find the data.

The Logical Link Control
LLC is responsible for identifying network layer 3 protocols and encapsulating them into layer 2 Frames.

An LLC Header also tells the DataLink what to do with a packet once it is received ….. With a little help from SNAP 0x00AA

i.e .. A host will receive a Frame and then look at octets which will identify the presence of LLC encapsulation. The LLC header provides further information to understand that the packet is for IP, via the LSAP service types contained in the DSAP / SSAP octets.

IEEE802.3 LLC Header Offset 15: The DSAP The DSAP, or Destination Service Access Point, is a 1 byte field that simply acts as a pointer to a memory buffer in the receiving station. It tells the receiving NIC in which buffer to put this information. This functionality is crucial in situations where users are running multiple protocol stacks, etc...

The LLC Header Offset 16: The SSAP The SSAP, or Source Service Access Point is analogous to the DSAP, and specifies the Source of the sending process.

The LLC Header LSAP numbers
The LSAP’s are thus service access points, which specify a unique identifier within the station through which a remote station can access to communicate. LSAP’s use the DSAP / SSAP Octets As such lets now look at some LSAP examples

Link Service Access Points
Link Service Access Point Description References IEEE Internet binary binary decimal Null LSAP [IEEE] Indiv LLC Sublayer Mgt [IEEE] Group LLC Sublayer Mgt [IEEE] SNA Path Control [IEEE] Reserved (DOD IP) [104,JBP] PROWAY-LAN [IEEE] EIA-RS [IEEE] ISI IP [JBP] PROWAY-LAN [IEEE] SNAP [IEEE] ISO CLNS IS [64,JXJ] Global DSAP [IEEE]

The LLC Header Offset 17: The Control Byte Following the SAPs is a one byte control field that specifies the type of LLC frame that this is.

User Data and the Frame Check Sequence
Data: Bytes Following the header are 43 to 1,497 bytes of user data, generally consisting of upper layer headers such as UDP/TCP/IP or IPX and then the actual user data.

User Data and the Frame Check Sequence
FCS: Last 4 Bytes The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.

Below is an example of how an IEEE802
Below is an example of how an IEEE802.3 Frame identifies that its payload is destined for IP As an example, to indicate that the Data is to be delivered to the TCP/IP internet protocol, IEEE802.3 LSAP values are: DSAP: 170(decimal) or 0xAA(hex) = SNAP SSAP: 170(decimal) or 0xAA(hex) = SNAP Ctrl: 3 = (for unnumbered information) Organ. Code: 0 Type: 2048(decimal), or 0x0800(hex), Xerox assigned protocol number = IP

Ethernet DIX / Version II
IEEE802.3 was fairly complicated. Ethernet DIX / II is more simple. The following is a description of the frame format described by the original Ethernet Version II specification, as released by DEC, Intel, and Xerox.

Like the spec, the Version II spec defines a Data Link Header consisting of 14 bytes of information, but the Version II spec does not specify an LLC header

Offset 0-5: The Destination Address The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.

Offset 6-11: The Source Address The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.

Offset 12-13: The Ethertype Following the Source Address is a 2 byte field called the Ethertype. The Ethertype is analogous to the SAPs in the frame in that it specifies the memory buffer in which to place this frame, and which application to hand to payload too.

Ethernet Type Version II
An interesting question arises when one considers the and Version II frame formats: Both formats specify a 2 byte field following the source address (an Ethertype in Version II, and a Length field in 802.3) How does a driver know which format it is seeing, if it is configured to support both?

The answer is actually quite simple. Just remember all Ethertypes have a value greater than 05DC hex, or 1500 decimal. Since the maximum frame size in Ethernet is 1518 bytes, there is no point of overlap between Ethertypes and lengths. If the field that follows the Source Address is greater than O5DC hex. The frame is a Version II, otherwise, It is something else (either 802.3, SNAP, or Novell Proprietary).

Data: Bytes Following the Ethertype are 46 to 1,500 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data. Remember for Ethernet there were bytes for data ! Because has more header bytes ( 21 ) above we have 18

FCS: Last 4 Bytes The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.

Ethernet Type SNAP The SNAP Frame Format consists of a normal Data Link Header followed by a normal LLC Header, and then a 5 byte SNAP field, followed by the normal user data and FCS.

Ethernet Type SNAP While the original specification worked well, the IEEE realised that some upper layer protocols required an Ethertype to work properly. For example, TCP/IP uses the Ethertype 0x806 to differentiate between ARP packets and normal 0x0800 IP data frames.

Ethernet Type SNAP In order to provide this backwards compatibility with the Version II frame type, the SNAP (SubNetwork Access Protocol) format was created. And is identified by a LSAP value of 0xAA for both the DSAP and SSAP Octets. Once an adaptor has identified the DSAP/SSAP as 0xAA it knows that a SNAP field is also present in the Data area. And to look at Offset for the EtherType code

Ethernet Type SNAP The SNAP Frame Format consists of a normal Data Link Header followed by a normal LLC Header, and then a 5 byte SNAP field, followed by the normal user data and FCS.

The Sub-Network Access Protocol (SNAP) Header
Offset 18-20: The Vendor Code The first 3 bytes of the SNAP header is the vendor code, generally the same as the first three bytes of the source address, although it is sometimes set to zero.

Offset 21-22: The Local Code Following the Vendor Code is a 2 byte field that typically contains an Ethertype for the frame. Here is where the backwards compatibility with Version II Ethernet is implemented.

Below is an example of how an IEEE802
Below is an example of how an IEEE802.3 Frame identifies that its payload is destined for IP As an example, to indicate that the Data is to be delivered to the TCP/IP internet protocol, IEEE802.3 LSAP values are: DSAP: 170(decimal) or 0xAA(hex) = SNAP SSAP: 170(decimal) or 0xAA(hex) = SNAP Ctrl: 3 = (for unnumbered information) Organ. Code: 0 Type: 2048(decimal), or 0x0800(hex), Xerox assigned protocol number = IP

The Novell Proprietary Frame Type
Novell's Proprietary Frame Format was developed based on a preliminary release of the specification. After Novell released their proprietary format. The IEEE LLC Header was added to the original format,thus making Novell's format incompatible.

Novell's Proprietary Frame Format was developed based on a preliminary release of the specification. After Novell released their proprietary format, the LLC Header was added, making Novell's format incompatible. Note no Type field and no LLC !!

A Final Note on the Novell Ethernet Frame Format "A Novell client can only use one frame format for NetWare" This is a true statement that needs some clarification to be fully understood.

It should be noted that Novell workstations are capable of using any of the four Ethernet frame types mentioned

The format it selects will be based on its initial attempt to locate a server and the type of Format the server responded too.

Layer 1 signal encoding MANCHESTER CODE

Signal Encoding MANCHESTER ENCODING

Signal Encoding The device driver software receives a frame of IP, IPX, NetBIOS, or other higher-layer protocol data. From this data, the device driver constructs a frame, with appropriate Ethernet header information and a frame check sequence at the end.

Signal Encoding The circuitry on the adapter card then takes the frame and converts it into an electrical signal. The voltage transitions in the transmitted bit stream are in accordance to the format called Manchester Signal Encoding.

Signal Encoding Manchester encoding describes how a binary ONE and ZERO are to be represented electrically. Manchester encoding is used in all 10 Megabit per second Ethernets; for example, 10BASE2 Thin Ethernet, 10BASE5 Thick Ethernet, and 10BASE-T

Here, we see an example of the signal transitions used to encode the hexadecimal value "0E", which converts to " " in binary. Notice that there is a consistent transition in the middle of each bit-time.

Sometimes this transition is from low-to-high and sometimes it's from high-to-low. This is the clock transition. The receiving adapter circuitry 'locks on' to this constant signal transition and, thereby, identifies the timing to determine the beginning and end of each bit.

To represent a binary ONE, the first half of the bit-time is a low voltage; the second half of a bit is always the opposite of the first half, that's how the clock transition is created.

To represent a binary ZERO, the first half of the bit-time is a high voltage. You see that sometimes there an additional transition at the beginning of a bit-time (not drawn in the diagram above) where the signal is pulled either up or down in preparation for the next bit.

Consider what happens if an external electromagnetic field interferes with the Manchester bit encoding. This external field could be the result of an electric motor, radio transmission, or other source of interference.

You should be able to see that if the Manchester signal is disrupted the bits will be destroyed - because the clock signal will be disrupted.

It would not be reasonably possible for electrical interference to change a binary ONE into a binary ZERO. Since each bit is symmetrical (second half is always opposite the first half) the result of electrical noise would be the destruction of the bit; not a change in bit value.

Media Access (MAC) Defined by 802.3

Media Access (MAC) CSMA/CD What is CSMA/CD?
Uses Manchester codes on the wire

Media Access (MAC) CSMA/CD stands for Carrier Sense
Multiple Access with Collision Detection. It refers to the means of media access, or deciding "who gets to talk" in an Ethernet network and is defined as a Layer 2 IEEE802.3 ethernet protocol.

Media Access (MAC) Carrier Sense means that before a station will "talk" onto an Ethernet wire, it will listen for the "carrier" that is present when another station is talking. If another station is talking, this station will wait until there is no carrier present.

Media Access (MAC) Multiple Access refers to the fact that when a station is done transmitting it is allowed to immediately make another access to the medium (a 'multiple' access). This is as opposed to a Token-Ring network where a station is required to perform other tasks in-between accessing the medium (like releasing a token or sometimes releasing a management frame).

Media Access (MAC) Collision Detection refers to the ability of an Ethernet adapter to detect the resulting "collision" of electrical signals and react appropriately. In a normally operating Ethernet network, it will sometimes occur that two stations simultaneously detect no carrier and begin to talk. In this case the two electrical signal will interfere with each other and result in a collision; An event which is detected by the Collision Detection circuitry in the transmitting network interface cards.

Runts & Collisions A collision is an event that happens on an Ethernet network when two stations simultaneously "talk" on the wire. Collisions are a normal part of life in an Ethernet network, and under most circumstances should not be considered a problem.

Early Collisions In this discussion, we will refer an imaginary Ethernet network consisting of Stations A and B, and any number of other stations. The status of the network is such that the wire is idle (nobody is talking) and 9.6 microseconds have passed since anybody last talked on the wire

Early Collisions An early collision is any collision that occurs before 512 bits of the frame have been put onto the wire.

Early Collisions The following is an outline of a normal or "early" collision event: Station A, detecting that the wire has been idle for 9.6 microseconds, begins to transmit its data frame, beginning with the 64 bit preamble (8bytes). While Station A is transmitting, it is also listening for abnormal voltages on the wire -- a signal that a collision has occurred.

Early Collisions Some period of time later, but before the signal from Station A has had time to propagate down the wire to Station B, Station B also detects that the wire has been idle for 9.6 microseconds, and begins to transmit its data frame beginning with the 64 bit preamble. Station B is also listening for a collision on the wire.

Early Collisions At some point on the wire in between Station A and Station B, the electrical signals overlap, creating a point of abnormal voltage. As the signals continue to propagate, this abnormal voltage travels down the wire towards both Station A and Station B.

Early Collisions Whichever station is closest to the physical point on the wire where the two signals overlapped will detect the collision first.

Early Collisions Station A, detecting the abnormal voltage on the wire, and realizing that a collision has occurred, immediately stops transmitting data and transmits a 32 bit "jam" onto the wire.

Early Collisions The 32 bit jam consists of any combination of values that is not a valid CRC for the frame that was just interrupted by the collision. Most Ethernet cards today just send 32 ones Knowing that there is only a 1/(2^32) chance that that will be the checksum -- pretty good odds.

Early Collisions The purpose of the 32 bit jam is to fully propagate the wire with voltage, preventing anybody else from talking.

Early Collisions Station A will then implement an algorithm known as the …. Truncated Binary Exponential Backoff Algorithm, which determines how long it will wait before it attempts to retransmit the frame that was just interrupted. The interrupted frame is referred to as a runt.

Early Collisions Next, Station B will detect the collision. Station B will also send a 32 bit jam and implement the Truncated Binary Exponential Backoff Algorithm

Early Collisions Early collisions occur regularly in a normally operating Ethernet network. There is no hardware malfunction or misbehaving station – It typically takes no longer than 2-3 milliseconds for a station to recover from a collision and successfully retransmit its frame. 

Late Collisions Late collisions, on the other hand, are not normal, and are usually the result of out of spec. cabling or a malfunctioning adapter. A late collision is defined as any collision that occurs after 512 bits of the frame have been transmitted. The rationale behind this is discussed next

Late Collisions The following is an outline of a late collision event caused by out of spec. cabling:

Late Collisions Station A, detecting that the wire has been idle for 9.6 microseconds, begins to transmit its data frame Beginning with the 64 bit preamble. Station A transmits 256 bits of its frame. If the cabling were in spec, and Station B began to transmit, causing a collision, even if Stations A and B were on the farthest ends of the wire from each other, the collision would be detected by station A before it could transmit its 512th bit.

Late Collisions

Late Collisions Station A continues to transmit bits, and meanwhile, down at the other end of the wire, just before the electrical signal reaches Station B, Station B detects idle wire for 9.6 microseconds and begins to transmit.

Late Collisions

Late Collisions A minute amount of time later, a collision occurs. Station B, being extremely close to the collision, detects it first, and begins transmitting a 32 bit jam signal.

Late Collisions

Late Collisions The collision begins to propagate down the wire towards Station A, but, because the cabling was out of spec, by the time it gets to Station A, Station A has already finished transmitting, and is no longer listening for collisions! Station A is completely unaware that a collision has occurred!

Late Collisions

Late Collisions Station A finishes transmitting and therefore stops listening for collisions. Because the network length is out of spec, however, the collision event has not yet reached it. Station A is never aware that the collision occurred. When Station A sees the 32 bit jam, it will just think that some other stations collided and ignore it.

Late Collisions The reason that late collisions are a problem is that once the NIC misses the fact that a collision has occurred, recovery and retransmission are left to the upper layers, and recovery time goes up drastically. While a NIC will typically recover and retransmit a frame in 2-3 milliseconds, it typically takes anywhere from 10 to 100 times that long for upper layers.

Late Collisions The other major cause of late collisions is a malfunctioning NIC. If a NIC malfunctions in such a manner that it is unable to detect that another station is talking, late (and early) collisions will occur.

Designing Ethernet systems to avoid Late Collisions

You now know that the minimum frame size in an Ethernet network is 64 bytes or 512 bits, including the 32 bit CRC.

You also know that the maximum length of an Ethernet cable segment is 100 meters for 10BASE-T UTP cabling and 500 meters for 10BASE5 thicknet cabling.

It is, however, a much less well known fact that these two specifications are directly related.

Lets now discuss the relationship between minimum frame size and maximum cable length.

Before we discuss frame size and cable length, an understanding of signal propagation in copper media is necessary.

Electrical signals in a copper wire travel at approximately 2/3 the speed of light. ms-1 This is referred to as the propagation speed of the signal.

Since we know that Ethernet operates at 10Mbps or 10,000,000 bits per second, we can determine that the length of wire that one bit occupies is approximately equal to 20 meters via the following math:

speed of light in a vacuum = 300,000,000 meters/ second speed of electricity in a copper cable = 200,000,000 meters/ second So in 1 sec 1 bit travels m However bits are sent each sec So by division we can work out how much distance each bit goes. (200,000,000 ms-1) / (10,000,000 bits / s) 1bit travels = 20 meters every 1/ th sec

We can further determine that a minimum size Ethernet frame consisting of 64 bytes or 512 bits will occupy 10,240 meters of cable. 512 bits x 20 meters / bit = meters

The Relationship The only time that an Ethernet controller can detect collisions on the wire is when It is in the transmit mode.

The Relationship When an Ethernet NIC has finished transmitting and switches to receive mode, the only thing it listens for is the 64 bit preamble that signals the start of a data frame

The Relationship The minimum frame size in Ethernet is specified such that, based on the speed of propagation of electrical signals in copper media, an Ethernet card is guaranteed to remain in transmit mode, and therefore detecting collisions, long enough for a collision to propagate back to it from the farthest point on the wire from it.

The Relationship Take, for example, a length of 10BASE5 thick Ethernet cabling exactly 500 meters long (the maximum that the spec allows) With two stations, Station A and Station B attached to the farthest ends of it.

The Relationship If Station A begins to transmit, it will have transmitted 25 bits by the time the signal reaches Station B, 500 meters away. 25 bits x 20m per bit = 500m

The Relationship If Station B begins to transmit at the last possible instant before Station A's signal reaches it, the collision will reach Station A 25 bit-times The time it takes for the signal on the wire to travel one bit-length meters in copper cable later. Station A will have transmitted only 50 bits when the collision reaches it -- nowhere near the 512 bit boundary for an early collision.

The Relationship Remember station A has only transmitted 25 bits when the 1st bit reaches 500m ( the end of the segment). The collision now propagates back to the source taking another 25 bit times As such station A has only transmitted a total of 50 bits which is well below the 512 threshold to be an EARLY Collision.

The Relationship Upon closer examination, however, a peculiarity arises. Consider if a normal collision happens just before the 512 bit boundary, Station A would have to be over 5000 meters away from Station B before a late collision occurred! 255 bits x 20m per bit = 5100m

The Relationship That's means 255 bits or 5100 meters for the signal to propagate from Station A to Station B and 5100 meters for the collision event to propagate back to and be detected by Station A. It seems like a late collision would never occur with a maximum cable length of only 500 meters. 

The Relationship The reason for the overhead is twofold.
First of all, while the maximum possible cable segment length in 10base5 Ethernet is 500 meters, it is possible to extend that length with up to 4 repeaters before the IEEE spec is violated. This means that the signal may have to travel through as much as 2500 meters of cable to reach Station B, or 5000 meters of cable round trip.

The Relationship The second and final reason for the overhead lies solely in the carefulness of Ethernet's inventors. Generally, the spec is twice as strict as it needs to be, allowing ample room for errors.

The Relationship Herein lies one of the greatest strengths and weaknesses of Ethernet. It is a strength in that if you need to, you can probably get away with violating the specs -- an extra length of cable here, an extra repeater there, and your network continues to run normally.

The Relationship It is a weakness in that while you can get away with violating the specs, there is a very fine line between a network that is violating the specs and is running, and a network that is violating the specs and is crippled by late collisions, and you never know which extra bit of wire or extra repeater is going to cross the line.

The Relationship Despite this dire warning, there are some general rules for violating specs:

The Relationship If your vendor tells you that you can violate the spec, and you're not mixing vendors, it's probably ok. If you mix vendors, obey the most strict of the vendors. If something is wrong with your network, and you know that it violates the spec in places, those places should be the first ones you check. Try segmenting the network with a bridge and see which side of the bridge the problems are on.

Designing Ethernet cabling to avoid Late collisions using Path Delay Values.

Calculating the Worst case Path Delay Value

Calculating the Worst-Case Delay for the Sample Network
To start with, we set out the segments in our maximum delay path as Left end, Middle, and Right end segments. Let's begin by assuming that the thin Ethernet segment that DTE1 is attached to is the left end segment.

That leaves us with three middle segments composed of a 10BASE5 segment and two link segments, and a right end segment which is a 10BASE-T link segment

Next, we begin the calculations with the left end, using the 185 meter 10BASE2 thin Ethernet segment. We could calculate the segment delay value by adding the left end base (11.75) to the product of the round trip delay times the length (185 * = ) to come up with a value of

Since 185 meters is the maximum segment length allowed for 10BASE2 segments, we could be lazy and simply look up the max left hand segment value in the table, which, not surprisingly, is also

The segment delay values provided in the table include allowances for an AUI cable of up to two meters length at each end of the segment, except for 10BASE-FB segments which connect directly to special repeater hubs and never use AUI cables. An AUI cable attaches the Repeaters to the segments

If you're not sure how long the AUI cables are you may wish to use the maximum delay shown for an AUI cable, which is 4.88 for all segment locations, left end, middle, or right end.

Let's continue by making the calculations for the middle segments.

In Figure 1 there are three mid-segments composed of a maximum length 10BASE5 segment, and two 500 meter long 10base-FL segments. By looking in the table under mid-segments we find that the 10BASE5 segment has a max delay value of 89.8

Let's add in the delay for two AUI cables to allow for two maximum-length AUI cables in the segment, one at each connection to a repeater. That gives us an AUI cable delay of 9.76 to add to the total path delay.

We can calculate the segment delay value for the 10BASE-FL mid-segments by multiplying the 500 meter length of each segment times the RT Delay/meter, which is 0.1, which gives us a result of 50. We then add 50 to the mid-segment base value for a 10BASE-FL segment, which is 33.5, for a total of 83.5

Finally, we have a right end segment of 10BASE-T twisted-pair Ethernet, which is the maximum length of 100 meters. The max value for 10BASE-T right end segment is Adding all the bit time values together we get the following:

Finally, the standard recommends adding a margin of up to five bit times to form the total path delay value. We are allowed to add anywhere from zero to five bits margin, but five bit times is recommended. Adding five bit times for margin brings us up to which is less than the maximum of 575 bit times. (511+64)

Therefore, our sample network is qualified in terms of the worst-case delay. All shorter paths will have smaller delay values, so all paths in the Ethernet system shown in Figure 1 meet the requirements of the standard as far as path delay value is concerned.

Ethernet Frame Types and Ethernet Design

Similar presentations

Presentation on theme: "Ethernet Frame Types and Ethernet Design"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Ethernet Frame Types and Ethernet Design

Similar presentations

Presentation on theme: "Ethernet Frame Types and Ethernet Design"— Presentation transcript:

Similar presentations

About project

Feedback