1 OpenDaylight Karaf Features
2 ===========================
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.
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:
19 * Support for persistent data stores
20 * Federation and SSO with OpenStack Keystone
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.
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:
31 #. Network Map Service - Provides batch information to ALTO clients in the forms
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
38 #. Endpoint Cost Service - Allows an ALTO server to return costs directly
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.
46 Border Gateway Monitoring Protocol (BMP)
47 ----------------------------------------
48 Is a southbound plugin that provides support for BGP Monitoring Protocol as a
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
60 Creates a repository called the Unified-Security Plugin (USecPlugin) to provide
61 controller security information to northbound applications, such as the
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
68 Information collected at the plugin may also be used to configure firewalls and create IP blacklists for the network.
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.
80 Web based OpenDaylight user interface that includes:
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
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.
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:
98 * Integration with OpenStack Neutron
99 * Service Function Chaining
100 * OFOverlay support for NAT, table offsets
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
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.
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.
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
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.
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.
139 Offers four features:
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
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:
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
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.
171 OVSDB Services are at parity with the Neutron Reference Implementation in
172 OpenStack, including support for:
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
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.
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.
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
202 * Service Function Chaining
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
208 * Network Virtualization User interface for DLUX
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.
216 Supports connecting to OpenFlow-enabled network devices via the OpenFlow
217 specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
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.
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.
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:
235 #. Discover each other, which includes:
237 a. Revealing the physical topology of the network
238 #. Exposing each type of a device
239 #. Assigning the domain for each device
241 #. Get assigned an IP-address
242 #. Establish secure IP connectivity
244 SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
245 network functions within a network device, including individual network element
248 * Performance measurement
249 * Traffic-sniffing functionality
250 * Traffic transformation functionality
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.
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:
265 * YANG models to express service function chains
266 * SFC receiver for Intent expressions from REST & RPC
267 * UI for service chain construction
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
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
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.
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
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.
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.
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
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.
325 Functionality of TDSR includes:
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
331 * Data Purging Service - Periodically purges data from TSDR
332 * Data Collection Framework - Data Collection framework to allow plugging in of
333 various types of collectors
334 * HSQL data store - Replacement of H2 data store to remove third party
335 component dependency from TSDR
336 * Enhancement of existing data stores including HBase to support new features
337 introduced in Beryllium
338 * Cassandra data store - Cassandra implementation of TSDR SPIs
339 * NetFlow data collector - Collect NetFlow data from network elements
340 * SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
341 * Syslog data collector - Collects syslog data from network elements
343 TSDR has multiple features to enable the functionality above. To begin,
344 select one of these data stores:
346 * odl-tsdr-hsqldb-all
350 Then select any “collectors” you want to use:
352 * odl-tsdr-openflow-statistics-collector
353 * odl-tsdr-netflow-statistics-collector
354 * odl-tsdr-controller-metrics-collector
355 * odl-tsdr-snmp-data-collector
356 * odl-tsdr-syslog-collector
358 See these TSDR_Directions_ for more information.
360 Unified Secure Channel (USC)
361 ----------------------------
362 Provides a central server to coordinate encrypted communications between
363 endpoints. Its client-side agent informs the controller about its encryption
364 capabilities and can be instructed to encrypt select flows based on business
367 A possible use case is encrypting controller-to-controller communications;
368 however, the framework is very flexible, and client side software is available
369 for multiple platforms and device types, enabling USC and OpenDaylight to
370 centralize the coordination of encryption across a wide array of endpoint and
375 Implements the infrastructure services required to support L3 VPN service. It
376 initially leverages open source routing applications as pluggable components.
380 * MP-BGP Routing Stack
383 * FIB Service & Openstack Neutron Service
385 The VPN Service offers:
387 * An API for L3 VPN Services
388 * Integration with open source routing suites, including Quagga & Ryu
389 * OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration
390 * OpenStack Neutron integration
391 * VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN)
392 project of Open Platform for NFV project (OPNFV) (available in Brahmaputra
394 * Network Overlay solution necessary for a Datacenter/Cloud environment
396 Virtual Tenant Network (VTN)
397 ----------------------------
398 Provides multi-tenant virtual network on an SDN controller, allowing you to
399 define the network with a look and feel of a conventional L2/L3 network. Once
400 the network is designed on VTN, it automatically maps into the underlying
401 physical network and is then configured on the individual switch, leveraging
402 the SDN control protocol.
404 By defining a logical plane with VTN, you can conceal the complexity of the
405 underlying network and better manage network resources to reduce network
406 configuration time and errors.
408 .. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
409 .. _oneM2M: http://www.onem2m.org/
410 .. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
Code Review / docs.git / blob