Download - Thank you for joining us today! The presentation will ... · The presentation will begin shortly. ... • Transport SDN Use Cases & Functional Requirements ... Follow “Agile”

Sponsored by

Thank you for joining us today! The presentation will begin shortly.

Thank you for your patience.

© 2015 SDNCentral. All Rights Reserved. December 2, 2015

Sponsored by © 2015 SDNCentral. All Rights Reserved.

SDN’s Hottest Topics: A Panel Discussion

Solving Interoperability& Operations Issues – The Guide to SDN for Optical Networks

December 2, 2015


Your Presenters for Today

Roy Chua

Co-Founder SDxCentral

December 2, 2015

Lyndon Ong

Chair, ONF Open Transport WG

ONF

Vishnu Shukla

Vice Chair, Open Transport WG

Verizon

Dave Brown

VP of Marketing, Board Member

OIF

Sponsored by

Agenda

•  Why do transport networks need SDN? •  What are the challenges of making transport SDN work in the

real world? •  How are we (industry, ONF, OIF) addressing these challenges? •  How to get started and get involved with transport SDN •  Wrap-‐up and Q&A

© 2015 SDNCentral. All Rights Reserved.

Hot Topics in SDN Panel Discussion


Welcome to SDxCentral Webinar with Open Networking Foundation (ONF) Relevant Industries Who Should A4end? Key Takeaways

•  CommunicaRon service providers

•  Internet content providers •  Research and educaRon

networks

•  Engineers

•  Infrastructure architects

•  ApplicaRon developers

•  Deploy SDN in the service transport network

•  Carrier view: Make SDN more widely deployable in the SP network

•  OIF’s toolbox for service provider SDN deployment

December 2, 2015

Carrier SDN Transformation

→  Proprietary, vendor-specific silos→  Complex to operate, integrate across

vendors/technologies

→  Centralized, vendor-agnostic control and service orchestration

→  Virtualization of physical network resources→  Open, programmable carrier networks

OSS Platform

Proprietary OSVendor X HW

Proprietary OSVendor Y HW

Proprietary OSVendor Z HW

Current Networks Software-Defined Networks

OSS Platform/SDN Apps

Multi-vendor Network with Integrated SDN Control

SDN SW

SDN-enabled HW

Open APIsVendor EMS

SDN Control Infrastructure

ONF Open Transport WG ��(formerly Optical Transport WG)•  Objectives

•  Develop SDN and OpenFlow® standard-based control capabilities for carrier transport networks.•  Recent change: addition of Wireless Transport project

•  Leadership•  WG Chair: Lyndon Ong, Ciena•  Vice Chairs: Vishnu Shukla, Verizon; Maarten Vissers, Huawei; Karthik Sethuraman, NEC

•  Work to date•  Transport SDN Use Cases & Functional Requirements•  OpenFlow Extensions for Optical Transport•  2014 Joint Demo with OIF

•  In Progress: T-API, Information Model & OpenFlow v1.1

Wireless Transport Work��POC Madrid October 2015

•  Supported by •  Telefonica•  5 largest microwave vendors (90%

of the market)•  Based on ONOS controller

with basic microwave port extensions

•  Presenting two SDN apps:•  Capacity driven air interface•  Flow based shaping

•  Whitepaper available at ONF

8

CoriantCoriant

Tester

ONOS Controller

Capacity driven air interface

APP

Flow Based Shaping APP

VirtualRouter

VirtualRouter

9

•  Introduce OPTICAL_TRANSPORT port type – specifies port description properties – key information that characterizes the port•  Port (Base Layer) Signal Type•  Port Capabilities

•  Supported Signal Types•  Supported Adaptations (Layer stack) above the base port layer

•  Port Constraints•  Signal Compatibility – Optical Interface Class (Application code/ID)

•  Add Adjacency Discovery•  specify/retrieve an identity string being sent•  specify an identity string(s) to be expected, •  retrieve peer identity string(s) received

OpenFlow Optical Extensions: ��Port Attributes for support of L0/L1 connections

OpenFlow Optical Extensions��Match/Action extensions for L0 and L1 connections

10

ODU-XC Port #1

Port #2

Port #3

Port #4

Port #5

Port #6

Match Action In_port = #1ODU_Sigtype=ODU1ODU_SigID={TPN=1, tslen=2,tsmap=[1,0]}

Out_port = #4Set Field ODU_SigID={TPN=3, tslen=2,tsmap=[0,1]}

In_port = #1ODU_Sigtype= ODU1ODU_SigID={TPN=2,tslen=2, tsmap=[0,1]}

