Understanding Layer 2, 3, and 4 Protocols: The OSI Seven Layer Model-What A Layer?
Understanding Layer 2, 3, and 4 Protocols: The OSI Seven Layer Model-What A Layer?
Understanding Layer 2, 3, and 4 Protocols: The OSI Seven Layer Model-What A Layer?
Understanding Layer 2,
3, and 4 Protocols
While many of the concepts well known to traditional Layer 2 and Layer 3 net-
working still hold true in content switching applications, the area introduces
new and more complex themes that need to be well understood for any success-
ful implementation. Within the discussion of content networking, we will
replace terms such as packets and frames with sessions and transactions as we move
our attention further up the OSI Seven Layer Model. Before we move into
these new terms, however, let’s look at some standard Layer 2, 3, and 4 network-
ing concepts.
13
14 Chapter 2 ● UNDERSTANDING LAYER 2, 3, AND 4 PROTOCOLS
network types, such as Ethernet, Frame Relay, and ATM. Figure 2–1 shows the
OSI Seven Layer Model.
When we talk about Layer 2 and Layer 3 networking, it is these layers that
we’re referring to, and logically the further up the OSI model we move, the
greater intelligence we can use in networking decisions.
Each layer plays its part in moving data from one device to another across a net-
work infrastructure by providing a standard interface to the surrounding layers.
7 Application Layer
6 Presentation Layer
5 Session Layer
4 Transport Layer
3 Network Layer
2 Data Link Layer
1 Physical Layer
GET / HTTP/1.0\r\n
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg\r\n
Accept-Language: en-gb\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)\r\n
Host: www.foocorp.com\r\n
Connection: Keep-Alive\r\n
\r\n
Once this application information has been generated, it can be packaged and
passed on to the next layer for transport. HTTP requires a connection-oriented
Transport layer protocol to guarantee the delivery of each packet in the session.
Transmission Control Protocol (TCP) is used in HTTP applications to ensure
this successful packet delivery. Other applications will make use of different
Transport layer protocols. TFTP, for example, uses the User Datagram Protocol
(UDP) as its Layer 4 transport because it does not require the guaranteed deliv-
ery provided by TCP. Routing updates sent between Layer 3 devices can use
OSPF, RIP, or BGP as their Layer 4 transport.
At the Transport layer, information about the port numbers, sequence num-
bers, and checksums are included to provide reliable transport. The Layer 4
headers in our example would look something like:
Transmission Control Protocol
Source port: 3347 (3347)
Destination port: http (80)
Sequence number: 52818332
Next sequence number: 52818709
Acknowledgement number: 3364222344
18 Chapter 2 ● UNDERSTANDING LAYER 2, 3, AND 4 PROTOCOLS
User http://www.foocorp.com/
Application,
Presentation, and
Session Layers
Layer 4
Headers
Layer 3
Headers
Layer 2
Headers
...11001001001001101010101011010101000010010011010100011010010101...
Layer 2 Switching
The first implementation of Ethernet or Layer 2 switching uses information in
the Ethernet headers to make traffic forwarding decisions. Intelligent switches
learn which ports have which end stations attached by recording the Ethernet
MAC addresses of packets ingressing the switch. Using this information along
with the ability to parse the Layer 2 headers of all packets means that a Layer 2
switch need only forward frames out of ports where it knows the end station to
be. For end station addresses that have not yet been learned, frames with
unknown destination MAC addresses are flooded out of every port in the switch
to force the recipient to reply. This will allow the switch to learn the relevant
MAC address, as it will be the source address on the reply frame.
Layer 2 switching is implemented along side Layer 3 routing for local area
networks to facilitate communication between devices in a common IP subnet.
As the information at this layer is relatively limited, the opportunity to configure
Layer 2 switches to interpret address information and act upon it in any way
other than described previously is generally not required. Many Layer 2 switches
will offer the ability to configure intelligent services such as Quality of Service
(QoS), bandwidth shaping, or VLAN membership based on the Layer 2 infor-
mation. Figure 2–3 shows a simplified Layer 2 frame with examples of informa-
tion that might be used to make switching decisions.
Many of the early implementers and pioneers of Layer 3 routing devices used
software-based devices as platforms that, while offering a flexible platform for
development of the technology, often provided limitations in terms of perfor-
mance. As Layer 2 switching became more commonplace and the price per port
of Ethernet switching systems dropped, manufacturers looked to combine the
performance of ASIC-based Layer 2 switching with the functionality and flexi-
bility of Layer 3 routing. Step forward the Layer 3 switch. Layer 3 switches
work by examining the destination IP address and making a forwarding decision
based on the routing configuration implemented. The destination subnet might
be learned via a connected interface, a static route, or a dynamic routing protocol
such as RIP, OSPF, or BGP. In all instances, once the Layer 3 switch has exam-
ined the frame and compared the destination IP address against the information
in its routing database, the destination MAC address is changed and the frame
is forwarded through the relevant egress port. For IP frames traversing a Layer 3
device, such as a router or Layer 3 switch, the TTL field in the IP header is also
decremented to indicate to end stations and intermediaries that a routing hop
has occurred.
It is once we reach the Layer 3 switching environment that configuration for
devices become inherently more complex. The administrator must configure the
correct routing information to enable basic traffic flow along with the interface
IP addresses in each of the subnets to which the Layer 3 switch is attached.
Figure 2–4 shows the typical information used by a Layer 3 switch in making
a forwarding decision.
IGMP, and IP itself can all be identified by a unique protocol number in the IP
header (see Figure 2–5).
The list of IP protocol numbers is administered and controlled by the Inter-
net Assigned Numbers Authority (IANA), and a comprehensive list can be
found at www.iana.org/. Table 2–1 lists some of the more common IP protocol
numbers.
Table 2–1 Some Examples of Common IP Protocol Numbers
Some Layer 4 protocols effectively operate at this layer alone. VRRP, for
example, uses Layer 4 headers to transport all information between a series of
participating routers in an IP subnet and consequently has no need for upper
layer protocol information. Its payload is simply the information contained at
Layer 4. Other routing protocols, such as the Border Gateway Protocol (BGP),
will use the reliable Layer 4 Transport layer protocol with the BGP routing
information and updates carried in the upper layer payloads.
In terms of content switching, the two most commonly understood Layer 4
protocols are TCP and UDP. The majority of the standard Application layer
protocols are carried either within TCP or UDP depending on whether there is
a requirement for a reliable end-to-end connection. Taking a Web user example,
the browser application needs to ensure that all packets are successfully delivered
when presenting the user with the desired Web page. The HTTP protocol will
1 = ICMP
6 = TCP
17 = UDP
Figure 2–5 Different IP protocol numbers identify which Layer 4 protocol is being used.
T ra n sp o rt C o n tro l P ro to c o l ( T C P ) 23
This combination of source and destination ports, along with the Layer 3 IP
addressing, gives TCP the ability to uniquely identify each conversation or ses-
sion within an internetwork, even in the case of the Internet itself.
1. Initiating a Session
Before initiating the session, there are two pieces of information upon which the
client must decide. First, in order to identify the session uniquely between itself
and the server, it selects a TCP port number to represent the session. This port
will be the source port for packets from the client to the server and the destina-
tion port for packets from the server to the client. The client will select the
source port sequentially on a connection-by-connection basis starting from a
value greater than 1024. Port numbers below 1024 are typically referred to as
well-known ports and are used to identify well-known applications. Table 2–2
shows some well-known reserved ports as defined by IANA.
Table 2–2 Some Well-Known TCP Port Number Assignments
The second element that needs to be decided by the client is the starting
sequence number. This will be selected based on an internal 32-bit clock that
ensures both randomness and that sequence numbers will not overlap should a
lost packet reappear some time after its original transmission. Just as with the
T ra n sp o rt C o n tro l P ro to c o l ( T C P ) 25
TCP ports used by both the client and server, each side also uses its own
sequence numbering to identify where within the session each frame fits.
Once the client has determined these two variables, it is ready to send the first
packet of the session and initiate the connection to the server. Using TCP flags,
the client will indicate to the server that it wants to initiate a connection by set-
ting the SYN or synchronize flag showing that this is the first pack in the ses-
sion. In TCP terms, this element is the first packet in what is commonly
referred to as the “three-way handshake.” This is simply because three packets
are exchanged between the client and server to bring the TCP state into that
which can transport data. Consequently, no Application layer data is transmit-
ted until at least the fourth packet in the session, a concept which we will see has
an important consequence when applied to content switching. Figure 2–6 shows
a simplified representation of the three-way handshake to illustrate which side
sends which of the packets when a new connection is initiated.
Taking this sequence packet by packet, we can see the importance of the port and
sequence numbers in ensuring the reliable transport between the client and server.
The first frame from the client to the server initiates the connection by setting the
client side port and sequence numbers as shown in Figure 2–7. As we can see,
the client chooses a random source port that will be used by the client to identify
this session uniquely in cases where it has concurrent sessions to the same server.
Server
Client Initiating a TCP Connection to the Server
User
SYN, S
Port 30
8 6, Dpo
rt 80, S
eq 713
245119
, Ack 0
120
713245
q 200 72, Ack
0 86, Se
DPort 3
ort 80,
CK, SP
SYN-A
ACK, S
Port 30
86, Dpo
rt 80, S
eq 713
245120
, Ack 2
0073
When the server replies, both the SYN and ACK flags are set in the TCP
headers to indicate that the server acknowledges the client’s connection request.
To ensure that each packet can be accounted for, the server will set an acknowl-
edgment number that is equal to the last byte received from the client, relative to
the starting sequence number, plus one. In our example, the client started with a
sequence number of 713245119 and transmitted no user data, meaning that the
server will use an acknowledgment of 713245120.
It is also important to notice the change in source and destination ports
depending on which way a particular packet is directed. In our example, the cli-
ent sends on port 80 and listens on port 3086, whereas the server sends on port
3086 and listens on port 80. Figure 2–8 shows the return packet from the server
to the client.
The final packet exchanged during this handshake period is an acknowledg-
ment from the client to the server. This allows the client to correctly acknowl-
edge the sequence numbering used by the server in the previous packet and
remove the SYN flag being used to show the start of the session. Once this final
T ra n sp o rt C o n tro l P ro to c o l ( T C P ) 27
packet of the handshake has been received, both sides of the connection can
move into the established state, indicating that the transfer of user or application
data can now commence. Figure 2–9 shows this final packet of the handshake.
Note that in our example, the client has changed the acknowledgment number-
ing to match that initiated by the server and has also removed the SYN flag in
the TCP header.
2. Data Transfer
Once the connection has moved into the established state, data transmission can
begin between the two end points. During this state, the ACK flag is always set
and the two end stations use the sequence and acknowledgment numbering to
track the successful delivery of each segment of data. TCP also employs a num-
ber of windowing and buffering techniques to ensure the optimal delivery,
retransmission, and buffering of data during this state. The discussions of such
techniques are outside of the scope of this book.
28 Chapter 2 ● UNDERSTANDING LAYER 2, 3, AND 4 PROTOCOLS
3. Terminating a Session
Unlike the session initiation, the termination of a TCP connection can be initi-
ated from either side. Once one side of the connection decides that it has no
more data to transmit, it will set the FIN flag in the TCP header to indicate to
the other side that it is ready to terminate the connection. In simple terms, the
receiving station will then acknowledge the FIN, by setting the ACK flag, and
set its own FIN flag to show that it too is ready to terminate the connection.
This series of exchanges results in both sides moving through the TIME WAIT
state to the CLOSED state and the connection is closed.
In some instances, when the client receives the FIN it might still have data to
send, in which case it will issue only an ACK back to the closing station. This
allows the client to continue sending data until it is complete and then issue a
FIN to show that the termination of the session can commence. During this
period, the initiator and recipient of the initial FIN are referred to as being in
the FIN WAIT 2 and CLOSE WAIT states, respectively. Some applications, such
U se r D a ta g ra m P ro to c o l ( U D P ) 29
as Web browsers, will often use this type of exchange to leave the connection in
a type of half-closed state, thereby allowing the connection to be brought back
into use when needed without having to reinitiate the entire connection (see
Figure 2–10).
A more detailed description of TCP can be found in RFC 793.
Server
Server terminating TCP session with client
User
462
713245
q 202 31, Ack
086, Se
DPort 3
ort 80,
FIN, SP
FIN, SP
ort 308
6, Dpo
rt 80, S
eq 713
245462
, Ack 2
0232
2 45463
ck 713
eq 20072, A
Dport 3086, S
,
Port 80
ACK, S
whereby you write a message and send it without receiving any acknowledgment
of its delivery from anything other than a local call access point.
UDP does share some common characteristics with TCP, as it does imple-
ment source and destination ports, to identify application sockets, and a
checksum to verify the correct delivery of the layer 4 datagram.
The Request
The first thing you will notice in Figure 2–11 is that the structure of the UDP
header is far simpler than that used by TCP. There are only four fields used
within the UDP header, to indicate the source and destination ports, the header
length, and the checksum. It is clear from this that many of the techniques used
by TCP are simply not present in UDP, such as sequencing, handshaking, and
flow control.
The Response
As DNS is a bidirectional, request-response application, the frame shown in
Figure 2–11 will yield an answer from the DNS server, also carried using
UDP. Figure 2–12 shows the response. Note that the source and destination
ports are reversed as with TCP, as the client sending the request will be listen-
ing and expecting an answer on port 1763.
V i rtu a l R o u te r R e d u n d a n c y P ro to c o l ( V R R P ) 31
This is again a very brief overview of the UDP protocol. A more detailed
description is available in RFC 768, available on the IETF Web site.
Internet Internet
R1 R2 R2
10.10.10.2 (10.10.10.2) 10.10.10.2 R2 replaces R1 with
the same IP address
Layer 2 switch Layer 2 switch
User has default
gateway of Where did the MAC
10.10.10.2 and address go ?!?!
resolves the MAC
User User
address to R1
It is for these reasons that we need VRRP to provide resilience at both Layer
2, by providing a virtual MAC address, and at Layer 3, by providing a virtual IP
address. This virtualization of addresses amongst two or more physical units
means that the client or client router will always have a default gateway both in
terms of MAC address and IP address.
address. VRRP advertisements are always sent using the primary IP address
as the source of the IP packet.
• Virtual router master: The VRRP router that is assuming the responsi-
bility of forwarding packets sent to the IP address(es) associated with the
virtual router, and answering ARP requests for these IP addresses. Note
that if the IP address owner is available, it will always become the master.
• Virtual router backup: The set of VRRP routers available to assume for-
warding responsibility for a virtual router should the current master fail.
• VRID: Configured item in the range 1–255 (decimal). There is no default.
• Priority: Priority value to be used by this VRRP router in master elec-
tion for this virtual router. The value of 255 (decimal) is reserved for the
router that owns the IP addresses associated with the virtual router. The
value of 0 (zero) is reserved for the master router to indicate that it is
releasing responsibility for the virtual router. The range 1–254 (decimal)
is available for VRRP routers backing up the virtual router. The default
value is 100 (decimal).
VRRP Addressing
Let’s take our previous example and expand it now to include VRRP on the two
routers, R1 and R2. Assuming that router R1 is configured with the IP address
that matches the proposed VRRP address, it will become the VRRP master and
VRRP owner. Router R2 will become the VRRP backup.
Internet
Virtual Router Master
Virtual Router Owner Virtual Router Backup
VRRP
R1 10.10.10.1 R2
00:00:5E:00:01:0A
10.10.10.1 10.10.10.2
User
VRRP Operation
Now that we have all of the component parts in place, let’s look at how the rout-
ers operate together to provide a resilient pair. VRRP uses advertisement mes-
sages between all participating routers to indicate the health and availability of
the current virtual router master. These messages are exchanged using a com-
mon multicast destination address of 224.0.0.18, and it is to this address that the
current master router will continually advertise to indicate that it is still opera-
tional on the network.
In our example topology, during normal operation, router R1 will continually
advertise the virtual router ID, the virtual router address, and its priority inside
the multicast frame. The source IP address on these advertisements will be the
interface on router R1 along with a source MAC address of the virtual MAC
address we calculated earlier. The use of this virtual MAC address in these
advertisements allows any Layer 2 infrastructure surrounding the VRRP rout-
ers—typically Layer 2 switches—to source learn where the common MAC
address is currently located.
Now for the interesting part, a router failure. Let’s imagine that router R1
experiences a power failure and effectively disappears from the network. In this
instance, the following series of events would occur:
1. The master router, R1, would cease sending multicast packets advertis-
ing the virtual router.
2. After several missed packets, the standby router, R2, will acknowledge
this occurrence by commencing with its own multicast advertisements.
36 Chapter 2 ● UNDERSTANDING LAYER 2, 3, AND 4 PROTOCOLS
When it does, it will use a source MAC address of the VRRP virtual
MAC address, thus informing the attached Layer 2 switch that the MAC
address has moved ports.
3. Since the virtual IP address and associated virtual MAC address have
now survived the failure of router R1, the client will notice only minimal
disruption during the re-election. This period is dependent on the con-
figurable parameters associated with the advertisement intervals, but
should typically be no more than 2 to 3 seconds.
VRRP, or variations on it, is commonly implemented in many content
switching platforms, and as such it forms an important part of any implementa-
tion. More information about VRRP can be found in RFC 2338.
Summary
Many books have been written on the TCP/IP protocol stack and the higher
layer applications such as HTTP and FTP that it supports. While it is outside
the scope of this book to cover all the details and caveats, this chapter provided
sufficient overview of the workings most relevant to content switching. Under-
standing the concept of a user session—being the total user experience of inter-
acting over a period of time with a resource—and how that maps down the OSI
seven-layer model and into the frames, packets, and TCP sessions below is key
to understanding and successfully deploying content switching. In Chapter 3,
Understanding Application Layer Protocols, we’ll look at some of the Application
layer protocols common to content switching.