lecture 3: hardware and physical links chap 1.4, 2 of [pd] based partly on lecture notes by xiaowei...

74
Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] artly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis, Jo

Upload: norma-stephens

Post on 27-Dec-2015

221 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Lecture 3: Hardware and physical links

Chap 1.4, 2 of [PD]

Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis, John Jannotti

Page 2: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Overview

• Sockets Programming Revisited

• Network Architectures

• Examples of Networking Principles

• Hardware and physical layer– Nuts and bolts of networking– Nodes – Links

• Bandwidth, latency, throughput, delay-bandwidth product• Physical links

Page 3: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

IPs V. Ports : Server V. App.

Server has ..34.232.23.99

Client has ..12.32.43.23

Server has ..12.32.43.23

Gmail: 23

Plus: 43

Xbox: 23

Bing: 43

The Internet Google

microsoft

Page 4: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Socket

• What is a socket?– The point where a local application process attaches to the

network– An interface between an application and the network– An application creates the socket

• The interface defines operations for– Creating a socket– Attaching a socket to the network– Sending and receiving messages through the socket– Closing the socket

Page 5: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Creating a Socket

int sockfd = socket(address_family, type, protocol);

• The socket number returned is the socket descriptor for the newly created socket

• int sockfd = socket (PF_INET, SOCK_STREAM, 0);• int sockfd = socket (PF_INET, SOCK_DGRAM, 0);

The combination of PF_INET and SOCK_STREAM implies TCP

Page 6: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Socket

• Socket Family– PF_INET denotes the Internet family – PF_UNIX denotes the Unix pipe facility – PF_PACKET denotes direct access to the network

interface (i.e., it bypasses the TCP/IP protocol stack)

• Socket Type– SOCK_STREAM is used to denote a byte stream– SOCK_DGRAM is an alternative that denotes a

message oriented service, such as that provided by UDP

Page 7: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Client-Server Model with TCP

Server–Passive open–Prepares to accept connection, does not

actually establish a connection

Server invokesint bind (int socket, struct sockaddr *address,

int addr_len)int listen (int socket, int backlog)int accept (int socket, struct sockaddr *address,

int *addr_len)

Page 8: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Client-Server Model with TCP

Bind– Binds the newly created socket to the

specified address i.e. the network address of the local participant (the server)

– Address is a data structure which combines IP and port

Listen– Defines how many connections can be

pending on the specified socket

Page 9: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Client-Server Model with TCP

Accept– Carries out the passive open– Blocking operation

• Does not return until a remote participant has established a connection

• When it does, it returns a new socket that corresponds to the new established connection and the address argument contains the remote participant’s address

Page 10: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Client-Server Model with TCP

Client– Application performs active open– It says who it wants to communicate with

Client invokesint connect (int socket, struct sockaddr *address, int addr_len)

Connect– Does not return until TCP has successfully

established a connection at which application is free to begin sending data

– Address contains remote machine’s address

Page 11: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Client-Server Model with TCP

Once a connection is established, the application process invokes two operation

int send (int socket, char *msg, int msg_len,

int flags)

int recv (int socket, char *buff, int buff_len,

int flags)

Page 12: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Overview

• Sockets Programming Revisited

• Network Architectures

• Examples of Networking Principles

• Hardware and physical layer– Nuts and bolts of networking– Nodes – Links

• Bandwidth, latency, throughput, delay-bandwidth product• Physical links

Page 13: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Network architectures

• Layering is an abstraction that captures important aspects of the system, provides service interfaces, and hides implementation details

Page 14: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Protocols

• The abstract objects that make up the layers of a network system are called protocols

• Each protocol defines two different interfaces– Service interface– Peer interface

Layer N

Layer N-1Layer N-1

Layer N+1

Layer N

Layer N-1Layer N-1

Layer N+1

Page 15: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Network architectures

• A protocol graph represents protocols that make up a system– Nodes are protocols

– Links are depend-on relations

• Set of rules governing the form and content of a protocol graph are called a network architecture