Out_port = #5Set Field ODU_SigID={TPN=4,tslen=2,tsmap=[1,0]}

Example: Match/Action for ODU-XC

OIF/ONF Global Transport SDN Demo ��Implementation Experience•  OIF/ONF Joint Prototype Demo in

Fall 2014•  Multi-vendor, Multi-domain Demo•  5 carrier labs worldwide

•  OpenFlow Optical Transport Extensions•  Vendor X NE vs. Vendor Y

Controller•  Prototype NBI for Connectivity

Service and Topology•  (more on this later)

Application Layer

Control Layer

Infrastructure LayerDomain 1

NE NE NE

Domain 2

NE NE NE

Domain 3

NE NE NE

Network Orchestrator

Parent Controller

DomainController

DomainController

DomainController

SBI

NBI

SBI

CloudOrchestrator

Compute Storage

SDN Framework for Transport ��Multi-Domain Integration ��Transport SDN framework for carrier networks

•  Can be realized over diverse carrier networks

•  Highly flexible - multiple technology layers, multiple domains, greenfield and brownfield

Need standards on application layer interface to control layer (NBI)

•  Programmability of Transport SDN across controller and NE vendors

ONF Transport API Project•  Project chartered under OTWG

•  Project lead: Karthik Sethuraman•  Objective – realize a software-centric approach to standardization

•  Purpose-specific API to facilitate SDN control of Transport networks•  Focus is on functional aspects of transport network control/mgmt•  Target is YANG & JSON API libraries

•  Scope – based on use case discussions•  Topology Service

•  Retrieve Topology, Node, Link & Edge-Point details•  Connectivity Service

•  Retrieve & Request P2P, P2MP, MP2MP connectivity for (L0/L1/L2) layers•  Path Computation Service

•  Request for Computation & Optimization of paths•  Virtual Network Service

•  Create, Update, Delete Virtual Network topologies

13

ONF Transport API Project

Applications include Bandwidth on Demand, Data Center Interconnect, IP over DWDM, Virtual Network Services, Network Analytics, etc.

14

Topology Service

Connectivity Service

Network Information Model Database

Path Computation

Network Virtualization

D/I-‐CPI

A/I-‐CPI

NENENE NENEN/EMS NENESDN

Controller NENELegacy

Controller

NENESDN

ControllerNENEApplication

Transport API

Transport APIOpenflow Legacy Protocols Legacy APIs

API Divergence Problem��Absent Standards •  Potential API divergence

•  Vendor-specific

•  Controller-specific

•  Technology-specific

•  Language-specific•  SDO-specific

•  Need commonality

•  Common core model

•  Common minimal subset

•  Plus extensions

ONF Common Information Model

•  Define a common object model for all types of Software Defined Networks•  Basic components like network resources,

service constructs•  Use protocol-independent method

(UML model)•  Capable of being mapped to different

schemas and protocols•  YANG/NETCONF, JSON/REST, OpenFlow

•  Work to develop common view across groups•  ONF, ITU-T, TMF, MEF, OIF, etc.

ONFCIM

TMF

ONF ITU-T

T-API High Level Work Process•  Use cases – describe concepts and API usage

•  Contributions from ONF members•  Functional Requirements

•  Formal requirements TR•  Information Model

•  T-API UML Module within the ONF Common IM •  Based on and extends ONF Core IM

•  Data Schema•  Develop JSON and YANG schema encoding•  Based on the T-API IM

•  Software Prototyping•  Testing with OIF•  Separate project under ONF Open Source SDN•  Follow “Agile” development and “fail-fast” processes

•  Work on all items (Req, IM, API) in parallel

17

Add, Modify, Clarify Functional

Requirements

Update Transport API Information Model (UML in Papyrus)

Update Transport API Data-Schema

(JSON/YANG)

Prototype the APIs

Collect and Analyze the Purpose-specific

Use cases

Achieving Common APIs�� The Tools and Remaining Challenges

Keys to achieving interoperable common APIs •  Base efforts on Common Information Model and API specification •  Verify APIs interoperability and function via Implementation and Testing

•  Joint OIF/ONF Interop of both SBI and NBI Open-Source Friendly Process with Open Documentation •  Draft TAPI documents available via github (ONF OpenTransport project

“Snowmass” ) •  https://github.com/OpenNetworkingFoundation/ONFOpenTransport

•  Open Source Implementation project “Englewood” •  Part of ONF OpenSource SDN Initiative •  https://github.com/OpenNetworkingFoundation/Englewood

Accelerating the Deployment of Practical, Programmable Transport Networks

Dave Brown

