Challenges and Opportunities:

(1)

Challenges and Opportunities:

The Rise of Software Centric Networking

Nicolai Leymann

Deutsche Telekom Technik

12.03.2015

(2)

24.03.2015 2

1. Todays networks and challenges

2. The New World: Software Centric Networking

3. Integrated Data Center and Network Architecture

4. Service Chaining

5. Summary

(3)

The Old and the New World

Software Centric Networking

(4)

Software Centric Networking.

Typical Service Provider Network.

24.03.2015 4 – public – Backbone Network (IP/MPLS) Aggregation/Access Service Node LER Service Node Aggregation/Access Customer Customer Customer

Customer Data Center



_{Aggregation/Access Network: Aggregates}

business and residential Customers

(VDSL, GPON, …)



_{Service Node: Terminates customer session}

and provides basic services (e.g. QoS,

Multicast Replication, Bandwidth Control,

VPN, P2P, P2MP, …)



_{Backbone Network: Provides connectivity}

among customers, towards service areas

and the internet



_{Data Centers: Providing additional services}

(e.g. IPTV services, web, customer self

service, …)

(5)

Software Centric Networking.

Todays (Networking) Challenges.

24.03.2015 5 – public –



_{Typical network designs are using an access/aggregation network and a backbone network which also}

interconnects to service areas/data centers.



_{typically, operation and provisioning of dc and network are separated.}



_{In many cases introducing a new services leads to software updates on networking nodes (service and network}

are closely coupled).



_{Monolithic Software/Hardware}



_{Innovation to slow (no ability to “program” or closely interact with the network).}



_{Modification of forwarding mainly through routing protocols (no external interfaces in order to interact}

directly with forwarding hardware).

(6)

Software Centric Networking.

Vision.

24.03.2015 6 Backbone Network (IP/MPLS) Aggregation/Access Service Node LER Service Node Aggregation/Access Customer Customer Customer

Customer Data Center

24.03.2015 6



_{Integrated architecture which takes network}

and data center into account.



_{Service can span from network into data}

center



_{Flexible placement of service functions}

(driven by requirements).



_{Network is programmable (a new service}

does not lead to a new software release on

networking nodes)



_{Complexity moved into the data centers}

(applications).



_{High level of automation.}

Typical Network Design

(7)

7

Software Centric Networking.

Moving towards a Programmable Network.

24.03.2015 – public– D ec oupling of Liv e C y c les



_{Application used to build service chains}

sitting on top of an Controller



_{Controller offers a common API (or}

several APIs) northbound



_{Controller uses southbound interface}

towards abstraction layer (e.g.

openflow)



_{Abstraction layer integrates different}

NEs and protocols



_{Flexible chaining mechanism used to}

build network path between service

nodes

Key Components

Control Layer Netz-element Netz-element Netz-element Netz-element

Netz-element element Netz-Netz- element Infrastructure Layer AP I API Application Application Application Application Application Application Application Networkservices „Network Operation

System“ Network Services

N ort hbound Southbound

(8)

24.03.2015 8

Software Centric Networking.

Key Building Blocks of Upcoming Network Architectures.

(Network Function) Virtualization in allows to run all applications (like web services, IPTV services, of network functions) on a standard x86 based server infrastructure using an additional abstraction layer. Virtualization

allows elastic services, mobility and highly scalable services.

Based on Wikipedia (01.08.2013)

Software Defined Networking allows network administrators to have programmable central control of network traffic without requiring physical access to the hardware devices. It decouples the control plane from the underlying

forwarding (data) plane. It allows fine (external) control over the network.

High Level of Automation allows a fast and flexible service provisioning. Decoupled life cycles allow the introduction of new services without installing/deploying new software images on networking components.

(9)

Moving towards an SDN based and virtualized

Network Architecture

(10)

24.03.2015 10

Software Centric Networking.

Eight Principles for Service Providers.

1. One integrated strategy for Software Defined Networking,

Network Function Virtualization and Data Center deployments.

2. Virtualization of network functions on data center hardware should

be the standard model when introducing new technologies.

3. Implement open interfaces to ensure programmability of the

network fabric but don’t limit to a specific protocol or standard.

4. SDN enables different level of control of the network .

Most attractive use cases for IP flow-level control (e.g. OpenFlow)

are at the network edge and the DC, e.g. service chaining.

5. Combine the mechanisms of SDN and NFV in order to simplify IT processes.

6. Accelerate the efforts to implement network aware orchestration

