Protocol Translation Between Industrial Field Network and Backbone Network Based on IPv6
draft-wang-v6ops-industrial-translation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Heng Wang , Yixuan Bai , Xin Xie | ||
| Last updated | 2024-10-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-v6ops-industrial-translation-00
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,
<https://www.rfc-editor.org/info/rfc2464>.
[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,
<https://www.rfc-editor.org/info/rfc6147>.
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, <https://www.rfc-editor.org/info/rfc6144>.
[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, <https://www.rfc-editor.org/info/rfc7426>.
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]