EN 13321-2:2012

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Odprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Elektronski sistemi za stanovanja in stavbe - 2. del: Komunikacija KNTnet/IPOffene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP KommunikationRéseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Systèmes électroniques pour la maison et le bâtiment - Partie 2: Communication KNXnet/IPOpen Data Communication in Building Automation, Controls and Building Management - Home and Building Electronic Systems - Part 2: KNXnet/IP Communication97.120Avtomatske krmilne naprave za domAutomatic controls for household use35.240.99IT applications in other fieldsICS:Ta slovenski standard je istoveten z:EN 13321-2:2012SIST EN 13321-2:2013en,fr,de01-junij-2013SIST EN 13321-2:2013SLOVENSKI
STANDARDSIST EN 13321-2:20071DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 13321-2
December 2012 ICS 35.240.99; 97.120 Supersedes EN 13321-2:2006English Version
Open Data Communication in Building Automation, Controls and Building Management - Home and Building Electronic Systems -Part 2: KNXnet/IP Communication
Réseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Systèmes électroniques pour la maison et le bâtiment - Partie 2: Communication KNXnet/IP
Offene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP-Kommunikation This European Standard was approved by CEN on 30 September 2012.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2012 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 13321-2:2012: ESIST EN 13321-2:2013

List of codes . 94Annex B (informative)
Binary examples of KNXnet/IP IP frames . 103Annex C (normative)
KNXnet/IP Parameter Object . 122SIST EN 13321-2:2013

Common External Messaging Interface (cEMI) . 125Annex E (normative)
Coupler Resources . 158Bibliography . 170 SIST EN 13321-2:2013

The KNXnet/IP standard consists of the following clauses:  Clause 1, Overview  Clause 2, Core Specification  Clause 3, Device Management  Clause 4, Tunnelling  Clause 5, Routing  Clause 6, Remote Diagnosis and Configuration Additional clauses may be added to the KNXnet/IP standard in the future at which time Clause 1 “Overview” as well as Annex A will need to be updated. KNXnet/IP supports different software implementations on top of the protocol. More specifically, these software implementations can be Building Management, Facility Management, Energy Management, or simply Data Base and SCADA (Supervision, Control and Data Acquisition) packages.
Most of these packages need to be configured for the specific user application. In order to simplify this process and cut costs for engineering, KNXnet/IP provides simple engineering interfaces, namely a description “language” for the underlying KNX system. This may be done off-line, e.g. generated as an ETS export file, or on-line by a mechanism that self-describes the underlying KNX system (reading data from the system itself). In conjunction with the EIB/KNX-to-BACnet mapping described in EN ISO 16484-5, EIB/KNX installations can very easily be integrated into BACnet system environments. KNXnet/IP supports:  on-the-fly change-over between Operational modes (configuration, operation);  event driven mechanisms;  connections with a delay time greater than tEIB_transfer_timeout
(e.g. network connection via satellite). Clause 1, Overview Clause 1 “Overview” provides a general overview of KNXnet/IP and covers security considerations. Clause 2, Core specification SIST EN 13321-2:2013

Figure 1 — Device types and configuration examples 2 Normative references Not applicable. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 subnet portion of a network that shares a common address component known as the "subnet address" Note 1 to entry: Different network protocols specify the subnet address in different ways. 3.2 Engineering Tool Software ETS software used to configure KNX devices 3.3 Host Protocol Address Information HPAI structure holding the IP host protocol address information used to address a KNXnet/IP endpoint on another KNXnet/IP device 3.4 communication channel logical connection between a KNXnet/IP client and a KNXnet/IP server (or, in case of routing, between two or more KNXnet/IP servers)
Note 1 to entry: A communication channel consists of one or more connections on the definition of the host protocol used for KNXnet/IP. SIST EN 13321-2:2013

Note 1 to entry: A KNXnet/IP server is by design always also a KNX node. 3.7 KNXnet/IP client application using the KNXnet/IP client protocol to get access to a KNX subnetwork over an IP network channel 3.8 KNXnet/IP device implementation of KNXnet/IP services on a KNX node (KNXnet/IP server) or any other hardware (KNXnet/IP client) 3.9 KNXnet/IP router special type of KNXnet/IP device that routes KNX protocol packets between KNX sub-networks 3.10 Time To Live TTL maximum number of IP routers a multicast UDP/IP datagram may be routed through
Note 1 to entry: Each IP router the datagram passes decrements the TTL by one; the local host adapter also does this. When the TTL has reached zero, the router discards the datagram. When sending a datagram from the local host adapter, a TTL of zero means that the datagram never leaves the host. A TTL of one means that the datagram never leaves the local network (it is not routed). 3.11 KNXnet/IP Tunnelling services for point-to-point exchange of KNX telegrams over an IP network between a KNXnet/IP device acting as a server and a KNXnet/IP client
3.12 Internet Control Message Protocol ICMP extension to the Internet Protocol (IP) for error, control, and informational messages
Note 1 to entry: ICMP is defined by RFC 1) 92 and supports packet containing error, control, and informational messages. The PING command, for example, uses ICMP to test an Internet connection. 3.13 Internet Group Management Protocol IGMP extension to the Internet Protocol (IP) for management of IP multicasting in the Internet Note 1 to entry: IGMP is defined in RFC 1112 as the standard for IP multicasting in the Internet. It is used to establish host memberships in particular multicast groups on a single network. By using Host Membership Reports, the
1) Request for Comment: Internet Standards defined by the Internet Engineering Task Force (IETF) are firstly published as RFCs. SIST EN 13321-2:2013

