misc

[Desmond Kang]

Hi ONOS Developers, 

I am developing a new solution to replace the current LLDP Link Provider application. But I first need to check if ONOS has a one-to-one mapping of the switchport MAC Address to a local switch port identifier.

I have been reading the source code for 3 days at least but still dont find any clues that ONOS records the MAC address of the switch. 

By right, ONOS should receive the MAC of every switch when it receives the following multipart_reply message.

But I cant figure out a way to check if ONOS records it down or not. Is there a documentation that covers also the //providers and //protocols etc? as I searched the http://api.onosproject.org/2.7.0/apidocs/ and still having hardship in understanding the algorithm.

Thanks in advance

[Eder Ollora]

Hi Desmond,

I am also working with extending LLDP in ONOS. I am not going to replace it, but I am definitely extending the functionality. :)

I have not made a deep reading of the link provider/discovery app, but maybe I can help on my knowledge about it.

I think we have one place to look at in the LinkDiscovery class. Furthermore, I assume you are only interested in ONOSLLDP packets, which, btw, extends the LLDP packet. But the process of identifying the source device and port, are not the exactly same. 

If you check the code in processOnosLldp, you will notice that if everything is fine with the packet, ONOS will store the information as a LinkDescription object. This object takes the source and destination ConnectPoints as input when creating it. The ConnecPoints (one for source device and one for destination device) are, from a simple point of view, a combination of source device id & port and also destination device id & port. In summary, it seems that link information is stored as a combination of ConnecPoints involved in an LLDP transaction.

Now, you asked if it keeps any reference to switch/device MAC address. Well, if you check the code from LinkDiscovery, you can see that the app is extracting a value from an LLDP TLV (idString). This value should represent de source device id. This value is used, with the source port, as the input to create a Connecpoint. 

ONOS knows both the source device and port, when the OPENFLOW PACKET_IN arrives from the destination device, because it was at first ONOS that told the source device to output the LLDP packet to the port towards the destination device. And because it was ONOS itself telling it to do so, it also serialized the device id and source port as part of TLVs. It is the LLDP deserializer (when the packet arrives to ONOS again) that extracts this information. See the deserializer here. Of course, you can find the part of the code that created the ONOS LLDP packet and serialized the information in the beginning. 

I think the one-to-one mapping you ask about is clear in this line. I believe it does not store a MAC-port relation, but it keeps track of ConnecPoints (DeviceId and PortNumber). Likewise, I have not analyzed the app, entirely, but that is my opinion so far.

I hope it helps,

[Desmond Kang]

Hi Eder, thanks for explaning so much details about LLDP discovery mechanism. It really helped me advanced alot faster than I would expect.

Based on my understanding, current LLDP Link Provider uses ONOSLLDP to identify links.

In this line, we know that ONOS is using the Ethernet src mac as a fingerprint used for identification of mastership when multiple ONOS instance are running over the same domain. And this is what makes ONOSLLDP special when compared to its inheritted LLDP.

However, currently what I'm working on to modify the LLDP Link Discovery behavior requires the Src Mac of the switches to be specific to every switchport. Means that my implementation requires ONOS to not use the Src Mac as the fingerprint. Instead, I should find another way to let ONOS to identify for mastership (maybe add another field in the LLDP TLV payload?).

The reason I'm using the src mac is that ONOS will be able to identify src port simply by reading the src mac. Which is another reason I need ONOS to have the one-to-one mapping for the MAC Address of every switchport to a local port identifier.

My first step is to build the mapping function to create a reference for ONOS to identify ports through switchport mac addresses. My plan is to intercept OpenFlow Features Reply messages containing the Port Description, like this one. 

I learned that we can intercept network packets using Packet Service and Packet Processor and Traffic Selector (https://api.onosproject.org/2.7.0/apidocs/org/onosproject/net/packet/package-summary.html), but I don't seem to find a way to intercept OpenFlow traffic. Please suggest some ways to intercept OpenFlow traffic so that I can retrieve the mac address of switch and create the one-to-one mapping.

Thanks in advance

[Eder Ollora]

  Hi,

I will try to answer with the things I know :)

