Frame compatibility across network protocol version

1. A method comprising:

receiving, by a network device in a mesh network, a type-length-value (TLV) element;

determining, by the network device based on both a first type identified in a type field of the TLV element and a first version of a network protocol implemented by the network device for processing the TLV element, an expected length of a value field of the TLV element, wherein:

the first version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have the expected length,

a second version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have a second expected length different from the expected length, and

the expected length is greater than zero; and

processing, by the network device, the value field up to the expected length.

2. The method of claim 1 , wherein determining the expected length of the value field is further based on a value in a sub-field of the value field.

3. The method of claim 2 , wherein the value in the sub-field identifies a number of entries in a second sub-field.

4. The method of claim 1 , wherein the expected length of the value field is equal to or shorter than a length of the value field included in a length field of the TLV element.

5. The method of claim 1 , wherein:

processing the value field up to the expected length comprises processing the value field up to the expected length according to the first version of the network protocol; and

the TLV element is compatible with the second version of the network protocol, and

the second version of the network protocol is newer than the first version of the network protocol.

6. The method of claim 5 , wherein the value field includes a sub-field beyond the expected length that is included in the second version of the network protocol and is not included in the first version of the network protocol.

7. The method of claim 5 , wherein:

a first TLV element compatible with the first version of the network protocol includes a first plurality of sub-fields in the value field;

a second TLV element compatible with the second version of the network protocol includes a second plurality of sub-fields in the value field; and

the second plurality of sub-fields includes the first plurality of sub-fields.

8. The method of claim 1 , further comprising:

receiving, by the network device, a second TLV element;

determining, by the network device based on both a second type identified by a type field of the second TLV element and the first version of the network protocol, an expected length of a value field of the second TLV element; and

in response to determining that the expected length of the value field of the second TLV element is longer than a length of the value field of the second TLV element specified by a length field of the second TLV element, discarding, by the network device, the second TLV element without processing the value field of the second TLV element.

9. A node in a mesh network, comprising:

one or more processors; and

a memory storing executable instructions that, when executed by the one or more processors, cause the one or more processors to:

receive, via a link coupling the node to a second node in the mesh network, a network packet including a type-length-value (TLV) element, the TLV element comprising a type field, a length field, and a value field;

compute, based on both a first type of the TLV element identified in the type field and a first version of a network protocol implemented by the node for processing the TLV element, an anticipated length of the value field, wherein:

the first version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have the anticipated length,

a second version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have a second anticipated length different from the anticipated length, and

the anticipated length is greater than zero; and

perform one or more operations on a portion of the value field up to the anticipated length.

10. The node of claim 9 , wherein the anticipated length of the value field is further computed based on a first version of a frame format for the TLV element.

11. The node of claim 10 , wherein:

the one or more processors perform the one or more operations on the portion of the value field according to the first version of the frame format; and

the TLV element is compatible with a second version of the frame format used by the second node, the second version of the frame format being newer than the first version of the frame format.

12. The node of claim 11 , wherein the value field includes a sub-field in the portions of the value field past the anticipated length that is included in the second version of the frame format and is not included in the first version of the frame format.

13. The node of claim 9 , wherein the anticipated length of the value field is further computed based on a value included in a sub-field of the value field.

14. The node of claim 9 , wherein the anticipated length of the value field is equal to or shorter than a length of the value field specified by the length field.

15. A non-transitory computer-readable medium storing instructions that, when executed by a computing device, cause the computing device to perform operations comprising:

receiving, via a link in a mesh network, a network frame, the network frame including a type-length-value (TLV) element having a type field, a length field, and a value field;

determining, based on the type field, a first type of the TLV element;

determining, based on at least (i) the type of the TLV element, (ii) a first version of a network protocol implemented by the computing device for processing the TLV element, and (iii) a mapping, an expected number of bytes in the value field, wherein:

the first version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have the expected number of bytes,

a second version of the network protocol specifies that value fields of TLV elements having type fields identifying the first type have a second expected number of bytes different from the expected number of bytes, and

the expected number of bytes in the value field is greater than zero; and

processing a beginning portion of the value field that includes the expected number of bytes.

16. The non-transitory computer-readable medium of claim 15 , wherein determining the expected number of bytes comprises determining, based on a value in a first sub-field of the value field, a size of a second sub-field in the value field.

17. The non-transitory computer-readable medium of claim 15 , further comprising:

determining, based on the length field, a number of bytes in the value field; and

determining that the expected number of bytes in the value field is less than or equal to the number of the bytes in the value field.

18. The non-transitory computer-readable medium of claim 15 , further comprising:

receiving, via the link, a second TLV element having a second type field, a second length field, and a second value field;

determining, based on the second type field, a second type of the second TLV element;

determining, based on at least (i) the second type of the second TLV element, (ii) the first version of the network protocol implemented by the computing device for processing the TLV element, and (iii) the mapping, a third expected number of bytes in the second value field;

determining, based on the second length field, a number of bytes in the second value field; and

in response to determining that the third expected number of bytes of the second value field is greater than the number of bytes in the second value field, discarding the second TLV element without processing the second value field.