...

Table of Contents

outline	true

Design Overview

Genius contains four main components:

Interface Manager
Tunnel Manager
Aliveness Monitor
ID-Manager

these modules are developed as karaf features which can be independently installed. However, there is some dependency among these modules. The diagram below provides a dependency relationship of these modules.

Image Removed

the central/main component of Genius is the Interface Manager which uses other modules for its operations. All these modules expose Yang based API which can be used to configure/interact with these modules and fetch services provided by these modules. Thus all these modules can be used/configured by other ODL modules and can also be accessed via REST interface.

Following sections provide details about each of these components.

Interface Manager

The Interface Manager (IFM) uses an MD-SAL based architecture, where different software components operate on, and interact via a set of data-models. Interface manager defines configuration data-stores where other opendaylight modules can write interface configurations and register for services. These configuration data-stores can also be accessed by external entities through REST interface. IFM listens to changes in these config data-stores and accordingly programs the data-plane. Data in Configuration data-stores remains persistent across controller restarts.

Operational data like network state and other service specific operational data are stored in operational data-stores. Change in network state is updated in southbound interfaces (OFplugin, OVSDB) data-stores. IFM listens to these updates and accordingly updates its own operational data-stores. Operational data stores are cleaned up after a controller restart.

Additionally, IFM also provides a set of RPCs to access IFM data-stores and provide other useful information. Following figure presents different IFM data-stores and its interaction with other modules.

Follwoing diagram provides a toplevel architecture of Interface Manager.

Image Removed

In addition to these datamodels, it also implements several RPCs for accessing interface operational data. Details of these datamodels and RPCs are described in following sections. Interface Manager also uses ODL Inventory and Topology datastores to retrive southbound configurations and events. As described above Interface Manager uses other Genius modules for its operations. It mainly interacts with following other modules-

Modules used by InterfaceManager

Id Manager – For allocating dataplane interface-id (if-index)
Aliveness Monitor - For registering the interfaces for monitoring
MdSalUtil – For interactions with MD-SAL and other openflow operations

Code structure

Interface manager code is organized in following folders -

interfacemanager-api contains the interface yang data models and corresponding interface implementation.
interfacemanager-impl contains the interfacemanager implementation
interface-manager-shell contains Karaf CLI implementation for interfacemanager

interfacemanager-api

...

interfacemanager-impl

...

Design Overview

Genius contains four main components:

Interface Manager
Tunnel Manager
Aliveness Monitor
ID-Manager

these modules are developed as karaf features which can be independently installed. However, there is some dependency among these modules. The diagram below provides a dependency relationship of these modules.

Image Added

the central/main component of Genius is the Interface Manager which uses other modules for its operations. All these modules expose Yang based API which can be used to configure/interact with these modules and fetch services provided by these modules. Thus all these modules can be used/configured by other ODL modules and can also be accessed via REST interface.

Following sections provide details about each of these components.

Interface Manager

The Interface Manager (IFM) uses an MD-SAL based architecture, where different software components operate on, and interact via a set of data-models. Interface manager defines configuration data-stores where other opendaylight modules can write interface configurations and register for services. These configuration data-stores can also be accessed by external entities through REST interface. IFM listens to changes in these config data-stores and accordingly programs the data-plane. Data in Configuration data-stores remains persistent across controller restarts.

Operational data like network state and other service specific operational data are stored in operational data-stores. Change in network state is updated in southbound interfaces (OFplugin, OVSDB) data-stores. IFM listens to these updates and accordingly updates its own operational data-stores. Operational data stores are cleaned up after a controller restart.

Additionally, IFM also provides a set of RPCs to access IFM data-stores and provide other useful information. Following figure presents different IFM data-stores and its interaction with other modules.

Follwoing diagram provides a toplevel architecture of Interface Manager.

Image Added

In addition to these datamodels, it also implements several RPCs for accessing interface operational data. Details of these datamodels and RPCs are described in following sections. Interface Manager also uses ODL Inventory and Topology datastores to retrive southbound configurations and events. As described above Interface Manager uses other Genius modules for its operations. It mainly interacts with following other modules-

Modules used by InterfaceManager

Id Manager – For allocating dataplane interface-id (if-index)
Aliveness Monitor - For registering the interfaces for monitoring
MdSalUtil – For interactions with MD-SAL and other openflow operations

Code structure

Interface manager code is organized in following folders -

interfacemanager-api contains the interface yang data models and corresponding interface implementation.
interfacemanager-impl contains the interfacemanager implementation
interface-manager-shell contains Karaf CLI implementation for interfacemanager

interfacemanager-api

└───main
   ├───java
   │   └───org
   │       └───opendaylight
   │           └───genius
   │               └───interfacemanager
  <--- Contains│ different southbound renderers' implementation  │   ├───hwvtep          ├───exceptions
   │                 <--- HWVTEP specific├───globals
