Top Banner
EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley
31

EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

Dec 21, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS122 – Lecture 2

Department of Electrical Engineering and Computer Sciences

University of CaliforniaBerkeley

Page 2: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 2

TOC: Applications/Design

Web BrowsingTelephone CallMultiplexingProtocolsIETF

Page 3: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 3

Applications: Web Browsing

ExampleLocating Resource: DNSConnectionEnd-to-endPacketsBitsPoints to remember

Page 4: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 4

Click Link or URL get content from localor remote computerURL:

http://www.google.com/stringSpecifies- Protocol: http- Computer: www.google.com- StringComputer (server) selects contents based on string

Web: Example

Page 5: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 5

Web: Locating Resourcewww.google.com is the name of a computerNetwork uses IP addressesTo find the IP address, the application uses a hierarchical directory service called theDomain Name System

local

com

host

www.google.com?IP = a.b.c.d

IP = a.b.c.d

www.google.com?

Page 6: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 6

Web: ConnectionThe protocol (http) sets up a connection between the host and cnn.com to transfer the pageThe connection transfers the page as a byte stream, without errors: pacing + error control

H ost cnn.com

Page 7: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 7

Web: End-to-end

The byte stream flows from end to end across many links and switches: routing (+ addressing)That stream is regulated and controlled by both ends: retransmission of erroneous or missing bytes; flow control

End-to-end pacing andflow control

Routing

www.google.com

host

Page 8: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 8

Web: PacketsThe network transports bytes grouped into packetsThe packets are “self-contained” and routers handle them one by oneThe end hosts worry about errors and flow control:

Destination checks packet for errors (using error detection code CKS) and sends ACKs with sequence number #

Source retransmits packets that were not ACKed and adjusts rate of transmissions

C

A | B | # , CKS | bytes

B C

www.google.comIP address: A

HostIP address: B

Destination

Next Hop

Page 9: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 9

Web: Bits

Equipment in each node sends the packets as a string of bitsThat equipment is not aware of the meaning of the bits

01011...011...110

Transmitter Physical Medium Receiver

01011...011...110

OpticalCopperWireless

Page 10: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 10

Web: Points to remember

Separation of tasks send bits on a link: transmitter/receiver [clock,

modulation,…] send packet on each hop [framing, error detection,…]

send packet end to end [addressing, routing]

pace transmissions [detect congestion]

retransmit erroneous or missing packets [acks, timeout]

find destination address from name [DNS]

Scalability routers don’t know about connections names and addresses are hierarchical

Page 11: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 11

Applications: Telephone

Telephone NetworkDialing a NumberSetting up a CircuitPhone ConversationReleasing the Circuit

Page 12: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 12

Telephone: Telephone Network

Switches

Network

Logic Diagram

Page 13: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 13

Telephone Network: Switches

5ESS (Lucent)

DMS100 (Nortel)

Page 14: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 14

Telephone Network: Network

Page 15: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 15

Telephone Network: Logic Diagram

Page 16: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 16

Telephone: Dialing a Number

A Off-HookS1 ListensA dialsS1 Registers

A

BS1

Page 17: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 17

Telephone: Setting Up a Circuit

A

Bring

Circuit = capacity to carry one phone call (shown by thin lines)Circuit is allocated to the call between A and BCircuits are not shared; they are dedicated.

Page 18: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 18

Telephone: Phone Conversation

A

B

Voice signals use the reserved circuits

Page 19: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 19

Telephone: Release Circuits

A

B

A or B goes Off-HookCircuits get released

Page 20: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 20

Design: Multiplexing

OverviewOperationsTDM/FDMStatistical MultiplexingAnalysis of TDM/FDMAnalysis of Statistical Multiplexing

Page 21: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 21

Multiplexing: Overview

Networks are shared resourcesSharing via multiplexingFundamental Question:

how to achieve controlled sharing

Page 22: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 22

Multiplexing: Operations

Methods for sharing a communication channelTradeoff between utilization and predictabilityCommon Approaches: TDM (time-division multiplexing) Statistical Multiplexing

Page 23: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 23

MPX: Time Division Multiplexing

Multiplexern linksrate r bpseach

1 link, rate nr bps

Frame:

Time “slots” are reservedbps = bits per second

Page 24: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 24

MPX: Statistical Multiplexing

Multiplexern linksany rate 1 link, any rate

TraceExcerpt:

Variable-sized “packets” of data are interleavedbased on the statistics of the senders

Page 25: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 25

MPX: Analysis of TDM/FDM

TDM, FDM (frequency division multiplexing), and WDM (wavelength) may under-utilize channel with idle sendersApplicable only to fixed numbers of flowsRequires precise timer (or oscillator and guard bands for FDM)Resources are guaranteed

Page 26: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 26

MPX: Analysis of SM

Traffic is sent on demand, so channel is fully utilized if there is traffic to sendAny number of flowsNeed to control sharing: packets are limited in size prevents domination of single sender

Resources are not guaranteed

Page 27: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 27

Design: Protocols

DefinitionExamplesStandards

Page 28: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 28

Protocols: Definition

Agreement dictating the form and function of data exchanged between two (or more) parties to effect a communicationTwo parts: syntax and semantics syntax: where bits go semantics: what they mean and what to

do with them

Page 29: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 29

Protocols: Examples

Internet Protocol (IP) if you can generate and understand

IP, you can be on the Internet media, OS, data rate independent

TCP and HTTP if you can do these, you are on the

web

Page 30: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 30

Protocols: Standards

New functions require new protocolsThus there are many (e.g. IP, TCP, UDP, HTTP, RIP, OSPF, IS-IS, SMTP, SNMP, Telnet, FTP, DNS, NNTP, NTP, BGP, PIM, DVMRP, ARP, NFS, ICMP, IGMP)Specifications do not change frequentlyOrganizations: IETF, IEEE, ITU

Page 31: EECS122 – Lecture 2 Department of Electrical Engineering and Computer Sciences University of California Berkeley.

EECS 122 - UCB 31

Design: The IETF

Specifies Internet-related protocolsProduces “RFCs” (www.rfc-editor.org)Quotation from IETF T-shirt:

We reject kings, presidents and voting.We believe in rough consensus and running code.

--- David Clark