-
Revealing the physical topology of the network
-
Exposing each type of a device
-
Assigning the domain for each device
-
Get assigned an IP-address
-
Establish secure IP connectivity
SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
network functions within a network device, including individual network element
services, such as:
-
Performance measurement
-
Traffic-sniffing functionality
-
Traffic transformation functionality
SNBi also provides a Linux side abstraction layer to forward elements as well
as enhancements to feature the abstraction and bootstrapping infrastructure.
You can also use the device type and domain information to initiate controller
federation processes.
Provides the ability to define an ordered list of network services (e.g.
firewalls, load balancers) that are then “stitched” together in the network to
create a service chain. SFC provides the chaining logic and APIs necessary for
OpenDaylight to provision a service chain in the network and an end-user
application for defining such chains. It includes:
-
YANG models to express service function chains
-
SFC receiver for Intent expressions from REST & RPC
-
UI for service chain construction
-
LISP support
-
Function grouping for load balancing
-
OpenFlow renderer for Network Service Headers, MPLS, and VLAN
-
Southbound REST interface
-
IP Tables-based classifier for grouping packets into selected service chains
-
Integration with OpenDaylight GBP project
-
Integration with OpenDaylight OVSDB NetVirt project
The SNMP southbound plugin allows applications acting as an SNMP Manager to
interact with devices that support an SNMP agent. The SNMP plugin implements a
general SNMP implementation, which differs from the SNMP4SDN as that project
leverages only select SNMP features to implement the specific use case of
making an SNMP-enabled device emulate some features of an OpenFlow-enabled
device.
Provides a southbound SNMP plugin to optimize delivery of SDN controller
benefits to traditional/legacy ethernet switches through the SNMP interface. It
offers support for flow configuration on ACLs and enables flow configuration
via REST API and multi-vendor support.
Enables creation of a tag that allows you to filter traffic instead of using
protocol-specific information like addresses and ports. Via SXP an external
entity creates the tags, assigns them to traffic appropriately, and publishes
information about the tags to network devices so they can enforce the tags
appropriately.
More specifically, SXP Is an IETF-published control protocol designed to
propagate the binding between an IP address and a source group, which has a
unique source group tag (SGT). Within the SXP protocol, source groups with
common network policies are endpoints connecting to the network. SXP updates
the firewall with SGTs, enabling the firewalls to create topology-independent
Access Control Lists (ACLs) and provide ACL automation.
SXP source groups have the same meaning as endpoint groups in OpenDaylight’s
Group Based Policy (GBP), which is used to manipulate policy groups, so you can
use OpenDaylight GPB with SXP SGTs. The SXP topology-independent policy
definition and automation can be extended through OpenDaylight for other
services and networking devices.
Provides a framework for simplified aggregation and topology data query to
enable a unified topology view, including multi-protocol, Underlay, and
Overlay resources.
Creates a framework for collecting, storing, querying, and maintaining time
series data in OpenDaylight. You can leverage various data-driven applications
built on top of TSDR when you install a datastore and at least one collector.
Functionality of TDSR includes:
-
Data Query Service - For external data-driven applications to query data from
TSDR through REST APIs
-
ElasticSearch - Use external elastic search engine with TSDR integrated support.
-
NBI integration with Grafana - Allows visualization of data collected in TSDR
using Grafana
-
Data Aggregation Service - Periodically aggregates raw data into larger time granularities
-
Data Purging Service - Periodically purges data from TSDR
-
Data Collection Framework - Data Collection framework to allow plugging in of
various types of collectors
-
HSQL data store - Replacement of H2 data store to remove third party
component dependency from TSDR
-
Cassandra data store - Cassandra implementation of TSDR SPIs
-
NetFlow data collector - Collect NetFlow data from network elements
-
NetFlowV9 - version 9 Netflow collector
-
sFlowCollector - Collects sFlow data from network elements
-
SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
-
Syslog data collector - Collects syslog data from network elements
-
Web Activity data collector - Collects ODL RESTCONF queries made to TSDR
TSDR has multiple features to enable the functionality above. To begin,
select one of these data stores:
-
odl-tsdr-hsqldb-all
-
odl-tsdr-hbase
-
odl-tsdr-cassandra
Then select any “collectors” you want to use:
-
odl-tsdr-openflow-statistics-collector
-
odl-tsdr-netflow-statistics-collector
-
odl-tsdr-sflow-statistics-collector
-
odl-tsdr-controller-metrics-collector
-
odl-tsdr-snmp-data-collector
-
odl-tsdr-syslog-collector
-
odl-tsdr-restconf-collector
Enable ElasticSearch support:
-
odl-tsdr-elasticsearch
See these
TSDR_Directions
for more information.
Provides a central server to coordinate encrypted communications between
endpoints. Its client-side agent informs the controller about its encryption
capabilities and can be instructed to encrypt select flows based on business
policies.
A possible use case is encrypting controller-to-controller communications;
however, the framework is very flexible, and client side software is available
for multiple platforms and device types, enabling USC and OpenDaylight to
centralize the coordination of encryption across a wide array of endpoint and
device types.
Provides multi-tenant virtual network on an SDN controller, allowing you to
define the network with a look and feel of a conventional L2/L3 network. Once
the network is designed on VTN, it automatically maps into the underlying
physical network and is then configured on the individual switch, leveraging
the SDN control protocol.
By defining a logical plane with VTN, you can conceal the complexity of the
underlying network and better manage network resources to reduce network
configuration time and errors.