Based on my understanding, current LLDP Link Provider uses ONOSLLDP to identify links.

In this line, we know that ONOS is using the Ethernet src mac as a fingerprint used for identification of mastership when multiple ONOS instance are running over the same domain. And this is what makes ONOSLLDP special when compared to its inheritted LLDP.

That's a fair point. One reason could be to identify the links from a device that one particular controller is managing. I guess that the LLDP app is distributed so if another controller receives the LLDP packet at the "other end", both controllers will ultimately compare the metadata from an (ONOS)LLDP packet and add the link to the store. I guess that if another non-SDN device sends an LLDP packet, the controller can also identify that there might be another device past that "edge" OpenFlow switch.

However, currently what I'm working on to modify the LLDP Link Discovery behavior requires the Src Mac of the switches to be specific to every switchport. Means that my implementation requires ONOS to not use the Src Mac as the fingerprint. Instead, I should find another way to let ONOS to identify for mastership (maybe add another field in the LLDP TLV payload?).

The switches will not modify the MAC address of the packet. This is clear from the flow rule that you can check yourself. I guess there are different approaches for this. You can try to modify src MAC for every different output device+port. Or you can just craft a packet with a particular src MAC. Because the controller knows which device and port is sent using the PACKET_OUT, then you can establish which source MAC to use. Alternatively, using a special TLV for this will require less modification of the core LLDP provider. However, because you want to modify the code functionality of the LLDP app in ONOS, your implication on analyzing the code and commenting out the actual code that manages links is inevitable.

The reason I'm using the src mac is that ONOS will be able to identify src port simply by reading the src mac. Which is another reason I need ONOS to have the one-to-one mapping for the MAC Address of every switchport to a local port identifier.

I think I understand what you mean but parsing LLDP packets is "automatic" . So having a TLV, yes, it is a little more complex because you need to deserialize it but you can have one to one mapping with many different components from a packets. Source MAC, still, could be the best option. 

My first step is to build the mapping function to create a reference for ONOS to identify ports through switchport mac addresses. My plan is to intercept OpenFlow Features Reply messages containing the Port Description, like this one. 

I learned that we can intercept network packets using Packet Service and Packet Processor and Traffic Selector (https://api.onosproject.org/2.7.0/apidocs/org/onosproject/net/packet/package-summary.html), but I don't seem to find a way to intercept OpenFlow traffic. Please suggest some ways to intercept OpenFlow traffic so that I can retrieve the mac address of switch and create the one-to-one mapping.

Consider, I am not absolutely sure of what exactly you want to achieve and how you want to do it, so my comments might or not apply to your use case. I think I would go in a different way. I would create an event listener when  a new device is added to the controller. You can even create an event listener when new ports are added to the ONOS store. This happens when devices and controllers communicate with OpenFlow and new devices are discovered or new ports are discovered, you do not need to intercept OpenFlow messages to be aware of new devices and/or ports. You can see an example of the code in classes that are normally named "InternalDeviceListener()". You implement it as a private class in your application and when you Override the event method, then you can execute code when a new device is added by the controller or a new port is added (examples as links). Once you discover a port from a particular device you can assign a MAC to that port yourself (and with assign I mean associate in your own app). You can keep a local list or Map<ConnectPoint, MacAddress> that associates a particular Device+Port (I wrote ConnectPoint, but you can use any class) to the way that you define your own MAC address. Once you have all necessary entries in your Map, you could modify the LLDP provider app to introduce the appropriate source MAC. I think this is done here and more deeply here, but not 100% sure. Consider that if you change this behavior, you will also have to change the way that ONOS initially conceived the srcMac for LLDP so you do not break the existing src MAC processing to identify mastership for some devices. This is why custom TLVs are always more flexible and help on building on top of the existing code without significant changes.

I hope it helps,