2. LDP 操作
2.1. FEC
必须精确规定哪些分组可以被映射到每条 LSP。这是通过为每条 LSP 提供一个 FEC 规范来完成的。FEC 标识可以被映射到该 LSP 的那组 IP 分组。
每个 FEC 被指定为一个或多个 FEC 元素的集合。每个 FEC 元素标识一组可以被映射到相应 LSP 的分组。当一条 LSP 被多个 FEC 元素共享时, 该 LSP 在该 FEC 元素不能再共享同一路径的节点处 (或之前) 终止。
本规范定义了一种 FEC 元素类型, 即 "地址前缀 FEC 元素 (Address Prefix FEC element)"。该元素是长度从 0 到完整地址 (含) 的任意长度的地址前缀。
其他规范可以按需定义额外的 FEC 元素。
在本节的剩余部分, 我们给出用于将分组映射到使用地址前缀 FEC 元素建立的 LSP 的规则。
我们说某个特定地址 "匹配 (matches)" 某个特定地址前缀, 当且仅当该地址以该前缀开头。我们还说某个特定分组匹配某条特定 LSP, 当且仅当该 LSP 具有一个匹配该分组目的地址的地址前缀 FEC 元素。对于某个特定分组和某条特定 LSP, 我们把任何匹配该分组的地址前缀 FEC 元素称为 "匹配前缀 (matching prefix)"。
将某个特定分组映射到某条特定 LSP 的过程使用以下规则。依次应用每条规则, 直到该分组可以被映射到某条 LSP 为止。
-
如果一个分组恰好匹配一条 LSP, 则该分组被映射到该 LSP。
-
如果一个分组匹配多条 LSP, 则它被映射到匹配前缀最长的那条 LSP。如果没有哪条 LSP 的匹配前缀最长, 则该分组被映射到匹配前缀比其他 LSP 更长的那个 LSP 集合中的某一条。选择其中某条 LSP 的过程超出了本文档的范围。
-
如果已知某个分组必须经过某个特定出口路由器, 并且存在一条 LSP, 它拥有一个为该路由器 /32 地址的地址前缀 FEC 元素, 则该分组被映射到该 LSP。获取该知识的过程超出了本文档的范围。
确定某个分组必须经过某个特定出口路由器的过程超出了本文档的范围。(例如, 如果运行链路状态路由算法, 则可能可以从链路状态数据库获取该信息。再例如, 如果运行 BGP, 则可能可以从该分组路由的 BGP 下一跳属性获取该信息。)
2.2. 标签空间、标识符、会话与传输
2.2.1. 标签空间
"标签空间 (label space)" 这一概念对于讨论标签的分配和分发很有用。标签空间有两种类型:
-
按接口标签空间 (Per interface label space)。特定于接口的入标签用于那些把接口资源用作标签的接口。这类接口的一个例子是把 VCI (Virtual Channel Identifier, 虚通道标识符) 用作标签的标签控制 ATM 接口, 或把 DLCI (Data Link Connection Identifier, 数据链路连接标识符) 用作标签的帧中继接口。
请注意, 只有在 LDP 对等体通过某个接口 "直接相连"、且该标签只用于通过该接口发送的流量时, 使用按接口标签空间才有意义。
-
按平台标签空间 (Per platform label space)。平台范围的入标签用于那些可以共享相同标签的接口。
2.2.2. LDP 标识符
LDP Identifier (LDP 标识符) 是一个用于标识某个 LSR 标签空间的六字节量。前四个八位组标识该 LSR, 且必须是全局唯一的值, 例如分配给该 LSR 的 32 位路由器 Id。最后两个八位组标识该 LSR 内特定的一个标签空间。对于平台范围标签空间, LDP Identifier 的最后两个八位组总为零。本文档对 LDP Identifier 使用如下打印表示:
<LSR Id> : <label space id>
例如 lsr171:0、lsr19:2。
请注意, 管理和通告多个标签空间的 LSR 为每个这样的标签空间使用不同的 LDP Identifier。
LSR 需要向某个对等体通告多个标签空间、因而需要使用多个 LDP Identifier 的情况包括: 该 LSR 与该对等体之间有两条链路, 且两条都是 ATM 链路 (使用按接口标签)。另一种情况是该 LSR 与该对等体之间有两条链路, 其中一条是 ethernet (使用按平台标签), 另一条是 ATM。
2.2.3. LDP 会话
LDP 会话存在于各 LSR 之间, 以支持它们之间的标签交换。
- 当 LSR 使用 LDP 向另一台 LSR 通告多个标签空间时, 它为每个标签空间使用一个单独的 LDP 会话。
2.2.4. LDP 传输
LDP 使用 TCP 作为会话的可靠传输。
- 当两台 LSR 之间需要多个 LDP 会话时, 每个 LDP 会话对应一个 TCP 会话。
2.3. 非直连 LSR 之间的 LDP 会话
在链路层不直接相连的 LSR 之间的 LDP 会话, 在某些情况下可能是可取的。
例如, 考虑一个 "流量工程 (traffic engineering)" 应用, 其中 LSRa 将匹配某种条件的流量经一条 LSP 发送给非直连的 LSRb, 而不是沿其通常路由的路径转发该流量。
LSRa 与 LSRb 之间的路径会包含一个或多个中间 LSR (LSR1,...,LSRn)。LSRa 与 LSRb 之间的 LDP 会话使 LSRb 能够对从 LSRa 经该 LSP 到达的流量进行标签交换, 因为它为 LSRb 提供了为此目的向 LSRa 通告标签的手段。
在这种情况下, LSRa 会对它经该 LSP 转发给 LSRb 的流量施加两个标签: 一个是从 LSR1 学到的、用于沿 LSP 路径从 LSRa 向 LSRb 转发流量的标签; 另一个是从 LSRb 学到的、用于使 LSRb 能够对经该 LSP 到达的流量进行标签交换的标签。
LSRa 首先把通过其与 LSRb 的 LDP 会话学到的标签加到分组标签栈上 (如果分组到达时带标签, 则用它替换分组标签栈顶部的标签; 如果分组到达时不带标签, 则压入它)。然后, 它把从 LSR1 学到的、用于该 LSP 的标签压入标签栈。
2.4. LDP 发现
LDP 发现 (discovery) 是一种使 LSR 能够发现潜在 LDP 对等体的机制。发现机制使得无需显式配置某个 LSR 的标签交换对等体。
发现机制有两种变体:
-
基本发现 (Basic Discovery) 机制, 用于发现链路层直接相连的 LSR 邻居。
-
扩展发现 (Extended Discovery) 机制, 用于定位链路层不直接相连的 LSR。
2.4.1. 基本发现机制
为在某个接口上进行 LDP 基本发现, LSR 周期性地从该接口发出 LDP 链路 Hello (Link Hello)。LDP Link Hello 作为 UDP 分组发送, 目的地址为 "all routers on this subnet" 组播地址上的周知 LDP 发现端口。
LSR 发送的 LDP Link Hello 携带该 LSR 打算用于该接口的标签空间的 LDP Identifier, 以及可能的附加信息。
在某个接口上收到 LDP Link Hello 会标识出一个与该接口上链路层可达的潜在 LDP 对等体的 "Hello 邻接", 以及该对等体打算用于该接口的标签空间。
2.4.2. 扩展发现机制
非直连 LSR 之间的 LDP 会话由 LDP 扩展发现支持。
为进行 LDP 扩展发现, LSR 周期性地向某个特定地址发送 LDP 定向 Hello (Targeted Hello)。LDP Targeted Hello 作为 UDP 分组发送, 目的地址为该特定地址上的周知 LDP 发现端口。
LSR 发送的 LDP Targeted Hello 携带该 LSR 打算使用的标签空间的 LDP Identifier, 以及可能的附加可选信息。
扩展发现与基本发现的差异如下:
-
Targeted Hello 发送到某个特定地址, 而不是发送到出接口的 "all routers" 组播地址。
-
与对称的基本发现不同, 扩展发现是非对称的。
一台 LSR 向另一台被定向的 LSR 发起扩展发现, 由被定向的 LSR 决定是响应还是忽略该 Targeted Hello。选择响应的被定向 LSR 通过向发起方 LSR 周期性发送 Targeted Hello 来响应。
收到 LDP Targeted Hello 会标识出一个与网络层可达的潜在 LDP 对等体的 "Hello 邻接", 以及该对等体打算使用的标签空间。
2.5. 建立和维护 LDP 会话
2.5.1. LDP 会话建立
两台 LSR 之间交换 LDP 发现 Hello 会触发 LDP 会话建立。会话建立是一个两步过程:
-
传输连接建立 (Transport connection establishment)
-
会话初始化 (Session initialization)
以下从 LSR1 的角度描述 LSR1 与 LSR2 之间 LDP 会话的建立。它假定所交换的 Hello 为 LSR1 规定了标签空间 LSR1:a, 为 LSR2 规定了标签空间 LSR2:b。
2.5.2. 传输连接建立
Hello 的交换导致在 LSR1 处创建一个 Hello 邻接, 它用于把链路 (L) 与标签空间 LSR1:a 和 LSR2:b 绑定在一起。
-
如果 LSR1 尚未拥有用于交换标签空间 LSR1:a 和 LSR2:b 的 LDP 会话, 它尝试为一条新的、与 LSR2 的 LDP 会话打开一个 TCP 连接。
LSR1 确定 LDP TCP 连接在其自身一端 (A1) 和 LSR2 一端 (A2) 要使用的传输地址。地址 A1 按如下方式确定:
a. 如果 LSR1 在它发送给 LSR2 的 Hello 中使用 Transport Address 可选对象 (TLV) 来通告一个地址, 则 A1 就是 LSR1 通过该可选对象通告的地址;
b. 如果 LSR1 不使用 Transport Address 可选对象, 则 A1 是它发送给 LSR2 的 Hello 中使用的源地址。
类似地, 地址 A2 按如下方式确定:
a. 如果 LSR2 使用 Transport Address 可选对象, 则 A2 是 LSR2 通过该可选对象通告的地址;
b. 如果 LSR2 不使用 Transport Address 可选对象, 则 A2 是从 LSR2 收到的 Hello 中的源地址。
-
LSR1 通过把地址 A1 和 A2 作为无符号整数进行比较, 确定它将在会话建立中扮演主动角色还是被动角色。如果 A1 > A2, 则 LSR1 扮演主动角色; 否则它是被动的。
把 A1 和 A2 作为无符号整数进行比较的过程是:
-
如果 A1 和 A2 不在同一个地址族中, 它们不可比较, 无法建立会话。
-
令 U1 为把 A1 视为字节序列所得到的抽象无符号整数, 其中在消息中出现最早的字节是该整数的最高有效字节, 在消息中出现最晚的字节是该整数的最低有效字节。
以类似方式从 A2 得到抽象无符号整数 U2。
-
比较 U1 与 U2。如果 U1 > U2, 则 A1 > A2; 如果 U1 < U2, 则 A1 < A2。
-
-
如果 LSR1 是主动的, 它尝试通过连接到地址 A2 上的周知 LDP 端口来建立 LDP TCP 连接。如果 LSR1 是被动的, 它等待 LSR2 向其周知 LDP 端口建立 LDP TCP 连接。
请注意, 当 LSR 发送 Hello 时, 它为会话连接其自身这一端选择传输地址, 并使用该 Hello 通告该地址: 或者通过在可选的 Transport Address TLV 中显式包含它, 或者通过省略该 TLV 并将其用作 Hello 源地址来隐式通告它。
LSR 必须 (MUST) 在所有通告同一标签空间的 Hello 中通告相同的传输地址。该要求确保通过多条使用相同标签空间的 Hello 邻接相连的两台 LSR 为每个邻接扮演相同的连接建立角色。
2.5.3. 会话初始化
在 LSR1 和 LSR2 建立传输连接之后, 它们通过交换 LDP Initialization 消息协商会话参数。所协商的参数包括 LDP 协议版本、标签分发方法、定时器取值、标签控制 ATM 的 VPI/VCI (Virtual Path Identifier / Virtual Channel Identifier) 范围、标签控制帧中继的 DLCI (Data Link Connection Identifier) 范围, 等等。
协商成功即完成了 LSR1 与 LSR2 之间为通告标签空间 LSR1:a 和 LSR2:b 而进行的 LDP 会话建立。
以下从 LSR1 的角度描述会话初始化。
在连接建立之后, 如果 LSR1 扮演主动角色, 它通过向 LSR2 发送一条 Initialization 消息来发起会话参数协商。如果 LSR1 是被动的, 它等待 LSR2 发起参数协商。
一般而言, 当 LSR1 与 LSR2 之间存在多条链路、且每一方要通告多个标签空间时, 被动的 LSR 在收到该连接上的 LDP Initialization 消息之前, 无法知道要在这个新建立的 TCP 连接上通告哪个标签空间。Initialization 消息同时携带发送方 (主动 LSR) 标签空间的 LDP Identifier 和接收方 (被动 LSR) 标签空间的 LDP Identifier。
通过等待来自其对等体的 Initialization 消息, 被动 LSR 能够把该对等体所要通告的标签空间 (由 Initialization 消息的 PDU 头部中的 LDP Identifier 确定) 与先前交换 Hello 时创建的 Hello 邻接匹配起来。
-
当 LSR1 扮演被动角色时:
a. 如果 LSR1 收到一条 Initialization 消息, 它尝试把该消息 PDU 所携带的 LDP Identifier 与某个 Hello 邻接匹配。
b. 如果存在匹配的 Hello 邻接, 该邻接就规定了本会话的本地标签空间。
接下来 LSR1 检查该消息中所提议的会话参数是否可接受。如果可接受, LSR1 用一条自己的 Initialization 消息回复, 以提议它希望使用的参数, 并发送一条 KeepAlive 消息以表示接受 LSR2 的参数。如果参数不可接受, LSR1 通过发送一条 Session Rejected/Parameters Error Notification 消息并关闭 TCP 连接来响应。
c. 如果 LSR1 找不到匹配的 Hello 邻接, 它发送一条 Session Rejected/No Hello Error Notification 消息并关闭 TCP 连接。
d. 如果 LSR1 收到响应其 Initialization 消息的 KeepAlive, 则从 LSR1 的角度看该会话已可操作 (operational)。
e. 如果 LSR1 收到 Error Notification 消息, 则 LSR2 拒绝了它提议的会话, LSR1 关闭 TCP 连接。
-
当 LSR1 扮演主动角色时:
a. 如果 LSR1 收到 Error Notification 消息, 则 LSR2 拒绝了它提议的会话, LSR1 关闭 TCP 连接。
b. 如果 LSR1 收到 Initialization 消息, 它检查会话参数是否可接受。如果可接受, 它用一条 KeepAlive 消息回复。如果会话参数不可接受, LSR1 发送一条 Session Rejected/Parameters Error Notification 消息并关闭连接。
c. 如果 LSR1 收到 KeepAlive 消息, 则 LSR2 已接受它提议的会话参数。
d. 当 LSR1 既收到了可接受的 Initialization 消息、又收到了 KeepAlive 消息时, 从 LSR1 的角度看该会话已可操作。
在 LDP 会话建立之前, 除上述过程中列出的消息之外, 不得交换任何其他消息, 并且 LDP 消息中 U 位的处理规则被覆盖。如果收到了上述过程中列出的消息之外的任何消息, 则 必须 (MUST) 发送一条 Shutdown 消息, 并且 必须 (MUST) 关闭传输连接。
一对配置不兼容、在会话参数上不一致的 LSR 可能陷入无休止的消息序列, 因为每一方都用 Error Notification 消息对对方的 Initialization 消息回以 NAK。
在 Initialization 消息被 NAK 的情况下, LSR 必须 (MUST) 用指数退避 (exponential backoff) 来限制其会话建立重试尝试。还建议检测到这种情况的 LSR 采取行动通知操作员。
在 Initialization 消息被 NAK 之后的会话建立尝试 必须 (MUST) 延迟不少于 15 秒, 且后续延迟 必须 (MUST) 增长到不少于 2 分钟的最大延迟。必须被延迟的具体会话建立动作, 是扮演主动角色的 LSR 打开会话传输连接的尝试。
在操作员干预并重新配置其中一台 LSR 之前, 这种被节流的 Initialization NAK 序列不太可能停止。在此类配置动作之后, 不再需要对后续会话建立尝试进行节流 (直到它们的 Initialization 消息被 NAK)。
由于会话建立的非对称性质, 如果不采取进一步动作, 被动 LSR 的重新配置不会被主动 LSR 察觉。 "Hello Message" 一节描述了一种可选机制, LSR 可以用它向潜在 LDP 对等体信号它已被重新配置。
2.5.4. 初始化状态机
用状态机来描述 LDP 会话协商行为很方便。我们定义 LDP 状态机具有五种可能状态, 并以状态转换表和状态转换图的形式给出其行为。请注意, Shutdown 消息实现为一条带有表示致命错误的 Status TLV 的 Notification 消息。
Session Initialization State Transition Table
STATE EVENT NEW STATE
NON EXISTENT Session TCP connection established INITIALIZED
established
INITIALIZED Transmit Initialization msg OPENSENT
(Active Role)
Receive acceptable OPENREC
Initialization msg
(Passive Role)
Action: Transmit Initialization
msg and KeepAlive msg
Receive Any other LDP msg NON EXISTENT
Action: Transmit Error Notification msg
(NAK) and close transport connection
OPENREC Receive KeepAlive msg OPERATIONAL
Receive Any other LDP msg NON EXISTENT
Action: Transmit Error Notification msg
(NAK) and close transport connection
OPENSENT Receive acceptable OPENREC
Initialization msg
Action: Transmit KeepAlive msg
Receive Any other LDP msg NON EXISTENT
Action: Transmit Error Notification msg
(NAK) and close transport connection
OPERATIONAL Receive Shutdown msg NON EXISTENT
Action: Transmit Shutdown msg and
close transport connection
Receive other LDP msgs OPERATIONAL
Timeout NON EXISTENT
Action: Transmit Shutdown msg and
close transport connection
Session Initialization State Transition Diagram
+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg or Timeout |
| +-----------+ |
Rx Any other | | | |
msg or | |INITIALIZED| |
Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) |
| | Rx Acceptable | Tx Init msg |
| | Init msg / | |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg |
msg | | | |
| | | Rx Acceptable |
| | | Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown msg
All other | ^ or Timeout /
LDP msgs | | Tx Shutdown msg
| |
+---+
2.5.5. 维护 Hello 邻接
与某个对等体的 LDP 会话拥有一个或多个 Hello 邻接。
当一对 LSR 通过多条共享同一标签空间的链路相连时, 该 LDP 会话就有多个 Hello 邻接; 例如一对路由器之间的多条 PPP 链路。在这种情况下, LSR 在每条这样的链路上发送的 Hello 携带相同的 LDP Identifier。
LDP 包含用于监控 LDP 会话及其 Hello 邻接之必要性的机制。
LDP 使用对 LDP 发现 Hello 的定期接收来表示对等体有意使用该 Hello 所标识的标签空间。LSR 为每个 Hello 邻接维护一个保持定时器, 当它收到匹配该邻接的 Hello 时就重启该定时器。如果在未收到来自该对等体的匹配 Hello 的情况下该定时器到期, LDP 就断定该对等体不再希望为该链路 (或在 Targeted Hello 的情况下为那个目标) 使用该标签空间进行标签交换, 或者断定该对等体已故障。随后该 LSR 删除该 Hello 邻接。当某个 LDP 会话的最后一个 Hello 邻接被删除时, 该 LSR 通过发送一条 Notification 消息并关闭传输连接来终止该 LDP 会话。
2.5.6. 维护 LDP 会话
LDP 包含用于监控 LDP 会话完整性的机制。
LDP 使用对会话传输连接上 LDP PDU 的定期接收来监控会话的完整性。LSR 为每个对等体会话维护一个 KeepAlive Timer, 每当它从该会话对等体收到一个 LDP PDU 时就重置该定时器。如果在未收到来自该对等体的 LDP PDU 的情况下 KeepAlive Timer 到期, 该 LSR 就断定该传输连接已损坏或该对等体已故障, 并通过关闭该传输连接来终止该 LDP 会话。
在 LDP 会话建立之后, LSR 必须安排使其对等体至少每个 KeepAlive 时间周期收到一个来自它的 LDP PDU, 以确保该对等体重启会话的 KeepAlive Timer。该 LSR 可以发送任何协议消息来满足该要求。在 LSR 没有其他信息要告知其对等体的情况下, 它发送一条 KeepAlive 消息。
LSR 可以随时选择终止与某个对等体的 LDP 会话。如果它选择这样做, 它用一条 Shutdown 消息通知该对等体。
2.6. 标签分发与管理
MPLS 架构 [RFC3031] 允许 LSR 响应另一台 LSR 的显式请求来分发某个 FEC 标签绑定。这称为下游按需 (Downstream On Demand) 标签分发。它也允许 LSR 向未显式请求它们的 LSR 分发标签绑定。[RFC3031] 把这种标签分发方法称为 Unsolicited Downstream; 本文档使用术语下游主动 (Downstream Unsolicited)。
这两种标签分发技术可以在同一网络中同时使用。然而, 对于任何给定的 LDP 会话, 每台 LSR 都必须知道其对等体所使用的标签分发方法, 以避免出现某一方使用下游主动标签分发、却假定其对等体也使用该方法的情况。见 "Downstream on Demand Label Advertisement" 一节。
2.6.1. 标签分发控制模式
LSP 初始建立的行为取决于该 LSR 是以独立 (independent) 还是有序 (Ordered) LSP 控制方式运行。LSR 可以作为一种可配置选项同时支持这两种控制方式。
2.6.1.1. 独立标签分发控制
当使用独立 LSP 控制时, 每台 LSR 可以在它希望的任何时刻向邻居通告标签映射。例如, 在下游按需独立模式下运行时, LSR 可以立即应答标签映射请求, 而不必等待来自下一跳的标签映射。在下游主动独立模式下运行时, 每当 LSR 准备好对某个 FEC 进行标签交换时, 它就可以向邻居通告该 FEC 的标签映射。
使用独立模式的一个后果是, 上游标签可能在下游标签收到之前就被通告。
2.6.1.2. 有序标签分发控制
当使用 LSP 有序控制时, LSR 只能为以下 FEC 发起标签映射的发送: 它拥有该 FEC 下一跳的标签映射的 FEC, 或者它自身是该 FEC 出口的 FEC。对于每台 LSR 不是出口、且不存在映射的 FEC, 该 LSR 必须 (MUST) 等到收到来自下游 LSR 的标签之后, 才能为该 FEC 建立映射并向各上游 LSR 传递相应的标签。LSR 可能对某些 FEC 是出口, 对其他 FEC 则不是出口。
就某个特定 FEC 而言, LSR 可以在以下任一情况下作为出口 LSR 行事:
-
该 FEC 指向该 LSR 自身 (包括其一个直接相连的接口)。
-
该 FEC 的下一跳路由器位于标签交换网络之外。
-
该 FEC 元素可以通过跨越路由域边界而到达, 例如对于 OSPF 汇总网络而言的另一个区域, 或对于 OSPF AS 外部路由和 BGP 路由而言的另一个自治系统 [RFC2328] [RFC4271]。
请注意, 某台 LSR 对某个给定 FEC 是否是出口可能随时间变化, 这取决于网络状态和 LSR 配置设置。
2.6.2. 标签保留模式
MPLS 架构 [RFC3031] 引入了标签保留模式 (label retention mode) 的概念, 它规定 LSR 是否为某个 FEC 维护从不是该 FEC 下一跳的邻居学到的标签绑定。
2.6.2.1. 保守标签保留模式
在下游主动通告模式下, 可能从所有对等 LSR 收到针对所有路由的标签映射通告。当使用保守标签保留 (Conservative Label retention) 时, 只有当所通告的标签映射将被用于转发分组时 (即, 如果按照路由它们是从有效下一跳收到的), 才保留它们。如果运行在下游按需模式下, LSR 只按照路由向下一跳 LSR 请求标签映射。由于下游按需模式主要在希望节省标签时使用 (例如交叉连接空间有限的 ATM 交换机), 它通常与保守标签保留模式一起使用。
保守模式的主要优点是: 只分配和维护数据转发所需的标签。这在标签空间本身受限的 LSR (例如 ATM 交换机) 中特别重要。保守模式的缺点是: 如果路由改变了某个目的地的下一跳, 就必须先从新的下一跳获得新标签, 然后才能转发带标签的分组。
2.6.2.2. 宽松标签保留模式
在下游主动通告模式下, 可能从所有 LDP 对等体收到针对所有路由的标签映射通告。当使用宽松标签保留 (Liberal Label retention) 时, 从某个对等 LSR 收到的每一个标签映射都被保留, 无论该 LSR 是否是所通告映射的下一跳。当在下游按需模式下结合宽松标签保留运行时, LSR 可能选择向所有对等 LSR 请求所有已知前缀的标签映射。不过请注意, 下游按需模式通常由基于 ATM 交换机的 LSR 之类的设备使用, 而对这类设备推荐采用保守方式。
宽松标签保留模式的主要优点是: 由于标签已经存在, 对路由变化的反应可以很快。宽松模式的主要缺点是: 会分发和维护不需要的标签映射。
2.6.3. 标签通告模式
LSR 上的每个接口都被配置为以下游主动或下游按需通告模式运行。LSR 在初始化期间交换通告模式。下游主动与下游按需模式之间的主要差别在于由哪台 LSR 负责发起映射请求和映射通告。
2.7. LDP 标识符与下一跳地址
LSR 在标签信息库 (Label Information Base, LIB) 中维护学到的标签。在下游主动模式下运行时, 某个地址前缀的 LIB 条目把一组 (LDP Identifier, label) 对与该前缀关联起来, 每个为该前缀通告标签的对等体对应一个这样的对。
当前缀的下一跳发生变化时, 该 LSR 必须从 LIB 中取出新的下一跳所通告的标签, 以供转发使用。为取出该标签, 该 LSR 必须能够把该前缀的下一跳地址映射到一个 LDP Identifier。
类似地, 当 LSR 从某个 LDP 对等体学到某个前缀的标签时, 它必须能够确定该对等体当前是否是该前缀的下一跳, 以判断在转发匹配该前缀的分组时是否需要开始使用新学到的标签。为作出该判断, 该 LSR 必须能够把一个 LDP Identifier 映射到该对等体的各个地址, 以检查其中是否有任何地址是该前缀的下一跳。
为使 LSR 能够在对等体 LDP Identifier 与该对等体地址之间进行映射, LSR 使用 LDP Address 和 Withdraw Address 消息通告其地址。
LSR 发送 Address 消息以向某个对等体通告其地址。LSR 发送 Withdraw Address 消息以向某个对等体撤销先前通告过的地址。
2.8. 环路检测
环路检测 (Loop Detection) 是一个可配置选项, 它提供一种机制, 用于发现成环的 LSP, 以及在存在不支持合并的 LSR 时防止 Label Request 消息成环。
该机制利用 Label Request 和 Label Mapping 消息所携带的 Path Vector 和 Hop Count TLV。它建立在这些 TLV 的以下基本性质之上:
-
Path Vector TLV 包含一个列表, 列出包含它的消息所经过的各 LSR。LSR 在 Path Vector 列表中由其唯一的 LSR Identifier (Id) 标识, 即其 LDP Identifier 的前四个八位组。当 LSR 传播包含 Path Vector TLV 的消息时, 它把其 LSR Id 加入 Path Vector 列表。收到 Path Vector 中包含其自身 LSR Id 的消息的 LSR, 就检测到该消息已经历了环路。LDP 支持最大允许 Path Vector 长度这一概念; 检测到 Path Vector 已达到最大长度的 LSR, 会表现得如同包含它的消息已经历了环路一样。
-
Hop Count TLV 包含一个计数, 统计包含它的消息所经过的 LSR 数目。当 LSR 传播包含 Hop Count TLV 的消息时, 它递增该计数。检测到 Hop Count 已达到所配置最大值的 LSR, 会表现得如同包含它的消息已经历了环路一样。按约定, 计数 0 被解释为跳数未知。对未知跳数值加一的结果为未知跳数值 (0)。
以下段落描述 LDP 环路检测过程。仅就这些段落而言, "MUST" 被重新定义为 "如果配置了环路检测则 MUST"。这些段落规定必须携带 Path Vector 和 Hop Count TLV 的消息。请注意, 在未配置环路检测的情况下, Hop Count TLV 及其过程会在没有 Path Vector TLV 的情况下被使用 (见 [RFC3035] 和 [RFC3034])。
2.8.1. 标签请求消息
Path Vector TLV 和 Hop Count TLV 的使用可防止 Label Request 消息在包含不支持合并的 LSR 的环境中成环。
当启用环路检测时, 支配 LSR R 在 Label Request 消息中使用 Hop Count TLV 的规则如下:
-
该 Label Request 消息 必须 (MUST) 包含一个 Hop Count TLV。
-
如果 R 是由于它是该 FEC 的入口而发送该 Label Request, 它 必须 (MUST) 包含一个跳数值为 1 的 Hop Count TLV。
-
如果 R 是由于从某个上游 LSR 收到了 Label Request 而发送该 Label Request, 并且所收到的 Label Request 包含 Hop Count TLV, 则 R 必须 (MUST) 把所收到的跳数值加一, 并 必须 (MUST) 把所得的值放在一个 Hop Count TLV 中, 随该 Label Request 消息一起传给其下一跳。
当启用环路检测时, 支配 LSR R 在 Label Request 消息中使用 Path Vector TLV 的规则如下:
-
如果 R 是由于它是该 FEC 的入口而发送该 Label Request, 那么如果 R 不支持合并, 它 必须 (MUST) 包含一个长度为 1、含有其自身 LSR Id 的 Path Vector TLV。
-
如果 R 是由于从某个上游 LSR 收到了 Label Request 而发送该 Label Request, 那么如果所收到的 Label Request 包含 Path Vector TLV, 或者 R 不支持合并:
R 必须 (MUST) 把它自己的 LSR Id 加入该 Path Vector, 并 必须 (MUST) 把所得的 Path Vector 随该 Label Request 消息一起传给其下一跳。如果该 Label Request 不包含 Path Vector TLV, R 必须 (MUST) 包含一个长度为 1、含有其自身 LSR Id 的 Path Vector TLV。
请注意, 如果 R 收到针对某个特定 FEC 的 Label Request 消息, 而 R 先前已向其次一跳发送过针对该 FEC 的 Label Request 消息且尚未收到回复, 并且 R 打算把新收到的 Label Request 与现有的未完成 Label Request 合并, 那么 R 不把该 Label Request 传播给下一跳。
如果 R 从其次一跳收到 Label Request 消息, 其中 Hop Count TLV 超过了所配置的最大值, 或者 Path Vector TLV 包含其自身 LSR Id 或超过最大允许长度, 则 R 检测到该 Label Request 消息已经历了环路。
当 R 检测到环路时, 它 必须 (MUST) 向该 Label Request 消息的源发送一条 Loop Detected 通知消息, 并丢弃该 Label Request 消息。
2.8.2. 标签映射消息
在 Label Mapping 消息中使用 Path Vector TLV 和 Hop Count TLV, 提供了一种发现并终止成环 LSP 的机制。当 LSR 从某个下一跳收到 Label Mapping 消息时, 该消息按如下规定向上游传播, 直到到达某个入口 LSR 或发现环路。
当启用环路检测时, 支配 LSR R 所发送的 Label Mapping 消息中使用 Hop Count TLV 的规则如下:
-
R 必须 (MUST) 包含一个 Hop Count TLV。
-
如果 R 是出口, 则跳数值 必须 (MUST) 为 1。
-
如果发送该 Label Mapping 消息是为了把从下一跳收到的 Label Mapping 消息传播给某个上游对等体, 则跳数值 必须 (MUST) 按如下方式确定:
-
如果 R 是某个 LSR 域的边缘集合的成员 (该域中的 LSR 不执行 'TTL 递减', 例如 ATM LSR 域或帧中继 LSR 域), 且该上游对等体位于该域内, 则 R 必须 (MUST) 在传播该消息之前把跳数重置为 1。
-
否则, R 必须 (MUST) 在传播该消息之前把从下一跳收到的跳数加一。
-
-
如果发送该 Label Mapping 消息不是为了传播某条 Label Mapping 消息, 则跳数值 必须 (MUST) 等于把 R 当前所知的、从先前 Label Mapping 消息学到的跳数加一的结果。请注意, 如果 R 没有从该下一跳收到过 Label Mapping 消息, 则该跳数值将是未知的。
任何 Label Mapping 消息都 可以 (MAY) 包含 Path Vector TLV。当启用环路检测时, 支配 LSR R 所发送的 Label Mapping 消息中强制使用 Path Vector TLV 的规则如下:
-
如果 R 是出口, 该 Label Mapping 消息不必包含 Path Vector TLV。
-
如果 R 发送该 Label Mapping 消息是为了把从下一跳收到的 Label Mapping 消息传播给某个上游对等体, 则:
-
如果 R 支持合并, 且 R 先前未向该上游对等体发送过 Label Mapping 消息, 则它 必须 (MUST) 包含一个 Path Vector TLV。
-
如果所收到的消息包含未知跳数, 则 R 必须 (MUST) 包含一个 Path Vector TLV。
-
如果 R 先前已向该上游对等体发送过 Label Mapping 消息, 则当所收到的消息报告 LSP 跳数增加、跳数从未知变为已知, 或从已知变为未知时, 它 必须 (MUST) 包含一个 Path Vector TLV。
-
如果上述规则要求 R 在该 Label Mapping 消息中包含 Path Vector TLV, 则 R 按如下方式计算它:
-
如果所收到的 Label Mapping 消息包含 Path Vector, 则向上游发送的 Path Vector 必须 (MUST) 是把 R 的 LSR Id 加入所收到的 Path Vector 后的结果。
-
如果所收到的消息没有 Path Vector, 则向上游发送的 Path Vector 必须 (MUST) 是一个长度为 1、含有 R 的 LSR Id 的 Path Vector。
-
如果发送该 Label Mapping 消息不是为了向上游传播某条收到的消息, 则该 Label Mapping 消息 必须 (MUST) 包含一个长度为 1、含有 R 的 LSR Id 的 Path Vector。
如果 R 从其次一跳收到 Label Mapping 消息, 其中 Hop Count TLV 超过了所配置的最大值, 或者 Path Vector TLV 包含其自身 LSR Id 或超过最大允许长度, 则 R 检测到对应的 LSP 包含环路。
当 R 检测到环路时, 它 必须 (MUST) 停止将该标签用于转发, 丢弃该 Label Mapping 消息, 并向该 Label Mapping 消息的源信号 Loop Detected 状态。
2.8.3. 讨论
如果希望在某个 MPLS 域中进行环路检测, 则应当在该 MPLS 域内的所有 LSR 上开启它, 否则环路检测将无法正常工作, 并可能导致漏检环路或误检环路。
配置了环路检测的 LSR 不要求把 Path Vector 作为 LSP 状态的一部分来存储。
请注意, 在只存在不支持合并的 LSR 的网络中, Path Vector 沿下游方向从入口传递到出口, 而不向上游传递。即使支持合并, 对于已知能到达出口的 LSP, 也不必向上游传递 Path Vector。当 LSR 遇到下一跳变化时, 只有当它无法从跳数判断该下一跳变化不会造成环路时, 它才需要向上游传递 Path Vector。
在有序标签分发的情况下, Label Mapping 消息从出口向入口传播, 沿途自然地创建 Path Vector。在独立标签分发的情况下, LSR 可能在从下游对等体收到该 FEC 的 Label Mapping 消息之前, 就为某个 FEC 发出 Label Mapping 消息。在这种情况下, 随后从该下游对等体收到的该 FEC 的 Label Mapping 消息被视为对 LSP 属性的更新, 并且必须向上游传播该 Label Mapping 消息。因此, 建议把环路检测与有序标签分发一起配置, 以尽量减少 Label Mapping 更新消息的数目。
2.9. LDP 消息的真实性与完整性
本节规定一种机制, 用于防范把伪造的 TCP 段引入 LDP 会话连接流。该机制的使用 必须 (MUST) 作为一种可配置选项得到支持。
该机制基于 [RFC2385] 中规定的、供 BGP [RFC4271] 使用的 TCP MD5 Signature Option。MD5 散列函数的规范见 [RFC1321]。从标准成熟度的角度看, 本文档与 [RFC2385] 的关系同 [RFC4271] 与 [RFC2385] 的关系相同。这一点在 [RFC4278] 中有说明。
2.9.1. TCP MD5 Signature Option
以下摘自 [RFC2385] 的文字概述了使用 TCP MD5 Signature Option 所达到的安全性质, 并总结了其操作:
"IESG 说明 (IESG Note)
本文档描述用于保护 BGP 抵御某些简单攻击的现有实践。可以理解 的是, 它在面对协同攻击时存在安全弱点。"
"摘要 (Abstract)
本备忘录描述一种 TCP 扩展, 以增强 BGP 的安全性。它定义了一个 新的 TCP 选项, 用于在一个 TCP 段中携带 MD5 [RFC1321] 摘要。 该摘要作用如同该段的签名, 其中包含了只有连接端点才知道的信息。 由于 BGP 使用 TCP 作为其传输, 按本文所述方式使用该选项可以 显著降低某些安全攻击对 BGP 的危险。"
"引言 (Introduction)
该选项的主要动机是使 BGP 能够保护自己免受把伪造的 TCP 段引入 连接流之害。特别值得关注的是 TCP 复位 (reset)。
要使用本文所述方案伪造一个连接, 攻击者不仅必须猜出 TCP 序列号, 还必须获得包含在 MD5 摘要中的口令。该口令从不出现在连接流中, 口令的实际形式由应用决定。它甚至可以在某个特定连接的生命周期 内变化, 只要该变化在两端同步 (不过在某些 TCP 实现中, 口令变化 时重传可能成为问题)。
最后, 对于该选项的使用不存在协商, 它的连接是否使用该选项完全 是站点策略问题。"
"MD5 作为散列算法 (MD5 as a Hashing Algorithm)
自本备忘录首次发布 (以另一个标题) 以来, MD5 算法已被发现易受 碰撞搜索攻击 [Dobb], 并且被一些人认为对于这类应用而言强度不足。
然而, 本备忘录仍然规定 MD5 算法, 因为该选项已经在运营中部署, 而且没有定义 "算法类型" 字段来允许使用同一选项号进行升级。原始 文档没有规定类型字段, 因为那将至少需要多一个字节, 而当时认为 用 19 个字节来构成完整选项 (在 TCP 实现中很可能被填充到 20 字节) 会过多浪费本已有限的选项空间。
这并不妨碍部署另一种使用其他散列算法 (如 SHA-1) 的类似选项。 此外, 如果大多数实现无论如何都把所定义的 18 字节选项填充到 20 字节, 那么定义一个新的、包含算法类型字段的选项也是同样可行的。 不过, 这一点需要在另一份文档中解决。"
摘自 [RFC2385] 的引用结束。
2.9.2. LDP 对 TCP MD5 Signature Option 的使用
LDP 按如下方式使用 TCP MD5 Signature Option:
-
对 LDP TCP 连接使用 MD5 Signature Option, 是 LSR 的一个可配置选项。
-
使用 MD5 Signature Option 的 LSR 为每个潜在 LDP 对等体配置一个口令 (共享秘密)。
-
该 LSR 按 [RFC2385] 的规定应用 MD5 算法, 计算要发送给某个对等体的 TCP 段的 MD5 摘要。该计算既使用对等体口令, 也使用该 TCP 段。
-
当该 LSR 收到带有 MD5 摘要的 TCP 段时, 它通过计算 MD5 摘要 (使用其自己记录的口令) 并把计算出的摘要与所收到的摘要进行比较来验证该段。如果比较失败, 则丢弃该段, 且不向发送方作任何响应。
-
该 LSR 忽略来自任何未配置口令的 LSR 的 LDP Hello。这确保该 LSR 只与已配置口令的 LSR 建立 LDP TCP 连接。
2.10. 显式路由 LSP 的标签分发
流量工程 [RFC2702] 预期是重要的 MPLS 应用。MPLS 对流量工程的支持使用显式路由 LSP, 它不必遵循由基于目的地的路由协议所确定的通常路由 (逐跳) 路径。CR-LDP [CRLDP] 定义了 LDP 的扩展, 以便使用 LDP 建立显式路由的 LSP。