[mpls] Catalog for MPLS Metadata

[Vasilenko Eduard <[e-mail]>]

Hi all,

I did think about it a little more and come up with the below.

I could formalize it in the form of a draft if it would be the interest.


Chain of variable size headers could pose a considerable challenge for hardware pipeline. It needs sequence processing to parse it.
The progress of computing power during the last 15 years is mostly related to multi-core and multi-thread parallel processing. Any future-proof architecture should be friendly for parallel processing.
The challenge in processing IPv6 extension headers and their low adoption is partially attributed to the expensive parsing of the chain of variable length headers.
An additional challenge is the size of the key buffer that is used as the key materials to search in switching and forwarding tables. The cost of processing is linear to the key size. It is important to have the flexibility to ignore or discard some headers to compromise on low-cost platforms. Parsing of all headers in the long chain defeats the goals of a low-cost platform. Hence, parsing simplification and flexibility could help to the problem of restricted key buffer too.
MPLS's new metadata blocks must have some indication of their type and length. It is assumed that MPLS metadata blocks would have separate address space from IANA for block types. It is proposed to collect this information in one centralized table that could be called "Catalog".
There is no need for redundancy of this information in particular metadata blocks. It means that the size of metadata blocks could be reduced respectively. Hence, overall this proposal does not increase the size of the packet. Such an advantage is possible only as of the initial architecture decision.
The Catalog is proposed from a sequence of Type/Offset values. One Type/Offset for every metadata block that would follow Catalog.
The size of the Type is proposed as 1 octet, the size of Offset is proposed as 2 octets. It is the discussion point that should the Offset be the number of Octets or should it be 2, 4, or 8 octets in the metadata block. The former case restricts all metadata headers together by 64k octets that is probably enough. The latter could improve the performance by aligning to the memory unit of a particular platform but it would waste some bandwidth because of the need for padding in metadata blocks.
The positioning of the Catalog is proposed at the bottom of the stack (i.e. between MPLS label with BoS=1 and Data Header) to preserve interoperability with current MPLS implementations.
The Catalog should start from "0000" nibble to avoid packet reordering on old LSRs or a nibble that could be requested from IP protocols space (if possible).
The Catalog should finish with the special type of metadata (255?) which means that the Data Header is started from this Offset.
Hence, overall structure of the catalog would be:
0000

RRRR

Type1

Offset1

Type2

Offset2

...

  ...
TypeN

OffsetN

11111111

Offset of the Data Header


RRRR - reserved nibble.
The offset is calculated from "0000RRRR" octet.
The choice to put offset instead of length in the Catalog is explained by the desire to simplify the read of arbitrary Metadata blocks. The offset would show the start of needed Metadata immediately, the size of the block could be calculated by 1 subtraction (OffsetN++ - OffsetN). Additionally, offset would greatly simplify the search for upper-layer protocols that is much needed for middleboxes, filtering, QoS, and load balancing.
The other possibility was to use the length of the Metadata block. The length would push for the addition of all lengths from the catalog to calculate the arbitrary offset to read.
It makes sense to discuss the rule for not to have the ordering of different types of Metadata blocks. The Catalog does permit to easily find any block. Any new block make sense to add at the end. It permits to avoid the recalculation of Offsets for all previous Metadata blocks.
Fixed-size simplified structure of the Catalog permits to optimize parsing in hardware, arbitrary access to any metadata blocks, and easy search for the next layer offset. All of this could greatly improve the chances for market adoption of MPLS Metadata extensions.



Eduard