| Document Version 21 |  | |
LINX Protocols | ||
| Prev | 6. Enea LINX Point-To-Point (PTP) Connection Manager | Next |
|---|---|---|
Enea LINX PDUs are stacked in front of, possible, user data to form an Enea LINX packet. All PDUs contain a "next header" field which indicates the type of the next PDU to be sent. Everything from the transmit() down call, including possible control plane signaling, from the RLNH layer is sent reliably as user data. The first field in all headers is the current type, followed by "next" field.
If a malformed packet is received the PTP Connection Manager resets the connection and informs RLNH.
When the PTP Connection Manager encounters problems which prevents delivery of a message or part of a message it must reset the connection. If the peer replies with RESET, or if the peer has crashed and the Connection Supervision timer fires, the PTP CM will notify the RLNH.
The Enea LINX Point-To-Point Connection Manager protocol defines these headers.
Table 6.1 PTP Connection Manager Protocol Headers
| Protocol number | Value | Definition |
| PTP_CM_MAIN | 0x01 | Main header sent first. |
| PTP_CM_CONN_RESET | 0x02 | Reset header. Used to notify the remote side that the connection will be torn down and reinitialized. |
| PTP_CM_CONN_CONNECT | 0x03 | Connect header. Used to establish connections. |
| PTP_CM_CONN_CONNECT_ACK | 0x04 | Notify remote side that connection was established. |
| PTP_CM_UDATA | 0x05 | All messages generated outside the Connection Manager are send as UDATA. |
| PTP_CM_FRAG | 0x06 | Fragment header. Messages larger than MTU are fragmented into several packages. The first fragmented package has a PTP_CM_UDATA header followed by PTP_CM_FRAG header, the following packages has only PDU PTP_CM_FRAG. |
| PTP_CM_HEARTBEAT | 0x07 | Header for heart beat control messages. These messages are used to discover a connection failure. |
| PTP_CM_HEARTBEAT_ACK | 0x08 | Acknowledgement header for heartbeat messages. Sent as a reply to PTP_CM_HEARTBEAT messages. |
| PTP_CM_NONE | 0xFF | Indicates that the current header is the last in the PDU. |
All messages originating outside the Connection Manger begin with MAIN header. This header specify the type of the next header to come.
Table 6.2 PTP_CM Main header
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| Next Header Type | |||||||||||||||||||||||||||||||
Specify what type of PDU will be next.
All messages originating outside the Connection Manger are sent as USER_DATA. There are two types of USER_DATA header. The first type is used for messages not requiring fragmentation and for the first fragment of fragmented messages. The second type - PTP_CM_FRAG is used for all remaining fragments.
Table 6.3 PTP_CM User Data Header
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| Next Header Type | Total Size | ||||||||||||||||||||||||||||||
| Total Size | Upper layer data 1 | ||||||||||||||||||||||||||||||
| Upper layer data 1 | Upper layer data 2 | ||||||||||||||||||||||||||||||
| Upper layer data 2 | |||||||||||||||||||||||||||||||
Specify what header type will follow in the current PDU.
Size of user data to be sent. If the size exceeds MTU, there message will be fragmented.
Source address. CM does not modify this field.
Destination address. CM does not modify this field.
At destination, fragments will be expected to arrive in order, but may be interrupted by other packets, and the message will be re-composed based on total size information.
Table 6.4 PTP_CM Fragment Header
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| Next Header Type | Size | ||||||||||||||||||||||||||||||
| Size | ID | ||||||||||||||||||||||||||||||
Specify what header type will follow in the current PDU.
The size of the fragment.
Fragment ID.
Table 6.5 PTP_CM Control Header
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| Next Header Type | CM Version | ||||||||||||||||||||||||||||||
Type for next packet in PDU. Currently it is PTP_CM_NONE only.
Connection Manager version
Unless a Connection Manager has been configured to create a connection to a peer, no messages are sent and the Connection Manager does not respond to connection attempts. Below is described one case when a connection is created and B side initiates the connection later then A side.
When a Connection Object is created, A moves from DISCONNECTED state to CONNECTING, then sends a PTP_CM_CONN_CONNECT to B.
If B replies with a PTP_CM_CONN_RESET PDU, A remains in CONNECTING state.
If B sends a PTP_CM_CONN_CONNECT PDU, A moves to CONNECTED state, sends PTP_CM_CONN_CONNECT_ACK PDU to B and notifies RLNH that a connection have been established.
If PTP_CM_CONN_RESET or PTP_CM_CONN_CONNECT PDUs are received, while in CONNECTED state, A side returns to disconnected state.
In DISCONNECTED state, B does not evolve from this state unless a local attempt to create a connection is made.
When a Connection Object is created, B moves from DISCONNECTED state to CONNECTING and sends a PTP_CM_CONN_CONNECT to A.
When PTP_CM_CONN_CONNECT arrives, A is waiting already in CONNECTING state so it enters CONNECTED state and responds to B with PTP_CM_CONN_CONNECT_ACK.
When receiving PTP_CM_CONN_CONNECT_ACK, B side enters in CONNECTED state too.
If PTP_CM_CONN_RESET or PTP_CM_CONN_CONNECT PDUs are received while in CONNECTED state, B side returns to disconnected state
If either sides receive PTP_CM_CONN_CONNECT message while in CONNECTED state, it moves to DISCONNECTED and sends a PTP_CM_CONN_RESET message.
The purpose of Supervision function is to detect crashed on peer side. In order to do that, PTP_CM_HEARTBEAT PDU is sent periodically to the other side. When a PTP_CM_HEARTBEAT_ACK is received, an internal counter is re-set. If no acknowledgement is received within a certain time interval, the heartbeat counter is decremented. After a number of ACK missed, the connection is considered crashed and will be disconnected. The timeout and the number of acknowledgments are configurable.
The supervision activity is independent of user data flow over the connection. Each side is responsible to detect peer's activity, and each side will request acknowledgment to own heartbeat messages.
