Policy Control & SDN: A Perfect Match?

Transcription

1 White Paper Policy Control & SDN: A Perfect Match? Prepared by Graham Finnie Chief Analyst, Heavy Reading on behalf of May 2013

2 Introduction Policy control based on the 3GPP Policy & Charging Control (PCC) and similar architectures is now well-established in service provider networks, with 68 percent of operators reporting in Heavy Reading survey work in 2012 that they have deployed a policy server of some kind. Policy platforms, which typically include a policy server and policy enforcement devices (e.g., DPI appliances), often also connected to charging systems and subscriber databases, are used to help operators dynamically control the way that users and applications consume data network (IP and Internet) resources. Policy decisions can be based on a wide variety of triggers, including a customer's data volume usage, service tier, location, application, URL, time of day, congestion level and so on. Separately, carriers are considering the deployment of software-defined networks (SDNs) in which packet forwarding is separated from control functions, and the latter are provided via a "controller" function that tells simple packet forwarding devices how to direct flows using a protocol such as the Open Networking Foundation's OpenFlow. Northbound, the controller may itself be programmed to set up flows in specific ways via open APIs that connect to OSS/BSS tools, application servers and so on. A key objective of SDN is to facilitate and exploit the virtualization of network functions and applications so that they can be provided on a programmable basis from the cloud i.e., from generic compute and storage platforms (servers), typically housed in data centers, and capable of being (re)assigned on-demand to any function. An ETSI working group on network functions virtualization (NFV) in a public carrier context is creating further momentum around this objective. The deployment of policy control and the subsequent interest in SDN raise some important issues for how carriers control the way services are supported and delivered to end users. On the face of it, there is an obvious case for a policy decision or PCRF-like function to be the principal means by which SDN controllers decide how to set up and manage flows. But many issues remain to be decided. This paper concludes that while policy control does indeed seem to be an ideal mechanism through which to control the way network resources are allocated in an SDN, it requires that the SDN concept is extended beyond network flow control and applications-oriented flow control, to include individual subscriber preferences, profile and state. Subscriber awareness will be required at the interface between the control plane and data plane to ensure that operators can continue to honor service guarantees to users. Although there are some open issues in this area, by focusing on the subscriber, telcos can ensure that their core business objectives, including higher ARPU and lower churn, are best preserved. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 2

3 Policy Management in Existing Networks Policy management has undergone explosive growth since it was first described in specifications developed by CableLabs for the cable MSO industry and by 3GPP for the cellular mobile industry. In the 3GPP specifications, subsequently the template for all policy standards, policy emerged as a part of the IMS specifications in But as interest in IMS itself waned, interest in the policy elements grew. An independent Policy & Charging Control (PCC) architecture was laid out in 2008 and has been extended and refined in a series of 3GPP releases, most recently in Release 11. The current architecture is shown in Figure 1. Figure 1: Simplified View of Current 3GPP Policy Architecture Source: 3GPP In some respects, the objectives of those developing the IMS specification from which policy control sprang are strikingly similar to the objectives of those developing SDN. These similarities include the specification of a three-layer architecture (data, control and applications) with interfaces between and within the layers. Developers reasoned that this would enable operators to buy certain modular functions, such as policy control, from "best of breed" specialists. A second aim was to facilitate development of relationships with third parties operating their own application servers. Both of these objectives are also at the heart of SDN and NFV. These parallels should simplify the application of virtualization and cloudbased principles to (for example) modular 3GPP network functions, including in particular control layer functions like policy management especially, for example, in 4G LTE networks, where policy control is a mandatory mechanism for allocating resources to different applications. What Is Policy Management Used for Today? The creation of a policy architecture was driven by telcos' need to find more intelligent ways to allocate resources, especially bandwidth, in networks increasingly dominated by IP, data services, broadband, programmable devices such as smartphones and OTT applications. In this radical, self-reinforcing new environment, telcos have far less control than hitherto over subscriber applications and HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 3

4 Operators began to look at policy platforms as a means not just to control the way users consumed resources, but to differentiate and refine service packages network behavior. Using policy servers, however, they could in principle reestablish some control over user behavior by, for example, applying throttles if a specific user or application is deemed to be consuming too much of a particular resource. Against a backdrop of accelerating and apparently insatiable demand for "data" services, most initial policy deployments have been used to apply more intelligent traffic management measures an application of policy usually called "fair use management." A related objective has been to use policy to damp down or smooth out peak-hour demand in order to postpone further investment in spectrum or radio infrastructure, by encouraging users to shift bandwidth-intensive applications such as P2P to off-peak usage hours. Since those initial deployments took place between about , policy management use cases have flourished. Because policy servers are in effect general-purpose rules engines, any suitable rule can in principle be written to achieve a desired effect, which may include not just generalized traffic management but also applications-oriented QoS, subscriberoriented QoE, etc. Realizing this, operators began to look at policy platforms as a means not just to control the way users consumed resources, but to differentiate and refine service packages. Strategically speaking, the emphasis had begun to shift from cost-control to raising ARPU, or more generally to raise the revenue potential or yield from scarce and expensive resources such as radio spectrum. Summarizing, there has been a substantial shift in the past two years or so from network- or application-centric policy to subscriber-centric policy. As Figure 2 shows, carriers intend to apply most of the currently-touted triggers for policy decisions, and more could be added to those shown here. Figure 2: The Range of Policy Triggers Is Growing Rapidly Source: Heavy Reading survey of 80 network operators, June 2012 HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 4

