This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.
Related
How to get Throughput in OpenFlow Networks
We use OpenFlow 1.3 and Ryu Controller.
For Ryu Controller using OpenFlow, you may need to calculate based on statistics data received in OFPPortStats as part of OPFPortStatsReply for which you may need to use OFPPortStatsRequest message, to request port statistics info. Similarly, you can parse the OFPFlowStats of OPFFlowStatsReply message for flow based statistics calculation which shall be received as response for the request message OFPFlowStatsRequest.
OFPFlowStatsRequest can be used to get statistical information related to flow entry with switch. The requested target flow entry can be identified by conditions such as table ID, output port, cookie value and match but here all entries are made subject to the request.
OFPPortStatsRequest can be used to get port-related statistical information with switch. It is possible to specify the desired port number to acquire information from and OFPP_ANY can be specified to request information from all ports.
You may need to ceate an event handler that receives the PortStatsReply message. OPFPortStatsReply class’s attribute body is the list of OFPPortStats. The OFPPortStats has statistical information such as port numbers, send/receive packet count, respectively, byte count, drop count, error count, frame error count, overrun count, CRC error count, and collision count.
You may need to define a stats thread that send above requests messages and parse reply messages periodically. Once the statistics data it available, iterate/parse through the statistics information and compute bandwidth usage .
There are many other kind of requests you can perform and operate on the responses for which you can refer to http://osrg.github.io/ryu-book/en/html/traffic_monitor.html.
Calculating throughput on mininet will just give you a simulated answer which may not be true. However, check out the iPerf tool and see how you can integrate it with mininet.
In SysML, when modeling a message, I'm having trouble understanding what element type should be used to define it, its elements, and a port that it flows through.
I'm assuming it is either:
a raw Block
the more specialized InterfaceBlock
Both can type a proxy port (formerly flow port, if I understand correctly), or type most other properties in other blocks as one builds up a full message interface or port system (either straight ports or nested ports). If the base message definition is a normal block, then when do you create a flow property that gets typed by that block, so that something can actually flow from one task to another through the port?
An Interface Block should occur somewhere in there, in order to type the port, right? Does that mean I use it to define a message directly, or does that depend on my port scheme (i.e. whether I nest ports and to what level)?
I guess this boils down to confusion over when you are defining a thing (i.e. a class/block) and when you are defining that this thing is a quantity that flows in your model (a flow of some kind - the message passes from one task or piece of hardware to another).
P.S. I'm using MagicDraw as the SysML tool, but I don't think that should impact the core answer.
The answer, as developed by my team:
Use a full port for the raw network interface, the physical layer.
Use a block to type the network interface, including:
Flow properties that represent physical items flowing out of the port, such as total electrical current (power).
Nested full port elements for physical nested ports, such as pins that make up a physical ethernet port. Type with another block.
Nested <> elements for logical/abstract data flows across the network interface, such as sockets/connections
Use an Interface Block to type each logical connection (nested proxy port) with an Interface Block containing the following:
Flow properties that represent blocks of data, such as messages, which are sent as a group across the connection
Value properties that define characteristics of that connection, such as source and destination IP addresses and port numbers, comm loss and retry info, etc. Note some of this may be better served as meta data in tags as part of a separate stereotype.
Type the data flow properties of the connections with a ValueType whose attributes are the individual data elements of that data block (i.e. the message elements).
Create a new stereotype with a custom name something like "Data Element" and add tags for any meta-data that is needed about each data element, such as length (in bits or bytes), underlying type in the message, any unit or scaling factors, position in the message, etc.
You can even create a generic table at this point which will list every data element in a given message, or in all messages, and add all the relevant Data Element tags as columns, and use it as a current specification for each message and data element of each message, and allow much easier editing of all the information directly in that table.
Why use ValueTypes for data blocks that flow across Proxy Ports? Because then they will show up as Information Flow items instead of Item Flow items across a connector between two Proxy Ports on an Internal Block Diagram (IBD). I.e. when I send a physical item, typed by a Block, it is sent as an Item Flow, but when I send a logical item, such as data, it is typed by a ValueType, and sent as an Information Flow.
This is a starting point - we found issues with nesting the valuetype definitions initially, so opted for a much flatter message definition that contained all the aspects of a message in a single ValueType, rather than nesting them. I'm sure there are ways around this, but how complicated do you want to get?
I am trying to implement a monitoring system using ONOS. I am able to collect the port delta statistics from them using port_stat_changed listener.
In the flow statistics, I get the flow entry, which has selection criterion. This criterion only has only Ethernet information. Is there any way to identify the Source and Destination IP address and Port using ONOS. Any suggestion would be very helpful.
The source and destination IP and MAC if they are not in the Switch's rules can be accessed by the application by taking this information from the packets. If your application does not have access to the packages, I do not think the Switches store this kind of information. In case, then, you're going to have to develop a solution by putting a rule in the Switch to pick up that data.
hi guys i'm making a client-server software and this is my first question
i'd like to ask: how to distinguish data that sended by tcp Connection?
Well, my points are:
-we can determine data that sended by tcpconnection.
for example, we have 3 Listviews in our form
the point of the first listview is for Biodata of client.
the point of second listview is for *The value obtained from the clients
n the point of third listview is for The picture obtained from the clients
in this case we have 3 main points that must be processed.
in fact, we only have 1 connection in our system.
Well, here I'm confused..
how to determine that data we received is for the first listview or second listview or third listview?
remember, the data of third listview is a picture that we received from tcpconnection
How do we do that with 1 connection in our system?
do i have to make 3 connection to control third listviews?
With socket communication, both the client and the server must use the same agreed-upon protocol so that they can understand each other. There are many standard protocols that have already been created, so for most tasks, creating your own protocol is unnecessary. However, if you must, you can always define your own protocol. The nature of your protocol will obviously depend completely on your specific needs, so it would be impossible to tell you what the protocol should be. However, generally speaking, the first thing your protocol must define is how to know where each complete message begins and ends. This is often accomplished by separating each message with a delimiter (e.g. new line, EOF, null). As Francois recommended, you could alternatively specify the length of the message at the beginning of each message. Within each message, you then will need a header section which, among other things, would specify the type (the format) of the data stored in the body of the message.
A simple implementation might be to send each message as a JSON or XML document. Doing so makes it very easy to define and modify the format of the message.
However, unless you really need to, I would recommend using one of the built-in communication frameworks that are provided with .NET. For simple tasks, often a simple asmx web service is sufficient. For more complex tasks, often WCF is a good choice. An asmx web service uses SOAP via HTTP via TCP/IP. WCF uses SOAP, but the lower level connection is configurable so it doesn't have to use TCP/IP, but it can easily do so.
Does libpcap get a copy of the packet or the actual packet?
By copy, I mean: the application using libpcap gets packet A, and the kernel also gets packet A.
By actual, I mean: only the application using libpcap gets packet A, but the kernel didn't get it.
libpcap will not allow you to do what you want. The goal of pcap is to transparently receive a copy of every packet in the system.
You should investigate how to inter-operate with the existing firewall in your system, or how to add your own filters to the netfilter system (on Linux)
The kernel will get the packet then pass it through a list of filters (for example, there's usually a filter for IPsec, a firewall and so on) and once it's gone through all of these filters, it passes the packet on to the application. libpcap is another filter, but it simply adds the packet to an internal database for processing, rather than inspecting the packet, modifying or whatever else the other filters will do.
For what you want to do, the simplest solution would be to use a firewall.