Note 1 to entry: IP channels are either a guaranteed, reliable TCP (transmission control protocol) or an unreliable point-to-point or multicast (in case of routing) UDP (user datagram protocol) connection. 3.15 communication channel as defined by the KNXnet/IP Core specification, this is represented by one or two IP channels 3.16 common External Message Interface cEMI generic structure for medium independent KNX messages Note 1 to entry: cEMI (common EMI) frames are used to encapsulate KNX messages within Internet Protocol (IP) packets. 4 Symbols and abbreviations For the purpose of this document, the symbols, abbreviations and acronyms used are listed below. Tables listing implementation requirements use the following abbreviations. Symbol Description M Mandatory Cn Conditions are specified under note "n" O Optional X Not allowed n/a Not applicable R Required MC Message code AddIL length of additional information 4.1 DHCP Dynamic Host Configuration Protocol communication protocol for automatic assignment of IP address settings 4.2 DNS Domain Name Service assigns Internet names to IP addresses 4.3 EIB European Installation Bus Standard for Building Controls (EN 50090) SIST EN 13321-2:2013

Table 1 — KNXnet/IP service types and IP protocols IP protocol Service Type Core Device Management Tunnelling Routing ARP M M M M RARP O O O O Support of fixed IP address M M M M BootP (Client)a
M M M M DHCP (Client)a M M M M UDP M M M M TCP O O O na ICMP M M M M IGMP M M na M a BootP/DHCP: It is essential that either one be implemented by a KNXnet/IP device.
Other Internet protocols like NTP (network time protocol), FTP (file transfer protocol), HTTP (hypertext transfer protocol), SMTP (simple message transfer protocol), DNS (domain name system), and SNMP (simple network management protocol) may be used but are not within the scope of the KNXnet/IP protocol. 5.1.2.2 Minimum KNXnet/IP device requirements KNXnet/IP service types as defined in this standard require the implementation of a minimal set of IP protocols for interworking. KNXnet/IP servers shall implement these IP protocols: ARP, BootP, UDP, ICMP and IGMP. Other IP protocols may be required for specific services. 5.1.2.3 Network environment Because KNXnet/IP servers use IP, this standard does not require any specific medium carrying the IP datagrams. SIST EN 13321-2:2013

Table 2 — KNXnet/IP device classes Device Class Service Type Core Device Management Tunnelling Routing A (Configuration and System Maintenance Tools)M M M M B (KNXnet/IP Router) M M M M C (any other KNXnet/IP device) M M O O
Table 3 — Threats and countermeasures Threat… Is countered by measure(s) Eavesdropping a), b), d) Traffic analysis a), d) Masquerade a), c), d) Access control violation a), c), d) Modification a), e) Deletion a) Delay a) Replay c), e) Denial of service a)
5.1.3.4 Conclusion Most of the listed threats are countered by staying within a network, which tightly supervises and restricts network access from outside the network. Using authentication when establishing point-to-point connections is an additional means to this end. SIST EN 13321-2:2013

Figure 2 — KNXnet/IP frame binary format The type of KNXnet/IP frame is described by a KNXnet/IP service type identifier in the header. KNXnet/IP services include, but are not limited to, information regarding discovery and description, communication channel (connection) management and KNX data transfer. 5.2.2.3 Header 5.2.2.3.1 Description Every KNXnet/IP frame, without any exception, consists at least of the common KNXnet/IP header that contains information about the protocol version, the header and total packet length and the KNXnet/IP service type identifier. The KNXnet/IP header may be followed by a KNXnet/IP body, depending on the KNXnet/IP service. Timestamp information and frame counters are not included in the common KNXnet/IP frame header as this information is closely linked with certain KNXnet/IP service types and will therefore be included in the body of these services as additional information for certain communication channel types.
Figure 3 — KNXnet/IP header binary format 5.2.2.3.2 Header length Although the length of the header is always fixed, it is possible that the size of the header changes with a new version of the protocol. The header length can be used as an index into the KNXnet/IP frame data to find the beginning of the KNXnet/IP body. 5.2.2.3.3 Protocol version The protocol version information states the revision of the KNXnet/IP protocol that the following KNXnet/IP frame is subject to. It will be stored in binary coded decimal format. The only valid protocol version at this time is 1.0 (represented as hexadecimal 10h). 5.2.2.3.4 KNXnet/IP service The KNXnet/IP service type identifier defines the kind of action to be performed and the type of the data payload contained in the KNXnet/IP body if applicable. The high octet of the KNXnet/IP service type identifier denotes the service type family and the low octet the actual service type in that family. For a detailed description of the services, see below. SIST EN 13321-2:2013

Figure 4 — KNXnet/IP server endpoints sample configuration The control endpoint uniquely addresses one entity inside the KNXnet/IP server device that shall be capable of providing at least one KNXnet/IP service type. This entity, called service container, may be connected to a KNX Subnetwork. If the KNXnet/IP server device supports more than one KNX Subnetwork connection, it is REQUIRED that every KNX Subnetwork shall be SIST EN 13321-2:2013

Figure 5 — Discovery procedure SIST EN 13321-2:2013
...