SOFTWARE DEFINED NETWORK AND NETWORK FUNCTIONS VIRTUALIZATION An Inevitable Evolution for Communication Networks

Transcription

1 SOFTWARE DEFINED NETWORK AND NETWORK FUNCTIONS VIRTUALIZATION An Inevitable Evolution for Communication Networks VIKRAM NAIR Director, Technology VINOD KUMAR GUPTA Senior Technical Leader, Technology

2 SOFTWARE DEFINED NETWORK AND NETWORK FUNCTIONS VIRTUALIZATION An inevitable evolution for communication networks Introduction Traditional communications network equipment was built over proprietary software platforms tied onto proprietary hardware that evolved slowly, being in a walled garden. This approach forced service providers to deal with issues such as longer timeto-market and end of life equipment. Decoupling underlying hardware from software, through standardized interfaces, and deploying software solution over COTS (Commercial off the shelf) hardware has been a successful shift witnessed in past years. This enables operators in buying hardware and software platform from a variety of different vendors with no inter-dependence of hardware and software on each other. For example a soft-switch (that is used for VoIP call setup) is a software implementation decoupled from media gateway used to switch voice traffic. As the standardization of this solution is at infancy, today s communications network industry has yet to fully embrace this hardware and software decoupling in the coming years. Software defined networks (SDN) and network function virtualization (NFV) is a new development that builds on a premise to decouple hardware and software solutions, and further host software functions over a virtualized platform to achieve cost efficiencies with limitless flexibility for network configuration and operation. This paper starts with describing SDN and NFV technologies and their relationship. Then it discusses the accelerators driving adoption and challenges impinging the adoption of the technology. The paper then captures the applicability of SDN and NFV technology for mobile networks, for example, the segments or sub-systems where SDN and NFV can be introduced by service providers. It also provides a few use cases that can be realized through the technology introduction and the benefits that such solutions can yield. The paper also highlights key considerations for rolling out SDN and NFV technology. Finally, the paper summarizes the essentials requirements for testing SDN and NFV technology for successful deployment. Trends and Insights SDN and NFV will bring fundamental shift in CSP s approach to build network infrastructure. The network transformation is expected to happen in a phased manner, which will not only help mature the technology introduction methods and processes but also de-risk disruption of network services. Today, networks are built in silos wherein independent infrastructure is deployed for mobile, fixed, and enterprise markets with minimal or no infrastructure reuse or sharing. Realizing the benefits from virtualization, Communications Service Providers (CSPs) are 1

3 Now Next 2-3 Years Next 5+ Years Network Silos Component Virtualization Network virtualization - expected roadmap Network Virtualization stepping up the efforts to analyze the impact of virtualization on networks and O/BSS. It is expected that initial targets for virtualization will be the software components with minimal or no dependency on underlying hardware. In the next 2-3 year it is expected that first step towards virtualization will find its place in the networks wherein selective independent network components will get virtualized. For instance, in LTE networks, network components that are software only implementation with no specific hardware dependencies such as MME, IMS, PCRF, HSS will be the first target. OSS transformation will happen simultaneously to manage virtual assets. This phased transformation will require OSS to support both legacy as well as virtual assets with an external management system to manage the virtualization platform infrastructure. In the next five years, it is expected that majority of network components will get virtualized enabling CSPs to sell Network as a Service (NaaS). Additional network components which earlier were not targeted for virtualization because of their dependency on hardware platforms will see de-coupling of such components into control & data plane functions, with control plan functions being pushed onto virtualization platforms. For instance, in LTE networks, such network components will be deep packet inspection (DPI), serving gateway (SGW) and packet data network gateway (PGW). This phase will have OSS transformation to not only manage the virtual assets but also the virtualization platform infrastructure in a holistic manner. SDN is a new approach to networking in which network control is decoupled from the data forwarding function and is directly programmable. The result is an extremely dynamic, manageable, cost-effective, and adaptable architecture that gives administrators unprecedented programmability, automation, and control, through abstraction of the underlying infrastructure. Implementing SDN via an open standard enables extraordinary agility while reducing service deployment and operational costs, and frees network administrators to integrate best-of-breed technology as it is developed Open Networking Foundation [1] Decoupled control and data planes help you build a centralized control plane that manages large number of data plane equipment, which is spread across network. The control plane comprises SDN controller that interfaces with data plane switches and enforce packet treatment rules on data plane switches. Standardization attempt are underway in defining control protocol (OpenFlow) between SDN controller and switches. SDN primarily targets layer 2 and layer 3 infrastructure components. The SDN controller, in addition, exposes north bound interface using which many additional services can be built or extended through service chaining and orchestration. Examples of such services are discussed in detailed in subsequent section on use cases. The following diagram shows the high level network architecture for Software defined networks. Resilience Orchestration Layer SDN Services Service Chaining Traffic Management What are SDN and NFV SDN Controller SOFTWARE DEFINED NETWORKS (SDN) In traditional networking paradigm, a data packet arriving at conventional equipment (switch / router) is treated with a set of rules. These rules decide how the inbound data packet are treated and marked such as forward, duplicate, drop, (de-) tunnel, network address translation (NAT) or quality of service (QoS). Such equipment is not only expensive but also is a challenge to manage as the equipment are distributed across the network and may require synchronization of configuration. Open Flow vswitch Switch Switch Switch Switch Architectural Diagram for SDN 2

