1. Introduction Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Basic Networking Concepts Davide Pesavento davide.pesavento@lip6.fr

2. Transport Layer

3. Internet transport-layer protocols  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 application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 3-2

4. UDP: User Datagram Protocol [RFC 768]  “no frills,” “bare bones” Internet transport protocol  “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  UDP use:  streaming multimedia apps (loss tolerant, rate sensitive)  DNS  SNMP  reliable transfer over UDP:  add reliability at application layer  application-specific error recovery! 3-3

5. 3-4 UDP: segment header source port #dest port # 32 bits application data (payload) UDP segment format length checksum length, in bytes of UDP segment, including header  no connection establishment (which can add delay)  simple: no connection state at sender, receiver  small header size  no congestion control: UDP can blast away as fast as desired why is there a UDP?

6. 3-5 TCP: Overview RFCs: 793,1122,1323, 2018, 2581  full duplex data:  bi-directional data flow in same connection  MSS: maximum segment size  connection-oriented:  handshaking (exchange of control msgs) inits sender, receiver state before data exchange  flow controlled:  sender will not overwhelm receiver  point-to-point:  one sender, one receiver  reliable, in-order byte steam:  no “message boundaries”  pipelined:  TCP congestion and flow control set window size

7. 3-6 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number receive window Urg data pointer checksum F SR PAU head len not used options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

8. 3-7 TCP seq. numbers, ACKs sequence numbers:  byte stream “number” of first byte in segment’s data acknowledgements:  seq # of next byte expected from other side  cumulative ACK Q: how receiver handles out-of-order segments  A: TCP spec doesn’t say, - up to implementor source port # dest port # sequence number acknowledgement number checksum rwnd urg pointer incoming segment to sender A sent ACKed sent, not- yet ACKed (“in-flight”) usable but not yet sent not usable window size N sender sequence number space source port # dest port # sequence number acknowledgement number checksum rwnd urg pointer outgoing segment from sender

9. 3-8 TCP seq. numbers, ACK s User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ simple telnet scenario Host B Host A Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80

10. 3-9 TCP reliable data transfer  TCP creates rdt service on top of IP’s unreliable service  pipelined segments  cumulative acks  single retransmission timer  retransmissions triggered by:  timeout events  duplicate acks let’s initially consider simplified TCP sender:  ignore duplicate acks  ignore flow control, congestion control

11. 3-10 TCP sender events: data rcvd from app:  create segment with seq #  seq # is byte-stream number of first data byte in segment  start timer if not already running  think of timer as for oldest unacked segment  expiration interval: TimeOutInterval timeout:  retransmit segment that caused timeout  restart timer ack rcvd:  if ack acknowledges previously unacked segments  update what is known to be ACKed  start timer if there are still unacked segments

12. 3-11 TCP: retransmission scenarios lost ACK scenario Host B Host A Seq=92, 8 bytes of data ACK=100 Seq=92, 8 bytes of data X timeout ACK=100 premature timeout Host B Host A Seq=92, 8 bytes of data ACK=100 Seq=92, 8 bytes of data timeout ACK=120 Seq=100, 20 bytes of data ACK=120 SendBase=100 SendBase=120 SendBase=92

13. 3-12 TCP: retransmission scenarios X cumulative ACK Host B Host A Seq=92, 8 bytes of data ACK=100 Seq=120, 15 bytes of data timeout Seq=100, 20 bytes of data ACK=120

14. 3-13 TCP ACK generation [RFC 1122, RFC 2581] event at receiver arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed arrival of in-order segment with expected seq #. One other segment has ACK pending arrival of out-of-order segment higher-than-expect seq. #. Gap detected arrival of segment that partially or completely fills gap TCP receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK, ACKing both in-order segments immediately send duplicate ACK, indicating seq. # of next expected byte immediate send ACK, provided that segment starts at lower end of gap

15. 3-14 TCP fast retransmit  time-out period often relatively long:  long delay before resending lost packet  detect lost segments via duplicate ACKs.  sender often sends many segments back- to-back  if segment is lost, there will likely be many duplicate ACKs. if sender receives 3 ACKs for same data (“triple duplicate ACKs”), resend unacked segment with smallest seq #  likely that unacked segment lost, so don’t wait for timeout TCP fast retransmit (“triple duplicate ACKs”),

