IEC PAS 62412:2005

PUBLICLY
IEC
AVAILABLE
PAS 62412
SPECIFICATION
First edition
2005-08
Real-time Ethernet P-NET
on IP specification
Reference number
IEC/PAS 62412:2005(E)
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the

60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,

edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the

base publication incorporating amendment 1 and the base publication incorporating

amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
PUBLICLY
IEC
AVAILABLE
PAS 62412
SPECIFICATION
First edition
2005-08
Real-time Ethernet P-NET
on IP specification
 IEC 2005  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale
U
International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue

– 2 – PAS 62412 © IEC:2005 (E)

CONTENTS
FOREWORD.3

INTRODUCTION.4

1 Scope and object.5

2 Normative references .5

3 Conventions .5

4 61158-2 Physical Layer specification .6

4.1 OSI Data Link Layer .6
4.1.1 MAC sublayer .6
4.1.2 LLC sublayer .6
4.2 OSI Network layer .6
4.3 OSI Transport layer .6
5 61158-4 Data Link Layer protocol specification.7
5.1 Terms and definitions .7
5.1.1 P-NET-route .7
5.2 Additions to terms and definitions .7
5.2.1 IPNetTable .7
5.2.2 IPNetID.7
5.2.3 UDP port number .7
5.2.4 Nettype.7
5.2.5 IP Range net.7
5.2.6 UDP Range net.7
5.3 Type 4: Additional symbols and abbreviations .8
5.3.1 Constants, variables, counters and queues.8
5.4 Type 4: Data Link Protocol Definition .8
5.4.2 PhIDU structure and encoding.9
5.4.3 Frame check sequence .10
5.5 Additions to Frame check sequence .11
5.5.2 Common DLPDU structure, encoding and elements of procedure .11
5.6 Additions to P-NET-route field.11
5.7 DLPDU-specific structure, encoding and elements of procedure .13
5.7.2 Request P-NET-route generation.17

5.7.3 DL-route generation .18
6 61158-5 Application Layer service definition.20
7 Addressing conventions for P-NET on IP.25
8 Translation of P-NET address to IP address .27
9 Dynamic clients .28
10 Broadcast / Netcast .28
11 Package format .28

PAS 62412 © IEC:2005 (E) – 3 –

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
Real-time Ethernet P-NET on IP specification

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote

international co-operation on all questions concerning standardization in the electrical and electronic fields. To

this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,

Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
A PAS is a technical specification not fulfilling the requirements for a standard but made
available to the public.
IEC-PAS 62412 has been processed by subcommittee 65C: Digital communications, of IEC
technical committee 65: Industrial-process measurement and control.

The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
65C/360/NP 65C/376/RVN
Following publication of this PAS, the technical committee or subcommittee concerned will
transform it into an International Standard.
It is intended that the content of this PAS will be incorporated in the future new edition of the
various parts of IEC 61158 series according to the structure of this series.
This PAS shall remain valid for an initial maximum period of three years starting from
2005-08. The validity may be extended for a single three-year period, following which it shall
be revised to become another type of normative document or shall be withdrawn.

– 4 – PAS 62412 © IEC:2005 (E)

INTRODUCTION
The P-NET on IP specification is designed for use in an IP-environment. P-NET on IP enables
use of P-NET (IEC 61158, type 4) real-time communication wrapped into UDP/IP packages.

P-NET packages can be routed through IP-networks in exactly the same way as they can be

routed through non-IP-networks. Routing can be through any type of P-NET network and in

any order.
Nodes on an IP-network are addressed with two P-NET Route elements, but this is entirely

handled by the IP-nodes. This means that any P-NET client (master) can access servers on
an IP-network without knowing anything about IP-addresses.

PAS 62412 © IEC:2005 (E) – 5 –

Real-time Ethernet P-NET on IP specification

1 Scope and object
This PAS consists of paragraphs that are meant to be additional to the definitions and

specifications, which are already found in the IEC 61158 series. Following each heading,

there will be a reference to which paragraph must be inserted or replaced within the relevant

IEC 61158 series.
After the modifications to IEC 61158 series a few descriptions explain how to perform address

conversions and handle dynamic clients.

NOTE These descriptions are more implementation specific and will not be included in the normative parts of the
new standard.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.

