PowerPoint Presentation
Computer Networking: A Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
Chapter 4
Network Layer:
Data Plane
A note on the use of these PowerPoint slides:
We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:
If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!)
If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.
For a revision history, see the slide note for this page.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2020
J.F Kurose and K.W. Ross, All Rights Reserved
Version History
8.0 (May 2020)
All slides reformatted for 16:9 aspect ratio
All slides updated to 8th edition material
Use of Calibri font, rather that Gill Sans MT
Add LOTS more animation throughout
added new 8th edition material on middleboxes (and Internet arch), Net neutrality, buffering …
lighter header font
1
Network layer: our goals
understand principles behind network layer services, focusing on data plane:
network layer service models
forwarding versus routing
how a router works
addressing
generalized forwarding
Internet architecture
instantiation, implementation in the Internet
IP protocol
NAT, middleboxes
Network Layer: 4-2
2
Network layer: “data plane” roadmap
Network layer: overview
data plane
control plane
Generalized Forwarding, SDN
Match+action
OpenFlow: match+action in action
Middleboxes
Network Layer: 4-3
What’s inside a router
input ports, switching, output ports
buffer management, scheduling
IP: the Internet Protocol
datagram format
addressing
network address translation
IPv6
3
Network-layer services and protocols
transport segment from sending to receiving host
sender: encapsulates segments into datagrams, passes to link layer
receiver: delivers segments to transport layer protocol
network layer protocols in every Internet device: hosts, routers
routers:
examines header fields in all IP datagrams passing through it
moves datagrams from input ports to output ports to transfer datagrams along end-end path
mobile network
enterprise
network
national or global ISP
datacenter
network
application
transport
network
link
physical
application
transport
network
link
physical
network
link
physical
network
link
physical
network
link
physical
network
link
physical
network
link
physical
Network Layer: 4-4
4
Two key network-layer functions
network-layer functions:
forwarding: move packets from a router’s input link to appropriate router output link
analogy: taking a trip
forwarding: process of getting through single interchange
forwarding
routing
routing: process of planning trip from source to destination
routing: determine route taken by packets from source to destination
routing algorithms
Network Layer: 4-5
5
Network layer: data plane, control plane
Data plane:
local, per-router function
determines how datagram arriving on router input port is forwarded to router output port
Control plane
network-wide logic
determines how datagram is routed among routers along end-end path from source host to destination host
1
2
3
0111
values in arriving
packet header
two control-plane approaches:
traditional routing algorithms: implemented in routers
software-defined networking (SDN): implemented in (remote) servers
Network Layer: 4-6
6
Per-router control plane
Individual routing algorithm components in each and every router interact in the control plane
Routing
Algorithm
data
plane
control
plane
1
2
0111
values in arriving
packet header
3
Network Layer: 4-7
7
Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers
data
plane
control
plane
Remote Controller
CA
CA
CA
CA
CA
1
2
0111
3
values in arriving
packet header
Network Layer: 4-8
8
Network service model
example services for individual datagrams:
guaranteed delivery
guaranteed delivery with less than 40 msec delay
example services for a flow of datagrams:
in-order datagram delivery
guaranteed minimum bandwidth to flow
restrictions on changes in inter-packet spacing
Q: What service model for “channel” transporting datagrams from sender to receiver?
Network Layer: 4-9
9
Network-layer service model
Network
Architecture
Internet
ATM
ATM
Internet
Internet
Service
Model
best effort
Constant Bit Rate
Available Bit Rate
Intserv Guaranteed
(RFC 1633)
Diffserv (RFC 2475)
Bandwidth
none
Constant rate
Guaranteed min
yes
possible
Loss
no
yes
no
yes
possibly
Order
no
yes
yes
yes
possibly
Timing
no
yes
no
yes
no
No guarantees on:
successful datagram delivery to destination
timing or order of delivery
bandwidth available to end-end flow
Internet “best effort” service model
Quality of Service (QoS) Guarantees ?
Network Layer: 4-10
10
Network-layer service model
Network
Architecture
Internet
ATM
ATM
Internet
Internet
Service
Model
best effort
Constant Bit Rate
Available Bit Rate
Intserv Guaranteed
(RFC 1633)
Diffserv (RFC 2475)
Bandwidth
none
Constant rate
Guaranteed min
yes
possible
Loss
no
yes
no
yes
possibly
Order
no
yes
yes
yes
possibly
Timing
no
yes
no
yes
no
Quality of Service (QoS) Guarantees ?
Network Layer: 4-11
11
Reflections on best-effort service:
simplicity of mechanism has allowed Internet to be widely deployed adopted
sufficient provisioning of bandwidth allows performance of real-time applications (e.g., interactive voice, video) to be “good enough” for “most of the time”
replicated, application-layer distributed services (datacenters, content distribution networks) connecting close to clients’ networks, allow services to be provided from multiple locations
congestion control of “elastic” services helps
It’s hard to argue with success of best-effort service model
Network Layer: 4-12
12
Network layer: “data plane” roadmap
Network layer: overview
data plane
control plane
What’s inside a router
input ports, switching, output ports
buffer management, scheduling
IP: the Internet Protocol
datagram format
addressing
network address translation
IPv6
Generalized Forwarding, SDN
Match+action
OpenFlow: match+action in action
Middleboxes
Network Layer: 4-13
13
Router architecture overview
high-level view of generic router architecture:
high-speed
switching
fabric
routing
processor
router input ports
router output ports
forwarding data plane (hardware) operates in nanosecond timeframe
routing, management
control plane (software)
operates in millisecond
time frame
Network Layer: 4-14
14
Input port functions
switch
fabric
line
termination
physical layer:
bit-level reception
link
layer
protocol
(receive)
link layer:
e.g., Ethernet
(chapter 6)
lookup,
forwarding
queueing
decentralized switching:
using header field values, lookup output port using forwarding table in input port memory (“match plus action”)
goal: complete input port processing at ‘line speed’
input port queuing: if datagrams arrive faster than forwarding rate into switch fabric
Network Layer: 4-15
15
Input port functions
line
termination
lookup,
forwarding
queueing
decentralized switching:
using header field values, lookup output port using forwarding table in input port memory (“match plus action”)
destination-based forwarding: forward based only on destination IP address (traditional)
generalized forwarding: forward based on any set of header field values
physical layer:
bit-level reception
switch
fabric
link
layer
protocol
(receive)
link layer:
e.g., Ethernet
(chapter 6)
Network Layer: 4-16
16
Q: but what happens if ranges don’t divide up so nicely?
Destination-based forwarding
3
Network Layer: 4-17
Text for this animation:
This all works out pretty nice and looks pretty simple!
But of course the devil is in the details, as the saying goes.
What happens, for example, when a subset of addresses say in this first range should go to say interface 3, rather than interface 0. Well, of course we could split the first address range into multiple pieces, and add in this new subrange with its new destination output port. But it turns out there’s a much simpler and elegant way to do this. Known as longest prefix matching.
17
Longest prefix matching
when looking for forwarding table entry for given destination address, use longest address prefix that matches destination address.
longest prefix match
Destination Address Range
11001000 00010111 00010
11001000 00010111 00011000
11001000 00010111 00011
otherwise
Link interface
0
1
2
3
********
***
********
***
********
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
11001000 00010111 00010110 10100001
Network Layer: 4-18
18
Longest prefix matching
when looking for forwarding table entry for given destination address, use longest address prefix that matches destination address.
longest prefix match
Destination Address Range
11001000 00010111 00010
11001000 00010111 00011000
11001000 00010111 00011
otherwise
Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001
match!
Network Layer: 4-19
19
Longest prefix matching
when looking for forwarding table entry for given destination address, use longest address prefix that matches destination address.
longest prefix match
Destination Address Range
11001000 00010111 00010
11001000 00010111 00011000
11001000 00010111 00011
otherwise
Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001
match!
Network Layer: 4-20
20
Longest prefix matching
when looking for forwarding table entry for given destination address, use longest address prefix that matches destination address.
longest prefix match
Destination Address Range
11001000 00010111 00010
11001000 00010111 00011000
11001000 00010111 00011
otherwise
Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001
match!
Network Layer: 4-21
21
we’ll see why longest prefix matching is used shortly, when we study addressing
longest prefix matching: often performed using ternary content addressable memories (TCAMs)
content addressable: present address to TCAM: retrieve address in one clock cycle, regardless of table size
Cisco Catalyst: ~1M routing table entries in TCAM
Longest prefix matching
Network Layer: 4-22
22
transfer packet from input link to appropriate output link
Switching fabrics
high-speed
switching
fabric
N input ports
N output ports
. . .
. . .
switching rate: rate at which packets can be transfer from inputs to outputs
often measured as multiple of input/output line rate
N inputs: switching rate N times line rate desirable
R
R
R
R
(rate: NR, ideally)
Network Layer: 4-23
23
Switching fabrics
bus
memory
memory
interconnection
network
three major types of switching fabrics:
transfer packet from input link to appropriate output link
switching rate: rate at which packets can be transfer from inputs to outputs
often measured as multiple of input/output line rate
N inputs: switching rate N times line rate desirable
Network Layer: 4-24
24
first generation routers:
traditional computers with switching under direct control of CPU
packet copied to system’s memory
speed limited by memory bandwidth (2 bus crossings per datagram)
Switching via memory
input
port
(e.g.,
Ethernet)
memory
output
port
(e.g.,
Ethernet)
system bus
Network Layer: 4-25
25
datagram from input port memory to output port memory via a shared bus
bus contention: switching speed limited by bus bandwidth
32 Gbps bus, Cisco 5600: sufficient speed for access routers
Switching via a bus
Network Layer: 4-26
26
Crossbar, Clos networks, other interconnection nets initially developed to connect processors in multiprocessor
Switching via interconnection network
8×8 multistage switch
built from smaller-sized switches
3×3 crossbar
multistage switch: nxn switch from multiple stages of smaller switches
exploiting parallelism:
fragment datagram into fixed length cells on entry
switch cells through the fabric, reassemble datagram at exit
3×3 crossbar
Network Layer: 4-27
27
scaling, using multiple switching “planes” in parallel:
speedup, scaleup via parallelism
Switching via interconnection network
fabric plane 0
. . .
. . .
fabric plane 1
. . .
. . .
fabric plane 2
. . .
. . .
fabric plane 3
. . .
. . .
fabric plane 4
. . .
. . .
fabric plane 5
. . .
. . .
fabric plane 6
. . .
. . .
fabric plane 7
. . .
. . .
Cisco CRS router:
basic unit: 8 switching planes
each plane: 3-stage interconnection network
up to 100’s Tbps switching capacity
Network Layer: 4-28
28
If switch fabric slower than input ports combined -> queueing may occur at input queues
queueing delay and loss due to input buffer overflow!
Input port queuing
output port contention: only one red datagram can be transferred. lower red packet is blocked
switch
fabric
one packet time later: green packet experiences HOL blocking
switch
fabric
Head-of-the-Line (HOL) blocking: queued datagram at front of queue prevents others in queue from moving forward
Network Layer: 4-29
29
Output port queuing
Buffering required when datagrams arrive from fabric faster than link transmission rate. Drop policy: which datagrams to drop if no free buffers?
Scheduling discipline chooses among queued datagrams for transmission
Datagrams can be lost due to congestion, lack of buffers
Priority scheduling – who gets best performance, network neutrality
This is a really important slide
line
termination
link
layer
protocol
(send)
switch
fabric
(rate: NR)
datagram
buffer
queueing
R
Network Layer: 4-30
30
Output port queuing
at t, packets more
from input to output
one packet time later
switch
fabric
switch
fabric
buffering when arrival rate via switch exceeds output line speed
queueing (delay) and loss due to output port buffer overflow!
Network Layer: 4-31
31
RFC 3439 rule of thumb: average buffering equal to “typical” RTT (say 250 msec) times link capacity C
e.g., C = 10 Gbps link: 2.5 Gbit buffer
How much buffering?
but too much buffering can increase delays (particularly in home routers)
long RTTs: poor performance for realtime apps, sluggish TCP response
recall delay-based congestion control: “keep bottleneck link just full enough (busy) but no fuller”
RTT C
.
N
more recent recommendation: with N flows, buffering equal to
Network Layer: 4-32
You might think that more buffering is a good thing. Buffering is a bit like salt—just the right amount of salt makes food better, but too much makes it inedible!
32
Buffer Management
buffer management:
drop: which packet to add, drop when buffers are full
tail drop: drop arriving packet
priority: drop/remove on priority basis
line
termination
link
layer
protocol
(send)
switch
fabric
datagram
buffer
queueing
scheduling
marking: which packets to mark to signal congestion (ECN, RED)
R
queue
(waiting area)
packet
arrivals
packet
departures
link
(server)
Abstraction: queue
R
Network Layer: 4-33
33
packet scheduling: deciding which packet to send next on link
first come, first served
priority
round robin
weighted fair queueing
Packet Scheduling: FCFS
FCFS: packets transmitted in order of arrival to output port
also known as: First-in-first-out (FIFO)
real world examples?
queue
(waiting area)
packet
arrivals
packet
departures
link
(server)
Abstraction: queue
R
Network Layer: 4-34
34
Priority scheduling:
arriving traffic classified, queued by class
any header fields can be used for classification
Scheduling policies: priority
high priority queue
low priority queue
arrivals
classify
departures
link
1
3
2
4
5
arrivals
departures
packet in service
send packet from highest priority queue that has buffered packets
FCFS within priority class
1
3
4
2
5
1
3
2
4
5
Network Layer: 4-35
35
Round Robin (RR) scheduling:
arriving traffic classified, queued by class
any header fields can be used for classification
Scheduling policies: round robin
classify
arrivals
departures
link
R
server cyclically, repeatedly scans class queues, sending one complete packet from each class (if available) in turn
Network Layer: 4-36
36
Weighted Fair Queuing (WFQ):
generalized Round Robin
Scheduling policies: weighted fair queueing
classify
arrivals
departures
link
R
w1
w2
w3
wi
Sjwj
minimum bandwidth guarantee (per-traffic-class)
each class, i, has weight, wi, and gets weighted amount of service in each cycle:
Network Layer: 4-37
37
Sidebar: Network Neutrality
What is network neutrality?
technical: how an ISP should share/allocation its resources
packet scheduling, buffer management are the mechanisms
social, economic principles
protecting free speech
encouraging innovation, competition
enforced legal rules and policies
Different countries have different “takes” on network neutrality
Network Layer: 4-38
38
Sidebar: Network Neutrality
2015 US FCC Order on Protecting and Promoting an Open Internet: three “clear, bright line” rules:
no blocking … “shall not block lawful content, applications, services, or non-harmful devices, subject to reasonable network management.”
no throttling … “shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service, or use of a non-harmful device, subject to reasonable network management.”
no paid prioritization. … “shall not engage in paid prioritization”
Network Layer: 4-39
39
ISP: telecommunications or information service?
US Telecommunication Act of 1934 and 1996:
Title II: imposes “common carrier duties” on telecommunications services: reasonable rates, non-discrimination and requires regulation
Title I: applies to information services:
no common carrier duties (not regulated)
but grants FCC authority “… as may be necessary in the execution of its functions”4
Is an ISP a “telecommunications service” or an “information service” provider?
the answer really matters from a regulatory standpoint!
Network Layer: 4-40
40
Network layer: “data plane” roadmap
Network layer: overview
data plane
control plane
What’s inside a router
input ports, switching, output ports
buffer management, scheduling
IP: the Internet Protocol
datagram format
addressing
network address translation
IPv6
Generalized Forwarding, SDN
match+action
OpenFlow: match+action in action
Middleboxes
Network Layer: 4-41
41
Network Layer: Internet
host, router network layer functions:
IP protocol
datagram format
addressing
packet handling conventions
ICMP protocol
error reporting
router “signaling”
transport layer: TCP, UDP
link layer
physical layer
network
layer
forwarding
table
Path-selection algorithms: implemented in
routing protocols (OSPF, BGP)
SDN controller
Network Layer: 4-42
42
IP Datagram format
ver
length
32 bits
payload data
(variable length,
typically a TCP
or UDP segment)
16-bit identifier
header
checksum
time to
live
source IP address
head.
len
type of
service
flgs
fragment
offset
upper
layer
destination IP address
options (if any)
IP protocol version number
header length(bytes)
upper layer protocol (e.g., TCP or UDP)
total datagram
length (bytes)
“type” of service:
diffserv (0:5)
ECN (6:7)
fragmentation/
reassembly
TTL: remaining max hops
(decremented at each router)
20 bytes of TCP
20 bytes of IP
= 40 bytes + app layer overhead for TCP+IP
overhead
e.g., timestamp, record route taken
32-bit source IP address
32-bit destination IP address
header checksum
Maximum length: 64K bytes
Typically: 1500 bytes or less
Network Layer: 4-43
43
IP address: 32-bit identifier associated with each host or router interface
interface: connection between host/router and physical link
router’s typically have multiple interfaces
host typically has one or two interfaces (e.g., wired Ethernet, wireless 802.11)
IP addressing: introduction
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
223.1.1.1 = 11011111 00000001 00000001 00000001
223
1
1
1
dotted-decimal IP address notation:
Network Layer: 4-44
44
IP address: 32-bit identifier associated with each host or router interface
interface: connection between host/router and physical link
router’s typically have multiple interfaces
host typically has one or two interfaces (e.g., wired Ethernet, wireless 802.11)
IP addressing: introduction
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
223.1.1.1 = 11011111 00000001 00000001 00000001
223
1
1
1
dotted-decimal IP address notation:
Network Layer: 4-45
45
IP addressing: introduction
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
Q: how are interfaces actually connected?
A: wired
Ethernet interfaces connected by Ethernet switches
A: wireless WiFi interfaces connected by WiFi base station
For now: don’t need to worry about how one interface is connected to another (with no intervening router)
A: we’ll learn about that in chapters 6, 7
Network Layer: 4-46
46
Subnets
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
What’s a subnet ?
device interfaces that can physically reach each other without passing through an intervening router
network consisting of 3 subnets
IP addresses have structure:
subnet part: devices in same subnet have common high order bits
host part: remaining low order bits
Network Layer: 4-47
47
Subnets
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
Recipe for defining subnets:
detach each interface from its host or router, creating “islands” of isolated networks
each isolated network is called a subnet
subnet mask: /24
(high-order 24 bits: subnet part of IP address)
subnet
223.1.3.0/24
subnet 223.1.1.0/24
subnet 223.1.2.0/24
Network Layer: 4-48
48
Subnets
where are the subnets?
what are the /24 subnet addresses?
223.1.1.1
223.1.1.3
223.1.1.4
223.1.2.2
223.1.2.6
223.1.3.2
223.1.3.1
223.1.3.27
223.1.1.2
223.1.7.0
223.1.7.1
223.1.8.0
223.1.8.1
223.1.9.1
223.1.9.2
223.1.2.1
subnet 223.1.1/24
subnet 223.1.7/24
subnet 223.1.3/24
subnet 223.1.2/24
subnet 223.1.9/24
subnet 223.1.8/24
Network Layer: 4-49
49
IP addressing: CIDR
CIDR: Classless InterDomain Routing (pronounced “cider”)
subnet portion of address of arbitrary length
address format: a.b.c.d/x, where x is # bits in subnet portion of address
11001000 00010111 00010000 00000000
subnet
part
host
part
200.23.16.0/23
Network Layer: 4-50
50
IP addresses: how to get one?
That’s actually two questions:
Q: How does a host get IP address within its network (host part of address)?
Q: How does a network get IP address for itself (network part of address)
How does host get IP address?
hard-coded by sysadmin in config file (e.g., /etc/rc.config in UNIX)
DHCP: Dynamic Host Configuration Protocol: dynamically get address from as server
“plug-and-play”
Network Layer: 4-51
51
DHCP: Dynamic Host Configuration Protocol
goal: host dynamically obtains IP address from network server when it “joins” network
can renew its lease on address in use
allows reuse of addresses (only hold address while connected/on)
support for mobile users who join/leave network
DHCP overview:
host broadcasts DHCP discover msg [optional]
DHCP server responds with DHCP offer msg [optional]
host requests IP address: DHCP request msg
DHCP server sends address: DHCP ack msg
Network Layer: 4-52
52
DHCP client-server scenario
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4
223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2
223.1.3.1
223.1.3.27
DHCP server
223.1.2.5
arriving DHCP client needs
address in this network
Typically, DHCP server will be co-located in router, serving all subnets to which router is attached
Network Layer: 4-53
53
DHCP client-server scenario
DHCP server: 223.1.2.5
Arriving client
DHCP discover
src : 0.0.0.0, 68
dest.: 255.255.255.255,67
yiaddr: 0.0.0.0
transaction ID: 654
DHCP offer
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 654
lifetime: 3600 secs
DHCP request
src: 0.0.0.0, 68
dest:: 255.255.255.255, 67
yiaddrr: 223.1.2.4
transaction ID: 655
lifetime: 3600 secs
DHCP ACK
src: 223.1.2.5, 67
dest: 255.255.255.255, 68
yiaddrr: 223.1.2.4
transaction ID: 655
lifetime: 3600 secs
Broadcast: is there a DHCP server out there?
Broadcast: I’m a DHCP server! Here’s an IP address you can use
Broadcast: OK. I would like to use this IP address!
Broadcast: OK. You’ve got that IP address!
The two steps above can be skipped “if a client remembers and wishes to reuse a previously allocated network address” [RFC 2131]
Network Layer: 4-54
54
DHCP: more than IP addresses
DHCP can return more than just allocated IP address on subnet:
address of first-hop router for client
name and IP address of DNS sever
network mask (indicating network versus host portion of address)
Network Layer: 4-55
55
DHCP: example
Connecting laptop will use DHCP to get IP address, address of first-hop router, address of DNS server.
router with DHCP
server built into
router
DHCP REQUEST message encapsulated in UDP, encapsulated in IP, encapsulated in Ethernet
Ethernet frame broadcast (dest: FFFFFFFFFFFF) on LAN, received at router running DHCP server
Ethernet demux’ed to IP demux’ed, UDP demux’ed to DHCP
168.1.1.1
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP
DHCP
Network Layer: 4-56
56
DHCP: example
DCP server formulates DHCP ACK containing client’s IP address, IP address of first-hop router for client, name & IP address of DNS server
encapsulated DHCP server reply forwarded to client, demuxing up to DHCP at client
router with DHCP
server built into
router
DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP
client now knows its IP address, name and IP address of DNS server, IP address of its first-hop router
Network Layer: 4-57
57
IP addresses: how to get one?
Q: how does network get subnet part of IP address?
A: gets allocated portion of its provider ISP’s address space
ISP’s block 11001000 00010111 00010000 00000000 200.23.16.0/20
ISP can then allocate out its address space in 8 blocks:
Organization 0 11001000 00010111 00010000 00000000 200.23.16.0/23
Organization 1 11001000 00010111 00010010 00000000 200.23.18.0/23
Organization 2 11001000 00010111 00010100 00000000 200.23.20.0/23
… ….. …. ….
Organization 7 11001000 00010111 00011110 00000000 200.23.30.0/23
Network Layer: 4-58
58
Hierarchical addressing: route aggregation
“Send me anything
with addresses
beginning
200.23.16.0/20”
200.23.16.0/23
200.23.18.0/23
200.23.30.0/23
Fly-By-Night-ISP
Organization 0
Organization 7
Internet
Organization 1
ISPs-R-Us
“Send me anything
with addresses
beginning
199.31.0.0/16”
200.23.20.0/23
Organization 2
.
.
.
.
.
.
hierarchical addressing allows efficient advertisement of routing information:
Network Layer: 4-59
59
Hierarchical addressing: more specific routes
“Send me anything
with addresses
beginning
200.23.16.0/20”
200.23.16.0/23
200.23.30.0/23
Fly-By-Night-ISP
Organization 0
Organization 7
Internet
200.23.18.0/23
Organization 1
ISPs-R-Us
“Send me anything
with addresses
beginning
199.31.0.0/16”
200.23.20.0/23
Organization 2
.
.
.
.
.
.
Organization 1 moves from Fly-By-Night-ISP to ISPs-R-Us
ISPs-R-Us now advertises a more specific route to Organization 1
200.23.18.0/23
Organization 1
“or 200.23.18.0/23”
Network Layer: 4-60
60
Hierarchical addressing: more specific routes
“Send me anything
with addresses
beginning
200.23.16.0/20”
200.23.16.0/23
200.23.30.0/23
Fly-By-Night-ISP
Organization 0
Organization 7
Internet
ISPs-R-Us
“Send me anything
with addresses
beginning
199.31.0.0/16”
200.23.20.0/23
Organization 2
.
.
.
.
.
.
Organization 1 moves from Fly-By-Night-ISP to ISPs-R-Us
ISPs-R-Us now advertises a more specific route to Organization 1
200.23.18.0/23
Organization 1
“or 200.23.18.0/23”
Network Layer: 4-61
61
IP addressing: last words …
Q: how does an ISP get block of addresses?
A: ICANN: Internet Corporation for Assigned Names and Numbers http://www.icann.org/
allocates IP addresses, through 5 regional registries (RRs) (who may then allocate to local registries)
manages DNS root zone, including delegation of individual TLD (.com, .edu , …) management
Q: are there enough 32-bit IP addresses?
ICANN allocated last chunk of IPv4 addresses to RRs in 2011
NAT (next) helps IPv4 address space exhaustion
IPv6 has 128-bit address space
“Who the hell knew how much address space we needed?” Vint Cerf (reflecting on decision to make IPv4 address 32 bits long)
Network Layer: 4-62
62
Network layer: “data plane” roadmap
Network layer: overview
data plane
control plane
What’s inside a router
input ports, switching, output ports
buffer management, scheduling
IP: the Internet Protocol
datagram format
addressing
network address translation
IPv6
Generalized Forwarding, SDN
match+action
OpenFlow: match+action in action
Middleboxes
Network Layer: 4-63
63
10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.4
local network (e.g., home network) 10.0.0/24
138.76.29.7
rest of
Internet
NAT: network address translation
datagrams with source or destination in this network have 10.0.0/24 address for source, destination (as usual)
all datagrams leaving local network have same source NAT IP address: 138.76.29.7, but different source port numbers
NAT: all devices in local network share just one IPv4 address as far as outside world is concerned
Network Layer: 4-64
64
all devices in local network have 32-bit addresses in a “private” IP address space (10/8, 172.16/12, 192.168/16 prefixes) that can only be used in local network
advantages:
just one IP address needed from provider ISP for all devices
can change addresses of host in local network without notifying outside world
can change ISP without changing addresses of devices in local network
security: devices inside local net not directly addressable, visible by outside world
NAT: network address translation
Network Layer: 4-65
65
implementation: NAT router must (transparently):
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 address
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 destination fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table
NAT: network address translation
Network Layer: 4-66
66
NAT: network address translation
S: 10.0.0.1, 3345
D: 128.119.40.186, 80
1
10.0.0.4
138.76.29.7
1: host 10.0.0.1 sends datagram to 128.119.40.186, 80
NAT translation table
WAN side addr LAN side addr
138.76.29.7, 5001 10.0.0.1, 3345
…… ……
S: 128.119.40.186, 80
D: 10.0.0.1, 3345
4
S: 138.76.29.7, 5001
D: 128.119.40.186, 80
2
2: NAT router changes datagram source address from 10.0.0.1, 3345 to 138.76.29.7, 5001,
updates table
S: 128.119.40.186, 80
D: 138.76.29.7, 5001
3
3: reply arrives, destination address: 138.76.29.7, 5001
10.0.0.1
10.0.0.2
10.0.0.3
Network Layer: 4-67
67
NAT has been controversial:
routers “should” only process up to layer 3
address “shortage” should be solved by IPv6
violates end-to-end argument (port # manipulation by network-layer device)
NAT traversal: what if client wants to connect to server behind NAT?
but NAT is here to stay:
extensively used in home and institutional nets, 4G/5G cellular nets
NAT: network address translation
Network Layer: 4-68
68
initial motivation: 32-bit IPv4 address space would be completely allocated
additional motivation:
speed processing/forwarding: 40-byte fixed length header
enable different network-layer treatment of “flows”
IPv6: motivation
Network Layer: 4-69
69
IPv6 datagram format
payload (data)
destination address
(128 bits)
source address
(128 bits)
payload len
next hdr
hop limit
flow label
pri
ver
32 bits
priority: identify priority among datagrams in flow
flow label: identify datagrams in same “flow.” (concept of “flow” not well defined).
128-bit
IPv6 addresses
What’s missing (compared with IPv4):
no checksum (to speed processing at routers)
no fragmentation/reassembly
no options (available as upper-layer, next-header protocol at router)
Network Layer: 4-70
70
not all routers can be upgraded simultaneously
no “flag days”
how will network operate with mixed IPv4 and IPv6 routers?
Transition from IPv4 to IPv6
IPv4 source, dest addr
IPv4 header fields
IPv4 datagram
IPv6 datagram
IPv4 payload
UDP/TCP payload
IPv6 source dest addr
IPv6 header fields
tunneling: IPv6 datagram carried as payload in IPv4 datagram among IPv4 routers (“packet within a packet”)
tunneling used extensively in other contexts (4G/5G)
Network Layer: 4-71
71
Tunneling and encapsulation
Ethernet connecting two IPv6 routers:
Ethernet connects two IPv6 routers
A
B
IPv6
IPv6
E
F
IPv6
IPv6
Link-layer frame
IPv6 datagram
The usual: datagram as payload in link-layer frame
A
B
IPv6
IPv6/v4
E
F
IPv6/v4
IPv6
IPv4 network
IPv4 network connecting two IPv6 routers
Network Layer: 4-72
72
Tunneling and encapsulation
Ethernet connecting two IPv6 routers:
Ethernet connects two IPv6 routers
A
B
IPv6
IPv6
E
F
IPv6
IPv6
IPv4 tunnel connecting two IPv6 routers
IPv4 tunnel
connecting IPv6 routers
A
B
IPv6
E
F
IPv6
Link-layer frame
IPv6 datagram
The usual: datagram as payload in link-layer frame
IPv4 datagram
IPv6 datagram
tunneling: IPv6 datagram as payload in a IPv4 datagram
IPv6/v4
IPv6/v4
Network Layer: 4-73
73
B-to-C:
IPv6 inside
IPv4
Flow: X
Src: A
Dest: F
data
src:B
dest: E
Tunneling
physical view:
IPv4
IPv4
E
IPv6/v4
IPv6
F
C
D
A
B
IPv6
IPv6/v4
logical view:
IPv4 tunnel
connecting IPv6 routers
A
B
IPv6
IPv6/v4
E
F
IPv6/v4
IPv6
flow: X
src: A
dest: F
data
A-to-B:
IPv6
Flow: X
Src: A
Dest: F
data
src:B
dest: E
B-to-C:
IPv6 inside
IPv4
E-to-F:
IPv6
flow: X
src: A
dest: F
data
B-to-C:
IPv6 inside
IPv4
Flow: X
Src: A
Dest: F
data
src:B
dest: E
Note source and destination addresses!
Network Layer: 4-74
74
Google1: ~ 30% of clients access services via IPv6
NIST: 1/3 of all US government domains are IPv6 capable
IPv6: adoption
1 https://www.google.com/intl/en/ipv6/statistics.html
Network Layer: 4-75
75
Google1: ~ 30% of clients access services via IPv6
NIST: 1/3 of all US government domains are IPv6 capable
Long (long!) time for deployment, use
25 years and counting!
think of application-level changes in last 25 years: WWW, social media, streaming media, gaming, telepresence, …
Why?
IPv6: adoption
1 https://www.google.com/intl/en/ipv6/statistics.html
Network Layer: 4-76
76
Network layer: “data plane” roadmap
Network layer: overview
data plane
control plane
Generalized Forwarding, SDN
Match+action
OpenFlow: match+action in action
Middleboxes
Network Layer: 4-77
What’s inside a router
input ports, switching, output ports
buffer management, scheduling
IP: the Internet Protocol
datagram format
addressing
network address translation
IPv6
77
1
2
0111
3
values in arriving
packet header
Generalized forwarding: match plus action
Review: each router contains a forwarding table
“match plus action” abstraction: match bits in arriving packet, take action
generalized forwarding:
many header fields can determine action
many action possible: drop/copy/modify/log packet
forwarding table
(aka: flow table)
(aka: flow table)
destination-based forwarding: forward based on dest. IP address
Network Layer: 4-78
78
flow: defined by header field values (in link-, network-, transport-layer fields)
generalized forwarding: simple packet-handling rules
match: pattern values in packet header fields
actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller
priority: disambiguate overlapping patterns
counters: #bytes and #packets
Flow table abstraction
Router’s flow table define router’s match+action rules
Flow table
match
action
Network Layer: 4-79
79
flow: defined by header fields
generalized forwarding: simple packet-handling rules
match: pattern values in packet header fields
actions: for matched packet: drop, forward, modify, matched packet or send matched packet to controller
priority: disambiguate overlapping patterns
counters: #bytes and #packets
Flow table
match
action
1
2
3
4
* : wildcard
src=10.1.2.3, dest=*.*.*.* send to controller
src=1.2.*.*, dest=*.*.*.* drop
src = *.*.*.*, dest=3.4.*.* forward(2)
Flow table abstraction
Network Layer: 4-80
80
OpenFlow: flow table entries
Match
Action
Stats
Forward packet to port(s)
Drop packet
Modify fields in header(s)
Encapsulate and forward to controller
Packet + byte counters
Header fields to match:
Ingress Port
Src MAC
Dst MAC
Eth Type
VLAN
ID
IP
ToS
IP Proto
IP Src
IP Dst
TCP/UDP Src Port
VLAN
Pri
TCP/UDP Dst Port
Link layer
Network layer
Transport layer
Network Layer: 4-81
81
OpenFlow: examples
IP datagrams destined to IP address 51.6.0.8 should be forwarded to router output port 6
Block (do not forward) all datagrams destined to TCP port 22 (ssh port #)
Block (do not forward) all datagrams sent by host 128.119.1.1
Destination-based forwarding:
*
*
*
*
*
*
51.6.0.8
*
*
*
port6
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
s-port
TCP
d-port
Action
VLAN
Pri
IP
ToS
*
*
*
*
*
*
*
*
*
*
*
*
Firewall:
drop
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
s-port
TCP
d-port
Action
VLAN
Pri
IP
ToS
22
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
s-port
TCP
d-port
Action
VLAN
Pri
IP
ToS
*
*
*
*
*
*
*
*
*
*
drop
*
128.119.1.1
Network Layer: 4-82
82
OpenFlow: examples
Layer 2 destination-based forwarding:
layer 2 frames with destination MAC address 22:A7:23:11:E1:02 should be forwarded to output port 3
*
*
*
*
*
*
*
*
*
port3
22:A7:23:
11:E1:02
*
*
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
s-port
TCP
d-port
Action
VLAN
Pri
IP
ToS
Network Layer: 4-83
83
match+action: abstraction unifies different kinds of devices
OpenFlow abstraction
Router
match: longest destination IP prefix
action: forward out a link
Switch
match: destination MAC address
action: forward or flood
Firewall
match: IP addresses and TCP/UDP port numbers
action: permit or deny
NAT
match: IP address and port
action: rewrite address and port
Network Layer: 4-84
84
OpenFlow example
Host h1
10.1.0.1
Host h2
10.1.0.2
Host h4
10.2.0.4
Host h3
10.2.0.3
Host h5
10.3.0.5
s1
s2
s3
1
2
3
4
1
2
3
4
1
2
3
4
Host h6
10.3.0.6
controller
Orchestrated tables can create network-wide behavior, e.g.,:
datagrams from hosts h5 and h6 should be sent to h3 or h4, via s1 and from there to s2
Network Layer: 4-85
85
OpenFlow example
IP Src = 10.3.*.*
IP Dst = 10.2.*.*
forward(3)
match
action
ingress port = 2
IP Dst = 10.2.0.3
ingress port = 2
IP Dst = 10.2.0.4
forward(3)
match
action
forward(4)
ingress port = 1
IP Src = 10.3.*.*
IP Dst = 10.2.*.*
forward(4)
match
action
Host h1
10.1.0.1
Host h2
10.1.0.2
Host h4
10.2.0.4
Host h3
10.2.0.3
Host h5
10.3.0.5
s1
s2
s3
1
2
3
4
1
2
3
4
1
2
3
4
Host h6
10.3.0.6
controller
Orchestrated tables can create network-wide behavior, e.g.,:
datagrams from hosts h5 and h6 should be sent to h3 or h4, via s1 and from there to s2
Network Layer: 4-86
86
Generalized forwarding: summary
“match plus action” abstraction: match bits in arriving packet header(s) in any layers, take action
matching over many fields (link-, network-, transport-layer)
local actions: drop, forward, modify, or send matched packet to controller
“program” network-wide behaviors
simple form of “network programmability”
programmable, per-packet “processing”
historical roots: active networking
today: more generalized programming:
P4 (see p4.org).
Network Layer: 4-87
87
Network layer: “data plane” roadmap
Network Layer: 4-88
Network layer: overview
What’s inside a router
IP: the Internet Protocol
Generalized Forwarding
Middleboxes
middlebox functions
evolution, architectural principles of the Internet
88
Middleboxes
“any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host”
Middlebox (RFC 3234)
89
Middleboxes everywhere!
enterprise
network
national or global ISP
datacenter
network
NAT: home, cellular, institutional
Firewalls, IDS: corporate, institutional, service providers, ISPs
Load balancers: corporate, service provider, data center, mobile nets
Caches: service provider, mobile, CDNs
Application-specific: service providers, institutional, CDN
Middleboxes
initially: proprietary (closed) hardware solutions
move towards “whitebox” hardware implementing open API
move away from proprietary hardware solutions
programmable local actions via match+action
move towards innovation/differentiation in software
SDN: (logically) centralized control and configuration management often in private/public cloud
network functions virtualization (NFV): programmable services over white box networking, computation, storage
91
The IP hourglass
IP
TCP
UDP
HTTP
SMTP
QUIC
DASH
RTP
…
Ethernet
WiFi
Bluetooth
PPP
PDCP
…
copper radio fiber
Internet’s “thin waist”:
one network layer protocol: IP
must be implemented by every (billions) of Internet-connected devices
many protocols in physical, link, transport, and application layers
92
The IP hourglass, at middle age
IP
TCP
UDP
HTTP
SMTP
QUIC
DASH
RTP
…
Ethernet
WiFi
Bluetooth
PPP
PDCP
…
copper radio fiber
Internet’s middle age “love handles”?
middleboxes, operating inside the network
NAT
NFV
Firewalls
caching
93
Architectural Principles of the Internet
“Many members of the Internet community would argue that there is no architecture, but only a tradition, which was not written down for the first 25 years (or at least not by the IAB). However, in very general terms, the community believes that
RFC 1958
the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.”
Three cornerstone beliefs:
simple connectivity
IP protocol: that narrow waist
intelligence, complexity at network edge
94
The end-end argument
some network functionality (e.g., reliable data transfer, congestion) can be implemented in network, or at network edge
end-end implementation of reliable data transfer
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
network
link
physical
network
link
physical
network
link
physical
network
link
physical
network
link
physical
network
link
physical
hop-by-hop (in-network) implementation of reliable data transfer
95
The end-end argument
“The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
We call this line of reasoning against low-level function implementation the “end-to-end argument.”
Saltzer, Reed, Clark 1981
some network functionality (e.g., reliable data transfer, congestion) can be implemented in network, or at network edge
96
Where’s the intelligence?
20th century phone net:
intelligence/computing at network switches
Internet (pre-2005)
intelligence, computing at edge
Internet (post-2005)
programmable network devices
intelligence, computing, massive application-level infrastructure at edge
The 20th century phone network had dumb network endpoints, really by definition. The end points were rotary phones that maybe only your parents and grandparents remember; they weren’t computers. They really were dumb devices, and therefore the phone network had programmable switches that were quite smart. All functionality – well, all of the intelligence – was implemented within the network. It HAD to be. The end systems could not do anything more than send digits and send audio signals.
When the Internet came along, the endpoints and the switches were both programmable computers. So where to put the complexity? RFC 1958 – the architectural principles of the Internet RFC – that says “intelligence is end to end rather than hidden in the network.” That puts the intelligence clearly at the edge, like we see here. And that’s possible because the edge devices are smart; they’re programmable. Well that’s the diagram as I remember it 20 years ago.
And in the 20 years since, as we see the rise of middleboxes and SDN, we’re now seeing intelligence (in software) layered on top of “dumb” whiteboxes within the network. So I might add a brain here today. And with datacenters and content distribution networks, we see even smarter and more sophisticated application-level infrastructure being connected at points within the network. So now there are clearly much much bigger, much more computationally intensive and complex, endpoints if you will in today’s Internet
97
Question: how are forwarding tables (destination-based forwarding) or flow tables (generalized forwarding) computed?
Answer: by the control plane (next chapter)
Chapter 4: done!
Generalized Forwarding, SDN
Middleboxes
Network layer: overview
What’s inside a router
IP: the Internet Protocol
Additional Chapter 4 slides
Network Layer: 4-99
99
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 destination
IP header bits used to identify, order related fragments
IP fragmentation/reassembly
Network Layer: 4-100
fragmentation:
in: one large datagram
out: 3 smaller datagrams
reassembly
…
…
100
IP fragmentation/reassembly
Network Layer: 4-101
ID
=x
offset
=0
fragflag
=0
length
=4000
ID
=x
offset
=0
fragflag
=1
length
=1500
ID
=x
offset
=185
fragflag
=1
length
=1500
ID
=x
offset
=370
fragflag
=0
length
=1040
one large datagram becomes
several smaller datagrams
example:
4000 byte datagram
MTU = 1500 bytes
1480 bytes in
data field
offset =
1480/8
101
DHCP: Wireshark output (home LAN)
Network Layer: 4-102
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x6b3a11b7
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 192.168.1.101 (192.168.1.101)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 192.168.1.1 (192.168.1.1)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Wistron_23:68:8a (00:16:d3:23:68:8a)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP ACK
Option: (t=54,l=4) Server Identifier = 192.168.1.1
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (t=3,l=4) Router = 192.168.1.1
Option: (6) Domain Name Server
Length: 12; Value: 445747E2445749F244574092;
IP Address: 68.87.71.226;
IP Address: 68.87.73.242;
IP Address: 68.87.64.146
Option: (t=15,l=20) Domain Name = “hsd1.ma.comcast.net.”
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x6b3a11b7
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: Wistron_23:68:8a (00:16:d3:23:68:8a)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Option: (61) Client identifier
Length: 7; Value: 010016D323688A;
Hardware type: Ethernet
Client MAC address: Wistron_23:68:8a (00:16:d3:23:68:8a)
Option: (t=50,l=4) Requested IP Address = 192.168.1.101
Option: (t=12,l=5) Host Name = “nomad”
Option: (55) Parameter Request List
Length: 11; Value: 010F03062C2E2F1F21F92B
1 = Subnet Mask; 15 = Domain Name
3 = Router; 6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
……
reply
request
102
4.1 • OvERviEW Of NETWORK LAYER 309
tables. In this example, a routing algorithm runs in each and every router and both
forwarding and routing functions are contained within a router. As we’ll see in Sec-
tions 5.3 and 5.4, the routing algorithm function in one router communicates with
the routing algorithm function in other routers to compute the values for its forward-
ing table. How is this communication performed? By exchanging routing messages
containing routing information according to a routing protocol! We’ll cover routing
algorithms and protocols in Sections 5.2 through 5.4.
The distinct and different purposes of the forwarding and routing functions can
be further illustrated by considering the hypothetical (and unrealistic, but technically
feasible) case of a network in which all forwarding tables are configured directly by
human network operators physically present at the routers. In this case, no routing
protocols would be required! Of course, the human operators would need to interact
with each other to ensure that the forwarding tables were configured in such a way
that packets reached their intended destinations. It’s also likely that human configu-
ration would be more error-prone and much slower to respond to changes in the net-
work topology than a routing protocol. We’re thus fortunate that all networks have
both a forwarding and a routing function!
Values in arriving
packet’s header
1
2
3
Local forwarding
table
header
0100
0110
0111
1001
1101
3
2
2
1
output
Control plane
Data plane
Routing algorithm
Figure 4.2 ♦ Routing algorithms determine values in forward tables
M04_KURO4140_07_SE_C04.indd 309 11/02/16 3:14 PM
/docProps/thumbnail.jpeg