The Impact of SDN & NFV On Application Delivery and Virtualized Application Execution. Jim Hodges, Senior Analyst Heavy Reading

Transcription

1 v The Impact of SDN & NFV On Application Delivery and Virtualized Application Execution Jim Hodges, Senior Analyst Heavy Reading

2 OUR PANELISTS Caroline Chappell Senior Analyst, Heavy Reading Christian Martin Sr. Director of Engineering, Cisco Nirav Modi Director, Software Innovations, Cyan

3 AGENDA The Impact of SDN and NFV on Application Delivery Panel Discussion Q&A

4 SDN NFV AND APPLICATION VIRTUALIZATION Service Provider Data Center Virtualized Applications Orchestration Virtualized Resources Servers Storage Hypervisor VNF Function The goal: virtualized on demand application model. What s required? Advanced orchestration Virtualization of Network Functions (Data Center or distributed VNF model) Virtualized resources Advanced ADC functions Source: Heavy Reading Application Delivery Controller SDN Controller Transport Network Enterprise Data Center Enterprise Branch NFV SDN Application prioritization and policy in transport network

5 Ethernet & SDN Expo 2013 New York City, NY, USA SDN and Network Virtualization ADC Orchestration from the Ground Up Christian Martin Sr. Director, Engineering Chief Architect/CTO Engineering Office Cisco October 3,

6 Business Impact Core Technology: Virtualization Mainframe Centralized Client-Server Distributed Cisco establishes Networking Leadership SOA and Web 2.0 Virtualized DC 3.0: Cisco Establishes Systems leadership Unified Fabric Unified Computing Virtualization Public/Private Clouds Data Center Business Advantage: Accelerate IT innovations to deliver business value VDI/VXI Cloud Solutions vblocks LAN and SAN Switching Security, L4-7 Services 1960 VOIP Cost Center Role of IT/Data Center Strategic Asset 6

7 Use case #1: New service required Today 1. Buy hardware 2. Install image 3. Install hardware in DC 4. Connect to network 5. Configure and commission service With NfV 1. Requests service 2. Service is dynamically deployed in DC Use case #2: Increase service capacity 1. Identify capacity threshold reached 2. Buy hardware 3. Install image 4. Install hardware in DC 5. Connect to network 6. Configure and commission service 1. Service dynamically scales to adjust to demand 7

8 Co-ordinate the elements of a situation to produce a desired effect, esp. surreptitiously. 8

9 Needs to make hard tasks simple (notwithstanding the need to simplify hard tasks) Needs to enable new services not limit them Needs to scale-up/-down value services to volume services Flexibility, flexibility, flexibility, 9

10 High Cost The dynamic nature of vdcs introduce a large volume of OPEX intensive manual & repetitive changes. Slow And Complex App Rollouts Multiple touch points leads to increased lead-time and higher risk of error for application and service deployments. VM Blind Limited visibility into the status and operation of applications and the underlying virtual infrastructure. Limited Performance Difficult to scale applications and infrastructure to meet the demands of customers and users. Inflexible Infrastructure Centralized tools and expertise points make the provisioning of end-to-end services complex and resource intensive. vdc Solutions MUST Address These Key Issues 10

11

12

13 Policy & Intent Applications Network Intelligence, Guidance Services Orchestration Analytics Programmability Network Stats, State & Events 13

14 Ok with DC resources, custom routing National Data Center #3 Insufficient BW connectivity National Data Center #2 Request for additional resources with tight SLA: 1. DC1 is nearest, but busy #1 2. DC2 is next, but lack of bandwidth Insufficient DC resources National Data Center 3. DC3 is ok with resources except firewall performance; need custom routing to meet SLA requirements 14

15 Traffic Flow Services management Firewall IPSec GW NAT Analytics NfV responsible for: Different service bundles percustomer / per-traffic class Automatic scalability add / shutdown services upon request demand Self-provisioning portal customers can switch on/off services SDN responsible for: automatic adaptation for services / traffic matrix Traffic Flow Service monitoring 15

16 BRAS Central 1 st step expanding central node few minutes for every next BNG 2 nd step rollout of regional node few minutes for new cluster few minutes for every new BNG in new cluster BRAS Regional 16

17 17

18 Current network worst case utilisation = 79% Taking into account single link failures Need to deploy new workload New bidirectional demands of 100Mbps from every POP to chosen DC i.e. 11 POPs hence 22 new demands Candidate DCs = {SJC, CHI, NYC, KCY} WC delay requirement of 25ms WC utilisation requirement of 100% 18

