what is tlv (tag-length-value)

本文详细介绍了TLV(标签-长度-值)编码的基本概念、结构及其应用优势。TLV是一种简单且紧凑的数据编码格式,广泛应用于不同平台间的数据传输中。文章还探讨了其在解析复杂性和数据可读性方面的优缺点。

What is tlv?

To put hooks (functions) in the code instead of if/else?

if I have one piece of code running on different platforms, at different places in code, I can put tlv function hooks to identify what platform I am on and do accordingly? Or something like that?

benefits can be cleaner code? easy to maintain? When a new platform is added, only tlv code needs to change and not the source code?

I may be completely wrong here.

share | edit
 
 
It has nothing to do with code and everything to do with data. –   Karl Knechtel  Dec 11 '10 at 0:02
 
@karl: ( I know this is an old thread, but somehow I landed here today again :) ) Are you sure that this has nothing to do with code? Because I guess its other way around - all about code and nothing about data. :D –   hari  Apr 15 '11 at 18:26
add comment

4 Answers

up vote 10  down vote accepted

TLV is Tag-length-value encoding. Often it is better referred to by it's original name, type-length-value.

The first field is the "type" of data being processed, the second field specifies the "length" of the value, the third field contains a "length" amount of data representing the value for the "type".

Multiple pieces of data can be transmitted in the same message by appending more triplets to a previously existing message.

There's a page on wikipedia covering it in just a little more detail. Don't get confused though, each triplet is a "top level" description, there is typically no nesting of items in TLV (although you could come up with a way to do so by encoding TLV triplets in the V of another tag).

share | edit
 
 
Thanks Edwin. I was looking for exact need and pros/cons of it. If you know of any example, let me know. –   hari  Dec 11 '10 at 7:44
 
The pros are that it's a dead simple format (easy to parse, you can skip new added fields in old programs). The cons are that it's a dead simple format (no built-in hierarchy support, encodes binary poorly, data type must be known to both sides beforehand or transmitted in some custom-encoded way, very poor support for when the data changes over time are not additive but are substitutions, etc). Some of these cons are fixable, like you can uuencode binary to transmit it, but that's just more work to de-uuencode on the other end. –   Edwin Buck  Dec 13 '10 at 15:20
 
Actually you can put more TLVs inside other TLVs: the 6th bit of the 1st byte of type field in the TLV structure, if set to 1, means constructed, which indicates that the v part of the TLV structure is actually a set of other TLVs. –   Fabio A.  Sep 24 '13 at 13:36
1 
Fabio, yes you can embed TLVs in TLVs, as my original post mentioned; however, there is not a standard for which byte needs to be set unless you go with something a bit more specific than TLV, like X.690 BER encoding, or something. With the mentioned encoding, it is the 6th byte of the class sub-field of the tag that flags a constructed value, not the first byte of the type field. So obviously there is not an accepted constructed tag flag, without selecting amongst many different "more specific" TLV like protocols. –   Edwin Buck  Sep 24 '13 at 18:07
add comment

TLV refers to encoding values in Type-Length-Value trio's, and this more general form is documented on WikiPedia.

In some context's (such as EMV) TLV refers to the more specific X.690 which is also documented on WikiPedia.

TLV has the following advantages:

  • Relatively compact encoding format
  • Relatively simple to parse (I wrote a basic X.690 parser in a couple of hours)
  • The X.690 TLV has support for nested types (this part is slightly more complicated to parse, but from what I can tell is not required for EMV)

TLV's biggest disadvantage is that it is not directly human readable. Note however if the data is converted to hex it is only moderately difficult to read.

share | edit
 
 
add comment

TLV is a way of storing data to facilitate quick parsing of that data.

Typically, you read the type(tag), length and value and then send those datum to a processor function. This processor functions only function will be to process type X. Then, you read the next type, it's length and value and send it to the appropriate processor.

It's typically used as an easy way to process data without a lot of extra overhead.

share | edit
 
 
C'mon people, when you downvote, tell me why (especially 2 years after the fact) –   KevinDTimm  Dec 18 '12 at 2:42
add comment

I think what you are referring to is called Type Length Value, and there is a wikipedia page for it. Hope that helps.

