11.1 Protocol Description

The purpose of the CMCL is to provide peer supervision, the CMCL does not handle fragmentation and is not a reliability layer. Fragmentation and loss-less in-order delivery of messages is left to the underlying driver or connection manager.

Control signaling between the two instances of the CMCL (one instance on each peer of the connection) is recognized by using the src and dst parameters in the LINX protocol. src is always set to zero, and the dst parameter is used to identify the control signal.

The CMCL for linux sends a small payload when sending control messages, even though all information that is needed is submitted in the underlying medias protocol. This payload can be disregarded.

11.1.1 LINX CMCL Connection Establishment Algorithm

The following headers types are used in Connection Establishment and Disconnection:

Table 11.1 CMCL Connection Header Types

Header typeValueDefinition
CMCL_CONN_REQ0x1Connect request. Used to request connection establishment.
CMCL_CONN_ACK0x2Connect acknowledgement. Used to acknowledge the connection request.
CMCL_CONN_RST0x3Reset. Used to cancel the connection.

The CMCL will start in state Disconnected and will remain in that state until the RLNH layer calls downcall connect and CMCL will enter Connection_1 state where it in turn requests a connection from the underlying layer by calling downcall connect.

The CMCL will remain in state Connecting_1 until it receives an upcall connected from the underlying layer and then it will enter the Connecting_2 state where the CMCL tries to establish a connection to its peer by sending a CONN_REQ message.

The CMCL will remain in state Connection_2 until it receives a CONN_REQ or CONN_ACK from its peer and will then enter state Connected and call the connected upcall to the RLNH.

In state Connected, the CMCL will supervise the peer by sending keep-alive messages. If no response is received after three consecutive keep-alive messages the CMCL will enter state Disconnecting, send a CONN_RST to its peer and call the disconnect downcall to the underlying layer.

When the underlying layer calls upcall disconnected the CMCL will enter Disconnected state and in turn calls upcall disconnected to the RLNH.

In state Connected, if the RLNH calls downcall disconnect, the CMCL will enter state Disconnecting, send a CONN_RST message to its peer and call downcall disconnect to the underlying layer.

11.1.2 Enea LINX CMCL User Data

The transmit downcall from the RLNH layer is passed straight down to the underlying layer, no header is added.

The deliver upcall from the underlying layer is passed to the RLNH layer in the same context. While connecting the deliver upcall can sometimes be made while the CMCL is still in Connecting_2 state, in this case the message is queued and delivered after the CMCL enters the Connected state and the next deliver upcall is made or keep-alive message is received.

11.1.3 Enea LINX CMCL Connection Supervision Protocol

Supervision of the connection is needed in order to detect if a peer has been reset.

Table 11.2 CMCL Connection Supervision Header Type

Header typeValueDefinition
CMCL_CONN_ALV0x4Sent periodically to indicate that the sender is alive


The connection alive packet is sent three times per the connection timeout period. The default timeout period is 300ms.