VPWSVPLS-虚拟专用网络原理介绍+报文分析+配置示例

admin 管理员组

文章数量: 887019

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将以典型场景下的 VPWS/VPLS 组网为例进行分析，以详细介绍相关内容。

• 关于PW Emulation Edge-to-Edge (PWE3)协议的基本架构，可参考2005年发布的RFC3985-Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture。
• 关于MPLS L2VPN使用PW传递Ethernet帧的相关内容，可参考2006年发布的RFC4448-Encapsulation Methods for Transport of Ethernet over MPLS Networks。
• 关于L2VPN基本架构的相关内容，可参考2006年发布的RFC4664-Framework for Layer 2 Virtual Private Networks (L2VPNs)。
• 关于L2VPN基本需求的相关内容，可参考2006年发布的RFC4665-Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs)。
• 关于MP-BGP协议的相关内容，可参考2007年发布的RFC4760-Multiprotocol Extensions for BGP-4。
• 关于MPLS L2VPN的Kompella方案/BGP方案下的基本原理，可参考2007年发布的RFC4761-VPLS Using BGP for Auto-Discovery and Signaling。
• 关于MPLS L2VPN的Martini方案/LDP方案下的基本原理，可参考2007年发布的RFC4762-VPLS using Label Distribution Protocol (LDP) Signaling。
• 关于MPLS L2VPN的Martini方案/LDP方案下的信令实现，可参考2017年发布的RFC8077-Pseudowire Setup and Maintenance Using the LDP。

其他L2VPN技术：

• 关于L2VPN中的L2F私有协议，可参考1998年发布的RFC2341-Cisco Layer Two Forwarding (Protocol) “L2F”。
• 关于L2VPN中的PPTP协议，可参考1999年发布的RFC2637-Point-to-Point Tunneling Protocol。
• 关于L2VPN中的L2TP协议，可参考1999年发布的RFC2661-Layer Two Tunneling Protocol “L2TP”。
• 关于L2VPN中的L2TPv3协议，可参考2006年发布的RFC3931-Layer Two Tunneling Protocol-Version 3。
• 关于传递帧中继、ATM等二层PDU的Martini方案/LDP方案，可参考2007年发布的RFC4906-Transport of Layer 2 Frames Over MPLS。
• 关于 PW 的跨域场景实现，可参考2011年发布的RFC6073-Segmented Pseudowire。
• 关于Kompella方案/BGP方案的发展共识，可参考2012年发布的RFC6624-Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling。
• 与上文提到MPLS L2VPN承载Ethernet帧(RFC4448)类似的，MPLS L2VPN也可承载帧中继(RFC4619)、ATM(RFC4717)、HDLC(RFC4618)和PPP(RFC4618)等Layer 2 PDU。

其他相关资料：

• 关于LDP协议原理相关内容，可参考博客MPLS/LDP原理介绍+报文分析+配置示例。
• 关于BGP协议原理相关内容，可参考博客BGPv4-原理介绍+报文分析+配置示例。
• 关于L3VPN场景相关内容的，可参考博客BGP MPLS/LDP-3层虚拟专用网络原理介绍+报文分析+配置示例。
• 关于LDP协议报文的相关参数，可参考IANA的Label Distribution Protocol (LDP) Parameters。
• 关于PWE3命名空间的相关参数，可参考IANA发布的Pseudowire Name Spaces (PWE3)。
• 关于BGP协议地址族的相关参数，可参考IANA发布的Address Family Numbers。
• 关于BGP协议子地址族的相关参数，可参考IANA发布的SAFI Parameters。
• 关于BGP-4+的扩展团体属性的相关取值，可参考IANA发布的BGP Extended Communities。

…
L2VPN还存在大量相关RFC，感兴趣者可查阅相关资料。

个人能力有限，如有疑问烦请指导学习。

目录

MPLS L2VPNs

• 目录

• 1.基础内容
• • 1.1.背景介绍
  • 1.2.相关术语-RFC4026
• 2.L2VPN的基本原理-RFC4664/RFC4665
• • 2.1.L2VPN的功能组件
  • 2.2.VPWS和VPLS
  • 2.3.CE和ISP需求
• 3.L2VPN的Kompella方案/BGP方案-RFC4761
• • 3.1.BGP方案特性
  • 3.2.控制面行为
  • • 3.2.1.BGP信令
    • 3.2.2.跨域实现
  • 3.3.转发面行为
• 4.L2VPN的Martini方案/LDP方案-RFC4762/RFC8077
• • 4.1.Martini方案信令-RFC8077
  • • 4.1.1.伪线FEC
    • 4.1.2.常用Interface Parameter Sub-TLV
    • 4.1.3.常用PW属性TLV
  • 4.2.控制面行为-RFC8077
  • • 4.2.1.Control-Word 处理动作
    • 4.2.1.PW 信令状态的协商
  • 4.3.转发面行为-RFC4448
• 5.L2VPN的方案实例
• • 5.1.Kompella方案/BGP方案
  • 5.2.BGP方案状态检查
  • 5.3.Martini方案/LDP方案
  • 5.4.LDP方案状态检查
• 更新

1.基础内容

1.1.背景介绍

VPN 基本背景技术：
虚拟专用网络：
Virtual Private Network（虚拟专用网络）是通过互联网从设备到网络的加密连接。加密连接有助于确保敏感数据的安全传输。它防止未经授权的人窃听流量，并允许用户远程进行工作。

为什么企业使用VPN：
VPN 是一种经济高效的方式，可以安全地将远程用户连接到公司网络，同时提高连接速度。有了 VPN，企业可以使用高带宽的第三方互联网接入，而不是昂贵的专用WAN（广域网）链路或远程拨号链路。

什么是安全远程访问：
安全远程访问是一种将远程用户和设备安全连接到公司网络的方法。它包括 VPN 技术，该技术对用户或设备进行身份验证，确认他们满足某些要求，然后才能远程连接到网络。

什么是VPN“隧道”：
“隧道”是 VPN 建立的加密连接，这样虚拟网络上的流量就可以安全地通过互联网发送。来自计算机或智能手机等设备的 VPN 流量在通过 VPN 隧道时会被加密。

目前常用的 VPN 技术：
IPsec（互联网协议安全，Internet protocol Security） VPN 、SSL（ 安全套接层协议层， Security Socket Layer-SSL）VPN、、VPDN（ 虚拟专用拨号网，Virtual Private Dial - up Networks）和MPLS（多协议标签交换，Multi-Protocol Label Switching）VPN 等。

