跳到主要内容

RFC 4379 - 3. Packet Format

3. 数据包格式 (Packet Format)​

本节定义 MPLS echo 消息使用的消息类型, 回复模式, 返回码与 TLV.

MPLS echo request 是一个 (可能带标签的) IPv4 或 IPv6 UDP 分组; 该 UDP 分组的内容具有如下格式:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version Number 当前为 1. (注意: 当某项变更影响到实现能否正确解析或处理 MPLS echo request/reply 时, 版本号都需要递增. 这些变更包括对任何固定字段所作的语法或语义变更, 也包括对在某个特定版本号下定义的任何 Type-Length-Value (TLV) 或子 TLV 的分配或格式所作的变更. 若只是新增一个可选 TLV 或子 TLV, 则版本号可能无需变更.)

Global Flags 字段是一个位向量, 其格式如下:

    0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

目前只定义了一个标志位, 即 V 位; 其余位在发送时必须 (MUST) 置为零, 在接收时被忽略.

V (Validate FEC Stack) 标志位在发送方希望接收方执行 FEC 栈验证时置为 1; 若 V 为 0, 则由接收方自行决定.

Message Type 取下列值之一:

取值含义
1MPLS echo request (MPLS 回显请求)
2MPLS echo reply (MPLS 回显应答)

Reply Mode 可以取下列值之一:

取值含义
1Do not reply (不回复)
2Reply via an IPv4/IPv6 UDP packet (通过 IPv4/IPv6 UDP 分组回复)
3Reply via an IPv4/IPv6 UDP packet with Router Alert (通过带 Router Alert 的 IPv4/IPv6 UDP 分组回复)
4Reply via application level control channel (通过应用层控制通道回复)

Reply Mode 字段为 1 (不回复) 的 MPLS echo request 可用于单向连通性测试; 接收路由器可以记录 Sequence Number 中的空隙, 和/或维护延迟/抖动统计. MPLS echo request 通常将 Reply Mode 字段设为 2 (通过 IPv4/IPv6 UDP 分组回复). 若认为正常的 IP 返回路径不可靠, 可以使用 3 (通过带 Router Alert 的 IPv4/IPv6 UDP 分组回复). 注意, 这要求所有中间路由器都理解并知道如何转发 MPLS echo reply. echo reply 使用与所收到的 echo request 相同的 IP 版本号, 即对 IPv4 封装的 echo request 作出的应答是 IPv4 封装的 echo reply.

有些应用支持 IP 控制通道. 其中一个例子是 Virtual Circuit Connectivity Verification (VCCV) [VCCV] 中定义的关联控制通道 (associated control channel). 任何在其控制实体之间支持 IP 控制通道的应用, 都可以将 Reply Mode 设为 4 (通过应用层控制通道回复), 以确保应答使用同一通道. 该码点的进一步定义取决于具体应用, 因此超出本文档的范围.

返回码与子码在下一节中描述.

Sender's Handle 由发送方填写, 并由接收方在 echo reply (若有) 中原样返回. 该句柄没有关联的语义, 不过发送方可能会发现它有助于将请求与应答对应起来.

Sequence Number 由 MPLS echo request 的发送方分配, 可以 (例如) 用于检测丢失的应答.

TimeStamp Sent 是发送 MPLS echo request 时的当日时间 (time-of-day), 按发送方时钟以秒与微秒计, 采用 NTP 格式 [NTP]. echo reply 中的 TimeStamp Received 是收到相应 echo request 时的当日时间 (按接收方时钟), 采用 NTP 格式.