• Standard bodies such as IETF govern procedures for introducing, validating, and approving protocols

Page 16: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

The protocol graph of Internet

• No strict layering. One can do cross-layer design• Hourglass shaped: IP defines a common method for exchanging packets

among different networks• To propose a new protocol, one must produce both a spec and one/two

implementations

Link layer

Network layer

Transport layer

Applicatoin layer

Page 17: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Encapsulation• Upper layer sends a message using the service

interface

• A header, a small data structure, to add information for peer-to-peer communication, is attached to the front message– Sometimes a trailer is added to the end

• Message is called payload or data

• This process is called encapsulation

Page 18: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,
Page 19: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Multiplexing & Demultiplexing

• Same ideas apply up and down the protocol graph

Page 20: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Overview

• Sockets Programming Revisited

• Network Architectures

• Examples of Networking Principles

• Hardware and physical layer– Nuts and bolts of networking– Nodes – Links

• Bandwidth, latency, throughput, delay-bandwidth product• Physical links

Page 21: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

An Example

Page 22: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

• 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

Page 23: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

Page 24: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

Page 25: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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?

Page 26: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

Page 27: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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.

Page 28: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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.144neon.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

Page 29: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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 79telnet 23 http 80smtp 25 nntp 119

Page 30: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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 connectionto port 80 of 128.143.71.21

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

Page 31: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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 to128.143.71.21

ip_output()

Page 32: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Sending the IP datagram to the default router

• Argon sends the IP datagram to its default router

• The default gateway is an IP router

• The default gateway for Argon is Router137.tcpip-lab.edu (128.143.137.1).

Page 33: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

• Ethernet address of the default router is found out via ARP

argon.tcpip-lab.edu

IP module

Ethernet

Send an Ethernet frameto 00:e0:f9:23:a8:20

ether_output

Page 34: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

The route from Argon to Neon

• Note that the router has a different name for each of its interfaces.

neon.tcpip-lab.edu"Neon"

128.143.71.21

argon.tcpip-lab.edu"Argon"128.143.137.144

router137.tcpip-lab.edu"Router137"

128.143.137.1

router71.tcpip-lab.edu"Router71"128.143.71.1

Ethernet NetworkEthernet Network

Router

Page 35: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

argon.tcpip-lab.edu128.143.137.14400:a0:24:71:e4:44

IP Datagram for Neon

router137.tcpip-lab.edu128.143.137.100:e0:f9:23:a8:20

Page 36: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Forwarding the IP datagram

• The IP router receives the Ethernet frame at interface 128.143.137.11. recovers the IP datagram2. 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

neon.tcpip-lab.edu"Neon"

128.143.71.21

argon.tcpip-lab.edu"Argon"128.143.137.144

router137.tcpip-lab.edu"Router137"

128.143.137.1

router71.tcpip-lab.edu"Router71"128.143.71.1

Ethernet NetworkEthernet Network

Router

Page 37: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

• 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 to00:20:af:03:98:28

Invoking the Device Driver at the Router

Page 38: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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.

IP Datagram for Neon

neon.tcpip-lab.edu128.143.71.21

00:20:af:03:98:28

router71.tcpip-lab.edu128.143.71.1

Page 39: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

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

Page 40: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Overview

• Sockets Programming Revisited

• Network Architectures

• Examples of Networking Principles

• Hardware and physical layer– Nuts and bolts of networking– Nodes – Links

• Bandwidth, latency, throughput, delay-bandwidth product• Physical links

Page 41: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Layers, Services, Protocols

Network

Link

Physical

Transport

Application

Service: move bits to other node across link

Page 42: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Physical Layer (Layer 1)

• Responsible for specifying the physical medium– Type of cable, fiber, wireless frequency

• Responsible for specifying the signal (modulation)– Transmitter varies something (amplitude, frequency,

phase)

– Receiver samples, recovers signal

• Responsible for specifying the bits (encoding)– Bits above physical layer -> chips

