EN 62379-5-2:2014

Common control interface for networked digital audio and video products - Part 5-2: Transmission over networks - Signalling (TA4)

IEC 62379-5-2:2014(E) specifies protocols which can be used between networking equipment to enable the setting up of calls which are routed across different networking technologies. It also specifies encapsulation of digital media within those calls.

Gemeinsame Steuerschnittstelle für netzwerkbetriebene digitale Audio- und Videogeräte - Teil 5-2: Übertragung über Netzwerke - Signalisierung

Interface de contrôle commune pour produits audio et vidéo numériques en réseau - Partie 5-2: Transmission sur les réseaux - Signalisation (TA4)

L'IEC 62379-5-2:2014 spécifie les protocoles qui peuvent être utilisés entre les équipements de mise en réseau pour permettre l'établissement d'appels acheminés sur des technologies de mise en réseau différentes. Elle spécifie également l'encapsulation des supports numériques dans ces appels.

Skupni krmilni vmesnik za digitalne avdio in video izdelke, vključene v omrežje - 5-2. del: Prenos po omrežjih - Signalizacija (IEC 62379-5-2:2014)

Standard EN IEC 62379-5-2 določa protokole, prek katerih je mogoče v omrežni opremi nastavljati klice, ki se usmerjajo prek različnih omrežnih tehnologij. Določa tudi enkapsulacijo digitalnih medijev v teh klicih.

General Information

• Status: Published
• Publication Date: 15-May-2014
• Withdrawal Date: 10-Apr-2017
• ICS: 33.160 - Audio, video and audiovisual engineering
• ICS: 35.100 - Open systems interconnection (OSI)
• Technical Committee: CLC/TC 100X - Audio, video and multimedia systems and equipment and related sub-systems
• Drafting Committee: IEC/TC 100 - IEC_TC_100
• Current Stage: 6060 - Document made available - Publishing
• Start Date: 16-May-2014
• Completion Date: 16-May-2014
• Ref Project: SIST EN 62379-5-2:2014 - Common control interface for networked digital audio and video products -- Part 5-2: Transmission over networks - Signalling (IEC 62379-5-2:2014)

Standards Content (Sample)