IEC 61158-2:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 2: Physical layer specification and service definition

IEC 61158-4:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 4: Data link protocol specification

ISO/IEC 8802-3, Information technology – Telecommunications and information exchange
between systems - Local and metropolitan area networks – Specific requirements – Part 3:
Carrier sense multiple access with collision detection (CSMA/CD) access method and
physical layer specifications
RFC 768 (UDP, User Datagram Protocol)

RFC 791 (IP, Internet Protocol)

3 Conventions
This PAS specifies paragraphs that shall either be replaced or added to the IEC 61158 series.
Paragraphs that shall be replaced are indicated with the paragraph number(s) in question as

reference and begin and end with the lines as shown:
----------------------------------- Replace begin --------------------------------
modified text
----------------------------------- Replace end --------------------------------
Paragraphs that shall be added are indicated with first paragraph number(s) to add and begin
and end with the lines as shown:
----------------------------------- Addition begin --------------------------------
new text
----------------------------------- Addition end --------------------------------

– 6 – PAS 62412 © IEC:2005 (E)

4 61158-2 Physical Layer specification

----------------------------------- Addition begin --------------------------------

ISO/IEC 8802-3 shall be used.
4.1 OSI Data Link Layer
4.1.1 MAC sublayer
ISO/IEC 8802-3 shall be used.
4.1.2 LLC sublayer
ISO/IEC 8802-3 shall be used.
4.2 OSI Network layer
Internet standard RFC 791 (IP, Internet protocol) and its amendments and successors shall
be used.
4.3 OSI Transport layer
Internet standard RFC 768 (UDP, User Datagram Protocol) and its amendments and
successors and the Data Link Layer protocol specification within this document shall be used.
----------------------------------- Addition end --------------------------------

PAS 62412 © IEC:2005 (E) – 7 –

5 61158-4 Data Link Layer protocol specification

5.1 Terms and definitions
5.1.1 P-NET-route
The following term is to be replaced in 3.7.8, Type 4: Additional terms and definitions:

----------------------------------- Replace begin --------------------------------

A P-NET route holds a sequence of P-NET-route-elements.

NOTE A P-NET-route is defined as an encoded DL-route, with one of the formats used when transmitting the

DLPDU on the Link. The P-NET-route format can be Simple, Extended, Complex, Immediate or IP.

----------------------------------- Replace end --------------------------------

5.2 Additions to terms and definitions
The following terms are to be added in paragraph 3.7, Type 4: Additional terms and
definitions:
----------------------------------- Addition begin --------------------------------
5.2.1 IPNetTable
An IpNetTable defines the relation between IPNetID, IP address, UPD port number and
Router NodeAddress, where IPNetID is used as index in the table.
5.2.2 IPNetID
IPNetID identifies a unique IP network. The value of IPNetID shall be in the range of 0-127.
The values 0, 126 and 127 are reserved for special purposes.
NOTE An IPNetID is translated into an IP-address and a UPD port number.
5.2.3 UDP port number
A Server can receive requests on two different UPD port numbers: Normal UDP port and
Secure UDP port. UDP port number shall be 34378 for Normal UDP port. UDP port number
shall be 34379 for Secure UDP port.
NOTE These UDP port numbers are registered with the IANA (Internet Assigned Numbers Authority)
5.2.4 Nettype
An IP network is of a certain type, a Nettype that can be “Unused”, “IP Range net” or “UDP
Range net”.
5.2.5 IP Range net
An IP Range net is used for local access, where nodes can be accessed directly on the same
subnet as the client, or through a local Router where the subnets are configured in the local
Router.
5.2.6 UDP Range net
A UDP Range net is used for remote access, where a node cannot be accessed directly on
the same subnet as the client. The IPNetTable holds a NAT Router IP address and access to
the node is obtained through this NAT Router.
NOTE The NAT Router shall hold a table that translates the UDP port number to the actual server node IP address
and UDP port number.
----------------------------------- Addition end --------------------------------

– 8 – PAS 62412 © IEC:2005 (E)

5.3 Type 4: Additional symbols and abbreviations

5.3.1 Constants, variables, counters and queues

The following paragraph shall be added to paragraph 4.5.1, Type 4: Additional symbols and

abbreviations:
----------------------------------- Addition begin --------------------------------

