wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

15-8 Industrial Communication Systems
DMZ protects the industrial network and by this, the VAN subdomain against unauthorized access from
the outside (and related to the VAN-AP also from inside) according to the company’s security policy. Via the
VAN-AP, all incoming and outgoing VAN messages will be forwarded. A subdomain can also have several
VAN-APs.
Standard IT-routing mechanism alone will not work for the interconnection of different industrial
domains because a device of an industrial domain will not be visible outside its local domain, neither
by its DNS name nor its IP address. Furthermore, it is to be expected that in most cases, the industrial
domains are administrated independently, e.g., overlapping IP address spaces may exist or addresses
may change over time. To enable communication between devices of those industrial domains, a namebased
addressing and routing concept was developed—the VAN name-based routing. Here, the routing
decision is not based on network addresses, but on names. A VAN name is a complete fully qualified
domain name (FQDN) containing the structure of the devices location within a VAN domain. VAN
routing is a proactive next-hop routing mechanism allowing the forwarding of Web services without
knowing the entire path also in between different industrial domains and via public networks.
Each VAN end-to-end connection is preconfigured in both involved VAN devices by VAN engineering.
So, it is configured who is the initiator and who is the end point of that connection. The initiator at
first sends a tunnel setup Web service request to its end point. Since this request is targeted to a device
outside its own subdomain, the requester/initiator sends this message to its VAN-AP. The latter knows
via which next VAN-AP the subdomain of the targeted device can be reached (either directly or indirectly)
and hands over the request respectively. If the request hits its destination, the message will be
processed and a response will be issued.
In case of a positive response, the establishment of the tunnel connection starts. This means between
all affected VAN devices on the path (the path is determined by the VAN routing), tunnel segments,
which belong to that connection, will be built up.
For example, in an easy case as depicted in Figures 15.6 and 15.7, the requestor builds a tunnel to
its VAN-AP. The latter builds up a tunnel to the VAN-AP of the subdomain of the target device, and a
further tunnel segment will be built-up between the VAN-AP of the target device and the target device
itself. All the single tunnel ends in the VAN-APs will be connected via bridges. By this, a cascaded
tunnel will be established. A further option is to build a further tunnel through this cascaded tunnel
directly between the end devices (the initiator and the end point).
From this, it can be derived that the data for the tunnel segments of a dedicated connection will be
brought to the infrastructure components (the VAN-APs) during the establishment process because the
path is determined dynamically. If the establishment of a runtime tunnel is done by the Web service
communication using name-based addressing and routing, both devices are interconnected via a tunnel,
which can be seen as a virtual wire. A standardized connection establishment and communication
of the fieldbus system can follow. Both devices “see” each other as if they were in one local net allowing a
standard IP and MAC addressing-based communication for the runtime data exchange. Only the temporal
behavior of a connection is what distinguishes it from a local connection. The VAN functionality
hides the complexity of the heterogeneous network for the application.
VAN subdomain 1 VAN subdomain 2
VAN-AP
VAN-AP
Initiator
WAN
VANdevice
VANdevice
End point
FIGURE 15.7
Establishment of cascaded tunnels.
© 2011 by Taylor and Francis Group, LLC