CS计算机代考程序代写 dns DHCP cache assembly algorithm PowerPoint Presentation

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

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

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

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

network
link
physical

Network Layer: 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

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

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

Software-Defined Networking (SDN) control plane
Remote controller computes, installs forwarding tables in routers

data
plane
control
plane

Remote Controller

CA
1
2

0111

3
values in arriving
packet header
Network Layer: 4-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

Network-layer service model
Network
Architecture

Internet

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

yes

possibly
Order

yes

possibly
Timing

yes

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

Network-layer service model
Network
Architecture

Internet

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

yes

possibly
Order

yes

possibly
Timing

yes

no
Quality of Service (QoS) Guarantees ?

Network Layer: 4-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

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

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

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

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

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

Longest prefix matching

Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001

match!
Network Layer: 4-19

Longest prefix matching

Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001

match!
Network Layer: 4-20

Longest prefix matching

Link interface
0
1
2
3
11001000 00010111 00011000 10101010
examples:
which interface?
which interface?
********
***
********
***
********
11001000 00010111 00010110 10100001

match!
Network Layer: 4-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

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

Switching fabrics

bus

memory
memory

interconnection
network

three major types of switching fabrics:
transfer packet from input link to appropriate output link

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

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

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

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

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

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

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

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
.

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!

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)

queue
(waiting area)
packet
arrivals
packet
departures
link
(server)
Abstraction: queue
R
Network Layer: 4-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

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

5
arrivals
departures
packet in service
send packet from highest priority queue that has buffered packets
FCFS within priority class

5
Network Layer: 4-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

Weighted Fair Queuing (WFQ):
generalized Round Robin
Scheduling policies: weighted fair queueing

classify
arrivals
departures

link
R

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

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

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

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

Generalized Forwarding, SDN
match+action
OpenFlow: match+action in action
Middleboxes

Network Layer: 4-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
UDP
IP
Eth
Phy

DHCP

Network Layer: 4-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
UDP
IP
Eth
Phy

DHCP

DHCP
UDP
IP
Eth
Phy

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

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

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

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

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

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

Generalized Forwarding, SDN
match+action
OpenFlow: match+action in action
Middleboxes

Network Layer: 4-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
2

0111

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

network
link
physical

hop-by-hop (in-network) implementation of reliable data transfer

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

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

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

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

Related Posts