Subject: Token Cell Routing

From: Stewart Bryant <[email-masked]>
Date: Fri, 16 Apr 2021 12:51:43 +0100

Alex and I have recently uploaded 

https://datatracker.ietf.org/doc/draft-bcx-rtgwg-tcr/ <https://datatracker.ietf.org/doc/draft-bcx-rtgwg-tcr/>

Token Cell Routing (TCR) is a new packet design submitted as a design concept that incorporates what we believe to be unique, but quite powerful features, that we have not previously seen applied at the Network Layer.

A packet consists of a series of linked tokens that specify the network actions to be taken together with any associated parameters. By using pointers to explicitly specify the items and metadata that the forwarder is to process rather than relying on linear concatenation and parser logic, we can build some powerful forwarding structures as shown in the examples provided in the draft.

When we were formulating this design we were impressed by the way that we could introduce new packet forwarding concepts within the original framework that we set out. This is often the sign that the fundamentals of the architecture are correct.

There are two key concepts that we think make this a powerful construct. The first is the use of pointers within the packet tokens that allow the packet composer to describe the parsing path rather than requiring the forwarder to deduce this from the packet perhaps by walking a concatenated list of extension headers. I have not seen this done before in any mainstream network layer protocol. The second is the use of LTV rather than TLV in these extension components allowing the T to be extensible and the T and the V to be put into a longest match engine to do a parameterised lookup. This is a bit like the SR Network Programming use of parameters as a suffix to an IPv6 address and the ISO-8474 use of the AFI as a prefix to the address, but again I think potentially more powerful.

Whilst we doubt that packets will often be constructed using all the feature, the simplicity and flexibility of the approach encourages us to think that the ideas are of significant utility.

The TCR design shown in this draft is a packet design in its own right, and has properties that look to be interesting in the sub-IP and limited domain space, where utility is more important that backwards compatibility. However, the token structure itself looks as if it would have utility in the area of metadata and extension headers, freeing packet designers from the constraint of needing to parse a concatenated set of potentially unrelated metadata components to find the one that was applicable to a particular node. We hope to publish our thoughts on this aspect of the design in the next few weeks.

If anyone has any questions or comments we would be pleased to address them.

If anyone is interested in working with us to develop this concept further we would welcome the opportunity to work with you.

Best regards

Stewart Bryant and Alexander Clemm