Transcript data-link layer

Introduction
Basic Networking Concepts
Computer
Networking: A Top
Down Approach
Davide Pesavento
[email protected]
6th edition
Jim Kurose, Keith Ross
Addison-Wesley
March 2012
Transport Layer
Internet transport-layer protocols

reliable, in-order
delivery (TCP)
 congestion control
 flow control
 connection setup

unreliable, unordered
delivery: UDP
 no-frills extension of
“best-effort” IP

services not available:
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
 delay guarantees
 bandwidth guarantees
3-2
UDP: User Datagram Protocol [RFC 768]



“no frills,” “bare bones”
Internet transport
protocol
“best effort” service,
UDP segments may be:
 lost
 delivered out-of-order
to app
connectionless:
 no handshaking
between UDP sender,
receiver
 each UDP segment
handled independently
of others

UDP use:
 streaming multimedia
apps (loss tolerant, rate
sensitive)
 DNS
 SNMP

reliable transfer over
UDP:
 add reliability at
application layer
 application-specific error
recovery!
3-3
UDP: segment header
32 bits
source port #
dest port #
length
checksum
application
data
(payload)
length, in bytes of
UDP segment,
including header
why is there a UDP?



UDP segment format

no connection
establishment (which can
add delay)
simple: no connection
state at sender, receiver
small header size
no congestion control:
UDP can blast away as
fast as desired
3-4
TCP: Overview

RFCs: 793,1122,1323, 2018, 2581
point-to-point:

 one sender, one receiver


 bi-directional data flow
in same connection
 MSS: maximum segment
size
reliable, in-order byte
steam:
 no “message
boundaries”

connection-oriented:
 handshaking (exchange
of control msgs) inits
sender, receiver state
before data exchange
pipelined:
 TCP congestion and
flow control set window
size
full duplex data:

flow controlled:
 sender will not
overwhelm receiver
3-5
TCP segment structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
source port #
dest port #
sequence number
acknowledgement number
head not
UAP R S F
len used
checksum
counting
by bytes
of data
(not segments!)
receive window
Urg data pointer
options (variable length)
# bytes
rcvr willing
to accept
application
data
(variable length)
3-6
TCP seq. numbers, ACKs
sequence numbers:
byte stream “number” of
first byte in segment’s
data
acknowledgements:
seq # of next byte
expected from other side
cumulative ACK
Q: how receiver handles
out-of-order segments
A: TCP spec doesn’t say,
- up to implementor
outgoing segment from sender
source port #
dest port #
sequence number
acknowledgement number
rwnd
checksum
urg pointer
window size
N
sender sequence number space
sent
ACKed
sent, not- usable not
yet ACKed but not usable
yet sent
(“inflight”)
incoming segment to sender
source port #
dest port #
sequence number
acknowledgement number
rwnd
A
checksum
urg pointer
3-7
TCP seq. numbers, ACKs
Host B
Host A
User
types
‘C’
host ACKs
receipt
of echoed
‘C’
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
Seq=43, ACK=80
simple telnet scenario
3-8
TCP reliable data transfer

TCP creates rdt service
on top of IP’s unreliable
service
 pipelined segments
 cumulative acks
 single retransmission
timer

retransmissions
triggered by:
let’s initially consider
simplified TCP sender:
 ignore duplicate acks
 ignore flow control,
congestion control
 timeout events
 duplicate acks
3-9
TCP sender events:
data rcvd from app:
 create segment with
seq #
 seq # is byte-stream
number of first data
byte in segment
 start timer if not
already running
 think of timer as for
oldest unacked
segment
 expiration interval:
TimeOutInterval
timeout:
 retransmit segment
that caused timeout
 restart timer
ack rcvd:
 if ack acknowledges
previously unacked
segments
 update what is known
to be ACKed
 start timer if there are
still unacked segments
3-10
TCP: retransmission scenarios
Host B
Host A
Host B
Host A
SendBase=92
X
ACK=100
Seq=92, 8 bytes of data
timeout
timeout
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data
ACK=100
ACK=120
Seq=92, 8 bytes of data
SendBase=100
ACK=100
Seq=92, 8
bytes of data
SendBase=120
ACK=120
SendBase=120
lost ACK scenario
premature timeout
3-11
TCP: retransmission scenarios
Host B
Host A
Seq=92, 8 bytes of data
timeout
Seq=100, 20 bytes of data
X
ACK=100
ACK=120
Seq=120, 15 bytes of data
cumulative ACK
3-12
TCP ACK generation
[RFC 1122, RFC 2581]
event at receiver
TCP receiver action
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
arrival of in-order segment with
expected seq #. One other
segment has ACK pending
immediately send single cumulative
ACK, ACKing both in-order segments
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
immediately send duplicate ACK,
indicating seq. # of next expected byte
arrival of segment that
partially or completely fills gap
immediate send ACK, provided that
segment starts at lower end of gap
3-13
TCP fast retransmit

time-out period often
relatively long:
 long delay before
resending lost packet

detect lost segments
via duplicate ACKs.
 sender often sends
many segments backto-back
 if segment is lost, there
will likely be many
duplicate ACKs.
TCP fast retransmit
if sender receives 3
ACKs for same data
(“triple
(“triple duplicate
duplicate ACKs”),
ACKs”),
resend unacked
segment with smallest
seq #
 likely that unacked
