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).
