Network Protocol Network Protocol Application layer protocol Transport

  • Slides: 79
Download presentation
Network Protocol

Network Protocol

Network Protocol • Application layer protocol • Transport layer protocol • Network layer protocol

Network Protocol • Application layer protocol • Transport layer protocol • Network layer protocol • Link layer protocol 2

Application Layer • conceptual, implementation aspects of network application protocols – transport-layer service models

Application Layer • conceptual, implementation aspects of network application protocols – transport-layer service models – client-server paradigm – peer-to-peer paradigm • learn about protocols by examining popular application-level protocols – HTTP – FTP – SMTP / POP 3 / IMAP – DNS 3

Application architectures • Client-server • Peer-to-peer (P 2 P) • Hybrid of client-server and

Application architectures • Client-server • Peer-to-peer (P 2 P) • Hybrid of client-server and P 2 P 4

Client-server archicture server: – always-on host – permanent IP address – server farms for

Client-server archicture server: – always-on host – permanent IP address – server farms for scaling clients: – communicate with server – may be intermittently connected – may have dynamic IP addresses – do not communicate directly with each other 5

Pure P 2 P architecture • no always on server • arbitrary end systems

Pure P 2 P architecture • no always on server • arbitrary end systems directly communicate • peers are intermittently connected and change IP addresses • example: Gnutella Highly scalable But difficult to manage 6

Processes communicating Process: program Client process: process running within a host. that initiates •

Processes communicating Process: program Client process: process running within a host. that initiates • within same host, two communication processes Server process: process communicate using that waits to be inter-process contacted communication (defined by OS). • Note: applications with P 2 P architectures • processes in different have client processes hosts communicate by & server processes exchanging messages 7

Sockets • process sends/receives messages to/from its socket • socket analogous to door –

Sockets • process sends/receives messages to/from its socket • socket analogous to door – sending process shoves message out door – sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process host or server process controlled by app developer process socket TCP with buffers, variables Internet TCP with buffers, variables controlled by OS 8

Addressing processes • For a process to receive messages, it must have an identifier

Addressing processes • For a process to receive messages, it must have an identifier • A host has a unique 32 -bit IP address • Q: does the IP address of the host on which the process runs suffice for identifying the process? • Answer: No, many processes can be running on same host • Identifier includes both the IP address and port numbers associated with the process on the host. • Example port numbers: – HTTP server: 80 – Mail server: 25 9

App-layer protocol defines • Types of messages exchanged, eg, request & response messages •

App-layer protocol defines • Types of messages exchanged, eg, request & response messages • Syntax of message types: what fields in messages & how fields are delineated • Semantics of the fields, ie, meaning of information in fields • Rules for when and how processes send & respond to messages 10

Internet transport protocols services TCP service: • connection-oriented: setup required between client and server

Internet transport protocols services TCP service: • connection-oriented: setup required between client and server processes • reliable transport between sending and receiving process • flow control: sender won’t overwhelm receiver • congestion control: throttle sender when network overloaded • does not provide: timing, minimum bandwidth guarantees UDP service: • unreliable data transfer between sending and receiving process • does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: why bother? Why is there a UDP? 11

Web and HTTP First some jargon • Web page consists of objects • Object

Web and HTTP First some jargon • Web page consists of objects • Object can be HTML file, JPEG image, Java applet, audio file, … • Web page consists of base HTML-file which includes several referenced objects • Each object is addressable by a URL • Example URL: www. someschool. edu/some. Dept/pic. gif host name path name 12

HTTP overview HTTP: hypertext transfer protocol • Web’s application layer protocol • client/server model

HTTP overview HTTP: hypertext transfer protocol • Web’s application layer protocol • client/server model – client: browser that requests, receives, “displays” Web objects – server: Web server sends objects in response to requests • HTTP 1. 0: RFC 1945 • HTTP 1. 1: RFC 2068 HT TP req ues PC running HT t TP res Explorer pon se st ue q e r P nse Server T o p running HT es r P T Apache Web HT server Mac running Navigator 13

HTTP request message • two types of HTTP messages: request, response • HTTP request

HTTP request message • two types of HTTP messages: request, response • HTTP request message: – ASCII (human-readable format) request line (GET, POST, HEAD commands) GET /somedir/page. html HTTP/1. 1 Host: www. someschool. edu User-agent: Mozilla/4. 0 header Connection: close lines Accept-language: fr Carriage return, line feed indicates end of message (extra carriage return, line feed) 14

