SPARC: use-cases and results Requirements and Controller Architecture

SPARC: use-cases and results Requirements and Controller Architecture

Wolfgang John

[email protected]

November 23th 2012

Split Architecture for Carrier-Grade Networks.

EU FP7 Project Start date: July 2010; End date: November 2012 (1 week ago …) 6 Partners:

ER Kista ER Budapest=

SPARC @ ACREO23.11.2012 2

Mission: Applying Software Defined Networking (SDN) to operator networks Results

23 publications, presentations and demos (GENI engineering conference, World Telecommunication Congress, Globecom, etc.)

Standardization impact in ONF and IRTF

Key Project Deliverables D2.2: Use cases, requirements, techno-economic study (CAPEX and OPEX), business

environment D3.3: Main technical document, study of architecture and required extensions D4.2: Documentation of specific OpenFlow extensions D4.3: Technical documentation of implementation and prototyping activities D5.2: Results of validation and performance evaluation Movie: Summarizing the most important demo’s

(Soon) all to find on: http://www.fp7-sparc.eu

Split Architecture for Carrier-Grade Networks.


SPARC.Project Team.


LSR

Optical transportOptical transport

BRAS

Backbone

LERAGS2

GPON OLT

AGS1

Outdoor DSLAM

DSLAM

Business

Business

RGW

Switch / Router

Data Centre

Other Service Platforms (mobile,

business, IPTV, VoIP, ...)

Access/Aggregation

AAAAuto-

configuration Network

Management Service

Management

OAM subsystem

Use Case Areas.Focus on Access/Aggregation.


The vision of SPARC is to define, implement & evaluate a scalable carrier class Split Architecture.

Seven objectives of SPARC, with the three main objectives highlighted: Definition of typical use cases for Split Architecture (D2.2) Analysis and description of business potential (D2.2)

Definition of Split Architecture blueprint (D3.3) Extension of the OpenFlow protocol (D3.3 and D4.2) Development of SPARC prototype (D4.3)

Validation of SPARC prototype (D5.2) Exploitation of results (papers, demos, presentations, videos)

SPARC.Main Objectives.


What is carrier-grade? Scalability

Support large-scale deployments for carrier-grade networks. E.g. a controller shall be able to control forwarding devices that could count in the order of hundreds.

Availability and Reliability The availability of networking services shall be equivalent to that of traditional

technologies. Network and service management

The ability to monitor, diagnose and centrally manage the network Quality of Service

Allowing the assurance of SLAs using QoS guarantees for service attributes (e.g. rate, loss, delay) and service isolation

Support for legacy technology allowing deployment of new services in parallel to existing legacy protocol stacks

SPARC Objectives.Carrier-grade.


SPARC Requirements and Study Topics.Overview.

Requirements (study topics) from WP2

WP3: Problem and Solution Description

WP4: OF Extensions WP4: Prototype Integration /Implementation

WP5: Validation / Performance Evaluation

Controller Architecture Yes Yes Yes Yes

Network Management Yes No No No

Service Creation Yes Yes Yes Yes

Virtualization & Isolation Yes Yes Yes Yes

OAM Yes Yes Yes Yes

Openness & Extensibility Yes Yes Yes Yes

Control Channel Bootstrapping & Topology Discovery

Yes N/A Yes Yes

Network Resiliency Yes N/A Yes Yes

Energy-Efficient Networking Yes Yes No No

Quality of Service Yes No No No

Multilayer Aspects Yes No No No

Scalability Yes (numerical validation)

N/A N/A Yes

1

2


control

data

control

data

control

data

(I) today’s network design

control

data

app app app

data data

OpenFlow

(II) generic OpenFlow architecture proposed initially by Stanford

SDNcontrol

softwarenetwork services

OpenFlow

data data data

(III) SDN specified by the ONF

business applications

Intro to SplitArchitecture.Evolution of SDN.


• OpenFlow-based SDN model, defined by the ONF

Intro to SplitArchitecture.Software-Defined Networking.

data data data

SDNcontrol



SPARC @ ACREO23.11.2012 10

• OpenFlow-based SDN model, including a network hypervisor– Virtualization and abstraction layer– Position of hypervisor (below or above NOS) debatable

Intro to SplitArchitecture. Software-Defined Networking.

data data data

SDNcontrol



control program

data data data

hypervisor

network operating system


SPARC @ ACREO23.11.2012 11

• SPARC SplitArchitecture– Again a split between data and control plane– Forwarding and processing in data plane considered separately

Intro to SplitArchitecture.The SplitArchitecture concept.

control program

data data data

hypervisor

network operating system


SPARC @ ACREO23.11.2012 12

• SPARC SplitArchitecture– Again a split between data and control plane– Forwarding and processing in data plane considered separately