4 The decoupling will also result into CAPEX optimization by virtue of commoditized de-coupled data plane equipment. For instance, by introducing SDN into networks, CAPEX requirements for backhaul networks globally will reduce by more than $4 billion by 2017 as per a recent research report [3]. MME SGW HSS PCRF PGW Early benefits of SDN will be greater internal efficiency, reduced operations costs and higher reliability of the network due to greater automation and less room for human error. UE enodeb Internet Ultimate goal is that end customers will be able to interface their service provider s network and integrate services on an automated, software-controlled basis. NETWORK FUNCTION VIRTUALIZATION (NFV) Virtualization started with having discrete applications hosted on cloud platform. Driven by the benefits realized through cloud hosting such as scalability, resilience, reduced OPEX, usage of the virtualization technology for communication networks is a logical evolution. Cloud appeals because of its potential to lower down risks, costs, and time-to-market, while increasing agility and flexibility to experiment with new offerings. Top-line and bottom-line benefits play into decisions regarding adoption of cloud. Network Functions Virtualization aims to transform the way that network operators architect networks by evolving standard IT virtualization technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in datacenters, network nodes and in the end user premises. It involves the implementation of network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in, various locations in the network as required, without the need for installation of new equipment ETSI [2]. Early implementations of NFV would target moving those applications on cloud infrastructure that is hardware independent. OSS, BSS and certain VAS applications are example of such applications that are part of mobile networks. Subsequent to that, attempt will be to decouple the control and data plane implementations of other infrastructure elements to enable migration of control plane software onto cloud and deploy commoditized data plane equipment in network. Consider as an example a LTE network as shown in a high level network architecture diagram below. Each network element excluding the enodeb radio node is typically deployed on a separate hardware unit in data centers. Out of these network elements some are software implementation of control plane protocol and procedures and others require additional specialized hardware function for traffic handling. UE enodeb LTE Network Architectural Diagram For instance Mobility Management Entity (MME) network element falls under the category of network elements that implement control plane protocol and procedures for managing end-to-end data service. Other network elements that will fall under same category are HSS and PCRF implementing control plane protocol and procedures for subscription and policy control respectively. Such network elements can be moved onto centralized cloud platform as shown in the diagram below. MME SGW HSS PCRF PGW Internet Proposed LTE Network Architectural Diagram with NFV (some NEs) The concept can be further extended for other category of network elements that implement control plane protocol and procedures along with traffic handling i.e. Serving Gateway (SGW) and Packet Data Network Gateway (PGW). These categories of nodes can be split into two entities the control plane and data plane functions. The result will be SGW-Ctrl and SGW-Data for SGW node and PGW-Ctrl and PGW-Data for PGW node. The split will enable moving the control plane functions i.e. SGW-Ctrl and PGW-Ctrl onto centralized cloud platform and data plane nodes i.e. SGW-Data and PGW-Data network switch be deployed during network rollouts to meet traffic handling requirements. 3

