Add support for OSDP auto addressing scheme

[sidcha]

@schmida2, has put some effort into adding an extension for OSDP auto addressing (see proposal). This issue will track the discussion made in this topic and how it can be integrated into this project without breaking other compatibility to PDs that don't support this extension.

[sidcha]

@schmida2 I like this overall idea of auto addressing scheme described above. I'd like to suggest some changes as below:

First CP sends osdp_MFG(AUTO_ADDR) to the broadcast address 0x7F (all PDs will receive and process this according to the specification), each PD that understands this scheme has to respond with osdp_MFGREP(PD_UUID). The CP collects all PD UUIDs and then assigns a PD address for each of them. Then send another command again to the broadcast address with osdp_MFG(PD_ID_ALLOC, UUID_1 <=> PD_ID_1, UUID_1 <=> PD_ID_1, UUID_2 <=> PD_ID_2, ...). Each PD that understands this scheme will look for it's UUID in the list of UUID returned by the CP to extract it's new address and from then on, it identifies itself with that address. With the newly assigned address, PD responds to osdp_MFG(PD_ID_ALLOC) with a osdp_MFG(PD_ADDR_CONFIRM, UUID). This way, the CP knows that the right PD got the message and took ownership of the address that it intended to assign it.

In essence, a network with 4 PDs, the command exchange would look like this:

Transaction 1: CP: osdp_MFG(ADDR=0x7F, CMD=AUTO_ADDR) PD1: osdp_MFGREP(ADDR=0xFF, REPLY=AUTO_ADDR, UUID=PD_UUID_1) PD2: osdp_MFGREP(ADDR=0xFF, REPLY=AUTO_ADDR, UUID=PD_UUID_2) PD3: osdp_MFGREP(ADDR=0xFF, REPLY=AUTO_ADDR, UUID=PD_UUID_3) PD4: osdp_MFGREP(ADDR=0xFF, REPLY=AUTO_ADDR, UUID=PD_UUID_4)

Transaction 2: CP: osdp_MFG(ADDR=0x7F, PD_ID_ALLOC, UUID_1 <=> PD_ID_1, UUID_1 <=> PD_ID_1, UUID_2 <=> PD_ID_2, UUID_3 <=> PD_ID_3, UUID_4 <=> PD_ID_4) PD1: osdp_MFGREP(ADDR=PD_ID_1, REPLY=PD_ADDR_CONFIRM, UUID=UUID_1) PD2: osdp_MFGREP(ADDR=PD_ID_2, REPLY=PD_ADDR_CONFIRM, UUID=UUID_2) PD3: osdp_MFGREP(ADDR=PD_ID_3, REPLY=PD_ADDR_CONFIRM, UUID=UUID_3) PD4: osdp_MFGREP(ADDR=PD_ID_4, REPLY=PD_ADDR_CONFIRM, UUID=UUID_4)

(ALL PDs have their IDs now)

Other design notes/considerations:

• UUID could be a 64 bit random number generated by the PD (the CP can supply the PDs with a initial random seed in osdp_MFG(AUTO_ADDR) if the PDs don't have juice to produce reasonable randomness)
• PD response to broadcast collisions avoidance/detection may be a problem. We can come up with some backoff method
• If for some reason things don't go as planned, the CP can just decide to restart the auto addressing scheme and PDs have to be ready to do the same.

[schmida2]

@sidcha thanks for creating this issue for discussion the OSDP auto addressing idea.

I believe your point

PD response to broadcast collisions avoidance/detection may be a problem. We can come up with some backoff method

is a critical one:

• I would want to guarantee coexistence with PDs that do not know auto addressing. Here I would anticipate collisions with NAK (unknown command) replies.
• The introduction of backoff times - as I see it - would result in a violation of the OSDP standard timings.
• using broadcasts during operation sets back message sequence numbers (SQN) and this would harm the OSDP built-in error recovery

For the latter point I will come up with a proposal revision 2 without using broadcasts (reviewing inhouse at the moment). We ran extensive simulations of the auto addressing algorithm and now we try to get the following flow working with libosdp. Items in red color are potential changes for the libosdp.

1. The Access Controller would need to have control over starting communication with the PDs individually
2. The auto addressing should be done before secure session gets established
3. For both cp_xxx_callback() and pd_yyy_callback() I am not sure how to correlate the callback to the respective command. I admit the pd_yyy_callback() is not top prio.

[schmida2]

Sorry for keeping you waiting for the Revision 2 of the OSDP auto addressing concept. Here it is:

https://github.com/schmida2/libosdp/blob/osdp-extension-autoaddr/OSDP_Extension-AutoAddressingProtocol.md

, and it is in line with the sequence diagram I posted on May 10.