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

{
    Collection<TrafficTreatment> groupBuckets = new ArrayList<TrafficTreatment>();
	List<PortNumber> outPorts = getPortsToDevice(srcDevice, neighborDevice);

    for (PortNumber portNumber: outPorts) {
        TrafficTreatment.Builder tBuilder = DefaultTrafficTreatment.builder();
        tBuilder.setOutput(portNumber)
                .setEthDst(getRouterMacAddress(neighborDevice))
                .setEthSrc(getRouterMacAddress(srcDevice))
                .pushMpls()
                .setMpls(getMplsId(finalDstDevice));
        groupBuckets.add(tBuilder.build());
    }

	GroupKey gorupKey = SegmentRoutingGroupKey.build(srcDevice, Collection<NeighborDevice>, dstDevice);
    Future<Group> future = groupService.createGroup(srcDevice, Group.Type.SELECT,
            groupBuckets, groupKey, getAppId());
    Group group = future.get();
}
 
public void SetIpRule() {
....
	GroupKey gorupKey = SegmentRoutingGroupKey.build(srcDevice, Collection<NeighborDevice>, dstDevice);
	Group group = groupService.getGroup(srcDevice, groupKey);
	tbuilder.setGroup(group.id());
....
 
}