HTTP request message: general format 15

HTTP request message: general format 15

HTTP response message status line (protocol status code status phrase) header lines data, e.

HTTP response message status line (protocol status code status phrase) header lines data, e. g. , requested HTML file HTTP/1. 1 200 OK Connection close Date: Thu, 06 Aug 1998 12: 00: 15 GMT Server: Apache/1. 3. 0 (Unix) Last-Modified: Mon, 22 Jun 1998 …. . . Content-Length: 6821 Content-Type: text/html data data. . . 16

FTP: the file transfer protocol user at host FTP user client interface local file

FTP: the file transfer protocol user at host FTP user client interface local file system file transfer FTP server remote file system • transfer file to/from remote host • client/server model – client: side that initiates transfer (either to/from remote) – server: remote host • ftp: RFC 959 • ftp server: port 21 17

FTP: separate control, data connections • FTP client contacts FTP server at port 21,

FTP: separate control, data connections • FTP client contacts FTP server at port 21, specifying TCP as transport protocol • Client obtains authorization over control connection • Client browses remote directory by sending commands over control connection. • When server receives a command for a file transfer, the server opens a TCP data connection to client • After transferring one file, server closes connection. TCP control connection port 21 FTP client TCP data connection port 20 FTP server • Server opens a second TCP data connection to transfer another file. • Control connection: “out of band” • FTP server maintains “state”: current directory, earlier authentication 18

Electronic Mail Three major components: • user agents • mail servers • simple mail

Electronic Mail Three major components: • user agents • mail servers • simple mail transfer protocol: SMTP User Agent • a. k. a. “mail reader” • composing, editing, reading mail messages • e. g. , Eudora, Outlook, elm, Netscape Messenger • outgoing, incoming messages stored on server outgoing message queue user mailbox user agent mail server SMTP mail server user agent SMTP user agent mail server user agent 19

Electronic Mail: mail servers Mail Servers • mailbox contains incoming messages for user •

Electronic Mail: mail servers Mail Servers • mailbox contains incoming messages for user • message queue of outgoing (to be sent) mail messages • SMTP protocol between mail servers to send email messages – client: sending mail server – “server”: receiving mail server user agent mail server SMTP mail server user agent SMTP user agent mail server user agent 20

Electronic Mail: SMTP [RFC 2821] • uses TCP to reliably transfer email message from

Electronic Mail: SMTP [RFC 2821] • uses TCP to reliably transfer email message from client to server, port 25 • direct transfer: sending server to receiving server • three phases of transfer – handshaking (greeting) – transfer of messages – closure 21

Scenario: Alice sends message to Bob 1) Alice uses UA to compose 4) SMTP

Scenario: Alice sends message to Bob 1) Alice uses UA to compose 4) SMTP client sends Alice’s message and “to” message over the TCP bob@someschool. edu connection 2) Alice’s UA sends 5) Bob’s mail server places message to her mail the message in Bob’s server; message placed mailbox in message queue 6) Bob invokes his user agent 3) Client side of SMTP to read message opens TCP connection with Bob’s mail server 1 user agent 2 mail server 3 mail server 4 5 6 user agent 22

Mail message format SMTP: protocol for exchanging email msgs RFC 822: standard for text

Mail message format SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: • header lines, e. g. , – To: – From: – Subject: header blank line body • body – the “message”, ASCII characters only 23

Message format: multimedia extensions • MIME: multimedia mail extension, RFC 2045, 2056 • additional

Message format: multimedia extensions • MIME: multimedia mail extension, RFC 2045, 2056 • additional lines in msg header declare MIME content type From: alice@crepes. fr MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data 24

Mail access protocols user agent SMTP sender’s mail server access protocol user agent receiver’s

Mail access protocols user agent SMTP sender’s mail server access protocol user agent receiver’s mail server • SMTP: delivery/storage to receiver’s server • Mail access protocol: retrieval from server – POP: Post Office Protocol [RFC 1939] • authorization (agent <-->server) and download – IMAP: Internet Mail Access Protocol [RFC 1730] • more features (more complex) • manipulation of stored msgs on server – HTTP: Hotmail , Yahoo! Mail, etc. 25

DNS: Domain Name System People: many identifiers: – SSN, name, passport # Internet hosts,

