For example the tunnelling protocol should not rely on the existence of a socket interface or how that interface may be used; — ensure that CNP packet ordering is preserved; — ensure tha
Terms and definitions
For the purposes of this document, the following terms and definitions apply
3.1.1 tunnelling encapsulation of one protocol’s packet within the payload of another protocol’s packets
3.1.2 channel common communications transport mechanism that a specific collection of CNP devices share and communicate over without the use of a router
Note 1 to entry: Channels are used to transport CNP packets below the link layer of the CNP protocol stack
Typically, this refers to physical media like power lines, RF, or twisted pairs; however, in the context of IP networks, the channel is not physical but rather a protocol tunnel.
CNP device device that uses the CNP protocol to communicate with other CNP devices
Note 1 to entry: Specifically, a CNP/IP device is a CNP device that communicates with other CNP devices over an IP channel
CNP router special type of CNP device that routes CNP protocol packets between two or more channels
Note 1 to entry: Specifically, a CNP/IP router is a CNP router in which at least one of the channels it routes packets over is an IP channel
CNP node special type of CNP device that can send or receive CNP protocol packets, but does not route them between channels
Note 1 to entry: Specifically a CNP/IP node is a CNP node in which at least one of the channels it sends and receives packets over is an IP channel
Note 2 to entry: All CNP devices are either routers, nodes or both
CNP group collection of CNP devices that share a common multicast address
3.1.7 node ID logical network address that differentiates nodes within the same subnet or domain
Must Be Zero (MBZ) reserved field that may be used in the following versions of the protocol
Note 1 to entry: Such fields will be sent as zero and ignored by the receiver in implementations conforming to the current version of the specification.
Abbreviations
SA/DA Source Address / Destination Address
SNTP Simple Network Time Protocol
The following is a set of general requirements for the transporting of CNP packets over IP channels:
— be as efficient as possible to allow quasi real-time operation;
The tunneling protocol must operate independently of the application-level interface utilized for packet reception, ensuring it does not depend on the presence of a socket interface or its specific usage.
— ensure that CNP packet ordering is preserved;
— ensure that CNP packets that are “stale” (outside the maximum timeout characteristics of the IP channel) are not forwarded;
— detect packets that get duplicated in the IP network;
— support IP routing devices that prioritise IP packets;
— optional security measures to prevent malicious users from tampering with devices;
— allow status information to be extracted from CNP/IP devices;
— support the exchange of configuration information between CNP/IP devices and configuration servers
IP Related device specifications
A CNP/IP device shall behave like any standard IP host capable of exchanging IP packets with any other
CNP/IP devices can operate on the same IP subnet or across the Internet, each having a unique unicast IP address and the potential to join up to 32 multicast groups, although multicast support is optional This document does not cover the routing of IP packets between subnets or through the Internet CNP/IP devices must be compatible with standard mechanisms such as IP routers and switches necessary for IP routing functions.
CNP related device specifications
Packet formats
CNP packets, which are tunneled over the IP channel, originate from or are directed to the Link layer (layer 2) of the CNP protocol stack For detailed specifications of the packet formats related to the CNP protocol, please refer to Annex A.
Addressing schemes
Different CNP protocols utilize various addressing schemes for packet exchange, and while understanding the specifics of a CNP packet or its addresses is not essential for tunneling over IP, certain elements of the CNP addressing scheme influence configuration processes This is particularly relevant when establishing the IP channels for tunneling Given the diversity in addressing schemes among CNP protocols, the terminology in this specification is designed to be comprehensive and applicable to all CNP protocols The specification outlines key CNP addressing terms that are essential for understanding these protocols.
A Unique ID is a globally distinctive identifier assigned to all devices within a specific protocol, ensuring that it remains constant throughout the device's lifespan.
A domain represents the highest level in a three-tier hierarchical addressing system, where Domain IDs must be unique within a specific network If two devices share the same Domain ID, they are part of the same Domain Typically, Domain IDs are logical and can be modified and configured as needed.
A subnet is a crucial component of a three-level hierarchical addressing scheme, where each subnet ID must be unique within its domain In networks utilizing subnet IDs, devices sharing the same Domain ID and Subnet ID are considered part of the same subnet In some cases, certain CNPs may not employ domains, making the subnet the highest address level for devices Subnet IDs are typically logical and can be modified and configured as needed.
In a hierarchical addressing scheme, a node represents the lowest level, and each Node ID must be unique within its specific subnet to avoid conflicts It is essential that no two devices share the same Node ID within the same subset Typically, Node IDs are logical and can be configured or changed as needed.
Groups serve as an orthogonal addressing scheme distinct from the hierarchical Domain/Subnet/Node triplet, enabling the multi-casting of messages While some CNPs may lack support for group addresses, those that do often have varying rules regarding their relationship with other addressing schemes However, these factors are not pertinent to this specification.
The definitions provided serve as a general guideline for mapping the CNP protocol to specific terms The intricacies of how different addressing schemes function within the CNP protocol are not pertinent to this specification; it is sufficient to understand the meanings of the various addressing terms.
The addresses utilized in the CNP protocol play a crucial role in routing, and a corresponding table in the appendix outlines the mapping of these addresses to the previously defined terms.
Specification
IP channels differ significantly from traditional CNP channels, which are inherently physical busses In CNP channels, all devices automatically receive every packet transmitted, and the addition of a new device does not require prior awareness from existing devices for packet exchange A device only needs the capability to physically transmit packets on the channel to participate in communication, meaning that any device connected to the channel can exchange packets with others seamlessly.
An IP channel is a logical rather than a physical entity, supported by various physical media capable of facilitating IP communications To establish a CNP channel, it is essential to inform each device of the presence of other devices within the channel Consequently, before a device can send a packet to another on an IP channel, it must first know the specific IP address of the target device to ensure successful transmission.
A key distinction between physical and logical channels is that physical channels allow for the calculation of fixed upper bounds on packet traversal time between devices after transmission In contrast, IP networks do not always provide this capability, resulting in significantly higher variability in packet delivery times between CNP devices compared to traditional CNP channels.
The IP channel serves as an intermediary transport mechanism for CNP packets among various CNP/IP devices When a CNP packet is transmitted over an IP channel, it is encapsulated within an IP message that is sent to other CNP/IP devices Upon receiving an IP message, the CNP/IP device extracts and processes the CNP packets contained within Notably, a single IP message can include multiple CNP packets, necessitating a specific format for the IP messages to facilitate the extraction of individual CNP packets.
CNP/IP devices must support the receipt of bunched packets, ensuring that each CNP packet within a bunched IP message remains complete and does not cross IP message boundaries Additionally, intermediate IP devices are required to unbundle bunched CNP packets and re-bunch them differently before forwarding.
The IP channel is defined by a list of unicast IP addresses, with each CNP/IP device assigned a unique address There is no limit to the number of CNP/IP devices that can be included on a single IP channel.
To enable the tunneling of CNP packets on an IP channel, each CNP/IP device would need a list of unicast IP addresses for all other devices on that channel While a straightforward method would involve sending a separate unicast IP message for each CNP packet to every device, this approach is inefficient and does not scale well Therefore, techniques will be implemented to minimize IP traffic.
IP multicast groups enable the transmission of a single IP message to multiple CNP/IP devices simultaneously A comprehensive definition of a CNP/IP channel must include not only the unicast IP addresses of all devices within the channel but also the multicast groups they are associated with Each CNP/IP device can be a member of up to 32 multicast addresses.
Selective forwarding involves analyzing the contents of a CNP packet before it is sent to a specific CNP/IP device To achieve this, detailed CNP-specific information about each potential destination is required For routers, the necessary information includes the routing tables, while for nodes, it is essential to know the domain, subnet, node ID, unique ID, and the CNP groups associated with the node Consequently, this information is integral to a comprehensive IP channel definition.
The IP channel encompasses all pertinent information necessary for the effective forwarding of packets to other CNP/IP devices It represents the complete spectrum of knowledge related to the IP channel.
When implementing a forwarding scheme for CNP/IP devices, it is crucial to ensure that CNP protocol packets are consistently received by all relevant devices on the IP channel, regardless of their role as routers or nodes In cases of ambiguity regarding which devices should receive a CNP packet, the packet's fate may vary based on the device's implementation, leading to potential discarding or forwarding to all devices Additionally, a specific CNP packet must not be transmitted multiple times to the same CNP/IP device, except in cases of retry mechanisms above the link layer While duplicate IP messages may occur due to the nature of IP networks, they should never result from a CNP/IP device retransmitting the same message.
Selective forwarding can be applied to multicast groups formed based on specific criteria For instance, multicast group 'A' may include all CNP/IP devices associated with domain ID 'W' When a CNP packet is intended for domain 'W', it is sufficient to forward it solely to multicast group 'A' To effectively implement selective forwarding on multicast addresses, it is essential to understand the criteria used to form these groups.
CNP/IP devices are not required to utilize the complete IP channel definition for packet forwarding, as it can be cumbersome to manage Instead, an alternative data structure is available for this purpose.
The "send list" in each CNP/IP device can include both unicast and multicast addresses, adhering to specific conditions This list can be created and uploaded using third-party configuration tools designed for establishing multicast groups based on certain criteria It contains the essential information needed for the effective forwarding of CNP packets, streamlining the process so that the CNP/IP device only needs to send packets to the addresses listed For a CNP/IP device to forward packets to each address without additional checks, two conditions must be met: all CNP protocol packets must be received by relevant CNP/IP devices, whether they are routers or nodes, and no specific CNP packet should be sent more than once to the same device.
According to EN 14908-4:2014 (E), if device A is included in the send list of device B, then device B must also be included in the send list of device A This requirement is essential for supporting the acknowledged service of the CNP protocol.
It should be possible to perform simple forms of selective forwarding using the send list by associating characteristics with the multi-cast entries in the list
IP transport mechanisms
General
IP is a network-level protocol capable of functioning across various physical media and link layer protocols This document intentionally omits details regarding the link and physical layers of the IP stack.
As depicted in Figure 2 the three most common mechanisms used to transport IP packets are the following:
TCP and UDP are transport protocols that operate on top of IP, as defined in RFC 793 and RFC 768, respectively Due to its efficiency in transporting CNP data messages and its support for multicast addressing, UDP will be the primary communication method between CNP/IP devices, all of which must support UDP While TCP offers advantages during the configuration process and may be used for specific message types, its support in CNP/IP devices is optional.
To resolve the sequencing problem, a sequence number will be included in the packet headers to facilitate proper ordering Additionally, all UDP datagrams will be sent with valid checksums to ensure data integrity.
To send a packet using TCP or UDP, it is essential to specify a port number alongside the IP address Port numbers are typically configurable and serve various purposes For recommendations on port numbers to use for CNP, please refer to Annex B.
Datagrams can be transmitted using UDP through either unicast or multi-cast addressing Unicast is a point-to-point method, sending a datagram from one IP host to another, while multi-cast is more efficient for delivering the same datagram to multiple IP hosts It is advisable for CNP/IP devices to support both addressing types An IP channel consists of a list of IP addresses, and a channel definition can include any mix of unicast and multi-cast addresses Notably, a CNP/IP device does not need to support multi-cast to function with a device that does.
To enable multi-cast addressing across IP routers, a CNP/IP router must notify the IP router of its intent to join the multi-cast group Established methods exist for this process, but detailed specifications are not covered in this document For further information, readers are advised to refer to RFC 1112.
Informative considerations
Some IP networks utilize NAT routers, which typically struggle with protocols that embed IP addresses in their payloads unless specifically designed for such tasks Consequently, the tunneling protocol discussed in this document generally does not function across NAT routers However, it can still be employed in networks with NAT routers, provided there is a router capable of handling the protocol, either the NAT router itself or another CNP/IP to CNP/IP router located within the same network area.
Configuration of a CNP/IP device
The CNP/IP device exhibits a dual functionality, serving as a CNP node within a CNP channel, complete with all associated characteristics Its parameters are configurable and manageable through standard CNP network management procedures and messages.
The CNP/IP device functions as an IP host within an IP network, necessitating configuration similar to that of any other IP host.
In addition, there is configuration information that defines the logical IP channel associated with that CNP/IP device
This clause describes only those elements relevant to configuring the IP host and IP channel parameters
All IP host and channel parameters can be configured through various techniques and protocols At a minimum, all CNP/IP devices must allow manual configuration of their forwarding mechanisms to ensure basic interoperability among devices that may have different configurations Forwarding refers to the tunneling process to other devices on the IP channel.
Configuration parameters
General
This subclause outlines the parameters utilized by a CNP/IP for operation, without detailing the data structures for information storage or the messages exchanged Its primary aim is to provide a comprehensive section that identifies and defines all parameters of a CNP/IP device Additionally, subsections address the mechanisms for communication of this information between devices.
There are three relevant data sets that form the parameters contained within a CNP/IP device:
— CNP/IP channel definition as described in Clause 6;
— send list as described in Clause 6;
— device parameters relevant to its existence on a CNP/IP channel.
Channel definition parameters
A comprehensive channel definition includes a detailed list of all CNP/IP devices present on the channel, with each device linked to specific types of information.
— multi-cast support (yes or no) Since this is optional there shall be an indication of whether it is supported;
— TCP support (yes or no) Since this is optional there shall be an indication of whether it is supported;
— CNP/IP device type (router, node, proxy etc.);
— CNP router type (repeater, learning, configured etc.);
— CNP “Wants all Broadcasts” flag;
— name Simple text string used for identification purposes;
— channel timeout This parameter is global to the channel Each device has this value but it is the same for all devices;
— IP address This is the unicast IP address of the device
— unicast port for listening to data;
— list of multi-cast address/port number pairs a CNP/IP device listens on;
— CNP specific unique device ID 1 (router near side or node);
— CNP specific unique device ID 2 (router far side);
— CNP specific unique device ID 3 (auxiliary for configuration);
— CNP Domain length and ID, subnet, node address for each domain;
— the parameters specific to nodes are: CNP group membership info;
— the parameters specific to routers are: CNP routing table
Note that this list is representative in nature Complete details as required are left to later clauses of this European Standard
The tunnelling protocol defined in this specification does not require any specific CNP addressing scheme The following CNP address types are supported:
Refer to Annex A for the specific addressing conventions that correspond to the address types listed above.
Send List arameters
The following parameters are used to define the Send List
— list of unicast IP addresses and ports;
— list of multi-cast IP addresses and ports.
Device parameters
— configuration server IP address/port;
Configuration techniques
General
This subclause describes the various techniques that can be used to set the parameters defined in the previous subclause
CNP/IP devices can configure parameters through various methods While it is not essential for these devices to support every method, any supported method should adhere to standard practices.
Manual configuration
Manual configuration does not utilize a configuration server, requiring all necessary channel definition parameters, send list parameters, and device parameters to be entered manually There is no universal method for this process, as it is vendor-specific and can be achieved through various methods.
BOOTP and DHCP
Two mechanisms exist for devices to obtain an IP address without prior configuration: DHCP (RFC2131]) and BOOTP (RFC951 )
DHCP is actually an extension of BOOTP and BOOTP servers that are compliant with RFC951 can understand messages from DHCP clients and respond to those messages correctly
A system initiates the boot process by sending a DHCP request to obtain an IP address from a DHCP server, which then responds with a valid and unused IP address for the DHCP client to utilize.
Devices that are compliant with this specification and wish to obtain an IP address without prior configuration shall implement a DHCP client and may implement BOOTP client.
Configuration servers
For optimal functionality, devices on a CNP/IP channel should be designed for easy "plug and play" use Due to the extensive configuration information required for CNP/IP devices, a system for distributing this data is essential to avoid manual entry for each device This distribution is facilitated by a configuration server, which streamlines the setup process.
Devices utilizing a configuration server must be compatible with those that do not However, it is not required for the configuration server to accommodate all interactions outlined in this specification, particularly the support for Channel Routing packets.
A configuration server uses IP messages to configure CNP/IP clients in an automated fashion In general, a configuration server may support the following functionality:
— configuration of various client CNP/IP parameters;
The distribution of the IP channel involves defining and sending a list to client CNP/IP devices The channel list provides an overview of the entire network, while the send list is tailored to each specific CNP/IP device.
— automatic maintenance of the channel definition list by detecting when CNP/IP devices come on and go off line
In addition to the parameters described in 7.2, a CNP/IP device shall also have the IP address of a configuration server, and a port to communicate on to use a configuration server
CNP/IP devices shall send a device registration message to the configuration server on power up, on reset, and when parameters in the devices channel definition list changes
This clause does not dictate the server's method for managing the parameters it distributes to clients, allowing for flexibility in management approaches It is essential for the server to dynamically create and maintain parameters as clients connect and disconnect Therefore, the configuration protocol and message formats will be designed to enable servers to support this dynamic functionality.
Definition of CNP/IP messages and modes of operation
The purpose of this clause is the following:
— identify all messages that can be exchanged between CNP/IP devices on an IP channel;
— specify the protocol and behavioural aspects of the devices while they are exchanging these messages
Clause 9 will specifies the precise packet formats for messages defined in this clause
A CNP/IP device utilizes the IP channel for multiple functions and operational modes, with each mode addressed in a distinct clause of this European Standard.
— exchanging (tunnelling) CNP data packets;
— exchanging configuration information with configuration servers;
— vendor specific messages and protocols
For each of these modes of operations a set of messages will be defined which are exchanged between the CNP/IP devices.
Common message header
Each IP message transmitted between devices on the IP channel begins with a standardized fixed header that is consistent across all CNP/IP messages This header includes several key fields.
Specific message formats are covered in Clause 9
All packets sharing the same Version Number are expected to be parsable However, if a packet arrives with an unrecognized Version Number, it must be discarded immediately without any additional processing.
The Protocol Flags specifies information about the packet such as which CNP protocol packet is encapsulated within the message and whether the message was sent using security
The Vendor Code facilitates the use of vendor-specific packets, which are distinguished by a unique Vendor Code that is not equal to 0 For all standard definition packets as per this specification, the Vendor Code must be set to 0.
Each function is assigned a unique Packet Type code, as outlined in section 9.1, with standard codes ranging from 0x00 to 0x7F Vendor-specific packets that extend standard functions can share the same Packet Type code, but must include a unique Vendor Code Conversely, vendor-specific packets unrelated to any standard functions must utilize Packet Type codes between 0x80 and 0xFF.
The Data Packet Length and the Header Size specify the size of the packet and the size of the header respectively
The Session ID works in conjunction with the Sequence Number to minimise the occurrence of duplicated sequence numbers
The Time Stamp is essential for identifying stale data packets, relying on a synchronized time reference across all devices in the CNP/IP channel, as outlined in section 8.4.4.
The Security Key is used for securing packets as described in 8.8
CNP/IP messages can be transmitted using UDP datagrams, with each datagram capable of containing multiple CNP/IP messages In cases where multiple messages are included in a single UDP datagram, known as bunching, each message is accompanied by its own header This header contains size information, allowing for the individual extraction of each message.
All CNP/IP devices shall support packet bunching Figure 3 depicts more than one CNP/IP message within a single UDP datagram (packet bunching)
Certain CNP/IP messages can span a UDP datagram boundary, necessitating a specialized segmentation protocol to manage this When messages utilize this segmentation scheme, they do not need to be grouped with other packets.
Packet segmentation
Overview
Configuration requests for certain CNP/IP data structures often exceed the 548-byte payload limit of a single UDP packet This section outlines a common approach to convey these data structures It is important to note that this method does not inherently prevent data skew, which can occur when parts of the data structure change during the transfer of individual segments In the definitions of Configuration Response Packets within this protocol, either the response packet format is designed to mitigate sensitivity to data skew, or a straightforward method is provided to detect potential data skew.
This protocol utilizes the segment packet type, allowing other configuration packet types to be included as payloads within a series of segment packets The payload's byte sequences are chosen to ensure that the resulting segment packet fits within a UDP frame, which are then sent as responses If the requested packet can fit within a UDP frame, it is transmitted directly without encapsulation.
Segment packets are transmitted in full, with each payload packet featuring a shared header that includes the length of the payload Additionally, all segment packets maintain a consistent packet type.
To streamline this method, every Configuration Request packet that triggers a Configuration Response includes a Segment ID field Additionally, each Segment packet features a Flags field containing both a Valid bit and a Final bit, along with a datetime indicator.
— The Request ID field is copied from the Request to the segment packet by the responding server
The Request ID is a 16-bit tag value assigned by the request's source, allowing for unique identification of responses This enables multiple simultaneous requests to the same destination Additionally, the field can accommodate device information alongside the request number, depending on the specific implementation.
— The Segment ID is a reference to a partial block of data within a complete data structure The
Segment ID referencing the first partial block of data is 0x0
The Valid bit in a segment Packet signifies whether the data associated with the specified Segment ID is valid A Valid Set indicates that the data is indeed valid, while a Valid Clear denotes the absence of valid data for the given Segment ID.
— The Final bit in a segment Packet indicates the existence of additional data within the structure for
Segment ID values greater than that returned in this packet Final Set indicates there is no additional data
The datetime indicator serves to identify any skew in acquired data by marking the moment a specific data structure became valid, rather than indicating when the data was requested for transfer.
The EN 14908-4:2014 (E) standard outlines that data skew can be identified by analyzing the datetime field in response packets If discrepancies are found in the datetime field across packets, it indicates that some data has been skewed The specific format for the datetime field is detailed in section 9.5.
Segment exchange
The configuration data retrieval process begins when a requesting node sends a Request Packet with Segment ID = 0, optionally using the REQUEST_ALL flag to request all segment packets at once If the response fits within a single frame, it is sent immediately, and the receiver acts on it by retiring the Request ID For responses that exceed one frame, the responding node sends a segment packet with the corresponding Segment ID If no data exists for that segment, the response includes flags:final set and flags:valid clear; if data is present, it is sent with flags:valid set, and if more data exists, flags:final is cleared If the requesting node does not receive a response, it will repeat the request, increasing the interval exponentially up to a maximum of 30 seconds Upon receiving a response, the requesting node checks the flags; if flags:valid is clear, the rest of the packet is ignored, while if it is true, the data is processed, and the datetime field is examined for data skew The request sequence ends when flags:final is set, marking the data structure as valid; if flags:final is clear, another Request Packet is sent with an incremented Segment ID, continuing the process If any received packet's datetime differs from others, the process restarts from the beginning.
Acquiring a data structure can begin with any Segment ID value, but requesting Segment 0 typically yields valid data If a non-zero segment is requested and the response fits within a single UDP frame, the system will respond with just the response packet, bypassing the segment packet.
When the requesting node has received a stream of segment packets with a complete set of
The system assembles the payload packet using Segment IDs and a consistent datetime across all packets If any segment has a differing datetime, the entire set is discarded, and the process restarts from the initial step No segments are retained, as the response may include segments with a completely new datetime.
Segmented packets are never sent by the server in an unsolicited manner
The Request ID is sent from the device to the server within the request packet and is fully controlled by the requesting device It can take any value, including zero, and will be echoed in the segment packets sent by the server Each active request must have a unique Request ID to avoid ambiguity; otherwise, the server's behavior becomes undefined.
Discussion
This subclause describes the segmentation process in further detail The architectural implications of this design and the server and device implementation requirements are described
This segmentation scheme enables the reliable exchange of packets with arbitrary formats over a link that has a limited frame size Once a series of segments is received, their payloads are concatenated to create a byte stream, which is then interpreted as a packet This packet includes a standard header that contains a packet type code and a packet length.
Future packets can be encapsulated and segmented similarly, without the need for extra fields in the common packet header or in any existing or upcoming packet formats.
Packet segmentation is not intended to be applied to data packets
Packet segments can be requested in any order and multiple times If the server sends packets with identical datetime and Segment ID, each response will contain the same byte data.
A variety of implementations in a server can assure that the datetime field indicates that the sequence of packets for a Request ID is consistent Among these are:
— locking down the database for the duration of any unsatisfied requests and applying outstanding updates at the end of a last request;
Taking a snapshot of the data for a request is essential, and this snapshot should be retired once the final packet is sent or if a timeout occurs, indicating that the request/response sequence has not been completed.
A variety of implementations in a device can assure that a request that is not completely answered does not continue to consume resources Among these are:
— sequestering the segments as they arrive and retiring these segments and the control data when:
1) a timeout occurs indicating that the server is not answering requests (After a suitable retransmission policy);
2) a response of a suitable non-segmented packet indicates the request is satisfied (No explicit Request ID field is added to the packet header, but this condition is not ambiguous since a device only communicates with a single configuration server, so there is no need to support multiple outstanding requests of the same type with that server.);
3) a sequence of segment packets has been received with the correct Request ID and all with the same date time The payload of these segments is then decoded as a packet that is the response to this request.
Data packet exchange
General
This subclause outlines the exchange of CNP data packets over IP channels, detailing the process for forwarding CNP packets to another CNP/IP device It does not address the criteria for determining which device should receive the packets.
CNP/IP devices are responsible for forwarding CNP data packets, with the selection process based on either the IP channel definition or the send list For clarity, we will define this process further.
The "forward" list consists of IP addresses designated to receive specific CNP data packets, including both unicast and multicast addresses The method of determining this forward list is not pertinent to the current discussion.
Since CNP uses an end-to-end acknowledged service the following assumptions are made:
— there is no need to add acknowledgements to the forwarded CNP/IP data packets;
— there is no need to re-transmit dropped IP packets
On the other hand, the following conditions shall be maintained in order for CNP to operate properly:
— the packet ordering of CNP packets shall be maintained;
— the sender of CNP packets needs not send more than one copy of a CNP packet to each other member of the CNP/IP channel;
— the receiver shall detect duplicate CNP/IP packets and they need not be forwarded;
— packets that exceed the timeout characteristics for the channel need not be forwarded These are referred to as “stale” packets
CNP data packets are transmitted between CNP/IP devices through tunneling over UDP, where each packet is encapsulated with a header in a UDP datagram This combination of the header and the CNP data packet payload is known as a "CNP/IP data message," with the header referred to as the "CNP/IP data message header" and the payload as the "CNP/IP data message payload." It's important to note that a single UDP datagram can contain multiple CNP/IP data messages.
A CNP/IP device forwards data messages to multiple addresses in a forward list using UDP; however, this method does not ensure that the destination host will receive packets without duplicates, out-of-order delivery, or staleness To address these challenges, it is essential for the sender to include additional information in the CNP/IP data messages, enabling the receiver to handle these conditions effectively The subsequent sections will explore these issues in detail.
Out of order packets
Packets identified as out of sequence by the receiver should not be forwarded The CNP/IP device must try to re-order received packets to resolve sequencing issues; however, packets confirmed to be out of order must not be forwarded If re-ordering is unsupported or unfeasible, the packets should be discarded.
The following algorithm should be used to ensure that packets are not forwarded out of sequence by the receiver
Each CNP/IP data source assigns a session ID (SID) and an unsigned 32-bit Packet Sequence Number (PSN) to every data packet sent to an IP destination address The SID/PSN pair is included in each CNP/IP data message, with the PSN incrementing by 1 for each message, while the SID remains constant across successive messages Notably, the SID may be shared among different IP destination addresses that the CNP/IP source communicates with.
When a CNP/IP device initiates a new session to a specific destination address, such as after a power cycle or reboot, it must utilize a new Session Identifier (SID) that differs from the previously used SID Typically, SIDs remain unchanged for consecutive messages, while the Packet Sequence Number (PSN) increases.
— PSNs wrap from 0xFFFFFFFF to 0x00000000 Furthermore let X and Y be PSN’s It follows that
X < Y if (X – Y) < 0x80000000 assuming unsigned 32-bit arithmetic is used
— Each CNP/IP data sink device maintains a "Last Forwarded Sequence" number (LFS) for each IP Source Address/Destination Address (SA/DA) pair from which a data packet is received
The initial value of the LFS for each SA/DA is established based on the PSN of the recently received CNP/IP data message from the SA/DA, provided that certain conditions are met.
— after start-up of the data sink device;
— if the SID is different from the previous CNP/IP data message received from that SA/DA
— Receipt by a data sink of a CNP/IP data message with PSN = LFS + 1 causes the data packet to be forwarded LFS is incremented by 1
A data sink receiving a CNP/IP data message with a Packet Sequence Number (PSN) greater than the Last Forwarded Sequence Number (LFS) plus one may result in the packet being held in escrow This occurs while waiting for the arrival and in-sequence forwarding of all other packets where the PSN falls between (LFS + 1) and the PSN of the first escrowed packet.
If there are escrowed packets and the time since the first escrowed packet was received exceeds the channel timeout period of 1.5 seconds, the wait for all packets in the gap with PSNs between (LFS + 1) and the PSN of the first escrowed packet is abandoned In this case, LFS is updated to the PSN of the first escrowed packet minus one Forwarding of packets proceeds with the next in-sequence packet, whether it is escrowed or live.
— Receipt by a data sink of a CNP/IP data packet with PSN < (LFS + 1) is discarded as a duplicate packet
— Escrowing of CNP/IP data packets from one SA/DA does not affect forwarding or escrowing of CNP/IP data packets from other SA/DA
Duplicate packet detection
The receiver will discard packets identified as duplicates, utilizing the same algorithm outlined in the previous section to maintain proper sequencing.
Stale packet detection
CNP/IP devices must be capable of detecting stale packets, with the option to disable this feature in scenarios where it is unnecessary, such as single segment Ethernet LANs without intervening IP routers When stale packet detection is enabled, any packet deemed stale—defined as taking longer than the channel timeout period (CTP) to reach the receiver—will be discarded The CTP, measured in milliseconds, serves as a reasonable upper limit for packet transmission time and is uniformly applied across all CNP/IP devices on the channel This European Standard does not specify the method for determining the CTP.
To enable devices to identify stale packets, it is essential to measure the time elapsed since a packet was sent over the IP channel This process involves the transmitter assigning a timestamp to each data packet prior to its transmission For CNP/IP to CNP/IP routers, packets receive a new timestamp before being sent to the next IP channel In the case of proxy nodes, which forward packets to the same destination, similar timestamping practices are applied.
IP channel the packets are not re-stamped Also, note that all CNP/IP addresses that receive a specific packet shall have the same time stamp
To ensure the effectiveness of the time stamp, it is essential that the clocks on all devices within the IP channel are synchronized The exact level of accuracy required for this synchronization is not defined, and it may vary based on the type of devices used.
In an IP network, various levels of accuracy can be achieved It's important to recognize that any inaccuracies in time synchronization can lead to transport delay jitter in the tunneled protocol The significance of this issue for each specific protocol is detailed in the relevant annex of this specification.
The synchronization of clocks for CNP/IP devices is achieved through SNTP, as outlined in RFC 2030, which requires an SNTP time server within the IP network and proper configuration of the devices to access its IP address According to RFC 1305, the timestamp format consists of a 32-bit integer for seconds and another 32-bit integer for picoseconds; however, this format lacks the necessary resolution and arithmetic properties Consequently, the timestamp is represented as 32 bits of milliseconds, aligned with the current SNTP time, and it wraps around every 49.7 days.
Maintaining communication with the time server is crucial for device synchronization and effective stale packet detection If communication is lost, devices may only forward packets if they are confident their clocks have not drifted significantly from the network's time standard The time server serves as the common reference point, and devices can continue operations as long as they remain within an acceptable margin of error relative to the last known time from the server Understanding their own clock drift rate enables devices to manage this synchronization effectively.
If a device cannot estimate the margin of error between its clock and those of other devices on the network, it should refrain from forwarding packets to the IP channel.
The NTP time resolution is in picoseconds; however, the practical precision of a system's time is limited by timer interrupts, usually ranging from 10 ms to 16 ms Consequently, while timestamps are measured in milliseconds, the least significant bits (3 or 4) hold no significant value, leading to rounding or truncation in the final time representation.
The EN 14908-4:2014 (E) standard indicates that the smallest receive transaction timer value for CNP is 128 ms, making minor differences between two timestamps insignificant.
General device interaction
The communication process between a CNP/IP device (client) and a configuration server begins with the device sending a registration message that includes configuration parameters, which it will repeat until a response is received, with an exponential increase in the repeat interval up to a maximum of 30 seconds If the server does not wish to add the client, it responds with an acknowledge message indicating ACK_DEVICE_REFUSED; otherwise, it sends a Device Configuration message containing relevant parameters The server does not retransmit the acknowledge packet, so if the device does not receive it, it will resend the original request Upon receiving the Device Configuration message, the device must acknowledge it with various possible values, such as ACK_OK for acceptance, ACK_FIXED for a fixed configuration, ACK_BAD_MESSAGE for a corrupted message, or ACK_CANT_COMPLY if it cannot use the parameters After registration, the device can send additional request messages to the server, which will respond appropriately.
How the server responds to different acknowledgements is not defined here, but the server should log the messages to allow for debugging
8.5.1.2 Unsolicited packets from the server
The server can send an unsolicited Device Configuration message to a device, which the device acknowledges as previously described To prevent overwhelming a device that is coming online, it is advisable for the server to refrain from sending unsolicited packets until the device has completed its request for packets While implementation details may vary, other configuration packets should not be sent unsolicited, and any unsolicited Device Configuration message is not segmented.
The unsolicited Device Configuration message from the server notifies the device of changes in the channel configuration It includes valid datetime fields that reflect the latest Send List and Channel Membership list packets By comparing these datetimes with those of the packets stored on the device, the device will request updated Channel Membership, Send List, and Channel Routing packets from the server to ensure it has the most recent versions.
The configuration of a CNP/IP channel can remain static, even when a configuration server is utilized, particularly if the settings are predetermined and fixed within the server This static configuration can lead to scenarios where a server responds to a client registration message by refusing the CNP/IP device.
The EN 14908-4:2014 (E) standard indicates that devices registering with the server may not be included in a fixed configuration The server's response to a client registration message is determined by the specific vendor's implementation.
8.5.1.3 Requests from devices or other nodes
Devices are expected to respond to requests from other nodes, including other devices, but there are no guarantees for data requested from non-device nodes Segmentation ensures that packets share the same timestamp and a consistent byte structure Additionally, each device must uphold global integrity in its communication with the server.
When device (A) responds to device (B) for channel routing, it is not obligated to notify device (B) of any changes in its routing information during the exchange Device (A) is not responsible for failing responses to device (B) or updating it about data changes through datetime modifications, unless the exchanged data pertains to the altered dataset The sole responsibility of device (A) is to inform the server of the updated information.
Devices are not obligated to respond to unsolicited configuration messages from non-server devices, but they must respond to unsolicited request messages from such devices Consequently, if a device receives unsolicited messages like Channel Membership, Send List, Channel Routing, or Device Configuration from a non-server node, it may disregard them.
All configuration packets include a datetime field that indicates the validity period of the data This field allows for the identification of newer or older data versions with a precision of 1 second To ensure uniqueness, if multiple data versions are generated within the same second, each version is assigned a distinct and incrementally increasing value in this field.
If the network is compatible with SNTP or NTP, the datetime value represents the seconds portion of the NTP date time as specified in RFC 1305, indicating the number of seconds elapsed since 0h on January 1, 1900 It is important to note that this time will expire in 2036 For further information, refer to Clause 3 of RFC 2030.
In networks lacking support for SNTP or NTP protocols, the datetime may be represented as a small integer, excluding zero These integers, originating from the early 1900s, do not reflect actual wall clock time but must still adhere to the principle of uniqueness for all time values Consequently, the emitted values from such devices do not wrap around or repeat for different data entries.
The datetime is represented in UTC (Coordinated Universal Time), ensuring that timezones do not influence the value Daylight saving time adjustments are not applied, which means that when a device transitions between timezones or when daylight saving time begins, the timestamps for configuration packets consistently increase.
As clocks are adjusted, either automatically or manually, the time on a device may shift forward or backward It is crucial that a device never sends a configuration packet with a datetime earlier than any previously emitted packet This can be achieved by storing the datetime of the last emitted configuration packet in non-volatile memory When a new configuration packet is ready to be sent, the device selects the later of the current datetime or the last saved datetime plus one If the device emits configuration packets at an average rate of less than one per second, the system datetime will eventually surpass the configuration datetime.
General protocol interaction
Each sent packet is anticipated to receive a response, which can either be an ACK or another message within a protocol exchange If a different message is received, it should be interpreted as an ACK_OK for the preceding message.
Packets are retransmitted multiple times using a back-off algorithm to prevent congestion, with an example being a retransmit timer initially set to 1 second, which doubles with each attempt until it reaches a maximum of 30 seconds.
ACKs are not retransmitted; however, when a device receives a duplicate message in the protocol, it does not result in a state change Instead, the device will retransmit the corresponding ACK.
A configuration server can manage multiple channels by maintaining a list of device IP addresses for each channel Device Registration messages include the device's IP address, allowing for the identification of the device's channel membership For other messages, the source IP address can be identified from the UDP frame or the TCP connection.
Packet Segmentation
The UDP payload length of around 548 bytes imposes limitations on channel membership and leads to various issues when considering nodes Managing large packets is primarily a concern for configuration protocols associated with these packet types.
— Channel Membership packets for populations larger than about 128 devices;
— Send List packets for populations larger than about 64 devices;
— Channel Routing information for nodes with more than about 4 Domains
When these data sets exceed the 548-byte limitation of the UDP packet size then the segmentation scheme described in 8.3 is used
TCP serves as an optional communication method with a server When the Device Registration packet's IP_PROTOCOL field specifies TCP or both TCP and UDP, the server can utilize a TCP link to exchange data with the device.
In this scenario, segment packets are not utilized, and packets are transmitted in full regardless of their size Additionally, ACK messages are not dispatched on TCP connections, and retransmissions are not carried out Devices can send requests to the server via either TCP or UDP, and the server may respond using the same protocol If a device connects to the server using TCP and the server is TCP-compatible, the response will be provided through TCP.
According to EN 14908-4:2014 (E), when a configuration server detects a change, it can send configuration data unsolicited over the TCP link to the device, starting with the Channel Membership packet followed by relevant updates such as Send List, Device Configuration, or Channel Routing packets In the event of a non-graceful TCP connection break, the device is responsible for re-establishing the connection, as it is assumed that the device has failed or is partitioned from the network The configuration server will attempt to reconnect once to forward updates, while the device should continuously try to reconnect with a reasonable implementation-dependent interval, continuing to route messages based on existing configuration data The TCP connection can be initiated by either the device or the server and remains open for a prudent period, with either side able to terminate it after their own timeout Although a graceful shutdown of the TCP connection is encouraged, it is not mandatory.
When a TCP-supporting device initiates communication with a server, it is uncertain if the server also supports TCP To determine this, the device first attempts to establish a TCP connection with the configuration server Importantly, the device does not have to wait for the connection to either succeed or time out; it can simultaneously send requests via UDP to the server For instance, the device may initiate the TCP connection and immediately transmit the Device Registration packet, which includes essential information for the server.
IP Protocol field that states that the device supports TCP
The device can only verify TCP support from the configuration server by establishing a successful connection, as it is assumed that a node lacking TCP capability will not respond with a "Connection Refused" message.
When a server's capacity for simultaneous connections is exceeded by the number of devices attempting to connect, users may encounter connection refused messages These messages signal a lack of server resources, prompting devices to retry after a delay or switch to using UDP for their connections.
Servers should accelerate timeouts of cached TCP connections to provide one or more open connections for new device conversations.
Device Registration
This interaction is designed to allow a device to inform the Configuration Server of its identity and to obtain IP operational parameters from the server
To initiate communication with the server, the device needs specific information, including its own IP address and port, as well as the IP address and port of the configuration server All other necessary data can be derived from this unique information.
The interaction involves multiple scenarios, including one where the device possesses certain identity information and requires additional data from the server, which is already familiar with the device.
According to EN 14908-4:2014 (E), devices have a fixed configuration that may be locally entered and must register with the server to obtain a send list or channel membership list The protocol does not permit negotiation of configuration; if a device cannot comply with the server's suggested configuration, it will report this and cease operation Even when a device stops functioning, it continues to process messages from the configuration server without routing them, and it does not initiate further interactions with the server, although it processes Device Response messages.
This protocol is depicted in Table 1
Table 1 —Device Registration with Configuration Server Protocol
Send device registration packet → (1) Add to configure or reject
Cease operation until reset ← ACK_DEVICE_REFUSED on reject or Begin operation with new parameters, and ← Device configuration packet
ACK_OK begin operation or → Stop retransmit of device configuration, indicate in database that device is a member.
ACK_CANT_COMPLY cease operation until reset → No further action, no database change.
Perform next step ← Send unsolicited device configuration packet.
ACK_CANT_COMPLY → Request further information if necessary based on datetimes in device response
In the specified scenario, the server fails to resend the Device Configuration packet Consequently, if the client does not receive this packet promptly, it will resend the Device Registration Packet to the server.
In the unsolicited case, the server should retransmit the Device Configuration packet if it does not receive an ACK_OK or an ACK_CANT_COMPLY from the client
A Configuration Server can notify channel members of changes to its configuration, such as alterations to its IP address or port This process, outlined in Table 2, currently lacks security measures Devices may reject these requests and must be configured based on the specific implementation for identifying the Configuration Manager While the protocol does not inherently introduce significant security vulnerabilities, it is susceptible to IP spoofing, allowing another node to impersonate the Configuration Manager when it is offline.
Table 2 — Server to Device Unsolicited Configuration Message Protocol
Build response ← Send Configuration Request packet
Send Device Configuration packet → Build Device Configuration packet
Adopt new IP address / port for Configuration Server and Time Server
→ Proceed normally as Configuration server
Send ACK_CANT_COMPLY Cease operation so as not to interfere with further operations of channel.
→ Mark Device as no longer a member of the channel.
For a device to maintain interoperability, it must either comply with server changes or be compatible only with similar devices A new configuration manager depends on all devices following its commands; otherwise, it must wait for manual updates to address any failures.
Before sending a new Device Configuration packet, the server must request the client's configuration However, it is not mandatory for the client to receive this request prior to processing the new Device Configuration packet from the server.
Channel Membership
The purpose of this interaction is to allow device to obtain a complete list of other devices on the channel This protocol is depicted in Table 3
If the channel membership list changes after some devices are active, the server can send an unsolicited Device Configuration packet with a new datetime for the Channel Membership packet
Table 3 — Device to Server Channel Membership Request Protocol
Send Channel Membership Request packet → Find device in database and identify channel.
Cease operation until reset ← ACK_DEVICE_REFUSED if no channel defined or device is not a member of any channel or Begin operation with new parameters ← Send Channel Membership packet
The Channel Membership packet is not retransmitted by the server If the device does not receive the packet, it requests again
When a configuration change occurs, the server promptly notifies all members of the update There are three types of changes: a device can be added to the list, or a device can be removed from the list.
EN 14908-4:2014 (E) c) a device changes its configuration requiring other nodes to update their Send List or Channel Routing information for that node
The server manages these cases by sending an unsolicited Device Configuration packet containing an updated datetime for the Channel Membership packet to all devices Upon receiving this, the device requests a new Channel Membership packet If the node determines it is not part of the membership, it stops routing packets and waits for additional configuration messages Conversely, if the node lacks a channel membership list, indicating it has just been added to the channel, it will request Channel Routing packets or a Send List packet.
Each entry in the Channel Membership packet includes a datetime that marks the last valid datetime of the Channel Routing packet Additionally, it features a SendListDateTime, which indicates the last valid time for a send list packet, and a DeviceRequestDateTime, representing the last valid time for that packet specific to the device These datetimes are essential for the device to request updated information.
Send List
This interaction allows device to obtain a send list for the channel This protocol is depicted in Table 4
If the send list changes after some devices are active, the protocol can begin with the server sending a Device Configuration packet as an unsolicited message (see 8.5.4)
The send list is an optional method for routers to forward packets, allowing a configuration server to centrally manage multicast addresses for a channel Servers are required to create Send List packets and respond to device requests for these packets, while device support for Send List packets is optional, meaning they are not obligated to request them from servers.
The configuration of a Send List on a server is implementation dependent, provided it follows the three rules outlined in Clause 6.1 If a Send List is not configured or a more advanced algorithm is unavailable, the server can utilize a specific algorithm to generate the Send List.
If and only if every Device in the CNP/IP channel belongs to the same multi-cast group(s) use Algorithm
A, else use Algorithm B Note that which multi-cast groups a device belongs to are part of the device's configuration which the server has full knowledge of This knowledge is gained either through the Device Registration packet sent from the device or the Device Configuration packet sent from the server to the device
Select a single multi-cast group that every device on the CNP/IP channel belongs to Use the multi-cast
The IP address serves as the sole entry in the Send List for this group It is important to note that the algorithm relies on all devices within the CNP/IP channel being part of the specified multicast group in the Send List If this condition is not met for any reason, the Send List will be updated accordingly.
To ensure proper communication, each device in the Channel Membership list must have its corresponding unicast IP address added to the Send List, maintaining a one-to-one correspondence Any additions or deletions of devices in the Channel Membership list will require corresponding updates to the Send List.
When utilizing send lists, each packet forwarded by a device is transmitted to all addresses in the list without exception The device monitors the ports and addresses outlined in the Device Configuration messages.
Table 4 — Device to Server Send List Request Protocol
Send Send List Request packet → Find device in database and identify send list.
Cease operation until reset ← ACK_DEVICE_REFUSED if no channel defined or device is not a member of any channel or Begin operation with new parameters ← Send Send List packet
The Send List packet is not retransmitted by the server If the device does not receive the packet, it requests again.
Channel Routing
This interaction enables the device to acquire Channel Routing information or transmit it to the server for distribution to other devices, as illustrated in Tables 5 and 6.
CNP/IP devices exchange packets that contain routing information for the specified device When a configuration server transmits multiple packets, each unicast IP address corresponds to an entry in the channel membership list, indicating the routing information for that node It is essential that all IP addresses of channel members are unique.
Support of Channel Routing packets is optional
The packet contains routing tables that include subnet and group masks, which help routers efficiently manage data transmission By utilizing this subnet and group mask information, routers can prevent unnecessary bandwidth usage by avoiding the transmission of every packet to all other routers, especially in scenarios where multicast addressing is not permitted on the IP network.
The SubnetMsk, GroupMsk, and Domain structure may be repeated in the packet if the router can route to a more than one CNP domain or as a proxy
If the channel routing information changes after some devices are active, the protocol can begin with the server sending an unsolicited Device Configuration message (see 8.5.4)
When a device supports Channel Routing packets, and it has new channel routing information, the device creates a new Channel Routing packet This packet is then transmitted to the server
Table 5 — Device to Server Channel Routing Update Protocol
Send Channel Routing packet → Find device in database and identify routing list.
EN 14908-4:2014 (E) defined or device is not a member of any channel or Stop re-transmission of Channel
Routing Packet ← Send ACK_OK.
When a device supports Channel Routing packets, it requires the Channel routing packets of the other devices on the channel It obtains these packets in the manner shown in Table 6
Table 6 — 6 Device to Server Channel Routing Request Protocol
Send Channel Routing Request packet → Find device in database and identify routing list.
Cease operation until reset ← ACK_DEVICE_REFUSED if no channel defined or device is not a member of any channel or Begin operation with new parameters ← Send Channel Routing packet.
The transmission by the server is not repeated and no ACK is performed by the device If the device does not receive the message, it requests again
The Channel Routing Request message contains two fields of interest in the request to the server:
Datetime indicates that data should be sent if any data is newer than this datetime Zero indicates always send the data;
An IP Unicast Address that is non-zero signifies that only the channel routing specific to this device will be transmitted Conversely, a zero value indicates that all channel routing information for every member of the channel should be sent.
To optimize server requests, routers can selectively request information For instance, when a router retrieves a channel membership list and identifies a new device, it may only request the routing information specific to that device.
8.5.7.2 Routing to subnet/node addresses
The Channel Routing packet includes a list of subnet and node addresses along with domain information and subnet masks, which routers utilize to achieve optimal routing.
Messages directed to a specific domain, subnet, or node address are delivered to the corresponding device, while subnet broadcasts and directed Unique ID messages reach all nodes within that subnet These subnets are not included in the domain's subnet mask Although domain, subnet, and node addresses are generally unique, there are instances—such as error conditions or temporary situations—where multiple devices may claim the same address, necessitating message routing to all affected devices.
8.5.7.3 Semantics for Wants All Broadcasts
The CNP Flags field of the Channel Routing packet contains a bit called WANTS_ALL_BROADCASTS This field conditions optimised routing as follows:
Every device must have at least one CNP addressable node For instance, in the case of CNP/IP Routers, this node refers to the router side linked to the IP channel If a device possesses at least one un-configured CNP addressable node, it will indicate that it requires all broadcasts, whether domain-wide or otherwise.
The EN 14908-4:2014 (E) standard specifies that CNP nodes will respond to all broadcast messages within a subnet, irrespective of the domain ID, when they are in an un-configured state.