ISO/IEC 21559-1:2022

Telecommunications and information exchange between systems - Future network protocols and mechanisms - Part 1: Switching and routing

This document specifies protocols and mechanisms for use within systems conforming to the future network (FN) architecture specified in ISO/IEC 21558-1.

Télécommunications et échange d'informations entre systèmes — Futurs protocoles et mécanismes de réseau — Partie 1: Commutation et routage

General Information

• Status: Published
• Publication Date: 28-Feb-2022
• ICS: 35.100.30 - Network layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 6060 - International Standard published
• Start Date: 01-Mar-2022
• Due Date: 06-May-2023
• Completion Date: 01-Mar-2022

Overview

ISO/IEC 21559-1:2022 - "Telecommunications and information exchange between systems - Future network protocols and mechanisms - Part 1: Switching and routing" specifies protocol elements and mechanisms for systems conforming to the Future Network (FN) architecture (see ISO/IEC 21558-1). The standard defines how FN physical and virtual links carry frames and signalling, how flows for audio/video and IT data are handled, and how network synchronization, timing and management are performed across FN deployments.

Key topics

• FN physical links: structure and behavior of physical links that convey sequences of frames, including procedures for negotiating FN operation over legacy physical layers.
• Frame format: mandatory components of an FN frame (including a 4-octet timing field and slots for AV/IT packets) and framing considerations. The timing field encodes time (seconds and nanoseconds) and is compatible with PTP-style timing.
• AV and IT flows: two primary flow types - AV flow for regularly timed media (audio/video, live media) and IT flow for irregular IT traffic - and associated packet/slot handling.
• Link negotiation and establishment: packet formats and state-machine procedures for initiating, accepting, rejecting and managing link establishment and transitions from non-FN to FN frames.
• Virtual links and link management: rules for virtual link creation, error handling and termination within FN systems.
• Network layer synchronization: alignment of frames within islands/clouds, sync domain establishment, link up/down procedures, and signalling messages for sync state and handover.
• Network time: signalling messages and protocols to distribute precise time across FN elements.
• Management of network elements: message formats, status reporting, console data and a Management Information Base (MIB) for call/flow management.
• Implementation guidance: Annex A gives normative guidance for links implemented over 1 Gb/s Ethernet physical layer.

Applications

• Designing and implementing Future Network switching and routing systems that require deterministic media transport, precise timing and robust link negotiation.
• Implementing transport protocols for live audio/video and mixed IT traffic over FN links.
• Integrating FN-capable equipment into heterogeneous environments (e.g., migrating existing Ethernet links to FN frames).
• Developing network element management, MIBs and synchronization services for telecom and media-over-IP products.

Who should use it

• Network architects and protocol designers working on FN-compliant systems
• Telecommunications and broadcast equipment vendors
• System integrators deploying synchronized media transport networks
• Standards bodies and test labs validating FN switching, routing and timing behavior

Related standards (selected)

• ISO/IEC 21558-1 (FN architecture)
• ISO/IEC TR 29181-1 and TR 29181-3 (FN requirements, switching & routing)
• IEC 62379 parts on transmission and signalling
• AES51 (ATM over Ethernet)

