From: Colin Dixon Date: Sun, 28 Jun 2015 02:36:27 +0000 (-0400) Subject: First complete pass over the developer guide X-Git-Tag: release/lithium-sr1~23 X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=commitdiff_plain;h=57e967a0b4783fba6741c29fa97c4aa83f06a001;p=docs.git First complete pass over the developer guide * Alphabetized chapters * Fixed minor formatting isssues * Removed TODOs, TBDs, and TBAs * Common errors around Openflow vs. OpenFlow, Openstack vs. OpenStack and the like. Change-Id: I296f55549d4ec6c9756b30a49319e43a326cd4be Signed-off-by: Colin Dixon --- diff --git a/manuals/developer-guide/src/main/asciidoc/bk-developers-guide.adoc b/manuals/developer-guide/src/main/asciidoc/bk-developers-guide.adoc index 629888bf9..93cd74bfe 100644 --- a/manuals/developer-guide/src/main/asciidoc/bk-developers-guide.adoc +++ b/manuals/developer-guide/src/main/asciidoc/bk-developers-guide.adoc @@ -52,43 +52,48 @@ include::section_Hacking_from_CLI.adoc[] 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] @@ -100,12 +105,8 @@ include::ttp/ttp-cli-tools-dev.adoc[] include::usc/odl-usc-channel-dev.adoc[] -include::didm/didm-dev.adoc[] - include::vtn/vtn-dev.adoc[] -include::sxp/odl-sxp-dev.adoc[] - :numbered!: /////// diff --git a/manuals/developer-guide/src/main/asciidoc/controller/config-initial.adoc b/manuals/developer-guide/src/main/asciidoc/controller/config-initial.adoc index 1664316f8..2f768ed5e 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/config-initial.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/config-initial.adoc @@ -27,7 +27,7 @@ Various parts of the system that are not under the configuration subsystem use t |=== |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 + @@ -441,7 +441,7 @@ As a part of the configuration subsystem, the purpose of the persister is to sav ===== 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:* + ---- diff --git a/manuals/developer-guide/src/main/asciidoc/controller/config-logback.adoc b/manuals/developer-guide/src/main/asciidoc/controller/config-logback.adoc index b37a1aed9..b6a902ba1 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/config-logback.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/config-logback.adoc @@ -237,7 +237,7 @@ Now, the runtime bean status attribute will be empty: } } ---- -==== 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. diff --git a/manuals/developer-guide/src/main/asciidoc/controller/config-threadpool.adoc b/manuals/developer-guide/src/main/asciidoc/controller/config-threadpool.adoc index d31104c18..1606ff35d 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/config-threadpool.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/config-threadpool.adoc @@ -135,7 +135,7 @@ The response containing the current configuration: + ]]>]]> ---- -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: + ---- diff --git a/manuals/developer-guide/src/main/asciidoc/controller/controller.adoc b/manuals/developer-guide/src/main/asciidoc/controller/controller.adoc index 8bcbd57c2..30155e94d 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/controller.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/controller.adoc @@ -1,4 +1,4 @@ -== OpenDaylight Controller +== Controller === Overview === diff --git a/manuals/developer-guide/src/main/asciidoc/controller/md-sal-faq.adoc b/manuals/developer-guide/src/main/asciidoc/controller/md-sal-faq.adoc index 1b78133e9..8143dbf66 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/md-sal-faq.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/md-sal-faq.adoc @@ -266,4 +266,4 @@ However, if you want to, you can create your own REST API (for example, to be *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]. diff --git a/manuals/developer-guide/src/main/asciidoc/controller/restconf.adoc b/manuals/developer-guide/src/main/asciidoc/controller/restconf.adoc index 113682268..ec07e1d5b 100644 --- a/manuals/developer-guide/src/main/asciidoc/controller/restconf.adoc +++ b/manuals/developer-guide/src/main/asciidoc/controller/restconf.adoc @@ -1,17 +1,17 @@ -=== 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]. ++ is used in the explanation of the operations. ** + @@ -20,11 +20,11 @@ Most of the paths of the pathsRestconf endpoints use https://wiki.opendaylight.o * 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, //. * The format : 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 /*yang-ext:mount*/. The first is the path to a mount point and the second is the path to a node behind the mount point. A URI can end in a mount point itself by using /*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 @@ -144,10 +144,10 @@ NOTE: Even though this is a default for the toasterToastType value in the yang, * Removes the data node in the Config datastore and returns the state about success. * 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 @@ -167,7 +167,7 @@ Figure 1 shows the GET operation with URI restconf/config/M:N where M is the mod 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. @@ -183,7 +183,7 @@ image::Put.png[width=500] . 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 diff --git a/manuals/developer-guide/src/main/asciidoc/core/odl-controller-controller-overview.adoc b/manuals/developer-guide/src/main/asciidoc/core/odl-controller-controller-overview.adoc index 0bd376a63..1fed2b118 100644 --- a/manuals/developer-guide/src/main/asciidoc/core/odl-controller-controller-overview.adoc +++ b/manuals/developer-guide/src/main/asciidoc/core/odl-controller-controller-overview.adoc @@ -1,6 +1,6 @@ == OpenDaylight controller overview -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). +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). === Background to the emergence of SDN @@ -24,7 +24,7 @@ SDN consists of a network applications layer on the top written to open API. The 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. -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. +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. The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane. @@ -63,7 +63,7 @@ image::SAL.jpg[title="Framework of SAL", alt="Framework of SAL"] 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. -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. +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. === SAL architecture @@ -207,11 +207,11 @@ The following are the OpenDaylight modules. See the relevant sections for an ove ** Statistics Manager -* MD-SAL Netconf Connector (Southbound Netconf Plugin) +* MD-SAL NETCONF Connector (Southbound NETCONF Plugin) -* MD-SAL Restconf Connector (Northbound Restconf Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller +* MD-SAL RESTCONF Connector (Northbound RESTCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller -* Config Subsystem - Netconf/Yang based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller +* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller * 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 diff --git a/manuals/developer-guide/src/main/asciidoc/core/using_mininet.adoc b/manuals/developer-guide/src/main/asciidoc/core/using_mininet.adoc index 35181535e..a26757ef1 100644 --- a/manuals/developer-guide/src/main/asciidoc/core/using_mininet.adoc +++ b/manuals/developer-guide/src/main/asciidoc/core/using_mininet.adoc @@ -93,7 +93,7 @@ $ sudo mn -c === Using the Simple Forwarding Application -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. +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. . With OpenDaylight Controller and Mininet running as described in previous sections, log into the web interface. diff --git a/manuals/developer-guide/src/main/asciidoc/didm/didm-dev.adoc b/manuals/developer-guide/src/main/asciidoc/didm/didm-dev.adoc index 74a0bcf3f..21e463add 100644 --- a/manuals/developer-guide/src/main/asciidoc/didm/didm-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/didm/didm-dev.adoc @@ -33,10 +33,10 @@ The DIDM project creates the infrastructure to support the following functions: 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. diff --git a/manuals/developer-guide/src/main/asciidoc/lacp/lacp-dev.adoc b/manuals/developer-guide/src/main/asciidoc/lacp/lacp-dev.adoc index cd8abcf90..81a5c1de8 100644 --- a/manuals/developer-guide/src/main/asciidoc/lacp/lacp-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/lacp/lacp-dev.adoc @@ -35,7 +35,7 @@ switches using OpenFlow 1.3+ group table functionality. 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 diff --git a/manuals/developer-guide/src/main/asciidoc/neutron/neutron.adoc b/manuals/developer-guide/src/main/asciidoc/neutron/neutron.adoc index 9632cdfbd..7b7976f46 100644 --- a/manuals/developer-guide/src/main/asciidoc/neutron/neutron.adoc +++ b/manuals/developer-guide/src/main/asciidoc/neutron/neutron.adoc @@ -17,7 +17,7 @@ I*Aware interface defines a pair of calls (The general template 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 diff --git a/manuals/developer-guide/src/main/asciidoc/odl-controller-controller-overview.adoc b/manuals/developer-guide/src/main/asciidoc/odl-controller-controller-overview.adoc index 0bd376a63..8123077e2 100644 --- a/manuals/developer-guide/src/main/asciidoc/odl-controller-controller-overview.adoc +++ b/manuals/developer-guide/src/main/asciidoc/odl-controller-controller-overview.adoc @@ -1,6 +1,6 @@ == OpenDaylight controller overview -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). +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). === Background to the emergence of SDN @@ -24,7 +24,7 @@ SDN consists of a network applications layer on the top written to open API. The 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. -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. +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. The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane. @@ -63,7 +63,7 @@ image::SAL.jpg[title="Framework of SAL", alt="Framework of SAL"] 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. -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. +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. === SAL architecture @@ -207,11 +207,11 @@ The following are the OpenDaylight modules. See the relevant sections for an ove ** Statistics Manager -* MD-SAL Netconf Connector (Southbound Netconf Plugin) +* MD-SAL NETCONF Connector (Southbound RESTCONF Plugin) -* MD-SAL Restconf Connector (Northbound Restconf Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller +* MD-SAL RESTCONF Connector (Northbound NETCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller -* Config Subsystem - Netconf/Yang based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller +* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller * 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 diff --git a/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc b/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc index c4a025c9a..ff4ed2463 100644 --- a/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc @@ -40,8 +40,8 @@ configured in openflowjava-config/src/main/resources/45-openflowjava-stats.xml 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. @@ -208,7 +208,7 @@ and documented (e.g using MacAddress instead of byte array...) 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 @@ -353,7 +353,7 @@ fulfill the same role as in case of TCP connection / channel pipeline (please see above). .UDP Channel pipeline -image::openflowjava/500px-UdpChannelPipeline.png["UDP Channel pipeline"] +image::openflowjava/500px-UdpChannelPipeline.png[width=500] .UDP Handler @@ -442,7 +442,7 @@ communication * [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 @@ -671,7 +671,7 @@ deserializers. For example +IntructionsDeserializer+ needs access to 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 @@ -725,7 +725,7 @@ For example IntructionsSerializer needs access to ActionsSerializer in order to 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 @@ -765,7 +765,7 @@ Openflow v1.3. These extensions are registered under registration keys, 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 @@ -793,7 +793,7 @@ table below: .*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 diff --git a/manuals/developer-guide/src/main/asciidoc/ovsdb/ovsdb-developer.adoc b/manuals/developer-guide/src/main/asciidoc/ovsdb/ovsdb-developer.adoc index 19a5f29c8..bb8955b05 100644 --- a/manuals/developer-guide/src/main/asciidoc/ovsdb/ovsdb-developer.adoc +++ b/manuals/developer-guide/src/main/asciidoc/ovsdb/ovsdb-developer.adoc @@ -1,4 +1,4 @@ -include::ovsdb-openstack-developer.adoc[] - include::ovsdb-southbound-developer.adoc[] + +include::ovsdb-openstack-developer.adoc[] diff --git a/manuals/developer-guide/src/main/asciidoc/packetcable/packetcable-dev.adoc b/manuals/developer-guide/src/main/asciidoc/packetcable/packetcable-dev.adoc index 7bc69bbde..e2297c2c3 100644 --- a/manuals/developer-guide/src/main/asciidoc/packetcable/packetcable-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/packetcable/packetcable-dev.adoc @@ -24,7 +24,7 @@ specification. PacketCable solution is an MDSAL compliant component. [[packetcable-components]] === Packetcable Components -packetcable is comprised of three OpendayLight bundles +packetcable is comprised of three OpenDaylight bundles [options=="header"] |======================================================================== @@ -80,7 +80,8 @@ what kind of flows are interesting for use cases. Multicast? ===== 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 @@ -312,21 +313,21 @@ OPTIONS (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 diff --git a/manuals/developer-guide/src/main/asciidoc/sfc/sfc.adoc b/manuals/developer-guide/src/main/asciidoc/sfc/sfc.adoc index 97c532ab8..d5d3b2aee 100644 --- a/manuals/developer-guide/src/main/asciidoc/sfc/sfc.adoc +++ b/manuals/developer-guide/src/main/asciidoc/sfc/sfc.adoc @@ -12,5 +12,6 @@ include::odl-sfc-load-balance-dev.adoc[Service Function Grouping and Load Balanc 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] diff --git a/manuals/developer-guide/src/main/asciidoc/sxp/odl-sxp-dev.adoc b/manuals/developer-guide/src/main/asciidoc/sxp/odl-sxp-dev.adoc index d37ea5d80..ad59f4d51 100644 --- a/manuals/developer-guide/src/main/asciidoc/sxp/odl-sxp-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/sxp/odl-sxp-dev.adoc @@ -36,5 +36,5 @@ Contains data holders and entiies 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] diff --git a/manuals/developer-guide/src/main/asciidoc/topoprocessing/odl-topoprocessing-framework-dev.adoc b/manuals/developer-guide/src/main/asciidoc/topoprocessing/odl-topoprocessing-framework-dev.adoc index 334c381e0..27ca2e40f 100644 --- a/manuals/developer-guide/src/main/asciidoc/topoprocessing/odl-topoprocessing-framework-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/topoprocessing/odl-topoprocessing-framework-dev.adoc @@ -33,5 +33,5 @@ Basic Provider class is TopoProcessingProvider which provides startup and shutdo 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] diff --git a/manuals/developer-guide/src/main/asciidoc/ttp/ttp-model-dev.adoc b/manuals/developer-guide/src/main/asciidoc/ttp/ttp-model-dev.adoc index b38ec343f..084215be1 100644 --- a/manuals/developer-guide/src/main/asciidoc/ttp/ttp-model-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/ttp/ttp-model-dev.adoc @@ -33,7 +33,7 @@ APIs. ==== 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 @@ -468,7 +468,7 @@ image::ttp-screen2-applied-basic-auth.png[width=500] 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] diff --git a/manuals/developer-guide/src/main/asciidoc/vtn/OpenStack_Support-dev.adoc b/manuals/developer-guide/src/main/asciidoc/vtn/OpenStack_Support-dev.adoc index 9fc316cb5..c908fd06f 100644 --- a/manuals/developer-guide/src/main/asciidoc/vtn/OpenStack_Support-dev.adoc +++ b/manuals/developer-guide/src/main/asciidoc/vtn/OpenStack_Support-dev.adoc @@ -43,7 +43,7 @@ It subscribes to the events from OVS and also implements the neutron requests re * 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 diff --git a/manuals/developer-guide/src/main/asciidoc/vtn/vtn-overview.adoc b/manuals/developer-guide/src/main/asciidoc/vtn/vtn-overview.adoc index 3d3cc16d5..fb0152d79 100644 --- a/manuals/developer-guide/src/main/asciidoc/vtn/vtn-overview.adoc +++ b/manuals/developer-guide/src/main/asciidoc/vtn/vtn-overview.adoc @@ -82,7 +82,7 @@ VTN Coordinator doesn't have Karaf features. 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 @@ -94,7 +94,7 @@ The table identifies the functions and the interface used by VTN Components: | 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.