Information technology — Future Network — Problem statement and requirements — Part 3: Switching and routing

ISO/IEC TR 29181-3:2013 contains the problem statement and requirements for switching and routing in the Future Network, in particular: description of the requirements for carrying data over digital networks; description of the ways in which these requirements are not satisfied by current networks; functional architecture for switching and routing in the Future Network; and requirements for control plane information flows for finding, setting up, and tearing down routes. The requirements in 4. include support for both current ("legacy") and future ("new") switching technologies, to aid the transition between them.

Technologies de l'information — Réseaux du futur — Énoncé du problème et exigences — Partie 3: Commutation et routage

General Information

Status
Published
Publication Date
08-Apr-2013
Current Stage
6060 - International Standard published
Due Date
11-Oct-2013
Completion Date
09-Apr-2013
Ref Project

Buy Standard

Technical report
ISO/IEC TR 29181-3:2013 - Information technology -- Future Network -- Problem statement and requirements
English language
29 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

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 TR 29181-3:2013(E)
©
ISO/IEC 2013

---------------------- Page: 1 ----------------------
ISO/IEC TR 29181-3:2013(E)

COPYRIGHT PROTECTED DOCUMENT


©  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

---------------------- Page: 2 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 3 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 4 ----------------------
ISO/IEC TR 29181-3:2013(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. 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

---------------------- Page: 5 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 6 ----------------------
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

---------------------- Page: 7 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 8 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 9 ----------------------
ISO/IEC TR 29181-3:2013(E)
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

---------------------- Page: 10 ----------------------
ISO/IEC TR 29181-3:2013(E)
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
...

Questions, Comments and Discussion

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