(Geneva, Switzerland, 4 June 2013) · • IETF BoF on Software Driven Networks (SDN) • IRTF BoF...

Geneva, Switzerland, 4 June 2013

"Deeply Programmable Network"Emerging Technologies for Network Virtualization

and Software Defined Network (SDN)

Akihiro NakaoAssociate Professor

The University of [email protected]

ITU Workshop on Software Defined Networking (SDN)

Standardization Landscape(Geneva, Switzerland, 4 June 2013)

Future Network Research Proliferating...

• Future Internet Architecture (FIA) in U.S.

• Global Initiative in Network Innovations (GENI) in U.S.

• Framework Programme 7 (FP7) in EU

• Horizon 2020 (2014-) in EU

• New Generation Network (NwGN) in Japan

2The University of Tokyo Confidential

How can we resolve newly observed, constantly arising problems in the current Internet?

33

Cloud Computing Platform

Sensors

Smartphones

NetBooks/NetTops

SaaS PaaS IaaS

Network Services

Enterprises EnterprisesEnterprises

Sub-optimal Data Center NW

Access & Data Convergence

Security Vulnerability

Wired-Wireless Convergence Content Oriented Access

Sensor Data Processing

Economic DDoS Attack

Named Content ID-Locator Separation

The University of Tokyo Confidential

Emerging Areas of Studyin Future Network Research

• Network Virtualization (NV)

• Software Defined Network (SDN)

• Network Functions Virtualization (NFV)

• And more?4

Introducing “programmability” into networking to flexibly and dynamically resolve constantly arising contemporary issues.


Network VirtualizationIn computing, network virtualization is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization.

http://en.wikipedia.org/wiki/Network_virtualization

.... the “advanced network virtualization”, govern a collection of the resources ranging from links, networks, and node-software as a slice and create a virtualized network over the slice with dynamically controllable and programmable links and nodes.

http://nvlab.nakao-lab.org/nv-study-group-white-paper.v1.0.pdf


http://en.wikipedia.org/wiki/Virtual_network

http://en.wikipedia.org/wiki/Virtual_network

http://en.wikipedia.org/wiki/Platform_virtualization

http://en.wikipedia.org/wiki/Platform_virtualization



https://nvlab.nakao-lab.org/nv-study-group-white-paper.v1.0.pdf

https://nvlab.nakao-lab.org/nv-study-group-white-paper.v1.0.pdf

SDN• Software Driven Network (IETF BoF)

• Software Defined Network

• Some Definition Needed :-)

??

SDN decouples the system that makes decisions about where traffic is sent (the control plane) from the underlying system that forwards traffic to the selected destination (the data plane)...

Software-defined networking (SDN) is an approach to building computer networks that separates and abstracts elements of these systems

http://en.wikipedia.org/wiki/Software-defined_networking

6

SDN enables programmability for control-plane so that OPEX in network operation and management can be reduced through automation...

Aki Nakao 2013






Standardization Activities• ITU-T on Future Networks / Network Virtualization

• ETSI on Network Functions Virtualization (NFV)

• IETF BoF on Software Driven Networks (SDN)

• IRTF BoF on Network Virtualization

• IETF WG on Interface to Routing System (I2RS) (conceptually similar to SDN)

• ONF (Open Networking Foundation) on Software Defined Networks (SDN) /OpenFlow

• OpenDaylight on Software Defined Networks (SDN)


Deep Programmability within Network

8

•Application Programmability

•Control-Plane Programmability• Interfaces •Functions • Route Control• Access Control• Network Management

•Data-Plane Programmability• Interfaces •Functions •Packet Data Processing• Network Appliances (DPI, BRAS, EPC)• In-Network processing (Cache, Transcode) • Wide-Area generic processing

•Handling New Protocols• IPvN (N>6), New Layer2, CCN


Control-PlaneElements

Network Applications

Interfaces

Data-PlaneElements

e.g, OpenFlow Controller

e.g, OpenFlow Switches

e.g, Southbound API

Interfacese.g, Northbound API

Applications

Control Plane

Data Plane

OpenFlowSDN

OpenDaylight

NFV

DPN

DeeplyProgrammableNetwork(DPN)

Discussions necessary at ITU-T

• Network Virtualization (NV)

• Software Defined Network (SDN)

• Network Functions Virtualization (NFV)

9