DNS: Domain Name System People: many identifiers: – SSN, name, passport # Internet hosts, routers: – IP address (32 bit) used for addressing datagrams – “name”, e. g. , ww. yahoo. com - used by humans Q: map between IP addresses and name ? Domain Name System: • distributed database implemented in hierarchy of many name servers • application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) – note: core Internet function, implemented as application-layer protocol 26

DNS services • Hostname to IP address translation • Host aliasing – Canonical and

DNS services • Hostname to IP address translation • Host aliasing – Canonical and alias names • Mail server aliasing • Load distribution – Replicated Web servers: set of IP addresses for one canonical name Why not centralize DNS? • single point of failure • traffic volume • distant centralized database • maintenance doesn’t scale! 27

Distributed, Hierarchical Database Root DNS Servers com DNS servers yahoo. com amazon. com DNS

Distributed, Hierarchical Database Root DNS Servers com DNS servers yahoo. com amazon. com DNS servers org DNS servers pbs. org DNS servers edu DNS servers poly. edu umass. edu DNS servers Client wants IP for www. amazon. com; 1 st approx: • Client queries a root server to find com DNS server • Client queries com DNS server to get amazon. com DNS server • Client queries amazon. com DNS server to get IP address for www. amazon. com 28

Internet transport-layer protocols 29

Internet transport-layer protocols 29

Transport services and protocols application transport network data link physical al ic g lo

Transport services and protocols application transport network data link physical al ic g lo d en d- en network data link physical po s an tr rt • provide logical communication between app processes running on different hosts • transport protocols run in end systems – send side: breaks app messages into segments, passes to network layer – rcv side: reassembles segments into messages, passes to app layer • more than one transport protocol available to apps – Internet: TCP and UDP application transport network data link physical 30

Transport vs. network layer • network layer: logical communication between hosts • transport layer:

Transport vs. network layer • network layer: logical communication between hosts • transport layer: logical communication between processes – relies on, enhances, network layer services 31

Internet transport-layer protocols application transport network data link physical al ic g lo d

Internet transport-layer protocols application transport network data link physical al ic g lo d en d- en network data link physical po s an tr rt • reliable, in-order delivery (TCP) – congestion control – flow control – connection setup • unreliable, unordered delivery: UDP – no-frills extension of “best-effort” IP • services not available: – delay guarantees – bandwidth guarantees application transport network data link physical 32

Multiplexing/demultiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header

Multiplexing/demultiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Demultiplexing at rcv host: delivering received segments to correct socket = socket application transport network link = process P 3 P 1 application transport network P 2 P 4 application transport network link physical host 1 physical host 2 physical host 3 33

How demultiplexing works • host receives IP datagrams – each datagram has source IP

How demultiplexing works • host receives IP datagrams – each datagram has source IP address, destination IP address – each datagram carries 1 transport-layer segment – each segment has source, destination port number host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 34

Connectionless demultiplexing • When host receives UDP segment: – checks destination port Datagram. Socket

Connectionless demultiplexing • When host receives UDP segment: – checks destination port Datagram. Socket my. Socket 1 = number in segment new – directs UDP segment to Datagram. Socket(99111); socket with that port Datagram. Socket my. Socket 2 = number new • IP datagrams with different Datagram. Socket(99222); source IP addresses and/or source port numbers • UDP socket identified by twodirected to same socket tuple: • Create sockets with port numbers: (dest IP address, dest port number) 35

Connectionless demux (cont) Datagram. Socket server. Socket = new Datagram. Socket(6428); P 2 SP:

Connectionless demux (cont) Datagram. Socket server. Socket = new Datagram. Socket(6428); P 2 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 client IP: A P 1 P 3 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP: B SP provides “return address” 36

UDP: User Datagram Protocol [RFC 768] • “best effort” service, UDP segments may be:

UDP: User Datagram Protocol [RFC 768] • “best effort” service, UDP segments may be: – lost – delivered out of order to app • connectionless: – no handshaking between UDP sender, receiver – each UDP segment handled independently of others Why is there a UDP? • no connection establishment (which can add delay) • simple: no connection state at sender, receiver • small segment header • no congestion control: UDP can blast away as fast as desired 37

UDP: more • often used for streaming Length, in multimedia apps bytes of UDP

