Hello all,
I try to find a subject that uses ONOS and P4 in order to do my diploma thesis. I am open to different domains about it from 5G to DPI, but i can’t find a specific feasible scenario to make it happen.
So I kindly ask from someone a little guidance about what use case it would a good diploma thesis related to ONOS and P4.
Any help is more than welcome!
Thanks in advnace.
Best Regards,
Panagiotis
Hi @ppavlidis,
Now a day an hot topic in the P4 community are SMART NICs, so the environment is 5G and Data Center. Unfortuntelly, till now , it is all in the early stages of development.
Feasible projects for ONOS+P4 can be:
propose augmentations for the in band telemetry (https://p4.org/p4-spec/docs/INT_v2_1.pdf) , here you can find one of the first implementation In-band Network Telemetry (INT) with ONOS and P4 - ONOS - Wiki.
You can provide telemetry/monitoring via P4+ONOS for various scenarios such as 5g, Data Center etc.
You can offload some networking functionalities provided by gNodeB in P4+ONOS
Could you please be more specific? I found the SD-Fabric project but i am not sure if can do something with it without hardware requirements. As far as I know there is the bmv2 software switch that supports P4.
Can you give me a hand? The mininet and onos stopped working when I changed the topology of the in-band telemetry.
mininet will report the following error:
Hi @hero,
To be fair i don’t know how come this error is correlated with the change in topology. Because you thorw an error in the bhevaioral model implemnetations, so seems that you pass to the the switch something that is not correc in the C/C++ implementation.
Thanks, I will check my topology carefully, is it feasible to modify this app for in-band telemetry? In other words, have you ever seen or personally modified the topology and run it successfully? Because I read on the Internet that this topology modification is difficult. When I tried to modify it, I reported an error but had no way to start, so I wanted to know if this path was feasible and worth trying.
You can modify the python script used by mininet for deploying the topology as you prefer, this change does not affect the implementation of P4 and behavioral model code.
Basically the python script create the number of switches that you need with the respective interfaces and links, in other word it generates the virtual network node instances.
Thank you, I just modified it on the script. After the modification, the above error is reported. I just want to change it to fat tree topology. Let me try, and I’ll go over the script that generated the topology. If you have time, could you help me see what is wrong? I would be very grateful to you.
class ClosTopo4(Topo):
def init(self, args, **opts):
Topo.init(self, **opts)
#Marking the number of switch for per level
k=4
pod=k
L1 = (pod/2)**2
L2 = pod*pod/2
L3 = L2
#Starting create the switch
c = [] #core switch
a = [] #aggregate switch
e = [] #edge switch
#notice: switch label is a special data structure
for i in range(L1):
deviceId = i+1
latitude = SWITCH_BASE_LATITUDE + 3 * BASE_SHIFT
longitude = BASE_LONGITUDE + 2*i * BASE_SHIFT
c_sw = self.addSwitch('c{}'.format(i+1),cls=ONOSBmv2Switch,
loglevel=args.log_level,
deviceId=deviceId,
netcfg=True,
netcfgDelay=0.5,
longitude=longitude,
latitude=latitude,
pipeconf=args.pipeconf_id)
#label from 1 to n,not start with 0
c.append(c_sw)
for i in range(L2):
deviceId = L1+i+1
latitude = SWITCH_BASE_LATITUDE + 2 * BASE_SHIFT
longitude = BASE_LONGITUDE + i * BASE_SHIFT
a_sw = self.addSwitch('a{}'.format(L1+i+1),cls=ONOSBmv2Switch,
loglevel=args.log_level,
deviceId=deviceId,
netcfg=True,
netcfgDelay=0.5,
longitude=longitude,
latitude=latitude,
pipeconf=args.pipeconf_id)
a.append(a_sw)
for i in range(L3):
deviceId=L1+L2+i+1
latitude = SWITCH_BASE_LATITUDE + 1 * BASE_SHIFT
longitude = BASE_LONGITUDE + i * BASE_SHIFT
e_sw = self.addSwitch('e{}'.format(L1+L2+i+1),cls=ONOSBmv2Switch,
loglevel=args.log_level,
deviceId=deviceId,
netcfg=True,
netcfgDelay=0.5,
longitude=longitude,
latitude=latitude,
pipeconf=args.pipeconf_id)
e.append(e_sw)
#Starting create the link between switchs
#first the first level and second level link
for i in range(L1):
c_sw=c[i]
start=i%(pod/2)
for j in range(pod):
self.addLink(c_sw,a[start+j*(pod/2)],cls=TCLink, bw=DEFAULT_SW_BW)
#second the second level and third level link
for i in range(L2):
group=i/(pod/2)
for j in range(pod/2):
self.addLink(a[i],e[group*(pod/2)+j],cls=TCLink, bw=DEFAULT_SW_BW)
#Starting create the host and create link between switchs and hosts
for i in range(L3):
for j in range(2):
hs = self.addHost('h{}'.format(i*2+j+1), cls=DemoHost,
ip="10.0.0.{}/24".format(i*2+j+1),
mac='00:00:00:00:00:%02x' % (i*2+j+1))
self.addLink(e[i],hs,cls=TCLink, bw=DEFAULT_HOST_BW)
Did you installed a recent version of BMV2?
Are you recompiled the P4 int code?
I only changed the script that generated the topology, not the p4 code, so I didn’t recompile. It is not the latest version of the bmv2. Do you mean that the problem may be caused by not the latest version of the bmv2?
I only changed the script that generated the topology, not the p4 code, so I didn’t recompile. I am using the bmv2-demo that comes with onos to implement in-band telemetry, and I want to modify this topology to report the above error. Do you mean that the problem may be caused by the fact that the bmv2 is not the latest version?
I only changed the script that generated the topology, not the p4 code, so I didn’t recompile. I am using the bmv2-demo that comes with onos to implement in-band telemetry, and I want to modify this topology to report the above error. Do you mean that the problem may be caused by the fact that the bmv2 is not the latest version?
Did p4 work in the previous topology ? Because you might have a version problem, due to the fact that the INT code is compiled few years ago
When I tried onos app Inband telemetry, it turned out that the topology worked normally, mininet error would not be reported, and telemetry data could be looked up in the database. When I changed his original 2*2 topology to fat-tree topology, mininet reported an error, which caused onos to not work properly. I didn’t see much difference between his topology and mine, and I couldn’t figure out why it wouldn’t work.
class ClosTopo(Topo):
The following is his original code:
#2 stage Clos topology
def __init__(self, args, **opts):
# Initialize topology and default options
Topo.__init__(self, **opts)
bmv2SwitchIds = []
length=len(bmv2SwitchIds)
for row in (1, 2):
for col in range(1, args.size + 1):
bmv2SwitchIds.append("s%d%d" % (row, col))
bmv2Switches = {}
#for Id in range(length,len(bmv2SwitchIds)):
for switchId in bmv2SwitchIds:
#switchId=bmv2SwitchIds[Id]
deviceId = int(switchId[1:])
# Use first number in device id to calculate latitude (row number),
# use second to calculate longitude (column number)
latitude = SWITCH_BASE_LATITUDE + (deviceId // 10) * BASE_SHIFT
longitude = BASE_LONGITUDE + (deviceId % 10) * BASE_SHIFT
bmv2Switches[switchId] = self.addSwitch(switchId,
cls=ONOSBmv2Switch,
loglevel=args.log_level,
deviceId=deviceId,
netcfg=True,
netcfgDelay=0.5,
longitude=longitude,
latitude=latitude,
pipeconf=args.pipeconf_id)
for i in range(1, args.size + 1):
for j in range(1, args.size + 1):
if i == j:
self.addLink(bmv2Switches["s1%d" % i],
bmv2Switches["s2%d" % j],
cls=TCLink, bw=DEFAULT_SW_BW)
if args.with_imbalanced_striping:
# 2 links
self.addLink(bmv2Switches["s1%d" % i],
bmv2Switches["s2%d" % j],
cls=TCLink, bw=DEFAULT_SW_BW)
else:
self.addLink(bmv2Switches["s1%d" % i],
bmv2Switches["s2%d" % j],
cls=TCLink, bw=DEFAULT_SW_BW)
for hostId in range(1, args.size + 1):
host = self.addHost("h%d" % hostId,
cls=DemoHost,
ip="10.0.0.%d/24" % hostId,
mac='00:00:00:00:00:%02x' % hostId)
#switchId=(hostId+1)/2
self.addLink(host, bmv2Switches["s1%d" % hostId],
cls=TCLink, bw=DEFAULT_HOST_BW)
If I remember well the script made by ONF generate the Json files needed to push the devices in the controller. So maybe you are generating those file in the wrong way.
Yes, the ONF script generates these json files. I just changed the topology, nothing else. This also causes file generation errors, right? His error message came from the bmv2 log. I tried to find out the source of the error message and how it was generated, but failed.
Ok, so take a look to json files because maybe are “malformed” due to the change of the topology script.
I have tried to check the json file in the past, but found no obvious errors, the json file generation is fairly standard, and no configuration errors were found after checking.
{
“hosts”: {
“00:00:00:00:00:09/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.9”
],
“locations”: [
“device:bmv2:e17/3”
],
“longitude”: -43,
“name”: “h9”
}
},
“00:00:00:00:00:0b/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.11”
],
“locations”: [
“device:bmv2:e18/3”
],
“longitude”: -27,
“name”: “h11”
}
},
“00:00:00:00:00:01/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.1”
],
“locations”: [
“device:bmv2:e13/3”
],
“longitude”: -107,
“name”: “h1”
}
},
“00:00:00:00:00:0f/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.15”
],
“locations”: [
“device:bmv2:e20/3”
],
“longitude”: 5,
“name”: “h15”
}
},
“00:00:00:00:00:0d/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.13”
],
“locations”: [
“device:bmv2:e19/3”
],
“longitude”: -11,
“name”: “h13”
}
},
“00:00:00:00:00:0e/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.14”
],
“locations”: [
“device:bmv2:e19/4”
],
“longitude”: -3,
“name”: “h14”
}
},
“00:00:00:00:00:10/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.16”
],
“locations”: [
“device:bmv2:e20/4”
],
“longitude”: 13,
“name”: “h16”
}
},
“00:00:00:00:00:03/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.3”
],
“locations”: [
“device:bmv2:e14/3”
],
“longitude”: -91,
“name”: “h3”
}
},
“00:00:00:00:00:08/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.8”
],
“locations”: [
“device:bmv2:e16/4”
],
“longitude”: -51,
“name”: “h8”
}
},
“00:00:00:00:00:07/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.7”
],
“locations”: [
“device:bmv2:e16/3”
],
“longitude”: -59,
“name”: “h7”
}
},
“00:00:00:00:00:02/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.2”
],
“locations”: [
“device:bmv2:e13/4”
],
“longitude”: -99,
“name”: “h2”
}
},
“00:00:00:00:00:0a/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.10”
],
“locations”: [
“device:bmv2:e17/4”
],
“longitude”: -35,
“name”: “h10”
}
},
“00:00:00:00:00:06/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.6”
],
“locations”: [
“device:bmv2:e15/4”
],
“longitude”: -67,
“name”: “h6”
}
},
“00:00:00:00:00:04/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.4”
],
“locations”: [
“device:bmv2:e14/4”
],
“longitude”: -83,
“name”: “h4”
}
},
“00:00:00:00:00:05/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.5”
],
“locations”: [
“device:bmv2:e15/3”
],
“longitude”: -75,
“name”: “h5”
}
},
“00:00:00:00:00:0c/-1”: {
“basic”: {
“latitude”: 28,
“ips”: [
“10.0.0.12”
],
“locations”: [
“device:bmv2:e18/4”
],
“longitude”: -19,
“name”: “h12”
}
}
},
“devices”: {},
“links”: {}
}
This is followed by a specific switch file：
{
“devices”: {
“device:bmv2:c1”: {
“ports”: {
“1”: {
“name”: “c1-eth1”,
“speed”: 10000,
“enabled”: true,
“number”: 1,
“removed”: false,
“type”: “copper”
},
“3”: {
“name”: “c1-eth3”,
“speed”: 10000,
“enabled”: true,
“number”: 3,
“removed”: false,
“type”: “copper”
},
“2”: {
“name”: “c1-eth2”,
“speed”: 10000,
“enabled”: true,
“number”: 2,
“removed”: false,
“type”: “copper”
},
“4”: {
“name”: “c1-eth4”,
“speed”: 10000,
“enabled”: true,
“number”: 4,
“removed”: false,
“type”: “copper”
}
},
“basic”: {
“latitude”: 49,
“managementAddress”: “grpc://127.0.0.1:51931?device_id=1”,
“driver”: “bmv2”,
“longitude”: -115,
“pipeconf”: “org.onosproject.pipelines.int”
}
}
}
}
onos reports the following error.
I guess it is because the connection between the two sides of p4runtime is not established successfully. Because the index exceeds the upper limit, this exception is triggered. As a result, the grpc server of the switch is shut down, and the client in onos cannot establish the connection with the switch.
Indeed the device_id should be always equal to 1 for each switch in the network
I know. In the json files of all switches, the device_id is equal to 1, but the port is different.
