include::alto/alto-developer-guide.adoc[ALTO]
-include::controller/controller.adoc[Controller]
-
include::bgpcep/odl-bgpcep-bgp-all-dev.adoc[BGP]
-include::bgpcep/odl-bgpcep-pcep-all-dev.adoc[PCEP]
-
include::capwap/capwap-dev.adoc[CAPWAP]
+include::controller/controller.adoc[Controller]
+
+include::didm/didm-dev.adoc[]
+
include::dlux/dlux-core-dev.adoc[]
include::iotdm/iotdm-dev.adoc[]
-include::lacp/lacp-dev.adoc[]
-
include::l2switch/l2switch-dev.adoc[]
+include::lacp/lacp-dev.adoc[]
+
include::nic/nic-dev.adoc[]
include::neutron/neutron.adoc[]
+include::sdninterfaceapp/odl-sdninterfaceapp-all-dev.adoc[]
+
include::openflowjava/odl-openflowjava-protocol-dev.adoc[]
-include::opflex/libopflex-dev.adoc[]
+include::opflex/agent-ovs-dev.adoc[]
include::opflex/genie-dev.adoc[]
-include::opflex/agent-ovs-dev.adoc[]
+include::opflex/libopflex-dev.adoc[]
include::ovsdb/ovsdb-developer.adoc[]
+include::bgpcep/odl-bgpcep-pcep-all-dev.adoc[PCEP]
+
include::packetcable/packetcable-dev.adoc[Packet Cable PCMM Southbound Plugin]
-include::reservation/reservation-dev.adoc[]
+// commenting this out as it contains no content
+//include::reservation/reservation-dev.adoc[]
include::sfc/sfc.adoc[]
-include::sdninterfaceapp/odl-sdninterfaceapp-all-dev.adoc[]
+include::sxp/odl-sxp-dev.adoc[]
include::tcpmd5/odl-tcpmd5-all-dev.adoc[TCP-MD5]
include::usc/odl-usc-channel-dev.adoc[]
-include::didm/didm-dev.adoc[]
-
include::vtn/vtn-dev.adoc[]
-include::sxp/odl-sxp-dev.adoc[]
-
:numbered!:
///////
|===
|Setting | Description
-| yangstore.blacklist=.\*controller.model.* | This regular expression (can be OR-ed using pipe character) tells netconf to exclude the yang files found in the matching bundle symbolic name from the hello message. This is helpful when dealing with a netconf client that has parsing problems.
+| yangstore.blacklist=.\*controller.model.* | This regular expression (can be OR-ed using pipe character) tells NETCONF to exclude the yang files found in the matching bundle symbolic name from the hello message. This is helpful when dealing with a NETCONF client that has parsing problems.
| netconf.config.persister.* settings | See '_opendaylight_controller_configuration_initial'.
| netconf.tcp.address=0.0.0.0 netconf.tcp.port=8383 +
===== Persister implementation
-Configuration persister implementation is part of the Controller Netconf. PersisterAggregator class is the implementation of the Presister interface. The functionality is delegated to the storage adapters. Storage adapters are low level persisters that do the heavy lifting for this class. Instances of storage adapters can be injected directly by means of the constructor, or instantiated from a full name of its class provided in a properties file. There can be many persisters configured, and varying numbers of them can be used.
+Configuration persister implementation is part of the Controller NETCONF. PersisterAggregator class is the implementation of the Presister interface. The functionality is delegated to the storage adapters. Storage adapters are low level persisters that do the heavy lifting for this class. Instances of storage adapters can be injected directly by means of the constructor, or instantiated from a full name of its class provided in a properties file. There can be many persisters configured, and varying numbers of them can be used.
*Example of presisters configuration:* +
----
}
}
----
-==== Logback configuration: Netconf
+==== Logback configuration: NETCONF
In this case, NETCONF RPCs are used to configure logback. The Netconf server listens at port 8383. To communicate over TCP, telnet is used. More about NETCONF is available at: http://tools.ietf.org/html/rfc6241. Netconf implementation is a part of the Controller - netconf-subsystem. The RPCs of Netconf are XML, and the operations are mapped to JMX operations.
* A server re-start is required. The procedure is the same as above.
<commit/>
</rpc>]]>]]>
----
-The Netconf endpoint should respond with ok to edit-config, as well as the commit message: +
+The NETCONF endpoint should respond with ok to edit-config, as well as the commit message: +
----
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
-== OpenDaylight Controller
+== Controller
=== Overview ===
*Q-10: How can one use RESTCONF to access the MD-SAL datastore?*
*A-10:* For information on accessing the MD-SAL datastore, see
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf[MD-SAL Restconf].
+https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf[MD-SAL RESTCONF].
-=== OpenDaylight Controller MD-SAL: Restconf
+=== OpenDaylight Controller MD-SAL: RESTCONF
-==== Restconf operations overview
+==== RESCONF operations overview
-Restconf allows access to datastores in the controller. +
+RESTCONF allows access to datastores in the controller. +
There are two datastores: +
* Config: Contains data inserted via controller
* Operational: Contains other data
NOTE: Each request must start with the URI /restconf. +
-Restconf listens on port 8080 for HTTP requests.
+RESTCONF listens on port 8080 for HTTP requests.
-Restconf supports *OPTIONS*, *GET*, *PUT*, *POST*, and *DELETE* operations. Request and response data can either be in the XML or JSON format. XML structures according to yang are defined at: http://tools.ietf.org/html/rfc6020[XML-YANG]. JSON structures are defined at: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02[JSON-YANG]. Data in the request must have a correctly set *Content-Type* field in the http header with the allowed value of the media type. The media type of the requested data has to be set in the *Accept* field. Get the media types for each resource by calling the OPTIONS operation.
+RESTCONF supports *OPTIONS*, *GET*, *PUT*, *POST*, and *DELETE* operations. Request and response data can either be in the XML or JSON format. XML structures according to yang are defined at: http://tools.ietf.org/html/rfc6020[XML-YANG]. JSON structures are defined at: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02[JSON-YANG]. Data in the request must have a correctly set *Content-Type* field in the http header with the allowed value of the media type. The media type of the requested data has to be set in the *Accept* field. Get the media types for each resource by calling the OPTIONS operation.
Most of the paths of the pathsRestconf endpoints use https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Concepts#Instance_Identifier[Instance Identifier]. +<identifier>+ is used in the explanation of the operations.
*<identifier>* +
* <nodeName> can represent a data node which is a list or container yang built-in type. If the data node is a list, there must be defined keys of the list behind the data node name for example, <nodeName>/<valueOfKey1>/<valueOfKey2>.
* The format <moduleName>:<nodeName> has to be used in this case as well: +
Module A has node A1. Module B augments node A1 by adding node X. Module C augments node A1 by adding node X. For clarity, it has to be known which node is X (for example: C:X).
-For more details about encoding, see: http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3.1[Restconf 02 - Encoding YANG Instance Identifiers in the Request URI.]
+For more details about encoding, see: http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3.1[RESTCONF 02 - Encoding YANG Instance Identifiers in the Request URI.]
==== Mount point
A Node can be behind a mount point. In this case, the URI has to be in format <identifier>/*yang-ext:mount*/<identifier>. The first <identifier> is the path to a mount point and the second <identifier> is the path to a node behind the mount point. A URI can end in a mount point itself by using <identifier>/*yang-ext:mount*. +
-More information on how to actually use mountpoints is available at: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf[ OpenDaylight Controller:Config:Examples:Netconf].
+More information on how to actually use mountpoints is available at: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf[OpenDaylight Controller:Config:Examples:Netconf].
==== HTTP methods
* Removes the data node in the Config datastore and returns the state about success.
* <identifier> points to a data node which must be removed.
-More information is available in the http://tools.ietf.org/html/draft-bierman-netconf-restconf-02[Restconf RFC].
+More information is available in the http://tools.ietf.org/html/draft-bierman-netconf-restconf-02[RESTCONF RFC].
-==== How Restconf works
-Restconf uses these base classes: +
+==== How RESTCONF works
+RESTCONF uses these base classes: +
InstanceIdentifier:: Represents the path in the data tree
ConsumerSession:: Used for invoking RPCs
image::Get.png[width=500]
. The requested URI is translated into the InstanceIdentifier which points to the data node. During this translation, the DataSchemaNode that conforms to the data node is obtained. If the data node is behind the mount point, the MountInstance is obtained as well.
-. Restconf asks for the value of the data node from DataBrokerService based on InstanceIdentifier.
+. RESTCONF asks for the value of the data node from DataBrokerService based on InstanceIdentifier.
. DataBrokerService returns CompositeNode as data.
. StructuredDataToXmlProvider or StructuredDataToJsonProvider is called based on the *Accept* field from the http request. These two providers can transform CompositeNode regarding DataSchemaNode to an XML or JSON document.
. XML or JSON is returned as the answer on the request from the client.
. Input data is sent to JsonToCompositeNodeProvider or XmlToCompositeNodeProvider. The correct provider is selected based on the Content-Type field from the http request. These two providers can transform input data to CompositeNode. However, this CompositeNode does not contain enough information for transactions.
. The requested URI is translated into InstanceIdentifier which points to the data node. DataSchemaNode conforming to the data node is obtained during this translation. If the data node is behind the mount point, the MountInstance is obtained as well.
. CompositeNode can be normalized by adding additional information from DataSchemaNode.
-. Restconf begins the transaction, and puts CompositeNode with InstanceIdentifier into it. The response on the request from the client is the status code which depends on the result from the transaction.
+. RESTCONF begins the transaction, and puts CompositeNode with InstanceIdentifier into it. The response on the request from the client is the status code which depends on the result from the transaction.
// FIXME: Replace with coretutorials tutorial or point to openflow location
== OpenDaylight controller overview\r
\r
-The Open Daylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
+The OpenDaylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
\r
=== Background to the emergence of SDN\r
\r
\r
Central to the SDN effort is the controller which provides the ability to deploy software to control the network gear and redeploy as needed. The vision is to have a modular controller with a well published Northbound API for network applications to write towards while utilizing southbound protocols such as OpenFlow to communicate with supported downstream network nodes. The industry and end users will benefit immensely by having an OpenSource controller with contributions from various industry players.\r
\r
-The Open Daylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
+The OpenDaylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
\r
The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane.\r
\r
\r
The OSGi framework allows dynamically linking plugins for the evolving southbound protocols. The SAL provides basic services such as device discovery which is used by modules like Topology Manager to build the topology and device capabilities. Services are constructed using the features exposed by the plugins (based on the presence of a plugin and capabilities of a network device). Based on the service request, the SAL maps to the appropriate plugin and uses the most appropriate southbound protocol to interact with a given network device. Each plugin is independent of others and is loosely coupled with the SAL.\r
\r
-NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the Open Daylight controller contribution.\r
+NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the OpenDaylight controller contribution.\r
\r
=== SAL architecture\r
\r
\r
** Statistics Manager\r
\r
-* MD-SAL Netconf Connector (Southbound Netconf Plugin)\r
+* MD-SAL NETCONF Connector (Southbound NETCONF Plugin)\r
\r
-* MD-SAL Restconf Connector (Northbound Restconf Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
+* MD-SAL RESTCONF Connector (Northbound RESTCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
\r
-* Config Subsystem - Netconf/Yang based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
+* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
\r
* NSF Adapters - Network Service Function Adapter that allow the MD-SAL based OF1.0/1.3 Plugin to talk with AS-SAL based Network Service Functions\r
\r
\r
=== Using the Simple Forwarding Application\r
\r
-The OpenDaylight Controller includes an application called Simple Forwarding that lets you use the basic services for making forwarding decisions and install flows across all devices on the Openflow network. This application discovers the presence of a host via ARP message and installs dest-only /32 entries across all switches in the network, with the corresponding output ports toward the host.\r
+The OpenDaylight Controller includes an application called Simple Forwarding that lets you use the basic services for making forwarding decisions and install flows across all devices on the OpenFlow network. This application discovers the presence of a host via ARP message and installs dest-only /32 entries across all switches in the network, with the corresponding output ports toward the host.\r
\r
. With OpenDaylight Controller and Mininet running as described in previous sections, log into the web interface.\r
\r
support the APIs defined by the RPCs. There may be different Driver
implementations for different device types.
-TODO: Add more info and diagram.
-
-=== Key APIs and Interfaces
-TODO
-
-=== API Reference Documentation
-TODO: Provide links to JavaDoc, REST API documentation, etc.
+//TODO: Add more info and diagram.
+//
+//=== Key APIs and Interfaces
+//TODO
+//
+//=== API Reference Documentation
+//TODO: Provide links to JavaDoc, REST API documentation, etc.
The LAG representing the aggregated multiple physical ports
are realized in the OpenDaylight controlled switches by creating a
-group table entry (Group table supported from Openflow 1.3 onwards).
+group table entry (Group table supported from OpenFlow 1.3 onwards).
The group table entry has a group type *Select* and action referring to
the aggregated physical ports.
Any data traffic to be sent out through the LAG can be sent
is shown in the following table, please see javadoc of the specific interface
for specific details)
-.Table I*Aware Methods
+.I*Aware Methods
|===
|Create |Update |Delete
== OpenDaylight controller overview\r
\r
-The Open Daylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
+The OpenDaylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
\r
=== Background to the emergence of SDN\r
\r
\r
Central to the SDN effort is the controller which provides the ability to deploy software to control the network gear and redeploy as needed. The vision is to have a modular controller with a well published Northbound API for network applications to write towards while utilizing southbound protocols such as OpenFlow to communicate with supported downstream network nodes. The industry and end users will benefit immensely by having an OpenSource controller with contributions from various industry players.\r
\r
-The Open Daylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
+The OpenDaylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
\r
The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane.\r
\r
\r
The OSGi framework allows dynamically linking plugins for the evolving southbound protocols. The SAL provides basic services such as device discovery which is used by modules like Topology Manager to build the topology and device capabilities. Services are constructed using the features exposed by the plugins (based on the presence of a plugin and capabilities of a network device). Based on the service request, the SAL maps to the appropriate plugin and uses the most appropriate southbound protocol to interact with a given network device. Each plugin is independent of others and is loosely coupled with the SAL.\r
\r
-NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the Open Daylight controller contribution.\r
+NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the OpenDaylight controller contribution.\r
\r
=== SAL architecture\r
\r
\r
** Statistics Manager\r
\r
-* MD-SAL Netconf Connector (Southbound Netconf Plugin)\r
+* MD-SAL NETCONF Connector (Southbound RESTCONF Plugin)\r
\r
-* MD-SAL Restconf Connector (Northbound Restconf Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
+* MD-SAL RESTCONF Connector (Northbound NETCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
\r
-* Config Subsystem - Netconf/Yang based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
+* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
\r
* NSF Adapters - Network Service Function Adapter that allow the MD-SAL based OF1.0/1.3 Plugin to talk with AS-SAL based Network Service Functions\r
\r
Basic API / SPI classes are ConnectionAdapter (Rpc/notifications) and
SwitchConnectionProcider (configure, start, shutdown)
-=== API Reference Documentation
-Provide links to JavaDoc, REST API documentation, etc. [TBD]
+//=== API Reference Documentation
+//Provide links to JavaDoc, REST API documentation, etc. [TBD]
=== Installation ===
Pull the code and import project into your IDE.
Creates channel processing pipeline based on configuration and support.
.TCP Channel pipeline
-image::openflowjava/500px-TCPChannelPipeline.png["TCP Channel pipeline"]
+imageopenflowjava/500px-TCPChannelPipeline.png[width=500]
.Switch Connection Provider
Implementation of connection point for other projects. Library exposes its
see above).
.UDP Channel pipeline
-image::openflowjava/500px-UdpChannelPipeline.png["UDP Channel pipeline"]
+image::openflowjava/500px-UdpChannelPipeline.png[width=500]
.UDP Handler
* [11] Plugin shutdowns the Library when desired
.Library lifecycle
-image::openflowjava/Library_lifecycle.png["Library lifecycle"]
+image::openflowjava/Library_lifecycle.png[width=500]
=== Statistics collection
OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTIONS instructions.
.Deserialization scenario walkthrough
-image::openflowjava/800px-Extensibility.png["Deserialization scenario walkthrough"]
+image::openflowjava/800px-Extensibility.png[width=500]
==== Detailed walkthrough: Serialization extensibility
.External interface & class description
be able to process OFPIT_WRITE_ACTIONS/OFPIT_APPLY_ACTIONS instructions.
.Serialization scenario walkthrough
-image::openflowjava/800px-Extensibility2.png["Serialization scenario walkthrough"]
+image::openflowjava/800px-Extensibility2.png[width=500]
==== Internal description
that are shown in table below:
.*Deserialization*
-[options="header,footer"]
+[options="header",cols="20%,10%,40%,30%"]
|========================================================================================================================================================
|Extension type |OpenFlow|Registration key |Utility class
|Vendor message |1.0 |ExperimenterIdDeserializerKey(1, experimenterId, ExperimenterMessage.class) |ExperimenterDeserializerKeyFactory
.*Serialization*
-[options="header,footer"]
+[options="header",cols="20%,10%,40%,30%"]
|=============================================================================================================================================================
|Extension type |OpenFlow|Registration key |Utility class
|Vendor message |1.0 |ExperimenterIdSerializerKey<>(1, experimenterId, ExperimenterInput.class) |ExperimenterSerializerKeyFactory
-include::ovsdb-openstack-developer.adoc[]
-
include::ovsdb-southbound-developer.adoc[]
+
+include::ovsdb-openstack-developer.adoc[]
[[packetcable-components]]
=== Packetcable Components
-packetcable is comprised of three OpendayLight bundles
+packetcable is comprised of three OpenDaylight bundles
[options=="header"]
|========================================================================
===== flow_config_perf_pcmm.py
For load testing there is this nice tool that could be repurpose to load
-test a CMTS. TODO: Adapt this script for load testing PCMM on a CMTS.
+test a CMTS.
+//TODO: Adapt this script for load testing PCMM on a CMTS.
[[yang-ide]]
==== Yang-IDE
(defaults to )
opendaylight-user@root> wrapper:install
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/bin/karaf-wrapper
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/bin/karaf-service
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/etc/karaf-wrapper.conf
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/lib/libwrapper.so
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/lib/karaf-wrapper.jar
-Creating file: /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/lib/karaf-wrapper-main.jar
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-wrapper
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-service
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/etc/karaf-wrapper.conf
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/libwrapper.so
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/karaf-wrapper.jar
+Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/karaf-wrapper-main.jar
Setup complete. You may wish to tweak the JVM properties in the wrapper configuration file:
-/home/user/odl/distribution-karaf-0.2.0-Helium-RC0/etc/karaf-wrapper.conf
+/home/user/odl/distribution-karaf-0.3.0-Lithium/etc/karaf-wrapper.conf
before installing and starting the service.
Ubuntu/Debian Linux system detected:
To install the service:
- $ ln -s /home/user/odl/distribution-karaf-0.2.0-Helium-RC0/bin/karaf-service /etc/init.d/
+ $ ln -s /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-service /etc/init.d/
To start the service when the machine is rebooted:
$ update-rc.d karaf-service defaults
include::odl-sfc-sf-scheduler-dev.adoc[Service Function selection scheduler]
-include::odl-sfc-sf-monitoring-dev.adoc[Service Function Monitoring]
+// Commented out because it has no content
+//include::odl-sfc-sf-monitoring-dev.adoc[Service Function Monitoring]
Main logic and core features
=== API Reference Documentation
-https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf[Restconf Interface and Dynamic Tree]
+https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf[RESTCONF Interface and Dynamic Tree]
methods. Otherwise the framework communicates via requests and outputs stored
in DataStores.
-=== API Reference Documentation
-Provide links to JavaDoc, REST API documentation, etc. [TBD]
+//=== API Reference Documentation
+//Provide links to JavaDoc, REST API documentation, etc. [TBD]
==== Java Bindings
-TODO: Provide a link to JavaDoc.
+//TODO: Provide a link to JavaDoc.
As stated above there are 3 locations where a Table Type Pattern can be
placed into the MD-SAL Data Store. They correspond to 3 different REST
After clicking Refresh headers, we can see that a new header
(+Authorization+) has been created and this will allow us to
-authenticate to make the rest call.
+authenticate to make the REST call.
.PUTting a TTP
image::ttp-screen3-sent-put.png[width=500]
* Network and Sub-Network Create:
Whenever a new sub network is created, VTN Manager will handle the same and create a vbridge under the VTN.
* VM Creation in openstack:
- The interface mentioned as integration bridge in the configuration file, will be added with more interfaces on creation of a new VM in OpenStack and network is provisioned for it by VTN neutron bundle. The addition of new PORT is captured by VTN Manager and it creates a vbridge interface with port mapping for the particular port.Now, when the VM starts to communicate with other VM's created, VTN Manger will install flows in the OVS and other openflow switches to facilitate communication between VM(s).
+ The interface mentioned as integration bridge in the configuration file, will be added with more interfaces on creation of a new VM in OpenStack and network is provisioned for it by VTN neutron bundle. The addition of new PORT is captured by VTN Manager and it creates a vbridge interface with port mapping for the particular port.Now, when the VM starts to communicate with other VM's created, VTN Manger will install flows in the OVS and other OpenFlow switches to facilitate communication between VM(s).
NOTE:
To use this feature, VTN feature should be installed
For VTN Coordinator REST API, please refer: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
==== VTN Manager
-An OpenDaylight Controller Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the Openstack L2 Network Functions API.
+An OpenDaylight Controller Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
===== Function Outline
| VTN Manager |RESTful API | Configure VTN Virtualization model components in OpenDaylight
| VTN Manager | Neutron API implementation | Handle Networks API from OpenStack (Neutron Interface)
| VTN Coordinator | RESTful API |
-(1) Uses the Restful interface of VTN Manager and configures VTN Virtualization model components in OpenDaylight. +
+(1) Uses the RESTful interface of VTN Manager and configures VTN Virtualization model components in OpenDaylight. +
(2) Handles multiple controller orchestration. +
(3) Provides API to read the physical network details. See https://wiki.OpenDaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:L2_Network_Example_Using_VTN_Virtualization[samples] for usage.
Code Review / docs.git / commitdiff