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
Current Stage
4099 - Full report circulated: DIS approved for registration as FDIS
Start Date
08-Nov-2021
Completion Date
08-Nov-2021
Ref Project

Buy Standard

Standard
ISO/IEC 21559-1:2022 - Telecommunications and information exchange between systems — Future network protocols and mechanisms — Part 1: Switching and routing Released:3/1/2022
English language
22 pages
sale 15% off
Preview
sale 15% off
Preview

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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© 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

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

© 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

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

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

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.