ISO/IEC TR 29181-3:2013

TECHNICAL ISO/IEC
REPORT TR
29181-3
First edition
2013-04-15
Information technology — Future
Network — Problem statement and
requirements —
Part 3:
Switching and routing
Technologies de l'information — Réseaux du futur — Énoncé du
problème et exigences —
Partie 3: Commutation et routage

Reference number
©
ISO/IEC 2013
©  ISO/IEC 2013
All rights reserved. Unless otherwise specified, 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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2013 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations . 3
5 Background . 4
5.1 Main features . 4
5.2 Rationale for a new paradigm . 4
5.2.1 Appropriateness for today's traffic . 4
5.2.2 Addressing and scalability . 5
5.2.3 Security . 5
5.2.4 Complexity of routing hardware . 5
5.3 Migration . 6
5.4 Structure of this document . 6
6 Requirements . 6
6.1 Introduction . 6
6.2 Classes of flow . 7
6.2.1 Minimising complexity . 7
6.2.2 Synchronous flows . 7
6.2.3 Asynchronous flows . 9
6.3 Addressing . 11
6.4 Security and accountability . 11
6.4.1 Privacy, trust and traceability . 11
6.4.2 Corruption of data units . 11
6.4.3 Resilience . 12
6.4.4 Accounting . 12
6.4.5 Time-limited calls . 12
6.4.6 Prioritisation of calls . 13
6.5 Net neutrality . 13
6.6 Mobility . 13
6.7 Scalability . 13
6.8 Network management . 13
6.9 Energy efficiency . 14
7 Gap analysis . 14
7.1 Introduction . 14
7.2 Service experienced by flows . 14
7.2.1 Delay and throughput . 14
7.2.2 Packet size . 15
7.3 Addressing . 15
7.4 Security and accountability . 16
7.4.1 Privacy, trust and traceability . 16
7.4.2 Resilience . 16
7.4.3 Accounting . 16
7.4.4 Time-limited calls . 16
7.4.5 Prioritisation of calls . 16
7.5 Net neutrality . 16
7.6 Mobility . 16
© ISO/IEC 2013 – All rights reserved iii

7.7 Scalability .17
7.8 Network management .17
7.9 Energy efficiency .17
8 Functional architecture for switching and routing .17
8.1 Model of the switching and routing process .17
8.2 Structure of the network .18
8.3 Layers .19
9 Requirements for data plane .19
9.1 General .19
9.2 Asynchronous service .20
10 Requirements for control plane .21
10.1 Control plane protocol .21
10.2 Message format .21
10.2.1 Encoding .21
10.2.2 Size .22
10.2.3 Extensibility .22
10.3 Relationship with link partner .22
10.4 Timeouts .22
10.5 Acknowledgements .22
10.6 Call set-up .23
10.6.1 Calls .23
10.6.2 Routes .23
10.6.3 Identification .23
10.6.4 Information in set-up messages .23
10.6.5 Synchronous flows .24
10.6.6 Asynchronous flows .24
10.7 Routing .24
10.8 Other messages .25
10.8.1 Disconnecting calls, flows, and routes .25
10.8.2 Rerouting .25
10.8.3 Changing QoS parameters .25
10.8.4 Adding flows .25
10.8.5 User data .25
11 Route finding .26
11.1 General requirements .26
11.2 Propagation of routing information .26
11.3 Message format .26
Annex A (informative) Use cases and other background information .27
A.1 Remote contribution to radio broadcasts .27
Bibliography .29

iv © ISO/IEC 2013 – 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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
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.
ISO/IEC TR 29181-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.
ISO/IEC TR 29181 consists of the following parts, under the general title Information technology — Future
Network — Problem statement and requirements:
 Part 1: Overall aspects
 Part 3: Switching and routing
 Part 4: Mobility
 Part 6: Media transport
 Part 7: Service composition
The following parts are under preparation:
 Part 2: Naming and addressing
 Part 5: Security
© ISO/IEC 2013 – All rights reserved v

