pespin submitted this change.

View Change

Approvals: osmith: Looks good to me, approved Jenkins Builder: Verified laforge: Looks good to me, but someone else must approve
tcap: Add SUA spec references regarding TCAP routing

It seems most of TCAP routing we have implemented is somehow documented
in RFC3868 (SUA).
The main difference is that we are implementing TCAP routing on top
of SCCPLite (IPA/SCCP) instead.

Change-Id: I9c1806570529e1568c5f65152b4bb298f19afe14
---
M src/tcap_as_loadshare.c
M src/tcap_trans_tracking.c
2 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/src/tcap_as_loadshare.c b/src/tcap_as_loadshare.c
index 2e8d86a..12a482c 100644
--- a/src/tcap_as_loadshare.c
+++ b/src/tcap_as_loadshare.c
@@ -505,17 +505,35 @@

switch (as->cfg.loadshare.tcap.unroutable_tcap_msg) {
case SS7_AS_TCAP_UNROUTABLE_LOAD_SHARE_AS:
+ /* RFC3868 A.3.1 Connectionless Transport:
+ * "load sharing is only possible for the first message in a
+ * TCAP dialogue (TC_Begin, TC_Query, TC_Unidirectional) [...]
+ * unless the ASPs are able to share state and maintain sequenced
+ * delivery. To this end, the SGP needs to know the TID
+ * allocation policy of the ASPs in a single AS".
+ *
+ * Hence, if UNROUTABLE_LOAD_SHARE_AS is configured, allocation
+ * policy "State sharing" at the peer is assumed. */
asp = select_asp_tcap_enabled_rr(as);
if (asp)
rc = 0;
break;
case SS7_AS_TCAP_UNROUTABLE_ROUTE_FALLBACK:
+ /* RFC3868 A.2:
+ * "Replicated relay points: in normal circumstances, the path
+ * from SEP to ASP will always go via the same SGP when
+ * in-sequence-delivery is requested. However, linkset failures
+ * may cause MTP to reroute to the other SG." */
/* No ASP selection. Try to route the SCCP msg to the fallback DPC */
rc = asp_loadshare_tcap_route_fallback(as, mtp3_rtlb, sccp_msg);
if (!rc) /* rc == 0 would require a valid asp, use > 0 to drop the msg, but don't send an error back if needed */
rc = 1;
break;
case SS7_AS_TCAP_UNROUTABLE_REJECT_UDTS:
+ /* RFC3868 4.7.3.1 TCAP traffic:
+ * "If an ASP is not available, the SG may generate (X)UDTS
+ * "routing failure", if the return option is used." */
+ /* fall-through */
default:
/* default case, asp stays NULL, will reject when returning -ENOKEY */
rc = -ENOKEY;
@@ -632,6 +650,11 @@
goto out_free_sua;
}

+ /* RFC3868 4.7.3.1 TCAP traffic:
+ * "Messages not containing a destination (or "responding") TID, i.e.,
+ * Query, Begin, Unidirectional, are loadshared among the available
+ * ASPs. Any scheme permitting a fair load distribution among the ASPs
+ * is allowed (e.g., round robin)." */
asp = select_asp_tcap_enabled_rr(as);
if (asp) {
rate_ctr_inc2(as->ctrg, SS7_AS_CTR_TCAP_ASP_SELECTED);
@@ -651,6 +674,9 @@
goto out_free_sua;
}

+ /* RFC3868 4.7.3.1 TCAP traffic:
+ * "When a destination TID is present, the SG extracts the label and
+ * selects the ASP that corresponds with it." */
asp = tcap_trans_track_continue(as, &called_addr, &parsed.dtid, &calling_addr, &parsed.otid);
if (!asp) {
LOGPAS(as, DLTCAP, LOGL_INFO, "Couldn't find cached ASP for TCAP Continue, dtid %u/otid %u, using tcap route", parsed.dtid, parsed.otid);
@@ -794,6 +820,14 @@
uint8_t data[0];
} __attribute__((packed));

+/* This message is similar to provided "TID Label" in SUA ASP ACTIVATE,
+ * since there's no ASP management messages such as ASP ACTIVATE in IPA.
+ *
+ * RFC3868 A.3.1: "Fixed range of TIDs per ASP in the AS. [...]
+ * This information may be provisioned in the SG, or may be dynamically
+ * exchanged via the ASP_Active message."
+ * See also RFC3868 4.7.2.1. Association Setup, ASP going active
+ */
struct ipa_tcap_routing_add_range {
uint32_t tid_start;
uint32_t tid_end;
@@ -907,6 +941,7 @@

LOGPASP(asp, DLTCAP, LOGL_INFO, "Rx: TCAP Add Range command: seq: %u pc: %u ssn: %u [%u-%u]\n", osmo_ntohl(hdr->seq), tcar.pc, tcar.ssn, tcar.tid_start, tcar.tid_end);

+ /* RFC3868 4.7.2.1 "The SG has to perform some trivial plausibility checks on the parameters" */
tcrng = tcap_overlap_tid(as, tcar.pc, tcar.ssn, tcar.tid_start, tcar.tid_end);
if (tcrng) {
LOGPASP(asp, DLTCAP, LOGL_ERROR, "New TCAP Range overlaps with existing range to ASP %s [%u-%u]. Rejecting Add Range Command seq: %u pc: %u ssn: %u [%u-%u]\n",
diff --git a/src/tcap_trans_tracking.c b/src/tcap_trans_tracking.c
index 421ad7b..d88a12b 100644
--- a/src/tcap_trans_tracking.c
+++ b/src/tcap_trans_tracking.c
@@ -21,6 +21,12 @@
*
*/

+/* RFC3868 4.7.2 Support for Loadsharing:
+ * "the loadsharing scheme used at the SG must make sure that messages continuing or ending the
+ * transactions/connections arrive at the same ASP where the initial message (TC_Query, TC_Begin,
+ * CR) was sent to/received from."
+*/
+
#include <stdint.h>

#include <osmocom/core/msgb.h>

To view, visit change 43903. To unsubscribe, or for help writing mail filters, visit settings.

Gerrit-MessageType: merged
Gerrit-Project: libosmo-sigtran
Gerrit-Branch: master
Gerrit-Change-Id: I9c1806570529e1568c5f65152b4bb298f19afe14
Gerrit-Change-Number: 43903
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin@sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <daniel@totalueberwachung.de>
Gerrit-Reviewer: laforge <laforge@osmocom.org>
Gerrit-Reviewer: lynxis lazus <lynxis@fe80.eu>
Gerrit-Reviewer: osmith <osmith@sysmocom.de>
Gerrit-Reviewer: pespin <pespin@sysmocom.de>