Telexistence Robot, SDN and OpenStack Li Ma @ Telexistence Inc. Who - PowerPoint PPT Presentation

Telexistence Robot, SDN and OpenStack Li Ma @ Telexistence Inc.

Who We Are? • Telexistence Inc. • Founded in January 2017. • Located in Omotesando, Tokyo Japan. • Our Mission – Industrialize Telexistence Technology. – Change lives, organizations and society.

Who We Are?

Who We Are? • Li Ma (Nick) – Chief Cloud Architect @ Telexistence Inc. – Started with a focus on real-time robotic communication, multimedia streaming and software-defined networking. – Started to contribute codes and ideas in OpenStack Com- munity from 2013. – Former Core Reviewer in OpenStack Dragonflow Project.

What I Will Cover? • What is Telexistence • Cloud Networking for Telexistence • OpenStack-powered SDN Implementation • Summary • Q & A

What Is Telexistence?

• Youtube – https://www.youtube.com/watch?v=HLdM6no7 F34&t=3s

What Is Telexistence? Telexistence is a concept that was first proposed in 1980 advocated by Dr. Susumu Tachi, Professor Emeritus of the University Tokyo and the chairman of Telexistence Inc. , which refers to the notion of human bei ngs in effect being in a place other than where he or she actually exists and being able to act freely in that remote environment.

What Is Telexistence? Human and robot are connected through network. Avatar robot exists in a remote place. Cockpit (Controller) User Local PC Real-time User App Cloud Networking Surrogate (Robot) Cockpit SDK Avatar Robot Vision Module Vision, Audio and Tactile Cockpit HW Haptics Control Module Sensors Haptics Display Other Mech/ Motion Motors Elec Body Tracker (Hand, Arm, Neck, Head, Body) Locomotion Head Mount Display Hand controllers

What Is Telexistence? Inspection / Reception Remote Healthcare Construction Machine Operation

What Is Telexistence? Fire Fighting Outer Space Exploration

Cloud Networking in Telexistence

Cloud Networking in Telexistence • More capacity, lower cost • Ultra low latency • Uniform Experience Cloud Networking Vision, Audio, Motion (Hand, Arm, Neck, Head, Body)

Cloud Networking in Telexistence • VR requires rich vision/audio contents • Constant upload/download on an all-day wearable – Two-way telepresence: 5 - 25 Mbps – Current-gen 360 degree video: 10 - 50 Mbps – Next-gen 360 degree video: 50 - 200 Mbps – 6 DoF video of free viewpoint: 200 - 5000 Mbps

Cloud Networking in Telexistence • Dynamic Resource Allocation at edge – For packet inspection/processing – For machine learning • Conflict Avoidance • Motion Planning • Health Checkup • Secure Analysis

Cloud Networking in Telexistence Edge Customer Customer Access Edge Centralized Equipments Premises Network Latency: ~2ms Latency: ~5ms Latency: 1-3ms Latency: 5-20ms Latency: ~20ms Last-mile EC Cockpit EC - Central Office Centralized DC Surrogate Network

Cloud Networking in Telexistence • Telexistence Requirements – Immersion MUST be maintained at all times. • Consistent quality • Anywhere usage • High mobility – Flexible policy for packet processing and transmission.

Cloud Networking in Telexistence Network Controller

Cloud Networking in Telexistence Network Controller Cockpit 5G Nagoya Osaka Tokyo Sendai 5G TX Cloud Service Chain Surrogate

OpenStack-Powered Implementation

TX Cloud Features • Multi-hop Global Packet Transmission Network • Intelligent Routing Capability • Deterministic Learning • Dynamic Service Insertion • Authentication, Authorization and Accounting

TX Cloud Features • Software defined networking technology is applied to abstract and develop policy engine of traffic tran smission and bandwidth control. • Eliminate single point of failure. • Scale-out architecture.

