docs/getting-started-guide/karaf_features.rst

   1 ***************************
   2 OpenDaylight Karaf Features
   3 ***************************
   4
   5 This section provides brief descriptions of the most commonly used Karaf
   6 features developed by OpenDaylight project teams. They are presented in
   7 alphabetical order. OpenDaylight installation instructions and a feature table
   8 that lists installation commands and compatibility follow.
   9
  10 .. contents::
  11    :depth: 1
  12    :local:
  13
  14 AAA
  15 ===
  16 Standards-compliant Authentication, Authorization and Accounting Services.
  17 RESTCONF is the most common consumer of AAA, which installs the AAA features
  18 automatically.  AAA provides:
  19
  20 * Support for persistent data stores
  21 * Federation and SSO with OpenStack Keystone
  22
  23 This release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore.
  24
  25 ALTO
  26 ====
  27 Implements the Application-Layer Traffic Optimization (ALTO) base IETF protocol
  28 to provide network information to applications. It defines abstractions and
  29 services to enable simplified network views and network services to guide
  30 application usage of network resources and includes five services:
  31
  32 #. Network Map Service - Provides batch information to ALTO clients in the forms
  33    of ALTO network maps.
  34 #. Cost Map Service - Provides costs between defined groupings.
  35 #. Filtered Map Service - Allows ALTO clients to query an ALTO server on ALTO
  36    network maps and/or cost maps based on additional parameters.
  37 #. Endpoint Property Service - Allows ALTO clients to look up properties for
  38    individual endpoints.
  39 #. Endpoint Cost Service - Allows an ALTO server to return costs directly
  40    amongst endpoints.
  41
  42 Border Gateway Protocol (including Link-state Distribution (BGP)
  43 ================================================================
  44 Is a southbound plugin that provides support for Border Gateway Protocol
  45 (including Link-state Distribution) as a source of L3 topology information.
  46
  47 Border Gateway Monitoring Protocol (BMP)
  48 ========================================
  49 Is a southbound plugin that provides support for BGP Monitoring Protocol as a
  50 monitoring station.
  51
  52 Control and Provisioning of Wireless Access Points (CAPWAP)
  53 ===========================================================
  54 Enables OpenDaylight to manage CAPWAP-compliant wireless termination point (WTP)
  55 network devices. Intelligent applications, e.g., radio planning, can be
  56 developed by tapping into the operational states made available via REST APIs of
  57 WTP network devices.
  58
  59 Controller Shield
  60 =================
  61 Creates a repository called the Unified-Security Plugin (USecPlugin) to provide
  62 controller security information to northbound applications, such as the
  63 following:
  64
  65 * Collating the source of different attacks reported in southbound plugins
  66 * Gathering information on suspected controller intrusions and trusted
  67   controllers in the network
  68
  69 Information collected at the plugin may also be used to configure firewalls and create IP blacklists for the network.
  70
  71 Device Identification and Driver Management (DIDM)
  72 ==================================================
  73 Provides device-specific functionality, which means that code enabling a feature
  74 understands the capability and limitations of the device it runs on. For
  75 example, configuring VLANs and adjusting FlowMods are features, and there may be
  76 different implementations for different device types. Device-specific
  77 functionality is implemented as Device Drivers.
  78
  79 DLUX
  80 ====
  81 Web based OpenDaylight user interface that includes:
  82
  83 * An MD-SAL flow viewer
  84 * Network topology visualizer
  85 * A tool box and YANG model that execute queries and visualize the YANG tree
  86
  87 Fabric as a Service (FaaS)
  88 ==========================
  89 Creates a common abstraction layer on top of a physical network so northbound
  90 APIs or services can be more easily mapped onto the physical network as a
  91 concrete device configuration.
  92
  93 Group Based Policy (GBP)
  94 ========================
  95 Defines an application-centric policy model for OpenDaylight that separates
  96 information about application connectivity requirements from information about
  97 the underlying details of the network infrastructure. Provides support for:
  98
  99 * Integration with OpenStack Neutron
 100 * Service Function Chaining
 101 * OFOverlay support for NAT, table offsets
 102
 103 Internet of Things Data Management (IoTDM)
 104 ==========================================
 105 Developing a data-centric middleware to act as a oneM2M_-compliant IoT Data
 106 Broker (IoTDB) and enable authorized applications to retrieve IoT data uploaded
 107 by any device.
 108
 109 Link Aggregation Control Protocol (LACP)
 110 ========================================
 111 LACP can auto-discover and aggregate multiple links between an
 112 OpenDaylight-controlled network and LACP-enabled endpoints or switches.
 113
 114 Location Identifier Separation Protocol (LISP) Flow Mapping Service (LISP)
 115 ==========================================================================
 116 LISP (RFC6830) enables separation of Endpoint Identity (EID) from Routing
 117 Location (RLOC) by defining an overlay in the EID space, which is mapped to the
 118 underlying network in the RLOC space.
 119
 120 *LISP Mapping Service* provides the EID-to-RLOC mapping information, including
 121 forwarding policy (load balancing, traffic engineering, and so on) to LISP
 122 routers for tunneling and forwarding purposes. The LISP Mapping Service can
 123 serve the mapping data to data plane nodes as well as to OpenDaylight
 124 applications.
 125
 126 To leverage this service, a northbound API allows OpenDaylight applications and
 127 services to define the mappings and policies in the LISP Mapping Service. A
 128 southbound LISP plugin enables LISP data plane devices to interact with
 129 OpenDaylight via the LISP protocol.
 130
 131 NEMO
 132 ====
 133 Is a Domain Specific Language (DSL) for the abstraction of network models and
 134 identification of operation patterns. NEMO enables network users/applications to
 135 describe their demands for network resources, services, and logical operations
 136 in an intuitive way that can be explained and executed by a language engine.
 137
 138 NETCONF
 139 =======
 140 Offers four features:
 141
 142 * odl-netconf-mdsal: NETCONF Northbound for MD-SAL and applications
 143 * odl-netconf-connector: NETCONF Southbound plugin - configured through the
 144   configuration subsystem
 145 * odl-netconf-topology: NETCONF Southbound plugin - configured through the
 146   MD-SAL configuration datastore
 147 * odl-restconf: RESTCONF Northbound for MD-SAL and applications
 148
 149 NetIDE
 150 ======
 151 Enables portability and cooperation inside a single network by using a
 152 client/server multi-controller architecture. It provides an interoperability
 153 layer allowing SDN Applications written for other SDN Controllers to run on
 154 OpenDaylight. NetIDE details:
 155
 156 * Architecture follows a client/server model: other SDN controllers represent
 157   clients with OpenDaylight acting as the server.
 158 * OpenFlow v1.0/v1.3 is the only southbound protocol supported in this initial
 159   release. We are planning for other southbound protocols in later releases.
 160 * The developer documentation contains the protocol specifications required for
 161   developing plugins for other client SDN controllers.
 162 * The NetIDE Configuration file contains the configurable elements for the
 163   engine.
 164
 165 OVSDB-based Network Virtualization Services
 166 ===========================================
 167 Several services and plugins in OpenDaylight work together to provide simplified
 168 integration with the OpenStack Neutron framework. These services enable
 169 OpenStack to offload network processing to OpenDaylight while enabling
 170 OpenDaylight to provide enhanced network services to OpenStack.
 171
 172 OVSDB Services are at parity with the Neutron Reference Implementation in
 173 OpenStack, including support for:
 174
 175 * L2/L3
 176
 177   * The OpenDaylight Layer-3 Distributed Virtual Router is fully on par with
 178     what OpenStack offers and now provides completely decentralized Layer 3
 179     routing for OpenStack. ICMP rules for responding on behalf of the L3 router
 180     are fully distributed as well.
 181   * Full support for distributed Layer-2 switching and distributed IPv4 routing
 182     is now available.
 183
 184 * Clustering - Full support for clustering and High Availability (HA) is
 185   available in the this OpenDaylight release. In particular, the OVSDB
 186   southbound plugin supports clustering that any application can use, and the
 187   Openstack network integration with OpenDaylight (through OVSDB Net-Virt) has
 188   full clustering support. While there is no specific limit on cluster size, a
 189   3-node cluster has been tested extensively as part of the release.
 190
 191 * Security Groups - Security Group support is available and implemented using
 192   OpenFlow rules that provide superior functionality and performance over
 193   OpenStack Security Groups, which use IPTables. Security Groups also provide
 194   support for ConnTrack with stateful tracking of existing connections.
 195   Contract-based Security Groups require OVS v2.5 with contract support.
 196
 197 * Hardware Virtual Tunnel End Point (HW-VTEP) - Full HW-VTEP schema support has
 198   been implemented in the OVSDB protocol driver.  Support for HW-VTEP via
 199   OpenStack through the OVSDB-NetVirt implementation has not yet been provided
 200   as we wait for full support of Layer-2 Gateway (L2GW) to be implemented within
 201   OpenStack.
 202
 203 * Service Function Chaining
 204
 205 * Open vSwitch southbound support for quality of service and Queue configuration
 206   Load Balancer as service (LBaaS) with Distributed Virtual Router
 207
 208 * Network Virtualization User interface for DLUX
 209
 210 OpenFlow Configuration Protocol (OF-CONFIG)
 211 ===========================================
 212 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.
 213
 214 OpenFlow plugin
 215 ===============
 216 Supports connecting to OpenFlow-enabled network devices via the OpenFlow
 217 specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
 218
 219 In addition to support for the core OpenFlow specification, OpenDaylight
 220 also includes preliminary support for the Table Type Patterns and
 221 OF-CONFIG specifications.
 222
 223 Path Computation Element Protocol (PCEP)
 224 ========================================
 225 Is a southbound plugin that provides support for performing Create, Read,
 226 Update, and Delete (CRUD) operations on Multiprotocol Label Switching (MPLS)
 227 tunnels in the underlying network.
 228
 229 Secure Network Bootstrapping Interface (SNBi)
 230 =============================================
 231 Leverages manufacturer-installed IEEE 802.1AR certificates to secure initial
 232 communications for a zero-touch approach to bootstrapping using Docker. SNBi
 233 devices and controllers automatically do the following:
 234
 235 #. Discover each other, which includes:
 236
 237    a. Revealing the physical topology of the network
 238    #. Exposing each type of a device
 239    #. Assigning the domain for each device
 240
 241 #. Get assigned an IP-address
 242 #. Establish secure IP connectivity
 243
 244 SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
 245 network functions within a network device, including individual network element
 246 services, such as:
 247
 248 * Performance measurement
 249 * Traffic-sniffing functionality
 250 * Traffic transformation functionality
 251
 252 SNBi also provides a Linux side abstraction layer to forward elements as well
 253 as enhancements to feature the abstraction and bootstrapping infrastructure.
 254 You can also use the device type and domain information to initiate controller
 255 federation processes.
 256
 257 Service Function Chaining (SFC)
 258 ===============================
 259 Provides the ability to define an ordered list of network services (e.g.
 260 firewalls, load balancers) that are then "stitched" together in the network to
 261 create a service chain. SFC provides the chaining logic and APIs necessary for
 262 OpenDaylight to provision a service chain in the network and an end-user
 263 application for defining such chains. It includes:
 264
 265 * YANG models to express service function chains
 266 * SFC receiver for Intent expressions from REST & RPC
 267 * UI for service chain construction
 268 * LISP support
 269 * Function grouping for load balancing
 270 * OpenFlow renderer for Network Service Headers, MPLS, and VLAN
 271 * Southbound REST interface
 272 * IP Tables-based classifier for grouping packets into selected service chains
 273 * Integration with OpenDaylight GBP project
 274 * Integration with OpenDaylight OVSDB NetVirt project
 275
 276 SNMP Plugin
 277 ===========
 278 The SNMP southbound plugin allows applications acting as an SNMP Manager to
 279 interact with devices that support an SNMP agent. The SNMP plugin implements a
 280 general SNMP implementation, which differs from the SNMP4SDN as that project
 281 leverages only select SNMP features to implement the specific use case of
 282 making an SNMP-enabled device emulate some features of an OpenFlow-enabled
 283 device.
 284
 285 SNMP4SDN
 286 ========
 287 Provides a southbound SNMP plugin to optimize delivery of SDN controller
 288 benefits to traditional/legacy ethernet switches through the SNMP interface. It
 289 offers support for flow configuration on ACLs and enables flow configuration
 290 via REST API and multi-vendor support.
 291
 292 Source-Group Tag Exchange Protocol (SXP)
 293 ========================================
 294 Enables creation of a tag that allows you to filter traffic instead of using
 295 protocol-specific information like addresses and ports. Via SXP an external
 296 entity creates the tags, assigns them to traffic appropriately, and publishes
 297 information about the tags to network devices so they can enforce the tags
 298 appropriately.
 299
 300 More specifically, SXP Is an IETF-published control protocol designed to
 301 propagate the binding between an IP address and a source group, which has a
 302 unique source group tag (SGT). Within the SXP protocol, source groups with
 303 common network policies are endpoints connecting to the network. SXP updates
 304 the firewall with SGTs, enabling the firewalls to create topology-independent
 305 Access Control Lists (ACLs) and provide ACL automation.
 306
 307 SXP source groups have the same meaning as endpoint groups in OpenDaylight’s
 308 Group Based Policy (GBP), which is used to manipulate policy groups, so you can
 309 use OpenDaylight GPB with SXP SGTs. The SXP topology-independent policy
 310 definition and automation can be extended through OpenDaylight for other
 311 services and networking devices.
 312
 313 Topology Processing Framework
 314 =============================
 315 Provides a framework for simplified aggregation and topology data query to
 316 enable a unified topology view, including multi-protocol, Underlay, and
 317 Overlay resources.
 318
 319 Time Series Data Repository (TSDR)
 320 ==================================
 321 Creates a framework for collecting, storing, querying, and maintaining time
 322 series data in OpenDaylight. You can leverage various data-driven applications
 323 built on top of TSDR when you install a datastore and at least one collector.
 324
 325 Functionality of TDSR includes:
 326
 327 * Data Query Service - For external data-driven applications to query data from
 328   TSDR through REST APIs
 329 * ElasticSearch - Use external elastic search engine with TSDR integrated support.
 330 * NBI integration with Grafana - Allows visualization of data collected in TSDR
 331   using Grafana
 332 * Data Aggregation Service - Periodically aggregates raw data into larger time granularities
 333 * Data Purging Service - Periodically purges data from TSDR
 334 * Data Collection Framework - Data Collection framework to allow plugging in of
 335   various types of collectors
 336 * HSQL data store - Replacement of H2 data store to remove third party
 337   component dependency from TSDR
 338 * Cassandra data store - Cassandra implementation of TSDR SPIs
 339 * NetFlow data collector - Collect NetFlow data from network elements
 340 * NetFlowV9 - version 9 Netflow collector
 341 * sFlowCollector - Collects sFlow data from network elements
 342 * SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
 343 * Syslog data collector - Collects syslog data from network elements
 344 * Web Activity data collector - Collects ODL RESTCONF queries made to TSDR
 345
 346 TSDR has multiple features to enable the functionality above. To begin,
 347 select one of these data stores:
 348
 349 * odl-tsdr-hsqldb-all
 350 * odl-tsdr-hbase
 351 * odl-tsdr-cassandra
 352
 353 Then select any “collectors” you want to use:
 354
 355 * odl-tsdr-openflow-statistics-collector
 356 * odl-tsdr-netflow-statistics-collector
 357 * odl-tsdr-sflow-statistics-collector
 358 * odl-tsdr-controller-metrics-collector
 359 * odl-tsdr-snmp-data-collector
 360 * odl-tsdr-syslog-collector
 361 * odl-tsdr-restconf-collector
 362
 363 Enable ElasticSearch support:
 364
 365 * odl-tsdr-elasticsearch
 366
 367 See these TSDR_Directions_ for more information.
 368
 369 Unified Secure Channel (USC)
 370 ============================
 371 Provides a central server to coordinate encrypted communications between
 372 endpoints. Its client-side agent informs the controller about its encryption
 373 capabilities and can be instructed to encrypt select flows based on business
 374 policies.
 375
 376 A possible use case is encrypting controller-to-controller communications;
 377 however, the framework is very flexible, and client side software is available
 378 for multiple platforms and device types, enabling USC and OpenDaylight to
 379 centralize the coordination of encryption across a wide array of endpoint and
 380 device types.
 381
 382 Virtual Tenant Network (VTN)
 383 ============================
 384 Provides multi-tenant virtual network on an SDN controller, allowing you to
 385 define the network with a look and feel of a conventional L2/L3 network. Once
 386 the network is designed on VTN, it automatically maps into the underlying
 387 physical network and is then configured on the individual switch, leveraging
 388 the SDN control protocol.
 389
 390 By defining a logical plane with VTN, you can conceal the complexity of the
 391 underlying network and better manage network resources to reduce network
 392 configuration time and errors.
 393
 394 .. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
 395 .. _oneM2M: http://www.onem2m.org/
 396 .. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step