Keywords: ISO/IEC 21559-1:2022, Future Network, FN, switching and routing, frame format, AV flow, IT flow, network synchronization, network time, link negotiation, 1GbE, network management.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 21559-1
First edition
2022-03
Telecommunications and information
exchange between systems — Future
network protocols and mechanisms —
Part 1:
Switching and routing
Télécommunications et échange d'informations entre systèmes —
Futurs protocoles et mécanismes de réseau —
Partie 1: Commutation et routage
Reference number
© ISO/IEC 2022
© ISO/IEC 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2022 – All rights reserved

Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 FN physical links . 2
5.1 General . 2
5.2 Frame format . 2
5.2.1 Components of a frame . 2
5.2.2 AV packets . 3
5.2.3 IT data stream . 3
5.3 Negotiation packets . 4
5.3.1 Payload format . 4
5.3.2 Information elements . . 4
5.4 Link establishment procedure . 5
5.4.1 General . 5
5.4.2 Transmission of request . 5
5.4.3 Response to incoming Link Request . 6
5.4.4 Response to incoming Link Reject . 6
5.4.5 Response to incoming Link Accept . 6
5.4.6 Errors and unexpected packets . 6
6 Virtual links . 7
6.1 General . 7
6.2 Transmission of Link Request . . 7
6.3 Response to incoming Link Request . 7
6.4 Response to incoming Link Reject . 7
6.5 Response to incoming Link Accept . 7
6.6 Errors, unexpected packets, and termination . . 8
7 Network layer synchronisation . 8
7.1 General . 8
7.2 Alignment of frames within an island . 8
7.3 Alignment of frames within a cloud . 8
7.4 Establishment of sync domains . 9
7.5 Action on link down . 9
7.6 Procedures . 9
7.6.1 Link up . 9
7.6.2 Link down . 10
7.6.3 SyncInfo signalling messages . 10
7.6.4 State information . 11
7.6.5 Downstream messages . 11
7.6.6 Upstream messages . 11
7.6.7 Handover messages .12
7.6.8 Transition to active state .12
8 Network time .12
8.1 General .12
8.2 Signalling messages .13
8.3 Protocols . 14
9 Management of network elements.14
9.1 Message format and protocol . 14
9.2 Status reporting . 16
iii
© ISO/IEC 2022 – All rights reserved

9.3 Console data . 16
9.4 MIB for call management . 16
Annex A (normative) Links implemented over 1Gb/s Ethernet physical layer .17
Bibliography .22
iv
© ISO/IEC 2022 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.
A list of all parts in the ISO/IEC 21559 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
v
© ISO/IEC 2022 – All rights reserved

Introduction
ISO/IEC TR 29181-1 describes the definition, general concept, problems and requirements for the
Future Network (FN).
ISO/IEC TR 29181-3 examines the requirements for carrying data over digital networks and identifies
those that are not satisfied by the current Internet. It also notes some expected characteristics of new
systems that are better able to satisfy the requirements and specifies a model which supports both
the existing system and the new systems. This will enable a migration to the new systems; it is also
intended to make networks of all sizes easier to manage.
ISO/IEC 21558-1 specifies an architecture which meets the requirements identified in
ISO/IEC TR 29181-3.
vi
© ISO/IEC 2022 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 21559-1:2022(E)
Telecommunications and information exchange between
systems — Future network protocols and mechanisms —
Part 1:
Switching and routing
1 Scope
This document specifies protocols and mechanisms for use within systems conforming to the future
network (FN) architecture specified in ISO/IEC 21558-1.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC/TR 29181-1, Information technology — Future Network — Problem statement and requirements
— Part 1: Overall aspects
ISO/IEC/TR 29181-3, Information technology — Future Network — Problem statement and requirements
— Part 3: Switching and routing
IEC 62379-5-1, Common control interface for networked digital audio and video products - Part 5-1:
Transmission over networks - General
IEC 62379-5-2, Common control interface for networked digital audio and video products – Part 5-2:
Transmission over networks – Signalling
AES51-2006 (s2017), AES standard for digital audio - Digital input-output interfacing - Transmission of
ATM cells over Ethernet physical layer (Audio Engineering Society, New York, NY, USA)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC TR 29181-1 and
ISO/IEC TR 29181-3 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org
3.1
AV flow
flow in which packets are expected to be transmitted at regular intervals, suitable for carrying live
audio, video, and other media
3.2
IT flow
flow in which packets are not expected to be transmitted at regular intervals
© ISO/IEC 2022 – All rights reserved

