Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Project type

feature/enhancement

Project Description

To summarize the objective of this feature project in a sentence, we can say that it enables multiple ONOS clusters to share information about their networks, using an East-West interface

...

. Moreover, it allows an application, running on top of a specific cluster, to configure, via the NB Core API, routes crossing different

...

data plane devices, not under the control of that cluster.

...

In order to achieve this goal, the ICONA provider will be responsible of:

  • exposing the local topology to remote clusters

  • handling the topologies exposed by remote clusters

To implement this solution we decided to implement a new ONOS Provider (e.g. Adapter), responsible to interact with the ONOS core to:

...

  • configure (add/modify/remove) intents coming from and towards remote clusters

Topology Abstraction

Each cluster exposes the local topology to the peers as a single big switch, with several ports. Each port can represent both a customer edge point (e.g. the boundary between the managed infrastructure and remote networks) or an interconnection with other managed clusters. 

The cross-connection matrix (not all the ports can be reached from a source port, in case of link failures) and related metric information (hop-counts and link bandwidth) are also shared with remote clusters. 

Policy-based Approach

...

Icona is designed for a multi-domain scenario primarily, which is characterized by the presence of networks under control of different authorities (domains). The main difference with a single domain scenario consists in the fact that there is no trust among different authorities. For instance a domain would not expose everything to another domain who does not trust, it might instead want to hide some topology details such as hosts or links.

This is why the provider is policy-oriented, to guarantee, through policies configuration, the compliance to the agreements between different authorities.

In order to provide a policy-based approach, ICONA should allow an operator to configure at runtime different parameters:

  • the peering clusters allowed to access the local information

  • the maximum number of intents settable by each remote cluster

  • the weight of each interlink (the link between the local and remote cluster)

  • the preferred path for specific classes of traffic (based on L2 and L3 fields)

  • the link speed (bandwidth)

  • the type of connection

  • ...  

Applicability: single and multi-domain

This feature can be applied both to single and multi domain use-cases.

 

 

Moreover each cluster exposes to peers an abstraction of its local topology which allows flexibility in a policy-based approach.

Currently ICONA only exposes a big switch, with several ports, as the representation of the local topology. Each port can represent both a customer edge point (e.g. the boundary between the managed infrastructure and remote networks) or an interconnection with other managed clusters. The figure below (Fig.1) shows a possible abstraction of cluster topologies.

 

Image Added

Fig.1

 

In the future ICONA will share with remote clusters also the cross-connection matrix (not all the ports can be reached from a source port, in case of link failures) and related metric information (hop-counts and link bandwidth).

The final goal is to support more detailed types of topologies other than the big switch one. An example could be a full-mesh topology, a way to expose the full local topologyDetailed information could be found in the Design child page.

Project Design

See the Project Design page.

...