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 The Beryllium 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 OpenDaylight Beryllium 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 Beryllium 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, as offered
 207   in the Lithium release
 208
 209 * Network Virtualization User interface for DLUX
 210
 211 OpenFlow Configuration Protocol (OF-CONFIG)
 212 ===========================================
 213 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.
 214
 215 OpenFlow plugin
 216 ===============
 217 Supports connecting to OpenFlow-enabled network devices via the OpenFlow
 218 specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
 219
 220 In addition to support for the core OpenFlow specification, OpenDaylight
 221 Beryllium also includes preliminary support for the Table Type Patterns and
 222 OF-CONFIG specifications.
 223
 224 Path Computation Element Protocol (PCEP)
 225 ========================================
 226 Is a southbound plugin that provides support for performing Create, Read,
 227 Update, and Delete (CRUD) operations on Multiprotocol Label Switching (MPLS)
 228 tunnels in the underlying network.
 229
 230 Secure Network Bootstrapping Interface (SNBi)
 231 =============================================
 232 Leverages manufacturer-installed IEEE 802.1AR certificates to secure initial
 233 communications for a zero-touch approach to bootstrapping using Docker. SNBi
 234 devices and controllers automatically do the following:
 235
 236 #. Discover each other, which includes:
 237
 238    a. Revealing the physical topology of the network
 239    #. Exposing each type of a device
 240    #. Assigning the domain for each device
 241
 242 #. Get assigned an IP-address
 243 #. Establish secure IP connectivity
 244
 245 SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
 246 network functions within a network device, including individual network element
 247 services, such as:
 248
 249 * Performance measurement
 250 * Traffic-sniffing functionality
 251 * Traffic transformation functionality
 252
 253 SNBi also provides a Linux side abstraction layer to forward elements as well
 254 as enhancements to feature the abstraction and bootstrapping infrastructure.
 255 You can also use the device type and domain information to initiate controller
 256 federation processes.
 257
 258 Service Function Chaining (SFC)
 259 ===============================
 260 Provides the ability to define an ordered list of network services (e.g.
 261 firewalls, load balancers) that are then "stitched" together in the network to
 262 create a service chain. SFC provides the chaining logic and APIs necessary for
 263 OpenDaylight to provision a service chain in the network and an end-user
 264 application for defining such chains. It includes:
 265
 266 * YANG models to express service function chains
 267 * SFC receiver for Intent expressions from REST & RPC
 268 * UI for service chain construction
 269 * LISP support
 270 * Function grouping for load balancing
 271 * OpenFlow renderer for Network Service Headers, MPLS, and VLAN
 272 * Southbound REST interface
 273 * IP Tables-based classifier for grouping packets into selected service chains
 274 * Integration with OpenDaylight GBP project
 275 * Integration with OpenDaylight OVSDB NetVirt project
 276
 277 SNMP Plugin
 278 ===========
 279 The SNMP southbound plugin allows applications acting as an SNMP Manager to
 280 interact with devices that support an SNMP agent. The SNMP plugin implements a
 281 general SNMP implementation, which differs from the SNMP4SDN as that project
 282 leverages only select SNMP features to implement the specific use case of
 283 making an SNMP-enabled device emulate some features of an OpenFlow-enabled
 284 device.
 285
 286 SNMP4SDN
 287 ========
 288 Provides a southbound SNMP plugin to optimize delivery of SDN controller
 289 benefits to traditional/legacy ethernet switches through the SNMP interface. It
 290 offers support for flow configuration on ACLs and enables flow configuration
 291 via REST API and multi-vendor support.
 292
 293 Source-Group Tag Exchange Protocol (SXP)
 294 ========================================
 295 Enables creation of a tag that allows you to filter traffic instead of using
 296 protocol-specific information like addresses and ports. Via SXP an external
 297 entity creates the tags, assigns them to traffic appropriately, and publishes
 298 information about the tags to network devices so they can enforce the tags
 299 appropriately.
 300
 301 More specifically, SXP Is an IETF-published control protocol designed to
 302 propagate the binding between an IP address and a source group, which has a
 303 unique source group tag (SGT). Within the SXP protocol, source groups with
 304 common network policies are endpoints connecting to the network. SXP updates
 305 the firewall with SGTs, enabling the firewalls to create topology-independent
 306 Access Control Lists (ACLs) and provide ACL automation.
 307
 308 SXP source groups have the same meaning as endpoint groups in OpenDaylight’s
 309 Group Based Policy (GBP), which is used to manipulate policy groups, so you can
 310 use OpenDaylight GPB with SXP SGTs. The SXP topology-independent policy
 311 definition and automation can be extended through OpenDaylight for other
 312 services and networking devices.
 313
 314 Topology Processing Framework
 315 =============================
 316 Provides a framework for simplified aggregation and topology data query to
 317 enable a unified topology view, including multi-protocol, Underlay, and
 318 Overlay resources.
 319
 320 Time Series Data Repository (TSDR)
 321 ==================================
 322 Creates a framework for collecting, storing, querying, and maintaining time
 323 series data in OpenDaylight. You can leverage various data-driven applications
 324 built on top of TSDR when you install a datastore and at least one collector.
 325
 326 Functionality of TDSR includes:
 327
 328 * Data Query Service - For external data-driven applications to query data from
 329   TSDR through REST APIs
 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 * Enhancement of existing data stores including HBase to support new features
 339   introduced in Beryllium
 340 * Cassandra data store - Cassandra implementation of TSDR SPIs
 341 * NetFlow data collector - Collect NetFlow data from network elements
 342 * NetFlowV9 - version 9 Netflow collector
 343 * SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
 344 * sFlowCollector - Collects sFlow data from network elements
 345 * Syslog data collector - Collects syslog data from network elements
 346
 347 TSDR has multiple features to enable the functionality above. To begin,
 348 select one of these data stores:
 349
 350 * odl-tsdr-hsqldb-all
 351 * odl-tsdr-hbase
 352 * odl-tsdr-cassandra
 353
 354 Then select any “collectors” you want to use:
 355
 356 * odl-tsdr-openflow-statistics-collector
 357 * odl-tsdr-netflow-statistics-collector
 358 * odl-tsdr-controller-metrics-collector
 359 * odl-tsdr-sflow-statistics-collector
 360 * odl-tsdr-snmp-data-collector
 361 * odl-tsdr-syslog-collector
 362
 363 See these TSDR_Directions_ for more information.
 364
 365 Unified Secure Channel (USC)
 366 ============================
 367 Provides a central server to coordinate encrypted communications between
 368 endpoints. Its client-side agent informs the controller about its encryption
 369 capabilities and can be instructed to encrypt select flows based on business
 370 policies.
 371
 372 A possible use case is encrypting controller-to-controller communications;
 373 however, the framework is very flexible, and client side software is available
 374 for multiple platforms and device types, enabling USC and OpenDaylight to
 375 centralize the coordination of encryption across a wide array of endpoint and
 376 device types.
 377
 378 VPN Service
 379 ===========
 380 Implements the infrastructure services required to support L3 VPN service. It
 381 initially leverages open source routing applications as pluggable components.
 382 L3 services include:
 383
 384 * The L3 VPN Manager
 385 * MP-BGP Routing Stack
 386 * MPLS Label Manager
 387 * NextHop Manager
 388 * FIB Service & Openstack Neutron Service
 389
 390 The VPN Service offers:
 391
 392 * An API for L3 VPN Services
 393 * Integration with open source routing suites, including Quagga & Ryu
 394 * OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration
 395 * OpenStack Neutron integration
 396 * VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN)
 397   project of Open Platform for NFV project (OPNFV) (available in Brahmaputra
 398   release)
 399 * Network Overlay solution necessary for a Datacenter/Cloud environment
 400
 401 Virtual Tenant Network (VTN)
 402 ============================
 403 Provides multi-tenant virtual network on an SDN controller, allowing you to
 404 define the network with a look and feel of a conventional L2/L3 network. Once
 405 the network is designed on VTN, it automatically maps into the underlying
 406 physical network and is then configured on the individual switch, leveraging
 407 the SDN control protocol.
 408
 409 By defining a logical plane with VTN, you can conceal the complexity of the
 410 underlying network and better manage network resources to reduce network
 411 configuration time and errors.
 412
 413 .. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
 414 .. _oneM2M: http://www.onem2m.org/
 415 .. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step