UDP: more • often used for streaming Length, in multimedia apps bytes of UDP – loss tolerant segment, including – rate sensitive header • reliable transfer over UDP: add reliability at application layer – application-specific error recovery! 32 bits source port # dest port # length checksum Application data (message) UDP segment format 38

UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender:

UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: Receiver: • treat segment contents as • compute checksum of sequence of 16 -bit received segment integers • check if computed checksum • checksum: addition (1’s equals checksum field value: complement sum) of – NO - error detected segment contents – YES - no error detected. • sender puts checksum But maybe errors value into UDP checksum nonetheless? More later …. field 39

Internet Checksum Example • Note – When adding numbers, a carryout from the most

Internet Checksum Example • Note – When adding numbers, a carryout from the most significant bit needs to be added to the result • Example: add two 16 -bit integers 1 1 0 0 1 1 1 0 1 0 1 wraparound 1 1 0 1 1 sum 1 1 0 1 1 0 0 checksum 1 0 0 0 0 1 1 40

The Internet Network layer 41

The Internet Network layer 41

The Internet Network layer Host, router network layer functions: Transport layer: TCP, UDP Network

The Internet Network layer Host, router network layer functions: Transport layer: TCP, UDP Network layer IP protocol • addressing conventions • datagram format • packet handling conventions Routing protocols • path selection • RIP, OSPF, BGP forwarding table ICMP protocol • error reporting • router “signaling” Link layer physical layer 42

IP datagram format IP protocol version number header length (bytes) “type” of data max

IP datagram format IP protocol version number header length (bytes) “type” of data max number remaining hops (decremented at each router) upper layer protocol to deliver payload to 32 bits ver head. type of len service length fragment 16 -bit identifier flgs offset upper time to Internet layer live checksum total datagram length (bytes) for fragmentation/ reassembly 32 bit source IP address 32 bit destination IP address Options (if any) data (variable length, typically a TCP or UDP segment) E. g. timestamp, record route taken, specify list of routers to visit. 43

NAT: Network Address Translation rest of Internet local network (e. g. , home network)

NAT: Network Address Translation rest of Internet local network (e. g. , home network) 10. 0. 0/24 10. 0. 0. 1 10. 0. 0. 2 138. 76. 29. 7 10. 0. 0. 3 All datagrams leaving local network have same single source NAT IP address: 138. 76. 29. 7, different source port numbers Datagrams with source or destination in this network have 10. 0. 0/24 address for source, destination (as usual) 44

NAT: Network Address Translation • Motivation: local network uses just one IP address as

NAT: Network Address Translation • Motivation: local network uses just one IP address as far as outside word is concerned: – no need to be allocated range of addresses from ISP: - just one IP address is used for all devices – can change addresses of devices in local network without notifying outside world – can change ISP without changing addresses of devices in local network – devices inside local net not explicitly addressable, visible by outside world (a security plus). 45

