Bringing OTTs and Telecom SPs together Kumar N Sivarajan, CTO SDN and OpenFlow
OTTs
Evolving Network Overview
© Tejas Networks Proprietary. All rights
reserved. 2
SPs Users
Pay for Bytes
“Utility” Service
Provider
Pay to Over the
Top Operator for
ad free content
OTTs pay for
connectivity but
do not share
ad/user revenue
3
User Communication Needs
Interact through Skype, Whatsapp,
Hangout
Collaborate through Webex, Citrix, skype, google+, LCG Grid
Connect through Google, facebook
© Tejas Networks Proprietary. All rights reserved.
4
User Perception of Service Providers and OTTs
Visualizes the service provider as a utility provider for “bytes” and as
“wires” to OTTs. Visualizes OTTs as free/ ad free content provider with good UI and/or content
Changing this user perception and building new business models (other than utility model) for such a wide variety of users is difficult and costly for SPs. OTTs have to go through at least one service provider to reach user and user QOE is linked to network quality
© Tejas Networks Proprietary. All rights reserved.
OTTs Network View
5
OTT#1 Virtual Network
OTT#2 Virtual Network
• OTTs runs over best effort but connected network free of cost. • OTTs make revenue through ads or user (for ad free content) • Refuses to cooperate with SPs
© Tejas Networks Proprietary. All rights reserved.
6
Service Providers Dilemma
Source: Mobile Voice and Data Forecast: 2012–17, Ovum 2012
•Operator revenue has peaked. Little scope to charge more for “bytes” delivered. •Cost of “bytes” delivery not growing proportionate to revenue from “bytes”.
•Service provider finds more and more of his application being provided by OTTs for free/nominal amount • Service provider revenue not enough to fund good quality network Infrastructure. • Eventually can affect OTTs delivery quality
© Tejas Networks Proprietary. All rights reserved.
OTTs
Way forward: Cooperation, not confrontation
© Tejas Networks Proprietary. All rights
reserved. 7
SPs Users
• OTTs are more competitive market compared to
monopoly/duopoly of SPs • OTTs and SPs need to work
together to differentiate on network quality in addition to content quality else both will suffer and lose the end
user
OTTs Network View: SP abstraction
8
OTT#1 Virtual Network
OTT#2 Virtual Network
• SPs need to provide a value added agile and dynamic virtual network to OTTs and give “preferential” access if possible. •OTTs can use knowledge of their virtual network to provide a superior network experience to users than competitor OTTs in addition to UI and content differentiation.
© Tejas Networks Proprietary. All rights reserved.
OTT + SPs: User differentiation of Network Quality
9
Skype Virtual Network
Changes resolution based on network loss
Reroutes traffic due to loss/jitter
OTTs can start to behave as true Application Service Providers concerned about real-time user experience, rather than as
Best Effort providers. © Tejas Networks Proprietary. All rights reserved.
OTT + SPs: Win-win bandwidth saving for both
10
Hangout Virtual Network
Convert to multicast Reroute from LTE to Carrier WiFi for application level restoration
© Tejas Networks Proprietary. All rights reserved.
Access
Core
How to build the network? Step#1: Understanding the SP Network
Aggregation
Access
Operators need to develop a “Converged View” of their mobile/fiber access, wire-line aggregation and
core networks, and view them as one network rather than as distinct elements.
11 © Tejas Networks Proprietary. All rights reserved.
• Rapid innovation in network technology requirements of end user compared to a sluggish rate of network refresh and training which cannot be speeded up even if needed
• Massively diverse user groups with wide variety of requirements from data rates as low as 64 kbps to multiples of 10GE, different level of security and SLAs, complex billing methods, etc.
• Demand for bandwidth growing rapidly
• Increasing TCO (CAPEX & OPEX) but no proportionate growth in revenue
• Increasing complexity in data routing; 5400 IETF RFCs
Solution Step #1: Understanding the SP Challenges
© Tejas Networks Proprietary. All rights
reserved. 12
xPON
OTN/DWDM
Solution Step #1: Understanding the SP Network
MPLS/MPLS-TP
LTE
Access: LTE (Wireless), xPON (wireline) Aggregation: PTN based on MPLS-TP, L2MPLS, IP/MPLS
Core: OTN with ODUFlex capability, DWDM, 40/100G Coherent optics
13 © Tejas Networks Proprietary. All rights reserved.
OTN • OTN: Scalable client agnostic but
granular “pipes” with protection
• Flexible bandwidth option through ODUFlex @ 1Gbps granularity
– ODUFlex (CBR)
• Clients are mapped to this using bit-synchronous mapping procedure (BMP)
– ODUFlex (packet)
• Packet based clients are mapped using GFP-F
• G.7044/G.HAO allows hitless increase/decrease in ODUFlex capacity
• Drop and continue for multicasting traffic
• Overhead, TCM provide efficient multi operator circuit monitoring and FEC
ODU Client
FrameOH OTU OH
OPU OH ODU OH
OTU FEC
Client#1 Client#n
ODUFLex#1 ODUFlex#n
OPU OH
Payload
ODU OH
Payload
OTU OH
Payload OTU FEC
Using BMP or GMP
Using GMP (Generic
mapping procedure)
14 © Tejas Networks Proprietary. All rights reserved.
MPLS/MPLS-TP: Scalable mapping of Ethernet
LSP Label TC S TTL
GAL TC S TTL
0001 Ver Reserved ChannelType
PID MCC/SCC
MCC/SCC Message
LSP Label TC S TTL
Payload (EthernetPW, SAToP,…) MPLS data plane maps
Ethernet or TDM
packets over PW
Control Messages
Data Messages
15 © Tejas Networks Proprietary. All rights reserved.
• MPLS/MPLS-TP: Scalable CIR/EIR “pipes” with protection
• Flexible bandwidth option @ 64Kbps granularity
• Support for unicast, multicast and broadcast traffic.
• Control messages enhanced with GAL/G-ACh to handle proactive and reactive monitoring of network
Access: LTE, xPON
16
Copper cannot meet the future bandwidth
requirements and will be replaced by fiber/PON access or wireless converging to LTE.
© Tejas Networks Proprietary. All rights reserved.
LTE Provide variable and dynamic bandwidth pipes of 1Mbps granularity with Aperiodic/Periodic Channel Quality Information or CQI PON provides dynamic bandwidth pipe in UL direction and operates in broadcast mode in DL and OMSI. PON is inherently broadcast in DL while LTE does it with eMBMS
• Sub-Mbps granular LTE pipes with sub-ms scheduling
• Sub-Gbps granular MPLS-TP pipes
• Gbps granular OTN pipes
Variable rate “pipes”
• Unicast
• Multicast/Broadcast
Ingress/Egress points of “pipes”
• Latency, jitter, loss, buffer levels Monitoring of
provisioned “pipes”
• OTN and MPLS-TP have network level protection
• LTE provides protection in case of multicast traffic through MBSFN Area
Protection of “pipes”
Solution Step#1: Network (OTN,MPLS-TP,LTE) Abstraction
17 © Tejas Networks Proprietary. All rights reserved.
Solution Step #2: Revisit the Computing Evolution
18
• Completely Centralized processing with UNIX Mainframes • Monitors linked to the Mainframe with no distributed control processors
• Completely distributed control processor architecture • Modular hardware, OS, Application
• Centralized datacenters, large processors , memory • Distributed smart phones, phablets; smaller processors, memory but modular hardware, OS and Apps through open APIs to data centers.
© Tejas Networks Proprietary. All rights reserved.
© Tejas Networks Proprietary. All rights reserved.
Solution Step #2: Extrapolate to Networks
19
• Centralized Management plane for provisioning and management • Distributed NE with minimal control plane processing
• IP/MPLS has completely distributed architecture with highly powerful control processors • Minimal management plane and no centralized control.
• Centralized Network Hypervisor Controllers (NHC) • Minimal control plane functionality on the node • Standardized data planes with Open API access to NHCs.
OTN MPLS-TP
Solution Step #2: Extrapolate to Networks
(Proprietary) API
to the data plane (I-API)
Extremely
Smart,
slow
Minimally
Smart, Fast
LTE
Open APIs (E-API)
For OTT Access Logically-centralized
Network HyperVisor
Controller (NHC)
20 © Tejas Networks Proprietary. All rights reserved.
Windows Windows
x86
Virtualization
Windows Windows Windows Linux
Windows Windows FreeBSD
Apps Apps Apps
Computer Industry
Windows Windows
Virtualization
Network OS
Windows Windows NOX Windows Windows Beacon
Apps Apps Apps
Network Industry
I-API
Solution Step #2: Extrapolate to Networks (SDN)
Open Flow Architecture
© Tejas Networks Proprietary. All rights
reserved. 22
OF v1.3.2 OF-CONFIG v1.1.1
OTT Space is more competitive than SP space and hence OTTs will need to work with SPs for differentiating in the near future.
OTTs perceived value is not just the content and UI differentiation but also the perceived connectivity as experienced by the end user.
Infrastructure SDN concept must be extended to span LTE, MPLS-TP and OTN to provide a “converged network” view to OTTs.
Hierarchical API Infrastructure with Open E-API to OTTs and Closed I-API within the service-provider network: Allows virtual network scalability by abstracting the underlying multi-layer network complexity.
Summary
24 © Tejas Networks Proprietary. All rights reserved.
• I would like to thank Jishnu Aravindakshan for the production of this presentation.
Acknowledgement
© Tejas Networks Proprietary. All rights
reserved. 25
2008-2009
OpenFlow/SDN proposed
• Nick McKeown, Stanford university proposes OpenFlow a way for researchers to run experimental protocols in the networks they use every day
• Kate Greene proposes concept of Software Defined Network (SDN)
2011
OpenFlow for Switches
• Version 1.1 of OpenFlow protocol released
• Indiana University launched the SDN Interpretability lab in conjunction with the Open Networking Foundation (ONF)
2012
OpenFlow/SDN for Routers
• Version 1.3 of OpenFlow protocol published
• Big Switch Networks released an open source package for OpenFlow software
• HP starts support
• Google redesigns itself to support OpenFlow
• Cariden Technologies proposes Infrastructure SDN for visibility and control of network resources.
SDN and OpenFlow
30
•SDN should be extended to span OTN, MPLS-TP and LTE network to provide holistic view of network to OTTs •SDN can reduce network cost by minimizing node hardware costs •SDN API Hierarchy consisting of E-API and I-API. I-API abstracts the network layer complexity. E-API provides a useable OTT virtual network interface.
© Tejas Networks Proprietary. All rights reserved.
Directly programmable:
Network control is directly programmable because it is decoupled
from forwarding functions.
Agile:
Abstracting control from forwarding lets administrators dynamically adjust
network-wide traffic flow to meet changing needs.
Centrally managed:
Network intelligence is (logically) centralized in software-based SDN
controllers that maintain a global view of the network, which appears to
applications and policy engines as a single, logical switch.
Programmatically configured:
SDN lets network managers configure, manage, secure, and optimize network
resources very quickly via dynamic, automated SDN programs, which they
can write themselves because the programs do not depend on
proprietary software.
Open standards-based and vendor-neutral:
When implemented through open standards, SDN simplifies network
design and operation because instructions are provided by SDN
controllers instead of multiple, vendor-specific devices and protocols.
SDN: Formal Definition (ONF)
© Tejas Networks Proprietary. All rights
reserved. 32
Software-Defined Networking (SDN) is an emerging architecture that is dynamic,
manageable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic
nature of today's applications. This architecture decouples the network control and forwarding
functions enabling the network control to become directly programmable and the underlying
infrastructure to be abstracted for applications and network services. The OpenFlow™
protocol is a foundational element for building SDN solutions. The SDN architecture is:
Open Flow Architecture
© Tejas Networks Proprietary. All rights
reserved. 33
OF v1.3.2 OF-CONFIG v1.1.1
Changing traffic patterns: Applications that commonly access
geographically distributed databases and servers through public and
private clouds require extremely flexible traffic management and
access to bandwidth on demand.
The “consumerization of IT”:
The Bring Your Own Device (BYOD) trend requires networks that are
both flexible and secure.
The rise of cloud services:
Users expect on-demand access to applications, infrastructure, and
other IT resources.
“Big data” means more bandwidth: Handling today’s mega datasets
requires massive parallel processing that is fueling a constant demand for
additional capacity and any-to-any connectivity.
What drives SDN?
© Tejas Networks Proprietary. All rights
reserved. 35
SDN addresses the fact that the static architecture of conventional networks is ill-
suited to the dynamic computing and storage needs of today’s data centers,
campuses, and carrier environments. The key computing trends driving the need
for a new network paradigm include:
SDN
Transport SDN: Layer 0/1
Carrier SDN: L2 and above
SDN(DC): OpenFlow
SDN Definition
© Tejas Networks Proprietary. All rights
reserved. 36
• OFPXMC_OPENFLOW_BASIC match fields ([OF-1.3.0], Section A.2.3.7): – Match on Switch Input Port (OFPXMT_OFB_IN_PORT)
– Match on MPLS Label (OFPXMT_OFB_MPLS_LABEL)
– Match on MPLS BoS bit (OFPXMT_OFP_MPLS_BOS)
– Match on Ethertype (OXM_OF_ETH_TYPE)
• OF Actions ([OF-1.3.0], Section A.2.5):
– Output to switch port (OFPAT_OUTPUT)
– Push a new MPLS tag (OFPAT_PUSH_MPLS)
– Pop the outer MPLS tag (OFPAT_POP_MPLS)
– Apply group (OFPAT_GROUP)
©Tejas Networks
Proprietary & Confidential 39
OpenFlow Implementation of MPLS-TP (Draft medved + OFv1.3)
©Tejas Networks Proprietary & Confidential
Tejas Transport SDN Implementation for MPLS-TP
41
App Layer
Tejas Network Hypervisor Controller (TejNHC)
E-API/NB-API
1400P 1400 PTN 1600 PTN
I-API
PW
Primary
T-LSP
Secondary
T-LSP
PW
Third Party SDN Controller
OFv1.3
Third Party SDN Controller
OF-CONFIG
• Built in SDN applications in Tejas
– Sub-sec restoration of circuits/tunnels
– Sub-sec congestion based prioritization of services
– Sub-sec based performance counters to help in billing of circuits made the OFv1.3 interface
– AAA of the third party and application request
– Backward compatibility to existing equipment's and layers to manage smooth migration
– Handles transport, carrier and RAN
• Standard API for third party SDN controllers/ management servers
©Tejas Networks
Proprietary & Confidential 42
TejNHC features
I-API Characteristics
• Exposure of this layer through Open APIs is not warranted.
• Increases the complexity at the application layer.
• Making it completely open has security implications.
• Keeping it closed, enable service providers to abstract the complexity associated with network upgradation from the OTTs.
E-API Characteristics
• Open interface
• Information on OTTs virtual network such as k-path level bandwidth, uptime, delay, jitter, packet loss, … .
• OTTs can use this information to select a unicast path, create multicast tree, change bandwidth (screen resolution), … .
TejNHC API Characteristics
43 © Tejas Networks Proprietary. All rights reserved.
Provisioning
• Select the type of multiplexing/FEC through I-API
• Mapping of LO-ODU to HO-ODU
• Cross connection or frame switching is node based
Bandwidth Adjustment
• Through ODUFlex
• Hitless addition and deletion can be triggered through I-API
Restoration
• Protection will be node based while restoration can be centralized beyond “N” failures
• Can use GMPLS control plane for Diamond and Gold services and Network Hypervisor for beyond
• Path computation can be centralized completely based on the scale of the network.
Performance monitoring
• Data collection is localized in appropriate bins
• Node uploads the info regularly through the I-API
TejNHC I-API for L1/L2.5
44
Provisioning
• Force a pre-determined path for the tunnel through the I-API
• Create an optimal multicast path along with protection
Bandwidth Adjustment
• Ability to tweak the PW/LSP tunnel CIR,CBS,PIR,PBS through I-API dynamically
Restoration
• Protection will be node based while restoration can be centralized beyond “N” failures
• Path computation can be centralized completely based on the scale of network
Performance monitoring
• Data collection is localized in appropriate bins
• Node uploads the info regularly through the I-API
Options for OTN Options for MPLS-TP
© Tejas Networks Proprietary. All rights reserved.
TejNHC I-API for LTE
45
Bandwidth Adjustment
•Ability to decide and overrule local scheduling decisions on RBs through the I-API regarding the RBs associated with a bearer
Inter-RAN Handoff
•Ability to force handoff of a customer with authentication information from LTE to WiFi
Performance monitoring and User Positioning
•Data collection is localized in appropriate bins
•Node uploads the info regularly through the I-API
•User location through BS triangulation based on position reference signal (PRS)
Multicast
•Allocation of RBs across MBSFN eNBs to improve cell edge performance
Radio Selection (for LTE-A CoMP)
•Appropriate radio selection in addition to the selection of the RBs
Distributed Radio
Centralized eNodeB
© Tejas Networks Proprietary. All rights reserved.
Path information
• Information on multiple paths along with max available bandwidth, hops, expected latency and uptime info of the path.
• In case of LTE, RBs CQI information can be provided for suggesting appropriate selection of Downlink RBs as required by the application layer
Path and User Statistics
•Real time information about delay, jitter, up/down status of the provisioned path can be provided for E-API
• Information regarding the associated UEs traffic priorities, buffer status and position can be provided
Multicast Traffic
• Information of multicast path spanning both backhaul and RAN can be provided to convert unicast traffic to multicast traffic whenever new sessions get added to the same application.
TejNHC E-API/NB-API
46
OTT#1 Virtual Network
© Tejas Networks Proprietary. All rights reserved.