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.
...
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 same VPLS
At least two hosts need to be connected to the OpenFlow network. The hosts should Hosts participating to the same VPLS can send in packets tagged with the same VLAN Id defined in the interface configurationVLAN Ids, different VLAN Ids, no VLAN Ids at all
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 hosts of the hosts configured same VPLS- unicast communication is established between the hosts discovered on that specific overlay network.
General workflow
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
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
...
.
Components:
VPLS contains several components:
VPLS (VPLS Manager):
- Provides public API for managing virtual private LANs.
- The API provides create/update/read/delete (CURD) functionality, helps other application to interact with VPLS Store and VPLS operation service.
- Handles host events to attach/detach hosts to a virtual private LAN
VPLS Store Delegate (in VPLS Manager):
Handles VPLS store events, it will generate new VPLS Operation according to store event type and VPLS status.
Also, after it generate an operation, it will send to VPLS Operation Service directly.
VPLS Operation Service(VPLS Operation Manager):
Manage any operation(modification) of any VPLS.
Convert VPLS operations to sets of Intent operations.
Provide correct order of Intent operations.
Update VPLS status to store when finished/failed VPLS operation.
VPLS Store (Distributed VPLS Store):
Stores all VPLS information
Push all VPLS information to network config system
VPLS Config Manager:
Handles network config update event
Optimize changes from VPLS network config event and invoke VPLS API
VPLS Neighbour Handler:
Handles neighbour messages of any VPLS from any interface
VPLS REST API (Work in progress):
Provides REST API to control VPLS
General workflow
VPLS can be changed by these ways:
Host event (host added or removed)
Network config modification
VPLS command
- VPLS REST API
VPLS Operation Service
- When a new VPLS operation generated and submit to VPLS operation service the operation will be queued.
- An operation scheduler will take batches of operation for multiple VPLS, if there exists multiple operations to process, it will optimize operations to a single operation.
- For every operation to be process, the scheduler will put the operation into operation executor and add success and error consumer to it.
- For success consumer, it will update VPLS state according to previous state (e.g. ADDING -> ADDED)
- For error consumer, will change the state to FAILED.
VPLS Operation Executor (Intent installation)
The VPLS Operation Executor will generate different Intent operations for different operation type (add, remove or update VPLS).
For ADD operation, executor will generate two types of Intents:
Single-Point to Multi-Point intents Intents for broadcast traffic, from any ingress point to every egress point, configured in the same VPLS.
Multi-Point to Single-Point intents 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.
...
.
- See Traffic provisioning and intent requests chapter below for more information.
For REMOVE operation, the executor will find every intents related to the VPLS (by Intent key) and remove them.
For UPDATE operation, two situation will be considered:
Interfaces updated: will reinstall all Intents related to this VPLS.
Hosts updated: will remove or add new unicast Intent only.
Provide correct ordering of Intent installation
To resolve race condition issue (install after withdraw Intents), the executor uses IntentCompleter to wait Intent installation process.
An IntentCompleter is a kind of IntentListener, initialize by Intent keys we need to wait, then register as listener to the IntentService and do Intent operations (submit, withdraw)
After that, invoke “complete” method from the IntentCompleter, it will wait until all Intents finished or timeout exceed.
Network configuration, interface configuration and hosts listeners
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 JSON configuration file or through CLI. The Interface configuration is filtered to consider only the interfaces with VLANs configured, but not IPno IPs (to avoid to conflict with Layer3 applications, such as SDN-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 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, possibly 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 intent framework abstraction allows to mask the complexity of provisioning single flows on each switch and do error recovering in case failures happen.
...
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 (in case the interface associated has a VLAN Id associated), 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 (in case destination hosts have VLANs configured). The intent framework automatically performs the VLAN Id translation (translation, popping, pushing) at the egress as needed, 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.
...
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 (in case the source interface has a VLAN Id configured), 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 (in case the interfaces associated to the destination hosts have a VLAN Id configured). The intent framework automatically performs the VLAN Id translation (translation, popping, pushing) at the ingress as needed, 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.
...
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 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 beginning, the VPLS operation manager from each ONOS instance will send a request to LeadershipService to make sure which instance is the leader of VPLS application.
Only the leader node can execute VPLS operation and install Intents now.
Known limitations
At the current At the present stage:
- Run-time Interface 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.
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;
to select traffic at the ingress, no MPLS