These missing pieces should be studiedamong industriesand academia(GENI, FIA, FP7NwGN related academia)

Further study and standardization needed at ITU-T (SG13, SG11 or FG-DPN)


Existing standardization activities

• Systematic view and organization of related technologies (NV, SDN, NFV and DPN)

• Deeply Programmable Network (DPN) Technologies

• Programmability for in-network processing

• Programmability for new (non-IP) protocols

• Data-Plane Programmability Interfaces

• Accommodation of multiple isolated programmable environments

These missing pieces

DPN Research: FLARE


11

!""#$%&'()'*++*,$"

-(."

!&-/!-010!*2*0&$*3"0&'()'*++*,4$42%

/!-5(32'($0&$*3"0

&'()'*++*,4$42%

-"60&'(2(7($05*#*,4$42%

-"26('8094'2:*$4;*<(3

FLARE


OpenFlow Switch

OpenFlow Controller (OFC)

Fixed Data Plane Fixed Control Plane

OpenFlow API(Southbound API)

Flow Pattern Match

ActionsActions

•Complex processing not supported Data-plane programmability •Non Internet protocols not supported New protocols•L7 pattern match not suppoted New classification•Proprietary actions cannot be executed Proprietary actions•Proprietary API cannot be added Proprietary APIs (re)definition

Physical PortsAlthough flexible control is achieved to some extent...

Applications

Northbound API

OpenFlow Switch (OFS)


12

Programmable Data PlaneProgrammable Control Plane

•Tradeoff between performance and flexibility•Ease of programming •Supporting multiple protocols/instant switch/concurrent use

Challenges:

Controller

Southbound API

Applications

Northbound API

Physical PortsDeeply

Programmable Switch

Fully Programmable Switch?

The University of Tokyo Confidential 13


Multiple Fully Programmable Layers (Slivers)





“Resource virtualization” within a single node enables multiple switching logics/controls

Virtualized Resource Layers(Slivers)


Sliver N

Sliver 2

Sliver 1

Packet Slicer

NodeManager

FLARE Central

Physical Ports15

Virtual Ports


..

FullyProgrammable

FLARE Node Architecture(multiple fully programmable slivers)


FLARE Node Implementation• Multiple, isolated, deeply programmable environments• OS Virtualization on many-core processor (D-plane)

and x86 processor (C-plane)• Multi 10Gbps ports• 1U / 1U Mini Form Factor• Control Plane & Data Plane Linux Programmability• Flexible programmability and reasonable performance


17

10GbE x4

The number of ports

GbE x8 + 10GbE x2Capa

city in

Gbps

Roadmap of FLARE nodes

40

320

4 10 32

FLARE12012 4Q

FLARE22013 1Q

10GbE x8 FLARE-X (1U)2013 4Q

10GbE x32FLARE-EX (1U)

2014 1Q


FLARE Programming Model in Sliver

19

OFSwitch

FromIO(xgbe1)

ToIO(xgbe2)

FromIO(xgbe2)

ToIO(xgbe1)

Programmable Control Plane

ofprotocoldpctl

tunnel

dpctl NOXController

Multi-Threaded Modular Programminge.g., Click Software Modular Router (multi-threaded)

•Arbitrary switch logic(s) can be implemented


Programmable Data Plane

20

Ethernet Switch

!

"#$

$#!

%#$

&!#!

&'()*+ "'()*+, -'()*+, .'()*+, $'()*+,

;#;;#;;#;;#;;#; ;#;;#;;#;

%#<

.#"

/012,34+5$&"6/012,34+5&$&.6

789/,:

!"#$%&'(")#

*%+,-./01.23$45

6+-./01.23$75

*%+,-./01.23$75

6+-./01.23$45

Switching PerformanceThe University of Tokyo Confidential

OpenFlow

OFSwitch

FromIO(xgbe1)

ToIO(xgbe2)

FromIO(xgbe2)

ToIO(xgbe1)

Data PlaneData Plane

Control Planeofprotocoldpctl

tunnel

dpctl NOXController

!

"#$

$#!

%#$

&!#!

&'()*+ "'()*+, -'()*+, .'()*+, $'()*+,

;#;;#;;#;

%#;

.#"

=#%

$#&-#<

"#%&#$

/012,34+5$&"6/012,34+5&$&.6

789/,:

Switching Performance21The University of Tokyo Confidential

What can we do with FLARE that others cannot doin a simple manner?


Multiple SDN Logics(OpenFlow 1.3 and OpenFlow 1.0)

23

FLARE2 1

GbE 10GbE

video client

video server

OpenFlow1.0

OpenFlow1.3

NOX1

NOX2

IPv6

VLCServer

IPv4

IPv6

IPv6video client

video client

video client

IPv4 IPv4

IPv6Client #1

IPv6Client #2

IPv4Client #1

IPv4Client #2


Multiple SDN Logics

24

Purpose: Dynamically changing SDN control logics for different flow spaces

Benefit:Instant upgrade/downgrade of switching softwareIncremental upgrade while keeping compatibility with old technologiesEnable “evolve-able” network architecture

Solution: FLARE can implement multiple SDN logics (southbound APIs) in slivers


Window-based Arbitrary Bit Matching

25

Arbitrary bit matching as in openflow pattern matcheris costly due to expensive memory operation per packet

!"#$%!

Set a window to minimize per-packet memory operationsImprove performance while keeping flexibility

Leon Lee, Ping Du and Akihiro Nakao, "Ouroboros: SDN Beyond Flow-Tuple Matching," IEICE NS Technical Report, Mar. 2013


http://pman.nakao-lab.org/cgi-bin/pman3/pman3.cgi?A=Leon%20Lee


http://pman.nakao-lab.org/cgi-bin/pman3/pman3.cgi?A=Akihiro%20Nakao


http://pman.nakao-lab.org/cgi-bin/pman3/pman3.cgi?D=129


26

Purpose: Specific Real-time audio/video traffic control, based on “stream”, not “flow”

(e.g. based on RTP SSRC field to enable routing according to the streaming-video IDs )

Benefit: Application/Content specific routing Solution: Use window to extract information included in RTP headers

"0$

!!"#$%&'(%)*+&,-..//

e.g., RTP-SSRC MatchingWindow-based Arbitrary Bit Matching


L7 Switching and In-Network Processing

27

FLARE

OFSW /RTP

OpenFlow Controller

OpenFlow /RTP

FLARE

Trans coder

FLARE Mux

Video Server

Video Client

L7 Switching

In-Network Processing

L7 Switching

FLARE supports deeply programmable SDN solutions such as arbitrary-bits and arbitrary offset matching and definition of proprietary APIs achieving both flexibility and performance

In-Network Processing

Video transcoding can be preformed in real time on either D-plane (many-cores processor) or C-plane (Intel-CPU).


28

Purpose: Device/application/content specific traffic engineering

Benefits: More specific recognition for packets bound to overly used TCP port (e.g., 80)Traffic engineering for data transmitted from specific devicesNetwork Virtualization for non-IP protocols!

&'

&'&'

100$

##23 ./

Solution:After attach/detach trailers, establish control in intermediate FLARE switches

e.g., Trailer MatchingWindow-based Arbitrary Bit Matching


29

Leon Lee, Ping Du and Akihiro Nakao, "Ouroboros: SDN Beyond Flow-Tuple Matching," IEICE NS Technical Report, Mar. 2013

Trailer is an extra section attached at the end of each packet

End/Edge nodes are responsible for attaching and detaching Trailers

1-%)-45************************************$%67-+*6(8+-8+*************************************************04%9'-4

(%)*+ (%)*,

$%67-+

$%67-+ /

$%67-+

/

!"#$%

$%67-+ / $%67-+ /

e.g., Trailer MatchingWindow-based Arbitrary Bit Matching








30

FLARE1 FLARE2

Network Virtualization with Trailer Slicing

FLARE1 FLARE2

!"#$$%&'$

�()�

�(*�

!+,-+,.)�!"#$$%&'$

-()/�

-(*/�

!+,-+,.*�

+0%12��(3�

�(4�

!+,-+,.3�+0%12� �(3�

!+,-+,.4�

5678$$%69:;<=>�

!+,-+,.?�

@A8>$B;9$

!+,-+,.C�

D51,+.)$ D51,+.*$

D51,+.3$ D51,+.4$

76E8=$F8:78:�

76E8=$GH68>I�

SERVER1 SERVER2

SERVER3SERVER4

SERVER5 SERVER6


Drastic Examples


DMAC (48bits)

Traditional Ethernet Frame: SMAC (48bits)SMAC (48bits)SMAC (48bits) Type IP PayLoad

DMAC (96bits)

Extended Ethernet Frame with Extended MAC: SMAC (96bits) Type IP PayLoad

Prototype with Click

FromDevice (tap0)

Strip(14) ExEtherEncapExEtherEncap

ExEtherSwitch

FromDevice (tap1)

Strip(14) ExEtherEncapExEtherEncap

ToDevice (tap0)

Strip(26) EtherEncap

ToDevice (tap1)

Strip(26) EtherEncap

ExEtherEncapExEtherEncap

ExEtherEncapExEtherEncap

L2 ProgrammabilityExtended (96bit) MAC switching



789/,:

Switch Performance

!

"#$

$#!

%#$

&!#!

&'()*+ "'()*+, -'()*+, .'()*+, $'()*+,

;#;;#;;#;;#;;#% ;#;;#;<#%

=#&

-#"

/012,34+5$&"6/012,34+5&$&.6

!.89:&'(")#

*%+,-./01.23$45

6+-./01.23$75

*%+,-./01.23$75

6+-./01.23$45


34

Purpose: •Demonstrating “Clean-Slate” programmability even for L2 protocols•Possibly alternative to VXLAN for mitigating MAC address exhaustion for supporting a large number of tenants in data center networks

Benefit:MAC address extension keeping transparence for IP applications

Solution: FLARE can literally provide “deep programmability” in data-plane, even in L2.



Non-IP protocol

35

FLARE

MF

FLARE

MF

GNRS

MF Sender

Mobility FirstUS Backbone

C-channel

D-channel XGB

FLARETestbed (Japan)

ProtoGENITestbed(US)

Mobility FirstNetworkIn Utah

GBE

Mobility First Network In Tokyo


36

Non-IP protocolPurpose:

Develop and operate Non-IP protocols over a network

Benefit:Enable non-IP protocol development for research community

Solution:FLARE can be used to program data-plane as well as control-plane for Non-IP protocols (that requires data-plane programming)


FLARE at ITPro EXPO 2012Beyond OpenFlow/SDN


MPLS 2012(with Cisco & Juniper)


IM2013 Keynote

39

iPoP 2013 Business SessionPlatinum Booth

40

!"#"$%&!'(&)'*'&+,'$-&

./0�

./1� ./2� ./3�

.� 0�

.� 0� .� 0� .� 0�

4/0�5"(-6&+76*&&

//1&+'*89&+'$-,&

./1

.

.

5�

5�5�

5�

5�

5"(-6&+76*&&

.� 0�0

0

./2

.

5"(-6&+76*&

0

5

./3

0

./3

.

5�5

!!"#�

$%&%'(#$)*#+,'-.,/#0/)'1#

2!3�

2!"� 2!4� 2!5�

5� 6�

2� 3� 7� 8� "� 2� 3�

8!3�9/:1#;<8"#=,.->#?+@A4B##

C�

4�

9/:1#;<8"#=,.->#?+@A4B##

2!"

2 3 7

2!4

8 " 4

9/:1#;<8"#=,.->#?+@A4B#9/:1#;<8"#=,.->#?+@A4B#9/:1#;<8"#=,.->#?+@A4B#

!!"#

5 6 C

2!5

2

D�

E�

E�E�

E�

2�

D�

E�

E+�

E�ED� <� F�

!!"##$3#DG#�

LivingLab @ NakaoLab

41

Living with Deeply Programmable FLARE


42

Conclusion• Deep Programmability refers to the extensive programmability including Control-plane, Data-plane (including non-IP handling), (re)defining APIs in SDN, etc.

• Deeply Programmable Network research encourages “clean-slate” thinking and redesigning the network and lifts the limitation in traditional networking and even in the current SDN

• Standardization on deep programmability within the network is yet to be done


Credits• FLARE Project Team @ UTokyo • Aki Nakao• Shu Yamamoto• Ryota Ozaki• Ping Du• Eiji Miyagaki• Haruki Denpo

• NICT & MIC for Funding the Project(s)


(Geneva, Switzerland, 4 June 2013) · • IETF BoF on Software Driven Networks (SDN) • IRTF BoF...

Documents

Transcript of (Geneva, Switzerland, 4 June 2013) · • IETF BoF on Software Driven Networks (SDN) • IRTF BoF...