Availability For Network Function Virtualization. Alon Bernstein Distinguished Engineer Cisco Systems

Transcription

1 Availability For Network Function Virtualization Alon Bernstein Distinguished Engineer Cisco Systems

2 Availability Using Software In The Data Center Storage Compute Networking (NFV)

3 NFV Redundancy Requirements Minimal packet loss High bandwidth Stateful

4 Example : vcpe Redundancy

5 Example : vcpe Redundancy

6 Example : vcpe Data Path

7 ETSI-NFV

8 Conclusion NFV can support high availability Traditional as well as new Availability models are possible in the data center

9 Distributed Trace For Comcast Video May 2015

10 ARCHITECTURE SKETCH Comcast Confidential & Proprietary 2

11 GRAPH OF CALLS Comcast Confidential & Proprietary 3

12 GRAPH OF CALLS WITH ANNOTATIONS Comcast Confidential & Proprietary 4

13 SIMPLE CORE PROTOCOL Traces A trace encompasses all interactions, generally for some interesting user interaction. Here, it s going to encompass a video playback session. Spans A span is some small chunk of that, here, it will almost always be handling or making a service call. Traces and Spans both have IDs. Trace IDs in our scheme are GUIDs, Spans are pseudorandomly generated integers. Pass information around on X-MoneyTrace header. X-MoneyTrace:traceId=$TraceId;spanID=$SpanID;ParentID=$ParentID At each new span generation, generate a new Span ID, and move existing Span ID to the Parent Span. Every service call passes X-MoneyTrace, and every service responds with the same X-MoneyTrace when it responds to the call. Comcast Confidential & Proprietary 5

14 Virtual Business CPE Accelerating Quote to Cash and Enhancing Operational Flexibility Kevin Luehrs, Director, CableLabs

15 Cloud Technologies Transform the Landscape Cloud Computing to Software Defined Networks Dynamic demand for services in data centers drove evolution of Software Defined Networking (SDN) Separation of control from data Control functions centralized under a single software controller Software control of data paths, network functions and packet handling rules improve flexibility and enable greater automation.

16 Virtualization OS Hardware Virtualization Initiation of self-contained instances of an operating system and software applications on a hardware platform emulating an independent device. Virtual machines can be installed in a host and operate as separate devices even with different OS. OS OS Network Function Virtualization (NFV) Implementing network functions as software programs that can be run independently or as a group on industry standard servers. Route Load Balance DPI Functions can be moved out of purpose-built hardware into standard servers in the cloud. Switch Performance Management Tag

17 Cloud Technologies Transform the Landscape Hypothesis Cloud technologies that transformed data centers will similarly transform networks Opportunity The emergence of new access network technologies such as DOCSIS 3.1, EPON and EPoC and greater adoption of SDN provides opportunity for virtualization of networks and services.

18 Use Case: Virtual Business CPE Apply virtualization methods to delivery of business services SDN to configure endpoint devices and establish connections Software control facilitates automation NFV for flexibility in deploying services Business services providers run applications to provision and manage devices and connections. SDN & NFV can be used to accomplish this

19 Problem Statement No standard and open Application Programming Interfaces (APIs) are currently available to expose open source SDN controller features for Business Services applications. SDN controllers manage device configuration and connections based on inputs from network applications. Open source SDN controllers are supported by collaborative developer communities. Enable scale, rapid development, diversity of ideas

20 Proposed Solution Develop data models and standard open APIs enabling delivery of business services using open source virtualization techniques. Submit data models and APIs to open source project for evolution, adoption and use by NFV community. Develop a reference software platform integrating RESTful APIs, OpenDaylight and OVSDB/OVS

21 Virtual Business CPE Demo Platform Raspberry Pi

22 Thank You

23 A History of Abuse Lies, Damned Lies, and Cybersecurity Metrics

24 Past - The Abuse Department An Internet Service Provider s abuse department processes reports of Acceptable Use Policy (AUP) violations Reports enter the system via the ISP s abuse@ address. Reports range in seriousness from criminal activity down to people calling each other names

25 Annual Ticket Volume

26 Annual Ticket Volume by Type

27 Malware Ticket Volume

28 Present - The Customer Safety Department Since the early 2000 s, the number of customers intentionally launching attacks has dwindled to almost nothing compared with malware. Today s offenders are also victims, and we do our best to protect them

