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

Li Ma @ Telexistence Inc.

Telexistence Robot, SDN and OpenStack

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.

Human and robot are connected through network. Avatar robot exists in a remote place.

Vision Module Control Module Motors Haptics Sensors

Avatar Robot

Surrogate (Robot)

Cockpit SDK Hand controllers

Head Mount Display

Haptics Display

Cockpit HW User Local PC

User App

Cockpit (Controller)

Motion (Hand, Arm, Neck, Head, Body)

Body Tracker Locomotion Other Mech/ Elec

Vision, Audio and Tactile

What Is Telexistence?

Real-time Cloud Networking

What Is Telexistence?

Inspection / Reception Remote Healthcare Construction Machine Operation

What Is Telexistence?

Outer Space Exploration Fire Fighting

Cloud Networking in Telexistence

Cloud Networking in Telexistence

• More capacity, lower cost
• Ultra low latency
• Uniform Experience

Vision, Audio, Motion (Hand, Arm, Neck, Head, Body) Cloud Networking

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

Customer Equipments Customer

Premises

Access

Network

Edge

Centralized

Cloud Networking in Telexistence

Latency: ~2ms Cockpit Surrogate Latency: ~5ms Last-mile Network Latency: 1-3ms EC Latency: 5-20ms EC - Central Office Latency: ~20ms Centralized DC Edge

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

Cockpit TX Cloud Service Chain Surrogate 5G 5G Network Controller

Tokyo Nagoya Osaka Sendai

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

Configuration AAA Service

Core (Internal) Services Service Support

Logging Data Persistence Coordination Service Scheduler Engine Operation Portal

Public Service

Other Portal Traffic Engine

Service Insertion Plugins QoS Plugins Machine Learning Plugins

Notification Service Telco Edge Computing Infrastructure

Infrastructure Service

Public Cloud Infrastructure

Development Plan in 2017

• Initial Development Plan

Testing Development Design Analysis

Duration: 3 Weeks Duration: 6 Weeks Duration: 18 Weeks Duration: 4 Weeks

Development Plan

• Implementation

Testing Development Design Analysis

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

OpenStack Oslo.config OpenStack Keystone

Core (Internal) Services Service Support

OpenStack Oslo.log The 3rd Party Library OpenStack TooZ OpenStack Nova Scheduler OpenStack Horizon

Public Service

Other Portal OpenStack Dragonflow

Service Insertion Apps

QoS App

Machine Learning Apps

OpenStack Dragonflow Telco Edge Computing Infrastructure

Infrastructure Service

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

Compute Node Compute Node Traffic Engine Nodes Dragonflow Network DB OVS TX Control Server

ETCD

OVSDB-Server

Kernel Datapath Module

NIC

User Space Kernel Space

DB Drivers

ETCD

Dragonflow Plugin

L3 L4 Apps vswitchd

Dragonflow Controller

Abstraction Layer

… L3 App

Pluggable DB Layer

NB DB Drivers SB DB Drivers

OVSDB ETCD OpenFlow

Pub/Sub Drivers

ZeroMQ L4 App

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

Build Blocks Glue Codes Develop OpenFlow Applications

OpenStack-Powered Implementation

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.