IPsec VPN不是一个单独的协议，它给出了应用于 IP 层上网络数据安全的一整套体系结构。该体系结构包括认证头协议(Authentication Header，AH )、封装安全负载协议(Encapsulating Security Payload，ESP)、密钥管理协议( Internet Key Exchange，IKE）和用于网络认证及加密的一些算法等。IPsec VPN 的搭建不需要电信运营商的参与，不能穿越通常的 NAT、防火墙。

SSL VPN是一种基于 WEB 应用的安全协议，也通常和 HTTPs 结合使用。SSL VPN 通过在远程接入用户和 SSL VPN 网关之间建立 SSL 连接、SSL VPN网关对用户进行身份认证等机制对用户数据流量进行保护。SSL VPN和IPsec VPN在架构上一个为浏览器 / 服务器端 (B/S) 应用构架，另一个为客户端 / 服务器端 (C/S) 应用构架。

VPDN是在中国宽带互联网基础上开放的基于拨号方式的虚拟专有网络业务。它向用户提供采用 PSTN、ISDN、XDSL、电缆或无线以拨号方式接入中国宽带互联网。VPDN隧道协议有点到点隧道协议（PPTP）、第二层转发协议（L2F）、第二层隧道协议（L2TP）等几种。

MPLS VPN是电信运营商大量使用的 VPN 技术，具有较高的灵活性和可扩展性，可以实现点到点，点到多点和任意接入点之间互访的全网状结构，满足用户不同的通信需求。MPLS VPN 利用标签交换，一个标签对应一个用户数据流的方式来区分不同的用户，从而实现用户间数据的隔离的 VPN 网络，MPLS VPN 网络主要由 CE 路由器、PE 路由器和 P 路由器 3 部分组成。
VPN 技术分类如上图所示。

1.2.相关术语-RFC4026

2005 年发布的《RFC4026-Provider Provisioned Virtual Private Network (VPN) Terminology》中定义了如下概念。

VPLS：Virtual Private LAN Service，虚拟专用局域网服务。VPLS 是一种点到多点的 L2VPN，可模拟传统局域网的全部功能。 VPLS 可以通过 PSN（packet switched network，分组交换网络）互连多个局域网网段，使其表现为单个局域网。在 VPLS 中，运营商网络模拟学习网桥，并根据 MAC 地址或 VLAN 标记做出转发决策。

某些情况下，VPLS 技术又称为 VPSN（Virtual Private Switched Network，虚拟私有交换网络）。
VE：VPLS Edge，VPLS边缘节点。这一角色通常指的是VPLS PE或者u-PE。

VPWS：Virtual Private Wire Service，虚拟专线网络服务。VPWS 是一种点到点的 L2VPN。链路同样通过 PSN（packet switched network，分组交换网络）建立为逻辑链路。 客户网络中的 CE 通过 AC 链路连接到运营商的 PE 设备。

某些情况下，VPWS 技术又称为 VLLS（Virtual Leased Line Service，虚拟租用线路服务）。VLLS 被用于一个现在已经过时的文档中。

SP：Service Providers，网络服务供应商，有时也称 ISP。ISP 提供的 P、CE 和 PE 构成了公网或骨干网。
P：Provider，运营商设备。SP 网络中未连接到客户边缘设备的路由器。
CE：Custom Edge，用户边缘设备。直接与服务运营商相连的用户边缘设备。
PE：Provider Edge，运营商边缘设备。服务运营商网络上的边缘设备，与CE相连，主要负责VPN业务的接入。

PE又可分为UPE（User facing-Provider Edge/User Provider Edge）、SPE（Superstratum PE or Service Provider-end PE）和NPE（Network Provider Edge）：
UPE：是指靠近用户侧的PE设备，主要作为用户接入VPN的汇聚设备。
SPE：连结UPE并位于MPLS网络内部的设备。
NPE：是指网络核心PE设备，处于网络的核心域边缘。
自动换行
这三种PE角色的出现主要是为了适应当今网络层次化需求而形成的角色细分。在城域网的核心层、汇聚层和接入层架构划分中，PE角色依次被分为了NPE、SPE和UPE。

AC：Attachment Circuit，接入电路，指连接 CE 与 PE 的链路，对应的接口可以是实际的物理接口，也可以是虚拟接口。

CPE：Customer Premise Equipment，客户前置设备。CPE 通常是一个功能有限的低成本盒子。它有两个目的：为客户提供可插入的端口，并使运营商能够监视与客户站点的连接。 CPE 设备不一定是具有 CE 功能的设备，但它是运行商网络的一部分。
目前常用的 CPE 设备是一种接收移动信号并以无线 WIFI 信号转发出来的移动信号接入设备。 一台典型的 CPE 是一台功能齐全的无线路由器，能够为终端设备提供宽带连接和无线网络。
Site：简单来说是指一组具有不需要使用骨干网的相互 IP 互连系统。一台 CE 设备总是可以认为成一个站点，同时站点可能有多个 VPN。

VRFs（VPN Routing and Forwarding tables）：虚拟路由转发表实例，在 HW 中称为 VPN 实例。在设备单独分配一块处理区域用于单独模拟一台物理设备，处于VRF实例中的接口或进程称为私网接口私网进程。
RD（Route-Distinguisher）：VRF 实例中本地唯一的 ID，用于 VRF 实例间的相互区分。在 L3VPN 中也可和私网前缀组成 VPNv4 路由进行路由区分。8字节。
RT（Route-Target）：VRF 实例中的路由收发标识。可分为入方向 RT 和出方向 RT。只有相匹配了对应 RT 值才可接收相应路由。

RFC4360 中定义了 BGP Extended Communities Attribute，这种 Type Code 16 的 Attribute 是一种可选过渡的属性。这一属性又可分为多种 Extended Community Sub-Types。
自动换行
RFC4360 中定义每一种 Extended Community 有 8 字节：其中 Type 字段分为 Type high 和 Type low：
Type high：1字节，主要用于描述 Extended Community 是 Regular 类型还是 Extended 类型。RFC4360中将这一字节的高位bit进行了定义，I-bit (IANA-bit 用于描述是否支持 First Come First Serve) 和 T-bit (Transitive-bit 用于描述是否支持在AS内传递。)。
例如在 RFC7153 中有区分：
0x00 为 Transitive Two-Octet AS-Specific Extended Community；
0x01 为 Transitive IPv4-Address-Specific Extended Community；
0x02 为 Transitive Four-Octet AS-Specific Extended Community；
0x03 为 Transitive Opaque Extended Community；
0x06 为 EVPN Extended Community；
等等 Type high 不在进行介绍，感兴趣者可自行查阅资料。
Type low：1字节，主要用于描述每种 Extended Community 的具体类型。
自动换行
这里提到的 Route-Target 属性便是其中一种 Extended Community Sub-Types。

• 0x0002 定义于 RFC4360 表示 Transitive Two-Octet AS-Specific 的 Route-Target；
• 0x0102 定义于 RFC4360 表示 Transitive IPv4-Address-Specific 的 Route-Target；
• 0x0202 定义于 RFC5668 表示 Transitive Four-octet AS 的 Route-Target；
• 0x0002 定义于 RFC5701 和 RFC7153 表示 IPv6-Address-Specific Extended Community 下的 Route-Target，其与上述所描述的 Extended Community 区别在于长度为 20 字节。

自动换行
这里几种 Route-Target 属性的区别是 Value 字段的组成格式不同，通常采用 0x0002 格式下的 Route-Target。这里不在进行进一步介绍，感兴趣者可查阅相关资料。

VC：Virtual Channel，虚拟通道。在隧道内传输并以 VCID 进行标识的通道。
VC Label：MPLS IP 网络中用于标识 VPN 的内层 MPLS Label。而 MPLS 的外层标签用于标识所属的隧道或 LSP。
PW：Pseudo Wire，伪线。IETF (The Internet Engineering Task Force，互联网工程任务组) 中的 PW Emulation Edge-to-Edge (PWE3) 工作组指定 PW 用于提供点到点的 L2VPN 服务。类似的，PW 也通过 PSN（packet switched network，分组交换网络）建立为逻辑链路。
VSI：Virtual Switch Instance，虚拟交换实例。将接入电路映射到各条虚拟链路上。每个 VSI 提供单独的 VPLS 服务。
VE：VPLS edge，VPLS域边缘设备。

除上述概念外，在光网络中还有：
UNI：User Network Interface，用户网络接口。通常指用户设备（包括IP路由器、ATM交换机、SDH交换机等）和智能光网络之间的接口。
NNI：Network to Network Interface，网络到网络接口。通常指网络节点互联的接口，它包含了传输网络的两种基本设备，即传输设备和网络节点设备。NNI 就是设备之间的接口协议，根据设备不同，业务类型不同，NNI 接口的具体内容不同。

点击此处回到目录

2.L2VPN的基本原理-RFC4664/RFC4665

在2006年发布的《RFC4664-Framework for Layer 2 Virtual Private Networks (L2VPNs)》中定义了 L2VPN 的基本组织架构。并且，在《RFC4665-Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks》中定义了 L2VPN 的组件需求。

2.1.L2VPN的功能组件

Attachment Circuits：
L2VPN 中，CE 设备通过某种电路或虚拟电路连接到 PE 设备称为 Attachment Circuits 连接电路。AC 可以是 Frame Relay DLCI、ATM VPI/VCI、以太口、VLAN、物理接口的 PPP 连接、L2TP 隧道的 PPP 会话和 MPLS LSP。任何给定的数据帧都将在 AC 上从 CE 转发到 PE，然后在另一个 AC 上从 PE 转发到 CE。与之对应的可称为“入口 AC”和“出口 AC”。而这一概念只表示帧在该 AC 上的传输方向。

Pseudowires：
PW 伪线是两个 PE 设备之间的关系。AC 用于 CE 到 PE 的传输，而 PW 用于在两个 PE 之间的传输。PW 可以是点对点、多点对点或点对多点。但 PW 建立的点对点传输被视为双向传输，而多点到点以及点到多点被视为单向传输。
此外，传输给定数据帧的 PW 关联多个 AC 的场景下，如果 AC 使用不同的传输介质，则称为 heterogeneous transport 异质传输。在异质传输的情况下，PW 应当完成某种封装机制以便完成透明传输，并且应当提前协商多个站点 AC 的 MTU。反之则称为 homogeneous transport 同质传输。

Forwarders：
PE 设备在转发来自本站点 AC 的数据帧时可以基于入口 AC、二层帧头和维护的某些静态/动态转发信息决定将数据帧转发至哪一个站点的 PE。
PE 设备在接受来自对端站点 PW 的数据帧时可以基于入口 PW、二层帧头和维护的某些静态/动态转发信息决定将数据帧转发至哪一个 AC。

Tunnels：
PW 在站点 PE 之间（PE1<—>PE2）的隧道中传输。通常可以假设在单个隧道中可以携带任意数量的 PW；唯一的要求是 PW 全部终止于 PE2。甚至隧道可以是多点到点隧道，而不要求隧道中的所有 PW 都起源于 PE1。我们也不要求同一对 PE 之间的所有 PW 都在同一隧道中传输。重点在于当数据帧通过隧道到达 PE2 时，PE2 将能够将其与特定的 PW 相关联。
PE<—>PE 隧道可以使用诸如 MPLS LSP、L2TP 隧道、IPsec 隧道、MPLS-in-IP 等各种不同的隧道技术，但需要需要将特定 PW 与特定隧道进行相应关联。

Encapsulation：
当 PW 承载 L2VPN 数据时应尽可能使用 IETF (The Internet Engineering Task Force，互联网工程任务组) 中的 PWE3 工作组定义的标准伪线封装格式和技术。

Pseudowire Signaling：
PW 信令应当执行如下功能：

• 隧道协议必须为每个 PW 分配一个 demultiplexor 解复用器值，并对于给定隧道必须唯一或者在出口 PE 处必须唯一。
• 信令协议必须包含足够的信息，以使出口 PE 能够选择要绑定正确的 PW Forwarder。
• 如果特定 PW 必须模拟特定 2 层技术的信令，则 PW 信令必须提供必要的 PW 模拟。
• 及时反馈并响应 AC 状态的变化。
• 如果 PW 的某些特性需协商一致，则信令必须允许必要的交互。

PW 的点到点信令和点到多点信令某种程度是共通的，因为出口 PE 不一定需要知道 PW 是多点对点还是点对点。
除了上述介绍外，PW 还应允许跨域场景的存在。这就要求 PW 的信令协议必须能够跨越网络边界。跨域 PE 必须是可寻址且可相互路由。有时还应允许每个 PW 端点对另一个端点进行身份验证。

Service Quality：
服务质量通常指的是通过 QOS 的方式根据与客户签订的 SLA（Service Level Agreement，服务级别协定协议）要求，对来自客户的流量进行优先级排序、监管和调整，以实现优先级、吞吐量、延迟、抖动等特定目标。

并且 L2VPN 基础架构应当允许诸如重路由的故障检测和恢复机制。

2.2.VPWS和VPLS

VPWS：
在 VPWS 中，每个 CE 设备都带有一组点对点 Virtual Circuits。从逻辑上而言，CE 通过 Virtual Circuits 连接的另一端是另一个 CE 设备。从一个 CE 设备转发到另一个 CE 设备不受帧内容的影响，但完全由传输帧的 Virtual Circuits 决定。因此，PE 充当 Virtual Circuits 开关。这种类型的 L2VPN 长期以来一直可以通过 ATM、帧中继和 MPLS/IP 骨干网使用。

而 PE 设备用于提供逻辑互连，使得一对 CE 设备看起来通过单条二层逻辑电路连接。PE 则需将对应的 AC 映射到 SP 网络中的隧道上。这些隧道可以特定用于VPWS，也可以在多个服务之间共享。VPWS 适用于以太网、ATM、帧中继等多种服务。

VPLS：
在 VPLS 中，每个 CE 设备都有一个或多个 LAN 接口通向“虚拟骨干网”。 当且仅当两个 CE 是同一 VPLS 实例时，它们才会连接到同一虚拟主干网。从逻辑上而言，虚拟主干网是一组 PE 网桥及其所在的模拟局域网。转发决策的 PE 以网桥的方式基于 SMAC 源地址学习。传输时，接收 CE 二层帧的 PE 通过检查 DMAC 目的地址确定转发行为。

类似的 VPLS 模型下的 PE 设备用于提供逻辑互连，使得一对 CE 设备看起来通过单个 LAN 连接。VPLS 可以包含单个 VLAN 或多个 VLAN。在 VPLS 中，客户站点从 SP 接收 2 层服务。PE 通过 AC 连接到一个或多个 CE，并根据二层报头中的信息 (如 MAC 目标地址) 对用户数据报文进行转发。

对于每个 VPLS，都有一个模拟 LAN 实例。模拟 LAN 由通过 PW 连接的 VPLS 转发器模块 (每个 VPLS 服务实例的每个 PE 一个) 组成，其中 PW 可能通过路由主干网通过 PSN (packet switched network，分组交换网络) 隧道传输。VSI 是一个逻辑实体，其中包含 VPLS forwarder 模块和与 VPLS 服务实例相关的网桥模块的一部分 。每个 PE 设备负责根据相应 VSI 的转发信息库将客户流量正确转发到相应的目的地。

VPLS 与 VPWS 类似，在完成转发时不考虑 Layer3 头。 VPLS 与 VPWS 的不同之处在于：

• VPLS 允许 PE 使用帧的 L2 标头中的 MAC 信息来确定如何转发帧。
• VPLS 允许使用单个 CE/PE 连接将帧传输到多个远程 CE。在这方面，VPLS 比VPWS 更像 L3VPN。

自动换行
L2VPN 协议不应干扰客户 2 层网络的现有 2 层协议和标准。并且需要说明的是 VPLS 跟和真正的 LAN 之间仍存在显著的区别。比如 VPLS 的硬件可靠性在广播上不如真正的以太网。并且在转发数据时可能导致多包和乱序。而对于 802.3x Pause frames 将在 PE 终结而非透传至对端 PE 节点。

2.3.CE和ISP需求

客户需求：

服务独立性：L2VPN 服务必须能够跨越多个 AS 和 SP 网络，而忽视其 underlay 的存在。从客户的角度来看，它仍然能够作为一个单一的、同构的 L2VPN 来运行和显示。
L3协议支持：除 IPLS 外，L2VPN 服务应正确处理客户的第 3 层流量。例如透明传输各种协议报文。
QOS和SLA需求：L2VPN 服务应支持对延迟和丢失敏感的流量。客户应用程序的 QOS 服务体验不应受到同一 L2VPN 不同站点使用的接入网络技术的影响。并且应提供诸如 SNMP MIB 等标准接口来监控 L2VPN 服务的使用情况，以便检测服务质量。
安全需求：首先 L2VPN 应当以客户 VLAN ID 等方式作为服务分隔符，进行流量和转发信息库的隔离。此外，L2VPN 还应当可以根据客户要求在 CE 和 PE 之间进行基于 MAC 或 VLAN 的数据过滤功能。并且，L2VPN 解决方案可以提供增值安全服务，例如客户数据包的加密和身份验证，证书管理和类似服务。但不得影响客户在第 3 层和更高层采用的安全机制。此外，802.10b 和 802.1AE 等 2 层安全机制可能会被禁止使用。
网络访问需求：L2VPN 解决方案应支持多种物理和链路层接入技术。例如 PSTN、ISDN、xDSL、电缆调制解调器、租用线路、以太网、以太网VLAN、ATM、帧中继、无线本地环路、移动无线接入等。
基于冗余的考虑，L2VPN 还应当支持同一站点同一台 CE 的多归，不同运营商 PE 网络的多归，以及同一站点不同 CE 间的 Backdoor Links 后门链路和不同运营商 PE 网络的后门链路。
流量类型需求：遵守入口策略、安全策略和同一 QOS 策略的转发单播以及 BUM 流量。并且在转发时还需考虑 MTU 的影响。
此外，如果客户自身的 2 层网络通过 VLAN ID 自身隔离，那么 L2VPN 在传输客户流量时也必须考虑 VLAN 翻译的情况并避免对 MSTP 等协议产生影响。
2层协议控制：L2VPN 解决方案应透明传输客户使用的 STP 等 2 层控制协议，以便避免环路的产生。

运营商需求：

规模性和可扩展性需求：L2VPN 应该是可支持大规模网络并且是扩展的，以支持每个服务运营商网络的大量 VPN。并且每个 VPN 可以具有广泛数量的站点接口，具体取决于客户组织的规模和/或结构。
唯一性需求： 理想情况下，L2VPN 标识符应该是全局唯一的，以支持 L2VPN 跨越多个 SP。必须至少在所有互连的 SP 网络集中唯一标识 SP 域。每个 L2VPN 的标识符应该是唯一的，至少在每个 SP 的网络中唯一以便用于自动发现、管理（例如，警报和服务关联、故障排除、性能统计信息收集）和信令传递等方面。
此外，L2VPN 方案应当使得域中的每个设备都应该能够确定哪些其他设备属于同一个 L2VPN。 这种成员身份发现方案必须防止未经授权的访问，并允许对源进行身份验证。L2VPN 信息的分发应仅限于该 L2VPN 中涉及的设备。同时最大程度地减少 SP 维护的操作信息量。
QOS和SLA需求：SP 至少可以控制 PE 和 P 设备中的资源配置和参数配置，在某些情况下还可以控制 CE 设备中的资源配置。
安全需求：L2VPN 方案必须保护 SP 网络免受畸形或恶意构建流量的影响。这些流量包括但不限于重复或无效的 2 层地址、客户端环路、短/长数据包、欺骗性管理数据包、欺骗性 VLAN 标记、大流量。除非获得特别授权，否则不得从任何 L2VPN 访问 SP 网络设备。如果检测到入侵，SP 网络中的设备应提供一些向 SP 报告入侵尝试的方法。
跨域需求：所有 SP 需求，例如流量和转发信息隔离、SLS、管理、安全性、配置等，必须支持跨相邻 AS 实现。

• 必须描述 SP 间网络接口、封装方法、路由协议和所有适用参数。
• 必须提供跨多个 AS 和/或 SP 的 L2VPN 服务的详细信息。
• 必须支持在存在多个 AS 或 SP 的情况下将操作参数正确传播到 L2VPN 的所有元素。
• 必须采用在不同 AS 之间共享操作参数的机制。
• 应支持正确选择来自不同 AS 的操作参数的策略。同样，L2VPN 解决方案应支持选择要传播到不同AS的信息的策略。

点击此处回到目录

3.L2VPN的Kompella方案/BGP方案-RFC4761

这里以 VPLS 的 Kompella 方案/ BGP 方案为例进行相关介绍。关于此方案的基本原理可参考 2007 年发布的《RFC4761-VPLS Using BGP for Auto-Discovery and Signaling》。

pwsignal bgp 用于指定VPLS创建PW采用的信令方式为bgp。

3.1.BGP方案特性

自动发现：
在此方案中，VPLS 的自动发现通常是指每个 PE 通过 BGP 发现哪些其他 PE 是与自身同属于一个 VPLS 域的过程。这允许每个 PE 的配置仅包含建立的 VPLS 实例的标识，而不包含所有其他 PE 的标识。同时当拓扑变化时，仅涉及变化 PE 的改动其他 PE 进行自动发现。

自动发现的主要是通过 BGP 的 extended community 扩展团体属性来实现的。属于同一个 VPLS 域的 PE 会通告以 Route Target 标识的 Network Layer Reacheable Informations。其他 PE 接收到该信息后，与本地维护 VPLS 域的 Route Target 比对来确认是否与该 PE 同属于一个 VPLS 域。当 PE 撤销具有该 Route Target 的 Network Layer Reacheable Informations 时，即说明退出该 VPLS 域。

pwsignal bgp 用于定义 pw 信令传递方式为 bgp。

信令维护：
一旦发现完成，VPLS 的每对 PE 将开始进行建立或拆除 PW。demultiplexor 解复用器用于标识数据包所属的 VPLS 域，同时用于标识所属 PE 以便完成 MAC 学习。
在 MPLS/LDP 隧道中，承担这一角色的是 Label。

信令标识：
为了实现这一点引入了“Label Blocks” (LB，标签块) 的概念。
标签块由 label base (LB，基本标签) 和 VPLS Edge block size (VBS，VE 块大小) 组成，是一组连续的标签。其基本原理如下：

• 所有 PE 都会在给定 VPLS 中分配唯一的 VE ID。
• 除多归场景外，VPLS 域中的 VE ID 应当是唯一的。
• 所有 PE 并将其 VE ID 和 LB 通告给其他 PE。
• 接收 PE 通过 VE ID 和 LB 推断用于该 PE 的标签。同时确定该 PE 的 demultiplexor 解复用器。
• 发送 LB 时还允许发送 VE block offset（VBO，VE 块偏离）。因此 LB 是 <Label Base，VBO，VBS> 这样的集合，或者说是 {LB+VBO, LB+VBO+1, …,LB+VBO+VBS-1}。

//RFC4761中定义了上图所示BGP传递LB时的格式信息。其 Address Family Identifier=25 标识L2VPN，同时 Subsequent Address Family Identifier=65 标识VPLS BGP NLRI。

PW分配逻辑：
在给定 VPLS 域中有 PE-A，其参数为：
< VE-IDa ，label base LBa，VBOa，VBSa>。

如果 VBOa <= VE-IDb <= VBOa+VBSa，则 PE-B 可作为 PE-A 的远端 VE 节点。同时 PE-B 到 PE-A 的 demultiplexor label 解复用器标签取 label base LBa+VE-IDb-VBOa。
或者说 PE-A 为 PE-B 分配了基于自身 label base LB 的对应标签。

PW的信令控制信息：
PW 的信令控制信息主要定义了关于 PW 的特定属性。
Layer2 Info Extended Community 是一种 Generic Transitive Extended Community，因此其第一个字节为 0x80。同属于此种扩展团体属性的还有 OSPF Domain Identifier（0x8005）等。

同时，RFC4761中也定义了 1 字节的 Control Flags。其中 C-bit 置 1 时表示必须发送 VPLS 包给该 PE；S-bit 置 1 时表示必须使用帧的顺序传送。

3.2.控制面行为

3.2.1.BGP信令

上文提到，当以 BGP 作为 pw 建立的信令时，BGP Speaker 将携带一个 MP_NLRI 信息。这里进行详细介绍。

[AFI 25 = L2VPN，SAFI 65 = VPLS]的NLRI：Length：2 字节，标识 NLRI 剩余字段的长度。
Route Distinguisher：8 字节，标识 VPLS 域。

当指定信令为bgp方式后，route-distinguisher 用于指定RD。

VE ID：2 字节，VE 节点或者 VPLS 节点标识。

site 用于指定 VE ID。VE ID 应当保证在整个 VPLS 域内唯一。

VE Block offset：2 字节，标签块偏移量。

site 1000 default-offset 用于指定 VE Block offset。

VE Block Size：2 字节，标签块大小。

bgp-vpn label-block-size 用来修改BGP方式L2VPN申请的标签块大小。
site range 用于指定VSI的大小个数。

Label Base：3 字节，起始标签块。

display mpls label all summary 可以看到系统默认分配的 label 情况。
display vsi verbose 可看到远端和本地分配的 label base。
自动换行
BGP传递VPLS NLRI的报文实例。
正如前文《RFC4761-VPLS Using BGP for Auto-Discovery and Signaling的3.2.3. PW Setup and Teardown》提到如果需要成功建立 pw，则 VPLS 实例应满足：
对端 V B O ≤ 本地 V E I D ≤ 对端 V B S + 对端 V B O 对端 VBO ≤ 本地VEID ≤对端 VBS + 对端 VBO 对端VBO≤本地VEID≤对端VBS+对端VBO
同时本地为远端PE分配的标签原则为：
对端 L B + 本地 V E I D − 对端 V B O 对端LB + 本地VEID - 对端VBO 对端LB+本地VEID−对端VBO

VPLS NLRI的扩展团体属性 Layer2 Info Extended Community：
Extended community type：封装类型固定为 0x800a 用于表示 Layer2 Info 信息。
Encaps Type：封装类型固定为 0x13 标识 VPLS。

encapsulation rfc4761-compatible 用于配置BGP VPLS报文封装类型遵循相关标准，将参数设置为 0x13。

Control Flags：1 字节，控制字。
Layer-2 MTU：2 字节，VPLS 实例/AC MTU。

mtu用于设置VSI的MTU。

Reserved：2 字节，保留字段。

VPLS NLRI的Layer2 Info Extended Community报文实例。
同时，RFC4761中也定义了 1 字节的 Control Flags。其中 C-bit 置 1 时表示必须发送 VPLS 包给该 PE；S-bit 置 1 时表示必须使用帧的顺序传送。

当 BGP Peer 受到对应 RT + VPLS Edge 的路由信息时，可知 BGP Speaker 同为 VPLS 自动发现的成员。随后依照所携带的信息进行 PW 建立和拆除。

3.2.2.跨域实现

关于Kompella方案/BGP方案下的跨域需求，此处仅进行原理介绍。详情请查看相关资料。

VPLS 的跨域主要需要解决两个问题：

1. 跨 AS 的信令传递方式。
2. 提供不同 AS 间 PE 节点的隧道建立方式。

在 RFC4761 中主要提供了 3 种方案，在此仅进行原理的简单介绍。

Method (a)：VPLS-to-VPLS Connections
类似于 L3VPN 的 Option A 方案，这里提供的 Method (a) 原理在于各自 ASBR 节点互相将对端 ASBR 视为自己的 CE 节点。

这种方式实现上较为简单但存在诸多问题。
1@：遍历此链路的每个 VPLS 都有一个单独的 VLAN 子接口。因此工作时需要针对每个子接口进行 PE 操作（发现、信令、MAC 地址学习、泛洪、封装等）。由此给 ASBR1 带来了巨大的负担，而限制了跨域 VPLS 的数量。
2@：通常一对 AS 之间会有多个连接，以实现冗余。在这种情况下，必须在 ASBR 之间运行生成树协议等方式来在 VPLS 间构建无环路拓扑。

Method (b)：EBGP Redistribution
类似于普通 L3VPN 的跨域 OptionB 场景，本方案需要有如下 BGP 对等体关系：
在此示例中，控制面由 PE1 发送携带 Label Blocks 标签块并以 PE1 自身作为下一跳的 VPLS NLRI 发送给 ASBR1。ASBR1 接收到后将携带更新的 Label Blocks 标签块并以 ASBR1 自身作为下一跳的 VPLS NLRI 发送给 ASBR2。ASBR2 接收到后将携带更新的 Label Blocks 标签块并以 ASBR2 自身作为下一跳的 VPLS NLRI 发送给 PE2。

而转发时仅涉及标签的 SWAP，而且不要求 AS 间使用以太连接而仅支持 MPLS 即可。这种方式下 ASBR 的数据面要求比 Method (a) 简单得多，而 AS 间的无环路 VPLS 拓扑的构建通过 BGP 的路由决策来完成。

此方案下流量转发的数据面 Label1 由 ASBR1 的 BGP 分配，Label2 由上游公网 MPLS/LDP 分配，Label1s 由 ASBR2 的 BGP 分配，Label1ss 由 PE2 的 BGP 分配，Label2s 由上游公网 MPLS/LDP 分配。

Method (c)：Multi-Hop EBGP Redistribution
类似于普通 L3VPN 的跨域 OptionC 场景，本方案的 AS1 中的 PE1 和 AS2 中的 PE2 需要建立多跳的 eBGP 对等体关系，并同时建立 PE-to-PE 的公网 LSP。

此方案下，ASBR 只需在控制面设置 PE-to-PE 隧道 LSP，并在数据面进行标注操作即可。并且 AS 间的无环路 VPLS 拓扑的构建通过 BGP 的路由决策来完成。因此，这种方法比 Method (a) 更具可扩展性。

此方案下流量转发的数据面 Label2 由上游公网 MPLS/LDP 分配，Label1 由 PE2 的 BGP 分配。

3.3.转发面行为

VPLS 的数据面主要涉及如下几个方面：
Encapsulation：封装来自 CE 的数据，以便在 PE 上进行传输。
MAC Address Learning：正如交换机学习 MAC 地址一样，VE 节点也必须将 MAC 地址与其到达的逻辑端口进行关联。由此形成 FIB (Forwarding Information Base，转发信息库)。同时也应当有某种机制来抑制 MAC 漂移。
Aging：与交换机类似，VPLS PE 应该具有老化机制来删除与逻辑端口关联的 MAC 地址。
Flooding：当受到未知单播报文时，应当将其转发给所有其他端口。
Broadcast and Multicast：广播报文应以泛洪方式进行转发。组播报文以泛洪方式转发或者转发至特定组 PE 节点。
Split Horizon：同一个站点的 PE 设备不得将 BUM 流转发给其他站点的 PE 设备。
Qualified and Unqualified Learning：仅学习 MAC 地址的学习行为称为 “Unqualified Learning”；学习 MAC + vlan 的学习行为称为 “Qualified Learning”。
这两种学习方式区别在于想要将数据包在单个广播域内进行泛洪还是 vlan 域内进行泛洪。
Class of Service：为了实现差分服务可以选择将 VLAN 标记中的 802.1p 映射到 PW 或隧道 Label 中的适当 EXP 位设置。

点击此处回到目录

4.L2VPN的Martini方案/LDP方案-RFC4762/RFC8077

这里以 VPLS 的 Martini 方案/ LDP 方案为例进行相关介绍。在 2007 年发布的《RFC4762-Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling》中主要介绍了 VPLS 的 Martini 方案/ LDP 方案下控制面行为和转发面行为。
而在 2017 年发布替代 RFC4447 的《RFC8077-Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)》中主要介绍了 LDP 作为控制面所使用的各种 TLV 字段。

