|
GROUP SPECIFICATION
Next Generation Protocols (NGP);
Flexilink: efficient deterministic packet forwarding
in user plane for NGP;
Packet formats and forwarding mechanisms
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) 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 GS NGP 013 V1.1.1 (2018-09)
Reference
DGS/NGP-0013
Keywords
3GPP access, core network, fixed networks,
flexilink, IP, MPLS, next generation protocol,
non 3GPP access, NR, QoS, switching
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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:
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
If you find errors in the present document, please send your comment to one of the following services:
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 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI GS NGP 013 V1.1.1 (2018-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Packets and flows . 8
5 Basic service . 9
5.1 Service characteristics . 9
5.2 Encapsulation . 9
5.3 Payload . 9
5.3.1 Size . 9
5.3.2 Format . 9
5.3.2.1 General . 9
5.3.2.2 User message. 10
5.3.2.3 Integrity check . 10
5.3.2.4 Aggregated flows . 10
6 Guaranteed service . 10
6.1 Service characteristics . 10
6.2 Packet format . 11
6.3 Synchronous service . 11
6.3.1 Slots . 11
6.3.2 Alignment of allocation periods . 12
6.4 Asynchronous service . 12
6.4.1 General . 12
6.4.2 Alignment of allocation periods . 12
7 Carriage of one service in another . 12
7.1 Guaranteed service packets as basic service payloads. 12
7.2 Basic service packets as guaranteed service payloads . 13
7.3 Legacy packets as basic service payloads . 13
7.4 Legacy packets as guaranteed service payloads . 13
8 Encapsulation formats . 13
8.1 General . 13
8.2 Formats for continuous transmission . 14
8.2.1 Common elements . 14
8.2.2 1 Gb/s Ethernet PHY . 14
8.2.2.1 Frame format . 14
8.2.2.2 Background octet stream . 15
8.3 Formats for intermittent transmission. 15
8.3.1 General . 15
8.3.2 Basic service packets in legacy networks . 15
8.3.3 Wireless links . 16
Annex A (informative): Assessment against KPIs . 17
A.1 KPIs for Naming and Addressing . 17
ETSI
---------------------- Page: 3 ----------------------
4 ETSI GS NGP 013 V1.1.1 (2018-09)
A.2 KPIs for Performance . 17
A.3 KPIs for Mobility . 17
A.4 KPIs for buffering . 18
A.5 KPIs for Multihoming . 18
A.6 KPIs for Protocol and Energy Efficiency . 18
A.7 KPIs for Security and privacy . 20
A.8 KPIs for traffic Management . 21
A.9 KPIs for Interoperability . 21
A.10 Deployment effort . 22
A.11 Revenue opportunities . 22
Annex B (informative): Authors & contributors . 23
History . 24
ETSI
---------------------- Page: 4 ----------------------
5 ETSI GS NGP 013 V1.1.1 (2018-09)
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 Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Next Generation
Protocols (NGP).
Modal verbs terminology
In the present document "shall", "shall not", "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.
Introduction
ISG NGP is tasked with finding a system of packet routing that does not suffer from the problems operators have
experienced with LTE and also optimizes the performance, efficiency, and scalability of new services proposed for 5G.
Internet Protocol (IP) is not fully able to meet these requirements for a number of reasons which have been widely
documented. Many of the constraints that applied when IP was developed, around 1980, (such as memory size) are no
longer an issue, while other considerations that are important now (such as mobility and latency) were not an issue then.
Furthermore, back then all processing had to be done by code running on a CPU, whereas now many tasks can be done
more efficiently by dedicated logic in a System-on-a-Chip (SoC).
Most packets are part of a "flow" such as a TCP session or a video stream. Increasingly, there is a separation between
the processes of deciding the route packets will follow and of forwarding the packets, for example in Software Defined
Networking (SDN) and Control and User Plane Separation (CUPS). This is taken to its logical conclusion by specifying
a system in which routing decisions are taken per-flow by control plane code, and per-packet processing is made simple
enough that it can be implemented entirely in logic.
The system provides two separate services, a "basic" service suitable for traditional statistically multiplexed packet data,
and a "guaranteed" service providing the lowest possible latency for continuous media, not only audio and video but
also signals used in industrial automation and newer services proposed for 5G such as tactile feedback. Implementing
these two services and multiplexing them together on communication links is less complex than attempting to serve
both kinds of traffic with a single service.
ETSI
---------------------- Page: 5 ----------------------
6 ETSI GS NGP 013 V1.1.1 (2018-09)
The control plane procedures for managing flows are not specified in the present document. The system has been
prototyped using the signalling messages specified in ISO/IEC 62379-5-2 [i.1]; messages containing similar
information in other formats can also be used.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI GS NGP 013 V1.1.1 (2018-09)
1 Scope
The present document specifies user plane packet formats and routing mechanisms for 5G core and access networks,
based on the requirements documented in ETSI GS NGP 012 [i.3] and taking technologies from ETSI
GR NGP 003 [i.2] as appropriate.
It does not specify the control plane procedures for managing routes.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 document is necessary for the application of the present document.
[1] IEEE 802.3™-2008: "Local and metropolitan area networks - Specific requirements - Part 3:
Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical
Layer Specifications".
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] ISO/IEC 62379-5-2:2014: "Common control interface for networked digital audio and video
products - Transmission over networks - Signalling".
[i.2] ETSI GR NGP 003: "NGP Next Generation Protocol; Packet Routing Technologies".
[i.3] ETSI GS NGP 012: "KPIs for Next Generation Protocols Basis for measuring benefits of NGP".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
basic flow: flow with no guarantees as to latency or whether packets will be dropped
basic service: packet transmission service carrying basic flows
ETSI
---------------------- Page: 7 ----------------------
8 ETSI GS NGP 013 V1.1.1 (2018-09)
flow: specification for how packets are forwarded from source to destination(s), and interpreted at the destination
guaranteed flow: flow offering a specified latency and specified probability of packet loss for packets which are
transmitted at a specified rate
guaranteed service: packet transmission service carrying guaranteed flows
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Program Interface
ATM Asynchronous Transfer Mode
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CUPS Control and User Plane Separation
FCS Frame Check Sequence
FF FlipFlop
IP Internet Protocol
ls least significant
MAC Media Access Control
MPLS Multi-Protocol Label Switching
ms most significant
MTU Maximum Transmission Unit
PHY PHYsical layer, or hardware that implements an interface to it
PTP Precision Time Protocol
RAM Random Access Memory
SDN Software Defined Network
SFD Start-of-Frame Delimiter
TC CYBER Cybersecurity Technical Committee (ETSI)
TCP Transmission Control Protocol
UDP User Datagram Protocol
XOR eXclusive OR
4 Packets and flows
A packet shall consist of a payload and encapsulation. The payload shall be an octet string which is conveyed unaltered
(apart from the effect of transmission errors and equipment faults) from source to destination. The encapsulation shall
depend on the medium over which the packet is conveyed.
NOTE 1: Thus in many cases the encapsulation will change as the packet progresses through the system.
Each packet shall be associated with a flow.
NOTE 2: Management of flows is handled by the control plane, and is thus out of scope for the present document.
The action to be taken when a packet is received at a network element shall be defined by the flow with which it is
associated; it shall not (except at a destination of the flow and as provided in clause 5.3.2.3) depend on the content of
the payload.
NOTE 3: The route taken by packets associated with the flow is established, and any required resources reserved,
before the first packet is sent. This allows security checks to be made before any data is transmitted.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI GS NGP 013 V1.1.1 (2018-09)
5 Basic service
5.1 Service characteristics
The service specified in clause 5 is intended for the kind of communication between software processes that commonly
occurs in computer systems. Transmission will typically be intermittent, so that reservation of capacity would be
inappropriate and thus latency is undefined and packet loss due to queue overflow can occur.
Each flow shall have exactly one destination. It may have more than one source.
NOTE 1: A flow with more than one source would be similar to an MPLS Forwarding Equivalence Class.
NOTE 2: Multicasting not supported by basic flows, to simplify implementation of the forwarding process.
Typically, basic flows will be used in pairs, one in each direction, so that messages can be acknowledged
and dropped packets repeated. Multicasting is supported by the guaranteed service (see clause 6).
Switches may support facilities similar to those specified for IP networks to prioritize particular classes of traffic. Such
facilities would be invoked by control plane messages (with the traffic class being a property of the flow and not
signalled in packet headers) and are thus out of scope for the present document. Consideration should be given to
whether they are necessary, or whether all traffic for which they might be useful can use the guaranteed service.
NOTE 3: These facilities would add complexity, but could be useful for sharing out capacity in the context of
network slicing, and possibly also for compatibility with legacy systems.
5.2 Encapsulation
The details of packet formats, including the encapsulation, shall be defined separately for each type of link (see
clause 8).
The payload should be preceded by a label which serves as an identification of the flow which is local to the link.
The encapsulation shall indicate the number of payload octets, either directly or by marking the start and end of the
packet or of the payload.
5.3 Payload
5.3.1 Size
The payload of a packet transmitted by an end system shall be any number of octets in the range 1 to 2 000 inclusive.
NOTE 1: The lower limit is much less than for Ethernet. Zero-length payloads are not supported because support
for them has been found to increase complexity in the forwarding logic.
NOTE 2: The upper limit supports tunnelling of maximum-size Ethernet envelope frames; per-packet overheads are
minimal, so there is no incentive to support larger packets. A fixed upper limit eliminates the need for
path MTU discovery.
Switching equipment shall support payload sizes up to 2 016 octets.
NOTE 3: That allows for up to 16 octets of inner labels.
5.3.2 Format
5.3.2.1 General
The payload of a basic service packet shall consist of a user message and an integrity check.
The form taken by the integrity check shall be signalled in the control plane messages that set the flow up. The user
message shall consist of all payload octets that are not part of the integrity check.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI GS NGP 013 V1.1.1 (2018-09)
5.3.2.2 User message
The syntax and semantics of the user message shall be negotiated by the source and destination entities as part of the
process of setting the flow up.
The network shall treat the user message as an unstructured octet string, and shall not take any action that is based on
the value of any octet in the string.
5.3.2.3 Integrity check
Integrity check formats supported by the control plane messages shall include:
• No integrity check; all payload octets are part of the user message.
• Last two payload octets are coded with a nonzero value such that the sum of the set of 16-bit numbers derived
as follows is a multiple of 65535. If the payload is an odd number of octets, a zero octet is inserted before the
penultimate octet (i.e. at the end of the user message). Then, the payload is divided into pairs of octets, each
holding a 16-bit number, with the more significant half of each number being in the first octet of the pair.
• Last four payload octets hold a CRC calculated as specified in clause 3.2.9 of IEEE 802.3-2008 [1].
• Last four payload octets hold longitudinal parity, calculated as specified in clause 8.2.2.
NOTE 1: The integrity check covers the user message but not the header, which has its own integrity check, and is
changed at each switching point.
The integrity shall be checked by the destination entity. It may be checked at other points in the network, and the packet
discarded if the check fails.
NOTE 2: In many cases corruption of a packet will be sufficiently unlikely that checking the integrity at
intermediate nodes is not worth the effort.
5.3.2.4 Aggregated flows
A flow may be created that gathers together a bundle of other flows, by prepending a label that identifies the flow
within the bundle (the "inner" label") to the payload of each packet.
NOTE 1: This is similar to an MPLS "push" operation, but unlike with MPLS the existence of the inner label is a
property of the outer (aggregated) flow and not indicated in the packet format; the format of the inner
label only needs to be understood by the network elements at the ends of the aggregated flow, not by any
intermediate switches through which it passes.
Integrity check fields within the payload should not be adjusted to include the inner label. The format of the inner label
shall include its own integrity check.
NOTE 2: It will usually be appropriate for an aggregated flow to be signalled as "no integrity check", so that
switches through which it passes do not perform any checks on the payloads.
6 Guaranteed service
6.1 Service characteristics
The service specified in clause 6 is intended for continuous media such as digital audio and video, tactile feedback, and
position of vehicles and industrial robots. However, it can also be used for other traffic.
NOTE 1: If the guaranteed service is used for file transfers, the data rate can be negotiated via control plane
messages and packets will not be dropped due to buffer overflow, so the transport protocol can be greatly
simplified.
Each flow shall have exactly one source. It may have more than one destination.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI GS NGP 013 V1.1.1 (2018-09)
Each flow shall support a defined number of packets per second, negotiated by the control plane protocols when it is set
up, and should have resource allocated such that latency is bounded and packets will not be lost due to congestion.
The service on each link shall be either synchronous as specified in clause 6.3 or asynchronous as specified in
clause 6.4.
NOTE 2: A synchronous service can achieve lower latency than an asynchronous service.
6.2 Packet format
Each guaranteed service packet shall consist of a header and 0 to 63 payload octets.
The header shall be a single octet formatted as:
ms bit: odd parity
1 bit: flag f (see below)
ls 6 bits: n, the number of payload octets
The flag f shall not be used for forwarding, but shall be available for use by end systems; 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.
NOTE 1: Unlike basic service packets, the header does not change when the packet is forwarded and does not need
to be read in order to identify the flow; this is potentially useful for forwarding in the optical domain.
NOTE 2: See clause 5.2.2 of ETSI GR NGP 003 [i.2] for the rationale behind the payload size.
6.3 Synchronous service
6.3.1 Slots
Each link between network elements that is capable of carrying a synchronous service shall be formatted into "slots",
and the slots grouped into "allocation periods". Each slot shall be 64 octets in length. The link may also carry symbols
(e.g. framing) that are not part of any slot.
Each guaranteed flow shall be allocated one or more slots per allocation period. The framing on the link shall show
where each allocation period starts, and a flow's allocation shall be of th
...