Mohamed BOUCADAIR France Telecom R&D Cardiff, 17/09/2008

1. Enhancing the Serviceability and the Availability of IMS-Based Multimedia Services: Avoiding Core Service Failures Mohamed BOUCADAIR France Telecom R&D Cardiff, 17/09/2008

2. Agenda • Context • Challenges • Potentials of P2P and autonomic techniques • Focus on Robustness and Availability • Proposals to avoid core segment failures

3. Context • PSTN renewal is a fact • IMS and TISPAN have been adopted as the main architectures for the deployment of conversational services • These architectures are centralized and suffer from several hurdles related to robustness and availability • Current deployments assume a vertical model: both service and transport layers are managed by the same administrative entity… • In the meantime, autonomic solutions and P2P-based alternatives have been promoted • These techniques present numerous potentials…that can be exploited by telcos

4. Potentials of P2P and Autonomic techniques: Examples • Allow dynamic and autonomous behaviours instead of "static/frozen" one • Implement scalable service offerings through “intelligent” load distribution • Avoid DoS (Denial of Service) and SPAM attacks since the service logic is distributed among several nodes. The impact of a DoS attack may not be critical as for a centralised service platform • Enable fast re-route, dynamic failure detection and failure repair • Enhance service reliability • Reduce CAPEX and OPEX • Etc.

5. Challenges • Enhance current IMS-based service offerings • Exploit autonomic techniques in operational networks and propose viable scenarios of usage of these promising techniques • Focus on Robustness and availability • This paper presents only a part of a toolkit elaborated within the EURESCOM study: "P1755, P2PSIP Potentials in telecommunications" • The toolkit covers several areas such as access failures, core failures, avalanche restart, flash crowds, etc.

6. Enhancing Robustness of IMS-based architectures • The main objective is to propose a set of viable solutions aiming to enhance the robustness and the availability of current IMS-based architectures owing to the activation of autonomic techniques • A Service Provider's standpoint is adopted for the deployment of autonomic techniques • The adopted rationale argues in favor of introducing autonomic means into current operational service platforms in order to build survival and deterministic networks • autonomic means are not used as alternative solutions but as an enhancement to the already deployed ones • For backward compatibility and for migration issues, it is recommended to enforce the proposed solutions as backup ones in the earlier stages of deployment • Once field proven, the proposed mechanisms could be enforced as primary procedures to deliver more sophisticated services

7. Macroscopic view of IMS-based architectures • IMS-based architectures may be devided into three segments: • Access segment • This segment encloses functions which are required for connecting customers’ equipment to the service • This segment may include for instance BGF or P-CSCF • Several of access functions are embedded in SBC (Session Border Controllers) • Core segment • This segment is the place where the service logic and required functions such as routing, billing, etc. are hosted • Within IMS architecture, this segment is responsible for interconnecting to internal or external AS (Application Servers) • Examples of core IMS functional elements : I-CSCF, S-CSCF, HSS, etc. • Border segment or Interconnection segment • This segment groups required functions to interconnect with external realms • These external realms may be VoIP ones, PSTN, PLMN or any other voice service domain • Usually this segment is implemented by an SBC

8. SBC1 SBC2 SBC3 SBC4 SBC1_b SBC2_b SBC3_b SBC4_b Service POP2 Service POP3 Core PF Service POP1 Service POP4 Service Provider Macroscopic View of an IMS-enabled Service Domain Access POP: physical redundancy is usually implemented

9. SBC1 SBC2 SBC3 SBC4 SBC3_b SBC1_b SBC2_b SBC4_b Service POP2 Service POP3 Core PF Service POP1 Service POP4 Service Provider Macroscopic View of an IMS-enabled Service Domain UE1 SBC is the first service contact point of each User Equipment

10. SBC1 SBC2 SBC3 SBC4 SBC3_b SBC1_b SBC2_b SBC4_b Service POP2 Service POP3 Core PF Service POP1 Service POP4 Service Provider Macroscopic View of an IMS-enabled Service Domain UE1 The service topology is hidden. Only SBCs are visible to external parties

11. SBC nodes • SBC stands for Session Border Controller • SBC have been introduced to solve several problems encountered in SIP deployments • Examples of functions supported by these nodes are • Topology hiding • NAT Traversal • Solve protocol mismatch • Etc. • SBC are considered as a single point of failure

12. Focus on core service failures • Failure of core segment • When access to core service nodes is broken • Problems reltaed to: • Availbility of the core service nodes • Routing problems; • Etc.