4.1.Martini方案信令-RFC8077

在 2017 年发布替代 RFC4447 的《RFC8077-Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)》中定义了几种新的 LDP TLV，来标识 PW 伪线及其变化。并以(内层) Label 作为 demultiplexor 解复用器标识。

pwsignal bgp 用于指定VPLS创建PW采用的信令方式为ldp。

4.1.1.伪线FEC

在 RFC8077 中定义了 2 种新的 FEC(Forwarding Equivalence Class，转发等价类)，作为控制面用于传递 PW 信息。

FEC Type code 0x80=PWid FEC：RFC8077
C-bit：1-bit，控制字 bit。当置位 1 时表示在 PW 上使用控制字 bit。

control-word 用于在PW模板中使能控制字功能。此外，PW的control-word属性也可以通过mpls l2vc命令行指定。默认情况，系统没有使能control-word功能。
在《RFC4385-PWE3 Control Word for Use over an MPLS PSN》中主要定义两种 4 字节的control-word：PW MPLS Control Word (PWMCW) 和 PW Associated Channel Header (PWACH)。control-word功能主要用于实现报文排序，携带二层帧头控制信息，填充报文防止报文过短导致Ethernet无法承载等功能。
PWMCW 用于携带 RFC3985 中定义的报文转发序列号，PWACH 用于关联通道。PWMCW 或 PWACH 必须紧跟 MPLS 标签堆栈的底部。

