Virtual Private LAN Service (VPLS) is an ONOS application that enables operators to create L2 broadcast overlay networks on-demand, on top of OpenFlow infrastructures.
The application connects into overlay broadcast networks hosts connected to the OpenFlow data plane.
In order to let VPLS establish connectivity between two or more hosts, different things need to happen:
A VPLS needs to be defined
At least two interfaces need to be configured in the ONOS interfaces configuration
At least two interfaces need to be associated to the VPLS
At least two hosts need to be connected to the OpenFlow network. The hosts should send in packets tagged with the same VLAN Id defined in the interface configuration
When conditions 1, 2 and 3 are satisfied, hosts attached to the VPLS will be able to send and receive broadcast traffic (i.e. ARP request messages). This is needed to make sure that all hosts get discovered properly, before establishing unicast communication.
When 4 gets satisfied - meaning that ONOS discovers as hosts with a MAC address and a VLAN Id, at least two of the hosts configured - unicast communication is established between the hosts discovered on that specific overlay network.
The VPLS workflow can be grouped in two main functions:
Getting information about configured interfaces, the VPLS configuration and the hosts attached
Installation of the related intents (so of the flows) to let the hosts communicate
Information collection is grouped in two main functions called in sequence, that represent the main steps that the application performs at each operational cycle:
getConfigCPoints(...): it parses the ONOS interfaces configuration, looking for two or more attachment points with interfaces configured with the same VLAN Id and with no IP addresses configured. Looking for interfaces without an IP addresses means looking for pure Layer 2 interfaces and it’s done to don’t conflict with Layer 3 ONOS applications that use the same configuration mechanism. The interfaces found are grouped by VLAN Id (in a HashMap) and returned to the next method, pairAvailableHosts(...).
pairAvailableHosts(...): it parses (if not null) the data structure received from getConfigCPoints(...) and for each interface found finds hosts in the Host Service matching with the interfaces configured. If hosts are found, the original data structure is modified: the MAC addresses of the hosts found is bound to the related interfaces discovered in the configuration. The final data structure is then returned.
VPLS relies the intent framework has a stand-alone component called Intent Installer. Intent Installer analyzes the data returned by pairAvailableHosts and creates the intent installation requests. VPLS installs:
Single-Point to Multi-Point intents for broadcast traffic, from any ingress point to every egress point, configured in the same VPLS.
Multi-Point to Single-Point intents for unicast traffic, from every egress point to any ingress point in the same VPLS.
Functions above are grouped in a unique method called setupConnectivity(...). The method is called
At the application startup;
Every time the interface configuration or VPLS configuration get updated;
As soon as new hosts join the network and get discovered.
VPLS has listeners for three event types:
Interface configuration updates: each time a node in the interface configuration is added, updated or deleted, for example pushing the network-cfg.json file or through CLI. The Interface configuration is filtered to consider only the interfaces with VLANs configured, but not IP.
VPLS configuration updates: each time a node in the VPLS configuration is added or updated or deleted, for example pushing the network-cfg.json file or through CLI.
Host added / Host updated: each time a host joins the network, meaning a new host gets physically connected to the OpenFlow data plane and starts sending ARP packets into the network. The Host Service will discover the host (with a MAC address, a VLAN, and possibly one or more IP addresses). VPLS listens for Host added / updated / removed events and filters hosts that are attached to the OpenFlow switches, and use VLANs, according to what has been configured in the interfaces section.
The Intent Framework is used to provision both broadcast and unicast connectivity between the edge ports of the OpenFlow network, where hosts are attached to. Using the Intent Framework abstraction allows to mask the complexity of provisioning single flows on each switch and error recovering in case failures happen.
Broadcast connectivity is provisioned through single-point to multi-point intents. Within the same VPLS, for each host (source of the broadcast traffic), a single-point to multi-point intent is installed.
The (single) ingress point of each intent is the edge port where the source host (for that intent) is connected to. The egress points are any other edge port where destination hosts associated to the same VPLS, are connected to.
The intent ingress selector is defined using the edge in-port, the destination MAC address FF:FF:FF:FF:FF:FF (broadcast Ethernet address) and the VLAN Id of the source host, according to what has been defined in the interface configuration. The egress selectors are defined as the ingress selector (broadcast Ethernet address), but with the VLAN Id of the destination hosts. The intent framework automatically performs the VLAN Id translation at the egress, before the traffic is sent to the destination hosts. The traffic is carried through the best-path - according to the PCE installed - to all the edge ports associated to the same VPLS.
Assuming N edge ports have interfaces associated to the same VPLS, N single-point to multi-point intents for broadcast will be installed.
Intents for Broadcast traffic get generated, regardless the hosts have been discovered or not. This is done since often hosts won’t be able to send traffic into the network (so get discovered by the Host Service) before ARP requests reach them and they reply to them with an ARP reply.
Unicast connectivity is provisioned through multi-point to single-point intents. Within the same VPLS, for each host (destination of the unicast traffic), a multi-point to single-point intent is installed.
The egress point of each intent is the edge port where the destination host is connected to. The ingress points are any other edge ports where the source hosts associated to the same VPLS, are connected to.
At each ingress, the intent ingress selector is defined using the edge in-port, the MAC address of the destination host, and the VLAN Id of the source host, according to what has been defined in the interface configuration. The egress selector is defined as the ingress selectors (matching on the destination MAC address), but with the VLAN Id of the destination host. The intent framework automatically performs the VLAN Id translation at the ingress, before the traffic is sent through the core. The traffic is carried through the best-path - according to the PCE installed - to all the edge ports associated to the same VPLS.
Assuming N edge ports have interfaces associated to the same VPLS, N multi-point to single-point intents for unicast will be installed.
Intents for Unicast traffic get generated only if:
Two or more interfaces (with a VLAN Id configured and with no IPs) are configured and associated to the same VPLS;
Two or more hosts attached to the interfaces configured send packets into the network and get discovered by the Host Service,
The reason for the second condition is that intents for unicast (see above) match on the MAC address of the hosts connected, which is doesn’t get configured by the operator, but instead provided by the host service after the host gets discovered.
VPLS runs on top of ONOS as a distributed application: each ONOS instance has a VPLS application running on top of it. VPLS applications share their status and use common data structures. ONOS makes sure they remain in synch.
The intentInstaller component prepares the intent requests, to be submitted to the external IntentSynchronizer component. IntentSynchronizer makes sure that only one ONOS instance at the time is elected as the leader for VPLS and takes care of installing in the system the intents needed by VPLS to provision the connectivity.
If an ONOS instance fails because of issues, another ONOS instance is re-elected leader for VPLS and takes over for the intent installation process.
At the present stage:
Only VLAN tags can be used, no MPLS;
Hosts need to send into the network tagged traffic. “Access” or “untagged” ports are currently not supported;
Single-point to multi-point intents and multi-point to single-point intents still don’t support encapsulation. Traffic cannot be encapsulated through the core;
