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

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 21559-1:2022(E)
© ISO/IEC 2022

---------------------- Page: 1 ----------------------
ISO/IEC 21559-1:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© 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

---------------------- Page: 2 ----------------------
ISO/IEC 21559-1:2022(E)
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

---------------------- Page: 3 ----------------------
ISO/IEC 21559-1:2022(E)
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

---------------------- Page: 4 ----------------------
ISO/IEC 21559-1:2022(E)
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

---------------------- Page: 5 ----------------------
ISO/IEC 21559-1:2022(E)
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

---------------------- Page: 6 ----------------------
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
1
© ISO/IEC 2022 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 21559-1:2022(E)
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.
2
  © ISO/IEC 2022 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 21559-1:2022(E)
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
3
© ISO/IEC 2022 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 21559-1:2022(E)
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.
4
  © ISO/IEC 2022 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 21559-1:2022(E)
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.
5
© ISO/IEC 2022 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 21559-1:2022(E)
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 p
...