New Control Architectures for E2E networks

Juan Pedro Fernandez-Palacios, Telefonica I+D (jpfpg@tid.es)

April 2013

Core network operation is not adapted to flexible networking Multiple manual configuration actions are needed in core network nodes Network solutions from different vendors typically use particularized Network

Management System (NMS) implementations Very long service provisioning times

Internet Voice CDN Cloud BusinessService ManagementSystems

Network ProvisioningSystems

Metro NMS

NMS Vendor A

IP Core NMS

Optical Transport NMS

Umbrella Provisioning System

Complex and long workflows for network provisioning over different segments (metro, IP core, Optical transport) requiring multiple configurations over different NMS

NMS Vendor B

NMS Vendor C

NMS Vendor D

NMS Vendor E

NMS Vendor C

NMS Vendor A

NMS Vendor B

Metro Node

Vendor A

Metro Node

Vendor B

IP Node

Vendor C

IPNode

Vendor D

IPNode

Vendor E

Optical Node

Vendor A

Optical Node

Vendor B

OpticalNode

Vendor CCore Network Nodes

CURRENT APPROACH FOR NETWORK PROVISIONING

Traditional core network operation is very complex and expensive

Control plane and SDN pave the path towards a unified network provisioning architecture

Key building block of such unified network provisioning architecture are: Network configuration interface: Multivendor edge nodes configuration (e.g

OLT and BRAS, IP core routers, etc) by standard interfaces (e.g OpenFlow) IT and network SDN orchestration: Coordinated network and datacenter

resources control according to service requirements (e.g orchestrated Virtual Machine transfer among datacenters)

Network-Service API: Application level API hiding details of the network

Internet Voice CDN Cloud Business

Multiservice network provisioning system(SDN Orchestrator)

Standard signaling mechanisms running over network nodes enabling flexible networking and automated network

provisioning over different network segments (metro, core IP, optical transport) including multiple vendors

Metro Node

Vendor A

Metro Node

Vendor B

IP Node

Vendor C

IPNode

Vendor D

IPNode

Vendor E

Optical Node

Vendor A

Optical Node

Vendor B

OpticalNode

Vendor C

Service ManagementSystemsNetwork Provisioning

Core Network Nodes

Network-Service API

Network configuration

interface

Unified network provisioning architecture

Infrastructure Layer (e.g DataCenter)

SDNController

ALTO SDN orchestrator

Application Layer

OAM Handler

TED VNTM PCE

Provisioning Manager

OPENFLOW

SDN CONTROLLER

API

OpenFlow is based on the concept of actions that are applied to each packet of a given flow (Ethernet-level addresses, VLAN tags, IP

addresses, MPLS labels or transport-level ports).

The actions taken by SDN the controller comprise: inserting and removing tags (layer 2), performing routing (layer 3) and also providing

differentiated treatment to packets (QoS)

Basic SDN Approach for OpenFlow Domains

82nd IETF, Taipei

1) Discovery of network resources2) Routing, path computation3) Automated network orchestration in response to changing network

conditions and service requirements 4) Network resources abstraction to application layer5) QoS control and performance monitoring 6) Multilayer interworking7) Multidomain/multivendor network resources provisioning through

different control domains (e.g OpenFlow DataCenter, OpenFlow MAN, GMPLS optical transport…)

E2E networks might be pure OpenFlow based one day, but the migration process will take

some time

Main actions to be taken by the SDN controller in E2E networks

OpenFLowData

Center

SDNController4-ALTO3-SDN orchestrator

Applications (Internet, CDN, cloud…)

5-OAM Handler

1- TED 6-VNTM 2-PCE

7-Provisioning Manager

OpenFlowMAN

Domain

IP/MPLScore

OpenFlowOptical Domain

OPENFLOW OPENFLO

W

GMPLSOptical Domains

NETCONF

MPLSMAN

PCEP OPENFLOW CLI

Most of these building blocks are still on

definition and standardization

process

SDN controller based on standard building blocks

