EN 13321-2:2006

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Open data communication in building automation, controls and building management - Home and building electronic systems - Part 2: KNXnet/IP CommunicationOdprta izmenjava podatkov v avtomatizaciji stavb in izvršnih elementov ter pri upravljanju stavb - Elektronski sistemi za stanovanja in stavbe - 2. del: KNTnet/IPRéseau ouvert de communication de données pour l'automatisation, la régulation et la gestion technique du bâtiment - Systemes électroniques pour les foyers domestiques et les bâtiments - Partie 2 : Communication KNX/IPOffene Datenkommunikation für die Gebäudeautomation und Gebäudemanagement - Elektrische Systemtechnik für Heim und Gebäude - Teil 2: KNXnet/IP KommunikationTa slovenski standard je istoveten z:EN 13321-2:2006SIST EN 13321-2:2007en97.120Avtomatske krmilne naprave za domAutomatic controls for household use35.240.99IT applications in other fieldsICS:SLOVENSKI
STANDARDSIST EN 13321-2:200701-februar-2007

EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 13321-2October 2006ICS 35.240.99; 97.120Supersedes ENV 13321-2:2000
English VersionOpen data communication in building automation, controls andbuilding management - Home and building electronic systems -Part 2: KNXnet/IP CommunicationRéseau ouvert de communication de données pourl'automatisation, la régulation et la gestion technique dubâtiment - Systèmes électroniques pour les foyersdomestiques et les bâtiments - Partie 2 : CommunicationKNX/IPOffene Datenkommunikation für die Gebäudeautomationund Gebäudemanagement - Elektrische Systemtechnik fürHeim und Gebäude - Teil 2: KNXnet/IP KommunikationThis European Standard was approved by CEN on 28 August 2006.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the Central Secretariat or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the officialversions.CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2006 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 13321-2:2006: E

This document also supersedes parts BatiBUS, EHS and EIB of ENV 13154-1:1998.
Whereas ENV 13321-2:2000 described the transmission of EIB packets over Ethernet including the frame encoding this document describes the transmission of HBES packets using the Internet Protocol. Details of the HBES packet frames are covered in EN 13321-1, [9] Open Data Communication in Building Automation, Controls and Building Management — Home and Building Electronic Systems — Part 1: Product and System Requirements, removing the need to explicitly describe the HBES frames in this document.
This document is part 2 of the EN 13321 series of European Standards under the general title Open data communication in building automation, controls and building management - Home and building electronic systems, which will comprise the following parts:
Part 1: Product and system requirements
Part 2: KNXnet/IP communication
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

• The KNXnet/IP specification consists of these clauses:  Clause 1, Overview  Clause 2, Core Specification  Clause 3, Device Management  Clause 4, Tunnelling  Clause 5, Routing Additional clauses may be added to the KNXnet/IP specification in the future at which time Clause 1 “Overview” as well as Annex A shall be updated. KNXnet/IP supports different software implementations on top of the protocol. 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 cost 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 [11] 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.

 Configuring and establishing a communication channel between a KNXnet/IP client and a KNXnet/IP server Clause 3, Device Management Clause 3 “Device Management” defines services for remote configuration and remote management of KNXnet/IP servers. Clause 4, Tunneling Clause 4 “Tunnelling” defines services supporting all ETS functions for download, test, and analysis of KNX devices on KNX networks connected via KNXnet/IP servers. This includes changes of single KNX device object properties. Tunnelling assumes that a data transmission round-trip between ETS or any other KNXnet/IP Tunnelling client and KNXnet/IP servers takes less than tKNX_transfer_timeouts. It describes direct communication between ETS and target BCU with single telegrams exchanged between both (like iETS). This mode also allows for change of properties in devices. Clause 5, Routing Clause 5 “Routing” defines services, which route KNX telegrams between KNXnet/IP servers through the IP network.