SLOVENSKI STANDARD
01-oktober-2014
6NXSQLNUPLOQLYPHVQLN]DGLJLWDOQHDYGLRLQYLGHRL]GHONHYNOMXþHQHYRPUHåMH
GHO3UHQRVSRRPUHåMLK6LJQDOL]DFLMD,(&
Common control interface for networked digital audio and video products -- Part 5-2:
Transmission over networks - Signalling (IEC 62379-5-2:2014)
Gemeinsame Steuerschnittstelle für netzwerkbetriebene digitale Audio- und Videogeräte
- Teil 5-2: Übertragung über Netzwerke - Signalisierung (IEC 62379-5-2:2014)
Interface de contrôle commune pour produits audio et vidéo numériques en réseau -
Partie 5-2: Transmission sur les réseaux - Signalisation (TA4) (CEI 62379-5-2:2014)
Ta slovenski standard je istoveten z: EN 62379-5-2:2014
ICS:
33.160.01 Avdio, video in avdiovizualni Audio, video and audiovisual
sistemi na splošno systems in general
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 62379-5-2

NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2014
ICS 33.160; 35.100
English Version
Common control interface for networked digital audio and video
products - Part 5-2: Transmission over networks - Signalling
(TA4)
(IEC 62379-5-2:2014)
Interface de contrôle commune pour produits audio et vidéo Gemeinsame Steuerschnittstelle für netzwerkbetriebene
numériques en réseau - Partie 5-2: Transmission sur les digitale Audio- und Videogeräte - Teil 5-2: Übertragung über
réseaux - Signalisation (TA4) Netzwerke - Signalisierung
(CEI 62379-5-2:2014) (IEC 62379-5-2:2014)
This European Standard was approved by CENELEC on 2014-04-11. CENELEC 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 CENELEC 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 CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 62379-5-2:2014 E
Foreword
The text of document 100/2050/CDV, future edition 1 of IEC 62379-5-2, prepared by IEC/TC 100, "Audio,
video and multimedia systems and equipment" was submitted to the IEC-CENELEC parallel vote and
approved by CENELEC as EN 62379-5-2:2014.
The following dates are fixed:
• latest date by which the document has (dop) 2015-01-11
to be implemented at national level by
publication of an identical national
standard or by endorsement
(dow) 2017-04-11
• latest date by which the national
standards conflicting with the
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such patent
rights.
Endorsement notice
The text of the International Standard IEC 62379-5-2:2014 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards indicated:
IEC 60958-4 NOTE Harmonised as EN 60958-4.
IEC 61883 (Series) NOTE Harmonised as EN 61883 (Series).
IEC 61937 (Series) NOTE Harmonised as EN 61937 (Series).

- 3 - EN 62379-5-2:2014
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant EN/HD

applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu
Publication Year Title EN/HD Year
IEC 60958 -  Digital audio interface EN 60958 -
IEC 62365 2009 Digital audio - Digital input-output interfacing EN 62365 2009
- Transmission of digital audio over
asynchronous transfer mode (ATM)
networks
IEC 62379 series Common control interface for networked EN 62379 series
digital audio and video products
IEC 62379-2 2008 Common control interface for networked EN 62379-2 2009
digital audio and video products -- Part 2:
Audio
IEC 62379-5-1 -  Common control interface for networked FprEN 62379-5-1 -
digital audio and video products -- Part 5-1:
Transmission over networks - General
AES53 -  AES standard for digital audio - Digital input-- -
output interfacing - Sample-accurate timing
in AES47
ITU-T -  Usage of cause and location in the Digital - -
recommendation Subscriber Signalling System No. 1 and the
Q.850 Signalling System No. 7 ISDN user part

IEC 62379-5-2 ®
Edition 1.0 2014-03
INTERNATIONAL
STANDARD
Common control interface for networked digital audio and video products –

Part 5-2: Transmission over networks – Signalling

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XA
ICS 33.160; 35.100 ISBN 978-2-8322-1455-8

– 2 – IEC 62379-5-2:2014 © IEC 2014
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 Identification . 10
4.1 Byte order . 10
4.2 Unit identification . 10
4.3 Flow identifiers . 10
4.4 Address format . 11
5 Message format . 12
5.1 General . 12
5.2 Header . 13
5.3 Variable part . 14
5.3.1 General . 14
5.3.2 Information element format . 14
5.3.3 Order of occurrence of information elements . 15
5.4 Data formats . 16
5.5 Contents of fixed and variable parts . 16
5.5.1 FindRoute messages . 16
5.5.2 ClearDown messages . 16
5.5.3 AddFlow messages . 16
5.5.4 NetworkData and EndToEndData messages . 16
5.5.5 AsyncSetup messages . 17
5.5.6 Extended message types . 17
5.6 Information element types . 17
5.6.1 Coding of “type” field . 17
5.6.2 Called address . 18
5.6.3 Flow descriptor . 18
5.6.4 Data format or protocol . 19
5.6.5 Start time. 19
5.6.6 End time . 19
5.6.7 Call importance . 19
5.6.8 Service (or programme) name . 19
5.6.9 Source name . 19
5.6.10 Destination name. 20
5.6.11 Privilege level . 20
5.6.12 Password . 20
5.6.13 Charge for call . 20
5.6.14 Calling address. 20
5.6.15 Route metric . 20
5.6.16 Synchronous service parameters . 21
5.6.17 Asynchronous service parameters . 21
5.6.18 Link-specific resource allocations . 22
5.6.19 End-to-end delay . 22

IEC 62379-5-2:2014 © IEC 2014 – 3 –
5.6.20 Route identifier of multicast . 22
5.6.21 Cause . 23
5.6.22 Route and flow selection. 23
5.6.23 Alternatives . 23
5.6.24 Group . 23
5.6.25 Interim offer . 24
5.6.26 Path MTU . 24
5.6.27 Number of destinations . 25
5.6.28 Selector for an individual destination . 25
5.6.29 User data . 25
5.6.30 Extended IE types . 25
6 Protocols . 26
6.1 General . 26
6.2 Establishing a route . 27
6.2.1 Connection of flows . 27
6.2.2 Request message . 27
6.2.3 Action on receiving a FindRoute request . 29
6.2.4 Action on receiving on a FindRoute response . 31
6.2.5 Passing on a FindRoute confirmation . 33
6.2.6 Action of the responder on receiving a FindRoute confirmation . 33
6.2.7 FindRoute completion message . 33
6.3 Disconnection of routes and flows . 34
6.3.1 General . 34
6.3.2 ClearDown request message . 34
6.3.3 Action on receiving a ClearDown request message. 35
6.4 Adding new flows to an existing route . 35
6.5 Information messages related to a route . 35
6.5.1 General . 35
6.5.2 Notification of the number of destinations . 36
6.5.3 Changing service parameters . 36
6.5.4 Out-of-band data . 36
6.6 Quasi-connectionless service . 36
6.6.1 General . 36
6.6.2 Request message . 36
6.6.3 Action on receiving request . 37
7 Media formats . 37
7.1 Identification. 37
7.2 Packet data . 37
7.2.1 General packet data . 37
7.2.2 Other packet formats . 38
7.3 Pulse-code modulated audio . 38
7.3.1 Rationale . 38
7.3.2 Sequencing octet . 38
7.3.3 Subframe format . 39
7.3.4 Frame format . 39
7.3.5 Transport . 40
7.3.6 Signalling of format. 40
8 Cause codes . 42
8.1 ITU-T standard cause codes . 42

– 4 – IEC 62379-5-2:2014 © IEC 2014
8.2 Other cause codes . 42
Annex A (informative) Background . 43
Bibliography . 52

Figure 1 – Structure of flow identifier . 10
Figure 2 – Signalling message format . 13
Figure 3 – Signalling message header . 13
Figure 4 – Information element header. 15
Figure 5 – Information element with a nonempty fixed part and a variable part. 15
Figure 6 – Fixed part of FlowDescriptor IE . 18
Figure 7 – Fixed part of multicast route identifier IE . 22
Figure 8 – Sequencing octet . 38
Figure 9 – “Short” bit string value . 38
Figure 10 – “Long” bit string value . 39

Table 1 – Address type codes . 12
Table 2 – Message class . 13
Table 3 – Message type . 14
Table 4 – Information element types . 17

IEC 62379-5-2:2014 © IEC 2014 – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
COMMON CONTROL INTERFACE FOR NETWORKED
DIGITAL AUDIO AND VIDEO PRODUCTS –

Part 5-2: Transmission over networks –
Signalling
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 itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
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.
International Standard IEC 62379-5-2 has been prepared by technical area 4: Digital system
interfaces and protocols of IEC technical committee 100: Audio, video and multimedia
systems and equipment.
The text of this standard is based on the following documents:
CDV Report on voting
100/2050/CDV 100/2158/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
A list of all parts in the IEC 62379 series, published under the general title Common control
interface for networked digital audio and video products, can be found on the IEC website.

– 6 – IEC 62379-5-2:2014 © IEC 2014
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IEC 62379-5-2:2014 © IEC 2014 – 7 –
INTRODUCTION
IEC 62379 specifies the Common Control Interface, a protocol for managing networked
audiovisual equipment. The following parts exist or are planned:
1 General
2 Audio
3 Video
4 Data
5 Transmission over networks
6 Packet transfer service
7 Measurement
IEC 62379-1:2007 specifies aspects which are common to all equipment, and it includes an
introduction to the Common Control Interface.
IEC 62379-2:2008, IEC 62379-3 (under consideration) and IEC 62379-4 (under consideration)
specify control of internal functions specific to equipment carrying particular types of live
media. IEC 62379-4 refers to time-critical data such as commands to automation equipment,
but not to packet data such as the control messages themselves.
IEC 62379-5 specifies control of transmission of these media over each individual network
technology. It includes network specific management interfaces along with network specific
control elements that integrate into the control framework.
IEC 62379-5-1 specifies management of aspects which are common to all network
technologies. IEC 62379-5-3 onwards specify management of aspects which are particular to
individual networking technologies.
IEC 62379-5-2 (this standard) specifies protocols which can be used between networking
equipment to enable the setting up of calls which are routed across different networking
technologies.
IEC 62379-6 specifies carriage of control and status messages and non-audiovisual data over
transports that do not support audio and video, such as RS232 serial links, with (as for
IEC 62379-5) a separate subpart for each technology.
IEC 62379-7 specifies aspects that are specific to the measurement of the service
experienced by audio and video streams and in particular to the requirements of EBU ECN-
IPM Measurements Group.
– 8 – IEC 62379-5-2:2014 © IEC 2014
COMMON CONTROL INTERFACE FOR NETWORKED
DIGITAL AUDIO AND VIDEO PRODUCTS –

Part 5-2: Transmission over networks –
Signalling
1 Scope
This part of IEC 62379 specifies protocols which can be used between networking equipment
to enable the setting up of calls which are routed across different networking technologies.
It also specifies encapsulation of digital media within those calls.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 60958 (all parts), Digital audio interface
IEC 62365:2009, Digital audio – Digital input-output interfacing – Transmission of digital
audio over asynchronous transfer mode (ATM) networks
IEC 62379 (all parts), Common control interface for networked digital audio and video
products
IEC 62379-1, Common control interface for networked digital audio and video products –
Part 1: General
IEC 62379-2:2008, Common control interface for networked digital audio and video
products – Part 2: Audio
IEC 62379-5-1, Common control interface for networked digital audio and video products –
Part 5-1: Transmission over networks – General
ITU-T Recommendation Q.850, Usage of cause and location in the digital subscriber
signalling system No. 1 and the signalling system No.7 ISDN used part
AES53, AES standard for digital audio – Digital input-output interfacing – Sample-accurate
timing in AES47 (Audio Engineering Society, New York, NY, USA)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62379-1 and the
following apply.
________________
To be published.
IEC 62379-5-2:2014 © IEC 2014 – 9 –
3.1
adjacent
such that data can be sent from one to the other without passing
through any other network element
3.2
asynchronous flow
flow consisting of data units for which the time of arrival at the destination is less important
3.3
asynchronous service
best-effort point-to-point service carrying asynchronous flows
3.4
call identifier
first 12 octets of a flow identifier
Note 1 to entry: See 4.3.
3.5
connectionless data unit
data unit which is not part of a flow
3.6
data unit
sequence of one or more octets which is conveyed across the network as a single unit
3.7
end equipment
equipment that is connected to the network and produces or consumes data units
3.8
extended unique identifier
EUI-64
64-bit globally unique identifier, the first 24 or 36 bits of which are an organizationally unique
identifier (OUI) administered by the Institute of Electrical and Electronics Engineers (IEEE)
Note 1 to entry: The extended unique identifier contains 64 bit.
3.9
flow
sequence of data units
3.10
information element
IE
element of a message, in tag-length-value format
3.11
link
means by which data units are conveyed between adjacent network elements
3.12
network delay
time from submission of a data unit to the network by the sender to its delivery to the recipient

– 10 – IEC 62379-5-2:2014 © IEC 2014
3.13
network element
piece of equipment which takes part in the process of conveying data and conforms to this
Standard
EXAMPLES: Switches, gateways, and interfaces, but not equipment internal to legacy networks.
3.14
path
sequence of links
3.15
route
path from source to destination of a flow
3.16
route identifier
first 13 octets of a flow identifier (see 4.3), excluding the least significant bit of the 13th octet
3.17
synchronous flow
flow for which the network delay experienced by data units is required to be within specified
limits
Note 1 to entry: The size of the units, and also the rate at which units are transmitted, may be fixed or may be
variable with a defined upper limit.
3.18
synchronous service
one-to-many service carrying synchronous flows
4 Identification
4.1 Byte order
All multiple-octet quantities shall be coded with the most significant octet first.
4.2 Unit identification
Each switch or end equipment unit shall have assigned to it a globally unique EUI-64.
NOTE The EUI-64 can be derived from the MAC address of one of the unit’s interfaces by concatenating the first
three octets of the MAC address, hexadecimal FFFE, and the last three octets of the MAC address.
4.3 Flow identifiers
Each flow shall be identified by a 16-octet value formatted as shown in Figure 1.
IEC  0916/14
Figure 1 – Structure of flow identifier

IEC 62379-5-2:2014 © IEC 2014 – 11 –
The first 8 octets shall contain an EUI-64 identifying the unit which created the flow identifier.
This unit is referred to in this standard as the “owner” of the flow identifier.
The next 4 octets shall contain a nonzero reference number, chosen by the owner, identifying
the call of which the flow is a part. Call references should be chosen in a way that maximises
the time from when a call ceases to exist until its reference is re-used for a new call.
The next octet shall contain, in its most significant seven bits, a nonzero reference number,
chosen by the owner and unique within the call, selecting the route followed by the flow; and,
in its least significant bit, a “direction” indicator which shall be 0 for a flow in the direction
away from the owner and 1 for a flow in the direction towards it.
The remaining 3 octets shall contain a nonzero reference number, chosen by the owner,
identifying the flow uniquely within the call. Where a pair of flows in opposite directions
carries a two-way protocol such as TCP, the same flow reference value shall be used for each
of them.
NOTE 1 The call reference distinguishes between different calls with the same owner. A call may be connected
over several different routes (for instance, to give resilience in the event of failure) and the route reference
distinguishes between them. The flow reference distinguishes between different flows within a call; for instance, a
single call may carry video, programme audio, and talkback, and each of these streams will have its own flow
reference.
NOTE 2 The flow reference is orthogonal to the route reference, so flows carrying the same content over different
routes have the same flow reference, and flows carrying different content have different flow references even if
they do not follow the same route. Different routes may carry different sets of flows, for instance a backup route
might only carry the most important flows, or different kinds of flow may have different backup routes.
Zero in the route reference field shall indicate all routes for the call. Except where specified
otherwise (e.g. in 5.6.3), zero in the "direction" bit and the flow reference field shall indicate
all flows for the route(s), and zero in the flow reference with 1 in the "direction" bit is reserved.
NOTE 3 These identifiers are the same at all points in the system and there is just one set of call reference
values for each owner. This contrasts with call references in ITU-T Recommendation Q.2931 where a call has a
different reference on every link, and a switch can use the same call reference for different calls as long as they
are on different links. See also Clause A.4.
In the case of a unicast call, the owner shall be the caller. In the case of a multicast, the
owner shall be the sender or, in the case where for resilience the same content is transmitted
by more than one unit, one of the senders. A caller wishing to join a multicast shall use a
temporary call identifier (which it owns) until the identifier of the multicast (which may need to
be created by the sender) has been discovered.
4.4 Address format
An address shall be represented as an octet string formatted as specified below.
NOTE It is thus a valid TAddress value (unless it is more than 255 o long).
The TDomain value identifying an address in the form specified in this subclause shall be
{ iso(1) standard(0) iec62379 network(5) signalling(2) address_format(2) }
The first octet of the address shall contain a “type” code; the format and interpretation of the
remainder shall depend on the type and on the length of the octet string, as specified in
Table 1.
– 12 – IEC 62379-5-2:2014 © IEC 2014
Table 1 – Address type codes
Type Remainder of octet string
0 second octet contains n, third to (n+2)th inclusive are an address (which shall not be of type 0) which
acts as the locator, remainder is another address (the “local” address, which may be of type 0), which
a
is to be interpreted at the specified location
b, c, d
second octet contains n, third to (n+2)th inclusive are an OID, remainder is a value
b, c, e
2 second octet contains n, third to (n+2)th inclusive are an OID, remainder is a value
second octet contains n, third to (n+2)th inclusive are a TDomain value (which is an OID), remainder
b, f
is an address within that domain
4 IPv4 address if 4 octets, subnet address followed by subnet mask if 8 o
5 EUI-64 identifier
6 IPv6 address
7 URL
8 1 o containing a protocol identifier (as in IP headers, e.g. 6 for TCP and 17 for UDP) followed by a
port number for the indicated protocol coded in 2 o as a 16-bit unsigned integer
9 IEC 62379 block identifier
10 service name coded as a UTF8 string
11 NetBIOS unique name
12 NetBIOS group name
13 NSAP address (20 o) or prefix
14 E.164 address
15-255 reserved
a
In the case of type 0, the locator may be the address of a gateway, or some other identification of a
subnetwork (such as an NSAP prefix or an IPv4 subnetwork address). It may also identify end equipment.
The locator is not allowed to be a type 0 address so that the sequence of locations will be “flat” rather than
nested.
b
The OID in types 1-3 is coded in the same way as in ASN.1 Basic Encoding Rules (BER), including the
compressed form for the first two arcs, but omitting the tag and length. These address types should only be
used for address formats that cannot be supported by any of the other types. An IPv4 address, for instance,
should use type 4 although it could also be expressed as a type 3 address or, if the target unit’s MIB
includes its IP address, as a type 1. An IPv4 address with a port number should be type 0, with a type 4
locator and a type 8 local address.
c
The value which follows the OID in types 1-2 is coded using ASN.1 Basic Encoding Rules (BER), including
the tag and length.
d
Type 1 identifies a unit in whose MIB the object identified by the OID (such as unitName or unitLocation) has
the specified value. In the case of scalar objects, the OID may omit the final zero arc. Units are not required
to support all objects in their MIBs that could be used in this context, and switches are not required to
remember any but the most obviously useful for the units connected to them. Objects in IEC 62379 should
be used in preference to those in other MIBs, for instance unitLocation (1.0.62379.1.1.1.2) rather than
sysLocation (1.3.6.1.2.1.1.5).
e
Type 2 identifies a port or other resource within a unit, by searching the unit’s MIB, usually for a columnar
object such as aPortName to select an audio port. The OID omits the index arcs. As with type 1, units are
not required to support all objects in their MIBs that could be used in this context, so a management
terminal which has discovered the port name (e.g. from a status broadcast) should use type 9 instead.
f
For types 3 onwards, the remainder of the value is an octet string containing the address in the appropriate
format. Some codes are only valid in certain contexts, for instance an IEC 62379 block identifier would not
be valid on a subnetwork and a NetBIOS name would only be valid within a subnetwork that supported
NetBIOS protocols.
5 Message format
5.1 General
All signalling messages shall consist of an octet string with the format shown in Figure 2.

IEC 62379-5-2:2014 © IEC 2014 – 13 –

IEC  0917/14
NOTE The header is specified in 5.2 and the variable part in 5.3. The format of the fixed part depends on the
message type, and is specified in 5.5.
Figure 2 – Signalling message format
Encapsulation of the octet string for transmission on a link (see 6.1) depends on the
technology used for the link, and is not specified in this standard. It should not place a
limitation on the maximum length of a message.
5.2 Header
The header of a signalling message shall consist of two octets formatted as shown in Figure 3.
IEC  0918/14
Figure 3 – Signalling message header
The most significant bit of the first octet shall be 1 for an acknowledgement, 0 otherwise. The
next two bits shall code the message class as specified in Table 2. The least significant five
bits shall code the message type as specified in Table 3.
NOTE For the significance of the “acknowledgement” and “message class” fields, see also the definitions of
“original” and “reply”, see 6.1.
The second octet shall contain the number of octets in the fixed part.
Table 2 – Message class
Code Message class
0 request
1 response
2 confirmation
3 completion
– 14 – IEC 62379-5-2:2014 © IEC 2014
Table 3 – Message type
Code Message type
a
0-7 reserved for link management messages
8 FindRoute
9 ClearDown
10 AddFlow
11 NetworkData
12 EndToEndData
13 AsyncSetup
14-15 reserved
a
16-19 reserved for link-specific resource management messages
20-29 reserved
30-31 extended message types: see 5.5.6
a
Message types 0-7 and 16-19 may be used for carrying messages that are
specific to a particular networking technology, on links that use that technology.
Use of such message types should be negotiated when the link is established.
Message types 14-15 and 20-29 may be specified in future versions of this
standard, or in related standards, including for exchanging network topology
information, and should not be used for other purposes.

5.3 Variable part
5.3.1 General
The variable part of a signalling message shall consist of zero or more information elements
(IEs), as specified in 5.3.2, which are referred to in this standard as being directly contained
or its variable part in the message. The first IE shall begin in the octet immediately following
the fixed part of the message, and each subsequent IE shall begin in the octet immediately
following the IE that precedes it.
If the encapsulation of the message does not specify the number of octets it occupies, or the
number of octets is greater than the length of the message, then the octet immediately
following the last IE (or the fixed part if there are no IEs) shall contain zero and any further
octets shall be ignored by the recipient of the message.
NOTE A zero in the IE type field is therefore interpreted as "end of message".
5.3.2 Information element format
Each IE shall begin with a 3-octet header with the format shown in Figure 4.

IEC 62379-5-2:2014 © IEC 2014 – 15 –
IEC  0919/14
Figure 4 – Information element header
The most significant bit of the first octet shall be 1 if the IE includes a variable part,
0 otherwise.
The least significant seven bits of the first octet shall contain the IE type, coded as specified
in 5.6.1.
The next two octets shall contain the number of further octets in the IE.
In the case of an IE with no variable part, the remaining octets shall contain the fixed part.
In the case of an IE with a variable part, the fourth octet shall contain the number of octets in
the fixed part. If this number is nonzero, the fixed part shall begin in the fifth octet and the
variable part shall begin in the octet immediately following the fixed part, as shown in Figure 5.
Otherwise, the variable part shall begin in the fifth octet.
IEC  0920/14
NOTE 1 The format of the fixed part (in either case) depends on the type, and is specified in 5.6.
NOTE 2 If there is a variable part, the fixed part cannot be longer than 255 o, whereas if there is no variable part
the format allows the fixed part to be up to 65 535 o.
Figure 5 – Information element with a nonempty fixed part and a variable part
The variable part of an IE (if present) shall consist of zero or more IEs, which are referred to
in this standard as being “directly contained” in the IE. The first directly contained or its
variable part IE shall begin in the octet immediately following the fixed part, and each
subsequent IE shall begin in the octet immediately following the IE that precedes it.
The length signalled in the IE header shall be exactly equal to the sum of the lengths of the
fixed part
...