Spaces

Spaces are the main organizational construct in Bonded Internet. Spaces allow bonds, aggregators, users, and other resources to be placed into distinct groups. Spaces can have their own IP subnet assignments, user interface branding options, and private WAN settings. Spaces are arranged in a hierarchy, similar to a directory structure, where one root space can have multiple child spaces, and each child space can have their own child spaces, and so on.

• Branding
  • Branding options
• IP management
  • Routing group validation
  • Network delegation
• Managing IP allocations and delegations
  • Group allocations
  • Adding a group allocation
  • Reviewing allocation availability
  • Updating a group allocation
  • Merging a group allocation
  • Deleting a group allocation
  • Delegated allocations
  • Delegating a network from a group allocation
  • Delegating a delegation
  • Reviewing delegation availability
  • Updating a delegated allocation
  • Merging a delegated allocation
  • Deleting a delegated allocation
• Managing spaces
  • Adding a space
  • Viewing or updating a space
  • Space fields
  • Deleting a space
• Moving resources between spaces
  • Moving bonds
  • Moving aggregators
  • Moving QoS profiles
  • Moving mobile broadband providers
  • Moving users
• Node setup
  • Root password
  • Timezone
  • DNS servers
  • Network interface names
  • Custom configuration
  • Preseed files
  • Apt source
• Space private WAN
  • Managed mesh
  • Unmanaged
  • With private WAN routers
• Space statistics
  • Space growth
  • Prevented downtime
  • History
• Technical support
• Technical support contacts

Space overview

Spaces are the main organizational construct in Bonded Internet. They are used to group and define relationships between the following components:

• Bonds
• Aggregators
• Private WAN routers
• Routing groups
• IP allocations and delegations
• QoS profiles
• Classification profiles
• Flow collectors
• Mobile broadband provider profiles
• Users

Spaces are arranged in a hierarchy, similar to a directory structure, where one root space can have multiple child spaces, and each child space can have their own child spaces, and so on.

In the example above, Chase Dental Clinics and Stanley Internet are second level spaces, while Murphy Electrical is a third level space.

Spaces allow users to access a limited part of the Bonded Internet application. For example, a space could be created for a reseller, and user accounts added to that space, such that the users could manage bonds and aggregators only within their space but not be able to see bonds or aggregators outside their space. Since spaces are hierarchical, users in the child space could create a child space of their own, and create users that are only allowed to manage objects within that space.

In the example above, Granville Networks (GN) is the root space. This space has a number of bonds, aggregators, private WAN routers, users, routing groups, and QoS profiles. Because GN is the root, users in GN can view and manage the objects in that space as well as all other spaces. GN has two child spaces, Chase Dental Clinics (CDC) and Stanley Internet (SI). CDC represents an end-user company with two bonds and two users. Since CDC doesn’t host their own aggregators, the bonds in CDC are assigned to the aggregators in GN. The users in CDC cannot view the objects in any other space. SI represents a reseller that hosts its own aggregators in its own datacentre, and SI has an end-user company of its own, Murphy Electrical (ME). The bonds in both the SI and ME spaces are assigned to the aggregators in SI.

User access control

Users are assigned to a specific space, and can only view and manage objects in their space and descendants of that space. In the example above, users in ME can only see their own bonds and other objects, while users in SI can see objects in SI and ME, users in CDC can only see objects in CDC, and users in GN can see objects in the entire environment, since GN is the root.

There is one exception to this—if a space has been given access to its parent’s aggregators, QoS profiles, mobile broadband providers, or routing groups, then users in the child space will be able to see the names of those resources in the parent and possibly other ancestors. Users are not able to see other details about the shared objects.

Resource sharing

Space permissions can be set up in a variety of flexible arrangements that allow aggregators, QoS profiles, mobile broadband provider profiles, and routing groups to be used by bonds and aggregators in child spaces, or to require bonds in child spaces to be assigned to aggregators, QoS profiles, etc. only in their own space.

In the example above, the bonds in the root space, GN, can use only the aggregators in the root space. Since space CDC has no aggregators of its own, it must be allowed to use spaces from its parent. The diagram above shows its two bonds assigned to the aggregators in its parent space, GN. Space SI, on the other hand, has its own aggregators, so has not been allowed to use aggregators in its parent space. Bonds in SI can only use the SI aggregators. Finally, space ME has a similar relationship to its parent, SI, as CDC has to its parent, GN. ME has no aggregators of its own, so it is allowed to use aggregators in its parent, SI. Because SI is not allowed to use aggregators from its parent, ME can only use aggregators in SI, and not in GN.

Bonds in a given space can never be assigned to aggregators in a descendant of that space.

Sharing of QoS profiles and mobile broadband provider profiles works the same as sharing of aggregators. Sharing of routing groups is similar, but applies to aggregators and private WAN routers, not bonds. If a space is allowed to use routing groups from its parent, then an aggregator or private WAN router in that space may be assigned to a routing group in its parent. If a space is not allowed to use routing groups from its parent, those hosts can only be assigned to routing groups in their own space.