4 Abbreviated terms
For the purposes of this document, the abbreviations given in ISO/IEC TR 29181-1 and
ISO/IEC TR 29181-3 and the following apply.
AV AudioVisual
CRC Cyclic Redundancy Check
FCS Frame Check Sequence
FN Future Network
IT Information Technology
5 FN physical links
5.1 General
An FN physical link conveys a sequence of frames. There shall be a whole number of frames per
allocation period.
Where an FN physical link is implemented over a physical layer that was developed for another
technology, the link partners may use the negotiation procedure specified in 5.4 to manage the change
from using that technology to sending FN frames. Alternatively, if FN frames are not valid frames for
the other technology, either link partner may begin sending FN frames as soon as the link is established.
Once the link is established, with FN frames being sent in both directions, it can be used to exchange
signalling messages, which shall be used to convey any of the information necessary to set up IT flows
that was not included in a negotiation process (or all such information if there was no negotiation
process), and to align frames as specified in Clause 7.
5.2 Frame format
5.2.1 Components of a frame
General provisions are specified here. Details are specified in Annex A.
Each frame on a physical link shall include:
— timing field (see below);
— slots for AV packets (see 5.2.2 and 5.2.3);
and may also include:
— trailing octets (see 5.2.3).
The timing field shall consist of four octets holding (big-endianly) a 32-bit value. The all-ones value
shall show that no time is indicated. Time (modulo four seconds) shall be coded with seconds in the ms
2 bits and nanoseconds (in the range 0 to 999 999 999 inclusive) in the remaining 30 bits. Other code
points are reserved.
NOTE 1 Coding time as counts of seconds and nanoseconds is compatible with PTP.
The timing field is a “framing” field. There may be other framing fields, e.g. to mark the start of a frame,
to identify its position within the allocation period, or to detect transmission errors. A frame shall not
contain anything that would require the recipient to buffer the data before processing it.
© ISO/IEC 2022 – All rights reserved

For each link, a “word” shall be defined as a whole number of octets. The number shall be strictly
positive and shall be fixed for each format and physical layer.
A slot should consist of 64 octets. Each slot shall be a whole number of words.
The trailing octets (if present) shall be a whole number of words.
NOTE 2 On physical layers where the interface between MAC and PHY is typically 8 bits wide, such as 1Gb/s
Ethernet, the word length can be a single octet. Where typical interfaces are wider, as with 10Gb/s Ethernet, the
word length can match the width of the interface. The word length can be signalled in a framing field or during
negotiation.
5.2.2 AV packets
Each slot shall either contain an AV packet or be an “empty slot”. In the case of a packet, the payload
shall be any number of octets in the range 0 to 63 (inclusive). The header shall consist of one octet
formatted as follows:
— bit 7 (most significant bit): set such that the total number of bits set to 1 in the octet is odd;
— bit 6: flag f;
— bits 5-0: length, coded as the number of payload octets.
The flag f shall not be used for routing, but shall be available for use by the higher layers; if it is used
to guide reassembly of longer messages, it should be set to 0 in the last fragment of a message and 1 in
others.
The frame format may provide for explicit indication of whether a slot is empty; otherwise, an empty
slot shall be coded as a “null packet”, with length zero and f = 1.
NOTE If f is used as specified above, inserting or dropping null packets in a flow will have no effect.
5.2.3 IT data stream
The octets in each slot that are not part of an AV packet (after rounding the size of the packet up to a
whole number of words), together with the trailing octets if present, shall be concatenated in the order
in which they are transmitted to form the “IT data stream”.
NOTE 1 If the packet is not a whole number of words, the unused octets in the last word contain rubbish and
are thus an overhead. Where the word length is more than one octet, this will always occur with zero-length
packets (which use a whole word for one octet of information), so for frames with a longer word length a more
efficient means of identifying empty slots can be useful.
The IT data stream shall carry IT packets and “idle” words. An “idle” word shall be a single word coded
with a value that cannot be the first word of an IT packet header, and shall be transmitted whenever
there is no IT packet available for transmission,
The recipient of an IT data stream shall interpret it according to the following three contexts:
a) Searching: this shall be the initial context when the first frame is received and shall be entered
in the event of any error, including: frame of the wrong length; excessive gap between frames;
parity error in the first octet of a slot; and error in integrity check fields for the frame or an IT
packet header. There shall be a transition to “between packets” context when a sufficient number
of consecutive “idle” words have been received.
NOTE 2 This document does not specify how many is a “sufficient” number. It is a decision for the
implementer.
b) Between packets: in this context either an “idle” word or the start of a packet is expected. An “idle”
word shall be ignored and the context remain as “between packets”. A word that can be the start of
© ISO/IEC 2022 – All rights reserved