5 UE enodeb SGW Data MME SGW-Ctrl PGW-Ctrl OpenFlow Switch PCRF HSS PGW Data Internet Proposed LTE Network Architectural Diagram with NFV and SDN Though, this split is not defined completely as part of specifications, however this is another example of implementing NFV. Additional virtualization use cases would also emerge for Radio side such as Cloud RAN which are discussed under subsequent sections. The pyramid above represents the standard OSI reference model [5], which is also a generic representation of any network component. SDN and NFV combined will target virtualization of layer 4 till layer 7 and also layer 3 partially. From standardization perspective, ONF [1] is focusing on splitting layer 3 into control plane and data plane wherein layer 3 control plane can be deployed in a virtualized environment. ETSI [2] on the other hand is focusing on virtualization of layer 4 till layer 7. What this means is that NFV functions (actually telecom function apps) can sit on top of SDN and leverage (use SDN as a service) cost effective SDN routing/switching/transport and enable unprecedented efficiencies in terms of resource utilization, configuration, customer interface/support. The venn diagram below shows that SDN and NFV are mutually exclusive technologies but maximum benefits of SDN and NFV can be achieved when these are coupled together with open innovative apps on the top. Use cases and accelerators describe benefits in detail, which are covered in subsequent sections. Additional network element (Open Flow Switch) shown in the diagram above is introduced as part of section on SDN. SDN and NFV Relation SDN and NFV emerged as independent concepts and are self-sufficient for the purpose they were built for. The two technologies are complementary to each other and do not compete against each other. Combined implementation of SDN and NFV will maximize the benefits that are mentioned in subsequent sections. The scope of virtualization can be understood with the following diagram. Creates competitive supply of innovative applications by third parties Open Innovation Creates network abstractions to enable faster innovation Software-Defined Network Virtualization Scope Layer 7 Layer 6 Layer 5 Layer 4 App Layer Presentation Layer Session Layer Transport Layer Netowork Functions Virtualization Reduces capex, opex, space and power consumption Venn diagram interaction of SDN, NFV, Open Innovation Layer 3 Layer 2 Layer 1 Network Layer Data Link Layer Physical Layer To summarize, role of SDN and NFV when combined in an implementation can be understood as - decoupling control plane and data plane is what SDN recommends and moving the decoupled control plane (or the entire network equipment software functionality wherever possible) to a virtualized platform is what NFV recommends. Scope of Virtualization 4

6 Accelerators Driving Adoptions Numerous benefits across CAPEX & OPEX reduction ease of operation, flexibility and scalability is what will and is driving adoption of SDN & NFV technology. Few such benefits that can be realized through the technology adoption are:- CAPEX AND OPEX REDUCTION Service providers will be able to reduce their CAPEX and OPEX spend through SDN and NFV technology adoption. While CAPEX benefits will be realized by virtue of control plane functionality consolidation on cloud and commoditization of data switches, the OPEX benefits will be realized by virtue of reduction in power usage, space requirements and number of operational staff required for operation and maintenance Service providers can further reduce customer onboarding and support spend by deploying commoditized data switch equipment at enterprise customer premises as opposed to fully functional switch, and manage those switch through control plane in service provider s cloud environment. Thus reducing customer on-boarding and support spend. It is estimated that a CSP can have up to 50% direct CAPEX saving by adopting SDN in backhaul [3]. Some vendors are claiming 90% saving in CAPEX when purpose built hardware is replaced with high performance server and routers [6]. The ability to host multi-version for applications and multi-tenancy will further drive down costs for service providers. IMPROVED TIME-TO-MARKET Time to market will be drastically reduced in a SDN/NFV enabled network. Most of the solutions will be hardware independent and would use the same infrastructure, thus saving testing and integration time. Some of the services would become available by simply adding an app at controller software in a virtualized environment. EASE OF OPERATIONS Key benefit in operations will be homogeneity of the network and efficient management and flow control of mobile IPs. Centralization and less number of equipment will ease out configuration management, implementation, and also reduces risk of miss-configuration. There would be no need to login to individual equipment for configuration, hence will save time and resources. Virtualization will give a readymade platform for migration of network elements and services to cloud. Scalability and multitenancy capabilities on virtualized platforms will enable easy rollouts, upgrades and operations. OPENNESS SDN will provide an excellent platform for app development work, which will help in building advanced networks. Dependency from OEM to come up with innovative solution will be reduced that provides openness to the technology. Readymade apps from freelancers and domain experts will reduce cost and time for carriers. NEW REVENUE STREAMS Mainstream adoption of SDN and NFV technology will not only help drive down costs but also help create new revenue streams that to an extent will compensate for declining ARPUs. Dynamic programmability of network control elements coupled with open standard interfaces will enable rapid introduction of new revenue generating, value added services in network environment. For instance, a service that allows an enterprise subscriber to purchase additional bandwidth through an on-line portal. Such request from a subscriber gets orchestrated in a manner that the policies to grant additional bandwidth towards subscriber CPE/device get provisioned automatically at the network layer and at edge router. This dynamic programing of the network will reduce time to provision the policies in the network, if done manually from operations standpoint, resulting into quick upsell of existing data services. Example of such services/use cases is discussed in subsequent sections. TECHNOLOGY MANAGEMENT Managing multiple technologies, domains, vendors, skills processes and policies are always complicated and challenging. SDN and NFV will bring a common platform for technologies, vendors, and skills required to manage. Some of the direct benefits from technology management perspective are: > Improved automation > Common policy management and enforcement > Increased availability, reliability, scalability, multi tenancy and security > Easy deployment and up-gradation of new technology, features > Common skills set for resources to manage network Adoption Challenges SDN and NFV technology is evolving not only from technology standardization standpoint but also in terms of broad set of use cases that it can address to realize the benefits claimed. 5

7 However, there are challenges to be addressed before SDN and NFV technology get into mainstream adoption. Subsequent section mentions such challenges. STANDARDIZATION As the technology is in its nascent stage standardization of SDN controller APIs is not compete yet. For successful adoption of SDN and NFV technologies there is a need to have standardized APIs for traffic flow management, interconnect policies, and authentication and authorization with other network elements on priority. For instance, in the case of policy management, PCRF and SDN controller integration is required. While PCRF is a service/ application level policy enforcement entity also used in LTE network, SDN controller is a L2/L3 level policy enforcement entity for data network. Integration of these two entities is depicted in the diagram below. PCRF Gx Gx? TESTING AND DEBUGGING In a virtualized environment, network elements would be present in distributed fashion i.e. network elements providing same service can be placed at different physical location. So there is a need for specialized testing tools, which can collect data, analyze and report exact faults points. In a virtualized network it is difficult to ensure that traffic is properly routed. Dynamic behavior of traffic flow according to configuration and network load would add complications for testing. A rigorous testing is needed keeping in mind APIs, and multiple vendors for general purpose server and user experience. SECURITY As SDN / NFV are not matured technologies there are many associated security challenges. For instance, service provider would target 3rd party application providers to tap new business opportunities, which risks networks against security threats. To mitigate such security threats, a high level of security in terms of authentication and authorization is required for 3rd party applications that use network assets. Moreover, all controls would be concentrated at SDN controller and any intrusion at SDN controllers could impact the whole network. PCEF PCEF SDN Controller OpenFlow Switch Interface between SDN controller and PCRF As shown in the diagram above, interface between PCRF and PCEF (policy control enforcement function), labeled Gx, has been standardized by 3GPP. However, there is not much focus on standardization of APIs between SDN controller and PCRF, which implies no coordination between policy decisions across network elements. This is a big challenge for successful deployment of SDN / NFV and application development community. IMPLEMENTATION Migration would be a real challenge and needs a proper planning in terms of selecting network islands and prioritizing their upgrade keeping in mind minimum interruption to services, co-existence with legacy networks, rollback plans and QoS maintenance. MAINTENANCE Operators have already invested heavily in existing network infrastructure. Legacy infrastructure will co-exist for years to come. The migration to SDN/NFV will be gradual with specific nodes and functions being introduced as legacy equipment become depreciated or obsolete and based on SDN/NFV available feature set, resilience (carrier grade) and other operational attributes. Centralized control plane at SDN controller makes availability of controller an important aspect. Due to the above facts, fault Management (hardware / software failure) is going to be a big challenge, as it would not be easy to troubleshoot a problem in virtualized network with simple tools. PERFORMANCE Telecom networks are designed with the consideration to have minimum latency in the network to provide high throughput and low connection time. Maintaining a low latency is a main challenge. SDN and NFV will add more complications as single controller has to communicate with multiple nodes and maintaining its huge database will impact the performance. Controller-to-controller interface is not yet standardized which otherwise improve performance by load sharing. Special considerations are required for integration of SDN controllers as the technology is evolving and security aspects are not mature enough. 6

