CompSci514/ECE558: Computer Networks Lecture 1: Course Introduction - - PowerPoint PPT Presentation

compsci514 ece558 computer networks
SMART_READER_LITE
LIVE PREVIEW

CompSci514/ECE558: Computer Networks Lecture 1: Course Introduction - - PowerPoint PPT Presentation

CompSci514/ECE558: Computer Networks Lecture 1: Course Introduction Xiaowei Yang xwy@cs.duke.edu http://www.cs.duke.edu/~xwy Overview History of the Internet What does the Internet look like? The historic design of the Internet


slide-1
SLIDE 1

CompSci514/ECE558: Computer Networks

Lecture 1: Course Introduction Xiaowei Yang xwy@cs.duke.edu http://www.cs.duke.edu/~xwy

slide-2
SLIDE 2

Overview

  • History of the Internet
  • What does the Internet look like?
  • The historic design of the Internet
  • Next

– Design philosophy – End-to-end argument

slide-3
SLIDE 3

The History of the Internet

Introductory material.

An overview lecture that covers Internet related topics, including a definition of the Internet, an overview of its history and growth, and standardization and naming.

slide-4
SLIDE 4

Internet History

  • 1961: Leonard Kleinrock -

queueing theory shows effectiveness of packet- switching

  • 1964: Paul Baran - packet-

switching in military nets

  • 1967: ARPAnet conceived by

Advanced Research Projects Agency

  • 1969: first ARPAnet node
  • perational
  • 1972:

– ARPAnet demonstrated publicly – NCP (Network Control Protocol) first host-host protocol

  • No TCP/IP yet

– first e-mail program – ARPAnet has 15 nodes

1961-1972: Early packet-switching principles

slide-5
SLIDE 5

https://www2.cs.duke.edu/courses/fall18/compsci514/slides/IMG_1342.MOV

slide-6
SLIDE 6
slide-7
SLIDE 7
slide-8
SLIDE 8

Internet in 1971

slide-9
SLIDE 9

Internet History

  • 1970: ALOHAnet satellite

network in Hawaii

  • 1973: Metcalfes PhD thesis

proposes Ethernet

  • 1974: Cerf and Kahn -

architecture for interconnecting networks (Turing award work)

  • late70s: proprietary

architectures: DECnet, SNA, XNA

  • late 70s: switching fixed

length packets (ATM precursor)

  • 1979: ARPAnet has 200 nodes

Cerf and Kahn’s internetworking principles: – minimalism, autonomy - no internal changes required to interconnect networks – best effort service model – stateless routers – decentralized control define todays Internet architecture

1972-1980: Internetworking, new and proprietary nets

slide-10
SLIDE 10

Internet History

  • Early 1990s: ARPAnet

decommissioned

  • 1991: NSF lifts restrictions on

commercial use of NSFnet (decommissioned, 1995)

  • early 1990s: Web

– hypertext [Bush 1945, Nelson 1960s] – HTML, HTTP: Berners-Lee – 1994: Mosaic, later Netscape – late 1990s: commercialization of the Web Late 1990s – 2000s:

  • more killer apps: instant

messaging, P2P file sharing

  • network security to forefront
  • est. 50 million host, 100

million+ users

  • backbone links running at

Gbps 2000-now:

  • Cloud computing
  • Mobile computing
  • Social applications

Future: …

1990, 2000s: commercialization, the Web, new apps

slide-11
SLIDE 11

Design of the Internet

  • Review of what the current Internet looks

like

  • Historic design

– The original TCP/IP design paper (optional reading)

  • A protocol for packet network

intercommunication by Cerf and Karn, 1974

  • An excellent case study
  • Design Philosophy
slide-12
SLIDE 12

12

Whats the Internet?

  • The Internet is a large-scale general-purpose

computer network.

– Run more than one applications

  • The Internet transfers information between

computers.

  • The Internet is a network of networks.
slide-13
SLIDE 13

13

What the Internet looks like

email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio... Ethernet ATM Framerelay IP/SONET Ethernet Ethernet 802.X Wireless Host Host Host Host Host Host Host Host Host Host Host Host Host Host Host

Tier 1 Tier 1

Tier 2 Tier 2 Tier 2

Tier 3

The Internet

BGP RIP, OSFP Distance Vector Link-State

Ethernet, CSMA/CD Bridges, Switches, Spanning Tree Bandwidth x Delay TCP Performance

Modulation Coding FDMA, TDMA

IP Blocks, CIDR, Subnets Longest Prefix Match, Fragmentation, MTU

slide-14
SLIDE 14

14

