X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2Fgetting-started-guide%2Fkaraf_features.rst;h=3c7ad93e39c53e6269dbd00d1d91325b29c348df;hb=1d2d1381a50ced9a2f31c8f8110a907a1f208331;hp=65d0cea01a123e917380e10474172f445d0f4ef7;hpb=ef597f1ec8d248b01260aca5be8eabee80bfd8e3;p=docs.git diff --git a/docs/getting-started-guide/karaf_features.rst b/docs/getting-started-guide/karaf_features.rst index 65d0cea01..3c7ad93e3 100644 --- a/docs/getting-started-guide/karaf_features.rst +++ b/docs/getting-started-guide/karaf_features.rst @@ -1,5 +1,6 @@ +*************************** OpenDaylight Karaf Features -=========================== +*************************** This section provides brief descriptions of the most commonly used Karaf features developed by OpenDaylight project teams. They are presented in @@ -11,7 +12,7 @@ that lists installation commands and compatibility follow. :local: AAA ---- +=== Standards-compliant Authentication, Authorization and Accounting Services. RESTCONF is the most common consumer of AAA, which installs the AAA features automatically. AAA provides: @@ -19,10 +20,10 @@ automatically. AAA provides: * Support for persistent data stores * Federation and SSO with OpenStack Keystone -The Beryllium release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore. +This release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore. ALTO ----- +==== Implements the Application-Layer Traffic Optimization (ALTO) base IETF protocol to provide network information to applications. It defines abstractions and services to enable simplified network views and network services to guide @@ -39,24 +40,24 @@ application usage of network resources and includes five services: amongst endpoints. Border Gateway Protocol (including Link-state Distribution (BGP) ----------------------------------------------------------------- +================================================================ Is a southbound plugin that provides support for Border Gateway Protocol (including Link-state Distribution) as a source of L3 topology information. Border Gateway Monitoring Protocol (BMP) ----------------------------------------- +======================================== Is a southbound plugin that provides support for BGP Monitoring Protocol as a monitoring station. Control and Provisioning of Wireless Access Points (CAPWAP) ------------------------------------------------------------ +=========================================================== Enables OpenDaylight to manage CAPWAP-compliant wireless termination point (WTP) network devices. Intelligent applications, e.g., radio planning, can be developed by tapping into the operational states made available via REST APIs of WTP network devices. Controller Shield ------------------ +================= Creates a repository called the Unified-Security Plugin (USecPlugin) to provide controller security information to northbound applications, such as the following: @@ -68,7 +69,7 @@ following: Information collected at the plugin may also be used to configure firewalls and create IP blacklists for the network. Device Identification and Driver Management (DIDM) --------------------------------------------------- +================================================== Provides device-specific functionality, which means that code enabling a feature understands the capability and limitations of the device it runs on. For example, configuring VLANs and adjusting FlowMods are features, and there may be @@ -76,7 +77,7 @@ different implementations for different device types. Device-specific functionality is implemented as Device Drivers. DLUX ----- +==== Web based OpenDaylight user interface that includes: * An MD-SAL flow viewer @@ -84,13 +85,13 @@ Web based OpenDaylight user interface that includes: * A tool box and YANG model that execute queries and visualize the YANG tree Fabric as a Service (FaaS) --------------------------- +========================== Creates a common abstraction layer on top of a physical network so northbound APIs or services can be more easily mapped onto the physical network as a concrete device configuration. Group Based Policy (GBP) ------------------------- +======================== Defines an application-centric policy model for OpenDaylight that separates information about application connectivity requirements from information about the underlying details of the network infrastructure. Provides support for: @@ -100,18 +101,18 @@ the underlying details of the network infrastructure. Provides support for: * OFOverlay support for NAT, table offsets Internet of Things Data Management (IoTDM) ------------------------------------------- +========================================== Developing a data-centric middleware to act as a oneM2M_-compliant IoT Data Broker (IoTDB) and enable authorized applications to retrieve IoT data uploaded by any device. Link Aggregation Control Protocol (LACP) ----------------------------------------- +======================================== LACP can auto-discover and aggregate multiple links between an OpenDaylight-controlled network and LACP-enabled endpoints or switches. Location Identifier Separation Protocol (LISP) Flow Mapping Service (LISP) --------------------------------------------------------------------------- +========================================================================== LISP (RFC6830) enables separation of Endpoint Identity (EID) from Routing Location (RLOC) by defining an overlay in the EID space, which is mapped to the underlying network in the RLOC space. @@ -128,14 +129,14 @@ southbound LISP plugin enables LISP data plane devices to interact with OpenDaylight via the LISP protocol. NEMO ----- +==== Is a Domain Specific Language (DSL) for the abstraction of network models and identification of operation patterns. NEMO enables network users/applications to describe their demands for network resources, services, and logical operations in an intuitive way that can be explained and executed by a language engine. NETCONF -------- +======= Offers four features: * odl-netconf-mdsal: NETCONF Northbound for MD-SAL and applications @@ -146,7 +147,7 @@ Offers four features: * odl-restconf: RESTCONF Northbound for MD-SAL and applications NetIDE ------- +====== Enables portability and cooperation inside a single network by using a client/server multi-controller architecture. It provides an interoperability layer allowing SDN Applications written for other SDN Controllers to run on @@ -161,14 +162,14 @@ OpenDaylight. NetIDE details: * The NetIDE Configuration file contains the configurable elements for the engine. -OVSDB-based Network Virtualization Services -------------------------------------------- +NetVirt - Network Virtualization Services +========================================= Several services and plugins in OpenDaylight work together to provide simplified integration with the OpenStack Neutron framework. These services enable OpenStack to offload network processing to OpenDaylight while enabling OpenDaylight to provide enhanced network services to OpenStack. -OVSDB Services are at parity with the Neutron Reference Implementation in +NetVirt Services are at parity with the Neutron Reference Implementation in OpenStack, including support for: * L2/L3 @@ -179,13 +180,16 @@ OpenStack, including support for: are fully distributed as well. * Full support for distributed Layer-2 switching and distributed IPv4 routing is now available. + * NAT and Floating IPs + * IPv6 + * MAC and IP learning * Clustering - Full support for clustering and High Availability (HA) is - available in the OpenDaylight Beryllium release. In particular, the OVSDB + available in the this OpenDaylight release. In particular, the OVSDB southbound plugin supports clustering that any application can use, and the - Openstack network integration with OpenDaylight (through OVSDB Net-Virt) has + Openstack network integration with OpenDaylight (through NetVirt) has full clustering support. While there is no specific limit on cluster size, a - 3-node cluster has been tested extensively as part of the Beryllium release. + 3-node cluster has been tested extensively as part of the release. * Security Groups - Security Group support is available and implemented using OpenFlow rules that provide superior functionality and performance over @@ -194,40 +198,42 @@ OpenStack, including support for: Contract-based Security Groups require OVS v2.5 with contract support. * Hardware Virtual Tunnel End Point (HW-VTEP) - Full HW-VTEP schema support has - been implemented in the OVSDB protocol driver. Support for HW-VTEP via - OpenStack through the OVSDB-NetVirt implementation has not yet been provided - as we wait for full support of Layer-2 Gateway (L2GW) to be implemented within - OpenStack. + been implemented in the OVSDB protocol driver. + +* Hardware VTEP for hardware switches + +* Support for OVS and DPDK-accelerated OVS data paths * Service Function Chaining +* L3VPN (BGPVPN), EVPN, ELAN + * Open vSwitch southbound support for quality of service and Queue configuration - Load Balancer as service (LBaaS) with Distributed Virtual Router, as offered - in the Lithium release + Load Balancer as service (LBaaS) with Distributed Virtual Router * Network Virtualization User interface for DLUX OpenFlow Configuration Protocol (OF-CONFIG) -------------------------------------------- +=========================================== Provides a process for an Operation Context containing an OpenFlow Switch that uses OF-CONFIG to communicate with an OpenFlow Configuration Point, enabling remote configuration of OpenFlow datapaths. OpenFlow plugin ---------------- +=============== Supports connecting to OpenFlow-enabled network devices via the OpenFlow specification. It currently supports OpenFlow versions 1.0 and 1.3.2. In addition to support for the core OpenFlow specification, OpenDaylight -Beryllium also includes preliminary support for the Table Type Patterns and +also includes preliminary support for the Table Type Patterns and OF-CONFIG specifications. Path Computation Element Protocol (PCEP) ----------------------------------------- +======================================== Is a southbound plugin that provides support for performing Create, Read, Update, and Delete (CRUD) operations on Multiprotocol Label Switching (MPLS) tunnels in the underlying network. Secure Network Bootstrapping Interface (SNBi) ---------------------------------------------- +============================================= Leverages manufacturer-installed IEEE 802.1AR certificates to secure initial communications for a zero-touch approach to bootstrapping using Docker. SNBi devices and controllers automatically do the following: @@ -255,7 +261,7 @@ You can also use the device type and domain information to initiate controller federation processes. Service Function Chaining (SFC) -------------------------------- +=============================== 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 @@ -274,7 +280,7 @@ application for defining such chains. It includes: * Integration with OpenDaylight OVSDB NetVirt project SNMP Plugin ------------ +=========== 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 @@ -283,14 +289,14 @@ making an SNMP-enabled device emulate some features of an OpenFlow-enabled device. SNMP4SDN --------- +======== 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. Source-Group Tag Exchange Protocol (SXP) ----------------------------------------- +======================================== 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 @@ -311,13 +317,13 @@ definition and automation can be extended through OpenDaylight for other services and networking devices. Topology Processing Framework ------------------------------ +============================= Provides a framework for simplified aggregation and topology data query to enable a unified topology view, including multi-protocol, Underlay, and Overlay resources. Time Series Data Repository (TSDR) ----------------------------------- +================================== 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. @@ -326,6 +332,7 @@ 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 @@ -334,14 +341,13 @@ Functionality of TDSR includes: various types of collectors * HSQL data store - Replacement of H2 data store to remove third party component dependency from TSDR -* Enhancement of existing data stores including HBase to support new features - introduced in Beryllium * Cassandra data store - Cassandra implementation of TSDR SPIs * NetFlow data collector - Collect NetFlow data from network elements * NetFlowV9 - version 9 Netflow collector -* SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR * 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: @@ -354,15 +360,20 @@ Then select any “collectors” you want to use: * odl-tsdr-openflow-statistics-collector * odl-tsdr-netflow-statistics-collector -* odl-tsdr-controller-metrics-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. Unified Secure Channel (USC) ----------------------------- +============================ 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 @@ -374,31 +385,8 @@ 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. -VPN Service ------------ -Implements the infrastructure services required to support L3 VPN service. It -initially leverages open source routing applications as pluggable components. -L3 services include: - -* The L3 VPN Manager -* MP-BGP Routing Stack -* MPLS Label Manager -* NextHop Manager -* FIB Service & Openstack Neutron Service - -The VPN Service offers: - -* An API for L3 VPN Services -* Integration with open source routing suites, including Quagga & Ryu -* OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration -* OpenStack Neutron integration -* VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN) - project of Open Platform for NFV project (OPNFV) (available in Brahmaputra - release) -* Network Overlay solution necessary for a Datacenter/Cloud environment - Virtual Tenant Network (VTN) ----------------------------- +============================ 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