ETSI proposes non-IP packet technology for telecoms

ETSI proposes non-IP packet technology for telecoms

Technology News |
By Nick Flaherty

The Internet as we know it is fundamentally based on TCP/IP networking. The IPv4 and IPv6 packet structure dominated the zetabits of data that move across all kinds of networks. However there are problems for telecoms networks that want to deliver quality of service and streaming services using TCP/IP.  

The ETSI Non-IP Networking group (ISG NIN) has just released its first three Group Reports on alternatives for TCP/IP. The first report, GR NIN 001, details the shortcomings of TCP/IP for fixed and mobile networks; the second, GR NIN 002, considers testing Non-IP Networking over 5G cellular Radio Access Networks; and GR NIN 003 describes the networking model that is the foundation for the new technology.

“Finding new networking protocols more suitable to the 5G era was essential. These reports set the scene for standardization of technology that meets the requirements of mission-critical systems such as industrial control, intelligent vehicles, sound reinforcement for live events, and remote medicine,” said John Grant, Chair of ISG NIN.

The first ETSI report describes the challenges of IP-based networking for fixed and mobile networks and ways in which new network protocols can result in improved performance and more efficient operation. Topics covered include efficient use of the cellular radio spectrum, naming and addressing (including addressing lifecycle), Quality of Service (QoS) and time-sensitive traffic, security, network management, efficient forwarding, and migration.

Implementing Non-IP networking over 3GPP cellular access recommends approaches to test Non-IP Networking (NIN) using mobile radio access. This includes existing mechanisms specified by 3GPP for both LTE and 5G Radio Access Networks, as well as guidance on enabling a non-IP protocol stack directly atop the 3GPP PHY (physical) radio layer. The Report suggests test scenarios appropriate to proof-of-concept testing for low-power IoT devices, for video and audio services, and for tactile feedback in applications such as remote surgery.

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.

The third report, GR NIN 003, illustrates how the Flexilink technology described in another ETSI Specification, GS NGP 013, 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.

Flexilink is agnostic as to the format and semantics of identifiers and addresses used to specify the destination of a flow. In a network there can, for instance, be some flows routed to IP addresses, others to addresses such as RINA, and others to content identifiers or service names; all are forwarded in the same way, so that the network service is to some extent virtualized. Recursive InterNetwork Architecture (RINA) is a new computer network architecture proposed as an alternative to the architecture of the currently mainstream Internet protocol suite.

Flows need to have identifiers that are unique within any domain through which the flow might pass, for use in control plane messages, and clause of ETSI GR NGP 003 [i.3] describes a possible format. These identifiers are not expected to be visible to applications (except for applications that are concerned with network management), and control plane messages should not require a rigid format for them; unlike IP addresses, they would not be used in the forwarding plane and therefore would not affect packet formats.

Related ETSI articles 

Other articles on eeNews Europe 

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles