1. CIS 81 Fundamentals of Networking Chapter 7: Transport Layer Part 2 of 2
CCNA Introduction to Networking 5.0
Rick Graziani
Cabrillo College
Fall 2013

2. Chapter 7: Objectives Part 1
Describe the purpose of the transport layer in managing the transportation of data in end-to-end communication.
Describe characteristics of the TCP and UDP protocols, including port numbers and their uses.
Part 2
Explain how TCP session establishment and termination processes facilitate reliable communication.
Explain how TCP protocol data units are transmitted and acknowledged to guarantee delivery.
Explain the UDP client processes to establish communication with a server.
Determine whether high-reliability TCP transmissions, or non-guaranteed UDP transmissions, are best suited for common applications.

3. Session Establishment3

4. Client Sending TCP Requests

5. Request Destination / Source Ports

6. Response Destination / Source Ports

7. Establishing a Session
TCP is reliable because it has connection and session mechanisms.
When a host wants to communicate with another host using TCP, a connection must be established before data can be exchanged.
This is known as the Three-way Handshake
After the communication is completed, the session is closed and the connection is terminated.

8. A TCP Conversation … A B

9. Acknowledgement Number (32) Application Layer Data
Source Port (16)
Destination Port (16)
Sequence Number (32)
Acknowledgement Number (32)
Header Length (4)
Reserved (6)
Control Bits (6)
Window (16)
Checksum (16)
Urgent (16)
Options
Application Layer Data
Control Bits (Flags) (6 bits)
Includes bit codes, or flags, that indicate the purpose and function of the TCP segment.

10. Acknowledgement Number (32) Application Layer Data
TCP Mechanisms
The 6 bit TCP Control field contains 1 bit control information used to manage the TCP processes.
Fields are referred to as flags and are 1 bit long.
It can only contain 1 of 2 values: 0 or a 1.
A bit value = 1: indicates control information is contained.
Source Port (16)
Destination Port (16)
Sequence Number (32)
Acknowledgement Number (32)
Header Length (4)
Reserved (6)
Control Bits (6)
Window (16)
Checksum (16)
Urgent (16)
Options
Application Layer Data

11. TCP Control Bits There are 6 bits that are used by the TCP:
URG - (0x020) Urgent pointer field significant
ACK - (0x010) Acknowledgement field significant
PSH - (0x004) Push function
RST - (0x003) Reset the connection
SYN - (0x002) Synchronize sequence numbers
FIN - (0x001) No more data from sender
Used in
three-way handshake.
NOTE:
Other flags are either reserved for future use or for special functions and are beyond the scope of this course.

12. Connection Establishment Phase
When two hosts communicate using TCP, a connection is established before data can be exchanged.
To establish the connection, hosts use a three-way handshake flagging with the SYN and ACK control bits in the TCP header.
The three-way handshake:
Establishes that the destination device is present on the network.
Verifies that the destination device has an active service and is accepting requests on specified destination port number.
Informs the destination device that the source client intends to establish a communication session on that port number.

13. Connection Establishment Phase
The 1st host sends an Initial Sequence Number (ISN):
The SYN flag set to binary 1.
All other control bits (ACK, FIN, RST, URG, and PSH) are set to binary 0.

14. Connection Establishment Phase
The 2nd host receives the 1st host’s ISN and replies with:
An Acknowledgment (ACK) consisting of the 1st host’s ISN + 1.
This is called an expectational acknowledgement – the next byte this host expects to receive
And it’s own Initial Sequence Number (ISN).
The reply is flagged with SYN and ACK set to binary 1.

15. Connection Establishment Phase
The 1st host receives the ACK and recognizes its ISN+1 and replies with:
An ACK consisting of the 2nd host’s ISN + 1.
The 1st host’s next sequence number (SN).
The ACK flag is set to binary 1