Structure of TX Cloud Public Service Service Support Operation Portal Other Portal Coordination Service Core (Internal) Services AAA Service Scheduler Engine Traffic Engine Notification Service Data Persistence Machine Learning QoS Plugins Service Insertion Plugins Plugins Logging Infrastructure Service Configuration Public Cloud Infrastructure Telco Edge Computing Infrastructure

Development Plan in 2017 • Initial Development Plan Analysis Design Development Testing Duration: 3 Weeks Duration: 6 Weeks Duration: 18 Weeks Duration: 4 Weeks

Development Plan • Implementation Analysis Design Development Testing Duration: 1 Week Duration: 1 Week Duration: 4 Weeks Duration: 4 Weeks SAVE 66% of the development time!

OpenStack-Powered Implementation • 60% of the core fu nctions have been implemented. • Additional 15% cor e logic of the third- party libraries can also be reused.

OpenStack-Powered Implementation Public Service Service Support OpenStack Horizon Other Portal OpenStack TooZ Core (Internal) Services OpenStack OpenStack Nova OpenStack Dragonflow OpenStack Dragonflow Keystone Scheduler The 3 rd Party Library QoS App Service Insertion Apps Machine Learning Apps OpenStack Oslo.log Infrastructure Service OpenStack Oslo.config Telco Edge Computing Infrastructure Public Cloud Infrastructure

OpenStack-Powered Implementation • Third-Party Libraries – cotyledon in OpenStack Ceilometer • Multi-worker Framework • https://github.com/sileht/cotyledon – etcd3gw in OpenStack Tooz/Dragonflow • Python ETCD3 SDK • https://github.com/dims/etcd3-gateway

OpenStack-Powered Implementation • Core SDN Framework – OpenStack Dragonflow – Pure Python OpenFlow Controller – Distributed in nature – Pluggable application framework – Easy to remove Neutron L2 logics – Fast processing, real-time response!

OpenStack-Powered Implementation Pub/Sub Drivers Dragonflow Plugin DB Drivers TX Control Server L3 ETCD ZeroMQ L4 Apps Network DB ETCD Compute Node Compute Node Traffic Engine Nodes Dragonflow Pluggable DB Dragonflow Controller NB DB Drivers Layer Abstraction Layer ETCD SB DB Drivers L4 App L3 App … OVSDB OpenFlow OVS User Space vswitchd OVSDB-Server Kernel Space Kernel Datapath Module NIC

OpenStack-Powered Implementation • Dragonflow DONE the SDN way – https://www.openstack.org/videos/austin-2016/dragonflo w-neutron-done-the-sdn-way

OpenStack-Powered Implementation • Architecture Highlights – Database: • Eventually consistent • Only responsible for data persistence • Minimize the logic around key-value operations – Only WRITE once (READ, only when failure happens) – No SQL-like operation, for example, JOIN – No transaction primitive

OpenStack-Powered Implementation • Architecture Highlights – Message Queue: • Real-time notification • Fast delivery • Message Persistence • Implement all the sophisticated logic

OpenStack-Powered Implementation • Architecture Highlights – Virtual Router Instance • Local OpenFlow controller: – PACKET_IN efficiency – Stateless process -> easy to scale Network Controller

OpenStack-Powered Implementation Build Blocks Glue Codes Develop OpenFlow Applications

Summary

Summary • We built our own SDN controller prototype within six weeks. – Pure Python – Scalable – Extensible – Easy to maintain

Summary • OpenStack Community provides almost all the blocks that can help build a scalable cloud application.

Summary • OpenStack CI can greatly help you identify dependencies and stabilize your system.

Summary Project Modules Dragonflow Ryu-based OpenFlow Controller ZeroMQ-based Message Queue Database modeling (ETCD-based) Oslo log: Log Management config: Configuration Management stevedore: Dynamic Plugins concurrency: Synchronization Primitives tooz: Distributed Lock API Keystone AAA Service Nova scheduler: Filter Scheduler Framework Horizon Pluggable Web Framework

Summary • Give credits to this awesome open source community.