TELCO CLOUD

92764436

43256276

176654420

188119508

170293716

188713620

53840532

173570516

164264404

42830292

158566484

158566484

MOTivation

2 – Confidential – 30.10.2015

Situation

Cost & Complexity

Competitive Pressure

Traffic Growth

Long Innovation Cycles

ASPIRATION

Cost Leadership

Innovation Leadership

Robustness

Service Leadership: Self-Service Company

Fixed Mobile Integration

Revenue in EUR Harmonized & simplified NT, IT, Operations

Revenue in EUR Enable Software-Defined Service Delivery

Radical Network Simplification - Terastream

1. Reduce the amount of technologies used

2. Use IPv6 for all internal functions and services

3. Integrate optical networks and IP networks as much as possible

4. Use one network for all services (Fixed, Mobile, Internet, IP, TV, …)

TeraStream Network

The TeraStream IP network has two types of routers:

•“R1” routers are routers located at the edge of the IP networks and perform the handling of user facing IP traffic. Both incoming and outgoing service characteristics are strictly enforced in “R1”.

•“R2” routers are routers located at central sites of a service provider performing the aggregation of IP traffic coming from, or directed to, the “R1” routers. “R2” routers also provide the interface to peering partners, and to internal generated traffic from Data Centers operated by the service provider. “R2” also serves as transmission for externally faced data center switch/routers.

Terastream Service Definition

In the Terastream concept services are defined as everything that is: Transported over IPv6 Hosted as a virtual machine

IPv4/IPv6 Aspects

•The expectation is that in the long run all end-user traffic will be IPv6. IPv4 might remain confined to the end-user’s internal home network, hidden behind the small router. We assume that the public IPv4 address will have a very long tail.

•Not using IPv4, is related to some technical challenges. Current adoption rate of IPv6 is low, peering traffic with IPv6 is still a fraction of the IPv4 traffic, and there might be problems with IPv6 that the IP community has still not encountered.

•However, starting a new architecture based on mechanisms that are reaching its limits do not seem to be the best way forward.

FUTURE – TERASTREAM NETWORK

What’s in the TELCO Cloud?

R2

40% of

tra

ffic

50% of traffic

Cloud Service Center (TV, IMS, CDN, OTT, …)

Network Services (DHCP, DNS, OSS)

Legacy Protocols (IPv4, MPLS,

PPPoE)

Value Services IPTV, VoD

Innovation OTT apps

CDN - Google

CDN - Facebook

CDN - Akamai Infrastructure as a Service

IMS Components

Mobile Services

Self-Provisioning Portal

In-country 10%

TeraStream and industry Revenue in EUR Vendors & Industry

Full vendor support & agreement with TeraStream strategy

Leading Carrier Strategy in the Industry

Revenue in EUR Applicability

Fixed (Retail & Wholesale) Mobile Business Services Cost leadership and scalability for ANY size and ANY

bandwidth

TeraStream Design Principles

•Complexity by the use of abstraction and a separation of architectural layers •Operating costs •Number of application

Reduce

•COTS products •Scalable Architecture •Standardized virtual platform (Plug & Play) with a central resource •Simplified and automated business processes

Use

•Self-development •Dependencies between application and hardware •HW repair •Duplication of functionalities

Avoid

•Centralized management of all locations •Easy integration of new services / OTT services (using the Plug & Play platform) •Easily replicable Architecture •Seamless Customer Experience

Achieve

TeraStream Deliverables

Introduce • Similar processes for all services • Real-time Fulfillment • Zero human interaction

Handle • All IP traffic without IP packets losses • Large IP traffic volume for a lower cost • IPv6 for all internal functions and services

Reduce • The amount of technologies used • Complexity in the OSS • Service Downtime: <=200 ms / per day / per network

Achieve • Service Availability: 99,999 % • Decoupled Network and Service Fulfillment • Integrated optical networks and IP networks

Frontend and Backend Data Centers (1/2)

DWDM

R1 R1

R2 R2

DE intern

R1 R1

Node B

Frontend Data Center:

New OSS, SDP: IPTV, IMS ...Frontend Data Center:

New OSS, SDP: IPTV, IMS ...

Backend Data Center:

legacy CRM, Billing, OSS

• Cloud Computing (Virtualization, Automation, Selfprovisioning Portal)

• OSS Gateway • Service Delivery Platforms

Frontend Data Center

• OSS • eMail • AAA • vEPC

Backend Data Center