PW type：15-bit，PW 承载类型。如前文介绍，PW 可以用于承载包括帧中继(RFC4619)、ATM(RFC4717)、HDLC(RFC4618) 和 PPP(RFC4618) 等多种 Layer 2 PDU。此处用于表示所承载协议类型。

例如，当 PW type = 0x0004 时表示承载 Ethernet Tagged Mode；当 PW type = 0x0005 时表示承载 Ethernet。
这两种与前文提到的 Qualified and Unqualified Learning，以及 AC 接口的 tagged and rawed 模式类似。但 tagged and rawed 仅用于表示pw承载数据时的封装。
encapsulation 用来配置 VPLS 的封装类型，默认封装类型为 Ethernet Tagged mode/VLAN mode。
mac-learn-style 配置mac学习方式。MAC地址学习方式是unqualify。

PW info length：不定长，以字节为单位描述的 PW 长度。实际指 PW ID 字段以及 Interface Parameter Sub-TLV 字段长度。如果此值为 0，则它使用 Group ID 引用所有 PW，并且不存在 PW ID，也没有任何接口参数子 TLV。
Group ID：4字节，用于在 PW 空间中创建一组 PW。
PW ID：4字节，非 0 的 PW 标识。与 PW type 一起标识特定的 PW，并且 PW 两端的 PW ID 和 PW type 必须相同。