OIF VP of Marketing Alcatel-Lucent

SDxCentral Webinar

December 2, 2015

Moving Transport SDN Forward OIF Activities

Completed: ü  SDN Reference Architecture ü  Carrier SDN Requirements ü  2014 Global Transport SDN Demo ü  Framework for Transport SDN In-Progress: •  Transport API Implementation Agreements •  Virtual Transport Network Service Definition •  Transport SDN Operator’s Toolbox •  2016 Global Transport SDN/NFV Demo Planning

20

SDN Reference Architecture Components of Transport SDN

Data Center

DC Mgt/ Controller

Orchestrator

ServiceApplication Plane

Mgt- &Control-Plane

DataPlane

Service Service

Transport

TN Controller

TransportNetwork

TN ControllerMgt

TN ControllerMgt

SDN southbound:OF, XML, SNMP, PCEP, … (could be NE-internal)

OF, MTOSI, REST, …

SDN northbound:OGF NSI, …

DC Mgt/ ControllerDC Mgt/

Controller

Carrier Requirements: Transport Networks in SDN Architectures

•  Based on contributions of major carriers worldwide

•  Comprises requirements on Transport SDN •  Orchestrator (transport network relevant

part) •  Control and management planes •  Data plane

•  Being used as guidance within OIF but also communicated to other SDO’s and forums

2014 Global Transport SDN Demo

•  Testing conducted in carrier labs over 7 week period August-September

•  China Mobile, China Telecom, Deutsche Telekom, TELUS, Verizon

•  Participating vendors •  ADVA, Alcatel-Lucent, Ciena, Coriant,

FiberHome, Fujitsu, Huawei, NEC, ZTE

•  Consulting members

•  China Academy of Telecommunications Research, KDDI R&D Laboratories, Orange

2014 Global Transport SDN Demo Outcome

◆  Successful demonstration of SDN Architecture for carriers •  Can be realized over WAN and provide carrier benefits

•  Highly flexible - multiple technology layers, multiple domains, greenfield and brownfield

◆  Identified a lack of definition for how user applications interact with transport network applications and resource functions

•  The programmability of Transport SDN requires some of the internal interfaces used by ASON to become open

◆  Whitepaper jointly published by OIF and ONF ◆  OIF project started to develop API implementation agreements (IAs)

•  Build on Service Request and Topology APIs prototyped in the demo •  Liaise and align with ONF

Transport SDN Framework ◆  Validated in the OIF/ONF

Prototype Demo in Fall 2014 ◆  MulK-‐layer control ◆  MulK-‐vendor, MulK-‐domain

Demo •  5 Carrier Labs •  9 Vendors

◆  OpenFlow OpKcal Transport Extensions

◆  Prototype NBI for ConnecKvity Service and Topology

◆  Whitepaper available with details

Application Layer

Control Layer

Infrastructure Layer

Domain 1

NE NE NE

Domain 2

NE NE NE

Domain 3

NE NE NE

Network Orchestrator

Parent Controller

Domain Controller

Domain Controller

Domain Controller

SBI

NBI

SBI

Cloud Orchestrator

Compute Storage

Transport APIs Work in Progress

◆  Northbound Interface – OIF API Project •  OIF Project to define API specs

•  Based on OIF/ONF prototyping and testing of REST/JSON APIs •  Service Request, Topology, others

•  Joint with ONF for commonality across technologies & SDOs •  Common Core Information Model •  Mapping to REST/JSON interfaces

Ø  Common Transport API

Virtual Transport Network Service Definition

Work in Progress ◆  An example service definition activity ◆  Takes advantage of virtualization in SDN ◆  Offer customers controllable network slice

Leased Line

VPN

VNS

Client site A

Client site B

Client site A

Client site B

Client site D

Client site C

Client site A

Client site B

Client site D

Client site C Virtual network with vNE & vLink

Client controller

Ctrl of virtual XC

ConnecRon controlled by network providers

RenRng P2P connecRons

Leasing virtual network (connecRon)

Leasing virtual network + connecRon control over the virtual network

Similar to SCS

(PVNS) Static

Dynamic

Service requirements VNS

Virtual network with vNE & vLink

Client controller Rent virtual network

resources from provider

(SVNS) Client site

Virtual network recursive creaRon

Client site Client site Client site

Client site Client site Client site

Leasing virtual network + recursive virtual network creaRon

Transport SDN Toolkit Work in Progress

◆  Essential tools for Transport SDN deployment •  How to apply SDN to a carrier’s multi-domain, multi-layer

transport network •  Transport SDN API specifications to allow deployment of SDN

