ART R. Schott Internet-Draft M. Kreipl Intended status: Informational B. Dreyer Expires: 6 January 2025 R. Jesske Deutsche Telekom 5 July 2024 Avoiding Registration Storms by adapted Registration Behavior for Voice Cloud Applications draft-schott-sip-avors-01 Abstract This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active registrations. The concept can be mapped on any architecture having a distributed structure and could work for different protocols. The concept is exemplary explained here regarding an architecture for voice and is mapped on a 3GPP (3rd Generation Partnership Project) architecture. This document describes the AVORS (Avoiding Registration Storms) concept that allows the resumption of active UE (User Equipment) registrations on other Outbound Proxies (P-CSCF) within the SIP voice 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) in context 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 6 January 2025. Schott, et al. Expires 6 January 2025 [Page 1] Internet-Draft AVORS July 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. Functions of Registration Resumption Feature . . . . . . . . 7 5.1. P-CSCF related Functions . . . . . . . . . . . . . . . . 7 5.2. S-CSCF related Functions . . . . . . . . . . . . . . . . 13 5.3. Data Base related Functions . . . . . . . . . . . . . . . 18 6. Related work . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security and operational considerations . . . . . . . . . . . 19 8. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Annex A . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 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 [TS_23.228] Service Based Architecture (SBA) and Service Based Schott, et al. Expires 6 January 2025 [Page 2] Internet-Draft AVORS July 2024 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 [RFC5246] or [RFC8446]. 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. 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 6 January 2025 [Page 3] Internet-Draft AVORS July 2024 3. 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. 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 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 Schott, et al. Expires 6 January 2025 [Page 4] Internet-Draft AVORS July 2024 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. Figure 1 describes the geo-redundancy use case. Initial register in case of an initial registration or from time-to-time for security or data base cleaning. +---------+ +-------+ | | | | | P-CSCF | | DNS | | Site #1 | | | /| | \ +-------+ / +---------+ \ | / \ | / \ | / sip \ | / initial +---------+ +-------+ / register | | | |/ | Data | | UE | | Base | | | | | +-------+ +---------+ / +---------+ / | | / | P-CSCF | / | Site #2 |/ | | +---------+ Registration resumption in case of a failover to the secondary outbound proxy or P-CSCF respectively. \ / +---------+ +-------+ | \ / | | | | P-CSCF | | DNS | | Site #1 | | | | / \ | \ +-------+ +---------+ \ | / \ \ | \ | \ | +---------+ +-------+ | | | | | Data | Schott, et al. Expires 6 January 2025 [Page 5] Internet-Draft AVORS July 2024 | UE |\ | Base | | | \ | | +-------+ \ +---------+ \ / \ +---------+ / sip \ | | / registration\ | P-CSCF | / resumption \| Site #2 |/ | | +---------+ Figure 1: AVORS Geo-Redundancy. Figure 2 describes the local-redundancy use case. Initial register in case of an initial registration or from time-to-time for security or data base cleaning. +---------+ +-------+ | | | | | P-CSCF | | DNS | | Inst.#1 | | | /| | \ +-------+ / +---------+ \ | / \ | / \ | / sip \ | / initial +---------+ +-------+ / register | Local | | |/ | Data | | UE | | Base | | | | | +-------+ +---------+ / +---------+ / | | / | P-CSCF | / | Inst.#2 |/ | | +---------+ Registration resumption in case of a failover to the secondary local P-CSCF instance. \ / +---------+ +-------+ | \ / | | | | P-CSCF | Schott, et al. Expires 6 January 2025 [Page 6] Internet-Draft AVORS July 2024 | DNS | | Inst.#1 | | | | / \ | \ +-------+ +---------+ \ | / \ \ | \ | \ | +---------+ +-------+ | Local | | | | Data | | UE |\ | Base | | | \ | | +-------+ \ +---------+ \ / \ +---------+ / sip \ | | / registration\ | P-CSCF | / resumption \| Inst.#2 |/ | | +---------+ Figure 2: AVORS Local-Redundancy. 5. 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 or according to 3GPP IMS (IP-Multimedia Subsystem) for P-CSCF and S-CSCF architecture. It also works in context of 3GPP SBA (Service Based Architecture). 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. 5.1. P-CSCF related Functions +==================+==============================================+ | Function | Description | +==================+==============================================+ | *AVORS Option | P-CSCF shall on receipt of the AVORS Option | | Tag* | Tag in the Supported Header of the Initial | | | Register confirm the AVORS feature support | | | by including the AVORS Option Tag in the 200 | | | OK message. | +------------------+----------------------------------------------+ | *P-CSCF - | P-CSCF shall provide an interface to the | | Database | Database according Udsf Specification of | | Interface* | 3GPP. | Schott, et al. Expires 6 January 2025 [Page 7] Internet-Draft AVORS July 2024 +------------------+----------------------------------------------+ | *Storage of | P-CSCF shall store after each successful TLS | | Security Data* | based Initial Registration the tls session | | | context in the Database according to the | | | related Datamodel and additionally locally | | | (in order to save database requests). | +------------------+----------------------------------------------+ | *Storage of TCP | P-CSCF shall store after each successful TCP | | Fast Open (TFO) | based Initial Registration or TLS based | | Data* | Initial Registration the TFOData in the | | | Database according to the used Datamodel and | | | additionally locally (in order to save | | | database requests). | +------------------+----------------------------------------------+ | *TCP Fast Open | P-CSCF shall support TCP session resumption | | Support* | (TFO) at the Gm interface according to | | | [RFC7413]. | +------------------+----------------------------------------------+ | *TFO parameter* | For the TCP session resumption P-CSCF shall | | | obtain from the Database TFOData the | | | required TFO session cookie based on the UE | | | IP address. | +------------------+----------------------------------------------+ | *TLS Session | P-CSCF shall support TLS session resumption | | Resumption* | at the Gm interface according to [RFC2246] | | | for TLS 1.2 and [RFC8446] for TLS 1.3. | +------------------+----------------------------------------------+ | *TLS Session | For the TLS session resumption P-CSCF shall | | Resumption | obtain from the Database Security Data View | | parameter* | the TLS session context based on the TLS | | | SessioID. Note: Be aware of the possible | | | TLS Resumption timeout that shall be | | | avoided. | +------------------+----------------------------------------------+ | *Handling | On receipt of a Register message (Initial or | | Register | Re-Register) not belonging to a registered | | messages of | UE on this P-CSCF instance, P-CSCF shall | | users not | obtain from Database Registration data the | | registered at | required UE Registration and NBA (NASS | | the P-CSCF* | Bundled Authentication) data based on the UE | | | IP address and PAU. Note: PAU may contain | | | 1-3 IMPUs that might be implicitly | | | registered. | +------------------+----------------------------------------------+ | *Initial | Initial Registration shall be initiated when | | Registration | no Registration Data is available on the | | initiation* | Database. | +------------------+----------------------------------------------+ Schott, et al. Expires 6 January 2025 [Page 8] Internet-Draft AVORS July 2024 | *Generation of | After receipt of 200 OK, P-CSCF shall store | | Registration | after each successful UDP based Initial | | Data and storage | Registration, TCP based Initial | | in Database* | Registration, TLS based Initial | | | Registration, or IPSec based Initial | | | Registration the Registration and NBA Data | | | (fixed access) in the Database according to | | | used Datamodel AVORS Registration View and | | | additionally locally (in order to save | | | Database requests). - For fixed access in | | | IMPU table - For mobile access in IMSI table | +------------------+----------------------------------------------+ | *Generation of | After receipt of 200 OK, P-CSCF generates | | IMSI/IMPU | IMSI/IMPU value pair and and stores it in | | correlation | the Database in IMSI/IMPU correlation table | | table and | and if suitable locally. Note: IMSI/IMPU | | storage in | correlation table mighjt be used for in the | | Database* | terminating Invite use case, when the S-CSCF | | | or terminating P-CSCF requires to obtain | | | called user Registration Data stored under | | | the record identifier "IMSI", but only knows | | | the IMPU i the To-header. | +------------------+----------------------------------------------+ | *Registration | Registration of IMPUs shall be resumed (no | | Resumption on | Initial Registration) on P-CSCF instance | | new P-CSCF | previously not assigned during Initial | | instance for | Registration phase in case of available | | fixed network | Registration Data the on | | access* | | +------------------+----------------------------------------------+ | | - UDP based Initial Register message with or | | | without supported SIP InstanceID (no nonce) | +------------------+----------------------------------------------+ | | - UDP based Re-Register message AVORS | | | header, same IP address, same SIP | | | InstanceID, same CallID, Cseq >1, valid | | | nonce. The contact header may contain no | | | port number or the port number 5060. | +------------------+----------------------------------------------+ | | - TFO based Re-Register message with AVORS | | | header, same IP address, same SIP | | | InstanceID, same CallID, Cseq >1, valid | | | nonce. The contact header may contain no | | | port number or the port number 5060. | +------------------+----------------------------------------------+ | | - TLS Session Resumption based Re-Register | | | message with AVORS header, same IP address, | | | same SIP InstanceID, same CallID, Cseq >1, | Schott, et al. Expires 6 January 2025 [Page 9] Internet-Draft AVORS July 2024 | | valid nonce. The contact header may contain | | | no port number or the port number 5061. | +------------------+----------------------------------------------+ | | Note: UDP based Initial Registration message | | | for Registration Resumption is allowed due | | | to IAD agnostic approach. | +------------------+----------------------------------------------+ | *Cascaded | For fixed network access cascaded | | registration | registration timer shall be supported. In | | timer for fixed | case of switch over to another P-CSCF | | network access* | instance, Re-Register message counter starts | | | with “1 to 4 randomly”. Note: The 5th Re- | | | Register message counter number is not used | | | in order to avoid forwarding to S-CSCF in | | | failure case. The numbers are examples here | | | and should be configurable. | +------------------+----------------------------------------------+ | *Registration | P-CSCF shall confirm the successful | | Resumption | Registration Resumption with a 200 OK | | confirmation* | message to the UE when Register message is | | | not forwarded to S-CSCF. | +------------------+----------------------------------------------+ | *Registration | Registration of IMSI shall be resumed (no | | Resumption on | Initial Registration) on P-CSCF instance | | new P-CSCF | previously not assigned during Initial | | instance for | Registration phase in case of available | | mobile network | Registration Data in the Database on | | access* | | +------------------+----------------------------------------------+ | | - IPSec based Initial Register message | +------------------+----------------------------------------------+ | *AA Request on | When a mobile network access registration | | registration | resumption on a new P-CSCF instance is | | resumption for | conducted, new P-CSCF shall execute a AA | | mobile network | Request to PCRF via Rx interface. Note: The | | access* | AA Request is required to update session | | | information in the PDN Gateway, that a new | | | P-CSCF instance has taken over. | +------------------+----------------------------------------------+ | *Forwarded | For mobile access forwarded Register message | | Register message | to S-CSCF in registration resumption uses | | to S-CSCF for | case shall comply with a Re-Register | | mobile access | message, containing the previous Call-ID and | | during | the nonce in the Authorization header | | registration | retrieved from the Database. Note: This | | resumption* | applies in the Registration resumption use | | | case (switchover to another node) when | | | initiated by an Initial Register message. | Schott, et al. Expires 6 January 2025 [Page 10] Internet-Draft AVORS July 2024 +------------------+----------------------------------------------+ | *Update of | After successful Registration Resumption | | pcscfPath* | P-CSCF shall update the pcscfPath attribute | | | of the Database Registration Data with it's | | | own name. | +------------------+----------------------------------------------+ | *Reset for | P-CSCF must update the Registration Data in | | registration | the Database with every 5th Re-Register, in | | Timer in fixed | order to reset the registration timer. | | network* | Note: In fixed network cascaded registration | | | timer is introduced. P-CSCF maintains for | | | example a 12 min registration timer, S-CSCF | | | a one-hour registration timer. When in an | | | AVORS deployment Registration data gets | | | stored locally in P-CSCF, P-CSCF must update | | | the Registration Data in the Database with | | | every 5th Re-Register, in order to reset the | | | registration timer. The numbers are | | | examples here and should be configurable. | +------------------+----------------------------------------------+ | *Reset of | P-CSCF must update the Registration Data in | | registration | the Database with every Re-Register, in | | Timer in mobile | order to reset the registration timer. | | network* | Note: In mobile network every Re-Register | | | initiates an Registration Data update in the | | | Database in order to reset the registration | | | timer. | +------------------+----------------------------------------------+ | *TLS based Re- | On receipt of a TLS based Re-Register | | Register message | message not belonging to a registered UE on | | at new P-CSCF | this P-CSCF instance, P-CSCF shall initiate | | instance* | an Initial Registration. | +------------------+----------------------------------------------+ | *No TFO Data in | If on a TCP session resumption request no | | the Database* | TFO Data can be found in the Database, | | | P-CSCF must reject the TCO session | | | resumption request. | +------------------+----------------------------------------------+ | *No Security | If on a TLS Session Resumption request no | | Data in the | Security Data can be found in the Database, | | Database* | P-CSCF must initiate a new TLS session | | | establishment and Initial Registration. | +------------------+----------------------------------------------+ | *No Registration | If on an Initial Registration or Re- | | Data in the | Registration message no Registration Data | | Database* | can be found in the Database, P-CSCF must | | | initiate an Initial Registration for the UE. | +------------------+----------------------------------------------+ Schott, et al. Expires 6 January 2025 [Page 11] Internet-Draft AVORS July 2024 | *No NBA Data in | If on an Initial Registration or Re- | | NDL* | Registration message no NBA Data can be | | | found in the Database, P-CSCF must initiate | | | an Initial Registration for the UE. | +------------------+----------------------------------------------+ | *UE initiated | On the receipt of a 200 OK messsage | | De-Registration* | belonging to a De-Registration message from | | | a UE, P-CSCF shall delete the Security data, | | | TFO data, Registration Data and NBA Data of | | | the concerned IMPU from the Database. | +------------------+----------------------------------------------+ | *P-CSCF | After the P-CSCF Registration Timer of a UE | | Registration | registration has expired, P-CSCF shall | | timer expiry* | terminate the UE binding. Note: Originating | | | and terminating calls must be rejected after | | | binding termination. P-CSCF must not send a | | | network initiated De-Registration. | +------------------+----------------------------------------------+ | *SIP request | Generally, every S-CSCF instance can be | | forwarding to | selected by P-CSCF for SIP request | | local S-CSCF* | forwarding. However, the SIP request | | | forwarding to the local S-CSCF is the | | | prioritized option and shall be selected | | | whenever possible. | +------------------+----------------------------------------------+ | *Switch back to | For the initiation of the intentional switch | | primary P-CSCF* | back to the primary P-CSCF, the Graceful | | | Shutdown feature shall be utilized. | +------------------+----------------------------------------------+ | *System wide | In case of system wide outage with lost of | | Disaster | registration data or new IP address | | Restoration | assignment it shall be possible to | | mechanism* | deactivate the P-CSCF AVORS feature and and | | | to allow step by step start up of single | | | sites | +------------------+----------------------------------------------+ | *Registration | When IRS is activated P-CSCF shall generate | | Data generation | on the first user's Initial Registration | | in case of | Registration Data for all IMPUs of the user | | activated | and store them in the Database and locally. | | Implicit | Note: The user's assigned IMPUs can be | | Registration | derived from the PAU header in the 200 OK | | state (IRS)* | response of the first Initial Registration. | +------------------+----------------------------------------------+ | *Application | P-CSCF shall assign an Application Server | | Server instance | instance at the first IMPU registration of a | | Assignment at | user. After the receipt of the 200 OK | | first IMPU/IMSI | response for the Initial Registration, | Schott, et al. Expires 6 January 2025 [Page 12] Internet-Draft AVORS July 2024 | registration of | P-CSCF shall query Database for Registration | | a user* | Data for all IMPUs of the user provided in | | | the PAU of the 200 OK response. Since no | | | Registration Data is available, P-CSCF | | | selects an Application Server instance | | | (preferably the local AS) and writes the | | | selected AS instance into the new generated | | | Registration Data of this IMPU. | +------------------+----------------------------------------------+ | *Application | P-CSCF shall assign an Application Server | | Server instance | instance for the first IMPU registration of | | identification | a user. After the receipt of the 200 OK | | for second or | response for the Initial Registration, | | following IMPU/ | P-CSCF shall query Database for Registration | | IMSI | Data for all IMPUs of the user provided in | | registration of | the PAU of the 200 OK response. Since | | a user or same | already an IMPU is registered, Database will | | IMPU at second | provide the Registration Data of this IMPU. | | or following IP | P-CSCF identifies the already assigned AS | | address* | for this user and inserts the assigned AS | | | into the Registration Data of the IMPU that | | | gets registered. | +------------------+----------------------------------------------+ Table 1 5.2. S-CSCF related Functions +===================+===============================================+ | Function | Description | +===================+===============================================+ | *Stateless | S-CSCF shall be provided in a stateless | | S-CSCF* | implementation with respect to | | | Registration. Assignment of dedicated | | | S-CSCF shall be abdicated. | +-------------------+-----------------------------------------------+ | *Session Data* | Stateless S-CSCF only concerns | | | Registration related features. Session | | | related features shall remain stateful. | +-------------------+-----------------------------------------------+ | *S-CSCF | Since the S-CSCF is operated in stateless | | Registration | operation mode, the S-CSCF Registration | | Timer* | timer shall be apdicated in S-CSCF. | +-------------------+-----------------------------------------------+ | | Note: Regitration timer is moved to the | | | UDSF [TS_29.598] chapter 5.3 Nudsf Timer | | | Service. | +-------------------+-----------------------------------------------+ Schott, et al. Expires 6 January 2025 [Page 13] Internet-Draft AVORS July 2024 | *S-CSCF | In stateless S-CSCF mode S-CSCF is not | | Restoration | assigned to users anymore, thereby the | | Procedure* | S-CSCF Restoration Procedure shall be | | | abdicated. | +-------------------+-----------------------------------------------+ | | Note: Stateless S-CSCF is able to process | | | the SIP requests of any user. | +-------------------+-----------------------------------------------+ | *S-CSCF User Re- | In stateless S-CSCF mode S-CSCF is not | | Distribution* | assigned to users anymore, thereby the | | | S-CSCF User Re-Distribution feature shall | | | be abdicated. | +-------------------+-----------------------------------------------+ | | Note: Stateless S-CSCF can be selected | | | freely after registration at new P-CSCF. | +-------------------+-----------------------------------------------+ | *Initial | Deviant from the standard Initial | | Registration Call | Registration call flow the | | Flow mobile | | | network access* | | +-------------------+-----------------------------------------------+ | | - S-CSCF Register authorization with UAR | | | request shall be configurable | +-------------------+-----------------------------------------------+ | | - S-CSCF assignment with UAR request | | | shall be abdicated | +-------------------+-----------------------------------------------+ | | - S-CSCF shall assign in case of stateful | | | AS the responsible AS instance for the | | | user and write the assigned AS instance | | | into the Registration Data in the | | | Database | +-------------------+-----------------------------------------------+ | *Initial | Deviant from the standard Initial | | Registration Call | Registration call flow the | | Flow mobile | | | network access* | | +-------------------+-----------------------------------------------+ | | - S-CSCF Register authorization with UAR | | | request shall be configurable for foreign | | | network access and own network access | +-------------------+-----------------------------------------------+ | | - S-CSCF assignment with UAR request | | | shall be abdicated | +-------------------+-----------------------------------------------+ | | - 3rd Party Registration shall be | | | abdicted in case of stateless Application | | | Server | Schott, et al. Expires 6 January 2025 [Page 14] Internet-Draft AVORS July 2024 +-------------------+-----------------------------------------------+ | | - S-CSCF shall assign in case of stateful | | | AS the responsible AS instance for the | | | user and write the assigned AS instance | | | into the Registration Data in the | | | Database | +-------------------+-----------------------------------------------+ | | Note: When the Registration request is | | | sent by a visited network, that can be | | | derived from the P-Visited-Network-ID of | | | the Register message sent by P-CSCF, a | | | UAR query shall be sent. | +-------------------+-----------------------------------------------+ | | Note: When the Registration request is | | | sent by the home network, that can be | | | derived from the P-Visited-Network-ID of | | | the Register message sent by P-CSCF, a | | | UAR query shall be abdicated. | +-------------------+-----------------------------------------------+ | *Service-Route | Due to the stateless S-CSCF | | header* | implementation, P-CSCFs do not need to be | | | informed about the assigned S-CSCF by the | | | Service-Route header in the 200 OK | | | response from the S-CSCF on Initial | | | Registrations. The Service-Route header | | | shall not be supported. | +-------------------+-----------------------------------------------+ | | Note: In a stateless S-CSCF deployment | | | any S-CSCF instance can be selected for | | | SIP requests processing. Usually the | | | local S-CSCF instance gets selected. | +-------------------+-----------------------------------------------+ | *Re-Registration* | On an incoming Re-Registration message | | | and locally unavailable registration | +-------------------+-----------------------------------------------+ | | - S-CSCF shall query NDL AVORS | | | Registration Data for active Registration | +-------------------+-----------------------------------------------+ | | - In case of active Registration, the | | | Registration shall be resumed | +-------------------+-----------------------------------------------+ | | - In case no active Registration, initial | | | registration process shall be initiated | +-------------------+-----------------------------------------------+ | *Re-Registration | Deviant from the standard Re-Registration | | Call Flow* | call flow the | +-------------------+-----------------------------------------------+ | | - assigned S-CSCF determination shall be | Schott, et al. Expires 6 January 2025 [Page 15] Internet-Draft AVORS July 2024 | | abdicated | +-------------------+-----------------------------------------------+ | | - S-CSCF shall not include S-CSCF URI in | | | SAR request towards HSS | +-------------------+-----------------------------------------------+ | | - User Data shall be requested with SAR | | | request when the User Data is not | | | available locally (switchover to Failover | | | site) | +-------------------+-----------------------------------------------+ | *Deletion of De- | The S-CSCF shall delete the Security | | Registered | Data, the TFO Data, the Registration | | Registration Data | Data, and NBA Data of an UE in the | | on Network | Database after network initiated De- | | initiated De- | Registration of the UE. | | Registration* | | +-------------------+-----------------------------------------------+ | *Deletion of De- | If in an IRS environment an user de- | | Registered | registers an IMPU from one IP address, | | Registration Data | all other IMPUs belonging to the user and | | in case of | registered with the same IP address shall | | activated IRS* | be de-registered and the S-CSCF shall | | | delete the Security Data, the TFO Data, | | | the Registration Data, and NBA Data of an | | | UE in the Database. Note: The user's | | | IMPUs registered with different IP | | | addresses remain registered. | +-------------------+-----------------------------------------------+ | *User initiated | On receipt of a De-Registration message | | De-Registration* | from the UE, S-CSCF shall send an | | | according Delete request to Database | +-------------------+-----------------------------------------------+ | *Database | When S-CSCF receives a De-Registration | | initiated De- | notification, S-CSCF sends a SAR message | | Regstration HSS | to HSS. Note: S-CSCF informs HSS about a | | notice* | network initiated De-Registration | +-------------------+-----------------------------------------------+ | *Database | When S-CSCF receives a De-Registration | | initiated De- | notification, S-CSCF sends a Notfy (De- | | Regstration UE | Registered) message to P-CSCF. Note: | | notice* | S-CSCF informs HSS about a network | | | initiated De-Registration | +-------------------+-----------------------------------------------+ | *HSS initiated | On receipt of a Registration Termination | | De-Regstration | Request (RTR) from HSS, S-CSCF shall send | | Database notice* | an according Delete request to Database | +-------------------+-----------------------------------------------+ | *Invite Call | Deviant from the standard Invite call | Schott, et al. Expires 6 January 2025 [Page 16] Internet-Draft AVORS July 2024 | Flow* | flow the | +-------------------+-----------------------------------------------+ | | - for Onnet Calls the selected S-CSCF | | | instance shall act as originating and | | | terminating S-CSCF | +-------------------+-----------------------------------------------+ | | - S-CSCF shall retrieve the user data of | | | User B with SAR request | +-------------------+-----------------------------------------------+ | | - S-CSCF shall determine the P-CSCF | | | instance of User B with retrieving the | | | Registration Data from Database | +-------------------+-----------------------------------------------+ | *Stateful | In case the Application Server operates | | Application | in stateless mode, the assigned ASs of | | Server selection* | User A and User B shall be determined by | | | querrying the Registration Data of User A | | | and User B locally or in Database | +-------------------+-----------------------------------------------+ | *System wide | In case of system wide outage with lost | | Disaster | of registration data or new IAD IP | | Restoration | address assignment it shall be possible | | mechanism* | to deactivate the S-CSCF AVORS feature | | | and to enforce step by step start up of | | | single sites. | +-------------------+-----------------------------------------------+ | *Registration | In case of disaster causing outage longer | | Timer | as the S-CSCF Registration time, it shall | | Deactivation | be possible to deactivate the | | Parameter* | Registration Timer validation in the Re- | | | Registration process. | +-------------------+-----------------------------------------------+ | *Identification | S-CSCF shall identfy the assigned AS to | | of user / IMPU | the user from the Registration Data of | | assigned AS | the IMPU, to which the application | | instance for | services shall be applied. The S-CSCF | | Invite request* | shall forward the Invite message to the | | | assigned AS instance. | +-------------------+-----------------------------------------------+ Table 2 Schott, et al. Expires 6 January 2025 [Page 17] Internet-Draft AVORS July 2024 5.3. Data Base related Functions +==================+======================================+ | Function | Description | +==================+======================================+ | *Storage of | Database shall store Registration | | Registration | Data according to Datamodel. | | Data* | | +------------------+--------------------------------------+ | *Registration | For each stored Registration Data | | Timer for each | (IMPU/IMSI), a registration timer | | data record* | must be applied. | +------------------+--------------------------------------+ | *Registration | After Reguistration Timer expiry, | | Data deletion* | Database shall delete the according | | | Registration Data and all correlated | | | data. | +------------------+--------------------------------------+ | *Database | The Database Registration Timer | | Registration | shall be configurable from Minutes | | timer | to Days. | | configuration* | | +------------------+--------------------------------------+ | | Note: In case of a system wide | | | outage resulting in long servie | | | outages, the Registration Timer must | | | be able to be increased in order not | | | to loose the registrations. | +------------------+--------------------------------------+ | *Reset of | Each Registration Data record update | | registration | initiates a reset of the | | Timer* | registration timer | +------------------+--------------------------------------+ | *Network based | After registration timer expirey and | | De-Registration* | data record deletion, Database must | | | inform a S-CSCF instance about the | | | De-Registration. Note: Registration | | | timer expiery | +------------------+--------------------------------------+ Table 3 6. Related work Related work can be found in the referenced standards. Schott, et al. Expires 6 January 2025 [Page 18] Internet-Draft AVORS July 2024 7. 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. 8. Abbreviations +========+==================================+ | IAD | Integrated Access Device | +========+==================================+ | P-CSCF | Proxy Session Control Function | +--------+----------------------------------+ | RG | Residential Gateway | +--------+----------------------------------+ | S-CSCF | Serving Session Control Function | +--------+----------------------------------+ | UE | User Equipment | +--------+----------------------------------+ Table 4 9. 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 [RFC3261], is: Name: avors Schott, et al. Expires 6 January 2025 [Page 19] Internet-Draft AVORS July 2024 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 P-CSCF instances. For TLS based tansport protocols TLS session resumption according to [RFC8446] is used at the failover P-CSCF instance. Additionally, the "avors" option tag in order to query P-CSCF support for Registration Recovery Procedure or registration resumption, respectively, is introduced. The following procedures shall apply: 1. The UE determines a P-CSCF instance by a standard P-CSCF discovery mechanism. 2. The UE performs an initial SIP registration at the P-CSCF. 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 P-CSCF. If the P-CSCF 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 P-CSCF instance and a registration was successfully negotiated, the following behavior applies: Note: For AVORS, a re-register on a new P-CSCF 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 P-CSCF. 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 P-CSCF 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 P-CSCF until the re-registration timer is expired. Schott, et al. Expires 6 January 2025 [Page 20] Internet-Draft AVORS July 2024 This avoids a mass registration at the secondary P-CSCF, 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 P-CSCF instance using the TLS session data obtained from the initial handshake on the original P-CSCF instance. The UE shall delete the TLS session data determined during the initial TLS handshake with the original P-CSCF from its internal memory when a new initial 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 P-CSCF instance instead of an initial register message. b. If UDP is used between UE and P-CSCF: 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 P-CSCF instance instead of a register. ii. The UE shall not immediately try to send a re-register message to the secondary P-CSCF until the Re-registration timer is expired. This avoids a mass registration at the secondary P-CSCF, 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 P-CSCF: 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 P-CSCF until the Re-Registration timer is expired. This avoids a mass registration at the secondary P-CSCF, 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 P-CSCF instance using the TFO session cookie obtained from the initial handshake on the original P-CSCF instance. iii. The UE shall delete the TFO session cookie determined during the initial TCP handshake with the original P-CSCF 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 P-CSCF instance instead of an initial Register message. Schott, et al. Expires 6 January 2025 [Page 21] Internet-Draft AVORS July 2024 4. Optional “Re-register on not answered Invite message” i. If an Invite message to primary P-CSCF receives no response, the UE shall send a re-register to secondary P-CSCF and, after receiving 200 OK, shall send the Invite message to secondary P-CSCF. 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. 5. UE behavior if P-CSCF doesn’t support AVORS i. If P-CSCF 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 P-CSCF IP address (no change to current behavior). 10. IANA Considerations TBD 11. Acknowledgements This work has been supported by various contributors. Special thanks to 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, . Schott, et al. Expires 6 January 2025 [Page 22] Internet-Draft AVORS July 2024 [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, . 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] "tbd.", July 2024. Authors' Addresses Roland Schott Deutsche Telekom Ida-Rhodes-Str. 2 64295 Darmstadt Germany Email: roland.schott@telekom.de URI: https://www.telekom.de Michael Kreipl Deutsche Telekom 90441 Nürnberg Germany Email: michael.kreipl@telekom.de Schott, et al. Expires 6 January 2025 [Page 23] Internet-Draft AVORS July 2024 Bastian Dreyer Deutsche Telekom 20359 Hamburg Germany Email: Bastian.Dreyer@telekom.de Roland Jesske Deutsche Telekom 64295 Darmstadt Germany Email: r.jesske@telekom.de Schott, et al. Expires 6 January 2025 [Page 24]