How to enable a Telephone Company to Innovate like Google James Kempf Principal Research Engineer Ericsson Research Silicon Valley outline › Problem Definition › Historical Perspective › Platform › Process › Prototypes › Summary Ericsson Confidential | 2013-11-21 | Page 2 Problem Definition: How Service Development works today › Typical platform – Collection of protocols and systems accumulated over 50 years › Digital telephony/POTS › Internet – Just concerned with user facing actions › Call control, billing › Typical process – Group of 30 people – 1-2 years of effort › Ensuring the underlying hooks are there › Programming them if not › Bottom Line: time consuming and expensive Ericsson Confidential | 2013-11-21 | Page 3 Problem Definition: AGILE Service Development Platform: - Engineered for fast innovation - Easily enhanced for new use cases - Built on existing technology when good enough - Stable enough for long term - Covers cross-domain (WAN, cloud, mobile) Ericsson Confidential | 2013-11-21 | Page 4 Process: - Flexible, adaptable to fast evolving customer tastes - Low overhead - Doesn’t require CS PhD’s to run - Able to turn around feature set in weeks rather than years Historical perspective: Parlay › Standardization effort by ETSI, 3GPP, and TISPAN – Started in 1998. › Goal: to produce a set of APIs usable by enterprise IT developers for developing telephony applications independent of the underlying network type (SS7, mobile, etc.) – – – – Call Control Conferencing User Interaction (audio, text messaging, SMS, MMS) Billing › Multiple language bindings – CORBA/IDL – Java – WDSL (XML Web Services specification) › In 2003 simplified set of APIs released called Parlay X – Basic Web services API › In 2007, the Parlay standardization work was completed Ericsson Confidential | 2013-11-21 | Page 5 Historical Perspective: JAIN › Standardization effort within the Java Community Process › Originally started as a way to control ISDN-based Intelligent Networks from a Java API – Moved to higher level call control later – Overlap with Parlay › Between 2001 and 2003, Parlay and JAIN harmonized their APIs – Process issue: JCP requires implementations, ETSI doesn’t Ericsson Confidential | 2013-11-21 | Page 6 Historical Perspective: OneAPI › In 2007, GSMA took over Parlay Web services APIs for telephony › Renamed OneAPI – REST-based APIs – Standardization effort still ongoing with GSMA › Includes call control and billing Ericsson Confidential | 2013-11-21 | Page 7 Historical Perspective: Analysis Where are the flood of applications expected from Parlay/Jain/OneAPI? Lack despite more than 10 years of effort suggests need for some reflection and analysis APIs initially exposed maximal information rather than simplified abstractions The APIs must support more that just application control of communications - Automation of configuration and deployment cross-domain -service orchestration platform Cross domain orchestration - Original Parlay/Jain APIs were too complicated for enterprise IT folks Key to a successful is simple, usable abstractions and maximally automated deployment. The APIs must evolve out of implementing use cases - Use case driven APIs will get used at least for the cases they are designed for - Supporting more use cases may require refining the abstractions Ericsson Confidential | 2013-11-21 | Page 8 The APIs must support maximal automation - Anything less will increase OPEX and deployment complexity, lengthening innovation cycle Platform: sDN › In 2008, Stanford introduced OpenFlow – Simple, TCAM-based forwarding model – 1990’s view of the data plane › In 2012, ONS standardized OpenFlow 1.3 – Same forwarding model – 2008 view of the data plane › Problem – Most networking devices don’t have the hardware to support scalable, line speed TCAM based forwarding › In 2010, OpenFlow generalized to Software Defined Networking (SDN) – Centralized control plane – Protocol control of forwarding elements › What protocol isn’t specified – Basically real time network management › SDN opened the discussion to combining control and management planes in a single controller SDN Controller North-bound API is the Platform for transport and network management control Ericsson Confidential | 2013-11-21 | Page 9 Platform: ExamPle OpenDaylight Ericsson Confidential | 2013-11-21 | Page 10 Hydrogen Release Platform: Cloud Computing › IaaS APIs virtualize/automate server, storage, and network configuration and deployment – – – – – Example: Openstack Virtual server deployment and provisioning Load balancing Virtual network connectivity Virtual storage › PaaS APIs support application developent – Java, Ruby, Python, CloudFoundary › Orchestration platforms support complex service deployment – Compose multiple applications into a single service › Confined to a single data center so far but potentially applicable to the entire network – Cross domain – View network, compute and storage resources as one gigantic computational platform Ericsson Confidential | 2013-11-21 | Page 11 Platform: NFV › In 2012, 24 companies from the operator community issued a white paper for Network Function Virtualization (NFV) – Emphasis on CAPX savings by using COTS hardware › Remove function deployment dependence on specific hardware platforms – Vision was to virtualize all functions involved in running an operator network onto COTS › Including data plane of routing and forwarding elements › Subsequent study showed that CAPX savings from white box COTS would not be so great – Revised white paper now stresses OPEX and speed of innovation – Virtualizing other network functions like IMS, mobile core, etc. › Less talk about basic routing and forwarding element virtualization NFV is now about changing the deployment model which could enable deeper automation of deployment Ericsson Confidential | 2013-11-21 | Page 12 Platform: Example CrossDomain Controller/Telco PaaS Service Development Environment/Customer Portal Abstracted Simplified Realtime Automated Deployment Framework Service Automated Service Assurance and Management Network 3G/LTE Enterprise and Operational domain Mobile Access Consumer Access Ericsson Confidential | 2013-11-21 | Page 13 Transport Router Operational domain IP & Optical Transport Edge Service Edge Data Center DataCenter Platform: What’s Missing? › Policy configuration and management › Service and order management – Including end user self-provisioning › Network management and automation of fault correction – – – – – Root cause analysis Service assurance Realtime session monitoring Topology monitoring Cross-layer correlation › Automated traffic engineering to reduce the need for overprovisioning – Gscale-like utilization in operator network › WebRTC support and streaming media protocols/APIs › Realtime gateway deployment and IoT? › Security APIs? › Other? Additional Platform APIs should derive from specific use cases Ericsson Confidential | 2013-11-21 | Page 14 Process: Agile Service Development › Agile principles of software development help make service development quicker › Good software engineering practices are necessary – – – – Object-oriented design Unit testing Automated acceptance testing … › Devops or Continuous Deployment can reduce the time until new features – Integrate development and operations – Decrease feature set in any one release – Release on a monthly basis › Proactive, destructive fault testing can ensure that services will stand up to any load or any fault condition – Netflix Chaos Monkey kills streaming video VMs randomly to ensure their video feeds will survive a VM crash Ericsson Confidential | 2013-11-21 | Page 15 PrototypeS: Cloud Atlas Abstractions › Elastic WAN Networking with SLAs for OpenStack › Tight integration with OpenStack Neutron data center networking with WAN › End to End, Data Center to WAN to X, virtual networking › Simple, customer usable API – Based on simple abstractions for bandwidth and connectivity – Reduces operator management overhead › Connectivity and bandwidth on demand – Cloud – Cloud – Cloud – Enterprise › Independent of underlying WAN VPN hw/sw technology – OTT, L3VPN, L2VPN, etc. – SmartEdge, SPO 1400, etc. Ericsson Confidential | 2013-11-21 | Page 16 Applications Prototypes: Cloud Atlas Architecture Orchestration Layer or Cloud OS Tenant Cloud Atlas Public API Cloud OS A EN Agent A EN Plug-in EN Manager EN Plug-in Management API Network Virtualization A EN Agent B Cloud OS B EN Plug-in Management API Network Virtualization B WAN GW A Site A Ericsson Confidential | 2013-11-21 | Page 17 GW B Site B Prototypes: BANDWITH Calendaring Use Case › Bandwidth calendaring: – Limited duration scheduled period of increased bandwidth – Between two data centers or a data center and enterprise network › Operator can make use of spare capacity during offpeak hours › Example application: – Checkpoint (not live migrate) VM into another data center – Periodically update – Start checkpointed image if original goes down Ericsson Confidential | 2013-11-21 | Page 18 Prototypes: Network Slices › On-demand, policy driven QoS for mobile enterprise cloud services – Demonstrates cross-domain orchestration between cloud and mobile network › Portal for enterprises to configure enhanced QoS for specific cloudbased services – Both by deployment location choice and LTE enhanced bearer › No mobile operator administrative involvement after enterprise tenant account is set up – Demonstrates customer service configuration portal Ericsson Confidential | 2013-11-21 | Page 19 Prototypes: Network Slices Demo Video Network slices video here Ericsson Confidential | 2013-11-21 | Page 20 Prototypes: Network Slices Architecture Ericsson Confidential | 2013-11-21 | Page 21 summary › Despite minimal success historically, a Telco PaaS for controlling cross domain functions in operator networks show some promise due to new developments – SDN NFV as building block technologies – OpenStack as deployment platform – “as a Service” movement › Agile service development requires more than just new APIs, it requires a different approach to service development – Agile Software Development – Automated acceptance testing – Devops/Continuous Deployment › Prototypes illustrate the utility of Telco PaaS for quick service development Ericsson Confidential | 2013-11-21 | Page 22 Credits › Picture on slide 3 is from http://www.planetgeek.ch/2010/06/17/code-quality-buildingcode-you-wont-curse-tomorrow/#more-1646 › Cloud Atlas prototype was developed by Stephan Baucke and Racha Ben Ali › Network Slices prototype was developed by Stephan Baucke, Olof Bäckman, Vladimir Katardjiev, and Martin Körling › Victa McClellan kicked off and led the architecture work on cross-domain control Ericsson Confidential | 2013-11-21 | Page 23