How does Source Routing work with EZSP?

While stack tables generally live on the network coprocessor (NCP) in an EZSP+Host development scenario, the Source Route Table is a bit different. The following paragraphs describe how EZSP can utilize a host-side source route table and/or its internal source route table to assist with the source-routing of outgoing APS Unicasts and APS ACKs.

Route Storage/Management
If EZSP_CONFIG_SOURCE_ROUTE_TABLE_SIZE is configured as non-zero size (call the arbitrary size “X”) for the NCP (via SetConfigurationValue 0×1A), the NCP will use a FIFO queue to buffer the last X source routes (seen in incoming Route Record packets) in its internal source route table. Regardless of the value of X (even if X=0), there is also always a “currentSourceRoute” buffer in the NCP that is used for the host to manually set/override the NCP’s source route to the next destination. This buffer is managed by the host with SetSourceRoute EZSP command (frame ID 0×5A). CurrentSourceRoute can only be set by the host, but it is always cleared by the NCP after each Unicast or ACK has been sent.

The notion is that the host would store some number of source routes (call this quantity “Y”) in its own table, via Ember’s utility code from app/util/source-route-host.c (and source-route-common.c). For a High-RAM concentrator, Y is assumed to be large enough to accommodate all possible source routes from the concentrator (call that quantity “T”), or at least all the source routes the concentrator would ever need to use (for ACKs and Unicasts). For a Low-RAM concentrator, Y is assumed to be less than T but greater than 0. (Technically, since the NCP can store a few table entries internally if configured to do so, the host table size Y could be 0, and the NCP would handle the cache of source routes for a Low-RAM concentrator.)

Routing Logic
Any time a Unicast/ACK needs to be sent, the NCP will look at CurrentSourceRoute (which host should be set in advance of SendUnicast/SendReply if using a host-specified route from the host’s table). If this is set and matches the destination needed for the current frame, it takes precedence as the source route for the current frame. If not, the NCP will look in its internal table and try to find a source route to destination. If still not found after resorting to its internal table, the stack will try traditional (as opposed to many-to-one [MTO]) route discovery (if you have it enabled/forced, which is not recommended since mixing normal route discovery with MTORR can cause strange behavior), and if that fails or is disallowed, the stack will try routing via neighbor table (if destination is a neighbor). Else, the message/ACK will fail.