Versions Compared

Old Version 19

changes.mady.by.user Nishchya

Saved on

compared with

New Version Current

changes.mady.by.user Nishchya

Saved on

Key

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

Contents

Table of Contents
outlinetrue

Design Overview

Genius contains four main components:

  1. Interface Manager
  2. Tunnel Manager
  3. Aliveness Monitor
  4. ID-Manager

...

Contents

Table of Contents
outlinetrue

Design Overview

Genius contains four main components:

  1. Interface Manager
  2. Tunnel Manager
  3. Aliveness Monitor
  4. 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.

...

Follwoing diagram provides a toplevel architecture of Interface Manager.

 

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

...

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

...

IFM listeners listen to different MD-SAL data-stores. On the NBI side it implements data change listeners for interface config data-store and the service-binding data store. On the SBI side IFM implements listeners for Topology and Inventory data-stores in opendaylight.

...

implements listeners for Topology and Inventory data-stores in opendaylight.

Interface Config change listener

Interface config change listener listens to ietf-interface/interfaces data node.

service-binding change listener

Interface config change listener listens to ietf-interface/interfaces data node.

Topology state change listener

Interface config change listener listens to ietf-interface/interfaces data node.

service-binding change listener

Interface config change listener listens to ietf-interface/interfaces data node.

Topology state change listener

Interface config change listener listens to ietf-interface/interfaces data node.

inventory state change listener

+++ this page is under construction +++

Dynamic Behavior

...

inventory state change listener

+++ this page is under construction +++

Dynamic Behavior

when a l2vlan interface is configured

  1. Interface ConfigDS is populated
  2. Interface DCN in InterfaceManager does the following :
    1. Add interface-state entry for the new interface along with if-index generated
    2. Add ingress flow entry
    3. If it is a trunk VLAN, need to add the interface-state for all child interfaces, and add ingress flows for all child interfaces

when a tunnel interface is configured

...

  1. Interface ConfigDS is populated
  2. Interface DCN in InterfaceManager does the following :
    1. Add interface-state entry for the new interface along with if-index generated
    2. Add ingress flow entry
    3. If it is a trunk VLAN, need to add the interface-state for all child interfaces, and add ingress flows for all child interfaces

when a tunnel interface is configured

  1. Interface ConfigDS is populated
  2. Interface DCN in InterfaceManager does the following :
    1. Creates bridge interface entry in odl-interface-meta Config DS
    2. Add port to Bridge using OVSDB
      1. retrieves the bridge UUID corresponding to the interface and
      2. populates the OVSDB Termination Point Datastore with the following information

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

  1. 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

  1. 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

  1. Interface service-bindings config DS is populated with service name, priority and lport dispatcher flow instruction details
  2. Based on the service priority, the higher priority service flow will go in dispatcher table with match as if-index
  3. 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 Removed         Image Removed          Image Removed         

  2. Interface DCN in InterfaceManager does the following :
    1. Creates bridge interface entry in odl-interface-meta Config DS
    2. Add port to Bridge using OVSDB
      1. retrieves the bridge UUID corresponding to the interface and
      2. populates the OVSDB Termination Point Datastore with the following information

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

  1. 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

  1. 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

  1. Interface service-bindings config DS is populated with service name, priority and lport dispatcher flow instruction details
  2. Based on the service priority, the higher priority service flow will go in dispatcher table with match as if-index
  3. 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                                            Updating of Tunnel Interfaces   
     OF Switch is Connected       switch is connected                                      in Pre provisioning Mode              DCN handling



Image Added           Image Added          in Pre provisioning Mode    Image Added

 node connector removed                                                    updation of vlan interface in pre                            Image Removedupdation of vlan interface when
 DCN handling              Image Removed           Image Removed   Creation of tunnel-interface when OF switch is        Creation of vlan interface                                     provisioning mode     Creation of vlan interface
  connected and PortName already in OperDS           in pre provisioning mode                                       when switch is connected