Network Protocol Network Protocol • Application layer protocol • Transport layer protocol • Network layer protocol • Link layer protocol.

Download Report

Transcript Network Protocol Network Protocol • Application layer protocol • Transport layer protocol • Network layer protocol • Link layer protocol.

Network Protocol
Network Protocol
• Application layer protocol
• Transport layer protocol
• Network layer protocol
• Link layer protocol
2
Application Layer
• conceptual,
implementation
aspects of network
application
protocols
– transport-layer
service models
– client-server
paradigm
– peer-to-peer
paradigm
• learn about protocols
by examining popular
application-level
protocols
– HTTP
– FTP
– SMTP / POP3 /
IMAP
– DNS
3
Application architectures
• Client-server
• Peer-to-peer (P2P)
• Hybrid of client-server and P2P
4
Client-server archicture
server:
– always-on host
– permanent IP address
– server farms for scaling
clients:
– communicate with
server
– may be intermittently
connected
– may have dynamic IP
addresses
– do not communicate
directly with each other
5
Pure P2P architecture
• no always on server
• arbitrary end systems
directly communicate
• peers are intermittently
connected and change
IP addresses
• example: Gnutella
Highly scalable
But difficult to manage
6
Processes communicating
Process: program
Client process: process
running within a host.
that initiates
• within same host, two
communication
processes
Server process: process
communicate using
that waits to be
inter-process
contacted
communication
(defined by OS).
• Note: applications
with P2P architectures
• processes in different
have client processes
hosts communicate by
& server processes
exchanging messages
7
Sockets
• process sends/receives
messages to/from its socket
• socket analogous to door
– sending process shoves
message out door
– sending process relies on
transport infrastructure
on other side of door
which brings message to
socket at receiving
process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
8
Addressing processes
• For a process to receive
messages, it must have
an identifier
• A host has a unique32-bit
IP address
• Q: does the IP address of
the host on which the
process runs suffice for
identifying the process?
• Answer: No, many
processes can be running
on same host
• Identifier includes both
the IP address and port
numbers associated with
the process on the host.
• Example port numbers:
– HTTP server: 80
– Mail server: 25
9
App-layer protocol defines
• Types of messages exchanged, eg, request &
response messages
• Syntax of message types: what fields in
messages & how fields are delineated
• Semantics of the fields, ie, meaning of
information in fields
• Rules for when and how processes send &
respond to messages
10
Internet transport protocols
services
TCP service:
• connection-oriented: setup
required between client and
server processes
• reliable transport between
sending and receiving
process
• flow control: sender won’t
overwhelm receiver
• congestion control: throttle
sender when network
overloaded
• does not provide: timing,
minimum bandwidth
guarantees
UDP service:
• unreliable data transfer
between sending and
receiving process
• does not provide:
connection setup,
reliability, flow control,
congestion control,
timing, or bandwidth
guarantee
Q: why bother? Why is
there a UDP?
11
Web and HTTP
First some jargon
• Web page consists of objects
• Object can be HTML file, JPEG image, Java
applet, audio file,…
• Web page consists of base HTML-file which
includes several referenced objects
• Each object is addressable by a URL
• Example URL:
www.someschool.edu/someDept/pic.gif
host name
path name
12
HTTP overview
HTTP: hypertext transfer
protocol
• Web’s application layer
protocol
• client/server model
– client: browser that
requests, receives,
“displays” Web objects
– server: Web server
sends objects in
response to requests
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
13
HTTP request message
• two types of HTTP messages: request, response
• HTTP request message:
– ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
14
HTTP request message: general
format
15
HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
16
FTP: the file transfer protocol
user
at host
FTP
FTP
user
client
interface
local file
system
file transfer
FTP
server
remote file
system
• transfer file to/from remote host
• client/server model
– client: side that initiates transfer (either to/from
remote)
– server: remote host
• ftp: RFC 959
• ftp server: port 21
17
FTP: separate control, data
connections
• FTP client contacts FTP
server at port 21, specifying
TCP as transport protocol
• Client obtains authorization
over control connection
• Client browses remote
directory by sending
commands over control
connection.
• When server receives a
command for a file transfer,
the server opens a TCP data
connection to client
• After transferring one file,
server closes connection.
TCP control connection
port 21
FTP
client
TCP data connection
port 20
FTP
server
• Server opens a second TCP
data connection to transfer
another file.
• Control connection: “out of
band”
• FTP server maintains
“state”: current directory,
earlier authentication
18
Electronic Mail
Three major components:
• user agents
• mail servers
• simple mail transfer
protocol: SMTP
User Agent
• a.k.a. “mail reader”
• composing, editing, reading
mail messages
• e.g., Eudora, Outlook, elm,
Netscape Messenger
• outgoing, incoming
messages stored on server
outgoing
message queue
user mailbox
user
agent
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
19
Electronic Mail: mail servers
Mail Servers
• mailbox contains incoming
messages for user
• message queue of outgoing
(to be sent) mail messages
• SMTP protocol between mail
servers to send email
messages
– client: sending mail
server
– “server”: receiving mail
server
user
agent
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
20
Electronic Mail: SMTP [RFC
2821]
• uses TCP to reliably transfer email
message from client to server, port 25
• direct transfer: sending server to
receiving server
• three phases of transfer
– handshaking (greeting)
– transfer of messages
– closure
21
Scenario: Alice sends
message to Bob
1) Alice uses UA to
compose message and 4) SMTP client sends Alice’s
message over the TCP
“to”
connection
[email protected]
5) Bob’s mail server places
2) Alice’s UA sends
the message in Bob’s
message to her mail
mailbox
server; message placed
in message queue
6) Bob invokes his user agent
to read message
3) Client side of SMTP
opens TCP connection
with Bob’s mail server
1
user
agent
2
mail
server
3
mail
server
4
5
6
user
agent
22
Mail message format
SMTP: protocol for
exchanging email msgs
RFC 822: standard for text
message format:
• header lines, e.g.,
– To:
– From:
– Subject:
header
blank
line
body
• body
– the “message”, ASCII
characters only
23
Message format: multimedia
extensions
• MIME: multimedia mail extension, RFC
2045, 2056
• additional lines in msg header declare
MIME content type From: [email protected]
MIME version
method used
to encode data
multimedia data
type, subtype,
parameter declaration
encoded data
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
24
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server
access
protocol
user
agent
receiver’s mail
server
• SMTP: delivery/storage to receiver’s server
• Mail access protocol: retrieval from server
– POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
– IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored msgs on server
– HTTP: Hotmail , Yahoo! Mail, etc.
25
DNS: Domain Name System
People: many identifiers:
– SSN, name, passport
#
Internet hosts, routers:
– IP address (32 bit) used for addressing
datagrams
– “name”, e.g.,
ww.yahoo.com - used
by humans
Q: map between IP
addresses and name ?
Domain Name System:
• distributed database
implemented in hierarchy of
many name servers
• application-layer protocol
host, routers, name servers
to communicate to resolve
names (address/name
translation)
– note: core Internet
function, implemented
as application-layer
protocol
26
DNS
DNS services
• Hostname to IP address
translation
• Host aliasing
– Canonical and alias
names
• Mail server aliasing
• Load distribution
– Replicated Web
servers: set of IP
addresses for one
canonical name
Why not centralize DNS?
• single point of failure
• traffic volume
• distant centralized database
• maintenance
doesn’t scale!
27
Distributed, Hierarchical Database
Root DNS Servers
com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
org DNS servers
pbs.org
DNS servers
edu DNS servers
poly.edu
umass.edu
DNS serversDNS servers
Client wants IP for www.amazon.com; 1st
approx:
• Client queries a root server to find com DNS
server
• Client queries com DNS server to get
amazon.com DNS server
• Client queries amazon.com DNS server to get
IP address for www.amazon.com
28
Internet transport-layer
protocols
29
Transport services and
protocols
• provide logical communication
between app processes
running on different hosts
• transport protocols run in end
systems
– send side: breaks app
messages into segments,
passes to network layer
– rcv side: reassembles
segments into messages,
passes to app layer
• more than one transport
protocol available to apps
– Internet: TCP and UDP
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
application
transport
network
data link
physical
30
Transport vs. network layer
• network layer: logical communication
between hosts
• transport layer: logical communication
between processes
– relies on, enhances, network layer
services
31
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:
– delay guarantees
– bandwidth guarantees
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
application
transport
network
data link
physical
32
Multiplexing/demultiplexing
Multiplexing at send host:
gathering data from multiple
sockets, enveloping data with
header (later used for
demultiplexing)
Demultiplexing at rcv host:
delivering received segments
to correct socket
= socket
application
transport
network
link
= process
P3
P1
P1
application
transport
network
P2
P4
application
transport
network
link
link
physical
host 1
physical
host 2
physical
host 3
33
How demultiplexing works
• host receives IP datagrams
– each datagram has
source IP address,
destination IP address
– each datagram carries 1
transport-layer segment
– each segment has
source, destination port
number
host uses IP addresses &
port numbers to direct
segment to appropriate
socket
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
34
Connectionless demultiplexing
• When host receives UDP
segment:
– checks destination port
DatagramSocket mySocket1 =
number in segment
new
– directs UDP segment to
DatagramSocket(99111);
socket with that port
DatagramSocket mySocket2 =
number
new
• IP datagrams with different
DatagramSocket(99222);
source IP addresses and/or
source port numbers
• UDP socket identified by twodirected to same socket
tuple:
• Create sockets with port
numbers:
(dest IP address, dest port
number)
35
Connectionless demux
(cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
P2
SP: 6428
SP: 6428
DP: 9157
DP: 5775
SP: 9157
client
IP: A
P1
P1
P3
DP: 6428
SP: 5775
server
IP: C
DP: 6428
Client
IP:B
SP provides “return address”
36
UDP: User Datagram Protocol [RFC
768]
• “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
Why is there a UDP?
• no connection
establishment (which can
add delay)
• simple: no connection
state at sender, receiver
• small segment header
• no congestion control: UDP
can blast away as fast as
desired
37
UDP: more
• often used for
streaming
Length, in
multimedia apps
bytes of UDP
– loss tolerant
segment,
including
– rate sensitive
header
• reliable transfer over
UDP: add reliability
at application layer
– applicationspecific error
recovery!
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP segment format
38
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
Receiver:
• treat segment contents
• compute checksum of
as sequence of 16-bit
received segment
integers
• check if computed checksum
• checksum: addition (1’s
equals checksum field value:
complement sum) of
– NO - error detected
segment contents
– YES - no error detected.
• sender puts checksum
But maybe errors
value into UDP checksum
nonetheless? More later
field
….
39
Internet Checksum Example
• Note
– When adding numbers, a carryout from the
most significant bit needs to be added to
the result
• Example: add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
40
The Internet Network layer
41
The Internet Network layer
Host, router network layer functions:
Transport layer: TCP, UDP
Network
layer
IP protocol
•addressing conventions
•datagram format
•packet handling conventions
Routing protocols
•path selection
•RIP, OSPF, BGP
forwarding
table
ICMP protocol
•error reporting
•router “signaling”
Link layer
physical layer
42
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
32 bits
head. type of
length
ver
len service
fragment
16-bit identifier flgs
offset
upper
time to
Internet
layer
live
checksum
total datagram
length (bytes)
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.
43
NAT: Network Address
Translation
rest of
Internet
local network
(e.g., home network)
10.0.0/24
10.0.0.4
10.0.0.1
10.0.0.2
138.76.29.7
10.0.0.3
All datagrams leaving local
network have same single source
NAT IP address: 138.76.29.7,
different source port numbers
Datagrams with source or
destination in this network
have 10.0.0/24 address for
source, destination (as usual)
44
NAT: Network Address
Translation
• Motivation: local network uses just one IP address
as far as outside word is concerned:
– no need to be allocated range of addresses from
ISP: - just one IP address is used for all devices
– can change addresses of devices in local network
without notifying outside world
– can change ISP without changing addresses of
devices in local network
– devices inside local net not explicitly
addressable, visible by outside world (a security
plus).
45
NAT: Network Address
Translation
Implementation: NAT router must:
– outgoing datagrams: replace (source IP address, port #) of
every outgoing datagram to (NAT IP address, new port #)
. . . remote clients/servers will respond using (NAT IP
address, new port #) as destination addr.
– remember (in NAT translation table) every (source IP
address, port #) to (NAT IP address, new port #)
translation pair
– incoming datagrams: replace (NAT IP address, new port #)
in dest fields of every incoming datagram with
corresponding (source IP address, port #) stored in NAT
table
46
NAT: Network Address Translation
2: NAT router
changes datagram
source addr from
10.0.0.1, 3345 to
138.76.29.7, 5001,
updates table
2
NAT translation table
WAN side addr
LAN side addr
1: host 10.0.0.1
sends datagram to
128.119.40, 80
138.76.29.7, 5001 10.0.0.1, 3345
……
……
S: 10.0.0.1, 3345
D: 128.119.40.186, 80
S: 138.76.29.7, 5001
D: 128.119.40.186, 80
138.76.29.7
S: 128.119.40.186, 80
D: 138.76.29.7, 5001
3: Reply arrives
dest. address:
138.76.29.7, 5001
3
1
10.0.0.4
S: 128.119.40.186, 80
D: 10.0.0.1, 3345
10.0.0.1
10.0.0.2
4
10.0.0.3
4: NAT router
changes datagram
dest addr from
138.76.29.7, 5001 to 10.0.0.1, 3345
47
ICMP: Internet Control Message
Protocol
• used by hosts & routers to
communicate network-level
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
48
IPv6
• 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
49
IPv6 Header (Cont)
Priority: identify priority among datagrams in flow
Next header: identify upper layer protocol for data
50
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
51
Transition From IPv4
To IPv6
• Not all routers can be upgraded
simultaneous
– no “flag days”
– How will the network operate with mixed
IPv4 and IPv6 routers?
• Tunneling: IPv6 carried as payload in
IPv4 datagram among IPv4 routers
52
Tunneling
Logical view:
Physical view:
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
Flow: X
Src: A
Dest: F
data
A-to-B:
IPv6
E
F
IPv6
IPv6
D
E
F
IPv4
IPv6
IPv6
tunnel
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
Flow: X
Src: A
Dest: F
data
D-to-E:
E-to-F:
IPv6 inside
IPv6
IPv4
53
Link Layer Protocol
54
Multiple Access Links and
Protocols
Two types of “links”:
• point-to-point
– PPP for dial-up access
– point-to-point link between Ethernet switch
and host
• broadcast (shared wire or medium)
– traditional Ethernet
– 802.11 wireless LAN
55
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!
56
– no out-of-band channel for coordination
Ideal Multiple Access Protocol
Broadcast channel of rate R bps
1. When one node wants to transmit, it can
send at rate R.
2. When M nodes want to transmit, each can
send at average rate R/M
3. Fully decentralized:
– no special node to coordinate transmissions
– no synchronization of clocks, slots
4. Simple
57
MAC Protocols: a
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
58
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
59
Channel Partitioning MAC
protocols: FDMA
frequency bands
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 (Frequency Division Multiplexing): frequency
subdivided.
60
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
61
Slotted ALOHA
Assumptions
• all frames same size
• time is divided into
equal size slots, time
to transmit 1 frame
• nodes start to
transmit frames only
at beginning of slots
• nodes are
synchronized
• if 2 or more nodes
transmit in slot, all
nodes detect collision
Operation
• when node obtains fresh
frame, it transmits in
next slot
• no collision, node can
send new frame in next
slot
• if collision, node
retransmits frame in
each subsequent slot
with prob. p until
success
62
Slotted ALOHA
Pros
• single active node
can continuously
transmit at full rate
of channel
• highly decentralized:
only slots in nodes
need to be in sync
• simple
Cons
• collisions, wasting
slots
• idle slots
• nodes may be able
to detect collision in
less than time to
transmit packet
• clock synchronization
63
Slotted Aloha efficiency
• For max efficiency with N
Efficiency is the long-run
nodes, find p* that
fraction of successful slots
maximizes
Np(1-p)N-1
when there are many nodes,
each with many frames to send • For many nodes, take
limit of Np*(1-p*)N-1 as
• Suppose N nodes with
N goes to infinity, gives
many frames to send,
1/e = .37
each transmits in slot
with probability p
• prob that node 1 has
At best: channel
success in a slot
= p(1-p)N-1
used for useful
• prob that any node has a
transmissions 37%
N-1
success = Np(1-p)
of time!
64
Pure (unslotted) ALOHA
• unslotted Aloha: simpler, no synchronization
• when frame first arrives
– transmit immediately
• collision probability increases:
– frame sent at t0 collides with other frames sent in [t01,t0+1]
65
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!
66
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
note:
role of distance & propagation
delay in determining collision
probability
67
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: receiver shut off
while transmitting
• human analogy: the polite conversationalist
68
CSMA/CD collision detection
69
“Taking Turns” MAC
protocols
channel partitioning MAC protocols:
– share channel efficiently and fairly at high load
– inefficient at low load: delay in channel access,
1/N bandwidth allocated even if only 1 active
node!
Random access MAC protocols
– efficient at low load: single node can fully
utilize channel
– high load: collision overhead
“taking turns” protocols
look for best of both worlds!
70
“Taking Turns” MAC
protocols
Polling:
• master node “invites”
slave nodes to
transmit in turn
• concerns:
– polling overhead
– latency
– single point of
failure (master)
Token passing:
• control token passed from one
node to next sequentially.
• token message
• concerns:
– token overhead
– latency
– single point of failure
(token)
71
Summary of MAC protocols
• What do you do with a shared media?
– Channel Partitioning, by time, frequency or code
• Time Division, Frequency Division
– Random partitioning (dynamic),
• ALOHA, S-ALOHA, CSMA, CSMA/CD
• carrier sensing: easy in some technologies (wire),
hard in others (wireless)
• CSMA/CD used in Ethernet
• CSMA/CA used in 802.11
– Taking Turns
• polling from a central site, token passing
72
MAC Addresses and ARP
• 32-bit IP address:
– network-layer address
– used to get datagram to destination IP subnet
• MAC (or LAN or physical or Ethernet) address:
– used to get datagram from one interface to
another physically-connected interface (same
network)
– 48 bit MAC address (for most LANs)
burned in the adapter ROM
73
LAN Addresses and ARP
Each adapter on LAN has unique LAN address
1A-2F-BB-76-09-AD
71-65-F7-2B-08-53
LAN
(wired or
wireless)
Broadcast address =
FF-FF-FF-FF-FF-FF
= adapter
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
74
LAN Address (more)
• MAC address allocation administered by IEEE
• manufacturer buys portion of MAC address space (to assure
uniqueness)
• Analogy:
(a) MAC address: like Social Security Number
(b) IP address: like postal address
• MAC flat address ➜ portability
– can move LAN card from one LAN to another
• IP hierarchical address NOT portable
– depends on IP subnet to which node is attached
75
ARP: Address Resolution
Protocol
Question: how to determine
MAC address of B
knowing B’s IP address?
237.196.7.78
1A-2F-BB-76-09-AD
237.196.7.23
237.196.7.14
LAN
71-65-F7-2B-08-53
237.196.7.88
• Each IP node (Host, Router) on
LAN has ARP table
• ARP 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)
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
76
ARP protocol: Same LAN
(network)
• A wants to send datagram
to B, and B’s MAC address
not in A’s ARP table.
• A broadcasts ARP query
packet, containing B's IP
address
– Dest MAC address = FFFF-FF-FF-FF-FF
– all machines on LAN
receive ARP query
• B receives ARP packet,
replies to A with its (B's)
MAC address
– frame sent to A’s MAC
address (unicast)
• A caches (saves) IP-to-MAC
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
77
Routing to another LAN
• walkthrough: send datagram from A to B via R
assume A knows B IP address
A
R
B
• Two ARP tables in router R, one for each IP network
(LAN)
• In ARP table at source, find MAC address E6-E9-00-17-BB-4B,
etc
• In routing table at source Host, find router 111.111.111.110
78
• A creates datagram with source A, destination B
• A uses ARP to get R’s MAC address for 111.111.111.110
• A creates link-layer frame with R's MAC address as dest,
frame contains A-to-B IP datagram
• A’s adapter sends frame
• R’s adapter receives frame
• R removes IP datagram from Ethernet frame, sees its destined
to B
• R uses ARP to get B’s MAC address
• R creates frame containing A-to-B IP datagram sends to B
A
R
B
79