Frontend and Backend Data Centers (2/2)

Data Centers in the Terastream terminology are computational resources located at the same site as “R2” routers (Frontend Data Center – FDC).

Services provided by the FDC might vary from basic IP services as DNS or DHCP to more complex services as IPTV. FDCs should also host a large number of web servers or other types of computer based traffic sources, for example: IPv4 to IPv6 NAT. The Operating Support Systems (OSS Gateway) should also be hosted at the FDC.

(Backend Data Center – BDC) - performing more traditional backend services.

Logicalarchitecture

Change architecture

BusinessArchitecture

Applicationarchitecture

Technicalarchitecture

OrganizationBusiness process

Business strategy

Logicalfunction

Logical information

Standard

Business change

Technical component

a

Business product

Architecture Development

Implication of Terastream on IT Systems – Radical Change

• Improved support for online channels and self

service • Support for new markets and business models • Process simplification & automation • Decreasing TCO

NEW telco infrastructure

18 – Confidential – 30.10.2015

– streng vertraulich, vertraulich, intern, öffentlich –

Telco Infrastructure Cloud is a tight coupling of network I/O optimized data centers with the IP network. Used for running Virtualized Network Functions. Follows the cloud paradigm with full automation and lifecycle management as part of the network infrastructure. The Infrastructure Cloud consists of Front-End and Back-End Datacenters. Both use CEPH for distributed storage, KVM as hypervisor and OpenStack as cloud operating system. Through its network optimization, the Telco Infrastructure Cloud is not comparable to a traditional IT Cloud.

TELCO INFRASTRUCTURE – DT VISION

PaaS High-level automation APIs and additional frameworks

Optimized hardware, network setup

IaaS KVM, CEPH, OpenStack

Virtual Network Functions (VNFs)

Potentially many different PaaS offerings on top of Infrastructure Cloud IaaS to shorten time2market and further reduce complexity in VNF / project adoption/development and/or offer partner easy integration with self-service

Infrastructure Cloud Layered structure

IaaS based on OpenStack, KVM as Hypervisor. CEPH for Software Defined Storage (block&object). Highly automated installation. Fully supporting Security Requirements.

Hardware and network setup depending on optimization for cost (server, storage), network throughput, and NFV demand

The Software Defined Operator

IP network

SDN Realtime Network & Service Management

Infrastructure Cloud NFV

Holistic approach Successfully Tested All

Elements

Executed in radically lean way IP and Optical Integration to lower costs Scalable up to the highest bandwidth

• Based on SDN concept • Software flexibility of previously HW dominated

operator • Standardized open interfaces • Accelerated product introduction

REAL-TIME NETWORK AND SERVICE MANAGEMENT

DRASTICALLY SIMPLIFIED IP NETWORK

Tight integration of data centers and IP network = Infrastructure Cloud, foundation for NFV

Fully automated – = Cloudification of network functions

Minimized latency High bandwidth apps

INFRASTRUCTURE CLOUD

General architecture assumptions (1/2)

Generic concept: Provide auto scaling capabilities for NFVs HW independent API to automate operational procedures and avoid vendor lock-in Abstraction and separation of architectural layers Avoid dependencies between applications and hardware Simplify and automate business processes Automated deployment on both layers, infrastructure as well as application High degree of standardization Single-point of Infrastructure Cloud orchestration Centralized management of all locations Use of COTS products Use of open-source software and open standards Scalable architecture

General architecture assumptions (2/2)

General design rules: Multiple data centers acting as one distributed Infrastructure Cloud Two tier data center concept (FDC / BDC) Transparent infrastructure platform for internal customer and services (IaaS) (not for public

customers, no public IaaS offering) Internal (tenant) networks are logically separated IPv6 preferred Use of distributed storage (Ceph) for VM disks Use of object storage for applications KVM as hypervisor Open Stack as Cloud operating system Ansible as preferred automation tool Virtualized security zone concept (named “placement zones”) based on DTAG SEC

requirements Use of TOSCA and HEAT as application on-boarding standard

Frontend daTa center– FDC

Fully automated High availability through georedundancy and integration into IP routing

(to be supported by VNFs) Used to deliver low latency, high bandwidth services, and specific services which are essential for building small

failure domains (e.g. DNS, DHCP) Optimized for North-South traffic flow Not designed for storing persistent data Option to connect servers directly to core router Physical security dependent on central office environment Energy and cooling dependent on central office environment

Data centers at core router locations, optimized for massive IP network I/O and low latency

