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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