Intro to SplitArchitecture.The SplitArchitecture concept.

OpenFlow

hierarchical controllerconcept

forwarding forwarding forwarding

processing processing processing

SPARC @ ACREO23.11.2012 13

• SPARC SplitArchitecture– Initial considerations on the role of network management

Intro to SplitArchitecture. The SplitArchitecture concept.

network management

system

OpenFlow




SPARC @ ACREO23.11.2012 14

• SPARC SplitArchitecture– Recursively stacked control planes– Abstracted network view ot higher planes via OpenFlow Interface


OpenFlow

OpenFlow

hier. control plane n+1

hier. control plane n

hier. control plane n-1

app

app

app

OpenFlow


filtered,abstract network

view



network management

system

SPARC @ ACREO23.11.2012 15


network management

system

OpenFlow

OpenFlow




app

app

app

OpenFlow



view



• SPARC SplitArchitecture– Recursively stacked control planes– Abstracted network view ot higher planes via OpenFlow Interface

SPARC @ ACREO23.11.2012 16

• Goals for a carrier-grade control layer:– Increase flexibility

• Adapt control architecture to use-cases and business models• Distribute the control layer to adapt to network capabilities• Allowing both cross-layering and strict layering of control logic

– Increase scalability• Operator networks are complex

-> divide and conquer the problem space– Allow smooth migration

• Supporting control protocol operations with legacy domains

Hierarchical controller.Design goals.

SPARC @ ACREO23.11.2012 17

CPCP CPCP CPCP

DPDP DPDP DPDP

CP peers talk OSPF, IS-IS, STP, etc.

FWD engine (DP) and control logic (CP) sit jointly on a single network element

Hierarchical controller.

• Current situation: monolithic network elements

SPARC @ ACREO23.11.2012 18

DPDP DPDP DPDP

CPCP CPCP CPCP

OpenFlow

But still the old situation the CP peers control a single network element and use the old protocol for sharing state as before (OSPF, IS-IS, LDP, STP, …)

Hierarchical controller.Splitting Ccontrol and forwarding.

• Step 1 of SDN: Splitting control from data plane

SPARC @ ACREO23.11.2012 19

• Step 2 of SDN: Centralize control plane

Hierarchical controller.Centralizing control.

Benefit: no complex protocols for sharing state among CP peers required any more.

Centralized control logicCentralized control logic

DPDP DPDP DPDP

OpenFlow

SPARC @ ACREO23.11.2012 20


DPDP DPDP DPDP

Domain acts like a backplane within the emulated data path element.

OpenFlow

Mgmt API

• SPARC Idea #1: Exposing services via OpenFlow again!

Hierarchical controller.OpenFlow as northbound interface.

OpenFlow

SPARC @ ACREO23.11.2012 21

Flowspace MgmtFlowspace Mgmt

Hierarchical controller.Flow space registration.


DPDP DPDP DPDP

Higher layer controllers subscribe to parts of the flowspace (i.e. slices)Replace the pub/sub interface (as in NOX) with flowspace reservation

OpenFlow

Mgmt API

OpenFlowOpenFlow

OpenFlow

• SPARC Idea #2: Integrate FlowVisor functionality into controller

SPARC @ ACREO23.11.2012 22

Requires OpenFlow protocol extensions for management of:* Flowspaces: allow plane (n) to register a slice of the flowspace on (n-1)* Transport endpoints: allow plane (n) to control (CRUD) logical ports on (n-1)

• Result: Hierarchical structuring of control planes!

Hierarchical controller.Stacked control planes.

SPARC @ ACREO23.11.2012 23

IPIP

ETHETH ETHETH

04/22/23

PHYPHY PHYPHY

SMTPSMTP

IPv4IPv4 IPv6IPv6

ETHETH ETHETH

PHYPHY PHYPHY

An IP router use case: build an IPv4/IPv6 router

An SMTP router use case: build a Mail Transport Agent (MTA)

DPDP

SMTPSMTP

ETHETH

IPv4IPv4

OpenFlow

PHY-CTLPHY-CTL

ETH-CTLETH-CTL

APP-CTL APP-CTL

IP-CTLIP-CTL

=

• IP-CTL emulates a single IP layer• ETH-CTL emulates Ethernet host stacks• PHY-CTL is a data path element

The northbound interface is OPENFLOW!

Hierarchical controller.Example: protocol stack.

• Example: Modular layering of a controller

SPARC @ ACREO23.11.2012 24

• SPARC SplitArchitecture– Initial considerations on the role of network management

Considerations on network management. The SplitArchitecture concept.

network management

system

OpenFlow

OpenFlow




app

app

app

OpenFlow



view



SPARC @ ACREO23.11.2012 25