TLV (Type-Length-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 定义见下文; Length 是 Value 字段的长度, 以字节为单位. Value 字段取决于 Type; 它会被零填充以对齐到 4 字节边界. TLV 可以嵌套在其他 TLV 之内, 此时被嵌套的 TLV 称为子 TLV (sub-TLV). 子 TLV 具有独立的类型, 并且也必须 (MUST) 按 4 字节对齐.

下面给出两个例子. 标签分发协议 (Label Distribution Protocol, LDP) IPv4 FEC 子 TLV 具有如下格式:

    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 = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

该 TLV 的 Length 为 5. 一个包含 LDP IPv4 FEC 子 TLV 与 VPN IPv4 前缀子 TLV 的目标 FEC 栈 TLV 具有如下格式:

    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 = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下面给出 LSP ping 的顶层 TLV 的类型与值 (Types and Values) 的描述:

类型编号 (Type #)值字段 (Value Field)
1Target FEC Stack (目标 FEC 栈)
2Downstream Mapping (下游映射)
3Pad (填充)
4Not Assigned (未分配)
5Vendor Enterprise Number (供应商企业编号)
6Not Assigned (未分配)
7Interface and Label Stack (接口与标签栈)
8Not Assigned (未分配)
9Errored TLVs (出错的 TLV)
10Reply TOS Byte (回复 TOS 字节)

小于 32768 的类型 (即高位比特等于 0) 是强制 (mandatory) TLV, 实现必须 (MUST) 支持它们, 否则必须在 echo 应答中发送返回码 2 ("一个或多个 TLV 未被理解").

大于或等于 32768 的类型 (即高位比特等于 1) 是可选 (optional) TLV; 若实现不理解或不支持它们, 则应当 (SHOULD) 忽略之.

3.1. 返回码 (Return Codes)​

发送方将返回码置为零. 接收方可以将其置为下面列出的值之一. 记号 表示返回子码 (Return Subcode). 对于要求携带栈深 (stack-depth) 的那些返回码, 该字段填入栈深; 对于所有其他返回码, 返回子码必须置为零.

取值含义
0No return code (无返回码)
1Malformed echo request received (收到格式错误的 echo request)
2One or more of the TLVs was not understood (一个或多个 TLV 未被理解)
3Replying router is an egress for the FEC at stack-depth (应答路由器是栈深 处 FEC 的出口)
4Replying router has no mapping for the FEC at stack-depth (应答路由器对栈深 处的 FEC 无映射)
5Downstream Mapping Mismatch (下游映射不匹配) (见注 1)
6Upstream Interface Index Unknown (上游接口索引未知) (见注 1)
7Reserved (保留)
8Label switched at stack-depth (在栈深 处发生标签交换)
9Label switched but no MPLS forwarding at stack-depth (发生标签交换但在栈深 处无 MPLS 转发)
10Mapping for this FEC is not the given label at stack-depth (此 FEC 的映射不是栈深 处给定的标签)
11No label entry at stack-depth (栈深 处无标签条目)
12Protocol not associated with interface at FEC stack-depth (协议未与栈深 处 FEC 所对应的接口关联)
13Premature termination of ping due to label stack shrinking to a single label (由于标签栈收缩为单个标签, ping 过早终止)

注 1

返回子码包含标签栈中处理被终止的位置. 若 RSC 为 0, 表示未处理任何标签; 否则, 该分组本应在深度 RSC 处被标签交换.

3.2. 目标 FEC 栈 (Target FEC Stack)​

目标 FEC 栈 (Target FEC Stack) 是一个子 TLV 的列表. 元素的数量通过查看各子 TLV 的长度字段来确定.

子类型 (Sub-Type)长度 (Length)值字段 (Value Field)
15LDP IPv4 prefix (LDP IPv4 前缀)
217LDP IPv6 prefix (LDP IPv6 前缀)
320RSVP IPv4 LSP (RSVP IPv4 LSP)
456RSVP IPv6 LSP (RSVP IPv6 LSP)
5Not Assigned (未分配)
613VPN IPv4 prefix (VPN IPv4 前缀)
725VPN IPv6 prefix (VPN IPv6 前缀)
814L2 VPN endpoint (L2 VPN 端点)
910"FEC 128" Pseudowire ("FEC 128" 伪线, 已弃用)
1014"FEC 128" Pseudowire ("FEC 128" 伪线)
1116+"FEC 129" Pseudowire ("FEC 129" 伪线)
125BGP labeled IPv4 prefix (BGP 标签 IPv4 前缀)
1317BGP labeled IPv6 prefix (BGP 标签 IPv6 前缀)
145Generic IPv4 prefix (通用 IPv4 前缀)
1517Generic IPv6 prefix (通用 IPv6 前缀)
164Nil FEC (空 FEC)

其他 FEC 类型将按需定义.

注意, 该 TLV 定义的是一个 FEC 栈: 第一个 FEC 元素对应标签栈的栈顶, 依此类推.

MPLS echo request 必须带有描述被测 FEC 栈的目标 FEC 栈. 例如, 若 LSR X 拥有针对 192.168.1.1 的 LDP 映射 [LDP] (设标签为 1001), 则为了验证标签 1001 确实到达了通过 LDP 通告该前缀的出口 LSR, X 可以发送一个 FEC 栈 TLV 中只含一个 FEC 的 MPLS echo request, 该 FEC 的类型为 LDP IPv4 prefix, 前缀为 192.168.1.1/32, 并以标签 1001 发送该 echo request.

再设 LSR X 想验证标签栈 <1001, 23456> 是否是到达 VPN foo 中 VPN IPv4 前缀 10/8 (见 3.2.5 节) 的正确标签栈. 又设环回地址为 192.168.1.1 的 LSR Y 通告了前缀 10/8, 其路由区分符 (Route Distinguisher) 为 RD-foo-Y (通常可能与 LSR X 自己为 VPN foo 通告时使用的路由区分符不同), 标签为 23456, BGP 下一跳为 192.168.1.1 [BGP]. 最后, 假设 LSR X 通过 LDP 收到了 192.168.1.1 的标签绑定 1001. X 在发送 MPLS echo request 时有两种选择: X 可以发送一个 FEC 栈 TLV, 其中只含一个类型为 VPN IPv4 prefix 的 FEC, 前缀为 10/8, 路由区分符为 RD-foo-Y; 或者, X 可以发送一个含两个 FEC 的 FEC 栈 TLV, 第一个 FEC 的类型为 LDP IPv4, 前缀为 192.168.1.1/32, 第二个 FEC 的类型为 IP VPN, 前缀为 10/8, 路由区分符为 RD-foo-Y. 无论哪种情况, 该 MPLS echo request 的标签栈都是 <1001, 23456>. (注意: 在此例中, 1001 是 "外层" 标签, 23456 是 "内层" 标签.)

3.2.1. LDP IPv4 前缀 (LDP IPv4 Prefix)​

IPv4 前缀 FEC 定义于 [LDP]. 当 LDP IPv4 前缀被编码进标签栈时, 使用如下格式. 值字段由 4 个字节的 IPv4 前缀后随 1 个字节的前缀长度 (以比特为单位) 组成; 格式如下. IPv4 前缀采用网络字节序; 若前缀不足 32 比特, 尾随比特应当置为零. IPv4 FEC 的 Mapping 示例参见 [LDP].

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.2. LDP IPv6 前缀 (LDP IPv6 Prefix)​

IPv6 前缀 FEC 定义于 [LDP]. 当 LDP IPv6 前缀被编码进标签栈时, 使用如下格式. 值字段由 16 个字节的 IPv6 前缀后随 1 个字节的前缀长度 (以比特为单位) 组成; 格式如下. IPv6 前缀采用网络字节序; 若前缀不足 128 比特, 尾随比特应当置为零. IPv6 FEC 的 Mapping 示例参见 [LDP].

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.3. RSVP IPv4 LSP (RSVP IPv4 LSP)​

值字段具有如下格式. 这些值字段取自 RFC 3209 的 4.6.1.1 节与 4.6.2.1 节. 参见 [RSVP-TE].

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.4. RSVP IPv6 LSP (RSVP IPv6 LSP)​

值字段具有如下格式. 这些值字段取自 RFC 3209 的 4.6.1.2 节与 4.6.2.2 节. 参见 [RSVP-TE].

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.5. VPN IPv4 前缀 (VPN IPv4 Prefix)​

VPN-IPv4 网络层路由信息 (NLRI) 定义于 [RFC4365]. 本文档使用术语 "VPN IPv4 prefix" 指代在 BGP 中随 MPLS 标签一起通告的 VPN-IPv4 NLRI. 参见 [BGP-LABEL].

当 VPN IPv4 前缀被编码进标签栈时, 使用如下格式. 值字段由随该 VPN IPv4 前缀一起通告的路由区分符 (Route Distinguisher)、IPv4 前缀 (尾随补 0 比特, 使其共为 32 比特) 以及前缀长度组成, 如下所示:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

路由区分符 (RD) 是一个 8 字节的标识符; 它本身不包含任何内在信息. RD 的目的仅仅是允许为同一 IPv4 地址前缀创建多条不同的路由. RD 的编码方式在此并不重要. 在将该字段与本地 FEC 信息进行匹配时, 它被当作不透明值处理.

3.2.6. VPN IPv6 前缀 (VPN IPv6 Prefix)​

VPN-IPv6 网络层路由信息 (NLRI) 定义于 [RFC4365]. 本文档使用术语 "VPN IPv6 prefix" 指代在 BGP 中随 MPLS 标签一起通告的 VPN-IPv6 NLRI. 参见 [BGP-LABEL].

当 VPN IPv6 前缀被编码进标签栈时, 使用如下格式. 值字段由随该 VPN IPv6 前缀一起通告的路由区分符 (Route Distinguisher)、IPv6 前缀 (尾随补 0 比特, 使其共为 128 比特) 以及前缀长度组成, 如下所示:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

此处的路由区分符与 VPN IPv4 前缀的 RD 相同, 只是它在这里的作用是允许为 IPv6 前缀创建多条不同的路由. 参见 3.2.5 节. 在将该字段与本地 FEC 信息进行匹配时, 它被当作不透明值处理.

3.2.7. L2 VPN 端点 (L2 VPN Endpoint)​

VPLS 代表虚拟专用局域网服务 (Virtual Private LAN Service). 术语 VPLS BGP NLRI 与 VE ID (VPLS Edge Identifier, VPLS 边缘标识符) 定义于 [VPLS-BGP]. 本文档在指代 VPLS BGP NLRI 时使用较简单的术语 "L2 VPN endpoint" (L2 VPN 端点). 路由区分符是一个 8 字节的标识符, 用于区分某节点通告的各个 L2 VPN 的信息. VE ID 是一个 2 字节的标识符, 用于标识在 VPLS 中充当业务接入点的特定节点. 这两个标识符的结构在此并不重要; 在将这些字段与本地 FEC 信息进行匹配时, 它们被当作不透明值处理. 封装类型与下文 3.2.8 节中的 PW Type 相同.

当 L2 VPN 端点被编码进标签栈时, 使用如下格式. 值字段由路由区分符 (8 字节)、ping 发送方的 VE ID (2 字节)、接收方的 VE ID (2 字节) 以及封装类型 (2 字节) 组成, 格式如下:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.8. FEC 128 伪线 (已弃用) (FEC 128 Pseudowire (Deprecated))​

FEC 128 (0x80) 定义于 [PW-CONTROL], 术语 PW ID (Pseudowire ID, 伪线 ID) 与 PW Type (Pseudowire Type, 伪线类型) 亦同. PW ID 是一个非零的 32 比特连接 ID. PW Type 是一个 15 比特的数值, 指示封装类型. 它在下方称为封装类型 (encapsulation type) 的字段中右对齐承载, 最高位置为零. 在本协议中, 这两个字段均被当作不透明值处理.

当 FEC 128 被编码进标签栈时, 使用如下格式. 值字段由远端 PE 地址 (目标 LDP 会话的目的地址)、PW ID 以及封装类型组成, 如下所示:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

此 FEC 已被弃用, 仅为向后兼容而保留. LSP ping 的实现应当接受并处理该 TLV, 但应当使用新的 TLV (见下一节) 发送 LSP ping echo request, 除非被明确配置为使用旧 TLV.

收到此 TLV 的 LSR 应当利用 LSP echo request 的源 IP 地址来推断发送方的 PE 地址.

3.2.9. FEC 128 伪线 (现行) (FEC 128 Pseudowire (Current))​

FEC 128 (0x80) 定义于 [PW-CONTROL], 术语 PW ID (Pseudowire ID, 伪线 ID) 与 PW Type (Pseudowire Type, 伪线类型) 亦同. PW ID 是一个非零的 32 比特连接 ID. PW Type 是一个 15 比特的数值, 指示封装类型. 它在下方称为封装类型 (encapsulation type) 的字段中右对齐承载, 最高位置为零.

在本协议中, 这两个字段均被当作不透明值处理. 在将这些字段与本地 FEC 信息进行匹配时, 匹配必须完全一致 (exact).

当 FEC 128 被编码进标签栈时, 使用如下格式. 值字段由发送方的 PE 地址 (目标 LDP 会话的源地址)、远端 PE 地址 (目标 LDP 会话的目的地址)、PW ID 以及封装类型组成, 如下所示:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.10. FEC 129 伪线 (FEC 129 Pseudowire)​

FEC 129 (0x81) 以及术语 PW Type、Attachment Group Identifier (AGI, 附着组标识符)、Attachment Group Identifier Type (AGI Type, 附着组标识符类型)、Attachment Individual Identifier Type (AII Type, 附着个体标识符类型)、Source Attachment Individual Identifier (SAII, 源附着个体标识符) 与 Target Attachment Individual Identifier (TAII, 目标附着个体标识符) 定义于 [PW-CONTROL]. PW Type 是一个 15 比特的数值, 指示封装类型. 它在下方 PW Type 字段中右对齐承载, 最高位置为零. 所有其他字段均被当作不透明值处理, 并直接从 FEC 129 格式中复制. 这些值合在一起, 在由源 PE 地址与远端 PE 地址所标识的 LDP 会话范围内唯一地定义该 FEC.

当 FEC 129 被编码进标签栈时, 使用如下格式. 该 TLV 的 Length 为 16 + AGI 长度 + SAII 长度 + TAII 长度. 使用填充 (padding) 使总长度成为 4 的倍数; 填充的长度不计入 Length 字段.

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.11. BGP 标签 IPv4 前缀 (BGP Labeled IPv4 Prefix)​

BGP 标签 IPv4 前缀定义于 [BGP-LABEL]. 当 BGP 标签 IPv4 前缀被编码进标签栈时, 使用如下格式. 值字段由 IPv4 前缀 (尾随补 0 比特, 使其共为 32 比特) 以及前缀长度组成, 如下所示:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.12. BGP 标签 IPv6 前缀 (BGP Labeled IPv6 Prefix)​

BGP 标签 IPv6 前缀定义于 [BGP-LABEL]. 当 BGP 标签 IPv6 前缀被编码进标签栈时, 使用如下格式. 值由 16 个字节的 IPv6 前缀后随 1 个字节的前缀长度 (以比特为单位) 组成; 格式如下. IPv6 前缀采用网络字节序; 若前缀不足 128 比特, 尾随比特应当置为零.

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.13. 通用 IPv4 前缀 (Generic IPv4 Prefix)​

值由 4 个字节的 IPv4 前缀后随 1 个字节的前缀长度 (以比特为单位) 组成; 格式如下. IPv4 前缀采用网络字节序; 若前缀不足 32 比特, 尾随比特应当置为零. 当通告标签的协议未知, 或者在 LSP 的生存期内可能发生变化时, 使用此 FEC. 一个例子是跨自治系统 (inter-AS) 的 LSP: 它可能在一个自治系统 (AS) 内由 LDP 通告, 在另一个 AS 内由 RSVP-TE [RSVP-TE] 通告, 而在 AS 之间由 BGP 通告, 这在跨 AS VPN 中很常见.

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.14. 通用 IPv6 前缀 (Generic IPv6 Prefix)​

值由 16 个字节的 IPv6 前缀后随 1 个字节的前缀长度 (以比特为单位) 组成; 格式如下. IPv6 前缀采用网络字节序; 若前缀不足 128 比特, 尾随比特应当置为零.

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.15. 空 FEC (Nil FEC)​

有时, 出于影响负载均衡等各种诊断目的, 保留范围的标签 (例如 Router Alert 与 Explicit-null) 可能会被加入标签栈. 这些标签可能没有与之显式关联的 FEC. 定义空 FEC (Nil FEC) 栈的目的, 是允许向目标 FEC 栈中添加一个目标 FEC 栈子 TLV 来对应这类标签, 从而仍然可以执行正确的验证.

Length 为 4. 标签是 20 比特的数值, 被当作数字处理.

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label 是插入标签栈中的实际标签值; MBZ 字段在发送时必须为零, 在接收时被忽略.

3.3. 下游映射 (Downstream Mapping)​

下游映射 (Downstream Mapping) 对象是一个 TLV, 可以 (MAY) 包含在 echo request 消息中. 一个 echo request 中只能出现一个下游映射对象. 下游映射对象的存在, 表示请求在 echo reply 中包含下游映射对象. 若应答路由器是该 FEC 的目的地, 则 echo reply 中不应 (SHOULD NOT) 包含下游映射 TLV. 否则, 应答路由器应当 (SHOULD) 为每个可将该 FEC 转发出去的接口包含一个下游映射对象. 关于 "下游" 这一概念的更精确定义, 见 3.3.2 节 "下游路由器与接口 (Downstream Router and Interface)".

Length 为 K + M + 4*N 字节, 其中 M 是多路径长度 (Multipath Length), N 是下游标签 (Downstream Label) 的数量. K 的取值见下文地址类型 (Address Type) 的描述. 下游映射的 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

最大传输单元 (Maximum Transmission Unit, MTU)

MTU 是适合于通往下游 LSR 的接口的最大 MPLS 帧 (包括标签栈) 的大小, 以字节为单位.

地址类型 (Address Type)

地址类型指示接口是有编号的 (numbered) 还是无编号的 (unnumbered). 它同时决定 Downstream IP Address 与 Downstream Interface 字段的长度. TLV 初始部分的总长度在下表中列为 "K Octets". 地址类型设置为下列值之一:

     Type #        Address Type           K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28

DS Flags (下游标志)

DS Flags 字段是一个具有如下格式的位向量:

     0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+

当前定义了两个标志位 I 与 N. 其余标志位在发送时必须 (MUST) 置为零, 在接收时被忽略.

标志名称与含义
IInterface and Label Stack Object Request (接口与标签栈对象请求): 该标志置位时, 表示应答路由器应当 (SHOULD) 在 echo reply 消息中包含一个 Interface and Label Stack 对象.
NTreat as a Non-IP Packet (作为非 IP 分组处理): echo request 消息将被用于诊断非 IP 流. 然而, 这些消息本身承载于 IP 分组之中. 对于根据 FEC 或深度分组检测来改变其 ECMP 算法的路由器, 该标志请求路由器按照在 IP 载荷判定失败时本应采取的方式进行处理.

Downstream IP Address 与 Downstream Interface Address

IPv4 地址与接口索引编码为 4 个字节; IPv6 地址编码为 16 个字节.

若通往下游 LSR 的接口是有编号的, 则地址类型必须 (MUST) 设置为 IPv4 或 IPv6, Downstream IP Address 必须设置为下游 LSR 的 Router ID 或下游 LSR 的接口地址, 并且 Downstream Interface Address 必须设置为下游 LSR 的接口地址.

若通往下游 LSR 的接口是无编号的, 则地址类型必须是 IPv4 Unnumbered 或 IPv6 Unnumbered, Downstream IP Address 必须是下游 LSR 的 Router ID, 并且 Downstream Interface Address 必须设置为上游 LSR 分配给该接口的索引.

若某个 LSR 不知道其邻居的 IP 地址, 则它必须将地址类型设置为 IPv4 Unnumbered 或 IPv6 Unnumbered. 对于 IPv4, 它必须将 Downstream IP Address 设置为 127.0.0.1; 对于 IPv6, 地址设置为 0::1. 两种情况下, 接口索引都必须置为 0. 若某个 LSR 收到的 Echo Request 分组在 Downstream IP Address 字段中带有上述地址之一, 则表示它必须跳过接口验证, 但继续进行标签验证.

若 Echo Request 分组的发起方希望获得下游映射信息, 但不知道期望的标签栈, 则它应当 (SHOULD) 将地址类型设置为 IPv4 Unnumbered 或 IPv6 Unnumbered. 对于 IPv4, 它必须将 Downstream IP Address 设置为 224.0.0.2; 对于 IPv6, 地址必须设置为 FF02::2. 两种情况下, 接口索引都必须置为 0. 若某个 LSR 收到的 Echo Request 分组带有全路由器组播地址 (all-routers multicast address), 则表示它必须同时跳过接口与标签栈验证, 但使用所提供的信息返回下游映射 TLV.

多路径类型 (Multipath Type)

定义了下列多路径类型:

键值类型多路径信息
0no multipath (无多路径)空 (Multipath Length = 0)
2IP address (IP 地址)IP 地址
4IP address range (IP 地址范围)低/高地址对
8Bit-masked IP address set (位掩码 IP 地址集)IP 地址前缀与位掩码
9Bit-masked label set (位掩码标签集)标签前缀与位掩码

类型 0 表示所有分组都将从这一个接口转发出去.

类型 2, 4, 8 与 9 表示所提供的多路径信息将用于驱动 (exercise) 这条路径.

深度限制 (Depth Limit)

深度限制仅适用于标签栈, 是哈希计算中考虑的最大标签数; 若未指定或不作限制, 应当 (SHOULD) 置为零.

多路径长度 (Multipath Length)

多路径信息 (Multipath Information) 的长度, 以字节为单位.

多路径信息 (Multipath Information)

按照多路径类型编码的地址或标签值. 编码细节见下一节.

下游标签 (Downstream Label(s))

标签栈在该路由器经由这个接口转发分组时所应有的标签集合. 任何 Implicit Null 标签都被显式包含. 标签被当作数字处理, 即在字段中右对齐.

一个下游标签为 24 比特, 其格式与 MPLS 标签相同但不含 TTL 字段, 即标签的最高位 (MSBit) 为比特 0, 最低位 (LSBit) 为比特 19, EXP 位为比特 20-22, 比特 23 为 S 位. 应答路由器应当 (SHOULD) 填写 EXP 与 S 位; 接收 echo reply 的 LSR 可以 (MAY) 选择忽略这些位.

协议 (Protocol)

协议取自下表:

Protocol #信令协议
0Unknown (未知)
1Static (静态)
2BGP
3LDP
4RSVP-TE

3.3.1. 多路径信息编码 (Multipath Information Encoding)​

多路径信息 (Multipath Information) 对将要驱动此路径的标签或地址进行编码. 多路径信息取决于多路径类型, 该字段的内容见上表. IPv4 地址取自 127/8 范围; IPv6 地址取自 0:0:0:0:0:FFFF:127/104 范围. 标签被当作数字处理, 即在字段中右对齐. 对于类型 4, 地址对所指示的范围禁止 (MUST NOT) 重叠, 并且必须 (MUST) 按升序排列.

类型 8 允许对 IP 地址进行更紧凑的编码. IP 前缀的格式为一个基础 IP 地址, 其非前缀的低位比特置为零. 最大前缀长度为 27. 前缀之后跟随一个掩码, 对于 IPv4 其长度为 2^(32-前缀长度) 比特, 对于 IPv6 其长度为 2^(128-前缀长度) 比特. 每一个置 1 的比特代表一个有效地址. 该地址等于基础 IPv4 地址加上该比特在掩码中的位置, 其中比特自左向右从零开始编号. 例如, IPv4 地址 127.2.1.0, 127.2.1.5-127.2.1.15 与 127.2.1.20-127.2.1.29 将按如下方式编码:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

这些相同的地址嵌入 IPv6 中时, 将按如下方式编码:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

类型 9 允许对标签进行更紧凑的编码. 标签前缀的格式为一个基础标签值, 其非前缀的低位比特置为零. 最大前缀长度 (包括因编码产生的前导零) 为 27. 前缀之后跟随一个长度为 2^(32-前缀长度) 比特的掩码. 每一个置 1 的比特代表一个有效标签. 该标签等于基础标签加上该比特在掩码中的位置, 其中比特自左向右从零开始编号. 1152 到 1279 之间的所有奇数标签值将按如下方式编码:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

注: 英文原文 (RFC 4379) 中该示例的位图在排版换行处发生断裂, 此处按其语义整理为两行 32 比特的掩码: 第一行为基础标签 1152 的前缀 (置位的比特对应 1152 = 0b10010000000), 第二行为间隔置位的奇数掩码.

若收到的多路径信息非空, 则标签和 IP 地址必须 (MUST) 从所提供的集合中选取; 若这些标签或地址均不映射到某个特定的下游接口, 则该接口的多路径类型必须 (MUST) 设为 0. 若收到的多路径信息为空 (即 Multipath Length = 0, 或对于类型 8 与 9, 掩码全为零), 则多路径类型必须 (MUST) 设为 0.

例如, 假设位于第 10 跳的 LSR X 对于所讨论的 FEC 有两个下游 LSR Y 和 Z. X 可以返回多路径类型 4, 对于下游 LSR Y 给出低/高 IP 地址 127.1.1.1->127.1.1.255, 对于下游 LSR Z 给出 127.2.1.1->127.2.1.255. 头端 (head end) 将该信息反射给 LSR Y. Y 有三个下游 LSR: U, V 和 W. Y 计算出 127.1.1.1->127.1.1.127 将去往 U, 127.1.1.128->127.1.1.255 将去往 V. 于是 Y 将以 3 个下游映射应答: 去往 U 的, 多路径类型 4 (127.1.1.1->127.1.1.127); 去往 V 的, 多路径类型 4 (127.1.1.127->127.1.1.255); 以及去往 W 的, 多路径类型 0.

注意, 计算多路径信息可能给接收方带来显著的处理负担. 因此, 接收方可以 (MAY) 选择仅处理所收到前缀的一个子集. 发送方在收到带有部分信息的下游映射应答时, 应当 (SHOULD) 假定应答中缺失的前缀已被接收方跳过, 并可以 (MAY) 在新的 echo request 中重新请求这些信息.

3.3.2. 下游路由器与接口 (Downstream Router and Interface)​

"下游路由器" 与 "下游接口" 的含义说明如下. 考虑 LSR X. 若一个以 TTL n>1 发起, 以最外层标签 L 且 TTL=1 到达 LSR X 的分组, X 必须能计算出: 若以 TTL=n+1 发起, 哪些 LSR 可能收到该分组, 经哪个接口到达, 以及这些 LSR 会看到什么标签栈. (如何完成此计算超出本文档范围.) 这些 LSR/接口的集合即为 X 相对于 L 的下游路由器/接口 (及其相应标签). 每一对下游路由器与接口都需要在应答中添加一个单独的下游映射.

X 作为发起 echo request 的 LSR 是一种特殊情况: X 需要算出对于给定的, 以 TTL=1 发起的 FEC 栈, 哪些 LSR 会收到该 MPLS echo request.

X 处的下游路由器集合可能是替代路径 (见下文 ECMP 讨论) 或同时路径 (如 MPLS 组播). 前者情况下, 多路径信息用作对发送方的提示, 告知其如何影响这些替代路径的选择.

3.4. 填充 TLV (Pad TLV)​

Pad TLV 的值部分包含可变数量 (>= 1) 的字节. 第一字节取值如下表; 其余字节 (若有) 被忽略. 接收方应当 (SHOULD) 验证该 TLV 被完整接收, 但除此之外应忽略本 TLV 的内容 (首字节除外):

值含义
1从应答中丢弃 Pad TLV (Drop Pad TLV from reply)
2复制 Pad TLV 到应答 (Copy Pad TLV to reply)
3-255保留供将来使用

3.5. 供应商企业编号 (Vendor Enterprise Number)​

SMI 私有企业编号 (SMI Private Enterprise Numbers) 由 IANA 维护. Length 恒为 4; 值为供应商的 SMI 私有企业代码 (按网络字节序), 该供应商对消息固定部分中的某个字段作了供应商私有 (Vendor Private) 扩展, 此时此 TLV 必须 (MUST) 出现. 若消息固定部分中没有任何字段带供应商私有扩展, 则包含此 TLV 是可选的 (OPTIONAL). 已为消息类型, 回复模式与返回码定义了供应商私有范围; 使用其中任何一个值时, 消息中必须 (MUST) 包含供应商企业编号 TLV.

3.6. 接口与标签栈 (Interface and Label Stack)​

Interface and Label Stack TLV 可以 (MAY) 包含在应答消息中, 用于报告接收到请求消息的接口以及分组被接收时所带的标签栈. 只能出现一个这样的对象. 该对象的目的在于, 让上游路由器能够获得在应答 LSR 处呈现的精确的接口与标签栈信息.

Length 为 K + 4*N 字节; N 是标签栈中的标签数量. K 的取值见下文地址类型 (Address Type) 的描述. 该对象的 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

地址类型 (Address Type)

地址类型指示接口是有编号的还是无编号的. 它同时决定 IP Address 与 Interface 字段的长度. TLV 初始部分的总长度在下表中列为 "K Octets". 地址类型设置为下列值之一:

     Type #        Address Type           K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24

IP Address 与 Interface

IPv4 地址与接口索引编码为 4 个字节; IPv6 地址编码为 16 个字节.

若接收到 echo request 消息的接口是有编号的, 则地址类型必须 (MUST) 设置为 IPv4 或 IPv6, IP Address 必须设置为该 LSR 的 Router ID 或接口地址, 并且 Interface 必须设置为该接口地址.

若接口是无编号的, 则地址类型必须是 IPv4 Unnumbered 或 IPv6 Unnumbered, IP Address 必须是该 LSR 的 Router ID, 并且 Interface 必须设置为分配给该接口的索引.

标签栈 (Label Stack)

接收到的 echo request 消息的标签栈. 若本路由器更改过任何 TTL 值, 则应当 (SHOULD) 将其恢复.

3.7. 出错的 TLV (Errored TLVs)​

下列 TLV 可以 (MAY) 包含在 echo reply 中, 用于向 echo request 的发送方告知那些未被实现支持, 或者经解析后发现存在错误的强制 (mandatory) TLV.

Value 字段包含那些未被理解的 TLV, 编码为子 TLV (sub-TLV):

    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 = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.8. 回复 TOS 字节 TLV (Reply TOS Byte TLV)​

此 TLV 可以 (MAY) 由 echo request 的发起方使用, 用于请求以 IP 首部 TOS 字节设置为该 TLV 中指定值的方式发送 echo reply. 此 TLV 的长度为 4, 其值字段如下:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+