IEC 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 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.

Interface de commande commune pour produits audio et vidéo numériques connectés en réseaux - Partie 5-2: Transmission sur des réseaux - Signalisation

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.

General Information

• Status: Published
• Publication Date: 06-Mar-2014
• ICS: 33.160.01 - Audio, video and audiovisual systems in general
• ICS: 35.100.05 - Multilayer applications
• Technical Committee: TC 100 - Audio, video and multimedia systems and equipment
• Drafting Committee: MT 62379-1 - TC 100/TA 4/MT 62379-1
• Current Stage: PPUB - Publication issued
• Start Date: 15-Jul-2014
• Completion Date: 07-Mar-2014

Overview

IEC 62379-5-2:2014 - Common control interface for networked digital audio and video products (Part 5-2: Transmission over networks – Signalling) defines signalling protocols and message structures used to set up, manage and tear down “calls” that carry encapsulated digital media across heterogeneous networks. The standard addresses control-plane elements needed for interoperable transmission of audio and video flows between networked devices, and specifies how digital media is encapsulated within those calls.

Key topics and technical requirements

• Message and header formats - standardized signalling message structure, header fields and byte order to ensure interoperable parsing.
• Identification and addressing - unit identification, flow identifiers and address formats for routing media between endpoints.
• Information elements (IEs) - fixed and variable IE formats, types and ordering (e.g., called address, flow descriptor, data format, start/end time).
• Signalling procedures - protocols to establish routes and flows (FindRoute, AddFlow), disconnect (ClearDown), and manage mid-call information and resource changes.
• Media and encapsulation formats - definitions for packet data and pulse-code modulated (PCM) audio transport, sequencing and subframe/frame formats to carry digital audio/video within calls.
• Quality and control parameters - route metrics, end-to-end delay, path MTU, privilege/charge/cause codes for management and billing.
• Quasi‑connectionless and asynchronous modes - support for different transport behaviours and out-of-band data.
• Cause codes and diagnostics - standardized cause codes (including ITU‑T codes) for error reporting and interoperability troubleshooting.

Practical applications

• Implementing vendor-neutral signalling stacks for AV-over-IP products to enable multi-vendor interoperability.
• Designing networked audio/video equipment (encoders, decoders, mixers, gateways) that need standardized control-plane messaging for call setup and media encapsulation.
• Building broadcast and live-production networks that require predictable call routing, flow control and end-to-end media transport semantics.
• Integrating system-level control and monitoring tools that consume signalling IEs to display route state, QoS metrics and call diagnostics.

Who should use this standard

• AV equipment manufacturers, firmware and software developers
• System integrators and network architects for broadcast, conferencing and public address
• Test and certification labs validating interoperability of networked digital media products

Related standards

• IEC 62379 series (other parts of the Common Control Interface) - for broader device control and management topics.
• ITU‑T cause codes referenced in the document for standardized error reporting.

IEC 62379-5-2 is essential for anyone implementing or integrating signalling and media encapsulation for reliable, interoperable networked audio and video transport.

Standards Content (Sample)

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

All rights reserved. Unless otherwise specified, 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
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: [phone]
3, rue de Varembé Fax: [phone]
CH-1211 Geneva 20 [e-mail]
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: [e-mail].
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

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

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.

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.
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

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  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  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 and all the contained IEs.
5.3.3 Order of occurrence of information elements
An IE is “contained” in an IE or message if it is either directly contained in it or directly
contained in another IE which is, in turn, contained in it.
An IE is “indirectly contained” in an IE or message if it is contained, but not directly contained,
in it.
IEs of the same type that are directly contained within the same variable part shall be grouped
together, i.e. there shall not be any directly contained IEs of a different type occurring
between any two of them.
NOTE 1 This provision allows the recipient of a message to build a table showing the location of each IE type in
the message or in the variable part of an IE, to simplify processing of the message or IE.
NOTE 2 There is no other restriction on the order of occurrence, except where specified in 5.6.23.

