Transcript APAN201202_FlowSpace_yamanaka

Flow Space Virtualization on Shared
Physical OpenFlow Networks
Hiroaki Yamanaka, Shuji Ishii, Eiji Kawai (NICT),
Masayoshi Shimamura, Katsuyoshi Iida (TITECH),
and Masato Tsuru (Kyutech)
Background
• Diverse requirements to networks for application
services
– Network resources for application-specific
performance
– Functions of in-network processing
• Clean-slate network technology design
– Network programmability
– Testbed for spiral development
– OpenFlow is one of key technologies for flexible
routing
What OpenFlow is
• Decoupling control and data planes
Data plane;
Switches forward
packets according to
flow tables
Control plane：
A controller injects flow
tables for each switch
A controller
• Flexible routing
OpenFlow
protocol
OpenFlow networks
– Flow is defined using flow space, ingress port and L2-L4
packet headers (flow space).
– Dynamic path setting for arbitrary fine-grained flows
OpenFlow Testbed
• Testbed users’ OpenFlow-enabled networks
for experiments
– Connecting testbed user’s end-hosts to the
network
– Controlling the network by a testbed user’s
controller
• Resources of the experiments networks are
provided by testbed infrastructure providers,
e.g., JGN-X, GENI, and OFELLIA .
Virtual OpenFlow Networks
• Requirements
– Testbed infrastructure providers: Efficient use of physical
resources
– Testbed users: Use of customized experiment networks
• Building experiment networks as virtual OpenFlow
networks on physical OpenFlow networks
– Sharing physical resources by multi-testbed
users→efficiency
– Software defined networks→customization
The Gap between Virtual and Physical
OpenFlow Networks
• Virtual OpenFlow networks: customizable for testbed users
– Local flow space
• Local addressing in virtual OpenFlow networks
• Content centric networks using IP address as a name of content
– Local network topology
• Easy-to-manage topology for a testbed user’s experiments
gap
• Physical OpenFlow networks: manageability for testbed
infrastructure providers
– Regulated flow space
• Physical network addressing for easy-to-operate
• E.g., in-network processing hosts’ IP addresses
– Physical topology
• Depending on physical configuration
Existent Virtualization Mechanism
• Links and OpenFlow
switches of subgraph
• Just assigned flow space
• FlowVisor
Exp. NW 1
OpenFlow
controller of
testbed user 1
Access control
between slice
controllers and
physical switches
OpenFlow
controller of
testbed user 2
OpenFlow
protocol
FlowVisor
module
• Issues for testbed users
Exp. NW 2
OpenFlow
protocol
Physical
OpenFlow
networks
The customizability
for testbed users
is limited.
– Flow space: not allowed collision among distinct experiment networks
– Experiment network topology: just subgraph of physical networks
Proposal
• Supporting virtual OpenFlow network topology
independent from physical OpenFlow networks
– Name space mapping (data path id, link id)
– Links aggregation, nodes integration
• Allowing collision of flow space among virtual
OpenFlow networks
– Rewriting flow space for controllers and end-hosts of
virtual OpenFlow networks
Reference Providers Model
• 3 providers model
– Testbed user: Service Provider (SP)
– Testbed infrastructure provider: Infrastructure Provider (InP)
Our proposal :
– Mediator: Virtual Network Provider (VNP)
• The VNP’s functions:
– Resource brokering between SPs and InPs
An implementation for
customizable virtual
OpenFlow networks
• Conflict of resources requests from SPs are adjusted by a VNP.
– Mapping resources between physical networks and virtual networks
– Providing interfaces for both SPs and InPs
• Applicable to:
– Cross-domain testbed federation
– Network virtualization on the Internet with heterogenous SPs and InPs
Data Plane Model
Virtual Network of SP 2
SP (testbed user)
Virtual Network of SP 1
Virtual OpenFlow
network with
local flow space
and topology
Virtual Network of SP 3
VNP
Topology and
flow space
mapping
Middle Virtual
Network (MVN)
of VNP1
Resource pool with
abstracted topology of
physical OpenFlow
networks
InP
Resource
abstraction for
InP’s security
Physical switches
and links
Physical OpenFlow
network of InP1
Physical OpenFlow
network of InP 2
Control Plane Model
SP (testbed user)’s controller
•
Flow tables for logical OpenFlow switches
in the logical OpenFlow network
Referencing the local flow space and the
topology
•
Control messages, packet-in,
statistics for a virtual
OpenFlow network
VNP’s controller
•
•
Control messages,
packet-in, statistics
for the MVN
Transforming the message
from SP to fit the MVN
The mapping between the
slice and the MVN is
referenced.
InP’ controller
•
•
Transforming the message from
VNP to fit the physical
OpenFlow network
Mapping between MVN and
physical OpenFlow network is
references.
OpenFlow
protocol
Physical
OpenFlow
switches
Proposal: Independent Topology of
Virtual OpenFlow Networks
SP (testbed user)
SP’s OpenFlow
controller
Virtual OpenFlow networks
VNP
Interface to control virtual OpenFlow networks nodes and links
VNP’s controller
InP
Managing the
topology mapping*
between MVN and
virtual OpenFlow
network
Interface to control MVN nodes and links
InP’s controller
MVN
Managing the topology
mapping* between
physical OpenFlow
network and MVN
Physical OpenFlow networks
* All possible mappings (hiding, aggregation, slicing) are supported.
Proposal: Flow Space Virtualization for
Testbed User Controllers
SP (testbed user) 1’s OpenFlow controller
Ingre
ss
Port
Ether
src
Ether
dst
…
IPv4
src
SP (testbed user) 2’s OpenFlow controller
TCP/
UDP/
SCTP
src
port
IPv4
dst
TCP/
UDP/
SCTP
dst
port
Ingre
ss
Port
Ether
src
Ether
dst
…
IPv4
src
IPv4
dst
TCP/
UDP/
SCTP
src
port
TCP/
UDP/
SCTP
dst
port
Rewriting: SP local flow space⇔SP allocated flow space
• Port and packet header in packet-in messages
• Port and packet header in injecting flow tables
Ingress
Port
VNP
Flow space
allocation for
SP 1
InP’s controller
Ether src
Ether
dst
…
IPv4 src
IPv4 dst
TCP/UD
P/SCTP
src port
TCP/UD
P/SCTP
dst port
TCP/UD
P/SCTP
src port
TCP/UD
P/SCTP
dst port
Flow space allocation information
Ingress
Port
Flow space
allocation for
SP 2
Ether src
Ether
dst
…
IPv4 src
IPv4 dst
InP divisions packet header space and
allocates to each SP for management.
Proposal: Flow Space Virtualization for
End-hosts
SP
SP1’s virtual OpenFlow network
SP 2’s virtual
OpenFlow network
VNP
InP
Always sending
packets with SP1local headers
An edge switch
•
•
Identifying the end-host’s
belonging SP by the ingress
port or the MAC address
Rewriting to be the allocated
header on physical networks
An Initial Prototype
An SP’s OpenFlow
controller
A module for SP (testbed user)
A Virtual OpenFlow network
OpenFlow message for the
virtual OpenFlow network
A module of VNP
DB
OpenFlow message
for MVN
A module of InP
An InP can manage flow
space easily though SPs’
customization.
An SP (testbed user)
can control his/her
customized slice by only
referencing the slice.
DB
Mapping the topologies and
packet-header MVN and SPs’
virtual OpenFlow networks
MVN
An end-host only
uses SP-local
packet-headers.
Mapping the topologies
of InP and VNP
Physical OpenFlow network
An switch for
end-hosts
packet headers
rewriting
An end-host
Future Plan
• Detailed design of flow space allocation
management
• Demonstration experiments on JGN-X
Summary
• An OpenFlow testbed is important for cleanslate network architecture design.
• Proposal of customized virtual OpenFlow
networks on shared physical OpenFlow
networks
– Enabling virtual OpenFlow network-local topology
and flow space
• An initial prototype
Thank you!
Q&A