an IT packet shall be interpreted as such and “within packet” context entered. Any other code point
should be interpreted as an error, and “searching” context entered.
c) Within packet: each word shall be interpreted as the next word of the packet. After the last word
the context shall revert to “between packets”.
5.3 Negotiation packets
5.3.1 Payload format
Negotiation packets shall be formatted as specified in AES51, except as follows:
a) The timing information shall use the same coding as the timing field in frames (see 5.2.1).
b) The octet string specified as the Ethernet MAC client data may instead be sent as a service data unit
for a service other than Ethernet, e.g. as a UDP datagram. The UDP port numbers to be used in this
case are tbd.
NOTE No semantics are assigned to the timing information in negotiation packets, so it will usually be coded
as all-ones.
5.3.2 Information elements
5.3.2.1 Information element types
Information element types 01, 03, and 04 specified in AES51 shall not be used.
Information element type 02 specified in AES51 may be present for physical links able to carry AV flows,
and if present shall be coded with the value zero. Use of this IE coded with a nonzero value is reserved.
Additional information element types specified in 5.3.2.2 to 5.3.2.5 inclusive shall also be supported.
5.3.2.2 Sender's identifier
Information element type hexadecimal 82 shall be used to convey information relevant to higher-layer
management, and shall be included if, and only if, the sender has a 64-bit identifier.
The first 8 octets of the information field shall contain the sender's 64-bit identifier, as specified in
IEC 62379-5-2. Where the information field is longer than 8 octets, the remaining octets are reserved.
5.3.2.3 Flow label for signalling messages
Information element type hexadecimal 83 shall be used to specify the flow label to be used on signalling
messages to the sender. The information field shall be coded with the value for the part of the packet
header containing the flow label (including any protection fields), using the minimum number of octets
and aligned at the high end if not a whole number of octets. If there is no type 83 IE, signalling messages
shall use flow label zero.
NOTE For all current link formats, the information field will be exactly two octets, containing the flow label
and CRC.
5.3.2.4 Recipient's identifier
Information element type hexadecimal 84 may be used to issue a temporary 64-bit identifier to a unit
which does not have a permanent one. It may also be used to confirm the link partner's identity. The
first 8 octets of the information field shall contain the 64-bit identifier to be used by the recipient.
Where the information field is longer than 8 octets, the remaining octets are reserved.
© ISO/IEC 2022 – All rights reserved

5.3.2.5 Link type
Information element type hexadecimal 85 shall be used to specify the type of link. In a Link Accept the
information field shall consist of four octets containing (big-endianly) a 32-bit record in the following
form:
— 4 bits: protocol version: shall be coded with the value 1;
— 4 bits: link type: 1 = virtual link, 2 = physical link, other code points reserved;
— 22 bits: reserved: code as zero on transmission, ignore on reception;
— 1 bit: 1 if timing information is to be exchanged, 0 if not;
— 1 bit: 1 if FindRoute requests can be sent to the sender of the Link Request, 0 if not.
In other packet types it shall consist of one or more 4-octet records in the same format, in decreasing
order of preference, showing all the link types the sender can support. When requesting a physical link,
all supported link types (physical and virtual) should be shown, with physical link types listed first.
NOTE This allows a virtual link format to be used as a fall-back if the link partner does not support any of
the offered physical link formats.
For each of the flags in the last two bits, if the bit is set in the Link Request it may be clear in the Link
Accept, to show that the responder does not implement the facility.
If the penultimate bit is set for a physical link, the timing field shall be set as described in 8.1 in each
frame; if not, it may be coded as all-ones. If the penultimate bit is set for a virtual link, both partners
shall send link timing packets.
On a physical link or an internal virtual link, both bits should be set. On an external virtual link, they
should be set to show what functions each link partner implements.
5.4 Link establishment procedure
5.4.1 General
Link establishment occurs in the following three stages:
a) physical layer communication established;
b) exchange of negotiation packets and/or exchange of identity etc information in signalling messages;
c) exchange of synchronisation information and amalgamation of synchronisation domains.
In stage (b), exchange of negotiation packets is not required if both sides default to sending FN frames,
or one side defaults to sending FN frames and the other can detect that it does so.
On completion of stage (b), IT flows can be set up across the link. On completion of stage (c), AV flows
can be set up across the link.
The negotiation procedure in stage (b) is outlined in 5.4.2 to 5.4.6 inclusive, and details, including the
encapsulation of negotiation packets, are given in Annex A. Stage (c) is specified in Clause 7.
5.4.2 Transmission of request
Negotiation of the use of the FN frame format on a network interface shall begin with transmission of a
Link Request packet requesting a physical link as the first preference.
When a request has been sent, the interface shall enter “requesting” state.
© ISO/IEC 2022 – All rights reserved