Backend daTa center– BDC

High degree of automation Provides high availability using infrastructure redundancy Design for storing persistent data North-South and East-West traffic Offers all placement zones for security requirements Physical security in place Highly efficient energy & cooling systems Option to host non-virtualized components of network functions

Highly available centralized data centers, optimized for production of virtualized network functions

FDC vs BDC

High bandwidth

Low latency

Stateless

No service chaining

No permanent sensitive data

Special network functions (DNS, DHCP, NTP, …)

FDC

Statefull

Service chaining

Permanent sensitive customer data

HA configuration

Two/three compartment zone

BDC

BDC building blocks

Network block

Management block

Computing block

Storage block

Backup block

Perimeter block

BDC Building Blocks

BDC Placement zones

Security zone

Management zone

Militarized zone

Demilitarized zone

Exposed host domain

BDC Placement Zones

application onboarding

29 – Confidential – 30.10.2015

Orchestration

What is the Infrastructure Cloud and its Benefits

Ensure strategic fit of cloud initiatives and sort out responsibilities

Foster process to use OpenSource community and internal know-how

Lean cloud processes (new roles in operations): Design2Cost,, loose coupling, delivery speed

Ensure strategic fit of cloud initiatives and sort out responsibilities

Foster process to use OpenSource community and internal know-how

Lean cloud processes (new roles in operations): Design2Cost,, loose coupling, delivery speed

Cloud Production Model Cloud Production Model

Define and deploy architectural patterns for fast system development cycles (reuse)

Define dependencies in configuration

Carrier grade model for orchestration

Core Components lead to reliable cost lines

Define and deploy architectural patterns for fast system development cycles (reuse)

Define dependencies in configuration

Carrier grade model for orchestration

Core Components lead to reliable cost lines

Configuration, orchestration Configuration, orchestration

Automated installation of OpenStack

Update capability Additional tooling: metering,

monitoring, integration to ticketing

HW cost optimization: low-cost storage, SDN, …

Automated installation of OpenStack

Update capability Additional tooling: metering,

monitoring, integration to ticketing

HW cost optimization: low-cost storage, SDN, …

OpenStack: install / update OpenStack: install / update

Cloud Production Model

Configuration, Orchestration

OpenStack Efficient Cloud Management: Install / Update

Application Management

Application

Cloud Infrastructure Cloud Infrastructure

Management

Infrastructure Orchestration

Application Orchestration

Application management - Overview

Application Management is structured into two functional domains Application Lifecycle Management (ALM) applies

automation capabilities to the product lifecycle of application software; the key methodologies are: Continuous Integration Continuous Delivery

Application Orchestration (AO) orchestrates instances and resource demand of an application (or several interacting/chained applications) dynamically based on models. It triggers environment creation & changes towards Infrastructure Orchestration which actually provides the resources

Infrastructure Orchestration provides the automation of the Infrastructure environment but is not aware of the virtual machines‘ purpose and the applications on top

Application Lifecycle Management

LAYER TOOLSET Use-Cases

AUTOMATION

Service activation, fulfilment, assurance ... acts as northbound interface to further OSS

Lifecycle management of virtual network functions and network related applications The lifecycle management supports: provisioning, configuration, patching / upgrading, monitoring,

auto scaling and self-healing and phase-out.

Orchestrated lifecycle management of interdependent infrastructure resources over several data enters.

The lifecycle management supports: provisioning, configuration, patching / upgrading, monitoring, auto scaling and self-healing and phase-out.

Lifecycle management of individual virtual infrastructure related resources , e.g. compute (virtual servers), virtual storage (block- and object-storage) and virtual networks (overlay network / SDN)

Infrastructure Orchestration

Infrastructure as a Service

Bare-Metal

Virtual Network Functions / Applications

Infrastructure Orchestrator

OpenStack

e.g. MaaS/Juju

Nagios/Ganglia/...

RT-NSM / Appl. Orch.

RT-NSM / OSS Services

installation/upgrade/de-installation of the host operating systems basic network configuration of the server and main network elements installation/upgrade/de-installation of the management toolset monitoring

Requirements for Applications some examples

Requirements Compliance

•Awareness of 2-tier data center concept (FDC/BDC)

•Application/VNF SHALL be deployable in an OpenStack cloud

•No HW dependency

•Application resilience

•“Cloud-aware” applications: scaling, automated install, use of object storage

•Stateful Application Information

•Prediction of resource consumption per business function