Physical Network

NETWORK OPERATING SYSTEM

CSO Multilayer Orchestrator

Link Provisioni

ng

CDN and nionetwork optimizat

APIAPI API

Provisioning Manager

Cloud Services Live OTT Internet…

Orchestration mechanisms (*)

Network APIs

…

NetConf OpenFlow

PCEP UNI

Inside SDN Orchestrator

Access Network Metro Area Network Core Network

Optical Transport

Multidomain L2 service provisioning

Data Center Network

CPEVirtual

Machine (e.g BRAS)

Technical challenges: Horizontal Orchestration. Automated L2 service provisioning

through different packet switching domains (metro, core, datacenter).

Vertical Orchestration. This orchestration enables adaptive network resources allocation in IP and optical layers according to the traffic pattern to efficiently use network resources

Multilayer orchestration

SDN controller

E2E SDN

control

Access Network Metro Area Network Core Network Data Center Network

CPEVirtual

Machine (e.g BRAS)

SDN controller

OpenFlowCLI CLI

Multidomain pseudowire over seamless MPLS

Intra datacenter connection

Multidomain L2 service provisioning (short term)

Access Network Metro Area Network Core Network Data Center Network

CPEVirtual

Machine (e.g BRAS)

SDN controller

OpenFlowOpenFlow OpenFlow

Multidomain pseudowire over seamless MPLS

Intra datacenter connection

Multidomain L2 service provisioning (Medium term)

For this scenario, OF is used to trigger control plane. This means that edge nodes have to decode OF and translate into CP messages.

For the case of creating a Pseudo-Wire following parameters are required:• Pseudowire Label

• MPLS Label

• Service VLAN (VLANs)

• Output port

11

CP node

OF and CP node enable node

OF Request

1

3OF Information Updated

2

4

Multidomain L2 service provisioning (Medium term)

Access Network Metro Area Network Core Network Data Center Network

CPEVirtual

Machine (e.g BRAS)

SDN controller

Intra datacenter connection

OpenFlow

Common Interface

OpenFlow

SDN controllerSDN controllerSDN controller

Options: Hierarchical Approach. There is a controller which has a

global view so it can orchestrate the configuration in each domain.

Peer Relationship. Each controller can request for information or connections to other peers.

Connection to datacenter

Multidomain L2 service provisioning (Long term)

Access R1

Access Region 2

Transit R1

Transit R2

TransitBackup R3

Interconnection

Transit R3

Access R3

• Increased survivability• Extended reparation processes• Capex Savings (best effort

traffic only)

Load balancing between IP and optical networksMulti-layer restoration

Vertical Orchestration

OpenFLowOPS Data

Center

SDNController4-ALTO3-SDN orchestrator

Applications (Internet, CDN, cloud…)

5-OAM Handler

1- TED 6-VNTM 2-PCE

7-Provisioning Manager

OpenFlowMetro-Core

Node (L3/L2/L1)

IP/MPLScore

OpenFlowWSON

network

OPENFLOW, GMPLS

OPENFLOW

GMPLSFlexiGrid

NETCONFPCEP, GMPLS OPENFLOW OFELIAIDEALISTIDEALISTDISCUSSTRAUSS

IDEALIST: IP and Flexgrid configuration

IDEALISTIDEALISTIDEALIST

IDEALIST: Multilayer IP over FlexiGrid Orchestration

STRAUSS: VM transfer orchestration

EU projects situation in this picture

15

EU –Japan collaboration within STRAUSS project

E2E SDN control (KDDI, NTT, NEC…)Network Operating System Multilayer and multidomain orchestration mechanismsNetwork Functions Virtualisation

Optical data plane (NTT, Fujitsu, Osaka University, NEC…)Subwavelength, Flexgrid, Optical OFDMSliceable and Programmable Transponders

“sliceable” BVT. Figure from NTT.

Joint EU-Japan standardization contributions (IETF, ONF, NFV, ITU…)

List of potential topics for future collaboration EU-Japan