Design Decisions:
- Group Identifier will be represented as a simple Integer. Will be revisited at a later point of time to see if it needs to be aligned with PortNumber representation
- Group objects for a device will only be created/updated/removed by current Master controller instance.
- So as, the Group Identifier allocation/management also will only be done by current Master controller instance.
- Groups for a device are only replicated in the Master controller instance and another potential candidate instance. It is not replicated in all the instances.
- Group creation/update/removal/query request can be submitted in any controller instance and that instance will take care of routing the request to current Master controller instance.
- Group creation API does not return any Group object as in some scenarios the request needs to be routed to Master controller instance where the Group object gets created. Application should use Group Query API to retrieve the Group object after creation.
- Group query API blocks the caller thread until it retrieves from the remote Master controller instance if the instance where request is submitted is not having the control over that device
- Group query API returns the Group object even if the Group object is in PENDING_ADD state
- Group subsystem generates GROUP_ADDED event only after it receives confirmation from Data plane through Barrier Reply or Group Description Reply (In the first phase, it will be based on Group Description Reply)
Group Subsystem Design:
High level layout of Group subsystem components is depicted below.
Group Service
Provides the following API to applications
Future<Group> CreateGroup(Device, GroupType, Collection<GroupBuckets>, GroupKey, appid)
Group GetGroup(Device, GroupKey)
void AddBucketsToGroup(Device, OldGroupKey, Collection<GroupBuckets>, NewGroupKey, appid)
void RemoveBucketsFromGroup(Device, OldGroupKey, Collection<GroupBuckets>, NewGroupKey, appid)
- void RemoveGroup(Device, GroupKey, appid)
GetAllGroups(Device, appid)
DataModel
Group Types to be supported
Select
Indirect
All
Failover
Key
An application specific cookie that supports Hash and Equals method
Id
The GroupId derived from PortNumber construct
Bucket
One or more collection of Traffic Treatments
Group Manager
Implements the Group Service
Handles the Group create/modify/remove operations for any devices. If the device is not under the current controller instance, Group manager uses the distributed Group store to send GROUP_ADD_REQUEST to the master controller instance of that device.
GroupId generation
Group ID space is per device.
A monotonically increasing Group ID is maintained per device that will be incremented every time a new group is created.
Group Store replicates any changes to per device Group ID to all instances in the cluster, so that any instance in the cluster can generate a Group ID for a device even if it is not master.
Creates the groups only if the device doesn’t have those groups populated. If group already exists, the APIs return with the existing group object.
Maintains monotonically increasing Group ID number space for each device
ONOS Group construct/object:
The Group Store replicates the Groups to atleast two (?) instances in the cluster similar to Flow subsystem.
Group Store will have authoritative role. i.e.
When a Device is connected to the controller, GroupStore will wipe off all extraneous groups in the device and inserts if any groups are missing
High level flow of events in the Group subsystem is depicted below when an operation like CreateGroup is submitted by the application.
Group AUDIT
TODO
Multi-instance Support
TODO
Group Provider
Provides SB APIs towards core
CreateGroup(GroupId, Buckets)
ModifyGroup(GroupId, Buckets)
RemoveGroup(GroupId)
GetGroups()
OF Group Provider
Implements Group Providers interface
Builds OF GROUP_MOD (ADD/MOD/DELETE) Message depending on the API invocation and writes the message to switch driver
OF Switch Driver
No changes