Data Communication and Networks

1. Data Communication and Networks Lecture 9/10 Internet Protocols November 6, 2003 Joseph Conron Computer Science Department New York University jconron@cs.nyu.edu

2. millions of connected computing devices: hosts, end-systems pc’s workstations, servers PDA’s phones, toasters running network apps communication links fiber, copper, radio, satellite routers: forward packets (chunks) of data thru network What’s the Internet: Components view

3. protocols: control sending, receiving of msgs e.g., TCP, IP, HTTP, FTP, PPP Internet: “network of networks” loosely hierarchical public Internet versus private intranet Internet standards RFC: Request for comments IETF: Internet Engineering Task Force What’s the Internet: Components view

4. communication infrastructure enables distributed applications: WWW, email, games, e-commerce, database., voting, more? communication services provided: connectionless connection-oriented What’s the Internet: a service view

5. roughly hierarchical national/international backbone providers (NBPs) e.g. BBN/GTE, Sprint, AT&T, IBM, UUNet interconnect (peer) with each other privately, or at public Network Access Point (NAPs) regional ISPs connect into NBPs local ISP, company connect into regional ISPs local ISP local ISP NAP NAP Internet structure: network of networks regional ISP NBP B NBP A regional ISP

6. Connectionless Operation • Corresponds to datagram mechanism in packet switched network • Each NPDU treated separately • Network layer protocol common to all DTEs and routers • Known generically as the internet protocol • Internet Protocol • One such internet protocol developed for ARPANET • RFC 791 (Get it and study it) • Lower layer protocol needed to access particular network

7. Connectionless Internetworking • Advantages • Flexibility • Robust • No unnecessary overhead • Unreliable • Not guaranteed delivery • Not guaranteed order of delivery • Packets can take different routes • Reliability is responsibility of next layer up (e.g. TCP)

8. application: supporting network applications ftp, smtp, http transport: host-host data transfer tcp, udp network: routing of datagrams from source to destination ip, routing protocols link: data transfer between neighboring network elements ppp, ethernet physical: bits “on the wire” application transport network link physical Internet protocol stack

9. M M H H H H H H H H H H H H t t t t l n l t n n t n M M M M application transport network link physical application transport network link physical M M Protocol layering and data Each layer takes data from above • adds header information to create new data unit • passes new data unit to layer below source destination message segment datagram frame

10. Internet Protocol (IP) • Only protocol at Layer 3 • Defines • Internet addressing • Internet packet format • Internet routing • RFC 791 (1981)

11. IP Address Details • 32 Bits - divided into two parts • Prefix identifies network • Suffix identifies host • Global authority assigns unique prefix to network (IANA) • Local administrator assigns unique suffix to host

12. multicast address 1110 network host 110 network 10 host IP Addresses given notion of “network”, let’s examine IP addresses: “class-full” addressing: class 1.0.0.0 to 127.255.255.255 A network 0 host 128.0.0.0 to 191.255.255.255 B 192.0.0.0 to 223.255.255.255 C 224.0.0.0 to 239.255.255.255 D 32 bits

13. Classes and Network Sizes • Maximum network size determined by class of address • Class A large • Class B medium • Class C small

14. IP Addressing Example

15. Subnets and Subnet Masks • Allow arbitrary complexity of internetworked LANs within organization • Insulate overall internet from growth of network numbers and routing complexity • Site looks to rest of internet like single network • Each LAN assigned subnet number • Host portion of address partitioned into subnet number and host number • Local routers route within subnetted network • Subnet mask indicates which bits are subnet number and which are host number

16. Routing Using Subnets

17. host part network part 11001000 0001011100010000 00000000 200.23.16.0/23 IP addressing: CIDR • classful addressing: • inefficient use of address space, address space exhaustion • e.g., class B net allocated enough addresses for 65K hosts, even if only 2K hosts in that network • CIDR:Classless InterDomain Routing • network portion of address of arbitrary length • address format: a.b.c.d/x, where x is # bits in network portion of address

18. Internet Packets • Contains sender and destination addresses • Size depends on data being carried • Called IP datagram • Two Parts Of An IP Datagram • Header • Contains source and destination address • Fixed-size fields • Data Area (Payload) • Variable size up to 64K • No minimum size

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

20. 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 IP Fragmentation & Reassembly fragmentation: in: one large datagram out: 3 smaller datagrams reassembly

21. length =1500 length =4000 length =1040 length =1500 ID =x ID =x ID =x ID =x fragflag =0 fragflag =1 fragflag =0 fragflag =1 offset =0 offset =0 offset =1480 offset =2960 IP Fragmentation and Reassembly One large datagram becomes several smaller datagrams

22. IP Semantics • IP is connectionless • Datagram contains identity of destination • Each datagram sent/ handled independently • Routes can change at any time

23. IP Semantics (continued) • IP allows datagrams to be • Delayed • Duplicated • Delivered out-of-order • Lost • Called best effort delivery • Motivation: accommodate all possible networks

24. Datagram Lifetime • Datagrams could loop indefinitely • Consumes resources • Transport protocol may need upper bound on datagram life • Datagram marked with lifetime • Time To Live field in IP • Once lifetime expires, datagram discarded (not forwarded) • Hop count • Decrement time to live on passing through a each router • Time count • Need to know how long since last router

