lexibility of sizing and scaling and also provides flexibility with packaging and deploying VNFs as needed for the service. It enables grouping functions in a common data center or on the same physical host to minimize intercomponent latency. In addition, best-in-breed vendors can be selected for the decomposed VNFs. The approach for decomposing network functions is to use the following guiding principles: 1. Decompose if the functions have significantly different scaling characteristics (e.g., signal- ing VS. media functions, control VS. data plane functions, etc.) 2. Decomposition should enable customizing a specific aspect of the network function on instantiations (e.g., the interworking function may need to be customized specific to each carrier interconnect instantiation) 3. Decomposition should enable instantiating only the functionality that is needed for the service (e.g., if transcoding is not needed, it should not be instantiated) Today, the registration and presence states of the user are tightly coupled with the network func- tions and are not replicated across disaster recovery sites. In case of a site failure, the registration/ presence state of users is lost. This requires all user devices, which were registered at the failed site, to reregister and republish their presence information. This causes a massive registration/presence storm at the disaster recovery site and increases the risk of failures at the disaster recovery site due to the additional load. This also requires overdimensioning to handle capacity needed during regis- tration/presence storms. Also, today, the state of stable sessions is tightly coupled with the network functions and is not replicated across disaster recovery sites. In case of a site failure, the state of stable sessions being handled at that site is lost. This impacts users and has a less-than desirable user experience. Decoupling long-lived state including the registration/presence state of users and session state of stable calls from the virtualized network function 