mpls 保留标签值_MPLS：鸿蒙初辟
祝贺华为
第十一章 MPLS
华为任正非2013年11月25日接受巴黎小范围媒体采访时表示“华为和思科还不一样。思科要比我们先进。全世界走向 ATM 技术模式时，唯有思科走的是 IP 模式。结果我们全部都走错了，就思科走对了。我们现在还创建不到这么高水平，因为我们还是走向 IP 的路上，在这条路上的创造能力还不如思科”。
华为一向都有强烈的危机意识。笔者以为，任老板在说这番话时，既有谦虚的成份，也有对思科的尊敬，更是对他自己和整个华为公司的一种激励。对危机的警醒、对卓越的追求、对客户的认真负责，促使着华为这么多年来一直在砥砺奋进，取得了一个又一个的辉煌成就。
话题扯远了，还是回到本章的主题。从网络协议角度讲，任正非当时所说那番话的背后，是二十世纪九十年代整个通信行业的技术路线世纪之争：IP 和 ATM 谁将成为下一代网络技术基础？
现在看来，答案是非常明显。IP 对 ATM 取得了“碾压”性的胜利。但是造化弄人，虽然早已是明日黄花，但是 ATM 标签交换的思想与 IP 相结合所催生的 MPLS 技术，在当今的网络里大展身手、所向披靡。
在那场世界之争中，除了思科“高瞻远瞩”，还有一个公司“卓尔不群”，它在思考“是否可以将 ATM 与 IP 相结合”。正是这个思考，使得这个位于美国加州名字叫作 IPSilon 的小公司成为了 MPLS 最早的先行者。1996年春，IPSilon 推出了一项具有震撼意义的技术，称为 IP Switching。IP Swiching 技术通过在ATM交换机上提供一个额外的 IP 路由引擎，较好地把 ATM 的高速转发能力和IP的简洁易部署特点结合起来。
IP Switching技术的推出,使得 IPSilon 公司由一个默默无闻的小公司，一举成为IP通信界的明星。受到 IPSilon 的刺激，业界巨头纷纷推出更易于扩展和升级的三层交换解决方案，比如 CISCO 提出了 Tag Switching(标记交换)方案、IBM 提出了 ARIS(Aggregate Route-based IP Switching，聚类基于路由的 IP 交换)方案。一场路由交换技术的革命，拉开了大幕。
为了协调各方利益，形成一个统一的标准，1996年底，IETF成立了一个工作组，对集成路由和交换技术的标签解决方案进行标准化。到1997年初，这个工作组形成了IETF认可的章程，工作组的第一次会议在1997年4月召开。经过多次商讨，最终 MPLS(Multi-Protocol Label Switching，多协议标签交换)这个术语被确定下来，作为独立于各个厂家私有标准的一系列标准的名称。
说明：
(1)ATM(Asynchronous Transfer Mode，异步传输模式)是以信元为基础的一种分组交换和复用技术。
(2)IPSilon 公司在1997年被诺基亚收购。
MPLS 中的“MP(Multi-Protocol)”指的是 MPLS 可以支持多种网络层的协议，包括IP、IPX(Internet Packet Exchange)、Appletalk、DECnet、CLNP(Connectionless Network Protocol)等。不过这并不是关键，最关键的是 MPLS 能够与 IP 协议很好地配合。
所以本章忽略“MP”，而是将重点放在讲述 MPLS 中的“LS(Label Switching)”的含义，以及“标签交换”与 “IP 转发”的关系。
11.1 MPLS 概述
在 IP Header 中，有一个字段表示“目的 IP”，路由器收到该报文时，会通过“目的 IP ”查找 FIB(Forwarding Information Base，转发信息库，也称转发表)，进而查出“下一跳”、“出接口”等关键字段，然后再进行转发。
类似地 MPLS 的报文头中，也有“Lable”这样的字段，路由器收到该报文后，也会查找 LFIB(Label Forwarding Information Base，标签转发信息库，也称标签转发表)进行转发。
MPLS(RFC 3031)的报文格式，如图11-1所示。
图11-１ MPLS 报文格式
MPLS 在2层(数据链路层)和3层(IP 层)之间，插入了1个 MPLS Header。基于此，也有人称 MPLS 为2.5层协议。
MPLS 一共包含4个字段：Label、Exp、S、TTL。
Label
Label 占有20个 bits，标识标签的值。MPLS 就是利用 Label 进行转发。
Exp
Exp 是 Experimental 的缩写，也就是说 Exp 是一个“实验”字段。不过 MPLS 一般是拿它来做 QoS 标记。
Exp 占有3个 bits，可以标识8个 QoS 优先级。
S
S 是栈底标志(栈，Stack)。S 为1时，表明此为最底层标签，S 为 0 时表明后面还接有1个 MPLS Header，如图11-2所示。
图11-２ MPLS 的“S”标志
通过图11-2可以看到，MPLS的标签理论上可以无限嵌套，从而提供无限的业务支持能力(MP-BGP MPLS L3VPN，就是利用了 MPLS 的2层标签)。这正是MPLS技术最大魅力所在。
TTL
TTL(Time to Live，生存期)字段占有8个 bits，其与IP报文中的 TTL 功能类似。
正如 IP 的报文格式仅仅是 IP 的一小部分一样，MPLS 的报文格式，也仅仅是 MPLS 协议的一小部分。
IP 可以分为两大部分：转发面和控制面。简单地说，转发面就是通过转发表进行路由转发，控制面就是构建路由表、转发表。IGP、BGP 都是属于 IP 控制面的协议。
同理，MPLS 协议也可以分为两大部分：转发面和控制面。简单地说，MPLS 的转发面就是通过标签进行转发，MPLS 的控制面就是构建 MPLS 的标签。
当然，除了转发面和控制面，MPLS 和 IP 都还包括 OAM(Operation Administration and Maintenance，操作维护管理)的功能。由于篇幅和主题的关系，本章不涉及 MPLS 的 OAM。
下面我们就分别讲述 MPLS 的转发和控制方面的内容。
11.2 MPLS 的转发
从报文格式的角度来说，MPLS Header 位于 IP Header 之前，但是从转发的角度来说，MPLS 却是位于 IP 之后，即1个 IP 报文先是经过 IP 协议栈，然后再被“引流”到 MPLS协议栈，才能进行 MPLS 转发。当然这只是一个比方，无论是协议的设计还是协议栈的具体实现，MPLS 都不应该与 IP 耦合。
这么说有点抽象，我们还是先看看 MPLS 的转发模型。
11.2.1 MPLS 转发模型
MPLS 的转发模型，可以分为2部分：转发基本模型、转发等价类。下面我们分别讲述。
11.2.1.1 转发基本模型
MPLS 的转发基本模型，如图11-3所示。
图11-３ MPLS 转发基本模型
图11-3中，路由器 R1~R7 组成了1个 IP 网络，IF0、IF1 表示的是路由器接口(IF 是 Interface 的缩写)。网络中 R1~R6 通过 IGP 协议(比如 OSPF)构建了路由表/转发表。当 PC1(100.1.1.1)发送1个 IP报文给 PC2(20.2.2.2)时，报文首先到达 R1。R1 查找转发表，发现下一跳是R2(实际上还包括出接口的查找，我们暂时忽略)，就将报文转发给 R2。同理 R2 转发给 R3、R3 转发给 R4、R4 转发给 PC2。就这样，R1~R4 完成了1次路由转发。在这次转发中，“R1-R2-R3-R4”也可以称为1个3层路径(L3 Path，L 是 Layer 的缩写)。
与 IP 转发相比，MPLS 的转发从 R1 开始，其“画风”就开始转变。IP 的路由转发是查找的 FIB(Forwarding Information Base)，而 MPLS 的标签转发所查找的是 LFIB(Label Forwarding Information Base)。
LFIB 的结构(示意)，如表11-1所示。
表11-1 LFIB 的结构示意
In Interface (入接口) |
In Label (入标签) |
Dst. Address (目的地址) |
Out Interface (出接口) |
Out Label (出标签) |
IF0 |
-- |
200.2.2.0/24 |
IF1 |
2020 |
... |
... |
... |
... |
... |
表11-1只是 LFIB 的一个示意(以 R1 为例)。通过表11-1可以看到，LFIB 与 FIB 的最大区别是将 FIB 的“下一跳”换成了“出标签”。
我们假设 MPLS 的转发路径与 IP 的转发路径是一样的，对于图11-3来说，PC1 到达 PC2 的路径都是“R1-R2-R3-R4”，那么我们就将 LFIB 叠加到转发路径上，以对 LFIB 有个更加直观的认识，如图11-4所示。
图11-４ LFIB 示例
实际上对于图11-4中的 R2、R3、R4 来说，LFIB 中的目的地址并无实际意义。它们的转发，只需要根据“入接口”、“入标签”这2个参数，查找到“出接口”、“出标签”即可(R4 的“出标签”为空)。
对于 R1 来说，它的“入标签”为空，所以需要通过“入接口”、“目的地址”这2个参数，查找到“出接口”、“出标签”。
对于 R4 来说，它的“出标签”为空，所以下一步就不能再是 MPLS 转发。
图11-4中的 R1 和 R4,它们分别是 MPLS 转发的“入节点(Ingress)”和“出节点(Egress)”，所以称为 LER(Label Edge Router，标签边缘路由器)。
图11-4中的 R2 和 R3，它们是 MPLS 的“中间点(Transit)”，所以被称为 LSR(Label Switch Router，标签交换路由器)。当然，LER 也是 LSR 的一种。
相应地，图11-4中的“R1-R2-R3-R4”，就被称为 LSP(Label Switch Path，标签交换路径)。
需要强调的是，LER、LSR、LSP 都是与某一个具体的转发相关的。转发不同，路由器的角色也不同，如图11-5所示。
图11-５ MPLS 转发示例
图11-5中，PC3 到达 PC4 的路径是“R2-R7-R6”，所以 R2、R6 是 LER，R7 是 LSR，“R2-R7-R6”是 LSP。
另外，LSP 也可以称为 MPLS Tunnel(隧道)。隧道可以简单理解为“一种转发协议封装另一种转发协议”。比如图11-5，原本“R2-R7-R6”走的是 IP 转发，现在变成了 MPLS 转发。MPLS 将 IP 报文封装起来，使得网络在转发的过程中，不必感知 IP 协议。我们会在第12章继续涉及 MPLS Tunnel 相关概念，这里就不再着墨。
11.2.1.2 转发等价类
转发等价类(Forwarding Equivalence Class，FEC)这个名词，乍一看让人摸不着头脑。我们把这个词掰开来看。
(1)转发：指的是 MPLS 转发
(2)等价：指的转发走同一条 LSP
(3)类：就是类别的意思
这样一来就明白了：1个 FEC 与1条 LSP 相对应。
“物以类聚，人以群分”。什么样的流(IP 报文)属于1个 FEC 呢？或者说 FEC 划分类别的标准是什么呢？
FEC 分类的标准有很多种。MPLS 可以将网络中的流按照“源地址、目的地址、源端口、目的端口、传输层协议类型，以及其他参数”做任意得组合，并根据这些组合划分不同的类别，也就是 FEC。
不过这么多 FEC 类别，我们最熟悉的可能还是 Prefix FEC。下面我们就以 Prefix FEC 为例来进行讲述，以对 FEC 有个直观的感觉。
Prefix 就是 IP 地址的 Prefix(前缀)，也就是 IP 地址中的网络地址(当然，如果 Prefix 的长度等于32，那 Prefix 就代表 Host Address)。所以，Prefix FEC，顾名思义，就是与网络地址(含 Host Address)相关。
FEC 的数据结构是 TLV(Type-Length-Value)格式，如图11-6所示。
图11-６ TLV 格式
图11-6中，各个字段的含义如下。
(1)U(Unknown TLV bit)：占有1个bit，对于 FEC 来说，其值为0。
(2)F(Forward unknown TLV bit)：占有1个bit，对于 FEC 来说，其值为0。U、F 两个字段，与本节主题无关，我们不做解释，具体请参见 RFC 5036
(3)Type，占有14个 bits，表示数据类型，对于 FEC 来说，其值为 0x0100
(4)Length，占有16个 bits，表示数据的长度，长度计量单位是“字节”
(5)Value，数据的值，是一个变长字段，数据的长度由“Length”字段标识。
具体到 FEC，其数据结构如图11-7所示。
图11-７ FEC 数据结构
图11-7中的“FEC Element 1”至“FEC Element 1”，本质上1个 FEC 数据结构包含多个 FEC(Element)，本质上是指多个 FEC 对应1个 LSP。
FEC Element 也有多种类型，Prefix FEC 只是其中的一种，其数据结构如图11-8所示。
图11-８ Prefix FEC 数据结构
图11-8中的各字段含义如下。
(1)FEC Type：占有8个 bits。对于 Prefix FEC 来说，其值等于 0x02。FEC 还有一种类型是“Wildcard”，其值为 0x01，具体可以参见 RFC 5036
(2)Address Family：占有16个 bits，对于 IPv4 Prefix 来说，其值等于 0x01
(3)PreLen：占有8个 bits，指示 Prefix 的长度，长度计量单位是“bit”
(4)Prefix：IP 地址的 Prefix 部分。比如“1.1.1.0/24”的 Prefix 就是“1.1.1”，PreLen 等于24。当然，“1.1.1”要用bit的形式表示：111111100000000111111111(1 * 2553 + 1 * 2552 + 1 * 255)
现在我们对于 Prefix FEC 有个初步的了解，下面我们就继续以 Prefix 为例，看看它是如何与路由表挂钩、如何与目的地址挂钩，从而使得 MPLS 将 IP 转发变成了 MPLS 转发。
11.2.2 MPLS 的转发过程
当1个 IP 报文到达 MPLS 的 “入节点”时(Ingress LER)，Ingress LER 需要根据 “目的地址”从 LFIB 查询“出标签”和“出接口”。表11-1和图11-4仅仅是表达的就是这个含义。
查询到“出标签”以后，Ingress LER 需要将 IP 报文封装为 MPLS 报文，然后从“出接口”转发出去。这个过程，MPLS 称之为“Push”。
MPLS 的“中间节点”(Transit LSR) 接到 MPLS 报文以后，就直接根据“入标签”查询 LFIB，查到“出标签”和“出接口”以后，Transit LSR 会将 MPLS 报文中的 Label 字段替换为其所查到的“出标签”，然后通过“出接口”转发出去。这个过程，MPLS 称为之为“Swap”。
MPLS 的“出节点”时(Egress LER)接到 MPLS 报文以后，也是直接根据“入标签”查询 LFIB。只是 Egress LER 仅仅查询到了“出接口”，而没有查询到“出标签”，这个时候该路由器就知道自己是 MPLS 的最后1跳了，于是它将报文中的 MPLS Header 剥去，还原为原来的报文格式，然后从“出接口”转发出去。这个过程，MPLS 称为之为“Pop”。
Push、Swap、Pop 就是 MPLS 的基本转发过程。但是这里面还有2个细节需要讲述一下，一个是 LFIB，另一个是“倒数第二跳弹出”。
11.2.2.1 LFIB
11.2.1节所说的 LFIB(Label Forwarding Information Base)实际上只是1个逻辑意义上的表，从具体实现来说，各个厂商一般都会将 LFIB 分解为多张表：NHLFE、FTN、ILM。
NHLFE
NHLFE(Next Hop Label Forwarding Entry，下一跳标签转发表项)用于指导MPLS报文的转发。NHLFE包括：Tunnel ID、出接口、下一跳、出标签、标签操作类型等信息，如表11-2所示。
表11-2 NHLFE 示意
Tunnel ID |
Out Interface |
Out Label |
Next Hop |
Operate Type |
0x11 |
IF1 |
2020 |
R2.IP |
Push |
... |
... |
... |
... |
... |
表11-2是以图11-4的 R1 为例，对 NHLFE 做了一个示意。因为 LSP 也可以成为 MPLS Tunnel，所以表11-2中的 Tunnel ID，其本质上是暗含着1条 LSP 的意思。
表11-2中的 Next Hop 对于 MPLS 转发的意义，我们放到11.3节的讲述。
表11-2中的 Operate Type，指的就是 MPLS 转发过程中的动作。由于图11-4中的 R1 是 MPLS 转发的“入节点”，所以它的转发动作是“Push”。
FTN
FTN(FEC-to-NHLFE)，表示 FEC 到 NHLFE 的映射，包含 FEC、Tunnel ID 等2个字段。我们还是以图11-4的 R1 为例，看看 FTN 的示意，如表11-3所示。
表11-3 FTN 示意
FEC |
Tunnel ID |
FEC1 |
0x11 |
... |
... |
表11-3中的“FEC”是个示意，实际上会包含“源地址、目的地址、源端口、目的端口、传输层协议类型”等等各种组成 FEC 的字段。
表11-3中的“Tunnel ID”本质上是指代1条 LSP。如果 Tunnel ID 等于“0”，那就表示没有对应的 LSP，也就是意味着不支持 MPLS 转发(支持 IP 转发)。这句话实际上隐含着 FIB 中的路由表项与 FEC 的映射关系。
对于 Prefix FEC 来说，1个 Prefix 对应着1条 LSP。对于 FIB 来说，1个目的地址，也对应着1个 IP 转发路径。那么 FIB 中的目的地址与 Prefix 该如何映射呢？有2种映射规则。
(1)精确匹配。路由表中的目的地址与 FEC 中的 Prefix 完全相同，才会认为两者是匹配的。这个时候，该路由表项才会与1个 LSP 挂钩
(2)最长匹配。最长匹配就是不追求精确匹配，而是追求最长掩码匹配，路由表中的目的地址与 FEC 中的 Prefix 进行掩码匹配，谁的掩码匹配长度最长，就选择哪个 FEC。
路由器将路由表中的每一个路由表项，按照其中一种映射规则，映射到1个 FEC，也就等价与映射到1个 LSP。所以，在具体实现中，有的厂商就是使用 FIB 承担 FTN 的职责：在 FIB 中增加1个字段“Tunnel ID”，如果目的地址与某一个 FEC 有映射关系，那么就填上相应的 Tunnel ID，否则，Tunnel ID 就赋值为0。
说明：FEC 与 LSP 如何对应，请参见 11.3 和 11.4。
ILM
ILM(Incoming Label Map)，表示的“入标签”到 NHLFE 的映射，包括：Tunnel ID、入标签、入接口、Tunnel ID 等信息。 我们还是以图11-4的 R2 为例，看看 ILM 的示意，如表11-4所示。
表11-4 ILM 示意
In Interface |
In Label |
Tunnel ID |
IF0 |
2020 |
0x22 |
... |
... |
相应地，图11-4中的 R2 的 NHLFE，如表11-5所示。
表11-5 NHLFE 示意(R2)
Tunnel ID |
Out Interface |
Out Label |
Next Hop |
Operate Type |
0x15 |
IF2 |
2030 |
R3.IP |
Swap |
... |
... |
... |
... |
... |
通过表11-2~表11-5可以看到，之所以将 LFIB 一分为三(NHLFE、FTN、ILM)，其实是在路由器厂商在具体的实现中，为了避免数据的冗余而做的数据解耦设计。
11.2.2.2 倒数第二跳弹出
如果没有“倒数第二跳弹出(Penultimate Hop Popping，PHP)”机制，MPLS 是在最后一跳(MPLS 转发的“出节点”)做 Pop 动作(称为“最后一跳弹出”)，如图11-9所示。
图11-９ “最后一跳弹出”示意
图11-9是对图11-4的简化描述，而且为了突出主题，不仅没有将 LFIB“一分为三”，还将 LFIB 做了简化，只保留了“入标签”、“出标签”2个字段。
图11-9中的 R4，接到 R3 转发过来的 MPLS 报文时，会做3个动作。
(1)查找 LFIB 表，发现出标签为“空”
(2)剥去 MPLS Header，还原为原来的报文格式(IP 报文)
(3)查找 FIB(路由转发表)，将 IP 报文转发出去
这个过程中，出现了2次查表，一次是查 LFIB，一次是查 FIB。有没有可能减少一次查表呢？准确地说，是将 LFIB 查询省略掉，只查询 FIB(因为最终需要路由转发，无法省略掉 FIB)。
PHP的目的就是如此，它就是为了将“最后一跳弹出”方案中的“LFIB”查询给省略掉。
PHP 的原理正如它的名字所暗示的那样，在“倒数第二跳”将 MPLS Header 弹出即可。不过 PHP 的具体实现有2种方法。
(1)倒数第二跳将“出标签”设置为“3”。路由器看到“出标签”为“3”，知道自己是“倒数第二跳”，于是它直接将 MPLS 弹出。那么显然，“最后一跳”所收到的报文，就是1个原生的 IP 报文，于是它只需要“FIB 查找”即可。
标签“3”也被称为“implicit-null label(隐示空标签)”，因为它的值是“3”而不是“0”，而“0”在语义层面与“空”挂钩。
(2)倒数第二跳将“出标签”设置为“0”，并不弹出 MPLS Header。路由器看到“入标签”为“0”，知道自己是“最后一跳”，于是它就不必去查找 LFIB，只需要做“弹出”和“FIB 查找”即可。
标签“0”也被称为“explicit-null label(显示空标签)”。
说明：“倒数第二跳将‘出标签’设置为‘0’、倒数第二跳将‘出标签’设置为‘3’”，严格来说，这里的“设置”二字用词并不准确。除了最后一跳的 LSR 可以设置自己的“出标签”(当然，此时的所谓的“出标签”实际上也不存在)，其它所有的 LSR(包括倒数第二跳)，它的“出标签”并不是自己“设置”的，而是依据下一跳通告的标签而赋值的。具体请参见11.3节。
两种方法都比较简单，从省略了“LFIB 查找”这一步骤来讲，两者的效果也是一样的。不过“隐示空标签”是真正的在“倒数第二跳”弹出了 MPLS Header。11.1节讲过，MPLS Header 中的 Exp 字段一般用来表达 QoS 信息，如果在“倒数第二跳”弹出了 MPLS Header，会对最后一跳的 QoS 处理造成一定的影响。所以，一般的默认实现都是采用“显示空标签”。
显示也好，隐式也罢，我们在讲述这两种方法都有意忽略了1个关键点：路由器如何知道它是1条 LSP 的“倒数第二跳”的？
不仅如此，从表11-1到表11-5中的“入标签”、“出标签”，路由器又是如何知道的？是谁给它们赋的标签值？这就涉及到了 MPLS 的控制面。
11.3 标签分发协议
11.2节所讲述的 LFIB(NHLFE、FTN、ILM)，表面上看起来每个路由器的 LFIB 是独立的，但是实际上各个路由器的 LFIB 互相“关联”，隐含着一条条的 LSP。
MPLS 构建这一条条的 LSP 呢？有两种方法：人工静态分配、通过控制面协议动态分配。
广义地讲，人工静态分配也是“控制面”的一种，不过这没有什么好说的，“人”对着网络拓扑图，“脑补”出一条条 LSP,然后再相应地配置标签及其它字段即可。
狭义的控制面，指的是通过协议自动地进行标签分配。控制面协议包括 ：LDP、CR-LDP、RSVP-TE 等多种协议。
说明：
LDP：Label Distribution Protocol，标签分发协议
CR-LDP：Constraint-Based LDP，基于路由受限标签分发协议
RSVP-TE：Resource Reservation Protocol-Traffic Engineering，基于流量工程扩展的资源预留协议
由于篇幅和主题的原因，本章只介绍 LDP。
11.3.1 LDP 概述
LDP(Label Distribution Protocol，标签分发协议)是 MPLS 的一种控制协议，相当于传统网络中的信令协议，负责 FEC 的分类、标签的分配以及 LSP 的建立和维护等操作。LDP 规定了标签分发过程中的各种消息以及相关处理过程。
11.3.1.1 LDP 的报文格式
LDP 的报文格式，如图11-10所示。
图11-１０ LDP 报文格式
LDP 一共有4种消息类型(Discovery、Session、Advertisement、Notification)，这4种消息类型的报文格式都是一样的，就是图11-10所展示的那样——承载于 TCP 或者 UDP，报文分为2部分：LDP Header、LDP Data。
LDP Header 包含3个字段。
(1)Version：占有 16 bits，表示版本号。目前LDP 的版本号始终为1
(2)PDU Length：占有 16 bits，表示整组 LDP 消息的总长度(计量单位为字节)，不包括 LDP PDU 头部的长度
(3)LDP Identifier：占有 48 bits，表示 LDP 标识符。前 32 bit为LSR ID，后16 bit 为标签空间
LDP Data 是1个变长字段，它的基本数据结构，如图11-11所示。
图11-１１ LDP Data 的数据结构
LDP Data 包含6个字段。
(1)U：占有 1 bit，标志位。为0 表示可以识别的消息，为1表示不能识别的消息。(一般都是为0)
(2)Message Type：占有 15 bits，LDP 消息的类型
(3)Message Length：占有 16 bits，LDP Data 的长度
(4)Message ID：占有 16 bits，LDP 消息的编号，用于唯一地标识1个LDP 消息
(5)Mandatory Parameters：LDP 消息的强制参数
(6)Optional Parameters：LDP 消息的可选参数
LDP Data 就是 LDP 消息(Message)，它分为4种消息类型，如表11-6所示。
表11-6 LDP 消息类型
消息类型 |
功能简述 |
消息名称 |
传输类型 |
Discovery (发现) |
用于 LDP 对等体的发现 |
Hello 消息 |
UDP |
Session (会话) |
用于建立、维护和终止LDP对等体之间的会话 |
Initialization 消息 Keepalive 消息 |
TCP |
Advertisement (通告) |
用于创建、改变和删除 FEC 的标签映射 |
Address 消息 Address withdraw 消息 Label request 消息 Label mapping 消息 Label withdraw 消息 Label release 消息 Label abort request 消息 |
TCP |
Notification (通知) |
用于提供建议性的消息和差错通知 |
Notification 消息 |
TCP |
11.3.1.2 LDP 的功能概述
LDP 的4种消息类型，对应着 LDP 的4种协议功能。
Discovery
Discovery 消息简单地说就是为了 LDP 的对等体发现(Peer discovery)。LDP Peer 的发现方式有2种。
(1)基本发现机制：用于发现链路上直连的 LSR
网络中每个 LSR 都周期性地发送 Hello消息。Hello 消息承载于 UDP 报文，目的地址是组播地址“224.0.0.2”。
有发送就有接收。如果某个 LSR 在某个接口上收到了 LDP Hello消息，那就说明该 LSR在该接口存在 LDP Peer。
(2)扩展发现机制：用于发现链路上非直连 LSR。
扩展发现机制与基本发现机制相比，只有1个不同点，那就是 Hello 消息的目的地址。由于是非直连，所以目的地址只能是单播地址，而且这个单播地址也需要人工指定。
无论是哪种机制，通过 Hello 消息，网络中的 LSR 都可以发现自己的对等体，如图11-12所示。
图11-１２ LDP Peer 示意
图11-12中，R2 与 R3、R3 与 R6、R6 与 R5、R5 与 R2 都是互为 LDP Peer。
Session
LDP Peer 的建立过程非常简单，它甚至都不存在建立过程，只是一个发现过程。发现了1个 LSR，就意味跟对方是 LDP Peer。但是这种“只是因为在人群中多看了你一眼”，并不会意味着“今生的爱情故事不会再改变”。因为此时 LDP Peer 之间还没有“爱情”。
要想建立“爱情”，LDP Peer 之间必须要互相协商相关参数，只有双方参数一致，才能意味着有下一步的可能。这些参数包括LDP协议版本、标签分发方式、Keepalive 保持定时器的值、最大PDU长度和标签空间等。
LDP 协商参数的消息是 Initialization 消息。承载 Initialization 消息的是 TCP，所以 LDP Peer 首先要建立 TCP 连接。
TCP 连接的建立，以及参数的成功协商(Initialization 消息)，这个过程称为建立 LDP Session。
既然 LDP Session 是基于 TCP 连接，而且后续的消息还需要基于此 Session，那也就意味着 LDP 需要 Keepalive 消息长期保持 Session。
Advertisement
LDP Peer 双方通过 Session 消息建立会话，并参数协商一致后，就可以通过Advertisement 消息进行标签分配和发布。这个我们放到11.3.2节重点讲述。
Notification
在 LDP Session 的保持过程中，总有可能会遇到这样那样的状况和问题，所以 LDP 使用 Notification 消息以“提供建议性的消息和差错通知”。
通过以上描述，我们可以简单总结 LDP 的基本功能。
(1)LDP Peer 的发现
(2)LDP 参数的协商(建立 LDP Session)
(3)标签的分配和发布
(4)LDP Session 的维护(Session 的保持、建议性的消息和差错通知)
下面我们重点讲述 MPLS 标签的分配和发布。
11.3.2 标签的分配和发布
MPLS 标签的分配和发布，是基于 LDP 的 Advertisement 消息。Advertisement 消息又细分为：Address、Address withdraw、Label request、Label mapping、Label withdraw Label release、Label abort request 等多种消息。本节并不打算介绍这些消息的详细和格式和流程，而是基于“标签的分配和发布”的基本原理进行讲述。
在讲述基本原理之前，我们先讲述1个概念：上游和下游。
在“标签的分配和发布”中，“上游和下游”是绕不开的2个名词，如图11-13所示。
图11-１３ 上游和下游示意
首先需要澄清的是，“上游和下游”是相对的，没有哪个路由器是另一个路由器的绝对的“上游”或“下游”。
在 IP 转发中，1条 IP 路径对应的是“目的地址”。在 MPLS转发中，1条 LSP 对应的是 FEC(Forwarding Equivalence Class)。FEC 的划分有很多种方法，这里我们简化模型，假设 FEC 就是 Prefix FEC，比如图11-12中，“200.3.1.0/24”就等价于1个 FEC(记为 FEC1)。
“水往低处流”。1条 LSP，去往 FEC 所指代的方向，就是“上游”去往“下游”的方向。图11-12中，FEC1 所指代的就是“200.3.1.0/24”，所以：R1 是 R2 的上游、R2 是 R3 的上游、R3 是 R2 的下游、R2 是 R1 的下游。
澄清了“上游和下游”概念以后，我们正式讲述“标签的分配和发布”的基本原理。
11.3.2.1 标签分配控制方式
所谓标签分配，就是路由器将其“心中”的每个 FEC，都分配1个“入标签”。这种分配行为，也称为“FEC 标签映射”，简称“标签映射”。
为什么分配的是“入标签”，而不是“出标签”，请参考11.4节，这里暂且不必细究。
MPLS 的标签占有20个 bits，其取值范围是0~1048575。不过这些范围有一定的分配原则。
(1)0~15：特殊标签(比如11.2.2.2节所介绍的“0”、“3”)
(2)16~1023：静态 LSP 和静态CR-LSP 共享的标签空间
(3)1024及以上：LDP、RSVP-TE 等动态信令协议的标签空间
也就是说，LDP 只会在“大于等于 1024”的范围内分配标签。
LDP 的标签分配控制方式(Label Distribution Control Mode)有2种：独立标签分配控制方式、有序标签控制方式。
1)独立标签分配控制方式
独立标签分配控制方式(Independent)比较简单直接，符合人的直观理解，如图11-14所示。
图11-１４ 独立标签分配控制方式
图11-14中，R1、R2、R3 都知道有 FEC1的存在，所以它们各自都可以独立地针对 FEC1 分配1个“入标签”。
需要强调的是，11.2.1.1节说过，Ingress LER 是相对某1条 LSP 而言的角色。所以，对于图11-14，我们不能有误解，以为 R1 就是 Ingress LER，以为它不需要分配“入标签”。
2)有序标签控制方式
有序标签控制方式(Ordered)是指对于 LSR 上某个 FEC 的标签映射，只有当该LSR 已经具有此 FEC 下一跳的标签映射信息、或者该 LSR 就是此 FEC 的出节点(Egress)时，该LSR 才可以向上游发送此FEC 的标签映射。
这句话比较拗口，这里我们先解释一半，如图11-15所示。
图11-１５ 有序标签分配方式
对于图11-15，R1、R2、R3、R7 是如何知道其关于 FEC1 的“下一跳”的？它们又如何知道自己是不是 FEC1 的“出节点”的？
我们知道，LDP 运转的前提，是“网络中各个路由器已经基于 IGP 先行构建了路由表(或者基于静态人工配置构建了路由表)”。这就意味着，网络中的每个 LSR 都知道关于某个 FEC 的“下一跳”是谁。同理，LSR 也会知道自己是不是某个 FEC 的“出节点”(没有“下一跳”，并且可达，那就是“出节点”)。
至于LSR 是如何知道关于某1个 FEC 所对应的“下一跳”的“标签映射信息”，这个我们放到11.3.2.3节讲述。
11.3.2.2 标签发布方式
1个 LSR 给它“心中”的每个 FEC 都分配了标签以后，总得告知其它 LSR，不然大家互不知晓，是无法构建出 LSP 的(具体请参见 11.4节)。
LSR 将自己的“标签映射”信息告知其它 LSR 的行为，称为标签发布。
LDP 的标签发布方式(Label Advertisement Mode)有2种：下游自主方式、下游按需方式。
1)下游自主方式
下游自主方式(Downstream Unsolicited，DU)，我们看1个例子，以有个直观感受，如图11-16所示。
图11-１６ 下游自主方式
图11-16中，R3 将它的标签映射(FEC1/2030)通告(发布)给 R2，R2 将自己的标签映射(FEC1/2020)通告给 R1。这2个通告有如下特点。
(1)2个通告是独立的，互不影响
(2)2个通告除了互不影响以外，也不受其它因素影响
(3)通告的方向是下游发布给上游
像这种“下游”将自己的标签映射信息“独立自主”地通告给“上游”的行为，称为“下游自主方式”。
下游自主方式，也是比较简单直接。不过“下游自主方式”还有2个问题需要澄清。
第1个问题，“下游”通告给其“上游”以后，该“上游”还会继续再通告给它自己的“上游”吗？也就是说，标签映射信息需要类似“一传十十传百”那样的泛洪吗？
答案是“不需要”。“下游”通告“上游”以后，“上游”不会再将该通告信息继续向上通告。也就是说，标签映射信息的通告，只有1跳。具体原因，请参考11.4节。
第2个问题，网络中的 LSR，是如何知道网络中的其它 LSR，哪些是自己的“上游”，哪些是自己的“下游”？
这个问题非常重要，人相对于路由器来说，实际上是有个“上帝视角”，所以人可以很轻松地知道谁是“上游”，谁是“下游”。但是路由器怎么会知道呢？
答案还是从路由表里寻找。
(1)对于 LSR 来说，它知道自己有哪些 LDP 邻居(与自己组成 LDP Peer 的 LSR，都是自己的 LDP 邻居)
(2)对于某1个 FEC 来说，LSR 知道针对这个 FEC，谁是自己的下一跳
(3)在自己所有的 LDP 邻居中，针对某个 FEC，是自己“下一跳”的，就是自己的“下游”，其余的，都是自己的“上游”
有了这样的判断规则，LSR 就可以通过“下游自主方式”，将自己的标签映射信息准确地发布给自己的“上游”，如图11-17所示。
图11-１７ 下游自主方式(2)
图11-17中，R3 将自己的“FEC1 标签映射信息”发布给 R7(A3.7)、R2(A3.2)，R2 将自己的“FEC1 标签映射信息”发布给 R7(A2.7)、R1(A2.1)，R7 将自己的“FEC1 标签映射信息”发布给 R2(A7.2)。
我们看到，R2 与 R7 互相通告自己的标签映射信息，因为它们互相认为对方是自己的“上游”。另外，由于“标签映射信息的通告，只有1跳”，所以它们这种互相通告的行为，也不会引发环路。
2)下游按需方式
下游按需方式(Downstream on Demand，DoD)是指对于某一个 FEC，LSR 收到标签请求消息之后才进行标签应答，如图11-18所示。
图11-１８ 下游按需方式
图11-18中，R1、R2、R3 可能都已经有了 FEC1 的标签映射信息，但是它们就是“憋在心里”，不通告给它们的“上游”。待到“上游”询问时，“下游”才会告知。比如图11-18中，R1 向 R2 询问“你的 FEC1 所对应的标签是什么”，R2 才会给 R1 回答“我的 FEC1 所对应的标签是20”。
下游按需方式，用大白话说，就是“我知道，也不说；你来问，我才答”。
但是，如果“上游”来问，“下游”是否马上应答呢？这又与标签的“分配 + 发布”的组合方式有关了。
11.3.2.3 分配与发布的排列组合
标签的分配与发布，各有2种方式，它们的排列组合，就存在4种方式，如表11-7所示。
表11-7 标签的分配与发布
独立标签分配控制 |
有序标签控制 |
|
下游自主 |
(1)每个 LSR 独立构建 FEC 与 Label 的映射 (2)每个 LSR 独立向“上游”通告自己的标签映射信息 |
(1)收到“下一跳”的标签映射消息时，可以独立向“上游”通告自己对应的标签映射信息 |
下游按需 |
(1)每个 LSR 独立构建 FEC 与 Label 的映射 (2)每个 LSR 收到“上游”的请求时，才像“上游”通告(应答)自己的标签映射信息 |
(1)收到“上游”的请求时，继续向“下游”请求 (2)收到“下游”的应答后，再向“上游”应答 |
标签的分发，包括“分配”与“发布”两部分。标签的分配，是每个 LSR 内部的事情，与其他 LSR 无关。而标签的发布，是不同 LSR 之间的事情。
笔者以为，LSR 内部的事情，就交由各厂商自己决定即可，标准(RFC)没有必要定义什么“独立标签分配”、“有序标签”之类的控制方式。而且，“有序标签控制”看起来更像是标签发布策略，而不是分配策略。
我们补充一下“下游按需 + 有序标签控制”的1个图例，以加深理解，如图11-19所示。
图11-１９ 下游按需 + 有序标签控制
图11-19中，R1 向 R2 请求 FEC1 的标签映射，R2 并不能马上回答 R1，它还得继续向 R3 请求 FEC1 的标签映射。R3 向 R2 回答其关于 FEC1 的标签是“30”，R2 收到 R3 的应答以后，才能向 R1 应答其关于 FEC1 的标签(“20”)。
需要说明的是，R2 只向 R3 请求，不会向 R7 请求，因为针对 FEC1，只有 R3 才是 R2 的“下一跳”，R2 根据“下一跳”推断出只有 R3 才是它的“下游”。
无论“标签的分配与发布”如何排列组合，对于1个 FEC，路由器是知道它到底是不是“最后一跳”的。比如对于图11-19，R3 就知道自己是 FEC1 的最后一跳。
既然知道自己是“最后一跳”，那么在向上游通告自己的“入标签”时，就可以将标签设置为“3”或者“0”通告出去。这样，它的“上游”看到这样的标签时，也就知道自己是该 FEC 的“倒数第二跳”。
11.3.2.4 标签保留方式
标签保持方式(Label Retention Mode)，与标签的“分发”没有直接关系，指的是 LSR 收到“下游”通告过来的标签映射信息的存储方式。
“下游”有2种，一种是“下一跳”，一种是“自作多情”，如图11-20所示。
图11-２０ 下游的分类
图11-20中，R3 和 R7 都认为 R2 是自己的“上游”，于是都向 R2 通告了自己的标签映射关系(假设是“独立标签分配 + 下游自主”方式)。
现在，R2 关于 FEC1 收到了2份标签映射通告。我们假设 R2 到达 FEC1 的下一跳是 R3，那么R7 的标签映射通告对于 R2 来说是“没用”的。此时，R2 对于 R7 的标签通告有2种处理方法。
(1)保守保留方式。大白话就是直接删除，不保留在自己的标签绑定表里。
(2)自由保留方式。大白话就是保留在自己的标签绑定表里。
保守保留方式的好处是节省路由器的标签空间，但是对网络拓扑变化的响应会变慢。自由保留方式则恰恰相反：坏处是浪费标签空间，好处是对网络拓扑变化的响应较快，如图11-21所示。
图11-２１ 网络拓扑变化
图11-21，假设 R2 采取的是“自由保留方式”，那么当 R2 与 R3 之间的链路断连时，R2 能够快速地构建新的到达 FEC1 的 LSP。
现在的问题是，MPLS 是如何构建 LSP 的呢？
说明：图11-20、图11-21中的“入标签”，指的是“通告者”的“入标签”。比如“2030”指的是 R3 的“入标签”。
11.4 LSP 的构建
LSP 的构建的技术，相对比较简单直接，但是其背后的应用策略，却有着鲜明的时代印记。这句话似乎有点故弄玄虚，那我们先从不“玄虚”的地方开始，先看看 LSP 构建的基本原理。
11.4.1 LSP 构建的基本原理
无论通过什么方式，MPLS 网络中的各个 LSR 最终总会得到“下游”的标签映射信息，如图11-22所示。
图11-２２ 下游的标签映射
图11-22相对于图11-20、图11-21补充了“接口”、“下一跳”等两个字段。“接口”指的是收到“下游”标签通告的接口，下一跳是标识标签映射的通告者是不是当前 LSR 的下一跳(针对通告中的 FEC)。再强调一遍，图11-22中的“入标签”，指的是“通告者”的“入标签”，不是自己的“入标签”。
LSR 将“非下一跳”的标签通告“过滤”掉以后，1个 LSP 就“呼之欲出”，如图11-23所示。
图11-２３ LSP“呼之欲出”
首先澄清一下图11-23中的“入标签”、“出标签”，指的是 R2 的“入标签”和“出标签”。
图11-23中，“万事俱备”只欠“出标签”。那么 R2 的“出标签”应该等于多少呢？显然它应该等于“下一跳”的“入标签”，这样 R2 的“出标签”就能与它的“下一跳”(R3)的“入标签”对应起来。
网络中的每个 LSR 都按照 R2 这样操作，1条通往 FEC1 的 LSP 就会被构建起来，如图11-24所示。
图11-２４ LSP 的构建
图11-24中，因为 R3 是该 LSP 的 Egress，所以其“出标签”为空。
通过图11-24可以看到，R1 的“出标签”等于 R2 的“入标签”，R2 的“出标签”等于 R3 的“出标签”。R1、R2、R3 的这种“标签接力”的方式，构建了1条通往 FEC1 的 LSP。
不过仅仅构建出 LSP 还不够，这个 LSP 还需要与路由绑定。11.2.2.1节提到“华为将 LFIB 分解成3张表：NHLFE、FTN、ILM ...... 承担 FTN 职责的是 FIB”，实际上思科虽然在具体实现细节上与华为有所不同，但是它们的基本原理是一样的。两者的实现中，“承担 FTN 职责的是 FIB”最能体现路由与 LSP 的绑定的绑定关系，如表11-8所示。
表11-8 路由与 LSP 的绑定关系
目的地址 |
出接口 |
下一跳 |
Tunnel ID |
备注 |
200.3.1.0/24 |
IF1 |
IP1 |
0x11 |
FEC1 |
200.3.2.0/24 |
IF2 |
IP2 |
0x0 |
-- |
表11-8是 FIB 的伪码表示，虽然只有短短2行数据，却反映了一个事实“FIB 里有2个路由表项，一个对应有 LSP，另一个没有对应的 LSP”。
“我家门前有两棵树，一棵是枣树，另一棵也是枣树”，这句话表达了鲁迅先生对旧社会的黑暗的愤怒和不满，并显示出自己欲求文明民主的希冀 ...... 好吧，我编不下去了。不过表11-8的背后，却蕴含着路由器构建 LSP 的方案。
(1)路由器是基于路由表项来构建 LSP 的。因为1个报文到达路由器后，它首先会查找 FIB，只有通过 FIB 查找到 Tunnel ID 以后，才会通过相应的 LSP 进行 MPLS 转发，否则就是通过 IP 转发。如果闭着眼构建1个 LSP，而这个 LSP 根本没有对应的路由表项，那么这个 LSP 实际上也就毫无意义：它显然不会出现在 FIB 中，也就是说，它永远没有被路由器“翻牌”的机会。
说明：与路由表项没有关联的 LSP，被称为“Liberal LSP(自由 LSP)”。
(2)路由器基于路由表项构建 LSP，也有2种选择：自动构建、手工构建。自动构建的意思是，路由器针对路由表项去查找相应的 MPLS 标签，如果找到，就为其构建 LSP。或者更准确地说，路由器收到1个标签通告后，会查找相应的路由表项，如果找到，就为其构建 LSP。
(3)关于第“2”点，还需要做个修正。路由器有时候不需要为每个路由表项构建 LSP(或者说，有些路由，路由器还是选择 IP 转发，而不是 MPLS 转发)，针对这种需求，路由器提供了 LSP 构建策略：只针对某些特征的路由表项才会构建 LSP。
路由器为什么需要这样的策略呢？这个跟 MPLS 所处的时代背景有一定的关系。
11.4.2 MPLS 的应用场景
20世界90年代中期，基于 IP 技术的 Internet 快速普及。但基于最长匹配算法的IP技术必须使用软件查找路由，转发性能低下。ATM(Asynchronous Transfer Mode)采用定长标签(即信元)，能够提供比IP路由方式高得多的转发性能。然而，ATM 协议相对复杂，且 ATM 网络部署成本高，这使 ATM 技术很难普及。
在这种背景下，结合双方优点(IP 的简单、部署成本低，ATM 转发性能高)的 MPLS应运而生。
然而，随着 ASIC 技术的发展，路由查找速度已经不是阻碍网络发展的瓶颈。这使得MPLS在提高转发速度方面不再具备明显的优势。
忽然间，MPLS 的地位就显得非常尴尬。因为 MPLS 并不能独立于网络层而存在(网络协议事实上就被 IP 协议“垄断”)，它原本也只是在转发层面比 IP 有优势，现在这个优势可以忽略不计，那么在 IP 上叠加 MPLS 就有点多此一举。
所幸的是，上帝为 MPLS 关上了一扇门，又为它打开了一扇窗。ASIC 技术的发展，背后是时代的发展。时代的发展，又使得企业对 VPN(Virtual Private Network，虚拟专用网络)等需求有了爆发性的增长。
而 MPLS 天生就是隧道协议，而且它的多层标签以及转发平面面向连接的特性，使其具有“无限”的可能性，如图11-25所示。
图11-２５ MPLS 的多层标签
MPLS 这种的“无限可能”，使得基于 MPLS 构建的 VPN 在当今得到了广泛应用。然而作为 VPN 的隧道协议，MPLS 在绝大多数场景下并不需要为一个网段构建 LSP，如图11-26所示。
图11-２６ VPN 的隧道
通过图11-26可以看到，只需要在“1.1.1.1/32”、“4.4.4.4/32”两个 Host 地址之间创建1个 MPLS Tunnel(LSP)即可。
也正是因为此，有些厂商(比如华为)的自动构建 LSP 的默认策略就是只为 Host 地址创建 LSP。当然，也有厂商(比如思科)的默认行为则是为所有 IGP 路由创建 LSP。这没有谁对谁错，只是一种观点，或者只是一种历史习惯使然(默认行为也是一种广义的“接口”，为了兼容性，当初定下的默认行为，后续可能就无法改变了)。
既然是默认行为，那就都可以改变。无论是华为还是思科，都可以修改其 LSP 的构建策略。比如华为的配置命令行是：
lsp-trigger { all | host | ip-prefix ip-prefix-name | none }
当配置路由器可以为 IGP 路由(网络地址)建立 LSP 时，可以敲如下命令行：
lsp-trigger ip-prefix ip-prefix-name
当然，无论默认行为是什么，无论提供了多少灵活的配置能力，最终路由器的 LSP 构建策略还得与实际的应用场景相匹配(大部分应用场景只须为 Host 地址创建 LSP)。
11.4.3 跨域 LSP
虽然大部分应用场景只须为 Host 地址创建 LSP，但是在跨域(跨 AS)的情形下，却不能简单直接地创建出这样的 LSP，如图11-27所示。
图11-２７ 跨域 LSP 的组网示意
图11-27中，R1 属于 AS2，R2、R3、R4 属于 AS2。eBGP 的路由通告的特点是“路由汇聚”，也就是所 R2 会先将 R3、R4 的主机地址汇聚成网络地址“4.4.4.0/24”，然后再通告给 R1。
此时，期望 R1 自动构建到达“4.4.4.4/32”的 LSP 已经不可能。因为 R1 的 FIB 中只有到达“4.4.4.0/24”的路由，它已经找不到“入口”自动为“4.4.4.4/32”构建 LSP。
那么单独为“4.4.4.4/32”手工构建1个 LSP呢？这里面也有个问题，如表11-9所示。
表11-9 路由表项的目的地址与 FEC
R1 路由表项中的目的地址 |
R1 收到的标签通告中的 FEC |
4.4.4.0/24 |
4.4.4.3/32 |
4.4.4.4/32 |
单独为“4.4.4.4/32”手工构建1个 LSP，不是不可以。但是，这个 LSP 被构建出以后，马上就会“飞”掉。因为路由器再通过目的地址查找对应的 LSP 时，默认情况是“精确匹配”，即目的地址与 FEC 要完全匹配。显然表11-9所述的情形不符合精确匹配，也就是说这个手工构建的 LSP 会变成“Liberal LSP”。
“怎么忍心怪你犯了错，是我给你自由过了火”。为了查找这个“Liberal LSP”，路由器又推出了“最长匹配”机制。华为配置“最长匹配”的命令行是：
longest-match
“最长匹配”机制确实能为“4.4.4.4/32”构建出了1个不会飞的 LSP，但是它也会引发另一个问题，如图11-28所示。
图11-２８ 最长匹配机制的问题
图11-28中，按照最长匹配原则，目的地址属于“4.4.4.0/24”网段的报文，R1 都能查找到相应的 Tunnel ID，然后走 MPLS 转发，然而 ..... 如果图11-28中的 R6、R5 不支持 MPLS(或者没有开启 MPLS)这是会出问题的。
所以在具体的应用中，是不是要通过“最长匹配”方法构建跨域 LSP，需要慎重考虑。
11.5 MPLS 小结
MPLS 的思想起源于 ATM 的标签交换，其名称在1997年才被 IETF 正是认定。
MPLS 报文是在数据链路层(2层)Header 和网络层(3层)Header 之间添加了 MPLS Header。所以 MPLS 也被称为2.5层协议。
MPLS 就是利用 MPLS Header 中的标签(Label)字段进行转发，其转发所依据的转发表称为 LFIB(Label Forwarding Information Base)。
MPLS 的转发过程可以分为：Push、Swap、Pop 等3个阶段。在 Ingress LER 处，MPLS 将 IP 报文封装成 MPLS 报文(Push)，在 Transit LSR 处，MPLS 进行标签交换转发(Swap)，在 Egress LER 处，MPLS 将 MPLS 报文解封装为 IP 报文(Pop)。
为了性能优化，MPLS 还提出了 PHP(倒数第二跳弹出)机制。
从转发面来讲，MPLS 的标签交换转发是 IP 转发的一种替代。但是从控制面来讲，MPLS 的控制协议首先得依赖 IP 的路由协议(比如 OSPF)。
在路由协议构建好各个路由器的路由表的基础上，MPLS 的控制协议才能有效的工作。MPLS 的控制协议有多种，LDP 是其中比较基础而且重要的一个协议。
LDP(包括其他控制协议)的最终目的是要构建到达 FEC 的 LSP。1条 LSP 的本质，是多个 LSR 之间的“标签接力赛”。
所以，LDP 最核心的部分是标签的分配和发布。LDP 的标签分配分为“独立标签分配控制方式”和“有序标签控制方式”。LDP 的标签发布分为“下游自主方式”和“下游按需方式”。
除了标签的分发，LDP 还设计了2种标签保留方式：保守保留方式、自由保留方式。保守保留方式的好处是节省路由器的标签空间，但是对网络拓扑变化的响应会变慢。自由保留方式则恰恰相反。
LDP 通过 FEC 的分类、标签的分发、标签的过滤(过滤掉“非下一跳”的标签映射)，以及标签的“接力匹配”，构建出一条条通往各个 FEC 的 LSP。
“欲穷千里目，更上一层楼”。个人的奋斗，离不开时代的阶梯。随着 ASIC 技术的发展，虽然转发性能与 IP 相比不再有优势，但是 MPLS 支持多层标签和转发平面面向连接的特性，使其在VPN(Virtual Private Network)、流量工程、QoS(Quality of Service)等方面得到广泛应用。
“少年子弟江湖老，雪满长安道”。与 IP、ATM相比，1997年诞生的 MPLS，确实可以称得上是“少年子弟”。但是，网络里的报文，早已是“雪满长安道”。MPLS 接过了 IP 的枪，将报文像子弹一样发射出去。那清脆的子弹声中，隐隐还回荡着 ATM 当年的那“沧海一声笑”。
谁负谁胜出 天知晓！
---------------------