NAT: Network Address Translation Implementation: NAT router must: – outgoing datagrams: replace (source IP

NAT: Network Address Translation Implementation: NAT router must: – outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #). . . remote clients/servers will respond using (NAT IP address, new port #) as destination addr. – remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair – incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table 46

NAT: Network Address Translation 2: NAT router changes datagram source addr from 10. 0.

NAT: Network Address Translation 2: NAT router changes datagram source addr from 10. 0. 0. 1, 3345 to 138. 76. 29. 7, 5001, updates table 2 NAT translation table WAN side addr LAN side addr 1: host 10. 0. 0. 1 sends datagram to 128. 119. 40, 80 138. 76. 29. 7, 5001 10. 0. 0. 1, 3345 …… …… S: 10. 0. 0. 1, 3345 D: 128. 119. 40. 186, 80 S: 138. 76. 29. 7, 5001 D: 128. 119. 40. 186, 80 138. 76. 29. 7 S: 128. 119. 40. 186, 80 D: 138. 76. 29. 7, 5001 3: Reply arrives dest. address: 138. 76. 29. 7, 5001 3 1 10. 0. 0. 4 S: 128. 119. 40. 186, 80 D: 10. 0. 0. 1, 3345 10. 0. 0. 1 10. 0. 0. 2 4 10. 0. 0. 3 4: NAT router changes datagram dest addr from 138. 76. 29. 7, 5001 to 10. 0. 0. 1, 3345 47

ICMP: Internet Control Message Protocol • used by hosts & routers to communicate network-level

ICMP: Internet Control Message Protocol • used by hosts & routers to communicate network-level information – error reporting: unreachable host, network, port, protocol – echo request/reply (used by ping) • network-layer “above” IP: – ICMP msgs carried in IP datagrams • ICMP message: type, code plus first 8 bytes of IP datagram causing error Type 0 3 3 3 4 Code 0 0 1 2 3 6 7 0 8 9 10 11 12 0 0 0 description echo reply (ping) dest. network unreachable dest host unreachable dest protocol unreachable dest port unreachable dest network unknown dest host unknown source quench (congestion control - not used) echo request (ping) route advertisement router discovery TTL expired bad IP header 48

IPv 6 • Initial motivation: 32 -bit address space soon to be completely allocated.

IPv 6 • Initial motivation: 32 -bit address space soon to be completely allocated. • Additional motivation: – header format helps speed processing/forwarding – header changes to facilitate Qo. S IPv 6 datagram format: – fixed-length 40 byte header – no fragmentation allowed 49

IPv 6 Header (Cont) Priority: identify priority among datagrams in flow Next header: identify

IPv 6 Header (Cont) Priority: identify priority among datagrams in flow Next header: identify upper layer protocol for data 50

Other Changes from IPv 4 • Checksum: removed entirely to reduce processing time at

Other Changes from IPv 4 • Checksum: removed entirely to reduce processing time at each hop • Options: allowed, but outside of header, indicated by “Next Header” field • ICMPv 6: new version of ICMP – additional message types, e. g. “Packet Too Big” – multicast group management functions 51

Transition From IPv 4 To IPv 6 • Not all routers can be upgraded

Transition From IPv 4 To IPv 6 • Not all routers can be upgraded simultaneous – no “flag days” – How will the network operate with mixed IPv 4 and IPv 6 routers? • Tunneling: IPv 6 carried as payload in IPv 4 datagram among IPv 4 routers 52

Tunneling Logical view: Physical view: A B IPv 6 A B C IPv 6

Tunneling Logical view: Physical view: A B IPv 6 A B C IPv 6 IPv 4 Flow: X Src: A Dest: F data A-to-B: IPv 6 E F IPv 6 D E F IPv 4 IPv 6 tunnel Src: B Dest: E Flow: X Src: A Dest: F data B-to-C: IPv 6 inside IPv 4 Flow: X Src: A Dest: F data D-to-E: E-to-F: IPv 6 inside IPv 6 IPv 4 53

Link Layer Protocol 54

Link Layer Protocol 54

Multiple Access Links and Protocols Two types of “links”: • point-to-point – PPP for

Multiple Access Links and Protocols Two types of “links”: • point-to-point – PPP for dial-up access – point-to-point link between Ethernet switch and host • broadcast (shared wire or medium) – traditional Ethernet – 802. 11 wireless LAN 55

Multiple Access protocols • single shared broadcast channel • two or more simultaneous transmissions

Multiple Access protocols • single shared broadcast channel • two or more simultaneous transmissions by nodes: interference – collision if node receives two or more signals at the same time multiple access protocol • distributed algorithm that determines how nodes share channel, i. e. , determine when node can transmit • communication about channel sharing must use channel itself! 56 – no out-of-band channel for coordination

Ideal Multiple Access Protocol Broadcast channel of rate R bps 1. When one node

Ideal Multiple Access Protocol Broadcast channel of rate R bps 1. When one node wants to transmit, it can send at rate R. 2. When M nodes want to transmit, each can send at average rate R/M 3. Fully decentralized: – no special node to coordinate transmissions – no synchronization of clocks, slots 4. Simple 57

MAC Protocols: a taxonomy Three broad classes: • Channel Partitioning – divide channel into

MAC Protocols: a taxonomy Three broad classes: • Channel Partitioning – divide channel into smaller “pieces” (time slots, frequency, code) – allocate piece to node for exclusive use • Random Access – channel not divided, allow collisions – “recover” from collisions • “Taking turns” – Nodes take turns, but nodes with more to send can take longer turns 58

Channel Partitioning MAC protocols: TDMA: time division multiple access • access to channel in

Channel Partitioning MAC protocols: TDMA: time division multiple access • access to channel in "rounds" • each station gets fixed length slot (length = pkt trans time) in each round • unused slots go idle • example: 6 -station LAN, 1, 3, 4 have pkt, slots 2, 5, 6 idle 59

Channel Partitioning MAC protocols: FDMA: frequency division multiple access • channel spectrum divided into

Channel Partitioning MAC protocols: FDMA: frequency division multiple access • channel spectrum divided into frequency bands • each station assigned fixed frequency band • unused transmission time in frequency bands go idle • example: 6 -station LAN, 1, 3, 4 have pkt, frequency bands 2, 5, 6 idle • FDM (Frequency Division Multiplexing): frequency subdivided. frequency bands time 60

Random Access Protocols • When node has packet to send – transmit at full

Random Access Protocols • When node has packet to send – transmit at full channel data rate R. – no a priori coordination among nodes • two or more transmitting nodes ➜ “collision”, • random access MAC protocol specifies: – how to detect collisions – how to recover from collisions (e. g. , via delayed retransmissions) • Examples of random access MAC protocols: – slotted ALOHA – CSMA, CSMA/CD, CSMA/CA 61

Slotted ALOHA Assumptions • all frames same size • time is divided into equal

Slotted ALOHA Assumptions • all frames same size • time is divided into equal size slots, time to transmit 1 frame • nodes start to transmit frames only at beginning of slots • nodes are synchronized • if 2 or more nodes transmit in slot, all nodes detect collision Operation • when node obtains fresh frame, it transmits in next slot • no collision, node can send new frame in next slot • if collision, node retransmits frame in each subsequent slot with prob. p until success 62

Slotted ALOHA Pros • single active node can continuously transmit at full rate of

Slotted ALOHA Pros • single active node can continuously transmit at full rate of channel • highly decentralized: only slots in nodes need to be in sync • simple Cons • collisions, wasting slots • idle slots • nodes may be able to detect collision in less than time to transmit packet • clock synchronization 63

Slotted Aloha efficiency • For max efficiency with N Efficiency is the long-run nodes,

Slotted Aloha efficiency • For max efficiency with N Efficiency is the long-run nodes, find p* that fraction of successful slots maximizes Np(1 -p)N-1 when there are many nodes, each with many frames to send • For many nodes, take limit of Np*(1 -p*)N-1 as N • Suppose N nodes with goes to infinity, gives 1/e many frames to send, =. 37 each transmits in slot with probability p • prob that node 1 has At best: channel success in a slot = p(1 -p)N-1 used for useful • prob that any node has a transmissions 37% N-1 success = Np(1 -p) of time! 64

Pure (unslotted) ALOHA • unslotted Aloha: simpler, no synchronization • when frame first arrives

Pure (unslotted) ALOHA • unslotted Aloha: simpler, no synchronization • when frame first arrives – transmit immediately • collision probability increases: – frame sent at t 0 collides with other frames sent in [t 01, t 0+1] 65

CSMA (Carrier Sense Multiple Access) CSMA: listen before transmit: If channel sensed idle: transmit

CSMA (Carrier Sense Multiple Access) CSMA: listen before transmit: If channel sensed idle: transmit entire frame • If channel sensed busy, defer transmission • Human analogy: don’t interrupt others! 66

CSMA collisions spatial layout of nodes collisions can still occur: propagation delay means two

CSMA collisions spatial layout of nodes collisions can still occur: propagation delay means two nodes may not hear each other’s transmission collision: entire packet transmission time wasted note: role of distance & propagation delay in determining collision probability 67

CSMA/CD (Collision Detection) CSMA/CD: carrier sensing, deferral as in CSMA – collisions detected within

CSMA/CD (Collision Detection) CSMA/CD: carrier sensing, deferral as in CSMA – collisions detected within short time – colliding transmissions aborted, reducing channel wastage • collision detection: – easy in wired LANs: measure signal strengths, compare transmitted, received signals – difficult in wireless LANs: receiver shut off while transmitting • human analogy: the polite conversationalist 68

CSMA/CD collision detection 69

CSMA/CD collision detection 69

“Taking Turns” MAC protocols channel partitioning MAC protocols: – share channel efficiently and fairly

“Taking Turns” MAC protocols channel partitioning MAC protocols: – share channel efficiently and fairly at high load – inefficient at low load: delay in channel access, 1/N bandwidth allocated even if only 1 active node! Random access MAC protocols – efficient at low load: single node can fully utilize channel – high load: collision overhead “taking turns” protocols look for best of both worlds! 70

“Taking Turns” MAC protocols Polling: • master node “invites” slave nodes to transmit in

“Taking Turns” MAC protocols Polling: • master node “invites” slave nodes to transmit in turn • concerns: – polling overhead – latency – single point of failure (master) Token passing: • control token passed from one node to next sequentially. • token message • concerns: – token overhead – latency – single point of failure (token) 71

Summary of MAC protocols • What do you do with a shared media? –

Summary of MAC protocols • What do you do with a shared media? – Channel Partitioning, by time, frequency or code • Time Division, Frequency Division – Random partitioning (dynamic), • ALOHA, S-ALOHA, CSMA/CD • carrier sensing: easy in some technologies (wire), hard in others (wireless) • CSMA/CD used in Ethernet • CSMA/CA used in 802. 11 – Taking Turns • polling from a central site, token passing 72

MAC Addresses and ARP • 32 -bit IP address: – network-layer address – used

MAC Addresses and ARP • 32 -bit IP address: – network-layer address – used to get datagram to destination IP subnet • MAC (or LAN or physical or Ethernet) address: – used to get datagram from one interface to another physically-connected interface (same network) – 48 bit MAC address (for most LANs) burned in the adapter ROM 73

LAN Addresses and ARP Each adapter on LAN has unique LAN address 1 A-2

LAN Addresses and ARP Each adapter on LAN has unique LAN address 1 A-2 F-BB-76 -09 -AD 71 -65 -F 7 -2 B-08 -53 LAN (wired or wireless) Broadcast address = FF-FF-FF-FF = adapter 58 -23 -D 7 -FA-20 -B 0 0 C-C 4 -11 -6 F-E 3 -98 74

LAN Address (more) • MAC address allocation administered by IEEE • manufacturer buys portion

LAN Address (more) • MAC address allocation administered by IEEE • manufacturer buys portion of MAC address space (to assure uniqueness) • Analogy: (a) MAC address: like Social Security Number (b) IP address: like postal address • MAC flat address ➜ portability – can move LAN card from one LAN to another • IP hierarchical address NOT portable – depends on IP subnet to which node is attached 75

ARP: Address Resolution Protocol Question: how to determine MAC address of B knowing B’s

ARP: Address Resolution Protocol Question: how to determine MAC address of B knowing B’s IP address? 237. 196. 7. 78 1 A-2 F-BB-76 -09 -AD 237. 196. 7. 23 237. 196. 7. 14 LAN 71 -65 -F 7 -2 B-08 -53 237. 196. 7. 88 • Each IP node (Host, Router) on LAN has ARP table • ARP Table: IP/MAC address mappings for some LAN nodes < IP address; MAC address; TTL> – TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min) 58 -23 -D 7 -FA-20 -B 0 0 C-C 4 -11 -6 F-E 3 -98 76