5.3.1.1 IPNetTable Table to convert IPNetID to IP-addresses

----------------------------------- Addition end --------------------------------

5.4 Type 4: Data Link Protocol Definition
5.4.1.1 Half-duplex and full duplex
The following paragraphs are to be replaced in paragraph 24.1.2.2, Type 4: Data Link
Protocol Definition:
----------------------------------- Replace begin --------------------------------
Unless otherwise stated, the PhL is assumed to support half-duplex transfer. However, a PhL
supporting full duplex is allowed.
Full duplex systems allow up to 125 DLEs on a Link, all of Normal class. Each DLE is allowed
to transmit immediately, that is, there is no Link Access system. DLEs supporting full duplex
PhEs have separate state machines for receive and transmit, as illustrated in Figure 91 to
Figure 92.
In full duplex systems, as well Confirmed as Unconfirmed DLPDUs are unacknowledged.
PhLs supporting full duplex shall not provide Link-Idle indications.
----------------------------------- Replace end --------------------------------

5.4.1.2 Responder role, receiving a DLPDU from the PhE
The following paragraphs are to be replaced in 24.1.2.5, Type 4: Data Link Protocol
Definition:
----------------------------------- Replace begin --------------------------------

This action includes a sequence of steps, as described in the following.
a) Receive a single PhIDU specifying START-OF-ACTIVITY. This PhIDU holds a Node
address. This address is examined to determine, whether its value is equal to the Node-
address of this DLE, or equal to the Broadcast-Node-address (BNA) or the Service-Node-
Address (SNA). If not, ignore this sequence and wait for the next PhIDU specifying START-
OF-ACTIVITY.
b) Receive a sequence of PhIDUs from the PhE, specifying DATA, concatenate them to a
received DLPDU, compute a frame check sequence over the entire sequence of received
data as specified by the value of V(FCM) - FrameCheckMethod, and, if necessary, check
for the proper value. If the value is not correct, ignore the DLPDU and wait for the next
PhIDU specifying START-OF-ACTIVITY.
c) Convert the received DLPDU into its DL-protocol control information and data
components.
PAS 62412 © IEC:2005 (E) – 9 –

d) Generate a DLS-user indication primitive.

e) If the DLPDU received from the remote DLE is of type Confirmed, and the receipt of

the DLPDU must be acknowledged, according to the rules described in 24.1.2.1, wait for a

request or response primitive from the local DLS-user.

If no request or response primitive is issued from the local DLS-user in time (before a

PhIDU specifying "LINK-IDLE for 30 bit periods" is received from the PhE), generate and

immediately send an Acknowledge DLPDU. This DLPDU must specify "Wait" if this DLE is

of Simple class, and "Response Comes Later / Acknowledge" ("RCL/ACK") if this DLE is of
Normal class.
If a response primitive is issued from the local DLS-user in time, generate and

immediately send an Acknowledge DLPDU, specifying "Wait" if this DLE is of Simple
class, and "RCL/ACK" if this DLE is of Normal class.
If a request primitive is issued from the local DLS-user in time, convert it into an
Immediate-reply DLPDU and send it immediately. After sending, wait for the next PhIDU
specifying START-OF-ACTIVITY.
f) If the DLPDU received from the remote DLE is of type Confirmed, and the receipt of
the DLPDU shall not be acknowledged, wait for the next PhIDU specifying START-OF-
ACTIVITY.
g) If the DLPDU received from the remote DLE is of type Unconfirmed, and the receipt of
the DLPDU must be acknowledged, according to the rules described in 24.1.2.1, generate
and immediately send an Acknowledge DLPDU, specifying RCL/ACK. After sending, wait
for the next PhIDU specifying START-OF-ACTIVITY.
h) If the DLPDU received from the remote DLE is of type Unconfirmed, and the receipt of
the DLPDU shall not be acknowledged, wait for the next PhIDU specifying START-OF-
ACTIVITY.
----------------------------------- Replace end --------------------------------

5.4.2 PhIDU structure and encoding
The following paragraphs are to be replaced in 24.2.1, Type 4: Data Link Protocol Definition:
----------------------------------- Replace begin --------------------------------
Each PhIDU consists of Ph-interface-control-information and in some cases one octet of Ph-
interface-data (see 24.1.3). When the DLE transmits a DLPDU, it computes a frame check

