Friday, November 3, 2017

Radiator Load Balancer

As a part of our Radiator VNF products, we have recently developed a Radiator Load Balancer for RADIUS and Diameter interfaces. With our own load balancer, Radiator VNF is able to scale workload more efficiently and without need for external load balancer products – which provides a cost-effective solution for all our AAA customers.

Technical overview and key features

To put it short: Radiator Load Balancer’s main function is to distribute the incoming load to the worker components of VNF. It is the primary entry point for the incoming RADIUS and Diameter messages, for which we have independent load balancers.

Loab balancers in Radiator VNF architecture


Our Diameter load balancer supports multicore processor architecture that makes it very effective to use. The load balancer can utilise multiple threads for processing the incoming requests concurrently. The worker thread count is configurable for the best possible performance.

Diameter load balancer has an extensive support for logging. By default, it can produce JSON and plain text log files. The JSON logs can be further integrated to Elasticsearch or other log collecting systems. These systems provide possibilities to create graphical presentations of the system data – both performance counters and log files.

Loadbalancer is very flexible, you can configure several different features, such as routing, initiator support, responder support, TCP and SCTP support, timeout, logging, and many, many more.

You can redirect the messages with Diameter Loadbalancer and use dynamic routing tables. For example, from VNF point of view, HSS can specify which server handles particular traffic. The worker then instructs the load balancer to forward traffic to the indicated server, and the load balancer modifies its dynamic routing tables to perform the forwarding. In addition, to avoid redirect loops, Radiator Loadbalancer has a detector that recognises and prevents them.

The routing decisions are based on matching the dynamic routing table against the Diameter AVPs:
– realm
– application-id
– user-id
– session-id
– hostname

Loadbalancer has a comprehensive support for failover. It prefers the active peers by default and retransmits the messages to alternative peers if one peer does not respond.

Interested to know more about Radiator Load Balancer?

If you are interested to know more about Radiator Load Balancer and Radiator VNF in general, you can contact our sales and support team at info@open.com.au . We are happy to provide more detailed information for your infrastructure.

Thursday, August 17, 2017

Going Cloud-Native with Radiator VNF

Cloud-native packet core architecture

Nowadays, many telcos target their packet core architecture at a cloud-native implementation, which is deployed in their own virtual infrastructure environment. In this environment, all different network functions, such as AAA, are virtualised.

This infrastructure supports all services (data, voice, IoT, and so on) and all wireless access technologies including WiFi, LTE, and 5G. Also the data plane and control plane are fully separated. They are likely to follow different deployment models, such as centralised control plane and session management or distributed data plane.

Radiator - cloud-native AAA solution

Radiator VNF is an ideal solution for this kind of approach and migration to cloud-native infrastructure. Radiator VNF components and virtual hosts are configured automatically through a centralised configuration system. In addition to this, all VNF components interact using the redundant message queue. Cloud-native approach is also seen in load balancers, that ensure that you always have the right amount of AAA capacity in your cloud-native network.

radiator-vnf-architecture.png

Radiator VNF is cloud-native from architecture point of view as well

Two ways: cloud-native from the start or step-by-step approach

For transition to Radiator VNF for your AAA solution, you can run it on your cloud-native infrastructure, such as Openstack. The other alternative is that you run Radiator VNF with a static configuration on VMs. In that case, you can have all the components, such as load balancers, developed for Radiator VNF, but options in scaling and automatic configuration are more limited. They emerge when your infrastructure is transformed to be cloud-native. Our licensing options and Radiator deployments support both approaches.

If you want to get more information, please see Radiator VNF technical documentation, or contact our team at info@open.com.au

Tuesday, July 25, 2017

Recent logging and management updates in Radiator

In recent Radiator releases 4.18 and 4.19 we have implemented numerous logging and management updates. These enhancements provide more tools for diagnostics and management of your network and possible authentication issues. In Radiator release 4.19, the enhancements include:
  • Unfinished EAP authentications are now logged and available for AuthLog logging
  • Ignored authentications are now available for AuthLog logging
Also, in release 4.18 we have added support for new type of clause "AcctLog xxxxx". With this enhancement, it is easier to configurate the handling of accounting messages than before. An AcctLog clause logs RADIUS accounting requests to a file, Windows Event Log, SQL or syslog. An AcctLog is configured similar to AuthLog: you configure one more AcctLog clauses for a Handler or Realm. Currently supported AcctLog clauses are: 
  • AcctLog EVENTLOG 
  • AcctLog FILE
  • AcctLog SQL
  • AcctLogSYSLOG. 
In Radiator documentation, you can see logformat.cfg and sql.cfg for configuration samples. All enhancements in releases 4.18 and 4.19 can be found from Radiator product history.

Would you like to know more?

If you would like to know more how these enhancements and Radiator in general can help you with your authentication, accounting and logging needs, please do not hesitate to contact our team at info@open.com.au

Wednesday, June 7, 2017

Radiator VNF – meeting the standards

Radiator – interoperability in NFV world

