Capability of IPv6 for control network and the activities toward its application

MIYATA Hiroshi¹ ENDO Masahito¹

The digital Fieldbus has expanded the potential of instrumentation. The shift from bus to network communication will maximize the advantages of digital instrumentation. We have been working on the utilization of IPv6 (Internet Protocol version 6), the latest version of the widespread Internet Protocol, for instrumentation. This paper introduces how we are applying IPv6 to instrumentation.

INTRODUCTION

The emergence of the Fieldbus has brought significant changes to instrumentation. These include the change of sending and receiving data format from normalized format to engineering unit format with digitalization, more efficient wiring by using a bus, and multi-vendor systems using a standardized interface.

On the other hand, in the field of information technology (IT), Internet Protocol version 4 (IPv4)¹ has become the norm and IPv4-based Internet now connects the world as a social infrastructure. Various systems including backbone systems are being built on IPv4. This trend is being driven by the advantages of IPv4 such as seamless communication using the same protocol, efficient development using common technologies, and lower cost using common components. The IP technology itself is now shifting the version from IPv4 to the next IPv6.²

It had long been considered difficult to apply IP to instrumentation, because instrumentation requires high reliability and real-time processing. However, the digitalization achieved by the Fieldbus would offer even greater advantages of scalability and flexibility, etc., if it evolves into a network architecture like IP.

We have assessed IPv6 and then extracted issues required to apply it to instrumentation. Then, we have explored and evaluated the solutions for those issues. In this paper, we will introduce our activities relating to those.

STRATEGY FOR IPv6

Yokogawa has long known that IPv6 is a suitable protocol for the control field and has been conducting various IPv6- related R&D.

We have researched and developed testing techniques for IPv6 in the TAHI Project³, which started in 1998. Specific activities include developing specifications for testing specification conformity, developing testing tools for them, and developing scenarios for testing interoperability. The results of these activities were used in the IPv6 Ready Logo Program⁵, which is hosted by the IPv6 Forum⁴ and is the only authenticating activity related to IPv6 in the world. We have played a leading role in this program, and received an award for our contribution from the IPv6 Forum in April 2008.

In 2001, we developed and released the TTB Series⁶, which is the world's first system to translate between IPv4 and IPv6.

Through the experiences described above, we have obtained a better understanding of the detailed behavior of IPv6 and related technologies, differences between IPv6 and IPv4, and other issues, and have used this understanding for subsequent research described in this paper.

IPv6 ADVANTAGES

Since the Internet Engineering Task Force (IETF)⁷ deemed that IPv4 was unsuitable for the spread of IP due to insufficient expandability and address space, it drew up the IPv6 specification. The IPv6 protocol incorporates functions that compensate for the weaknesses of IPv4. Its primary advantages are as follows.

Address Space

An IPv4 address is composed of four 8-bit addresses and is expressed in the form "192.168.10.200" in decimal notation. It has a 32-bit address space and can cover about 4.3 billion addresses. As of May 1, 2008, with the world population exceeding 6.6 billion, it is obvious that IPv4 cannot cope with the global spread of IP.

By contrast, an IPv6 address consists of eight 16-bit addresses and is expressed in the form "fedc:ba98:7654:3210: fedc:baff:fe98:3210" in hexadecimal notation. It has a 128-bit address space, and can express about 4.3 billion to the power of four addresses. This address space would be large enough to connect every device on the planet.

Since this large address space obviates the need for the Network Address Translation (NAT) devices⁸ used in IPv4, IPv6 will allow the construction of a stable network that has fewer potential Single Point of Failure components (SPOF, a generic phrase for a component of a system whose failure may cause the entire system to fail), providing end-to-end two-way communication.

Auto-configuration of IP layer

In IPv4, the Dynamic Host Configuration Protocol (DHCP)⁹ is widely used, which configures IPv4 addresses and default gateways (relaying devices between networks) automatically. IPv6 incorporates auto-configuration as a basic function and so can configure automatically without DHCP. Specifically, a stateless address auto-configuration function and router searching function automate those configurations.

Expandability

The fundamental packet format of IPv6 is more simply designed than IPv4 and contains only the minimum information required. Additional information can be added to a packet by applying extension headers. There are six types of extension header: Hop-By-Hop Options header, Destination Option header, Routing header, Fragment header, Authentication header and Encapsulation Security Payload (ESP) header. By applying these headers, new functions can be added easily in the process of sending, receiving and delivering packets.

Security function

In response to the increasing demand for network security, application of Security Architecture for Internet Protocol (IPsec)¹⁰ was considered at the outset when designing IPv6. IPsec is a protocol which provides functions to encrypt and authenticate each IP packet. Since IPsec handles such functions on the IP layer, it can be commonly used without special processing in applications.

ISSUES WHEN APPLYING IPV6 TO CONTROL FIELDS

There are major differences between the requirements for networks in the IT field and those in the instrumentation field. Therefore, when using network technology that was developed for the IT field in the instrumentation field, some issues need to be solved related to real-time processing, reliability and security.

We have developed a prototype High Speed Ethernet (HSE) of FOUNDATION Fieldbus¹¹ (FF) as an implementation of IP instrumentation which runs on IPv6, identified the issues, and investigated solutions.

Issues on real-time processing

Network topology	Average delay [μs]	Standard deviation [μs]	Minimum delay [μs]	Maximum delay [μs]
Cross cable [5 m]	112	1	110	121
Cross cable [100 m]	112	1	110	121
1 switch	127	2	123	137
2 switches	142	3	135	193
2 switches and 1 router	271	52	212	403

Table 1 Transmission delay on end-to-end communication

We measured the end-to-end transmission delay within the application level to confirm the real-time communication performance of IP. The measurement results are shown in Table 1. We used a Linux-based PC (Intel Celeron 3.06 GHz CPU, 512 Mbytes of memory) for a device, APRESIA3248G of Hitachi Cable for a switch and SEIL/PLUS of IIJ for a router. As the network communication medium, we used 100Base- TX (100 Mbps Fast Ethernet) which is currently the most widespread. The packet measured was 69 bytes long and was sent every 250 ms, and Quality of Service (QoS) technologies such as priority control and bandwidth control were not used.

The measurement results show that the maximum total processing time within two devices, one of which sends packets and the other receives them, is 121 μs and its jitter (variation in the time) is 11 μs. The results also show that the maximum transmission delay caused by two switches and one router is 293 (= 403 - 110) μs and jitter is 191 μs.

We performed an equivalent trial calculation for between embedded devices (ARM7 CPU, with our original embedded OS). Although the details are not shown here, the calculation showed that the transmission delay is 4 ms or less and its jitter is a similar order of magnitude, though the CPU processing time increases due to the limited CPU power in the embedded device.

On the other hand, the communication rate of FF H1 used for communication between field devices is 31.25 kbps, and it takes about 10 ms to transmit a message equivalent to a 69- byte packet. In the case of FF H1, jitter of 8 ms is generally tolerable.

From those results, it is concluded that IPv6 running on Ethernet can provide real-time communication performance far exceeding that of FF H1.

However, if the amount of traffic approaches the limit of the network medium, the jitter of transmission delay increases, and packets themselves may sometimes be lost. Consequently, a technology which can provide real-time communication in such circumstances is required. As it is difficult to supply electric power to field devices through Ether net and to use Ethernet in hazardous areas for explosion protection, technologies to solve these problems are required. These issues are described in detail in "Application of IPv6 to Field Instruments level network and Virtual Wiring Technology" in this Yokogawa Technical Report.

For packets requiring real-time processing, all other packets act as disturbances. Therefore, for an instrumentation network, bandwidth itself should be secured. Although such systems are widely used in IT (called quarantine systems), they are not suitable for field devices with no user interface, because users are usually authenticated th rough a user interface. Technologies to secure the bandwidth need to be incorporated also.

Issues on reliability

When using Ethernet, which is the most common network medium, as an example of an instrumentation network, it is necessary to investigate the following to increase network reliability:

1. making network paths redundant,
2. making network devices duplex,
3. making cables connecting devices duplex, etc.

In IT, technologies such as OSPFv3 (Open Shortest Path First version 3)¹², VRRP (Virtual Router Redundancy Protocol)¹³ and Link Aggregation¹⁴ may be used. However, because most of those technologies for duplication and redundancy require periodic monitoring to detect malfunctions, it takes a certain amount of time between the occurrence of a malfunction and the completion of a changeover. For example, both OSPFv3 and VRRP require at least 1 second. Since multiple data for real-time control flow on the network at the same time, disconnecting the network would greatly disturb the control; such time for changeover is unacceptable.

Issues on security function

Since IPsec provided by IPv6 can be used regardless of the application, IPsec is advantageous for providing confidentiality and integrity. To maintain secure communication with IPsec, periodic updating of keys used for calculation of encryption and authenticating values is necessary, and a key exchange protocol to exchange these keys automatically is required. Regarding communication for control, multicasting is often used to minimize the communication load, thus a security function to support multicasting is desired.

Encryption, authentication, key exchange protocol, and authentication of devices as mentioned above require sophisticated calculations. For field devices etc. with limited CPU power, it is difficult for the CPU to do these calculations which occur asynchronously. Therefore, these calculations should be handled by the hardware.

SOLVING THE ISSUES

As mentioned earlier, IPv6 has the capability to satisfy the requirements for control networks, and the issues to be solved have been identified. We are working on the following to solve the issues.

Bandwidth control by QoS for securing real-time processing

Disturbance traffic	Bandwidth control	Average delay [μs]	Standard deviation [μs]	Minimum delay [μs]	Maximum delay [μs]
90 Mbps	No	144	4	137	164
	Yes	144	3	136	163
