pete > courses > CS 431 Spring 25 > Lecture 04: Link Layer II – Ethernet
Lecture 04: Link Layer II – Ethernet
Goals
- explain the meaning and purpose of the fields of the Ethernet header
- define collision and collision domain
- explain the purpose and behavior of binary exponential backoff
- compare and contrast the behavior of hubs and switches
| last time, we started looking at the link layer (also known as "Layer 2") |
| recall that the link layer is built on top of the physical layer |
| the physical layer lets us transmit and receive bits |
| the link layer organizes sequences of bits into units of communication called frames |
| a frame is a chunk of octets (8-bit values) that is sent from one host to another |
we looked at a very simple link-layer protocol, the Point-to-Point Protocol (PPP) by examining some of the RFCs that define it (1661 and 1662)
while we won’t interact with PPP directly in this course, we did see some aspects of it that show up in other protocols we will be looking at more closely:
- we got an initial glimpse at an RFC and its patterns
- we saw how encapsulation is achieved: a section of the frame is set aside for the payload ("opaque data") and a field in the headers indicates the type of that data
- when a frame is received and integrity checks (such as FCS) fail, the frame is silently discarded
before we get into Ethernet, I want to show a diagram that we will expand on over the coming weeks, but is useful in thinking about how all the various layers fit together
| ^
v |
+----------------+ +----------------+
| Link Layer | | Link Layer |
+----------------+ +----------------+
| ^
v |
+----------------+ +----------------+
| Physical Layer | -------> | Physical Layer |
+----------------+ +----------------+
Host 1 Host 2
if we want to send data from Host 1 to Host 2, we submit that data to the link layer implementation, which does some stuff (more detail coming soon)
and then passes it to the physical layer implementation, which does other stuff (like converting bits to electrical impulses) and sends it over the communication medium
which the physical layer implementation on Host 2 receives, converts from electrical impulses to bits, and passes it up to the link layer implementation
which then does stuff (again, more detail soon) and then passes it up to the software
because of separation of concerns, however, there is another way we can think about that diagram
since all the manipulations performed by the physical layer on Host 1 are reversed by the physical layer on Host 2, the data that is passed up to the link layer implementation on Host 2 is identical to the data that the link layer implementation on Host 1 passed down to its physical layer
therefore, if we imagine ourselves as the link layer implementation on Host 1 and blindly trust that the underlying physical layer Just Works (tm), then conceptually we are just sending a frame to the link layer implementation on Host 2
and (again, conceptually) the diagram above squishes down to this:
+----------------+ +----------------+
| Link Layer | -------> | Link Layer |
+----------------+ +----------------+
Host 1 Host 2
being able to simplify the situation like this in our minds is one of the key benefits of separation of concerns
that said, there are certainly times where it is important to keep the underlying layers in mind (examples soon)
thinking back to the processes/kernel/hardware diagram from the first day…
the physical layer stuff definitely happens in the "Hardware" box: by definition it is physically connected to the communication medium
and indeed, the vast majority of physical layer implementations are entirely implemented in hardware
the link layer implementation, on the other hand, straddles the kernel/hardware boundary
some of its functionality will exist in the NIC, some of it will exist in the kernel
and indeed we can move this boundary around a bit even while the computer is running (example in a bit)
PPP was a very simple protocol for a very simple circumstance: two hosts connected by a single cable
a PPP frame contains an octet that signifies the beginning of the frame, an octet (always set to 0xff) that signifies the recipient, an octet (always set to 0x03) that specifies control information, one or two octets that specify the kind of data contained within, followed by the data itself, and then a two-octet or four-octet frame check sequence to (weakly) verify the integrity of the preceding bits
our next link-layer protocol is Ethernet, which supports many hosts attached to the same cable
starting with PPP as a basis, though, there are lots of issues when we consider more than two hosts on the same wire
- how does the sender identify the intended recipient of the frame?
- how does the recipient identify the sender?
- what if multiple hosts try to send at the same time?
- what if one host tries to send ALL the time? how can the medium be reasonably shared?
(this last question seems to suggest that Ethernet is half-duplex; to begin with, we will assume this is the case, and we’ll return to the question later)
before we get into the technical details, some history about Ethernet
it was developed in the early 70s at Xerox PARC ("Palo Alto Research Center")
it preceded the conception of the OSI model, which partially explains why its specification includes stuff we would today attribute to both the physical layer and the link layer
(the other part of the explanation is that, by their very natures, physical and link layers must often be considered together, blurring the boundary between them: examples to come soon)
Ethernet was inspired in some ways by ALOHAnet, which was developed to facilitate communication between the Hawaiian Islands, a topology different to pretty much any other place in the US
and indeed much (if not the vast majority) of the development of the ideas of networking in that era happened in the US
in the early 80s, three companies got together and codified a standard for Ethernet: Digital Equipment Corporation (DEC), Intel, and Xerox
these days, you probably haven’t even heard of DEC; you’ve only heard of Xerox in the context of photocopiers; and Intel is the only one of those names that is recognizably computer-related
that said, really significant developments came out of both DEC and Xerox in the 60s-90s
in any event, the standard they produced is known as the "DIX" standard, using the first letter of each company name
the IEEE also developed a standard for Ethernet, with very minor differences, and called it "802.3"
in practice, the DIX standard is followed more often, so that is what we will look at
frames that follow the DIX standard are usually called "Ethernet II" frames
the DIX standard is available here
let us begin by looking at how Ethernet frames are arranged, because that will answer some of the questions above and raise others
on page 39 of the pdf above (though it has "page 27" printed on it) we see the illustrative diagram
reproduced here in ASCII art:
+---------------+ | | | Destination | 6 octets | | | | | | | | +---------------+ | | | Source | 6 octets | | | | | | | | +---------------+ | Type | 2 octets | | +---------------+ | | | | . Data . 46-1500 octets . . . . | | | | +---------------+ | | | Frame Check | 4 octets | Sequence | | | +---------------+
as the diagram also indicates, bits within an octet are transmitted starting with the least-significant bit
most of these fields are directly comparable to the PPP frame we saw last time
"Destination" identifies the intended recipient: it is equivalent to the "Address" field of the PPP frame
"Source" identifies the sender; it has no equivalent in the PPP frame
"Type" identifies the kind of data being transmitted: it is equivalent to the "Protocol" field of the PPP frame
"Data" is the… data being transmitted: it is equivalent to the "Information" field in the PPP frame
"Frame Check Sequence" is identical to PPP’s usage
one other important thing about Ethernet is the term station, which is effectively equivalent to host: it is the machine to which the interface is attached
the existence of Destination and Source fields answers a couple of our questions above: both recipient and sender are identified by 6-octet (48-bit) addresses
(and yes, they are called "addresses" in the context of Ethernet, too, even though that word doesn’t show up in the diagram above)
the (correct) implication is that every interface (NIC) connected to the wire has an address associated with it, that the sender will include its address in frames that it sends, and that the sender will know the address of the intended recipient of any given frame
a related assumption is that addresses are globally unique: there do not exist two NICs with the same address
how does an interface get an address in the first place? and how can we be sure the address is unique?
answer: the IEEE manages the Ethernet address space and companies have to purchase 24-bit prefixes from them, which permits them to manufacture NICs whose addresses begin with that prefix
example: let’s say you want to manufacture NICs
you go to the IEEE, pay their fee, and they grant you the privilege to manufacture NICs whose addresses begin with 42:93:AB
Ethernet addresses are usually written as 6 pairs of hex digits separated by colons
so you are now entitled to manufacture NICs with addresses in the range 42:93:AB:00:00:00 through 42:93:AB:FF:FF:FF
no, I don’t know what the fee is
no, I don’t know if it’s enforced (I kinda doubt it)
yes, it is possible to change your NIC’s address via software—this is known as spoofing
in fact, lots of Apple devices in particular spoof their Ethernet address by design to make tracking more difficult
the Ethernet address is sometimes also referred to as hardware address or a MAC address
hardware address because it’s the address associated with the NIC, which is a piece of hardware
MAC standards for Media Access Control, which makes sense because the NIC controls access to the communication medium
in practice, you will probably hear the term "MAC address" more often than either of the other two
but be careful: other link-layer technologies also use addresses, which are often also called MAC addresses, and which often look very similar to Ethernet addresses
(wifi is the most significant example here: it also uses 48-bit hardware addresses, they are formatted the same as Ethernet addresses, and they are often referred to as MAC addresses)
one thing the Ethernet frame diagram above does not show is anything like PPP’s "Flag" field that indicates the beginning and end of frames
so how does it know?
helpfully, the "beginning of frame" marker is discussed starting at the bottom of page 90 of the pdf
here, it is called the preamble
it is this 64-bit sequence:
10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011
equivalently, in hex:
AA AA AA AA AA AA AA AB
immediately after the final bit of the preamble comes the first bit of the frame itself (specifically, the first bit of the destination address)
how about the end?
this is a bit more subtle, because it colludes with the physical layer
as long as a station is sending bits on the wire, it also includes on the wire a carrier signal, which doesn’t represent actual bits, is sent simultaneous with the bits of the data, and makes it clear to anybody listening that somebody is sending bits
when the sender is done sending, it stops the carrier signal, at which point all other stations know the frame is done
there is also a mandated inter-frame delay, in which no station sends, so that stations unequivocally know that a frame has completed
you know how I said that there were actually two standards for Ethernet: DIX (Ethernet II) and 802.3?
the main difference (on the wire) is that the 802.3 frame includes an explicit length field, whereas the Ethernet II frame does not, and uses the carrier signal solution described above
and in fact the length field of the 802.3 frame occupies the same bits as the type field of the Ethernet II frame
this presents some complications, but since Ethernet II is the much more popular style, we won’t get into them
I just wanted to point out that a very similar protocol does have an explicit length field
speaking of length, recall that the Ethernet frame has a maximum size: 1500 bytes of data plus 18 bytes of metadata
this is known as the maximum transmission unit (MTU), and a similar notion exists in most link layer protocols
in a way, it helps solve one of the other problems posed at the beginning: by having a maximum frame size, it makes it less easy for a single station to monopolize the communication medium
the carrier signal described above also solves part of another question we posed: it helps to prevent multiple stations from sending at the same time
if the link layer implementation on Host X is handed data to send out, it will first wait until the carrier signal is absent until trying to send
except this isn’t perfect, mostly because of the speed of light
that is, because it takes time for the carrier signal to travel over the wire, two stations could both believe the wire isn’t being used and simultaneously decide to send a frame
the result is a collision, the effect of which is that both frames fail to send successfully
but we want both frames to (eventually) send successfully, so what do we do?
the solution is a technique called binary exponential backoff
every station that sent a frame resulting in a collision will pick a number at random between 0 and 1, wait that amount of time, and then try to send the frame again
if it sends successfully, great
if another collision happens, it will then pick a number at random between 0 and 3, wait that amount of time, and try to send again
it will keep doing this, doubling the size of the random-number range each time until it succeeds
if it fails to send after the 10th attempt, it gives up and returns an error to the upper layer
to tie this back to the name, we are delaying (backing off) by multiplying (exponential) our maximum wait time by 2 (binary) with each failure
related to the collisions is the notion of a collision domain
this is the set of all stations with whose frames one might collide
ie, all stations attached to the same wire
and, by the way, yes, literally attached to the same wire
