Modernising the way packets are forwarded

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.

When the TCP/IP protocol suite was devised, around 1980, memory was a scarce resource so switches and routers kept as little information as possible; all the information needed to route a packet to its destination had to be in the packet header. Thus each packet was a separate event, like a letter arriving at a postal sorting office. However, in practice most packets are part of a sequence or "flow", and different kinds of flow need a different service. For instance, in a live audio or video stream packets are sent at regular intervals, and need to arrive at their destination at regular intervals; this can be assured by reserving resources along the route the packets will follow. Other kinds of flow consist of packets that are sent at unpredictable intervals, so reserving resources is not appropriate; these flows simply need the packets to arrive as soon as possible.

Memory sizes have increased by a factor of about a million, so information about each flow can now be stored in the network, and technologies such as SDN are used to control the kind of service each flow receives. But packets still have IP headers, and often Ethernet headers as well.

A typical scenario is as follows:

1. The application asks for the IP address that corresponds to the domain name with which it wishes to communicate, which is found using DNS.
2. It creates a "socket" which is identified by a 4-byte "handle" and associates the IP address with it.
3. To send a packet, it simply supplies the handle (to identify the flow) and the data.
4. The operating system then builds a header containing the IP address and various other information, and an Ethernet header containing a MAC address which it has found using ARP.
5. This packet is then sent to a network switch which searches its routing table for a match on various fields in these headers, to work out which flow the packet belongs to and hence how it should be forwarded.

It would be much simpler and cleaner for the packet header to simply contain an index to the entry in the routing table, thus identifying the flow direcly, along with per-packet information such as the data length. Instead of the DNS look-up, the application can ask for a route to the domain name, service, content, etc, it requires, and can specify the level of service required. Information which is currently conveyed by protocols such as SDP can be carried in the same messages. New types of service (different priority mechanisms, perhaps) can be supported by new fields in the routing table, without needing to change the format of packet headers. New forms of address (such as content-centric) can be supported with nothing more than a software update in the control plane.

A system using these methods has been prototyped and is described in clause 5 of GR 003, available from the Specifications tab.