– 16 – IEC 62379-5-2:2014 © IEC 2014
5.4 Data formats
Within the fixed part (of a message or an IE), the following conventions as to how various
values will be represented shall apply unless the specification explicitly states otherwise.
• OID: 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.
• RELATIVE OID: coded in the same way as in ASN.1 Basic Encoding Rules (BER),
omitting the tag and length.
• integer: most significant octet first; description shows length and whether signed
or unsigned.
• octet string: verbatim.
• UTF8 string: octet string; terminating NUL is not required and should not be included.
• address: octet string, as specified in 4.4.
NOTE The length of a value is fixed by the context; often it will be in an unsigned integer immediately preceding
the value, or deduced from the length of the fixed part.
5.5 Contents of fixed and variable parts
5.5.1 FindRoute messages
The fixed part of a FindRoute message shall consist of 13 o containing the route identifier for
the route, with the least significant bit of the 13th octet coded as zero.
In messages that are not acknowledgements, the variable part shall contain IEs as specified
in 6.2 for each message class.
In an acknowledgement message, the variable part shall contain a copy of each McastRoute
or InterimOffer IE that was in the original message. There should be no other IEs.
5.5.2 ClearDown messages
The fixed part of a ClearDown request message shall consist of 3 o containing a serial
number chosen by the sender. The recipient shall not attribute any significance to the serial
number. The variable part shall contain IEs as specified in 6.3 for each message class.
The fixed part of the acknowledgement to a ClearDown request message shall consist of 3 o
containing the serial number that was in the original message. The variable part should be
empty.
NOTE The only purpose served by the serial number is to show which message is being acknowledged. The
recipient cannot, for instance, assume that a gap in serial number values means that a message has been lost.
Other classes (i.e. response, confirmation, and completion) shall not be used with the
ClearDown message type.
5.5.3 AddFlow messages
The fixed part of an AddFlow message shall consist of 13 o containing the route identifier for
the route, with the least significant bit of the 13th octet coded as zero. The variable part shall
contain IEs as specified in 6.4.
5.5.4 NetworkData and EndToEndData messages
The fixed part of a NetworkData or EndToEndData message shall consist of 13 o containing
the route identifier for the route, with the least significant bit of the 13th octet coded as zero.

In messages that are not acknowledgements, the variable part shall contain IEs as specified
in 6.5.
In an ac
...

IEC 62379-5-2 ®
Edition 1.0 2014-03
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Common control interface for networked digital audio and video products –
Part 5-2: Transmission over networks – Signalling

Interface de commande commune pour produits audio et vidéo numériques
connectés en réseaux –
Partie 5-2: Transmission sur des réseaux – Signalisation

All rights reserved. Unless otherwise specified, 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
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Central Office Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC online collection - oc.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 000 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 18 additional languages.
once a month by email.
Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer Service
Centre: [e-mail].
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC - IEC online collection - oc.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications IEC gratuitement tous les aperçus des publications. Avec un
en utilisant différents critères (numéro de référence, texte, abonnement, vous aurez toujours accès à un contenu à jour
comité d’études, …). Elle donne aussi des informations sur adapté à vos besoins.
les projets et les publications remplacées ou retirées.

Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
Le premier dictionnaire d'électrotechnologie en ligne au
Restez informé sur les nouvelles publications IEC. Just
monde, avec plus de 22 000 articles terminologiques en
Published détaille les nouvelles publications parues.
anglais et en français, ainsi que les termes équivalents dans
Disponible en ligne et une fois par mois par email.
16 langues additionnelles. Egalement appelé Vocabulaire

Electrotechnique International (IEV) en ligne.
Service Clients - webstore.iec.ch/csc

Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-nous:
[e-mail].
IEC 62379-5-2 ®
Edition 1.0 2014-03
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Common control interface for networked digital audio and video products –

Part 5-2: Transmission over networks – Signalling

Interface de commande commune pour produits audio et vidéo numériques

connectés en réseaux –
Partie 5-2: Transmission sur des réseaux – Signalisation

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.160.01; 35.100.05 ISBN 978-2-8322-1042-2

– 2 – IEC 62379-5-2:2014 © IEC 2014
CONTENTS
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 9
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 . 13
5.1 General . 13
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. 19
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
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 . 23
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 . 32
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. 34
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 . 35
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 . 36
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 . 37
7.3 Pulse-code modulated audio . 37
7.3.1 Rationale . 37
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 . 41
8.1 ITU-T standard cause codes . 41
8.2 Other cause codes . 42
Annex A (informative) Background . 43
A.1 Support for future network (FN) . 43

– 4 – IEC 62379-5-2:2014 © IEC 2014
A.1.1 Rationale . 43
A.1.2 Separation of route-finding from data-forwarding . 43
A.1.3 Mobility and resilience . 43
A.1.4 Addressing . 44
A.1.5 Two classes of service . 44
A.1.6 Negotiation and reporting of QoS parameters and data format . 44
A.2 Structure of the network . 45
A.3 Addressing . 45
A.4 Calls, routes, paths, and flows . 46
A.4.1 Definitions . 46
A.4.2 Identification . 47
A.4.3 Quasi-connectionless flows . 47
A.5 Route finding . 49
A.5.1 General . 49
A.5.2 Additional options . 50
A.5.3 Call to receive a multicast . 50
A.6 Message format . 50
A.7 Media coding and encapsulation. 51

Figure 1 – Structure of flow identifier . 11
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 . 38

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

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.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

– 6 – IEC 62379-5-2:2014 © IEC 2014
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.
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)
________________
To be published.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62379-1 and the
following apply.
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

– 10 – IEC 62379-5-2:2014 © IEC 2014
3.12
network delay
time from submission of a data unit to the network by the sender to its delivery to the recipient
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
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

– 12 – IEC 62379-5-2:2014 © IEC 2014
{ 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.
Table 1 – Address type codes
Type Remainder of octet string
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
second octet contains n, third to (n+2)th inclusive are an OID, remainder is a value
3 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  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  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
...