Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Overview
Virtual Private LAN Service (VPLS) is an ONOS application that allows the creation of enables operators to create L2 broadcast overlay networks on-demand, on top of OpenFlow infrastructures.
The application connects into overlay broadcast network networks hosts connected to the OpenFlow data plane, sharing the same VLAN Id.
...
In order to let VPLS establish connectivity between two or more hosts, two different things need to happen:
A VPLS needs to be defined
At least two interfaces
with the same VLAN Id 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 gets , 2 and 3 are satisfied, any host a) hosts attached to the ports where the interfaces have been configured, b) sending in traffic using the same VLAN that has been configured, VPLS will be able to send in and receive broadcast traffic (i.e. ARP requests) to the other hosts in the same overlay networkrequest messages). This is needed to make sure that all hosts get discovered properly, before establishing unicast communication.
When 1 and 2 get 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:
Collect Getting information about configured interfaces, the VPLS configuration and the hosts attached
Install Installation of the related intents (so of the flows needed ) to let the hosts communicate
Information collection
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.
Intent installation
VPLS relies the intent framework has a stand-alone component called Intent Installer. Intent Installer analyzes the data structure 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 VLANVPLS.
Multi-Point to Single-Point intents for unicast traffic, from every egress point to any ingress point in the same VLANVPLS.
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 gets get updated;
As soon as new hosts join the network and get discovered.
Configuration and Host listeners
VPLS has listeners for two three event types:
Interface configuration updates: each time a node in the interface configuartion configuration is added, updated or deleted, for example pushing the network-cfg.json file or through CLI. Interfaces The Interface configuration is filtered to consider only the interfaces with VLANs configured, but not IP. Also, informations are considered by VPLS, only if two or more interfaces are correctly configured, using the same VLAN Id
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 get gets physically connected to the OpenFlow data plane and start to send in starts sending ARP packets into the network ARP packets. The Host Service will discover the host (with a MAC address, possiblly a VLAN, and possibly one or more IP addresses). VPLS listens for Host added / updated / removed events and filters hosts that are attached to attachment pointsthe OpenFlow switches, and use VLANs, according to what has been configured in the interfaces section..
Traffic provisioning and intent requests
The ONOS 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 failover error recovering in case failures happen.
Broadcast traffic: single-point to multi-point intents
Broadcast connectivity is provisioned through single-point to multi-point intents. Within the same VLANVPLS, for each host (source of the broadcast traffic), a single-point to multi-point intent is installed.
The (single) ingress point intent is instantiated.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 Intents match on destination MAC address FF:FF:FF:FF:FF:FF (broadcast Ethernet address) and on 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 shared by the overlay network. As treatment, the traffic is 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 other edge ports configured associated to use the same VLAN Id.The (single) ingress point of each intent is the edge port where the soruce hosts (for that intent) is connected to. The egress point is any other edge port where destination hosts (for that intent) with the same VLAN Id, are connected tothe same VPLS.
Assuming N edge ports have interfaces configured within associated to the same VLAN IdVPLS, N single-point to multi-point intents for broadcast will be installed.
Intents for Broadcast traffic get generated, reguardless 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 VLANVPLS, for each host (destination of the unicast traffic), a multi-point to single-point intent is instantiatedinstalled.
Intents match on unicast destination MAC of the source host and on the VLAN Id shared by the overlay network. As treatment, the traffic is carried through the best-path to the source edge port.
The (multiple) ingress points of each intent are the 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 destination hosts (for that intent) source hosts associated to the same VPLS, are connected to. The egress point is the source edge port where the source host (for that intent) within the same VLAN Id, is 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 configured within associated to the same VLAN Id and N related hosts have been discovered 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 sharing the same (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 packet packets into the network sharing the same VLAN Id and on through the physical ports (configured above), and get discovered by the ONOS 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.
Intent Installation, synchronization and leader election
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.
Current Limitations
At the present stage:
...
Only VLAN tags can be used, no MPLS;
Hosts need to send into the network tagged traffic. The application won’t let switches tag the switches automatically tag the traffic at the edge (edge ports act as trunk ports, not as access ports)“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 incapsulated through the core in a third unique VLAN/MPLS packet, thus saving flow entries (and lookup time) in the core;There’s no app related CLI. Currently, broadcast networks can’t be listed, created or modified. The only way to see what’s connected and troubleshoot is to use the intent framework. If new networks needs to be created, the interface configuration CLI can be usedencapsulated through the core;
- Run-time Interface configurtion configuration doesn’t support persistency. Either the configuration is loaded through an external json file or the configuration won’t survive after an ONOS reboot.