Considerations on network management.Control vs. management.

• Boundary between management and control is blurred– Management functions are important in SplitArchitecture

Today’sNetwork

Management

SplitArch/SDN

Functionality(Increased control granularity)

Automation(Program driven, automatic adjustment

of the network)

Speed(Beyond human time-scale)

SPARC @ ACREO23.11.2012 26

• Which NM functions to embed in a controller?– Q1: Already an essential part of SplitArchitecture/SDN control?

If not,– Q2: Facilitates timely and automated configuration and flow steering?

If so,– Q3: Possible with open and standardized extensions to the OF / OF-

Config protocols? (no bloating with vendor or device specific models)• Apply this question to NM function according the TMN/FCAPS

definitions of network management

Considerations on network management.Assessment of functions.

SPARC @ ACREO23.11.2012 27

NM function FCAPS Groups Q1 included? Q2 timely?

Q3 open interfaces?

Proposed CP integration

Element management functions:Firmware management config no no no noDevice monitoring (temp., etc) performance no no no noDevice monitoring: Power consumption performance no yes¹ OF-mon yes¹Control network bootstrapping config no no no noResource and capability discovery config yes no OF, OF-config yesLogical swtich instatiation config yes no OF-config yesControl channel (addresses and credentials) config / security yes no OF-config yesFault detection (equipment) fault no no no noAlarm management configuration no yes OF-config yesLogging of alarms fault, accounting no no no noLogging of statistical data performance, accounting no no no noResource usage (cpu, buffer, queue-length) performance no yes² OF-mon yes²Network management functions:Topology discovery (creation of network view) config yes yes OF yesPath computation & setup config yes yes OF yesFlow table management config yes yes OF yesTunnel management config yes yes OF-config yesTraffic engineering (creation of QoS paths) config yes yes OF yesFault detection (link level) fault yes³ yes OF-mon yesLink performance monitoring performance no yes OF-mon yesNetwork performance optimization performance no yes OF, OF-config yesResiliency measures performance/config yes yes OF, OF-config yesService management functions:Accounting accounting no no no noUser management and AAA accounting / security no no no noService definition and administration config no no no noService OAM configuration config no yes OF-config yes*QoS management (service delay, loss) performance no yes OF-mon yes*SLA management accounting no no no no

¹ for energy-aware networking (see section 5.7)² for logical switches sharing switch resources (see section 5.2.4)³ implemented in SPARC as BFD (see section 5.3.3)* assuming service controller functionality in the CP, as in SPARC D4.3

Considerations on network management.SPARC assessment example.

SPARC @ ACREO23.11.2012 28

Control and management architecture.Summary.

• Result: A recursive and modular control plane architecturecontrol plane A control plane B

e.g. optical devices

network management

system

OpenFlow




SPARC @ ACREO23.11.2012 29

SPARC: use-cases and results SPARC prototype implementations

Wolfgang John

[email protected]

November 23th 2012

Seamless MPLSaka carrier grade packet transport

• Seamless MPLS “…architecture which can be used to extend MPLS networks to integrate

access and aggregation networks into a single MPLS domain…” draft-leymann-mpls-seamless-mpls-03

Forklifting access/aggregation to MPLS may be too expensive apply SDN principles for Seamless MPLS

SPARC @ ACREO23.11.2012 31

Central element

IP/MPLS coreAggregationIP EdgeAccess GW

Service

SwitchSwitch

Switch

CPCP

CP

OpenFlow

IPMPLS IP

MPLS

IPMPLS

OSPF, LDP,RSVP-TE, BGP …

CP

CPCP

CP

SPARC Controller

Pro

toco

lP

roxy

CP

APP (CP) APP (CP)

Seamless MPLS implementation.Basic concept.

SPARC @ ACREO23.11.2012 32

1. Topology discovery of MPLS aggregation & core2. Management of MPLS LSPs in aggregation3. Signal end-to-end MPLS LSPs 4. Provision MPLS transport services (e.g. Pseudowire)

Video

WEBClient

MPLSCP

MPLSCP

MPLSCP

OFSwitch

OFSwitch

OFSwitch

OFSwitch

OFEdge

OFEdge

IP/MPLS coreOPENFLOW MPLS Aggregation

NNIOSPF, LDP

OFSwitch

CoreMPLS

CoreMPLS

CoreMPLS

ServicesClients

Client

SPARC Controller

NOX Kernel

OpenFlow MPLS CTRL

Pro

toco

l Pro

xy

OS

PF

LDP

End-to-end MPLS CTRL

Discovery

Seamless MPLS implementation.Essential Functionalities.

SPARC @ ACREO23.11.2012 33

IP/MPLS coreOPENFLOW MPLS Aggregation ServicesClients

