Protocols: An Introduction

Acknowledgement: This series of posts is based on the work of John Day in his book “Patterns in Network Architecture”, and others, as mentioned in the References section. I added some clarifications, examples, and diagrams, wherever appropriate.

Introduction

Protocols play a crucial role in ensuring seamless and efficient data exchange between two entities in a communication system. For two parties to communicate, they must have a common language, some common understanding about what symbols in the language stand for, and what rules are used for communication. Consequently, a communication protocol is a set of rules and conventions that allows two or more entities within a communication system to exchange information. The protocol defines the shared schema that includes the rules, syntax, semantics, and synchronization of communication. A communication protocol ensures that the entities involved in the communication process understand each other and can effectively transmit and receive data.

The figure below illustrates the role protocols play in the communication system framework.

Communication networks are complex systems. The concept of layers in communication serves as an abstraction mechanism that manages the communication system complexity by hiding the specifics of underlying technology, much like how operating systems abstract hardware details from software applications. Network layers create abstract services independent of the physical media, enabling consistent communication interfaces across different technologies. Each network layer functions as a black box, providing specific services without revealing the underlying mechanisms. For instance, the ‘Network’ layer abstracts transmission media details, allowing higher layers to transmit data without managing physical connections.

The concept of service is another key abstraction that simplifies interactions by hiding the underlying mechanisms. Positioned above the protocol/interface, service abstraction allows for protocol flexibility and changes without altering the provided service. A service is defined independently of protocols, and it includes a set of service operations, parameters, and rules. This abstraction ensures consistent interactions between service users and providers (protocols), enhancing system flexibility and reducing complexity. By abstracting the interface between layers, different protocols can provide the same service, decoupling the protocol’s internal workings from the user while maintaining consistency across implementations.

Interfaces are the interaction points between system components, closely related to protocols. While protocols define communication rules, interfaces expose these rules to other components through function calls or message formats. The also address system-specific issues like buffer management.

A protocol should be viewed as a requirements document, not a design specification. The implementation of a protocol translates the protocol rules into practice. A well-designed protocol allows for various implementations that conform to the same rules, ensuring consistent external behavior regardless of differing internal workings.

Example

Readers may be familiar with the services that each layer provides, so we will list only two examples here. Among the Transport layer services are congestion control and in-order delivery of packets. The Network layer handles routing packets through the network as well as packets fragmentation and reassembly. Some services, such as error control, may be provided by more than one layer.

Protocols as Finite State Machines

Finite State Machines (FSMs) are often used to describe and analyze communication protocols. FSMs are models that describe the different states a system can be in and how it transitions from one state to another based on inputs. For complex protocols, pure FSM representation is impractical because the number of states would need be significantly large. To make FSMs more practical for protocols, they are combined with programming or formal language techniques. A modified FSM includes:

• Major states of the FSM.
• Set of all possible inputs and outputs.
• Set of procedures or algorithms that operate on inputs and modify the state.
• A state vector that includes a collection of variables (e.g., sequence numbers, counters) that must be preserved between inputs.

The modified FSM receives an input and the current major state. A procedure is invoked based on the input and state. The procedure executes an algorithm that modifies the state vector and produces an output. The state vector maintains necessary information between executions, and the major states indicate the progress within the algorithm (e.g., “beginning,” “waiting,” “end”). This modified FSM approach reflects how most protocol implementations are done, making it both powerful and practical for real-world applications.

The FSM that implements a protocol will be referred to as a Protocol Machine (PM) (see the figure below). A PM is the operational implementation of a protocol, responsible for executing the protocol’s rules and managing the communication process according to the protocol’s specifications. i.e. a protocol is the blueprint or the “what” of communication, while a PM is the “how,” the engine that makes the protocol operational within a system.

Example

TCP (Transmission Control Protocol) uses a finite state machine to manage the states of a connection, including states like LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT. The figure below shows a simplified FSM for TCP. The green represents the initiator states and the orange represent the responder states.

References

1. J. Day, Patterns in network architecture: A return to fundamentals. 2008.