Introduction
ISO/IEC TR 29181-1 describes the definition, general concept, problems and requirements for the Future
Network (FN). The other parts of ISO/IEC TR 29181 provide details of various components of the technology.
This part of ISO/IEC TR 29181 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.
vi © ISO/IEC 2013 – All rights reserved

TECHNICAL REPORT ISO/IEC TR 29181-3:2013(E)

Information technology — Future Network — Problem
statement and requirements —
Part 3:
Switching and routing
1 Scope
This part of ISO/IEC TR 29181 contains the problem statement and requirements for switching and routing in
the Future Network, in particular:
a) description of the requirements for carrying data over digital networks;
b) description of the ways in which these requirements are not satisfied by current networks;
c) functional architecture for switching and routing in the Future Network; and
d) requirements for control plane information flows for finding, setting up, and tearing down routes.
The requirements in (d) include support for both current (“legacy”) and future (“new”) switching technologies,
to aid the transition between them.
NOTE A distinction is made between “data”, which is simply a string of bytes, and “content”, for which an
interpretation, for instance as text, sounds, or still or moving images, is defined. Content is addressed in
ISO/IEC TR 29181-6.
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.
ISO/IEC TR 29181-1, Information technology — Future Network — Problem statement and requirements —
Part 1: Overall aspects
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC TR 29181-1 and the following
apply.
3.1
data unit
sequence of octets which is conveyed across the network as a single unit
3.2
flow
sequence of data units
© ISO/IEC 2013 – All rights reserved 1

3.3
asynchronous flow
flow consisting of data units for which the time of arrival at the destination is unimportant
3.4
synchronous flow
flow for which the network delay experienced by data units is required to be within specified limits, the size of
the units, and also the number of units to be transmitted per unit time, being either fixed, or variable with a
defined upper limit
3.5
connectionless data unit
data unit which is not part of a flow
3.6
network delay
time from submission of a data unit to the network by the sender to its delivery to the recipient
NOTE The exact events which constitute submission and delivery are not specified in this document, as they depend
on internal details of the equipment.
3.7
network element
piece of equipment which takes part in the process of conveying data, such as a switch, gateway, or interface
3.8
FN-aware network element
network element which implements a protocol which will be standardised, based on the requirements in
clauses 9 and 10
3.9
legacy network
network composed of network elements which are not FN-aware
3.10
end equipment
equipment that is connected to the network and produces or consumes data units
3.11
identifier
value that identifies a subnetwork, network element, service, or piece of content
3.12
locator
value that identifies a subset of the network which is the scope of an identifier or in which the object identified
by an identifier is to be found
3.13
address
identifier, or locator together with an address whose scope is defined by the locator
3.14
label
information in the encapsulation of a data unit which defines, to the network element which receives the data
unit, how it is to be routed
EXAMPLE 1 IP address and port number
EXAMPLE 2 MPLS label
2 © ISO/IEC 2013 – All rights reserved

EXAMPLE 3 ISDN channel number
3.15
encapsulation
additional octets or other symbols associated with a data unit which serve to delimit it or to identify aspects of
the service it should receive
3.16
packet
data unit together with its associated encapsulation
4 Abbreviations
Numbers in square brackets identify references in the Bibliography. Numbers prefixed by RFC identify IETF
"Request For Comments" documents.
ADSL Asymmetric Digital Subscriber Line
ARP Address Resolution Protocol (RFC 826)
AoIP Audio over Internet Protocol
ATM Asynchronous Transfer Mode
AVB Audio Video Bridging [1]
CO Connection Oriented
CL ConnectionLess
DAB Digital Audio Broadcasting
DHCP Dynamic Host Configuration Protocol (RFC 2131)
DNS Domain Name System (RFC 1034, 1035)
DSL Digital Subscriber Line
DWDM Dense Wavelength Division Multiplexing
EUI Extended Unique Identifier
FEC Forward Error Correction
FM Frequency Modulation
GPS Global Positioning System
HTTP HyperText Transfer Protocol (RFC 2616)
IANA Internet Assigned Numbers Authority
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
IPv4 Internet Protocol version 4 (RFC 791)
IPv6 Internet Protocol version 6 (RFC 2460)
ISDN Integrated Services Digital Network [2]
ISP Internet Service Provider
MAC Media Access Control
MPLS MultiProtocol Label Switching (RFC 3031)
MTU Maximum Transmission Unit size
NAT Network Address Translation
OSI Open Systems Interconnection
PC Personal Computer
PCM Pulse Code Modulation
QoS Quality of Service
RSVP resource ReSerVation Protocol (RFC 2205)
© ISO/IEC 2013 – All rights reserved 3