share | edit
 
 
add comment
<think> 我们正在讨论IEEE 1905.1标准中的CMDU(控制消息数据单元)及其TLV结构。用户要求详细说明每种消息类型(Message Type)按协议规定包含0个或多个TLV的具体信息。 根据IEEE Std 1905.1-2013标准,第6.2节详细定义了各种CMDU消息类型及其对应的TLV结构。以下将逐一说明: ### 1. **TLV结构概述** TLV(Type-Length-Value)是CMDU消息体的基本组成单元,结构如下: ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Type (1B) | Length (2B) | |---------------------------------------------------------------| | Value | | ... | +---------------------------------------------------------------+ ``` - **Type**:1字节,标识TLV类型(0x00~0xFF)。 - **Length**:2字节,表示Value字段的字节数。 - **Value**:变长数据,由Length字段指定长度。 ### 2. **消息类型与强制/可选TLV对照表** 下表列出标准定义的19种消息类型及其对应的TLV要求(依据标准第6.2.1~6.2.19节)[^1]: | Message Type | 消息名称 | 强制TLV类型 | 可选TLV类型 | |--------------|--------------------------|-----------------------------|-------------------------------------| | **0x0000** | 拓扑发现请求 | 无 | 厂商特定TLV(0x00) | | **0x0001** | 拓扑发现响应 | 设备信息TLV(0x01)<br>接口列表TLV(0x02) | 厂商特定TLV(0x00) | | **0x0002** | 拓扑通告 | 设备信息TLV(0x01)<br>接口列表TLV(0x02) | 厂商特定TLV(0x00) | | **0x0003** | 拓扑查询请求 | 无 | 厂商特定TLV(0x00) | | **0x0004** | 拓扑查询响应 | 设备信息TLV(0x01)<br>接口列表TLV(0x02) | 厂商特定TLV(0x00) | | **0x0005** | 链路度量查询请求 | 链路度量查询TLV(0x03) | 厂商特定TLV(0x00) | | **0x0006** | 链路度量查询响应 | 链路度量报告TLV(0x04) | 厂商特定TLV(0x00) | | **0x0007** | 自动拥塞报告 | 自动拥塞报告TLV(0x05) | 无 | | **0x0008** | AP能力报告 | AP能力TLV(0x06) | 无 | | **0x0009** | AP自动配置请求 | AP自动配置请求TLV(0x07) | 厂商特定TLV(0x00) | | **0x000A** | AP自动配置响应 | AP自动配置响应TLV(0x08) | 厂商特定TLV(0x00) | | **0x000B** | AP自动配置重部署请求 | AP重部署请求TLV(0x09) | 厂商特定TLV(0x00) | | **0x000C** | AP自动配置重部署确认 | AP重部署确认TLV(0x0A) | 厂商特定TLV(0x00) | | **0x000D** | 信道选择请求 | 信道选择请求TLV(0x0B) | 厂商特定TLV(0x00) | | **0x000E** | 信道选择响应 | 信道选择响应TLV(0x0C) | 厂商特定TLV(0x00) | | **0x000F** | 回送请求 | 无 | 厂商特定TLV(0x00) | | **0x0010** | 回送响应 | 无 | 厂商特定TLV(0x00) | | **0x0011** | 接口控制命令 | 接口控制命令TLV(0x0D) | 厂商特定TLV(0x00) | | **0x0012** | 厂商特定消息 | 厂商特定TLV(0x00) | 无 | > **注**: > - **强制TLV**:消息中必须包含且仅包含一次(除非协议允许重复)。 > - **可选TLV**:根据场景可包含0或多个。 > - **厂商特定TLV**(Type=0x00):允许设备厂商扩展自定义信息,结构为`厂商ID(3B)+自定义子类型(1B)+自定义数据`。 ### 3. **关键TLV详细说明** #### (1) 设备信息TLV(Type=0x01) ``` Value字段结构: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | 厂商ID (3B) | 设备型号 (16B) | |---------------------------------------------------------------| | 支持技术位图 (1B) | 保留 (1B) | AL MAC地址数量 (1B) | 保留(1B)| |---------------------------------------------------------------+ | AL MAC地址列表(6B × N) | | ... | +---------------------------------------------------------------+ ``` - **支持技术位图**:Bit0=Wi-Fi, Bit1=PLC, Bit2=Ethernet, Bit3=MoCA, 其他保留。 - **AL MAC地址数量N**:设备关联的1905.1抽象层MAC地址数。 #### (2) 链路度量报告TLV(Type=0x04) ``` Value字段结构(每链路): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | 本地接口MAC (6B) | 邻居接口MAC (6B) | |---------------------------------------------------------------| | 链路可用性 (1B) | 物理层速率 (2B) | 平均延迟 (2B) | 包错误率 (2B) | +---------------------------------------------------------------+ ``` - **链路可用性**:$A = \frac{T_{\text{up}}}{T_{\text{total}}} \times 255$(8位整数,0~255)。 - **平均延迟**:$\tau_{\text{avg}}$(单位为毫秒)。 - **包错误率**:$P_e = \frac{N_{\text{error}}}{N_{\text{total}}} \times 65535$(16位整数)。 ### 4. **TLV扩展机制** TLV结构天然支持协议扩展: - **向后兼容**:未知Type的TLV可被接收方忽略(标准要求)。 - **厂商扩展**:通过Type=0x00的厂商特定TLV实现私有扩展。 - **嵌套TLV**:部分TLV(如接口控制命令)允许在Value字段内嵌套子TLV--- §§相关问题§§ 1. 厂商特定TLV如何避免不同厂商的Type值冲突? 2. 链路度量报告TLV中的性能指标如何转换为实际数值? 3. 在拓扑发现响应消息中,如果设备有多个AL MAC地址,TLV结构如何处理? [^1]: IEEE Std 1905.1TM-2013, Section 6.2 Control Message Data Unit (CMDU) </think> ### IEEE 1905.1 各消息类型的TLV结构详解 根据IEEE Std 1905.1-2013标准第6.2节,CMDU消息体由0个或多个TLV(Type-Length-Value)结构组成。以下是主要消息类型对应的TLV要求及结构说明: #### 1. **拓扑发现请求 (Message Type=0x0000)** - **TLV数量**:0个或1个 - **允许的TLV类型**: - `0x00` 厂商特定TLV(可选) - **说明**:用于请求网络设备信息,本身不含强制TLV字段 #### 2. **拓扑发现响应 (Message Type=0x0001)** - **TLV数量**:最少2个 - **强制TLV**: - `0x01` 设备信息TLV - `0x02` 接口列表TLV - **可选TLV**: - `0x00` 厂商特定TLV - **设备信息TLV结构**: ``` +----------------------+ | 厂商ID (3B) | |----------------------| | 设备型号 (16B) | |----------------------| | 技术位图 (1B) | // Bit0-WiFi, Bit1-PLC, Bit2-Ethernet +----------------------+ ``` #### 3. **链路度量查询请求 (Message Type=0x0006)** - **TLV数量**:1个 - **强制TLV**: - `0x03` 链路度量查询TLV - **TLV结构**: ``` +----------------------+ | 查询类型 (1B) | // 0x01=邻居设备,0x02=特定链路 |----------------------| | 目标AL MAC (6B) | // 仅当查询类型=0x02时存在 +----------------------+ ``` #### 4. **链路度量报告 (Message Type=0x0007)** - **TLV数量**:1个或多个 - **强制TLV**: - `0x04` 链路度量数据TLV - **TLV结构**: ``` +----------------------+ | 本地接口MAC (6B) | |----------------------| | 邻居接口MAC (6B) | |----------------------| | 链路可用性 (1B) | // $A = \frac{T_{\text{up}}}{T_{\text{total}}} \times 255$ |----------------------| | 物理层速率 (2B) | // $R_{\text{phy}}$ (Mbps) |----------------------| | 平均延迟 (2B) | // $\tau_{\text{avg}}$ (ms) |----------------------| | 包错误率 (2B) | // $P_e \times 65,535$ +----------------------+ ``` #### 5. **接口控制命令 (Message Type=0x0002)** - **TLV数量**:1个 - **强制TLV**: - `0x0D` 接口控制TLV - **TLV结构**: ``` +----------------------+ | 控制类型 (1B) | // 0x01=启用接口,0x02=禁用接口 |----------------------| | 目标接口MAC (6B) | |----------------------| | 参数长度 (1B) | |----------------------| | 控制参数 (变长) | // 如信道号、发射功率等 +----------------------+ ``` #### 6. **AP自动配置请求 (Message Type=0x0009)** - **TLV数量**:1个或多个 - **强制TLV**: - `0x07` AP配置请求TLV - **可选TLV**: - `0x00` 厂商特定TLV - **TLV结构**: ``` +----------------------+ | 请求类型 (1B) | // 0x01=信道切换,0x02=功率调整 |----------------------| | 目标AP MAC (6B) | |----------------------| | 参数列表 (嵌套TLV) | // 包含具体配置参数 +----------------------+ ``` ### TLV通用结构 所有TLV遵循相同的基础格式: ``` 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---------------+---------------+ | Type | Length | | (1B) | (2B) | +---------------+---------------+ | Value | | (变长数据) | +-------------------------------+ ``` - **Type**:1字节,标识TLV类型(标准定义0x01-0x7F,0x80-0xFF保留) - **Length**:2字节,指示Value字段的字节长度 - **Value**:实际数据载荷,格式由Type字段决定 ### 协议扩展机制 TLV结构天然支持扩展: 1. **厂商特定TLV (Type=0x00)**: - 前3字节为OUI(厂商标识) - 第4字节为子类型 ```mermaid graph LR A[TLV Type=0x00] --> B[OUI:3B] A --> C[Subtype:1B] A --> D[Vendor Data:变长] ``` 2. **嵌套TLV**: 部分TLV(如接口控制命令)允许在Value字段内包含子TLV结构 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值