Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications

Introduction The AVORS "Avoiding Registration Storms" concept in context of SIP and IMS (IP-Multimedia Subsystem) respectively helps, as the name suggests, to reduce registration storms in case of an outage especially site outages. Nowadays, registration storms are prevented by overcapacity. This overcapacity can be used for other applications, if available or it is idling until an outage occurs. The idling is causing electricity cost even in the case of intelligent power management. In stateless architectures the registration context is stored in a session data base and normally all instances could access this session data base. According to Service Based Architecture (SBA) and Service Based Interfaces (SBI) offer in principal access to the session data base for IMS cloud based applications. Regarding the current standardized registration behavior the IMS UE (User Equipment) MUST initiate a new initial registration. This registration needs to pass the outbound proxy (P-CSCF) and the registrar (S-CSCF) before reaching the data base. With the AVORS principle the outbound proxy (P-CSCF) has a dip into the data base and recognizes that a UE is already registered and is able to resume the registration. Resuming of a register of a session is feasible because the registration session context can be stored in a session data base. Instead of sending an initial registration in case of an outage the UE will send a re-register message to the secondary outbound proxy namely a failover P-CSCF. The latter is able to retrieve the session information out of the session data base and is able to resume the registration without sending the message via the registrar or S-CSCF. This works especially when the registrar (S-CSCF) is fully stateless and shortens the amount of messages being sent in case of a failover scenario. The idea of resumption of a registration or a session is working also for other protocols than SIP e.g., TLS or . AVORS use the idea of session resumption for SIP via a data base dip from the P-CSCF as an alternative approach to optimize registration behavior especially in case of heavy outages and registration storms. The mechanism does not obsolete the original or classical registration behavior and is complementary. The UE or end devices can run either in classical or AVORS mode and the SIP core or IMS core systems can have both options implemented, classical mode and AVORS mode. The AVORS mode is also working in the case that the failover P-CSCF (secondary outbound proxy) uses a different IP address compared to the primary one. The mechanism can be combined with TLS resumption in case of a wireline Residential Gateway (RG). In wireless or mobile context where IPSec is used for authentication the SIP registration resumption works similar to the wireline case. The aim of this document is to specify how resumption for SIP registration works in combination with a session data base. The focus of this document is on the aspect of registrations and recovery time in case of outages e.g., site outages. A fully session resumption including resumption of media streams needs to be analyzed in an additional work.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Rationale of the usage of AVORS mode for SIP sessions By using the AVORS mode for SIP sessions the overcapacity within the IMS Core or voice systems can be reduced because the amount of message flows is reduced when the P-CSCF is able to resume the registration directly. The approach fits into the SBA of 3GPP and the introduction of a session data base in context 5G. Recovery time of the system is also optimized and shortened which is beneficial for the users. In future cloud based SIP applications will run as virtual instances or in containers and will have a context data base anyway. Therefore, it is reasonable to provide an additional registration or re-registration mechanism when migrating the SIP or IMS systems into the cloud. Regarding the UE there are two paths possible:

UE agnostic approach requiring that the voice or IMS core respectively behaves accordingly. No special indication is given by the UE that it works in either the classical or the AVORS mode.
UE AVORS approach where the UE sends an AVORS header or parameter indicating that it is working in AVORS mode. Without sending this AVORS parameter, it is assumed that the UE is working in classical registration mode.

Depending on the installed basis of the operator or the operational requirements both options are valid approaches. In case the UE indicates that it operates in AVORS mode an AVORS header needs to be specified. A suggestion how such a header or parameter could look like is described in the Appendix.

Architecture Overview of AVORS Concept This section gives an overview of the registration resumption concept for SIP sessions. As stated above the classical registration mechanism in case of a failure of a site or a P-CSCF failure is to start a new initial registration towards the secondary outbound proxy and P-CSCF respectively. The registration process invokes P-CSCF, S-CSCF and the data base. With AVORS the P-CSCF is able to resume a registration by handling a normal re-register message of the UE. Instead of starting a new initial registration the UE sends the normal re-registration message to the secondary outbound proxy namely P-CSCF. The P-CSCF gets the session registration context out of the data base where the session context is stored, i.e., session data base. In case of using a TLS session the session resumption process can be implemented for both protocols, TLS and SIP, making the recovery and failover process more efficient. The spare overcapacity needed for processing the initial registration process can be reduced and the recovery mechanism is kept efficient. This document has not the ambition to investigate a TCP session resumption. The AVORS architecture is described in the following figures.

Related work Related work can be found in the referenced standards.

Security and operational considerations Registration or session resumption leads to a situation where security plays a role to avoid unauthenticated and unauthorized access to the platform. The security can be hardened in case the sip session resumption is combined with a TLS session resumption. The AVORS mechanism helps in special failure situations to increase the recovery of the platform. It is up to the implementation to request a new initial registration after a longer time interval. Such kind of mechanism would increase security. In case of TCP or TLS the IP address spoofing is not or difficult to achieve. In case of UDP a nonce and next-nonce mechanism with short re-registration timer ensures security. This is also valid in case of using AVORS. Other security considerations will be addressed in future versions of the document.

Abbreviations

IAD	Integrated Access Device
P-CSCF	Proxy Session Control Function
RG	Residential Gateway
S-CSCF	Serving Session Control Function
UE	User Equipment

Annex A AVORS (Avoidance of Registration Storms): The following sections describes the procedures for AVORS which allows a seamless switch over of IAD in case of a faulty connection towards the first SIP proxy where the IAD is connected. When changing the SIP proxy a simple (Re-) REGISTER is needed to reconnect instead of an challenged initial registration procedure. The following SIP option tag shall apply: This amendment specifies a single option tag, avors. The required information for this registration, as specified in , is: Description: This option tag is for the procedure used to send a re-register instead of a register when changing the first network proxy due to network failure/proxy failure. To allow this procedure the network will indicate if this procedure is implemented.

IANA Considerations TBD

Acknowledgements This work has been supported by various contributors. Special thanks to TBD.