Download Internetworking

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

IEEE 802.1aq wikipedia , lookup

RapidIO wikipedia , lookup

Peering wikipedia , lookup

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

Point-to-Point Protocol over Ethernet wikipedia , lookup

Net bias wikipedia , lookup

AppleTalk wikipedia , lookup

IEEE 1355 wikipedia , lookup

Internet protocol suite wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Distributed firewall wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Deep packet inspection wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Network tap wikipedia , lookup

Computer network wikipedia , lookup

Airborne Networking wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Packet switching wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Real-Time Messaging Protocol wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Transcript
Chapter 4: Internetworking
Spring 2010
CS 332
1
Assumptions
• Data pipe from every machine to every other
machine.
– Need not be single link.
– Pipe can lose or corrupt messages.
• Sender/receiver may be on different physical
networks, using different technology
• So what info do we need to build a single
“logical” network (either reliable or unreliable)?
Spring 2010
CS 332
2
Issues
• Getting various technologies to work with one
another (i.e. creating a single “network” from
many heterogeneous systems).
– Problem magnified since packet may need to traverse
several different networks (and network technologies),
each with their own addressing schemes, service
models, media access protocols, etc.
• Scale: It’s the big issue
– How can you find an efficient path through a network
with millions (and perhaps billions eventually) of
nodes?
– How do you provide addressing for a network with this
many nodes?
Spring 2010
CS 332
3
Internetwork
• Arbitrary collection of possibly heterogeneous
networks interconnected to provide host-to-host
packet delivery service.
• Network: Directly connected or switched network
that uses a single technology (i.e. ATM, 802.5,
Ethernet).
– Could be many physical networks creating a single
logical network.
Spring 2010
CS 332
4
Internetwork
• Internet—THE internetwork.
–
–
–
–
Runs the Internet Protocol (IP or Kahn-Cerf)
Interesting because it has faced the problems of scale
Experimental versions 1977 – 1981
IPv4 first deployed in 1981
• internet—abstract internetwork
Spring 2010
CS 332
5
IP is a big deal
White House News & Policies photo
• Vint Cerf and Bob Kahn with Pres. Bush at 2006
ceremony where they received the Presidential Medal of
Freedom for their work on IP.
Spring 2010
CS 332
6
IP Internet
• Concatenation of Networks
Spring 2010
CS 332
Note Hn denotes host,
Rn denotes router.
7
IP Internet
• Protocol Stack
H1
H8
TCP
R1
IP
IP
ETH
Spring 2010
R2
ETH
R3
IP
FDDI
FDDI
IP
PPP
CS 332
PPP
TCP
IP
ETH
ETH
8
The Internet
Outline
Best Effort Service Model
Global Addressing Scheme
Spring 2010
CS 332
9
Service Model
• Connectionless (datagram-based)
– So each packet must be “self-contained”
• Best-effort delivery (unreliable service)
–
–
–
–
Spring 2010
packets are lost
packets are delivered out of order
duplicate copies of a packet are delivered (?!)
packets can be delayed for a long time
CS 332
10
Why?!
• Best Effort service model is simple as it gets –
intentionally!
– If you provide best effort service over a network
technology that provides reliable delivery, you’re fine
– Providing reliable delivery over an unreliable network
means extra functionality in the routers
– Keeping the routers as simple as possible was an IP
design goal. (Why?)
• Note: IP today runs over many technologies that
were not in existence when IP was invented!
Spring 2010
CS 332
11
Note: fields
aligned on
32 bit
boundaries 0
IP Datagram Format
In 32 bit words
In bytes
4
V ersion
8
HLen
16
TOS
31
Length
Ident
TTL
19
Flags
Protocol
Offset
Checksum
SourceAddr
DestinationAddr
Pad
(variable)
Options (variable)
Data
Spring 2010
CS 332
12
Fields
• Version: note placement at front of packet (why?)
• Header Length: in 32 bit words (20 bytes when no
options)
• Type of service: later
• Length: of entire packet in bytes (note max of
65,535 bytes because of 16 bit length field)
• Ident, flags, offset all deal with fragmentation
• Time to live: first seconds, but evolved to be hop
count
Spring 2010
CS 332
13
Fields
• Protocol: demux key specifying higher level protocol that
gets datagram
• Checksum: take IP header as sequence of 16 bit words, add
them using ones complement, take ones complement of
result.
– Relatively easy to calculate in software
– Not as strong error detection as CRC
– Bad packets discarded by router (potential bad dest. addr.)
• Src, dest address: pretty clear (and these are unique!)
• Options: rare, but complete IP implementation must handle
them all! Presence determined by header length field
Spring 2010
CS 332
14
Fragmentation and Reassembly
• Each network has some MTU (why not uniform?)
– Why not some uniform standard?
– What is a reasonable choice for a given host?
• Strategy
–
–
–
–
–
–
fragment when necessary (MTU < Datagram length)
try to avoid fragmentation at source host
re-fragmentation is possible
fragments are self-contained datagrams
delay reassembly until destination host
do not recover from lost fragments
Spring 2010
CS 332
15
Fragmentation and Reassembly
Header fields used in F &R (bits in parens)
• Ident field (16): chosen by sending host, intended
to be unique among all datagrams that might be
received at this dest from this source over
reasonable time period.
– All fragments keep this same ident value
• Offset (13): specifies 8 byte chunks of data (Why?
And why not fragment #?)
• Flags: M is “more” flag
Spring 2010
CS 332
16
Example
Start of header
Ident= x
0
Offset= 0
Rest of header
1400 data bytes
MTU 532 bytes
Start of header
Ident= x
H1
R1
R2
R3
H8
1
Offset= 0
Rest of header
512 data bytes
Start of header
ETH IP (1400)
FDDI IP (1400)
PPP IP (512)
ETH IP (512)
PPP IP (512)
ETH IP (512)
Rest of header
PPP IP (376)
ETH IP (376)
512 data bytes
Ident= x
1 Offset= 512
Start of header
Ident= x
Note: fragmentation can occur
at multiple hops!
Spring 2010
0 Offset= 1024
Rest of header
376 data bytes
CS 332
17
Global Addresses
• Properties
– globally unique (don’t want anyone with my phone #)
• Why not just use Ethernet address?!
– hierarchical: network + host (really interface)
• Dot Notation
– 10.3.2.4
– 128.96.33.81
– 192.12.69.77
A:
B:
C:
Spring 2010
0
7
24
Network
Host
1 0
1 1 0
CS 332
14
16
Network
Host
21
8
Network
Host
18
IP Internet
Note Hn denotes host,
Rn denotes router.
Routers need two
IP addresses.
All hosts on same
network have same
network part of
IP address
Spring 2010
CS 332
19
Terminology
•
•
Routing Mechanism: How a router selects the
link over which to forward a packet
Routing Protocol: Policies that determine what is
placed in the routing tables.
These are not the same thing!
Spring 2010
CS 332
20
Datagram Forwarding
• Strategy
– every datagram contains destination’s address
– if directly connected to destination network, then forward
to host
– if not directly connected to destination network, then
forward to some router
– forwarding table maps network number into next hop
– each host has a default router
– each router maintains a forwarding table
• Example (R2)
Spring 2010
Network Number
1
2
3
4
CS 332
Next Hop
R3
R1
interface 1
interface 0
21
Recall:
Network 1 (Ethernet)
H7
H2
H1
R3
H8
H3
Network 4
(point-to-point)
Network 2 (Ethernet)
R1
R2
H4
Network 3 (FDDI)
H5
Spring 2010
H6
CS 332
22
Pseudocode
if (networknum dest = networknum my interface)
deliver packet over that interface
else
if (networknum in my routing table)
deliver packet to next hop router
else
deliver packet to default router
Spring 2010
CS 332
23
Address Translation
• Map IP addresses into physical addresses
– destination host
– next hop router
– Why not just broadcast it? (E.g. if physical network is
Ethernet).
• Techniques
– encode physical address in host part of IP address
– table-based
• ARP
–
–
–
–
table of IP to physical address bindings
broadcast request if IP address not in table
target machine responds with its physical address
table entries are discarded if not refreshed
Spring 2010
CS 332
24
ARP Details
• Request Format
– HardwareType: type of physical network (e.g., Ethernet)
– ProtocolType: type of higher layer protocol (e.g., IP)
– HLEN & PLEN: length of physical and protocol addresses
• Stands for “hardware address length” and “protocol address length”
– Operation: request or response
– Source/Target-Physical/Protocol addresses
• Notes
–
–
–
–
table entries timeout in about 15 minutes (why?)
update table with source when you are the target (why?)
"refresh" table if already have an entry (i.e. reset timeout)
do not refresh table entries upon reference
Spring 2010
CS 332
25
ARP Packet Format
0
8
16
Hardware type = 1
HLen = 48
31
ProtocolT ype = 0x0800
PLen = 32
Operation
SourceHardwareAddr (bytes 0 – 3)
SourceHardwareAddr (bytes 4 – 5) SourceProtocolAddr (bytes 0 – 1)
SourceProtocolAddr (bytes 2 – 3) TargetHardwareAddr (bytes 0 – 1)
TargetHardwareAddr (bytes 2 – 5)
TargetProtocolAddr (bytes 0 – 3)
Spring 2010
CS 332
26
Dynamic Host Configuration
Protocol (DHCP)
• Manually configuring IP information can be hard
– Large networks
– Configuration process error prone
• Every host needs correct network number
• No two hosts can have same IP address
• DHCP automates process
– Network management has to scale, too – not just
network operation
Spring 2010
CS 332
27
DHCP (continued)
• At least one DHCP server per administrative domain
– Centralized repository for host configuration info
• Info can be sent to hosts at boot or connection time.
• Can also be used to maintain pool of available addresses assigned on
demand
• Method
–
–
–
–
–
Send DHCPDISCOVER msg to 255.255.255.255.
Response is DHCP Offer message – also broadcast (why?)
Host chooses one of offers and sends Reply and gets Ack
Host "leases" IP address for a period of time – can renew
Relay agents
Spring 2010
CS 332
28
Internet Control Message Protocol
(ICMP)
• Communicates error messages and other
conditions that require attention
• ICMP messages are acted on by either the IP layer
or higher layers (TCP or UDP).
• Transmitted within IP datagrams
0
7 8
type
15 16
code
31
checksum
Contents depends on type and code
Spring 2010
CS 332
29
ICMP (cont.)
• 15 different values for the type field, then several
codes for each of the types
• Checksum computed same as for IP packet
• Contains first 8 bytes of IP datagram that
generated the message so sender can ID
• Complete specification of protocol is RFC 792
(Postel)
• Another good source is TCP/IP Illustrated, Vol. 1,
Ch. 6
Spring 2010
CS 332
30
Types of ICMP Messages
•
•
•
•
•
•
•
Echo (ping)
Redirect (from router to source host)
Destination unreachable (protocol, port, or host)
TTL exceeded (so datagrams don’t cycle forever)
Checksum failed
Reassembly failed
Cannot fragment
Spring 2010
CS 332
31
Virtual Private Networks (VPNs)
• Goal: simulate private network of dedicated links
on a public (shared) network
• Easy on circuit-switched infrastructure
• Not so easy on IP-based internetwork
• Strategy: routers create an IP "tunnel" for VPN
traffic.
Spring 2010
CS 332
32
IP Tunneling
• Router R1 at one end of tunnel is provided with IP address
of router R2 at the other end.
• R1 is directly connected to the network where the host that
requested the tunnel lives.
• R2 is directly connected to the network where the
destination host lives.
• All VPN traffic is encapsulated as IP packets from R1 to
R2 (this is not the norm)
• R2 strips tunnel header and forwards packet to ultimate
recipient.
Spring 2010
CS 332
33
Tunnel implementation
Routing table
for router R1:
Spring 2010
NetworkNum
1
2
NextHop
Interface 0
Virtual interface 0
Default
Interface 1
CS 332
34
What is it good for?
• Security – tunnel plus encryption
• Using routers that have enhanced capabilities, e.g.
multicast
• Tunneling other protocols across IP
• Short-circuiting normal routing – useful for
mobility
Spring 2010
CS 332
35