4th -8th November 2024
To ensure that SMEs have a front-row seat to telecoms standards making, our Standards Champion, Andy Reid, attends key standards meetings to observe, participate in conversations and report back on key themes and discussion points.
Here, Reid shares his reflections on the recent IETF meeting in Dublin.
What is the Internet Engineering Task Force (IETF)?
The IETF is the body that sets technical standards for the Internet. It sets its scope as the middle layers of the ‘seven layer stack’, especially at layer three (network layer) and layer four (transport layer).
An early maxim of the IETF was “IP over everything and everything over IP”, deliberately embracing the idea that there may be many different layer one and two technologies and there may be many different application layer protocols, but they can all enjoy universal connectivity across all sorts of physical networks by using the same middle layer protocols.
Its foundational protocols, the Internetworking Protocol (IP) and the Transmission Control Protocol (TCP), commonly lumped together as TCP/IP, are respectively for these two layers. For example, since 4G, mobile has used IP as its basic layer three protocol for all services including voice. Conversely, at the application layer (layer seven), the world-wide web (WWW) was born in the IETF, but it was fairly quickly divested as a separate body - the world-wide web consortium (W3C) - allowing the IETF to retain its focus on the middle layers.
The IETF has in-person meetings three times a year and broadly rotates those between North America, Europe, and the Far East. As the body that defined email as we currently understand it, it will not be a surprise that a great deal of IETF work has always taken place on email discussion lists between meetings. The in-person meetings are used more for presenting new ideas and inputs, as well as driving for consensus on established items of work.
A number of factors make IETF somewhat different to most other standards development organisations (SDOs), and these also make participation by SMEs and academics significantly easier:
- Participation is on an individual expert basis not as a representative of an organisation;
- Fees are only charged for attending meetings (there are also fees for remote attendance but funds are available to cover these if the fees present an obstacle, for example for PhD students);
- There is a very active agenda to welcome new attendees and help them navigate meetings;
- The Internet Research Task Force (IRTF) meets seamlessly with IETF which explicitly works on pre-standardisation topics and actively welcomes academic involvement;
- The working methods favour simpler focussed solutions which have some level of demonstrated implementation over ‘top-down’, large scale, programme driven solutions;
- The IETF was founded by engineering academic researchers in the first place!
What were the hot topics in Dublin?
There are some 128 active IETF working groups and 15 active IRTF working groups. In addition to the established working groups, there are sessions discussing the formation of new working groups (charmingly called ‘birds of a feather’, or BoF for short) and other ah-hoc side meetings. At this Dublin meeting there were normally eight working groups meeting in parallel at any one time. The following observations therefore inevitably reflect some of my own areas of interests, but hopefully capture the sense of where the active work is at.
General themes
Over recent years a number of new protocols in IETF have arisen out of the development advanced programmable network processor chips, including those based on the open ‘P4’ architecture. These chips are able to process packet headers with a more complex structure of header fields and with arbitrary length. A notable example of such a protocol is segment routing using IPv6 (SRv6) which makes use of flexible header extensions in the IPv6 header to control the route an individual packet takes through the network. The work developing these protocols is now maturing but there is more this latest generation of network processor could achieve. There is a sense that SRv6 may be just the beginning of more programmable packet forwarding.
Another general theme across a number of working groups was the inclusion of enhanced security mechanisms, for example, upgrading authentication and encryption mechanisms.
Data centre routing
The growth of large language model AI systems like ChatGPT, is driving a huge volume of networking within data centres. This is pointing to specific enhancements to some protocols to optimise them for data centres. For example, topology discovery is operationally quite different in data centres compared to general networks as most data centres are designed to have an explicit and regular spine and leaf topology. In data centres, topology discovery protocols are really detecting failures in the intended topology, not really discovering new topology. Exploiting this knowledge of the intended topology design, opens up the possibility of very much faster failure recovery and overload control protocols.
Collaboration with 3GPP on 6G mobile
This ad-hoc early morning session was mainly for information to IETF attendees about 6G including the working methods of 3GPP, its 6G work programme, and the details of the liaison process between IETF and 3GPP. The session demonstrated the commitment of IETF to work with 3GPP on the development of 6G, for example, to work together and agree the extent to which new protocols like SRv6 will play in 6G and how tunnelling protocols might converge.
Intent based management and use of AI
There has been a lot of recent activity facilitating the use of AI in the operations and management of networks. For example: the use of AI to analyse traffic and network fault data in order to make automated responses to failures and abnormal traffic conditions; and the use of AI to interpret input from operations staff given in highly summarised form, often in natural language and translate this input or ‘intent’ into detailed operational actions in the network.
These AI systems are not themselves normally the subject of standardisation, however, they do interact with the management interfaces of the network systems. They rely on the monitoring data made visible through the management interfaces and the configuration options that can be configured through the management interface. These management interfaces (generally YANG models in IETF) are therefore a focus for activity on intent based management and AI based network automation.
QUIC and reworked transport layer
Around 10 years ago Google took a completely fresh look at the transport layer in order to address a number of issues arising with the original TCP (which is now 50 years old) with the transport layer security (TLS) added on top when applied at data centre scale. The result was QUIC. Google presented their work to IETF early on it has now been developed into a proposed standard (IETF doesn’t actually declare a standard until after many years of active use) in 2021. Since then, there has been rapid take up by browsers and servers and a significant and growing proportion of all Internet traffic is now using QUIC.
Reworking something as fundamental as the transport protocol has a knock-on impact including the security aspects of many protocols and this is driving work in a multiple working groups.
Better integration with distributed applications including IoT
For a number of years, there has been ongoing work with the IRTF on developing networking beyond forwarding packets to a network address. For example, information centric networking (ICN) has been developing protocols based on finding named content directly. At the same time, compute in the network (COIN) has been looking at what more general compute functions can be carried out in the network by exploiting IPv6 extension headers and the flexibility of the BGP routing protocol. In addition, there has been work looking at the protocol optimisation for very low power IoT devices which also considers the application layer protocols, for example based on REST interfaces in a micro-services architecture.
While these specific activities each have a tightly defined scope according to the working methods of IETF and IRTF, they also reflect a growing broader trend. Namely, to look for better solutions for how the micro-services architecture of distributed applications integrate better with networking, especially for IoT devices and other automation devices such as factory robots. This seems likely to be a prominent area in the next few years, especially as it is also of growing concern within 3GPP for ‘industry vertical’ solutions within 6G.
Quantum networking
At the tip of the iceberg, quantum key distribution solutions are starting to emerge as commercial services. Below this tip, there is significant research activity on more generalised distributed quantum computing and associated quantum networking. This is at early stages - there are there are still many technology challenges - but recent progress across the range of these technologies is creating a significant interest in the general architecture of quantum networking and how this relates to ‘classical’ networking architecture.
IRTF has a research working group on ‘quantum Internet’. In general, the working group is acting as a forum for sharing information on quantum networking, developing appropriate system architecture, liaising with other interested bodies, and exchanging experience on operational control and management (this should lead to management interface standards). The working group is developing an architecture for quantum networking, starting by noting a strong synergy with the layers of classical networking. There are some interesting questions on how to define quantum connectivity given the objective is an entangled quantum state that coexists in two or more locations simultaneously and also noting that the transfer of classical information is also an important part of quantum networking.
Why Get Involved?
IETF is the primary body for all things related to layer three protocols (data plane and routing/control), layer four transport protocols, the Internet domain name system (DNS), and the management interfaces for these systems. Assuming your areas of interest overlaps with these, as standards bodies go, IETF has particularly low barriers to involvement.
All information is publicly available including the formal published documents – mostly called ‘request for comments’ (RFCs) - all working draft documents, and even all emails on the email lists of the working groups. You can search and navigate these at will and freely subscribe to the email lists of the working groups. There is no membership fee and great efforts are made to keep the meeting attendance fee to a minimum.
It is also an interesting time to get involved with IETF. As some of the current major activities are maturing, there is a general sense that people have got time and mental space to be interested in what might come next. So, if you have good ideas which relate to networking and transport layers, use and operation of domain names, or the operational management and control of these, then IETF and/or IRTF is the place to get involved.
It is also worth noting that while membership is as an individual expert, this does not mean that commercial considerations are ignored. There is a well-established intellectual property policy (noting that in IETF, the abbreviation ‘IP’ will not be understood as intellectual property but as the internetworking protocol, probably its most important protocol!). And, of course, the big commercial players will work to protect their commercial interests. However, there are also many IETFers who are genuinely dedicated to keeping fresh ideas coming in, in keeping with the origins of IETF.