SDH Synchronous Digital Hierarchy [3]
SDP Session Description Protocol (RFC 4566)
SIP Session Initiation Protocol (RFC 3261)
SNAP SubNetwork Access Protocol
SNMP Simple Network Management Protocol (RFC 1157)
STL Studio-Transmitter Link
STUN Session Traversal Utilities for NAT (RFC 5389)
TCP Transmission Control Protocol (RFC 792)
UDP User Datagram Protocol (RFC 768)
UHF Ultra High Frequency
URL Universal Resource Locator
VCI Virtual Channel Identifier
VPI Virtual Path Identifier
5 Background
5.1 Main features
New switching technologies are expected to support virtual circuits, in contrast to the connectionless paradigm
of the current Internet Protocol: see 5.2.
The control protocols outlined in this document allow an application to negotiate with the network, and with the
remote application, to achieve the communication of its data in the most appropriate way. They do not
constrain the system to use any particular method of delivering the data to its destination, and thus support
both existing and new switching technologies. They do, however, require the network to report explicitly (to the
application) parameters defining the service it will receive; this allows the application to take advantage of the
facilities offered by the new networks if available, and to make provision for the deficiencies of existing
technologies otherwise.
The Internet Protocol world is often depicted as an hour-glass, with many applications at the top, many
network technologies at the bottom, and IP as the narrow waist through which everything must pass. FN has a
similar structure, but there are some important differences in the nature of the narrow waist:
 there are two kinds of interaction between the application and the network, which we describe as control
plane and data plane;
 control plane messages usually refer to a “flow” (a sequence of data units) rather than to a single data unit,
so are able to include the QoS parameters needed for live media, also other session-related information
such as security checks and per-call billing; and
 the data plane carries data units whose encapsulation depends only on the local switching technology.
Thus different kinds of switching technology can be supported, even those (such as DWDM) that do not route
according to information in packet headers. Where packet switching is used, the routing information in the
packet does not need to include the kind of globally unique addresses that are required for IP.
5.2 Rationale for a new paradigm
5.2.1 Appropriateness for today's traffic
Today's Internet mainly carries two kinds of traffic: static objects such as files and web pages, and continuous
media such as audio and video. The connectionless service provided by Internet Protocol is transmission of
individual packets from one interface to another; it is a “best effort” service, aiming to deliver each packet as
soon as possible but not giving any guarantees as to when (or even whether) each packet will be delivered.
4 © ISO/IEC 2013 – All rights reserved

