Networking for the age of virtualization
In traditional networking, each technology has a fixed format for packet headers, which is the same throughout the system, and the headers carry all the information needed to forward the packet to its destination. Line speeds are high enough that hardware assistance in interpreting incoming packets is needed, and new hardware is needed if a new format is to be introduced. This is why the implementation of IPv6 has taken more than 20 years.
Software-Defined Networking (SDN) recognizes that most packets are part of a “flow”, and most of the decisions the system has to make are per-flow rather than per-packet. For instance, the “next hop” from a switch towards the destination will be the same for every packet on a flow; and packets carrying a live audio or video stream will arrive at regular intervals and require to be forwarded promptly, whereas those that are part of a TCP session can join a low-priority queue, being discarded if the queue is full. Furthermore, battery operated constrained IoT devices generally interact with a unique endpoint in their lifetime so a “flow”, kept active for long time, makes possible that the messages are forwarded promptly in order to minimize the battery consumption.
Currently, traditional packet headers are used; this means that typically five separate fields in the packet header must be inspected to identify the flow, and additional protocols are needed to convey any information that isn’t included in the packet headers.
It also means that an application wishing to access a service identified by a domain name, or a virtualized network service, has to find an IP address that identifies the location where the service is provided.
ISG NIN is standardizing the concept of a flow, control plane protocols for managing flows, and appropriate packet formats.
The title, Non-IP Networking, emphasises that the technology is not dependent on IP packet formats or protocols; however, it supports the TCP/IP suite as well as other systems such as Information Centric Networking and RINA.
Packet formats are appropriate to the physical layer technology of each link, for instance a higher-capacity link will support more flows. Introducing a link with a new format does not require any change to the rest of the system.
Recognizing that networks will carry an increasing amount of time-critical traffic – not only live audio and video but also applications promised for 5G such as industrial automation and remote surgery – and that traditional store-and-forward packet networks struggle to reliably achieve the sub-millisecond latencies that some of these applications require, NIN defines two kinds of flow. “Basic” flows provide the best-effort service with queues that is traditional for packet networks, while “guaranteed” flows provide a service for time-critical traffic. The two services can be multiplexed so that all the capacity not occupied by guaranteed service data (including capacity reserved but not used) is available to the basic service.
To provide the lowest latency, the guaranteed service can be implemented in a way that is more like the “routers” that switch point-to-point audio and video. It can also be carried over to other technologies such as TSN; the latency (which will be higher in that case) is reported in the control plane messages that set the flow up.
Our Role & Activities
The Industry Specification Group on Non-IP Networking (NIN) has been set up to standardize a digital communications technology fit for the 21st century.
Our vision is a much more efficient system that is far more responsive to its users.
We have identified a number of technical issues with the current (TCP/IP-based) technology which prevent it delivering the required levels of service without excessive complexity or, in some cases, at all.
The new protocols will provide:
- virtual elimination of delays in forwarding real-world signals: not only audio and video but also tactile feedback and the position of vehicles or industrial robots
- multicasting of live content (such as sports events) to an unlimited number of subscribers
- more efficient use of spectrum and of processing power
- better security, both privacy and resilience to denial-of-service
- better performance when accessing remote content such as web pages
- ways of guaranteeing network service sustainability
- extensibility: packet formats do not have to be the same throughout the system, and introducing new features such as a new kind of addressing only affects the control plane messages
What does this mean for the user?
Elimination of delays in packet forwarding equipment will make conversation more natural, especially in conference calls. A performer’s sound can be sent across the network to be mixed with other performers’ and returned to their headphones. Applications such as remote surgery become possible.
More efficient processing extends battery life in handsets.
Privacy is improved: devices do not need to have IP addresses, and a server does not need to know a client’s address or location in order to reply to its request. Before any exchange of data takes place the server can require as much or as little authentication of the client’s identity as is appropriate to the application. It will be much easier to discover where your device is sending data to.
Downloads will be faster, and there will be less “buffering delay” when watching streamed content. New business models can be explored based on improved identification of content and quality auditing.
What does it mean for the operator?
The whole system becomes much simpler and therefore cheaper to build and to operate. Many middle-box functions, such as address translation, firewalls, header compression, and transport-layer optimisers, are eliminated or incorporated into the control plane procedures. Mobility is supported natively instead of needing tunnelling layers to be added.
The service for media streams provides multicasting and ultra-low latency (typically less than 10µs per hop) as standard. As well as live broadcasting (such as of sporting events) it can be used to distribute recorded content to local caches and to distribute software updates.
Many of the protocols needed by current systems, such as DNS, ARP, SIP, SDP, and RSVP, are incorporated into the control plane procedures. This, along with a dramatic reduction in packet header sizes, reduces the amount of capacity on the air interface that is taken up by protocol overheads.
The forwarding plane can be implemented entirely in logic (hardware), and thus needs much less power than is needed for per-packet processing by software. Simplified protocols and elimination of the need for header compression reduce processing power requirements further.
How do we get there?
The new technology can be carried over IP networks, and IP packets can be carried over the new technology. Thus, the new technology can be introduced incrementally, in the form of “islands” where internal traffic benefits from the new levels of service and there is seamless transition to the legacy technology at the edge. This can be done as part of the normal processes of expanding networks and of replacing end-of-life equipment.
An example would be where a new network is being built to support 5G: core, RAN, and MEC can be implemented with the new technology. When an application connects a socket to a service, the system can check whether that service is available at the edge and if so connect directly using the new technology. This check might need more information than would be provided in the DNS look-up used in legacy systems, e.g. to see whether a cached copy of a particular piece of content is available. Otherwise, the connection goes through the User Plane Function; much of the processing of legacy packet headers is transferred from the UE to the UPF, saving battery in the UE, and the amount of processing required in the UPF is similar to the NAT procedures common in today´s Internet access.
Participation in the Non-IP Networking Industry Specification Group is open to all ETSI members as well as organizations that are not members, subject to signing ISG Agreements. For information on how to participate please contact [email protected]
A full list of related specifications in the public domain is accessible via the NIN committee page.
ISG NIN will also act as responsible body for the maintenance of ISG NGP Deliverables if need arises. The specifications published by NGP are accessible via the standards search on our website.
Blog from the NGP Industry Specification Group now Non-IP Networking (NIN)
The direct link to refer to this blog is https://www.etsi.org/newsroom/blogs/blog-nin
IPv6 is finally beginning to be adopted, more than two decades after its specification was published in RFC 1883. Why did it take so long? And how will NGP avoid the same problems?
Internet Protocol (IP) is a "connectionless" technology, in which all the information necessary to deliver a packet to its destination must be in the packet header. This includes the destination address and the address to be used for sending a reply, as well as other information regarding the service the packet should experience. The format of this information has to be the same throughout the system, so that it can be understood by any switching equipment the packet might pass through. IPv4 and IPv6 use different formats, so if support for IPv6 is to be added to an IPv4 network, all equipment in the network must be updated so it can process IPv6 headers. Only when that has been done can IPv6 be used.
When IP was first specified, packet headers were processed at each switching point by software running in a general-purpose computer. Since then, transmission speeds have increased by more than processing speeds, so more of the processing of headers has to be done in hardware. Technologies such as Software Defined Networking (SDN) recognize that most packets are part of a "flow" such as an audio or video stream or an exchange of information between a browser and a web site; decisions about how each flow should be forwarded are made by software and loaded into a "routing table" at each of the switching points. The hardware in the switch reads the packet header and searches the routing table to find the entry that matches it.
Thus, adding support for IPv6 addresses doesn't just need a software upgrade, it needs new hardware that is able to read IPv6 headers in addition to the existing IPv4 hardware.
GS NGP 013 specifies a system (with the working title Flexilink) in which the packet header carries a "label", which is an index into the routing table, and all other information is carried in control plane messages and is thus sent once for each flow instead of in every packet: the ultimate in header compression. Routing table entries in each switch only need to show the action to be performed by that switch, typically the output port number and the label for the next hop. Supporting a new form of addressing (such as content-centric, or using a domain name directly as an address) only needs a software update to the control elements, and no change to the hardware. The packet format can be different for different kinds of link, for instance having a larger field for the label on links that can carry more flows, but this only affects equipment designed for that kind of link, which will in any case have hardware that is specific to that link type.
Any part of an IP network can be replaced by Flexilink without affecting the rest of the network. Depending on requirements, IP packets (either version) can be carried with their headers included, in the same way as over MPLS, or the headers can be stripped on entry and added back on exit. In the latter case the routing table has to hold the necessary information to construct the IP header, but if the IP network would be doing address translation a similar amount of information would need to be held in any case.
Thus with Flexilink a single hardware implementation is able to support multiple addressing schemes including both IPv4 and IPv6.
Almost every packet on a digital network is part of a "flow", a sequence of packets from the same source to the same destination. These flows are of two types:
- they either carry a continuous stream of data such as an audio or video signal
- or transfer information between processes running in computers, as in a TCP session
We can think of the former as "AV" flows and of the latter as "IT" flows. For many applications, AV flows are sensitive to "latency", which is the time between a packet being transmitted by the sender and received at its destination; in a phone call, for example, longer delays make it difficult to have a natural conversation. New applications proposed for 5G, such as those involving augmented or virtual reality, or tactile feedback, will have even more severe requirements. For IT flows, if latency is important at all it will be the average over time that matters, whereas for AV flows it is the delay for the slowest packet.
Current-generation networks were originally designed as IT networks, carrying IT flows, and have had various features added to assist AV flows, which increase complexity but still do not provide the best service for these flows.
One of the main drivers for the formation of ISG NGP was operators' need to make more efficient use of spectrum. While New Radio allows more bits to be carried, by some estimates half of those bits are unnecessary overhead. NGP is investigating how these overheads can be reduced, while at the same time providing the kind of performance (such as lower latency) that the new services proposed for 5G will need.