19 NYC exceeds acceptable WC util and WC delay thresholds SJC exceeds acceptable WC delay threshold CHI and KCY are able to support the requested demands KCY is preferred because the worst-case utilisation is lower than for CHI DC: SJC WC delay: 33.0ms WC path util: 90.8% WC net util: 90.8% DC: NYC WC delay: 29.5ms WC path util: 101.8% WC net util: 101.8% DC: CHI WC delay: 22.0ms WC path util: 91.4% WC net util: 91.4% DC: KCY WC delay: 22.2ms WC path util: 90.8% WC net util: 90.8% 19

20 Network and trafficaware service placement Ensures SLAs can be met Supports ~30-35% more traffic for the same provisioned bandwidth compared to other workload placement algorithms 180% 160% 140% 120% 100% 80% 60% 40% 20% 0% Avg. Network Worst-Case Utilisation 135% 130% 130% 100% Random WRR Lowest latency Demand eng 20

21 SDN and NfV are compelling technologies, aimed to decrease capital and operational expenditures, as well as increase revenue by introducing agility, automation and orchestration of networks and services. Both SDN and NfV are industry initiatives, which joined all kinds of industry players communication providers, content providers and vendors. Most of trials and tests initiated by providers. ADC placement is an endeavor that takes parts of SDN and NfV into consideration. Ultimately, ADC placement is a resource management problem (both on the server side AND the network side) and thus benefits from knowledge of the performance characteristics of both. It is not limited to intradc and will require WAN orchestration as well as DC orchestration. Orchestration is the key! 21

22 22

23 Cyan SDN and NFV Solutions , CYAN, INC.

24 SDN and NFV Driving Change SDN/NFV causing confluence of WANs/MANs + DCs Multi-layer, multi-vendor WAN/MAN and cloud orchestration must be integrated for better network economics Many DCs will be embedded into the network Competing requirements Economies of scale -> fewer number of very large DCs Locality, latency -> larger number of small/medium DCs Variety of client attachment types WAN-attached (enterprise, residential, wholesale, wireless, etc.) DC-attached Physical and Virtual , CYAN, INC.

25 Virtualized Network Functions One Size Does Not Fit All Orchestrator must be open Agnostic to application vendor and function Orchestration must support both virtual and bare-metal VNF deployments Flexible virtualization architectures: VMs, LXCs, 1:1, 1:N, N:1, Composite and clustered VNFs Manual, semi-automated, and automated VNF placement DC selection Server selection Multiple placement strategies (affinity, diversity) Fully automated service insertion/routing/chaining Variety of packaging VM images, packages (.deb,.rpm), etc , CYAN, INC.

26 Application Delivery and Service-Chaining Orchestrate multi-vendor fixed-network infrastructure Requires orchestration of VNFs + virtualized (or bare metal) infrastructure Service-chaining (recursive templates) enables delivery of applications enodeb + vepc + vdns chaining to deliver broadband data services vepc and vims chaining used to deliver VOLTE , CYAN, INC.

27 Service-Chaining Workflows The work-flow to deploy an application can be defined , CYAN, INC.

28

29 QUESTION 1 Will NFV and SDN simplify application orchestration, or make it more complex? Considerations: Impact of virtual CPUs should help Both enable a true and multi layer end-to-end orchestration model How long will it take to get the bugs out? NFV is a little more ad hoc (operators are free to decide which functions to virtualize) while SDN is a more rigid top down design (can t implement one piece of SDN), does that pose a problem?

30 QUESTION 2 Will virtualizing application delivery control will make it more difficult to add new applications going forward? Considerations: Impact on existing service provisioning procedures More logically aligned with an OTT application model Will it enable a more seamless roaming model? Will it simplify the B2B application delivery model?

31 QUESTION 3 Will operators will be finally able to implement best of breed strategies for ADCs and orchestration products? Considerations: The positive impact of open APIs How will orchestration function in a hybrid network? Will pricing and existing OSS integration prevail? What is the impact of decomposed VNFs?

32 QUESTION 4 Will virtualizing applications and delivery controllers positively or negatively impact redundancy and failover? Considerations: NFV enables on-demand of spin-up How will redundancy be impacted if there are mass software failures? Will it be more difficult to troubleshoot software only failures? What is the impact of multiple hypervisor support?

33 QUESTION 5 Is comprehensive pretesting of new virtualized applications more difficult than the traditional model? Considerations: It should be shorter, but likely requires new telco practices.what happens to regression testing? When will a rich suite of virtualized software testing tools become available? What is the testing impact of the chaining VNFs into one logical function?

34 QUESTION 6 Will the integration of SDN/NFV architectures into existing networks and operations environments limit the pace of adoption/deployment? Considerations: The open environments will be embraced because of their flexibility APIs are vital for integration into existing operation environments A new set of operational tools will be needed for this paradigm Orchestration platforms must be able to span legacy and SDN/NFV architectures

35 Q&A