dear,
i am trying to understand if it possible to run different industrial protocol on the same physical network.
for example, i need to run Bacnet/IP and MODBUS TCP/IP on the same physical network, each of them will have separate port but will run on the same converged network.
appreciate any info on this,
charbel
Summary
Yes, it is possible because IP and TCP were designed to do this.
Details
The "OSI seven-layer model" is what makes this possible, and even though strictly speaking TCP/IP may not follow that model exactly, it does follow the same general principles. The basic idea is that each layer rides on top of, but is invisible (opaque) to, the layer below it. The "physical network" is comprises layers 1 (physical - analog signal usually voltage) and 2 (data - bits), and possibly 3 (network - host addresses).
As you note, the individual protocols (BACNET/TCP and MODBUS/TCP) use separate ports, so they are isolated in layer 4 (transport - source and destinations hosts' IP addresses and ports) and above i.e. layer 4 segregates, in a sense, traffic for TCP port 47808 (BACNET) from TCP port 502, and the layers below don't know the difference.
BACNET and MODBUS protocols, i.e. the data requests to and responses from the server, operate at levels 5 or 6 and above.
Every logical client-server connection across TCP/IP has four unique identifiers: the server host's IP address; the server host's port number; the client host's IP address; the client host's port number (usually chosen randomly). So even if two client hosts choose the same local random port number (e.g. 44444) to connect to a BACNET (port 47808) server at IP address 1.2.3.4, those clent IP addresses will be different, so the quartet of identifiers for each connection will be different, which will be enough for the BACNET server (1.2.3.4:47808) to keep those two clients' connections separate.
Having different ports for BACNET/TCP and MODBUS/TCP makes the quartets even more different, and if BACNET/TCP is on one server and MODBUS/TCP is on another server, then that make the quartets yet even more different, which answers the OP question.
As an example, I am accessing this PLCtalk forum web server (IP address 208.67.16.116) via the HTTPS protocol (port 443). Others may be accessing that web server at the same IP address using the HTTP protocol (port 80). I do not see their traffic and they do not see mine. Also, my web browser client does not confuse the PLCtalk traffic with traffic to and from its connections to other web servers e.g. to mail.google.com. All because each connection has unique quartets of identifiers.
The situation is similar to any protocol used over an RS-485 multi-drop network: when the controller of the network sends a request, that request typically contains the address of one target device on the network. All of the devices see the request and parse it, but only that one target device with that address will respond. The one exception would be requests sent to a designated broadcast address, for which there is usually no response (otherwise all devices would respond an interfere with each other).
Finally, there is the concept of "well-know ports," such as BACNET/TCP at port 47808 and MODBUS/TCP at port 502. That is nothing more than an convention, or agreement, that when a client host connects to a server host on port 47808, the server host assumes that the protocol will be BACNET. There are many well-known ports: 21 for FTP; 22 for SSH; 23 for telnet; etc. There is nothing magical about them, and different port numbers can be re-assigned and used if all hosts are aware of the modified convention. For example, I set up a special-purpose web API on port 886 for a recent project, however during startup some of our users could not get to it because they were on a guest network that, for security reasons, blocked most ports. However, 3389 (Remote Desktop Protocol- RDP) was not blocked, so I simply had my web API server also "listening" at 3389, and those users on that guest network pointed their browser at
https://drbitboy.server:3389/ instead of
https://drbitboy.server:886/. Note that if they had pointed their RDP application at my server it would not have worked because the drbitboy.server was not running an RDP server. My point is that a client-server application is nothing more than a convention of how things should work: the host IP address of the server; what port on that host the server listens to. Just as we would not connect a BACNET device on an RS-485 multi-drop network where the controller was using MODBUS and expect it to work, a TCP client and a TCP server have to agree on the connection protocols.
Cf.
here.