The Link Request message should be repeated if no reply is received. The number of repetitions and the
interval between them are specified in Annex A.
If there is no reply after the specified number of repetitions, and the interface supports virtual links
over the network to which the interface is connected, it may attempt to establish one or more virtual
links as specified in Clause 6, otherwise it should enter the “passive” state.
5.4.3 Response to incoming Link Request
If there is no compatible format, a Link Reject packet shall be sent and "passive" state entered as
specified in AES51.
NOTE Having established that the link partner is an FN network element but there is no format that both
support, there is no point in attempting to set up a virtual link, assuming the Link Request packet included all
supported link formats.
Otherwise the actual configuration shall be transmitted in a Link Accept packet as specified in AES51,
but the new state shall be "accepting" rather than "active".
5.4.4 Response to incoming Link Reject
As specified in AES51, on receiving a Link Reject packet in any state the recipient shall enter the
"passive" state.
5.4.5 Response to incoming Link Accept
The action for an incoming Link Accept packet shall be as specified in AES51 except that instead of
entering "active" state the recipient shall switch to “transition” state.
In “transition” state it shall be configured to send FN frames, but transmission of the first complete
frame might not have begun, so it cannot transmit any FN packets. After a delay long enough to ensure
FN frames are being transmitted correctly, it shall switch to “await sync” state.
NOTE Implementers will usually find it convenient for outgoing frames on all interfaces to begin at the same
time, so it can take up to one frame time before the first frame header is transmitted; an additional delay is then
needed until the recipient's IT stream enters “between packets” state (see 5.2.3).
The link partner shall switch to “await sync” state either when it detects incoming FN frames or when it
receives a signalling message; if the signalling message is a SyncInfo message with appropriate content,
it shall switch directly to "aligning" state.
In "await sync" state it can connect IT flows but not AV flows.
After switching to the “await sync” state, each unit shall send a SyncInfo signalling request message
(see 8.2); it shall transition to “aligning” state when appropriate, as specified in 7.6. In “aligning” state,
the phase relationship between incoming frames on the link and outgoing frames shall be measured,
and the transition to “active” state shall occur when the phase has been established.
AV flows can only be set up in “active” state.
5.4.6 Errors and unexpected packets
Packets received in the wrong state may be either ignored or treated as errors.
Persistent errors in FN frames should cause "reset" state to be entered, which may include ceasing to
send FN frames.
© ISO/IEC 2022 – All rights reserved

6 Virtual links
6.1 General
Whereas a point-to-point link between two FN-aware network elements transitions to a (single)
physical link as soon as it is connected, a link to a legacy network can carry multiple virtual links, and
these links can be set up at any time.
This document does not specify how setting up a virtual link is initiated (i.e. what causes a Link
Request packet to be sent); typically, it will be by a command from a control element or by the interface
being configured to attempt it whenever the link comes up. Thereafter the process is similar to that for
physical links.
Each virtual link has its own state, which shall be “requesting”, “connected”, or “terminating”.
6.2 Transmission of Link Request
Setting up a new virtual link shall begin with the sending of a Link Request packet, after which the link
shall be in “requesting” state. If no reply is received, the packet may be repeated or the link may be
terminated.
NOTE This document does not specify the frequency of retransmissions or how many there should be before
giving up.
6.3 Response to incoming Link Request
A network element receiving a Link Request that it does not accept shall send a Link Reject if the request
was unicast. If the request was broadcast, it shall either ignore it or send a Link Reject.
A network element receiving a Link Request for a link which already exists with the same configuration
and is in “connected” state shall reply with a Link Accept.
NOTE This covers the case where a Link Accept has been lost and also where both parties send a Link
Request at the same time.
A network element receiving a Link Request for a link which already exists but with a different
configuration and is in “connected” state shall either send a Link Reject or update the configuration to
match the new request and send a Link Accept.
A network element receiving a Link Request for a new link which it accepts shall create the link with
“connected” state and send a Link Accept.
6.4 Response to incoming Link Reject
A Link Reject packet on any link shall cause the link to be terminated. If the link was in “connected”
state, a Link Reject shall be sent in reply.
6.5 Response to incoming Link Accept
The action for an incoming Link Accept packet in “requesting” state shall be as specified in AES51 except
that instead of “active” state the recipient enters “transition” state. In “reset” and “passive” states it
shall be ignored. In other states the action shall be as specified in AES51 for “active” state.
On entry to “transition” state, it shall configure the tx MAC logic to send Flexilink frames.
NOTE This can take up to 1 frame time to take effect, and a further 3 frame times before the link partner
detects that it is receiving Flexilink frames. No packets can be transmitted while in “transition” state.
© ISO/IEC 2022 – All rights reserved

