Show Lecture.Routing as a slide show.
CT320 Routing
Thanks to:
- Dr. Indrajit Ray, CSU
- Dr. James Walden, NKU
- Russ Wakefield, CSU
for the contents of these slides.
The Internet Network layer
Remember the layers?
- Application Layer
- Transport Layer
- Network Layer
- Data Link Layer
The Internet Network layer
Host, router network layer functions:
- IP protocol
- addressing conventions
- datagram format
- packet handling conventions
- Routing protocols
- ICMP protocol
- error reporting
- router “signaling”
IP Fragmentation & Reassembly
- Like a big text message
- Network links have MTU (max. transmission unit)
largest possible link-level frame.
- different link types, different MTUs
- Large IP datagram divided (“fragmented”) within net
- one datagram becomes several datagrams
- “reassembled” only at final destination
- IP header bits used to identify, order related fragments
- Fragmentation:
- in: one large datagram
- out: several smaller datagrams
IP Fragmentation and Reassembly Example
- 4000 byte datagram
- MTU = 1500 bytes (1480 bytes of data)
Original:
| length=4000 | ID | fragflag=0 | offset=0 | … |
Fragments:
| length=1500 | ID | fragflag=1 | offset=0 | … |
| length=1500 | ID | fragflag=1 | offset=185 | … |
| length=1040 | ID | fragflag=1 | offset=370 | … |
(185 = 1480 / 8)
Joke
(Well, it’s the setup to a joke.)
is to packet IP delivered An a bar …
An IP packet is delivered to a bar …
Hierarchical Addressing: Route Aggregation
How it’s not done:
┌─────────────┐ ┌────────┐ ┌────────┐ ┌──────────────┐
│ 192.0.2.4 │·······│ ISP #1 │ │ ISP #2 │·······│ 203.0.113.42 │
└─────────────┘ : └────────┘ └────────┘ : └──────────────┘
┌─────────────┐ : : : : ┌──────────────┐
│ 203.0.113.8 │···: : ┌──────────┐ : :···│ 192.0.2.88 │
└─────────────┘ : ···│ Internet │··· : └──────────────┘
┌─────────────┐ : └──────────┘ : ┌──────────────┐
│ 192.0.2.66 │···· : ····│ 203.0.113.17 │
└─────────────┘ : └──────────────┘
- ISP #1: “Internet, forward 192.0.2.4, 203.0.113.8, and 192.0.2.66 to me.”
- ISP #2: “Internet, forward 203.0.113.42, 192.0.2.88, and 203.0.113.17 to me.”
- Imagine if each ISP had thousands of customers!
Hierarchical Addressing: Route Aggregation
How it’s done:
┌────────────┐ ┌────────┐ ┌────────┐ ┌──────────────┐
│ 192.0.2.4 │·······│ ISP #1 │ │ ISP #2 │·······│ 203.0.113.42 │
└────────────┘ : └────────┘ └────────┘ : └──────────────┘
┌────────────┐ : : : : ┌──────────────┐
│ 192.0.2.88 │···: : ┌──────────┐ : :···│ 203.0.113.8 │
└────────────┘ : ···│ Internet │··· : └──────────────┘
┌────────────┐ : └──────────┘ : ┌──────────────┐
│ 192.0.2.66 │···· : ····│ 203.0.113.17 │
└────────────┘ : └──────────────┘
- ISP #1: “Internet, forward 192.0.2/24 to me.”
- ISP #2: “Internet, forward 203.0.113/24 to me.”
This scales nicely.
Hierarchical Addressing: More Specific Routes
┌────────────┐ ┌────────┐ ┌────────┐······················
│ 192.0.2.4 │·····│ ISP #1 │ │ ISP #2 │ :
└────────────┘ : └────────┘ └────────┘·: ┌──────────────┐ : ┌────────────┐
┌────────────┐ : : : :··│ 203.0.113.42 │ ···│ 192.0.2.11 │
│ 192.0.2.88 │··: : ┌──────────┐ : : └──────────────┘ : └────────────┘
└────────────┘ : ···│ Internet │·· : ┌──────────────┐ : ┌────────────┐
┌────────────┐ : └──────────┘ :··│ 203.0.113.8 │ :··│ 192.0.2.22 │
│ 192.0.2.66 │··· : : └──────────────┘ : └────────────┘
└────────────┘ : : ┌──────────────┐ : ┌────────────┐
···│ 203.0.113.17 │ ···│ 192.0.2.97 │
└──────────────┘ └────────────┘
- ISP #1: “Internet, forward 192.0.2/24 to me.”
- ISP #2: “Internet, forward 203.0.113/24 and 192.0.2/24 to me.”
Hierarchical Addressing
- Without hierarchical addressing, top-level routers would have
to know the location of every host in the world.
- With hierarchical addressing, top-level routers only have to
know where big hunks of hosts are.
- It’s a lot easier to treat all of CSU as one entity, as opposed
to having sixty-five thousand entries for all the possible CSU hosts.
- Now, imagine how many hosts NASA has. Or HP. Or the Pentagon.
- Phone call routing used to work this way,
until everything got all mobile.
IP Addressing: ICANN
- How does an ISP get block of addresses?
- ICANN: Internet Corporation for
Assigned Names and Numbers
- allocates addresses
- manages DNS
- assigns domain names, resolves disputes
Addressing at CSU
- All of CSU is 129.82/16
- That’s more than sixty-five thousand possible hosts.
- Does the CSU main router have to have sixty-five thousand entries?
- This is the same problem as we have at the top level of the internet.
- So, use the same solution!
Hierarchy at CSU
- Hierarchy saves the day again!
- Groups within CSU get blocks within CSU’s 129.82/16:
- 129.82.28/22 Morgan Library
- 129.82.40/22 College of Business
- 129.82.44/23 Computer Science
- 129.82.48/22 Atmospheric Science
- 129.82.76/22 Chemistry
- 129.82.220/22 Lory Student Center
- 129.82.224/21 Engineering (more than CS!?)
- wait—how is /21 more than /23?
- and scores more, but not thousands more.
- ICANN neither knows nor cares about this.
Hierarchy at CSU
┌───────────────┐ ┌──────────┐ ┌────────┐ ┌───────────────┐
│ 129.82.40.123 │·····│ Business │ │ CS │·····│ 129.82.44.12 │
└───────────────┘ : └──────────┘ └────────┘ : └───────────────┘
┌───────────────┐ : : ┌────────────┐ : : ┌───────────────┐
│ 129.82.43.4 │··: ····│ CSU router │···· :··│ 129.82.45.85 │
└───────────────┘ : └────────────┘ : └───────────────┘
┌───────────────┐ : : : ┌───────────────┐
│ 129.82.42.66 │··· ┌────────────┐ ···│ 129.82.45.234 │
└───────────────┘ │ FRGP │ └───────────────┘
└────────────┘
- The CSU router doesn’t need 65 000-some entries, just one per
subnet: one for Business, one for CS, one for Engineering, etc.
- When the Business School adds another computer, the CSU router doesn’t
have to be updated, since the new computer is within 129.82.40/22.
- CSUs connects to the Internet via
Front Range GigaPop, costing >$160 000 in 2017.
IP datagram format, redux
| 0
| 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
| 10
| 11
| 12
| 13
| 14
| 15
| 16
| 17
| 18
| 19
| 20
| 21
| 22
| 23
| 24
| 25
| 26
| 27
| 28
| 29
| 30
| 31
|
| Version
| IHL
| Type of service
| Total length
|
| Identification
| Flags
| Fragment offset
|
| Time to live
| Protocol
| Header checksum
|
| Source IP address
|
| Destination IP address
|
| Options (optional)
|
| IP data payload (many bytes)
|
ICMP: Internet Control Message Protocol
| Type | Code | Description |
|---|
| 0 | 0 | echo reply (ping) |
| 3 | 0 | dest network unreachable |
| 3 | 1 | dest host unreachable |
| 3 | 2 | dest protocol unreachable |
| 3 | 3 | dest port unreachable |
| 3 | 6 | dest network unknown |
| 3 | 7 | dest host unknown |
| 8 | 0 | echo request (ping) |
| 9 | 0 | router advertisement |
- used by hosts & routers to communicate network-level information
- error reporting: unreachable host, network, port, protocol
- echo request/reply (used by ping)
- network-layer “above” IP:
- ICMP msgs carried in IP datagrams
- ICMP message: type, code plus first 8 bytes of IP datagram
causing error
Ping
- Create an IP packet with type=8, code=0.
- Send it to the destination
- Destination will create an IP packet with type=0, code=0,
and send it back.
Ping examples
$ ping -c1 google.com
PING google.com (142.250.72.14) 56(84) bytes of data.
64 bytes from den08s06-in-f14.1e100.net (142.250.72.14): icmp_seq=1 ttl=117 time=2.94 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.942/2.942/2.942/0.000 ms
$ ping -c1 tuba
PING tuba.cs.colostate.edu (10.1.44.62) 56(84) bytes of data.
64 bytes from tuba.cs.colostate.edu (10.1.44.62): icmp_seq=1 ttl=63 time=2.66 ms
--- tuba.cs.colostate.edu ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.662/2.662/2.662/0.000 ms
Traceroute and ICMP
- Source sends series of UDP packets to dest
- First has TTL=1, second has TTL=2, third has TTL=3, etc.
- Unlikely port number
- When nth datagram arrives at the nth router:
- Router discards datagram, because we ran out of TTL hops
- Sends back an ICMP message packet (type 11, code 0), “too many hops”
- Message includes name of source router & IP address
- When a packet actually gets to the destination:
- Destination returns ICMP “port unreachable” (type 3, code 3)
- When source gets this ICMP, stops.
- This all assumes that routing is consistent—what about anycast?