xua_asp_fsm: Validate remote ASP Id matching config in SG role
The node in SG role really doesn't have an ASP Id of its own (it is never sent over the wire). Hence, use the "asp-identifier <N>" VTY config in SG role to require the ASP to identify itself with a given ASP identifier.
This new struct allows supporting unlimited number of ASPs per AS. It can also potentially be used in the future to: * Hold M3UA "ASP Identifier" per AS<->ASP association * Speed up iterating over AS served by a given ASP.
NOTE: Having >16 ASPs per AS may not be desirable, for instance under loadshare traffic mode ITU SLS is 4 bit, so despite having ext_sls extending the table to 128 entries based on OPC, it may not provide enough entropy to properly loadshare among all of them.
This way we can iterate easily/quickly the AS served by a given ASP. This in turn allows simplifying some code since we cache the amount of AS served by the ASP at any time, so we save some counting.
Look for counterpart on the object with the shortest list, ie. convert from O(N) to O(min(N,M)). This way eg. if we have 100 ASPs on 1 AS, lookup time becomes O(1). Same if we have eg. 1 ASP serving 100 AS.
If configured, it will be transmitted during ASP UP and ASP UP ACK. This may be needed if facing an SG/IPSP peer who requires ASP Identifier to be set.
xua_asp_fsm: Error on ASP UP (ACK) with non-unique ASP Identifier
Following RFC4666: """ The "Invalid ASP Identifier" error is sent by an SGP in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier """
Sending that kind of event is up to the layer manager. Right now, all ASPs (except ipa_aspm_fsm, which doesn't need that event because there's no ACTIVATE in IPA) have an associated layer manager FSM, so that workaround is not needed.
That quirk was added back in time most probably when interacting with some peer who claimed to be in SG mode but actually was in IPSP mode. Hence, to be on the safe side, be relaxed and allow accepting DAUD also if the quirk is added, otherwise it may be impossible to continue communication with that faulty peer. In theory according to spec DAUD should only be sent ASP->SG.
xua: Improve logging around unexpected snm messages
Log rx of unexpected message type according to configured role. Decrease verbosity of DAUD logging to match the new logging.
For SUA we can use M3UA's m3ua_snm_msgt_names because the value/strings are the same and they are actually used through m3ua_msg_class_snm in xua_dialect_sua.
The rx DUNA/DAVA/DUPU paths are already guarded at m3ua.c and sua.c to only call xua_snm_rx_{duna,dava,dupu}() in ASP role. Hence, calling those functions is expected to always happen in ASP role.
We could eventually define how the IPA CCM is expected to behave when in IPSP role (eg. implementing/allowing both sides of IPA CCM, or assigning an IPA CCM role based on TCP client/server), but that has not yet been defined.
IPSP is actually a good candidate for IPA ASPs, since in IPA proto we don't have SNM messaging either, and it's meant to be used point-to-point (or through STP by assigning hardocded routes).
The xua server has nothing to do with a node being an ASP or an SG, it used to allow transport server features (SCTP/TCP server). One may want to configure an ASP role with a SCTCP server.
Several changes to improve separation of the LM object and its lifecycle: * Store in ss7_asp a pointer to a xua_layer_manager, which contains all implementation dependent information inside its priv pointer. * Add a new free_func field to the xua_layer_manager struct in order to be able to free it without knowing how it was allocated. * Get rid og the loglevel param, LOGL_DEBUG was always passed and that was actually an implementation specific detail of the default xua layer manager. * Pass pointer to function to be called by LM to submit primitives to M3UA.
Right now the LM will stay in IDLE for role=SG, but it already provides with an easier logic where all xUA ASPs (no matter their role) have an associated FSM object, which can be extnded later on. This way we already valdiate the FSM instance lifecycle wroks as expected. It also allows in the future more easily integrating the LM in role IPSP, where it will need to be extended.
The role is actually taken from the asp object, and it's not expected to change during its lifetime, so there's no really a need to keep a copy of it. Simplify the code by using the asp role everywhere.
The specific spec paragraph talks about "Alternate ASP_Active" scenario in quotes, which I could find right away by grepping in the code. Improve the documentation so it can be easily matched in code.