A layered architecture

  • Many sub-tasks need to be accomplished

– Find a path to the destination, reliably transfer information

  • The complexity of the communication task is

reduced by using multiple protocol layers:

  • Each protocol is implemented independently
  • Each protocol is responsible for a specific subtask
  • Protocols are grouped in a hierarchy
  • The old divide-and-conquer principle!
slide-15
SLIDE 15

15

The Internet Protocol Suite

  • The Internet architecture has

four layers: Application, Transport, Network, and Data Link Layer

  • Sending or receiving a packet

from end systems (hosts) may involve actions of all four

  • layers. Packet forwarding by

(Routers) only involve the bottom two layers.

Application Transport Network

Operating system User-level programs

Data Link

Data Link Media Access Control (MAC) Sublayer in Local Area Networks

slide-16
SLIDE 16

16

Functions of the Layers

  • Data Link Layer:

– Service: Reliable transfer of frames over a link Media Access Control on a LAN – Functions: Framing, media access control, error checking

  • Network Layer:

– Service: Move packets from source host to destination host – Functions: Routing, addressing

  • Transport Layer:

– Service: Delivery of data between hosts – Functions: Connection establishment/termination, error control, flow control

  • Application Layer:

– Service: Application specific (delivery of email, retrieval of HTML documents, reliable transfer of file) – Functions: Application specific

slide-17
SLIDE 17

17

TCP/IP Suite and OSI Reference Model

Application Layer Application Layer

Presentation

Layer Session Layer Transport Layer Network Layer (Data) Link Layer Physical Layer Transport Layer Network Layer OSI Reference Model (Data) Link Layer TCP/IP Suite

The TCP/IP protocol stack does not define the lower layers of a complete protocol stack

slide-18
SLIDE 18

18

Assignment of Protocols to Layers

Network Layer

Routing Protocols

PIM OSPF RIP Application Layer Data Link Layer IP ARP Ethernet Network Interface Transport Layer TCP UDP SNMP FTP DNS HTTP ICMP IGMP

ping application

Telnet DHCP

slide-19
SLIDE 19

19

An Example

slide-20
SLIDE 20

20

  • A user on host argon.tcpip-lab.edu (Argon) makes web

access to URL http://neon. tcpip-lab.edu/index.html.

  • What actually happens in the network?

A simple TCP/IP Example

argon.tcpip-lab.edu ("Argon") neon.tcpip-lab.edu ("Neon") Web request Web page Web client Web server

slide-21
SLIDE 21

21

HTTP Request and HTTP response

  • Web server runs an HTTP server program
  • HTTP client Web browser runs an HTTP client

program

  • sends an HTTP request to HTTP server
  • HTTP server responds with HTTP response

HTTP client

Argon

HTTP server

Neon HTTP request HTTP response

slide-22
SLIDE 22

22

HTTP Request

GET /example.html HTTP/1.1 Accept: image/gif, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Host: 192.168.123.144 Connection: Keep-Alive

slide-23
SLIDE 23

23

HTTP Response

HTTP/1.1 200 OK Date: Sat, 25 May 2002 21:10:32 GMT Server: Apache/1.3.19 (Unix) Last-Modified: Sat, 25 May 2002 20:51:33 GMT ETag: "56497-51-3ceff955" Accept-Ranges: bytes Content-Length: 81 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html <HTML> <BODY> <H1>Internet Lab</H1> Click <a href="http://www.tcpip-lab.net/index.html">here</a> for the Internet Lab webpage. </BODY> </HTML>

  • How does the HTTP request get from Argon to Neon ?
slide-24
SLIDE 24

24

From HTTP to TCP

  • To send request, HTTP client program

establishes an TCP connection to the HTTP server Neon.

  • The HTTP server at Neon has a TCP server

running

HTTP client

TCP client Argon

HTTP server

TCP server Neon HTTP request / HTTP response TCP connection

slide-25
SLIDE 25

25

Resolving hostnames and port numbers

  • Since TCP does not work with hostnames and

also would not know how to find the HTTP server program at Neon, two things must happen:

  • 1. The name neon.tcpip-lab.edu must be

translated into a 32-bit IP address.

  • 2. The HTTP server at Neon must be identified

by a 16-bit port number.

slide-26
SLIDE 26

26

Translating a hostname into an IP address

  • The translation of the hostname neon.tcpip-lab.edu into an IP

address is done via a database lookup

– gethostbyname(host)

  • The distributed database used is called the Domain Name

System (DNS)

  • All machines on the Internet have an IP address:

argon.tcpip-lab.edu 128.143.137.144 neon.tcpip-lab.edu 128.143.71.21

