Radisys and Wind River present on the evolution to the Telecom Cloud and how cloud technology and network virtualization will provide both big opportunities and challenges for operators. Important details and insights are shared on Network Function Virtualization (NFV), Software Defined Network (SDN) and Virtualization.
2. 2
Agenda
Telecom Cloud Introduction
• Eric Gregory – Director Product Management, Radisys
(eric.gregory@radisys.com)
Software Defined Networking
• James Radley – Senior Architect, Radisys
(james.radley@radisys.com)
Virtualization
• Darshan Patel - Director Product Management, Wind River
(darshan.patel@windriver.com)
Network Functions Virtualization Use Case
• Denis Bouffard - Director Product Management, Radisys
(denis.bouffard@radisys.com)
3. 3
Market Drivers:
Decouple forwarding &
control processes
CapEx & OpEx savings
by organizing network
resources
Dynamic workload
allocation & resource
affinitization
Enablers:
OpenFlow
Market Drivers:
CapEx & OpEx savings by
efficiently utilizing CPU
resources
Decouple application from
underlying hardware
Green: Power & Cooling
efficiencies based on
network traffic
Enablers:
Virtualization
OpenStack
Virtual Switching (Open
vSwitch)
Software Define Networking Network Functions Virtualization
Telecom Cloud Components
SDN and NFV are becoming coupled as network transformation begins
4. 4
SDN NFV
TEMs trying to
maximize
utilization through
automation
Operators
desiring improved
financials
Telecom Cloud Components
Determined to
leverage existing
hw architectures
Must deliver cost
savings to stay in
the game
Determined to
follow Enterprise
Virtualization Path
High Availability
requirements must
still be met
SDN and NFV are becoming coupled as network transformation begins
5. 5
Telecom Cloud Components
SDN NFV
TEMs trying to
maximize
utilization through
automation
Operators
desiring improved
financials
Determined to
leverage existing
hw architectures
Must deliver cost
savings to stay in
the game
Determined to
follow Enterprise
Virtualization Path
High Availability
requirements must
still be met
6. 6
Where is the
middle
ground?
Where
to
start?
TEMs will need an approach that enables a non-disruptive migration
Telecom Cloud Components
Determined to
leverage existing
hw architectures
Must deliver cost
savings to stay in
the game
SDN NFV
Determined to
follow Enterprise
Virtualization Path
High Availability
requirements must
still be met
Operators
desiring improved
financials
Operators trying to
maximize
utilization through
automation
7. 7
IT Infrastructure is not a “drop in” for telecom
Enterprise Cloud
Enterprise Cloud ≠ Telecom Cloud
Less strict 3 9s
reliability requirements
Some Latency
Homogeneous Transport
(Ethernet)
Single Control Protocol
(OpenFlow)
Controlled Data Center
Operating Environment
Smaller Number of
Warehouse-sized Data Centers
Telecom Cloud
Strict 5 9s
reliability requirement
Low Latency
Heterogeneous Transport
(Optical, Ethernet, Wireless)
Multiple Control Protocols
(OpenFlow, SNMP)
Regulatory Requirements
(NEBS)
Larger Number of Smaller,
Distributed Data Centers
8. 8
Market TimingLevelofNetworkTransformation
Steps per Year
Identify Apps for SDN
Implement Separation of Control & Data plane
for targeted App in a single platform
Select second app for
control/data separation
Separate out control plane
to dedicated platform
Consolidate control planes
on to a single platform
Begin virtualization of control plane
(Follow virtualization steps)
Spread applications freely amongst
geographically diverse data centers
Identify Control
Plane Apps for NFV
Implement Virtualization framework
(Hypervisor, Optimized OVS and Orchestration)
Virtualize 1-2 Applications, each
on dedicated core or processor
Virtualize 1-2 Applications on
the same core or processor
Virtualize 1-2 Applications on the same core
or processor within same data center
1 2 3 4 5
RSYS expects Phase I
NFV/SDN transformation to
be complete in 5 years
SDN
NFV
10. 10
What is Software Defined Networking?
Network management paradigm to separate out
network control from forwarding planes
• Provides automated network control
• Co-ordinated and timely updates across disparate network
elements
• Enables a competitive and complementary eco-system
• Exposes inherent features of network equipment
– which may otherwise have not been accessible via black box s/w
11. 11
SDN: a three layer cake
Forwarding plane:
• Network elements which physically interact with network traffic
• May be implemented as;
– Virtual switches running in s/w (such as Open vSwitch)
– Switch based solutions (using TCAM tables for ACL style rules)
– Network Processor (NPU) devices – apply additional services such as
fragment reassembly & local ARP resolution
• Device parses packet, applies defined actions if a known flow
– Hands off to controller if flow previously unknown (or forgotten)
12. 12
SDN: a three layer cake
Controller plane:
• Provides network service functions, such as routing
• Manages flow tables across multiple forwarding plane
elements;
– Forwarding Information Bases (FIBs) and ACLs, etc
• Correlates flow statistics from the various forwarding plane
network elements under it’s control
• Multiple controller plane elements may overlap the set of
managed network elements (allowing HA operation)
13. 13
SDN: a three layer cake
Orchestration:
• Tightly coupled to the management of the life cycle of VMs
– Responds to the elastic demand for VMs and the dynamic movement
of resources around the cloud
• Ensures that flow paths are created to connect packet
streams to the right VM
• Is expected to be the entity responsible for delivering carrier
class HA
• Is often portrayed as the panacea for all cloud based
networking problems – the box where
“some magic will happen”
14. 14
What is OpenFlow?
Specification now ‘managed’ by the
Open Networking Foundation (opennetworking.org)
OpenFlow is;
• An asynchronous message based protocol
• For defining ACL style rules
– Parse out selected header fields to match against masked bit patterns
– Matches produce a list of ‘instructions’ to be executed on the packet
• Multiple cascading look-up tables are supported
– Tables cascade through resulting instructions specifying ‘GoTo next table’
– Metadata (results) from a preceding table search can be used in
subsequent table searches
– Instructions can be accumulated across multiple searches
15. 15
OpenFlow
OpenFlow is arguably not a perfect solution
• Missing a standardized definition of many common packet fields
• Assumes that the forwarding device is pretty dumb
• Urgently requires common abstraction definitions of how to
implement core network functions such as routing, NAT & firewalls
Other ‘southbound’ SDN APIs exist
• Notably IETF’s ForCES
– But it’s like VHS vrs Betamax, the best technology does not necessarily
win against market momentum
16. 16
Cascading tables for a routing function
NH_VRF_ID NH_IP
VLAN-ID VRF_ID
VRF_ID Dst_IP Dst_IP Mask NH_Index
NH_Index NH_VRF_ID NH_IP
Dst_MAC Interface
1
1
Table_0: VLAN_VRF_TABLE
Table_1: IPv4_FIB_TABLE
Table_2: IPv4_NH_TABLE
4k entries
128k entries
4k entries
4k entries
Table_3: IPv4_ARP_TABLE
Packet Header
Field
Resulting
Metadata
Metadata used
in search
OF mask field
17. 17
Functional Abstraction
Abstraction models for standard network functions are
a MUST HAVE
• So that diverse forwarding plane solutions can be managed by
common controller plane applications
• To allow a competitive eco-system to develop
• To prevent inadvertent vendor lock-ins
Need abstraction definitions for;
• Routers
• Load balancers
• NAT Firewalls
• Traffic Shapers
18. 18
Poll question
What is your current strategy for developing/deploying
SDN based controller plane solutions?
a. No plans currently in regard to leveraging SDN technology
b. Will develop own SDN controller software
c. Will use a solution based on an open source initiative
d. Will use a solution based on a proprietary commercial solution
e. Don’t care about the controller plane,
orchestration is what matters
20. 1. Separation of data & control planes
2. Rapid deployment and lower OpEx for provisioning new services
3. Movement towards open APIs for provisioning virtual machines
4. Emergence of cloud services and SDN techniques
Why Virtualization?
20
83%
Virtualization in Next Product Design
23. Open source innovation that provides high performance, real-time
kernel virtualization for next-generation telecom equipment that…
Provides near native hardware results
Enables services to be run flexibly anywhere on the network
Supports hardware consolidation
Fits the specific needs of the networking and telecom industry including carrier
grade requirements
And solves the following challenges…
Latency and throughput performance requirements
New service deployment time constraints
Network scaling and operating costs
Open source compatibility issues
AND…the transition of networks into the cloud
What is Wind River Open Virtualization
Profile?
23
24. 24
It’s all about Performance! (KVM vs.
Wind River Open Virtualization Profile)
WR OVP (vs Native): Average latency increases of 1.5x = SUCCESS
KVM (vs Native): Average latency increases of 7.4x = FAIL
1.5x
27. Additional reference information
27
Open Standard Virtualization with SDN and NFV
White Paper:
http://www.windriver.com/whitepapers/ovp/
01.Org Open Source Packet Processing Project:
https://01.org/packet-processing
29. 29
Media Processing as a Service
Challenges
MPaaS Vision:
• Real-time media processing already in private/hybrid clouds
• Adapt media processing for virtualized architectures (NFV), Public
Clouds, etc.
Several MPaaS Challenges:
• Real-time Network Performance
• Media Processing in Virtual Machines
• Secure Access for Media and Control Planes
• High Availability and Reliability
• Resource Optimization and Management
• Service-aware Load Balancing and Traffic Redirection
• Service Provisioning and Orchestration
• Cloud Service Delivery Frameworks
• Cloud/Web/Mobile Applications
• Communications Enabling Developer APIs
30. 30
MPaaS Challenges
Real-time Network Performance
Many classic IT applications don’t have
stringent performance requirements
MRF Media Processing is different:
• Rule-of-thumb: End-End 150 ms maximum delay
• Hard Real-time Performance on COTS VM Servers
• Platform Independent Media Processing Architecture
• Reduced Media Plane Delays (e.g.: 5 ms packetization)
• Bandwidth Optimized Multi-Core Compute and I/O
• Remote/Distributed Media Storage (HTTP, NFS)
31. 31
MPaaS Challenges
Media Processing in Virtual Machines
Virtualization often used in the Cloud
Virtualization can impact real-time
performance under load
MRF on VMs:
1. Maintain acceptable media quality (delay, jitter, packet loss, …)
2. Ensure predictable media quality
3. Minimize capacity degradation compared to bare metal
With or without demand elasticity and VM migration
32. 32
MPaaS Challenges
Media Processing in Virtual Machines
Lessons learned:
• Define capacity/performance/media quality targets before starting
• Know your VM technology and application architecture in detail
• Trial and error to find ideal affinity for RTP/SIP/OAMP processes
• Achieving 90% of bare metal capacity is feasible
• Migrating VMs in real time can be problematic
• VMs spanning sockets have proven sub-optimal
• Multiple VMs may be needed for optimum capacity
• Hardware independence remains a challenge
COTS IA HW PLATFORM
0 1 2 3 4 5 6 7
0 16 1 17 2 18 3 19 4 20 5 21 6 22 7 23
0
0 1 2 3 4 5 6 7 8 9
SWMS (VM1)
Socket
Physical Core
Hyper-threaded Core
Virtual CPU
Host
10 11 12 13
34. 34
T-Series is the choice
Cloud services and virtualizations:
What is the best platform?
[Source: Seeing through the Cloud A survey of mobile operators' views on the
evolution of the mobile core., Monica Paolini, Senza Fili Consulting, Feb 2013]
ATCA is the clear
choice for telecom
environments
35. 35
Thank You for Attending…
~Please fill out our short survey~
We Value Your Feedback
Check out previous Webinars in this series:
Monetizing VoLTE and RCS
http://www.slideshare.net/Radisys/radisys-mavenir-monetizing-
volte-and-rcs
LTE-Advanced & Small Cells – Capacity, Coverage & Customer
Satifaction
http://www.slideshare.net/Radisys/2013-radisys-airspan-webinar-
smallcellsfinal