vsi-id 用于指定 VPLS 实例的 PW ID。
mpls l2vc 用于指定 VPWS 实例的 PW ID。

Interface Parameter Sub-TLV：可变长，接口参数 Sub-TLV。主要指 AC 参数信息。

例如，当 Interface Parameter Sub-TLV type = 0x01(RFC8077) 时表示 AC Interface MTU；当 Interface Parameter Sub-TLV type = 0x0x0C(RFC5085) 时表示 VCCV parameter。
由于 Interface Parameter Sub-TLV 是 FEC 的一部分，因此一旦 AC 接口变化可能改变 PW 状态。

在 RFC3985 中关于 PW 架构说明中有提到，PW 可以认为是连接了两个“forwarder”。并且要求 forwarder 能够通过 Attachment ID 完成相互识别。FEC Type code 0x80=PWid FEC 主要通过 PW ID 字段来实现这一效果。

同时需要说明的是，在 2014 年发布的《RFC7358-Label Advertisement Discipline for LDP FEC》中定义 FEC Type code 0x80=PWid FEC 必须以 Downstream Unsolicited(DU) 方式进行 FEC Label 通告，以 liberal 方式进行标签保留。

FEC Type code 0x81=Generalized PWid FEC：RFC8077
AGI：Attachment Group Identifier 用户组标识。通常以 VPN-ID/RD 等形式出现。
AII：Attachment Individual Identifier 用户个体标识。是一种可变长字段的标识。

