sdn and openflow - national knowledge networkworkshop.nkn.in/2013/images/presentation/sdn and... ·...

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


OTTs Network View

5

OTT#1 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


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


OTTs

Way forward: Cooperation, not confrontation


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



• 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.


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


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


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


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)


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


• 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.


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


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.



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)


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


reserved. 22

OF v1.3.2 OF-CONFIG v1.1.1

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.2.pdf

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1-1-1.pdf



©Tejas Networks

Proprietary & Confidential 23

Openflow Switch Architecture

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


• I would like to thank Jishnu Aravindakshan for the production of this presentation.

Acknowledgement


reserved. 25

SDN & OpenFlow Overview

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.


SDN


reserved. 31

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)


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


reserved. 33

OF v1.3.2 OF-CONFIG v1.1.1

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.2.pdf




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?


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


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


OpenFlow Implementation of MPLS-TP (Draft medved + OFv1.3)

Tejas Infrastructure SDN Implementation

©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


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


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


• 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


TejNHC I-API for LTE

45


•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


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



sdn and openflow - national knowledge networkworkshop.nkn.in/2013/images/presentation/sdn and... ·...

Documents