A user downloading a file simply requires a copy of the file to be received by a particular piece of equipment
(such as a PC) as soon as possible after it is requested, so a “best effort” service such as that provided by IP
is appropriate. However, the equipment may have several different interfaces to the network, and the user
should not need to consider through which interface the data should be received, nor the location of the server
on which it is hosted.
In the case of continuous media, the source produces data at regular intervals and the destination consumes
it at regular intervals. The time between the source sending some data and the destination consuming it must
be long enough for the slowest packet to arrive. (The destination must hold data packets that arrive more
quickly in a buffer.) In connectionless packet networks, this time interval includes an unpredictable amount of
queuing time and is thus not well-defined. For some applications, such as streaming recorded material, this is
of minor importance, but for others, such as videoconferencing, it degrades the user experience and in some
cases, for instance some telemedicine and industrial control applications, delays will compromise safety.
To deliver a service appropriate for continuous media, the network needs to configure resources to be ready
to pass on the data with a minimum of delay; a negotiation is therefore required between the application and
the network before transmission begins. Various measures have been introduced to improve the service
experienced by continuous media on the current Internet, but this traffic still experiences dropped packets and
unnecessarily long delays. Moreover, the addition of new protocols and procedures increases the complexity
of the system, decreasing its reliability and making it more difficult to manage: see reference [4] in the
Bibliography.
5.2.2 Addressing and scalability
Use of Internet Protocol also requires every packet to carry the IP addresses of sender and destination. These
addresses have global scope, and must therefore be large enough to uniquely identify every endpoint; as the
number of endpoints increases (a process that will accelerate as the Internet of Things develops), addresses
need to become larger, for instance changing from 32-bit IPv4 addresses to 128-bit IPv6 addresses. A system
with a fixed address format in which addresses have global scope cannot scale beyond a certain size; for
instance a system using IPv4 cannot have more than 4 billion endpoints.
However, a switch or router simply needs to forward the packet to the correct neighbour with the correct level
of service, and locally-significant forms of identification have the potential to allow this task to be performed
more efficiently and more reliably. Moreover, they do not impose any limitations on the total size of the
network because addresses in one area can be re-used in other areas. Network address translation has retro-
fitted this feature to IPv4, but caused other problems which required the introduction of further protocols such
as STUN.
FN makes possible a migration from IP to improved switching technologies in which the information used for
local routing is separate from global addressing.
5.2.3 Security
Another area of concern is security. In a connectionless packet-switched network, all the information needed
to route a packet has to be included in the packet header. This limits the amount of checking that can be done
without unreasonably increasing the packet size, or the amount of processing required per packet at each
switching point, or both. A system in which the routing information in a packet refers, indirectly, to a route that
was set up as a result of a negotiation which can include much more thorough checking of identity etc, has the
potential to be much more secure. It can also enhance privacy by allowing a client to set up a session with a
server without disclosing the client's address to the server.
5.2.4 Complexity of routing hardware
Connectionless packet switching requires each switch or router to read and interpret addressing information in
each packet, in order to discover on which output to forward it and what service (e.g. higher- or lower-priority
queue) it should experience. This information is usually too long to be used as a memory address for direct
lookup, for instance an IPv6 address is 128 bits and the information necessary to identify a flow in an IPv4
packet is over 100 bits, so the more complex and power-hungry associative or content-addressable memory
must be used. Other techniques, where much of the work is done once (when the call is set up) rather than for
© ISO/IEC 2013 – All rights reserved 5

every packet, allow switching equipment (and particularly large switches) to be simpler and less power-
hungry; see, for instance, 4.1 of reference [6]. With increasing traffic on the Internet, and increasing concern
over energy use and its contribution to climate change, efficiency of switching equipment will become more
important over the coming decade.
5.3 Migration
The FN model allows a network to be seen as a “black box”, so it is only the edge devices that need to be FN-
aware. If the network supports QoS, its native QoS mechanisms can be used and the resulting QoS
parameters reported to the application. Otherwise, the application will be informed that only a “best effort”
service is possible, with an indication of the performance expected (for instance, whether the network is the
public Internet or a small Ethernet network). This allows piecemeal migration in both private and public
networks.
For instance, on an AVB network [1] the resource reservation mechanisms of IEEE 802.1Qat and Qav can be
used to deliver defined QoS. The edge devices need to support the FN protocols, but within the network only
the AVB protocols need to be supported.
An application on an FN-aware terminal on the AVB network can ask to receive video from a server identified
by a URL; if the server is on the AVB network, IEEE 1722 can be used for transport and there is no need to
use IP at all. If the server is on the Internet, there are two possibilities: either the application is told it has to
use IP over the Ethernet network, or the gateway between the AVB network and the Internet implements the
IP protocols.
A public network which supports non-IP routing may tunnel IP packets through its asynchronous service, and
it may convert between IP and FN protocols in gateway devices. It may intercept protocols such as SIP and
set up synchronous flows for them.
On the link between two networks, for instance an ADSL link between a private network and an ISP, if the
devices at both ends of the link are FN-aware the FN protocols can be used. Otherwise, legacy protocols must
continue to be used.
5.4 Structure of this document
Clause 6 lists requirements for applications that transmit information across digital networks, and clause 7 lists
ways in which the current technology fails to meet those requirements.
Clause 8 examines the functionality of switching and routing equipment. Clauses 9 and 10 list requirements
for the communication between network elements, and clause 11 outlines the requirements for the process of
exchanging information between network elements that allows the route to any given destination to be
established.
6 Requirements
6.1 Introduction
The basic service provided by the network is to convey data units between end equipment.
This clause reviews the requirements which applications that transmit various kinds of data across digital
networks have for this service.
Many different kinds of application will use this service to convey information encoded as octet strings, and the
network should not attempt to interpret the data units it conveys. It should not deliberately alter them in any
way, although transmission errors may occasionally occur (see 6.4.2). Many different kinds of network
element will participate in the conveying of an application's data unit, and the application should not make
assumptions about their characteristics.
6 © ISO/IEC 2013 – All rights reserved

