Chapter 3 Transport Layer A note on the

Chapter 3 Transport Layer A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in Power. Point form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: v If you use these slides (e. g. , in a class) that you mention their source (after all, we’d like people to use our book!) v If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Thanks and enjoy! JFK/KWR All material copyright 1996 -2012 J. F Kurose and K. W. Ross, All Rights Reserved Transport Layer 3 -1

3. 1 Introduction and Transport-Layer Services : Transport services and protocols v le ca gi nd -e nd ns tra t r po v application transport network data link physical lo v provide logical communication between app processes running on different hosts (meaning as if the hosts running the processes were directly connected) 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 Transport Layer 3 -2

3. 1 Introduction and Transport-Layer Services : Transport vs. network layer v v network layer: logical communication between hosts transport layer: logical communication between processes § relies on, enhances, network layer services household analogy: 12 kids in Ann’s house sending letters to 12 kids in Bill’s house: v hosts = houses v processes = kids v app messages = letters in envelopes v transport protocol = Ann and Bill who demux to inhouse siblings v network-layer protocol = postal service Transport Layer 3 -3

3. 1 Introduction and Transport-Layer Services : Internet transport-layer protocols v reliable, in-order delivery (TCP) ns tra network data link physical d n -e network data link physical t r po services not available: nd v network data link physical le § no-frills extension of “best-effort” IP network data link physical ca unreliable, unordered delivery: UDP gi v network data link physical lo § congestion control § flow control § connection setup application transport network data link physical § delay guarantees § bandwidth guarantees Transport Layer 3 -4

3. 2 Multiplexing/Demultiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing) demultiplexing at receiver: use header info to deliver received segments to correct socket application P 1 P 2 application P 3 transport P 4 transport network link network physical socket link physical process physical Transport Layer 3 -5

3. 2 Multiplexing/Demultiplexing : How demultiplexing works v host receives IP datagrams § each datagram has source IP address, destination IP address § each datagram carries one transport-layer segment § each segment has source, destination port number v host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (payload) TCP/UDP segment format Transport Layer 3 -6

3. 2 Multiplexing/Demultiplexing : Connectionless demultiplexing v recall: created socket has host- recall: when creating v local port #: datagram to send into Datagram. Socket my. Socket 1 UDP socket, must specify = new Datagram. Socket(12534); v when host receives UDP segment: § checks destination port # in segment § directs UDP segment to socket with that port # § destination IP address § destination port # IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest Transport Layer 3 -7

3. 2 Multiplexing/Demultiplexing : Connectionless demux: example Datagram. Socket my. Socket 2 = new Datagram. Socket (9157); Datagram. Socket server. Socket = new Datagram. Socket (6428); application Datagram. Socket my. Socket 1 = new Datagram. Socket (5775); P 1 application P 3 P 4 transport network link physical source port: 6428 dest port: 9157 source port: 9157 dest port: 6428 source port: ? dest port: ? Transport Layer 3 -8

3. 2 Multiplexing/Demultiplexing : Connection-oriented demux v TCP socket identified by 4 -tuple: § source IP address § source port number § dest IP address § dest port number v demux: receiver uses all four values to direct segment to appropriate socket v server host may support many simultaneous TCP sockets: § each socket identified by its own 4 -tuple v web servers have different sockets for each connecting client § non-persistent HTTP will have different socket for each request Transport Layer 3 -9

3. 2 Multiplexing/Demultiplexing : Connection-oriented demux: example application P 4 P 3 P 5 application P 6 P 3 P 2 transport network link physical host: IP address A server: IP address B source IP, port: B, 80 dest IP, port: A, 9157 source IP, port: A, 9157 dest IP, port: B, 80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets physical source IP, port: C, 5775 dest IP, port: B, 80 host: IP address C source IP, port: C, 9157 dest IP, port: B, 80 Transport Layer 3 -10

3. 2 Multiplexing/Demultiplexing : Connection-oriented demux: example threaded server application P 3 application P 4 P 3 P 2 transport network link physical host: IP address A server: IP address B source IP, port: B, 80 dest IP, port: A, 9157 source IP, port: A, 9157 dest IP, port: B, 80 physical source IP, port: C, 5775 dest IP, port: B, 80 host: IP address C source IP, port: C, 9157 dest IP, port: B, 80 Transport Layer 3 -11

3. 3 Connectionless Transport : User Datagram Protocol [RFC 768] v v v “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 v UDP use: § streaming multimedia apps (loss tolerant, rate sensitive) § DNS § SNMP v reliable transfer over UDP: § add reliability at application layer § application-specific error recovery! Transport Layer 3 -12

3. 3 Connectionless Transport : UDP segment header 32 bits source port # dest port # length checksum application data (payload) length, in bytes of UDP segment, including header why is there a UDP? v v v UDP segment format v 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 Transport Layer 3 -13

3. 3 Connectionless Transport : UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment sender: receiver: v v treat segment contents, including header fields, as sequence of 16 -bit integers checksum: take the 1’s complement for the addition of segment contents sender puts checksum value into UDP checksum field v 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 …. Transport Layer 3 -14

3. 3 Connectionless Transport : Internet checksum (example) 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 (1’s complement) Note: when adding numbers, a carryout from the most significant bit needs to be added to the result Transport Layer 3 -15

3. 5 Connection-Oriented Transport : TCP Overview RFCs: 793, 1122, 1323, 2018, 2581 v connection-oriented: § handshaking (exchange of control msgs) inits sender, receiver state before data exchange v point-to-point: reliable, in-order byte stream: § no “message boundaries” v flow controlled: § sender will not overwhelm receiver full duplex data: § bi-directional data flow in same connection § MSS: maximum segment size v v v pipelined: § TCP congestion and flow control set window size § one sender, one receiver § multicasting (one sender to many receivers ) is not possible with TCP Transport Layer 3 -16

3. 5 Connection-Oriented Transport : how a TCP connection is established v The client application first informs the client transport layer that it wants to establish a connection to process in the server (ex) a Python client program: client. Socket. connect((server. Name, server. Port)) v The client first sends a special TCP segment; the server responds with a second special TCP segment; and finally the client responds again with a third special segment three-way handshake (three segments between two hosts) v The client process passes a stream of data through the socket. Once the data passes through the socket, the data is in the hands of TCP running in the client v TCP directs this data to the connection’s send buffer. From time to time, TCP will grab chunks of data from the send buffer and pass the data to the network layer. The maximum amount of data that can be grabbed and placed in a segment is limited by the maximum segment size (MSS) Transport Layer 3 -17

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

3. 5 Connection-Oriented Transport : TCP segment structure v The MSS limits the maximum size of a segment’s data fields. When TCP sends a large file it typically breaks the file into chunks of size MSS. (note: data chunks smaller than MSS are possible) v The 32 -bit sequence number field and the 32 -bit acknowledgement number field are for implementing a reliable data transfer service v 16 -bit receive window field is for flow control (i. e. indicates the number of bytes that a receiver is willing to accept) v The 4 -bit header length filed. The TCP header can be of variable length due to the TCP options filed v The optional and variable-length options field is to negotiate the MSS or as a window scaling factor. A time-stamping option is also defined. Transport Layer 3 -19

3. 5 Connection-Oriented Transport : TCP segment structure v The flag field contains bits: § The ACK bit is used to indicate that the value carried in the acknowledgement filed is valid § The RST, SYN, and FIN bits are used for connection setup and tear down § The PSH bit indicates that the receiver should pass the data to the upper layer immediately § The URG bit is used to indicate that there is data in this segment that the sending-side upper-layer entity has marked as “urgent” Transport Layer 3 -20