CENG415 – Communication Networks

CENG415 – Communication Networks Lectures 6 Transport layer

Transport layer We will cover • Transport-layer services • Multiplexing and demultiplexing • Connectionless transport: UDP • Principles of reliable data transfer • Connection-oriented transport: TCP • segment structure • reliable data transfer • flow control • connection management • Principles of congestion control • TCP congestion control

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 logical end-end transport Transport services and protocols • 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 • Two transport protocols available • TCP • UDP

Transport VS. network layer Household analogy: 12 kids sending letters to 12 kids • Processes (applications) = kids • app messages = letters in envelopes • hosts = houses • transport protocol: • Ahmad: will do his best • Sarah: will guarantee delivery • network-layer protocol = postal service • network layer:logical communication between hosts • transport layer: logical communication between processes

TCP/IP transport protocols • TCP: • reliable, in-order delivery • congestion control • flow control • connection setup • UDP: • unreliable, unordered delivery • services not available: • delay guarantees • bandwidth guarantees

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

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

Port number NOTE 1: • Port numbers are not unique between transport layer protocols • the numbers are only unique within a specific transport protocol • TCP and UDP can, and do, both assign the same port numbers • It is the combination of protocol and port numbers that uniquely identifies the specific process to which the data should be delivered NOTE 2: • Well-known ports are standardized port numbers that enable remote computers to know which port to connect to for a particular network service. • Both the sender and receiver know in advance that data bound for a specific process will use a specific port. • Example, all systems that offer telnet do so on port 23 • Dynamically allocated ports provide the flexibility needed to support multiple users. • To uniquely identify every connection, the source port is assigned a dynamically allocated port number, and the well-known port number is used for the destination port.

Connectionless demultiplexing • Create sockets with port numbers • UDP socket identified by 3 tuples (“UDP”, dest IP address, dest port number) • When host receives UDP segment: • checks destination port number in segment • directs UDP segment to socket with that port number • IP datagrams with different source IP addresses and/or source port numbers and same destination port number are directed to same UDP socket • JAVA Create sockets with dynamic port number (client side): • DatagramSocket mySocket1 = new DatagramSocket( ); • Automatically assigned between 1024 and 65535 (not used by any other UDP) • Create sockets with port numbers (server side): • DatagramSocket mySocket1 = new DatagramSocket(53);

P2 P1 P1 P3 SP: 9157 client IP: A DP: 6428 Client IP:B server IP: C SP: 6428 SP: 6428 SP: 5775 DP: 6428 DP: 9157 DP: 5775 Connectionless demux Same incoming UDP destination port, delivered to same process, the one that opened that socket. SP provides “return address”

SP: 9157 SP: 5775 P1 P1 P2 P4 P3 P6 P5 client IP: A DP: 80 DP: 80 Connection-oriented demux TCP socket identified by 5 tuples (TCP, source IP address, source port number, dest IP address, dest port number) • recv host TCP layer uses all 4 values to direct segment to socket • Server host may support many simultaneous TCP sockets: • each TCP socket identified by its own 4-tuple (5-tuple) • Web servers have different sockets for each connecting client • non-persistent HTTP will have different socket (different client port number) for each request S-IP: B D-IP:C SP: 9157 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C

SP: * SP: 5775 SP: 9157 P1 P1 P2 P3 client IP: A DP: 80 DP: 80 DP: 80 Connection-oriented demux: WEB server Different TCP source port -> different process (thread) Listening Socket P4 * S-IP: * S-IP: B D-IP:C * = "any" D-IP:C SP: 9157 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C thread, spawned or "forked" from main process, manages each connected socket. • Server is listening on socket * • Each time a connection is established, server open new socket for that connection and continue listening on socket *.

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 applications connectionless: • no handshaking between UDP sender, receiver • each UDP segment handled independently of others • often used for streaming multimedia apps • loss tolerant • rate sensitive • other UDP uses • DNS (name lookup) • SNMP (network management) 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

Length, in bytes of UDP segment, including header UDP format 32 bits Goal of checksum: detect “errors” (e.g., flipped bits) in transmitted segment source port # dest port # Sender: • treat segment contents as sequence of 16-bit integers • checksum: addition (1’s complement sum) of segment contents • sender puts checksum value into UDP checksum field Receiver: • compute checksum of received segment • check if computed checksum equals checksum field value: • NO - error detected • YES - no error detected. But maybe errors nonetheless? More later …. checksum length Application data (message) UDP segment format

Checksum • Note • When adding numbers, a carryout from the most significant bit needs to be added to the result 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound sum checksum

Lab: Packet tracer - UDP • Open the CENG415-network packet tracer • Wait until all connection lights are green • Click once on PC0 to open PC0 configuration • Select the Desktop tab • Click once on Command Prompt

Lab: Packet tracer - UDP • From the button right of Packet Tracer, select Simulation • Click on Event List to close it • Now go back to the Command Prompt of PC0 and type: • ping www.ceng415.com • You will see a small envelop on PC0. This is PC0 sending a message to the DNS server to resolve the address of www. ceng415.com

Lab: Packet tracer - UDP • Click on capture /forward • You will notice the envelop moving • Keep clicking till the envelop reaches router 2 • Double click on the envelop to open it • This will open the window “PDU information at device: router2” • Select the “Inbound PDU details” tab • Check the message

LAB: UDP • What is the destination port number? • What transport protocol is used? • What type of message? • What is the IP of the DNS server?

LAB: UDP checksum computation • The objective of this lab is to compute the checksum in the header of a UDP message • Use Wireshark to capture traces as follow: • Open Wireshark • Select Capture / Options • From Interface, select your network card • In Capture filter, select UDP only • Click on Start • Now open a CMD and type • ping www.google.com • In Wireshark, click on Capture / Stop • You now have the traces to work with • In filter, write UDP and click on apply. • Select the first DNS message (that is a UDP)

LAB: UDP checksum computation Checksum in UDP header is computed as follow: From the IP header: • Source IP address • Destination IP address • Protocol number  0011 for udp • From the UDP header: • Source port • Destination port • UDP length (including data) • UDP length field • From the UDP data: • All the message After adding all the HEX values, then adding the carry to the 16 bits value, complement to get the checksum.

LAB: Wireshark traces

LAB: UDP checksum computation • Source IP address: • Destination IP address: • Protocol number : 0011 for UDP • Source and destination ports: • UDP length *2 : 0026 * 2 = 004C Till now: 15280 • The message (underlined with read) 222B1 • Total: 15280 + 222B1 = 37531 • Adding the Carry: 7531 + 3 = 7534 • Complement: 8ACB 80ee 26a0 80ee 1d17 0c5b 0035

LAB: Windows files Browse your windows OS to the following directory: C:\windows\system32\drivers\etc • services: This file contains port numbers for well known services • protocols: this file contains internet protocols and the assigned numbers. EX: UDP 1710 = 11HEX

CENG415 – Communication Networks