In most cases, the application will need to send a sequence of data units, either because the data to be sent is
larger than the maximum size of a data unit (as with file transfer) or because it is being produced and/or
consumed by a continuous process (as with audio and video). Such a sequence is referred to in this
document as a “flow”.
Each sub-clause below describes a group of requirements that have been identified for the carriage of data
units. Mostly, these are expressed as requirements on flows rather than on individual data units.
6.2 Classes of flow
6.2.1 Minimising complexity
 The number of different options should be kept to a minimum.
This makes the task of implementing and managing networks as simple as possible. Thus, only two classes of
flow are described in this document; it would be possible to identify additional classes, but the improvement in
efficiency achieved by tailoring the service more closely to the application requirements would be outweighed
by the increase in complexity of the system.
For example, no distinction is made between constant bit rate and variable bit rate media flows. We assume
that in the latter case the application will request enough capacity to support its maximum bit rate; when it is
sending at a lower rate, for some switching technologies the network will be able to use the remaining
bandwidth for best-effort traffic, while for others the “wasted” bandwidth is less than the additional overheads
of alternative mechanisms.
6.2.2 Synchronous flows
6.2.2.1 Network delay
 The application should be able to negotiate with the network to achieve the best balance between the
delay the application can tolerate and the delay the network can achieve.
For many applications the maximum network delay is important, but the acceptable limits vary from a few
milliseconds to a few seconds. Also, the recipient needs to have enough buffer space to store data that arrives
with a minimum delay until it is needed, so delay variation can also be important.
For some applications, particularly safety-critical applications that involve control loops (whether or not
humans are included in the loop), the maximum delay must not be exceeded; these applications require
absolute guarantees from the network. The maximum delay value depends on the parameters of the control
loop.
For other applications, particularly those involving conversations between humans, there is no hard-and-fast
limit to the delay, but as the delay increases communication becomes increasingly difficult. Delays of a few
tens of ms are acceptable in conversation, but if the round trip delay is more than 150 ms it is difficult to avoid
both parties speaking at once and the conversation does not flow naturally; thus for conversational services
the end-to-end time in each direction should be less than 75ms including encoding and decoding delays. In
the case of audio- and video-conferencing, the signals may go via a central unit, in which case the round trip
will involve four transits across the network so the end-to-end time for each transit needs to be less than
37.5 ms. If the time to encode the signals in digital form, and decode them at the receiving end, is significant,
the budget for network transmission is reduced still further.
NOTE Audio analogue-to-digital and digital-to-analogue converters typically take 1ms each. Encoding in a
compressed form can take tens or hundreds of milliseconds.
The most demanding requirements are probably where musicians' sound is returned to them through in-ear
monitors; a total round trip time (via a mixing desk, including two transits across the network as well as
processing delays) of as little as 1 ms is perceptible by some performers, and most have difficulty in
© ISO/IEC 2013 – All rights reserved 7