HTTP client DNS Server argon.tcpip-lab.edu 128.143.136.15 neon.tcpip-lab.edu 128.143.71.21

slide-27
SLIDE 27

27

Finding the port number

  • Note: Most services on the Internet are reachable via well-known
  • ports. E.g. All HTTP servers on the Internet can be reached at

port number 80.

  • So: Argon simply knows the port number of the HTTP server at a

remote machine.

  • On most Unix systems, the well-known ports are listed in a file

with name /etc/services. The well-known port numbers of some of the most popular services are: ftp 21 finger 79 telnet 23 http 80 smtp 25 nntp 119

slide-28
SLIDE 28

28

Requesting a TCP Connection

  • The HTTP client at argon.tcpip-lab.edu requests the TCP client to establish

a connection to port 80 of the machine with address 128.141.71.21

HTTP client

TCP client argon.tcpip-lab.edu Establish a TCP connection to port 80 of 128.143.71.21

connect(s, (struct sockaddr*)&sin, sizeof(sin))

slide-29
SLIDE 29

29

Invoking the IP Protocol

  • The TCP client at Argon sends a request to establish a connection to port 80 at Neon
  • This is done by asking its local IP module to send an IP datagram to 128.143.71.21
  • (The data portion of the IP datagram contains the request to open a connection)

TCP client argon.tcpip-lab.edu IP Send an IP datagram to 128.143.71.21

slide-30
SLIDE 30

30

Sending the IP datagram to an IP router

  • Argon (128.143.137.144) can deliver the IP datagram directly to

Neon (128.143.71.21), only if it is on the same local network (subnet)

  • But Argon and Neon are not on the same local network

(Q: How does Argon know this?)

  • So, Argon sends the IP datagram to its default gateway
  • The default gateway is an IP router
  • The default gateway for Argon is Router137.tcpip-lab.edu

(128.143.137.1).

slide-31
SLIDE 31

31

The route from Argon to Neon

  • Note that the gateway has a different name for each of its interfaces.
slide-32
SLIDE 32

32

Finding the MAC address of the gateway

  • To send an IP datagram to Router137, Argon puts the IP datagram

in an Ethernet frame, and transmits the frame.

  • However, Ethernet uses different addresses, so-called Media

Access Control (MAC) addresses (also called: physical address, hardware address)

  • Therefore, Argon must first translate the IP address 128.143.137.1

into a MAC address.

  • The translation of addressed is performed via the Address

Resolution Protocol (ARP)

slide-33
SLIDE 33

33

Address resolution with ARP

slide-34
SLIDE 34

34

Invoking the device driver

  • The IP module at Argon, tells its Ethernet device driver to send an

Ethernet frame to address 00:e0:f9:23:a8:20

argon.tcpip-lab.edu IP module Ethernet Send an Ethernet frame to 00:e0:f9:23:a8:20

slide-35
SLIDE 35

35

Sending an Ethernet frame

  • The Ethernet device driver of Argon sends

the Ethernet frame to the Ethernet network interface card (NIC)

  • The NIC sends the frame onto the wire
slide-36
SLIDE 36

36

Forwarding the IP datagram

  • The IP router receives the Ethernet frame at interface 128.143.137.1

1. recovers the IP datagram 2. determines that the IP datagram should be forwarded to the interface with name 128.143.71.1

  • The IP router determines that it can deliver the IP datagram directly
slide-37
SLIDE 37

37

Another lookup of a MAC address

  • The router needs to find the MAC address of Neon.
  • Again, ARP is invoked, to translate the IP address of

Neon (128.143.71.21) into the MAC address of neon (00:20:af:03:98:28).

ARP message: What is the MAC address of 128.143.71.21? ARP message: IP address 128.143.71.21 belongs to MAC address 00:20:af:03:98:28

neon.tcpip-lab.edu 128.143.71.21 00:20:af:03:98:28 router71.tcpip-lab.edu 128.143.71.1

slide-38
SLIDE 38

38

  • The IP protocol at Router71, tells its Ethernet

device driver to send an Ethernet frame to address 00:20:af:03:98:28

router71.tcpip-lab.edu IP module Ethernet Send a frame to 00:20:af:03:98:28

Invoking the Device Driver at the Router

slide-39
SLIDE 39

39

Sending another Ethernet frame

  • The Ethernet device driver of Router71 sends

the Ethernet frame to the Ethernet NIC, which transmits the frame onto the wire.

slide-40
SLIDE 40

40

Data has arrived at Neon

  • Neon receives the Ethernet frame
  • The payload of the Ethernet frame is an