16. TCP Three-Way Handshake
PC1
Server
PC1 requests a client-to-server communication session.
The Server acknowledges the client-to-server communication session and requests a server-to-client communication session.
Send SYN
SN: 100
CTRL= SYN
The initial request contains PC1’s ISN and flags the SYN bit.
100
SYN Received
The response consists of the Server’s ISN and PC1’s ISN + 1 with the SYN and ACK bits flagged.
300
= 101.
Send SYN, ACK
SN: 300
ACK: 101
CTRL= SYN, ACK
SYN, ACK Received
PC1acknowledges the server-to-client communication session.
Send ACK
SN: 101
ACK: 301
CTRL= ACK
ACK Received
The final response consists of PC1’s next SN and the Server’s ISN + 1 with the ACK bit flagged.
101
= 301.
HTTP Request (GET)

21. Terminating a Current Session
To close a connection, the Finish (FIN) control flag must be set in the segment header.
Each host performs a two-way handshake is used using the FIN segment and an ACK control bits.
Therefore, to terminate a single conversation supported by TCP, four exchanges are needed to end both sessions.

22. Connection Termination Phase
The 1st host sends a segment with the FIN bit set.
The 2nd host replies with the ACK bit set.
The 2nd host sends a segment with the FIN bit set.
The 1st host replies with the ACK bit set:

23. Termination Mechanisms

24. Reliable Delivery

25. Segments Can Be Lost Congestion can cause segments to be dropped.
For example, when a receiver is congested it may drop segments.
Congestion can be caused by:
Traffic faster than a network can transfer it.
Multiple computers simultaneously sending segments to a single destination.

26. TCP Provides Reliability
In TCP, clients acknowledge the receipt of segment(s) before the next segment is sent.
The sender also starts a timer when it sends a segment, and it retransmits a segment if the timer expires before an acknowledgment arrives.

28. TCP Provides Reliability
The sequence number (SN) and acknowledgement (ACK) number are used to confirm receipt of data contained in the transmitted segments.
The SN number indicates the relative number of bytes that have been transmitted in this session, including the bytes in the current segment.
TCP uses the ACK number sent back to the source to indicate the next byte that the receiver expects to receive.
This is called expectational acknowledgement.

29. Reliability - Simplified
Send 1
Receive 1
Send ACK 2
Receive ACK 2
Send 2
Receive 2
Send ACK 3
Receive ACK 3
Send 3
Receive 3
Send ACK 4
Receive ACK 4

30. Managing TCP Sessions 10 bytes Next 10 bytes starting with byte 11
Source
Dest. SN
ACK #
1028 23 1
10 bytes
Source
Dest. SN
ACK # 23
1028 1 11
Source
Dest. SN
ACK #
1028 23 11 2
Next 10 bytes starting with byte 11

31. Flow Control

32. TCP Windows
Waiting for an acknowledgment after each segment would be very inefficient.
To maintain efficiency, TCP actually forwards segments in a “window”.
A window specifies the number of segments the sender can forward without receiving an acknowledgment.

33. Flow Control and Reliability
Client Window Size=5,000
Server Window Size=10,000
Flow Control and Reliability
The window size specifies the number of bytes, starting with the acknowledgment number, that the receiving host's TCP layer is currently prepared to receive.
Included in every TCP segment starting with three-way handshake.
TCP is a full duplex service
Client and server specify their own window sizes.
Flow Control and Reliability
The receiving host's TCP layer reports a window size to the sending host's TCP layer.
This window size specifies the number of bytes, starting with the acknowledgment number, that the receiving host's TCP layer is currently prepared to receive.
Window size is included in every TCP segment sent from client or server starting with three-way handshake.
TCP is a full duplex service, client and server specify their own window sizes.

34. Windowing and Flow Control
TCP implements flow control by increasing / decreasing window sizes as required.
Referred to a “sliding windows” (coming).
Window sizes are variable during the lifetime of a connection.
Instead of allowing data to be dropped or lost, a “not ready” indicator can be sent to the sender.
Referred to as Flow control.
Flow control uses windows to prevent a receiver from being overwhelmed by incoming data.

35. My Receive Window: 10,000 My Receive Window: 5,000
Client Window Size=5,000
Server Window Size=10,000
Client’s Send Window: 5,000
Server’s Send Window: 10,000
“I can send 10,000 bytes without hearing an ACK, and I can only receive 5,000 bytes at a time.”
“I can send 5,000 bytes without hearing an ACK, and I can only receive 10,000 bytes at a time.”
Receive Window
Sending host can send only that amount of data before getting an acknowledgment and window update from this (the receiving) host.
Send Window (not a TCP field)
The TCP Receive Window size of the other host.
Client Example
Receive Window Size=5,000 bytes – Server can only send 5,000 bytes before it receives an acknowledgement.
Send Window Size = 10,000 bytes – Server told the client that it can send the server 10,000 bytes before receiving an acknowledgment.
Receive Window
The TCP Receive Window size: Amount of receive data (in bytes) that can be buffered by this host, at one time on a connection.
Sending host can send only that amount of data before getting an acknowledgment and window update from this (the receiving) host.
Send Window (not a TCP field)
The TCP Receive Window size of the other host.
How much data (in bytes) that can be sent by this host before receiving an acknowledgement from the other host.
Client Example
Receive Window Size=5,000 bytes – Server can only send 5,000 bytes before it receives an acknowledgement.
Send Window Size = 10,000 bytes – Server told the client that it can send the server 10,000 bytes before receiving an acknowledgment.

36. MSS of 1,000 bytes
Client has a Window Size of 5,000 bytes
Web Server
Client
Send Window=5,000
Client Window Size=5,000
Server Window Size=10,000
SEQ=1 (to 1,000) …
SEQ=1,001 (to 2,000)
SEQ=2,001 (to 3,000)
SEQ=3,001 (to 4,000)
SEQ=4,001 (to 5,000)
This is known as a Stop-and-Wait windowing protocol.
Server must wait for acknowledgment before continuing to send data.
A better method?
Sliding Windows
Next!
Send Window Byte: This is the last byte that can be sent before receiving an ACK
ACK=5,001
Client Window Size=5,000
Send Window: Byte 10,000
Server Window Size=10,000
SEQ=5,001 (to 6,000) …
SEQ=6,001 (to 7,000)
SEQ=7,001 (to 8,000)
This is known as a Stop-and-Wait windowing protocol.
Server must wait for acknowledgment before continuing to send data.
A better method?
Sliding Windows
Next!
Send Window Byte: This is the last byte that can be sent before receiving an ACK
SEQ=8,001 (to 9,000)
SEQ=9,001 (to 10,000)
Client Window Size=5,000
Send Window: Byte 15,000
ACK=10,001
Server Window Size=10,000
SEQ=10,001 (to 11,000) … ….

37. Windowing Sizes - Example
Send 1
Receive 1
Send 2
Receive 2
Send 3
Receive 3
Send ACK 4 Window size: 3
Receive ACK 4
Send 4
Receive 4
Send 5
Receive 5
Send 6
Receive 6
Send ACK 7 Window size: 3
Receive ACK 7 3
Window = x - Acknowledge after x segments
Window = 1 - Acknowledge each segment sent
Window = 0 - Stop sending

38. Windows and Acknowledgements
SEQ 1 | Bytes
In actual fact, the window specifies the number of “bytes” that the receiving TCP process is currently prepared to receive without acknowledgement.
For example:
Host B is downloading a 10 KB file from Host A.
The Window size is set to 3 KB.
Host B downloads 1 KB segments (maximum segment size).
SEQ | Bytes
SEQ | Bytes
ACK = 3001
SEQ | Bytes
SEQ | Bytes
SEQ | Bytes
ACK = 6001

39. Managing TCP Sessions

40. Sliding Windows (FYI) and SACK (FYI)
For flow control hosts use:
Sliding windows
Selective Acknowledgements (SACK)
See notes in the next two PowerPoint slides for more information.

41. Sliding Windows (FYI)
For simplicity, we will use segments, 1,000 bytes per segment
Server
Client
Window = 10 segments (10,000 bytes)
Request
Window Size=10,000 1 2 3 4 5 6 7 8 9 10 11 12 13
Segment 1
Segment 2 1 2 3 4 5 6 7 8 9 10 11 12 13
ACK=2
Segment 3 1 2 3 4 5 6 7 8 9 10 11 12 13
ACK=3
Segment 4 1 2 3 4 5 6 7 8 9 10 11 12 13
ACK=4
Sliding Windows
The TCP header includes a 16-bit field called the window size. This is the number of bytes the sender of this TCP segment is able to receive. No more data can be sent to this device until an acknowledgement of that data has been received.
Sliding windows allows the sender to transmit multiple segments within the TCP window size without receiving an acknowledgment. A device can send successive segments without waiting for an acknowledgement that a previous segment has been received.
For example, the Client has a window size of 10,000 bytes and includes this information in a TCP segment it sends to the Server. This means the Server can send a maximum of 10,000 bytes of data to the Client without an acknowledgement (confirmation). Each segment contains 1,000 bytes.
As the Client receives each segment it sends the Server an acknowledgment. These are expectational acknowledgements indicating the next byte in the sequence that the Client is ready to receive.
1. The Client includes its window size in every TCP segment sent, including those used in session establishment and any other communications with the Server. This informs the Server of the number of bytes the Client is able to receive from the Server. The Server cannot send any more data to the client until it has received an acknowledgment from the Client.
For simplicity we will use segment numbers instead of bytes. The Client’s window size is 10 segments. This means the Server can send up to 10 segments without receiving an acknowledgement from the Client. (10 segments of 1,000 bytes per segment is equal to the Client’s window size of 10,000 bytes.) As the Client receives each segment it will return an acknowledgement for that segment.
2. At this point we will say the Server has sent the first two segments, Segment 1 and Segment 2. The Server maintains state information that these segments have been sent but not yet acknowledged by the Client.
3. The Client receives Segment 1 but has not yet received Segment 2. The Client sends an Acknowledgement 2 segment to the Server indicating that it has received Segment 1 and is still expecting Segment 2. (In our example we are using segment numbers instead of the bytes.)
4. The Server receives the Acknowledgment 2 segment from the Client and slides its window over one TCP segment to the right. The window size continues to be 10 segments or 10,000 bytes. Since the first segment has been acknowledged, the Server can now send up to Segment 11 without receiving an acknowledgement. The Server continues sending the next segment in the data stream, Segment 3. Notice the window is now past segment 1 indicating that Segment 1 has been acknowledged.
5. The Client receives Segment 2 and returns another expectational acknowledgement to the Server, Acknowledgement 3.
6. The Sever receives the Acknowledgment 3 segment from the Client and once again slides its window over one more TCP segment to the right. The Server can now send up to Segment 12 without receiving an acknowledgement. The Server also continues sending the next segment in the data stream, Segment 4. The Server’s sliding window now indicates that Segment 2 has been acknowledged.
7. The Client receives Segment 3 and returns another expectational acknowledgement to the Server, Acknowledgement 4.
8. The Sever receives the Acknowledgment 4 segment from the Client and slides its window over one more TCP segment to the right. The Server can now send up to Segment 13 without receiving an acknowledgement. The Server also continues sending the next segment in the data stream, Segment 5. The Server’s sliding window now indicates that Segment 3 has been acknowledged.
This process continues until all data has been sent and acknowledged.
This section only discusses the most basic operations of sliding windows and leaves out various possibilities and scenarios. The actual details of the sliding windows mechanism are beyond the scope of this course.
Segment 5 1 2 3 4 5 6 7 8 9 10 11 12 13
Sliding windows allows the sender to transmit multiple segments within the TCP window size without receiving an acknowledgment.
A device can send successive segments without waiting for an acknowledgement that a previous segment has been received.
See notes in PowerPoint for more information.

42. SACK (FYI) Normal windowing (without SACK)1
Client
Segment 1
Server
Segment 2 X
Segment 3 2
ACK=2
Segment 4
Normal windowing (without SACK)
The process of retransmitting segments that did not arrive at their destination can lead to certain inefficiencies.
See notes in PowerPoint for more information
Segment 5 3
ACK=2 (Duplicate)
ACK=2 (Duplicate)
ACK=2 (Duplicate) 4
Segment 2
Segment 3
Selective Acknowledgements (SACK)
Reliability is one of the key features of TCP. TCP uses a combination of sequence numbers and acknowledgements to ensure all the data has been received. However the process of retransmitting segments that did not arrive at their destination can lead to certain inefficiencies. This is illustrated in Figure 1 with a Client receiving data from a Server. For simplicity we will use segment numbers instead of bytes.
TCP Reliability using Acknowledgments
Step 1. As part of a larger data stream, the Server sends the first 5 TCP segments to the Client. However, Segment 2 is lost and never arrives at the Client.
Step 2. The Client receives Segment 1 but has not yet received Segment 2. The Client sends an Acknowledgement 2 segment to the Server indicating that it has received Segment 1 and is still expecting Segment 2.
Step 3. The next segments received by the Client are Segment 3, Segment 4 and Segment 5. Because the Client is still expecting Segment 2, it sends duplicate Acknowledgement 2 segments back to the Server, one for each successive segment it received.
Step 4. The Server receives the multiple Acknowledgement 2 segments from the Client. The Server must resend Segment 2. This is where the inefficiency happens. The Server has no indication whether Segment 3 through 5 arrived at the Client. The Server must not only resend the lost segment, Segment 2, but Segment 3 through 5 as well.
Step 5. The Client receives the missing segment, Segment 2 along with duplicate segments, Segment 3 through 5. The Client sends an acknowledgement for each of the segments.
Step 6. The Server receives the acknowledgments from the Client and sends the next segment in its transmission queue, Segment 6.
TCP Reliability using the Selective Acknowledgment option
Figure 2 illustrates the use of TCP selective acknowledgments (SACK). SACK is a strategy that corrects the inefficiency we saw with TCP acknowledgments when there is one or more lost segments. SACK is an optional implementation of TCP introduced with RFC Support of SACK is negotiated during the establishment of the TCP connection. If both hosts support SACK, then it will be used during the connection.
Step 1. Both Client and Server indicate the support of SACK during the establishment of the TCP connection. This occurs as part of the normal three-way handshake process.
Step 2. As part of a larger data stream, the Server sends the first 5 TCP segments to the Client. Segment 2 is lost and never arrives at the Client.
Step 3. The Client receives Segment 1 but has not yet received Segment 2. The Client sends an Acknowledgement 2 segment to the Server indicating that it has received Segment 1 and is still expecting Segment 2.
Step 4. The next segments received by the Client are Segment 3, Segment 4 and Segment 5. This is where SACK comes into affect. The Client sends duplicate acknowledgements for the first segment but this time includes the SACK option to show which segments it has received. The client sends three duplicate acknowledgments, one for each successive segment received, but also letting the Server know it is still expecting Segment 2. Each duplicate acknowledgment includes the SACK option indicating the range of segments the Client has received.
Step 5. The Server receives the acknowledgement that the Client has received the Segment 1 and is awaiting the Segment 2.
Step 6. The Server receives a duplicate acknowledgment of Segment 1, which includes with the first acknowledgment with the SACK option. This acknowledgement with the SACK option indicates that the Client has received Segment 3 (SACK=3) but still hasn’t received Segment 2 (ACK=2).
Step 7. The server resends Segment 2. The Client receives the other duplicate acknowledgements of Segment 1 with SACK options indicating that the Client has also received Segment 4 and Segment 5. Notice that the Server does not need to resend Segments 3 through 5.
Step 8. The Client receives Segment 2 and now has Segment 1 through Segment 5. The Client sends Acknowledgment 6 to inform the Server that this is the next segment it is expecting.
Step 9. The Server sends Segment 6 and any other segments in the transmission queue. Depending on the window size of the Client, the Server could have sent Segment 6 and additional segments prior to receiving the acknowledgement.
This section only discusses the most basic operations of SACK and does not include various possibilities and scenarios. The actual details of SACK are more involved but are beyond the scope of this course. 5
ACK=3
Segment 4
ACK=4
Segment 5
ACK=5
ACK=6
Segment 6 6