在 RFC3985 中关于 PW 架构说明中有提到，PW 可以认为是连接了两个“forwarder”。并且要求 forwarder 能够通过 Attachment ID 完成相互识别。同时要求 PE 上的 Attachment ID 应当唯一。那么，我们可以通过<PE router IP address, Attachment ID>来标识。

假如，我们将一组 forwarder 视为一个特定组，其中 PW 只能在组的成员中建立。在这种情况下，可以将 forwarder 方便地识别为相对于组的转发器，Attachment ID 可以由 AGI 和 AII 组成。

同时由于 PW 是双向建立的路径，而 LSP 仅是单向转发。那么对于属于同一个 AGI 的 PE1 到 PE2 的 PW 路径可以表示为：

< P E 1 , < A G I , A I I 1 > , P E 2 , < A G I , A I I 2 > > . <PE1, <AGI, AII1>, PE2, <AGI, AII2>>. <PE1,<AGI,AII1>,PE2,<AGI,AII2>>.

相应的 PE2 到 PE1 的 PW 路径可以表示为：

< P E 2 , < A G I , A I I 2 > , P E 1 , < A G I , A I I 1 > > . <PE2, <AGI, AII2>, PE1, <AGI, AII1>>. <PE2,<AGI,AII2>,PE1,<AGI,AII1>>.

对于需要建立 PW 的两个 PE，可以要求其具有相同的 AGI，不同的 AII。并可以根据转发路径，区分 Source AII 和 Target AII。对 Source Attachment ID 和 Target Attachment ID 的解释是 PE 的本身问题，但使用 FEC Type code 0x81=Generalized PWid FEC 的每个应用程序和预配模型都必须指定执行此关联的规则。

关于 AGI 和 AII 的描述与使用，在 RFC4667、RFC5003 和 RFC6074 等文档中有进一步说明介绍。

同时需要说明的是，在 2014 年发布的《RFC7358-Label Advertisement Discipline for LDP FEC》中定义 FEC Type code 0x81=Generalized PWid FEC 必须以 Downstream Unsolicited(DU) 方式进行 FEC Label 通告，以 liberal 方式进行标签保留。

除上文介绍的 FEC Type code 0x80 和 0x81 两种类型外，RFC8104 还定义用于多归保护场景的 Protection FEC，RFC8338 还定义了 P2MP场景下的 PW FEC。感兴趣者可查阅相关资料。

点击此处回到目录

4.1.2.常用Interface Parameter Sub-TLV

Interface Parameter Sub-TLV：RFC4446/RFC8077
Interface Parameter Sub-TLV 采用 TLV 格式进行定义。
Sub-TLV Type：1字节，用于标识 Interface Parameter Sub-TLV 类型。
Length：1字节，用于标识整个 Sub-TLV 长度。
Value：不定长，取决于 Sub-TLV Type 用于携带具体内容。

Sub-TLV Type Code 0x01= Interface MTU：RFC8077
携带了一个 2 字节的 AC 接口 MTU。此参数仅适用于传输数据包的 PW，对于这些 PW 类型是必需的。 如果此参数在特定 PW 的两个方向上都不匹配，则不得启用该 PW。

MTU 用于配置 PW 协商 AC MTU 参数。同时在AC接口视图下和PW模板视图下配置了MTU，则接口视图下的配置优先生效。

Sub-TLV Type Code 0x03= Optional Interface Description：RFC8077
携带一个最大 80 字节的 value，用于携带 RFC2277 定义的 UTF-8 格式的 AC 接口描述。此参数是可选 Sub-TLV，适用于所有 PW 类型。

Sub-TLV Type Code 0x0c= VCCV parameter：RFC5085/RFC5885/RFC7708/RFC7885
《RFC5085-Pseudowire VCCV: A Control Channel for Pseudowires》中定义了 VCCV (Virtual Circuit Connectivity Verification，VC连通性检查) 参数用于指示特定 PW 控制通道的类型以及连通性检查的模式。这一参数主要在 LDP 的 Label Mapping Message 中出现用作 PW 建立信令的一部分，用于实现 PW OAM 功能。

这一参数主要分为 Control Channel(CC) 和 Connectivity Verification(CV)。 一旦选择了特定的 CC 类型进行发送和回复，则在重新发出 PW 信令之前，必须唯一使用该 CC 类型。此外，如果需要一组不同的功能类型，则必须重新发送伪线信号。如果所有功能都不支持，应将 CC 和 CV 取 0x00。

每个 CC 类型的定义都依赖于定义它的 PW type context，即 MPLS 或 L2TPv3。这里介绍 MPLS 场景下的 CC 参数。
PWE3 Control Word-bit：这一 bit 与《RFC4385-PWE3 Control Word for Use over an MPLS PSN》中定义的 PWE3 control-word=PWACH 有关。
MPLS Router Alert-bit：当置位时也可以用于生成 VCCV control channel。无论 PW 是否设置了 control-word，都可以使用本功能。
MPLS PW Label with TTL == 1：当置位时表示可以将 PW Label 的 TTL 设置为 1，以强制在目标路由器的控制平面内处理数据包。无论 PW 是否设置了 control-word，都可以使用本功能。
GAL-bit：定义于 RFC7708。当置位时表示转发面携带额外的 VCCV 控制通道类型，用于不使用 PW 控制字并通过 MPLS 网络传输的伪线。