renderer │   │   ├───confighelpers                └───interfaces
   └───yang

interfacemanager-impl

├───commons  │   │   ├───statehelpers │   │   └───utilities │   └───ovs           <--- contains common utility functions
├───listeners                  <--- OVS specific SBI renderer  │    <--- Contains interfacemanager ├───confighelpersDCN │listenenrs for differnt MD-SAL datastores 
├───renderer ├───statehelpers │       └───utilities ├───servicebindings                      <--- containsContains interfacedifferent servicesouthbound bindingrenderers' DCNimplementation listener
and│ corresponding implementation │├───hwvtep   └───flowbased │       ├───confighelpers │       ├───listeners │       ├───statehelpers │   <--- HWVTEP specific renderer
└───utilities│ ├───rpcservice  │   ├───confighelpers                     
<---│ Contains interfacemanager RPCs'│ implementation ├───pmcounters ├───statehelpers
│   │   └───utilities
│   └───ovs                                  <--- Contains PM counters gathering 
└───statusanddiag   OVS specific SBI renderer 
│       ├───confighelpers
│       ├───statehelpers
│       └───utilities
├───servicebindings                      <--- contains statusinterface and diagnostics implementations

'interfacemanager-shell

Data-model

InterfaceManager mainly uses two Yang data models to accept configurations.

odl-interface datamodel () where verious type of interface can be configuted.
service-binding datamodel () where different applications can bind services to interfaces.

In addition to these datamodels, it also implements several RPCs for accessing interface operational data. Details of these datamodels and RPCs are described in following sections. Interface Manager also uses ODL Inventory and Topology datastores to retrive southbound configurations and events. As described above Interface Manager uses other Genius modules for its operations. It mainly interacts with following other modules-

Interface Config DS

IFM datamodel is defined in odl-interface.yang . It is based on ‘ietf-interfaces’ datamodel (imported in odl_interface.yang) with additional augmentations to it. Common interface configurations are –

...

l2vlan (trunk, vlan classified sub-ports/trunk-member)
tunnel (OVS based VxLAN, GRE, MPLSoverGRE/MPLSoverUDP)

...

service binding DCN listener and corresponding implementation
│   └───flowbased
│       ├───confighelpers
│       ├───listeners
│       ├───statehelpers
│       └───utilities
├───rpcservice                           <--- Contains interfacemanager RPCs' implementation
├───pmcounters                           <--- Contains PM counters gathering 
└───statusanddiag                        <--- contains status and diagnostics implementations

'interfacemanager-shell

Data-model

InterfaceManager mainly uses two Yang data models to accept configurations.

odl-interface datamodel () where verious type of interface can be configuted.
service-binding datamodel () where different applications can bind services to interfaces.

In addition to these datamodels, it also implements several RPCs for accessing interface operational data. Details of these datamodels and RPCs are described in following sections. Interface Manager also uses ODL Inventory and Topology datastores to retrive southbound configurations and events. As described above Interface Manager uses other Genius modules for its operations. It mainly interacts with following other modules-

Interface Config DS

IFM datamodel is defined in odl-interface.yang . It is based on ‘ietf-interfaces’ datamodel (imported in odl_interface.yang) with additional augmentations to it. Common interface configurations are –

name (string) : this is the unique interface name/identifier.
type (identityref:iana-if-type) : this configuration sets the interface type. Interface types are defined in iana-if-types data model. Odl-interfaces.yang data model adds augmentations to iana-if-types to define new interface types. Currently supported interface types are -
- l2vlan (trunk, vlan classified sub-ports/trunk-member)
- tunnel (OVS based VxLAN, GRE, MPLSoverGRE/MPLSoverUDP)
enabled (Boolean) : this configuration sets the administrative state of the interface.
parent-refs : this configuration specifies the parent of the interface, which feeds data/hosts this interface. It can be a physical switch port or a virtual switch port.
- Parent-interface (string) : is the port name with which a network port in dataplane in that appearing on the southbound interface. E.g. neutron port. this can also be another interface, thus supporting a hierarchy of linked interfaces.
- Node-identifier (topology_id, node_id) : is used for configuring parent node for HW nodes/VTEPs

...

Introducing Egress Service Binding

Currently Interface Manager supports service binding on port ingress only. However, there are services that need packet processing on the egress, before sending the packet out to particular port/interface. To accommodate this, interface manager will be enhanced to support egress service binding also. This will be achieved by introducing a new “egress dispatcher table” at the egress of packet pipeline before the interface egress groups.

Image Modified

On different application request, Interface Manager returns the egress actions for interfaces. Service modules program use these actions to send the packet to particular interface. Generally, these egress actions include sending packet out to port or appropriate interface egress group. With the inclusion of the egress dispatcher table the egress actions for the services would be to

