ART R. Schott Internet-Draft M. Kreipl Intended status: Informational B. Dreyer Expires: 23 March 2025 R. Jesske Deutsche Telekom 19 September 2024 Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications draft-schott-sip-avors-02 Abstract This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active UE (User Equipment) registrations on other SIP Proxies within the SIP voice architecture. The concept can be mapped on any architecture having a distributed structure and could work for different protocols. In this document, the concept is exemplary explained regarding an architecture for voice and could also be mapped on a 3GPP (3rd Generation Partnership Project) architecture. The AVORS concept increases service continuity, improves network resilience and offers savings potential. Additionally, this document gives an outlook regarding stateless voice architectures, load calculation aspects, and Service Based Interfaces (SBI) with session data base interworking. Security aspects are considered in the security chapter. As stated above the AVORS principle is not only limited to the SIP protocol and could be adopted by other protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 March 2025. Schott, et al. Expires 23 March 2025 [Page 1] Internet-Draft AVORS September 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale of the usage of AVORS mode for SIP sessions . . . . 4 4. Architecture Overview of AVORS Concept . . . . . . . . . . . 4 5. AVORS Procedure for SIP . . . . . . . . . . . . . . . . . . . 7 6. Functions of Registration Resumption Feature . . . . . . . . 10 7. Related work . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security and operational considerations . . . . . . . . . . . 10 9. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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 mitigated by overcapacity. This overcapacity can be used by other applications, if applicable 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 [TS_23.228] Service Based Architecture (SBA) and Service Based Interfaces (SBI) offer in principal access to the session data base for voice cloud-based applications. Regarding the current standardized registration behavior the UE (User Equipment) MUST Schott, et al. Expires 23 March 2025 [Page 2] Internet-Draft AVORS September 2024 initiate a new initial registration. This registration needs to pass the outbound proxy (SIP Proxy) and the registrar (SIP Server) before reaching the data base. With the AVORS principle the outbound proxy (SIP Proxy) has a dip into the session data base and recognizes that a UE is already registered and is able to resume the registration. Resuming of a registration 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 SIP Proxy. This SIP Proxy could be a geo-redundant one. 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. This works especially when the registrar 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 1.2 [RFC5246] or TLS 1.3 [RFC8446]. AVORS use the idea of session resumption for SIP via a session data base dip from the SIP Proxy 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 in order to trigger registration resumption. The SIP core systems can operate in classical and AVORS mode in parallel. In this case only the UE supporting the AVORS mode, trigger the registration resumption feature. The AVORS mode is also working in the case that the failover SIP Proxy (secondary outbound proxy) uses a different IP address compared to the primary one. The mechanism can be combined with TLS resumption in 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. This principle is described above for the geo-redundancy use case and also works for local redundant instances or in combination. 2. 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 [RFC2119]. Schott, et al. Expires 23 March 2025 [Page 3] Internet-Draft AVORS September 2024 3. Rationale of the usage of AVORS mode for SIP sessions By using the AVORS mode for SIP sessions the overcapacity within the SIP Core or voice systems can be reduced because the amount of message flows are reduced when the SIP Proxy 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 of 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 session data base anyway. Therefore, it is reasonable to provide an adapted registration or re-registration mechanism when migrating the SIP systems into the cloud. Regarding the UE there are two paths possible: * UE agnostic approach requiring that the voice SIP core applies the AVORS mode to all register messages. 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 and the voice core does not apply the AVORS mode to the regarding register messages. 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. 4. 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 SIP Proxy failure is to start a new initial registration towards the secondary outbound proxy and SIP Proxy respectively. The registration process invokes SIP Proxy, SIP Server and the session data base. With AVORS the SIP Proxy 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 SIP Proxy. The SIP Proxy 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 Schott, et al. Expires 23 March 2025 [Page 4] Internet-Draft AVORS September 2024 efficient. The spare overcapacity needed for processing the initial registration process can be reduced and the recovery mechanism is kept efficient. TCP session resumption is no prerequisite for TLS session resumption in case a TCP session is used instead of UDP. The AVORS architecture is described in the following figures. Figure 1 describes the geo-redundancy use case. Initial register. +---------+ +-------+ | | | | |SIP Proxy| | DNS | | Site #1 | | | /| | \ +-------+ / +---------+ \ | / \ | / \ | / sip \ | / initial +---------+ +-------+ / register | Session | | |/ | Data | | UE | | Base | | | | | +-------+ +---------+ / +---------+ / | | / |SIP Proxy| / | Site #2 |/ | | +---------+ Registration resumption in case of a failover to the secondary outbound proxy or SIP Proxy respectively. \ / +---------+ +-------+ | \ / | | | |SIP Proxy| | DNS | | Site #1 | | | | / \ | \ +-------+ +---------+ \ | / \ \ | \ | \ | +---------+ +-------+ | Session | Schott, et al. Expires 23 March 2025 [Page 5] Internet-Draft AVORS September 2024 | | | Data | | UE |\ | Base | | | \ | | +-------+ \ +---------+ \ / \ +---------+ / sip \ | | / registration\ |SIP Proxy| / resumption \| Site #2 |/ | | +---------+ Figure 1: AVORS Geo-Redundancy. Figure 2 describes the local-redundancy use case. Initial register. +---------+ +-------+ | | | | |SIP Proxy| | DNS | | Inst.#1 | | | /| | \ +-------+ / +---------+ \ | / \ | / \ | / sip \ | / initial +---------+ +-------+ / register | Local | | |/ | Data | | UE | | Base | | | | | +-------+ +---------+ / +---------+ / | | / |SIP Proxy| / | Inst.#2 |/ | | +---------+ Registration resumption in case of a failover to the secondary local SIP Proxy instance. \ / +---------+ +-------+ | \ / | | | |SIP Proxy| Schott, et al. Expires 23 March 2025 [Page 6] Internet-Draft AVORS September 2024 | DNS | | Inst.#1 | | | | / \ | \ +-------+ +---------+ \ | / \ \ | \ | \ | +---------+ +-------+ | Local | | | | Data | | UE |\ | Base | | | \ | | +-------+ \ +---------+ \ / \ +---------+ / sip \ | | / registration\ |SIP Proxy| / resumption \| Inst.#2 |/ | | +---------+ Figure 2: AVORS Local-Redundancy. 5. AVORS Procedure for SIP AVORS (Avoidance of Registration Storms): The following sections describes the procedures for AVORS which allows a seamless switch over of UE in case of a faulty connection towards the first SIP proxy where the UE 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 [RFC3261], is: Name: avors 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. The next part describes a possible process. It is requested to include the SIP Instance-ID in the Contact-Header. For TCP based protocols TFO (TCP Fast Open) according to [RFC7413] shall be supported. Latter is relevant for the SIP Proxy instances. For TLS based transport protocols TLS session resumption according to [RFC8446] is used at the failover SIP Proxy instance. Additionally, Schott, et al. Expires 23 March 2025 [Page 7] Internet-Draft AVORS September 2024 the "avors" option tag in order to query SIP Proxy support for Registration Recovery Procedure or registration resumption, respectively, is introduced. The following procedures shall apply: 1. The UE determines a SIP Proxy instance by a standard SIP Proxy discovery mechanism. 2. The UE performs an initial SIP registration at the SIP Proxy. a. In addition, the UE sends an option tag "avors" in the Supported header field in any SIP register request message. b. The UE expects an option tag "avors" in the Supported header field in the 200 OK response to a SIP registration from the SIP Proxy. If the SIP Proxy supports AVORS, the UE receives an option tag "avors" in the Supported header field of the 200 OK. 3. For all cases that require the UE to change to a different SIP Proxy instance and a registration was successfully negotiated, the following behavior applies: Note: For AVORS, a re-register on a new SIP Proxy is considered as new request in an existing dialog. Note: The Contact header field may contain no port number or port number according to {{RFC3261}}. For UEs supporting AVORS, the Contact header field must not be changed on a re-register to a new SIP Proxy. Note: It is requested that the UE supports SIP Instance-ID and includes it in the Contact header field. Note: For AVORS, any re-register sent to a new SIP Proxy MUST also perform re-registration procedures regarding commitment to nonce, retaining the call-id and increase of the CSeq by at least the value 1. a. If TLS was used as a transport protocol: i. If TCP session used by the TLS transport fails and the „Timer F“ has not expired, the UE shall not immediately try to send a Re-register message to the secondary SIP Proxy until the re-registration timer is expired. This avoids a mass registration at the secondary SIP Proxy, the re-registration gets spread over the UE re-registration time of a defined value of e.g., x min. ii. In case of a failed TCP session the UE shall attempt a TLS session resumption according to {{RFC8446}} on the new SIP Proxy instance using the TLS session data obtained from the initial handshake on the original SIP Proxy instance. The UE shall delete the TLS session data determined during the initial TLS handshake with the original SIP Proxy from its internal memory when a new initial Schott, et al. Expires 23 March 2025 [Page 8] Internet-Draft AVORS September 2024 register for this contact has to be executed or if the timers belonging to the TLS session have expired or the TLS resumption failed. iii.The UE will send a re-register request to the new SIP Proxy instance instead of an initial register message. b. If UDP is used between UE and SIP Proxy: i. If a SIP message is not answered or in case that a keepalive is failed, the UE will send a re-register request to the new SIP Proxy instance instead of a register. ii. The UE shall not immediately try to send a re-register message to the secondary SIP Proxy until the Re-registration timer is expired. This avoids a mass registration at the secondary SIP Proxy, the re-registration gets spread over the UE re-registration time of a defined time e.g., x min. c. If TCP is used between UE and SIP Proxy: i. If TCP session used with or without TLS fails and the „Timer F“ has not expired, the UE shall not immediately trying to send a Re-register message to the secondary SIP Proxy until the Re-Registration timer is expired. This avoids a mass registration at the secondary SIP Proxy, the Re-Registration gets spread over the UE Re-Registration time of a defined value of x min. ii. In case of a failed TCP session the UE shall attempt a TCP session resumption (TCP Fast Open (TFO)) according to {{RFC7413}} on a new SIP Proxy instance using the TFO session cookie obtained from the initial handshake on the original SIP Proxy instance. iii. The UE shall delete the TFO session cookie determined during the initial TCP handshake with the original SIP Proxy from its internal memory when the user de-registers or gets de-registered by the network or if the timers belonging to the TFO session cookie have expired or the TCP session resumption failed. iv. The UE will send a Re-Register request to the new SIP Proxy instance instead of an initial Register message. 4. Optional “Re-register on not answered Invite message” i. If an Invite message to primary SIP Proxy receives no response, the UE shall send a re-register to secondary SIP Proxy and, after receiving 200 OK, shall send the Invite message to secondary SIP Proxy. Note: Upon receiving a 503 (Service Unavailable) response to an initial invite request containing a Retry-After header field, then the originating UE shall not automatically reattempt the request until after the period indicated by the Retry-After header field contents. Schott, et al. Expires 23 March 2025 [Page 9] Internet-Draft AVORS September 2024 5. UE behavior if SIP Proxy doesn’t support AVORS i. If SIP Proxy doesn’t support option tag "avors" in the Supported header field in the 200 OK of a SIP registration, an initial registration has to be performed when switching to a new SIP Proxy IP address (no change to current behavior). 6. Functions of Registration Resumption Feature This document is focusing on the introduction of registration resumption in a SIP (Session Initiation Protocol) environment. The method can be used for SIP-Proxies and SIP-Registrars. It also works in context of 3GPP SBA (Service Based Architecture) and with a session data base [TS_29.598]. In a second step, one can consider using a similar advanced mechanism for complete session resumption. The procedure and functions described here are part of a stateless voice architecture and are suitable for use in a cloud environment. 7. Related work Related work can be found in the referenced standards. 8. 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. 9. Abbreviations +=========+==============================+ | Abbrev. | Description | +=========+==============================+ | AVORS | Avoiding Registration Storms | +---------+------------------------------+ | IAD | Integrated Access Device | Schott, et al. Expires 23 March 2025 [Page 10] Internet-Draft AVORS September 2024 +---------+------------------------------+ | RG | Residential Gateway | +---------+------------------------------+ | UE | User Equipment | +---------+------------------------------+ Table 1 10. IANA Considerations TBD 11. Acknowledgements This work has been supported by various contributors. Special thanks to them. TBD 12. References 12.1. Normative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC 6223, DOI 10.17487/RFC6223, April 2011, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Schott, et al. Expires 23 March 2025 [Page 11] Internet-Draft AVORS September 2024 12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [TS_23.228] "IP Multimedia Subsystem (IMS); Stage 2", October 2020. [TS_24.224] "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", July 2020. [TS_29.598] "Unstructured Data Storage Services; Stage 3", June 2024. Authors' Addresses Roland Schott Deutsche Telekom Deutsche-Telekom-Allee 9 64295 Darmstadt Germany Email: roland.schott@telekom.de URI: https://www.telekom.de Michael Kreipl Deutsche Telekom Dieselstraße 43 90441 Nuremberg Germany Email: michael.kreipl@telekom.de Bastian Dreyer Deutsche Telekom Budapester Straße 18 20359 Hamburg Germany Email: Bastian.Dreyer@telekom.de Schott, et al. Expires 23 March 2025 [Page 12] Internet-Draft AVORS September 2024 Roland Jesske Deutsche Telekom Deutsche-Telekom-Allee 9 64295 Darmstadt Germany Email: r.jesske@telekom.de Schott, et al. Expires 23 March 2025 [Page 13]