Page 43: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Modulation

• Specifies mapping between digital signal and some variation in analog signal

• Why not just a square wave (1v=1; 0v=0)?– Not square when bandwidth limited

• Bandwidth – frequencies that a channel propagates well– Signals consist of many frequency

components

– Attenuation and delay frequency-dependent

Page 44: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Components of a Square Wave

Graphs from Dr. David Alciatore, Colorado State University

Page 45: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Graphs from Dr. David Alciatore, Colorado State University

Approximation of a Square Wave

Page 46: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Idea: Use Carriers• Only use frequencies that transmit well

• Modulate the signal to encode bits

OOK: On-Off Keying

ASK: Amplitude Shift Keying

Page 47: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Idea: Use Carriers• Only use frequencies that transmit well

• Modulate the signal to encode bits

FSK: Frequency Shift Keying

PSK: Phase Shift Keying

Page 48: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

How Fast Can You Send?

• Encode information in some varying characteristic of the signal.

• If B is the maximum frequency of the signal

C = 2B bits/s(Nyquist, 1928)

Page 49: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Can we do better?• So we can only change 2B/second, what if we

encode more bits per sample?– Baud is the frequency of changes to the physical channel– Not the same thing as bits!

• Suppose channel passes 1KHz to 2KHz– 1 bit per sample: alternate between 1KHz and 2KHz– 2 bits per sample: send one of 1, 1.33, 1.66, or 2KHz– Or send at different amplitudes: A/4, A/2, 3A/4, A– n bits: choose among 2n frequencies!

• What is the capacity if you can distinguish M levels?

Page 50: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Hartley’s Law

C = 2B log2(M) bits/s

Great. By increasing M, we can have as large a capacity as we want!

Or can we?

Page 51: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

The channel is noisy!

Page 52: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

• Noise prevents you from increasing M arbitrarily!

• This depends on the signal/noise ratio (S/N)• Shannon: C = B log2(1 + S/N)

– C is the channel capacity in bits/second– B is the bandwidth of the channel in Hz– S and N are average signal and noise power– Signal-to-noise ratio is measured in dB =

10log10(S/N)

The channel is noisy!

Page 53: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Putting it all together

• Noise limits M!

2B log2(M) ≤ B log2(1 + S/N)

M ≤ √1+S/N

• Example: Telephone Line– 3KHz b/w, 30dB S/N = 10ˆ(30/10) = 1000

– C = 3KHz log2(1001) ≈ 30Kbps

Page 54: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Encoding• Now assume that we can somehow

modulate a signal: receiver can decode our binary stream

• How do we encode binary data onto signals?

• One approach: 1 as high, 0 as low!– Called Non-return to Zero (NRZ)

0 0 1 0 1 0 1 1 0

NRZ(non-return to zero)

Clock

Page 55: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Drawbacks of NRZ

• No signal could be interpreted as 0 (or vice-versa)

• Consecutive 1s or 0s are problematic

• Baseline wander problem– How do you set the threshold?

– Could compare to average, but average may drift

• Clock recovery problem– For long runs of no change, could miscount periods

Page 56: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Alternative Encodings

• Non-return to Zero Inverted (NRZI)– Encode 1 with transition from current signal

– Encode 0 by staying at the same level

– At least solve problem of consecutive 1s0 0 1 0 1 0 1 1 0

Clock

NRZI(non-return to zero

intverted)

Page 57: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Manchester• Map 0 chips 01• Maps 1 chips 10

– Transmission rate now 1 bit per two clock cycles

• Solves clock recovery, baseline wander• But cuts transmission rate in half

0 0 1 0 1 0 1 1 0

Clock

Manchester

Page 58: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

4B/5B• Can we have a more efficient encoding?• Every 4 bits encoded as 5 chips• Need 16 5-bit codes:

– selected to have no more than one leading 0 and no more than two trailing 0s

– Never get more than 3 consecutive 0s• Transmit chips using NRZI• Other codes used for other purposes