43. SACK (FYI)
Client
SACK
Server 1
SACK
Segment 1 2
Segment 2
With SACK
SACK is an optional implementation of TCP introduced with RFC 2018.
Support of SACK is negotiated during the establishment of the TCP connection.
If both hosts support SACK, then it will be used during the connection. X
Segment 3 3
ACK=2
Segment 4
Segment 5 4
ACK=2, SACK= 3
ACK=2, SACK= 3-4 5
ACK=2, SACK= 3-5 6
Segment 2 7
Selective Acknowledgements (SACK)
Reliability is one of the key features of TCP. TCP uses a combination of sequence numbers and acknowledgements to ensure all the data has been received. However the process of retransmitting segments that did not arrive at their destination can lead to certain inefficiencies. This is illustrated in Figure 1 with a Client receiving data from a Server. For simplicity we will use segment numbers instead of bytes.
TCP Reliability using Acknowledgments
Step 1. As part of a larger data stream, the Server sends the first 5 TCP segments to the Client. However, Segment 2 is lost and never arrives at the Client.
Step 2. The Client receives Segment 1 but has not yet received Segment 2. The Client sends an Acknowledgement 2 segment to the Server indicating that it has received Segment 1 and is still expecting Segment 2.
Step 3. The next segments received by the Client are Segment 3, Segment 4 and Segment 5. Because the Client is still expecting Segment 2, it sends duplicate Acknowledgement 2 segments back to the Server, one for each successive segment it received.
Step 4. The Server receives the multiple Acknowledgement 2 segments from the Client. The Server must resend Segment 2. This is where the inefficiency happens. The Server has no indication whether Segment 3 through 5 arrived at the Client. The Server must not only resend the lost segment, Segment 2, but Segment 3 through 5 as well.
Step 5. The Client receives the missing segment, Segment 2 along with duplicate segments, Segment 3 through 5. The Client sends an acknowledgement for each of the segments.
Step 6. The Server receives the acknowledgments from the Client and sends the next segment in its transmission queue, Segment 6.
TCP Reliability using the Selective Acknowledgment option
Figure 2 illustrates the use of TCP selective acknowledgments (SACK). SACK is a strategy that corrects the inefficiency we saw with TCP acknowledgments when there is one or more lost segments. SACK is an optional implementation of TCP introduced with RFC Support of SACK is negotiated during the establishment of the TCP connection. If both hosts support SACK, then it will be used during the connection.
Step 1. Both Client and Server indicate the support of SACK during the establishment of the TCP connection. This occurs as part of the normal three-way handshake process.
Step 2. As part of a larger data stream, the Server sends the first 5 TCP segments to the Client. Segment 2 is lost and never arrives at the Client.
Step 3. The Client receives Segment 1 but has not yet received Segment 2. The Client sends an Acknowledgement 2 segment to the Server indicating that it has received Segment 1 and is still expecting Segment 2.
Step 4. The next segments received by the Client are Segment 3, Segment 4 and Segment 5. This is where SACK comes into affect. The Client sends duplicate acknowledgements for the first segment but this time includes the SACK option to show which segments it has received. The client sends three duplicate acknowledgments, one for each successive segment received, but also letting the Server know it is still expecting Segment 2. Each duplicate acknowledgment includes the SACK option indicating the range of segments the Client has received.
Step 5. The Server receives the acknowledgement that the Client has received the Segment 1 and is awaiting the Segment 2.
Step 6. The Server receives a duplicate acknowledgment of Segment 1, which includes with the first acknowledgment with the SACK option. This acknowledgement with the SACK option indicates that the Client has received Segment 3 (SACK=3) but still hasn’t received Segment 2 (ACK=2).
Step 7. The server resends Segment 2. The Client receives the other duplicate acknowledgements of Segment 1 with SACK options indicating that the Client has also received Segment 4 and Segment 5. Notice that the Server does not need to resend Segments 3 through 5.
Step 8. The Client receives Segment 2 and now has Segment 1 through Segment 5. The Client sends Acknowledgment 6 to inform the Server that this is the next segment it is expecting.
Step 9. The Server sends Segment 6 and any other segments in the transmission queue. Depending on the window size of the Client, the Server could have sent Segment 6 and additional segments prior to receiving the acknowledgement.
This section only discusses the most basic operations of SACK and does not include various possibilities and scenarios. The actual details of SACK are more involved but are beyond the scope of this course. 8
ACK=6
Segment 6 8

