cloud computing, sdn and nfv educational...

Cloud Computing, SDN and NFVEducational Series

SDN for Carrier Networks

Ralph SantitoroDirector of Strategic Market [email protected] 16, 2013

Part 1 (Sept. 24): Cloud Computing Essentials Objectives and Market Statistics Virtualization Approaches Cloud Computing Architecture and Deployment Models OpenStack Overview and Functional Components Network as a Service (NaaS)

Part 2 (Oct. 16): Software Defined Networking for Carrier Networks Market Drivers and Business Objectives Evolution of ICT to cloud and how it is changing WANs Concepts, Terminology and Architectures Software Defined Services Open Source SDN Controllers and Tools

Part 3 (Nov. 6): Introduction to Network Functions Virtualization (NFV) Market Drivers and Business Objectives Concepts, Terminology, and Architectures NFV Use Cases Cloud, SDN and NFV Inter-relationship

Webinar Educational Serieson Cloud, SDN and NFV

(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved. 2SDN for Carrier Networks

Definition of SDN


Several Definitions of SDN but all havesome common themes

(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved.SDN for Carrier Networks 4

Common Themes in SDN Definitions

Programmability of network through open APIs

Abstraction of network and technology

Virtualization of networks and network resources

Control Layer separation Decoupled from Forwarding Layer Multiple sub-layers (control plane, management plane)


WAN Service Provider Challenges in aCloud-centric world

CloudServices

ITWorld

WANServicesTelecoms

World

On DemandAutomated

ElasticProgrammable

ServicesCloud applications changing how WAN services are usedCarrier networks must evolve to support this new reality

WAN Services Long service lifecycle Manual service activation Infrequent changes Proprietary & hard to program

Cloud Services Short service lifecycle Automated service activation Frequent changes (Elastic) Open and programmable


Challenges with Network ProgrammabilityComputing Devices and Cloud Environments vs. Wide Area Networks

7

Easy to program: Computing Devices and Cloud Environments Singular, technology-abstracted programming environments Open, standardized, and “de facto” APIs, OSs and development tools

Difficult to program: Wide Area Networks Multi-vendor, multi-technology with limited technology-abstraction Diversity of protocols, interfaces and APIs for EMSs and network elements

(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved.SDN for Carrier Networks

Why SDN ?

Today’s static WANs do align with Cloud apps & services Cloud-based applications dynamically added, modified or removed

Changing today’s static WANs is complex To add/modify/remove a WAN service, network operator must:

• Access multiple switches, routers, transport equipment, firewalls, etc.• Configure ACLs, VLANs, QoS and protocols via management tools• Determine if change is possible or has been tested and integrated into

back office IT systems• Factoring in network topology, equipment model/SW revision and OSS

(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved. 8

These complexities force today’s networks to be relatively staticto minimize any service disruption


SDN Long Term Objectives

Mitigate multi-vendor interoperability issues through technology abstraction and centralized control and management APIs

Accelerate Innovation By reducing product development and deployment times More revenue sooner by rolling out new services and features faster

Increased Network Programmability SPs, enterprises, and independent software vendors (ISVs) leverage large

base of Web 2.0 application development tools, platforms and skilled workforce

Applications obtain more granular network control Ability to apply comprehensive and wide-ranging policies at the session, user,

device, and application levels

Increased network reliability and security Centralized control of network devices for uniform policy enforcement and

fewer configuration errors


Cloud Service Provider and CloudConsumer Requirements of SDNs Cloud Service Providers want to: Migrate VMs, on demand, to any DC based on:

• Available DC capacity, WAN BW, WAN Latency, etc. Query WAN to make informed DC route selection Create a pool of DC resources

• DCs interconnected via WANs act like a single DC

Enterprise Cloud Consumers want to: Increase/Decrease WAN bandwidth

• just how they increase/decrease CPU and storage for VMs with IaaS Use Bandwidth on Demand above a minimum CIR

• Short term increase in CIR bandwidth (hours to a week)


Ban

dwid

th

Time

WAN

DC 1

DC 2

DC 3

Additional SP revenue


WAN Services alignment with CloudCurrent and future SDN directions

What most WAN Service Providers offer today: Fixed bandwidth WAN services

• Takes weeks to months for subscribers to add bandwidth

New long term contract required for higher bandwidth• Delays buyer’s purchasing decision for higher bandwidth

Service Provider customer portals are closed systems• No APIs for Customer’s apps to query network or request service changes

WAN Services Evolution towards an SDN Bandwidth on Demand (BoD)

• Increase or Decrease CIR on Demand or via Reservation

Open APIs to create “Network as a Service” (NaaS) ala IaaS• Web 2.0 APIs agnostic of networking technology• Customer’s applications query network and make service changes


BoD provides more WAN Service Revenue - soonerOpen APIs enable Application/Service Innovation and Differentiation


SDN benefits between Buyers andSellers often differ Wireless Operator Cell Site Backhaul Provider Wireless Operator wants to purchase BoD service for all cell towers

• BW needs at different towers change at different times or days Cell Site Backhaul provider prefers fixed BW to each tower

• Simplifies billing and network operations

DC Operator WAN SP for DC-to-DC Interconnect DC Operator wants control of bandwidth and route selection based

on QoS policy decisions• E.g., path delay, available BW, packet loss, connection availability

If WAN SP does provide programmable access to the network,• DC Operator will purchase commodity wavelengths

• resulting in low value, low price, commodity service from WAN service provider



SDN Architectural Components

Open Networking Foundation (ONF)SDN Reference Model

Application Layer End User Business Applications (software) that

communicate with the SDN via Open APIs

Control Layer Software-based networking functions (called

Network Services by ONF) that control andmanage the physical network infrastructure viathe OpenFlow or other protocols

Infrastructure Layer Networking hardware that provides forwarding

of traffic through a L2/L3 packet-based orL0/L1 circuit-based transport network

InfrastructureLayer

ControlLayer

ApplicationLayer

BusinessApplications

API

API

API

NetworkServices

Network Services


Generalized SDN Model.. like programming devices and cloud applications

In the Southbound direction Abstracts networking technology/protocol details from NetOS/SDN Controller Provides vendor-independent programmability of network elements

In the Northbound direction Provides network/service programmability (APIs) by software applications Abstracts networking technology details from the applications Enables automated, on-demand capabilities just like cloud apps enjoy today

Northbound APIs (network/service abstraction)Network OS/SDN Controller

Southbound APIs (technology abstraction)

NetworkElement

NetworkElement EMS

Apps Apps AppsWeb 2.0 APIs, e.g., RESTful, for Appsto program networks and services

Software adapters (“plugins”) forNetOS/SDNC to NE/EMS protocols

NetworkElement

Apps


OpenFlow TL1 SNMP XML

Northbound APIsRESTful APIs providing network abstraction

REST = Representational State Transfer REST-style architectures consist of clients and servers Clients initiate request to servers which process request and return

responses Requests/responses for transfer of representations of resources Resources are any meaningful concept that may be addressed

Create Read Update Delete (CRUD) maps to HTTP requests as: Create (add new entries) = HTTP POST Read (retrieve, search or view existing entries) = HTTP GET Update (modify existing entries) = HTTP PUT Delete (destroy or deactivate existing entries) = HTTP DELETE


Southbound APIsSoftware Adapters (plugins) providing technology abstraction

SDN proponents initially said only OpenFlow can beused as the protocol to connect NEs to SDN controllers Such NEs are referred to as Open Virtual Switches (OVSs)

SDN is about making networks “programmable” Achieved by abstracting the networking technology protocol,

e.g., SNMP or TL1 through software adapters

Software adapters translate between a generalizedservice model and the NE-specific management protocol Windows printer driver analogy

• When a Windows application needs to print something, the printer driverconverts the generalized printing commands (# of pages, duplex,mono/color printing, etc.) to printer-specific codes and protocols



Software Defined Services

How WAN Services Are Defined/Sold TodayProblem Statement

Services typically defined/sold based on the transport technology SONET private line service Ethernet private line (EoSONET) service WDM private line service DS1 or DS3 private line service OTN private line service IP/MPLS service MPLS VPN or VPLS service

This is problematic: Many products with similar capabilities

• E.g., Ethernet private line delivered over WDM vs. OTN vs. SONET Product overlap results in delayed innovation and excessive costs

• Major implications to revenue and margins

Customer purchasing decision complicated and delayed• Customers have to sort through so many product/technology choices• Customers want to specify the service capabilities to meet their requirements

• Having to understand the technologies just delays their purchasing decision(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved.SDN for Carrier Networks 19

Customers want to purchase WAN servicesprimarily based on capabilities, not technology

Fundamental Capabilities Interface Type Ethernet: 10Mbps-100Gbps SONET: OC3-OC192 OTN: OTU1-OTU4

Connectivity of Interfaces Point-to-Point Any-to-Any (Multipoint) One-to-Many (Tree)

Bandwidth of Connection Line rate of port Sub-rate (CIR < Line Rate)

• E.g., 400Mbps on a 1Gbps port

Differentiating Capabilities Service Availability

MTTR Protected or Unprotected

Service Multiplexing Single service per port Multiple services per port

Classes of Service Application Identifier for each CoS

Bandwidth Granularity On Demand or Scheduled

Service Performance One-way or round trip delay Maximum packet loss

Service Transparency Fully transparent Protocol-aware


Software Defined Service (SDS) usingService Layer Abstraction

SDN currently focusing on networking and not services

Network ‘services’ are sold, not network infrastructure Services are what generates revenue Infrastructure is the means to deliver the services

Service Layer Abstraction Network connectivity (WAN) or other network “service” abstracted from transport

technology used to deliver it

SDS abstractly defines a service based on its capabilities not the technology used to deliver it

With SDS, apps. need not understand the networking technology used Query the network to determine its status, capabilities, etc. Request changes to the network, e.g., change bandwidth


Subscribers are more interested in what is deliveredrather than how it’s delivered

WAN Software Defined Service(SDS) Example Service defined by set of capabilities in a generic WAN service model The specific attributes can determine which technology to use and need not be

exposed to the subscriber

Example WAN software defined service capabilities Interface type and speed Data flow identifier: None, VLAN ID, MPLS label, IP address, MAC address Bandwidth granularity: 1Mbps, 1.25Gbps, 50Mbps, etc. On Demand or Scheduled Bandwidth Capabilities Application identifier: None, Layer 2-7 value or combination of them Mean Time to Restore (MTTR) service: <4hrs, < 2sec, < 50ms, etc. Data forwarding method: All, MAC address, VLAN ID, IP address, MPLS label Data isolation method: Virtual (e.g., VLAN ID) or Physical (e.g., λ or OTN container) Service Transparency: Fully transparent or Application/Protocol-aware Service Performance Metrics: Loss, Latency, Delay Variation, Availability


No longer need to define WAN service using Layer 1/2/2.5/3 technologyNo longer need to distinguish between “private line” and “VPN”


Open Source SDN Controllersand Tools “Open Source” in this context means that the software

can be freely downloaded Some tools are more “open” than others based on

who controls them

Open SDN ControllersOpenDaylight


FlowVisor (onlab.us) Acts as a transparent proxy between

OpenFlow switches and multipleOpenFlow controllers.

FlowVisor creates ”slices” of networkresources and delegates control of eachslice to a different controller

Mininet (mininet.org) Emulates any type of forwarding element,

in terms of function and performance, atscale

Create an SDN network to yourspecifications in a few minutes on yourcomputer, to test SDN ideas andsolutions on different networkconfigurations

Sampling of Open Source SDN Tools


OpenStack Quantum (http://wiki.openstack.org/QuantumDevstack) API for OpenStack orchestrator used to create virtual L2 networks and virtual ports Includes “plug-ins” to support Open vSwitch (OVS), Cisco UCS, Linux Bridge, Nicira NVP Virtual Networks: Equivalent to Virtual VLAN

• REST example: http://domain.com/<tennant-ID>/network/<network-ID> Virtual Ports: Linked to vNICs on virtual servers

• REST example: http://domain.com/<tennant-ID>/network/<network-ID/port/<port-ID>

Open Network OS (ONOS) (onlab.us) Captures up-to-date state of the network and

maintains a network map Provides an interface for the network control and

management applications to update the networkmap

Programs the forwarding elements, by installingforwarding rules, in response to the changes tothe network map by the control and managementapplications.

Sampling of Open Source SDN Tools(cont.)


ONOSNetwork OS


SDN Realities and Predictions

Cloud and Virtualization is driving SDN SDN now happening in Data Center Networks Multi-Provider WANs will follow but will take longer

SDNs require multi-vendor, multi-layer control and management SDNs will use hybrid approach to support new and legacy NEs

Network services will be abstracted from their technologyimplementation

Some Control Plane functionality may be difficult to centralize andwill remain on network elements E.g., Protection-switching or SOAM-PM protocols

Open Web 2.0 Northbound APIs

SDN discussions often focus on the use of COTS hardware toachieve high cost savings This is not where the major cost savings will be achieved OpEx savings will play a much larger role


SummaryWhat was covered in today’s session

SDN Definitions

How Cloud Services are changing WAN services

SDN Benefits and Objectives

SDN Architectural Components

RESTful Northbound APIs

Southbound APIs using Software Adapters (plugins)

Software Defined Services via Service Layer Abstraction

Open Source SDN Controllers and Tools(c) Copyright 2013 Fujitsu Network Communications, Inc. All Rights Reserved.SDN for Carrier Networks 28

References and Resources

SDN References and Resources

SDN Central (News, Education) http://sdncentral.com

Compendium of Open Source SDN Tools http://www.sdncentral.com/comprehensive-list-of-open-source-sdn-projects/

Open Networking Foundation (ONF) http://opennetworking.org

SDN Wikipedia Definition http://en.wikipedia.org/wiki/Software-defined_networking

Representational State Transfer (REST) Tutorial http://www.restapitutorial.com/

JavaScript Object Notation (JSON) http://www.json.org/

OpenDaylight Project (SDN Controller) http://opendaylight.org

Floodlight Project (SDN Controller) http://projectfloodlight.org

Open Networking Lab Mininet, FlowVisor, Open Network OS (ONOS) http://onlab.us


Q&A

Ralph SantitoroDirector of Strategic Market [email protected]

cloud computing, sdn and nfv educational...

Documents