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 NetVirt - 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 NetVirt 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   * NAT and Floating IPs
 184   * IPv6
 185   * MAC and IP learning
 186
 187 * Clustering - Full support for clustering and High Availability (HA) is
 188   available in the this OpenDaylight release. In particular, the OVSDB
 189   southbound plugin supports clustering that any application can use, and the
 190   Openstack network integration with OpenDaylight (through NetVirt) has
 191   full clustering support. While there is no specific limit on cluster size, a
 192   3-node cluster has been tested extensively as part of the release.
 193
 194 * Security Groups - Security Group support is available and implemented using
 195   OpenFlow rules that provide superior functionality and performance over
 196   OpenStack Security Groups, which use IPTables. Security Groups also provide
 197   support for ConnTrack with stateful tracking of existing connections.
 198   Contract-based Security Groups require OVS v2.5 with contract support.
 199
 200 * Hardware Virtual Tunnel End Point (HW-VTEP) - Full HW-VTEP schema support has
 201   been implemented in the OVSDB protocol driver.
 202
 203 * Hardware VTEP for hardware switches
 204
 205 * Support for OVS and DPDK-accelerated OVS data paths
 206
 207 * Service Function Chaining
 208
 209 * L3VPN (BGPVPN), EVPN, ELAN
 210
 211 * Open vSwitch southbound support for quality of service and Queue configuration
 212   Load Balancer as service (LBaaS) with Distributed Virtual Router
 213
 214 * Network Virtualization User interface for DLUX
 215
 216 OpenFlow Configuration Protocol (OF-CONFIG)
 217 ===========================================
 218 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.
 219
 220 OpenFlow plugin
 221 ===============
 222 Supports connecting to OpenFlow-enabled network devices via the OpenFlow
 223 specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
 224
 225 In addition to support for the core OpenFlow specification, OpenDaylight
 226 also includes preliminary support for the Table Type Patterns and
 227 OF-CONFIG specifications.
 228
 229 Path Computation Element Protocol (PCEP)
 230 ========================================
 231 Is a southbound plugin that provides support for performing Create, Read,
 232 Update, and Delete (CRUD) operations on Multiprotocol Label Switching (MPLS)
 233 tunnels in the underlying network.
 234
 235 Secure Network Bootstrapping Interface (SNBi)
 236 =============================================
 237 Leverages manufacturer-installed IEEE 802.1AR certificates to secure initial
 238 communications for a zero-touch approach to bootstrapping using Docker. SNBi
 239 devices and controllers automatically do the following:
 240
 241 #. Discover each other, which includes:
 242
 243    a. Revealing the physical topology of the network
 244    #. Exposing each type of a device
 245    #. Assigning the domain for each device
 246
 247 #. Get assigned an IP-address
 248 #. Establish secure IP connectivity
 249
 250 SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
 251 network functions within a network device, including individual network element
 252 services, such as:
 253
 254 * Performance measurement
 255 * Traffic-sniffing functionality
 256 * Traffic transformation functionality
 257
 258 SNBi also provides a Linux side abstraction layer to forward elements as well
 259 as enhancements to feature the abstraction and bootstrapping infrastructure.
 260 You can also use the device type and domain information to initiate controller
 261 federation processes.
 262
 263 Service Function Chaining (SFC)
 264 ===============================
 265 Provides the ability to define an ordered list of network services (e.g.
 266 firewalls, load balancers) that are then "stitched" together in the network to
 267 create a service chain. SFC provides the chaining logic and APIs necessary for
 268 OpenDaylight to provision a service chain in the network and an end-user
 269 application for defining such chains. It includes:
 270
 271 * YANG models to express service function chains
 272 * SFC receiver for Intent expressions from REST & RPC
 273 * UI for service chain construction
 274 * LISP support
 275 * Function grouping for load balancing
 276 * OpenFlow renderer for Network Service Headers, MPLS, and VLAN
 277 * Southbound REST interface
 278 * IP Tables-based classifier for grouping packets into selected service chains
 279 * Integration with OpenDaylight GBP project
 280 * Integration with OpenDaylight OVSDB NetVirt project
 281
 282 SNMP Plugin
 283 ===========
 284 The SNMP southbound plugin allows applications acting as an SNMP Manager to
 285 interact with devices that support an SNMP agent. The SNMP plugin implements a
 286 general SNMP implementation, which differs from the SNMP4SDN as that project
 287 leverages only select SNMP features to implement the specific use case of
 288 making an SNMP-enabled device emulate some features of an OpenFlow-enabled
 289 device.
 290
 291 SNMP4SDN
 292 ========
 293 Provides a southbound SNMP plugin to optimize delivery of SDN controller
 294 benefits to traditional/legacy ethernet switches through the SNMP interface. It
 295 offers support for flow configuration on ACLs and enables flow configuration
 296 via REST API and multi-vendor support.
 297
 298 Source-Group Tag Exchange Protocol (SXP)
 299 ========================================
 300 Enables creation of a tag that allows you to filter traffic instead of using
 301 protocol-specific information like addresses and ports. Via SXP an external
 302 entity creates the tags, assigns them to traffic appropriately, and publishes
 303 information about the tags to network devices so they can enforce the tags
 304 appropriately.
 305
 306 More specifically, SXP Is an IETF-published control protocol designed to
 307 propagate the binding between an IP address and a source group, which has a
 308 unique source group tag (SGT). Within the SXP protocol, source groups with
 309 common network policies are endpoints connecting to the network. SXP updates
 310 the firewall with SGTs, enabling the firewalls to create topology-independent
 311 Access Control Lists (ACLs) and provide ACL automation.
 312
 313 SXP source groups have the same meaning as endpoint groups in OpenDaylight’s
 314 Group Based Policy (GBP), which is used to manipulate policy groups, so you can
 315 use OpenDaylight GPB with SXP SGTs. The SXP topology-independent policy
 316 definition and automation can be extended through OpenDaylight for other
 317 services and networking devices.
 318
 319 Topology Processing Framework
 320 =============================
 321 Provides a framework for simplified aggregation and topology data query to
 322 enable a unified topology view, including multi-protocol, Underlay, and
 323 Overlay resources.
 324
 325 Time Series Data Repository (TSDR)
 326 ==================================
 327 Creates a framework for collecting, storing, querying, and maintaining time
 328 series data in OpenDaylight. You can leverage various data-driven applications
 329 built on top of TSDR when you install a datastore and at least one collector.
 330
 331 Functionality of TDSR includes:
 332
 333 * Data Query Service - For external data-driven applications to query data from
 334   TSDR through REST APIs
 335 * ElasticSearch - Use external elastic search engine with TSDR integrated support.
 336 * NBI integration with Grafana - Allows visualization of data collected in TSDR
 337   using Grafana
 338 * Data Aggregation Service - Periodically aggregates raw data into larger time granularities
 339 * Data Purging Service - Periodically purges data from TSDR
 340 * Data Collection Framework - Data Collection framework to allow plugging in of
 341   various types of collectors
 342 * HSQL data store - Replacement of H2 data store to remove third party
 343   component dependency from TSDR
 344 * Cassandra data store - Cassandra implementation of TSDR SPIs
 345 * NetFlow data collector - Collect NetFlow data from network elements
 346 * NetFlowV9 - version 9 Netflow collector
 347 * sFlowCollector - Collects sFlow data from network elements
 348 * SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
 349 * Syslog data collector - Collects syslog data from network elements
 350 * Web Activity data collector - Collects ODL RESTCONF queries made to TSDR
 351
 352 TSDR has multiple features to enable the functionality above. To begin,
 353 select one of these data stores:
 354
 355 * odl-tsdr-hsqldb-all
 356 * odl-tsdr-hbase
 357 * odl-tsdr-cassandra
 358
 359 Then select any “collectors” you want to use:
 360
 361 * odl-tsdr-openflow-statistics-collector
 362 * odl-tsdr-netflow-statistics-collector
 363 * odl-tsdr-sflow-statistics-collector
 364 * odl-tsdr-controller-metrics-collector
 365 * odl-tsdr-snmp-data-collector
 366 * odl-tsdr-syslog-collector
 367 * odl-tsdr-restconf-collector
 368
 369 Enable ElasticSearch support:
 370
 371 * odl-tsdr-elasticsearch
 372
 373 See these TSDR_Directions_ for more information.
 374
 375 Unified Secure Channel (USC)
 376 ============================
 377 Provides a central server to coordinate encrypted communications between
 378 endpoints. Its client-side agent informs the controller about its encryption
 379 capabilities and can be instructed to encrypt select flows based on business
 380 policies.
 381
 382 A possible use case is encrypting controller-to-controller communications;
 383 however, the framework is very flexible, and client side software is available
 384 for multiple platforms and device types, enabling USC and OpenDaylight to
 385 centralize the coordination of encryption across a wide array of endpoint and
 386 device types.
 387
 388 Virtual Tenant Network (VTN)
 389 ============================
 390 Provides multi-tenant virtual network on an SDN controller, allowing you to
 391 define the network with a look and feel of a conventional L2/L3 network. Once
 392 the network is designed on VTN, it automatically maps into the underlying
 393 physical network and is then configured on the individual switch, leveraging
 394 the SDN control protocol.
 395
 396 By defining a logical plane with VTN, you can conceal the complexity of the
 397 underlying network and better manage network resources to reduce network
 398 configuration time and errors.
 399
 400 .. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
 401 .. _oneM2M: http://www.onem2m.org/
 402 .. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step