sequence for the DLPDU as specified in 24.2.2, concatenates the DLPDU and the frame
check sequence, and transmits the concatenated pair as a sequence of PhIDUs as follows:
a) The DLE issues a single Ph-DATA request primitive with PhICI specifying START-OF-
ACTIVITY-2 if sending from the queue, and specifying START-OF-ACTIVITY-11 if sending an
Acknowledge or Immediate-reply DLPDU, or if re-transmitting because of missing
acknowledge. The request primitive is accompanied by one octet holding the first octet
from the DLPDU as Ph-interface-data. After that, the DLE awaits the consequent Ph-DATA
confirm primitive.
b) The DLE issues a sequence of Ph-DATA request primitives with PhICI specifying DATA,
each accompanied by one octet of the DLPDU as Ph-interface-data, from second to last
octet of the DLPDU, and after each Ph-DATA request primitive awaits the consequent Ph-
DATA confirm primitive.
c) If the value of V(FCM) - FrameCheckMethod - specifies reduced frame check, the DLE
issues a single Ph-DATA request primitive with PhICI specifying DATA, accompanied by

– 10 – PAS 62412 © IEC:2005 (E)

one octet holding the computed FCS as Ph-interface-data, and after the Ph-DATA request

primitive awaits the consequent Ph-DATA confirm primitive. If the value of V(FCM) -
FrameCheckMethod - specifies normal frame check, the DLE issues a sequence of Ph-
DATA request primitives with PhICI specifying DATA, each accompanied by one octet of the

FCS as Ph-interface-data, from first to last octet of the FCS, and after each Ph-DATA

request primitive awaits the consequent Ph-DATA confirm primitive. If the value of V(FCM)

- FrameCheckMethod - specifies None frame check, the transmission is finished.

d) The DLE issues a single Ph-DATA request primitive with PhICI specifying END-OF-

ACTIVITY, and awaits the consequent Ph-DATA confirm primitive.

It is a task of the implementation to ensure that there are no idle periods between the octets

of a transmitted DLPDU.
The DLE forms a received DLPDU by concatenating the sequence of octets received as Ph-
interface-data of consecutive Ph-DATA indications, computing a frame check sequence for
those received octets as specified in 24.2.2, and compares the received FCS value with the
computed, as follows:
1) The DLE received a single Ph-DATA indication primitive with PhICI specifying START-
OF-ACTIVITY, accompanied by one octet of the received DLPDU as Ph-interface-data, and
initializes its computation of an FCS for the received DLPDU.
2) The DLE receives a sequence of Ph-DATA indication primitives with PhICI specifying
DATA, each accompanied by one octet of the received DLPDU as Ph-interface-data,
incrementally computes an FCS on the received octet, and concatenates all, or all except
the last one or two as specified by V(FCM), of those received octets to form the received
DLPDU. During reception, the DLE encodes the DLPDU being received to compute the
number of octets forming the DLPDU.
3) When the DLE has received the last Ph-DATA indication, it compares the value(s) (if
any – depending on frame check method) of the computed FCS to zero:
i) If the value(s) is (are) zero, then the DLE reports the reconstructed DLPDU as
a correctly received DLPDU suitable for further analysis.
ii) If the value(s) is (are) not zero, the DLE ignores the received DLPDU, and
performs no further actions related to the received DLPDU.
----------------------------------- Replace end --------------------------------

5.4.3 Frame check sequence
The following paragraphs are to be replaced in 24.2.2, Type 4: Data Link Protocol Definition:
----------------------------------- Replace begin --------------------------------
The value of the DLE local variable V(FCM) determines which frame check method to use.
The following frame check methods are defined: "Normal", "Reduced" and “None”.
----------------------------------- Replace end --------------------------------

PAS 62412 © IEC:2005 (E) – 11 –

5.5 Additions to Frame check sequence

The following paragraph is to be added after 24.2.2.2, Type 4: Data Link Protocol Definition:

----------------------------------- Addition begin --------------------------------

5.5.1.1 None frame check method

The "None" frame check method uses no frame check. This method is only used for IP
networks. In this case the DLPDU is data within a frame on the IP network and the IP network
specifies the frame check.
----------------------------------- Addition end --------------------------------