MPLSCP

MPLSCP

CoreMPLS

CoreMPLS

CoreMPLS

MPLSCP

OFSwitch

OFSwitch

OFSwitch

OFSwitch

OFAccess

OFAccess

OFSwitch

Video

WEB

Client

Client

NOX Kernel

DiscoveryDiscovery

Pro

tocol P

roxy

Pro

tocol P

roxy

OS

PF

OS

PF

Combine OpenFlow and legacy topology discovery information

Seamless MPLS implementation.1. Topology disovery of MPLS aggegation & core.

SPARC @ ACREO23.11.2012 34


MPLSCP

MPLSCP

CoreMPLS

CoreMPLS

CoreMPLS

MPLSCP

OFSwitch

OFSwitch

OFSwitch

OFSwitch

OFAccess

OFAccess

OFSwitch

Video

WEB

Client

Client

SPARC Controller

NOX Kernel

OpenFlow MPLS CTRLOpenFlow MPLS CTRLDiscovery

• Installs PtP, MPtP and PtMP tunnels

• Reconfigures them upon topology changes

Seamless MPLS implementation.2. Management of MPLS LSPs in aggregation.

SPARC @ ACREO23.11.2012 35


MPLSCP

MPLSCP

CoreMPLS

CoreMPLS

CoreMPLS

MPLSCP

OFSwitch

OFSwitch

OFSwitch

OFSwitch

OFAccess

OFAccess

OFSwitch

Video

WEB

Client

Client

• Topology synchronization with OSPF

• Spans end-to-end MPLS with LDP• Nests them in MPtP tunnels in

aggregationSPARC Controller

NOX Kernel

OpenFlow MPLS CTRL

Pro

tocol P

roxy

Pro

tocol P

roxy

OS

PF

OS

PF

LD

PLD

P

End-to-end MPLS CTRLEnd-to-end MPLS CTRL

Discovery

MPLS Tunnel MPLS Tunnel

Seamless MPLS implementation.3. Signaling end-to-end MPLS LSPs.

SPARC @ ACREO23.11.2012 36

Split-BRAS

• Split-BRAS BRAS is complex and expensive integrated node since it must handle all

subscriber traffic, hence it must cope with continuously increasing capacity need, this means increasing cost

Traditional way of deploying BRAS will not scale apply SDN principles to distribute BRAS functionality

SPARC @ ACREO23.11.2012 37

RAWBRAS

AN

AGS 1

AGS 2

BRAS RADIUS

Client(RGW)

PPPoE tunnel

AN

AGS 1

AGS 2

RADIUS

Client(RGW)

PPPoE tunnel

Control session

AN

AGS 1

AGS 2

Client(RGW) PPPoE tunnel

IP Edge

RADIUS

Control session

Aggregationspecific tunnel

Common residential model today with PPPoE

Split Control and raw forwarding

Roll raw BRAS towardAccess Node

RAWBRAS

Split BRAS.Basic concept.

Control session

SPARC @ ACREO23.11.2012 38

Applying a recursive

control plane

data path element

control plane A control plane B

L2 fwd engine (disabled)

EoPhy

L3 fwd engine

IPoEPPP & PPPoE

EoPhy

Split BRAS.Architecture Blueprint.

SPARC @ ACREO23.11.2012 39

Central element


SPARC Controller

Split BRAS.Concept.

RAWBRAS

Relay PPP Request

Ethernet IP/MPLS

SPARC @ ACREO23.11.2012 40

Central element


SPARC Controller

Split BRAS.Flexible placement.

RAWBRAS

SwitchSwitch

Switch

PPPoE (over PWE)

SPARC @ ACREO23.11.2012 41

Central element


SPARC Controller

Split BRAS.Increased scalability.

SwitchSwitch

Switch

PPPoE (over PWE)RAWBRAS

RAWBRAS

IP/MPLS

SPARC @ ACREO23.11.2012 42

Summary of SPARC OpenFlow Protocol Extensions implemented.

• MPLS– Parsing MPLS headers– Basic MPLS actions: push/pop header, change TTL, …

• PPP & PPPoE– Terminate PPP & PPPoE tunnels

• Connectivity Check– Pro-active monitoring of contuity with probe packets of MPLS-TP BFD format– Used for monitoring adjacency and flow pairs (bidirectional path)

• OAM & Protection Notification– About state changes of monitoring entities– About protection events

• Pseudo Wire– Support for Ethernet Pseudo Wire over MPLS PSN– Not full implementation (i.e., no sequence numbers)

SPARC @ ACREO23.11.2012 43

SPARC: use-cases and results Requirements and Controller Architecture

Documents

Transcript of SPARC: use-cases and results Requirements and Controller Architecture