*** Welcome to piglix ***

Type-length-value


Within , optional information may be encoded as a type-length-value or TLV element inside a protocol. TLV is also known as tag-length-value.

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:

Some advantages of using a TLV representation data system solution are:

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":

Here command_c, makeCall_c and phoneNumberToCall_c are integer constants and 4 and 8 are the lengths of the "value" fields, respectively.

Later (in version 2) a new field containing the calling number could be added:

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

which it understands, and message parsing carries on.

An example of usage is the which allows for the sending of organizational-specific information as a TLV element within LLDP packets. Another example is the RR protocol used in GSM cell phones, defined in 3GPP 04.18.

In the RR protocol, each message is defined as a sequence of information elements.

Many other protocols use TLVs, such as COPS, IS-IS, and RADIUS.

Core TCP/IP protocols (particularly , , and ) use predefined, static fields.

Common TCP/IP-based protocols such as , , , , and use text-based "Field: Value" pairs formatted according to RFC 2822.

ASN.1 specifies several TLV-based encoding rules (BER, DER), as well as non-TLV based ones (PER, XER).

CSN.1 describes encoding rules using non-TLV semantics.


...
Wikipedia

...