5.5.2 Common DLPDU structure, encoding and elements of procedure
The following paragraph is to be replaced in 24.2.3, Type 4: Data Link Protocol Definition:
----------------------------------- Replace begin --------------------------------
Each DLPDU consists of a P-NET-route field, a Control-status field, a Data-field-format field,
and for most DLPDUs a Data field. An FCS field (see 24.2.2), which is used to check the
integrity of the received DLPDU can be appended before transmission, and removed after
reception.
----------------------------------- Replace end --------------------------------

5.5.2.1 P-NET-route field
The following paragraphs are to be replaced in 24.2.3.1, Type 4: Data Link Protocol
Definition:
----------------------------------- Replace begin --------------------------------
The first field in each DLPDU is a P-NET-route field. The P-NET-route field holds a P-NET-
route and consists of 2-30 octets, called P-NET-route-elements. Each P-NET-route-element is
an octet, holding a 7-bit DL-route-element or Remaining-route-length, and a 1-bit
Source/Destination designator. Five different P-NET-route field formats are defined: "Simple",
"Extended", "Complex", "Immediate" and “IP”. The P-NET-route field format is indicated by the
sequence of Source/Destination designators.

The Source/Destination designator is physically located as bit 8 in the octet. A value of "0"
designates "Destination", and a value of "1" designates "Source".
----------------------------------- Replace end --------------------------------

5.6 Additions to P-NET-route field
The following paragraphs are to be added after 24.2.3.1.4, Type 4: Data Link Protocol
Definition:
----------------------------------- Addition begin --------------------------------

– 12 – PAS 62412 © IEC:2005 (E)

5.6.1.1.1 IP P-NET-route format

P-NET-route fields of IP format consist of more than 2 destination P-NET-route-elements

followed by 2 or more source P-NET-route-elements, as illustrated in Figure 1.

0 Destination address
0 Destination address
0 Remaining-route-length
1 Source address
1 Source address
Figure 1 – IP P-NET-route format
The first Destination address is the IPNetID, which identifies the IP net to receive the DLPDU.
The second Destination address identifies the DLE to receive the DLPDU. The remaining
Destination addresses are used by the DLS-user. The third P-NET-route-element holds the
number of P-NET-route-elements following the third P-NET-route-element. The first Source
address identifies the transmitting IP net. The second Source address identifies the
transmitting DLE. The remaining source addresses (maybe except the last) are used by the
DLS-user.
Complex routes are used when sending Confirmed or Unconfirmed DLPDUs holding requests
or Unconfirmed DLPDUs holding responses to DLEs of normal class. The DLPDU is
Unconfirmed if the value of the last Source address equals 0, or the value of one of the
Destination addresses equals BNA.
----------------------------------- Addition end --------------------------------

PAS 62412 © IEC:2005 (E) – 13 –

5.7 DLPDU-specific structure, encoding and elements of procedure

The following paragraphs are to be replaced in 24.3, Type 4: Data Link Protocol Definition:

----------------------------------- Replace begin --------------------------------

Table 1 – Summary structure of DLPDUs

DLPDU type P-NET-route Destination Last Source Control-status Data Data

format Node-addresses address size

Confirmed Simple ≠ BNA ≠ 0 Any > 2 user data

Confirmed Extended Any > 2 user data
≠ BNA ≠ 0
Confirmed Complex Any > 2 user data
≠ BNA ≠ 0
Confirmed IP ≠ BNA ≠ 0 Any > 2 user data
Unconfirmed Simple = BNA Any > 2 user data
≠ 0
Unconfirmed Extended = BNA Any > 2 user data
≠ 0
Unconfirmed Complex = BNA ≠ 0 Any > 2 user data
Unconfirmed Complex ≠ BNA = 0 Any ≥ 0 user data
Unconfirmed IP Any > 2 user data
= BNA ≠ 0
Unconfirmed IP ≠ BNA = 0 Any ≥ 0 user data
Immediate-reply Immediate Any Any Any ≥ 0 user data
Acknowledge Immediate Any Any = Wait / RCL/ACK = 0 -

The DLPDU type is indicated by the P-NET-route format, the contents of the Destination
Node-addresses in the P-NET-route, the con
...