of services and resources for optimal placement.

7. Use standardized and common data center technologies and processes to implement

network functions.

8. Take into account that SDN/NFV is still a moving target. Many players on the market, almost anything runs

(for marketing purposes) under the “SDN/NFV” umbrella.

Strategy

Network

Functio

n

Virtualizatio

n

Data

Center

So

ftware

Defined

Networking

– public –

(11)

24.03.2015 11

Software Centric Networking.

Key Aspects from Definitions.

 _{Decoupling of Control Plane and Data Plane}

 _{Application are steering the traffic within the network and interacting with the forwarding nodes.}  _{Flexible Control of all network functionality (not focussed on forwarding).}

 _{Moving forward towards a „NOS“ – Network Operating System.}

 _{Network Functions (like firewalling) are running on a virtualized infrastructure in a DC.}  _{Use of standard x86 based hardware (same data center for all services).}

 _{Complex functionality for subset of services/customers not on every network node.}  _{Respond on changing requests via horizontal scaling}

 _{Use of standard x86 based server and abstraction of physical infrastructure}  _{Use of a common resource pool}

 _{Decoupling of hardware and application life cycles}

 _{Simplification and automation of provisioning processes for Cloud services}  _{Opex & Capex savings through lower energy & maintenance costs}

Software Defined

Networking

Virtualization

(Data

Center)

Network Function

Virtualization

– public –

(12)

24.03.2015 12

Software Centric Networking.

Challenges, Requirements and expectations.

12

Common solution for future services based on

low cost network elements and standardized

server infrastructure.

Network Control based on standardized interfaces. Use of COTS

hardware.

Overarching topology aware production instead

of node by node. Decoupling resource lifecycle management from hardware - move to

software.

Virtualization as integral part of solution. Deployment of Service and Network Function

Virtualization.

Reduce Costs per Bit

Enabling of New Services and Faster Deployments

(13)

24.03.2015 13

Software Centric Networking.

Remove Limits of Static Production.

 Vendor dependencies restricts development.

 Scalability limits are restricting growth.  Complexity limits

development and and hinders flexibility.

SDN Paradigms

 Universal API:

Standardized API as common base for development of network services and applications.

 Central Control Plane:

Universal access for controlling activities within the network

Limits of existing production

 Abstraction:

Separation of Forwarding and Control Plane Remove dependencies between hardware and implementation.

 Programmability:

Network and services can be programmed

(14)

Merchant

Switching Chips

Applications

Current

Networking

Industry

SDN Industry

Specialized Features

Specialized OS &

Control Plane

Specialized

Hardware

Network OS &

Control Planes

24.03.2015 14

Software Centric Networking.

Principle Architecture Software Defined Networking.

Computer View

Micro-processor

Applications

Old

IT Industry

Current

IT Industry

Applications

OS

Hardware

OS

Mac/Win/Lin

NetworkView

– public –

(15)

24.03.2015 15

Software Centric Networking.

Applying SDN and Virtualization: Network Function Virtualization

 _{Functionality which is typically provided by a dedicated network node (e.g. router,}

switch, appliance like a firewall) is virtualized and moved to a data center

 _{Data center uses standard hardware (x86 based) and a hypervisor to provide}

virtualization

 _{Examples: firewalling, DHCP server, PPPoE session termination, routing}

functionality, …

 _{Functions can be added/modified/removed based on requirements without touching}

typical network nodes (like routers/switches/…)

Figure (Source: ETSI) Key aspects of NFV Definition

 _{Standard virtualization platform for network functionality}

 _{Higher flexibility, better scalability (depends on what is virtualized)}

 _{Standard interfaces instead of vendor specific interfaces (single interface towards data}

center independent of the services which are provided)

 _{Better utilization of existing resources}

 _{Shorter update cycles (easier to update an VM).}

 _{Decoupling from hardware life cycles (e.g. if hardware is end of life).}

Benefits / Advantages

 _{Forwarding performance might be critical depending on}

service

 _{Non optimal traffic flows (e.g. in cases where}

functionality which should be close to the end customer is virtualized)

 _{Not all functions should/could be virtualized}  _{Common Orchestration function}

Challenges

(16)

Architecture Blueprint

Towards an SDN based and virtualized Network

Architecture

(17)

24.03.2015 17

 _{Standard x86 based hardware}

with flexible and elastic resource provisioning (computing performance, throughput, …)

Data Center

 _{Separated control /data}

planes with standardized south and northbound interfaces to control the nodes. Decoupling of life cycles. SDN