ARP protocol: Same LAN (network) • A wants to send datagram to B, and

ARP protocol: Same LAN (network) • A wants to send datagram to B, and B’s MAC address not in A’s ARP table. • A broadcasts ARP query packet, containing B's IP address – Dest MAC address = FFFF-FF-FF – all machines on LAN receive ARP query • B receives ARP packet, replies to A with its (B's) MAC address – frame sent to A’s MAC address (unicast) • A caches (saves) IP-to-MAC address pair in its ARP table until information becomes old (times out) – soft state: information that times out (goes away) unless refreshed • ARP is “plug-and-play”: – nodes create their ARP tables without intervention from net administrator 77

Routing to another LAN • walkthrough: send datagram from A to B via R

Routing to another LAN • walkthrough: send datagram from A to B via R assume A knows B IP address A R B • Two ARP tables in router R, one for each IP network (LAN) • In ARP table at source, find MAC address E 6 -E 9 -00 -17 -BB-4 B, etc • In routing table at source Host, find router 111. 110 78

 • A creates datagram with source A, destination B • A uses ARP

• A creates datagram with source A, destination B • A uses ARP to get R’s MAC address for 111. 110 • A creates link-layer frame with R's MAC address as dest, frame contains A-to-B IP datagram • A’s adapter sends frame • R’s adapter receives frame • R removes IP datagram from Ethernet frame, sees its destined to B • R uses ARP to get B’s MAC address • R creates frame containing A-to-B IP datagram sends to B A R B 79