| Document Version 21 |  | |
LINX Protocols | ||
| Prev | 5. Enea LINX Ethernet Connection Manager | Next |
|---|---|---|
Enea LINX PDUs are stacked in front of, possible, user data to form an Enea LINX Ethernet packet. All PDUs contain a field next header which contain the protocol number of following headers or the value -1 (1111b) if this is the last PDU. All headers except Enea LINX main header are optional. 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 next header field, having this field in the same place simplifies implementation and speeds up processing.
If a malformed packet is received the Ethernet Connection Manager resets the connection and informs RLNH.
When the Ethernet Connection Manager encounters problems which prevents delivery of a message or part of a message it must reset the connection. Notification of RLNH is implicit in the Ethernet CM, when the peer replies with RESET or, if the peer has crashed, the Connection Supervision timer fires.
Version 3 of the Enea LINX Ethernet Connection Manager protocol defines these headers.
Table 5.1 Ethernet Connection Manager Protocol Headers
| Protocol number | Value | Definition |
| ETHCM_COREID | Coreid header. Is used only in multicore enviroment. | |
| ETHCM_MAIN | Main header sent first in all Enea LINX packets. | |
| ETHCM_CONN | Connect header. Used to establish and tear down connections. | |
| ETHCM_UDATA | User data header. All messages generated outside the Connection Manager are sent as UDATA. | |
| ETHCM_FRAG | Fragment header. Messages bigger than the MTU are sent fragmented and PDUs following the first carries the ETHCM_FRAG header instead of ETHCM_UDATA. | |
| ETHCM_ACK | Reliability header. Carries seqno and ackno. ACK doubles as empty acknowledge PDU and ACK-request PDU, in sliding window management and connection supervision. | |
| ETHCM_NACK | Request retransmission of one or more packets. | |
| ETHCM_NONE | Indicates that the current header is the last in the PDU. |
The ETHCM_COREID header is used only in a multicore enviroment.It carries the destination and the source coreid. If the connection is established in a singlecore enviroment this header is missing.
Table 5.2 ETHCM Coreid 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 | Res | Dcoreid | Scoreid | Res | |||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
Reserved for future use, must be 0.
Destination coreid, specify the remote coreid.
Source coreid, specify the local coreid.
Reserved for future use, must be 0.
The ETHCM_MAIN header is sent first in all Enea LINX PDU's. It carries protocol version number, connection id, and packet size. Connection ID is negotiated when a connection is establish and is used to lookup the destination for incoming packets.
Table 5.3 ETHCM 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 | Ver | Res | Conn_ID | R | Packet size | ||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
Enea LINX Ethernet Connection Manager protocol version. Version 3 decimal is currently used, 0 is illegal.
Reserved for future use, must be 0.
A key representing the connection, used for fast identification of destination of incoming packets.
Reserved for future use, must be 0.
Total packet size in bytes including this and all other headers.
The Enea LINX Connect Protocol is used to establish a connection on the Connection Manager level between two peers A and B. A Connection Manager will only try to establish a connection or accept connection attempt from a peer if it has been explicitly configured to do. After configuration a CM will maintain connection with the peer until explicitly told to destroy the connection or an un-recoverable error occurs.
If a Connect-message is received, with a version number different from 2, the Ethernet CM refuses to connect.
The Connect Protocol determines Connection IDs to be used for this connection. Connection IDs are small keys used by receivers to quickly lookup a packets destination. Each side selects the Connection ID to be used by the peer when sending packets over the connection. The peer saves the ID and will use it for all future communication. If a node has a lot of connections it may run out of available Connection IDs. In this case the node sends Connection ID 0, which means no Connection ID and reverts to the slower MAC-addressing mode to determine destination for incoming packets.
A window size options may be sent in the CONNECT-header to indicate how the sender configuration deviates from the default. Deviations from default values are configured per connection in the create_conn()-call.
In the following protocol description the side initiating the connection is called A and the side responding to the request is called B. All protocol transitions are supervised by a timer, if the timer fires before the next step in the protocol have been completed the state machine reverts to state disconnected.
The Connect Protocol is symmetrical, there is no master and both sides try to initiate the connection. Collisions, i.e. when the initial CONNECT PDU is sent simultaneously from both sides, are handled by the protocol and the connection restarted after a randomized back of timeout.
Unless a Connection Manager has been configured to create a connection to a peer no messages are sent and the Connection Manager doesn't respond to connection attempts.
When a Connection Object is created at A by calling create_conn() A starts from DISCONNECTED state, sends a CONNECT PDU to B and enters state CONNECTING_1.
If tmo, go back to step 1 and try again after a grace period.
If B replies with a CONNECT_ACK PDU, move to CONNECTED state, send ACK PDU to B, notify RLNH that a connection have been established, and start the Connection Supervision function.
If any other PDU is received from B send RESET and go back to step 1 and try again after a short grace period.
After configuration, B waits in state DISCONNECTED for a CONNECT PDU from A.
If a CONNECT PDU arrives, send a CONNECT_ACK PDU and go to state CONNECTING_2
If some other PDU arrives, send RESET to A and go back to step 2.
In state CONNECTING_2, B waits for an ACK PDU from A.
When CONN_ACK arrives, the connect protocol is complete, the Connection Manager notifies higher layers that a connection have been established, and start the Connection Supervision function.
If some other PDU is received or the timer fires, send RESET and go to state DISCONNECTED
Allowed messages and state changes are summarized in this state diagram. The notation [xxx/yyy] means: event xxx causes action yyy.
A Feature Negotiation string is sent during connection establishment. The string is sent in the CONNECT ACK and the ACK type of ETHCM_CONN messages; the other messages contain an empty string '\0'). The string contains all feature names and corresponding argument. Only the features used by both peers (the intersection) are enabled. All the features supported by none or one peer (the complement) are disabled by both peers. An optional argument can be specified and It is up up to each feature how the argument is used and how the negotiation of the argument is performed.
The Connection header varies in size depending on the size of the address on the media, on Ethernet it is 16 bytes.
Table 5.4 ETHCM Connect 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 | Type | Size | Window | Reserved | Conn_ID | ||||||||||||||||||||||||||
| Dst media address followed by src media address | |||||||||||||||||||||||||||||||
| ... | |||||||||||||||||||||||||||||||
| ... | |||||||||||||||||||||||||||||||
| Feature Negotiation string (variable length, null-terminated string) | |||||||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
| CONNECT. Start a connect transaction. |
| CONNECT ACK. Reply from passive side. |
| ACK. Confirm that the connection have been created. |
| RESET. Sent if any error occurs. Also sent if the next step in connect protocol fails to complete within allowed time. |
Media address size.
Window size. Power of 2, thus Window == 5 means a window of 25 == 32 packets.
Reserved for future use, must be 0.
Use this Connection ID. Informs peer which connection ID to use when sending packets over this connection. Conn ID == 0, means don't use Connection ID.
Dst media address immediately followed by src media address.
String containing feature name and argument pairs. Example: "feature1:arg1,feature2:arg2\0".
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 is used for all remaining fragments.
Accept a new message from RLNH. Calculate how many fragments are required to send this message.
Frag_cnt = 0.
For each fragment in the message:
If first fragment send as USER_DATA else send as FRAG.
If only fragment set fragno to -1 else set fragno to frag_cnt and increment frag_cnt.
If last fragment set MORE to 0 else set MORE to 1.
Forward the packet to lower layer for transmission.
If last fragment go back to step 1
When a USER_DATA or a FRAG packet arrives.
If fragno = -1 (0x7fff) deliver() to RLNH since this is a complete message and wait for next packet.
If fragno ≠ -1 find the reassembly queue for this message and add the packet to the tail of the queue (lower layers doesn't emit packets out-of-order). If the packet is the last fragment deliver the complete message to RLNH else wait for next packet.
Table 5.5 ETHCM 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 | O | Reserved | M | Frag no | |||||||||||||||||||||||||||
| Dst addr | |||||||||||||||||||||||||||||||
| Src addr | |||||||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
Reserved for future use, must be 0.
More fragment follows.
Number of this fragment. Fragments are numbered 0 to (number of fragments - 1). Un-fragmented messages have fragment number -1 (0x7fff).
Opaque address (to CM) identifying the receiver.
Opaque address identifying the sender.
Table 5.6 ETHCM 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 | Reserved | M | Frag no | ||||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
Reserved for future use, must be 0.
More fragment follows.
Number of this fragment. Fragments are numbered 0 to (number of fragments - 1). Un-fragmented messages have fragment number -1 (0x7fff).
The Connection Manager uses a selective repeat sliding window protocol with modulo m sequence numbers. The ack header carries sequence and request numbers for all reliable messages sent over the connection. Sequence and Request numbers are 12 bits wide and m is thus 4096.
In the Selective Retransmit Sliding Window algorithm the B-side explicitly request retransmission of dropped packets and remembers packets received out of order. If the sliding window is full, the A-side queues outgoing packets in a deferred queue. When space becomes available in the window (as sent packets are acknowledged by B) packets are from the front of the deferred queue and sent as usual. A strict ordering is maintained, as long as there are packets waiting in the deferred queue new packets from RLNH are deferred, even if there is space available in the window.
For sliding window operation the sender A have the variables SNmin and SNmax, SNmin points to the first unacknowledged packet in the sliding window and SNmax points at the next packet to be sent. In addition the sliding window size is denoted n and size of sequence numbers are modulo m. The receiver side B maintains a variable RN which denotes the next expected sequence number. In the protocol description, the sequence number and the request number of a packet is called sn and rn respectively. The module number m must be >= 2n. In version 2 of the Enea LINX Ethernet protocol m is 4096 and n is a power of 2 <= 128. Drawing sequence number from a much larger space than the size of the window allows the reliability protocol to detect random packets with bad sequence numbers.
Set modulo variables SNmin and SNmax to 0.
In A if a message is sent from higher layer or there are packets in the defer queue, and (SMmax - SNmin) mod m < n, accept a packet into the sliding window set sn to SNmax and increment SNmax to (SNmax + 1) mod m. If (SNmax - SNmin) mod m >= n defer sending the packet, i.e. queue the packet until there is room in the sliding window.
If an error free frame is received from B containing rn, and (RN - SNmin) mod m <= (RN - SNmax) mod m, set SNmin to RN and remove packets with sn <= SNmin mod m from send queue.
If a NACK frame is received, retransmit NACKed packets in-order with rn set to RN.
At arbitrary times but within bounded delay after receiving a reliable packet from B and if there are unacknowledged packets in the sliding window, send the first un-acked packet with rn, RN and the request bit set.
Set the modulo m variable RN to 0.
When an error free frame is received from A containing sn equal to RN, release the packet as well as following queued packets with consecutive sn to higher layer and increment RN to (last released sn + 1) mod m.
When an error free frame is received from A containing sn in the interval RN < sn < RN + n, put the packet in sequence number order in the receive queue and send NACK requesting retransmission of sequentially dropped packets to A. The seqno field in the NACK frame shall contain RN and the count field shall contain the number of missing packets.
At arbitrary times but within a bounded delay after receiving an error free frame from A transmit a frame containing RN to A. If there are frames in the receive queue send a NACK indicating missing frames.
Note that only user data is sent reliable, i.e. consume sequence numbers. ACKR, NACK and empty ACK are unreliable messages sequence numbers are not incremented as they are sent.
Table 5.7 ETHCM Ack 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 | R | Res | Ackno | Seqno | |||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
ACK-request, peer shall respond with an ACK of its own as soon as possible. (Used during connection supervision.)
Reserved for future use, must be 0.
Shall be set to the next expected or missing seqno from peer.
Incremented for every sent packet. Note that seqnos are set based on sent packets rather than sent bytes as in TCP.
NACK is sent when a hole in the stream of received reliable packets is detected. If a sequence of packets is missing all are NACKed by the same NACK packet. A timer ensures that NACKs are sent as long as there are out-of-order packets in the receive queue.
Table 5.8 ETHCM Nack 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 | Reserved | Count | Res | Seqno | |||||||||||||||||||||||||||
Next header, the protocol number of the following Enea LINX header or 1111b if last header.
Reserved for future use, must be 0.
Number of NACKed seqnos.
Reserved for future use, must be 0.
First NACKed seqno, the rest are assumed to follow consecutively seqno + 1, seqno + 2, ... , seqno + count - 1.
The purpose of the Connection Supervision function is to detect crashes on the B-side. If B has been silent for some time A sends a few rapid pings and, if B doesn't respond, A decides that B has crashed, notifies higher layers, and initiates teardown of the connection. There is no separate PDU for the Connection Supervision function, the ACKR header from the reliability protocol doubles as ping PDU.
When a connection has been established, the Ethernet Connection Manager initializes the Connection Supervision function to state PASSIVE and starts a timer which will fire at regular interval as long as the link is up.
When the timer fires, the Ethernet Connection Manager checks if packets have been received from B since the last time the timer was active.
If yes, clear packets counter, set Connection Supervision state to PASSIVE and go to step 2.
If no, check if connection supervision is already in active state.
If no, enter state Active and send an ACKR to B.
If yes, check if the ping limit has been reached.
If yes, the connection is down, notify higher layers and go to state Disconnected.
If no, resend ACKR and increment the ping counter.
Restart the timer.
If the connection is closed, stop the send timer.
When an ACKR is received, reply to the sender with an empty ACK [RN,SNmax-1].