NFV

„Sweet

Spot“

1

Software Centric Networking.

Architecture Blueprint: Bringing Building Blocks together.

End-to-End Use Case (orchestration of NFV services in a Data Center). NFV can be seen as a use case of combining

virtualization in DC and Software Defined Networking. 2 3  _{Virtualization of network} functionaliy (e.g. PPP termination, Firewalling, Parental Control) NFV 1 2 3

Data

Center

SDN

– public –

(18)

24.03.2015 18

Software Centric Networking.

Architecture Blueprint: Towards a Common Architecture.

Common vision from IT and NT.

Open minded discussion and flexibility are key factors for success. Architecture and strategy should be seen as enablers for

future networks and services.

Support through organizational structure. Not religious on protocols and solutions. New products based on architecture blueprint.

Clear path towards Virtualization.

Factors for Success

(19)

24.03.2015 19

Software Centric Networking.

Architecture Blueprint (1 of 2)

Network _{Virtualized Data Center}

Hypervisor (KVM) VM VM VMVMAPP OS VMAPP OS VMAPP OS

Compute Storage Network OpenStack Services

API

Glance

Nova Swift Neutron

Infrastruktur Install & ConfigSys Hypervisor (KVM) VM VM VM VMVMVM VMVMVMVMAPP OS VMAPP OS VMAPP OS VM APP OS VM VMAPPAPP OS OS VMAPP OS VM VMAPPAPP OS OS VMAPP OS VM VMAPPAPP OS OS Compute

Compute StorageStorage NetworkNetwork OpenStack Services API API Glance Glance Nova

Nova SwiftSwift NeutronNeutron

Infrastruktur Install & ConfigSys Infrastruktur Install & ConfigSys Orchestration

APP APP APP APP

Abstraction Layer

Controller

Adapter Adapter Adapter

Orchestration

End-to-End Orchestration

Controller

(20)

Software Centric Networking.

Architecture Blueprint (2 of 2)

3/24/2015 20

 _{All services are virtualized}

 _{Standardized elastic and scalable data center(s) for all services}

 _{Single (small number) of standized interfaces – north and southbound}

The Bright Future

 _{Abstraction layer needs to take}

non virtualized hardware into account

 _{Integration of legacy software and hardware (for transition period)}

necessary

Abstraction

 _{Not everything can be virtualized}

 _{Legacy hardware not going to disappear in short term}

 _{Service specific Data Centers in deployment and need to be migrated}  _{large „zoo“ of different control planes and interfaces}

Reality

 _{End-to-End Orchestration of services and network (including}

connectivity)

 _{View on network and services (and network services in DC) crossing}

(todays) organizational borders

Orchestration Architecture Blueprint

(21)

(22)

24.03.2015 22

Software Centric Networking.

Service Function Chaining (SFC)

 _{Traffic from or towards customers flowing through a chain of service provisioning}

nodes

 _{Basic Components:}

 _{Classification of traffic packets}

 _{Routing entity which routes the packets towards service chain and/or within}

service chain

 _{Service nodes which applying service related functions}  _{Management / Orchestration component}

 _{Components within the chain can be easily modified (and added/removed if}

necessary)

Graphics Use Case Description

 _{Higher flexibility compared to existing, static chaining}

 _{Services can be provisioned and changed based on customers demands and Supports}

“elastic deployments” in virtualized DC

 _{Migration from existing service chains need more flexible mechanisms}  _{Reuse of existing service components from the service chain}

 _{If implemented as an overlay, independent of underlying network technology}

Benefits / Advantages

 _{More dynamic traffic flows, potentially less control}  _{Integration of service nodes from different sources (e.g.}

vendors) because of different provisioning models

Challenges

(23)

Software Centric Networking.

Service Chaining

24.03.2015 23

 _{A service function chain is a different path from normal forwarding or routing, where traffic is steered according to service characters}  _{Traffic must be steered through service functions in a specific sequence}

 _{Service function chain1: default path}  _{Service function chain2: http video traffic}  _{Service function chain3: https}

(24)

24.03.2015 24



_{Service Chaining deployed, typically in static or}

semi static environments (“hard wired”)



_{Typically one Service Chain per Service, no}

reuse of existing components



_{Mainly focused (but not only) on mobile}

networks (e.g. “Gi-Lan”)



_{Higher flexibility for fast and simple service}

delivery



_{More elasticity to fulfill temporary needs}



_{General architecture which can be deployed in}

fixed and mobile networks

