docs/getting-started-guide/karaf_features.rst

   1 OpenDaylight Karaf Features
   2 ===========================
   3
   4 This section provides brief descriptions of the most commonly used Karaf
   5 features developed by OpenDaylight project teams. They are presented in
   6 alphabetical order. OpenDaylight installation instructions and a feature table
   7 that lists installation commands and compatibility follow.
   8
   9 .. contents::
  10    :depth: 1
  11    :local:
  12
  13 AAA
  14 ---
  15 Standards-compliant Authentication, Authorization and Accounting Services.
  16 RESTCONF is the most common consumer of AAA, which installs the AAA features
  17 automatically.  AAA provides:
  18
  19 * Support for persistent data stores
  20 * Federation and SSO with OpenStack Keystone
  21
  22 The Beryllium release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore.
  23
  24 ALTO
  25 ----
  26 Implements the Application-Layer Traffic Optimization (ALTO) base IETF protocol
  27 to provide network information to applications. It defines abstractions and
  28 services to enable simplified network views and network services to guide
  29 application usage of network resources and includes five services:
  30
  31 #. Network Map Service - Provides batch information to ALTO clients in the forms
  32    of ALTO network maps.
  33 #. Cost Map Service - Provides costs between defined groupings.
  34 #. Filtered Map Service - Allows ALTO clients to query an ALTO server on ALTO
  35    network maps and/or cost maps based on additional parameters.
  36 #. Endpoint Property Service - Allows ALTO clients to look up properties for
  37    individual endpoints.
  38 #. Endpoint Cost Service - Allows an ALTO server to return costs directly
  39    amongst endpoints.
  40
  41 Border Gateway Protocol (including Link-state Distribution (BGP)
  42 ----------------------------------------------------------------
  43 Is a southbound plugin that provides support for Border Gateway Protocol
  44 (including Link-state Distribution) as a source of L3 topology information.
  45
  46 Border Gateway Monitoring Protocol (BMP)
  47 ----------------------------------------
  48 Is a southbound plugin that provides support for BGP Monitoring Protocol as a
  49 monitoring station.
  50
  51 Control and Provisioning of Wireless Access Points (CAPWAP)
  52 -----------------------------------------------------------
  53 Enables OpenDaylight to manage CAPWAP-compliant wireless termination point (WTP)
  54 network devices. Intelligent applications, e.g., radio planning, can be
  55 developed by tapping into the operational states made available via REST APIs of
  56 WTP network devices.
  57
  58 Controller Shield
  59 -----------------
  60 Creates a repository called the Unified-Security Plugin (USecPlugin) to provide
  61 controller security information to northbound applications, such as the
  62 following:
  63
  64 * Collating the source of different attacks reported in southbound plugins
  65 * Gathering information on suspected controller intrusions and trusted
  66   controllers in the network
  67
  68 Information collected at the plugin may also be used to configure firewalls and create IP blacklists for the network.
  69
  70 Device Identification and Driver Management (DIDM)
  71 --------------------------------------------------
  72 Provides device-specific functionality, which means that code enabling a feature
  73 understands the capability and limitations of the device it runs on. For
  74 example, configuring VLANs and adjusting FlowMods are features, and there may be
  75 different implementations for different device types. Device-specific
  76 functionality is implemented as Device Drivers.
  77
  78 DLUX
  79 ----
  80 Web based OpenDaylight user interface that includes:
  81
  82 * An MD-SAL flow viewer
  83 * Network topology visualizer
  84 * A tool box and YANG model that execute queries and visualize the YANG tree
  85
  86 Fabric as a Service (FaaS)
  87 --------------------------
  88 Creates a common abstraction layer on top of a physical network so northbound
  89 APIs or services can be more easily mapped onto the physical network as a
  90 concrete device configuration.
  91
  92 Group Based Policy (GBP)
  93 ------------------------
  94 Defines an application-centric policy model for OpenDaylight that separates
  95 information about application connectivity requirements from information about
  96 the underlying details of the network infrastructure. Provides support for:
  97
  98 * Integration with OpenStack Neutron
  99 * Service Function Chaining
 100 * OFOverlay support for NAT, table offsets
 101
 102 Internet of Things Data Management (IoTDM)
 103 ------------------------------------------
 104 Developing a data-centric middleware to act as a oneM2M_-compliant IoT Data
 105 Broker (IoTDB) and enable authorized applications to retrieve IoT data uploaded
 106 by any device.
 107
 108 Link Aggregation Control Protocol (LACP)
 109 ----------------------------------------
 110 LACP can auto-discover and aggregate multiple links between an
 111 OpenDaylight-controlled network and LACP-enabled endpoints or switches.
 112
 113 Location Identifier Separation Protocol (LISP) Flow Mapping Service (LISP)
 114 --------------------------------------------------------------------------
 115 LISP (RFC6830) enables separation of Endpoint Identity (EID) from Routing
 116 Location (RLOC) by defining an overlay in the EID space, which is mapped to the
 117 underlying network in the RLOC space.
 118
 119 *LISP Mapping Service* provides the EID-to-RLOC mapping information, including
 120 forwarding policy (load balancing, traffic engineering, and so on) to LISP
 121 routers for tunneling and forwarding purposes. The LISP Mapping Service can
 122 serve the mapping data to data plane nodes as well as to OpenDaylight
 123 applications.
 124
 125 To leverage this service, a northbound API allows OpenDaylight applications and
 126 services to define the mappings and policies in the LISP Mapping Service. A
 127 southbound LISP plugin enables LISP data plane devices to interact with
 128 OpenDaylight via the LISP protocol.
 129
 130 NEMO
 131 ----
 132 Is a Domain Specific Language (DSL) for the abstraction of network models and
 133 identification of operation patterns. NEMO enables network users/applications to
 134 describe their demands for network resources, services, and logical operations
 135 in an intuitive way that can be explained and executed by a language engine.
 136
 137 NETCONF
 138 -------
 139 Offers four features:
 140
 141 * odl-netconf-mdsal: NETCONF Northbound for MD-SAL and applications
 142 * odl-netconf-connector: NETCONF Southbound plugin - configured through the
 143   configuration subsystem
 144 * odl-netconf-topology: NETCONF Southbound plugin - configured through the
 145   MD-SAL configuration datastore
 146 * odl-restconf: RESTCONF Northbound for MD-SAL and applications
 147
 148 NetIDE
 149 ------
 150 Enables portability and cooperation inside a single network by using a
 151 client/server multi-controller architecture. It provides an interoperability
 152 layer allowing SDN Applications written for other SDN Controllers to run on
 153 OpenDaylight. NetIDE details:
 154
 155 * Architecture follows a client/server model: other SDN controllers represent
 156   clients with OpenDaylight acting as the server.
 157 * OpenFlow v1.0/v1.3 is the only southbound protocol supported in this initial
 158   release. We are planning for other southbound protocols in later releases.
 159 * The developer documentation contains the protocol specifications required for
 160   developing plugins for other client SDN controllers.
 161 * The NetIDE Configuration file contains the configurable elements for the
 162   engine.
 163
 164 OVSDB-based Network Virtualization Services
 165 -------------------------------------------
 166 Several services and plugins in OpenDaylight work together to provide simplified
 167 integration with the OpenStack Neutron framework. These services enable
 168 OpenStack to offload network processing to OpenDaylight while enabling
 169 OpenDaylight to provide enhanced network services to OpenStack.
 170
 171 OVSDB Services are at parity with the Neutron Reference Implementation in
 172 OpenStack, including support for:
 173
 174 * L2/L3
 175
 176   * The OpenDaylight Layer-3 Distributed Virtual Router is fully on par with
 177     what OpenStack offers and now provides completely decentralized Layer 3
 178     routing for OpenStack. ICMP rules for responding on behalf of the L3 router
 179     are fully distributed as well.
 180   * Full support for distributed Layer-2 switching and distributed IPv4 routing
 181     is now available.
 182
 183 * Clustering - Full support for clustering and High Availability (HA) is
 184   available in the OpenDaylight Beryllium release. In particular, the OVSDB
 185   southbound plugin supports clustering that any application can use, and the
 186   Openstack network integration with OpenDaylight (through OVSDB Net-Virt) has
 187   full clustering support. While there is no specific limit on cluster size, a
 188   3-node cluster has been tested extensively as part of the Beryllium release.
 189
 190 * Security Groups - Security Group support is available and implemented using
 191   OpenFlow rules that provide superior functionality and performance over
 192   OpenStack Security Groups, which use IPTables. Security Groups also provide
 193   support for ConnTrack with stateful tracking of existing connections.
 194   Contract-based Security Groups require OVS v2.5 with contract support.
 195
 196 * Hardware Virtual Tunnel End Point (HW-VTEP) - Full HW-VTEP schema support has
 197   been implemented in the OVSDB protocol driver.  Support for HW-VTEP via
 198   OpenStack through the OVSDB-NetVirt implementation has not yet been provided
 199   as we wait for full support of Layer-2 Gateway (L2GW) to be implemented within
 200   OpenStack.
 201
 202 * Service Function Chaining
 203
 204 * Open vSwitch southbound support for quality of service and Queue configuration
 205   Load Balancer as service (LBaaS) with Distributed Virtual Router, as offered
 206   in the Lithium release
 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 Beryllium 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 * NBI integration with Grafana - Allows visualization of data collected in TSDR
 330   using Grafana
 331 * Data Aggregation Service - Periodically aggregates raw data into larger time granularities
 332 * Data Purging Service - Periodically purges data from TSDR
 333 * Data Collection Framework - Data Collection framework to allow plugging in of
 334   various types of collectors
 335 * HSQL data store - Replacement of H2 data store to remove third party
 336   component dependency from TSDR
 337 * Enhancement of existing data stores including HBase to support new features
 338   introduced in Beryllium
 339 * Cassandra data store - Cassandra implementation of TSDR SPIs
 340 * NetFlow data collector - Collect NetFlow data from network elements
 341 * NetFlowV9 - version 9 Netflow collector
 342 * SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
 343 * sFlowCollector - Collects sFlow data from network elements
 344 * Syslog data collector - Collects syslog data from network elements
 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-controller-metrics-collector
 358 * odl-tsdr-sflow-statistics-collector
 359 * odl-tsdr-snmp-data-collector
 360 * odl-tsdr-syslog-collector
 361
 362 See these TSDR_Directions_ for more information.
 363
 364 Unified Secure Channel (USC)
 365 ----------------------------
 366 Provides a central server to coordinate encrypted communications between
 367 endpoints. Its client-side agent informs the controller about its encryption
 368 capabilities and can be instructed to encrypt select flows based on business
 369 policies.
 370
 371 A possible use case is encrypting controller-to-controller communications;
 372 however, the framework is very flexible, and client side software is available
 373 for multiple platforms and device types, enabling USC and OpenDaylight to
 374 centralize the coordination of encryption across a wide array of endpoint and
 375 device types.
 376
 377 VPN Service
 378 -----------
 379 Implements the infrastructure services required to support L3 VPN service. It
 380 initially leverages open source routing applications as pluggable components.
 381 L3 services include:
 382
 383 * The L3 VPN Manager
 384 * MP-BGP Routing Stack
 385 * MPLS Label Manager
 386 * NextHop Manager
 387 * FIB Service & Openstack Neutron Service
 388
 389 The VPN Service offers:
 390
 391 * An API for L3 VPN Services
 392 * Integration with open source routing suites, including Quagga & Ryu
 393 * OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration
 394 * OpenStack Neutron integration
 395 * VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN)
 396   project of Open Platform for NFV project (OPNFV) (available in Brahmaputra
 397   release)
 398 * Network Overlay solution necessary for a Datacenter/Cloud environment
 399
 400 Virtual Tenant Network (VTN)
 401 ----------------------------
 402 Provides multi-tenant virtual network on an SDN controller, allowing you to
 403 define the network with a look and feel of a conventional L2/L3 network. Once
 404 the network is designed on VTN, it automatically maps into the underlying
 405 physical network and is then configured on the individual switch, leveraging
 406 the SDN control protocol.
 407
 408 By defining a logical plane with VTN, you can conceal the complexity of the
 409 underlying network and better manage network resources to reduce network
 410 configuration time and errors.
 411
 412 .. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
 413 .. _oneM2M: http://www.onem2m.org/
 414 .. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step