1 Scope This specification defines the integration of KNX protocol implementations on top of Internet Protocol (IP) networks, called KNXnet/IP. It describes a standard protocol for KNX devices connected to an IP network, called KNXnet/IP devices. The IP network acts as a fast (compared to KNX transmission speed) backbone in KNX installations. • Widespread deployment of data networks using the Internet Protocol (IP) presents an opportunity to expand building control communication beyond the local KNX control bus providing:  Remote configuration  Remote operation (including control and annunciation)  Fast interface from LAN to KNX and vice versa  WAN connection between KNX systems (where an installed KNX system is at least one line) • A KNXnet/IP system contains at least these elements:  one EIB line with up to 64 (255) EIB devices OR one KNX segment (KNX-TP1, KNX-TP0, KNX-RF, KNX-PL110, KNX-PL132),  a KNX-to-IP network connection device (called KNXnet/IP server), and typically additional  software for remote functions residing on e.g. a workstation (may be iETS, data base application, BACnet Building Management System, browser, .). Figure 1 shows a typical scenario where a KNXnet/IP client (e.g. running ETS) accesses multiple KNX installed systems or KNX subnetworks via an IP network. The KNXnet/IP client may access one or more KNXnet/IP servers at a time. For subnetwork routing server-to-server communication is possible.

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". 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) represents the Host Protocol Address Information structure. This structure holds the IP host protocol address information and is used to address a KNXnet/IP endpoint on another KNXnet/IP device

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). A communication channel consists of one or more connections on the definition of the host protocol used for KNXnet/IP 3.5
KNX node KNX node is considered to be any device that implements a KNX protocol stack and fulfils the requirements for certification according to the KNX standard 3.6
KNXnet/IP server KNX device that has physical access to a KNX network and implements the KNXnet/IP server protocol to communicate with KNXnet/IP clients or other KNXnet/IP servers (in case of routing) on an IP network channel. A KNXnet/IP server is by design always also a KNX node 3.7
KNXnet/IP client application that implements the KNXnet/IP client protocol to get access to a KNX subnetwork over an IP network channel 3.8
KNXnet/IP devices all KNX devices are either a KNX or a KNXnet/IP node 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) TTL (Time To Live) of a multicast UDP/IP datagram is the maximum number of IP routers that may route this datagram. Each IP router the datagram passes decrements the TTL by one; the local host adapter does this as well. 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 Tunneling refers to the encapsulation of cEMI (common EMI) frames within Internet Protocol (IP) packets

Internet Control Message Protocol (ICMP) extension to the Internet Protocol (IP) defined by RFC1) 792. ICMP 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) 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. The mechanisms of the protocol allow a host to inform its local router, using Host Membership Reports, that it wants to receive messages addressed to a specific multicast group.
All hosts conforming to level 2 of the IP multicasting specification require IGMP 3.14
IP channel logical connection between two IP host/port endpoints. 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 communication channel as defined by the KNXnet/IP Core specification is represented by one or two IP channels
4 Symbols, abbreviations and acronyms For the purposes of this document, the symbols, abbreviations and acronyms used are listed below. 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) 4.4 IP Internet Protocol
1) Request for Comment: Internet Standards defined by the Internet Engineering Task Force (IETF) are firstly published as RFCs.

5 Requirements 5.1 Clause 1: Overview 5.1.1 KNXnet/IP Document Clauses 5.1.1.1 General This standard defines the integration of KNX protocol implementations within the Internet Protocol (IP) named KNXnet/IP or EIBnet/IP for continuity with ENV 13321-2:2000 (EIBnet) as defined by CEN/ TC 247. EIBnet was introduced as an expansion of EIB into the information technology realm and was incorporated as a building controls technology in CEN/TC 247. EIBnet/IP is the logical successor to EIBnet. As EIB has become a part of KNX, this standard is called KNXnet/IP. This specification defines a standard protocol, which is implemented within KNX devices, the EIB Tool Software Next Generation (ETS NG) and other implementations to support KNX data exchange over IP networks. In fact, KNXnet/IP provides a general framework, which accommodates several specialized “Service Protocols” in a modular and extendible fashion. • The KNXnet/IP specification consists of these clauses:  Clause 1, Overview;  Clause 2, Core Specification;  Clause 3, Device Management ;  Clause 4, Tunnelling ;  Clause 5, Routing. Additional clauses may be added to the KNXnet/IP specification in the future at which time this Clause 1 “Overview” shall be updated. KNXnet/IP supports different software implementations on top of the protocol. 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 cost 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).