performing above about 40 ms. (Sensitivity is different for different instruments, with vocalists being
particularly sensitive; for details see [7].)
In unidirectional transmission, longer delays are tolerable but there will be a requirement to synchronise
content delivered by different routes, for instance when handing over between devices (see 6.6) or when
combining a programme received over the air with additional material received over the Internet.
6.2.2.2 Throughput
 A wide range of data unit sizes and transmission rates should be supported.
At one extreme, a telemetry application may transmit a data unit consisting of a small number of bytes once a
minute. At the other extreme, uncompressed high-definition video requires multiple gigabits per second.
An example from legacy networks is 64 kb/s ISDN, where a single-byte data unit is transmitted every 125 µs,
synchronised to the network.
For some switching technologies, reservations will be for data units to be transmitted at a specified regular
interval, with the data units having a specified maximum size; such technologies are likely to be able to
achieve the lowest latencies by synchronising incoming and outgoing streams at a switch. For others, they
may be for a specified total number of bits per unit time; this figure would have to include encapsulation, which
is technology-specific, so should still be expressed as a number of data units of a specified size.
6.2.2.3 Data unit size
 The network should inform the application of the maximum data unit size and maximum per-data-unit
overhead for the route a flow will follow, so that it can choose an appropriate encapsulation for the data.
For most media flows, there will be a “natural” data unit size; for instance, in the case of linear PCM audio it is
one sample per channel. If this is more than the maximum data unit size, the application will need to split the
data into several units, for instance if there are 250 channels and up to 128 will fit in a maximum sized data
unit, it should send channels 1-125 in one data unit and 126-250 in another.
In the case of compressed audio, the natural size of a data unit will be one frame of compressed data,
typically 20 ms of audio.
If the natural data unit size is small compared with the reported per-data-unit overhead, the application should
use aggregation to create larger data units. In the case of linear PCM audio, this means putting more than one
sample per channel into each data unit, though this will increase the delay. (For example, if the sampling rate
is 48 kHz and a data unit contains 48 samples per channel, an extra 1 ms of delay is introduced: the first
sample in a data unit waits for 1ms before it is transmitted, and the last sample waits an extra 1ms at the
receiving end before it is consumed.) The appropriate limits for overheads will depend on circumstances;
overheads of several hundred percent are likely to be acceptable when sending audio on a gigabit Ethernet
local network, whereas a public network may reject, or charge a premium for, calls which send a large number
of small packets.
With some technologies, data units may be framed in such a way that there is no upper bound to their size;
the format of the message reporting the maximum size should support this case.
NOTE The application is responsible for sending data units of the right size; the network does not do any
fragmentation or reassembly.
6.2.2.4 Routing
 FN should not place any restrictions on the technology that can be used for routing synchronous data
units. In particular, it should not require a data unit, or its encapsulation, to include a globally-significant
address: see 6.7.
8 © ISO/IEC 2013 – All rights reserved

There are a number of ways in which the flow to which a data unit belongs may be identified, for instance by a
local “handle” value such as an ATM VCI, or by other information from the encapsulation such as its position
in an ISDN frame or the wavelength of its carrier.
Synchronous flows should be able to pass seamlessly along a route which includes several different routing
technologies.
6.2.2.5 Directionality
 The synchronous service should be unidirectional.
In many cases a synchronous flow is inherently unidirectional; either there is no return path or the return path
carries a different kind of data. A radio or television broadcast is unidirectional, likewise video-on-demand
(except for very occasional control messages). An outside broadcast sends programme-quality material to the
studio, but the return path may be a lower-quality channel, or (for live broadcasts) the off-air signal may be
used (see A.1).
Where bidirectional communication is required, as with a telephone call, two flows can be set up; typically the
network will set both flows up at the same time, and by the same route, so the extra effort compared with a
bidirectional service is minimal.
6.2.2.6 Multicasting
 One-to-many transmission, with the network copying the data as necessary, is required, and should
support very large numbers of recipients for a single flow.
There are many applications in which it is useful for the network to copy the data to more than one recipient.
For instance when a TV station covers an event such as a football match there will be many people wanting to
watch it simultaneously.
One-to-one transmission is simply a special c
...