...


tpAugmentationBuilder.setName(portName);
tpAugmentationBuilder.setInterfaceType(type);
options.put("key", "flow");
options.put("local_ip", localIp.getIpv4Address().getValue());
options.put("remote_ip", remoteIp.getIpv4Address().getValue());
tpAugmentationBuilder.setOptions(options);

OVSDB plugin acts upon this data change and configures the tunnel end points on the switch with the supplied information.

NodeConnector comes up on vSwitch

Inventory DCN Listener in InterfaceManager does the following:
1. Updates interface-state DS.
2. Generate if-index for the interface
3. Update if-index to interface reverse lookup map
4. If interface maps to a vlan trunk entity, operational states of all vlan trunk members are updated
5. If interface maps to tunnel entity, add ingress tunnel flow

Bridge is created on vSWitch

Topology DCN Listener in InterfaceManager does the following:
1. Update odl-interface-meta OperDS to have the dpid to bridge reference
2. Retrieve all pre provisioned bridge Interface Entries for this dpn, and add ports to bridge using ovsdb

ELAN/VPNManager does a bind service

Interface service-bindings config DS is populated with service name, priority and lport dispatcher flow instruction details
Based on the service priority, the higher priority service flow will go in dispatcher table with match as if-index
Lower priority service will go in the same lport dispatcher table with match as if-index and service priority

Interface Manager Sequence Diagrams

...

());
tpAugmentationBuilder.setOptions(options);

OVSDB plugin acts upon this data change and configures the tunnel end points on the switch with the supplied information.

NodeConnector comes up on vSwitch

Inventory DCN Listener in InterfaceManager does the following:
1. Updates interface-state DS.
2. Generate if-index for the interface
3. Update if-index to interface reverse lookup map
4. If interface maps to a vlan trunk entity, operational states of all vlan trunk members are updated
5. If interface maps to tunnel entity, add ingress tunnel flow

Bridge is created on vSWitch

Topology DCN Listener in InterfaceManager does the following:
1. Update odl-interface-meta OperDS to have the dpid to bridge reference
2. Retrieve all pre provisioned bridge Interface Entries for this dpn, and add ports to bridge using ovsdb

ELAN/VPNManager does a bind service

Interface service-bindings config DS is populated with service name, priority and lport dispatcher flow instruction details
Based on the service priority, the higher priority service flow will go in dispatcher table with match as if-index
Lower priority service will go in the same lport dispatcher table with match as if-index and service priority

Interface Manager Sequence Diagrams

Following gallery contains sequence diagrams for different IFM operations -

Image Added Image Added Image Added

Removal of Tunnel Interface When Removal of Tunnel Interfaces Updating of Tunnel Interfaces
OF Switch is Connected in Pre provisioning Mode in Pre provisioning Mode

Image Added Image Added Image Added

Creation of tunnel-interface when OF switch is Creation of vlan interface in pre Creation of vlan interface when
connected and PortName already in OperDS provisioning mode switch is connected

Image Added Image Added Image Added

deletion of vlan interface in deletion of vlan interface when node connector added_updated
pre provisioning mode switch is connected DCN handling

Image Added Image Added Image Added

node connector removed updation of vlan interface in pre updation of vlan interface when
DCN handling provisioning mode switch is connected

Versions Compared

Old Version 9

New Version Current

Key

Design Overview

Interface Manager

Modules used by InterfaceManager

Code structure

Contents

Design Overview

Interface Manager

Modules used by InterfaceManager

Code structure

Data-model

Interface Config DS

Data-model

Interface Config DS

Introducing Egress Service Binding

NodeConnector comes up on vSwitch

Bridge is created on vSWitch

ELAN/VPNManager does a bind service

Interface Manager Sequence Diagrams

NodeConnector comes up on vSwitch

Bridge is created on vSWitch

ELAN/VPNManager does a bind service

Interface Manager Sequence Diagrams

Page Comparison

Versions Compared

Old Version 9

New Version Current

Key

<span class="diff-html-changed" data-a11y-before="Start of changed content" data-a11y-after="End of changed content" id="changed-diff-0">[data-colorid=</span>

Design Overview

Interface Manager

Modules used by InterfaceManager

Code structure

Design Overview

Interface Manager

Modules used by InterfaceManager

Code structure

Data-model

Interface Config DS

Data-model

Interface Config DS

Introducing Egress Service Binding

NodeConnector comes up on vSwitch

Bridge is created on vSWitch

ELAN/VPNManager does a bind service

Interface Manager Sequence Diagrams

NodeConnector comes up on vSwitch

Bridge is created on vSWitch

ELAN/VPNManager does a bind service

Interface Manager Sequence Diagrams