29 Spam Ticket Volume

30 From Abuse to Customer Safety

31 Future The Ecosystem Literally everyone on the internet has at least a detection capability Many also have a notification capability (e.g. banks, search engines, and social media) Some even have a remediation capability (e.g. Facebook s malware walled garden) It takes a village to raise a child, and it takes an internet to fight cybercrime.

32 RDK + CA/DRM: ENHANCING INTEROPERABILITY FOR ROBUST REVENUE SECURITY Petr Peterka Verimatrix

33 Agenda Benefits and Challenges of RDK RDK and Revenue Security Mitigating Threats to Revenue Security Power of Standardization Looking Forward

34 Benefits and Challenges of RDK Benefits: Common implementation vs. common specification Cost benefits Accelerated development Supports differentiation Challenges: Security threats Interoperability with CAS and DRM 4K UHD security requirements OSS license obligations require careful attention

35 RDK and Revenue Security CAS/DRM RDK interfaces: 1. Interaction with the content tuner/demultiplexer 2. Interaction with a hardware security (root of trust, descrambling, key ladders, etc.) 3. Interaction with the application layer 4. Access to IP stack 5. Forensic watermarking CAS should be isolated from the middleware and application functionality for robustness reasons Abstracting out main functions for interoperability reasons

36 Mitigating Threats Interaction between the application and the CA client: 1. Tuning/Navigation 2. Initialization/Provisioning 3. Authorization/Entitlements 4. On-screen Display

37 Power of Standardization Examples of relevant standards organizations: SCTE OMS: Hardware root of trust (K-LAD) DVB Simulcrypt and MPEG-DASH Common Encryption (CENC) GlobalPlatform: Trusted Execution Environment (TEE) OSS implementation is possible

38 Looking Forward RDK is stable but still need abstract CAS APIs and HW security abstraction Plus Downloadable Security extension pending FCC DSTAC outcome

39 Questions?

40 Introducing an Abstraction Layer to Control the User Experience, Apps and Integrate Content on All Screens By Albert Dahan Co-Founder and CTO, Metrological

41 Market Challenges Integrating live TV, OTT content, widgets, third party apps into a single user experience on all screens Retaining control of the user experience across a growing number of devices Native apps running on STB middleware clients require device-specific solutions for each STB, mobile and tablet device Managing multiple, separate backend management structures for each content source Growing development costs for maintaining multiple versions of each app for each device Mounting pressure to lower operational costs while meeting consumer demand for OTT/app content, live TV and VOD content increases the demands on STB CPU and memory

42 Native vs Abstraction Layer Approach Native Development Approach Resides on the device requiring a device-specific solution Dictates development of many different versions of each app for each device Based on closed, monolithic software solutions Requires MVPDs to upgrade to next-gen IP STBs with browsers Closed app development community Separates OTT, live TV and apps viewing Key functionality built into the app itself Abstraction Layer/Framework Uses browser as a generic integration point to run and control the user interface, apps and client services across connected devices A single version of each app runs on all devices Uses modular software components that connect new web-based and open source technologies Minimizes CPU and memory usage of the end device ; deployable on browserless legacy STBs Open app development community via SDKs Integrates OTT, app and live TV viewing experiences enables new functionality and interactivity Apps are isolated in their own sandbox, separating key functionality and using it as a shared resource

43 Abstract Layer/Framework Approach Separates MVPD backend, device middleware and operating system from the user interface, presentation and navigation layers on each device Operates independently from the device eliminating the need for device-specific approaches Merges all content onto one screen, enabling new contextual, mobile and social features Minimizes CPU and memory usage of the end device Deployable on legacy or browser-less STBs Uses small, modular software components that connect new web-based and open source technologies with existing legacy ecosystems Apps only need to be developed once to run on all devices and can be developed by anyone using an open Software Development Kit (SDK)

44 Evolution of TV App Platform Development Phase 1: Native apps on STB middleware Phase 2: Web-based apps Phase 3: Proprietary MVPD app environments Phase 4: HTML5-based abstraction layer *Need to develop app for each device *Requires browser optimization and lacks integration with middleware, backend *Each app must be developed for each MVPD *HTML5 standard still evolving

45 Thank you! Albert Dahan Co-Founder and CTO, Metrological