v6ops Working Group H. Wang Internet-Draft Y. Bai Intended status: Standards Track X. Xie Expires: 4 April 2025 CQUPT 1 October 2024 Protocol Translation Between Industrial Field Network and Backbone Network Based on IPv6 draft-wang-v6ops-industrial-translation-00 Abstract This document describes a protocol conversion framework that can achieve interconnection between various industrial field networks and backbone network based on IPv6. The described scheme can ensure the quality of service and industrial traffic characteristics for cross- network data flows. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires 4 April 2025 [Page 1] Internet-Draft Industrial Translation October 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Conversion Framework . . . . . . . . . . . . . . . . 4 4. Protocol Conversion Mechanism . . . . . . . . . . . . . . . . 5 4.1. Address Conversion . . . . . . . . . . . . . . . . . . . 6 4.2. Frame Format Conversion . . . . . . . . . . . . . . . . . 7 4.3. Multi-Protocol Identification . . . . . . . . . . . . . . 7 4.4. Identification of Cross-Network Data Flows . . . . . . . 8 4.5. Service Type and Priority Mapping . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The integration of advanced network technology and traditional industrial production systems have promoted the continuous development of the Industrial Internet. As the development of the Industrial Internet, Internet Protocol Version 6 (IPv6), as a new generation of network protocol, has been continuously expanding its application, to meet the demand for device access, secure and efficient communication networks. The Industrial backbone network based on IPv6 serves as an important hub connecting industrial production sites with the Internet. It is widely deployed in the Industrial Internet to provide efficient and stable data transmission for complex industrial applications. Industrial field networks are typically used for information collection and decision-making control in the production process, generally including fieldbus, industrial Ethernet and industrial wireless network. Due to the complexity of the industrial production process, a single network cannot meet all production requirements. Therefore, the industrial field network is generally composed of multiple heterogeneous networks. Wang, et al. Expires 4 April 2025 [Page 2] Internet-Draft Industrial Translation October 2024 To address the requirements of complex industrial production, it is essential to use a backbone network for unified management and control of the industrial field network. However, it is difficult for industrial field networks to communicate directly with the Industrial backbone network based on IPv6 , due to protocol inconsistencies. In view of this, in order to achieve unified management and control of the industrial field network, the interconnection between the industrial field network and the backbone network based on IPv6 is crucial. However, there is currently no standardized protocol conversion mechanism to guide data transmission between different industrial field networks and the backbone network based on IPv6. Furthermore, existing protocol conversion methods are inadequate in preserving the industrial characteristics of the original data flow, such as protocol identification, frame format conversion, service type, and priority mapping. Therefore, this document describes a protocol conversion framework designed to facilitate protocol transmission between industrial field networks and the backbone network based on IPv6, while preserving the original industrial protocol characteristics. Specifically, we introduce a framework that supports conversion between multiple industrial field network protocols and the IPv6 backbone protocol, ensuring quality of service by mapping the characteristics of industrial data flows to the corresponding fields in the IPv6 header. 2. Terminology Industrial field network: An industrial field network refers to a communication network used in industrial environments to connect and control various devices, sensors, and actuators. Industrial backbone network based on IPv6: The Industrial backbone network is based on the IPv6 protocol, designed to connect different industrial field networks over a broader scope. Industrial heterogeneous network: An industrial heterogeneous network refers to a collection of multiple network types within an industrial environment, constructed using different communication protocols and technical standards. Software-Defined Networking: Software-Defined Networking (SDN) is a network architecture that separates the control plane from the data plane, enabling greater flexibility and programmability in network management. Wang, et al. Expires 4 April 2025 [Page 3] Internet-Draft Industrial Translation October 2024 OpenFlow: OpenFlow is a communication protocol that serves as a fundamental technology in the implementation of SDN. The OpenFlow protocol enables direct communication between the controller and network devices, thereby achieving flexible network control and automation. 3. Protocol Conversion Framework Aiming at the Industrial Internet, this document describes a protocol converter to support data transmission between the backbone network based on IPv6 and various field networks. As illustrated in Figure 1, the designed network architecture comprises a Software Defined Network (SDN) [RFC7426] controller, the backbone network based on IPv6, the protocol converter, and the industrial field networks. Specifically, the SDN controller manages network devices and resources in a centralized manner, the backbone network based on IPv6 handles IPv6 data forwarding, and the industrial field network is used for device control and data exchange. The protocol converter plays a crucial role in enabling interaction between the industrial field networks and the backbone network based on IPv6. +---------------------+ +----------------------+ | | | | | Industrial Cloud | | SDN Controller | | | | | +----------+----------+ +-----------+----------+ | | +----------+----------------------------+---------+ | | | IPv6 backbone | | | +-----+---------------+----------------------+----+ | | | +-----|-----+ +-----|-----+ +-----+-----+ | Protocol | | Protocol | | Protocol | | Converter | | Converter | | Converter | +-----+-----+ +-----+-----+ +-----+-----+ | | ... | +-----+-----+ +-----+-----+ +-----+-----+ |Industrial | |Industrial | |Industrial | | field | | field | | field | | network 1 | | network 2 | | network n | +-----------+ +-----------+ +-----------+ Figure 1. Structure of the heterogeneous industrial network In the industrial heterogeneous network based on SDN, there is no management method that can effectively control the protocol converter, which inspires us to design a protocol conversion Wang, et al. Expires 4 April 2025 [Page 4] Internet-Draft Industrial Translation October 2024 management scheme. The OpenFlow protocol is one of the commonly used protocols for southbound interfaces. Specifically, we design a southbound interface based on SDN controller to manage the protocol converter. The northbound interface is a communication interface that connects the network administrator, manager, and field devices. Through the northbound interface, the administrator can issue commands to configure and manage the network, and can also obtain data information and communication resources of the underlying network. The southbound interface is mainly responsible for communicating with the physical devices of the underlying network to realize the configuration and management of field devices. For the southbound interface, a southbound management frame is designed to control the protocol converter, and its parameters include start bit, transmission direction, frame type, length, payload, and function. We use the start bit of the frame to represent the management range, and set its size to 2 bytes. The first 8 bytes are the OpenFlow protocol header. The 9-th to 10-th bytes serve as the start flag, indicating the management range. Then, the transmission direction occupies the 11-th byte. When the value is 0x00, the transmission direction is from the protocol converter to the SDN controller. When the value is 0x01, the transmission direction is from the SDN controller to the protocol converter. The 12-th byte represents the interface type, and when the interface type is 0x00, it means the management interface. The 13-th byte is defined as management function, which indicates the specific management type, including registration function, reporting function, etc. The 14-th to 15-th byte is the payload length. Finally, the payload field, starting from the 16-th byte, is designed to have an indefinite length. The northbound interface mainly opens the functions of the SDN controller to the upper users. 4. Protocol Conversion Mechanism Considering the heterogeneity of industrial networks, we describe a protocol conversion framework for various industrial field networks and backbone network based on IPv6, which mainly includes address conversion, frame format conversion, multiprotocol identification, identification of cross-network data flow, service type and priority mapping. Wang, et al. Expires 4 April 2025 [Page 5] Internet-Draft Industrial Translation October 2024 4.1. Address Conversion The purpose of address conversion is to map or convert the local address of the device in the industrial field network with the IPv6 address so that each device can map a unique IPv6 address in the whole network, so as to implement the cross-network unified addressing based on IPv6. For networks that already support IPv6 addressing, such as 6TiSCH and ISA100.11a, address conversion is not required. For most networks that do not support IPv6 addressing, address conversion needs to be completed. Considering the different addressing modes of industrial networks, address conversion can be divided into the conversion between Non-IP address and IPv6 address, and the conversion between Internet Protocol Version 4 (IPv4) address and IPv6 address. The typical networks of the first type contain Modbus RTU, WIA-PA, etc. For this type, its network address is generally lower than 128 bits of IPv6 address. Therefore, a certain mapping rule can be adopted to map the short address to the IPv6 address at the protocol converter, so as to ensure that each network device has an addressable IPv6 address. Note that, for some Industrial Ethernet that use MAC address for addressing, such as Profinet network running in RT mode, MAC address can be directly converted to IPv6 address in the manner specified in [RFC2464]. The second type is common in Industrial Ethernet, where devices already have IPv4 addresses but do not yet support IPv6 addressing. For this type, the standard specification of IPv4 and IPv6 address conversion formulated by IETF can be adopted, such as the conversion method relying on Domain Name System 6-to-4 (DNS64) [RFC6147] and Network Address Translation 6-to-4 (NAT64) [RFC6144] conversion, and the approach that embeds IPv4 address into IPv6 address to realize conversion. In addition, considering that Industrial Ethernet is usually designed with connection ID for data flow, an address mapping method based on connection ID was used. The idea of this method is to use the connection ID to achieve the conversion of IPv4 unicast address and IPv6 unicast address, as well as IPv4 multicast address and IPv6 multicast Address according to the message type. Taking Ethernet/IP as an example, its messages carry the unique connection ID of the whole network, which can be used as a key to form a key value pair with the converted IPv6 address. The key-value pair is stored in the table, and the IPv6 address is directly looked up from the table during the next conversion. When the memory resources are sufficient, this method can effectively save the computing resources of protocol conversion, reduce the running time, and improve the conversion speed. Wang, et al. Expires 4 April 2025 [Page 6] Internet-Draft Industrial Translation October 2024 4.2. Frame Format Conversion The purpose of frame format conversion is to convert industrial field network messages into IPv6 packets. Since IPv6 protocol only involves the network layer, and most industrial network protocols include all protocol layers of the protocol architecture, when transforming the message format, UDP, TCP, and application layer protocol formats need to be considered in the backbone network. For industrial networks that have used TCP or UDP transmission, such as Ethernet/IP, it can be transformed into IPv6 header + TCP/UDP + application layer according to the TCP or UDP mode used by the field network, and the format and content of the application layer remain unchanged. For industrial networks that do not use IP technology or use IP technology but do not use TCP/UDP protocol, the application layer is wrapped in the TCP or UDP header respectively in accordance with the characteristics of industrial data to complete the conversion of frame format. UDP mode is preferred for data with high real-time requirements; TCP mode is preferred for data requiring high reliability. According to the tradeoff between real-time and reliability, the transport layer protocol is selected. Note that although the field network application layer can be directly copied to the application layer of backbone network messages in most cases, some application dependent messages need to be handled carefully. These special application protocols embedded IPv4 addresses into their protocol payload. For instance, to complete the configuration between Profinet I/O device and controller device, the DCP-Set message carries IPv4 configuration parameters, including the device address, subnet address, and gateway address. In this case, the protocol conversion device needs to convert the IPv4 address in the application layer payload into IPv6 address according to the above address conversion method, so as to realize correct and complete frame format conversion. 4.3. Multi-Protocol Identification To enable the IPv6 backbone to automatically identify the data flow from the industrial field network when transmitting the converted message, so as to provide a basis for some targeted processing. The described conversion framework identifies the industrial field protocol before conversion with the help of the high 6 bits of IPv6 header flow label. During protocol conversion, the upper 6 bits of the converted IPv6 header flow label (20 bits in total) identify the type of industrial field network protocol, and the 6 binary bits are converted to the hexadecimal and represent 64 industrial field network protocol types, of which the decimal number 1-14 represents Wang, et al. Expires 4 April 2025 [Page 7] Internet-Draft Industrial Translation October 2024 the industrial field network protocol type (i.e., Type1-Type20) in IEC 61158 standard. The remaining industrial field network types are represented by the remaining decimal numbers. 4.4. Identification of Cross-Network Data Flows Accurate identification of each data flow in the network is the key basis for network real-time scheduling and ensuring QoS. Protocol conversion framework is defined as QoS-aware conversion owing to the described framework can maintain key characteristics in the original data after conversion, so that data QoS can still be guaranteed after conversion. Based on the protocol conversion framework described in this document, these characteristics can be mapped to IPv6 frames as needed. The receiver is able to parse the original feature information based on the mapping used. Most industrial field networks design flow identification mechanisms. When transmitting data from the field network to the backbone network and performing protocol conversion, continuing to maintain the effective identification of data flow in the backbone network based on IPv6 is very important for performing end-to-end real-time scheduling across the network. We can identify the data flow in the backbone network with the help of the lower 14 bits in the IPv6 header flow label. By constructing the mapping relationship between the industrial field network data flow identifier and the lower 14 bits of IPv6 header flow label, the cross-network identification of data flow can be completed. When a data flow is transmitted from field network A to the field network B via the backbone network based on IPv6, the SDN controller can fully determine the data flow through the triplet of (data flow identifier of industrial field network A, IPv6 flow identifier, data flow identifier of industrial field network B) and maintain the triplet mapping relationship table. Taking Profinet and Ethernet/IP protocols as examples, we present the protocol type mapping and cross-network data flow identification mapping. The Ethernet type field of Profinet real-time message can describe the protocol type, and its frame ID field is responsible for addressing the communication channel between two Profinet devices, and writing them into the upper 6 bits and lower 14 bits of the flow label respectively by mapping. The Ethernet/IP message identifies the protocol through the destination port number of the transport layer, maps the protocol type to the upper 6 bits, and maps the ID used to identify a connection in the application layer to the lower 14 bits of the flow label field. The mapping based on protocol type and identity can promote the rapid identification and flexible scheduling of cross-network data flow, and ensure the efficient communication of industrial networks. On this basis, it can carry out complex operations such as deterministic scheduling, load balancing, transmission path optimization, etc. Wang, et al. Expires 4 April 2025 [Page 8] Internet-Draft Industrial Translation October 2024 4.5. Service Type and Priority Mapping In the industrial field network, there are messages of different service types such as management and control; In addition, different messages have different priorities. Priority usually includes application layer priority, link layer priority, and other different types. After protocol conversion, the service type and priority information of the message can still be maintained, which is critical for ensuring the real-time transmission of high priority data flow and the QoS of industrial network. Note that IPv6 header has an 8-bit traffic class field. We use this type domain to establish a one-to-one mapping relationship between the service type and priority combination and the type domain value for different industrial networks, and transfer the information to the IPv6 header type domain, so as to effectively maintain the packet service quality from the industrial field network to the backbone network based on IPv6 before and after protocol conversion. The above conversion method fully considers the key parts of protocol conversion, which can not only complete the conversion between industrial field network protocol and IPv6 protocol, but also ensure the QoS and industrial characteristics before and after conversion, and effectively interconnect heterogeneous industrial field networks with IPv6 industrial backbone network. The address conversion, frame format conversion, multi-protocol identification, identification of cross-network data flow, service type and priority mapping in the described framework can be regarded as a reference for broader heterogeneous protocol conversion. 5. Security Considerations This document does not add any new security considerations. 6. IANA Considerations This document has no request to IANA. 7. References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, . Wang, et al. Expires 4 April 2025 [Page 9] Internet-Draft Industrial Translation October 2024 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . Authors' Addresses Heng Wang CQUPT Chongqing University of Posts and Telecommunications No.2 Chongwen Road, Chongqing 400065 China Email: wangheng@cqupt.edu.cn Yixuan Bai CQUPT Chongqing University of Posts and Telecommunications No.2 Chongwen Road, Chongqing 400065 China Email: d240101001@stu.cqupt.edu.cn Xin Xie CQUPT Chongqing University of Posts and Telecommunications No.2 Chongwen Road, Chongqing 400065 China Email: xiexin@cqupt.edu.cn Wang, et al. Expires 4 April 2025 [Page 10]