![](\"https://raw.githubusercontent.com/ETI-Software-Solutions/Postman-Collection-Images/main/Nokia-Network-Services-Platform.png\")
\n\nNokia Network Services Platform is driven by YANG. The Altiplano 19.3 YANG models were used to build the instance of Lighty.io showing OpenDayLight services in this API.
\nThe Internet of Things Data Management (IoTDM) on OpenDaylight (ODL) project is about developing a data-centric middleware that will act as a oneM2M compliant IoT Data Broker and enable authorized applications to retrieve IoT data uploaded by any device. The ODL platform is used to implement the oneM2M data store which models a hierarchical containment tree, where each node in the tree represents an oneM2M resource. Typically, IOT devices and applications interact with the resource tree over standard protocols such as CoAP, MQTT, and HTTP.
\n![](\"https://raw.githubusercontent.com/ETI-Software-Solutions/Postman-Collection-Images/main/ODL-IoTDM.jpg\")
\n\nInitially, the oneM2M resource tree is used by applications to retrieve data. Possible applications are inventory/device management systems or big data analytic systems designed to make sense of the data collected. But, at some point, applications will need to configure the devices. Features and tools will have to be provided to enable configuration of the devices based on applications responding to user input, network conditions, or some set of programmable rules or policies possibly triggered by the receipt of data collected from the devices.
\nThe ODL platform, with its rich unique cross-section of SDN capabilities, NFV, and now IOT device and application management, can be bundled with a targeted set of features and deployed anywhere in the network to give the network/service provider ultimate control. Depending on the use case, the ODL IOT platform can be configured with only IOT data collection capabilities where it is deployed near the IOT devices and its footprint needs to be small, or it can be configured to run as a highly scaled up and out distributed cluster with IOT, SDN and NFV functions enabled and deployed in a high traffic data center.
\n![](\"https://raw.githubusercontent.com/ETI-Software-Solutions/Postman-Collection-Images/main/OneM2M-TSDR.jpg\")
\n\n![](\"https://raw.githubusercontent.com/CiscoDevNet/OneM2MPlugins/blob/master/onem2mTsdr/images/Slide1.jpg\")
\n\n![](\"https://raw.githubusercontent.com/ETI-Software-Solutions/Postman-Collection-Images/main/model-driven-programmability.png\")
\n\nThe MD-SAL engine of OpenDayLight provides the model driven approach to network automation for major initiatives of ONAP, oRAN, BroadbandForum, etc. This provides the “model driven” part of the previously mentioned components.
\nThe model driven service adaptation (abstraction) layer engine is a message-bus inspired extensible middleware component that provides messaging and data storage functionality based on data and interface models defined by application developers, i.e. user-defined models. Evidence of success is adoption by major open source and proprietary initiatives.
\nThe YANG modeling language is used by the MD-SAL engine for interface and data definitions.
\nModel-driven nature of the MD-SAL and DOM-based APIs allows for behind-the-scene API and payload type mediation and transformation to facilitate seamless communication between applications. By extension other components and applications are enabled to provide connectors / expose different set of APIs. The power is from deriving most of its functionality purely from models themselves. This can benefit all consumers of the model without modification!
\nConsider RESTCONF, it is built on top of MD-SAL and exposes YANG-modeled application APIs transparently via HTTP and adds support for XML and JSON payload types. Harnessing all the permutations and combinations possible from a generic modeling language is staggering!
\nThe BLS engine and generator were designed to harness MD-SAL exploitations.
\nIn MD-SAL terminology, the term ‘RPC’ is used to define the input and output for a procedure (function) that is to be provided by a provider, and mediated by the MD-SAL, that means it may not result in remote call. Because it can be a local call, doesn’t exclude local interaction.
\nThe wisdom and maturity of OpenDayLight and primarily the MD-SAL engine becomes elegant and poetic, balanced on what can and should be compiled for safe execution and what should be fast and loose for power.
\nMD-SAL provides several patterns for using a message broker, by design this is intended to transfer YANG modeled data between applications. The implementation provides for data-centric application integration and API-centric application integration.
\nModel-driven SDN networks enable the programmability, through an external controller, which supports applications and policies built from SDN programming languages, thus breaking the traditional bind between control and data plane.
\nModel-Driven Engineering (MDE) paradigm, called Model-Driven Networking (MDN). MDN relies on a Domain-Specific Modeling Language (DSML) to create SDN applications. The MDN raises the level of abstraction on development, thus reducing the complexity to implement SDN applications.
\nDescribes the network.
\nDescribes network services and APIs.
\nDescribes the network element configuration provided and supported by: 1) manufacturers for physical elements or 2) software developers for virtual elements.
\nDescribes the network element supported telemetry provided and supported by: 1) manufacturers for physical elements or 2) software developers for virtual elements.
\nNETCONF/YANG provides a standardized way to programmatically update and modify the configuration of a network device. ... YANG is the modeling language that describes the configuration changes. Whereas, NETCONF is the protocol that applies the changes to the relevant datastore (i.e running, saved etc) upon the device.
\nThe downstream usage of YANG data model to construct XML requests for NETCONF. The upstream usage is to struct a RESTCONF (REST) API. Command library generation for our engine from the api-doc becomes more obvious. This is a simplistic explanation.
\nNETCONF was specifically developed to support network configuration.
\nNETCONF supports transactions, commit and rollback, ACID transactions. Transactions are indivisible.
\nVendor Driven Independence, capabilities can be extracted from an exchange with the device and retrieved as schema from an RPC call. Yang models can be obtained from the device itself, from the discovery in a Call Home, or direct RPC call.
\nHaving a Vendor Agnostic strategy for your enterprise is quite valuable.
\nThis Technical Report defines YANG data models for the management interfaces to support
FTTdp. These models are to enable interoperability for FTTdp management.
![](\"https://raw.githubusercontent.com/ETI-Software-Solutions/Postman-Collection-Images/main/bbf-fttdp.png\")
\n\nLarge service providers, such as AT&T and Deutsche Telekom prefer the NETCONF and YANG standards.
\nQueries the operational (running) datastore on the mounted hosted.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=Queries the available operations (RPC calls) on the mounted hosted.
\n","urlObject":{"path":["restconf","operations","network-topology:network-topology","topology=topology-netconf","node=Mounting the device is similarly to plugging in a USB, the contents of the device are now available. Use this endpoint to obtain the root of the datastore on the device. The default is the ?content=config datastore used for provisioning. The ?content=nonconfig datastore is used for monitoring, operational status and performance measures.
\n","_postman_id":"8feb85e7-f86c-4155-9bae-465887cee5f5"},{"name":"mounted NodeID anv","item":[{"name":"POST - NodeID - anv - device-manager","id":"3efac22b-0583-42d3-ad77-eb443dc64a3a","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[{"key":"Content-Type","value":"application/json"}],"body":{"mode":"raw","raw":"null","options":{"raw":{"language":"json"}}},"url":"http://localhost:8888//restconf/data/network-topology:network-topology/topology=topology-netconf/node=This endpoint is for creating device manager on node NodeID.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=This endpoint is for reading the device manager from a node NodeId.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=This endpoint is for deleting a node NodeID device manager.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=This endpoint is for updating a node NodeID device manager.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=This endpoint is for querying a node NodeID device plugs.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=(Required)
\n","type":"text/plain"},"key":"content","value":"List of device plugs currently supported by this instance of\n PMA. A device plug is identified by a hardware-type and interface-version.\n Reference to a device plug (EG provided when creating a device)\n should use explicit reference to this list, as a leafref.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=(Required)
\n","type":"text/plain"},"key":"content","value":"NOT SUPPORTED\nThe resource-allocation container lists the resource types that\ncan be allocated by the Slicing Manager to each virtual device of the\ndevice plug
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=(Required)
\n","type":"text/plain"},"key":"content","value":"The private or read-only resources are the resources that can be\nallocated by the Slicing Manager to a virtual device, either as:
\n(Required)
\n","type":"text/plain"},"key":"content","value":"List of non-coded device plugs currently supported or currently being deployed\non this instance of PMA.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=(Required)
\n","type":"text/plain"},"key":"content","value":"List of Nokia device plugs currently supported or currently being deployed on this instance of PMA.
\n","urlObject":{"path":["restconf","data","network-topology:network-topology","topology=topology-netconf","node=(Required)
\n","type":"text/plain"},"key":"content","value":"