Control Plane Orchestration: The Evolution of Service Innovation Attributes

Transcription

1 White Paper Control Plane Orchestration: The Evolution of Service Innovation Attributes Prepared by Jim Hodges Senior Analyst, Heavy Reading on behalf of June 2014

2 Introduction Over the past 18 months, there has been a profound change in the role and relative importance of the control plane, as the telecom industry evolves to a softwarecentric architecture and services model built around software-defined networking (SDN) and network functions virtualization (NFV). Given that the control plane is protocol-centric, there is a high degree of interest in leveraging protocols such as Diameter in more innovative ways to drive the next phases of service innovation, and ultimately create a services-agnostic orchestration layer. Accordingly, the focus of this white paper is to document the role and evolutionary phases that Diameter nodes specifically, centralized Diameter Signaling Controllers (DSCs) play in this new model, and how they are expanding past supporting just Diameter to address the requirements for multi-protocol signaling orchestration. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 2

3 Orchestrating the Control Plane As touched upon in the introduction, the end-to-end services policy-driven orchestration model driven by SDN and NFV is fundamentally changing how the control plane is utilized in next-generation virtualized IP networks. In this section of the white paper, we explore what this means for Diameter-based control plane nodes and why they are positioned to assume a greater role in service orchestration. The Role of Diameter & DSCs More than 10 years ago, before the vision of all-ip networks had solidified from an architecture perspective, there was industry consensus that existing control plane authentication and authorization protocols such as SS7 and even the more modern RADIUS would not meet the payload and extensibility requirements that IP networks would vitally need to provide support for mobile broadband services. Specifically, what was required was a protocol that could flexibly meet the requirements associated with authentication, authorization and accounting. Accordingly, the industry, via several standards bodies, collaborated to create the Diameter protocol, which utilizes TCP or SCTP transport, supports transport layer security and, perhaps most importantly, provides a large and flexible address space (32 bits) to meet new services requirements. To meet these requirements, Diameter was designed to support attribute value pairs (AVPs) open-ended data structures with values that can be added, deleted or modified based on unique service requirements of either the origination or destination node. In a services context, this means Diameter can support new value-added services on the control plane without impacting existing defined service values. In addition, Diameter supports both stateful and stateless service request models, which delivers even greater implementation flexibility. Following the completion of Diameter protocol standardization, it was adopted as the control plane protocol interfaces for IP Multimedia Subsystem (IMS) core, packet core and billing systems. Although this was a very positive step, the original architecture advocated a peer-to-peer model in which each network node managed its own point-to-point signaling interfaces. However, following several peer-to-peer-based "signaling storm" incidents in 2012 by operators such as NTT Docomo, a standalone and centralized node that could handle all Diameter interfaces was standardized both in the core (a Diameter Routing Agent, or DRA) and at the network's edge (a Diameter Edge Agent, or DEA), to deliver control plane elasticity and simplify interface administration. A Diameter node that supports these capabilities and interfaces is generically referred to as a DSC. Therefore, strategically, as shown in Figure 1, the DSC has become an indispensable component of next-generation network control planes, because not only can it route messages between the operations/business support system (OSS/BSS), service control/applications and Evolved Packet Core (EPC) layers, it was designed with several distinct agent capabilities to either modify, translate or simply relay AVPbased messages. Moreover, this central network position means that the DSC can play a central role in managing service quality by managing session and node failover, since DSCs are session-aware and able to manage a large number of AVPs, depending on specific HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 3

4 service requirements. The addition of protocol translation functions also means that a DSC is able to interwork with legacy and other non-diameter network control plane protocols and nodes to ensure ubiquitous services interworking. However, it is important to note that not all DSCs automatically support all four agent functions. Figure 1: DSC Connectivity Model Source: Heavy Reading The four agent functions are defined as follows: Relay: Relay agents can insert and remove routing information but don't make any other AVP changes. They perform a basic relay message function and do not maintain session state. Proxy: In addition to relay, can modify message AVPs. Proxies maintain session state and are application-aware. Redirect: A redirect agent is not used to relay messages, but only provides information to a Diameter node, so that it can communicate with another Diameter node. Redirect agents do not maintain session state. Translation: Translation agents translate and interwork Diameter with other protocols, such as GSM MAP and RADIUS. This functionality can also be used to interwork vendor-specific Diameter-to-Diameter protocol implementations. Translation agents maintain session state. Since 2012, network and services requirements have continued to evolve at a rapid pace. As a result, as captured in Figure 2, three distinct DSC evolutionary phases can already be identified. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 4

