ETSI GR NIN 003 V1.1.1 (2021-03)

Non-IP Networking (NIN); Flexilink network model

DGR/NIN-003

General Information

• Status: Not Published
• Technical Committee: NIN - Non-IP Networking
• Current Stage: 12 - Completion
• Due Date: 05-Mar-2021
• Completion Date: 10-Mar-2021

Standards Content (Sample)

ETSI GR NIN 003 V1.1.1 (2021-03)






GROUP REPORT
Non-IP Networking (NIN);
Flexilink network model
Disclaimer
The present document has been produced and approved by the Non-IP Networking ETSI Industry Specification Group (ISG)
and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GR NIN 003 V1.1.1 (2021-03)



Reference
DGR/NIN-003
Keywords
core network, fixed networks, internet, layer 3,
network, network performance, next generation
protocol, non 3GPP access

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2021.
All rights reserved.

DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GR NIN 003 V1.1.1 (2021-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 5
3.1 Terms . 5
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Layers . 6
4.1 OSI model . 6
4.2 Current practice . 7
4.3 Layering in Flexilink . 7
4.4 Communicating entities . 7
5 Flows . 7
5.1 Background . 7
5.2 Flow identification . 8
5.3 Routing of flows . 8
5.3.1 Flow set-up . 8
5.3.2 Software Defined Networking . 9
5.4 Identification and location . 9
5.5 Control plane protocols . 10
6 Distribution of "header" information . 10
6.1 Flexilink headers . 10
6.2 UDP over IPv4 . 11
6.3 TCP over IPv4 . 11
6.4 RINA . 11
6.5 Live audio . 12
7 QoS, resource allocation, and congestion control . 12
7.1 Guaranteed service . 12
7.2 Basic service . 12
8 Security, privacy, and error protection . 13
History . 14


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR NIN 003 V1.1.1 (2021-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Non-IP Networking (NIN).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR NIN 003 V1.1.1 (2021-03)
1 Scope
The present document illustrates how the technology of ETSI GS NGP 013 [i.1] can carry multiple services, using as
examples RINA, TCP/IP, and digital audio and video; including example packet formats and requirements for the
control plane protocols.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS NGP 013: "Next Generation Protocols (NGP); Flexilink: efficient deterministic packet
forwarding in user plane for NGP; Packet formats and forwarding mechanisms".
[i.2] ISO/IEC 7498-1: "Information technology -- Open Systems Interconnection -- Basic Reference
Model: The Basic Model -- Part 1".
[i.3] ETSI GR NGP 003: "NGP Next Generation Protocol; Packet Routing Technologies".
[i.4] ETSI GR NGP 009: "Next Generation Protocols (NGP); An example of a non-IP network protocol
architecture based on RINA design principles".
[i.5] ISO/IEC 60958-1: "Digital audio interface -- Part 1: General".
[i.6] ISO/IEC 62379-5-2: "Common control interface for networked digital audio and video products --
Part 5-2: Transmission over networks -- Signalling".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
flow: set of packets all of which follow the same route and experience the same level of service
QUIC: UDP-based transport and session-control protocol with claimed performance improvements over TLS/TCP
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GR NIN 003 V1.1.1 (2021-03)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Program Interface
ARQ Automatic Repeat reQuest
BGP Border Gateway Protocol
CRC Cyclic Redundancy Check
DNS Directory Name Service
FIB Forwarding Information Base
GTP GPRS Tunnelling Protocol
HARQ Hybrid Automatic Repeat reQuest
IP Internet Protocol
NAT Network Address Translation
NGP Next Generation Protocols
OSI Open Systems Interconnection
PDU Protocol Data Unit
QoS Quality of Service
RIB Routing Information Base
RINA Recursive InterNetwork Architecture
SDN Software Defined Networking
SDU Service Data Unit
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TDM Time Domain Multiplexing
UDP Unacknowledged Datagram Protocol
4 Layers
4.1 OSI model
ISO/IEC 7498-1 [i.2] specifies a model in which there are seven layers, each performing a different function within the
process of conveying information from one device to another.
Each layer is implemented by an entity in one device exchanging Protocol Data Units (PDUs) with its peer entity in the
other device. Except for layer 1, the bottom (Physical) layer, the PDU is transmitted by handing it to the layer below
where it becomes a Service Data Unit (SDU) which is typically a byte string. Thus a layer n+1 PDU is encoded as a
byte string which is transmitted as a layer n SDU to the peer layer n entity and handed up to the receiver's layer n+1
entity.
In most cases layer n is supposed to treat the SDU purely as a string of bytes, without assuming any internal structure.
(Layer 6, the presentation layer, is an exception.) Each layer should be a "black box", with its interaction with the
adjacent layers defined by the service interface specification in the OSI standards, so that any part of the stack can be
changed without affecting the rest.
In many cases a layer n PDU will consist of a "header" containing information for the peer layer n entity followed by a
"payload" which is a layer n SDU and hence also a layer n+1 PDU, and there is a perception in some fora that any
packet will consist of a header for each layer followed by the application data. However, this is not necessarily the case,
for instance a layer (such as the presentation or session layer in IP networks) may have a recognizable function but no
header fields.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR NIN 003 V1.1.1 (2021-03)
4.2 Current practice
In most systems there is a "protocol stack" consisting of a number of layers as envisaged by ISO/IEC 7498-1 [i.2] but
with the entities forming the stack not corresponding exactly to the seven sets of functionality that it specifies. For
instance, a GTP tunnel in LTE has two instances of layers 3 and 4 (IP and TCP/UDP), one below the GTP layer with
the address serving as a locator and another above with the address serving as an identifier.
TCP and UDP include information from the IP header in their checksum fields, and port numbers in the layer 4 header
are used to identify flows in layer 3 switches. Thus in practice, layers 3 and 4 in an IP network are not independent.
Shallow Packet Inspection is used in layer 3 entities to affect the service a packet receives based on analysis of the
contents of higher-layer SDUs.
4.3 Layering in Flexilink
As with the OSI model, an entity sends information to a peer entity by encoding it in an SDU which is conveyed to the
peer entity by a service implemented by entities which are in some sense the next level down in a stack. Much of the
information which would traditionally be encoded per packet in headers is instead conveyed per flow in control plane
messages, so a layer will not in general correspond to an identifiable "header" in the packet.
The hierarchy is less rigid than in OSI, so that it supports tunnelling (for instance). However, layers are not expected to
examine the SDUs they carry, using control plane negotiation instead of guesswork based on higher-layer headers to
determine the service a flow receives. An important consequence of this is that payloads can be encrypted without
affecting the efficiency of transmission through the network.
4.4 Communicating entities
A network is considered to consist of "nodes" and "links"; each link carries packets between two or more nodes. A node
can have the role of "endsystem" or "switch" or "middlebox". A node is not necessarily a piece of physical equipment; it
may, for instance, be a process running inside a computer.
Traffic is originated and terminated in endsystems; typical endsystems include application processes and audio-visual
equipment. Switches forward packets from their source towards their destination along a "route" which is an ordered set
of links, without inspecting or processing the payloads.
Middleboxes, like switches, form part of a route, but they also process the payload data. An example might be a
function that converts video from one format to another, so a live event that is multicast in high definition can be
forwarded at a lower resolution to a device with a lower-bandwidth connection. Note, however, that many functions that
in IP networks use middleboxes, such as NAT and firewalls, will instead be implemented in the control plane.
Also note that the routing of flows within a computing system is decoupled from the identification of protocols, unlike
IP where port numbers take both roles. The driver software for a network interface should behave as a switch,
forwarding packets according to their flow labels and leaving higher-layer processing to the endsystem process
instances. The control plane messages show which higher-layer protocols are to be used when a flow is set up.
5 Flows
5.1 Background
The task of delivering a packet to a remote system may be divided into two parts: deciding its route through the
network, and transmitting its content. IP was designed for an age in which both parts were implemented by the same
component of the system, for instance a computer called the Interface Message Processor in the case of the ARPANET.
In today's networks the two tasks are usually separated, being respectively control plane and forwarding plane
functions.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR NIN 003 V1.1.1 (2021-03)
Most packets are not an isolated event but are part of a flow, for example a TCP, QUIC, etc., session or an audio or
video signal. In early networks, routing decisions were made independently for each packet, in order to avoid taking up
memory space remembering previous decisions, but as memory became more plentiful "route caching" was used to
reduce the load on the control plane. Now, with technologies such as SDN and OpenFlow, there is a trend towards a
further separation of control and forwarding planes, with routing decisions being applied to flows rather than to
individual packets. The interface between the two planes is a "routing table" which holds a record for each flow
containing the information the forwarding plane needs to forward packets for that flow.
Flows can be aggregated as described in clause 5.3.2.4 of ETSI GS NGP 013 [i.1], with a group of flows that all follow
the same route sharing a single entry in the routing table.
5.2 Flow identification
Currently the flow to which a packet belongs is identified by searching for a match on (typically) five fields in its
header. The searching process requires multiple accesses unless expensive "content-addressable" memory is used. The
Flexilink "basic" service specified in clause 5 of ETSI GS NGP 013 [i.1] replaces the per-flow information in a packet
header with a "flow label" which is an index into the routing table, thus greatly simplifying the forwarding plane front
end and also significantly
...