Type–length–value

<h2 id="details">Details</h2>
<p>The type and length are fixed in size (typically 1–4 bytes), and the value field is of variable size. These fields are used as follows:
</p>
Type
A binary code, often simply alphanumeric, which indicates the kind of field that this part of the message represents;
Length
The size of the value field (typically in bytes);
Value
Variable-sized series of bytes which contains data for this part of the message.
<p>Some advantages of using a TLV representation data system solution are:
</p>
<ul><li>TLV sequences are easily searched using generalized parsing functions;</li>
<li>New message elements which are received at an older node can be safely skipped and the rest of the message can be parsed. This is similar to the way that unknown <a href="/facts/XML/clNgUfWk">XML</a> tags can be safely skipped;</li>
<li>TLV elements can be placed in any order inside the message body;</li>
<li>TLV elements are typically used in a binary format and <a href="/facts/Binary_protocol/Nmj0lyxI">binary protocols</a> which makes parsing faster and the data smaller than in comparable text based protocols.</li></ul>
<h2 id="examples">Examples</h2>
<h3>Real-world examples</h3>
<h4>Transport protocols</h4>
<ul><li><a href="/facts/Transport_Layer_Security/pGy16TnA">TLS</a> (and its predecessor SSL) use TLV-encoded messages.</li>
<li><a href="/facts/SSH/wjVRw5zv">SSH</a></li>
<li><a href="/facts/Common_Open_Policy_Service/bMJUWHDs">COPS</a></li>
<li><a href="/facts/IS-IS/zaNkSwhW">IS-IS</a></li>
<li><a href="/facts/RADIUS/NfNur5Q5">RADIUS</a></li>
<li><a href="/facts/Link_Layer_Discovery_Protocol/8EeXor0m">Link Layer Discovery Protocol</a> allows for the sending of organizational-specific information as a TLV element within LLDP packets</li>
<li><a href="/facts/Media_Redundancy_Protocol/tcp2IL4T">Media Redundancy Protocol</a> allows organizational-specific information</li>
<li><a href="/facts/Dynamic_Host_Configuration_Protocol/lpASHnhz">Dynamic Host Configuration Protocol</a> (DHCP) uses TLV encoded options</li>
<li>RR protocol used in GSM cell phones (defined in 3GPP 04.18). In this protocol each message is defined as a sequence of information elements.</li></ul>
<h4>Data storage formats</h4>
<ul><li><a href="/facts/Interchange_File_Format/tuwp8bH7">IFF</a></li>
<li><a href="/facts/Matroska/hDrffBx0">Matroska</a> uses TLV for markup tags</li>
<li><a href="/facts/QTFF/WQVMMCQT">QTFF</a> (the basis for <a href="/facts/ISO/IEC_base_media_file_format/whvAPejY">MPEG-4 containers</a>)</li></ul>
<h4>Other</h4>
<ul><li>ubus used for <a href="/facts/Inter-process_communication/cIQYyT6y">IPC</a> in <a href="/facts/OpenWrt/3VYxerTY">OpenWrt</a><a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a></li></ul>
<h3>Other examples</h3>
<p>Imagine a message to make a telephone call. In a first version of a system this might use two message elements: a "command" and a "phoneNumberToCall":
</p>
command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"
<p>Here command_c, makeCall_c and phoneNumberToCall_c are integer constants and 4 and 8 are the lengths of the "value" fields, respectively.
</p><p>Later (in version 2) a new field containing the calling number could be added:
</p>
command_c/4/makeCall_c/callingNumber_c/14/"1-613-715-9719"/phoneNumberToCall_c/8/"722-4246"
<p>A version 1 system which received a message from a version 2 system would first read the command_c element and then read an element of type callingNumber_c. The version 1 system does not understand
callingNumber_c, so the length field is read (i.e. 14) and the system skips forward 14 bytes to read
</p>
phoneNumberToCall_c
<p>which it understands, and message parsing carries on.
</p>
<h2 id="other-ways-of-representing-data">Other ways of representing data</h2>
<p>Core <a href="/facts/TCP/IP/KNkxtSpw">TCP/IP</a> protocols (particularly <a href="/facts/Internet_Protocol/Qq6VeEal">IP</a>, <a href="/facts/Transmission_Control_Protocol/WW4sPrt9">TCP</a>, and <a href="/facts/User_Datagram_Protocol/dxLU0D6q">UDP</a>) use predefined, static fields.
</p><p>Some <a href="/facts/Application_layer/FAFhLruA">application layer</a> protocols, including <a href="/facts/HTTP/1.1/TWtvf7JD">HTTP/1.1</a> (and its non-standardized predecessors), <a href="/facts/FTP/THuWgzfw">FTP</a>, <a href="/facts/SMTP/TeCRKDpJ">SMTP</a>, <a href="/facts/POP3/QCp6qJQm">POP3</a>, and <a href="/facts/Session_Initiation_Protocol/cbjUoNqP">SIP</a>, use text-based "Field: Value" pairs formatted according to <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc2822">2822</a>. (<a href="/facts/HTTP/TWtvf7JD">HTTP</a> represents length of payload with a Content-Length header and separates headers from the payload with an empty line and headers from each other with a new line.)
</p><p><a href="/facts/ASN.1/ryUN7doc">ASN.1</a> specifies several TLV-based encoding rules (<a href="/facts/Basic_Encoding_Rules/sNL76pTs">BER</a>, <a href="/facts/Distinguished_Encoding_Rules/sNL76pTs">DER</a>), as well as non-TLV based ones (<a href="/facts/Packed_Encoding_Rules/ryUN7doc">PER</a>, <a href="/facts/XML_Encoding_Rules/ryUN7doc">XER</a>).
</p><p><a href="/facts/CSN.1/FgFNF7rE">CSN.1</a> describes encoding rules using non-TLV semantics.
</p><p>More recently,[<i>when?</i>] <a href="/facts/XML/clNgUfWk">XML</a> has been used to implement messaging between different nodes in a network. These messages are typically prefixed with line-based text commands, such as with <a href="/facts/BEEP/X8XfqCGt">BEEP</a>.
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/KLV/H88njq52">KLV</a>, specific type of type-length-value encoding</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>"OpenWrt documentation on ubus". openwrt.org. April 15, 2022. Retrieved 2022-04-15. <a href="https://openwrt.org/docs/techref/ubus" target="_blank">https://openwrt.org/docs/techref/ubus</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
</ol>

Type–length–value open-in-new

Type–length–value