TSM-ClComp-EN Cloud Computing
NET - Network Resource Virtualization
Prof. Dr. Thomas M. Bohnert
Christof Marti
TSM-ClComp-EN Cloud ComputingSources: Google,
Data Centers: Some Impressions
TSM-ClComp-EN Cloud Computing
Source: Facebook, Open Compute Project, DataCenterDynamics
Data Center Layout
TSM-ClComp-EN Cloud Computing
Connecting Sites
Internet Internet
Connecting Racks
Source: CISCO
DC Topology
TSM-ClComp-EN Cloud Computing
● Link Aggregation (LAG)
● Requires Capacity Over-
Subscription
● Fault Tolerance
● Equal Cost Multi-Pathing
(ECMP)
● Rack-to-Rack
● Inefficient, no direct Link
● L2 Broadcast Domains
● Storms
● Spanning Tree
● Convergence, Blocked Links
Source: CISCO
Network Architecture - DC Internal
TSM-ClComp-EN Cloud Computing
Source: NICIRA/VMWare
Virtual Networking
TSM-ClComp-EN Cloud Computing
● Networks in Data Centers exist at all sizes
● Networks in Data Centers are typically
− Internally or externally oriented
− Hierarchical
− Complex
− Static
● Does this hold for DCs that host Cloud Computing Services?
DC Networking Summary
TSM-ClComp-EN Cloud Computing
● The physical network end-to-end (DC-internal and potentially external)
becomes a shared resources
− Need for multi-tenancy support
● Different tenants do share the same links
− Need for isolation
● Tenants require a flexible network
− Self-Service interface
− On-demand instantiation and release
− Scale according to demand
− Quality of Service support
− Pay-as-you-go
Nature of Cloud Networking
TSM-ClComp-EN Cloud Computing
● Private Cloud scenario
− E.g. enterprise or campus
environment
● Full connectivity
− All participants can
communicate with each other
(flat hierarchy)
− Tenant (owner) of each virtual
machine (service) may be
different
− External connectivity via Router
Flat Networking
TSM-ClComp-EN Cloud Computing
● An enterprise or campus network with
private and public domains
− Networks for dedicated service-inter-
dependencies
− Replication or multi-master
configuration of services possible over
a private network
− Examples
● OpenLDAP need Kerberos
● OpenLDAP is replicated over
multiple machines
● Webserver and Database
Flat and Private Network
TSM-ClComp-EN Cloud Computing
● Public clouds hosting multiple tenants
● Tenants with multi-network requirements
● Tenants requires control over own
network topology
● Example
− Enterprise Customer (IT department)
that migrates the IT infrastructure to
the cloud
− Creates servers/services on demand
for his own customers (business
units)
Multi-Tenant and Multi-tier Architecture
TSM-ClComp-EN Cloud Computing
● Cloud Computing
− Is defined by Cloud Computing Principles, see Lecture CCI
− On-demand, self-service, elasticity, etc
− Infrastructure-as-a-Service (Network, Storage, Compute)
● IaaS means, that “network services” must be offered to tenants “aaS”
− The general term for this is Network as a Service “NaaS”
− In various configurations/architectures
− For various deployment scenarios, public, private, hybrid cloud
● Technologies to achieve this goals exist ...
− VALN/VXLAN for isolation, (G)MPLS for site-to-site connectivity, GRE for
tunneling
− … but non of them was designed for Cloud Computing; limited, complex,
error prone, expensive
Cloud Networks Summary
TSM-ClComp-EN Cloud Computing
Software Defined Networking
● (Great) Idea:
○ Unbundle Software from
Hardware
○ Individual logic on top of
generic devices
● Not new at all
○ Laptop HW
○ Linux or Windows?
● Popular and similar projects
in the networking domain
○ OpenWRT
TSM-ClComp-EN Cloud Computing
● Software Defined Networking is not a technology
− it's a paradigm shift
− “programming” network behavior, instead of “configuring”
− Central control vs distributed control
● Definition (one)
− SDN is about separation of “Control Plane” and “Data Plane”
● An “SDN Controller”
− is the executing environment of the programmable network logic
− pushes logic into devices over a specific protocol
● SDN-enabled devices are plain packet forwarding devices
− No control logic, minimal firmware for basic operations
● The original and purest SDN-enabling protocol is OpenFlow (OF)
− Generic and flexible, implements Cloud Networking natively
SDN - Software Defined Networking
TSM-ClComp-EN Cloud Computing
● In packet switching networks, traffic flow, packet flow or
network flow is a sequence of packets from a source
computer to a destination, which may be another host, a
multicast group, or a broadcast domain.
● In TCP/IP a flow can be uniquely identified by the
following parameters and within a certain period of time:
− Source and Destination IP address
− Source and Destination Port
− Layer 4 Protocol (TCP/UDP/ICMP)
OF - Flow Definition
TSM-ClComp-EN Cloud Computing
● Packet: a series of bytes comprising a header, a payload and optionally a trailer, in
that order, and treated as a unit for purposes of processing and forwarding. The
default packet type is Ethernet, other packet types are also supported
● Flow Table: Contains flow entries.
● Flow Entry (Flow): an element in a flow table used to match and process packets. It
contains a set of match fields for matching packets, a priority for matching
precedence, a set of counters to track packets, and a set of instructions to apply.
● Forwarding: Deciding the output port or set of output ports for a packet, and
transferring that packet to those output ports.
● Instruction: instructions are attached to a flow entry and describe the OpenFlow
processing that happens when a packet matches the flow entry. An instruction either
modifies pipeline processing, such as directing the packet to another flow table, or
contains a set of actions to add to the action set, or contains a list of actions to apply
immediately to the packet
OF - Flow-related Definitions
TSM-ClComp-EN Cloud Computing
● A Datapath consists of:− An Pipeline, which is made of
one or more Flow Tables
− Exactly one Group Table
− Ingress and Egress Ports
− A channel to the Controller
OF - The Datapath
TSM-ClComp-EN Cloud Computing
● OpenFlow ports are defined as
− physical, local, logical
● Physical port
− is a one-to-one mapping to physical interfaces
● Local port
− is a port that can be defined by the switch using non-openflow method
● Logical port
− are reserved OpenFlow ports
− ALL: is the port that represents all ports on the device
− CONTROLLER: is the port, representing the controller connected
− IN_PORT: is the port where the packet arrived, either physical or local
− ANY: Special case for wildcard ports in some OFP commands
OF - Ports
TSM-ClComp-EN Cloud Computing
● OpenFlow devices do have a Pipelining Process
− OpenFlow only: Packets are forwarded along the OF pipelining
process
− OpenFlow hybrid: Such devices support an attribute to decide, if
a packet is forwarded along the OF pipeline or not
● Example: OpenVSwitch
− OpenvSwitch can be configured for hybrid mode
− Generally, packets are handled by the OF-enabled pipeline and
according to the rules imposed by the controller
− Fallback mode is enabled in case the controller is unavailable,
which means default device logic is used (configurable)
OF - Pipeline
TSM-ClComp-EN Cloud Computing
OF - Pipelining and FlowTables
TSM-ClComp-EN Cloud Computing
● Packets are scanned for
predefined patterns - aka
match-fields
● match-fields relate to ISO
Reference Model Layer 2-4
● Pure SDN philosophy even
allows for “any” pattern
OF - Flow Matching
TSM-ClComp-EN Cloud Computing
OF - Matching and Actions
TSM-ClComp-EN Cloud Computing
● Each FlowTable entry has one or more Instructions
assigned
− Instructions define the Packet Actions Set and/or the
pipelining
● Write-Actions: Merges the actions through the pipelining into
the action set
● Clear-Actions: Clears all actions in the set immediately
● Meter: Assigns a specific meter to a packet
● GOTO-Table: Indicates the next table in the pipelining
process
● Write-Metadata: Writes additional metadata for processing in
other tables into the packet
OF - Actions
TSM-ClComp-EN Cloud Computing
● To set an action on a packet, the Write-Actions Instruction is used
● Not all Write-Actions are required by the standard, only those flaged as
“Required” (R)
● Output port_no (R): sends the packet out on the specified port
● Drop (R): Drops the packet. This action doesn't exist explicitly, if no action
is assigned to the packet, it will be dropped
● Group group_id (R): Sends out the packet to the group table for further
processing
● Push-Tag/Pop-Tag: Used for pushing MPLS or VLAN header onto the
packet
● Set-Field: Is used to set or update a field in any header that is already there
like IP, TCP or Ethernet
OF - Write Actions
TSM-ClComp-EN Cloud Computing
1: cookie=0x0, duration=180952.219s, table=1, n_packets=20, n_bytes=2008, priority=10, dl_vlan=2, actions=goto_table:22: cookie=0x0, duration=180952.220s, table=1, n_packets=15, n_bytes=2008, priority=10, dl_vlan=1, actions=goto_table:33: cookie=0x0, duration=180952.223s, table=1, n_packets=4, n_bytes=2008, priority=0, actions=drop4: cookie=0x0, duration=180952.224s, table=2, n_packets=2, n_bytes=2008, priority=10, dl_dst=fa:16:3e:95:6d:05, actions=output:15: cookie=0x0, duration=180952.250s, table=2, n_packets=12, n_bytes=2008, priority=10, dl_dst=fa:16:3e:6a:b4:00,
actions=output:26: cookie=0x0, duration=180894.656s, table=2, n_packets=3, n_bytes=1454, priority=10, dl_dst=ff:ff:ff:ff:ff:ff
actions=output:2,output:17: cookie=0x0, duration=180952.419s, table=2, n_packets=3, n_bytes=2008, priority=0, actions=drop8: cookie=0x0, duration=180972.209s, table=3, n_packets=12, n_bytes=2008, priority=10, dl_dst=fa:16:3e:c7:3d:40,
actions=output:39: cookie=0x0, duration=180994.346s, table=3, n_packets=2, n_bytes=1454, priority=10, dl_dst=ff:ff:ff:ff:ff:ff actions=output:310: cookie=0x0, duration=180992.919s, table=3, n_packets=1, n_bytes=2008, priority=0, actions=drop
I: Source MAC fa:16:3e:c7:3d:40, destination MAC fa:16:3e:95:6d:05, and VLAN ID = 1 → matching flows [line 2, 10]II: ARP message is sent from the host with the MAC address fa:16:3e:6a:b4:00 and is tagged with VLAN ID = 2. → matching flows [line 1, 6]
Example of Matching in FlowTables
TSM-ClComp-EN Cloud Computing
● Each Meter has one or more MeterBands assigned to it
− The Meter applies the MeterBand with the highest configured rate that
is lower than the current measured rate.
− If the current rate is lower than any specified meter band rate, no meter
band is applied.
● Each meter band is identified by a set of associated conditions
− rate: defines the lowest rate at which the band can apply
− band type: defines how packets are processed
− counters: updated when packets are processed by a meter band
− type specific arguments: some band types have optional arguments
● The DropMeter is the most supported band type
− Traffic Policing
− Quality of Service
OF - MeterBands
TSM-ClComp-EN Cloud Computing
SDN Controller
OpenStack and SDN
TSM-ClComp-EN Cloud Computing
OpenStack Local Virtual Networking
TSM-ClComp-EN Cloud Computing
POST v2.0/networks.json
Content-Type: application/json
Accept: application/json
{
"network":
{
"name": "sample_network",
"admin_state_up": false
}
}
'status': '201'
'content-length': '194'
'content-type': 'application/json;
{
"network":
{
...
"name": "sample_network",
"tenant_id":4d48804aad5d39c61b8f",
"id": “b-4b4f-bd82-94ec81110766"
}
}
OpenStack REST-call “Create Network”
TSM-ClComp-EN Cloud Computing
POST /v2.0/ports.json HTTP/1.1
Content-Length: 158
content-type: application/json
accept: application/json
{
"port": {
"admin_state_up": true,
"device_id":1493dd9dadc0",
"name": "port1",
"network_id": af36412f12"
}
}
Status: 201
Content-Type: application/json; charset=UTF-8
Content-Length: 410
{
"port": {
"admin_state_up": true,
"device_id": "d6b4d3a5-c700-476f-b609-1493dd9dadc0",
"device_owner": "",
"fixed_ips": [
{
"ip_address": "192.168.111.4",
"subnet_id": “44fc2-4ffb-4de4-b0f9-69d58b37ae27"
}
],
"id": "ebe69f1e-bc26-4db5-bed0-c0afb4afe3db",
"mac_address": "fa:16:3e:a6:50:c1",
"name": "port1",
"network_id": "6aeaf34a-c482-4bd3-9dc3-7faf36412f12",
"status": "ACTIVE",
"tenant_id": "cf1a5775e766426cb1968766d0191908"
}
}
OpenStack REST-call “Create Port”
TSM-ClComp-EN Cloud Computing
SDN Technology - OpenDaylight
TSM-ClComp-EN Cloud Computing
● OpenDayLight (ODL) is a community-driven, open-source software
defined networking framework.
− Supports different “Southbound” protocols
− OVSDB, OpenFlow, SNMP, etc
● ODL controls virtual bridges on compute nodes
− VM on compute node connects over this bridge to the physical
network
● ODL needs an intelligent bridge
− OpenvSwitch (OVS) is an OSS virtual and intelligent bridge
− bridge (switch) supporting two protocols: OpenFlow and OVSDB
− OVSDB is an OpenvSwitch only protocol and works over JSON-RPC
− Native support for isolation, live migration, and QoS
OpenStack and OpenDaylight
TSM-ClComp-EN Cloud Computing
● Java - cross-platform execution; Maven - easy build
● OSGi - dynamic bundles load; register dependencies
and services; information exchange across bundles
● Karaf – OSGI based runtime; provides container for
deploying components and apps
● Java Interfaces - event listening, specifications and
forming patterns
OpenDaylight: Java, Maven, OSGi, Karaf
TSM-ClComp-EN Cloud Computing
● The creation of an Instance means creating a Neutron Port
● Port creation is performed by the SDN controller using OVSDB as
tool to communicate with the Compute Node local OpenVSwitch
● Neutron Port is a virtual Port on the intelligent bridge (OVS)
− A VM Instance is bridged by the hypervisor to that port
● ODL imposes tenant isolation based on the preferred virtualization
protocol
− MAC-based, VLAN-based, or GRE-based
● The Port status is monitored by the SDN Controller via OpenFlow
OpenStack, ODL, OVS: VM Instance creation
TSM-ClComp-EN Cloud Computing
● Neutron server manages
network associations
− Key value pair
− <Net-UUID, VLAN ID or
GRE Tunnel>
● Neutron ML2 plugin calls ODL
north-bound REST interface
for network configurations
● ODL talks to OpenvSwitch
directly over OpenFlow and
OVSDB south-bound plugin
SDN Controller
OpenDaylight and OpenStack
TSM-ClComp-EN Cloud Computing
Annex
36
TSM-ClComp-EN Cloud Computing
ODL - Feautures
37
TSM-ClComp-EN Cloud Computing
ODL - Features
38
TSM-ClComp-EN Cloud Computing
ODL - Application Creation Workflow
39
TSM-ClComp-EN Cloud Computinghttps://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:L2_Switch
PacketHandler examines Ethernet packets to
find information about Mac-Port pairings.
AddressTracker stores the Mac-Port pairings
in the MD-SAL data tree.
InventoryService provides information about
the nodes and node connectors in the network.
FlowWriterService adds packet forwarding
(mac-to-mac) flows to the MD-SAL data tree.
TopologyLinkDataChangeHandler listens to
topology updates and informs
NetworkGraphDijkstra of these updates.
NetworkGraphDijkstra maintains the network
graph and computes the shortest path between
each node.
ODL - Packet Processing
40