5 Figure 2: DSC Evolutionary Phases Source: Heavy Reading DSC Evolution Phase 1: Deployment Drivers and Functionality: Focused on basic Diameter relay message routing and typically support little or no message modification capabilities. Many of the earlier projects were deployed as one-off custom interworking solutions, or as a front-end proxy for a Diameter Server Agent. DSC Design Characteristics: DSCs in this phase often utilize a monolithic "purposebuilt" design to maximize throughput. They are more hardware- than software-centric, and are not well suited to managing call state and policy enforcement. DSC Evolution Phase 2: Deployment Drivers and Functionality: In this phase, DSC functionality expands to include additional proxy and more advanced translation capabilities, such as multiprotocol translation (including the IWF function) and service orchestration, to assist with managing complex policy-based message flows. Orchestration scope includes the ability to translate Diameter and non-diameter message flows with intelligence from external data repositories, as well as apply conditional statements based on deep packet inspection of events and AVP attributes (e.g., International Mobile Subscriber Identity, or IMSI). DSC Design Characteristics: DSCs in this phase no longer follow a monolithic design and are more software- than hardware-centric, given the additional software intelligence to maintain session state and application awareness. DSCs in this phase start to be deployed on commercial-off-the-shelf (COTS) hardware. DSC Evolution Phase 3: Deployment Drivers and Functionality: In late 2012, the telecom world underwent an unprecedented change with the conceptual emergence of NFV, which advocates software virtualization of network functions, and SDN, which defines a distinct Layer 2/3 access network control plane to facilitate a common policy and service orchestration routing framework. Therefore, while the DSC was not originally envisaged to support virtualized service orchestration, the DSC that is emerging in this third evolution phase is positioned to play a key role. DSC Design Characteristics: This phase sees the introduction of even more intelligent, purely software-centric DSCs, which not only serve as an integrated software- HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 5

6 based platform for routing and protocol interworking and mediation, but can also support virtualized applications to empower a new generation of cloud-based value-added services. One of the most visible design characteristics of a DSC from this phase is the ability to leverage this additional software intelligence to manage more complex orchestration functionality with no specific hardware dependencies. From an investment protection perspective, while a monolithic Phase 1 DSC is highly unlikely to support Phase 3 requirements, a Phase 2 DSC has the potential, but it is not as straightforward as it may seem. To really take advantage of the elasticity, orchestration and on-demand capabilities of the cloud, it is important to have the foresight to implement an open, modular and extensible software design model. The Impact of Control Plane Virtualization on Service Orchestration As noted above, NFV introduces the concept of virtualized service orchestration. As defined in the most recent ETSI white papers, the orchestrator function, illustrated in Figure 3, manages the execution of the various virtualized network functions (VNFs) in the services control/application, EPC or even OSS/BSS layers. Figure 3: ETSI Orchestration Framework Source: ETSI Network Functions Virtualisation Update White Paper, October 2013 While the objectives of service orchestration are easy to grasp, the implementation is inherently complex, since VNFs can run either in the data center or on customer premises, to minimize application latency. Further complexity stems from the fact that the NFV orchestrator by default must be aware of all active VNFs running in the network. However, while the above diagram does not capture the role that Diameter or DSCs play in the orchestration process, it is important to note as illustrated in Figure 4 HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 6

7 that a DSC is in-path of the orchestration function, by virtue of the fact that it supports all the OSS/BSS, service control/applications and EPC virtualized interfaces. Furthermore, as a central node with knowledge of VNF application invocation, routing and session state, a DSC has visibility into all of the AVP data that nodes are exchanging, and that an orchestrator will require to dynamically manage more complex value-added services. As a result, as shown in Figure 4, Heavy Reading views a Phase 3 DSC emerging as an invaluable node for providing real-time support to NFV network management and orchestration. More specifically, we see a role for the DSC to simplify the management of decomposed applications to support "service chaining," which introduces the requirement to manage the virtualized state machine in real time. This is accomplished by utilizing the DSC as single holistic VNF-aware controller with the capability to translate/interwork in a multi-vendor VNF environment. Figure 4: DSC In-Path NFV Orchestration Source: Heavy Reading Diameter SDN Orchestration Integration SDN is not typically associated with Diameter signaling, since it was originally designed to support interfacing of Layer 4-7 core, packet and billing nodes. In contrast, SDN is focused on application of policy on the control plane of Layer 2-3 access nodes, including routers, packet optical and Ethernet switches. And yet, in order to ensure a holistic network security model, understanding and managing SDN and NFV interactions is necessary. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 7

