Presentation on theme: "Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A."— Presentation transcript:
Transport Layer 3-1 Chapter 3 Transport Layer Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint 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: 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!) 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. Thanks and enjoy! JFK/KWR All material copyright 1996-2012 J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-2 3.1 Introduction and Transport-Layer Services : Transport services and protocols 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 logical end-end transport application transport network data link physical
Transport Layer 3-3 3.1 Introduction and Transport-Layer Services : Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services 12 kids in Ann’s house sending letters to 12 kids in Bill’s house: hosts = houses processes = kids app messages = letters in envelopes transport protocol = Ann and Bill who demux to in- house siblings network-layer protocol = postal service household analogy:
Transport Layer 3-4 3.1 Introduction and Transport-Layer Services : 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
Transport Layer 3-5 3.2 Multiplexing/Demultiplexing process socket use header info to deliver received segments to correct socket demultiplexing at receiver: handle data from multiple sockets, add transport header (later used for demultiplexing) multiplexing at sender: transport application physical link network P2P1 transport application physical link network P4 transport application physical link network P3
Transport Layer 3-6 3.2 Multiplexing/Demultiplexing : How demultiplexing work s 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 host uses IP addresses & port numbers to direct segment to appropriate socket source port #dest port # 32 bits application data (payload) other header fields TCP/UDP segment format
Transport Layer 3-7 3.2 Multiplexing/Demultiplexing : Connectionless demultiplexing recall: created socket has host-local port #: DatagramSocket mySocket1 = new DatagramSocket(12534); when host receives UDP segment: checks destination port # in segment directs UDP segment to socket with that port # recall: when creating datagram to send into UDP socket, must specify 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-8 3.2 Multiplexing/Demultiplexing : Connectionless demux: example DatagramSocket serverSocket = new DatagramSocket (6428); transport application physical link network P3 transport application physical link network P1 transport application physical link network P4 DatagramSocket mySocket1 = new DatagramSocket (5775); DatagramSocket mySocket2 = new DatagramSocket (9157); source port: 9157 dest port: 6428 source port: 6428 dest port: 9157 source port: ? dest port: ? source port: ? dest port: ?
Transport Layer 3-9 3.2 Multiplexing/Demultiplexing : Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number demux: receiver uses all four values to direct segment to appropriate socket server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request
Transport Layer 3-10 3.2 Multiplexing/Demultiplexing : Connection-oriented demux: example transport application physical link network P3 transport application physical link P4 transport application physical link network P2 source IP,port: A,9157 dest IP, port: B,80 source IP,port: B,80 dest IP,port: A,9157 host: IP address A host: IP address C network P6 P5 P3 source IP,port: C,5775 dest IP,port: B,80 source IP,port: C,9157 dest IP,port: B,80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets server: IP address B
Transport Layer 3-11 3.2 Multiplexing/Demultiplexing : Connection-oriented demux: example transport application physical link network P3 transport application physical link transport application physical link network P2 source IP,port: A,9157 dest IP, port: B,80 source IP,port: B,80 dest IP,port: A,9157 host: IP address A host: IP address C server: IP address B network P3 source IP,port: C,5775 dest IP,port: B,80 source IP,port: C,9157 dest IP,port: B,80 P4 threaded server
Transport Layer 3-12 3.3 Connectionless Transport : 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!
Transport Layer 3-13 3.3 Connectionless Transport : 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?
Transport Layer 3-14 3.3 Connectionless Transport : UDP checksum sender: 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 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 …. Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Transport Layer 3-15 3.3 Connectionless Transport : Internet checksum (example) example: add two 16-bit integers 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 (1’s complement) Note: when adding numbers, a carryout from the most significant bit needs to be added to the result
Transport Layer 3-16 3.5 Connection-Oriented Transport : TCP Overview RFCs: 793,1122,1323, 2018, 2581 reliable, in-order byte stream: no “message boundaries” flow controlled: sender will not overwhelm receiver pipelined: TCP congestion and flow control set window size connection-oriented: handshaking (exchange of control msgs) inits sender, receiver state before data exchange full duplex data: bi-directional data flow in same connection MSS: maximum segment size point-to-point: one sender, one receiver multicasting (one sender to many receivers ) is not possible with TCP
3.5 Connection-Oriented Transport : how a TCP connection is established 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: clientSocket.connect((serverName, serverPort)) 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) 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 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
Transport Layer 3-18 3.5 Connection-Oriented Transport : 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)
3.5 Connection-Oriented Transport : TCP segment structure 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) The 32-bit sequence number field and the 32-bit acknowledgement number field are for implementing a reliable data transfer service 16-bit receive window field is for flow control (i.e. indicates the number of bytes that a receiver is willing to accept) The 4 -bit header length filed. The TCP header can be of variable length due to the TCP options filed 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 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