[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about TLV, subTLVs and length
Hi Jeroen,
The current text defining the length of TLVs is the following:
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The
TLV is padded to four-octet alignment; padding is not included in the
length field (so a three octet value would have a length of three,
but the total size of the TLV would be eight octets). Nested TLVs
are also 32-bit aligned. For example, a one-byte value would have
the length field set to 1, and three octets of padding would be added
to the end of the value portion of the TLV. Unrecognized types are
ignored.
I guess you are quoting from RFC4970 that repeats and adds to the tex in
RFC3630?
To me this seems very unclear about the handling of lengths of subTLVs,
and their impact on the length of the upper TLV.
Sub-TLVs form part of the V of the parent TLV.
The padding after a subTLV should of course not be included in the
length of that subTLV. But should that padding be included in the length
of the (enclosing) TLV?
Hah! Nice question.
Consider that the L field has two purposes.
1. To define the actual length of the V field
2. To allow a parser to step over the whole TLV without decoding it
In order to perform the second, the operation on a TLV with multiple
sub-TLVs it is essential that the L of the parent TLV includes all of the
padding implicit in the sub-TLVs.
I would think that the padding for the subTLV should be included in the
length of the enclosing TLV. Most of the time it is possible to deduce
the length, but if more than 4 bytes of padding are added, you run into
problems.
Exactly.
I really couldn't find a definitive answer on this anywhere, it may be
worth defining this somewhere, as the current wording is not clear on
this issue.
If you were quoting text from the OSPF RFCs, you might want to take this to
the OSPF list for confirmation.
Cheers,
Adrian