8 Without such an approach, there is the potential to have malicious control plane packets processed by virtualized DSC servers with adverse outcomes. To mitigate this risk, there is a requirement to provide the SDN controller with real-time information on how to forward service-critical control plane traffic. Heavy Reading views this as uniquely new territory, since never before has the telecom industry experienced the simultaneous emergence of two foundational shifting disruptive technology trends that are complementary. Normally, one disruptive technology simply overpowers the other. As a result, ETSI and ONF recently announced that both bodies will collaborate to provide a layer-agnostic reference architecture that will allow network operators to leverage SDN to support "automated, open and programmable network connectivity to support NFV." Therefore, while still very early in the discussion phase, with many scenarios to be considered, one scenario we consider plausible is to utilize an OpenFlow application programming interface (API) to enable the EPC to access an OpenFlow SDN controller, as depicted in Figure 5. In this case, the DSC acts as an intermediary between the SDN controller and the NFV orchestrator to support layer-agnostic policy control. Figure 5: NFV & SDN Interworking Scenario Source: Heavy Reading To be clear, we are not proposing that the DSC perform the function of an SDN controller, but rather that it is well equipped to support an intermediary function. For example, as we have seen, a DSC supports the protocol Translation agent function. While this capability was originally designed to support interworking with 2G and legacy protocols, given that OpenFlow is a protocol, we see no reason a DSC could not also interwork with modern and future protocols as part of its evolving Phase 3 mandate, if it supports the requisite levels of software modularity and extensibility. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 8

9 Control Plane Orchestration Use Cases This section of the white paper provides two use cases examining the impact and benefit of utilizing a DSC to facilitate control plane orchestration. The first use case Diameter to MAP interworking presents a current DSC Phase 2 interworking and orchestration scenario; the second Long Term Evolution (LTE) and Wi-Fi service orchestration addresses a use case that is applicable to a DSC Phase 3 virtualized environment. Diameter to MAP Interworking One of the ongoing challenges that operators currently face on the control plane is interworking legacy and next-generation protocols. This need for interworking is woven into almost every facet of service delivery, as operators strive to provide seamless coverage across 3G, 4G and Wi-Fi access. And as we have seen, the DSC via the translation agent can simplify this process. For example, as illustrated in Figure 6, commercially available Phase 2 DSCs typically support the interworking function (IWF), which is specifically designed to convert and interwork Diameter and SS7 based GSM MAP signaling. The addition of this capability means that network operators can ensure that LTE roamers will have seamless coverage when they roam into other carrier networks where LTE and IMS access are not supported, or within their own network that has only "islands" of LTE coverage available. Similarly, this approach can also support the roaming of 2G smartphone subscribers into 3G or 4G network. Figure 6: DSC Evolution Phase 2 Diameter to MAP Interworking Source: Heavy Reading DSC Role in Enabling Orchestration: In this use case, a DSC can play a valuable role in enabling orchestration on several network levels. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 9

10 Proxy Function: In this scenario, the DSC utilizes session state to assist in the orchestration of value-added services. An example would be to temporarily suspend active sessions until the identity of the user can be validated if the device and enduser calling and data consumption patterns change drastically while roaming. Translation Function: In addition to utilizing the IWF function for Diameter to GSM MAP conversion, the DSC can assist in providing services execution for roamers when the roaming network has deployed another vendor implementation that utilizes optional parameters or IDs. In this use case, the DSC can modify optional parameters and AVPs so that it can enable the roaming network to send updates on which services have been invoked. In turn, this capability can be utilized in the OSS/BSS to modify billing AVPs such as Accounting Session-ID and Credit Control Request, so that they meet the requirements of the home billing network to support seamless charging and negate the need for opex-heavy, billing-specific "workarounds." This approach could be applied to both post-paid and (perhaps more importantly) pre-paid subscribers, which require ongoing balance checks before application invocation. LTE & Wi-Fi Services Interworking The continued ramp of LTE deployments is good news for mobile operators and subscribers alike. Not only will LTE deliver a much-needed boost in mobile broadband performance, it also puts in place a totally IP-based network framework to leverage going forward. However, the adoption curve of LTE is also slower than anticipated in some regions due to several factors, ranging from regulatory readiness to market forces. For example, Heavy Reading estimates that only 8 percent of Latin America subscribers will utilize 4G technology in And in this market forces category, the impact of Wi-Fi offload must be considered. When carriers first deployed Wi-Fi it was often viewed as necessary to offload data traffic from their 3G networks. However, over time, as Wi-Fi network performance increased, mobile subscribers became increasingly loyal to the service, given the low-price access model. The other concern for network operators is that Wi-Fi networks do not support traditional billing and data analytics models, which makes it difficult to support customer loyalty and churn reduction initiatives. In response to this, the industry with initiatives such as Hotspot 2.0 is moving to implement a model where Wi-Fi access can be integrated into a traditional network model to ensure consistent billing and secure access, and to provide subscriberlevel personalization of services (e.g., special treatment for specific IMSIs when they roam into Wi-Fi environments). This approach is even more relevant in an NFV virtualization context because it empowers the use of a common policy control model regardless of underlying access technology and supports the ability to evenly distribute where this policy is enforced (RAN vs. hotspot) to minimize latency and maximize performance. Accordingly, as illustrated in Figure 7, not only can a DSC be utilized to perform RA- DIUS to Diameter interworking, which is necessary given Wi-Fi networks typically utilize RADIUS for authentication and accounting, it can provide the NFV orchestrator HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 10