8 SDN/NFV Applicability for Mobile Networks SDN and NFV can be implemented in various segments and sub-systems of mobile networks using industry standard COTS hardware. Refer to the diagram SDN and NFV applicability in Mobile Networks below for few examples of segments/subsystems, which are elaborated subsequently. EPC VIRTUALIZATION With the advent of technologies like LTE and LTE-A, data traffic is increasing exponentially on timescale and this demand is expected to explode in the future. To meet the increasing demand, service providers would need more hardware, space and resources. EPC virtualization is an approach that service providers can leverage to optimally address the capacity and management requirements. Refer to section Network Function Virtualization above for details. Implementation of EPC virtualization is possible in many ways. For instance, one virtualized logical node can have multiple virtual machines (VMs) working as different network elements as shown in the following diagrams. Since each VM works in isolation and is independent of other VMs, they don t impact on performance of one another. These VMs can be configured dynamically (links, network topology etc.) as per required capacity and traffic pattern. MME MME MME Server OPTION 1: Several VMs of same software component can be installed on same virtualized infrastructure. No need for dedicated HW. EPC virtualization will help operators reduce CAPEX and OPEX and also enable dynamic optimization for rapidly changing needs. Other advantages are stated in the section Accelerators Driving Adoption. Security Functions Mobile Backhaul Server Load Balancer Provisioning O/BSS Software Defined Networks Network Function Virtualization Cloud RAN WAN Accelerator EPC Virtualization CPE Virtualization SDN & NFV applicability in Mobile Networks 7

9 MME SGW-Ctrl PGW-Ctrl Server OPTION 2: Several VMs can have different software components running on virtualized infrastructure. EPC Virtualization CLOUD RAN An operator s CAPEX, OPEX expenditure on RAN is much more as compared to core. Cloud RAN will have several benefits right from direct cost reduction (less civil structures, less hardware, less energy consumption) to enhanced capacity and dynamic and uniform utilization of resources. Today, cloud RAN architecture is evolving. Possible architecture would have a pole mounted radio head connected through fiber and RF signals transferred to baseband processers located in cloud. An illustrative diagram is shown below. The above architecture will optimize the requirement for baseband processing capacity as it gets shared across radio heads. Base Station hotel has been around for some time with centralized baseband processing and remote radio heads fed with fiber (up to 10-15km) but NFV provides opportunity to run baseband on inexpensive hardware. CPE VIRTUALIZATION Customer premise equipment (CPE) comprises two logical functions service control function and data switch function. CPE virtualization will enable service provider to host CPE service function within its own cloud environment and deploy standard L2/L3 switch at customer premises. The CPE Virtualization diagram shows architecture where CPE switch is replaced by a server which is running virtualized router and service code. The previous approach will not only save hardware cost and UE RRH Fiber PHY MAC O&M transportation cost of signaling, but also operational cost as the CPE service logic will reside in service provider cloud environment, which can be easily managed from remote location. This implies an efficient way to deploy, upgrade and configure CPEs. Baseband Processors UE RRH Cloud RAN Orchestration IP Edge SP NGN SP GW Centralized DC CPE Services L2/L3 CPE router with services functions running in SP Datacenter Internet CPE Virtualization 8

10 MOBILE BACKHAUL Mobile backhaul comprises a complex mesh and chained topologies designed for network resilience, traffic carrying capacity while delivering desired QoS. Introduction of SDN in mobile backhaul will enable managing backhaul capacity through optimal resource utilization and dynamic traffic management. In addition, it will also allow for co-existence of multiple technologies on the same mobile backhaul infrastructure. An illustrative diagram is shown below, wherein, a SDN controller, optionally running on a virtualized platform, makes decision on traffic forwarding and pushes the forwarding rules onto the switches deployed. SDN Controller This approach will enable implementation of many use cases as described in subsequent section. Service providers can benefit from implementing SDN and NFV in many other areas such as O/BSS, security functions (Firewalls, IDS/IPS, SSL, VPNs etc), server load balancers, WAN acceleration and provisioning systems. Use Cases As discussed in previous section, SDN & NFV can be introduced in many segments/sub-systems of mobile networks. This section presents few end-to-end use cases that can be realized by introducing SDN & NFV. DYNAMIC BANDWIDTH MANAGEMENT UE enodeb MME There is an increasing demand for bandwidth hungry services such as HD video on demand, online gaming, cloud based apps etc. To deliver these services with desired QoE there is a need for better bandwidth management. UE enodeb SGW By virtue of SDN, subscriber will be able to define his/her bandwidth need, allocate and make changes in required bandwidth dynamically. Bandwidth management can also be orchestrated by application or end user without involvement of service provider personal. A framework for dynamic bandwidth management is shown below in this section. UE Small Cell Mobile Backhaul Bandwidth Management Application Network Monitoring (OF) Bandwidth Management OpenFlow API Orchestration Logic SDN Controller Higher bandwidth allocation for network latency sensitive application FTP Server Online Gaming Servers Online Gaming Client FTP Client Dynamic Bandwidth Management 9

