1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
/** @mainpage About hICN sysrepo plugin
*This plugin serves as a data management agent. It provides yang models via
*NETCONF to allow the management of hicn-plugin which runs in VPP instance from out-of-box.
*The following sections contain more details:
*- @subpage subp1 "hICN yang model"
*- @subpage subp2 "User Guide"
*- @subpage subp3 "Developer Guide"
*/
/** @page subp1
*hicn.yang consists of one container for providing the state data (i.e., hicn-state).
*It consists of state, route, and face-ip-params
*nodes with the corresponding leaves. In the hicn model a variety of RPCs are provided
*to allow controller to communicate with the hicn-plugin as well as update the state
*data in hicn-state. You can install the yang model using the following bash script:
```
EXIT_CODE=0
command -v sysrepoctl > /dev/null
if [ $? != 0 ]; then
echo "Could not find command \"sysrepoctl\"."
exit ${EXIT_CODE}
else
sysrepoctl --install path_to_hicn_yang_model
fi
```
*Here you can find different examples to run RPC in the yang-model.
```
<hicn-enable xmlns="urn:sysrepo:hicn">
<prefix>b001::/64</prefix>
</hicn-enable>
<hicn-disable xmlns="urn:sysrepo:hicn">
<prefix>b001::/64</prefix>
</hicn-disable>
```
*/
/** @page subp2
*Firstly, verify the plugin and binary libraries are located correctly, then run
*the vpp through (service vpp start). Next, run the sysrepo plugin (sysrepo-plugind),
*for debug mode: sysrep-plugind -d -v 4 which
*runs with high verbosity. When the hicn sysrepo plugin is loaded, run the
*netopeer2-server which serves as NETCONF server.
*## Connect from netopeer2-cli
*In order to connect through the netopeer client run the netopeer2-cli. Then, follow these steps:
```
*- connect --host XXX --login XXX
*- get (you can get the configuration and operational data)
*- user-rpc (you can call one of the rpc proposed by hicn model but it needs an xml input)
```
*## Connect from OpenDaylight (ODL) controller
*In order to connect through the OpenDaylight follow these procedure:
*- run karaf distribution (./opendayligh_installation_folder/bin/karaf)
*- install the required feature list in DOL (feature:install odl-netconf-server
* odl-netconf-connector odl-restconf-all odl-netconf-topology or
* odl-netconf-clustered-topology)
*- run a rest client program (e.g., postman or RESTClient)
*- mount the remote netopeer2-server to the OpenDaylight by the following REST API:
*PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/hicn-node
* with the following body
```
<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<node-id>hicn-node</node-id>
<host xmlns="urn:opendaylight:netconf-node-topology">Remote_NETCONF_SERVER_IP</host>
<port xmlns="urn:opendaylight:netconf-node-topology">830</port>
<username xmlns="urn:opendaylight:netconf-node-topology">username</username>
<password xmlns="urn:opendaylight:netconf-node-topology">password</password>
<tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
<keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">1</keepalive-delay>
</node>
```
*Note that the header files must be set to Content-Type: application/xml, Accept: application/xml.
*- send the operation through the following REST API:
*POST http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/hicn-node/yang-ext:mount/ietf-netconf:edit-config
*The body can be used the same as edit-config in netopeer2-cli.
*## Connect from Network Services Orchestrator (NSO)
*To connect NSO to the netopeer2-server, first, you need to write a NED package
*for your device. The procedure to create NED for hicn is explained in the following:
*Place hicn.yang model in a folder called hicn-yang-model, and follow these steps:
*- ncs-make-package --netconf-ned ./hicn-yang-model ./hicn-nso
*- cd hicn-nso/src; make
*- ncs-setup --ned-package ./hicn-nso --dest ./hicn-nso-project
*- cd hicn-nso-project
*- ncs
*- ncs_cli -C -u admin
*- configure
*- devices authgroups group authhicn default-map remote-name user_name remote-password password
*- devices device hicn address IP_device port 830 authgroup authhicn device-type netconf
*- state admin-state unlocked
*- commit
*- ssh fetch-host-keys
*At this point, we are able to connect to the remote device.
*/
/** @page subp3
*This guide contains information intended for developers that need to extend/modify the hICN yang model.
*# Adding configuration data
*In order to add configuration data, firstly it requires to update yang model and define the configuration paramters
*through a container and define the leaves. Once the yang model is updated in the sysrepo plugin you need to subscribe
*for ```sr_module_change_subscribe``` and provide the appropriate callback.
*
*
*# Adding new RPC
*
*In order to add RPC call, firstly it requires to update the yang model by new ```rpc``` statements and define the input to them.
*# Adding new operational data
*
*In order to add operational data, firstly it requires to add operational data in yang model by adding ```confg false``` to the container.
*Then, update the sysrepo plugin by the adding the ```sr_oper_get_items_subscribe```.
Example:
I have a switch with two ports. I am going to write an RPC call to switch them on/off
, moreover I need to read operational data from each port. So, the following yang model can be proposed:
```
module switch {
namespace "urn:sysrepo:switch";
prefix swtch;
revision 2019-12-08{
description "Initial revision.";
}
grouping status-reply{
list port{
key portid;
leaf portid {
description "the port id.";
type uint32;
}
leaf status {
description "the status of the port.";
type boolean;
}
}
}
rpc power {
description "Operation to power on/off switch.";
input {
leaf turned-on {
description "indicating on or off.";
type boolean;
default false;
}
}
}
container switch-state {
config false;
description "operational data container for the switch.";
container status{
uses status-reply;
}
```
Afterwards, the following subscribes are required in the sysrepo plugin.
```
sr_rpc_subscribe(session, "/switch:power", callback,
session, 100,SR_SUBSCR_CTX_REUSE, subscription);
```
session is the opened session with sysrepo, xpath is the path in the yang model, callback is the function
when RPC arrives, private context passed to the callback function, priprity which is set to 100 here indicates the priority if there re multiple RPCs,
options can alter the normal behaviour, and subscription is the subscribtion when initialize the connection towards the sysrepo
```
rc = sr_oper_get_items_subscribe(session, "switch","/switch:switch-state/status",
callback, NULL, SR_SUBSCR_CTX_REUSE,
subscription);
```
session is the opened session with sysrepo, xpath is the path in the yang model, callback is the function
when RPC arrives, private context passed to the callback which is NULL here,
options can alter the normal behaviour, and subscription is the subscribtion when initialize the connection towards the sysrepo
*/
|
