SDN controller: Intent-based Northbound Interface realization for extended applications

1. Introduction2. SDN Controller3. Intent-based Northbound Interface (NBI)4. The Intent framework in ONOS controller5. The proposed architecture for extended applications:

requirement, Micro-service architecture, three-tier application architecture, domain-driven design

6. Prototype7. Conclusion & Discussion

Minh Pham, Doan HoangUniversity of Technology Sydney, Australia

Introduction

• The adoption of SDN introduces an emerging class of extendednetwork applications

• Open Networking Foundation (ONF) principles of intent-basedNBI lack functionality to support the above extended applications

• We adopt the Intent-based NBI principles and propose anarchitecture to realise extended network applications

• The proposed architecture is built on Micro-service architecture,Domain driven design and three-tier application architecture

• The prototype is to build the Dynamic Resource Application(DRM) using Open Network Operating System (ONOS) controller

NORTHBOUND API

SOUTHBOUND API

DistributionPacket Processing

Device Manager

Topology Manager

Routing Processing

StatsManager

Interface Management

Device DeviceDevice

Application

OS components

SDN Controllers

Application Application

Intent-based NBI

(Janz 2015)

• ONF identified two types of NBI usages: prescribed and intent-based• In intent-based NBI, users describe their request in normal conversation

language, it is the WHAT question, not HOW question• Each request has two main components: substance and constraint,

substance contains the objects and constraint contains the conditions

Open Network Operating System (ONOS) Intent framework

• ONOS provides application intent framework as the NBI to describenetwork connectivity as network policy. It is a sub-system of ONOS.

• Intents in the framework are organised into a hierarchy; developerswill select the intents that are closest to their network models.

• Each intent has its compiler to compile the intent into flow rules;flow rules are installed as table entries in network devices based onthe Openflow protocol.

Intent life cycle(ONOS, 2014)

ONOS Intent life cycle

CREATE INTENT

Compiling intents

Saving flow rules

successful

Installable intents

Install on devices

Failed intents

Errors

SOUTHBOUND INTERFACE

DEVICE

Recompiling intents

NETWORK EVENTS

DEVICE DEVICE

Searching for intent

WITHDRAW INTENT

found?

removing from stores

Uninstall on devicesINTENT FRAMEWORK

NORTHBOUND INTERFACE

YYN N

ONOS Intent framework

SERVICE COMPOSITION

Language Interpreter

Adapt to context changes

Service, Application

Reuse

Service Discovery

Ease of use, User friendly

Handle complex

business rules

Adapt to Controller Structure

Availability, Scalability,

Modifiability

Use & Extend Core Services

Create new services

• Service composition is the main attribute to support intent’s composabilityattribute

• Requiring creating of new services, reuse of existing services and composingthem into applications

• Other requirements: user friendly, availability, scalability, modifiability

The proposed architecture - Requirements

Fine-grained Service Composition

A B

C C

Decentralised data management (Fowler, 2013)

MSA design principles:• Data decentralized• Componentized application• Application design robustness• Process isolationPatterns: Self registration, Service registry, Client service lookup (Richardson, 2014)MSA is used to promote the service composition for the intent realisation

Microservice architecture (MSA)

Experts + Development Team

SD1 SD2

SD3Problem domain

Domain Knowledge

Bounded Context 1 Bounded

Context 2

Bounded Context 3

Bounded Context 5

Bounded Context 4

Solution domain

Sub problem domain

• Promoting modular design and divide-and-conquer solution approach• Working well with the Micro-service architecture

Domain driven design

Rest API

CLINew

service creation

Service Integration

element

Service registry

Core network services

Other existing services

New composite

service

DB TIERBUSINESS TIERUI TIER

API

• Three-tier application architecture satisfies the requirements and serves wellin the development of commercial applications

• Database tier persists states• Business tier handles business logic via creation of new services, reuse

existing services and service composition• Presentation tier to interact with users: CLI, REST API, API

Three-tier application architecture

Intent-based NBI

SDN Control Logic

Intent manager

Intent execution environment

Intent store

Intent interpreter

executes

Prescribed NBI

Topology API

L3 VPN API

vRouter API

Virtualizer

(Tadepalli, 2014)

• Service composition and intent realization in the proposed architecture areparts of the intent execution environment of the virtualizer of NBI

Dynamic Resource Management (DRM) Application

(Mijumbi, 2014)

• DRM proposed a solution for network virtualisation in an efficientresource management

• In virtual network creation, the least cost path is selected based on theleast ratio of usage resource over available resource for switches andlinks

Java Virtual MachineOSGi framework (felix, equinox)

Programming model (spring/blueprint/DS)

Shell /SSH Logging Deployers Provisioning

Configurationadmin SecurityInstances JMX

Web container (pax web)

Enterprise features (JPA, JNDI, JTA) Web console

(Apache Karaf 2015)

Apache Karaf container architecture

Intent Interpreter

ResourceRequest

Location 1,Location 2,Location n

Bandwidth

Choreography platform

Path Intent

DRM Least-cost calculation functions

INTENT STORE

SERVICE REGISTRY

Replication Process

Device Manager

Event Management

APPLICATION LAYER

NORTHBOUND API

CORE SERVICE LAYER

SOUTHBOUND API

Flow rules

DRM Services

INTENT EXECUTION ENVIRONMENT

DRM application

The visualisation of the NBI Intent-based realisation

Intent realization

Topology service

Other core services

Prototype results

Conclusion & Discussion

• The intent-based NBI is needed to develop extended, business-likenetwork application

• Service composition, the creation of new services and reuse existingservices are the main requirements

• The proposed architecture is based on micro-service principles,three-tier application architecture and domain driven design

• The architecture avoids the ad-hoc and self-explored way andpromotes a systematic approach so developers can concentrate onthe business requirement

QUESTIONS

THANK YOU