Connection Oriented Versus Connectionless Protocols

The terms connection-oriented and connectionless have some relatively well-known connotations inside the world of networking protocols. However, the typical connotation can be a bit misleading. For instance, most people correlate connection-oriented protocols with reliable or error-recovering protocols because the two features are often implemented by a single protocol. However, connection-oriented protocols do not have to provide error recovery, and error-recovering protocols do not have to be connection-oriented.

First, some basic definitions are in order:

Connection-oriented protocol: A protocol that either requires an exchange of messages before data transfer begins or has a required pre-established correlation between two endpoints.

Connectionless protocol: A protocol that does not require an exchange of messages and that does not require a pre-established correlation between two endpoints.

The definitions are sufficiently general so that all cases can be covered. TCP is connection-oriented because a set of three messages must be completed before data is exchanged. Likewise, SPX is connection-oriented. Frame Relay, when using PVCs, does not require any messages be sent ahead of time, but it does require predefinition in the Frame Relay switches, establishing a connection between two Frame Relay attached devices. ATM PVCs are also connection-oriented, for similar reasons.

As mentioned earlier, connection-oriented protocols are often assumed to also perform error recovery. However, Frame Relay and ATM are two examples in which the protocols are connection-oriented but the protocol does not provide error recovery. Table 3-4 provides some example protocols and tells whether they are connection-oriented and error-recovering.

Table 3-4 Protocol Characteristics: Recovery and Connections

Connected?	Reliable?	Examples
Connection-oriented	Yes	LLC type 2 (802.2), TCP (TCP/IP), SPX (NetWare), X.25
Connection-oriented	No	Frame Relay virtual circuits, ATM virtual connections, PPP
Connectionless	Yes	TFTP, NetWare NCP (without Packet Burst)
Connectionless	No	UDP, IP, IPX, AppleTalk DDP, most Layer 3 protocols, 802.3, 802.5

The most typical option is for a protocol to be connectionless and not perform error recovery, or to be connection-oriented and to also perform error recovery. In fact, many connection-oriented protocols exchange information important to error recovery when the connection is established.

Cisco expects CCNAs to be able to distinguish between error detection and error recovery. Any header or trailer with a frame check sequence (FCS) or similar field can be used to detect bit errors in the PDU. Error detection uses the FCS to detect the error, which results in discarding the PDU. However, error recovery implies that the protocol reacts to the lost data and somehow causes the data to be retransmitted. An example of error recovery is shown later in this section.

NOTE Some documentation refers to the terms connected or connection-oriented. These terms are used synonymously. You will most likely see the use of the term connection-oriented in Cisco documentation.

In the context of previous Cisco official courses, reliable, error-recovering protocols were always defined as also being connection-oriented. In the current ICND course, part of the official Cisco CCNA training path, those references have been removed. If you are studying using an older ICRC or CRLS course book, pay particular attention to the comparisons made about connection orientation and error recovery in this book.

The following litany describes the attitude of the current Cisco course books on error recovery:

• The protocol implementing the connection defines headers and uses part of these headers to number and acknowledge the data. For example, TCP provides error recovery and defines a TCP header. The headers used by that protocol have some numbering and acknowledgment fields to both acknowledge data and notice when it has been lost in transmission. The endpoints that are sending and receiving data use the fields in this header to identify that data was sent and to signify that data was received.

• A sender of data will want an acknowledgment of the data. When an error occurs, many error-recovery algorithms require the sender to send all data, starting with the lost data. To limit the negative effect of having to resend lots of data, a window of unacknowledged data, which can be dynamic in size, is defined. This window defines the maximum amount of data that can be sent without getting an acknowledgment.

Continue reading here: Flow Control

Was this article helpful?

+1 0