11 As shown in the diagram, the end-to-end traffic between online gaming servers and online gaming clients (shown by a solid green arc) is shaped to meet service QoS requirement. In a real world scenario such request for dynamic bandwidth allocation for a gaming service will either be ordered by the end user through a self-care portal or by the game provider. The bandwidth management application will orchestrate policies for network wide deployment and pass it to SDN controller which in turn will push required configuration in network switches. This auto provisioning will require no intervention from service operations teams. This business model wherein the service provider ties up with OTT players or directly sells on demand bandwidth services to end users will open up new revenue streams for a service provider to cope up with declining ARPU. WAN INTERCONNECT As an extension to dynamic bandwidth management use case, WAN interconnect will allow subscribers to design their enterprise level policies for shortest paths through the service provider network as per bandwidth requirement which have less latency or congestion and fewer hops across their networks. This assures network-wide load balancing beyond node-level load balancing, and reduces OPEX for service providers. DYNAMIC PROVISIONING Traditional network implementations require configuration of pre-defined VLANs, interconnections etc. without providing flexibility for dynamic provisioning. Introducing SDN, which implies a centralized SDN controller, optionally deployed on virtualized platforms, can be used to configure network switches as per the orchestration function that runs on a remote application server. The architecture enables implementation of many dynamic provisioning uses cases eliminating the need to pre-define VLANs, interconnection of VMs and configuration parameters. DEEP PACKET INSPECTION Deep packet inspection (DPI) has been used since a long time to identify and act on packet streams in the networks. The DPI solutions today has evolved into software based implementations that brings much better analytics for inspecting application level (layer 4+) traffic. The software DPI solutions are easy to manage, upgrade with new traffic signatures and are easy to deploy in the networks compared to traditional methods. DPI software solution, optionally deployed onto virtualized platform, can be utilized for scenarios such as offloading certain traffic streams to other technologies, for example Wi-Fi. APPLICATION AWARE ROUTING Content delivery networks typically comprise a large distributed set of content hosting and content delivery servers that are deployed across multiple data centers. Application aware routing (AAR) service can be used by service providers to route service requests to content servers that can best serve the request. The following diagram shows an architectural implementation of AAR service. The centralized request server, hosted on a virtualized platform, is the first hop for all the service requests from the subscribers. The centralized request router redirects service request to the content server that can best serve the request. The centralized request router acts as an application level (layer 4+) load balancer redirecting requests based on subscriber geographical location, availability of content in the content server, service availability, and content server load. Centralized Request Router Caching or Streaming Servers 2 Caching or Streaming Servers 3 4 Caching or Streaming Servers Online user 1 L7 Monitoring Probes Control Messages Data Flow Architectural implementation of AAR 10

12 Route Optimization Configuration Analytics and Reporting Network Monitoring Bandwidth Management Request Routing SDN Controller Caching or Streaming Servers Caching or Streaming Servers 2 1 Caching or Streaming Servers L7 Monitoring Probes Control Messages Data Flow Provisioning of Flows Online user AAR implementation with SDN AAR implementation can be extended further with increased application awareness, which can be built into the network by developing SDN controller applications that keep track of application-level characteristics and use that intelligence to provision flow into the network switches. VIRTUALIZATION OF CONTENT DELIVERY NETWORK As an extension to application aware routing (AAR), content delivery servers along with the content can also be hosted on virtualized platforms. Such improvements in network will simplify removal or changing location of content delivery components. Virtualization creates an isolation layer across virtual machines, which will enable hosting of multiple instances of content delivery from multiple content providers on same virtualized platform, which will optimize management and maintenance cost.. SERVICE CHAINING As an extension to application aware routing (AAR), service providers can further launch composite services by service chaining the service requests across multiple application servers in a pre-defined order. An example of service chaining is when a subscriber request for HD video service, this will first trigger dynamic bandwidth management service to allocate desired bandwidth to the subscriber for service consumption. Upon successful grant of bandwidth, the request is routed to HD video content delivery server to start HD video streaming. VIRTUALIZED AGGREGATION NETWORK Service providers can benefit by centralizing the control for aggregation network. The centralized control will manage the switches that are deployed in networks. This reduces operational overheads due to fewer touch points to provision and operate as compared to a traditional network. Key Considerations While the benefits of adopting SDN & NFV are multi-fold, which is evident from both the applicability of technology across mobile networks and also from the use cases discussed in earlier sections. However, there are few important factors that need to be considered in order to successfully implement the SDN and NFV technologies. In SDN architecture, the routing rules will be pushed by SDN controller onto the network switches. Since the network switches will not inspect the packet flows, there would be need for additional DPI and security solutions. Interoperability across network equipment supporting OpenFlow and also with IT systems would require verification as OpenFlow implementations are evolving. Service level policies (which acts on layer 4+ of the traffic) in mobile networks is decided by PCRF (policy and charging rules function), whereas policies for SDN networks (which acts on layer 2/3 traffic) is decided by SDN Controller. These two entities, namely PCRF and SDN controller, are yet to work in tandem, which means that service level policies at PCRF shall be linked with L2/L3 traffic policies at SDN controller. Network security might require network and process audit and redesign for access privileges, firewalls. For example, a scenario would be to detect and block applications generating unwanted traffic. 11

