Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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.
  • Replication:
    • Alternative1: Groups for a device are only replicated in the Master controller instance and another potential candidate instance. 
    • Alternative2: Since typically the number Groups per device will not be huge, Groups are replicated in all the instances of the cluser
  • 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

    • void 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)
    • GetAllGroupStatistics(Device, appid)

  • DataModel

    • Group Types to be supported

      • Select

      • Indirect

      • All

      • Failover

    • Key

      • An application specific cookie that supports Hash and Equals method

    • Id

      • Integer

    • Bucket

      • One or more collection of Traffic Instructions

 

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

 

 

How to create and use Group
{
    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());
....
 
}


  • No labels