DRAFT
1. What is this for?
This document is intended to describe how inter connections between virtual networks will be achieved. We want to support scenarios where virtual networks are allowed to talk to each other.
1.1. Restrictions and Limitations
Virtual network which want to talk to each other will have to use disjoint IP subnets, while this is not a technical requirement, it maintains a level of sanity wothin the system and avoids confusions when referring to services within virtual networks by IP.
Currently each virtual address is translated into a physical address in each virtual network. By naively allowing virtual networks to communicate, a virtual network may consume N physical addresses where N is the number of virtual networks it talks to. This is not desirable because is large systems we may run out of physical addresses in a virtual network and therefore make communication impossible. Therefore, the idea is to allocate a physical IP which is internal to OVX only (a dom0 IP). This IP would then be used in each virtual network and not consume the physical IP space of the VN.
1.2. Libraries/Components Used
- OVXNetwork
- OVXBigSwitch
1.3. Terminology
- dom0 – A special virtual network used to interconnect other virtual networks. dom0’s controller is OVX and is actually a virtual network with tenant id 0 and a single bigswitch implementing it.
2. Implementation
The implementation will be split in three big parts.
- dom0 implementation
- Gateway port spawning
- Handling of messages at borders of dom0
2.1. General Approach
The diagram below attempts to explain the general approach used to implement VN inter connectivity.
In the diagram above switches are represented by circles and gateway ports by squares. Virtual Network 0 (dom0) is the OVX special network controlled by OVX. When gateways are specified in the virtual networks the virtual port is actually created in the virtual network but the virtual to physical mapping is maintained in dom0. Then as virtual networks are connected to each other OVX provision a route between the gateway ports in the bigswitch that makes up dom0. This implementation will allow us to reuse many existing OVX features without having to add any significant amount of code. Basically, as soon as OVX sees an output or input port which is referring a gateway port, ovx adds the appropriate actions to either funnel traffic into the route or out of the route and into the correct virtual network.
2.2. dom0 Implementation
Dom0 is a subclass of OVXNetwork. It’s tenant id is 0. Most methods will remain unchanged, the ones listed below will have their behaviour changed.
OVXMap changes
The OVXMap needs to be changed such that lists are changed to sets where appropriate. This will make adding switchs to a bigswitch dynamically much easier because we do not need to check whether the switch already exists in the list or not.
public Set<String> getControllerUrls()
Returns null, dom0 will not have any controller because it’s controller is OVX.
public OVXSwitch createSwitch(final List<Long> dpids, final long switchId)
Does nothing as dom0 is only a single giant switch.
public OVXPort createPort(final long physicalDpid, final short portNumber, final short… vportNumber)
Behaviour should be roughly the same but this will only be called when a gateway is requested from a virtual network.
public RoutingAlgorithms setOVXBigSwitchRouting(final long dpid, final String alg, final byte numBackups)
Always return SPF.
public Host connectHost(final long ovxDpid, final short ovxPort, final MACAddress mac, final int hostId)
No hosts will be connected to this switch so this does nothing and really should never be called. SHould probably return an Exception.
public synchronized OVXLink connectLink(final long ovxSrcDpid, final short ovxSrcPort, final long ovxDstDpid, final short ovxDstPort, final String alg, final byte numBackups, final int linkId)
No virtual links will exist in dom0, this should return an exception
public synchronized OVXLink setLinkPath(final int linkId, final List<PhysicalLink> physicalLinks, final byte priority)
No links means no paths for them. Do nothing.
public synchronized SwitchRoute connectRoute(final long ovxDpid, final short ovxSrcPort, final short ovxDstPort, final List<PhysicalLink> physicalLinks, final byte priority, final int… routeId)
Nothing to be done here as you cannot specify routes in the dom0 bigswitch
public synchronized void disconnectHost(final int hostId)
No hosts so do nothing.
public synchronized void disconnectLink(final int linkId)
No virtual links so do nothing
public synchronized void disconnectRoute(final long ovxDpid, final int routeId)
When a gateway from a virtual network is removed then the associated route(s) should be removed.
public synchronized void {start, stop}Switch(final long ovxDpid)
Dom0 will only have a single switch which will be started when ovx boots up and stopped when ovx shuts down. So these methods should do nothing publicly.
public synchronized void {stop, start}Port(final long ovxDpid, final short ovxPort)
Ports of the big switch may be stopped when the corresponding virtual network is stopped or paused.
public synchronized void handleLLDP(…)
No lldps so do nothing.