The Republic of Moldova is a country in Southeast Europe. Area — 33 846 km². Population — over 3,550,900 people. The capital is Chisinau. The country borders Ukraine and Romania. According to official statistics, the number of Internet users in Moldova is about 569 thousand, whereas the fiber optic connection amounted to more than 60% of the total Internet connections in Moldova in 2018.
StarNet is an advanced telecommunications company in Moldova with a subscriber base of over 130 thousand users. The operator is one of the three largest providers of the Republic, being a “pioneer” in providing Internet access via fiber-optic cable to individuals, and has been operating on the market since 2003.
Internet access is provided using GPON, FTTB and Wi-Fi technologies. Most customers use a wired connection.
Prior to using the Stingray Service Gateway its network scheme could be simplified like this:
Simplified Starnet network scheme before the optimization
Prior to optimization, the network was built on several Ericsson SE1200s that performed BRAS functions and NAT when necessary. Due to unforeseen circumstances, about once every six months the equipment refused to work. Of course, there were attempts to troubleshoot and search for ways to resolve this problem, but no permanent solution was ever found. This was the first reason to search for new equipment.
The second reason was switching to IPv6. Ericsson SE1200 handles IPv6 for PPPoE sessions only. Transferring 130 thousand users to PPPoE is technically incorrect for a number of reasons:
- the carrier has already configured IPoE and the transition to PPPoE is quite nonsense;
- to change the network settings for a large number of clients will require a lot of time and labor. Under this approach customer churn is inevitable.
The third reason for optimization is a long network recovery after downtime. Owing to its features Ericsson SE600 is capable of processing about 300 per second attempts of creating sessions. As a result, it took more than 10 minutes to fully reconnect all customers.
So the combination of these three factors forced Starnet to replace equipment.
Searching for a solution
The idea of buying a new Ericsson was nipped to the bud — too expensive, and the previous experience completely repelled all desire.
As possible options Juniper MX, CISCO ASR and Stingray Service Gateway were considered. The criteria were as follows:
- fault tolerance;
- clarity of documentation;
- support and upgradeability;
- the ability to reserve equipment;
- Dual-stack (simultaneous support for IPv6 and IPv4) and bandwidth shaping.
“Firstly we considered CISCO ASR, but it had many shortcomings. For example, it was unable to control transmission speed proportionally when dealing with IPv4, IPv6 and Dual-Stack clients at the same time — ASR limits transmission rate disproportionally: when traffic policing was configured to 50 Mbps, in fact, we had 100 — 50 Mbps in case of IPv4 and 50 Mbps in case of IPv6,whereas workaround we have found stated that if we are to get 50 Mbps, then traffic policing configuration should be set to 25 Mbps. But this absolutely wasn’t covered in official documentation…
We had no idea how to process subscriber traffic effectively either using CPU or Line Card. When choosing the Line Card case we reduce the burden on CPU that, in theory, is preferred, but in case of network link failure all the clients have to be moved to another channel. If all the subscriber traffic is handled by the CPU, then all processing is carried out centrally. On the other hand, the Line Card provides for the possibility of scaling whereas the CPU option implies that sooner or later we will push to its limits and it will need to be upgraded. Also, if users are processed by the CPU, then it is impossible to use IPv6.
Options are limited. Those that are available on Line Card are not available on the processor and vice versa. When the PortChannel is used to deal with subscribers the only case available is to use CPU for traffic processing. When the subscribers are bind to a physical port, then the CPU is the only choice. As a result, I have the following thoughts: what if I need to move all the subscribers from Line Card to CPU processing or vice versa … too complicated, long, and expensive.” — Andrian Wisniewski, the StarNet lead system administrator, shares his thoughts about technical aspects of choosing the proper solution.
The Stingray SG is a multifunctional solution for the telecom market that combines DPI, BRAS, CG-NAT, DLP, DDoS protection and Lawful Interception in one product. It also allows you to collect statistics to evaluate the quality of experience (QoE) and conduct marketing campaigns. The core of the system is the traffic classifier developed exclusively by VAS Experts programmers. The software solution is independent of the specific server hardware vendor and is compatible with any x86 server, and the throughput can reach 100 Gbit / s per 1 RU.
“In our opinion, the transition to software-based solutions is more profitable for the purposes of the upgrade, scaling, and redundancy. We observed this trend in the equipment market of almost all manufacturers: CISCO, Juniper, Nokia, Huawei, HP — almost all of them have software-based BRAS and they successfully promote it. Everything is simple — the processor load reaches critical — a new processor is installed in the neighboring socket and the problem is solved.
The cost of Stingray solution is lower than the new devices from Juniper or CISCO. Line Card and other service cards for well-known telecom equipment manufacturers increase eventual cost even more. Besides, licenses are tied to the number of customers and the amount of traffic”, – StarNet system administrator Andrian Wisnewski explains the choice of DPI-platform.
Testing, implementation and the results
Updated network scheme
The company acquired several licenses in two versions (DPI-60 and DPI-80) and installed them on the Huawei hardware platform. As a result, all Ericssons were replaced by routers, Stingray servers were installed based on the following principle: one unit per 1 public subnet and two units as NAT servers per 1 private one. In terms of topology, the network remained generally unchanged.
“We were surprised by the very fast deployment compared to Ericsson, which we set up on our own for a very long time with the help of various forums since there was no available documentation. And the final adjustment of Ericsson lasted for a year and a half.
The Stingray Service Gateway was implemented in three months. We signed an agreement at the end of October 2018. In November 2018, we received software for the test, and then a full license. We began to configure and startup of equipment. The full project implementation was completed by mid-December 2018.”
Like Ericsson, the Stingray SG interacts with a RADIUS server for authentication, authorization, and accounting purposes. For this purpose the RADIUS attributes are used but, unlike Ericsson, the RADIUS server <==> Stingray SG bundle works perfectly:
“… there were no difficulties with rewriting RADIUS attributes. On the contrary, it was surprising that the number of RADIUS procedures was reduced.
Comparative analysis: Ericsson required 3-4 RADIUS procedures and about 11 attributes; in order to set data transmission rate for the subscriber, the RADIUSDB sent to BRAS 8 RADIUS parameters: inbound and outbound Moldavian traffic transmission rate, the transmission rate of external inbound and outbound traffic along with rate and burst parameters. Apart from that, there were individual authentication procedures, individual authorization procedures, and individual accounting procedures.
The Stingray platform, instead, required 2 procedures in one along with 5 attributes: accept, transmission rate and services need to be activated”
StarNet is going to expand the network in 2019, whereas the positive results of the Stingray SG implementation and modernization in 2018 leave no doubt that the DPI, BRAS, and CG-NAT manufacturer replacement is not needed. The platform not only meets all the requirements for productivity and ease of use but also makes it possible to implement many more additional features to improve services quality and QoE.