Cellular Network Infrastructure » Core Network (CN) » OsmoSTP

Following osmo-stp user manual section needs to be updated when this is implemented:

4.5.1.2    Application Server (AS)An Application Server is basically a logical entity representing one particular external application (from the SS7 point of view)which is interfaced with the SS7 network by means of one of the SIGTRAN protocols.An Application Server can have one or more Application Server Processes associated with it.  This functionality (currently notimplemented in Osmocom) can be used for load-balancing or fail-over scenarios.

Seems the expected place for this to happen is in libosmo-sccp.git xua_as_transmit_msg().

Found related information in https://tools.ietf.org/html/rfc4666 (RFC for M3UA):

4.3.4.3.  ASP Active Procedures
   There are three modes of Application Server traffic handling in the
   SGP M3UA layer: Override, Loadshare and Broadcast.  When included,
   the Traffic Mode Type parameter in the ASP Active message indicates
   the traffic handling mode to be used in a particular Application
   Server.  If the SGP determines that the mode indicated in an ASP
   Active message is unsupported or incompatible with the mode currently
   configured for the AS, the SGP responds with an Error message
   ("Unsupported / Invalid Traffic Handling Mode").  If the traffic
   handling mode of the Application Server is not already known via
   configuration data, then the traffic handling mode indicated in the
   first ASP Active message causing the transition of the Application
   Server state to AS-ACTIVE MAY be used to set the mode.

3.6.1.  Registration Request (REG REQ):

   Traffic Mode Type: 32-bit (unsigned integer)

   The optional Traffic Mode Type parameter identifies the traffic mode
   of operation of the ASP(s) within an Application Server.  The format
   of the Traffic Mode Type Identifier is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000b          |         Length = 8            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Traffic Mode Type                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The valid values for Traffic Mode Type are shown in the following
   table:

         1     Override
         2     Loadshare
         3     Broadcast

3.7.1.  ASP Active:         

   Traffic Mode Type: 32-bit (unsigned integer)

      The Traffic Mode Type parameter identifies the traffic mode of
      operation of the ASP within an AS.  The valid values for Traffic
      Mode Type are shown in the following table:

         1         Override
         2         Loadshare
         3         Broadcast

      Within a particular Routing Context, Override, Loadshare, and
      Broadcast SHOULD NOT be mixed.  The Override value indicates that
      the ASP is operating in Override mode, in which the ASP takes over
      all traffic in an Application Server (i.e., primary/backup
      operation), overriding any currently active ASPs in the AS.  In
      Loadshare mode, the ASP will share in the traffic distribution

Similar information can be found in RFC for SUA:
https://tools.ietf.org/html/rfc3868

Found also some references in code:

enum m3ua_traffic_mode {
    M3UA_TMOD_OVERRIDE    = 1,
    M3UA_TMOD_LOADSHARE    = 2,
    M3UA_TMOD_BCAST        = 3,
};

enum osmo_ss7_as_traffic_mode {
    OSMO_SS7_AS_TMOD_OVERRIDE = 0,    /* default */
    OSMO_SS7_AS_TMOD_BCAST,
    OSMO_SS7_AS_TMOD_LOADSHARE,
    OSMO_SS7_AS_TMOD_ROUNDROBIN,
    _NUM_OSMO_SS7_ASP_TMOD
};

And function osmo_ss7_tmode_to_xua() and osmo_ss7_tmode_from_xua() provides a way to translate between them.

Traffic mode is already parsed into "as->cfg.mode" in "as_traf_mode_cmd". It is set by default to OSMO_SS7_AS_TMOD_LOADSHARE in osmo_ss7_as_find_or_create().

So far it seems out client code is submitting traffic mode = override in REG REQ messages, which probably changes the mode. That traffic mode is parsed and stored into as->cfg.mode in handle_rkey_reg().

Related patches:
remote: https://gerrit.osmocom.org/c/libosmo-sccp/+/15800 ss7: Fix trailing whitespace
remote: https://gerrit.osmocom.org/c/libosmo-sccp/+/15801 vty: Print traffic mode during show cs7 instance as
remote: https://gerrit.osmocom.org/c/libosmo-sccp/+/15802 ss7: Implement AS traffic mode loadshare using round robin ASP selection

• STP uses the "listen" node and I'm not sure if it can use the "as" node where the traffic-mode can be configured. I need to check if "as" can be used or I need to add the traffic-mode command to the "listen" node, so a preferred method can be forced.
• In general, the traffic mode is requested by ASPs towards the STP. Currently, If I set "traffic-mode loadshare" in "as" node of osmo-bsc.cfg, it still seems to be sending "override" during REG REQ (and nothing during AS ACT?). Once this is fixed if ASPs require "loadshare" then STP should be able to provide it.

Hi Roch,

I didn't start with the IPA-side implementation yet, it's in the TODO list.
So far I have been implementing the round robin loadshare part in M3UA and making sure I can configure through VTY and use it with RKM in an osmocom setup with BSC<->STP<->MSC, which was the quickest way to have something to start with.
I'll now focus on statically-configured AS/ASP in osmo-stp for both M3UA and IPA.

Using RKM traffic mode configured in VTY fixed here:
https://gerrit.osmocom.org/c/libosmo-sccp/+/15803 ss7: Set configured AS traffic mode when sending Routing Key Register msg

Kind regards,
Pau

Hi Pau,

I just force-pushed an update to STP_Tests.ttcn in the laforge/stp branch of osmo-ttcn3-hacks.git. It contains a test like TC_tmt_loadshare which should test functionality with traffic-mode load-share. I haven't tested the test yet, but I'll see if I can test it with a proprietary STP (Cisco ITP).

• with traffic-mode loadshare set in the vty
• withoutany traffic-mode set in the VTY

The outcome is the same: The first of the two ASPs always gets all the traffic, despite "show" in the VTY showing two ASP_ACTIVE ASPs within an AS that has loadshare:

                          Routing    Routing Key                          Cic   Cic   Traffic
AS Name      State        Context    Dpc           Si   Opc           Ssn Min   Max   Mode
------------ ------------ ---------- ------------- ---- ------------- --- ----- ----- -------
as-sender    AS_ACTIVE    1023       23                                                override
as-receiver  AS_ACTIVE    1042       42                                               loadshare

ASP Name      AS Name       State          Type Remote IP Addr:Rmt Port SCTP
------------  ------------  -------------  ---- ----------------------- ----------
asp-sender    ?             ASP_ACTIVE     m3ua  127.0.0.1:9999            
asp-receiver0  ?             ASP_ACTIVE     m3ua  127.0.0.1:10000            
asp-receiver1  ?             ASP_ACTIVE     m3ua  127.0.0.1:10001            

pcap file attached

current osmo-stp master has been tested with TTCN3 STP_Tests_IPA.ttcn from osmo-ttcn3-hacks.git branch laforge/stp and seems to support loadsharing fine on IPA ASs.

Only missing thing is to fix the TTCN3 hack required to have tests working in order to be able to merge the TTCN3 tests branch into master: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15821

libosmo-sccp.git fix to have TTCN3 tests working without the HACK patch available here:
https://gerrit.osmocom.org/c/libosmo-sccp/+/16005 xua: ipa_asp_fsm: Allow receiving IPA ID ACK before IPA ID RESP

Once all commit are merged and related TTCN3 tests are green (should be after everything's merged) we can probably close this ticket.

all commits merged. tests passing. closed.