ALM Requirements

•System /Artifact Versioning

•Artifact Dependencies

•CI Process: automated tests, traceability & verification of rollback

•CI Process audit

•Application configuration: model-based methodology

•Configuration Idempotence

application Work stream Roadmap

Stage 3: Commitment and Approval to start project for deployment on Infrastructure Cloud

Stage 2: Check of applications according to cloudification criteria

Continuous onboarding on Infrastructure Cloud

The roadmap will be developed in an agile mode to deliver fast results and to guarantee optimal flexibility

Stage 1: Identification of cloudification candidates for backlog

Stage 4: Compilation of a new version of application roadmap

Identification

Sanity Check

Compilation

Commitment

Backup

36 – Confidential – 30.10.2015

Four Major OpenStack Components

Compute/Nova: provision and manage large networks of virtual machines Object Storage/CEPH: Create petabytes of reliable storage using standard servers Image Service/Glance: Catalog and manage large libraries of server images

Network Service /Neutron: Catalog and manage virtual networks

+

Other components: Identity Service/Keystone Dashboard/Horizon Block Storage/CEPH Orchestration Service/Heat Database Service/Trove Telemetry/Ceilometer

Compute/Nova Key Features

2. Horizontally and

massively scalable

1. REST-based

API

3. Hardware agnostic: supports

a variety of standard

commodity hardware.

4. Hypervisor Agnostic: support for KVM,

Xen, Microsoft Hyper-V, VMware LXC and

ESX

Compute (1/2) The project envisions the usage of COTS (Commercial Off-The-Shelf) hardware and software. OpenStack can be deployed on any hardware supported by an OpenStack compatible Linux

distribution. A compute node has to provide “compute” functions only. The Compute node has to comply to all security requirements. A compute node must use local storage only for the operating system. VM data will be stored

on a IP connected storage (CEPH).

Compute (2/2) A compute node comprises of the following software components:

• Linux operating system • KVM • libvirt • OpenStack components (nova-compute) • Virtual networking solution (vSwitch and Juniper Contrail)

Image Service/Glance

2. REST-

based API

1. Store &

retrieve VM

images

3. Compatible with

all common image

formats 4. Storage agnostic: Store

images locally, or use

OpenStack Object Storage,

HTTP, or S3

Distributed Storage/Key Features

1. REST-based API

6. Account/Container/Object structure (not

file system, no nesting) plus Replication (N

copies of accounts, containers, objects)

5. No central

database

required

2. Data distributed evenly

throughout system.

3. Runs on

commodity

hardware

Ceph Storage (1/2) Ceph is a distributed object store and file system designed to provide excellent performance,

reliability, high availability and scalability. Ceph provides object, block and file storage in one unified system and is designed for data

center scale with 10s to 10.000s of storage servers and from terabytes to exabytes capacity. The Ceph cluster architecture has no single point of failure, is designed to be self managed,

balanced and healed. Ceph runs on any commodity x86_64 hardware based on Ethernet and storage components

like HDD/SSDs via SATA/SAS/Ethernet interfaces. Data reliability, consistency and cleanliness are achieved through replication.

Ceph Storage (2/2) Ceph serves block devices to virtual machines via Rados Block Devices (RBD). These devices

are striped over multiple objects in the Ceph Cluster while each object is distributed and replicated over the cluster.

Ceph provide via the Rados Gateway (RadosGW) a RESTful object store interface. The RadosGW can get accessed either via a Swift or an Amazon S3 API.

Network/Neutron Key Features

App Svr

OS

VM

App Svr

OS

VM

Create multiple, virtual, isolated networks per tenant (FE-Net, DB-Net)

Multiple network interfaces per VM (in-line services)

Create ports on networks (QoS, profiles) and attach VM’s

Have control over your own “private” IP addresses

Access through a user-friendly CLI and GUI (Horizon)

Invoke additional capabilities through extensions Support different underlying networking

implementations (VLANS, L2/L3 tunnels, etc.)

Create/delete private network

Create “ports” and attach VM’s

Assign IP address blocks (DHCP)

Network Decision of the particular layout depends on the capacity planning of the particular DC. In

general, it is better to have fewer tiers as this decreases complexity, costs and/or cabling efforts.

Selected topology must be able to fulfill following requirements:

• Capacity of the fabric can be scaled horizontally • Feature-set needed for operation of the fabric must be narrowed and standardized to

enable multi-vendor setup • Selected protocols must minimize complexity