Logate is not only a vendor but we offer professional services as well. Very often AAA system should be replaced and integrated within current environment. Also, very often current Telecom environment is not in line with the latest recommended standard especially if Telecom has legacy system created a decade ago. So, if Telecom wants to swap AAA system it is not possible to adapt the entire ecosystem according to AAA but vice verse. It is necessary to place AAA system and integrate it with a lot of external systems that may be completely different from client to client. That’s why it is important not only to deliver the platform but also to support the client in the migration process from old system to the new one.
The migration process from old (legacy) system to OpenProvider consist of the following phases:
1. Workshops
This is the first phase of project where Logate team learns about current services that Telecom offers to end users, integration points, and any specification that old AAA has. Also we explain OpenProvider architecture, define flavors for each VNFC, number of nodes, define networks and vlans. The result of the workshop phase is created high level design (HLD) document.
2. Platform building phase
In this phase Logate prepares VNFM (VNF Manager) which assumes puppet modules for all services on each OpenProvider node and one manifest for complete OpenProvider platform. Also, Logate creates rpm repository which is also placed on VNFM node. Thus, VNFM will install and configure all services and files necessary for the platform. Part of the installation process is creation of database keyspace (one or more) and initial keyspace population with default data. The result of this phase is fully up and running OpenProvider platform ready for integration with other components and creation of policing logic.
3. Integration phase
OpenProvider will be integrated with multiple components within the Telecom network. Below is the description of integration points for each node of OpenProvider system.
VNFM
VNFM will be integrated with the backup system, QA and SIEM (if exist) using TCP 22 within client network. The rest of communication VNFM works with other OpenProvider components using management interface and port 8140 (TCP port).
Policing nodes have to be integrated with the following external client systems:
- EPG node – new Radius client should be configured on EPG side with Policing node IP addresses. EPG should have all Policing nodes IP addresses from each Data Center. Failed Policing AAA node detection is done on EPG side, as EPG will keep list of Live and Dead RADIUS servers. Our recommendation is to choose multipleServer retry method with load balancing option. The main function of the multiple server retry method is to make RADIUS retries to different servers. When load balancing is enabled, the RADIUS requests are evenly distributed between the available servers. The best performance is achieved when load balancing is used in combination with the multiple servers retry method. A server that cannot be contacted and consequently triggers serverdownTimeout is not included in load balancing until serverdownTimeout Policing nodes can be defined into Radius groups in a way to force inner DC communication between EPG and Policing nodes primary and cross DC communication between EPG and Policing nodes in a case when primary group is down. Usually, we used UDP ports 1812/1813 for authorization and accounting ports. Also, if it supported on EPG side, we can configure CoA and PoD packet where Policing node is a source of request with 1700 UDP port.
- BRAS/iWAG node – new Radius client should be configured on BRAS/iWAG side with Policing node IP addresses. BRAS/iWAG should have all Policing nodes IP addresses from each Data Center. Policing nodes can be defined into Radius groups in a way to force inner DC communication between BRAS/iWAG and Policing nodes primary and cross DC communication between BRAS/iWAG and Policing nodes in a case when primary group is down. Usually, we used UDP ports 1812/1813 for authorization and accounting ports. Also, if it supported on BRAS/iWAG side, we can configure CoA and PoD packet where Policing node is a source of request with 1700 UDP port.
- HSS, PGW, ePDG, DRA – Policing nodes can be integrated with various Diameter interfaces for PCRF and VoWiFi functionalities. Policing node support TCP/SCTP 3868.
- LDAP nodes – Subscriber, profile and credit informations should be retrieved using LDAP protocol from central SPR (Subscriber and Profile Repository). During packet processing, Policing nodes have to get all informations about subscriber and integration with external or internal LDAP nodes is necessary (TCP 389).
- External Database systems – Sometimes Telecom does not have SPR but Policing nodes have to be integrated with external databases directly. In that case, Logate prepare queries for Oracle or any other database that keep subscriber, profile and credit informations.
- NMS systems – Each Policing node will be integrated with Monitoring system using standard snmp port for traps (UDP 161 port) and standard port for snmpget and snmpwalk commands (UDP 162 port).
- Rsyslog – Each Policing node will be integrated with Central Rsyslog system with Telecom using standard rsyslog port (UDP 514 port).
- SIEM – Integration will be done with SIEM in Telecom network (TCP 22 port)
- QA – Integration will be done with QA in Telecom network (TCP 22 port)
- Kafka – Policing nodes very often keep records from original incoming authorization and accounting request. Also policing nodes store original reply information, both accept and reject messages. All those records can be sent from Policing nodes to centralized Kafka system (TCP port 9092)
- Backup system – integration with backup system using
Beside Telecom external systems, Policing nodes will be integrated with SSDB nodes. Each policing node will have 3 IP addresses of SSDB nodes in local DC. There is no cross-DC communication between Policing nodes and SSDB nodes.
Also Policing nodes will communicate with APPS nodes for internal actions like clear session of send CoA/PoD messages.
LDAP nodes have to be integrated with following external Telecom systems:
- NMS systems – Each LDAP node will be integrated with Monitoring system using standard snmp port for traps (UDP 161 port) and standard port for snmpget and snmpwalk commands (UDP 162 port).
- Rsyslog – Each LDAP node will be integrated with Central Rsyslog system within Telecom using standard rsyslog port (UDP 514 port).
Beside Telecom external systems, LDAP nodes will be integrated with SSDB nodes. Each LDAP node will have 3 IP addresses of SSDB nodes in local DC. There is no cross-DC communication between LDAP nodes and SSDB nodes.
As stated before, LDAP nodes will be integrated with Policing nodes.
SSDB nodes have to be integrated with following external Telecom systems:
- NMS systems – Each SSDB node will be integrated with Monitoring system using standard snmp port for traps (UDP 161 port) and standard port for snmpget and snmpwalk commands (UDP 162 port).
- Rsyslog – Each SSDB node will be integrated with Central Rsyslog system with Telecom using standard rsyslog port (UDP 514 port).
- SIEM – Integration will be done with SIEM in Telecom network (TCP 22 port)
- QA – Integration will be done with QA in Telecom network (TCP 22 port)
- Backup system – integration with backup system using
Beside Telecom external systems, SSDB nodes have to communicate among themselves in order to sync data and to keep cluster status.
As a central stateful component from complete OpenProvider project, SSDB nodes will be integrated with all stateless components: Policing, LDAP and APPS nodes.
APPS nodes nodes have to be integrated with following external Telecom systems:
- NMS systems – Each APPS node will be integrated with Monitoring system using standard snmp port for traps (UDP 161 port) and standard port for snmpget and snmpwalk commands (UDP 162 port).
- Rsyslog – Each APPS node will be integrated with Central Rsyslog system with Telecom using standard rsyslog port (UDP 514 port).
- SIEM – Integration will be done with SIEM in Telecom network (TCP 22)
- QA – Integration will be done with QA in Telecom network (TCP 22)
- Backup system – Integration with backup system using
- Provisioning system – APPS nodes are integrated with provisioning systems, especially when we install and integrate SPR module. Integration is done using REST and HTTPS protocol.
- IT applications and clients’ applications – APPS nodes are interface for all informations that OpenProvider poses using REST for all external IT and clients systems and applications.
- External active directory – Integration with external active directory for web interface login using LDAP protocol (TCP 389)
Beside Telecom external systems, APPS nodes have to communicate with Policing nodes for internal actions like clear session of send CoA/PoD messages.
Overall picture of integrations
Figure below shows each OP component communication with external systems and within OP.
Communication between OpenProvider components is shown below:
4. Policy Logic creation phase
In this phase Logate team creates policy logic which has to support all services that Telecom offers. All policies are created using powerful SME and OpenFuncions where complete level of customisation is possible. Read more about SME and the power of OpenFucntions in this blog post.
5. User Training
Comprehensive training programs are provided to users to ensure they are comfortable with the new system. This includes explanation of each component, policy logic, reporting, and using advanced features.
6. User Accept Tests
In this phase Logate and client will check all service, security and system parts of the platform. Also UAT should cover tests of local and geo redundancy. We have to agree that each test is passed as expected. UAT is over in the moment when each test is passed correctly. Also, any change in logic during UAT phase requires that the entire set of tests is done again.
7. Data migration
Before production it is necessary to migrate all data from old system to the new one. Usually it is an action which has to be done just before migration.
8. Production
Traffic migration from old system to the new one is done in several phases. Pilot phase is the first one where some percentage of customers is migrated and that both Logate and Telecom monitor one week of traffic and services. After that, gradually, number of subscribers and NAS servers is increased in defined pace. Usually, in one month, complete migration process is done.
