Migrating a Legacy Application to OpenSAF Experience and Findings Using OpenSAF Ana Sanz Merino SAPC System Architect Ericsson

Agenda SAPC Overview SAPC to openSAF Drivers SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

Ericsson’s Service Aware Policy Controller Convergent Policy and Charging Control in Fixed and Mobile Access Networks SERVICES / BACK OFFICE M-TV Server IMS Domain External DB Self-Service Web Portal Rx Mobile access network presence 60 Contracts 150M Subscribers Fixed access network presence 110 Contracts 120M Subscribers LDAP SQL SOAP LDAP SOAP SAPC CENTRALIZED POLICY CONTROL Gx Gx Gy Rx RADIUS CoA Access GGSN DPI TRANSPORT LEVEL Non- Accesses BRAS DPI

SAPC on Proprietary Platform Advantages Platform provides everything O&M support SW management & availability Data storage Process model Inter-application environment communication mechanism Disadvantages No HW flexibility Not easy 3PP integration Feature lead time constraints SAPC Java SAPC C++ Middleware O.S. HW TSP

SAPC on OpenSAF Advantages Challenges Different HW alternatives Standard technologies & alignment on middleware layer Possible to reuse software Easy 3PP integration Open interfaces Broader developer community Challenges Need to adapt application to the new interfaces openSAF services’ characteristics might be different from the equivalent legacy platform service Not all legacy platform services supported by openSAF: add components to cover the difference SAPC Java SAPC C++ Java EE AS Middleware O.S. Ericsson HW COTS

OpenSAF 4.0 Services Used by SAPC

Agenda SAPC Overview SAPC to openSAF Drivers SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

SAPC Experience w/ IMM Service openSAF IMM Frequent reads from every payload node Infrequent writes In-memory storage Optimized for read access Not high throughput writes Small number of objects Limited volume of data Required redundancy, but not persistency Data redundancy Optional persistent back-end Access synchronization IMM is good for SAPC configuration data

Node Management System SAPC & IMM Object Manager API (OM-API) Create, access, and manage configuration objects/attributes Node Management System Adaption provided towards OAM interfaces OAM Java Logic C++ Logic SAPC Java IMM Conf Data Adapters SAPC C++ CM IMM Conf Data Adapters Access to configuration data during traffic processing Java EE AS Java Adaptation OM-API (create) OM-API (access) OM-API (access) Adaptation provided to access from Java openSAF IMM Config Data

IMM Conf Data Validator SAPC & IMM Object Implementer API (OI-API) To deliver the operations requested by Object Managers to the appropriate Services or applications that implement these objects At object creation, IMM Service invokes any existing Object Implementer synchronously to validate the creation request WrongObjectX Conf Data ERROR OAM 1 4 SAPC C++ CM IMM Conf Data Validator OM-API (create) OI-API (validate) 2 3 Useful for validations or configuration data openSAF IMM Conf Data

Agenda SAPC Overview SAPC to openSAF Drivers SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

SAPC Experience w/ AMF Service Different redundancy models to adapt to application needs Just a few simple ones used 2N for redundancy N-way active for load balancing SCN 1 SCN 2 PL 1 PL 2 ImmValidatorSG: 2N TrafficLogicSG: N-way active ImmValidatorSU ImmValidatorSU TrafficLogicSU TrafficLogicSU IMM VALIDATOR IMM VALIDATOR TRAFFIC LOGIC TRAFFIC LOGIC active standby active active AMF provides simple, flexible and robust high availability support to SAPC

Agenda SAPC Overview SAPC to openSAF Drivers SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

SAPC Experience w/ CKPT Service openSAF CKPT Frequent reads and writes from every payload node Required redundancy, but not persistency In memory storage No persistent storage Local reads/writes depend on checkpoint type Data redundancy Expiration on inactivity Retention and expiration time Number of sessions in the order of millions Limit of 1000 replicas per node CKPT is a good to store session data Good performance while guaranteeing redundancy Automatic session clean-up

Collocated Checkpoint for SAPC Session Session Establishment Session Modification 1 2 SC 1 SC 2 PL 1 PL 2 SAPC Java SAPC C++ SAPC C++ SAPC Java Java EE AS Java EE AS 1 2 CPSv CPSv CPSv CPSv Session X Session X openSAF openSAF openSAF openSAF With SAPC N-way active AMF model, collocated checkpoint redundancy not guaranteed

Non-Collocated Checkpoint for SAPC Session Session Establishment Session Modification 1 2 SCN 1 SCN 2 PL 1 PL 1 SAPC C++ SAPC Java SAPC C++ SAPC Java Java EE AS Java EE AS 1 2 CPSv CPSv CPSv CPSv Session X Session X Session X 1 2 openSAF openSAF openSAF openSAF Thanks to the different CKPT types, CKPT redundancy can be guaranteed for SAPC: use non-collocated checkpoint Local read/writes with non-collocated CKPT can be guaranteed with distribution algorithm of requests so that same session always handled in same PL blade

SAPC Session Model in CKPT CKPT_ID: SAPCSession#<Session Container ID> Multiple sessions per checkpoint Each session data in a section SECTION_ID: <Session ID> {"sessionData":<JSON string with all session attributes>} CKPT limit in number of objects not a problem

Agenda SAPC Overview SAPC to openSAF Drivers SAPC integration to openSAF IMM Service AMF Service CKPT Service Conclusions

SAPC Conclusions on OpenSAF Services IMM is good for SAPC configuration data CKPT is good to store session data AMF provides simple high availability support for SAPC OpenSAF services SW quite robust

OpenSAF advantages for SAPC SAPC General Conclusions on OpenSAF More standard and open interfaces Broader developer community Possible to reuse software Easy 3PP integration Reuse ideas from open source community OAM and Java Adaptation modules reused from other products OpenSAF advantages for SAPC Software-Hardware decoupling Same SW deployed in different HW Ericsson Blade System and COTS (SUN Blades)