LaForge's home page (Posts about sigtran)https://laforge.gnumonks.org/blog/tags/sigtran.atom2022-06-21T07:49:57ZHarald WelteNikolaOsmoDevCon 2017 Reviewhttps://laforge.gnumonks.org/blog/20170503-osmodevcon/2017-05-03T00:00:00+02:002017-05-03T00:00:00+02:00Harald Welte<p>After the public user-oriented OsmoCon 2017, we also recently had the
6th incarnation of our annual contributors-only <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon">Osmocom Developer Conference</a>: The <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2017">OsmoDevCon 2017</a>.</p>
<p>This is a much smaller group, typically about 20 people, and is limited
to actual developers who have a past record of contributing to any of
the many <a class="reference external" href="https://osmocom.org/projects">Osmocom projects</a>.</p>
<p>We had a large number of presentation and discussions. In fact, so
large that the schedule of talks extended from 10am to midnight on some
days. While this is great, it also means that there was definitely too
little time for more informal conversations, chatting or even actual
work on code.</p>
<p>We also have such a wide range of topics and scope inside Osmocom, that
the traditional <em>ad-hoch scheduling</em> approach no longer seems to be
working as it used to. Not everyone is interested in (or has time for)
all the topics, so we should group them according to their topic/subject
on a given day or half-day. This will enable people to attend only
those days that are relevant to them, and spend the remaining day in an
adjacent room hacking away on code.</p>
<p>It's sad that we only have OsmoDevCon once per year. Maybe that's
actually also something to think about. Rather than having 4 days once
per year, maybe have two weekends per year.</p>
<p>Always in motion the future is.</p>Overhyped Dockerhttps://laforge.gnumonks.org/blog/20170503-docker-overhyped/2017-05-03T00:00:00+02:002017-05-03T00:00:00+02:00Harald Welte<div class="section" id="overhyped-docker-missing-the-most-basic-features">
<h2>Overhyped Docker missing the most basic features</h2>
<p>I've always been extremely skeptical of suddenly emerging over-hyped
technologies, particularly if they advertise to solve problems by adding
yet another layer to systems that are already sufficiently complex
themselves.</p>
<p>There are of course many issues with containers, ranging from replicated
system libraries and the basic underlying statement that you're giving
up on the system packet manager to properly deal with dependencies.</p>
<p>I'm also highly skeptical of FOSS projects that are primarily driven by
one (VC funded?) company. Especially if their offering includes a
so-called <em>cloud service</em> which they can stop to operate at any given
point in time, or (more realistically) first get everybody to use and
then start charging for.</p>
<p>But well, despite all the bad things I read about it over the years, on
one day in May 2017 I finally thought let's give it a try. My problem
to solve as a test balloon is fairly simple.</p>
</div>
<div class="section" id="my-basic-use-case">
<h2>My basic use case</h2>
<p>The plan is to start OsmoSTP, the m3ua-testtool and the sua-testtool,
which both connect to OsmoSTP. By running this setup inside containers
and inside an internal network, we could then execute the entire
testsuite e.g. during jenkins test without having IP address or port
number conflicts. It could even run multiple times in parallel on one
buildhost, verifying different patches as part of the continuous
integration setup.</p>
<p>This application is not so complex. All it needs is three containers,
an internal network and some connections in between. Should be a piece
of cake, right?</p>
<p>But enter the world of buzzword-fueled web-4000.0 software-defined
virtualised and orchestrated container NFW + SDN vodoo: It turns out to
be impossible, at least not with the preferred tools they advertise.</p>
</div>
<div class="section" id="dockerfiles">
<h2>Dockerfiles</h2>
<p>The part that worked relatively easily was writing a few Dockerfiles to
build the actual containers. All based on debian:jessie from the
library.</p>
<p>As m3ua-testsuite is written in guile, and needs to build some guile
plugin/extension, I had to actually include guile-2.0-dev and other
packages in the container, making it a bit bloated.</p>
<p>I couldn't immediately find a nice example Dockerfile recipe that would
allow me to build stuff from source outside of the container, and then
install the resulting binaries into the container. This seems to be a
somewhat weak spot, where more support/infrastructure would be helpful.
I guess the idea is that you simply install applications via package
feeds and apt-get. But I digress.</p>
<p>So after some tinkering, I ended up with three docker containers:</p>
<ul class="simple">
<li><p>one running OsmoSTP</p></li>
<li><p>one running m3ua-testtool</p></li>
<li><p>one running sua-testtool</p></li>
</ul>
<p>I also managed to create an internal <em>bridged</em> network between the
containers, so the containers could talk to one another.</p>
<p>However, I have to manually start each of the containers with ugly long
command line arguments, such as <code class="docutils literal">docker run <span class="pre">--network</span> sigtran <span class="pre">--ip</span>
172.18.0.200 <span class="pre">-it</span> <span class="pre">osmo-stp-master</span></code>. This is of course sub-optimal, and
what Docker Services + Stacks should resolve.</p>
</div>
<div class="section" id="services-stacks">
<h2>Services + Stacks</h2>
<p>The idea seems good: A <em>service</em> defines how a given container is run,
and a <em>stack</em> defines multiple containers and their relation to each
other. So it should be simple to define a <em>stack</em> with three
<em>services</em>, right?</p>
<p>Well, it turns out that it is not. Docker documents that you can
configure a static <code class="docutils literal">ipv4_address</code> <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id5" id="id1">1</a> for each service/container, but it
seems related configuration statements are simply silently
ignored/discarded <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id6" id="id2">2</a>, <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id7" id="id3">3</a>, <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id8" id="id4">4</a>.</p>
<p>This seems to be related that for some strange reason <em>stacks</em> can (at
least in later versions of docker) only use <em>overlay</em> type networks,
rather than the much simpler <em>bridge</em> networks. And while bridge
networks appear to support static IP address allocations, overlay
apparently doesn't.</p>
<p>I still have a hard time grasping that something that considers itself a
serious product for production use (by a company with estimated value
over a billion USD, not by a few hobbyists) that has no support for
running containers on static IP addresses. that. How many applications
out there have I seen that require static IP address configuration? How
much simpler do setups get, if you don't have to rely on things like
dynamic DNS updates (or DNS availability at all)?</p>
<p>So I'm stuck with having to manually configure the network between my
containers, and manually starting them by clumsy shell scripts, rather
than having a proper abstraction for all of that. Well done :/</p>
</div>
<div class="section" id="exposing-ports">
<h2>Exposing Ports</h2>
<p>Unrelated to all of the above: If you run some software inside
containers, you will pretty soon want to expose some network services
from containers. This should also be the most basic task on the planet.</p>
<p>However, it seems that the creators of docker live in the early 1980ies,
where only TCP and UDP transport protocols existed. They seem to have
missed that by the late 1990ies to early 2000s, protocols like <a class="reference external" href="https://datatracker.ietf.org/doc/rfc2960">SCTP</a> or <a class="reference external" href="https://datatracker.ietf.org/doc/rfc4340/">DCCP</a> were invented.</p>
<p>But yet, in 2017, Docker chooses to</p>
<ul class="simple">
<li><p>blindly assume TCP in
<a class="reference external" href="https://docs.docker.com/engine/reference/builder/#expose">https://docs.docker.com/engine/reference/builder/#expose</a> without even
mentioning it (or designing the syntax to accept any specification of
the protocol)</p></li>
<li><p>design a syntax (<code class="docutils literal">/tcp</code>) in the command-line parsing (see
<a class="reference external" href="https://docs.docker.com/engine/reference/run/#expose-incoming-ports">https://docs.docker.com/engine/reference/run/#expose-incoming-ports</a>), but then
only parse tcp and udp, despite people requesting support for other
protocols like SCTP <a class="reference external" href="https://github.com/moby/moby/issues/9689">as early as three years ago</a></p></li>
</ul>
<p>Now some of the readers may think 'who uses SCTP anyway'. I will give
you a straight answer: Everyone who has a mobile phone uses SCTP. This
is due to the fact that pretty much all the connections inside cellular
networks (at least for 3G/4G networks, and in reality also for many 2G
networks) are using SCTP as underlying transport protocol, from the
radio access network into the core network. So every time you switch
your phone on, or do anything with it, you are using SCTP. Not on your
phone itself, but by all the systems that form the network that you're
using. And with the drive to C-RAN, NFV, SDN and all the other
buzzwords also appearing in the Cellular Telecom field, people should
actually worry about it, if they want to be a part of the software stack
that is used in future cellular telecom systems.</p>
</div>
<div class="section" id="summary">
<h2>Summary</h2>
<p>After spending the better part of a day to do something that seemed like
the most basic use case for running three networked containers using
Docker, I'm back to step one: Most likely inventing some custom
scripts based on <a class="reference external" href="http://man7.org/linux/man-pages/man2/unshare.2.html">unshare</a> to run my three
test programs in a separate network namespace for isolated execution of
test suite execution as part of a Jenkins CI setup :/</p>
<p>It's also clear that Docker apparently don't care much about playing a
role in the Cellular Telecom world, which is increasingly moving away
from proprietary and hardware-based systems (like STPs) to virtualised,
software-based systems.</p>
<dl class="footnote brackets">
<dt class="label" id="id5"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id1">1</a></span></dt>
<dd><p><a class="reference external" href="https://docs.docker.com/compose/compose-file/#ipv4address-ipv6address">https://docs.docker.com/compose/compose-file/#ipv4address-ipv6address</a></p>
</dd>
<dt class="label" id="id6"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id2">2</a></span></dt>
<dd><p><a class="reference external" href="https://forums.docker.com/t/docker-swarm-1-13-static-ips-for-containers/28060">https://forums.docker.com/t/docker-swarm-1-13-static-ips-for-containers/28060</a></p>
</dd>
<dt class="label" id="id7"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id3">3</a></span></dt>
<dd><p><a class="reference external" href="https://github.com/moby/moby/issues/31860">https://github.com/moby/moby/issues/31860</a></p>
</dd>
<dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id4">4</a></span></dt>
<dd><p><a class="reference external" href="https://github.com/moby/moby/issues/24170">https://github.com/moby/moby/issues/24170</a></p>
</dd>
</dl>
</div>OsmoCon 2017 Reviewhttps://laforge.gnumonks.org/blog/20170501-osmocon/2017-05-01T00:00:00+02:002017-05-01T00:00:00+02:00Harald Welte<p>It's already one week past the event, so I really have to sit down and
write some rewview on the first public <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon">Osmocom Conference</a> ever:
<a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017">OsmoCon 2017</a>.</p>
<p>The event was a huge success, by all accounts.</p>
<ul class="simple">
<li><p>We've not only been sold out, but we also had to turn down some last
minute registrations due to the venue being beyond capacity (60
seats). People traveled from Japan, India, the US, Mexico and many
other places to attend.</p></li>
<li><p>We've had an amazing audience ranging from commercial operators to
community cellular operators to professional developers doing work
relate to osmocom, academia, IT security crowds and last but not least
enthusiasts/hobbyists, with whom the project[s] started.</p></li>
<li><p>I've received exclusively positive feedback from many attendees</p></li>
<li><p>We've had a great programme. Some part of it was of introductory
nature and probably not too interesting if you've been in Osmocom for
a few years. However, the work on 3G as well as the current roadmap
was probably not as widely known yet. Also, I really loved to see
Roch's talk about <a class="reference external" href="https://media.ccc.de/v/osmocon17-4011-showcase_running_a_commercial_cellular_network_with_osmobts_osmopcu_osmobsc_co">Running a commercial cellular network with Osmocom
software</a>
as well as the talk on Facebook's <a class="reference external" href="https://media.ccc.de/v/osmocon17-4013-opencellular_open_source_wireless_access_platform">OpenCellular BTS hardware</a>
and the <a class="reference external" href="https://media.ccc.de/v/osmocon17-4014-community_cellular_manager">Community Cellular Manager</a>.</p></li>
<li><p>We have very professional live streaming + video recordings courtesy
of the <a class="reference external" href="https://c3voc.de/">C3VOC</a> team. Thanks a lot for your
support and for having the <a class="reference external" href="https://media.ccc.de/c/osmocon17">video recordings</a> of all talks online already at
the next day after the event.</p></li>
</ul>
<p>We also received some requests for improvements, many of which we will
hopefully consider before the next Osmocom Conference:</p>
<ul class="simple">
<li><p>have a multiple day event. Particularly if you're traveling
long-distance, it is a lot of overhead for a single-day event. We of
course fully understand that. On the other hand, it was the first
Osmocom Conference, and hence it was a test balloon where it was
initially unclear if we'll be able to get a reasonable number of
attendees interested at all, or not. And organizing an event with
venue and talks for multiple days if in the end only 10 people attend
would have been a lot of effort and financial risk. But now that we
know there are interested folks, we can definitely think of a multiple
day event next time</p></li>
<li><p>Signs indicating venue details on the last meters. I agree, this cold
have been better. The address of the venue was published, but we
could have had some signs/posters at the door pointing you to the
right meeting room inside the venue. Sorry for that.</p></li>
<li><p>Better internet connectivity. This is a double-edged sword. Of
course we want our audience to be primarily focused on the talks and
not distracted :P I would hope that most people are able to survive
a one day event without good connectivity, but for sure we will have
to improve in case of a multiple-day event in the future</p></li>
</ul>
<p>In terms of my requests to the attendees, I only have one</p>
<ul class="simple">
<li><p>Participate in the discussions on the schedule/programme while it is
still possible to influence it. When we started to put together the
programme, I posted about it on the openbsc mailing list and invited
feedback. Still, most people seem to have missed the time window
during which talks could have been submitted and the schedule still
influenced before finalizing it</p></li>
<li><p>Register in time. We have had almost no registrations until about two
weeks ahead of the event (and I was considering to cancel it), and
then suddenly were sold out in the week ahead of the event. We've had
people who first booked their tickets, only to learn that the tickets
were sold out. I guess we will introduce <em>early bird</em> pricing and add
a very expensive <em>last minute</em> ticket option next year in order to
increase motivation to register early and thus give us flexibility
regarding venue planning.</p></li>
</ul>
<p>Thanks again to everyone involved in OsmoCon 2017!</p>
<p>Ok, now, all of you who missed the event: Go to
<a class="reference external" href="https://media.ccc.de/c/osmocon17">https://media.ccc.de/c/osmocon17</a> and check out the recordings. Have
fun!</p>Things you find when using SCTP on Linuxhttps://laforge.gnumonks.org/blog/20170417-linux-sctp-dry-events/2017-04-17T00:00:00+02:002017-04-17T00:00:00+02:00Harald Welte<div class="section" id="observations-on-sctp-and-linux">
<h2>Observations on SCTP and Linux</h2>
<p>When I was still doing Linux kernel work with netfilter/iptables in the
early 2000's, I was somebody who actually regularly had a look at the
new RFCs that came out. So I saw the SCTP RFCs, SIGTRAN RFCs, SIP and
RTP, etc. all released during those years. I was quite happy to see
that for new protocols like SCTP and later DCCP, Linux quickly received
a mainline implementation.</p>
<p>Now most people won't have used SCTP so far, but it is a protocol used
as transport layer in a lot of telecom protocols for more than a decade
now. Virtually all protocols that have traditionally been spoken over
time-division multiplex E1/T1 links have been migrated over to SCTP
based protocol stackings.</p>
<p>Working on various Open Source telecom related projects, i of course
come into contact with SCTP every so often. Particularly some years
back when implementing the Erlang SIGTAN code in <a class="reference external" href="http://git.osmocom.org/erlang/osmo_ss7/tree/src">erlang/osmo_ss7</a> and most recently
now with the introduction of libosmo-sigtran with its OsmoSTP, both part
of the <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/">libosmo-sccp repository</a>.</p>
<p>I've also hard to work with various proprietary telecom equipment over
the years. Whether that's some eNodeB hardware from a large brand
telecom supplier, or whether it's a MSC of some other vendor. And they
all had one thing in common: Nobody seemed to use the Linux kernel SCTP
code. They all used proprietary implementations in userspace, using RAW
sockets on the kernel interface.</p>
<p>I always found this quite odd, knowing that this is the route that you
have to take on proprietary OSs without native SCTP support, such as
Windows. But on Linux? Why? Based on rumors, people find the Linux
SCTP implementation not mature enough, but hard evidence is hard to come
by.</p>
<p>As much as it pains me to say this, the kind of Linux SCTP bugs I have
seen within the scope of our work on Osmocom seem to hint that there is
at least some truth to this (see e.g.
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1308360">https://bugzilla.redhat.com/show_bug.cgi?id=1308360</a> or
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1308362">https://bugzilla.redhat.com/show_bug.cgi?id=1308362</a>).</p>
<p>Sure, software always has bugs and will have bugs. But we at Osmocom
are 10-15 years "late" with our implementations of higher-layer
protocols compared to what the mainstream telecom industry does. So if
we find something, and we find it even already during R&D of some
userspace code, not even under load or in production, then that seems a
bit unsettling.</p>
<p>One would have expected, with all their market power and plenty of
Linux-based devices in the telecom sphere, why did none of those large
telecom suppliers invest in improving the mainline Linux SCTP code? I
mean, they all use UDP and TCP of the kernel, so it works for most of
the other network protocols in the kernel, but why not for SCTP? I
guess it comes back to the fundamental lack of understanding how open
source development works. That it is something that the given
industry/user base must invest in jointly.</p>
</div>
<div class="section" id="the-leatest-discovered-bug">
<h2>The leatest discovered bug</h2>
<p>During the last months, I have been implementing SCCP, SUA, M3UA and
OsmoSTP (A Signal Transfer Point). They were required for an <a class="reference external" href="http://osmocom.org/versions/121">effort to
add 3GPP compliant A-over-IP to OsmoBSC and OsmoMSC</a>.</p>
<p>For quite some time I was seeing some erratic behavior when at some
point the STP would not receive/process a given message sent by one of
the clients (ASPs) connected. I tried to ignore the problem initially
until the code matured more and more, but the problems remained.</p>
<p>It became even more obvious when using <a class="reference external" href="https://github.com/nplab/m3ua-testtool">Michael Tuexen's m3ua-testtool</a>,
where sometimes even the most basic test cases consisting of sending +
receiving a single pair of messages like ASPUP -> ASPUP_ACK was failing.
And when the test case was re-tried, the problem often disappeared.</p>
<p>Also, whenever I tried to observe what was happening by meas of strace,
the problem would disappear completely and never re-appear until strace
was detached.</p>
<p>Of course, given that I've written several thousands of lines of new
code, it was clear to me that the bug must be in my code. Yesterday I
was finally prepare to accept that it might actually be a Linux SCTP
bug. Not being able to reproduce that problem on a FreeBSD VM also
pointed clearly into this direction.</p>
<p>Now I could simply have collected some information and filed a bug
report (which some kernel hackers at RedHat have thankfully invited me
to do!), but I thought my use case was too complex. You would have to
compile a dozen of different Osmocom libraries, configure the STP, run
the scheme-language m3ua-testtool in guile, etc. - I guess nobody
would have bothered to go that far.</p>
<p>So today I tried to implement a test case that reproduced the problem in
plain C, without any external dependencies. And for many hours, I
couldn't make the bug to show up. I tried to be as close as possible to
what was happening in OsmoSTP: I used non-blocking mode on client and
server, used the SCTP_NODELAY socket option, used the sctp_rcvmsg()
library wrapper to receive events, but the bug was not reproducible.</p>
<p>Some hours later, it became clear that there was one setsockopt() in
OsmoSTP (actually, libosmo-netif) which enabled all existing SCTP
events. I did this at the time to make sure OsmoSTP has the maximum
insight possible into what's happening on the SCTP transport layer, such
as address fail-overs and the like.</p>
<p>As it turned out, adding that setsockopt for SCTP_FLAGS to my test code
made the problem reproducible. After playing around which of the flags,
it seems that enabling the SENDER_DRY_EVENT flag makes the bug appear.</p>
<p>You can find my detailed report about this issue in
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1442784">https://bugzilla.redhat.com/show_bug.cgi?id=1442784</a> and a program to
reproduce the issue at
<a class="reference external" href="http://people.osmocom.org/laforge/sctp-nonblock/sctp-dry-event.c">http://people.osmocom.org/laforge/sctp-nonblock/sctp-dry-event.c</a></p>
<p>Inside the Osmocom world, luckily we can live without the
SENDER_DRY_EVENT and a corresponding work-around has been submitted and
merged as <a class="reference external" href="https://gerrit.osmocom.org/#/c/2386/">https://gerrit.osmocom.org/#/c/2386/</a></p>
<p>With that work-around in place, suddenly all the <a class="reference external" href="https://github.com/nplab/m3ua-testtool">m3ua-testtool</a> and <a class="reference external" href="https://github.com/nplab/m3ua-testtool">sua-testtool</a> test cases are reliably green
(PASSED) and OsmoSTP works more smoothly, too.</p>
</div>
<div class="section" id="what-do-we-learn-from-this">
<h2>What do we learn from this?</h2>
<p>Free Software in the Telecom sphere is getting too little attention.
This is true even those small portions of telecom relevant protocols
that ended up in the kernel like SCTP or more recently the GTP module I
co-authored. They are getting too little attention in development, even
more lack of attention in maintenance, and people seem to focus more on
not using it, rather than fixing and maintaining what is there.</p>
<p>It makes me really sad to see this. Telecoms is such a massive
industry, with billions upon billions of revenue for the classic telecom
equipment vendors. Surely, they would be able to co-invest in some
basic infrastructure like proper and reliable testing / continuous
integration for SCTP. More recently, we see millions and more millions
of VC cash burned by buzzword-flinging companies doing "NFV" and
"SDN". But then rather reimplement network stacks in userspace than to
fix, complete and test those little telecom infrastructure components
which we have so far, like the SCTP protocol :(</p>
<p>Where are the contributions to open source telecom parts from Ericsson,
Nokia (former NSN), Huawei and the like? I'm not even dreaming about
the actual applications / network elements, but merely the maintenance
of something as basic as SCTP. To be fair, Motorola was involved early
on in the Linux SCTP code, and Huawei contributed a long series of fixes
in 2013/2014. But that's not the kind of long-term maintenance
contribution that one would normally expect from the primary interest
group in SCTP.</p>
<p>Finally, let me thank to the Linux SCTP maintainers. I'm not
complaining about them! They're doing a great job, given the arcane code
base and the fact that they are not working for a company that has
SCTP based products as their core business. I'm sure the would love
more support and contributions from the Telecom world, too.</p>
</div>SIGTRAN/SS7 stack in libosmo-sigtran merged to masterhttps://laforge.gnumonks.org/blog/20170410-libosmo-sigtran/2017-04-10T00:00:00+02:002017-04-10T00:00:00+02:00Harald Welte<p>As I blogged in <a class="reference external" href="https://laforge.gnumonks.org/blog/20170212-libosmo_sigtran/">my blog post in Fabruary</a>, I was working towards a more
fully-featured SIGTRAN stack in the Osmocom (C-language) universe.</p>
<p>The trigger for this is the support of 3GPP compliant AoIP (with a
BSSAP/SCCP/M3UA/SCTP protocol stacking), but it is of much more general
nature.</p>
<p>The code has finally matured in my development branch(es) and is now
ready for mainline inclusion. It's a series of <a class="reference external" href="https://gerrit.osmocom.org/#/q/project:libosmo-sccp+branch:master+topic:sigtran">about 77 (!) patches</a>,
some of which already are the squashed results of many more incremental
development steps.</p>
<p>The result is as follows:</p>
<ul class="simple">
<li><p>General SS7 core functions maintaining links, linksets and routes</p></li>
<li><p>xUA functionality for the various User Adaptations (currently <a class="reference external" href="https://www.ietf.org/rfc/rfc3868.txt">SUA</a> and <a class="reference external" href="https://tools.ietf.org/html/rfc4666">M3UA</a> supported)</p>
<ul>
<li><p>MTP User SAP according to <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.701-199303-I!!PDF-E&type=items">ITU-T Q.701</a> (using osmo_prim)</p></li>
<li><p>management of application servers (AS)</p></li>
<li><p>management of application server processes (ASP)</p></li>
<li><p>ASP-SM and ASP-TM state machine for ASP, AS-State Machine (using osmo_fsm)</p></li>
<li><p>server (SG) and client (ASP) side implementation</p></li>
<li><p>validated against ETSI TS 102 381 (by means of Michael Tuexen's <a class="reference external" href="https://github.com/nplab/m3ua-testtool">m3ua-testtool</a>)</p></li>
<li><p>support for dynamic registration via RKM (routing key management)</p></li>
<li><p><code class="docutils literal"><span class="pre">osmo-stp</span></code> binary that can be used as Signal Transfer Point, with
the usual "Cisco-style" command-line interface that all Osmocom
telecom software has.</p></li>
</ul>
</li>
<li><p>SCCP implementation, with strong focus on Connection Oriented SCCP (as
that's what the A interface uses).</p>
<ul>
<li><p>osmo_fsm based state machine for SCCP connection, both incoming and
outgoing</p></li>
<li><p>SCCP User SAP according to <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.711-200103-I!!PDF-E&type=items">ITU-T Q.711</a> (osmo_prim based)</p></li>
<li><p>Interfaces with underlying SS7 stack via MTP User SAP (osmo_prim based)</p></li>
<li><p>Support for SCCP Class 0 (unit data) and Class 2 (connection oriented)</p></li>
<li><p>All SCCP + SUA Address formats (Global Title, SSN, PC, IPv4 Address)</p></li>
<li><p>SCCP and SUA share one implementation, where SCCP messages are
transcoded into SUA before processing, and re-encoded into SCCP after
processing, as needed.</p></li>
</ul>
</li>
</ul>
<p>I have already done experimental <a class="reference external" href="http://osmocom.org/projects/osmomsc/wiki">OsmoMSC</a> and <a class="reference external" href="http://osmocom.org/projects/osmohnbgw/wiki">OsmoHNB-GW</a> over to libosmo-sigtran.
They're now all just M3UA clients (ASPs) which connect to <code class="docutils literal"><span class="pre">osmo-stp</span></code>
to exchange SCCP messages back and for the between them.</p>
<p>What's next on the agenda is to</p>
<ul class="simple">
<li><p>finish my incomplete hacks to introduce IPA/SCCPlite as an alternative
to SUA and M3UA (for backwards compatibility)</p></li>
<li><p>port over OsmoBSC to the SCCP User SAP of libosmo-sigtran</p>
<ul>
<li><p>validate with SSCPlite lower layer against existing SCCPlite MSCs</p></li>
</ul>
</li>
<li><p>implement BSSAP / A-interface procedures in OsmoMSC, on top of the
SCCP-User SAP.</p></li>
</ul>
<p>If those steps are complete, we will have a single OsmoMSC that can talk
both IuCS to the HNB-GW (or RNCs) for 3G/3.5G as well as AoIP towards
OsmoBSC. We will then have fully SIGTRAN-enabled the full Osmocom
stack, and are all on track to bury the OsmoNITB that was devoid of such
interfaces.</p>
<p>If any reader is interested in interoperability testing with other
implementations, either on M3UA or on SCCP or even on A or Iu interface
level, please contact me by e-mail.</p>Towards a real SIGTRAN/SS7 stack in libosmo-sigtranhttps://laforge.gnumonks.org/blog/20170212-libosmo_sigtran/2017-02-13T00:00:00+01:002017-02-13T00:00:00+01:00Harald Welte<p>In the good old days ever since the late 1980ies - and a surprising
amount even still today - telecom signaling traffic is still carried
over circuit-switched SS7 with its TDM lines as physical layer, and not
an IP/Ethernet based transport.</p>
<p>When Holger first created OsmoBSC, the BSC-only version of OpenBSC some
7-8 years ago, he needed to implement a minimal subset of SCCP wrapped
in TCP called <em>SCCP Lite</em>. This was due to the simple fact that the MSC
to which it should operate implemented this non-standard protocol
stacking that was developed + deployed before the IETF SIGTRAN WG
specified M3UA or SUA came around. But even after those were specified
in 2004, the 3GPP didn't specify how to carry A over IP in a standard
way until the end of 2008, when a first <a class="reference external" href="http://www.etsi.org/deliver/etsi_tr/143900_143999/143903/08.03.00_60/tr_143903v080300p.pdf">A interface over IP study</a>
was released.</p>
<p>As time passese, more modern MSCs of course still implement classic
circuit-switched SS7, but appear to have dropped SCCPlite in favor of
real AoIP as specified by 3GPP meanwhile. So it's time to add this to
the osmocom universe and OsmoBSC.</p>
<p>A couple of years ago (2010-2013) implemented both classic SS7
(MTP2/MTP3/SCCP) as well as SIGTRAN stackings (M2PA/M2UA/M3UA/SUA in
Erlang. The result has been used in some production deployments, but
only with a relatively limited feature set. Unfortunately, this code
has nto received any contributions in the time since, and I have to say
that as an open source community project, it has failed. Also, while
Erlang might be fine for core network equipment, running it on a BSC
really is overkill. Keep in miond that we often run OpenBSC on
really small ARM926EJS based embedded systems, much more resource
constrained than any single smartphone during the late decade.</p>
<p>In the meantime (2015/2016) we also implemented some minimal SUA support
for interfacing with UMTS femto/small cells via Iuh (see <a class="reference external" href="https://osmocom.org/projects/osmohnbgw/wiki">OsmoHNBGW</a>).</p>
<p>So in order to proceed to implement the required
SCCP-over-M3UA-over-SCTP stacking, I originally thought well, take
Holgers old SCCP code, remove it from the IPA multiplex below, stack it
on top of a new M3UA codebase that is copied partially from SUA.</p>
<p>However, this falls short of the goals in several ways:</p>
<ul class="simple">
<li><p>The application shouldn't care whether it runs on top of SUA or SCCP,
it should use a unified interface towards the SCCP Provider.
OsmoHNBGW and the SUA code already introduce such an interface baed on
the SCCP-User-SAP implemented using <a class="reference external" href="http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__prim.html">Osmocom primitives (osmo_prim)</a>.
However, the old OsmoBSC/SCCPlite code doesn't have such abstraction.</p></li>
<li><p>The code should be modular and reusable for other SIGTRAN stackings
as required in the future</p></li>
</ul>
<p>So I found myself sketching out what needs to be done and I ended up
pretty much with a re-implementation of large parts. Not quite fun, but
definitely worth it.</p>
<p>The strategy is:</p>
<ul class="simple">
<li><p>Implement the SCCP SCOC state machines for connection-oriented SCCP
(of which Iu and A interface are probably the only users) using
<a class="reference external" href="http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__fsm.html">Osmcoom Finite State Machines (osmo_fsm)</a>.</p></li>
<li><p>Migrate the existing SUA code on top of that, maintaining the existing
osmo_prim based <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/tree/include/osmocom/sigtran/sccp_sap.h">SCCP User SAP</a></p></li>
<li><p>Implement <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=dc923e49cd3b623dab05f6016a3e935d7c652cb3">SCCP to SUA and vice-versa message transcoding</a>
to makes sure the bulk of the code has to deal only with one message
format (parsed SUA).</p></li>
<li><p>Introduce a <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=21c8a1bcc8f853f3da05d71c4b4fbea6faf53b24">MTP SAP</a>
at the lower boundary of the SCCP code</p></li>
<li><p>Implement <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=50e931338dfa1ad570734b80cce065ab611929aa">xUA ASP and AS statemachines using osmo_fsm</a>
and add ASPTM/ASPSM support to SUA (was missing so far) * Implement</p></li>
<li><p>Implement M3UA using the xUA ASP and AS FSMs as well as the general
<a class="reference external" href="http://git.osmocom.org/libosmo-sccp/tree/src/xua_msg.c">xUA message encoder/decoder</a>,
offering the MTP SAP toward SCCP</p></li>
</ul>
<p>And then finally stack all those bits on top of each other, rendering a
fairly clean and modern implementation that can be used with the IuCS of
the virtually unmodified OsmmoHNBGW, OsmoCSCN and OsmoSGSN for testing.</p>
<p>Next steps in the direction of the AoIP are:</p>
<ul class="simple">
<li><p>Implementation of the MTP-SAP based on the IPA transport</p></li>
<li><p>Binding the new SCCP code on top of that</p></li>
<li><p>Converting OsmoBSC code base to use the SCCP-User-SAP for its
signaling connection</p></li>
</ul>
<p>From that point onwards, OsmoBSC doesn't care anymore whether it
transports the BSSAP/BSSMAP messages of the A interface over
SCCP/IPA/TCP/IP (SCCPlite) SCCP/M3UA/SCTP/IP (3GPP AoIP), or even
something like SUA/SCTP/IP.</p>
<p>However, the 3GPP AoIP specs (unlike SCCPlite) actually modify the
BSSAP/BSSMAP payload. Rather than using Circuit Identifier Codes and
then mapping the CICs to UDP ports based on some secret conventions,
they actually encapsulate the IP address and UDP port information for
the RTP streams. This is of course the cleaner and more flexible
approach, but it means we'll have to do some further changes inside the
actual BSC code to accommodate this.</p>