6.6 Errors, unexpected packets, and termination
If any packet other than Link Request is received for a non-existent virtual link, a Link Reject should be
sent in reply.
If an encapsulated IT packet is received for a flow that is not connected, a ClearDown signalling message
for the flow should be sent in reply.
Either party may initiate termination of a link at any time by sending a Link Reject and changing the
link's state to “terminating”.
7 Network layer synchronisation
7.1 General
Frames on all links within an island shall be phase-aligned.
NOTE 1 This allows AV flows to be routed with minimal latency.
Frame rates for different islands within the same cloud shall be the same.
NOTE 2 This prevents queues building up in the de-jitter buffers.
NOTE 3 The phase-alignment of frames is completely independent of the synchronisation of digital audio and
video; sampling rates of digital media do not need to be synchronised with the network, nor with other media
flows.
7.2 Alignment of frames within an island
Each island shall be a single “sync domain”, within which all transmitted frames shall be phase-locked
to the frames transmitted by a single unit, the “sync master”, so that the timing propagates out from
that unit. The link on which a unit receives timing information is its “upstream” link. Any links over
which it supplies timing information to a neighbouring unit are “downstream” links. All other links are
“off-tree” links. The link partner on the upstream link is the upstream neighbour, and the link partner
on any other link is a downstream neighbour.
NOTE 1 The links across which the timing propagates form a spanning tree, with the sync master at the root.
These links are upstream in the direction towards the root, and downstream in the other direction. All other
links are off-tree.
NOTE 2 The synchronisation method is further specified in Annex A.
NOTE 3 End equipment may simply align the frame structure on the outgoing direction of its link directly
with the incoming frames, for instance by starting an output frame each time the start of an incoming frame is
detected. This is referred to as “loopback” timing. A link on which it is used is always on the spanning tree, with
the end unit being a leaf.
When a link becomes a unit's upstream link, the point in the input frame at which an outgoing frame
begins on each link shall be measured, and subsequent inter-frame gaps adjusted so that subsequent
frames begin as close as possible to the same point. The average inter-frame gap shall be measured over
each timing period as specified in Annex A, and if the reference is lost the most recent average figure
shall be maintained, using an algorithm such as a binary rate multiplier to minimise jitter.
NOTE 4 This reduces the impact on off-tree links until a new route to the sync master can be established.
7.3 Alignment of frames within a cloud
A cloud shall be a single sync domain, but frequency locked rather than phase locked.
NOTE 1 Each island will therefore have the same frame rate over time, although there can be considerable
wander in the phase relationship between different islands.
© ISO/IEC 2022 – All rights reserved

