HDR
F1
Source address
F2
Target address
F3
| 15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| LAY |
VERS |
SEQNR |
DTYPE |
LAY
The header layer. Layer 0 is used to address 65535 endpoints. Layer 1 can be used (via bridging) to address another 65535 endpoints
per endpoint. With 3 layers... I think we are prepared for a big experiment!
This is a future option, just to demonstrate that we are open for the future.
VERS
Version number. Must be 0
SEQNR
The sequence number, which is a consecutive number per active API. This does not mean, that the number is consecutive for the hubs. Considerering the following scenario: One endpoint is sending an init request, at the same time a second endpoint is sending in addition. In the hub, the first transfer will be transported, the second one blocked. After the channel is released, the second transfer is done. But: These are the same numbers. Consequence: The hubs may check, if the SEQNR of the HDR and the TRM is matching, and if the SEQNR of individual reply transfers is matching.
DTYPE
User defined field (data type), which might be used to define the meaninf of the following DAT fields.
TRM
F1 & F2 (ERROR_PATTERN)
Bit/Error pattern. For init transfers, the user may put here additional information. For reply transfers, one should know that all TRM words from all endpoints will be merged (OR).
F3
| 15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| res. |
VERS |
SEQNR |
DTYPE |
VERS
Version number. Must be 0
SEQNR
see above.
DTYPE
init transfers: See above. Reply transfers: Field will be set to 0 (res.)
EXT
Extended transfers. In principle treated like data. Could be used for transmission tests (PR-Noise, counters, ...) between 2 APIs on the network.
--
IngoFroehlich - 05 Dec 2006