13. SBC1 SBC2 SBC3 SBC4 Service POP2 SBC2_b SBC4_b SBC3_b SBC1_b Failure Service POP3 Core PF Service POP1 Service POP4 Service Provider Focus on core service failures: Scenario 1 One or many core service nodes are out of service: the service can not be delivered to end users

14. SBC1 SBC2 SBC3 SBC4 Service POP2 SBC2_b SBC4_b SBC3_b SBC1_b Failure Service POP3 Core PF Service POP1 Service POP4 Service Provider Focus on core service failures: Scenario 1 UE1 UA1 is unable to register to the service or to invoke its subscribed services

15. SBC1 SBC2 SBC3 SBC4 Service POP2 SBC2_b SBC4_b SBC3_b SBC1_b Service POP3 Core PF Failure Service POP1 Service POP4 Service Provider Focus on core service failures: Scenario 2 One or many access SBCs are unable to reach core service nodes: the service can not be delivered to end users

16. SBC1 SBC2 SBC3 SBC4 Service POP2 SBC2_b SBC4_b SBC3_b SBC1_b Service POP3 Core PF Failure Service POP1 Service POP4 Service Provider Focus on core service failures: Scenario 2 UE1 UA1 is unable to register to the service or to invoke its subscribed services

17. Proposal to Enhance IMS architectures • Unlike current IMS-based deployments, this solution aims to involve actively SBC nodes in the failure detection and reactivation processes • Additional functions and interfaces are introduced for this purpose • The characteristics of the proposed solution are as follows: • Assess the availability of core service through the invocation of dedicated messages • Detect an un-reachability problem between a given SBC and core service platform • Adopt a collaborative mode in which SBCs will intervene in the routing resolution process

18. Proposal to Enhance IMS architectures • Two scenarios may be envisaged: • (1) Partial Failure • This means that at least one SBC can reach core service nodes • In this scenario, a new procedure is introduced and implemented by SBCs • This procedure consists to select an SBC_PROXY which will relay messages to core service platform. A multicast channel is used for this purpose • (2) Full Failure • All SBCs fail to reach core service nodes • Once this occurs, all SBCs activate their autonomous mode and are acting as a network of co-equal peers, intervening during the routing process • Messages are not routed to core service nodes anymore, but are processed by SBCs themselves

19. Partial Failure • If Multicast is enabled, a multicast group is configured and all SBCs and Interconnection nodes are member of this group. If not, P2PSIP like mechanisms are used to create an SBC overlay network • Means to subscribe to this multicast group are activated in all SBCs (e.g. IGMP) • Keep alive messages are issued regularly to assess to availability to reach core service nodes • How to implement this function is not detailed in this paper • Once an unavailability is detected, a given SBC sends a dedicated request to select an SBC_PROXY which is able to reach core service nodes • The request is sent to the aforementioned multicast group • Responses are sent using unicast • If several offers are received, the local SBC makes its decision based on some criteria such as CPU, IGP path, etc. • All subsequent communications will cross this SBC_PROXY

20. Example of a Call Flow during a partial failure UE1 SBC1 SBC2 SBC4 UE4 (1) Keep-alive Core PF Is out of service (2) SBC_PROXY_REQUEST() (3a) SBC_PROXY_OFFER() (3b) SBC_PROXY_OFFER() SBC2 is selected as SBC_PROXY (4a) INVITE(UE4) (4b) INVITE(UE4) (4c) INVITE(UE4) (4d) INVITE(UE4) (5a) OK (5b) OK (5c) OK (5d) OK (6a) ACK) (6b) ACK (6c) ACK (6d) ACK) RTP RTP RTP RTP

21. Example of a Call Flow during a full failure UE1 SBC1 SBC4 UE4 (1) Keep-alive Core PF Is out of service (2) SBC_PROXY_REQUEST() Mode Auto (3a) INVITE(UE4) (3b) lookup_req(UE4) (3c) lookup_res() (3d) INVITE(UE4) (3e) INVITE(UE4) (4a) OK (4b) OK (4c) OK (5a) ACK) (5b) ACK (5c) ACK) RTP RTP RTP

22. Conclusions • Owing to autonomic behaviors, the service is delivered to end users even in case of partial or full failures • Customers are not aware about occurred failures • Further effort should be undertaken to assess the validity of the proposed solution for the delivery of sophisticated services

23. Questions?