100 Mbps	No	965	67	843	1089
	Yes	146	9	136	185

Table 2 Effects of bandwidth control

QoS technology can be used to secure real-time processing without being affected by an increase in traffic. Standardized technologies in which an intermediate device secures bandwidth are already implemented in routers or switches. To allow various network mediums to be used, technologies which can be applied on the I P layer are desirable. The QoS technology that can be used on the IP layer and that places the least load on devices is called Diffserv (Differentiated Services)¹⁵, and it does not require a device itself to reserve bandwidth. This technology runs within a router to evaluate the Diffserv Code Point (DSCP) value in IPv6 headers, and performs QoS processing. However, it is desirable to use DSCP values for control for communication between devices in the same network within the range of a router as well. The effects of bandwidth control are shown in Table 2.

The total processing time within two devices in the same network was measured, where packets could go through two switches that were configured to control communications by DSCP value. As in the case of Table 1, we used 100Base-TX, and the packet length was 69 bytes and transmission cycle was 250 ms. The disturbance was generated by periodically sending packets 1024 bytes long. As shown in the table, real- time processing was effectively secured even when the switch was allowed to evaluate IP headers.

IP instrumentation auxiliary layer complementing instability

Figure 1 IP instrumentation auxiliary function

One approach to increase adaptability is to adapt to changes in the network dynamically by detecting changes in devices. For example, a function which measures the transmission delay of packets and adjusts the transmission schedule is included.

In order to validate such functions, we built a prototype IP instrumentation auxiliary layer under the FF HSE layer and an auxiliary device for IP instrumentation which assists the functions of the auxiliary layer, and confirmed the performance. Figure 1 shows the concept of the group of functions which provide adaptability. For example, it is possible to complement unstable factors of the IP network by measuring the actual times needed for communications in the IP instrumentation auxiliary layer, and generating and adjusting the schedule in the auxiliary device automatically. Since the IP instrumentation auxiliary layer is placed under the FF HSE layer, it can perform without depending on the upper level protocol.

Redundancy by packet replications

Figure 2 Packet replicating system

One effective way to increase redundancy is duplication. However, for the reasons mentioned earlier, we are investigating a system architecture with no periodical monitoring where packets are replicated and transmitted using a ring topology as shown in Figure 2. Generally, duplex systems involve problems of more equipment and greater complexity, but with our architecture, these issues can be reduced. In the figure, the routers connected to field devices could be a SPOF, and we are separately considering the duplication of this part as well.

Miniaturizing and speeding up security function processing

Yokogawa has been developing a key exchange protocol which is suitable for embedded devices, and has also been miniaturizing and speeding up the encryption processing. A key exchange protocol for multicasting and a system to authenticate devices for control have been investigated as well. Those topics are reported in the paper in this Yokogawa Technical Report previously mentioned.

CONCLUSION

We have clarified the technical issues to be resolved for realizing IPv6 instrumentation systems. Since IPv6 and related technologies have high potential, solving these issues will enable connection to necessary devices safely and reliably at anywhere, anytime. This is one of the benefits of digitalization, and technologies for solving such issues will underpin the global value chain such as remote maintenance and collaboration between companies.

REFERENCES

1. Information Sciences Institute University of Southern California, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," IETF, RFC 791, 1981
2. S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," IETF, RFC 2460, 1998
3. TAHI Project, http://www.tahi.org/
4. IPv6 Forum, http://www.ipv6forum.com/
5. IPv6 Ready Logo Program, http://www.ipv6ready.org/
6. Hiroshi Miyata, Jirou Sajiki, "IPv6/IPv4 Translator TTB," Yokogawa Technical Report, Vol. 45, No. 4, 2001, pp. 213-216 in Japanese
7. IETF (The Internet Engineering Task Force), http://www.ietf.org/
8. K. Egevang, P. Francis, "The IP Network Address Translator (NAT)," IETF RFC 1631, 1994
9. R. Droms, "Dynamic Host Configuration Protocol," IETF RFC 2131, 1997
10. S. Kent, K. Seo, "Security Architecture for the Internet Protocol," ( 1 0 ) IETF RFC 4301, 2005
11. Fieldbus FOUNDATION, "FF-581-1.3, FOUNDATION Specification: System Architecture," Fieldbus FOUNDATION, 2003
12. R. Coltun, D. Ferugson, J. Moy, "OSPF for IPv6," IETF RFC 2740, 1999
13. R. Hinden, ed, "Virtual Router Redundancy Protocol (VRRP)," IETF RFC 3768, 2004
14. IEEE, "IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges," IEEE Std 802.1 ad, 2006
15. S. Blake, D. Black, et al., "An Architecture for Differentiated Services," IETF RFC 2475, 1998.

• "FOUNDATION Fieldbus" is the registered trademark of Fieldbus FOUNDATION