(e.g. network connection via satellite). 5.1.1.2 Clause 1, Overview Clause 1 “Overview” is this document. 5.1.1.3 Clause 2, Core specification Clause 2 “Core Specification” defines a standard protocol, which is implemented within KNXnet/IP devices and the EIB Tool Software Next Generation (ETS NG) to support KNX data exchange over IP networks. This specific implementation of the protocol over the Internet Protocol (IP) is called KNXnet/IP. This specification addresses:  Definition of data packets sent over the IP host protocol network for KNXnet/IP communication;  Discovery and self-description of KNXnet/IP servers;
 Configuring and establishing a communication channel between a KNXnet/IP client and a KNXnet/IP server; 5.1.1.4 Clause 3, Device Management Clause 3 “Device Management” defines services for remote configuration and remote management of KNXnet/IP servers. 5.1.1.5 Clause 4, Tunneling Clause 4 “Tunnelling” defines services supporting all ETS functions for download, test, and analysis of KNX devices on KNX networks connected via KNXnet/IP servers. This includes changes of single KNX device object properties. Tunnelling assumes that a data transmission round-trip between ETS or any other KNXnet/IP Tunnelling client and KNXnet/IP servers takes less than tKNX_transfer_timeouts. It describes direct communication between ETS and target BCU with single telegrams exchanged between both (like iETS). This mode also allows for change of properties in devices. 5.1.1.6 Clause 5, Routing Clause 5 “Routing” defines services, which route KNX telegrams between KNXnet/IP servers through the IP network. 5.1.2 Mandatory and optional implementation of IP protocols 5.1.2.1 General KNXnet/IP uses existing IP protocols where possible unless their use implies an undue burden with regards to memory and implementation requirements for the intended service.

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 specification 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 specification does not require any specific medium carrying the IP datagrams. It is RECOMMENDED to use a medium, which carries at least twice the bit rate of all KNXnet/IP routers connected to this medium. For a point-to-point, e.g. PPP, connection this would be at least 19,200 bit/s, for a network with up to 400 KNXnet/IP servers this would be least 8 Mbit/s.
2) BootP / DHCP: It is essential that either one be implemented by an EIBnet/IP device.

5.1.3 Security considerations 5.1.3.1 Introduction For EIB and subsequently KNX, security was and is a minor concern, as any breach of security requires local access to the network. In the case of KNX TP1 (EIB), KNX TP0, KNX PL* networks this requires even physical access to the network wires, which in nearly all cases is impossible as the wires are inside a building or buried underground.

Passive attacks are difficult to detect, since they do not modify the network traffic in any way.
The primary defence against passive attacks is isolation of network traffic (one cannot eavesdrop or analyse traffic that one cannot see).  Eavesdropping – interception and examination of packet contents by unauthorized third parties. In addition to network isolation, this threat can be countered by encrypting packets.  Traffic analysis – interception and analysis of traffic characteristics without examining the contents of individual packets.
This threat exists even if packets are encrypted, and it is very difficult to counter except by isolation of network traffic. 5.1.3.2.3 Active attacks Active attacks involve some type of modification to network traffic:
adding, deleting, or delaying packets, or changing the contents of packets in some way.  Masquerade – unauthorized entities forging traffic to make it appear to originate from a legitimate source.
This threat can be countered by authentication mechanisms.  Access control violation – a user accesses a resource that it does not have proper authorization to use.
This threat can be countered by message integrity, authentication, and authorization mechanisms (the access control policies shall also be secured).  Modification – intercepting and changing the contents of packets on the network.
This threat can be countered by message integrity mechanisms.  Deletion – preventing packets from arriving at their intended destination (for example, by maliciously configuring a router to drop packets or by deliberately interfering with packet transmissions on the wire).
This threat can be very difficult to counter, especially if the attacker can jam packet transmissions on the physical network.  Delay – delaying arrival of packets at their intended destination.
This attack can be achieved by compromising or overloading a router or bridge or by performing a time-limited attack on the packet transmission (thereby causing retransmission delays).
This threat is also very difficult to counter.  Replay – intercepting packets and later resending them on the network.
This threat can be countered by authentication, message integrity, and timestamps or message counters.  Denial of service – this type of attack typically involves injecting a flood of useless traffic on the network to consume resources such as bandwidth or processing time so that the resources are unavailable to service legitimate traffic.
This threat is difficult to counter, especially if the attack traffic cannot be easily distinguished from legitimate traffic.

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. It is quite unlikely that legitimate users of a network would have the means to intercept, decipher, and then tamper with the KNXnet/IP without excessive study of the EIB Developers Handbook / KNX specifications. Thus the remaining security threat is considered to be very low and does not justify mandating encryption, which would require considerable computing resources.
5.2 Clause 2: Core 5.2.1 Scope This Clause “Core” of the KNXnet/IP specification provides a general host protocol-independent framework, which accommodates several specialized “Service Protocols” in a modular and extendible fashion.
...