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.
The following headers types are used in Connection Establishment and Disconnection:
Table 11.1 CMCL Connection Header Types
Header type | Value | Definition |
CMCL_CONN_REQ | 0x1 | Connect request. Used to request connection establishment. |
CMCL_CONN_ACK | 0x2 | Connect acknowledgement. Used to acknowledge the connection request. |
CMCL_CONN_RST | 0x3 | Reset. 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.
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.
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 type | Value | Definition |
CMCL_CONN_ALV | 0x4 | Sent 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.