25. ICMP • Internet Control Message Protocol • RFC 792 • Transfer of (control) messages from routers and hosts to hosts • Feedback about problems • e.g. time to live expired • Encapsulated in IP datagram • Not reliable

26. ICMP Error Messages • When an ICMP error message is sent, the message always contains the IP header and the first 8 bytes of the IP datagram that caused the problem • ICMP has rules regarding error message generation to prevent broadcast storms

27. ICMP Echo Command • Used by “ping” and “tracert” • When a destination IP host receives an ICMP echo command, it returns and ICMP “echo reply” • Ping uses this to determine if a path to a destination (and its return path) are “up” • Tracert uses echo in a clever way to determine the identities of the routers along the path (by “scoping” TTL).

28. Address Resolution Problem • Suppose we know the IP Address of a local system (one to which we are connected) • We would like to send an IP packet to that system. • The link layer (ethernet, for instance) only knows about MAC addresses! • How do we determine the MAC address associated with the IP address?

29. ARP • Address resolution provides a mapping between two different forms of addresses • 32-bit IP addresses and whatever the data link uses • ARP (address resolution protocol) is a protocol used to do address resolution in the TCP/IP protocol suite (RFC826) • ARP provides a dynamic mapping from an IP address to the corresponding hardware address

30. ARP Protocol • A knows B's IP address, wants to learn physical address of B • A broadcasts ARP query pkt, containing B's IP address • all machines on LAN receive ARP query • B receives ARP packet, replies to A with its (B's) physical layer address • A caches (saves) IP-to-physical address pairs until information becomes old (times out) • soft state: information that times out (goes away) unless refreshed

31. ARP Cache • The cache maintains the recent IP to physical address mappings • Each entry is aged (usually the lifetime is 20 minutes) forcing periodic updates of the cache • ARP replies are often broadcast so that all hosts can update their caches

32. ARP Packet Format 8 16 31 Hardware Type Protocol Type Hardware Size Protocol Size Operation Sender’s Hardware Address (for Ethernet 6 bytes) Sender’s Protocol Address (for IP 4 bytes) Target Hardware Address Target Protocol Address Destination IP Address

33. Internet Transport Protocols • Two Transport Protocols Available • Transmission Control Protocol (TCP) • connection oriented • most applications use TCP • RFC 793 • User Datagram Protocol (UDP) • Connectionless • RFC 768

34. Transport layer addressing • Communications endpoint addressed by: • IP address (32 bit) in IP Header • Port number (16 bit) in TP Header1 • Transport protocol (TCP or UDP) in IP Header • 1 TP => Transport Protocol (UDP or TCP)

35. Standard services and port numbers

36. full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s 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 send & receive buffers TCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581

37. TCP Header

38. 32 bits source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent data Options (variable length) application data (variable length) TCP segment structure URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

39. Reliability in an Unreliable World • IP offers best-effort (unreliable) delivery • TCP uses IP • TCP provides completely reliable transfer • How is this possible? How can TCP realize: • Reliable connection startup? • Reliable data transmission? • Graceful connection shutdown?

40. Reliable Data Transmission • Positive acknowledgment • Receiver returns short message when data arrives • Called acknowledgment • Retransmission • Sender starts timer whenever message is transmitted • If timer expires before acknowledgment arrives, sender retransmits message • THIS IS NOT A TRIVIAL PROBLEM! – more on this later.

41. TCP Flow Control • Receiver • Advertises available buffer space • Called window • This is aknown as aCREDITpolicy • Sender • Can send up to entire window before ACK arrives • Each acknowledgment carries new window information • Called window advertisement • Can be zero (called closed window) • Interpretation: I have received up through X, and can take Y more octets

42. Credit Scheme • Decouples flow control from ACK • May ACK without granting credit and vice versa • Each octet has sequence number • Each transport segment has seq number, ack number and window size in header

43. Use of Header Fields • When sending, seq number is that of first octet in segment • ACK includes AN=i, W=j • All octets through SN=i-1 acknowledged • Next expected octet is i • Permission to send additional window of W=j octets • i.e. octets through i+j-1

44. Credit Allocation

45. receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow flow control TCP Flow Control sender won’t overrun receiver’s buffers by transmitting too much, too fast RcvBuffer= size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver buffering

46. Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: 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 time TCP seq. #’s and ACKs Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario

47. TCP ACK generation[RFC 1122, RFC 2581] TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap

48. Host A Host B Seq=92, 8 bytes data ACK=100 timeout X loss Seq=92, 8 bytes data ACK=100 time time lost ACK scenario TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 ACK=120 Seq=100 timeout Seq=92, 8 bytes data ACK=120 premature timeout, cumulative ACKs

49. Why Startup/ Shutdown Difficult? • Segments can be • Lost • Duplicated • Delayed • Delivered out of order • Either side can crash • Either side can reboot • Need to avoid duplicate ‘‘shutdown’’ message from affecting later connection

50. Recall:TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator Socket clientSocket = new Socket("hostname","port number"); server: contacted by client Socket connectionSocket = welcomeSocket.accept(); Three way handshake: Step 1:client end system sends TCP SYN control segment to server specifies initial seq # Step 2:server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # TCP Connection Management