16. 3-15 X fast retransmit after sender receipt of triple duplicate ACK Host B Host A Seq=92, 8 bytes of data ACK=100 timeout ACK=100 TCP fast retransmit Seq=100, 20 bytes of data

17. 3-16 TCP 3-way handshake SYNbit=1, Seq=x choose init seq num, x send TCP SYN msg ESTAB SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 choose init seq num, y send TCP SYNACK msg, acking SYN ACKbit=1, ACKnum=y+1 received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data received ACK(y) indicates client is live SYNSENT ESTAB SYN RCVD client state LISTEN server state LISTEN

18. 3-17 TCP 3-way handshake: FSM closed  listen SYN rcvd SYN sent ESTAB Socket clientSocket = newSocket("hostname","port number"); SYN(seq=x) Socket connectionSocket = welcomeSocket.accept(); SYN(x) SYNACK(seq=y,ACKnum=x+1) create new socket for communication back to client SYNACK(seq=y,ACKnum=x+1) ACK(ACKnum=y+1) 

19. 3-18 TCP: closing a connection  client, server each close their side of connection  send TCP segment with FIN bit = 1  respond to received FIN with ACK  on receiving FIN, ACK can be combined with own FIN  simultaneous FIN exchanges can be handled

20. 3-19 FIN_WAIT_2 CLOSE_WAIT FINbit=1, seq=y ACKbit=1; ACKnum=y+1 ACKbit=1; ACKnum=x+1 wait for server close can still send data can no longer send data LAST_ACK CLOSED TIMED_WAIT timed wait for 2*max segment lifetime CLOSED TCP: closing a connection FIN_WAIT_1 FINbit=1, seq=x can no longer send but can receive data clientSocket.close() client state server state ESTAB

21. Network Layer

22. 4-21 Network layer  transport segment from sending to receiving host  on sending side encapsulates segments into datagrams  on receiving side, delivers segments to transport layer  network layer protocols in every host, router  router examines header fields in all IP datagrams passing through it application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical

23. 4-22 Two key network-layer functions  forwarding: move packets from router’s input to appropriate router output  routing: determine route taken by packets from source to dest.  routing algorithms analogy:  routing: process of planning trip from source to dest  forwarding: process of getting through single interchange

24. 4-23 1 2 3 0111 value in arriving packet’s header routing algorithm local forwarding table header value output link 0100 0101 0111 1001 32213221 Interplay between routing and forwarding routing algorithm determines end-end-path through network forwarding table determines local forwarding at this router

25. 4-24 The Internet network layer forwarding table host, router network layer functions: routing protocols path selection RIP, OSPF, BGP IP protocol addressing conventions datagram format packet handling conventions ICMP protocol error reporting router “signaling” transport layer: TCP, UDP link layer physical layer network layer

26. 4-25 ver length 32 bits data (variable length, typically a TCP or UDP segment) 16-bit identifier header checksum time to live 32 bit source IP address head. len type of service flgs fragment offset upper layer 32 bit destination IP address options (if any) IP datagram format IP protocol version number header length (bytes) upper layer protocol to deliver payload to total datagram length (bytes) “type” of data for fragmentation/ reassembly max number remaining hops (decremented at each router) e.g. timestamp, record route taken, specify list of routers to visit. how much overhead?  20 bytes of TCP  20 bytes of IP  = 40 bytes + app layer overhead

27. 4-26 IP fragmentation, reassembly  network links have MTU (max.transfer size) - largest possible link-level frame  different link types, different MTUs  large IP datagram divided (“fragmented”) within net  one datagram becomes several datagrams  “reassembled” only at final destination  IP header bits used to identify, order related fragments fragmentation: in: one large datagram out: 3 smaller datagrams reassembly … …

28. 4-27 ID =x offset =0 fragflag =0 length =4000 ID =x offset =0 fragflag =1 length =1500 ID =x offset =185 fragflag =1 length =1500 ID =x offset =370 fragflag =0 length =1040 one large datagram becomes several smaller datagrams example:  4000 byte datagram  MTU = 1500 bytes 1480 bytes in data field offset = 1480/8 IP fragmentation, reassembly

