Contents
| Table of Contents | ||
|---|---|---|
|
Genius Services
Genius provides components and framework for application co-existence. Following diagram gives an overview of how multiple applications/service based on genius components, can work together.
Genius addresses app co-existence issue based on following principles –
...
An overlay tunnel interface is created with type 'tunnel' and particular 'tunnel-interface-type'. Tunnel interfaces are created on a particular DPN with a pair of (local, remote) IP addresses. Currently supported tunnel interface types are VxLAN, GRE and MPLSoverGRE. overlay tunnel interfaces are based on tunnel interafces provided by OVS. Some of these interfaces are not yet available with standard OVS versions. However, there are OVS patches available add specific tunnel interface implementation in OVS. Following are tunnel types for which specific patches are available -
1. VxLAN GPE interafce - following link provides information on how to add VxLAN GPE patch to OVS -
URL: /restconf/config/ietf-interfaces:interfaces
...
When a service is bind to an interface, Interface Manager programs the service dispatcher table with a rule to match on the interface data-plane-id and the service-index (based on priority) and the instruction-set provided by the service/application. Every time when the packet leaves the dispatcher table the service-index (in metadata) is incremented to match the next service rule when the packet is resubmitted back to dispatcher table. if the service-mode is ingress, ingress dispatcher is programmed or else if the service-mode-egress is configured egress-dispatcher table is programmed.
Binding services on interface
...
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.
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
...
rpc remove-terminating-service-actions {
description "remove the ingress terminating service table entries";
input {
leaf dpid {
type uint64;
}
leaf interface-name {
type string;
}
leaf tunnel-key {
type uint64;
}
}
}
ID Manager
Genius Id-Manager service provides interface to generate unique integer ID(s) for a particular key String, from a given pool of IDs with configured range. The key and generated ID mapping is persistent across cluster restarts.
ID Manager Data-Model/APIs
Creation of ID-Pool =
generating unique Id for a Key from particular pool
Resource Manager Framework
Resource Sharing Framework is based on Genius ID-Manager service. ID-Manager service manages resource/ID pools and allocates unique range of integer IDs for specific string keys. These key and ID/range mappings are persisted across controller restarts. The idea for resource sharing is to have common resource pools, managed by ID-Manager and allow applications to dynamically allocate a range of resource IDs for their use. The resource manager component of the framework creates resource Id pools for of-tables, groups, meters etc. Further, different applications can request for a number of resource-IDs from these pools. Same range is always returned across controller restarts.
Resource Framework Components
Resource pool config file contains available resource pool configs in a particular format which is understandable by the Resource Manager. Following is an example of Resource pool config file.
<poolName>, <id-start>, <id-end>
tableIdPool, 10, 254
GroupIdPool, 100, 1000
Pools should be created with resources available for dynamic allocations. Some of the resources are reserved for Genius Interface Manager, which manages port/interface ingress and egress functions and provides services to service modules.
Resource manager is a thin API wrapper layer on top of ID-Manager. It is responsible for creating different resource pools in ID-Manager, as specified in Resource pool config at the system startup. This is achieved using RPC provided by ID-Manager like following -
createIdPool{
input {
“pool-name” : “tableIdPool”,
“low” : “10”,
“high” : “220”
}
}Additionally it exposes following RPCs for resource allocation and release. Following RPCs are provided
AllocateIdRange
input {
“pool-name” : “tableIdPool”,
“key” : “app1.zone1.table1”,
“size” : “5” }
Returns --
output {
“id-list” : “100”, “101”, “102”, “103”, “104”
}
rpc releaseResource { input { leaf resource-type { type identityref{ base resource-type-base; } } leaf id-key { type string; } } }
rpc allocateResource { input { leaf resource-type { type identityref{ base resource-type-base; } } leaf id-key { type string; } leaf size { type uint32; } } output { leaf-list id-values{ type uint32; ordered-by user; } } }
rpc getAvailableResources{ input { leaf resource-type { type identityref{ base resource-type-base; } } } output{ leaf total-available-id-count { type uint32; } } }
rpc getResourcePool{ input{ leaf resource-type { type identityref{ base resource-type-base; } } } output{ list available-ids{ uses available-resource-ids; } uses released-resource-ids; } }
grouping available-resource-ids { leaf start { type uint32; } leaf end { type uint32; } }
grouping released-resource-ids {
list delayed-resource-entries {
uses idmgr:delayed-id-entry;
}
}ReleaseResource(poolName, key)