applications •  Prototyping and testing of real implementations for

experience and interoperability

Architecture

Identifiers Discovery

SCN APIs Integration with MP

Interoperability demos Security

2016 Global Transport SDN/NFV Demo In Early Planning Stage

◆  OIF-managed, co-op with ONF/others, carrier-hosted ◆  Target testing and readout timeframe - Fall 2016 ◆  Potential test candidates:

•  Standardized OpenFlow Optical extensions •  Based on Technical Spec issued by ONF

•  IA work on Transport APIs •  Service Request, Topology, others •  Cooperative efforts by OIF and ONF, e.g., IM

•  NFV and other test applications

Carrier view: what is needed to make SDN more widely deployable in the service

provider network Vishnu Shukla

Verizon

The SDN and Virtualization Business Case Virtualised environment Resources shared across services, reducing stranded capacity and reducing total cost of network build. (Build to average + margin across all services rather than to peak for each service).

Service reliability achieved at application level, without incurring hardware reliability costs. (1 for M vs. 1 for 1)

Reduced power, cooling and other facility requirements.

Standard (COTS) hardware Large scale drives cost down (Economy of Scale)

One Spare holding SKU, drastically reducing the number of units needed.

Disaster recovery/business continuity can be simplified

Software Implementation of Network Functions Introduce new services quickly without deploying an entire network of new hardware. (Velocity)

New services can be inserted and withdrawn without loss of capital investment due to reuse of hardware. Easy to introduce service changes. (Flexibility)

Move workloads around the network to tactically handle capacity issues in specific geographical areas. (Adaptability.)

Verizon 2015 All Rights Reserved

Why Does Transport Need SDN?︎

• Optical and transport networks continue to be difficult and expensive to manage, with many manual processes and very long provisioning times

• SDN and virtualization have the promise of simplifying optical transport network control, adding management flexibility, and allowing the rapid development of new service offerings by enabling programmatic control of optical transport networks and equipment

• Can also reduce the cost of optical switches by moving control and management planes from embedded processors to general-purpose COTS hardware and virtualized software

• Utilize centralized network-wide management and control to drive efficiency and speed


SDN Promise

SDN advocates for greater programmability Provide new behaviors not considered by Standards, Vendor implementations

Facilitates Network application eco-system Seamless/Rapid relocation of endpoints

Abstracted NEs

Virtual Networks

Programmability and Application Awareness


Potential Benefits of Transport SDN SDN Benefit Transport Network Impact Network Utilization •  Application-aware optimization of resources

•  Multilayer optimization across packet and circuit

Improved Service Development/Deployment

•  Greater separation of service development/deployment and network element embedded software

•  Virtualization of network resources Simplified/Streamlined Operations •  Streamline and integrate operations across different

domains •  Circumvent or remove restrictions of legacy

operations systems Monetization of Resources •  Improved charging for network resource usage and

class of service


SDN Architecture Issues

How will Multi-Domain be handled? •  What is the relationship between controllers?

–  Peer or overlay

How will Multi-Layer be handled? •  E.g., location and triggering of adaptation

What is the relationship to Network Management? •  OF control vs. EMS/NMS control (mediation device)


Sponsored by

Challenges

• OperaRonal simplicity •  On-‐board new clients rapidly

• DifferenRated service delivery

•  Automate resource allocaRon on the fly • Scalability

•  Support X transacRons per hour • Security

•  Service isolaRon and authenRcaRon per client

• ConRnuous Availability •  Disaster avoidance / recovery

•  Current transport business model

• MigraRon Path

• Many SDOs, Open source acRviRes

•  Common InformaRon Model


SDOs

ONF OIF

(Transport)

IETF/IRTF

InterDC ATIS

SW Infrastructure

Southbound Interface

Northbound Interface

Openstack

BBF, MEF

ODL,

NFV OPNFV

OPEN SOURCE

3GPP

High Level SDN/Data Center Reference Architecture with SDOs/Forums Focus

Data Center HW

Orchestration & Management

Service Service Service

Transport

SDN Controller

DC Mgt

ONOS

Summary

SDN has great promise to improve transport control •  Programmability

–  Ability to deliver new behaviors not (yet) considered by standards, vendors, …

•  Simplified multi-layer control

•  Common behaviors in heterogeneous NE deployments Operational issues

Role of SDOs

Monetizing Network


Sponsored by

Questions & Answers

© 2015 SDNCentral. All Rights Reserved. December 2, 2015


Upcoming SDxCentral Events

Visit https://www.sdxcentral.com/resources/events/ to view upcoming events by SDxCentral!

December 2, 2015