RFC 5036 - LDP 规范
- 状态: Draft Standard
- 发布日期: October 2007
- Stream: IETF
- 废弃了: RFC3036
- 勘误: 无勘误
摘要
本文档规定了标签分发协议 (Label Distribution Protocol, LDP), 该协议使标签交换路由器 (LSR) 能够分发标签, 以便在 MPLS 网络中建立标签交换路径 (LSP).
相关资源
- 官方文本:
https://www.rfc-editor.org/rfc/rfc5036.txt - 官方页面:
https://datatracker.ietf.org/doc/html/rfc5036
正文译文
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
Address List TLV 发送方 LSR 正在撤回的接口地址列表. Address List TLV 的编码在 Section "Address List TLV" 中规定.
Optional Parameters 未为 Address Withdraw message 定义可选参数.
3.5.6.1. Address Withdraw Message 过程
参见 Section "Address Message Procedures".
3.5.7. Label Mapping Message
LSR 向 LDP 对等方发送 Label Mapping message, 以向该对等方通告 FEC-label 绑定.
Label Mapping message 的编码为:
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| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
FEC TLV 指定所通告 FEC-Label 映射中的 FEC 组成部分. 编码见 Section "FEC TLVs".
Label TLV 指定 FEC-Label 映射中的 Label 组成部分. 编码见 Section "Label TLV".
Optional Parameters 此可变长度字段包含 0 个或多个参数, 每个参数均编码为 TLV. 可选参数为:
Optional Parameter Length Value
Label Request 4 见下文
Message ID TLV
Hop Count TLV 1 见下文
Path Vector TLV variable 见下文
Hop Count 和 Path Vector TLV 的编码见 Section "TLV Encodings for
Commonly Used Parameters".
Label Request Message ID
如果此 Label Mapping message 是对 Label Request message 的响应,
则它必须包含 Label Request Message ID 可选参数. 此可选参数的值是
对应 Label Request message 的 Message ID.
Hop Count
指定由 Label message 正在建立的 LSP 沿途 LSR 跳数的运行总计.
Section "Hop Count Procedures" 描述如何处理此 TLV.
Path Vector
指定由 Label message 正在建立的 LSP 沿途的 LSR. Section
"Path Vector Procedures" 描述如何处理此 TLV.
3.5.7.1. Label Mapping Message 过程
Mapping message 由 LSR 用于向 LDP 对等方分发某个 FEC 的标签映射. 如果 LSR 向多个 LDP 对等方分发某个 FEC 的映射, 则它是将单个标签 映射到该 FEC 并将该映射分发给所有对等方, 还是为每个对等方使用 不同映射, 均属于本地事项.
LSR 负责保证其已分发标签映射的一致性, 并负责保证其对等方拥有这些 映射.
从下游 LSR 接收针对 Prefix 的 Label Mapping message 的 LSR, 不应该将该 标签用于转发, 除非其路由表包含与该 FEC Element 精确匹配的条目.
更多细节见 Appendix A, "LDP Label Distribution Procedures".
3.5.7.1.1. Independent Control Mapping
如果 LSR 配置为 independent control, 则在以下任一条件下, 该 LSR 会传输 mapping message:
1. LSR 通过转发表识别出新的 FEC, 并且标签通告模式为
Downstream Unsolicited advertisement.
2. LSR 从上游对等方收到针对 LSR 转发表中存在的 FEC 的 Request
message.
3. 某个 FEC 的下一跳变更为另一个 LDP 对等方, 并且已配置 Loop
detection.
4. 映射的属性发生变化.
5. 从下游下一跳接收到映射 AND
a) 尚未创建上游映射 OR
b) 已配置 loop detection OR
c) 映射的属性已发生变化.
3.5.7.1.2. Ordered Control Mapping
如果 LSR 正在执行 Ordered Control, 则下游 LSR 会在以下任一条件下传输 Mapping message:
1. LSR 通过转发表识别出新的 FEC, 并且它是该 FEC 的出口.
2. LSR 从上游对等方收到针对 LSR 转发表中存在的 FEC 的 Request
message, 并且该 LSR 是该 FEC 的出口 OR 拥有该 FEC 的下游映射.
3. 某个 FEC 的下一跳变更为另一个 LDP 对等方, 并且已配置 Loop
Detection.
4. 映射的属性发生变化.
5. 从下游下一跳接收到映射 AND
a) 尚未创建上游映射 OR
b) 已配置 Loop Detection OR
c) 映射的属性已发生变化.
3.5.7.1.3. Downstream on Demand Label Advertisement
通常, 在 Downstream on Demand 模式下运行时, 上游 LSR 负责请求标签 映射. 然而, 除非遵循某些规则, 否则具有不同通告模式的相邻 LSR 可能 进入一种 livelock 状态, 即一切都正常运行, 但没有标签被
分发. 例如, 考虑两个 LSR Ru 和 Rd, 其中 Ru 是某一特定 FEC 的上游 LSR, Rd 是下游 LSR. 在此示例中, Ru 使用 Downstream Unsolicited advertisement 模式, Rd 使用 Downstream on Demand 模式. 在这种情况下, Rd 可能认为 Ru 在需要标签映射时会发起请求, 而 Ru 可能认为如果 Rd 希望 Ru 使用某个标签, Rd 会通告该标签. 如果 Rd 和 Ru 按上述方式运行, 则不会有标签从 Rd 分发到 Ru.
如果遵守以下规则, 可以避免这种 livelock 状态: 不应该期望以 Downstream on Demand 模式运行的 LSR 发送非请求的映射通告. 因此, 如果下游 LSR 正在 Downstream on Demand 模式下运行, 则上游 LSR 负责按需请求标签 映射.
3.5.7.1.4. Downstream Unsolicited Label Advertisement
通常, 当下游 LSR 希望上游 LSR 使用某个标签时, 它负责通告该标签映射. 上游 LSR 可以按自身需要发起映射请求.
Downstream Unsolicited 模式与 Conservative Label retention 的组合可能 导致一种情况, 即 LSR 释放了后续又需要的某个 FEC 的标签. 例如, 如果 LSR Rd 向 LSR Ru 通告某个 FEC 的标签, 而 Rd 并不是 Ru 针对该 FEC 的 下一跳, 则 Ru 会释放该标签. 如果 Ru 针对该 FEC 的下一跳后来变更为 Rd, 则它需要先前已释放的标签.
为处理这种情况, Ru 可以在需要时显式请求该标签, 或者 Rd 可以周期性地 向 Ru 重新通告该标签. 在许多情况下, Ru 会知道自己何时需要来自 Rd 的 标签. 例如, 当其针对该 FEC 的下一跳变更为 Rd 时. 然而, 也可能存在 Ru 不知道的情况. 例如, Rd 可能正在尝试建立具有非标准属性的 LSP. 在这种情况下强制 Ru 显式请求该标签, 将要求它维护关于潜在的、具有 非标准属性的 LSP 的状态.
在 Ru 知道自己需要该标签的情况下, 它负责通过 Label Request message 显式请求该标签. 在 Ru 可能不知道自己需要该标签的情况下, Rd 负责 周期性地向 Ru 重新通告该标签.
对于此版本的 LDP, Ru 知道自己需要来自 Rd 的某个 FEC 标签的唯一情况 是: Rd 是其针对该 FEC 的下一跳, Ru 没有来自 Rd 的标签, 并且该 FEC 的 LSP 是一个可以使用本文档中定义的 TLV 建立的 LSP.
3.5.8. Label Request Message
LSR 向 LDP 对等方发送 Label Request message, 以请求某个 FEC 的绑定 (映射).
Label Request message 的编码为:
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| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
FEC TLV 正在为其请求标签的 FEC. 编码见 Section "FEC TLV".
Optional Parameters 此可变长度字段包含 0 个或多个参数, 每个参数均编码为 TLV. 可选参数为:
Optional Parameter Length Value
Hop Count TLV 1 见下文
Path Vector TLV variable 见下文
Hop Count 和 Path Vector TLV 的编码见 Section "TLV Encodings for
Commonly Used Parameters".
Hop Count 指定由 Label Request message 正在建立的 LSP 沿途 LSR 跳数的运行总计. Section "Hop Count Procedures" 描述如何处理此 TLV.
Path Vector 指定由 Label Request message 正在建立的 LSP 沿途的 LSR. Section "Path Vector Procedures" 描述如何处理此 TLV.
3.5.8.1. Label Request Message 过程
Request message 由上游 LSR 用于显式请求下游 LSR 为某个 FEC 分配并通告 标签.
LSR 可以在以下任一条件下传输 Request message:
1. LSR 通过转发表识别出新的 FEC, 并且下一跳是 LDP 对等方, 且该
LSR 尚未拥有来自该下一跳的、针对给定 FEC 的映射.
2. 到该 FEC 的下一跳发生变化, 且该 LSR 尚未拥有来自该下一跳的、
针对给定 FEC 的映射.
注意, 如果该 LSR 已经有一个发往新下一跳的待处理 Label Request
message, 则它不应该因下一跳变化而发起额外的 Label Request.
3. LSR 从上游 LDP 对等方收到针对某个 FEC 的 Label Request, 该 FEC
的下一跳是 LDP 对等方, 且该 LSR 尚未拥有来自该下一跳的映射.
注意, 由于 non-merge LSR 必须为每个请求标签的上游对等方建立
单独的 LSP, 因而它必须为每个此类对等方发送单独的 Label
Request. 其结果是, non-merge LSR 可以同时有多个针对给定 FEC 的
Label Request message 处于未完成状态.
接收方 LSR 应该用所请求标签的 Label Mapping, 或用说明其为何无法满足 请求的 Notification message 来响应 Label Request message.
当请求标签的 FEC 是 Prefix FEC Element 时, 接收方 LSR 使用其路由表来 确定响应. 除非其路由表包含与所请求 Prefix 精确匹配的条目, 否则该 LSR 必须以 No Route Notification message 响应.
Label Request message 的 message ID 用作 Label Request 事务的标识符. 当接收方 LSR 用 Label Mapping message 响应时, 该 mapping message 必须 包含 Label Request/Returned Message ID TLV 可选参数, 该参数包含 Label Request message 的 message ID. 注意, 由于 LSR 使用 Label Request message ID 作为事务标识符, LSR 不应该在相应事务完成之前复用 Label Request message 的 message ID.
此版本的协议为指示请求无法满足的 Notification message 定义以下 Status Codes:
No Route
请求标签的 FEC 包含一个 FEC Element, LSR 对该 FEC Element 没有
路由.
No Label Resources
由于资源限制, LSR 无法提供标签. 当资源变为可用时, LSR 必须通过
发送带有 Label Resources Available Status Code 的 Notification
message 来通知请求方 LSR.
收到针对 Label Request message 的 No Label Resources 响应的 LSR,
在收到带有 Label Resources Available Status Code 的 Notification
message 之前, 不得再发起 Label Request message.
Loop Detected
LSR 已检测到循环的 Label Request message.
更多细节见 Appendix A, "LDP Label Distribution Procedures".
3.5.9. Label Abort Request Message
Label Abort Request message 可以用于中止未完成的 Label Request message.
Label Abort Request message 的编码为:
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| Label Abort Req (0x0404) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Request Message ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
FEC TLV 标识正在被中止的 Label Request 所对应的 FEC.
Label Request Message ID TLV 指定将被中止的 Label Request message 的 message ID.
Optional Parameters 未为 Label Abort Req message 定义可选参数.
3.5.9.1. Label Abort Request Message 过程
在以下情况下, LSR Ru 可以向 LSR Rd 发送 Label Abort Request message, 以中止发往 LSR Rd 的、针对某个 FEC 的未完成 Label Request message:
1. Ru 针对该 FEC 的下一跳已从 LSR Rd 变更为 LSR X; 或
2. Ru 是 non-merge, non-ingress LSR, 并且已从上游对等方 Y 收到针对
该 FEC 的 Label Abort Request.
3. Ru 是 merge, non-ingress LSR, 并且已从上游对等方 Y 收到针对该
FEC 的 Label Abort Request, 且 Y 是唯一 (最后一个) 为该 FEC 请求
标签的上游 LSR.
还可能存在其他情况, LSR 可以选择中止未完成的 Label Request message, 以回收与待处理 LSP 关联的资源. 然而, 规定使用中止机制的通用策略 超出了 LDP 的范围.
当 LSR 收到 Label Abort Request message 时, 如果它此前尚未用 Label Mapping message 或其他 Notification message 响应正在被中止的 Label Request, 则它必须通过返回 Label Request Aborted Notification message 来确认该中止. 该 Notification 必须包含 Label Request Message ID TLV, 其中携带被中止的 Label Request message 的 message ID.
如果 LSR 在已用 Label Mapping message 或 Notification message 响应相关 Label Request 之后收到 Label Abort Request Message, 则它忽略该中止请求.
如果 LSR 在已发送 Label Abort Request message 以中止 Label Request 之后, 收到作为 Label Request message 响应的 Label Mapping message, 则 Label Mapping message 中的标签是有效的. LSR 可以选择使用该标签, 或使用 Label Release message 将其释放.
中止 Label Request message 的 LSR 不得复用该 Label Request message 的 Message ID, 直到它从其对等方收到以下任一消息:
- 确认该中止的 Label Request Aborted Notification message;
- 响应正在被中止的 Label Request message 的 Label Mapping message;
- 响应正在被中止的 Label Request message 的 Notification message
(例如, Loop Detected, No Label Resources 等).
为保护自身免受迟滞对等方或有缺陷的对等方实现影响, LSR 可以选择对 接收上述消息设置超时. 该超时周期应该相对较长 (数分钟). 如果超时周期 届满而未收到对等方回复, LSR 可以复用 Label Request message 的 Message ID; 如果这样做, 它还应该丢弃任何关于未完成 Label Request 和 Label Abort message 的记录.
注意, 对 Label Abort Request message 的响应绝不是 "ordered". 也就是说, 该响应不依赖于正在被中止的 LSP 建立过程的下游状态. 收到 Label Abort Request message 的 LSR 必须立即处理它, 无论 LSP 的下游状态如何, 并 根据情况返回 Label Request Aborted Notification 或忽略它.
3.5.10. Label Withdraw Message
LSR 向 LDP 对等方发送 Label Withdraw Message, 以通知该对等方不得继续 使用该 LSR 先前通告的特定 FEC-label 映射. 这会断开 FEC 与标签之间的 映射.
Label Withdraw Message 的编码为:
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| Label Withdraw (0x0402) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
FEC TLV 标识正在撤回其 FEC-label 映射的 FEC.
Optional Parameters 此可变长度字段包含 0 个或多个参数, 每个参数均编码为 TLV. 可选参数为:
Optional Parameter Length Value
Label TLV variable 见下文
Label TLV 的编码见 Section "Label TLVs".
Label
如果存在, 指定正在撤回的标签 (见下文过程).
3.5.10.1. Label Withdraw Message 过程
LSR 在以下条件下传输 Label Withdraw message:
1. LSR 不再识别某个先前已知且它曾为其通告过标签的 FEC.
2. LSR 已单方面决定 (例如通过配置) 不再使用正在撤回的标签映射对
某个 FEC (或多个 FEC) 进行标签交换.
FEC TLV 指定要撤回标签的 FEC. 如果 FEC 后未跟随 Label TLV, 则与该 FEC 关联的所有标签都将被撤回; 否则, 仅撤回可选 Label TLV 中指定的 标签.
FEC TLV 可以包含 Wildcard FEC Element; 如果包含, 则它不得包含其他 FEC Elements. 在这种情况下, 如果 Label Withdraw message 包含可选 Label TLV, 则该标签将从其绑定到的所有 FEC 中撤回. 如果 Label Withdraw message 中 没有可选 Label TLV, 则发送方 LSR 正在撤回此前通告给接收方 LSR 的所有 标签映射.
收到 Label Withdraw message 的 LSR 必须以 Label Release message 响应.
更多细节见 Appendix A, "LDP Label Distribution Procedures".
3.5.11. Label Release Message
LSR 向 LDP 对等方发送 Label Release message, 以通知该对等方: 该 LSR 不再需要此前向该对等方请求和/或由该对等方通告的特定 FEC-label 映射.
Label Release Message 的编码为:
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| Label Release (0x0403) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 用于标识此消息的 32-bit 值.
FEC TLV 标识正在释放其 FEC-label 映射的 FEC.
Optional Parameters 此可变长度字段包含 0 个或多个参数, 每个参数均编码为 TLV. 可选参数为:
Optional Parameter Length Value
Label TLV variable 见下文
Label TLV 的编码见 Section "Label TLVs".
Label
如果存在, 表示正在释放的标签 (见下文过程).
3.5.11.1. Label Release Message 过程
当 LSR 不再需要此前从某个对等方接收或向该对等方请求的标签时, 它会向 该对等方传输 Label Release message.
在以下任一条件下, LSR 必须传输 Label Release message:
1. 发送该标签映射的 LSR 不再是被映射 FEC 的下一跳, 且该 LSR 配置为
conservative operation.
2. LSR 从一个并非该 FEC 下一跳的 LSR 接收到标签映射, 且该 LSR 配置为
conservative operation.
3. LSR 收到 Label Withdraw message.
注意, 如果 LSR 配置为 "liberal mode", 在上述条件 (1) 和 (2) 的情况下, 永远不会传输 release message. 在这种情况下, 上游 LSR 保留每个未使用的 标签, 以便当下游对等方成为该 FEC 的下一跳时, 稍后可以立即使用该标签.
FEC TLV 指定要释放标签的 FEC. 如果 FEC 后未跟随 Label TLV, 则与该 FEC 关联的所有标签都将被释放; 否则, 仅释放可选 Label TLV 中指定的标签.
FEC TLV 可以包含 Wildcard FEC Element; 如果包含, 则它不得包含其他 FEC Elements. 在这种情况下, 如果 Label Release message 包含可选 Label TLV, 则该标签将针对其绑定到的所有 FEC 释放. 如果 Label Release message 中 没有可选 Label TLV, 则发送方 LSR
正在释放此前从接收方 LSR 学到的所有标签映射.
更多细节见 Appendix A, "LDP Label Distribution Procedures".
3.6. 用于可扩展性的消息和 TLV
对 LDP 可扩展性的支持包括 U- 和 F-bit 规则, 这些 bit 指定 LSR 如何处理 未知 TLV 和消息.
本节规定用于 vendor-private 和 experimental 用途的 TLV 和消息.
3.6.1. LDP Vendor-Private 扩展
Vendor-private TLV 和消息用于在 LSR 之间传递 vendor-private 信息.
3.6.1.1. LDP Vendor-Private TLV
Type 范围 0x3E00 到 0x3EFF 保留用于 vendor-private TLV.
vendor-private 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x3E00-0x3EFF) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data.... | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit Unknown TLV bit. 收到未知 TLV 时, 如果 U 被清零 (=0), 则必须向消息 发起方返回 notification, 并且必须忽略整个消息; 如果 U 被置位 (=1), 则静默忽略未知 TLV, 并像该未知 TLV 不存在一样处理消息的其余部分.
对 vendor-private 消息是否被理解的判定, 基于 Type 和强制的 Vendor
ID 字段.
支持 vendor-private TLV 的实现必须支持一个用户可访问的配置接口, 使
所有传输的 vendor-private TLV 上的 U-bit 被置位; 此要求可以由一个
用户可访问的配置接口来满足, 该接口阻止传输所有 U-bit 被清零的
vendor-private TLV.
F-bit Forward unknown TLV bit. 仅当 U-bit 被置位且包含未知 TLV 的 LDP message 将被转发时, 此 bit 才适用. 如果 F 被清零 (=0), 未知 TLV 不随 包含它的消息一起转发; 如果 F 被置位 (=1), 未知 TLV 随包含它的消息 一起转发.
Type 范围 0x3E00 到 0x3EFF 内的 Type 值. Type 与 Vendor ID 字段共同指定 如何解释 Data 字段.
Length 指定 Vendor ID 和 Data 字段以 octet 计的累计长度.
Vendor ID IEEE 分配的 802 Vendor ID.
Data Value 字段中 Vendor ID 之后的剩余 octet 是可选的 vendor-dependent data.
3.6.1.2. LDP Vendor-Private Messages
Message Type 范围 0x3E00 到 0x3EFF 保留用于 Vendor-Private messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Msg Type (0x3E00-0x3EFF) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+
| Remaining Mandatory Parameters |
-
+
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
-
+
| Optional Parameters |
-
+
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit Unknown message bit. 收到未知消息时, 如果 U 被清零 (=0), 则向消息 发起方返回 notification; 如果 U 被置位 (=1), 则静默忽略未知消息.
对 Vendor-Private message 是否被理解的判定, 基于 Msg Type 和
Vendor ID 参数.
支持 Vendor-Private message 的实现必须支持一个用户可访问的配置接口,
使所有传输的 Vendor-Private message 上的 U-bit 被置位; 此要求可以由
一个用户可访问的配置接口来满足, 该接口阻止传输所有 U-bit 被清零的
Vendor-Private message.
Msg Type 范围 0x3E00 到 0x3EFF 内的 Message Type 值. Msg Type 与 Vendor ID 共同指定如何解释该消息.
Message Length 指定 Message ID, Vendor ID, Remaining Mandatory Parameters 和 Optional Parameters 以 octet 计的累计长度.
Message ID 用于标识此消息的 32-bit 整数. 发送方 LSR 使用它来便于识别可能适用于 此消息的 Notification message. 响应此消息而发送 Notification message 的 LSR 将在 notification message 中包含此 Message ID; 见 Section "Notification Message".
Vendor ID IEEE 分配的 802 Vendor ID.
Remaining Mandatory Parameters 剩余必需消息参数的可变长度集合.
Optional Parameters 可选消息参数的可变长度集合.
3.6.2. LDP Experimental 扩展
LDP 对 experimentation 的支持类似于对 vendor-private 扩展的支持, 但有以下 差异:
- Type 范围 0x3F00 到 0x3FFF 保留用于 experimental TLV.
- Message Type 范围 0x3F00 到 0x3FFF 保留用于 experimental message.
- experimental TLV 和 message 的编码类似于 vendor-private 编码, 但
存在以下差异.
Experimental TLV 和 message 使用 Experiment ID 字段替代 Vendor ID
字段. Experiment ID 字段与 Type 或 Message Type 字段一起使用, 用于
指定 experimental TLV 或 Message 的解释方式.
Experiment ID 的管理由实验者负责.
3.7. 消息摘要
以下是本协议版本中定义的 LDP 消息.
Message Name Type Section Title
Notification 0x0001 "Notification Message"
Hello 0x0100 "Hello Message"
Initialization 0x0200 "Initialization Message"
KeepAlive 0x0201 "KeepAlive Message"
Address 0x0300 "Address Message"
Address Withdraw 0x0301 "Address Withdraw Message"
Label Mapping 0x0400 "Label Mapping Message"
Label Request 0x0401 "Label Request Message"
Label Withdraw 0x0402 "Label Withdraw Message"
Label Release 0x0403 "Label Release Message"
Label Abort Request 0x0404 "Label Abort Request Message"
Vendor-Private 0x3E00- "LDP Vendor-Private Extensions"
0x3EFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.8. TLV 摘要
以下是本协议版本中定义的 TLV.
TLV Type Section Title
FEC 0x0100 "FEC TLV"
Address List 0x0101 "Address List TLV"
Hop Count 0x0103 "Hop Count TLV"
Path Vector 0x0104 "Path Vector TLV"
Generic Label 0x0200 "Generic Label TLV"
ATM Label 0x0201 "ATM Label TLV"
Frame Relay Label 0x0202 "Frame Relay Label TLV"
Status 0x0300 "Status TLV"
Extended Status 0x0301 "Notification Message"
Returned PDU 0x0302 "Notification Message"
Returned Message 0x0303 "Notification Message"
Common Hello 0x0400 "Hello Message"
Parameters
IPv4 Transport Address 0x0401 "Hello Message"
Configuration 0x0402 "Hello Message"
Sequence Number
IPv6 Transport Address 0x0403 "Hello Message"
Common Session 0x0500 "Initialization Message"
Parameters
ATM Session Parameters 0x0501 "Initialization Message"
Frame Relay Session 0x0502 "Initialization Message"
Parameters
Label Request 0x0600 "Label Mapping Message"
Message ID
Vendor-Private 0x3E00- "LDP Vendor-Private Extensions"
0x3EFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.9. Status Code 摘要
以下是本协议版本中定义的 Status Code.
"E" 列是 Status Code E-bit 的必需设置; "Status Data" 列是 Status Code TLV 中 30-bit Status Data 字段的值. 请注意, Status Code F-bit 的设置由 生成 Status TLV 的 LSR 自行决定.
Status Code E Status Data Section Title
Success 0 0x00000000 "Status TLV"
Bad LDP Identifier 1 0x00000001 "Events Signaled by ..."
Bad Protocol Version 1 0x00000002 "Events Signaled by ..."
Bad PDU Length 1 0x00000003 "Events Signaled by ..."
Unknown Message Type 0 0x00000004 "Events Signaled by ..."
Bad Message Length 1 0x00000005 "Events Signaled by ..."
Unknown TLV 0 0x00000006 "Events Signaled by ..."
Bad TLV Length 1 0x00000007 "Events Signaled by ..."
Malformed TLV Value 1 0x00000008 "Events Signaled by ..."
Hold Timer Expired 1 0x00000009 "Events Signaled by ..."
Shutdown 1 0x0000000A "Events Signaled by ..."
Loop Detected 0 0x0000000B "Loop Detection"
Unknown FEC 0 0x0000000C "FEC Procedures"
No Route 0 0x0000000D "Label Request Mess ..."
No Label Resources 0 0x0000000E "Label Request Mess ..."
Label Resources / 0 0x0000000F "Label Request Mess ..."
Available
Session Rejected/ 1 0x00000010 "Session Initialization"
No Hello
Session Rejected/ 1 0x00000011 "Session Initialization"
Parameters Advertisement Mode
Session Rejected/ 1 0x00000012 "Session Initialization"
Parameters Max PDU Length
Session Rejected/ 1 0x00000013 "Session Initialization"
Parameters Label Range
KeepAlive Timer 1 0x00000014 "Events Signaled by ..."
Expired
Label Request Aborted 0 0x00000015 "Label Abort Request ..."
Missing Message 0 0x00000016 "Events Signaled by ..."
Parameters
Unsupported Address 0 0x00000017 "FEC Procedures"
Family "Address Message Proc ..."
Session Rejected/ 1 0x00000018 "Session Initialization"
Bad KeepAlive Time
Internal Error 1 0x00000019 "Events Signaled by ..."
3.10. 知名编号
3.10.1. UDP 和 TCP 端口
LDP Hello message 的 UDP 端口为 646.
用于建立 LDP session connection 的 TCP 端口为 646.
3.10.2. Implicit NULL Label
Implicit NULL label 在 [RFC3031] 中定义如下:
"Implicit NULL label 是一种具有特殊语义的标签, LSR 可以将其绑定到 地址前缀. 如果 LSR Ru 通过查阅其 ILM (Incoming Label Map) 发现带标签 packet P 必须转发给下一跳 Rd, 但 Rd 已经向相应地址前缀分发了 Implicit NULL 的绑定, 则 Ru 不会替换标签栈顶部标签的值, 而是弹出标签栈, 然后将生成的数据包转发给 Rd."
implicit NULL label 在 LDP 中表示为一个 Generic Label TLV, 其 Label 字段 值为 3, 如 [RFC3032] 中所定义.
- IANA 考虑事项
LDP 定义了以下需要管理的命名空间:
- Message Type Name Space
- TLV Type Name Space
- FEC Type Name Space
- Status Code Name Space
- Experiment ID Name Space
以下各节提供了管理这些命名空间的准则.
4.1. Message Type Name Space
LDP 将 message type 的命名空间划分为三个范围. 以下是管理这些范围的 准则:
- Message Types 0x0000 - 0x3DFF. 此范围内的 message type 是 LDP
基础协议的一部分. 按照 [IANA] 中列出的策略, 此范围内的 Message
type 通过 IETF Consensus action 分配.
- Message Types 0x3E00 - 0x3EFF. 此范围内的 message type 保留用于
Vendor-Private extension, 并由各个厂商负责 (见 Section "LDP
Vendor-Private Messages"). IANA 无需管理 Message Type Name Space 的
这一范围.
- Message Types 0x3F00 - 0x3FFF. 此范围内的 message type 保留用于
Experimental extension, 并由各个实验者负责 (见 Sections "LDP
Experimental Extensions" 和 "Experiment ID Name Space"). IANA 无需
管理 Message Type Name Space 的这一范围; 但是, IANA 负责管理
Experiment ID Name Space 的一部分 (见下文).
4.2. TLV Type Name Space
LDP 将 TLV type 的命名空间划分为三个范围. 以下是管理这些范围的准则:
- TLV Types 0x0000 - 0x3DFF. 此范围内的 TLV type 是 LDP 基础协议的一
部分. 按照 [IANA] 中列出的策略, 此范围内的 TLV type 通过 IETF
Consensus action 分配.
- TLV Types 0x3E00 - 0x3EFF. 此范围内的 TLV type 保留用于
Vendor-Private extension, 并由各个厂商负责 (见 Section "LDP
Vendor-Private TLVs"). IANA 无需管理 TLV Type Name Space 的这一范围.
- TLV Types 0x3F00 - 0x3FFF. 此范围内的 TLV type 保留用于 Experimental
extension, 并由各个实验者负责 (见 Sections "LDP Experimental
Extensions" 和 "Experiment ID Name Space"). IANA 无需管理 TLV Name
Space 的这一范围; 但是, IANA 负责管理 Experiment ID Name Space 的
一部分 (见下文).
4.3. FEC Type Name Space
FEC type 的范围是 0 - 255.
按照 [IANA] 中列出的策略, 范围 0 - 127 内的 FEC type 通过 IETF Consensus action 分配, 范围 128 - 191 内的 type 按 First Come First Served 方式分配, 范围 192 - 255 内的 type 保留用于 Private Use.
4.4. Status Code Name Space
Status Code 的范围是 0x00000000 - 0x3FFFFFFF.
按照 [IANA] 中列出的策略, 范围 0x00000000 - 0x1FFFFFFF 内的 Status Code 通过 IETF Consensus action 分配, 范围 0x20000000 - 0x3EFFFFFF 内的 code 按 First Come First Served 方式分配, 范围 0x3F000000 - 0x3FFFFFFF 内的 code 保留用于 Private Use.
4.5. Experiment ID Name Space
Experiment ID 的范围是 0x00000000 - 0xffffffff.
按照 [IANA] 中列出的策略, 范围 0x00000000 - 0xefffffff 内的 Experiment ID 按 First Come First Served 方式分配, 范围 0xf0000000 - 0xffffffff 内的 Experiment ID 保留用于 Private Use.
- 安全考虑事项
本节识别 LDP 可能易受影响的威胁, 并讨论可用于缓解这些威胁的方法.
5.1. 欺骗
有两类 LDP 通信可能成为 spoofing attack 的目标.
-
由 UDP 承载的 Discovery exchange
LSR 通过周期性发送 Hello message 来表明其建立和维护 LDP session 的 意愿. 接收 Hello 会创建新的 "Hello adjacency" (如果该邻接尚不存在), 或刷新现有邻接. 对现有邻接伪造 Hello packet 可能导致该邻接超时, 并可能导致相关 session 终止. 当被伪造的 Hello 指定较小的 Hold Time 时, 就可能发生这种情况, 这会使接收方期望在该间隔内收到 Hello, 而 真正的邻居则继续以较低的、先前协商好的频率发送 Hello.
在链路层直接连接的 LSR 通过该链路交换 Basic Hello message. 可通过 以下方式降低伪造 Basic Hello 的威胁:
o 仅在与可信 LSR 直接连接的接口上接受 Basic Hello.
o 忽略未寻址到 All Routers on this Subnet multicast group 的 Basic Hello.
在链路层未直接连接的 LSR 可以使用 Extended Hello message 来表明建立 LDP session 的意愿. LSR 可以通过过滤 Extended Hello 并仅接受来自访问 列表允许源的 Extended Hello, 来降低伪造 Extended Hello 的威胁.
-
由 TCP 承载的 session communication
LDP 指定使用 TCP MD5 Signature Option 来提供 session message 的真实性 和完整性.
[RFC2385] 指出, 一些人现在认为 MD5 authentication 对于此应用而言过于 薄弱. 它还指出, 可以部署一种类似的 TCP option, 采用更强的 hashing algorithm (其以 SHA-1 为例). 据我们所知, 尚未定义并部署这样的 TCP option. 但是, 我们注意到 LDP 可以使用任何可用的 TCP message digest 技术, 并且当指定并实现一种强于 MD5 的技术时, 将 LDP 升级为使用它会 相对直接.
5.2. 隐私
LDP 未提供保护标签分发隐私的机制.
标签分发协议的安全要求本质上与分发路由信息的协议的安全要求相同. 通过提供一种机制来确保其消息的真实性和完整性, LDP 提供的安全级别至少 与路由协议本身所能提供的安全级别一样好, 但并不更好. 是否应要求路由 协议具备隐私性的更一般问题超出了本文档的范围.
有人可能会认为, 标签分发需要隐私性来应对标签欺骗的威胁. 然而, 这种 隐私性并不能防范标签欺骗攻击, 因为数据包以明文携带
标签. 此外, 即使不知道绑定到标签的 FEC, 也可以实施标签欺骗攻击.
为避免标签欺骗攻击, 必须确保带标签的数据包由可信 LSR 加标签, 并确保 置于数据包上的标签是执行加标签的 LSR 正确学习到的.
5.3. 拒绝服务
LDP 为 Denial of Service (DoS) 攻击提供了两个潜在目标:
-
用于 LDP Discovery 的 Well-known UDP Port
LSR 管理员可以通过确保该 LSR 仅直接连接到可信且不会发起此类攻击的 对等方, 来应对通过 Basic Hello 发起的 DoS 攻击威胁. 管理员域内部 对等方的接口不应该构成威胁, 因为内部对等方处于管理员控制之下. 域 外部对等方的接口构成潜在威胁, 因为外部对等方不受管理员控制. 管理员 可以通过仅将 LSR 连接到可信且不会发起 Basic Hello 攻击的外部对等方, 来降低该威胁.
通过 Extended Hello 发起的 DoS 攻击可能是更严重的威胁. 可以通过使用 访问列表过滤 Extended Hello 来应对此威胁, 这些访问列表定义了允许进行 Extended Discovery 的地址. 但是, 执行过滤需要 LSR 资源.
在可以识别可信 MPLS cloud 的环境中, 可使用 cloud 边缘的 LSR 来保护 内部 LSR 免受通过 Extended Hello 发起的 DoS 攻击, 做法是过滤掉来自 可信 MPLS cloud 外部的 Extended Hello, 仅接受来自访问列表所允许地址的 Extended Hello. 此过滤保护 cloud 内部的 LSR, 但会消耗边缘资源.
-
用于 LDP Session Establishment 的 Well-known TCP port
与其他使用 TCP 的控制平面协议一样, LDP 可能成为 DoS 攻击的目标, 例如 SYN 攻击. LDP 对此类攻击的脆弱性既不高于也不低于其他使用 TCP 的控制平面协议.
可通过以下方式在一定程度上缓解此类攻击的威胁:
o LSR 应该避免为建立 LDP session 而进行泛化的 TCP 监听. 它应该 只使用针对已发现对等方的监听. 这样可以在处理早期丢弃攻击 数据包, 因为它们较不可能匹配现有连接或正在建立的连接.
o 使用 MD5 option 会有所帮助, 因为它可以防止 SYN 在 MD5 segment checksum 无效时被接受. 但是, 接收方必须先计算 checksum, 然后 才能决定丢弃一个在其他方面可接受的 SYN segment.
o 以类似上文针对 Extended Hello 所建议的方式, 在 MPLS cloud 边界 应用访问列表机制, 可以保护内部免受源自 cloud 外部的攻击.
-
未来研究领域
以下主题未在此版本的 LDP 中处理, 可作为未来研究的领域:
- MPLS 架构 [RFC3031] 的 Section 2.16 要求, 对等 LSR 之间的初始
标签分发协议协商应使每个 LSR 能够确定其对等方是否能够弹出标签栈.
此版本的 LDP 假定 LSR 支持除 ATM 和 Frame Relay 之外所有链路类型的
标签弹出. 未来版本可以规定将这种判定纳入 session initiation
negotiation 的方法.
- 此版本未规定 LDP 对 CoS (Class of Service) 的支持. CoS 支持可以在
未来版本中处理.
- 此版本未规定 LDP 对 multicast 的支持. Multicast 支持可以在未来
版本中处理.
- 此版本未规定 LDP 对 multipath label switching 的支持. Multipath
支持可以在未来版本中处理.
- 此版本未规定 LDP 对 maximum transmission unit signaling 的支持.
实验性文档 [LDP-MTU] 中讨论了该问题.
- 当前规范未处理 Non-Broadcast Multi-Access (NBMA) 介质上的 basic
peer discovery. 当前规范中可用的解决方案是在此类环境中使用
extended peer
discovery. 定义一种在语义上类似于 Basic Discovery (1 hop limit,
将 hello adjacency 绑定到接口) 且使用预配置邻居地址的机制这一问题,
留待进一步研究.
- 当前规范不支持关闭 adjacency. 执行该操作的动机以及实现它的机制留待
进一步研究.
- 当前规范不包含用于保护 Hello message 以检测 Hello 欺骗的方法.
需要这种方法的场景以及实现它的机制均留待未来研究.
- 当前规范不具备检测无状态快速控制平面重启的能力. 实现该能力的方法,
可能通过 Hello message 中携带的 "incarnation/instance" 编号, 留待
未来研究.
- 当前规范不支持 "end of LIB" message, 该 message 类似于 BGP 的
"end of RIB" message, LDP LSR (以 DU 模式运行) 会在 session
建立后使用该 message. 关于是否需要这种机制及其实现的讨论留待未来
研究.
- 当前规范未处理不同 LSR 通告相同地址的情况. 这类情况通常由配置错误
导致, 此处的目标是向通告相同地址的 LSR 提供足够信息, 使操作员能够
采取纠正措施. 该机制的规范留待单独文档处理.
7. 相对于 RFC 3036 的变更
以下是相对于 RFC 3036 的变更列表
1. 移除了 Host Address FEC 及对它的引用, 因为它未被任何实现使用.
2. 将参考文献列表拆分为 normative references 和 informative
references
3. 从 normative references 列表中移除了 "MPLS using ATM VP Switching",
并移除了对它的引用.
4. 移除了对 RFC 1700 的引用, 并替换为指向
http://www.iana.org/assignments/address-family-numbers 的链接.
5. 移除了对 RFC 1771 的引用, 并替换为对 RFC 4271 的引用.
6. 澄清了 F-bit 的使用.
7. 增加了在执行 Ordered Control 时允许 split horizon 的选项.
8. 澄清了 session initialization procedures 中对设置了 U-bit 的 message
的处理
9. 澄清了 session initialization procedures 中对 E-bit 的处理.
10. 增加了说明性文字, 解释状态转换图中的 Shutdown message 实现为一条
notification message, 其中包含指示 fatal error 的 Status TLV.
11. 在处理 malformed TLV 的规范中, 增加了 TLV length too short 的情况.
12. 解释了 hello 欺骗带来的安全威胁.
13. 增加了对 4271 和 4278 的引用, 以及关于 MD5 option 的 standards
maturity variance 的文字.
14. 增加了来自 3031 的文字, 解释 implicit NULL label 的处理.
15. 纳入了 DLCI 的编码, 以移除对 3034 的 normative reference.
16. 将对 3031, 3032 和 3034 的引用移至 informative.
17. 在描述处理 unknown TLV 的章节中, 移除了对不存在章节的引用
(原始文档中的勘误).
18. 增加了文字, 澄清发送 vendor-private TLV 和 message 时如何实现
interoperability.
19. 在 "receive label request" procedures 中, 如果检测到环路, 将
procedure 改为在中止其余处理之前先发送 notification.
20. 在 "receive label release" procedures 中, 澄清了 merge-capable LSR
的行为.
21. 在 "receive label release" procedures 中, 澄清了接收到 unknown FEC
时的行为.
22. 在 "Detect Change in FEC Next Hop" 的注 4 中, 修改了文字, 以引用
发送 label request procedure 的正确条件集合 (原始文档中的拼写错误).
23. 在 "LSR decides to no longer label switch a FEC" 的 procedures 中,
澄清了标签不得被重用这一事实, 直到收到 label release 为止.
24. 在例程 "Prepare_Label_Mapping_Attributes" 中, 增加了一条说明, 关于
根据 unknown TLV 的 U-bit 和 F-bit 对其进行处理.
25. 在 Address message processing procedures 中, 澄清了当 LSR 接收到
此前已由其通告的某地址的重新通告, 或从一个此前未通告该地址的 LSR
接收到该地址的撤销时的行为.
26. 在例程 "Receive Label Mapping" 中, 澄清了在此前未发送 label
advertisement message 时 PrevAdvLabel 的含义.
27. 在 "Receive Label Mapping" procedures 中, 如果检测到环路, 修改
procedure, 使其在中止其余处理之前先发送 notification.
28. 在 "Receive Label Mapping" procedures 中, 修正了步骤 LMp.10, 以
处理该 FEC 的附加 (non-merged) LSP 的 label mapping message.
29. 在 "Receive Label Mapping" procedures 中, 澄清了接收到同一 FEC 的
重复标签时的行为.
30. 在例程 "Receive Label Abort Request" 中, 澄清了 non-merging LSR 的
行为.
31. 在讨论未来研究领域的章节中增加了以下条目:
o 用于传递 maximum transmission unit 的扩展
o NBMA 介质上的 basic peer discovery
o 关闭 adjacency 的选项
o 用于保护 Hello message 的机制
o 检测无状态快速控制平面重启
o 支持 "end of LIB" message
o 用于处理不同 LSR 通告相同地址这一情况的机制
8. 致谢
本文档是将 LDP 规范推进到 draft standard 状态的工作的一部分. 本文档最初 于 2001 年 1 月作为 RFC 3036 发布. 它由 IETF 的 MPLS Working Group 编写, 并由 Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette 和 Bob Thomas 共同署名.
RFC 3036 中的思想和文字来自多个来源. 我们感谢 Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter 和 Arun Viswanathan 对 RFC 3036 的贡献.
编辑们感谢 Eric Gray, David Black 和 Sam Hartman 对当前文档的贡献和审阅.
此外, 编辑们感谢 MPLS Working Group 成员为本文档提供的想法和支持, 尤其感谢 Eric Rosen, Luca Martini, Markus Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama Ramakrishnan, Nick Weeds, Adrian Farrel 和 Andy Malis.
- 参考文献
9.1. 规范性参考文献
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001.