control-word 用于在PW模板中使能控制字功能。此外，PW的control-word属性也可以通过mpls l2vc命令行指定。默认情况，系统没有使能control-word功能。
mpls l2vpn pw-ttl 用来配置PW的TTL属性值。默认PW TTL = 1。

每个 CV 类型的定义都依赖于定义它的 PW type context，即 MPLS 或 L2TPv3。这里介绍 MPLS 场景下的 CV 参数。
ICMP ping-bit：置位时，表示可使用 ICMP/ICMPv6 进行连通性检测。
LSP ping-bit：置位时，表示可使用 RFC4379 定义的 MPLS ping 进行连通性检测。仅当 MPLS Label 作为 PW demultiplexor 解复用器时，才应使用 LSP Ping CV 类型。
BFD-bit：定义于 RFC5885。
RFC5885 和 RFC7885 还定义了其他 BFD 技术相关 bit。

interface-parameter-type vccv 用于使能mapping报文中携带接口参数中的vccv参数。
mpls l2vpn vccv bfd-cv-negotiation 设置VCCV中携带的BFD CV值。默认值为0x08。

4.1.3.常用PW属性TLV

在 RFC 文档中还定义了与 PW 属性相关的几种 top LDP TLV：
PW Status TLV：code=0x096A， RFC8077中定义。
PW Interface Parameters TLV：code=0x096B， RFC8077中定义。仅在发送 Generalized PWid FEC 时出现。
PW Group ID TLV：code=0x096C， RFC8077中定义。仅在发送 Generalized PWid FEC 时出现。

PW Group ID 与 AGI 无关，不是 FEC 的一部分。PW Group ID 可以用作端口索引，并分配给通向该端口的所有 PW。当物理端口发生故障时可以向远程 PE 发送 status 或 withdraw 消息，实现收敛。

Pseudowire Switching Point PE TLV：code=0x096D， RFC6073 中定义。
Bandwidth TLV：code=0x096E， RFC7267 中定义。

PW Status TLV：code=0x096A， RFC8077 中定义
Length：2 字节，固定为 4 表示 Status Code 的长度。
Status Code：4 字节，用于指示 PW 状态。Status Code 中的每一个 bit 都可单独用于标识故障，以便一次通告可以标识多个故障。当所有故障都以消失，Status Code 以 0x00000000 填充。0x00000001 用于表示其他均不适用的故障。

LDP Notification message 可以携带 PW Status TLV 来向对端 PE 传递当前 PW 状态。
当以此种方式出现时，应当按照上述编码格式进行。
@：其中 Status TLV 的 status code 设置为 0x00000028 以表示 PW status。
@：由于该 LDP Notification message 不涉及其他 message，应将 Message ID 设置为 0。
@：PW FEC TLV 不应包含接口参数 Sub-TLV，必须包含 C 位（如果适用），因为它是 FEC 的一部分。
@：PW Generalized FEC TLV 不应包含 AGI、SAII 和 TAII，PW info length 设置为 0，包含 PW Group ID TLV，并且省略 PW 接口参数 TLV。
自动换行
上图则为 Notification message 可以携带 PW Status TLV 的例子。
mpls l2vpn default martini 用来禁止LDP作为信令时PW发送Notification消息。

Pseudowire Switching Point PE TLV：code=0x096D，RFC6073 中定义
SP-PE TLV Length：2 字节，标识 TLV 后续字段的长度。
Sub-TLV Type：1 字节，SP-PE 类型。
Length：1 字节，后续 Value 字段的长度。
Value：不定长。

在跨域场景中，不同管理域 PW 可能会在遍历多个交换点。出于管理和故障排除等原因，通过 Pseudowire Switching Point PE TLV (SP-PE TLV) 记录开关点的信息非常有用。发送 SP-PE TLV 是可选的。但是，PE 或 S-PE 必须在收到 TLV 时处理 TLV。SP-PE TLV 对于遍历的每个开关点只能出现一次，并且其长度不能为零。

Bandwidth TLV：code=0x096E， RFC7267中定义
TLV Length：2 字节，后续字段的长度。
Forward SENDER_TSPEC：4 字节，Source Terminating Provider Edge 到 Target Terminating Provider Edge 方向的数据路径。
Reverse SENDER_TSPEC：4 字节，Target Terminating Provider Edge 到 Source Terminating Provider Edge 方向的数据路径。

Bandwidth TLV 主要用于显式配置 PW 所需的带宽，在 RSVP 等场景下使用。

点击此处回到目录

4.2.控制面行为-RFC8077

在 2017 年发布替代 RFC4447 的《RFC8077-Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)》中定义了 LDP 作为 PW 信令传递协议的参数规范。

4.2.1.Control-Word 处理动作

1@：PW 两端必须协商一致的 Control-Word 参数。当受到与自身不一致的 Control-Word 参数时，必须发送 Status TLV (LDP TLV Code=0x300)。其中将 status date = 0x20000001 以标识 illegal C-Bit。
2@：协议定义了如下完整的 LDP Label Mapping message 交互逻辑。

接收 Label Mapping message，但未发送 Label Mapping message 时，应当：

• 接收 C=0，发送 C=0。不使用控制消息。
• 接收 C=1 且本地配置为优先使用 Control-Word，发送 C=1。
• 接收 C=1 且本地配置为不使用 Control-Word，发送 C=0。

未接收 Label Mapping message，但已发送 Label Mapping message 时，下一个操作取决于接下来接收到该 PW 的控制消息。

• 接收与发送一致，根据协商结果进行。
• 接收 C=1，但已发送 C=0。忽略接收的该 Label Mapping message，等待下一步动作。
• 接收 C=0，但已发送 C=1。必须发送 Label Withdraw message 携带 Status TLV (LDP TLV Code=0x300)。其中将 status date = 0x20000002 以标识 Wrong C-Bit。然后发送 C=0 的 Label Withdraw message。

接收 PE 不响应 Wrong C-Bit 的 Label Withdraw message，继续等待 PW 的下一条控制消息。

3@：在完成 PW C-bit 协商过程后，可能会重新配置本地 PE 的 Control-Word。

• 如果本地 PE 之前发送了 Label Mapping message，则必须向远端 PE 发送 Label Withdraw message，并等待接收来自远端 PE 的 Label Release message。
• 本地 PE 必须发送 Label Release message，以获取与 PW FEC 相关联的 Label。
• 本地 PE 必须发送 Label Request message 直到接收来自远端 PE 的 Label Mapping message。

4.2.1.PW 信令状态的协商

1@：一旦配置了 PW，不管 AC 状态如何，本地 PE 将向远端 PE 发送 Label Mapping messages。在任何情况下，如果标签到 PW 的绑定不可用，则必须将 PW 视为处于关闭状态。但只有 AC 状态为 Active，才将进行完整的 PW 信令状态的协商。

2@：LDP Notification message 可以携带 PW Status TLV 来向对端 PE 传递当前 PW 状态。

当以此种方式出现时，应当按照上述编码格式进行。
@：其中 Status TLV 的 status code 设置为 0x00000028 以表示 PW status。
@：由于该 LDP Notification message 不涉及其他 message，应将 Message ID 设置为 0。
@：PW FEC TLV 不应包含接口参数 Sub-TLV，必须包含 C 位（如果适用），因为它是 FEC 的一部分。
@：PW Generalized FEC TLV 不应包含 AGI、SAII 和 TAII，PW info length 设置为 0，包含 PW Group ID TLV，并且省略 PW 接口参数 TLV。
自动换行
上图则为 Notification message 携带 PW Status TLV 的例子。
mpls l2vpn default martini 用来禁止LDP作为信令时PW发送Notification消息。