13 OSS and BSS would require enhancements to support SDN & NFV deployments. OSS transformation would be the key challenge that needs a detailed strategy and planning for architectural impacts and functional impacts. OSS need to support virtualized infrastructure and orchestrate virtualized network elements and virtual platform infrastructure. Additional support to legacy network is needed during transition. Following are some of the subsystems and processes for OSS functional domains (service assurance and service fulfillment) that get impacted. SERVICE ASSURANCE > Impacted subsystems - Fault and alarm management systems, performance and threshold management systems, configuration systems, security systems, service quality management systems, health monitoring systems, SLA management systems, reporting systems > Impacted Processes - Network and device configuration process, performance management process, capacity management process SERVICE FULFILLMENT > Impacted subsystems - Resource and service provisioning systems, network planning and design systems, activation systems, workforce management, network inventory modeling and management systems, capacity management systems, network discovery systems, reconciliation systems, GIS systems, reporting systems > Impacted processes - Inventory reservation and allocation process, Network element discovery process, reconciliation process, Service address change process, order modification processes, CPE management, IP address management, network and virtual infrastructure capacity management process, service activation process South bound interface for SDN implementation is defined, which is OpenFlow. However, the north bound interface is yet to be defined. Service providers should consider defining this interface so that it is future proof. Early implementations from OEMs might have proprietary extensions and could impact successful interoperability NFV will not only bring change in how service is delivered but also on how the service is monitored. There will be a shift from measuring hardware downtime to service downtime. Therefore, resilience shall be built in the service software running on virtualized platform to instantly start up a new virtual machine on capacity overrun or an instance crash. NFV would also mean many virtual machines in multiple locations. Service operations should be planned for upgrade, patching, failure recovery across each virtual machine. Testing SDN and NFV Technology With advent of new technologies like SDN and NFV, the test methodologies also require change which spans across knowhow of the technology, and specialized testing and diagnostic tools to troubleshoot problems in this complex network environment. Options of putting test tools and test infrastructure on cloud is a natural evolution for test setup leading to resource optimization. Subsequent section gives high level guidelines on scenarios that should be tested for successfully introducing SDN & NFV technologies in the network. OPENFLOW TEST SCENARIOS (FOR SDN) > Control Channel functional testing to verify signaling protocol e.g. connection setup, failure, and interruption of a control channel. > Conformance testing of protocol messages including negative scenarios. > Spanning tree protocol testing to test port state and its configuration message > Flow administration and management testing to verify the requirements for adding, editing, deleting and removing a flow along with flow table. > Counter value verification per flow, per port, per queue and per table. > Data plane testing to verify supported actions by a switch. TEST RECOMMENDATIONS BASED ON ETSI REQUIREMENTS FOR NFV > Interoperability and Integration testing shall verify that the NFV framework is capable to re-host, optimize, and load integrate Virtualized network functions (VNF) in a standardized multivendor environment. > Performance testing shall verify that the NFV framework is independent of HW used and framework shall be capable to collect performance related information. > Security testing shall verify that the NFV framework protects network from E2E vulnerabilities (new HW, interfaces, third party entities) and provide authentication, authorization, data encryption, data confidentiality and data integrity. > Scalability testing shall verify that the NFV framework is capable of scaling VNFs (scale up and scale down) and moving its components from one computing resource to another. > Resiliency testing shall verify that Network functions are capable to recover after failure and the NFV framework is able to classify Network functions according to resiliency and facilitate resiliency scheme in both control plane and user plane. > O&M testing shall verify that the NFV framework is capable to provide mechanism for automated O&M (creation, scaling and healing of VNFs based on pre-defined criteria) 12

