This module aims to define YANG as a programming language, making it an embodiment of an active networking language. The goa...
Organization:
IEEE Std 1906.1-2015 - Recommended Practice for Nanoscale and Molecular Communication Framework Working Group
Module:
ieee1906-dot1-function
Version:
2020-12-07
File:
Abstract:
This module aims to define YANG as a programming language, making it an embodiment of an active networking language. The goa...
Contact:
Stephen F. Bush <bushsf@research.ge.com>
Guillaume Mantelet <gmantelet@voltigeurnetworks.com>
Check for an additional details:
Description:
This module aims to define YANG as a programming language, making it an embodiment
of an active networking language.
The goal of this YANG function is to use a NETCONF server to remotely execute
mathematic and logic functions. For example, one could imagine an interactive
Python or matlab console exchanging function calls through XML RPCs.
+--------------------+------------+----------------------------------------------+
| name | type | description |
+--------------------+------------+----------------------------------------------+
| call | rpc | Use to call a function and get a result |
| dynamic-programming| feature | This server can program with YANG |
| dynamic-assignment | feature | This server can assign to session variables |
| function | grouping | A function to call with its positional args. |
| language | identity | The language that is supported by the server |
| name | annotation | XML attribute to assign to session variables |
| number | typedef | String representation of a number |
| variable-name | typedef | String representation of a session variable |
| variable | typedef | Number or unknown defined by a name |
+--------------------+------------+----------------------------------------------+
An RPC to explicitly call a function on the server is also defined.
Defining the function behavior is out of the scope of this YANG model. This YANG
model only assumes that the functions to be used have consensus among the
community. For example, a sum should be a well known function and the XML RPC
function would look like:
If previous RPC led to the NETCONF server stores a=2 and b=3 for that session,
then:
<call>
<function>
<name>sum</name>
<arg>a</arg>
<arg>b</arg>
<arg>1</arg>
</function>
<call>
And the NETCONF server would return:
<call>
<result>
<sum>6</sum>
</result>
</call>
An annotation provides support for dynamic assignment for the current session, and
provides hints for the NETCONF server. Annotation offering naming means that
'name' can be used as an XML attribute for leaves, functions and containers:
<call>
<function name='c'>
<name>sum</name>
<arg>2</arg>
<arg>3</arg>
</function>
<call>
Is a hint so that the NETCONF server returns:
<call>
<result>
<c>5</c>
</result>
</call>
The scope of this call is that the assignment is lost when the result is returned.
However, if 'c' had been previously defined as an assignment for this session, the
function will assign the result to 'c', and 'c' can then be retrieved later. If
<get>
...
<myLeaf>c</myLeaf> //myLeaf is of type instance-identifier or variableName
...
</get>
The NETCONF server would return:
<data>
...
<myLeaf>5</myLeaf>
...
</get>
© 2023 YumaWorks, Inc. All rights reserved.