segment lost, so don’t
wait for timeout
3-14
TCP fast retransmit
Host B
Host A
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data
X
timeout
ACK=100
ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data
fast retransmit after sender
receipt of triple duplicate ACK
3-15
TCP 3-way handshake
client state
server state
LISTEN
LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT
received SYNACK(x)
indicates server is live;
ESTAB
send ACK for SYNACK;
this segment may contain
client-to-server data
SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
SYN RCVD
msg, acking SYN
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
ACKbit=1, ACKnum=y+1
received ACK(y)
indicates client is live
ESTAB
3-16
TCP 3-way handshake: FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
L
SYN(x)
SYNACK(seq=y,ACKnum=x+1)
create new socket for
communication back to client
listen
Socket clientSocket =
newSocket("hostname","port
number");
SYN(seq=x)
SYN
sent
SYN
rcvd
SYNACK(seq=y,ACKnum=x+1)
ACK(ACKnum=y+1)
ESTAB
ACK(ACKnum=y+1)
L
3-17
TCP: closing a connection

client, server each close their side of connection
 send TCP segment with FIN bit = 1

respond to received FIN with ACK
 on receiving FIN, ACK can be combined with own FIN

simultaneous FIN exchanges can be handled
3-18
TCP: closing a connection
client state
server state
ESTAB
ESTAB
clientSocket.close()
FIN_WAIT_1
FIN_WAIT_2
can no longer
send but can
receive data
FINbit=1, seq=x
CLOSE_WAIT
ACKbit=1; ACKnum=x+1
wait for server
close
FINbit=1, seq=y
TIMED_WAIT
timed wait
for 2*max
segment lifetime
can still
send data
LAST_ACK
can no longer
send data
ACKbit=1; ACKnum=y+1
CLOSED
CLOSED
3-19
Network Layer
Network layer





transport segment from
sending to receiving host
on sending side
encapsulates segments
into datagrams
on receiving side, delivers
segments to transport
layer
network layer protocols
in every host, router
router examines header
fields in all IP datagrams
passing through it
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
4-21
Two key network-layer functions


forwarding: move packets
from router’s input to
appropriate router
output
routing: determine route
taken by packets from
source to dest.
 routing algorithms
analogy:


routing: process of
planning trip from source
to dest
forwarding: process of
getting through single
interchange
4-22
Interplay between routing and forwarding
routing algorithm
routing algorithm determines
end-end-path through network
local forwarding table
header value output link
forwarding table determines
local forwarding at this router
0100
0101
0111
1001
3
2
2
1
value in arriving
packet’s header
0111
1
3 2
4-23
The Internet network layer
host, router network layer functions:
transport layer: TCP, UDP
IP protocol
routing protocols
network
layer
• addressing conventions
• datagram format
• packet handling conventions
• path selection
• RIP, OSPF, BGP
forwarding
table
ICMP protocol
• error reporting
• router
“signaling”
link layer
physical layer
4-24
IP datagram format
IP protocol version
number
header length
(bytes)
“type” of data
max number
remaining hops
(decremented at
each router)
upper layer protocol
to deliver payload to
how much overhead?
 20 bytes of TCP
 20 bytes of IP
 = 40 bytes + app
layer overhead
32 bits
total datagram
length (bytes)
ver head. type of
len service
length
16-bit identifier
upper
time to
layer
live
fragment
flgs
offset
header
checksum
for
fragmentation/
reassembly
32 bit source IP address
32 bit destination IP address
options (if any)
data
(variable length,
typically a TCP
or UDP segment)
e.g. timestamp,
record route
taken, specify
list of routers
to visit.
4-25
IP fragmentation, reassembly

fragmentation:
in: one large datagram
out: 3 smaller datagrams
…

reassembly
…
network links have MTU
(max.transfer size) largest possible link-level
frame
 different link types,
different MTUs
large IP datagram divided
(“fragmented”) within net
 one datagram becomes
several datagrams
 “reassembled” only at
final destination
 IP header bits used to
identify, order related
fragments
4-26
IP fragmentation, reassembly
example:


4000 byte datagram
MTU = 1500 bytes
1480 bytes in
data field
offset =
1480/8
length ID fragflag
=4000 =x
=0
offset
=0
one large datagram becomes
several smaller datagrams
length ID fragflag
=1500 =x
=1
offset
=0
length ID fragflag
=1500 =x
=1
offset
=185
length ID fragflag
=1040 =x
=0
offset
=370
4-27
ICMP: internet control message protocol

used by hosts & routers
to communicate networklevel information
 error reporting:
unreachable host, network,
port, protocol
 echo request/reply (used by
ping)

network-layer “above” IP:
 ICMP msgs carried in IP
datagrams

ICMP message: type, code
plus first 8 bytes of IP
datagram causing error
Type
0
3
3
3
3
3
3
4
Code
0
0
1
2
3
6
7
0
8
9
10
11
12
0
0
0
0
0
description
echo reply (ping)
dest. network unreachable
dest host unreachable
dest protocol unreachable
dest port unreachable
dest network unknown
dest host unknown
source quench (congestion
control - not used)
echo request (ping)
route advertisement
router discovery
TTL expired
bad IP header
4-28
Traceroute and ICMP

source sends series of
UDP segments to dest
 first set has TTL =1
 second set has TTL=2, etc.
 unlikely port number

when nth set of datagrams
arrives to nth router:
 router discards datagrams
 and sends source ICMP
messages (type 11, code 0)
 ICMP messages includes
name of router & IP address
3 probes

when ICMP messages
arrives, source records
RTTs
stopping criteria:
 UDP segment eventually
arrives at destination host
 destination returns ICMP
“port unreachable”
message (type 3, code 3)
 source stops
3 probes
3 probes
4-29
IPv6: motivation


initial motivation: 32-bit address space soon to be
completely allocated.
additional motivation:
 header format helps speed processing/forwarding
 header changes to facilitate QoS
IPv6 datagram format:
 fixed-length 40 byte header
 no fragmentation allowed
4-30
IPv6 datagram format
priority: identify priority among datagrams in flow
flow Label: identify datagrams in same “flow.”
(concept of“flow” not well defined).
next header: identify upper layer protocol for data
ver
pri
flow label
hop limit
payload len
next hdr
source address
(128 bits)
destination address
(128 bits)
data
32 bits
4-31
Other changes from IPv4



checksum: removed entirely to reduce processing
time at each hop
options: allowed, but outside of header, indicated
by “Next Header” field
ICMPv6: new version of ICMP
 additional message types, e.g. “Packet Too Big”
 multicast group management functions
4-32
Transition from IPv4 to IPv6


not all routers can be upgraded simultaneously
 no “flag days”
 how will network operate with mixed IPv4 and
IPv6 routers?
tunneling: IPv6 datagram carried as payload in IPv4
datagram among IPv4 routers
IPv4 header fields
IPv4 source, dest addr
IPv6 header fields
IPv6 source dest addr
IPv4 payload
UDP/TCP payload
IPv6 datagram
IPv4 datagram
4-33
Tunneling
IPv4 tunnel
connecting IPv6 routers
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
logical view:
E
F
IPv6
IPv6
D
E
F
IPv4
IPv6
IPv6
physical view:
4-34
Tunneling
IPv4 tunnel
connecting IPv6 routers
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
logical view:
E
F
IPv6
IPv6
D
E
F
IPv4
IPv6
IPv6
physical view:
flow: X
src: A
dest: F
data
A-to-B:
IPv6
src:B
dest: E
src:B
dest: E
Flow: X
Src: A
Dest: F
Flow: X
Src: A
Dest: F
data
data
B-to-C:
IPv6 inside
IPv4
B-to-C:
IPv6 inside
IPv4
flow: X
src: A
dest: F
data
E-to-F:
IPv6
4-35
Broadcast routing


deliver packets from source to all other nodes
source duplication is inefficient:
duplicate
duplicate
creation/transmission
R1
R1
duplicate
R2
R2
R3
R4
source
duplication

R3
R4
in-network
duplication
source duplication: how does source determine
recipient addresses?
4-36
In-network duplication

flooding: when node receives broadcast packet,
sends copy to all neighbors
 problems: cycles & broadcast storm

controlled flooding: node only broadcasts pkt if it
hasn’t broadcast same packet before
 node keeps track of packet ids already broadacsted
 or reverse path forwarding (RPF): only forward packet
if it arrived on shortest path between node and source

spanning tree:
 no redundant packets received by any node
4-37
Spanning tree


first construct a spanning tree
nodes then forward/make copies only along
spanning tree
A
A
B
B
c
c
D
F
D
E
F
G
(a) broadcast initiated at A
E
G
(b) broadcast initiated at D
4-38
Link Layer
Link layer: introduction
terminology:



hosts and routers: nodes
communication channels that
connect adjacent nodes along
communication path: links
 wired links
 wireless links
 LANs
layer-2 packet: frame,
encapsulates datagram
global ISP
data-link layer has responsibility of
transferring datagram from one node
to physically adjacent node over a link
5-40
Link layer: context


datagram transferred by
different link protocols over
different links:
 e.g., Ethernet on first link,
frame relay on
intermediate links, 802.11
on last link
each link protocol provides
different services
 e.g., may or may not
provide rdt over link
transportation analogy:





trip from Princeton to Lausanne
 limo: Princeton to JFK
 plane: JFK to Geneva
 train: Geneva to Lausanne
tourist = datagram
transport segment =
communication link
transportation mode = link
layer protocol
travel agent = routing
algorithm
5-41
Multiple access links, protocols
two types of “links”:
 point-to-point
 PPP for dial-up access
 point-to-point link between Ethernet switch, host

broadcast (shared wire or medium)
 old-fashioned Ethernet
 upstream HFC
 802.11 wireless LAN
shared wire (e.g.,
cabled Ethernet)
shared RF
(e.g., 802.11 WiFi)
shared RF
(satellite)
humans at a
cocktail party
(shared air, acoustical)
5-42
Multiple access protocols


single shared broadcast channel
two or more simultaneous transmissions by nodes:
interference
 collision if node receives two or more signals at the same
time
multiple access protocol


distributed algorithm that determines how nodes share
channel, i.e., determine when node can transmit
communication about channel sharing must use channel itself!
 no out-of-band channel for coordination
5-43
MAC protocols: taxonomy
three broad classes:
 channel partitioning
 divide channel into smaller “pieces” (time slots, frequency, code)
 allocate piece to node for exclusive use

random access
 channel not divided, allow collisions
 “recover” from collisions

“taking turns”
 nodes take turns, but nodes with more to send can take longer
turns
5-44
Channel partitioning MAC protocols: TDMA
TDMA: time division multiple access




access to channel in "rounds"
each station gets fixed length slot (length = pkt
trans time) in each round
unused slots go idle
example: 6-station LAN, 1,3,4 have pkt, slots
2,5,6 idle
6-slot
frame
6-slot
frame
1
3
4
1
3
4
5-45
Channel partitioning MAC protocols: FDMA
FDMA: frequency division multiple access



channel spectrum divided into frequency bands
each station assigned fixed frequency band
unused transmission time in frequency bands go idle
example: 6-station LAN, 1,3,4 have pkt, frequency bands 2,5,6
idle
FDM cable
frequency bands

5-46
Random access protocols

when node has packet to send
 transmit at full channel data rate R.
 no a priori coordination among nodes


two or more transmitting nodes ➜ “collision”,
random access MAC protocol specifies:
 how to detect collisions
 how to recover from collisions (e.g., via delayed
retransmissions)

examples of random access MAC protocols:
 slotted ALOHA
 ALOHA
 CSMA, CSMA/CD, CSMA/CA
5-47
CSMA (carrier sense multiple access)
CSMA: listen before transmit:
if channel sensed idle: transmit entire frame
 if channel sensed busy, defer transmission

human analogy: don’t interrupt others!
5-48
CSMA collisions


spatial layout of nodes
collisions can still occur:
propagation delay means
two nodes may not hear
each other’s
transmission
collision: entire packet
transmission time
wasted
 distance & propagation
delay play role in in
determining collision
probability
5-49
CSMA/CD (collision detection)
CSMA/CD: carrier sensing, deferral as in CSMA
 collisions detected within short time
 colliding transmissions aborted, reducing channel wastage

collision detection:
 easy in wired LANs: measure signal strengths, compare
transmitted, received signals
 difficult in wireless LANs: received signal strength
overwhelmed by local transmission strength

human analogy: the polite conversationalist
5-50
CSMA/CD (collision detection)
spatial layout of nodes
5-51
Ethernet CSMA/CD algorithm
1. NIC receives datagram
from network layer,
creates frame
2. If NIC senses channel
idle, starts frame
transmission. If NIC
senses channel busy,
waits until channel idle,
then transmits.
3. If NIC transmits entire
frame without detecting
another transmission,
NIC is done with frame !
4. If NIC detects another
transmission while
transmitting, aborts and
sends jam signal
5. After aborting, NIC
enters binary (exponential)
backoff:
 after mth collision, NIC
chooses K at random
from {0,1,2, …, 2m-1}.
NIC waits K·512 bit
times, returns to Step 2
 longer backoff interval
with more collisions
5-52
MAC addresses and ARP

32-bit IP address:
 network-layer address for interface
 used for layer 3 (network layer) forwarding

MAC (or LAN or physical or Ethernet) address:
 function: used ‘locally” to get frame from one interface to
another physically-connected interface (same network, in IPaddressing sense)
 48 bit MAC address (for most LANs) burned in NIC
ROM, also sometimes software settable
 e.g.: 1A-2F-BB-76-09-AD
hexadecimal (base 16) notation
(each “number” represents 4 bits)
5-53
LAN addresses and ARP
each adapter on LAN has unique LAN address
1A-2F-BB-76-09-AD
LAN
(wired or
wireless)
adapter
71-65-F7-2B-08-53
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
5-54
ARP: address resolution protocol
Question: how to determine
interface’s MAC address,
knowing its IP address?
137.196.7.78
1A-2F-BB-76-09-AD
137.196.7.23
137.196.7.14
LAN
71-65-F7-2B-08-53
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
ARP table: each IP node (host,
router) on LAN has table
 IP/MAC address
mappings for some LAN
nodes:
< IP address; MAC address; TTL>
 TTL (Time To Live):
time after which address
mapping will be
forgotten (typically 20
min)
137.196.7.88
5-55
ARP protocol: same LAN

A wants to send datagram
to B
 B’s MAC address not in
A’s ARP table.

A broadcasts ARP query
packet, containing B's IP
address
 dest MAC address = FF-FFFF-FF-FF-FF
 all nodes on LAN receive
ARP query


B receives ARP packet,
replies to A with its (B's)
MAC address
A caches (saves) IP-toMAC address pair in its
ARP table until
information becomes old
(times out)
 soft state: information that
times out (goes away)
unless refreshed

ARP is “plug-and-play”:
 nodes create their ARP
tables without intervention
from net administrator
 frame sent to A’s MAC
address (unicast)
5-56
Ethernet frame structure
sending adapter encapsulates IP datagram (or other
network layer protocol packet) in Ethernet frame
type
dest.
source
preamble address address
data
(payload)
CRC
preamble:
 7 bytes with pattern 10101010 followed by one
byte with pattern 10101011
 used to synchronize receiver, sender clock rates
5-57
Ethernet frame structure (more)

addresses: 6 byte source, destination MAC addresses
 if adapter receives frame with matching destination
address, or with broadcast address (e.g. ARP packet), it
passes data in frame to network layer protocol
 otherwise, adapter discards frame


type: indicates higher layer protocol (mostly IP but
others possible, e.g., Novell IPX, AppleTalk)
CRC: cyclic redundancy check at receiver
 error detected: frame is dropped
type
dest.
source
preamble address address
data
(payload)
CRC
5-58
Ethernet: unreliable, connectionless



connectionless: no handshaking between sending and
receiving NICs
unreliable: receiving NIC doesnt send acks or nacks
to sending NIC
 data in dropped frames recovered only if initial
sender uses higher layer rdt (e.g., TCP), otherwise
dropped data lost
Ethernet’s MAC protocol: unslotted CSMA/CD wth
binary backoff
5-59
Synthesis: a day in the life of a web request

journey down protocol stack complete!
 application, transport, network, link

putting-it-all-together: synthesis!
 goal: identify, review, understand protocols (at all
layers) involved in seemingly simple scenario:
requesting www page
 scenario: student attaches laptop to campus network,
requests/receives www.google.com
5-60
A day in the life: scenario
DNS server
browser
Comcast network
68.80.0.0/13
school network
68.80.2.0/24
web page
web server
64.233.169.105
Google’s network
64.233.160.0/19
5-61
A day in the life… connecting to the Internet
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP

connecting laptop needs to
get its own IP address, addr
of first-hop router, addr of
DNS server: use DHCP
DHCP

DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
router
(runs DHCP)


DHCP request encapsulated
in UDP, encapsulated in IP,
encapsulated in 802.3
Ethernet
Ethernet frame broadcast
(dest: FFFFFFFFFFFF) on LAN,
received at router running
DHCP server
Ethernet demuxed to IP
demuxed, UDP demuxed to
DHCP
5-62
A day in the life… connecting to the Internet
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP


DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
router
(runs DHCP)

DHCP server formulates
DHCP ACK containing
client’s IP address, IP
address of first-hop router
for client, name & IP
address of DNS server
encapsulation at DHCP
server, frame forwarded
(switch learning) through
LAN, demultiplexing at
client
DHCP client receives
DHCP ACK reply
Client now has IP address, knows name & addr of DNS
server, IP address of its first-hop router
5-63
A day in the life… ARP (before DNS, before HTTP)
DNS
DNS
DNS
ARP query

DNS
UDP
IP
ARP
Eth
Phy

ARP
ARP reply
Eth
Phy
router
(runs DHCP)


before sending HTTP request, need
IP address of www.google.com:
DNS
DNS query created, encapsulated in
UDP, encapsulated in IP,
encapsulated in Eth. To send frame
to router, need MAC address of
router interface: ARP
ARP query broadcast, received by
router, which replies with ARP
reply giving MAC address of
router interface
client now knows MAC address
of first hop router, so can now
send frame containing DNS
query
5-64
A day in the life… using DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
UDP
IP
Eth
Phy
DNS
DNS
DNS
UDP
IP
Eth
Phy
DNS server
DNS
Comcast network
68.80.0.0/13
router
(runs DHCP)

IP datagram containing DNS
query forwarded via LAN
switch from client to 1st hop
router

IP datagram forwarded from
campus network into comcast
network, routed (tables created
by RIP, OSPF, IS-IS and/or BGP
routing protocols) to DNS server

demux’ed to DNS server
DNS server replies to client
with IP address of
www.google.com

5-65
A day in the life…TCP connection carrying HTTP
HTTP
HTTP
TCP
IP
Eth
Phy
SYNACK
SYN
SYNACK
SYN
SYNACK
SYN

router
(runs DHCP)
SYNACK
SYN
SYNACK
SYN
SYNACK
SYN
TCP
IP
Eth
Phy
web server
64.233.169.105



to send HTTP request,
client first opens TCP socket
to web server
TCP SYN segment (step 1 in 3way handshake) inter-domain
routed to web server
web server responds with TCP
SYNACK (step 2 in 3-way
handshake)
TCP connection established!
5-66
A day in the life… HTTP request/reply
HTTP
HTTP
HTTP
TCP
IP
Eth
Phy
HTTP
HTTP
HTTP
HTTP
HTTP
HTTP

web page finally (!!!) displayed

HTTP
HTTP
HTTP
HTTP
HTTP
TCP
IP
Eth
Phy
web server
64.233.169.105
router
(runs DHCP)



HTTP request sent into TCP
socket
IP datagram containing HTTP
request routed to
www.google.com
web server responds with
HTTP reply (containing web
page)
IP datagram containing HTTP
reply routed back to client
5-67