The Impact of CloudRMIT, October 2014

Rich Bayliss

bayliss@juniper.net

Agenda

New Service

Infrastructure

Simplified Modern Network Architectures

Software Defined Intelligent Networking

x86

50BCONNECTED

DEVICES

3.8BBROADBAND

INTERNET USERS

5.3BTABLETS &

SMARTPHONES

BY

20

16

THE POWER OF A CONNECTED WORLD

What Is The Best Way Forward?

Starting From First Principles:Access Evolution To Gigabit Era

CURRENT EMERGING

CELLULAR3G HSPA+ 21-84Mbps/5.8Mbps+

LTE-Advanced 300Mbps/51Mbps (cat 6)

LTE-Advanced (8x8) 3Gbps

LTE-Advanced (E-UTRA) 1Gbps+

WIFIWiFi (802.11n) 288-600Mbps (2.4/5GHz)

WiFi (802.11ac) 1.3Gbps (5GHz)

WiFi (802.11ac II) 3.5Gbps (5GHz)

WiFi (802.11ax) 7-10Gbps

WiGig (802.11ad) 7Gbps (60GHz)

FIBERGPON (G.984) 2.488Gbps/1.244Gbps

10GPON (G.987) 10Gbps/2.5Gbps

DOCSIS 3.0 (J.222) 160Mbps+/120Mbps+

NGPON2 (G.989) 40Gbps/10Gbps

DOCSIS 3.1 1-10Gbps/1Gbps+

COPPERADSL2+ (G.992.5) 24Mbps/1Mbps

VDSL2 (G.993.2) 100Mbps/100Mbps

VDSL2-Vectoring (G.993.5) 200-300Mbps

G.Fast/FTTdp (G.9701) 500Mbps-1Gbps

Cloud First Approach To Services

PRODUCTION CONSUMPTION

END USERSCONNECTIVITY &

COMMUNICATIONS

ONLINE &

CLOUD SERVICES

ENTERPRISES

PRODUCTS,SERVICES, INFORMATION

PUBLIC

HYBRIDEND USERS

PRIVATE

BUSINESS CRITICAL IT DATA CENTER

SECURE PLATFORM FOR INNOVATION & SCALE

CLOUD MODEL SHIFTS TRAFFIC TO DATA CENTRES.

3-TIER APP MODEL INCREASES EAST-WEST TRAFFIC WITHIN DCFurther Reading: David Clark. ‘The Design Philosophy of the DARPA Internet Protocols’

Cloud In Australia

Source: Adrian Cockcroft @ Structure 2014 (http://slidesha.re/ZnhScq)

Why Does Telecoms Evolve Slowly?

• Evolution requires predictable yet massive shifts.

• Revolutions occur outside the mainstream.

• Evolution often seen as a threat not an opportunity.

• Building/Buying routers is a point in time decision.

• Standards take years to ratify.

BUILDING NETWORKS IS EXPENSIVE, TIME CONSUMING AND RISKY

Are Telecoms Companies Ready to Evolve?

A Brief Recap On The Diffusion of Innovation

Innovators(2.5%)

Early Adopters(13.5%)

Early Majority(34%)

Late Majority(34%)

Laggards(16%)

ENTERPRISE

TELCO

WEB SERVICES

3-12 MONTHS 24-48 MONTHS 48+ MONTHS

DEVOPS, SDN & NFV

Architectural Principles and Philosophy

How to Design a Router

Classic Considerations:• Scale• Function• Density• Location• Performance• Cost (CAPEX, OPEX)

Generalisation of market requirements lead to final design choices

?

How to Design a Traditional Network?

SDN and NFV Summary

Software Defined Networking – An evolution in network architecture

Network Functions Virtualisation – An evolution in equipment architecture

Equipment Architecture

Network Architecture

Standards Problem Space:

1. What functions of the existing network equipment should be virtualized ?

2. What impact does SDN have on existing network architectures ?

3. What impact do NFV and SDN have on each other ?

Network Function Virtualization•Network functions in VMs on x86•Service Chain physical network to VNFs•Elastic scaling incl. scale out•More choice, faster innovation

Software Defined Networking•Centralized control logic with global

optimisation•Network abstraction, programmability•DevOps and Automation

Software Defined Networking:Where Should Transport Paths Be Defined?

On Box First Box On Cloud

WHERE IS THE BEST LOCATION TO DEFINE SERVICE PATHS?

E.G. RSVP E.G. IETF SPRING E.G. SDN/TEC

Example: Compartmentalization & Functional Decomposition

1RU TOR Switch(Folded Clos)

EG. 2000+ 40GE Ports

Modular Chassis(Fat Tree)

EG. 2000+ 40GE Ports

DEVICE COMPLEXITY/CAPEX VS ARCHITECTURAL COMPLEXITY

Tier 1 Provider

WEB SERVICES

New Software Tools Will Change Work Practices

IT ISN’T JUST ABOUT WORKING FASTER, IT’S ABOUT WORKING DIFFERENT.

NEW TOOLS DISRUPT TRADITIONAL WORKFLOWS.

Network Functions Virtualisation:Extracting Services From the Network

On Box x86 POD On Cloud

WHERE IS THE BEST LOCATION TO DEFINE SERVICE PATHS?

Logical Decoupling of Services From Hardware

Native or x86 Blade x86 Server Cloud IaaS

ALL OPTIONS ARE VALID. NO ONE-SIZE FITS ALL SOLUTION

Example: NFV is Changing Hardware Design

JUNIPER NG-SWITCHTRADITIONAL SWITCH

SILICON

SINGLE CORE CPU

NETWORK OS

FLASH MEMORYBUS

DUAL CORE SANDY BRIDGE

LINUX

KVM

VM VMVM

JUNOS GUESTJUNOS

SSD DDR3BUS

SILICON1588

PTP

Tier 1 Provider

WEB SERVICES

Example:ETSI NFV MANO + BBF MSBN (TR-178)

EXISTING ARCHITECTURES NEED REWRITING… AGAIN.

Traditional OSS/EMS ETSI NFV MANO

Source: Broadband Forum contribution BBF2014.901.00 ‘NPIF proposal to add the Virtualization Layer’

MERGE

Per User/App/Flow Service Chaining

Service Scale Out

Service Chaining Virtual Network Functions

Chain of virtual servicesSERVICE CHAIN

DPIDPI DPIDPIDPIDPIDPIRouter RouterFirewall DPI NATCache

ROUTER

DPI

VIRTUAL NETWORK OVERLAY USING VXLAN, MPLSoGRE, MPLS etc.

Summary of Architectural Shifts

• Device Model from scale-up to cost-efficient scale-out

• Functional decomposition, particularly for virtual network functions

• Loosely coupled components (APIs/Service Exposure)

• Good-enough hardware with failure tolerant architectures

• Outsourcing of non-critical business functions

• Shift away from static OSS for service delivery

• DevOps with culture of quality and experience

• Shifting traffic flows with rapid inorganic movements.

• Increase in need for application engineering.

Q&A