The transport layer in TCP/IP always operates with the IP. Recall that this protocol provides a best try (connectionless) service for the transfer of individually addressed message units known as datagram’s.
This mode of operation minimizes the overheads associated with each message transfer since no network connection is established prior to a message (datagram) being sent. Also the IP does not perform any error control. To enable application protocol to exploit this property, TCP/IP provides a connectionless transport protocol known as the User Datagram Protocol (UDP). UDP provides a connectionless service application-level procedure.
User Datagram Protocol is basically an unreliable service; delivery and duplicate protection are not guaranteed. However, this does reduce the overhead of the protocol and may be adequate in many cases.
The strengths of the connection-oriented approach are clear. It allows connection related features such as flow control, error control and sequenced delivery. Connectionless service however is more appropriate in some contexts. At lower layers (internet, network) connectionless service is more robust. In addition, the connectionless service represents a "least common denominator" of service to be expected at higher layers. Further, even at transport layer and above there is justification for a connectionless service. There are instances in which the overhead of connection establishment and maintenance is unjustified or is even counter-productive. Examples include the following:
• Inward data collection: Involves the periodic active or passive sampling of data sources, such as sensors, and automatic self-test reports from security equipment or network components. In a real time monitoring situation, the loss of an occasional data unit would not cause distress, because the next report should arrive shortly.
• Outward data dissemination: Includes broadcast messages to network users, the announcement of a new node or the change of address of a service, and the distribution of real time clock values.
• Request response: Applications in which a transaction service is provided by a common server to a number of distributed transport service users, and for which a single request-response sequence is typical. Use of the service is regulated at the application level, and lower-level connections are often unnecessary and cumbersome.
• Real-time applications: Such as voice and telemetry, involving a degree of redundancy and/or a real time transmission equipment. These must not have connection-oriented functions such as retransmission.
Thus, there is a place at the transport level for both a connection-oriented and a connectionless type of service.
UDP sites are on top of IP, because it is connectionless. IDP has very little to do. Essentially, it adds a port addressing capacity to IP. This is best seen by examining the UDP header, shown in Figure 11.3(b). The header includes a source port and a destination port. The length field contains the length of the entire UDP segment, including header and data. The checksum has the same algorithm used for TCP and IP. For UDP, the checksum: applies to the entire UDP segment plus a pseudo header prefixed to the UDP header at the time of calculation and is the same pseudo header used for TCP. If an error is detected, the segment is discarded and no further action is taken.
The checksum field in UDP is optional. If it is not used, it is set to zero. However, it should be pointed out that the IP checksum applies only to the IP header and not to the data field, which consists of the UDP header and the user data. Thus, if no checksum calculation is performed by UDP, then no check is made on the user data
BACK |