– E.g., 11111: line idle; 00100: halt• Achieves 80% efficiency

Page 59: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

4B/5B Table

Page 60: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Encoding Goals• DC Balancing (same number of 0 and 1 chips)• Clock synchronization• Can recover some chip errors• Constrain analog signal patterns to make signal

more robust• Want near channel capacity with negligible errors

– Shannon says it’s possible, doesn’t tell us how– Codes can get computationally expensive

• In practice– More complex encoding: fewer bps, more robust– Less complex encoding: more bps, less robust

Page 61: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Last Example: 802.15.4• Standard for low-power, low-rate wireless

PANs– Must tolerate high chip error rates

• Uses a 4B/32B bit-to-chip encoding

Page 62: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Questions so far?

Photo: Lewis Hine

Page 63: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Layers, Services, Protocols

Network

Link

Physical

Transport

Application

Service: move bits to other node across link

Service: move frames to other node across link.May add reliability, medium access control

Service: move packets to any other node in the networkIP: Unreliable, best-effort service model

Service: multiplexing applicationsReliable byte stream to other node (TCP), Unreliable datagram (UDP)

Service: user-facing application.Application-defined messages

Page 64: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Framing

• Given a stream of bits, how can we represent boundaries?

• Break sequence of bits into a frame

• Typically done by network adaptor

Page 65: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Representing Boundaries

Approaches

• Sentinels

• Length counts

• Clock-based

Characteristics

• Bit- or byte oriented

• Fixed or variable length

• Data-dependent or independent

Page 66: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Sentinel-based Framing• Byte-oriented protocols (e.g. BISYNC, PPP)

– Place special bytes (SOH, ETX,…) in the beginning, end of messages

• What if ETX appears in the body?– Escape ETX byte by prefixing DEL byte– Escape DEL byte by prefixing DEL byte– Technique known as character stuffing

Page 67: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Bit-Oriented Protocols

• View message as a stream of bits, not bytes

• Can use sentinel approach as well (e.g., HDLC)

– HDLC begin/end sequence 01111110

• Use bit stuffing to escape 01111110– Always append 0 after five consecutive 1s in data

– After five 1s, receiver uses next two bits to decide if stuffed, end of frame, or error.

Page 68: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Representing Boundaries

Approaches

• Sentinels

• Length counts

• Clock-based

Characteristics

• Bit- or byte oriented

• Fixed or variable length

• Data-dependent or independent

Page 69: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Length-based Framing• Drawback of sentinel techniques

– Length of frame depends on data

• Alternative: put length in header (e.g., DDCMP)

• Danger: Framing Errors– What if high bit of counter gets corrupted?

– Adds 8K to length of frame, may lose many frames

– CRC checksum helps detect error

Page 70: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Representing Boundaries

Approaches

• Sentinels

• Length counts

• Clock-based

Characteristics

• Bit- or byte oriented

• Fixed or variable length

• Data-dependent or independent

Page 71: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Clock-based Framing• E.g., SONET (Synchronous Optical

Network)– Each frame is 125μs long

– Look for header every 125μs

– Encode with NRZ, but first XOR payload with 127-bit string to ensure lots of transitions

Page 72: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Representing Boundaries

Approaches

• Sentinels

• Length counts

• Clock-based

Characteristics

• Bit- or byte oriented

• Fixed or variable length

• Data-dependent or independent

Page 73: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Error Detection

• Basic idea: use a checksum– Compute small checksum value, like a hash of

packet

• Good checksum algorithms– Want several properties, e.g., detect any single-bit

error

– Details in a later lecture

Page 74: Lecture 3: Hardware and physical links Chap 1.4, 2 of [PD] Based partly on lecture notes by Xiaowei Yang, Rodrigo Fonseca, David Mazières, Phil Levis,

Summary

• Network architectures

• Application Programming Interface

• Hardware and physical layer– Nuts and bolts of networking– Nodes – Links

• Bandwidth, latency, throughput, delay-bandwidth product• Physical links