Software Centric Networking.

Motivation for Dynamic Service Chaining.

Today

Tomorrow

Need for a highly flexible service chaining architecture addressing fixed and mobile networks.

(25)

25

Software Centric Networking.

Service Chaining Requirements



_{Flexible and dynamic creation, modification and deletion of}

Service Chains and/or components of the Service Chain



_{Flexible (re-)use of Service Functions}



_{Agnostic to underlying network technology}



_{Support of virtualized and non-virtualized service functions}



_{Support for elasticity and scalability}

Requirements for

Flexible and Elastric

Service Chains

24.03.2015 – public–

Service Chaining

Architecture,

supporting

requirements and

use cases

(26)

P-GW

Software Centric Networking.

Use Cases Service Chaining: GI-LAN

24.03.2015

– public – 26

Load Balancer Web

Proxy Firewall NAT

APN

Video

Optimizer Firewall

APN

Web Service

OTT Video Service

User User

 _{With deployment of additional value-added services increasing number of functions required in Gi-LAN. Some functions in dedicated}

devices, sometimes multiple functions in one box.

 _{Due to fast service introduction cycles service chains emerge, growth & change evolutionary.}  _{Very often static IP links, policy routing, VRFs etc. used to enforce required service sequence.}

 _{Results in steadily increasing, handcrafted complexity and decreased visibility of functional dependencies between service chains and}

underlying LAN topology. Means expensive OAM.

(27)

Software Centric Networking.

Use Cases: Traffic Steering and Service Chaining.

24.03.2015 – public – 27 Peering IP Backbone LER LER Data Center LER Service Edge Customer Redirect



_{Need to dynamically classify and steer}

traffic based on customer demands

towards Data Center



_{Data Center implements service chaining}

(providing customer services)



_{Traffic classification and steering part of}

Service Chaining architecture



_{End-to-End Orchestration needs to take}

distributed classification and redirection

into account

Remarks

Dynamic Traffic Steering and Service Chaining

Firewall DPI Antivirus

(28)

Service Path Forking

Software Centric Networking.

Use Cases: Service Chaining Variants

24.03.2015 28

 _{A single flow being forked within one}

component of the Service Chain

Service Function Sharing

 _{Parts of the Service Chain are being}

reused for other Service Chains

Multiple Underlay Networks

 _{Service Chaining not to be bound to a}

single network/transport protocol

Firewall DPI Antivirus Par. Cnt. Firewall DPI Video Par. Cnt. Firewall DPI Antivirus _{IP Network} Ethernet – public–

(29)

24.03.2015 29 – public–

 _{“Pure SDN” – realizing the original idea of SDN in terms of simplicity}  _{The network is controlled entirely by the SDN controller, including all}

forwarding elements (virtual and physical)

 _{The forwarding elements are simply forwarding; no support for}

tunneling mechanisms e.g. VXLAN, NVGRE or MPLS over GRE/IP is required

 _{An overlay implementing the SDN principles is created on top of the}

(typically existing) underlay network

 _{The overlay is created by a mesh of virtual tunnels, based e.g. on}

VXLAN, NVGRE or MPLS over GRE/IP

 _{Not all forwarding elements are controlled by the controller (e.g.}

virtual elements only or a combination between virtual and physical)

Infrastructure Model

Overlay/Underlay Model

Software Centric Networking.

(30)

30

Software Centric Networking .

Architecture Options: Service Header

Service Header



_{Service header indicated using protocol type or GAL (in case of MLPS as encapsulation)}



_{Service header is inserted/removed at start or end of service chain/path or by service function within the chain}



_{Service header can be changed by node within the service chain (e.g. in case of reclassification)}



_{Service chain is independent of topology}

24.03.2015 – public–

Service Header Outer (Tunnel) Header

 _{Used to build an overlay network in order to address components of the}

service

 _{Independent of underlying transport network}

 _{Service header is meta data added to a packet or frame that is used to create a}

service plane

(31)

3/24/2015 31

Software Centric Networking.

Summary.

 _{Higher flexibility for network and service deployments (faster „time to market“)}  _{Possibility to provide services end-to-end and ..}

 _{Interact with the underlying network through a single orchestration}  _{Industry still in „gold rush mode“}

 _{Many players, many interpretations of SDN}

 _{Impact not only on technology level but also on organizational structures}

 _{Technologies like SDN and NFV are enablers for new services and more flexibility}  _{Network evolution towards a software based/centric approach}

Challenges and Opportunities: