Topology 2 is a "region aware" view of the topology, where the administrator can configure the network into regions and sub-regions.
In its default state (where no "regions" or "layouts" are defined), it should look and behave similarly to (eventually, the same as) the "classic" Topology view.
Note that this view is currently "experimental", although the longer term plan is to bring it up to par with the "classic" view, which it will eventually replace.
A more detailed description of the current state of Topology 2 can be found HERE. (Steven to provide link)
The ONOS model of the network includes Region objects which can be configured with a collection of Devices (switches) "belonging" to that region.
Regions can be configured using a number of CLI commands:
To add a region to the model, the region-add command can be used..
region-add <region-id> <region-name> <region-type> <lat/Y> <long/X> <locType> <region-master>
- <region-id> is a unique identifier for the region
- <region-name> is a human readable name for the region
- <region-type> is one of the values defined in the Region.Type enumeration:
- CONTINENT, COUNTRY, METRO, CAMPUS, BUILDING, DATA_CENTER, FLOOR, ROOM, RACK, LOGICAL_GROUP
- <lat/Y>, <long/X> are the latitude / longitude (for geo layouts) or Y-coord / X-coord (for grid layouts) to be assigned to the region when it is displayed as a node in its parent layout.
- <locType> is either geo (for geographical (map) layout) or grid (for logical grid layout).
- <region-master> is a list of sets of node-IDs for mastership of the devices (see RegionAddCommand for more details).
A couple of examples:
Note that CLI commands are scriptable. One way of doing this is as follows:
Devices can be assigned to regions with the region-add-devices command:
region-add-devices <region-id> <dev1> <dev2> ... <dev-n>
- <region-id> is the region unique identifier
- <dev-...> is a device identifier
The currently configured regions can be listed with the regions command:
(Another region command we'll look at is region-add-peer-loc, but we'll defer that until we have covered layouts).
Note that regions do not have any notion of hierarchy; they are simply "collections of devices". The hierarchy is expressed using Layouts.
Layouts are used to define a "containment" hierarchy for the regions, as well as provide configuration information for the UI, such as which background decoration to use when displaying the layout; for example a geographical map.
A Layout is a "UI construct" that has an associated region "backing" it. Layouts define some other layout as its parent (except the root layout, of course), thereby allowing a hierarchy of layouts to be constructed.
This could be pictured as shown here:
Note that the "root" (default) layout does not have a backing region. Any devices (and their attached hosts) that have not been assigned to a region will appear in the topology view at this top level.
Layouts can be configured using a number of CLI commands:
Layouts can be added to the model with the layout-add command.
layout-add <layout-id> <bg-ref> <region-id> <parent-layout-id> <scale> <offset-x> <offset-y>
- <layout-id> is a unique identifier for the layout
- <bg-ref> is a reference to the background to display for this layout
- <region-id> is the identifier of the backing region
- <parent-layout-id> is the identifier of the parent layout
- <scale>, <offset-x>, <offset-y> are custom values to define the initial pan/zoom of the background
Note that currently the <scale>, <offset-x>, <offset-y> values can be determined by trial and error. See the section on Useful Techniques below for more details.