44. UDP

45. User Datagram Protocol (UDP)
Connectionless-oriented protocol, described in RFC 768.
Advantage of providing for low overhead data delivery.
Each UDP segment adds a 8 byte header to the Application layer data.
It is a stateless protocol, meaning neither the client, nor the server, is obligated to keep track of the state of the communication session.
The UDP PDU is called a datagram, but generically the transport layer is referred to as a segment.
UDP datagrams are sent as "best effort".
Applications that use UDP include:
Domain Name System (DNS)
Video Streaming
Voice over IP (VoIP)

46. UDP Protocol UDP is simpler and requires less overhead than TCP.
It is not connection-oriented and does not provide the sophisticated retransmission, sequencing, and flow control mechanisms.

47. UDP Services
Unlike TCP, UDP does not provide segmentation or reassembly, or:
UDP does not establish a connection between the hosts before data can be sent and received.
UDP does not establish a connection between the hosts before data can be sent and received. .
Occasionally data is received in a different order than it was sent.
UDP does not provide any mechanism for reassembling the data in its original sequence.
The data is simply delivered to the application in the order that it arrives.
There are no flow control mechanisms within UDP
If resources on the destination host become overtaxed, the destination host mostly likely drops data sent until resources become available.
Unlike TCP, with UDP there is no mechanism for automatic retransmission of dropped data.

48. No Ordered Data Reconstruction
Segments arriving out-of-order are not reorganized because there are no sequence numbers.
Having taken different routes to the destination, the datagrams arrive out of order.

49. UDP Header

50. Application Layer Data
Source Port (16)
Destination Port (16)
Length (16)
Checksum (16)
Application Layer Data
Sample UDP Datagram

51. Application Layer Data
Source Port (16)
Destination Port (16)
Length (16)
Checksum (16)
Application Layer Data
Sample UDP Datagram
Source Port (16 bits)
Number of the calling port.
Dynamically assigned to the sending host.
Number ranges from 1024 to 65,535.
The source port makes it possible to have multiple sessions of FTP running simultaneously.

52. Application Layer Data
Source Port (16)
Destination Port (16)
Length (16)
Checksum (16)
Application Layer Data
Sample UDP Datagram
Destination Port (16 bits)
Number of the called port.
Usually a number between 1 and 1023.
End systems use the same port numbers to select the proper application.
E.g., when requesting DNS information the destination port is 53.

53. Clients Sending UDP Requests

54. Request Destination / Source Ports

55. Response Destination / Source Ports

56. The early years: 1981 – 1992
“The assignment of numbers is also handled by Jon Postel. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, or network number please contact Jon to receive a number assignment.” (RFC 790)
1981:

57. Jon Postel - Postmaster of the Net
Jon Postel made many significant contributions to the development of the Internet, particularly in the area of standards.
He is principally known for being the editor of the Request for Comment (RFC) document series, and for serving as the Internet Assigned Numbers Authority (IANA) until his death.
(1943 – 1998)

58. Different Destination Port
8080
8080
.20
When specifying an IP address, you can also specify a port number.
xxx.xxx.xxx.xxx:port#
This combination is called a socket.
The terms port number and socket used interchangeably.
For example, an HTTP web page request being sent to a web server (port 80) running on a host with a Layer 3 IPv4 address of would be destined to socket :80
You can set up a server to operate on different ports and therefore, hide the service from the outside world.
Called port forwarding
You set up port forwarding to work on port 8080.
Therefore your friends could connect to your web server by using: :8080

60. Different Destination Port
6001
6001
0.10
You can set up a server to operate on different ports and therefore, hide the service from the outside world.
Called port forwarding
For example, you want to access a web cam inside your home network, but everyone but your home uses private IP addresses.
So you set up port forwarding to work on a specific port.
Therefore you could connect to your web cam by using
:6001
Port forwarding is covered in more detail in CCNA 4.

61. CIS 81 Fundamentals of Networking Chapter 7: Transport Layer Part 2 of 2
CCNA Introduction to Networking 5.0
Rick Graziani
Cabrillo College
Fall 2013