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

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

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

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.

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.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Example of a Call Flow during a partial failure UE1SBC1SBC4SBC2UE4 (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

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

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

Questions?