5 Importantly, almost all of these triggers are either subscriber-centric by definition or could be linked to subscriber profile data to make better policy decisions. One result is that more policy decisions than before entail reference to charging/billing systems and external subscriber databases. All policy products now refer to subscriber data including subscriber state as a key input to policy decision-making This shift in emphasis has been matched by refinements to vendor propositions in the area. All policy products now refer to subscriber data including subscriber "state" as a key input to policy decision-making. This has facilitated the development of a whole raft of new and more complex policy use cases, including: Subscriber tiers or options that only allow the use of one or a few applications (e.g., "social networking only") The exclusion of certain applications from data quotas (e.g., "zero-rating Facebook, Google, or the operator's own Web site or an enterprise Web) On-the-fly purchase of additional capacity to meet a specific need (e.g., to watch a video, or while roaming) Shared usage quotas (e.g., within a family or business unit) Priority treatment for certain customer applications (e.g., a video or VoIP session) in the presence of congestion In a sense, therefore, policy controllers are already operating in an SDN-like manner, in that they are using a variety of (northbound) information sources and triggers to direct how (southbound) network devices are to route flows. But as we shall see later, the shift in emphasis in policy control from the application to the subscriber has important implications for the way SDN is designed. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 5

6 From SDN to "Carrier SDN" Though SDN arrived later on the carrier scene than policy control, it's no exaggeration to say that it has exploded into view over the past 18 months, and is now one of the central strategic issues with which telco network architects are grappling. Strictly speaking, the idea of separating network logic from underlying hardware is not new: It first found favor in the "Intelligent Networks" rolled out 25 years ago to handle certain services such as freephone separately, and as we saw in the last section, it underlay the development of the IMS architecture. But SDN in its modern sense has reignited interest in the idea, because it promises to resolve carriers' two most pressing needs: to radically cut the cost per bit transported, and to radically accelerate the speed at which new revenuegenerating services and service options are introduced. SDN has been strongly associated to date with the work of the Open Networking Foundation (ONF), which is led and funded by a mix of big carriers, Web destinations and academic institutions. The ONF's initial aim was to strip out complex routing logic from proprietary switches and routers and make it available as a function or as a cloud service, alongside other functions that help to make decisions about how packet flow are routed. This is shown conceptually in Figure 3. The main output to date therefore is OpenFlow, now in version 1.4, which enables simple switches to be controlled by separate routing software. Figure 3: SDN Architecture Source: ONF HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 6

7 This has several benefits for network operators. First, it means that the simple data forwarding function can be handled by very low-cost generic switches. Second, it means that routing software previously embedded in switches can be provided as a software function and housed, alongside other network functions and applications, in generic IT servers rather than dedicated proprietary network appliances. Third, SDN can handle a flow holistically, improving control of the flow.* Fourth, an SDN can make for improved tunneling (e.g., of MPLS, GTP). In principle, buyers should benefit in at least two ways. First, they should be able to greatly improve the price-performance of hardware both switches and servers taking full advantage of the Intel x86 cost-performance curve, and lowering cost per bit carried. Second, they should benefit from a much more streamlined and efficient operational environment. The network effectively becomes programmable and more automated, and operators are no longer dependent on long and expensive vendor upgrade programs when they want to upgrade or augment network functionality. In summary, both opex and capex are reduced. Adapting to the Carrier Network Environment These benefits are, of course, largely theoretical at this point, and there are plenty of challenges and pitfalls ahead. Most carriers don't currently believe that Open- Flow in itself meets all of their needs, and there has been much discussion around the concept of "carrier SDN." Though that term has no particular meaning, it is usually taken to include some or all of the following: Reliability at a higher level than in private networks Ability to handle larger forwarding or rule (flow) table sizes Ability to handle multi-path networking (e.g., OSPF, ECMP) Multi-carrier setup (e.g., multiple authority domains, analogous to the S9 interface in 3GPP) Ability to scale to very high traffic levels Ability to meet latency and other QoS requirements Support for hybrid networks running both virtualized and unvirtualized network functions Telco OSS functionality Orchestration and management tools Ability to use policy control as a primary controlling mechanism Northbound API[s], standardized or not, from controller to application layer From a carrier point of view, OpenFlow as it currently stands only takes them so far. SDN architects have focused mainly on Layer 2-4 functionality, between the control and data layers. Even so, it is unclear how session partitioning and steering can be implemented with the subscriber experience in mind. While the ONF * The per-device, per-hop behavior of a router gives little control over the data flow. The SDN can allow a holistic flow. This might be useful for, e.g., transit balancing, where an operator might prefer to use equal-cost-multipath-routing, but the links are unequal in bandwidth or the utilization is unequal to some large flows. This issue results in a lot of manual tuning of costs on a BGP. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 7

8 architecture describes a higher "applications" layer, linked to the lower layers by a set of so-called "northbound API[s]," it does not set any specific rules or describe any elements at this layer in further detail. Will this northbound API (or APIs) be standardized? This question remains open for now. The ONF has gone on record opposing such an approach at present, arguing that the market should decide what technical approaches work best though this does not, of course, preclude the possibility that de facto standards might emerge, or that carriers themselves might demand some minimal level of standardization, perhaps to ensure adequate interworking across network boundaries. The ONF has a number of working groups looking at carrier-related issues. These include working groups on Optical Transport, Migration, Architecture & Framework and Extensibility. Other groups, including IETF, are also tackling aspects of SDN. The NFV initiative is further contributing to this effort by looking specifically at virtualization issues, such as portability between different hardware vendors and hypervisors; managing, orchestrating and securing flows; achieving operational scale through automation; and integrating virtualized appliances from different vendors. In the meantime, carriers are beginning to issue RFIs and RFPs for hardware and software that enable them to virtualize and open up network functionality. While it is much too early to be sure what will happen and when, some common themes are emerging. In initial research with both operators and vendors, Heavy Reading reached the following interim conclusions, among others: There will be no big bang. Operators will focus on specific areas to virtualize first, based on a range of criteria. Operators are looking to major vendors to help them understand how to apply SDN in the specific circumstances of a public network. Network virtualization, led by network divisions, may take place independently, or may be deployed alongside cloud and IT-based virtualization initiatives. Many operators are looking at the control layer as the place to start with SDN and virtualization initiatives. There is interest in applying SDN or NFV principles in new service areas such as M2M or OTT applications support. Summarizing, SDN and related programs around cloudification and virtualization have developed very strong momentum within the carrier industry. During 2013 we expect activity to focus mainly on RFPs, trials and pilots as network operators seek to understand how SDN and virtualization will work in a carrier environment, and where the gaps and pitfalls are. In 2014, we expect small-scale deployment to begin, with more extensive deployment to follow in HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 8

9 Policy & SDN: Well-Matched, but Still Work to Do Most of the initial debate around carrier SDN has assumed that policy control of some kind will be a key aspect of SDN but without much in the way of a detailed view of exactly how that will work in a virtualized, cloud-based service and network environment. To see how policy might fit, we need first to look back at our model in Figure 1. The existence of an entity called the "SDN controller" in the ONF architecture has led to some confusion. If this is a "controller," could it in itself be a policy controller? The answer at present is, probably not, though it may handle some simple policy-like tasks on the network side. In theory, the SDN controller could infer "policies" directly via APIs from elements on the northbound side, such as application servers, as well as from southbound elements in the data path, especially DPI; the OpenFlow API supports a certain level of packet classification and actions directly. However, this approach would burden the SDN controller with tasks it was not really designed for. It also implies at least in some variations on this theme that the applications could directly control the way resources are allocated via a publicly available API. This strikes us as unlikely, given that most applications are "over the top" and network owners are reluctant to allow third parties direct access to network functions. A more likely scenario, we believe, would see the existing telco policy server, or PCRF, being adapted to act as the "controller's controller." Just as it does today, the PCRF would take feeds from a wide range of sources including charging systems, network probes, DPI and related software, AAA, subscriber profile repositories, analytics systems, CRM and so on to which it will connect using established Diameter interfaces such as the Rx interface, and use this information to apply policy decisions to specific network flows telling the SDN controller how to route a specific flow, for example, by adding appropriate QoS marking, tunneling or steering to an appropriate network function. In other words, policy controllers and SDN controllers could be highly synergistic: Acting as the brains of the system, the policy controller tells the SDN controller how to route a specific flow, working closely with other elements in the service chain such as DPI, video optimization and firewalls. However, much of the detail remains to be worked through, and there are some significant issues to resolve. For example, there is on the face of it an architectural mismatch between the flow-oriented SDN controller and the "point"-oriented policy controller. The latter is tied to an access gateway where a user's tunnel terminates, simplifying policy enforcement. But while the policy controller deals with a single point (e.g., a specific GGSN or PCEF), the SDN has to deal with a path in which packets may take one of a number or routes at each fork creating either uncertainty that resources are available to fulfill a policy, or necessitating wasteful over-provisioning of all possible links. A second issue is that (decoupled) control plane latency in an SDN could be longer than some (short) network events a problem that will be exacerbated in LTE, with its very low latencies. In light of issues like this, the precise nature of the relationship between SDN controllers and policy control (as well as the 3GPP control plane in general) remains to be resolved. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 9

10 Many currently available PCRFs are already housed on COTS hardware (e.g., IBM Blade Center, HP) and run in x86 environments Well-Suited to Virtualization? At a hardware level, the PCRF, along with other related elements in the control layer, are relatively well-suited to virtualization. Unlike core elements such as the GGSN, many currently available PCRFs are already housed on commercial offthe-shelf (COTS) hardware (e.g., IBM Blade Center, HP, etc.) and run in x86 environments. Many vendors have already begun to virtualize their policy gear, internally at least, and some vendors are running their own functions in a virtualized environment, in the sense that all the functions they offer are housed in common, and capacity can be reallocated to different functions on demand. Hence the most advanced vendors are already well on the way to full virtualization. These developments support the view (which we found in survey work was quite widespread in the operator community) that the control layer may be a good place to start on the road to virtualization. Not all of the elements here can immediately be ported to an x86 environment: Both operators and vendors accept that some equipment that lies in the data path, including DPI, may need specialized high-speed ASICs or packet processors, at least for the next few years, such as to minimize traffic latency (this is also true of, for example, the P-GW function in 4G LTE). Moreover, some operators may prefer engineered hardware platforms that have been hardened and tested to meet carrier needs. This is an area of debate: Some operators think this would diminish the value SDN and NFV, and want to deploy certain non-critical functions on true generic servers as soon as possible; the argument runs that, with an effective management layer that builds redundancy into the hardware environment, there is no need any longer for "five nines" box reliability. But we doubt that major public operators are ready to put operationally critical data plane functions such as P-GW on such servers, and a compromise between "generic" and "proprietary" may continue for some time yet. An alternative scenario sees operators virtualizing P-GW and the like onto generic servers, but only for certain new service environments, such as M2M; a similar idea is to use virtualized capacity to flex capacity, in a way analogous to hybrid clouds with a private cloud that calls on public cloud capacity when necessary. Either way, in order to create a degree of certainty for vendors, operators will need to define the required hardware architecture in terms of expected requirements for memory, compute, power, throughput, etc., perhaps at a per-function level, and this remains a work in progress for many. But the general trend is clear, and virtualization in the control layer is likely to begin among pioneering operators late this year or in Can Policy Put the Subscriber Back Into SDN? SDN as it is currently described lacks awareness of the subscriber as that term is understood by carriers. Carriers uniquely enjoy direct one-to-one relationships with customers, through their CRM systems, billing relationships and (latterly) policydriven tools such as Web portals and dashboards. This marks them off from other value-chain participants such as major Web destinations like Google or device makers such as Samsung, and defending this unique relationship is key to the future strategy of most telcos. However, the ONF's SDN does not consider end users explicitly; instead, it is mainly focused in the upper layers of its model on the concept of applications. In a HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 10

11 recent white paper, for instance, the ONF writes of "a logically centralized network control layer that maintains a global inventory of all network resources and completely controls resource allocation in response to evolving applicationspecified traffic demands" [emphasis added]. Applications, in this model, drive the network, requesting what they need, but without any explicit reference to what subscribers need, or are entitled to. The need to support tens of millions of subscribers, sometimes on the move, with the level of service they have paid for, is a major challenge for SDN. Could policy control help to fill this gap? The ONF paper just cited itself recognizes the possibility: "The open API above the SDN control layer enables operators to create their own methods for distinguishing flows and algorithms for determining treatment, such as integration with Policy and Charging Rules Function (PCRF)." Extending this thought, policy control in its broad sense, including elements such as subscriber profile repositories, policy enforcement systems, analytics tools and network probes can all help to make SDN controller decisions "subscriber-aware." To retain complex subscriber state e.g., subscriber X is at (currently congested) location Y using device Z and running application A; subscriber X is a gold tier user with xgbyte of remaining quota during a given session, and then make the right routing decisions based on that state information, is beyond what an SDN controller is currently designed to do. An SDN controller might be able to base decisions on a network address, for instance, but cannot in itself know subscriber state. It will need to be told what to do by another entity or layer a policy controller by any other name. In this way, the SDN controller won't itself need direct knowledge of subscriber state to make its routing decisions, and can focus on lower-layer routing issues. A virtualized network environment creates some new challenges for the carrier which subscriber-centric policy control can help to address. For instance, it creates major issues in scaling horizontally and in dealing with traffic asymmetries, in which upstream and downstream traffic follows different routes due to the use of multiple load-sharing paths, e.g., Open Shortest Path First (OSPF) or Equal Cost Multipath Routing (ECMP). If the SDN controller is indirectly aware of subscriber state and requirements, it can ensure that these asymmetries do not affect subscriber experience in such a way that set policies are violated. However, enabling this awareness is a challenging problem, given that asymmetries are packet by packet, not user session by user session. Carriers also must scale routing and other network functions across virtualized general-purpose CPUs in server farms, with thousands of virtual machines (VMs) running instead of one static machine or appliance, and must maintain appropriate quality on a session basis. There is a need for session-aware load-balancing on the interface between infrastructure and control layers, so that flexible and intelligent partitioning of resources occurs. Again, this is something that a policy controller can help to resolve. An individual subscriber may have several sessions running on different devices on the same connection and subscription; without subscriber state and profile, it may be difficult for operators to provide a consistent level of service. However, much of the detail remains to be resolved here, and there is a general recognition that functions such as load balancing will be a lot more challenging in an environment where basic functions are running as VMs on generic servers, and where there is per-packet session steering across the network to the VMs. Most HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 11

12 operators believe a new management and orchestration layer is required, among other things to provide carriers with absolute assurance that resources will be available to meet critical network needs. Since most operators don't want to be tied to a specific hypervisor or management layer vendor, there is support for an open approach, perhaps based on OpenStack, but there is no consensus yet on who will supply this layer, whether all vendors will converge on one approach (or a small number of ecosystems), or whether (some) operators will develop this for themselves. Again, this can be considered to be a work in progress for now. Either way, carriers will need reassurance that functions all housed on the same types of hardware can still realize the varying levels of service required by individual subscriber sessions. A related issue is that if the SDN model is to realize its potential, it should be possible for a specific subscriber session to be steered to an appropriate function, using OpenFlow, based on the various policy triggers laid out earlier (e.g., application, device, location, congestion level, etc.). These functions could include things such as optimization, parental control, caches, security firewalls, etc. Hence policy again can make an OpenFlow network subscriber- and sessionaware. If the SDN model is to realize its potential, it should be possible for a specific subscriber session to be steered to an appropriate function, using OpenFlow, based on the various policy triggers. How this happens in practice raises some challenging issues. If a specific flow needs to be steered, for example, to various stateful functions, such as a NAT, a firewall, a video optimization entity or a parental control entity, it will be necessary to understand the constraints on each of these functions: An overflow on any specific function will compromise the system. Conventionally, this problem is handled by application delivery controllers associated with each function, but this does not translate well to the VM world. Another issue is one of determining the right balance between centralized and distributed control. Some operators have taken the view that policy control must remain centralized to avoid conflicts and confusion, and the OpenFlow model itself operates on the principle of a logically centralized SDN controller that maintains a complete picture of all network resources and "completely controls resource application," but in reality some policy control decisions today are taken closer to the edge by other kinds of devices such as policy enforcement equipment or software, either to reduce the load on the centralized policy server to manageable proportions, or for pragmatic operational reasons (e.g., to cache local content, or to meet very low latency requirements). One way to achieve this in SDN might be to include DPI capability directly in the switches themselves, as suggested in a recent Bell Labs paper, though there is no consensus around this as yet; this could also be used to relieve pressure on the SDN controller itself, by allowing the switch to handle simple functions directly. Open Interfaces: Expansion, or Consolidation? Finally, there are questions around how the "northbound API" layer will enable carriers to interact more fruitfully with content and applications owners. Some carriers have active applications ecosystems designed to expose certain capabilities to third parties via APIs, and in an SDN, this should be easier to achieve. Again, this is an area where policy controllers might help, since operators are already HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 12

13 using them to help expose capabilities on a controlled basis to third parties. Hence if a particular content owner seeks to provide a specific level of quality to support a specific customer, a policy controller can handle this request, bridging between the network (via the SDN controller) and the third-party application server, in much the same way that IMS was originally supposed to do. A fourth issue is the long-term status of the current, complex 3GPP model with its many interfaces. Could SDN help to collapse these interfaces, eliminating some of them? It seems likely that Diameter signaling, already widely deployed to handle signaling among 3GPP entities, will continue to be needed to direct flows between the policy controller and the various other entities it will need to call on for help in making policy decisions. But with fewer interfaces and entities, SDN may help to manage the complexity of this signaling and reduce the very high signaling load on the PCRF. In addressing these challenges, a policy-controlled SDN environment can ensure that carriers are not focusing simply on the network capex and opex savings, but also on the other core objective described above: a better service creation and service differentiation environment. SDN means that operators no longer have to introduce services network-wide, with complex upgrades to all the impacted hardware and appliances, but can offer fine-grained services selectively, portioning the network using virtualization to support various new use cases, and easily scaling up or down to meet demand. This emerging SDN-enabled environment is perfectly complemented by the new generation of subscriber-centric and (increasingly virtualized) policy software. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 13

14 Conclusion: Issues for Carriers to Consider In this paper, we have described the relationship between SDN and policy control, and suggested that, properly implemented, they will reinforce each other to provide a powerful mechanism for operators to intelligently design, operate and control networks and network flows, putting subscriber needs at the heart of decision-making. This is essential to meeting their business goals in an environment of both burgeoning opportunity and multiple threats to conventional carrier operations. Business as usual is no longer an option. In light of the impending shift to SDN, network virtualization and cloud-based operation, what should carriers consider when choosing policy control suppliers? Here are seven principles that should be part of the selection process: 1. Is the solution currently on the right mix of COTS and/or standard network cards and x86 hardware, and specialized hardware or software? And has it been fully tested on the preferred hardware platform[s] of the operator, in the environment (e.g., a data center or CO) in which it will reside? In principle, a fully generic environment will generate the highest savings, but in practice the solution may (initially) be a hybrid of off-the-shelf and engineered elements. 2. Does the vendor have a clear and convincing plan and timeline for a virtualized version of its product? Does this plan include orchestration and hypervisor choices that meet the carrier's needs? Although carriers may vary in how aggressively they shift to virtualized platforms, most will now want to know that the option is at least available on a firm timeline. 3. Is the solution available as an independent capability, or must it usually be deployed alongside other functions from the same vendor, such as BSS (billing) or network (gateway) functions, or the SDN controller? Some vendors are virtualizing their own functions, but not necessarily looking to create open interfaces to thirdparty functions and applications. 4. Does the vendor plan to offer its solution as a service in the cloud that could increase a carrier's options and flexibility? Is the service appropriate for cloudbased delivery, given the additional latency this may entail? 5. How does the vendor retain subscriber state across a virtual environment, and what state information can be utilized to help with SDN routing decisions? As noted earlier, there are some major issues here in marrying point-based policy to flow-based SDN, and in retaining subscriber state across paths that may include a variety of functions with different constraints. Solutions may vary vendor by vendor while the industry works to solve these issues. 6. Does the product include analytics functionality critical to closing the loop in emerging control layer environments? In principle, SDNs and virtualization increase flexibility and agility, enabling operators to respond promptly to changes in subscriber needs, but without automated real-time analytics, this capability may not fulfill its promise. 7. Does it have a proven history of interoperability? Though SDN may not retain 3GPP interfaces in their entirety, ability to interoperate with today's interfaces, such as Diameter signaling and legacy billing, will continue to be important. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 14

15 Industry View: Sandvine Sandvine brings intelligent network policy control to fixed, mobile and converged networks, through its solutions portfolio which provides operators with end-to-end policy control functions: business intelligence with network analytics, DPI traffic classification, policy decision and enforcement across multiple data planes. Sandvine is constantly evaluating emerging technologies in order to ensure that operators, and their current and future subscriber base, continue to benefit from best-of-breed policy control solutions and a dynamic open ecosystem. SDN Underpinnings: Hardware Best Suited for the Task As a basis of policy control, the Sandvine platform is deployed in complex network environments to identify network conditions, evaluate operator-defined business rules in real time to make policy decisions, and enforce those policy actions across the operator's network. Today, this platform is provided to customers on the bestsuited hardware and software: Some components are sold in virtualized COTS environments, while others require the use of custom ASICs and NPUs not generally found in commodity hardware. These various platforms-of-choice highlight Sandvine's desire to leverage the technologies that best fit each function's tasks. The rise in visibility and popularity of SDN is a means to lower capex and TCO in an era of ever-tightening budgets and hardware commoditization, thus enabling rapid delivery of customer services and network functions by IT and network operations. Furthermore, the carrier's intent, ability and confidence to proceed with SDN can be reinforced if it possesses the ability to select best-of-breed products from supplying vendors, while preventing a hardware forklift of the underlying legacy infrastructure. As carriers look towards offloading network functions and applications to general purpose hardware, the industry implicitly infers that such general purpose hardware could not be supplied by those same network function vendors. But that is not the case. Carriers wishing to embrace SDN and NFV rely on a trusted relationship with their network function vendors to provide pragmatic guidelines for a trusted reference architecture for "Infrastructure as a Service" or private cloud environments. Such architecture acknowledges a certain level of abstraction of hypervisor and hardware requirements, while maintaining custom hardware where network requirements for throughput, latency and reliability cannot be met. SDN Challenge: Orchestration of Virtualized Network Functions The existence of complex asymmetric data paths in the packet network requires more scrutiny to be paid to subscriber states, sessions and data flows, in order to efficiently make use of the gains afforded by SDN and NFV. An operator must now, more than ever, carefully assess the access, distribution and core network paths to ensure that asymmetry and multi-path routing are handled with intelligence by a control plane that is able to steer traffic in and out of the network functions cloud with full subscriber, state and function capacity awareness. Sandvine's Policy Traffic Switch (PTS) can be deployed across multiple data plane links to handle traffic asymmetry and, due to its full subscriber and application awareness, it is expressly suited to steer session-based traffic through an application delivery network intelligently, while ensuring capacity and scale requirements are satisfied across the virtualized network functions, much like an application delivery controller. The Sandvine PTS is a key infrastructure element in the SDN solution space, since it leverages its knowledge and classification of subscriber sessions to intelligently steer traffic. When coupled with the Service Delivery Engine (SDE), the operator possesses the building blocks of an SDN-enabled carrier network with a rich open ecosystem. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 15

16 Figure 4 Sandvine Within SDN Reference Architecture Source: Sandvine Operators' renewed and focused interest in automated and on-demand network provisioning and configuration, as provided by SDN efforts driven by the ONF, means that vendors have found an opportunity to open platform interfaces and enable greater interaction between functions in a policy control environment. APIs such as OpenFlow, and OpenStack for IaaS offerings, are not new to the industry but have largely been proprietary and remained within the confines of a vendor's portfolio to ensure interoperability and provisioning within its commercial platform portfolio. In this regard, the capabilities of Sandvine's policy control portfolio highlight parallels of the fundamentals of SDN whereby application, control and infrastructure layers are decoupled and open, while maintaining their capabilities as a whole. The PTS utilizes its DPI visibility and subscriber awareness to intelligently divert relevant traffic, from those users who have subscribed to specific services, to value-added services in an open ecosystem, and it enforces the policy actions dictated by the SDE control layer. Holistically, SDE provides control layer interfaces in 3GPP, Packet- Cable, AAA and B/OSS, integrating smoothly into an SDN environment. When coupled with SDN interfaces such as OpenFlow client and controller APIs, the SDE can extend existing PCC interfaces such as 3GPP Gx, Gy and Sd into an advanced dynamic network based signaling framework. Business applications, such as Network Analytics and Usage Management for service plan creation, drive the specifications of business and policy rules to the SDE. There is wide opportunity for other applications, such as Fairshare Traffic Management for congestion management, to set additional policy rules that are aligned with the operator's business objectives. HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 16

17 Background to This Paper About the Author Graham Finnie Chief Analyst, Heavy Reading Graham Finnie has been working as an analyst and consultant in the telecommunications sector for more than 20 years. He joined Heavy Reading in 2004, following a 10-year tenure at the Yankee Group, and has been responsible for a wide range of research, focusing primarily on next-generation broadband networks, services and applications. He became Chief Analyst at Heavy Reading in Finnie's most recent report for Heavy Reading is RAN Congestion Control & the Road to QoE, published in September Finnie is also responsible for the Policy Control & DPI Market Tracker. Finnie has also hosted numerous Webinars and Live events for Light Reading, and is a regular speaker at other major industry events. Before becoming an analyst, he was editor-in-chief of the award-winning industry paper Communications Week International. Finnie is based in the U.K. and can be reached at [email protected]. About Heavy Reading Heavy Reading ( is an independent research organization offering deep analysis of emerging telecom trends to network operators, technology suppliers and investors. Its product portfolio includes in-depth reports that address critical next-generation technology and service issues, market trackers that focus on the telecom industry's most critical technology sectors, exclusive worldwide surveys of network operator decision-makers that identify future purchasing and deployment plans, and a rich array of custom and consulting services that give clients the market intelligence needed to compete successfully in the $4 trillion global telecom industry. As a telecom research arm of the Light Reading Communications Network ( Heavy Reading contributes to the only integrated business information platform serving the global communications industry. Heavy Reading 240 West 35th Street, 8th Floor New York, NY Phone: HEAVY READING MAY 2013 WHITE PAPER POLICY CONTROL & SDN: A PERFECT MATCH? 17