简介
本文档描述了虚拟可扩展局域网 (Virtual eXtensible Local Area Network，VXLAN)，该网络用于解决在容纳多租户的虚拟化数据中心内对overlay网络的需求。该方案及相关协议可用于云服务提供商和企业数据中心的网络。本备忘录记录了已部署的 VXLAN 协议，以造福 Internet 社区。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
这是对 RFC 系列的贡献，独立于任何其他RFC流。RFC编辑器选择自行决定发布此文档，并且不声明其对实施或部署的价值。由RFC编辑批准发布的文件不适合任何级别的Internet标准；请参阅 [RFC 5741-RFC Streams, Headers, and Boilerplates]的第2节。
有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7348。
1、简介
服务器虚拟化对物理网络基础架构提出了更高的要求。一台物理服务器现在有多个虚拟机 (Virtual Machines，VMs)，每个虚拟机都有自己的媒体访问控制 (Media Access Control，MAC) 地址。由于数十万 VM 之间的潜在连接和通信，这需要交换以太网中支持更大的 MAC 地址表。
如果数据中心中的 VM 根据其虚拟 LAN (Virtual LAN，VLAN) 进行分组，则可能需要数千个VLAN来根据VM可能所属的特定组对流量进行分区。在这种情况下，当前的VLAN上限规格4094是不能满足的。
数据中心通常需要托管多个租户，每个租户都有自己独立的网络域。由于使用专用基础设施实现这一点并不经济，因此网络管理员一般会选择通过对共享网络来实施隔离。在这种情况下，一个常见的问题是每个租户可能会独立分配MAC地址和 VLAN ID，从而导致在物理网络上的潜在重复。
使用二层物理基础设施的虚拟化环境的一个重要要求是在整个数据中心甚至数据中心之间拥有二层网络规模，以有效分配计算、网络和存储资源。在此类网络中，将生成树协议 (Spanning Tree Protocol，STP) 等传统方法用于无环路拓扑可能会导致大量链路被禁用。
最后一种情况是网络运营商更喜欢使用 IP 进行物理基础设施互连的情况。例如，通过等价多路径 (Equal-Cost Multipath，ECMP) 实现多路径可扩展性，从而避免禁用链路。即使在这样的环境中，也需要保留用于 VM 间通信的二层网络模型。
上述场景问题的解决就需要overlay网络。此overlay网络用于通过逻辑“隧道”以封装的形式承载来自各个 VM 的 MAC 流量。
本文档详细介绍了一个称为“虚拟可扩展局域网 (Virtual eXtensible Local Area Network，VXLAN)”的框架，该框架提供了一种封装方案来满足上述各种要求。本备忘录记录了已部署的 VXLAN 协议，以造福 Internet 社区。
1.1、首字母缩略词和定义
ACL：Access Control List，访问控制列表
ECMP：Equal-Cost Multipath，等价多路径
IGMP：Internet Group Management Protocol，网络组管理协议
IHL：Internet Header Length，网络报文头长度
MTU：Maximum Transmission Unit，最大传输单元
PIM：Protocol Independent Multicast，协议独立组播
SPB：Shortest Path Bridging，最短路径桥接
STP：Spanning Tree Protocol，生成树协议
ToR：Top of Rack，机架顶部
TRILL：Transparent Interconnection of Lots of Links，多链接透明互联
VLAN：Virtual Local Area Network，虚拟局域网
VM：Virtual Machine，虚拟机
VNI：VXLAN Network Identifier，VXLAN网络标识符（或 VXLAN 网段 ID）
VTEP：VXLAN Tunnel End Point，VXLAN 隧道端点。发起和/或终止 VXLAN 隧道的实体
VXLAN：Virtual eXtensible Local Area Network，虚拟可扩展局域网
VXLAN Segment，VXLAN 二层overlay网络中VM之间的通信方式
VXLAN Gateway，在 VXLAN 之间转发流量的实体
2、本文档中使用的约定
本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119-Key words for use in RFCs to Indicate Requirement Levels] 中的描述进行解释。
3、VXLAN问题陈述
本节提供有关 VXLAN 旨在解决的领域的更多详细信息。重点是数据中心内的网络基础设施及其相关问题。
3.1、生成树和 VLAN 范围引入的限制
当前的二层网络使用 IEEE 802.1D 生成树协议 (Spanning Tree Protocol，STP) [802.1D] 来避免网络中由于重复路径而导致的环路。STP阻止阻塞这些链路以避免帧的复制和循环。因为使用STP，一些数据中心运营商实际上支付比实际使用的端口和链接更多的端口和链接费用，他们普遍认为这是二层网络的一个问题。此外，由于多路径而产生的网络弹性在 STP 模型中不可用。类似TRILL [RFC6325- Routing Bridges (RBridges): Base Protocol Specification]和SPB[802.1aq]等新的举措，已被提议用于帮助多路径转发并克服 STP 的一些问题。通过将机架内的服务器配置在同一个三层网络内，在机架内和机架之间层进行三层交换，也可以避免 STP的限制。但是，这与用于 VM 间通信的二层模型不兼容。
二层数据中心网络的一个关键特性是它们使用VLAN来进行广播隔离，以太网数据帧中使用12位VLAN ID将较大的二层网络划分为多个广播域。这对于需要少于 4094 个 VLAN 的许多数据中心非常有用。随着越来越多地采用虚拟化，这个上限正面临压力。此外，由于 STP，一些数据中心限制了可以使用的 VLAN 数量。此外，如第 3.3 节所述，对多租户环境的要求加速了对更大 VLAN 上限的需求。
3.2、多租户环境
云计算涉及为多租户环境按需弹性供应资源，云计算最常见的例子是公共云，其中云服务提供商通过同一物理基础设施向多个客户/租户提供这些弹性服务。
租户对网络流量的隔离可以通过二层网络或三层网络完成。在二层网络中， 通常用VLAN来隔离流量。例如，租户可以通过其自己的 VLAN 进行识别。由于云提供商可能服务的租户数量众多，4094个 VLAN的限制通常是不够的。此外，通常每个租户也需要多个 VLAN，更加剧了这个问题。
一个相关的情况是跨集群扩展。一个集群通常由一个或多个具有相关网络和存储连接的服务器机架组成。租户开始可能只有一个集群，由于扩展，后来需要其他集群上的服务器/VM，特别是在其他集群上的租户没有充分利用其所有资源的情况下。这种情况就需要一个连接各个服务器/VM 的“延伸”二层网络环境。
三层网络也不是多租户的综合解决方案。两个租户可能在他们的网络中使用相同的三层地址集，这需要云提供商以其他形式提供隔离。以后，所有租户使用 IP和其他用户隔离，依赖于二层直连网络或非 IP的三层协议进行 VM 间通信。
3.3、ToR 交换机上的表容量不足
当今的虚拟化环境对连接到服务器的架顶式 (Top-of-Rack，ToR) 交换机的 MAC 地址表提出了额外的要求。 ToR 现在必须了解各个 VM 的 MAC 地址（每个服务器可能有数百个），而不是每个服务器链路只有一个 MAC 地址。这是必要的，因为进/出 VM 到物理网络其余部分的流量将遍历服务器和交换机之间的链路。典型的 ToR 交换机可以连接到 24 或 48 个服务器，具体取决于其面向服务器的端口数量。一个数据中心可能由多个机架组成，因此每个 ToR 交换机都需要为跨各种物理服务器的虚拟机通信维护一个地址表。与非虚拟化环境相比，这对表容量提出了更高的要求。
如果表溢出，交换机可能会停止学习新地址，直到空闲条目过期，从而导致后续未知目标帧的大量泛滥。
4、VXLAN
VXLAN（Virtual eXtensible Local Area Network，虚拟可扩展局域网）解决了在多租户环境中存在 VM 的情况下二层网络和三层网络数据中心网络基础架构的上述要求。它运行在现有的网络基础设施上，并提供了一种“延伸”二层网络的方法。简而言之，VXLAN是三层网络上的二层overlay方案。每个overlay被称为一个 VXLAN 段，只有在同一个 VXLAN 段内的虚拟机才能相互通信。每个 VXLAN 段都通过一个 24 位的网段 ID 进行标识，称为“VXLAN 网络标识符 (VXLAN Network Identifier，VNI)”。这允许多达 16 M （2的24次方=16777216）个 VXLAN 段在同一管理域*存。
VNI 通过不同 VM来区分内部 MAC 帧的范围。因此，您可以跨网段有重叠的 MAC 地址，但永远不会有流量“交叉”，因为流量是使用 VNI 隔离的，VNI 封装在由 VM 发起的内部 MAC 帧的外部报头中。在以下部分中，术语“VXLAN 段”与术语“VXLAN overlay网络”可互换使用。
由于这种封装，VXLAN 也可以称为隧道方案，以将二层网络overlay在三层网络之上。隧道是无状态的，因此每个帧都根据一组规则进行封装。以下部分中讨论的隧道端点（VXLAN Tunnel End Point，VXLAN 隧道端点或 VTEP）位于托管 VM 的服务器上的管理程序内。因此，VNI 和 VXLAN 相关的隧道/外部报头封装只有 VTEP 知道——VM 永远不会看到它（参见图 1）。请注意，VTEP 也可能位于物理交换机或物理服务器上，并且可以在软件或硬件中实现。 VTEP 位于物理交换机的场景会在关于 VXLAN 部署方案的第 6 节中讨论。
以下部分讨论了 VXLAN 环境中使用一种控制方案（数据平面学习）的典型流量场景。在这里，VM 的 MAC 与 VTEP 的 IP 地址的关联是通过源地址学习发现的。组播用于承载未知目的地、广播和组播帧。
除了基于学习的控制平面之外，还有其他可能用于分发 VTEP IP 到 VM MAC 映射信息的方案。方案可以包括由各个VTEP进行的基于*机构/基于目录的查找，由*机构将此映射信息分发到 VTEP，等等。这些有时分别被称为推模型和拉模型。本文档将重点介绍数据平面学习作为控制平面的VXLAN方案。
4.1、VM 到 VM单播通信
设想一台VXLAN overlay网络中的 VM，这台VM感知不到VXLAN。为了与不同主机上的虚拟机通信，它会像往常一样发送一个发往目标的 MAC 帧。物理主机上的 VTEP 查找与此 VM 关联的 VNI，然后确定目标 MAC 是否在同一网段上，以及目标 MAC 地址是否映射到远程 VTEP。如果是，则将包含外部 MAC、外部 IP 报头和 VXLAN 报头的外部报头（帧格式参见第 5 节中的图 1）添加到原始 MAC 帧之前。封装的数据包被转发到远程 VTEP。远程 VTEP收到后，使用与内部目标 MAC 地址匹配的 MAC 地址验证 VNI 的有效性以及该 VNI 上是否存在 VM。如果是，则数据包将剥离其封装标头并传递到目标 VM。目标 VM 永远不会知道 VNI的存在，也不知道数据是使用 VXLAN 封装传输的。
除了将数据包转发到目标 VM 之外，远程 VTEP 还会学习从内部源 MAC 到外部源 IP 地址的映射。它将此映射存储在一个表中，以便当目标 VM 发送响应数据包时，不需要响应数据包的“未知目标”泛洪。
除像第 4.2 节中描述的场景，源VM在传输之前确定目标 VM 的 MAC 地址与非 VXLAN 环境的操作是一样的。使用广播帧但封装在多播数据包中场景，详见第4.2节所述。
4.2、广播通信和组播映射
考虑源主机上的 VM 尝试使用 IP 与目标 VM 通信。假设它们都在同一个子网上，VM 会发送一个地址解析协议 (Address Resolution Protocol，ARP) 广播帧。在非 VXLAN 环境中，将使用 MAC 广播在承载该 VLAN 的所有交换机上发送此帧。
对于 VXLAN，包含 VXLAN VNI 的标头与 IP 标头和 UDP 标头一起插入到数据包的报文头中。但是，此广播数据包被发送到实现该VXLANoverlay网络的IP多播组。
为了实现这一点，我们需要在 VXLAN VNI 和它将使用的 IP 多播组之间建立映射。此映射在管理层完成并通过管理通道提供给各个 VTEP。通过使用此映射，VTEP可以向上游交换机/路由器提供IGMP成员报告，以根据需要加入/离开 VXLAN相关的IP组播组。这将根据使用特定多播地址的成员在该主机上是否可用来修剪特定多播流量地址的叶节点（参见 [RFC4541-Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches]）。此外，使用多播路由协议，如协议独立多播-稀疏模式（Protocol Independent Multicast-Sparse Mode，PIM-SM 见 [RFC4601-Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)]）将在三层网络内提供高效的多播树。
VTEP 将使用 (*,G) 加入。这是必需的，因为VXLAN隧道源的集合是未知的，并且可能会随着VM在不同主机之间启动/关闭而经常更改。这里要注意的是，由于每个 VTEP 都可以作为多播数据包的源和目的地，像双向 PIM（BIDIR-PIM——见 [RFC5015-Bidirectional Protocol Independent Multicast (BIDIR-PIM)]）这样的协议会更有效。
目标 VM 使用 IP 单播发送标准 ARP 响应。该响应报文会使用 IP 单播 VXLAN 进行封装，并发送到连接始发 VM 的 VTEP。这是可能的，因为 ARP 响应的目标 MAC 到 VXLAN 隧道端点 IP 的映射是早先通过 ARP 请求获知的。
请注意，多播帧和“未知 MAC 目标”帧也使用多播树发送，类似于广播帧。
4.3、物理基础设施要求
当在网络基础设施中使用 IP 多播时，网络中的各个三层IP路由器/交换机可以使用像PIM-SM这样的多播路由协议。这将用于构建高效的多播转发树，以便多播帧仅发送到那些请求接收它们的主机。
同样，连接源虚拟机和目标虚拟机的实际网络不要求是三层网络：VXLAN也可以工作在二层网络上。在任一情况下，都可以使用 IGMP 侦听，在二层网络内实现高效的多播复制。
VTEP 不得对VXLAN数据包进行分段。由于较大的帧大小，中间路由器可能会对封装的VXLAN数据包进行分段，目标VTEP可以默默地丢弃此类VXLAN分段。为确保无碎片的端到端流量传输，建议将物理网络基础设施上的 MTU（Maximum Transmission Units，最大传输单元）设置为一个值，以适应由于封装而产生的较大帧大小。其他技术，如路径MTU发现（参见 [RFC1191-Path MTU Discovery] 和 [RFC1981-Path MTU Discovery for IP version 6]）也可用于满足此要求。
5、VXLAN 帧格式
VXLAN 帧格式如下所示。从帧的底部解析——在外部帧校验序列 (Frame Check Sequence，FCS) 之上，有一个内部MAC帧，它带有自己的以太网报头，带有源、目标 MAC 地址和以太网类型，以及一个可选的VLAN。有关内部VLAN 标记处理的更多详细信息，请参阅第 6 节。
内层MAC帧封装有以下四个头部（从最内层开始）：
VXLAN 标头：这是一个 8 字节的字段，具有：
- 标志（8 位）：对于有效的 VXLAN 网络 ID (VNI)，I 标志必须设置为 1。其他 7 位（指定为“R”）是保留字段，传输时必须设置为零，接收时忽略。
- VXLAN 段 ID/VXLAN 网络标识符 (VNI)：这是一个 24 位值，用于指定通信 VM 所在的单个 VXLAN overlay网络。不同 VXLAN overlay网络中的虚拟机无法相互通信。
-保留字段（24位和8位）：必须在发送时设置为零，在接收时忽略。
外部 UDP 报头：这是外部 UDP 报头，其源端口由VTEP提供，目的端口是知名UDP端口。
- 目标端口：IANA 为 VXLAN UDP 端口分配了值 4789，默认情况下应该使用该值作为目标 UDP 端口。 VXLAN的某些早期实现已将其他值用于目标端口。为了启用与这些实现的互操作性，目标端口应该是可配置的。
- 源端口：建议使用来自内部数据包的字段散列来计算 UDP 源端口号——一种情况是内部以太网帧头的哈希。这是为了在VXLANoverlay范围内为虚拟机到虚拟机流量的ECMP/负载均衡启用一定程度的熵。以这种方式计算 UDP 源端口号时，建议该值在动态/私有端口范围 49152-65535 [RFC6335- Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry] 内。
- UDP 校验和：它应该被设置为0来传输。当接收到一个 UDP 校验和为0的数据包时，它必须被接受以进行解封装。可选地，如果封装端点包含非零UDP 校验和，则必须在整个数据包中正确计算，包括 IP 报头、UDP 报头、VXLAN 报头和封装的 MAC 帧。当一个解封装端点接收到一个具有非0校验和的数据包时，它可以选择验证校验和值。如果它选择执行这种验证，并且验证失败，则必须丢弃该数据包。如果解封装目的地选择不执行验证，或执行成功，则必须接受数据包进行解封装。
外部 IP 标头：这是带有源 IP 地址的外部 IP 标头，指示正在运行的通信 VM（由内部源 MAC 地址表示）运行的 VTEP 的 IP 地址。目标 IP 地址可以是单播或多播 IP 地址（参见第 4.1 和 4.2 节）。当它是单播 IP 地址时，它表示连接通信 VM 的 VTEP 的 IP 地址，如内部目标 MAC 地址所示。如果是组播目的IP地址，请参考4.2节详述的场景。
外部以太网报头（示例）：图 1 是封装在外部以太网 + IP + UDP + VXLAN 报头中的内部以太网帧示例。该帧中的外层目的MAC地址可能是目标VTEP的地址，也可能是中间三层路由器的地址。外层 VLAN 标记是可选的。如果存在，它可用于描述 LAN 上的 VXLAN 流量。
图1：带有IPv4外部报文头的VXLAN帧格式
上面的帧格式显示了使用 IPv4 进行传输的以太网帧隧道封装。VXLAN 与 IPv6 传输的使用详述如下。
图 2：带有 IPv6 外部报文头的 VXLAN 帧格式
6、VXLAN 部署场景
VXLAN 通常部署在数据中心的虚拟主机上，这些主机可能分布在多个机架上。各个机架可能是不同三层网络的一部分，也可能位于单个二层网络中。 VXLAN网段/overlay网络overlay在这些二层或三层层网络之上。
考虑图3的场景，它描绘了连接到三层网络基础架构的两个虚拟化服务器。服务器可以在同一个机架上，也可以在不同的机架上，或者可能是跨同一个管理域内的数据中心。VNI 22、34、74 和 98 标识了四个 VXLAN overlay网络。考虑服务器 1 中的 VM1-1 和服务器 2 中的 VM2-4 的情况，它们位于由 VNI 22 标识的同一个 VXLAN overlay网络上。 VM 不知道overlay网络和传输方法，因为在服务器 1 和 2 上的 VTEP 上终端无感知地进行封装和解封装。其他overlay网络和对应的 VM：服务器 1 上的 VM1-2 和服务器 2 上的 VM2-1 ，都在 VNI 34 上；服务器 1 上的 VM1-3 和服务器 2 上的 VM2-2，都在VNI 74 上；最后是服务器 1 上的 VM1-4 和服务器 2 上的 VM2-3，都在VNI 98上。
图 3：VXLAN 部署-跨三层网络的VTEP
一种部署方案是：VTEP是支持VXLAN的物理服务器。另一种情况是 VXLAN overlay网络上的节点可能需要与基于 VLAN 的传统网络上的节点进行通信，这些节点可以是物理节点或虚拟机。为了实现这种通信，网络可以包括在 VXLAN 和非 VXLAN 环境之间转发流量的 VXLAN 网关（参见下面的图 4，其中一个交换机充当 VXLAN 网关）。
考虑图 4 的情况，进行以下讨论。对于 VXLAN 连接接口上的传入帧，网关会根据内部以太网帧的目标 MAC 地址剥离 VXLAN 标头并将其转发到物理端口。除非明确配置为传递给非VXLAN接口，否则应该丢弃具有内部VLAN ID的已解封装的帧。在相反方向，非 VXLAN 接口的传入帧，应根据帧中的 VLAN ID 映射到特定的 VXLAN overlay网络。除非明确配置为在封装的 VXLAN 帧中传递，否则在报文进行VXLAN封装之前删除此 VLAN ID。
这些提供VXLAN隧道终止功能的网关可以是ToR /接入交换机或数据中心网络拓扑中较高级别的交换机：例如核心交换机甚至WAN边缘设备。最后一种情况（广域网边缘）可能涉及在混合云环境中终止 VXLAN 隧道的服务提供商边缘 (PE) 路由器。在所有这些情况下，请注意网关功能可以在软件或硬件中实现。
图 4：VXLAN 部署-VXLAN 网关
6.1、内部 VLAN 标记处理
VTEP 和 VXLAN 网关中的内部 VLAN 标记处理应符合以下要求：
除非另有配置，否则应丢弃带有内部 VLAN 标记的解封装 VXLAN 帧。在封装方面，除非另有配置，否则 VTEP 不应在封装数据包上包含内部 VLAN 标记。当带有 VLAN 标记的数据包在进入VXLAN隧道之前，除非另有配置，否则封装的 VTEP 应该剥离 VLAN 标记。
7、安全注意事项
传统上，二层网络只能被恶意端点从“内部”攻击——通过对 LAN 的不当访问和流量窥探，通过注入欺骗性数据包来“接管”另一个 MAC 地址，或者通过泛洪导致服务器拒绝服务。用于传输二层流量的MAC-over-IP机制大大扩展了这种攻击面，这可能是由于攻击者通过订阅一个或多个承载 VXLAN 段的广播流量多播组以及通过将 MAC-over-UDP 帧发送到传输网络以注入虚假流量（可能是为了劫持 MAC 地址）将自己注入网络而发生的。
本文档不包含针对此类攻击的具体措施，而是依赖于 IP 之上的其他传统机制。相反，本节概述了 VXLAN 环境中一些可能的安全方法。
通过限制在 VXLAN 环境中部署和管理虚拟机/网关的人员的管理和管理范围，可以减轻攻击者在端点的传统二层网络攻击。此外，此类管理措施可能会通过 802.1X [802.1X] 等方案得到加强，以对单个端点进行准入控制。此外，使用基于 UDP 的 VXLAN 封装可以在物理交换机中配置和使用基于 5 元组的 ACL（Access Control List，访问控制列表）功能。
可以使用 IPsec 等传统安全机制保护 IP 网络上的隧道流量，这些机制对 VXLAN 流量进行身份验证和可选加密。当然，这需要与授权端点的身份验证基础设施相结合，以获取和分发凭据。
VXLAN overlay网络是在现有 LAN 基础设施上指定和运行的。为确保 VXLAN 端点及其 VTEP 在 LAN 上获得授权，建议为 VXLAN 流量指定一个 VLAN，服务器/VTEP 通过此 VLAN 发送 VXLAN 流量以提供安全措施。
此外，VXLAN 需要在这些overlay网络中正确映射 VNI 和 VM 成员关系，期望使用现有安全方法完成此映射并将其传送到 VTEP 和网关上的管理实体。
8、IANA相关
IANA 在 VXLAN 的服务名称和传输协议端口号注册表中分配了一个知名 UDP 端口 (4789)。有关端口号的介绍，请参见第 5 节。
9、参考文献
9.1、规范参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2、信息参考
[802.1aq] IEEE, "Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE P802.1aq-2012, 2012.
[802.1D] IEEE, "Draft Standard for Local and Metropolitan Area Networks/ Media Access Control (MAC) Bridges", IEEE P802.1D-2004, 2004.
[802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Acces Control", IEEE Std 802.1X-2010, February 2010.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4601] Fenner, B., Handley, M., Hol*, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.