Transcript Network Architecture (R02) - L1 Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1213/R02/ Course Structure 16 Lectures several guest slots -        Yury Audzivich - router h/w algorithmics Christos Efstrathiou - sensor/mobile.

Network Architecture (R02) - L1
Jon Crowcroft,
http://www.cl.cam.ac.uk/~jac22
http://www.cl.cam.ac.uk/teaching/1213/R02/
Course Structure
16 Lectures
several guest slots -







Yury Audzivich - router h/w algorithmics
Christos Efstrathiou - sensor/mobile net arch
Dirk Trossen - pub/sub in the net
Hamed Haddadi - topology over time
Sue Moon – Packet Shader
Participation by you





Reading &
Critique-ing papers
See “How to read a paper” by Keshav
http://www.sigcomm.org/ccr/drupal/files/p83-keshavA.pdf
Course Assessment

Your involvement each week


3 essays - compare/contrast





Alternate me present & you all contribute
Due dates
Nov 2,
Nov 30,
start of next term (Jan 18)
An annotated bibligraphy

At start of next term, but update each week
Workload

Read 1-2 papers per week




Plus scan related material
Keep notes
Feel free to ask me more
Essays can be



2-4 pages
Note form is fine
References/citing source material essential
Review of Internet Architecture
•
Packet switching
•
•
Datagram Network
•
•
(video download can be faster than viewing)
“Stateless”
•
•
No set up - fast for transactions
Work Conserving
•
•
No circuit, virtual or otherwise
(end and router don’t share state)
(max pkt size unchanged for 30 yrs!)
Parsimony

End to end model


(clark et al)
Cautious Sender


Forgiving Receiver
(postel principle)
Many different kinds
of applications
and
higher-level
protocols
IP
Many different
kinds
of networks
The “Hourglass Model”,
Steve Deering
IP packet
Vers H. Len
TOS
Total Length
Identification
Flags Fragment Offset
Time to live Protocol
Header Checksum
Source IP Address
Destination IP Address
IP Options (if any)
Padding
Data
IP Address & Forwarding



Based on destination address (32 bits!)

Not source (why is it there?)

May change (or fail) somewhere along path
Forwarding is “hop by hop”
Address should be “where” something is




Route is “how to get there”


an interface of a host (can have lots)
IP has several roles, conflated
Routing Hint, Interface Id, Part of Flow State… …
Computed seperately, continuously and
asynchronously
Names (see later) are “what” something is
Two components of routing

Control component




Decides where the
packets will go
Use a set of routing
protocols (e.g. OSPF, BGP)
to collect information and
produce a “forwarding
table”
“Control plane”
routes
Routing “daemon”
collect routing info
and maintain
routing DB
kernel
Forwarding
table
Forwarding component


Moving packets from input
to output ports according
to forwarding table and
packet header
“Forwarding plane”
packets Forwarding
algorithm and
mechanism
Address Matching

Packet forwarding requires

Address matching
Followed by table lookup of output port

Moving the packet through the router (from input
port to output port)
This involves scheduling, queueing, design of switch fabric
etc, conventional aspects of switch design

Address matching

Exact matching
e.g. bridge forwarding, DECnet, OSI/CLNP…

Longest prefix match – “best matching”
IP networks
Exact match


Easier
Software approach:



Binary search
Hash function
Hardware: Content Addressable
Memory (CAM)
Longest prefix match




IP addresses are assigned in a manner that
reflect network topology
Address aggregation: group destinations with
the same prefix together if they exit the
same output port
Therefore, longer prefixes tend to be
announced by customers ISPs who are closer
to the destination, whereas provider ISPs
tend to announce aggregated addresses
Hence a route to the longest prefix match is
preferred
Example to show why “longest
prefix match” is better
Forwarding
table
BGP route
advertisement for
1.2.3/24
ISP B
(provider of ISP A)
ISP C
Peer relationship
(provider of ISP A)
Forwarding
table
1.2.3/24
1.2.3/24
1.2.3.123/26
BGP route
advertisement for
1.2.3.123/26
BGP route
advertisement for
1.2.3.123/26
Longer
prefix is a
better route!
ISP A
Subnet
1.2.3.123/26
Example

Each entry in forwarding table has address +
prefix e.g.
Longest
match
address: 11001111 01011100 00000000 10000111
mask: 11111111 11111111 11111111 11111111
address: 11001111 01011100 00000000 00000000
mask: 11111111 11111111 00000000 00000000
address: 11001111 01011100 00000000 00000000
mask: 11111111 11111111 11100000 00000000
11001111 01011100 00000000 10000111
matches with all three entries
How to do Longest Prefix Match


Not as easy as exact match
Approaches:





Create a data structure for doing LPM
Convert the problem into a form so that we can do
binary search
Reduce the problem to a sequence of exact match
problems which we can apply hashing
Optimization based on distribution of prefix
lengths
Combine software and hardware techniques
Algorithms
There is an entire industry of algorithms:

Binary search among all prefixes in forwarding
table
Perlman’s book, 13.4
Lampson et al “IP Lookups using Multiway and Multicolumn
Search”, IEEE Infocom 1998

Trie: bit-by-bit match
Perlman’s book, 13.3

Binary search based on prefix length
Perlman’s book, 13.3.3
Waldvogel et al “Scalable High Speed IP Routing Lookups”,
Sigcomm 1997
But this is all going wrong! Why?

Not enough bits -> NATs…



Four M’s (historical order)





Multicast
Mobility
Multihoming
Multipath
Security and Social Scale



NAT Traversal, Stateful browser/server
end is URL + Persistent HTTP state + cookie!
Unsolicited traffic
Byzantine (v. selfish or rational or altruistic)
Despite original ARPANET packet radio


And multicast since 1988,
Hierarchy is wrong
So Ipng effort started in 1992

See course web site for papers!



Specification of desiderata
Led to a set of competing efforts
Look at SIP & PIP



Represent extremes of
CS (SIP) & Telco (PIP)
SIP from PARC looks XNS


Just ip with more address bits
PIP looks VC/ATM ish…

QoS, fancy routing options
Eventually, converged on IPv6



Committee design (SIP/PIP/Novell)
Overtaken by reality ?
Four M’s (current order)






New requirements
Receiver control of input



Multihoming - killing aggregation
Mobility (smart phones roaming and receiving IP)
Multipath (load balance, but how to id sub-flow)
Multicast - sidelined?
New kinds of bad guys
Authentic addresses (HIP)
New content type (video “interest”)
Next week…



Monday 15th oct: Two of you will be
speaking (Ben Confino & Ionel Gog on
Plutarch and Haggle, respectively)
Wednesday 17th oct: I’ll set the first
essay and discuss topic #2
Remember the assignments for speaking
are online if you want to look ahead…