Radiator is known for its interoperability and flexibility and from the very beginning, Radiator VNF is meant to be similar. In order to make it so, we have built Radiator VNF to meet the industry standards, such as NFV release 1 by the European Telecommunications Standards Institute (ETSI). Radiator VNF follows the ETSI standard architecture as shown below.

Radiator VNF architecture

Of course, meeting the NFV release 1 standard is not enough for us. There are new releases coming, such as ETSI NFV release 2 published in autumn 2016. Our development team has been working to make Radiator VNF to meet this standard and the development goes on. The NFV release 2 added several new specifications to the previous release: various requirements and instructions for resilience, service quality metrics, management, orchestration, security, and many, many more.

Meeting these standards and constant development means that Radiator VNF customers can trust their solution to be interoperable now and in the future. This helps both our integrator partners and customers in their mission to have the best components for different needs in their infrastructure.

Meeting standards – more benefits for markets

When the vendors ensure that their software follows the NFV standards, the market will run better, too. The customers, such as telcos, can choose the components from the wide range of products without a fear for a vendor lock-in. This makes the NFV markets to mature more rapidly. Additionally, the technology itself matures and can deliver the promised benefits. More information about this is available in the industry report by SDx Central.

We in Radiator team are committed to deliver the NFV promise and Radiator’s well-known interoperability in the new Radiator VNF. Contact our sales team at info@open.com.au to get more information about our Radiator VNF solution.

Friday, May 12, 2017

Radiator 4.18 now available!

We have published the updated version of Radiator, please meet brand new Radiator 4.18!

There are lots of enhancements and bugfixes in Radiator 4.18. Some are small, some bigger but nothing really major. The main improvements include:
  • Several security fixes
  • Enhanced logging and debugging features
  • New modules for accounting handling
  • Automatic rejection of empty passwords and some types of invalid user names
  • AuthenProto parameter for setting the allowed authentication methods
  • Several EAP enhancements

The detailed list of changes is available on Radiator revision history.

Thursday, May 4, 2017

Radiator SIM Pack updated - version 2.1 available!

We are happy to announce that new Radiator SIM Pack version 2.1 is now available!

This is mainly an enhancement and bugfix release with some minor new features. We have fixed several small issues and improved all SIM authentication methods, 3GPP AAA Server and SIGTRAN interoperability and compatibility with different vendors’ devices. Many of these improvements are based on customer requests for new features and enhancements. In addition to new interoperability features, SIGTRAN support was updated with a number of configuration options that are useful for making sure Radiator fits your existing SIGTRAN environment.

Radiator SIM Pack 2.1 requires Radiator AAA Server version 4.16 or later. Some features, such as using 3GPP AAA Server and LocalAddress or LocalPort parameters, require Radiator 4.17 or later. The complete list of changes is available on the revision history page.

Friday, April 7, 2017

Radiator VNF 2017 release components

Radiator VNF consist of independent components. The modular architecture enables the Radiator VNF system to be flexible, scalable, and configurable. The basic components are:

  • Worker
  • Loadbalancer
  • Control
  • Management
  • BEDBINT (Backend Database Interface)

The image below shows their relations:

Worker

As the name indicates, the worker component does all the work: it processes the incoming RADIUS and Diameter messages. It provides the actual business logic and its functions, such as:

  • Radiator VoWiFi
  • Radiator Service Provider Wi-Fi
  • Radiator PCRF
  • Radiator OCS
  • Radiator Custom/OEM

Radiator AAA Core is the mandatory main module. It depends on the wanted functionality which other modules are necessary.

When workers are instantiated, they send their availability information to the loadbalancer through redundant message queue. Workers do not communicate directly with the external clients.

Loadbalancer

Loadbalancer receives the incoming RADIUS and Diameter messages and forwards them to the workers. It also takes care of balancing the workers' load, the control component sends the workers' availability information to loadbalancer so that loadbalancer always has an up-to-date list of available workers. Loadbalancer is stateless from RADIUS and Diameter perspective

Control

Control component's most important task is to provide the redundant message queue, which all other components use for communicating with each other. Inter-component communicating is extremely important in Radiator VNF, for example, scaling the system would be impossible without it. The workers sign up to the control component when they are initialised and the control component sends worker information to the loadbalancer. Also component shutdowns are informed to the control component.

The control component acts also as a data storage, it stores non-persistent session data and persistent data, such as IP addresses, prefixes, and pools. The control component is not stateless. The control component also maintains real-time user session data and provides that data to the workers and management component. The persistent data is stored in ACID-compliant storage.

Management

The management component holds the statistics and logging data. It also provides services which handle session cleaning and other management tasks, such as logs and statistics.

BEDBINT

BEDBINT connects Radiator VNF to the external backend systems. Depending on the configuration, these backend systems can be one of the following:

  • Customer LDAP (Lightweight Directory Access Protocol)
  • SQL
  • HSS (Home Subscriber Server)

BEDBINT includes a caching function that stores customer and configuration information. It also supports the overload protection mechanisms, scaling, and self-healing.

Do you want to know more?

Radiator VNF release 2017 will be commercially available soon. In case you are interested in Radiator VNF solutions, please contact info@open.com.au. We are happy to tell you more about Radiator VNF, and assist you with your NFV and AAA project with Radiator solutions.