Internetworking€¦ · • Network layer is first end-to-end layer in the OSI reference model •...
Transcript of Internetworking€¦ · • Network layer is first end-to-end layer in the OSI reference model •...
Colin Perkins | https://csperkins.org/ | Copyright © 2017 | This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
Internetworking
Networked Systems (H) Lecture 7
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Role of the Network Layer
2
Data Link
Network
Transport
Session
Presentation
Application
Data Link
Network
Transport
Session
Presentation
Application
Data Link Data Link
Physical Physical
End System End SystemHub
Network Network
• Network layer is first end-to-end layer in the OSI reference model
• Responsible for end-to-end delivery of data: • Across multiple link-layer hops and technologies
• Across multiple autonomous systems
• Building an Internet: a set of interconnected networks
Colin Perkins | https://csperkins.org/ | Copyright © 2017
An internet comprises a set of interconnected networks
Interconnecting Networks
Host Host Host
Ethernet
Local ISP
Regional ISP
Tier-1 ISP
End Site
Each network administered separately – an autonomous system (AS) – making independent policy and technology choices
3
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Components of an Internet
• A common end-to-end network protocol • Provide a single seamless service to transport layer
• Delivery of data packets/provisioning of circuits
• Addressing of end systems
• A set of gateway devices (a.k.a. routers) • Implement the common network protocol
• Hide differences in link layer technologies • Framing, addressing, flow control, error detection and correction
• Desire to perform the least amount of translation necessary
4
Colin Perkins | https://csperkins.org/ | Copyright © 2017
The Internet
• The globally interconnected networks running the Internet Protocol (IP) • Initial design by Vint Cerf and Robert Kahn, 1974
• IP provides an abstraction layer • Transport protocols and applications above
• Assorted data link technologies and physical links below
• A simple, best effort, connectionless, packet delivery service
• Addressing, routing, fragmentation and reassembly
Vint Cerf
Sou
rce:
IEE
E
Robert Kahn
Sou
rce:
IEE
E
© 1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974
[9] S. Carr, S. Crocker, and V. Cerf, “HOST-HOST
Communication Protocol In the ARPA Network,” in
Spring Joint Computer Conf., AFIPS Conf. Proc., vol.
36. Montvale, N.J.: AFIPS Press, 1970, pp. 589-597.
[10] A. McKenzie, “HOST/HOST protocol for the ARPA
network,” in Current Network Protocols, Network
Information Cen., Menlo Park, Calif., NIC 8246, Jan.
1972.
[11] L. Pouzin, “Address format in Mitranet,” NIC 14497,
INWG 20, Jan. 1973.
[12] D. Walden, “A system for interprocess
communication in a resource sharing computer
network,” Commun. Ass. Comput. Mach., vol. 15, pp.
221-230, Apr. 1972.
[13] B. Lampson, “A scheduling philosophy for
multiprocessing system,” Commun. Ass. Comput.
Mach., vol. 11, pp. 347-360, May 1968.
[14] F. E. Heart, R. E. Kahn, S. Ornstein, W. Crowther,
and D. Walden, “The interface message processor for
the ARPA computer network,” in Proc. Spring Joint
Computer Conf., AFIPS Conf. Proc., vol. 36.
Montvale, N.J.: AFIPS Press, 1970, pp. 551-567.
[15] N. G. Anslow and J. Hanscoff, “Implementation of
international data exchange networks,” in Computer
Communications: Impacts and Implications, S.
Winkler, Ed. Washington, D. C., 1972, pp. 181-184.
[16] A. McKenzie, “HOST/HOST protocol design
considerations,” INWG Note 16, NIC 13879, Jan.
1973.
[17] R. E. Kahn, “Resource-sharing computer
communication networks”, Proc. IEEE, vol. 60, pp.
1397-1407, Nov. 1972.
[18] Bolt, Beranek, and Newman, “Specification for the
interconnection of a host and an IMP,” Bolt Beranek
and Newman, Inc., Cambridge, Mass., BBN Rep.
1822 (revised), Apr. 1973.
Vinton G. Cerf was born in New Haven,
Conn., in 1943. He did undergraduate work in
mathematics at Stanford University,
Stanford, Calif., and received the Ph.D.
degree in computer science from the
University of California at Los Angeles, Los
Angeles, Calif., in 1972.
He was with IBM in Los Angeles from 1965
through 1967 and consulted and/or worked
part time at UCLA from 1967 through 1972.
Currently he is Assistant Professor of
Computer Science and Electrical Engineering
at Stanford University, and consultant to
Cabledata Associates. Most of his current
research is supported by the Defense Advanced Research Projects Agency
and by the National Science Foundation on the technology and economics
of computer networking. He is Chairman of IFIP TC6.1, an international
network working group which is studying the problem of packet network
interconnection.
Robert E. Kahn (M’65) was born in
Brooklyn, N.Y., on December 23 1938. He
received the B.E.E. degree from the City
College of New York, New York, in 1960,
and the M.A. and Ph.D. degrees from
Princeton University, Princeton, N.J., in 1962
and 1964, respectively.
From 1960 to 1962 he was a Member of the
Technical Staff of Bell Telephone
Laboratories, Murray Hill, N.J., engaged in
traffic and communication studies. From
1964 to 1966 he was a Ford Postdoctoral
Fellow and an Assistant Professor of
Electrical Engineering at the Massachusetts
Institute of Technology, Cambridge, where he worked on communications
and information theory. From 1966 to 1972 he was a Senior Scientist at Bolt
Beranek and Newman, Inc., Cambridge, Mass., where he worked on
computer communications network design and techniques for distributed
computation. Since 1972 he has been with the Advanced Research Projects
Agency, Department of Defense, Arlington, Va.
Dr. Kahn is a member of Tau Beta Pi, Sigma Xi, Eta Kappa Nu, the
Institute of Mathematical Statistics, and the Mathematical Association of
America. He was selected to serve as a National Lecturer for the Assocation
for Computing Machinery in 1972.
5
Colin Perkins | https://csperkins.org/ | Copyright © 2017
History and Development
• 1965: Packet switching • Paul Baran (RAND),
Donald Davies (NPL)
• 1969: ARPA funding • First link: UCLA – SRI
• 1973: First non-US sites • UCL, SICS
• 1983: Switch to IPv4
• 1990: World Wide Web • Tim Berners-Lee ARPA network map, December 1972
Source: RFC 432
6
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Basic Concepts
• Global inter-networking protocol
• Hour glass protocol stack • Single standard network layer protocol (IP)
• Packet switched network, best effort service
• Uniform network and host addressing
• Uniform end-to-end connectivity (subject to firewall policy)
• Many transport & application layer protocols
• Range of link-layer technologies supported
IP
TCPSMTP
HTTP RTPSIP
HTMLMIMESDP Codecs
Wi-Fi
EthernetADSL
SONET
UDP
WirelessTwisted Pair
Optical FibrePhysical
Data Link
Network
Transport
Session
Application Presentation
7
Colin Perkins | https://csperkins.org/ | Copyright © 2017
IP Service Model
• Best effort, connectionless, packet delivery • Just send – no need to setup a connection first
• Network makes its best effort to deliver packets, but provides no guarantees • Time taken to transit the network may vary
• Packets may be lost, delayed, reordered, duplicated or corrupted
• The network discards packets it can’t deliver
• Easy to run over any type of link layer
• Fundamental service: can easily simulate a circuit over packets, but simulating packets over a circuit difficult
8
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Best Effort Packet Delivery
0
20
40
60
80
100
120
0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000
RT
T (
ms)
Time (ms)
Measured round-trip time to www.google.comfrom host on Wi-Fi plus ADSL for a 20 second period (4th January 2008, 7pm)
9
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Internet Protocol
• Two versions of IP in use: • IPv4 – the current production Internet
• IPv6 – the next generation Internet
• IPv5 was assigned to the Internet Stream Protocol • An experimental multimedia streaming protocol developed between 1979 and 1995
[http://www.ietf.org/rfc/rfc1819.txt], but no longer used
10
Colin Perkins | https://csperkins.org/ | Copyright © 2017
IPv4 Packet Format
11
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 = 4 Header Len DSCP ECN Total LengthFragment Identifier DF MF Fragment Offset
TTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
IPv6 Packet Format
12
Compared to IPv4: simpler header format, larger addresses, removes support for fragmentation, adds flow label
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 = 6 DSCP ECN Flow LabelPayload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Addressing
• Every network interface on every host is intended to have a unique address
• Hosts may change address over time to give illusion of privacy
• Addressable ≠ reachable: firewalls exist in both IPv4 and IPv6
• IPv4 addresses are 32 bits • Example: 130.209.247.112
• Significant problems due to lack of IPv4 addresses → lecture 9
• IPv6 addresses are 128 bits • Example: 2001:4860:4860::8844
13
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Fragmentation
• Link layer has a maximum packet size (MTU)
• IPv4 will routers fragment packets that are larger than the MTU
• MF bit is set if more fragments follow: reconstruct using fragment offset and fragment identifier
• DF bit is set to indicate routers shouldn’t fragment, and must discard large packets
• IPv6 doesn’t support fragmentation • Hard to implement for very high rate links
• End-to-end principle
14
RouterLength = 2000
Length = 1500, MF = 1, fragment offset = 0
Length = 500, MF = 0, fragment offset = 1500
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Loop Protection
• Packets include a forwarding limit: • Set to a non-zero value when the packet
is sent (typically 64 or 128)
• Each router that forwards the packet reduces this value by 1
• If zero is reached, packet is discarded
• Stops packets circling forever if a network problem causes a loop
• Assumption: network diameter is smaller than initial value of forwarding limit
15
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Differentiated Services
• End systems can request special service from the network
• Telephony or gaming might prefer low latency over high bandwidth
• Emergency traffic could be prioritised
• Background software updates might ask for low priority
• Signalled by differentiated service code point (DSCP) field in header
• Provides a hint to the network, not a guarantee
• Often stripped out at network boundaries
• Difficult economic and network neutrality issues – who is allowed to set the DSCP and what are they charged for doing so?
• IPv6 provides a flow label to group related traffic flows together
16
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Explicit Congestion Notification
• Routers typically respond to network congestion by dropping packets
• A “best effort” packet delivery service
• Transport protocols detect the loss, and can request a retransmission if necessary
• Explicit congestion notification gives routers a way to signal congestion is approaching
• If ECN=00 explicit congestion notification is disabled
• If a sending host sets ECN=10 or ECN=01, routers monitor link usage, and can change the field to ECN=11 indicating congestion is imminent
• A host receiving ECN=11 needs to reduce it’s sending rate – or the congested router will start dropping packets
17
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Header Checksum
• IPv4 header contain a checksum to detect transmission errors
• Conceptually similar to link-layer checksum, although uses a different algorithm
• Protects the IP header only, not the payload data protected (must be protected by upper layer protocol, if needed)
• IPv6 does not contain checksum – assumes the data is protected by a link layer checksum
18
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Transport Layer Protocol Identifier
• Network layer packet carry transport layer data as their payload
• Necessary to identify what transport protocol is used, to pass the data to the correct upper-layer protocol
• TCP = 6
• UDP = 17
• DCCP = 33
• ICMP = 1
• Legal values managed by the IANAhttp://www.iana.org/assignments/protocol-numbers/
19
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=4 Header Len
DSCP ECN Total Length
Fragment Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source Address
Destination Address
(Options – variable length, padded to 32 bit boundary)
Data – variable length
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=6 DSCP ECN Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
(Optional Extension Headers – variable length)
Data – variable length
Colin Perkins | https://csperkins.org/ | Copyright © 2017
IPv4 or IPv6?
• IPv4 has reached end-of-life: insufficient addresses
• IPv6 intended as long term replacement for IPv4 • Primary goal: increase the size of the address space, to allow more hosts
on the network
• Also simplifies the protocol, makes high-speed implementations easier
• Not yet clear if IPv6 will be widely deployed • But, straight-forward to build applications that work with both IPv4 and IPv6
• DNS query using getaddrinfo() will return IPv6 address if it exists, else IPv4 address; all other socket calls use the returned value
• Write new code to support both IPv6 and IPv4
20
Colin Perkins | https://csperkins.org/ | Copyright © 2017
Summary
• Role of the network layer
• From an internet to the Internet
• Internet service model
• IPv4 and IPv6
21