Succesful Internet protocols evolve

Internet protocols are an essential part of our online experience. Over the last decades, a variety of protocols have been proposed, implemented and standardised within the IETF. The The first step to allow BGP implementations to be programmed is to have a clear understanding of how the BGP protocol operates and how it processes and sends messages. If we ignore the establishment of BGP sessions and the detection of failures, all BGP implementations need to implement the workflow described in the figure below.

In less than forty years, computer networks and the Internet in particular moved from a simple research project into being a global infrastructure upon which our society relies more and more. Billions of devices use a variety of protocols to exchange packets and provide a wide range of services, from entertainment to mission critical services. There are two very different types of Internet protocols: the data plane protocols (TCP, HTTP, TLS, …) that hosts use to exchange data and the control plane protocols (OSPF, BGP, PIM, …) that are only used by routers.

The specifications developed within the IETF define the protocol messages and a state machine, or an equivalent representation in natural language, that indicates when messages can be sent and how to respond. These protocol specifications are not static. Internet protocols continuously evolve to improve performance or address new use cases.

To illustrate this evolution, it is interesting to look the evolution of several of the most important Internet protocols. Their evolution can be observed through different metrics. Most Internet protocol specifications use the key words defined in RFC2119 to document implementation requirements. Each of these key words in a standards-track RFC corresponds to a precise requirement that must be supported by implementations.

Internet specifications started to adopt the RFC2119 during the first decade of 2000s. The figure below shows the evolution of the utilisation of these key words in the standards-track documents that have been adopted by the working groups that are responsible for three routing protocols : BGP, PIM and OSPF and two host protocols: TLS and HTTP. Similar results can be obtained for other succesful Internet protocols.

As an illustration, BGP was initially defined in RFC1771. This RFC did not include the RFC2119 key words. They only appeared in RFC4271 and the companion documents. BGP-4 was specified in 57 pages in 1995. Today, a BGP implementation must support more than 40 standards-track RFCs. In terms of RFC2119 key words, the complexity of BGP-compliant implementations has more than doubled during the last decade. The other protocols shown in the figure followed a similar evolution.

The extensibility of Internet protocols is clearly one of their key requirements. Protocols address this requirements by using extensible message formats (e.g. RFC5234RFC8259RFC4506). Unfortunately, this does not guarantee that it will be possible to easily extend the implementation. Protocol implementations are usually considered as blackboxes that interact with :

• the upper layer protocol using a standardised or proprietary API
• the lower layer protocol using its own API
• the management protocols such as SNMP by exposing a MIB
• other implementations of the same protocol by exchanging messages

These interactions are illustrated in the figure below.

Unfortunately, none of these interfaces take extensibility into account. To address the extensibility of Internet protocols in a generic manner, we propose to pluginize existing and future Internet protocols. Pluginizing means that we propose to define a standardised API that is exposed by all compliant implementations of a protocol. Thanks to this API, it will be possible to extend the features supported by an implementation using executable code, that we refer to as plugins, supplied by the user or the upper layer protocol. This is illustrated in the figure below assuming that the plugins are executed by an eBPF virtual machine.

We have already demonstrated the feasibility of executing eBPF plugins inside implementations of the QUIC, BGP and OSPF protocols in the following conference papers:

• Thomas Wirtgen, Cyril Dénos, Quentin De Coninck, Mathieu Jadin and Olivier Bonaventure. The Case for Pluginized Routing Protocols. 2019 IEEE 27th International Conference on Network Protocols (ICNP), pages 1-12, October 2019. IEEE.
• Quentin De Coninck, François Michel, Maxime Piraux, Florentin Rochet, Thomas Given-Wilson, Axel Legay, Olivier Pereira and Olivier Bonaventure. Pluginizing QUIC. SIGCOMM ‘19: Proceedings of the ACM Special Interest Group on Data Communication, pages 59-74, August 2019.

Future blog posts will explain how we generalise the approach.