Each island shall have its own sync master to which frames are phase locked; for one island this shall
also be the sync master for the cloud, while for the others it shall have an upstream link which is a
virtual link. Its upstream neighbour may be any unit in the neighbouring island; it is not required to be
the island's sync master.
NOTE 2 There can be virtual links within an island, for instance if the island covers two sites which are
connected by a physical link and also by a virtual link which is used as a back-up.
7.4 Establishment of sync domains
When a network element is powered on or otherwise reset, it shall form an island within which it
is the sync master. When a physical link enters “await sync” state, the link partners shall exchange
information regarding their sync domains. If they are in the same island, both will see the link as an off-
tree link and they can set up synchronous flows as soon as they have discovered the phase relationship
between the frames they transmit.
If they are part of different islands, the two islands shall be amalgamated as specified in 7.6.
NOTE In this process, the one with the better reference (chosen in a similar way to the “best master clock” in
PTP) is unchanged. The other is first reconfigured (if necessary) so that the unit connected to the new link is its
sync master, and then the new link is set to being its upstream link.
A similar process shall be used when a virtual link is connected. If the two units are both in the same
cloud, the link is off-tree. Otherwise, the two clouds shall be amalgamated with the new link being on-
tree and the unit for which it is the upstream link becoming the sync master for its island.
7.5 Action on link down
If a link which is part of the spanning tree goes down, the unit downstream of it shall become the sync
master of a new sync domain.
NOTE 1 There is no change to any other links.
It shall freeze the frequency of the frames it generates at the value it had just before the link went down
and announce the new configuration to the units that are downstream of it in the tree. If any of them
has an off-tree link to the previous domain, it shall act as if that link had just come up.
NOTE 2 This results in the tree being quickly reconfigured, before there can be significant drift in the phase
relationship on off-tree links.
7.6 Procedures
7.6.1 Link up
7.6.1.1 General
If, when a link comes up, information in negotiation packets or elsewhere shows that the link partner
uses loopback timing, the link can transition directly to the “aligning” state. Otherwise, it shall enter
“await sync” state.
The unit shall send a downstream SyncInfo request message on the link immediately after switching to
the “await sync” state. The normal process of repeating the message periodically until it is acknowledged
shall apply.
7.6.1.2 Same domain
On receiving a downstream SyncInfo request message on the link containing the same sync source as
its own (i.e. with the same “source of clock” value and, if it is less than 176, the same sync master's
identifier), it shall switch to “aligning” state.
© ISO/IEC 2022 – All rights reserved

7.6.1.3 Less “good” sync source
On receiving a downstream SyncInfo request message on the link in the case where its own sync source
is “better” than the one in the message (i.e. has a larger “source of clock” value, or the same “source of
clock” value and a larger identifier), it shall stay in “await sync” state until the link partner announces
that it is ready for the link to transition to “on-tree”.
7.6.1.4 “Better” sync source
On receiving a downstream SyncInfo request message on the link containing a sync source that is
“better” than its own (i.e. has a larger “source of clock” value, or the same “source of clock” value and a
larger identifier), if it is not the sync master it shall first become sync master, as follows:
— It shall forward the message on its upstream link, as an upstream message. Other units receiving the
message shall forward it on their upstream links until it reaches the sync master. The sync master
may ignore the message, for instance if it has already discovered a better sync source elsewhere.
— If the sync master accepts the request, it shall send a handover message towards the new sync
master. Each unit receiving a handover on its upstream link becomes sync master until it has passed
the message on and the recipient has acknowledged it.
— When the handover message reaches the unit that originated this part of the process, or immediately
on receiving the SyncInfo request message if it is the sync master at that time, it shall switch to
using the link as an upstream link, sending messages on all its links to inform the other units in its
domain of the change, and to inform the link partner that the link is now a downstream link.
— A unit receiving a handover message shall not announce the change to the rest of the network if it
immediately passes the sync master role on to another unit; it shall, however, announce the change
if it fails to pass it on.
7.6.2 Link down
When an off-tree link goes down, no action is required other than rerouting flows that traverse it. The
same applies to a downstream link.
When a unit's upstream link goes down, the unit shall become sync master, setting the frame rate from
the measurement in the most recent timing period as specified in 7.2, and send a downstream message
on all its remaining links announcing that it is now sync master. If a unit receiving the message has an
off-tree link, it should send an upstream message in the same way as in the “link up” case.
The link partner might also be in the detached part of the domain, so the unit should wait before sending
the upstream message, to give the link partner time to pass on its own downstream message.
7.6.3 SyncInfo signalling messages
SyncInfo messages shall be signalling messages (as specified in IEC 62379-5-2) with message type 7
and the message class coded as “request”.
For information on frame timing the fixed part shall consists of two or thirteen octets, the first of which
is the subtype and is coded as:
— bit 7 (most significant): coded as 0 (c
...