11 with the same level of billing and session state data to enable it to more efficiently manage virtualized sessions. Figure 7: DSC Evolution Phase 3 LTE & Wi-Fi Services Interworking Source: Heavy Reading DSC Role in Enabling Orchestration: As in the first use case, the Proxy and Translation agent functions are the keys to enabling service orchestration. However, as delineated below, the inherent flexibility of these functions means that they can also be utilized to accommodate more complex outcomes. For example, since Phase 2 DSCs can inspect and analyze the AVP information, they have the ability to perform real-time comparison with data cached in external sources to affect how message flows are processed. In this manner, they can access external black lists or identify and provide additional capabilities to high-value customers, or support targeted marketing campaigns to provide specific customers with additional quota or roaming privileges based on subscriber profile data. Proxy Function: A key challenge for NFV is managing the unlimited threshold of VNFs that a network may deploy to meet demand. While in such a scenario, the NFV orchestrator is key for managing these, the DSC also can provide important realtime data related to authentication, authorization and accounting systems. For example, the NFV orchestrator is not purely a billing node, so being able to apply common billing policy based on subscriber IMSI is additional complexity that it may HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 11

12 not be able to support without a Phase 3 DSC that has intimate knowledge of all billing and accounting practices. This includes linking Wi-Fi and 4G session service usage for analytics purposes. In the long term, Wi-Fi-specific AVPs could be developed to streamline two distinct billing systems into one single, holistic system. Translation Function: In this use case, in addition to simply translating RADIUS to Diameter, the DSC can also be invaluable in enabling wider roaming capabilities by translating between various interface-specific AVPs, as well as simplifying vendor interoperating requirements for the NFV orchestrator. However, unlike the previous use case, it is important to note that we believe modifying various vendor AVP implementations becomes a mandatory requirement in a virtualized environment, since it is extremely unlikely that one single vendor will develop all the VNFs and multi-tenant applications in the home network. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 12

13 Conclusion The concept of the DSC has quickly moved beyond the earlier functionality of just Diameter routing and security. It is now being seen not only as a platform to support Diameter routing, mediation and security, but also as a means to interwork, orchestrate and enhance other control plane signaling messages, such as RADIUS and SS7. This is required due to the need to provide seamless coverage across existing and new technology investments and take advantage of multiple access methodologies, such as Wi-Fi. But it is also borne out of a desire by service providers to accelerate services to market and provide more personalized connectivity to their customers. When SDN and NFV burst onto the scene less than two years ago, it was unclear what the impact would be on both network operators and vendors. Since then, a wave of specification development has helped to create a clearer view of both from a reference architecture perspective. One of the most notable takeaways from these activities is that SDN and NFV have in a very short period systematically redefined the role of the control plane. The most visible characteristic, as we have documented, is the shift from a traditional session set-up and tear-down model to a more intelligent model, which provides the foundation for support of virtualized Phase 3 orchestration use cases. Although it will take time to fully define and commercialize a fully service orchestrated control plane, it is readily apparent that service providers won't be able to take advantage of the full benefits of a signaling orchestration environment with traditional Diameter routers. The new breed of Phase 2 and Phase 3 DSCs currently coming to market are strategically and technically in a very strong position to support the new attributes required to usher in a new era of service innovation. HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 13

14 Background to This Paper This Heavy Reading white paper was commissioned by Dialogic, but is based on independent research. The research and opinions expressed in this report are those of Heavy Reading. About the Author Jim Hodges Senior Analyst Service Enabling Architecture and Software, Heavy Reading Jim has worked in telecommunications for more than 20 years, with experience in both marketing and technology roles. His primary areas of research coverage at Heavy Reading include the media- and control-plane impact of NFV and SDN on core and edge network components such as the IP Multimedia Subsystem (IMS), session border controllers (SBCs) and Diameter Signaling Controllers (DSCs). Jim is also focused on the impact of NFV and SDN on data center evolution, including the role of application delivery controllers (ADCs), as well as managed services evolution, subscriber data management (SDM) and fixed-line TDM replacement. Jim joined Heavy Reading from Nortel Networks, where he tracked the VoIP and application server market landscape, as well as working on the development of Wireless Intelligent Network (WIN) standards. Additional industry experience was gained with Bell Canada, where he performed IN and SS7 network planning, numbering administration and definition of regulatory-based interconnection models. Jim is based in Ottawa and can be reached at HEAVY READING JUNE 2014 WHITE PAPER CONTROL PLANE ORCHESTRATION 14