IP datagram which is passed to the IP protocol.

  • The payload of the IP datagram is a TCP

segment, which is passed to the TCP server

HTTP server neon.tcpip-lab.edu TCP server IP module Ethernet

slide-41
SLIDE 41

46

Use Encapsulation and Decapsulation to demultiplex

  • Encapsulation: As data is moving down the protocol stack, each protocol is adding

layer-specific control information.

  • Decapsulation is the reverse process.

HTTP TCP IP Ethernet

User data User data HTTP Header TCP Header TCP Header IP Header TCP Header IP Header Ethernet Header Ethernet Trailer

IP datagram TCP segment Ethernet frame

User data HTTP Header User data HTTP Header User data HTTP Header

slide-42
SLIDE 42

Historic design

  • The original TCP/IP design paper

– A protocol for packet network intercommunication by Cerf and Karn, 1974 – An excellent case study – Turing award winners

slide-43
SLIDE 43

Goal: Interconnecting different networks

  • Many different types of

packet switch networks

– ARPANET, packet satellite networks, ground-based packet radio networks, and

  • ther networks.
  • Each has

– Hosts, packet switches, processes – A protocol for communication

  • Q: what would you do

differently given such a design task?

slide-44
SLIDE 44

Challenges

  • 1. Different addressing schemes and host

communication protocols

  • 2. Different MTUs
  • 3. Different success or failure indicators
  • 4. End-to-end reliability: failures may occur at

each subnet

  • 5. Different control:
  • Status information, routing, fault

detection/isolation

slide-45
SLIDE 45

Inter- networking Architecture

  • Gateways interface different networks
  • A uniform data transmission control protocol

(TCP)

  • Uniform addressing (IP)
slide-46
SLIDE 46

Inter-networking design alternatives

  • Design alternative 1:
  • Design alternative 2:
slide-47
SLIDE 47

Inter-networking design alternatives

  • Design alternative 1: one unified technology, a multi-

media network

– Restrictive – Not pratical: existing networks cant be connected

  • Design alternative 2: each host implements all other

protocols

– Expensive – Difficult to accommodate future developement

slide-48
SLIDE 48

Maximum transmission unit size

  • Solution: fragmentation
  • +
  • -
  • Who reassembles?
  • Design alternatives:
slide-49
SLIDE 49

Maximum transmission unit size

  • Fragmentation: gateways fragment packets

into smaller units when MTU reduces

  • + packet sizes may vary in different networks
  • - complexity
  • Who reassembles?
  • Destination
  • + gateway needs not handle the complexity, adding

costs to all packets

  • + no need to reassemble again at downstream
slide-50
SLIDE 50

MTU design alternative

  • One max MTU for all networks

– + simple

  • -. coupling: cant isolate internal max packet size
  • f one network from other networks.
  • E.g. If a network can only support 512 bytes, then all

networks cant exceed 512 bytes

  • - difficult to increase, requires agreements from all

networks

  • - packet size may increase during transmission

without source host knowing it.

slide-51
SLIDE 51

Process Level Communication

  • Multiplexing and de-multiplexing messages

among processes

  • Design considerations: boundaries

– Case 1: No process boundaries

  • +
  • -

– Case 2: Separate messages from different processes

  • +
  • -
slide-52
SLIDE 52

Process Level Communication

  • Design: multiplexing and de-multiplexing messages

among processes into segment streams

  • Design considerations: boundaries

– Case 1: No process boundaries

  • + More efficient, packing msgs to full segments
  • - interferences between processes

– Case 2: Separate msgs from different processes

  • + process isolation
  • - overhead
slide-53
SLIDE 53

Addressing format

  • A network address understood by all gateways

– 8 bits

  • A TCP identifier to identify a host

– 16 bits

  • Port number to identify a destination process

– 16 bits

slide-54
SLIDE 54

Other design considerations of TCP

  • End to end reliability: sliding window
  • Flow control: to prevent receiver buffer overflow
  • Connection

– Three-way SYN hand-shakes – Close

slide-55
SLIDE 55

What are different today?

  • Or what would you do differently?
slide-56
SLIDE 56

What are different today?

  • TCP/IP separation

– Allows variety of services

  • TCP implements byte stream interface

– No notion of messages – Simple, and generic

  • TCP has congestion control

– Well learn why soon

  • Different addressing format, but same hierarchy
  • Its amazing how much they got it right!
slide-57
SLIDE 57

Summary

  • History of the Internet
  • What does the Internet look like?
  • The historic design of the Internet
  • Next

– Design philosophy – End-to-end argument