+++ /dev/null
-Atrium Developer Guide
-======================
-
-Overview
---------
-
-Project Atrium is an open source SDN distribution - a vertically
-integrated set of open source components which together form a complete
-SDN stack. It’s goals are threefold:
-
-- Close the large integration-gap of the elements that are needed to
- build an SDN stack - while there are multiple choices at each layer,
- there are missing pieces with poor or no integration.
-
-- Overcome a massive gap in interoperability - This exists both at the
- switch level, where existing products from different vendors have
- limited compatibility, making it difficult to connect an arbitrary
- switch and controller and at an API level, where its difficult to
- write a portable application across multiple controller platforms.
-
-- Work closely with network operators on deployable use-cases, so that
- they could download near production quality code from one location,
- and get started with functioning software defined networks on real
- hardware.
-
-Architecture
-------------
-
-The key components of Atrium BGP Peering Router Application are as
-follows:
-
-- Data Plane Switch - Data plane switch is the entity that uses flow
- table entries installed by BGP Routing Application through SDN
- controller. In the simplest form data plane switch with the installed
- flows act like a BGP Router.
-
-- OpenDaylight Controller - OpenDaylight SDN controller has many
- utility applications or plugins which are leveraged by the BGP Router
- application to manage the control plane information.
-
-- BGP Routing Application - An application running within the
- OpenDaylight runtime environment to handle I-BGP updates.
-
-- `DIDM <#_didm_developer_guide>`__ - DIDM manages the drivers specific
- to each data plane switch connected to the controller. The drivers
- are created primarily to hide the underlying complexity of the
- devices and to expose a uniform API to applications.
-
-- Flow Objectives API - The driver implementation provides a pipeline
- abstraction and exposes Flow Objectives API. This means applications
- need to be aware of only the Flow Objectives API without worrying
- about the Table IDs or the pipelines.
-
-- Control Plane Switch - This component is primarily used to connect
- the OpenDaylight SDN controller with the Quagga Soft-Router and
- establish a path for forwarding E-BGP packets to and from Quagga.
-
-- Quagga soft router - An open source routing software that handles
- E-BGP updates.
-
-Key APIs and Interfaces
------------------------
-
-BGP Routing Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The BGP Routing Configuration maintains information about its BGP
-Speakers & BGP Peers.
-
-- Configuration data about BGP speakers can be accessed from the below
- URL:
-
- ::
-
- GET http://<controller_ip>:8181/restconf/config/bgpconfig:bgpSpeakers/
-
-- Configuration data about BGP peers can be accessed from the below
- URL:
-
- ::
-
- GET http://<controller_ip>:8181/restconf/config/bgpconfig:bgpPeers/
-
-Host Service
-~~~~~~~~~~~~
-
-Host Service API contains the host specific details that can be used
-during address resolution
-
-- Host specific data can be accessed by using the below REST request:
-
- ::
-
- GET http://<controller_ip>:8181/restconf/config/hostservice-api:addresses/
-
-BGP Routing Information Base
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The BGP RIB module stores all the route information that it has learnt
-from its peers.
-
-- Routing Information Base entries can be accessed from the URL below:
-
- ::
-
- GET http://<controller_ip>:8181/restconf/operational/bgp-rib:bgp-rib/
-
-Forwarding Information Base
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Forwarding Information Base is used to keep track of active FIB
-entries.
-
-- FIB entries can be accessed from the URL below:
-
- ::
-
- GET http://<controller_ip>:8181/restconf/config/routingservice-api:fibEntries/
-
:maxdepth: 1
alto-developer-guide
- atrium-developer-guide
bgp-developer-guide
bgp-monitoring-protocol-developer-guide
capwap-developer-guide
l2switch-developer-guide
lacp-developer-guide
../user-guide/lisp-flow-mapping-user-guide
- natapp-developer-guide
nemo-developer-guide
netconf-developer-guide
network-intent-composition-(nic)-developer-guide
../submodules/netvirt/docs/developer-guide/index
neutron-service-developer-guide
neutron-northbound
- next-developer-guide
odl-parent-developer-guide
ocp-plugin-developer-guide
odl-sdni-developer-guide
pcep-developer-guide
packetcable-developer-guide
service-function-chaining
- snbi-developer-guide
snmp4sdn-developer-guide
sxp-developer-guide
topology-processing-framework-developer-guide
ttp-cli-tools-developer-guide
uni-manager-plug-in-developer-guide
unified-secure-channel
- usecplugin-aaa-developer-guide
- usecplugin-openflow-developer-guide
virtual-tenant-network-(vtn)
yang-tools
yang-push-developer-guide
+++ /dev/null
-NATApp Developer Guide
-======================
-
-Overview
---------
-
-NATApp acts as a basic framework for providing NAT functionality to the
-SDN controller. One can use REST or Java APIs to enter global IP address
-into YANG Data Store which will be used by the odl-natapp-feature to map
-local IP to global IP addresses.
-
-NATApp Architecture
--------------------
-
-NATApp listens on OpenFlow southbound interface for Packet\_In messages.
-The application parses the message for header information. If the
-received message has a local IP address the application installs rules
-on the OpenFlow switch for network address translation from local to
-global IP addresses. NATApp has NATPacketHandler class that implements
-the PacketProcessing interface to override the OnPacketReceived
-notification by which the application is notified of Packet\_In
-messages.
-
-NATApp is implemented with the help of a few java classes.
-
-1. NATPacketHandler
-
- - Receives Packet\_In messages coming to the controller and process
- them appropriately
-
-2. NATPacketParsing
-
- - Decodes Packet\_In messages for packet header information (L2, L3
- & L4 information)
-
-3. NATInventoryUtility
-
- - Decodes Packet\_In messages for OpenFlow Switch and Port
- information
-
-4. NATFlowBuilder
-
- - Creates NAT flow rules at the OpenFlow Switch
-
-5. NATYangStore
-
- - Reads Global IP entered by user and maps local IP to Global IP
- information
-
-6. NATFlowHandler
-
- - Manages expired flows in the switch and frees up used global IP
- address for future natting.
-
-Key APIs and Interfaces
------------------------
-
-1. RPC APIs
-
- - Static - Configure Static Natting Functionality
-
- - Dynamic - Configure Static Dynamic Functionality
-
- - PAT - Configure PAT Functionality
-
-2. DataStore APIs
-
- - StaticNatIp - Configure floating IP addresses for Static Natting
-
- - StaticIpMapInfo - Mapped Information between floating and private
- IP addresses in Static Natting
-
- - DynamicNatIp - Configure floating IP addresses for Dynamic Natting
-
- - DynamicIpMapInfo - Mapped Information between floating and private
- IP addresses in Dynamic Natting
-
- - PatIp - Configure floating IP addresses for Port Address
- Translation
-
- - PatIpMapInfo - Mapped Information between TCP Port numbers of
- floating IP and private IP addresses
-
-3. Notification APIs
-
- - DynamicIPExhaustion - Exhaustion of Dynamic Global IP Addresses
-
- - PatOverConnection - More than 10 TCP or UDP connections from one
- private IP address
-
+++ /dev/null
-NeXt Developer Guide
-====================
-
-Please see the NeXt documentation and tutorials here: https://github.com/NeXt-UI/next-tutorials
-
+++ /dev/null
-SNBI Developer Guide
-====================
-
-Overview
---------
-
-Key distribution in a scaled network has always been a challenge.
-Typically, operators must perform some manual key distribution process
-before secure communication is possible between a set of network
-devices. The Secure Network Bootstrapping Infrastructure (SNBI) project
-securely and automatically brings up an integrated set of network
-devices and controllers, simplifying the process of bootstrapping
-network devices with the keys required for secure communication. SNBI
-enables connectivity to the network devices by assigning unique IPv6
-addresses and bootstrapping devices with the required keys. Admission
-control of devices into a specific domain is achieved using whitelist of
-authorized devices.
-
-SNBI Architecture
------------------
-
-At a high level, SNBI architecture consists of the following components:
-
-- SNBI Registrar
-
-- SNBI Forwarding Element (FE)
-
-.. figure:: ./images/snbi/snbi_arch.png
- :alt: SNBI Architecture Diagram
-
- SNBI Architecture Diagram
-
-SNBI Registrar
-~~~~~~~~~~~~~~
-
-Registrar is a device in a network that validates device against a
-whitelist and delivers device domain certificate. Registrar includes the
-following:
-
-- RESTCONF API for Domain Whitelist Configuration
-
-- Certificate Authority
-
-- SNBI Southbound Plugin
-
-**RESTCONF API for Domain Whitelist Configuration:.**
-
-RESTCONF APIs are used to configure the whitelist set device in the
-registrar in the controller. The registrar interacts with the MD-SAL to
-obtain the whitelist set of devices and validate the device trying to
-join a domain. Furthermore it is possible to run multiple registrar
-instances pertaining to each domain.
-
-**SNBI Southbound Plugin:.**
-
-The Southbound Plugin implements the protocol state machine necessary to
-exchange device identifiers, and deliver certificates. The southbound
-plugin interacts with MD-SAL and the certificate authority to validate
-and create device domain certificates. The device domain certificate
-thus generated could be used to prove the validity of the devices within
-the domain.
-
-**Certificate Authority:.**
-
-A simple certificate authority is implemented using the Bouncy Castle
-package. The Certificate Authority creates the certificates from the
-device CSR requests received from the devices. The certificates thus
-generated are delievered to the devices using the Southbound Plugin as
-discussed earlier.
-
-SNBI Forwarding Element (FE)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The SNBI Forwarding Element runs on Linux machines which have to join
-the domain. The Device UDI(Universal Device Identifier) or the device
-identifier could be derived from a multitude of parameters in the host
-machine, but most of the parameters derived from the host are known
-ahead or doesn’t remain constant across reloads. Therefore, each of the
-SNBI FE should be configured explicitly with a UDI that is already
-present in the device white list. The registrar service IP address must
-be provided to the first host (Forwarding Element) to be bootstrapped.
-As mentioned in the `section\_title <#_host_configuration>`__ section,
-the registrar service IP address is **fd08::aaaa:bbbb:1**. The First
-Forwarding Element must be configured with this IPv6 address.
-
-The forwarding element must be installed or unpacked on a Linux host
-whose network layer traffic must be secured. The FE performs the
-following functions:
-
-- Neighour Discovery
-
-- Bootstrapping with device domain certificates
-
-- Host Configuration
-
-Neighbour Discovery
-^^^^^^^^^^^^^^^^^^^
-
-Neighbour Discovery (ND) is the first step in accommodating devices in a
-secure network. SNBI performs periodic neighbour discovery of SNBI
-agents by transmitting ND hello packets. The discovered devices are
-populated in an ND table. Neighbour Discovery is periodic and
-bidirectional. ND hello packets are transmitted every 10 seconds. A 40
-second refresh timer is set for each discovered neighbour. On expiry of
-the refresh timer, the Neighbour Adjacency is removed from the ND table
-as the Neighbour Adjacency is no longer valid. It is possible that the
-same SNBI neighbour is discovered on multiple links, the expiry of a
-device on one link does not automatically remove the device entry from
-the ND table. In the exchange of ND keepalives, the device UDI is
-exchanged.
-
-Bootstrapping with Device Domain Certificates
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Bootstrapping a device involves the following sequential steps:
-
-- Authenticate a device using device identifier (UDI-Universal Device
- Identifier or SUDI-Secure Universal Device Identifier) - The device
- identifier is exchanged in the hello messages.
-
-- Allocate the appropriate device ID and IPv6 address to uniquely
- identify the device in the network
-
-- Allocate the required keys by installing a Device Domain Certificate
-
-- Accommodate the device in the domain
-
-A device which is already bootstrapped acts as a proxy to bootstrap the
-new device which is trying to join the domain.
-
-- Neighbour Invite phase - When a proxy device detects a new neighbor
- bootStrap connect message is initiated on behalf of the New device
- --**NEIGHBOUR CONNECT** Msg. The message is sent to the registrar to
- authenticate the device UDI against the whitelist of devices. The
- source IPv6 address is the proxy IPv6 address and the destination
- IPv6 address is the registrar IPv6 address. The SNBI Registrar
- provides appropriate device ID and IPv6 address to uniquely identify
- the device in the network and then invites the device to join the
- domain. — \ **NEIGHBOUR INVITE** Msg.
-
-- Neighbour Reject - If the Device UDI is not in the white list of
- devices, then the device is rejected and is not accepted into the
- domain. The proxy device just updates its DB with the reject
- information but still maintains the Neighbour relationship.
-
-- Neighbour BootStrap Phase - Once the new device gets a neighbour
- invite message, it tries to boot strap itself by generating a key
- pair. The device generates a Certificate Sign Request (CSR) PKCS10
- request and gets it signed by the CA running at the SNBI
- Registrar. — \ **BS REQ** Msg. Once the certificate is enrolled and
- signed by the CA, the generated x.509 certificate is returned to the
- new device to complete the bootstrap process. — \ **BS RESP** Msg.
-
-Host Configuration
-~~~~~~~~~~~~~~~~~~
-
-Host configuration involves configuring a host to create a secure
-overlay network, assigning appropriate IPv6 address, setting up GRE
-tunnels, securing the tunnels traffic via IPsec and enabling
-connectivity via a routing protocol. Docker is used to package all the
-required dependent software modules.
-
-.. figure:: ./images/snbi/first_fe_bs.png
- :alt: SNBI Bootstrap Process
-
- SNBI Bootstrap Process
-
-- Interace configuration: The Iproute2 package, which comes by default
- packaged in the Linux distributions, is used to configure the
- required interface (snbi-fe) and assign the appropriate IPv6 address.
-
-- GRE Tunnel Creation: LinkLocal GRE tunnels are created to each of the
- discovered devices that are part of the domain. The GRE tunnels are
- used to create the overlay network for the domain.
-
-- Routing over the Overlay: To enable reachability of devices within
- the overlay network a light weight routing protocol is used. The
- routing protocol of choice is the RPL (Routing Protocol for Low-Power
- and Lossy Networks) protocol. The routing protocol advertises the
- device domain IPv6 address over the overlay network. **Unstrung** is
- the open source implementation of RPL and is packaged within the
- docker image. More details on unstrung is available at
- http://unstrung.sandelman.ca/
-
-- IPsec: IPsec is used to secure any traffic routed over the tunnels.
- StrongSwan is used to encrypt traffic using IPsec. More details on
- StrongSwan is available at https://www.strongswan.org/
-
-Docker Image
-~~~~~~~~~~~~
-
-The SNBI Forwarding Element is packaged in a docker container available
-at this link: https://hub.docker.com/r/snbi/boron/. For more information
-on docker, refer to this link: https://docs.docker.com/linux/.
-
-To update an SNBI FE Daemon, build the image and copy the image to
-/home/snbi directory. When the docker image is run, it autoamtically
-generates a startup configuration file for the SNBI FE daemon. The
-startup configuration script is also available at /home/snbi.
-
-.. figure:: ./images/snbi/docker_snbi.png
- :alt: SNBI Docker Image
-
- SNBI Docker Image
-
-Key APIs and Interfaces
------------------------
-
-The only API that SNBI exposes is to configure the whitelist of devices
-for a domain.
-
-The POST method below configures a domain - "secure-domain" and
-configures a whitelist set of devices to be accommodated to the domain.
-
-::
-
- {
- "snbi-domain": {
- "domain-name": "secure-domain",
- "device-list": [
- {
- "list-name": "demo list",
- "list-type": "white",
- "active": true,
- "devices": [
- {
- "device-id": "UDI-FirstFE"
- },
- {
- "device-id": "UDI-dev1"
- },
- {
- "device-id": "UDI-dev2"
- }
- ]
- }
- ]
- }
- }
-
-The associated device ID must be configured on the SNBI FE (see above).
-
-API Reference Documentation
----------------------------
-
-See the generated RESTCONF API documentation at:
-http://localhost:8181/apidoc/explorer/index.html
-
-Look for the SNBI module to expand and see the various RESTCONF APIs.
-
+++ /dev/null
-Usecplugin-AAA Developer Guide
-==============================
-
-Overview
---------
-
-Usecplugin-AAA provides security related information for the AAA
-northbound interface.
-
-Usecplugin-AAA Architecture
----------------------------
-
-AAA plugin creates log messages about successful and failed login
-attempts to OpenDaylight. Usecplugin-AAA continuously reads this log
-file and checks for either successful and failed attempt information.
-Whenever Usecpluin-AAA identifies a new attempt entry in the log file it
-is stored in YANG Data Store and its own log file.
-
-Usecplugin-AAA is implemented with the help of a few java classes.
-
-UsecpluginAAAProvider
- Provider class for Usecplugin-AAA feature implementation.
-
-UsecpluginAAANotifImpl
- Logs notification information which can be seen by log:display at
- the Karaf terminal
-
-UsecpluginAAARPCImpl
- Implements Usecplugin RPCs
-
-UsecpluginAAAParsingLog
- Parses OpenDaylight log information for identifying login attempts.
-
-UsecpluginAAAPublishNotif
- Publishes failed login attempt notification.
-
-UsecpluginAAAStore
- Creates login information at the YANG Data Store.
-
-Key APIs and Interfaces
------------------------
-
-- RPC APIs
-
- Login Attempt from IP
- Returns Time and Type of Attempts (Success or Failure)
-
- Login Attempt at Time
- Returns Attempter IP Address and Type of Attempts (Success or
- Failure)
-
-- Notification APIs
-
- On Invalid Login Attempt
- Notification generated on Invalid Login Attempt
-
-- YANG Data Store APIs
-
- Get Login Attempts
- Returns Source IP address of Attempter with Time of Attempts and
- Type of Attempts (Success or Failure)
-
+++ /dev/null
-Usecplugin-OpenFlow Developer Guide
-===================================
-
-Overview
---------
-
-Usecplugin-OpenFlow provides security related information for the
-OpenFlow southbound interface.
-
-Usecplugin-OpenFlow Architecture
---------------------------------
-
-Usecplugin-OpenFlow listens on OpenFlow southbound interface for
-Packet\_In messages. The application parses the message for header
-information. Usecplugin-OpenFlow has PacketHandler class that implements
-the PacketProcessing interface to override the OnPacketReceived
-notification by which the application is notified of Packet\_In
-messages.
-
-Usecplugin-OpenFlow is implemented with the help of a few java classes.
-
-UsecpluginProvider
- Provider class for Usecplugin-OpenFlow feature implementation.
-
-PacketHandler
- Receives Packet\_In messages coming to the controller and process
- them appropriately
-
-PacketParsing
- Decodes Packet\_In messages for packet header information (L2, L3 &
- L4 information)
-
-InventoryUtility
- Decodes Packet\_In messages for OpenFlow Switch and Port information
-
-UsecpluginNotifImpl
- Logs notification information which can be seen by log:display at
- the Karaf terminal
-
-UsecpluginRPCImpl
- Implements Usecplugin RPCs
-
-UsecpluginStore
- Stores attack information into YANG Data Store and log file.
-
-Key APIs and Interfaces
------------------------
-
-- RPC APIs
-
- Attacks from DPID
- Number of OpenFlow Packet\_In Attacks from Switch with DeviceID
-
- Attacks from Host
- Number of OpenFlow Packet\_In Attacks from SrcIP Address
-
- Attacks to Server
- Number of OpenFlow Packet\_In Attacks to DstIP Address
-
- Attacks at Time of Day
- Number of OpenFlow Packet\_In Attacks at a Particular Time with a
- variable Window Time
-
-- Notification APIs
-
- On Low Water Mark Breached
- Notification generated on breaching Low Water Mark
-
+++ /dev/null
-YANG-PUSH Developer Guide
-=========================
-
-Overview
---------
-
-The YANG PUBSUB project allows subscriptions to be placed on targeted
-subtrees of YANG datastores residing on remote devices. Changes in YANG
-objects within the remote subtree can be pushed to an OpenDaylight
-controller as specified without a requiring the controller to make a
-continuous set of fetch requests.
-
-YANG-PUSH capabilities available
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This module contains the base code which embodies the intent of
-YANG-PUSH requirements for subscription as defined in
-{i2rs-pub-sub-requirements}
-[https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/].
-The mechanism for delivering on these YANG-PUSH requirements over
-Netconf transport is defined in {netconf-yang-push} [netconf-yang-push:
-https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00].
-
-Note that in the current release, not all capabilities of
-draft-ietf-netconf-yang-push are realized. Currently only implemented is
-**create-subscription** RPC support from
-ietf-datastore-push@2015-10-15.yang; and this will be for periodic
-subscriptions only. There of course is intent to provide much additional
-functionality in future OpenDaylight releases.
-
-Future YANG-PUSH capabilities
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Over time, the intent is to flesh out more robust capabilities which
-will allow OpenDaylight applications to subscribe to YANG-PUSH compliant
-devices. Capabilities for future releases will include:
-
-Support for subscription change/delete: **modify-subscription** rpc
-support for all mountpoint devices or particular mountpoint device
-**delete-subscription** rpc support for all mountpoint devices or
-particular mountpoint device
-
-Support for static subscriptions: This will enable the receipt of
-subscription updates pushed from publishing devices where no signaling
-from the controller has been used to establish the subscriptions.
-
-Support for additional transports: NETCONF is not the only transport of
-interest to OpenDaylight or the subscribed devices. Over time this code
-will support Restconf and HTTP/2 transport requirements defined in
-{netconf-restconf-yang-push}
-[https://tools.ietf.org/html/draft-voit-netconf-restconf-yang-push-01]
-
-YANG-PUSH Architecture
-----------------------
-
-The code architecture of Yang push consists of two main elements
-
-YANGPUSH Provider YANGPUSH Listener
-
-YANGPUSH Provider receives create-subscription requests from
-applications and then establishes/registers the corresponding listener
-which will receive information pushed by a publisher. In addition,
-YANGPUSH Provider also invokes an augmented OpenDaylight
-create-subscription RPC which enables applications to register for
-notification as per rfc5277. This augmentation adds periodic time period
-(duration) and subscription-id values to the existing RPC parameters.
-The Java package supporting this capability is
-“org.opendaylight.yangpush.impl”. Below class supports the YANGPUSH
-Provider capability:
-
-(1) YangpushDomProvider The Binding Independent version. It uses a
-neutral data Document Object Model format for data and API calls, which
-is independent of any generated Java language bindings from the YANG
-model.
-
-The YANGPUSH Listener accepts update notifications from a device after
-they have been de-encapsulated from the NETCONF transport. The YANGPUSH
-Listener then passes these updates to MD-SAL. This function is
-implemented via the YangpushDOMNotificationListener class within the
-“org.opendaylight.yangpush.listner” Java package.
-
-Key APIs and Interfaces
------------------------
-
-YangpushDomProvider
-~~~~~~~~~~~~~~~~~~~
-
-Central to this is onSessionInitiated which acquires the Document Object
-Model format based versions of MD-SAL services, including the MountPoint
-service and RPCs. Via these acquired services, invoke
-registerDataChangeListener over in YangpushDOMNotificationListener.
-
-YangpushDOMNotificationListener
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This API handles instances of a received Push Updates which are inbound
-to the listener and places these in MD-SAL. Key classes in include:
-
-onPushUpdate Converts and validates the encoding of the pushed
-subscription update. If the subscription exists and is active, calls
-updateDataStoreForPushUpdate so that the information can be put in
-MD-SAL. Finally logs the pushed subscription update as well as some
-additional context information.
-
-updateDataStoreForPushUpdate Used to put the published information into
-MD-SAL. This pushed information will also include elements such as the
-subscription-id, the identity of the publisher, the time of the update,
-the incoming encoding type, and the pushed YANG subtree information.
-
-YangpushDOMNotificationListener Starts the listener tracking a new
-Subscription ID from a particular publisher.
-
-API Reference Documentation
----------------------------
-
-Javadocs are generated while creating mvn:site and they are located in
-target/ directory in each module.
opflex
tsdr
vtn
- yangide
+++ /dev/null
-YANG IDE Installation Guide
-===========================
-
-Overview
---------
-
-The YANG IDE project provides an Eclipse plugin for viewing and editing
-Yang model files. When you create a "Yang Project" using the plugin,
-it creates a small Maven project with a POM file (pom.xml) that
-references the appropriate OpenDaylight dependencies, along with a
-sample Yang model file (acme-system.yang).
-
-Pre Requisites for Installing YANG IDE
---------------------------------------
-
-* YANG IDE has the same hardware requirements as the Eclipse IDE, which
- is about the same as the hardware requirements for Java 7.
-* At least Java 7 is required to run Eclipse (also an obvious
- requirement), but Java 8 will be required if you are building an
- application using OpenDaylight, and Java 8 is recommended anyway.
-
-Preparing for Installation
---------------------------
-
-As soon as at least Java 7 (Java 8 preferred) and Eclipse are
-installed, and Eclipse is running, you can install YANG IDE.
-
-You can find the Oracle Java installer at
-http://www.oracle.com/technetwork/java/javase/downloads/index.html .
-
-The Eclipse installer can be found at
-http://www.eclipse.org/downloads/ . You should select the "Eclipse
-IDE for Java Developers", and make sure you select the installer for
-the correct platform (for instance, 32-bit or 64-bit).
-
-
-Installing YANG IDE
--------------------
-
-The YANG IDE plugin can be installed by using the public update site URL
-provided, which is https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide/release/ .
-
-While in Eclipse, select "Help" from the menu bar and select "Install
-New Software ...". On the resulting "Install" dialog, click the
-"Add..." button. In that dialog, enter the update site URL as
-specified above and give it a name of "YANG IDE". Select the provided
-plugin and approve the license.
-
-Eclipse will prompt you to restart Eclipse. Do that.
-
-Installation is complete at this point.
-
-Network Connections
-^^^^^^^^^^^^^^^^^^^
-
-If the installation failed with an indication that it could not reach
-the internet, then your work computer may be behind a firewall.
-You will need to go to the "Network Connections" section of the Eclipse
-preferences (Menubar: "Window"->"Preferences"->"General"->"Network
-Connections").
-
-Before you make these changes, you will need to know the host and port
-of your outbound proxy server.
-
-On the "Network Connections" page, you should select "Manual" in the
-"Active Provider" dropdown, then edit the "HTTP" and "HTTPS" rows in
-the table, setting the host and port of the outbound proxy server.
-
-If the proxy server requires authentication, turn on the "Requires
-Authentication" checkbox and enter the required userid and password
-fields. If you do not know whether your proxy server requires
-authentication, it probably does not.
-
-Verifying your Installation
----------------------------
-
-This is not really a "usage guide", but following these steps will
-verify that the plugin was properly installed.
-
-When installation is complete, you can select "File" from the menu
-bar, then "New", then "Other" (you may have a keyboard shortcut for
-"Ctrl+n" for this).
-
-In the "New" dialog, you can enter "yang" in the field under the
-"Wizards" label, which starts out with the content of "type filter
-text". That will limit the list to the "YANG" folder and the two
-choices of "YANG File" and "YANG Project". Select the "YANG Project"
-option and click "Next".
-
-On the "New Yang Project" dialog, you may see a wizard page titled
-"Specify YANG Code Generators Parameters". Do not change anything on
-that page and click "Next".
-
-On the next wizard page, with the title "Select project name and
-location", check the "Create a simple project" checkbox and click
-"Next".
-
-On that dialog, enter anything you want in the "Group Id" field.
-Enter a project name (again, whatever you want for now) in the
-"Artifact Id" field and click "Finish". No other fields on the page
-need to be changed.
-
-The dialog will now go away and Eclipse will create the project, which
-you should see in either the "Package Explorer" or "Project Explorer"
-view, on the left side.
-
-Click the arrow just left of the project name to expand the contents
-of the project.
-
-In that resulting list, there are only two entries that you will ever
-care about. One is "src/main/yang", which is where you will store the
-Yang model files, and the "pom.xml" file, which is where you will enter
-dependencies for Yang model files to import. If you will not be
-importing any Yang model files, or you will only be importing other Yang
-model files in your own project, then you will never have to do anything
-with the "pom.xml" file.
-
-Click the arrow to the left of the "src/main/yang" entry to expand that.
-
-You should see a "acme-system.yang" file, which the plugin created by
-default. Double-click on that entry to open the file in the editor.
-
-Troubleshooting
-^^^^^^^^^^^^^^^
-
-If Eclipse fails to start up initially, then there is something wrong
-with either the Java installation or the Eclipse installation.
-
-You can determine whether Java is installed correctly by opening a
-shell or command window and entering "java -version" and verifying
-whether the output corresponds to the version of Java that you
-installed.
-
-If the Java installation seems fine, but Eclipse still fails to start
-up, you can ask questions on the #eclipse IRC channel, or post
-questions on the "Newcomers" forum at http://www.eclipse.org/forums/ .
-
-If Java and Eclipse seem to be fine, but the YANG IDE is having
-problems, ask questions on the "yangide-dev" mailing list.
-
-Post Installation Configuration
--------------------------------
-
-Setting Proxy Used For Maven
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If your work computer sits behind a firewall, you will have had to put
-information about your firewall in the "Network Connections" section
-of the Eclipse preferences. That would have allowed you to at least
-obtain the plugin and install it into Eclipse.
-
-Much of the functionality of YANG IDE uses Maven internally. You do
-not need to be a Maven expert to use this functionality, but you will
-need to add a few more lines of configuration so that Maven can get
-through the firewall. Maven, even when running inside Eclipse, as it
-is when you are using YANG IDE, does not use the Eclipse "Network
-Connection" settings to reach the internet. You have to set the proxy
-server information in a different place for Maven.
-
-Maven looks for a file at ``$HOME/.m2/settings.xml`` (Linux) or
-``%HOME%\.m2\settings.xml`` (Windows). If the ``.m2`` folder does not
-exist, you will need to create it. If the "settings.xml" file does not
-exist, you should create it with the following contents::
-
- <?xml version="1.0" encoding="UTF-8"?>
- <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
- <proxies>
- <proxy>
- <id>proxy</id>
- <active>true</active>
- <protocol>http</protocol>
- <host>FULLY QUALIFIED NAME OF PROXY HOST</host>
- <port>PROXY PORT</port>
- </proxy>
- <proxy>
- <id>proxy2</id>
- <active>true</active>
- <protocol>https</protocol>
- <host>FULLY QUALIFIED NAME OF PROXY HOST</host>
- <port>PROXY PORT</port>
- </proxy>
- </proxies>
- </settings>
-
-Replace "FULLY QUALIFIED NAME OF PROXY HOST" and "PROXY PORT" with the
-host and port of your proxy server.
-
-If the "settings.xml" file already existed, then you will need to edit
-it, inserting the "proxies" element from the above sample at an
-appropriate place.
-
-Upgrading From a Previous Release
----------------------------------
-
-If you already had the "YANG IDE" plugin from "Xored", you will need to
-uninstall that plugin before you install this one.
-
-Uninstalling YANG IDE
----------------------
-
-Uninstalling the YANG IDE plugin is the same as uninstalling any other Eclipse plugin.
-
-Click on the "Help" menu item and select "Installation Details". That
-list will have all the plugins you have installed (or that came with
-the distribution). To uninstall YANG IDE, you will need to select four
-entries from that list:
-
-* "m2e connector for YANG"
-* "m2e connector for YANG Developer Resources"
-* "YANG IDE"
-* "YANG IDE Developer Resources"
-
-Use the Control key to select multiple entries in this list. When all
-four entries are selected, click the "Uninstall" button. The next
-dialog shows what you selected and asks you to confirm with the
-"Finish" button.
-
-It will then uninstall the plugin and prompt you to restart Eclipse.
-When Eclipse restarts, the uninstall process is complete.
+++ /dev/null
-Atrium User Guide
-=================
-
-Overview
---------
-
-Project Atrium is an open source SDN distribution - a vertically
-integrated set of open source components which together form a complete
-SDN stack. It’s goals are threefold:
-
-- Close the large integration-gap of the elements that are needed to
- build an SDN stack - while there are multiple choices at each layer,
- there are missing pieces with poor or no integration.
-
-- Overcome a massive gap in interoperability - This exists both at the
- switch level, where existing products from different vendors have
- limited compatibility, making it difficult to connect an arbitrary
- switch and controller and at an API level, where its difficult to
- write a portable application across multiple controller platforms.
-
-- Work closely with network operators on deployable use-cases, so that
- they could download near production quality code from one location,
- and get started with functioning software defined networks on real
- hardware.
-
-Architecture
-------------
-
-The key components of Atrium BGP Peering Router Application are as
-follows:
-
-- Data Plane Switch - Data plane switch is the entity that uses flow
- table entries installed by BGP Routing Application through SDN
- controller. In the simplest form data plane switch with the installed
- flows act like a BGP Router.
-
-- OpenDaylight Controller - OpenDaylight SDN controller has many
- utility applications or plugins which are leveraged by the BGP Router
- application to manage the control plane information.
-
-- BGP Routing Application - An application running within the
- OpenDaylight runtime environment to handle I-BGP updates.
-
-- `DIDM <#_didm_user_guide>`__ - DIDM manages the drivers specific to
- each data plane switch connected to the controller. The drivers are
- created primarily to hide the underlying complexity of the devices
- and to expose a uniform API to applications.
-
-- Flow Objectives API - The driver implementation provides a pipeline
- abstraction and exposes Flow Objectives API. This means applications
- need to be aware of only the Flow Objectives API without worrying
- about the Table IDs or the pipelines.
-
-- Control Plane Switch - This component is primarily used to connect
- the OpenDaylight SDN controller with the Quagga Soft-Router and
- establish a path for forwarding E-BGP packets to and from Quagga.
-
-- Quagga soft router - An open source routing software that handles
- E-BGP updates.
-
-Running Atrium
---------------
-
-- To run the Atrium BGP Routing Application in OpenDaylight
- distribution, simply install the ``odl-atrium-all`` feature.
-
- ::
-
- feature:install odl-atrium-all
-
alto-user-guide
authentication-and-authorization-services
- atrium-user-guide
bgp-user-guide
bgp-monitoring-protocol-user-guide
capwap-user-guide
l3vpn-service_-user-guide
link-aggregation-control-protocol-user-guide
lisp-flow-mapping-user-guide
- natapp-user-guide
nemo-user-guide
netconf-user-guide
netide-user-guide
pcep-user-guide
packetcable-user-guide
service-function-chaining
- snbi-user-guide
snmp-plugin-user-guide
snmp4sdn-user-guide
sxp-user-guide
ttp-cli-tools-user-guide
uni-manager-plug-in-project
unified-secure-channel
- usecplugin-aaa-user-guide
- usecplugin-openflow-user-guide
virtual-tenant-network-(vtn)
- yang-ide-user-guide
- yang-push
+++ /dev/null
-NATApp User Guide
-=================
-
-The NATApp User Guide contains information about configuration,
-administration, management, using and troubleshooting the feature.
-
-Overview
---------
-
-NATApp provides network different types of address translation
-functionality for OpenDaylight. After installing this feature, network
-administrators can select the type of NAT functionality they want to
-enable by sending a REST API command. Subsequently, the user may enter
-the gloabl IP addresses to the YANG Data Store through REST APIs. When
-an OpenDaylight managed enterprise network with local IPs tries to
-connect to external networks such as Internet, NATApp comes into play
-and installs appropriate flow rules at the OpenFlow switch for
-bidirectional NAT translation.
-
-NATApp Architecture
--------------------
-
-NATApp listens on OpenFlow southbound interface for Packet\_In messages.
-The application parses the message for header information. If the
-received message has a local IP address the application installs rules
-on the OpenFlow switch for network address translation from local to
-global IP addresses. NATApp has NATPacketHandler class that implements
-the PacketProcessing interface to override the OnPacketReceived
-notification by which the application is notified of Packet\_In
-messages.
-
-Configuring NATApp
-------------------
-
-REST APIs are available at the following URI:
-http://localhost:8181/apidoc/explorer/index.html#!/natapp(2016-01-25)
-
-Mininet Topology
-~~~~~~~~~~~~~~~~
-
-::
-
- sudo mn --mac --topo=single,10 --controller=remote,ip=127.0.0.1,port=6653
-
-Install a flow to flood the ARP packets.
-
-::
-
- sh ovs-ofctl add-flow s1 dl_type=0x0806,actions=FLOOD
-
-Check the flow for ARP Flooding
-
-::
-
- sh ovs-ofctl dump-flows s1
-
-Administering or Managing NATApp
---------------------------------
-
-Static NAT and Dynamic NAT
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First user has to select the type of NAT he wants by using the following
-URI:
-
-POST URI
- http://localhost:8181/restconf/operations/natapp:nat-type
-
-Sample Input
- {"natapp:input": { "type:static":""}}
-
-Sample Input
- {"natapp:input": { "type:dynamic":""}}
-
-Then user can inject the Global IPs using the following URI
-
-PUT URI
- http://localhost:8181/restconf/config/natapp:staticNat/
-
-Sample Input
- {"natapp:staticNat": {"globalIP":["172.0.0.1/32","172.0.0.2/32",
- "172.0.0.3/32", "172.0.0.4/32", "172.0.0.5/32", "172.0.0.6/32",
- "172.0.0.7/32", "172.0.0.8/32", "172.0.0.9/32", "172.0.0.10/32"] }}
-
-From mininet verify any pair of hosts can ping each other. The NATApp
-modifies the destination IP address of the ICMP Echo request with the
-global IP address. Check the mininet flows for this modification.
-
-::
-
- sh ovs-ofctl dump-flows s1
-
-Port Address Translation (PAT)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-User can select PAT by using the following URI.
-
-POST URI
- http://localhost:8181/restconf/operations/natapp:nat-type
-
-Sample Input
- {"natapp:input": { "type:pat":""}}
-
-Then user can inject the Global IPs using the following URI
-
-PUT URI
- http://localhost:8181/restconf/config/natapp:patNat/
-
-Sample Input
- {"natapp:patNat": {"globalIP":"172.0.0.1/32"}}
-
-From Mininet use the command as xterm h1 h5. At h5 give the following
-commands
-
-::
-
- $ ip r add 172.0.0.1/32 dev h5-eth0
- $ arp -s 172.0.0.1 00:00:00:00:00:01
- $ nc -l 5000
-
-At h1, Give the following command
-
-::
-
- $ echo "TCS" | nc -p 8000 10.0.0.5 5000
-
-::
-
- mininet> sh ovs-ofctl dump-flows s1
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=811.272s, table=0, n_packets=5, n_bytes=342, idle_age=13, priority=210,tcp,in_port=1,tp_src=8000 actions=mod_nw_src:172.0.0.1,mod_tp_src:2000,output:5
- cookie=0x0, duration=499.843s, table=0, n_packets=2, n_bytes=84, idle_age=13, arp actions=FLOOD
- cookie=0x0, duration=811.203s, table=0, n_packets=3, n_bytes=206, idle_age=13, priority=209,tcp,in_port=5,tp_dst=2000 actions=mod_nw_dst:10.0.0.1,mod_tp_dst:8000,output:1
-
+++ /dev/null
-SNBI User Guide
-===============
-
-This section describes how to use the SNBI feature in OpenDaylight and
-contains configuration, administration, and management section for the
-feature.
-
-Overview
---------
-
-Key distribution in a scaled network has always been a challenge.
-Typically, operators must perform some manual key distribution process
-before secure communication is possible between a set of network
-devices. The Secure Network Bootstrapping Infrastructure (SNBI) project
-securely and automatically brings up an integrated set of network
-devices and controllers, simplifying the process of bootstrapping
-network devices with the keys required for secure communication. SNBI
-enables connectivity to the network devices by assigning unique IPv6
-addresses and bootstrapping devices with the required keys. Admission
-control of devices into a specific domain is achieved using whitelist of
-authorized devices.
-
-SNBI Architecture
------------------
-
-At a high level, SNBI architecture consists of the following components:
-
-- SNBI Registrar
-
-- SNBI Forwarding Element (FE)
-
-.. figure:: images/snbi/snbi_arch.png
- :alt: SNBI Architecture Diagram
-
- SNBI Architecture Diagram
-
-SNBI Registrar
-~~~~~~~~~~~~~~
-
-Registrar is a device in a network that validates device against a
-whitelist and delivers device domain certificate. Registrar includes the
-following:
-
-- RESCONF API for Domain Whitelist Configuration
-
-- SNBI Southbound Plugin
-
-- Certificate Authority
-
-**RESTCONF API for Domain Whitelist Configuration:.**
-
-Below is the YANG model to configure the whitelist of devices for a
-particular domain.
-
-::
-
- module snbi {
- //The yang version - today only 1 version exists. If omitted defaults to 1.
- yang-version 1;
-
- //a unique namespace for this SNBI module, to uniquely identify it from other modules that may have the same name.
- namespace "http://netconfcentral.org/ns/snbi";
-
- //a shorter prefix that represents the namespace for references used below
- prefix snbi;
-
- //Defines the organization which defined / owns this .yang file.
- organization "Netconf Central";
-
- //defines the primary contact of this yang file.
- contact "snbi-dev";
-
- //provides a description of this .yang file.
- description "YANG version for SNBI.";
-
- //defines the dates of revisions for this yang file
- revision "2024-07-02" {
- description "SNBI module";
- }
-
- typedef UDI {
- type string;
- description "Unique Device Identifier";
- }
-
- container snbi-domain {
- leaf domain-name {
- type string;
- description "The SNBI domain name";
- }
-
- list device-list {
- key "list-name";
-
- leaf list-name {
- type string;
- description "Name of the device list";
- }
-
- leaf list-type {
- type enumeration {
- enum "white";
- }
- description "Indicates the type of the list";
- }
-
- leaf active {
- type boolean;
- description "Indicates whether the list is active or not";
- }
-
- list devices {
- key "device-identifier";
- leaf device-identifier {
- type union {
- type UDI;
- }
- }
- }
- }
- }
- }
-
-**Southbound Plugin:.**
-
-The Southbound Plugin implements the protocol state machine necessary to
-exchange device identifiers, and deliver certificates.
-
-**Certificate Authority:.**
-
-A simple certificate authority is implemented using the Bouncy Castle
-package. The Certificate Authority creates the certificates from the
-device CSR requests received from the devices. The certificates thus
-generated are delivered to the devices using the Southbound Plugin.
-
-SNBI Forwarding Element
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The forwarding element must be installed or unpacked on a Linux host
-whose network layer traffic must be secured. The FE performs the
-following functions:
-
-- Neighour Discovery
-
-- Bootstrap
-
-- Host Configuration
-
-**Neighbour Discovery:.**
-
-Neighbour Discovery (ND) is the first step in accommodating devices in a
-secure network. SNBI performs periodic neighbour discovery of SNBI
-agents by transmitting ND hello packets. The discovered devices are
-populated in an ND table. Neighbour Discovery is periodic and
-bidirectional. ND hello packets are transmitted every 10 seconds. A 40
-second refresh timer is set for each discovered neighbour. On expiry of
-the refresh timer, the Neighbour Adjacency is removed from the ND table
-as the Neighbour Adjacency is no longer valid. It is possible that the
-same SNBI neighbour is discovered on multiple links, the expiry of a
-device on one link does not automatically remove the device entry from
-the ND table.
-
-**Bootstrapping:.**
-
-Bootstrapping a device involves the following sequential steps:
-
-- Authenticate a device using device identifier (UDI or SUDI)
-
-- Allocate the appropriate device ID and IPv6 address to uniquely
- identify the device in the network
-
-- Allocate the required keys by installing a Device Domain Certificate
-
-- Accommodate the device in the domain
-
-**Host Configuration:.**
-
-Involves configuring a host to create a secure overlay network,
-assigning appropriate ipv6 address, setting up gre tunnels, securing the
-tunnels traffic via IPsec and enabling connectivity via a routing
-protocol.
-
-The SNBI Forwarding Element is packaged in a docker container available
-at this link: https://hub.docker.com/r/snbi/boron/. For more information
-on docker, refer to this link: https://docs.docker.com/linux/.
-
-Prerequisites for Configuring SNBI
-----------------------------------
-
-Before proceeding further, ensure that the following system requirements
-are met:
-
-- 64bit Ubunutu 14.04 LTS
-
-- 4GB RAM
-
-- 4GB of hard disk space, sufficient enough to store certificates
-
-- Java Virtual Machine 1.8 or above
-
-- Apache Maven 3.3.3 or above
-
-- Make sure the time on all the devices or synced either manually or
- using NTP
-
-- The docker version must be greater than 1.0 on a 14.04 Ubuntu
-
-Configuring SNBI
-----------------
-
-This section contains the following:
-
-- Setting up SNBI Registrar on the controller
-
-- Configuring Whitelist
-
-- Setting up SNBI FE on Linux Hosts
-
-Setting up SNBI Registrar on the controller
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section contains the following:
-
-- Configuring the Registrar Host
-
-- Installing Karaf Package
-
-- Configuring SNBI Registrar
-
-**Configuring the Registrar Host:.**
-
-Before enabling the SNBI registrar service, assign an IPv6 address to an
-interface on the registrar host. This is to bind the registrar service
-to an IPv6 address (**fd08::aaaa:bbbb:1/128**).
-
-::
-
- sudo ip link add snbi-ra type dummy
- sudo ip addr add fd08::aaaa:bbbb:1/128 dev snbi-ra
- sudo ifconfig snbi-ra up
-
-**Installing Karaf Package:.**
-
-Download the karaf package from this link:
-http://www.opendaylight.org/software/downloads, unzip and run the
-``karaf`` executable present in the bin folder. Here is an example of
-this step:
-
-::
-
- cd distribution-karaf-0.3.0-Boron/bin
- ./karaf
-
-Additional information on useful Karaf commands are available at this
-link:
-https://wiki.opendaylight.org/view/CrossProject:Integration_Group:karaf.
-
-**Configuring SNBI Registrar:.**
-
-Before you perform this step, ensure that you have completed the tasks
-`above <#_configuring_snbi>`__:
-
-To use RESTCONF APIs, install the RESTCONF feature available in the
-Karaf package. If required, install mdsal-apidocs module for access to
-documentation. Refer
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf_API_Explorer
-for more information on MDSAL API docs.
-
-Use the commands below to install the required features and verify the
-same.
-
-::
-
- feature:install odl-restconf
- feature:install odl-mdsal-apidocs
- feature:install odl-snbi-all
- feature:list -i
-
-After confirming that the features are installed, use the following
-command to start SNBI registrar:
-
-::
-
- snbi:start <domain-name>
-
-Configuring Whitelist
-~~~~~~~~~~~~~~~~~~~~~
-
-The registrar must be configured with a whitelist of devices that are
-accommodated in a specific domain. The YANG for configuring the domain
-and the associated whitelist in the controller is avaialble at this
-link:
-https://wiki.opendaylight.org/view/SNBI_Architecture_and_Design#Registrar_YANG_Definition.
-It is recommended to use Postman to configure the registrar using
-RESTCONF.
-
-This section contains the following:
-
-- Installing PostMan
-
-- Configuring Whitelist using REST API
-
-**Installing PostMan:.**
-
-Follow the steps below to install postman on your Google Chrome Browser.
-
-- Install Postman via Google Chrome browser available at this link:
- https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
-
-- In the chrome browser address bar, enter: chrome://apps/
-
-- Click Postman.
-
-- Enter the URL.
-
-- Click Headers.
-
-- Enter Accept: header.
-
-- Click Basic Auth tab to create user credentials, such as user name
- and password.
-
-- Send.
-
-You can download a sample Postman configuration to get started from this
-link: https://www.getpostman.com/collections/c929a2a4007ffd0a7b51
-
-**Configuring Whitelist using REST API:.**
-
-The POST method below configures a domain - "secure-domain" and
-configures a whitelist set of devices to be accommodated to the domain.
-
-::
-
- {
- "snbi-domain": {
- "domain-name": "secure-domain",
- "device-list": [
- {
- "list-name": "demo list",
- "list-type": "white",
- "active": true,
- "devices": [
- {
- "device-id": "UDI-FirstFE"
- },
- {
- "device-id": "UDI-dev1"
- },
- {
- "device-id": "UDI-dev2"
- }
- ]
- }
- ]
- }
- }
-
-The associated device ID must be configured on the SNBI FE (see below).
-You can also use REST APIs using the API docs interface to push the
-domain and whitelist information. The API docs could be accessed at
-link:http://localhost:8080/apidoc/explorer. More details on the API docs
-is available at
-link:https://wiki.opendaylight.org/view/OpenDaylight\_Controller:MD-SAL:Restconf\_API\_Explorer
-
-Setting up SNBI FE on Linux Hosts
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The SNBI Daemon is used to bootstrap the host device with a valid device
-domain certificate and IP address for connectivity and to create a
-reachable overlay network by interacting with multiple software modules.
-
-**Device UDI:.**
-
-The Device UDI or the device Unique Identifier can be derived from a
-multitude of parameters in the host machine, but most derived parameters
-are already known or do not remain constant across reloads. Therefore,
-every SNBI FE must be configured explicitly with a UDI that is present
-in the device whitelist.
-
-**First Forwarding Element:.**
-
-The registrar service IP address must be provided to the first host
-(Forwarding Element) to be bootstrapped. As mentioned in the
-"Configuring the Registrar Host" section, the registrar service IP
-address is **fd08::aaaa:bbbb:1**. The First Forwarding Element must be
-configured with this IPv6 address.
-
-**Running the SNBI docker image:.**
-
-The SNBI FE in the docker image picks the UDI of the ForwardingElement
-via an environment variable provided when executing docker instance. If
-the Forwarding Element is a first forwarding element, the IP address of
-the registrar service should also be provided.
-
-::
-
- sudo docker run -v /etc/timezone:/etc/timezone:ro --net=host --privileged=true
- --rm -t -i -e SNBI_UDI=UDI-FirstFE -e SNBI_REGISTRAR=fd08::aaaa:bbbb:1 snbi/boron:latest /bin/bash
-
-After the docker image is executed, you are placed in the snbi.d command
-prompt.
-
-A new Forwarding Element is bootstrapped in the same way, except that
-the registrar IP address is not required while running the docker image.
-
-::
-
- sudo docker run --net=host --privileged=true --rm -t -i -e SNBI_UDI=UDI-dev1 snbi/boron:latest /bin/bash
-
-Administering or Managing SNBI
-------------------------------
-
-The SNBI daemon provides various show commands to verify the current
-state of the daemon. The commands are completed automatically when you
-press Tab in your keyboard. There are help strings "?" to list commands.
-
-::
-
- snbi.d > show snbi
- device Host deevice
- neighbors SNBI Neighbors
- debugs Debugs enabled
- certificate Certificate information
-
+++ /dev/null
-Usecplugin-AAA User Guide
-=========================
-
-The Usecplugin User Guide contains information about configuration,
-administration, management, using and troubleshooting the feature.
-
-Overview
---------
-
-AAA plugin provides authorization, authentication and accounting
-services to OpenDaylight. A user logs in to OpenDaylight through the
-username and password provided by AAA plugin. Usecplugin-AAA collects
-and stores information about both successful and failed login attempts
-to OpenDaylight.
-
-Usecplugin-AAA Architecture
----------------------------
-
-AAA plugin creates log messages about successful and failed login
-attempts to OpenDaylight. Usecplugin-AAA continuously reads this log
-file and checks for either successful and failed attempt information.
-Whenever Usecpluin-AAA identifies a new attempt entry in the log file it
-is stored in YANG Data Store and its own log file.
-
-Administering or Managing Usecplugin-AAA
-----------------------------------------
-
-- Install feature ``odl-usecplugin-aaa``
-
-- Enable odl-aaa log using command
- ``log:set DEBUG org.opendaylight.aaa.shiro.filters``
-
-- Login to the RESTCONF documentation.
-
-- Check operational datastore for login attempts.
-
-- POST URI ::
- http://localhost:8181/restconf/operations/usecpluginaaa:attemptFromIP
-
- - Sample Input :: {"usecpluginaaa:input":{"ScrIP":"10.0.0.1"}}
-
-- POST URI ::
- http://localhost:8181/restconf/operations/usecpluginaaa:attemptOnDateTime
-
- - Sample Input :: {"usecpluginaaa:input":{"dateTime":"2016-07-27
- 14:11:18"}}
-
+++ /dev/null
-Usecplugin-OpenFlow User Guide
-==============================
-
-The Usecplugin-OpenFlow User Guide contains information about
-configuration, administration, management, using and troubleshooting the
-feature.
-
-Overview
---------
-
-Usecplugin-OpenFlow collects information about potential OpenFlow
-Packet\_In attacks to OpenDaylight. A threshold (water mark) can be set
-for the Packet\_In rate which when breached will trigger Packet\_In
-message information collection.
-
-Usecplugin Architecture
------------------------
-
-Usecplugin listens on OpenFlow southbound interface for Packet\_In
-messages. When the rate of Packet\_In breaches the high water mark the
-application parses the message for header information which is
-subsequently stored in YANG Data Store and a log file. Usecplugin has
-PacketHandler class that implements the PacketProcessing interface to
-override the OnPacketReceived notification by which the application is
-notified of Packet\_In messages.
-
-Configuring Usecplugin-OpenFlow
--------------------------------
-
-Install the Usecplugin-OpenFlow feautre in OpenDaylight with the
-``feature:install odl-usecplugin-openflow`` at the Karaf CLI.
-
-A user can set the low water mark and high water mark for Packet\_In
-rates as well as number of samples for checking the time interval to
-calculate Packet\_In rate.
-
-URI
- http://localhost:8181/apidoc/explorer/index.html#!/usecplugin(2015-01-05)
-
-High Water Mark Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-PUT URI
- http://localhost:8181/restconf/config/usecplugin:sample-data-hwm/
-
-Sample Input
- ``{"usecplugin:sample-data-hwm": { "samples":"3000","highWaterMark":"3000"}}``
-
-Low Water Mark Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-PUT URI
- http://localhost:8181/restconf/config/usecplugin:sample-data-lwm/
-
-Sample Input
- ``{"usecplugin:sample-data-lwm": { "samples-lwm":"2000","lowWaterMark-lwm":"2000"}}``
-
-Administering or Managing Usecplugin-OpenFlow
----------------------------------------------
-
-Use RPC POST APIs in the following format for getting the attack related
-information.
-
-attackID
-~~~~~~~~
-
-URI
- http://localhost:8181/restconf/operations/usecplugin:attackID
-
-Sample Input
- ``{"usecplugin:input": { "NodeID":"openflow:1"}}``
-
-attacksFromIP
-~~~~~~~~~~~~~
-
-URI
- http://localhost:8181/restconf/operations/usecplugin:attacksFromIP
-
-Sample Input
- ``{"usecplugin:input": { "SrcIP":"10.0.0.1"}}``
-
-attacksToIP
-~~~~~~~~~~~
-
-URI
- http://localhost:8181/restconf/operations/usecplugin:attacksToIP
-
-Sample Input
- ``{"usecplugin:input": { "DstIP":"10.0.0.2"}}``
-
+++ /dev/null
-YANG IDE User Guide
-===================
-
-Overview
---------
-
-The YANG IDE project provides an Eclipse plugin that is used to create,
-view, and edit Yang model files. It currently supports version 1.0 of
-the Yang specification.
-
-The YANG IDE project uses components from the OpenDaylight project for
-parsing and verifying Yang model files. The "yangtools" parser in
-OpenDaylight is generally used for generating Java code associated with
-Yang models. If you are just using the YANG IDE to view and edit Yang
-models, you do not need to know any more about this.
-
-Although the YANG IDE plugin is used in Eclipse, it is not necessary to
-be familiar with the Java programming language to use it effectively.
-
-The YANG IDE also uses the Maven build tool, but you do not have to be a
-Maven expert to use it, or even know that much about it. Very little
-configuration of Maven files will have to be done by you. In fact, about
-the only thing you will likely ever need to change can be done entirely
-in the Eclipse GUI forms, without even seeing the internal structure of
-the Maven POM file (Project Object Model).
-
-The YANG IDE plugin provides features that are similar to other
-programming language plugins in the Eclipse ecosystem.
-
-For instance, you will find support for the following:
-
-- Immediate "as-you-type" display of syntactic and semantic errors
-
-- Intelligent completion of language tokens, limited to only choices
- valid in the current scope and namespace
-
-- Consistent (and customizable) color-coding of syntactic and semantic
- symbols
-
-- Provides access to remote Yang models by specifying dependency on
- Maven artifact containing models (or by manual inclusion in project)
-
-- One-click navigation to referenced symbols in external files
-
-- Mouse hovers display descriptions of referenced components
-
-- Tools for refactoring or renaming components respect namespaces
-
-- Code templates can be entered for common conventions
-
-Forthcoming sections of this manual will step through how to utilize
-these features.
-
-Creating a Yang Project
------------------------
-
-After the plugin is installed, the next thing you have to do is create a
-Yang Project. This is done from the "File" menu, selecting "New", and
-navigating to the "Yang" section and selecting "YANG Project", and then
-clicking "Next" for more items to configure.
-
-Some shortcuts for these steps are the following:
-
-- Typically, the key sequence "Ctrl+n" (press "n" while holding down
- one of the "ctrl" keys) is bound to the "new" function
-
-- In the "New" wizard dialog, the initial focus is in the filter field,
- where you can enter "yang" to limit the choices to only the functions
- provided by the YANG IDE plugin
-
-- On the "New" wizard dialog, instead of clicking the "Next" button
- with your mouse, you can press "Alt+n" (you will see a hint for this
- with the "N" being underlined)
-
-First Yang Project Wizard Page
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After the "Next" button is pressed, it goes to the first wizard page
-that is specific to creating Yang projects. you will see a subtitle on
-this page of "YANG Tools Configuration". In almost all cases, you should
-be able to click "Next" again on this page to go to the next wizard
-page.
-
-However, some information about the fields on this page would be
-helpful.
-
-You will see the following labeled fields and sections:
-
-Yang Files Root Directory
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This defaults to "src/main/yang". Except when creating your first Yang
-file, you, you do not even have to know this, as Eclipse presents the
-same interface to view your Yang files no matter what you set this to.
-
-Source Code Generators
-^^^^^^^^^^^^^^^^^^^^^^
-
-If you do not know what this is, you do not need to know about it. The
-"yangtools" Yang parser from OpenDaylight uses a "code generator"
-component to generate specific kinds of Java classes from the Yang
-models. Again, if you do not need to work with the generated Java code,
-you do not need to change this.
-
-Create Example YANG File
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-This is likely the only field you will ever have any reason to change.
-If this checkbox is set, when the YANG IDE creates the Yang project, it
-will create a sample "acme-system.yang" file which you can view and edit
-to demonstrate the features of the tool to yourself. If you do not need
-this file, then either delete it from the project or uncheck the
-checkbox to prevent its creation.
-
-When done with the fields on this page, click the "Next" button to go to
-the next wizard page.
-
-Second Yang Project Wizard Page
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This page has a subtitle of "New Maven project". There are several
-fields on this page, but you will only ever have to see and change the
-setting of the first field, the "Create a simple project" checkbox. You
-should always set this ON to avoid the selection of a Maven archetype,
-which is something you do not need to do for creating a Yang project.
-
-Click "Next" at the bottom of the page to move to the next wizard page.
-
-Third Yang Project Wizard Page
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This also has a subtitle of "New Maven project", but with different
-fields to set. You will likely only ever set the first two fields, and
-completely ignore everything else.
-
-The first field is labeled "Group id" in the "Artifact" section. It
-really does not matter what you set this to, but it does have to be set
-to something. For consistency, you might set this to the name or
-nickname of your organization. Otherwise, there are no constraints on
-the value of this field.
-
-The second field is labeled "Artifact id". The value of this field will
-be used as the name of the project you create, so you will have to think
-about what you want the project to be called. Also note that this name
-has to be unique in the Eclipse workspace. You cannot have two projects
-with the same name.
-
-After you have set this field, you will notice that the "Next" button is
-insensitive, but now the "Finish" button is sensitive. You can click
-"Finish" now (or use the keyboard shortcut of "Alt+f"), and the Yang IDE
-will finally create your project.
-
-Creating a Yang File
---------------------
-
-Now that you have created your project, it is time to create your first
-Yang file.
-
-When you created the Yang project, you might have noticed the other
-option next to "YANG Project", which was "YANG File". That is what you
-will select now. Click "Next" to go to the first wizard page.
-
-First Yang File Wizard Page
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This wizard page lets you specify where the new file will be located,
-and its name.
-
-You have to select the particular project you want the file to go into,
-and it needs to go into the "src/main/yang" folder (or a different
-location if you changed that field when creating the project).
-
-You then enter the desired name of the file in the "File name". The file
-name should have no spaces or "special characters" in it. You can
-specify a ".yang" extent if you want. If you do not specify an extent,
-the YANG IDE will create it with the ".yang" extent.
-
-Click "Next" to go to the next wizard page.
-
-Second Yang File Wizard Page
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-On this wizard page, you set some metadata about the module that is used
-to initialize the contents of the Yang file.
-
-It has the following fields:
-
-Module Name
-^^^^^^^^^^^
-
-This will default to the "base name" of the file name you created. For
-instance, if the file name you created was "network-setup.yang", this
-field will default to "network-setup". You should leave this value as
-is. There is no good reason to define a model with a name different from
-the file name.
-
-Namespace
-^^^^^^^^^
-
-This defaults to "urn:opendaylight:xxx", where "xxx" is the "base name"
-of the file name you created. You should put a lot of thought into
-designing a namespace naming scheme that is used throughout your
-organization. It is quite common for this namespace value to look like a
-"http" URL, but note that that is just a convention, and will not
-necessarily imply that there is a web page residing at that HTTP
-address.
-
-Prefix
-^^^^^^
-
-This defaults to the "base name" of the file name you created. It mostly
-does not technically matter what you set this to, as long as it is not
-empty. Conventionally, it should be a "nickname" that is used to refer
-to the given namespace in an abbreviated form, when referenced in an
-"import" statement in another Yang model file.
-
-Revision
-^^^^^^^^
-
-This has to be a date value in the form of "yyyy-mm-dd", representing
-the last modified date of this Yang model. The value will default to the
-current date.
-
-Revision Description
-^^^^^^^^^^^^^^^^^^^^
-
-This is just human-readable text, which will go into the "description"
-field underneath the Yang "revision" field, which will describe what
-went into this revision.
-
-When all the fields have the content you want, click the "Finish" button
-to set the YANG IDE create the file in the specified location. It will
-then present the new file in the editor view for additional
-modifications.
-
-Accessing Artifacts for Yang Model Imports
-------------------------------------------
-
-You might be working on Yang models that are "abstract" or are intended
-to be imported by other Yang models. You might also, and more likely, be
-working on Yang models that import other "abstract" Yang models.
-
-Assuming you are in that latter more common group, you need to consider
-for yourself, and for your organization, how you are going to get access
-to those models that you import.
-
-You could use a very simple and primitive approach of somehow obtaining
-those models from some source as plain files and just copying them into
-the "src/main/yang" folder of your project. For a simple demo or a
-"one-off" very short project, that might be sufficient.
-
-A more robust and maintainable approach would be to reference
-"coordinates" of the artifacts containing Yang models to import. When
-you specify unique coordinates associated with that artifact, the Yang
-IDE can retrieve the artifact in the background and make it available
-for your "import" statements.
-
-Those "coordinates" that I speak of refer to the Maven concepts of
-"group id", "artifact id", and "version". you may remember "group id"
-and "artifact id" from the wizard page for creating a Yang project. It
-is the same idea. If you ever produce Yang model artifacts that other
-people are going to import, you will want to think more about what you
-set those values to when you created the project.
-
-For example, the OpenDaylight project produces several importable
-artifacts that you can specify to get access to common Yang models.
-
-Turning on Indexing for Maven Repositories
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before we talk about how to add dependencies to Maven artifacts with
-Yang models for import, I need to explain how to make it easier to find
-those artifacts.
-
-In the Yang project that you have created, the "pom.xml" file (also
-called a "POM file") is the file that Maven uses to specify
-dependencies. We will talk about that in a minute, but first we need to
-talk about "repositories". These are where artifacts are stored.
-
-We are going to have Eclipse show us the "Maven Repositories" view. In
-the main menu, select "Window" and then "Show View", and then "Other".
-Like in the "New" dialog, you can enter "maven" in the filter field to
-limit the list to views with "maven" in the name. Click on the "Maven
-Repositories" entry and click OK.
-
-This will usually create the view in the bottom panel of the window.
-
-The view presents an outline view of four principal elements:
-
-- Local Repositories
-
-- Global Repositories
-
-- Project Repositories
-
-- Custom Repositories
-
-For this purpose, the only section you care about is "Project
-Repositories", being the repositories that are only specified in the POM
-for the project. There should be a "right-pointing arrow" icon on the
-line. Click that to expand the entry.
-
-You should see two entries there:
-
-- opendaylight-release
-
-- opendaylight-snapshot
-
-You will also see internet URLs associated with each of those
-repositories.
-
-For this purpose, you only care about the first one. Right-click on that
-entry and select "Full Index Enabled". The first time you do this on the
-first project you create, it will spend several minutes walking the
-entire tree of artifacts available at that repository and "indexing" all
-of those components. When this is done, searching for available
-artifacts in that repository will go very quickly.
-
-Adding Dependencies Containing Yang Models
-------------------------------------------
-
-Double-click the "pom.xml" file in your project. Instead of just
-bringing up the view of an XML file (although you can see that if you
-like), it presents a GUI form editor with a handful of tabs.
-
-The first tab, "Overview", shows things like the "Group Id", "Artifact
-Id", and "Version", which represents the "Maven coordinate" of your
-project, which I have mentioned before.
-
-Now click on the "Dependencies" tab. You will now see two list
-components, labeled "Dependencies" and "Dependency Management". You only
-care about the "Dependencies" section.
-
-In the "Dependencies" section, you should see one dependency for an
-artifact called "yang-binding". This artifact is part of OpenDaylight,
-but you do not need to know anything about it.
-
-Now click the "Add" button.
-
-This brings up a dialog titled "Select Dependency". It has three fields
-at the top labeled "Group Id", "Artifact Id", and "Version", with a
-"Scope" dropdown. You will never have a need to change the "Scope"
-dropdown, so ignore it. Despite the fact that you will need to get
-values into these fields, in general usage, you will never have to
-manually enter values into them, but you will see values being inserted
-into these fields by the next steps I describe.
-
-Below those fields is a field labeled "Enter groupId, artifactId …".
-This is effectively a "filter field", like on the "New" dialog, but
-instead of limiting the list from a short list of choices, the value you
-enter there will be matched against all of the artifacts that were
-indexed in the "opendaylight-release" repository (and others). It will
-match the string you enter as a substring of any groupId or artifactId.
-
-For all of the entries that match that substring, it will list an entry
-showing the groupId and artifactId, with an expansion arrow. If you open
-it by clicking on the arrow, you will see individual entries
-corresponding to each available version of that artifact, along with
-some metadata about the artifacts between square brackets, mostly
-indicating what "type" of artifact is.
-
-For your purposes, you only ever want to use "bundle" or "jar"
-artifacts.
-
-Let us consider an example that many people will probably be using.
-
-In the filter field, enter "ietf-yang-types". Depending on what versions
-are available, you should see a small handful of "groupId, artifactId"
-entries there. One of them should be groupId
-"org.opendaylight.mdsal.model" and artifactId "ietf-yang-types". Click
-on the expansion arrow to open that.
-
-What you will see at this point depends on what versions are available.
-You will likely want to select the newest one (most likely top of the
-list) that is also either a "bundle" or "jar" type artifact.
-
-If you click on that resulting version entry, you should notice at this
-point that the "Group Id", "Artifact Id", and "Version" fields at the
-top of the dialog are now filled in with the values corresponding to
-this artifact and version.
-
-If this is the version that you want, click OK and this artifact will be
-added to the dependencies in the POM.
-
-This will now make the Yang models found in that artifact available in
-"import" statements in Yang models, not to mention the completion
-choices for that "import" statement.
-
+++ /dev/null
-YANG-PUSH
-=========
-
-This section describes how to use the YANG-PUSH feature in OpenDaylight
-and contains contains configuration, administration, and management
-sections for the feature.
-
-Overview
---------
-
-YANG PUBSUB project allows applications to place subscriptions upon
-targeted subtrees of YANG datastores residing on remote devices. Changes
-in YANG objects within the remote subtree can be pushed to an
-OpenDaylight MD-SAL and to the application as specified without a
-requiring the controller to make a continuous set of fetch requests.
-
-YANG-PUSH capabilities available
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This module contains the base code which embodies the intent of
-YANG-PUSH requirements for subscription as defined in
-{i2rs-pub-sub-requirements}
-[https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/].
-The mechanism for delivering on these YANG-PUSH requirements over
-Netconf transport is defined in {netconf-yang-push} [netconf-yang-push:
-https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00].
-
-Note that in the current release, not all capabilities of
-draft-ietf-netconf-yang-push are realized. Currently only implemented is
-**create-subscription** RPC support from
-ietf-datastore-push@2015-10-15.yang; and this will be for periodic
-subscriptions only. There of course is intent to provide much additional
-functionality in future OpenDaylight releases.
-
-Future YANG-PUSH capabilities
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Over time, the intent is to flesh out more robust capabilities which
-will allow OpenDaylight applications to subscribe to YANG-PUSH compliant
-devices. Capabilities for future releases will include:
-
-Support for subscription change/delete: **modify-subscription** rpc
-support for all mountpoint devices or particular mountpoint device
-**delete-subscription** rpc support for all mountpoint devices or
-particular mountpoint device
-
-Support for static subscriptions: This will enable the receipt of
-subscription updates pushed from publishing devices where no signaling
-from the controller has been used to establish the subscriptions.
-
-Support for additional transports: NETCONF is not the only transport of
-interest to OpenDaylight or the subscribed devices. Over time this code
-will support Restconf and HTTP/2 transport requirements defined in
-{netconf-restconf-yang-push}
-[https://tools.ietf.org/html/draft-voit-netconf-restconf-yang-push-01]
-
-YANG-PUSH Architecture
-----------------------
-
-The code architecture of Yang push consists of two main elements
-
-YANGPUSH Provider YANGPUSH Listener
-
-YANGPUSH Provider receives create-subscription requests from
-applications and then establishes/registers the corresponding listener
-which will receive information pushed by a publisher. In addition,
-YANGPUSH Provider also invokes an augmented OpenDaylight
-create-subscription RPC which enables applications to register for
-notification as per rfc5277. This augmentation adds periodic time period
-(duration) and subscription-id values to the existing RPC parameters.
-The Java package supporting this capability is
-“org.opendaylight.yangpush.impl”. YangpushDomProvider is the class which
-supports this YANGPUSH Provider capability.
-
-The YANGPUSH Listener accepts update notifications from a device after
-they have been de-encapsulated from the NETCONF transport. The YANGPUSH
-Listener then passes these updates to MD-SAL. This function is
-implemented via the YangpushDOMNotificationListener class within the
-“org.opendaylight.yangpush.listner” Java package. Applications should
-monitor MD-SAL for the availability of newly pushed subscription
-updates.
-
Code Review / docs.git / commitdiff