29. 4-28 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 Code description 0 0 echo reply (ping) 3 0 dest. network unreachable 3 1 dest host unreachable 3 2 dest protocol unreachable 3 3 dest port unreachable 3 6 dest network unknown 3 7 dest host unknown 4 0 source quench (congestion control - not used) 8 0 echo request (ping) 9 0 route advertisement 10 0 router discovery 11 0 TTL expired 12 0 bad IP header

30. 4-29 Traceroute and ICMP  source sends series of UDP segments to dest  first set has TTL =1  second set has TTL=2, etc.  unlikely port number  when nth set of datagrams arrives to nth router:  router discards datagrams  and sends source ICMP messages (type 11, code 0)  ICMP messages includes name of router & IP address  when ICMP messages arrives, source records RTTs stopping criteria:  UDP segment eventually arrives at destination host  destination returns ICMP “port unreachable” message (type 3, code 3)  source stops 3 probes

31. 4-30 IPv6: motivation  initial motivation: 32-bit address space soon to be completely allocated.  additional motivation:  header format helps speed processing/forwarding  header changes to facilitate QoS IPv6 datagram format:  fixed-length 40 byte header  no fragmentation allowed

32. 4-31 IPv6 datagram format priority: identify priority among datagrams in flow flow Label: identify datagrams in same “flow.” (concept of“flow” not well defined). next header: identify upper layer protocol for data data destination address (128 bits) source address (128 bits) payload len next hdr hop limit flow label pri ver 32 bits

33. 4-32 Other changes from IPv4  checksum: removed entirely to reduce processing time at each hop  options: allowed, but outside of header, indicated by “Next Header” field  ICMPv6: new version of ICMP  additional message types, e.g. “Packet Too Big”  multicast group management functions

34. 4-33 Transition from IPv4 to IPv6  not all routers can be upgraded simultaneously  no “flag days”  how will network operate with mixed IPv4 and IPv6 routers?  tunneling: IPv6 datagram carried as payload in IPv4 datagram among IPv4 routers IPv4 source, dest addr IPv4 header fields IPv4 datagram IPv6 datagram IPv4 payload UDP/TCP payload IPv6 source dest addr IPv6 header fields

35. 4-34 Tunneling physical view: IPv4 A B IPv6 E F C D logical view: IPv4 tunnel connecting IPv6 routers E IPv6 F A B

36. 4-35 flow: X src: A dest: F data A-to-B: IPv6 Flow: X Src: A Dest: F data src:B dest: E B-to-C: IPv6 inside IPv4 E-to-F: IPv6 flow: X src: A dest: F data B-to-C: IPv6 inside IPv4 Flow: X Src: A Dest: F data src:B dest: E physical view: A B IPv6 E F C D logical view: IPv4 tunnel connecting IPv6 routers E IPv6 F A B Tunneling IPv4

37. 4-36 R1 R2 R3R4 source duplication R1 R2 R3R4 in-network duplication duplicate creation/transmission duplicate Broadcast routing  deliver packets from source to all other nodes  source duplication is inefficient:  source duplication: how does source determine recipient addresses?

38. 4-37 In-network duplication  flooding: when node receives broadcast packet, sends copy to all neighbors  problems: cycles & broadcast storm  controlled flooding: node only broadcasts pkt if it hasn’t broadcast same packet before  node keeps track of packet ids already broadacsted  or reverse path forwarding (RPF): only forward packet if it arrived on shortest path between node and source  spanning tree:  no redundant packets received by any node

39. 4-38 A B G D E c F A B G D E c F (a) broadcast initiated at A (b) broadcast initiated at D Spanning tree  first construct a spanning tree  nodes then forward/make copies only along spanning tree

40. Link Layer

41. 5-40 Link layer: introduction terminology:  hosts and routers: nodes  communication channels that connect adjacent nodes along communication path: links  wired links  wireless links  LANs  layer-2 packet: frame, encapsulates datagram data-link layer has responsibility of transferring datagram from one node to physically adjacent node over a link global ISP

42. 5-41 Link layer: context  datagram transferred by different link protocols over different links:  e.g., Ethernet on first link, frame relay on intermediate links, 802.11 on last link  each link protocol provides different services  e.g., may or may not provide rdt over link transportation analogy:  trip from Princeton to Lausanne  limo: Princeton to JFK  plane: JFK to Geneva  train: Geneva to Lausanne  tourist = datagram  transport segment = communication link  transportation mode = link layer protocol  travel agent = routing algorithm

43. 5-42 Multiple access links, protocols two types of “links”:  point-to-point  PPP for dial-up access  point-to-point link between Ethernet switch, host  broadcast (shared wire or medium)  old-fashioned Ethernet  upstream HFC  802.11 wireless LAN shared wire (e.g., cabled Ethernet) shared RF (e.g., 802.11 WiFi) shared RF (satellite) humans at a cocktail party (shared air, acoustical)

44. 5-43 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!  no out-of-band channel for coordination

45. 5-44 MAC protocols: 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

46. 5-45 Channel partitioning MAC protocols: TDMA 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 1 3 4 1 3 4 6-slot frame 6-slot frame

47. 5-46 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 frequency bands time FDM cable Channel partitioning MAC protocols: FDMA

48. 5-47 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  ALOHA  CSMA, CSMA/CD, CSMA/CA

49. 5-48 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!

50. 5-49 CSMA collisions  collisions can still occur: propagation delay means two nodes may not hear each other’s transmission  collision: entire packet transmission time wasted  distance & propagation delay play role in in determining collision probability spatial layout of nodes

51. 5-50 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: received signal strength overwhelmed by local transmission strength  human analogy: the polite conversationalist

52. 5-51 CSMA/CD (collision detection) spatial layout of nodes

53. 5-52 Ethernet CSMA/CD algorithm 1. NIC receives datagram from network layer, creates frame 2. If NIC senses channel idle, starts frame transmission. If NIC senses channel busy, waits until channel idle, then transmits. 3. If NIC transmits entire frame without detecting another transmission, NIC is done with frame ! 4. If NIC detects another transmission while transmitting, aborts and sends jam signal 5. After aborting, NIC enters binary (exponential) backoff:  after mth collision, NIC chooses K at random from {0,1,2, …, 2 m -1}. NIC waits K · 512 bit times, returns to Step 2  longer backoff interval with more collisions

54. 5-53 MAC addresses and ARP  32-bit IP address:  network-layer address for interface  used for layer 3 (network layer) forwarding  MAC (or LAN or physical or Ethernet) address:  function: used ‘locally” to get frame from one interface to another physically-connected interface (same network, in IP- addressing sense)  48 bit MAC address (for most LANs) burned in NIC ROM, also sometimes software settable  e.g.: 1A-2F-BB-76-09-AD hexadecimal (base 16) notation (each “number” represents 4 bits)

55. 5-54 LAN addresses and ARP each adapter on LAN has unique LAN address adapter 1A-2F-BB-76-09-AD 58-23-D7-FA-20-B0 0C-C4-11-6F-E3-98 71-65-F7-2B-08-53 LAN (wired or wireless)

56. 5-55 ARP: address resolution protocol ARP table: each IP node (host, router) on LAN has table  IP/MAC address mappings for some LAN nodes:  TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min) Question: how to determine interface’s MAC address, knowing its IP address? 1A-2F-BB-76-09-AD 58-23-D7-FA-20-B0 0C-C4-11-6F-E3-98 71-65-F7-2B-08-53 LAN 137.196.7.23 137.196.7.78 137.196.7.14 137.196.7.88

57. 5-56 ARP protocol: same LAN  A wants to send datagram to B  B’s MAC address not in A’s ARP table.  A broadcasts ARP query packet, containing B's IP address  dest MAC address = FF-FF- FF-FF-FF-FF  all nodes 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

58. 5-57 Ethernet frame structure sending adapter encapsulates IP datagram (or other network layer protocol packet) in Ethernet frame preamble:  7 bytes with pattern 10101010 followed by one byte with pattern 10101011  used to synchronize receiver, sender clock rates dest. address source address data (payload) CRC preamble type

59. 5-58 Ethernet frame structure (more)  addresses: 6 byte source, destination MAC addresses  if adapter receives frame with matching destination address, or with broadcast address (e.g. ARP packet), it passes data in frame to network layer protocol  otherwise, adapter discards frame  type: indicates higher layer protocol (mostly IP but others possible, e.g., Novell IPX, AppleTalk)  CRC: cyclic redundancy check at receiver  error detected: frame is dropped dest. address source address data (payload) CRC preamble type

60. 5-59 Ethernet: unreliable, connectionless  connectionless: no handshaking between sending and receiving NICs  unreliable: receiving NIC doesnt send acks or nacks to sending NIC  data in dropped frames recovered only if initial sender uses higher layer rdt (e.g., TCP), otherwise dropped data lost  Ethernet’s MAC protocol: unslotted CSMA/CD wth binary backoff

61. 5-60 Synthesis: a day in the life of a web request  journey down protocol stack complete!  application, transport, network, link  putting-it-all-together: synthesis!  goal: identify, review, understand protocols (at all layers) involved in seemingly simple scenario: requesting www page  scenario: student attaches laptop to campus network, requests/receives www.google.com

62. 5-61 A day in the life: scenario Comcast network 68.80.0.0/13 Google’s network 64.233.160.0/19 64.233.169.105 web server DNS server school network 68.80.2.0/24 web page browser

63. router (runs DHCP) 5-62 A day in the life… connecting to the Internet  connecting laptop needs to get its own IP address, addr of first-hop router, addr of DNS server: use DHCP DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP  DHCP request encapsulated in UDP, encapsulated in IP, encapsulated in 802.3 Ethernet  Ethernet frame broadcast (dest: FFFFFFFFFFFF) on LAN, received at router running DHCP server  Ethernet demuxed to IP demuxed, UDP demuxed to DHCP

64. router (runs DHCP) 5-63  DHCP server formulates DHCP ACK containing client’s IP address, IP address of first-hop router for client, name & IP address of DNS server DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP  encapsulation at DHCP server, frame forwarded (switch learning) through LAN, demultiplexing at client Client now has IP address, knows name & addr of DNS server, IP address of its first-hop router  DHCP client receives DHCP ACK reply A day in the life… connecting to the Internet

65. router (runs DHCP) 5-64 A day in the life… ARP (before DNS, before HTTP)  before sending HTTP request, need IP address of www.google.com: DNS DNS UDP IP Eth Phy DNS  DNS query created, encapsulated in UDP, encapsulated in IP, encapsulated in Eth. To send frame to router, need MAC address of router interface: ARP  ARP query broadcast, received by router, which replies with ARP reply giving MAC address of router interface  client now knows MAC address of first hop router, so can now send frame containing DNS query ARP query Eth Phy ARP ARP reply

66. router (runs DHCP) 5-65 DNS UDP IP Eth Phy DNS  IP datagram containing DNS query forwarded via LAN switch from client to 1 st hop router  IP datagram forwarded from campus network into comcast network, routed (tables created by RIP, OSPF, IS-IS and/or BGP routing protocols) to DNS server  demux’ed to DNS server  DNS server replies to client with IP address of www.google.com Comcast network 68.80.0.0/13 DNS server DNS UDP IP Eth Phy DNS A day in the life… using DNS

67. router (runs DHCP) 5-66 A day in the life…TCP connection carrying HTTP HTTP TCP IP Eth Phy HTTP  to send HTTP request, client first opens TCP socket to web server  TCP SYN segment (step 1 in 3- way handshake) inter-domain routed to web server  TCP connection established! 64.233.169.105 web server SYN TCP IP Eth Phy SYN SYNACK  web server responds with TCP SYNACK (step 2 in 3-way handshake)

68. router (runs DHCP) 5-67 A day in the life… HTTP request/reply HTTP TCP IP Eth Phy HTTP  HTTP request sent into TCP socket  IP datagram containing HTTP request routed to www.google.com  IP datagram containing HTTP reply routed back to client 64.233.169.105 web server HTTP TCP IP Eth Phy  web server responds with HTTP reply (containing web page) HTTP  web page finally (!!!) displayed