14 > Service continuity testing shall verify that the NFV framework is able to restore services (recover VMs, provide alternative solution) as per SLAs. > Co existence and transition testing shall verify that the NFV framework co-exists with legacy network and supports transition phase (interwork with O/BSS, ensure security of VNF instances during transition) > Service assurance testing shall verify that Network functions are remotely accessible, monitored, and can perform diagnosis. 3GPP COMPLIANCE TESTING For EPC virtualization scenario as described in sections above, protocols and messages flow across the network will be impacted because of the architectural changes. Therefore compliance to 3GPP specs is a must to facilitate multi-vendor eco-system. > Exhaustive conformance testing is highly recommended for all virtualized telecom equipment. > KPI, Load, Capacity testing should be performed to raise overall QoE. > A new protocol that would get defined between control plane and user plane of S-GW and P-GW, would require thorough testing. NETWORK TESTING There would be significant changes in the network, when SDN / NFV are pervasively deployed. It is extremely essential to test all existing network services and to check there is no harm to the network in terms of Quality, User Experience with introduction of new services. Testing recommended for networks is: > Integration testing to assure smooth roll-outs. > End-to-end testing of all the services in real or near real network having multi-vendor / multi technology environment. > Field trial to assure overall performance of new technology. > SDN controller security testing. > No Harm to the network testing will assure that all legacy services are working fine and not impacted with introduction of SDN/NFV How Aricent Can Help? Aricent has helped service providers and equipment manufacturer across the world with its thought leadership, technology know-how, and expertise in integration, validation, rollout and maintenance of new cutting edge technologies. Aricent s expertise spans across SDN and NFV technologies, including OpenFlow, SDN applications and Northbound APIs. Aricent has proven record for successfully delivering end to end solutions, delivering telecom testing services (end-to-end testing, performance testing, functional testing and test automation), managed lab services and OSS transformation to support virtualized networks having multi-vendor, multi- technology and multi-release environment. Fore-sighting the need for constantly evolving communication networks, Aricent has developed reusable test assets (test strategy, test plans, test cases, and processes) to reduce timeto-market for service providers. Conclusion NFV and SDN will change the fundamental approach of how networks will be built in future. Focus will shift from building networks in silos to component virtualization and then to network virtualization. Though lack of standardization and other issues around security, performance of virtualized appliances / applications currently impinge mainstream adoption of SDN and NFV, but, it is a matter of time, when the specification forums will standardize the technology aspects, some of which are already being addressed in respective forums. The use cases and applicability of NFV and SDN as discussed in this paper will not only bring down CAPEX and OPEX in medium to long term, but also improve time-to-market for new services, simplify network operations and management. VIKRAM NAIR is Director Technology at Aricent responsible for E2E Testing, VAS & M2M practice. vikram.nair@aricent.com VINOD KUMAR GUPTA is Senior Technical Leader at Aricent responsible for E2E Testing pre-sales. vinod.gupta@aricent.com 13

15 REFERENCES (1) Open Networking Foundation (2) Network Functions Virtualization. An Introduction, Benefits, Enablers, Challenges & Call for Action ( (3) SDN: Bridging the Mobile Backhaul Funding Gap ( (4) White Paper by Aricent: Application Aware Routing in SDN ( Aricent_Whitepaper_-_Application_Aware_Routing_in_SDN.pdf) (5) OSI model ( (6) (7) ETSI GS NFV 004 v1.1.1network function virtualization (NFV), virtualization requirements ( NFV/001_099/004/ _60/gs_NFV004v010101p.pdf)

16 Engineering excellence.sourced Aricent is the world s #1 pure-play product engineering services and software firm. The company has 20-plus years experience co-creating ambitious products with the leading networking, telecom, software, semiconductor, Internet and industrial companies. The firm's 10,000-plus engineers focus exclusively on software-powered innovation for the connected world. frog, the global leader in innovation and design, based in San Francisco is part of Aricent. The company s key investors are Kohlberg Kravis Roberts & Co. and Sequoia Capital. info@aricent.com 2014 Aricent. All rights reserved. All Aricent brand and product names are service marks, trademarks, or registered marks of Aricent in the United States and other countries.