3@：当首次设置 PW 时，本地 PE 在 Label Mapping message 中必须尝试协商 PW Status TLV 并在 PW 的整个生命周期中使用。
如果本地 PE 初始发送 Label Mapping message 中携带 PW Status TLV，而远端 PE 不支持 PW Status TLV，那么对等体将自动忽略它。
如果 PE 接收的初始 Label Mapping message 中的 FEC TLV 之后不存在 PW Status TLV，则不会使用 PW Status TLV。

上图为初始发送 Label Mapping message 的一个示例。

4@：Label Withdrawal Message 可用于撤回特定 PW 组关联的所有 PW 标签。主要通过 PWid FEC TLV的 Group ID 字段，或与 Generalized PWid FEC Element 一起使用的 PW Group ID TLV 来实现。

上图为发送 Label Withdrawal message 的一个示例。
请注意，PW Group ID TLV 仅适用于使用 Generalized PWid FEC 的 PW，而 Group ID 仅适用于使用 PWid FEC 的 PW。

4.3.转发面行为-RFC4448

在 2006 年发布的《RFC4448-Encapsulation Methods for Transport of Ethernet over MPLS Networks)》中主要描述了 LDP 作为 PW 信令时的转发面行为。

当 MPLS 建立的 PW 用于为 Ethernet 帧提供服务时，应选择以下两种模式之一运行：raw mode 和 tagged mode。这两种模式也对应了上文 FEC 中所提到 PW type 的 Ethernet 和 Ethernet Tagged，实际上代表着 Ethernet 帧在 PW 中进行传输时是否携带 VLAN Tagged。
raw mode：每个帧通常不包含 802.1Q VLAN 标记，并且对 Native Service Processing (NSP，本地服务处理程序) 无意义。
tagged mode：每个帧必须至少包含一个 802.1Q VLAN 标记。

NSP 功能主要包括剥离、覆盖或添加 VLAN 标签、物理端口多路复用和demultiplexing解复用、PW-PW 桥接、L2 封装、整形、监管等。这些功能只针对于为 Ethernet 帧提供服务，并且可能不是 PW 所必需的。
encapsulation 用来配置VPLS实例的封装类型。默认封装类型是VLAN。
自动换行
PW 用于为 Ethernet 帧提供服务时具有如下特性：
@：无论帧中是否存在 802.1Q 标记，NSP 都会执行 Frame Check Sequence (FCS，帧检验序列) 功能。并在帧传输至对端 PE 时，重新生成 FCS。
@：出口 PE 的 NSP 需要支持 VLAN 重写。
@：PW 两端的 PW type 必须一致。
@：不考虑分片重组，可以转发的帧大小受 PSN MTU (也即MPLS MTU) 减去 MPLS 标头大小的限制。
@：此环境下应当可以实现包排序以及 QOS 功能。
@：在 tagged mode 下新定义了一种 Interface Parameter Sub-TLV。Pseudowire Interface Parameters Sub-TLV code 0x06=Requested VLAN ID。当入口 PE 接收该 Sub-TLV 时，必须以 Requested VLAN ID 重写 VLAN ID。如果入口 PE 既无法执行此操作，Sub-TLV 的 VLAN ID 又与配置的入口 VLAN ID 不匹配，则不得启用 PW。

Raw Mode vs. Tagged Mode：
1@：当 PE 接收到 Ethernet Tagged 帧时，VLAN ID 可能用于业务分隔。例如，来自不同客户的 LAN 可能连接到同一服务运营商交换机。也可能不用于业务分割，只连接一个客户。服务分隔与否由 PE 上的本地配置确定。
2@：如果 PW 工作于 raw mode，则 PW 传递的 Ethernet Tagged 帧将在入口 NSP 剥离 VLAN 并永远不会通过 PW 发送。
3@：如果 PW 工作于 tagged mode，则在 PW 上发送的每个帧都必须具有 VLAN Tagged。即使接收 Ethernet 帧不包含 Tagged，也必须在帧前面添加一个虚拟 VLAN 标记。
4@：在任何情况下，NSP 功能只能检查来自 AC 的 Ethernet 最外层的标签。在这两种模式下，服务分隔标签值仅具有局部意义，即仅在特定 AC 接口上有意义。
5@：tagged mode 可以支持重写或删除 VLAN，raw mode 不得重写或删除 VLAN。
6@：PW 两端 AC 接口的 MTU 必须一致。如果出口 PE 接收到的解封装 Ethernet 超过了 AC 接口 MTU，必须将其丢弃。
7@：如果出于 ECMP 等需要开启了 control-word 功能，则在转发面会携带 control word。
RFC4448 所定义的 control word。

RFC3985 所定义的 Ethernet Tagged 模式下协商 control-word 成功的转发面数据交互示例。

其他详细内容，可查阅相关资料。

点击此处回到目录

5.L2VPN的方案实例

5.1.Kompella方案/BGP方案

此处只提供了 CE1/PE1 设备的关键配置，而省略了打通 underlay 的相关配置。有能力者可自行进行其它设备的配置。
有需要者可私信联系提供模拟器源文件及配置。

mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
 bgp-vpn label-block-size 4
#
vsi vpls
 pwsignal bgp
  route-distinguisher 1:1
  vpn-target 100:100 import-extcommunity
  vpn-target 100:100 export-extcommunity
  mtu-negotiate disable
  encapsulation rfc4761-compatible
  site 100 range 200 default-offset 1
  peer 2.2.2.2 remote-site 101 pw pw1
   control-word enable
 mtu 1400
 encapsulation vlan
 mac-learn-style qualify
#
interface Ethernet1/0/1.10
 vlan-type dot1q 10
 l2 binding vsi vpls
#
bgp 65000
 router-id 1.1.1.1
 peer 2.2.2.2 as-number 65000
 peer 2.2.2.2 connect-interface LoopBack1
 #
 ipv4-family unicast
  undo synchronization
  undo peer 2.2.2.2 enable
 #
 l2vpn-ad-family
  policy vpn-target
  peer 2.2.2.2 enable
  peer 2.2.2.2 signaling vpls
#

此处相关命令已在前文介绍，此处不再解释。并且命令仅作示例使用。

5.2.BGP方案状态检查

display vpls connection verbose 用于查看 vpls 互联基本信息。

display vpls forwarding-info verbose 用于查看 pw 标签转发信息。

display vsi verbose 查看vpls详细信息。

display vsi remote bgp 查看bgp传递信令的详细信息。

5.3.Martini方案/LDP方案

此处只提供了 CE1/PE1 设备的关键配置，而省略了打通 underlay 的相关配置。有能力者可自行进行其它设备的配置。
有需要者可私信联系提供模拟器源文件及配置。

bfd
 mpls ping interval 500 
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls l2vpn
 mpls l2vpn default martini
#
vsi 10 bd-mode
 pwsignal ldp
  vsi-id 10
  peer 3.3.3.3 
  peer 3.3.3.3 pw pw1
   control-word enable
 encapsulation ethernet
#
bridge-domain 10
 l2 binding vsi 10
#
mpls ldp remote-peer to-CE2
 remote-ip 3.3.3.3
#
interface GE1/0/0.10 mode l2
 encapsulation dot1q vid 10
 bridge-domain 10
#

这里以 BD 为基础创建了 VPLS 实例，仅作示例进行展示。其中相关命令已在前文介绍，此处不再解释。

5.4.LDP方案状态检查

display vpls vsi name 10 verbose 展示了 VPLS 实例详细信息。主要包括了 PW 信令传递方式、PW type、VC-id、PW label 和 VCCV 等信息。

display vpls remote ldp verbose 主要展示了远端 PE 形成 PW 参数信息。主要包括 VC-id (pw id=10)，PW type (Ethernet)，pw label (16，远端为本地分配的内层标签)和 VCCV (0x030a。也即支持 C-word，MPLS Router Alert的 CC，支持 LSP ping 和 bfd 的 CV)等。

LDP所传递的PW信令信息。
由于功能有限，此处仅作示例。

点击此处回到目录

更新

本文标签： 报文 示例 原理 网络 VPWS