- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
BIER技术白皮书
Copyright © 2022 新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文中的内容为通用性技术信息，某些信息可能不适用于您所购买的产品。
传统IP组播和组播VPN技术中，设备需要为每条组播流量分别建立组播分发树，分发树中的每一个节点都需要感知组播业务，并保留组播流状态。例如，公网PIM组播中，需要为每条组播流量建立一个PIM的组播分发树；在NG MVPN中，需要为每条组播流量建立P2MP隧道，也相当于建立一个P2MP组播树。随着组播业务的大规模部署，待维护的组播分发树的数量也急剧增加，组播节点上需要保留大量的组播流状态，当网络发生变化的时候，会导致组播表项收敛缓慢。
同时，单播路由协议、组播路由协议、MPLS协议等多协议在承载网络上并存，增加了承载网络控制平面的复杂度，使得故障收敛速度慢，运维困难，难以向SDN架构网络演进。
BIER（Bit Index Explicit Replication，位索引显式复制技术）是一种新型的组播转发技术架构，通过将组播报文要到达的目的节点集合以BS（Bit String，位串）的方式封装在报文头部发送，使得网络中间节点无需感知组播业务和维护组播流状态，可以较好地解决传统IP组播技术存在的问题，提供了良好的组播业务扩展性。
在BIER网络中，组播报文的转发依靠BFR（Bit Forwarding Router，位转发路由器）上通过BIER技术建立的BIFT（Bit Index Forwarding Table，位索引转发表），实现组播报文只需根据位串进行复制和转发。
BIER具有如下几方面的技术优点：
· 良好的组播业务扩展性
BFR上采用BIER技术建立的BIFT是独立于具体的组播业务的公共转发表，使得网络中间节点无需感知组播业务，不需要维护特定组播业务的组播流状态。公网组播和私网组播报文均可通过BIFT转发，具有良好的组播业务扩展性。
· 简化业务部署和运维
由于网络中间节点不感知组播业务，因此部署组播业务不涉及中间节点，组播业务变化对中间节点没有影响，简化了网络的部署和运维。
· 简化承载网络的控制平面
在承载网络的中间节点上，不需要运行PIM协议，控制平面协议统一为单播路由协议IGP和BGP，简化了承载网络的控制平面协议。
· 利于SDN架构网络演进
部署组播业务不需要操作网络中间节点，只需在入口节点为组播报文添加上指示后续组播复制的BIER封装。BIER封装中携带标识组播出口节点的位串，中间节点根据位串实现组播复制和转发，有利于SDN架构网络的演进。
BIER网络的基本元素为支持BIER转发的BFR（Bit Forwarding Router，位转发路由器）。如图1所示，BIER的典型网络模型中包括以下几个部分：
· BFIR（Bit Forwarding Ingress Router，位转发入口路由器）：组播数据流量进入BIER域的节点，负责对进入BIER网络的报文进行BIER封装。
· Transit BFR：组播数据流量在BIER域中转发的中间节点，负责对BIER报文进行转发。
· BFER（Bit Forwarding Egress Router，位转发出口路由器）：组播数据流量出BIER域的节点，负责对BIER报文进行解封装，并转发给组播接收者。
其中，BFIR和BFER统称为BIER边缘设备。
图1 BIER典型网络模型
· BIER域和BIER子域：在一个路由域或者管理域内所有BFR的集合称为BIER域（Domain）。一个BIER域可以划分为一个或者多个BIER子域（Sub-domain），Sub-domain也可简称为SD。每个BIER子域通过一个唯一的Sub-domain ID来标识。
· BFR ID：用来在一个BIER子域中唯一标识一台BIER边缘设备，Transit BFR无需配置BFR ID。
· BFR prefix：相当于路由协议中的Router ID，用来标识BFR。在同一个BIER子域中，每个BFR必须配置唯一的BFR前缀，且该前缀必须是BIER子域内路由可达的。目前BFR prefix只支持配置为Loopback口的地址。
· BS（Bit String，比特串）：BIER封装用一个特定长度的BS来表示BIER报文的目的边缘设备。Bit String从最右边开始，每一个比特位对应一个BFR ID。比特位置1，表示该比特位对应的BFR ID所标识的BIER边缘设备，为组播报文转发的目的边缘设备。
· BSL（Bit String Length，比特串长度）：用来表示BIER封装中的比特串长度。
· SI（Set Identifier，集标识）：当一个BIER子域内使用的BSL长度不足以表示该子域内配置的BFR ID的最大值时，需要将Bit String分成不同的集合，每个集合通过SI来标识。比如，BIER子域内BFR ID最大值为1024，假如BSL设置为256，就需要将BIER子域分为四个集合，分别为SI 0，SI 1、SI 2和SI 3。
· BIRT（Bit Index Routing Table，位索引路由表）：BFR上结合IGP/BGP协议交互的BIER属性信息（Sub-domain ID、BSL、BFR ID）与IGP/BGP路由信息生成的BIER路由表项，用于指导BIER报文的转发。
· F-BM（Forwarding-Bit Mask，转发位串掩码）：用来表示BFR往下一跳邻居复制发送组播报文时，通过该邻居能到达的BIER子域边缘节点集合。F-BM是BFR通过将该邻居所能到达的所有BIER子域边缘节点的Bit String进行“或”操作后得到。
· BIFT（Bit Index Forwarding Table，位索引转发表）：BIER子域内的组播流量通过查询BIFT来实现逐跳转发。每张BIFT都由三元组（BSL，SD，SI）确定。BIFT是BFR将BIRT表项中经过相同邻居不同表项进行合并生成，每条表项记录了一个下一跳邻居和对应的F-BM。
IETF RFC8279将BIER网络架构分为Underlay、BIER和Overlay三层。
Underlay层为传统IP路由层，通过IGP协议（目前仅支持IS-IS）的扩展TLV属性携带BFR的BIER属性信息在BIER子域内进行泛洪。BFR根据IGP算法生成到本子域内其它BFR前缀的路由，也就是到每个BFR的路由，从而建立BIER子域内节点之间的邻居关系以及节点之间的最佳转发路径。
BIER层作为BIER转发的核心层，在控制平面对BIER转发所需的IGP协议进行了扩展，用于生成指导组播报文在BIER域内完成转发的BIFT。BIFT生成过程如下：
(1) BFR通过IGP协议将BIER层配置的BIER信息进行通告。
(2) BFR基于IGP协议通告的BIER信息，在BFR之间的最佳转发路径上生成BIFT。
在转发平面，当封装有BIER头的组播报文在BIER层进行转发时，BFR根据BIER头中的信息查找BIFT表项完成报文复制转发。
Overlay层在控制平面主要负责组播业务控制面信息交互，比如BFIR和BFER之间用户组播的加入和离开信息，建立组播流与BFER对应关系的组播转发表项。
在转发平面，当组播报文到达BFIR时确定目的BFER集合，并完成该组播报文对应的BIER头的封装；当携带有BIER头的组播报文到达BFER节点时，解封装BIER头并完成后续的组播报文转发。
用户组播报文进入BIER网络入节点被封装一个BIER报文头，组播报文离开BIER网络出节点解封装BIER报文头还原组播报文。BIER报文头位于内层组播报文和外层Underlay封装（MPLS、IPv6头等）之间，封装格式由RFC8296定义，具体如图2所示。
图2 BIER报文头封装格式
BIER头各字段含义如下：
· MPLS label/BIFT-id：
¡ Underlay层为MPLS时，表示MPLS标签。
¡ Underlay层为其他协议时，表示用来标识BIFT的BIFT-ID，BIFT-ID由三元组（BSL，SD，SI）唯一确定。
· TC：3bits，Traffic Class，流量等级，用于QoS。
· S：1bits，标签栈底标识，同MPLS 封装的S bit，具体使用请参考RFC3032。
· TTL：8bits，MPLS封装时作TTL使用，具体使用请参考RFC3032。
· Nibble：4bits，合法取值为0101。如果BFR收到的BIER报文的这个字段不是0101，则丢弃报文。
· Ver：4bits，表示版本号，当前值为0表示实验中的版本。
· BSL：4bits，取值用1～7来代表不同比特串长度，取值与比特串长度的对应关系如下：
¡ 1：表示比特串长度为64bits。
¡ 2：表示比特串长度为128bits。
¡ 3：表示比特串长度为256bits。
¡ 4：表示比特串长度为512bits。
¡ 5：表示比特串长度为1024bits。
¡ 6：表示比特串长度为2048bits。
¡ 7：表示比特串长度为4096bits。
· Entropy：20bits，用来在存在等价路径时，进行路径的选择。拥有相同Bit String和Entropy值的报文，选择同一条路径。
· OAM：2bits，缺省为0，可用于OAM功能，不影响转发和QoS。
· Rsv：2bits，保留位，缺省为0。
· DSCP：6bits，报文自身的优先等级，决定报文传输的优先程度。
· Proto：6bits，BIER头后面紧跟Payload报文类型。
· BFIR-ID：16bits，组播报文进入BIER域BFIR的BFR ID。
· BitString：位串，每个比特位与一个BFER的BFR ID对应，比特位设置为1，则表示报文要转发给对应的BFER。
RFC8279中对BIER定义了多种封装类型，不同的封装类型报文格式不相同。目前，我司支持G-BIER（Generalized BIER，通用位索引显式复制）和BIERv6（Bit Index Explicit Replication IPv6 Encapsulation，IPv6封装的比特索引显式复制）封装类型。
· G-BIER为中国移动提出的一种通用BIER封装方案，它根据IPv6网络的特点对BIER头进行适配性修改，与IPv6更好地进行融合。有关G-BIER报文封装的详细介绍，请参见“3.1 G-BIER报文格式”。
· BIERv6是基于Native IPv6的全新组播方案，BIERv6结合了IPv6和BIER的优势，可以无缝融入SRv6网络，简化了协议复杂度。有关BIERv6报文封装的详细介绍，请参见“4.1 BIERv6报文格式”。
在BFR上配置的BIER信息（SD、BFR prefix、BFR ID等），通过IGP协议在BIER域内泛洪。IGP根据邻居泛洪的BIER信息计算BIER最短路径树（以BFIR为根，Transit BFR和BFER为叶子）。BFR根据BIER最短路径树，生成BIRT，最终进一步生成用于指导BIER转发的BIFT。
如图3所示，BIER域中包含支持BIER和不支持BIER的节点（Device G）。对于不支持BIER的节点，会将其所有的子节点作为叶子节点加入到BIER最短路径树，如果子节点不支持BIER，则继续往下迭代到支持BIER的子节点。比如，Device G不支持BIER，Device G会将子节点Device C和Device E的BIER信息传递给Device B，在Device B上生成下一跳邻居为非直连邻居Device C和Device E的BIFT表项信息。
图3 BIER控制平面BIFT
组播报文到达BFIR，BFIR查找组播转发表得到该组播表项对应的BIFT-ID和BS，BS即组播报文穿越BIER域后到达的全部BFER集合。BFIR根据BIFT-ID匹配到指定BIFT，并根据报文头中携带的Bit String与BIFT表项匹配计算后复制转发。BIER报文到达BFER节点后解封成组播报文，根据组播地址查找组播转发表进行转发。
当BIER转发过程中需要经过非BIER节点，即BFR的下一跳邻居为非直连邻居时，可以通过特定的技术来穿越非BIER节点。特定的技术取决于BIER封装的外层封装（比如，MPLS封装依靠LSP穿过非BIER节点，IPv6封装可以按普通IPv6单播路由到非直连BIER邻居）。
下面以具体的示例来说明BIER转发过程。如图4所示，BIER子域中的每台设备都根据IGP协议计算生成了BIFT。Device D和Device E的下游存在某个组播组的接收者，Device A作为BFIR通过BGP MVPN路由收集到Device D和Device E上与Device A处于相同BIER子域的MVPN信息。当Device A收到发往该组播组的组播报文时，BIER转发过程如下：
(1) Device A收到IP组播报文后，查找组播转发表项，得到该组播表项对应的BIFT-ID和BS，根据BIFT-ID找到对应的BIFT表，将BS与BIFT表中每行表项F-BM进行“位与”操作，复制组播报文并按照BIER报文格式封装（封装的BS为“位与”计算后得到的值），发送给下一跳邻居Device B。
(2) Device B收到BIER报文后，根据BIER头中的BIFT-ID和BS，执行与步骤(1)相同的步骤，发现下一跳邻居为Device C和Device E，需要经过非BIER的节点Device G。此时，可以通过特定的技术穿越非BIER节点，复制组播报文并按照BIER报文格式封装后，发给Device C和Device E。
(3) Device C收到BIER报文后，执行与步骤(1)相同的操作，将组播报文复制一份，并按照BIER报文格式封装后，发给Device D和Device F。
(4) Device D、Device E和Device F收到BIER报文后，发现只有本节点对应的F-BM与上游发送的BIER报文中的BS进行“位与”操作后不为0，表明本节点为BFER，需要结束BIER转发。此时，Device D、Device E和Device F分别从BIER头部解封装出组播报文后，根据组播路由表项继续转发给下游接收者。
图4 BIER报文转发过程示意图
BIER信息（BFR prefix、Sub-domain、BFR ID等信息）通过IS-IS BIER扩展，并在BIER子域中进行发布。收到BIER信息的节点，若支持BIER转发，IS-IS将识别出BIER信息并生成对应的BIFT；若不支持BIER转发，则IS-IS无需识别所收到的BIER信息，直接进行泛洪。
RFC8401定义了BIER信息的发布机制，具体是在IS-IS Reachability Prefix TLV（定义在RFC5308中的TLV 236，定义在RFC5120中的TLV 237）中携带一个BIER Info Sub-TLV的方式实现。
BIER Info Sub-TLV格式如图5所示。
BIER Info Sub-TLV各字段的含义如下：
· Type：8bits，Sub-TLV的类型，取值为32，表示BIER Info Sub-TLV。
· Length：8bits，BIER Info Sub-TLV长度。
· BAR：8bits，BIER算法，用于计算到达BFER的路径。
· IPA：8bits，IGP算法，表示IGP增强或改进算法，可替代BAR算法。
· sub-domain-id：8bits，BIER子域的ID。
· BFR-ID：16bits，用来在一个BIER子域中唯一标识一台BIER边缘设备。
· sub-sub-TLVs(variable)：可变长度，表示不同的BIER封装类型（比如MPLS封装、G-BIER封装、BIERv6封装等）。
G-BIER（Generalized BIER，通用位索引显式复制）为中国移动携手新华三、华为、中兴等厂商提出的一种通用BIER封装方案，它根据IPv6网络的特点对RFC定义的标准的BIER头进行适配性修改，与IPv6实现了更好的融合。
对G-BIER报文的封装是通过在组播数据报文前面添加新的IPv6基本头和BIER头实现的。如图6所示，IPv6基本头中Next Header取值为60，表明下一个报文头为DOH（Destination Options Header，目的选项头）。
对于G-BIER报文，IPv6基本头中有如下约定：
· Source Address：源地址需要配置为BFIR的组播服务源地址，该源地址由BFIR的前缀地址和组播服务ID值共同生成。BFIR的前缀地址用来标识BFIR的网络位置，组播服务ID用来标识不同的MVPN实例。组播报文在转发过程中，该源地址保持不变。
· Destination Address：目的地址需要配置为专门用于BIER转发的MPRA（Multicast Policy Reserved Address，组播策略保留地址），该地址要求在子域内路由可达。当BFR收到IPv6报文中的目的地址为本地配置MPRA，则表示需要对该报文进行G-BIER转发。
图6 G-BIER的报文封装示意图
G-BIER报文中的BIER头主要包含以下几个部分：
· Next Header：8bits，用来标识下一个报文头的类型。
· Hdr Ext Len：8bits，表示IPv6扩展头长度。
· Option Type：8bits，选项类型为G-BIER。
· Option Length：8bits，选项长度。
· BSL：4bits，取值用1～7来代表不同比特串长度，取值与比特串长度的对应关系如下：
¡ 1：表示比特串长度为64bits。
¡ 2：表示比特串长度为128bits。
¡ 3：表示比特串长度为256bits。
¡ 4：表示比特串长度为512bits。
¡ 5：表示比特串长度为1024bits。
¡ 6：表示比特串长度为2048bits。
¡ 7：表示比特串长度为4096bits。
· SD：8bits，BIER子域ID。
· SI：8bits，集标识。
· Rsv：保留字段。
· TTL：8bits，和IP报文中的TTL意义相同，可以用来防止环路。
· Version：4bits，版本号，目前只支持0。
· Entropy：20bits，用来在存在等价路径时，进行路径的选择。拥有相同Bit String和Entropy值的报文，选择同一条路径。
· OAM：4bits，缺省值为0，可用于OAM功能。
· DSCP：7bits，报文自身的优先等级，决定报文传输的优先程度。
· Bit String：位串。
G-BIER的转发过程与BIER类似，请参考“2.6 BIER转发过程”。
如图7所示，在跨AS部署组播业务的场景下，参与跨域的所有域内路由器需要加入同一个BIER子域，AS 1的ASBR 1通过EBGP协议将AS 1内的的BFR ID汇总发布给AS 2，从而让AS 2的节点上建立到达AS 1内BFR ID对应的BFER的BIRT及BIFT。
以ASBR之间建立EBGP邻居为例，由ASBR 1通过单播主机路由携带自身的BIER信息（如SD、BSL、Max-SI、MPRA等）将其发布给跨域BGP邻居ASBR 2，ASBR 2上建立起到AS 1内各BFER的BIRT和BIFT。
ASBR 2将AS 1的BIER信息进一步在AS 2内发布，有如下两种方法：
· 使用IGP引入EBGP所携带的BIER信息
ASBR 2将EBGP路由引入到IGP进行泛洪，在整个AS 2的范围内引入BIER信息，并生成跨域的BIRT和BIFT。同时，G-BIER对IS-IS BIER做了进一步扩展，IS-IS除了携带原来支持的Sub-domain、BSL和MPRA，还需携带跨域引入的BFR ID的范围。
图7 跨AS BIER信息通告（IGP方式）
· 使用IBGP将EBGP所携带的BIER信息仅发布给AS 2内的BFIR
ASBR 2通过路由策略向BFIR重新发布BIER信息，BFR prefix为ASBR 2节点的主机路由前缀，下一跳为ASBR 2节点的IPv6地址，路由所携带的BIER信息包括ASBR 2的SD、BSL、MPRA以及通过ASBR 2所能到达的AS 1中的BFR ID范围。BFIR从ASBR 2收到携带BIER信息的路由后、建立到AS 1内各BFR ID的BIRT和BIFT。
图8 跨AS BIER信息通告（IBGP方式）
RFC8401定义了BIER的Sub-domain信息发布机制，具体参见“2.7 IS-IS BIER扩展”。IS-IS G-BIER扩展了BIER Info Sub-TLV，新增如下三种sub-sub-TLV：
(1) G-BIER能力sub-sub-TLV
G-BIER通过在BIER Info Sub-TLV中新增G-BIER能力sub-sub-TLV发布本节点的G-BIER能力，该sub-sub-TLV的具体格式如图9所示。
图9 G-BIER能力sub-sub-TLV
G-BIER能力sub-sub-TLV各字段的含义如下：
¡ Type：8bits，sub-sub-TLV的类型，取值为6，表示具有G-BIER能力的sub-sub-TLV。
¡ Length：8bits，TLV长度。
¡ Max-SI：8bits，集标识的最大值。
¡ BSL：4bits，比特串长度。
¡ Reserved：20bits，保留字段，用于字节对齐。
(2) G-BIER MPRA sub-sub-TLV
G-BIER需要在BFR上配置专门用于BIER转发的组播策略保留地址MPRA，并通过IS-IS发布本节点的MPRA，以通知其它邻居在向本节点发送G-BIER报文时，使用该IPv6地址作为IPv6目的地址。
作为G-BIER封装的一部分，MPRA需要通过在BIER Info sub-TLV中新增G-BIER MPRA sub-sub-TLV发布，该sub-sub-TLV格式如图10所示。
G-BIER MPRA sub-sub-TLV各字段的含义如下：
¡ Type：8bits，sub-sub-TLV的类型，取值为7，表示G-BIER MPRA sub-sub-TLV。
¡ Length：8bits，TLV长度。
¡ MPRA：128bits，组播策略保留地址。
¡ Extension：暂不定义具体格式及其含义补充，并不作处理。
(3) G-BIER BFR-ids sub-sub-TLV
Inter-AS G-BIER场景下，IS-IS引入EBGP携带的BIER信息的同时，通过新增的BFR-ids sub-sub-TLV携带ASBR引入的跨域可达的BFR ID范围，该sub-sub-TLV的格式如图11所示。
图11 G-BIER BFR-ids sub-sub-TLV
G-BIER BFR-ids sub-sub-TLV各字段的含义如下：
¡ Type：8bits，sub-sub-TLV的类型，取值为8，表示G-BIER BFR-ids sub-sub-TLV。
¡ Length：8bits，TLV长度。
¡ BFR-ID start：16bits，跨域可达的BFR ID范围的起始值。
¡ BFR-ID end：16bits，跨域可达的BFR ID范围的最大值。
Inter-AS G-BIER场景下，网络节点将G-BIER信息封装在BGP Update消息中，BGP报文中携带的G-BIER信息分为两部分：
· BFR prefix：封装在Update消息的NLRI字段中。
· G-BIER Path Attribute（BIER路径属性）：一种新定义的路由属性，该路由属性包含了G-BIER的G-BIER子域、BFR ID、BSL、MPRA等信息。
图12 G-BIER路径属性
如图12所示，BGP为G-BIER新增的G-BIER路径属性包含以下字段：
· Flags：BGP属性标记位，取值为0xd0，表示该属性为包含了完整信息的可选传递属性。
· Type：路径属性的类型，取值为67。
· Length：路径属性的长度，单位为字节。
· Sub-TLV：路径属性携带的子TLV，为可变长度。子TLV中携带了G-BIER信息。
G-BIER路径属性的子TLV（G-BIER Sub-TLV）格式如图13所示。
G-BIER Sub-TLV各字段的含义如下：
· Type：Sub-TLV的类型，取值为1，表示具有G-BIER能力的Sub-TLV。
· Length：Sub-TLV的长度，单位为字节。
· Sub Domain：G-BIER子域ID。
· BFR ID：发布该路由的G-BFER的BFR ID。
· Reserved：保留字段，用于字节对齐。
· Sub-Sub-TLVs(Optional)：Sub-TLV携带的子TLV，为可变长度。
G-BIER Sub-TLV目前支持的三类G-BIER Sub-Sub-TLV分别为：BSL Sub-Sub-TLV、MPRA Sub-Sub-TLV和BFR ID range Sub-Sub-TLV。
(1) BSL Sub-Sub-TLV
BSL Sub-Sub-TLV用于通告节点支持的BSL及Max SI，格式如图14所示。
BSL Sub-Sub-TLV各字段的含义如下：
· Type：Sub-Sub-TLV的类型，取值为1。
· Length： Sub-Sub-TLV长度，取值为4，单位为字节。
· BSL：比特串长度。
· Max SI：集标识最大取值。
· Reserved：保留字段，用于字节对齐。
(2) MPRA Sub-Sub-TLV
MPRA Sub-Sub-TLV用于通告节点的组播策略保留地址，格式如图15所示。
MPRA Sub-Sub-TLV各字段的含义如下：
· Type：Sub-Sub-TLV的类型，取值为2。
· Length：Sub-Sub-TLV的长度，取值大于16，单位为字节。
· MPRA：组播策略保留地址，长度为128位。
· Extension：扩展字段，为可变长度。暂不定义本字段的具体格式及含义。
(3) BFR-ID range Sub-Sub-TLV
BFR-ID range Sub-Sub-TLV用于通告本AS内已知的BFR ID的范围，格式如图16所示。
BFR-ID range Sub-Sub-TLV各字段含义如下：
· Type：Sub-Sub-TLV的类型。
· Length：Sub-Sub-TLV的长度，取值为4的整数倍，单位为字节。
· BFR ID start：BFR ID范围的起始值。
· BFR ID end：BFR ID范围的最大值。
NG MVPN over G-BIER场景下，使用G-BIER建立承载隧道，组播私网流量经过G-BIER封装后穿越公网发送到BIER子域其他各节点。
NG MVPN over G-BIER的控制平面包括以下特有的技术实现：
· 接收者PE信息收集
该场景中，组播源侧PE首先获知组播流量要发送给哪些接收者侧PE，然后组播源侧PE根据收到的私网组播流量封装Bit String。其中，MVPN中各PE成员的收集机制与RSVP-TE和mLDP模式下的MVPN过程类似。
· 新增BIER类型隧道属性
为了支持NG MVPN over G-BIER，RFC8556定义了在BGP MVPN业务中使用BIER隧道时所需要的信息，即一个BIER类型的PTA（PMSI Tunnel attribute，PMSI隧道属性）。在BGP MVPN业务使用G-BIER隧道时，使用上述BIER类型的PTA。其中，PTA的MPLS Label字段原本用于标识MVPN实例的上游分配标签，在基于G-BIER隧道的MVPN中不再使用该字段，而是使用一个新的BGP属性携带用于标识MVPN实例的IPv6源地址（组播服务源地址），该BGP属性称为MSID（Multicast Service Identifier，组播服务ID）。相应的，PTA中MPLS Label字段值则被设置为0。
在MVPN over G-BIER中，新增的BGP属性MSID用来标识MVPN实例，MSID中的组播服务源地址通过组播源侧PE在1类路由Intra-AS I-PMSI A-D route中携带，通告给接收者侧PE。接收者侧PE记录该源地址与MVPN实例的对应关系。当接收侧PE收到G-BIER封装的组播报文时，会通过报文中的组播服务源地址找到相应的MVPN实例，在对应的MVPN实例中找到对应的组播转发表项，并转发组播报文。
BGP MSID属性及其内容遵循BGP属性定义的格式要求，格式如图17所示。
MSID Attribute各字段的含义如下：
· Attribute Flags：8bits，属性标识。
· Attribute Type：8bits，属性类别字段，属性名为MSID。
· Attribute Length：16bits，属性长度。
· Attribute Data：可变长度，属性数据。采用无固定字段的Sub-TLV表示。
Attribute Data为无固定字段的Sub-TLV，具体格式如图18所示。
Sub-TLV各字段的含义如下：
· Sub-TLV Type：8bits，Sub-TLV类型。
· Sub-TLV Length：16bits，Sub-TLV长度。
· Reserved：8bits，保留字段。
· IPv6 address：IPv6源地址。
· sub-sub-TLV：可变长度，表示本Sub-TLV携带的sub-sub-TLV，目前仅支持Structure sub-sub-TLV。
Structure sub-sub-TLV的格式如图19所示。
Structure sub-sub-TLV各字段的含义如下：
· sub-sub-TLV Type：8bits，sub-sub-TLV类型，取值为1，表示Structure sub-sub-TLV。
· sub-sub-TLV Length：16bits，sub-sub--TLV长度，取值为5。
· Flags：8bits，标志字段用于后续扩展，目前要求为0。
· Prefix Length：8bits，前缀长度。
· MSID Length：8bits，组播服务ID的长度。
· Must Be Zero：16bits，保留字段。
(1) MVPN扩展团体属性介绍
MVPN的扩展团体属性主要用于C-multicast路由的发布和接收，包括以下两种类型：
· Source AS Extended Community：该属性用于标识组播源所在的AS号，用于跨域场景。
· VRF Route Import Extended Community：该属性用于标识组播源侧PE的IP地址以及组播源所在的VPN实例。
Source AS Extended Community以及VRF Route Import Extended Community在扩展团体属性中的格式分别如图20和图21所示。
图20 Source AS Extended Community的格式
Source AS Extended Community包含如下字段：
· Type：扩展团体属性的类型，取值为0x00（表示2字节AS号类型的扩展团体属性）或0x02（表示4字节AS号类型的扩展团体属性）。
· Sub-Type：扩展团体属性的子类型，取值为0x09，表示该扩展团体属性为Source AS Extended Communit。
· Global Administrator：组播源所在的AS号，可以是2字节形式的AS号，也可以是4字节形式的AS号。
· Local Administrator：取值为0，暂无特殊含义。
图21 VRF Route Import Extended Community的格式
VRF Route Import Extended Community包含如下字段：
· Type：扩展团体属性的类型，取值为0x01（表示IPv4地址类型的扩展团体属性）或无取值（表示IPv6地址类型的扩展团体属性）。
· Sub-Type：扩展团体属性的子类型，取值为0x0b（IPv4地址类型的扩展团体属性时的取值）或0x000b（IPv6地址类型的扩展团体属性时的取值），表示该扩展团体属性为VRF Route Import Extended Community。
· IPv4/IPv6 address：组播源侧PE的IP地址。
· Local Administrator：组播源所处的VPN实例。
(2) MVPN扩展团体属性的工作机制
如图22所示，PE 1和PE 2都是组播源测PE，PE 3为接收侧PE。PE 1和PE 2都与VPN 1以及公网实例的站点相连，PE 1上VPN 1的VRF Route Import Extended Community值为1.1.1.1:1；PE 1上公网实例的VRF Route Import Extended Community值为1.1.1.1:0（公网实例的VRF Route Import Extended Community中Local Administrator的值必须为0）；PE 1上Source AS Extended Community的值为10:0。PE 2上VPN 1的VRF Route Import Extended Community值为2.2.2.2:1；PE 2上公网实例的VRF Route Import Extended Community值为2.2.2.2:0（公网实例的VRF Route Import Extended Community中Local Administrator的值必须为0）；PE 1上Source AS Extended Community的值为10:0。
图22 MVPN扩展团体属性工作机制
PE 1和PE 2都与PE 3建立BGP MVPN地址族的BGP会话后，PE 1和PE 2都会向PE 3发布到组播源的单播路由信息，其中VPN实例的组播源单播路由信息通过BGP VPNv4或VPNv6路由携带，公网实例的组播源单播路由信息通过BGP IPv4/IPv6单播路由或BGP IPv4/IPv6组播路由携带。所有通告到组播源的单播路由信息的BGP路由均会携带Source AS Extended Community和VRF Route Import Extended Community。
PE 3接收到通告到组播源的单播路由信息的BGP路由后，会对BGP路由进行优选，然后将路由携带的Source AS Extended Community和VRF Route Import Extended Community存储下来，用于后续构造C-multicast路由。在本例中假设PE 3优选了来自PE 1的通告到VPN 1组播源的单播路由信息的BGP路由，以及优选了来自PE 2的通告到公网实例组播源的单播路由信息的BGP路由。
VPN实例VPN 1以及公网实例的C-multicast路由构造过程如下：
· 当PE 3收到来自CE 3的组播加入消息后，会构造C-multicast路由，然后向PE 1和PE 2发送，这个路由的Source AS字段为收到的Source AS Extended Community中的AS号，路由携带的Route Target属性为BGP优选路由的VRF Route Import Extended Community，即1.1.1.1:1。
¡ PE 1收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是1.1.1.1，即本地的源接口地址，接收C-multicast路由。随即PE 1根据RT属性中的Local Administrator确定C-multicast路由属于VPN实例VPN 1，将C-multicast路由添加到VPN 1的组播路由表中。
¡ PE 2收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是1.1.1.1，不是本地的源接口地址，丢弃C-multicast路由。
后续处于VPN 1的组播源发送组播报文时，由于仅PE 1形成了组播表项，组播报文会在PE 1进行G-BIER封装后通过G-BIER公网隧道发送到PE 3，在PE 3上进行解封装后转发到CE 3。
· 当PE 3收到来自CE 4的组播加入消息后，会构造C-multicast路由，然后向PE 1和PE 2发送，这个路由的Source AS字段为收到的Source AS Extended Community中的AS号，路由携带的Route Target属性为BGP优选路由的VRF Route Import Extended Community，即2.2.2.2:0。
¡ PE 2收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是2.2.2.2，即本地的源接口地址，接收C-multicast路由。随即PE 2根据RT属性中的Local Administrator确定C-multicast路由属于公网实例，将C-multicast路由添加到公网实例的组播路由表中。
¡ PE 1收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是2.2.2.2，不是本地的源接口地址，丢弃C-multicast路由。
后续处于公网实例的组播源发送组播报文时，由于仅PE 2形成了组播表项，组播报文会在PE 2进行G-BIER封装后通过G-BIER公网隧道发送到PE 3，在PE 3上进行解封装后转发到CE 4。
NG MVPN over G-BIER运行机制如下：
(1) 组播源侧PE首先通过与接收者PE交互BGP MVPN路由，获知组播流量需要发送给哪些接收者侧PE。
(2) 组播源侧PE和接收者侧PE之间通过BGP报文中携带的Intra-AS I-PMSI A-D Route、S-PMSI A-D Route和Leaf A-D Route三大路由信息传递BIER信息（BFR ID、Sub domain ID、BFR prefix）。
(3) 组播数据根据PIM路由表由CE传输到PE上的相容性隧道时完成了私网到公网的无缝连接，组播源侧PE将收到私网组播数据封装G-BIER头后，通过相容性隧道传输给远端PE，远端PE收到该报文后通过剥离标签信息将其还原成私网组播报文。
(4) 当组播源侧PE上有满足切换选择性隧道条件的组播流量时，建立选择性隧道，并通过选择性隧道传输封装了G-BIER头的私网组播数据。
如图23所示，私网侧采用PIM协议，公网为BIER网络。在PE 1、PE 2和PE 3上均部署了BGP和MVPN之后，相容性隧道的创建过程如下：
(1) PE 1向PE 2和PE 3发送1类路由Intra-AS I-PMSI A-D Route，该路由携带以下信息：
¡ Route Target：用于控制路由的发布和接收，配置为PE 1的Export Target。
¡ PMSI Tunnel attribute：用于传递隧道信息。其中，Tunnel Type字段取值为BIER隧道，并通过PMSI Tunnel attribute携带PE 1的BIER信息（Sub domain ID、BFR ID、BFR prefix）。
(2) PE 2和PE 3接收到PE 1发送的1类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接收此路由，并向PE 1回复4类路由Leaf A-D route，该路由携带以下信息：
¡ Route Target：用于控制路由的发布和接收，配置为PE 2或者PE 3的Export Target。
¡ PMSI Tunnel attribute：用于传递隧道信息。其中，Tunnel Type字段取值为BIER隧道，并通过PMSI Tunnel attribute携带各自与PE 1处于相同BIER子域的BIER信息（通过从PE 1发送的1类路由中获取到的Sub domain ID查找到本地相同的子域中配置的BFR ID和BFR prefix）。
(3) PE 1收到PE 2和PE 3发送的4类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接收此路由，并将PE 2和PE 3记录为MVPN的成员。同时，根据收到的4类路由中携带的BFR ID和对应BIER子域内配置的BSL的值，计算得到SI。PE1将所有叶子的信息合并，就生成了指定（S，G）对应的Bit String，即BIER类型的相容性隧道。
当相容性隧道接收到指定（S，G）表项的组播流量时，若私网报文满足隧道切换条件，则进行选择性隧道切换，实现了不同组播流量传输的隧道分离。一个VPN实例内允许存在多个选择性隧道。
如图24所示，创建选择性隧道并进行隧道切换的具体过程如下：
(1) PE 1向PE 2和PE 3发送3类路由S-PMSI A-D Route，该路由携带以下信息：
¡ Route Target：用于控制路由的发布和接收，配置为PE 1的Export Target。
¡ PMSI Tunnel attribute：用于传递隧道信息。其中，Tunnel Type字段取值为BIER隧道，并通过PMSI Tunnel attribute携带PE 1的BIER信息（Sub domain ID、BFR ID、BFR prefix）。
(2) PE 2和PE 3接收到PE 1发送的1类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接收此路由。如果下游存在接收者，则向PE 1回复4类路由Leaf A-D route，否则丢弃该路由。回复的4类路由携带以下信息：
¡ Route Target：用于控制路由的发布和接收，配置为PE 2或者PE 3的Export Target。
¡ PMSI Tunnel attribute：用于传递隧道信息。其中，Tunnel Type字段取值为BIER隧道，并通过PMSI Tunnel attribute携带各自与PE 1处于相同BIER子域的BIER信息（通过从PE 1发送的1类路由中获取到的Sub domain ID查找到本地相同的子域中配置的BFR ID和BFR prefix）。
(3) PE 1收到PE 2和PE 3发送的4类路由后，检查此路由中的Route Target属性与本地VPN实例配置的Import Target是否匹配。如果匹配，则接收此路由，并将PE 2和PE 3记录为MVPN的成员。同时，根据收到的4类路由中携带的BFR ID和对应BIER子域内配置的BSL的值，计算得到SI。PE1将所有叶子的信息合并，就生成了指定（S，G）对应的Bit String，即BIER类型的选择性隧道。
NG MVPN over G-BIER转发过程如图25所示。
(1) Device A（Ingress PE节点，G-BIER域BFIR节点）从CE 1收到来自MVPN实例组播报文，然后依次进行如下处理：
a. 查找MVPN实例对应的组播转发表，确定组播报文在BIER类型的PMSI隧道上转发，并获取到BIER PMSI的BIFT ID为0x30100、Bit String为0111。
b. 根据BIFT ID和Bit String查找本地G-BIER转发表，确定向邻居Device B转发。
c. 复制组播报文，将IPv6目的地址封装为Device B的MPRA，BIER封装的BIFT ID为0x30100、Bit String为0011（由“0111”与BIFT中Device B对应的F-BM值“0011”通过“位与”运算得到）。
(2) Device B收到报文，将报文的目的地址与本地配置的组播策略保留地址进行匹配，若能匹配成功，则执行G-BIER转发，否则进行普通的IP转发。匹配成功后，根据BIFT ID=0x30100、BitString=0011查找本地G-BIER转发表，确定向邻居Device C和Device E转发。以向Device E转发为例，复制组播报文，将IPv6目的地址封装为Device E的MPRA，BIER封装的BIFT ID为0x30100、Bit String为0100（由“0011”与BIFT中Device E对应的F-BM值“0100”通过“位与”运算得到）。
(3) Device E收到报文，将报文的目的地址与本地配置的组播策略保留地址进行匹配，若能匹配成功，则执行G-BIER转发，否则进行普通的IP转发。同时，BIER封装的Bit String匹配到本节点BFR ID对应的Bit String，则表示本节点为BFER，将要对G-BIER报文做解封装进行后续的组播转发。通过将G-BIER报文中的IPv6头和G-BIER头解封装后得到IP组播报文，IP组播报文将根据MVPN实例对应组播转发表进行后续的组播转发。
如图26所示，G-BIER承载组播业务的可靠性保护包括组播源侧、G-BIER域和组播接收者侧三方面：
· 组播源侧的可靠性保护，采用G-BIER域双根1+1机制，其中Root 1和Root 2互为G-BIER主备双根，组播源通过交换机SW1和SW2分别与主备双根连接。
· G-BIER域的可靠性保护，采用双流机制，具体为G-BIER域Root 1和Root 2向G-BIER域叶子节点（Leaf 1和Leaf 2）分别发送相同的组播流量。在叶子节点上对稳定组播流部署流量检测功能，当检测到组播流量未从主根所在链路到达时，表示主根所在链路存在故障，此时叶子节点将选择接收从备根所在链路发来的组播流量，从而大幅提高组播业务收敛速度，提高可靠性。对间歇流不部署流量检测（故障恢复依赖路由收敛）。
· 接收者侧的可靠性保护，采用的方式为：OLT通过双机热备（S-Trunk、VRRP等方式）双归接入Leaf，双归的两个Leaf形成保护组，Leaf之间通过双机热备实现用户组播表项同步，双机热备与Leaf保护组联动实现倒换保护。
图26 G-BIER双根1+1热备份
正常情况下，Leaf 1和Leaf 2通过互相备份，会收到来自Root 1和Root 2两份相同的组播流，Leaf 1根据路由优选策略选择Root 1为主根，接收来自主根Root 1的流量，丢弃来自备根Root 2的流量；Leaf 2根据路由优选策略选择Root 2为主根，接收来自主根Root 2的流量，丢弃来自备根Root 1的流量。同时，Leaf 1和Leaf 2会按流量选择规则，选择出其中一台设备将流量转发给OLT，从而转发给组播接收者。
如图27所示，组播源发往G-BIER域中叶子节点（Leaf）的组播流量转发经过的任一节点发生故障，都需要有可靠性保护机制保障流量快速恢复。
图27 双根1+1热备份组播源侧或G-BIER域内故障（不包括Leaf节点）
(1) 故障检测
叶子节点Leaf 1和Leaf 2均以一定的周期进行流量检测，如果叶子节点在两个周期内未收到来自各自主根节点（Leaf 1的主根Root 1、Leaf 2的主根为Root 2）的流量，则认为当前的主根节点故障。
(2) 故障切换
a. 主根节点故障发生时，叶子节点切换为接收来自备根的流量。
b. 主根节点故障恢复后，叶子节点重新收到主根节点的组播流量。为了减少不必要的切换，根据不同的本地配置进行流量处理：
- Leaf 1设置为不回切模式，不回切到接收Root 1的流量，继续接收来自Root 2的流量。直到Leaf 1检测到来自Root 2的组播流中断，才切换为接收Root 1的流量。
- Leaf 1设置为回切模式，则在主根Root 1流量正常的条件下，到达设定的等待恢复时限后，Leaf 1回切为继续接收来自主根Root 1的流量，并同时停止接收来自Root 2的流量。
G-BIER OAM（Operations, Administration, and Maintenance，操作、管理和维护）用于检测G-BIER转发路径的连通性和定位G-BIER路径的故障点。G-BIER OAM支持Ping和Tracert两种诊断方式：
· G-BIER Ping用于检查G-BIER数据平面的连通性。
· G-BIER Tracert在检查网络连接是否可达的同时，还可以分析G-BIER网路中什么地方发生了故障。
这两种诊断方式均首先使用IPv6头和UDP头对OAM Request报文进行内层封装，然后将封装后的OAM Request报文再封装外层G-BIER头，最后通过BIER隧道发送。G-BIER OAM需要在响应端打开一个UDP监听端口，用于监听和接收OAM Request报文，默认的UDP端口号为49100。G-BIER OAM响应端收到OAM Request报文后，通过UDP报文进行回复。
G-BIER OAM支持的Ping和Tracert均使用G-BIER Echo Request/Reply报文进行网络诊断。Echo Request/Reply报文的封装格式如图28所示。
图28 G-BIER OAM Echo Request报文格式
G-BIER OAM Request/Reply报文各字段的含义如下：
(1) G-BIER头部：有关G-BIER头部字段的详细介绍，请参见“3.1 G-BIER报文格式”。
(2) 内层IPv6头部：
¡ Source Address：32bits，IPv6源地址。对于Request报文，IPv6源地址和外层G-BIER头部中的IPv6源地址保持一致；对于Reply报文，IPv6源地址为目的节点的BFR prefix。
¡ Destination Address：32bits，IPv6目的地址。对于Request报文，为固定值0:0:0:0:0:FFFF:7F00:1；对于Reply报文，对应于Request报文的外层IPv6源地址。
(3) UDP头部：
¡ Source Port：16bits，UDP源端口号。
¡ Destination Port：16bits，UDP目的端口号。
¡ UDP Length：16bits，UDP数据报长度。
¡ UDP Checksum：16bits，UDP校验值，可以检验数据在传输过程中是否被损坏。
G-BIER的Ping用于检测Underlay层的连通性，不依赖于任何基于G-BIER的组播业务配置，只要G-BIER的Underlay层部署完就可以进行。
G-BIER的Ping处理的基本过程如下：由BIER域任意节点发起G-BIER Echo Request报文、由目标BFER节点响应G-BIER Echo Reply报文，完成整个Ping过程。如果发起节点在一定的时间内没有收到目标BFER节点的响应，则打印timeout信息。
G-BIER Ping的过程如图29所示。图中Ping过程的报文信息以Device A→Device B→Device C→Device D之间的报文交互为例。
Device A（Ping发起节点）根据命令指定的参数（目的节点的BFR ID列表等），查找本地BIER子域对应配置，获得BIER三元组信息（BSL、SD、SI），通过三元组信息可以唯一确定BIFT ID，通过BIFT ID查找本地G-BIER转发表，发起Ping过程。
(1) Device A按BIFT ID=0x30100查找本地G-BIER转发表，确定向邻居Device B转发Echo Request报文，转发时外层G-BIER封装的目的IPv6地址为Device B的MPRA，BS为“0011”。
(2) 报文到达中间节点Device B和Device C后，中间节点按照G-BIER转发表进行组播转发，直到目的节点。
(3) 目的节点Device D收到Echo Request报文，向源节点Device A回复Echo Reply报文。
(4) Device A收到Echo Reply报文，报文关键字段与Device A发送的Echo Request报文不匹配，则忽略。匹配上，则输出应答信息。
(5) Device A在指定的等待时间内没有收到指定目的节点的应答，则输出超时信息。
G-BIER Tracert运行机制包括以下三个阶段：
(1) 源端发起探测
从BIER TTL=1开始第一轮探测，TTL = 2/3/4/…进行后续的探测。
(2) 中间节点处理
中间节点收到Echo Request后，如果G-BIER头中的BIER TTL没有减到0，则正常转发。BIER TTL减到0后，如果存在转发表项，则返回Code为5的Echo Reply报文（Packet-Forward-Success，报文被成功转发），否则返回Code为8的Echo Reply报文（No matching entry in forwarding table，G-BIER转发表项中没有匹配的表项）。
(3) 目的端应答
BFER节点收到Echo Request后，返回Code为3或者4的Echo Reply报文。
¡ Code为3（Replying BFR is the only BFER in header Bitstring）：表示目的端应答BFR是G-BIER OAM Echo Request报文头中所携带的BitString唯一对应的BFER。
¡ Code为4（Replying BFR is one of the BFER in header Bitstring）：表示目的端应答BFR是G-BIER OAM Echo Request报文头中所携带的BitString对应的其中一个BFER。
已收到响应的BFR不再参与后续的探测，当所有待探测的节点都探测完成时即可结束探测。探测完成可以是源端收到所有待探测节点返回Code为3或者4的Echo Reply报文，或者达到系统默认的探测次数。探测完成后，源端打印到达探测BFER的路径信息。
G-BIER Tracert过程第一轮（BIER TTL=1）如图30所示。
图30 G-BIER Tracert过程第一轮
Device A（Tracert发起节点）根据命令指定的参数（目的节点的BFR ID列表等），查找本地BIER子域对应配置，获得BIER三元组信息（BSL、SD、SI），通过三元组信息可以唯一确定BIFT ID，通过BIFT ID查找本地G-BIER转发表，发起Tracert过程。
(1) Device A按BIFT ID=0x30100查找本地G-BIER转发表，确定向邻居Device B转发G-BIER Echo Request报文，转发时外层G-BIER封装的目的IPv6地址为Device B的MPRA、TTL为1、Downstream Mapping TLV携带Device B的BFR prefix。
(2) Device B收到的Echo Request报文后，TTL减为0，并向发起节点发送Echo Reply报文。由于Device B为Transit节点，发送的Echo Reply报文通过Downstream Mapping TLV携带下游Device C和Device E的BFR prefix，Responder BFR TLV携带Device B的BFR prefix。
(3) Device A收到Echo Reply报文后，将报文关键字段与Device A发送的Echo Request报文进行匹配，如果匹配失败，则忽略此响应报文，否则打印应答信息。
G-BIER Tracert过程第二轮（BIER TTL=2）过程如图31所示。图中Tracert过程的报文信息以Device A→Device B→Device C→Device D第二轮报文交互为例。
图31 G-BIER Tracert过程第二轮
(1) Device A按BIFT ID=0x30100查找本地G-BIER转发表，确定向邻居Device B转发G-BIER Echo Request，转发时外层G-BIER封装的目的IPv6地址为Device B的MPRA、TTL为2、Downstream Mapping TLV携带Device C和Device E的BFR prefix（从上一轮的Echo Reply中拷贝）。
(2) Device B按照G-BIER转发表进行组播转发，转发到Device C。
(3) Device C收到的Echo Request报文后，TTL减为0，并向发起节点发送Echo Reply报文。由于Device C为Transit节点，发送的Echo Reply报文携带通过Downstream Mapping TLV携带下游Device D的BFR prefix，Responder BFR TLV携带Device C的BFR prefix。
(4) Device A收到Echo Reply报文后，将报文关键字段与Device A发送的Echo Request报文进行匹配，如果匹配失败，则忽略此响应报文，否则打印应答信息。
后续轮次不赘述，处理与上述类似。
在实际的G-BIER组网中，存在控制平面支持G-BIER而转发平面由于硬件限制不支持G-BIER的设备。此时，需要在这类设备上开启G-BIER PHP（Penultimate Hop Popping，倒数第二跳弹出）功能，这类设备在通过IS-IS协议泛洪G-BIER信息时，会携带G-BIER PHP字段通告同一BIER子域内的其他BFR，它没有G-BIER转发能力。其他BFR设备在G-BIER转发过程中，如果发现下一跳邻居为此设备，则会将G-BIER报文中的的DOH头（包含G-BIER头）弹出后发送给该设备。该设备收到此报文后，根据组播路由表项继续转发给下游接收者。
在G-BIER域中，不支持G-BIER转发的节点称为G-BIER PHP Request节点。由于该节点没有G-BIER转发能力，不能作为Transit BFR和BFIR使用，只能作为BFER。G-BIER PHP功能配置在该节点上。
G-BIER PHP Request节点的BFR邻居节点称为G-BIER PHP Response节点。该节点在处理转发给G-BIER PHP Request节点的报文时，需要将DOH头弹出后发给G-BIER PHP Request节点。
如图32所示，Device D不支持G-BIER转发功能，此时需要在Device D（G-BIER PHP Request节点）上部署G-BIER PHP功能。Device C为Device D的BFR邻居（G-BIER PHP Response节点）。
Device D通过IGP发布PHP请求。在Device C上，IGP要根据收到的G-BIER信息计算G-BIER最短路径树（以BFIR为根，Transit BFR和BFER为叶子）。BFR根据G-BIER最短路径树，生成BIRT，最终生成用于指导G-BIER转发的BIFT。在构造G-BIER最短路径树时，对于不支持G-BIER转发功能的BFER节点Device D，Device C在收到Device D的IGP通告后，根据PHP请求生成对应的G-BIER BIFT转发表项，BIFT转发表项中记录对G-BIER邻居节点Device D需要弹出DOH头。最终各节点上生成的BIFT表项如图32所示，Device D上未生成和维护BIFT表项。
图32 G-BIER PHP控制平面
支持G-BIER转发能力的设备的具体转发过程参见“2.6 BIER转发过程”，此处不再赘述。本节重点讲述G-BIER Request和Response节点的转发过程。
如图33所示，Device C在收到Device B发送的G-BIER报文后，查找本设备上的BIFT表项，发现向邻居Device D转发G-BIER报文时，需要将DOH头弹出后发送给Device D。Device D在收到目的IPv6地址为本设备的MPRA且不带DOH头的报文后，将根据IPv6源地址中的MSID识别MVPN实例，剥掉外层IPv6封装后，再把内层组播数据根据对应VPN中组播转发表项进行转发。
图33 G-BIER PHP转发平面
BIERv6（Bit Index Explicit Replication IPv6 Encapsulation，IPv6封装的比特索引显式复制）是基于Native IPv6的全新组播方案，BIERv6结合了IPv6和BIER的优势，可以无缝融入SRv6网络，简化了协议复杂度。将BIER承载报文的封装类型配置为BIERv6时，需要BIER子域内的所有的BFR均支持SRv6。
对BIERv6报文的封装是通过在组播数据报文前面添加新的IPv6基本头和BIERv6头实现的。如图34所示，IPv6基本头中Next Header取值为60，表明下一个报文头为DOH（Destination Options Header，目的选项头）。
对于BIERv6报文，IPv6基本头中有如下约定：
· Source Address：源地址需要配置为BIERv6隧道的源地址，在组播报文在公网中转发时，该源地址保持不变。有关BIERv6隧道源地址的详细介绍，请参见“IP组播配置指导”中的“组播VPN”。
· Destination Address：目的地址需要配置为专门用于BIER转发的End.BIER SID，该地址要求在子域内路由可达。
BIERv6头主要包含以下几个部分：
· Next Header：8bits，用来标识下一个报文头的类型。
· Hdr Ext Len：8bits，表示IPv6扩展头长度。
· Option Type：8bits，选项类型为BIERv6。
· Option Length：8bits，表示BIERv6报文头长度。
· BIFT-ID：20bits，位索引转发表ID，用来唯一标识一张BIFT。
· TC：3bits，Traffic Class，流量等级，用于QoS。
· S：1bits，保留字段。
· TTL：8bits，表示报文经过BIERv6转发处理的跳数。每经过一个BIERv6转发节点后，TTL值减1。当TTL为0时，报文被丢弃。
· Nibble：4bits，保留字段，目前只支持0。
· Version：4bits，BIERv6报文版本号，目前只支持0。
· BSL：4bits，取值用1～7来代表不同比特串长度，取值与比特串长度的对应关系如下：
¡ 1：表示比特串长度为64bits。
¡ 2：表示比特串长度为128bits。
¡ 3：表示比特串长度为256bits。
¡ 4：表示比特串长度为512bits。
¡ 5：表示比特串长度为1024bits。
¡ 6：表示比特串长度为2048bits。
¡ 7：表示比特串长度为4096bits。
· Entropy：20bits，用来在存在等价路径时，进行路径的选择。拥有相同Bit String和Entropy值的报文，选择同一条路径。
· OAM：2bits，缺省为0，可用于OAM功能。
· Rsv：2bits，保留字段，缺省为0。
· DSCP：6bits，报文自身的优先等级，决定报文传输的优先程度。
· Proto：6bits，下一层协议标识，用于标识BIERv6报文头后面的Payload类型。
· BFIR ID：16bits，BFIR的BFR ID值。
· Bit String：位串。
图34 BIERv6的报文封装示意图
BIERv6的转发过程与BIER类似，请参考“2.6 BIER转发过程”。
RFC8401定义了BIER的Sub-domain信息发布机制，具体参见“2.7 IS-IS BIER扩展”。IS-IS BIERv6扩展了BIER Info Sub-TLV，新增如下两种sub-sub-TLV：
(1) BIERv6封装信息sub-sub-TLV
BIERv6通过在BIER Info Sub-TLV中新增BIERv6封装信息sub-sub-TLV发布本节点的Max-SI和BSL，该sub-sub-TLV的具体格式如图35所示。
图35 BIERv6封装信息sub-sub-TLV
BIERv6封装信息sub-sub-TLV各字段的含义如下：
¡ Type：8bits，sub-sub-TLV的类型，取值为6，表示携带BIERv6的封装信息。
¡ Length：8bits，TLV长度。
¡ Max-SI：8bits，BIERv6子域中集标识的最大值。
¡ BSL：4bits，比特串长度。
¡ Reserved：20bits，保留字段，用于字节对齐。
(2) BIERv6 End.BIER sub-sub-TLV
BIERv6需要在BFR上配置专门用于BIER转发的End.BIER SID，并通过IS-IS发布本节点的End.BIER SID，以通知其它邻居在向本节点发送BIERv6报文时，使用该IPv6地址作为IPv6目的地址。
作为BIERv6封装的一部分，End.BIER地址需要通过在BIER Info sub-TLV中新增BIERv6 End.BIER sub-sub-TLV发布，该sub-sub-TLV格式如图36所示。
图36 BIERv6 End.BIER sub-sub-TLV
BIERv6 End.BIER sub-sub-TLV各字段的含义如下：
¡ Type：8bits，sub-sub-TLV的类型，取值为3，表示携带End.BIER SID。
¡ Length：8bits，TLV长度。
¡ End.BIER SID：128bits，End.BIER地址。
¡ Extension：暂不定义具体格式及其含义补充，并不作处理。
NG MVPN over BIERv6场景下，使用BIERv6建立承载隧道，组播私网流量经过BIERv6封装后穿越公网发送到BIER子域其他各节点。
NG MVPN over BIERv6的控制平面包括以下特有的技术实现：
· 接收者PE信息收集
该场景中，组播源侧PE首先获知组播流量要发送给哪些接收者侧PE，然后组播源侧PE根据收到的私网组播流量封装Bit String。其中，MVPN中各PE成员的收集机制与RSVP-TE和mLDP模式下的MVPN过程类似。
· 新增BIER类型隧道属性
为了支持NG MVPN over BIERv6，RFC8556定义了在BGP MVPN业务中使用BIER隧道时所需要的信息，即一个BIER类型的PTA（PMSI Tunnel attribute，PMSI隧道属性）。在BGP MVPN业务使用BIERv6隧道时，使用上述BIER类型的PTA。其中，PTA的MPLS Label字段原本用于标识MVPN实例的上游分配标签，在基于BIERv6隧道的MVPN中不再使用该字段，而是使用一个新的BGP属性携带用于标识MVPN实例的IPv6源地址（src-dt4或src-dt6），该BGP属性称为Prefix-SID。相应的，PTA中MPLS Label字段值则被设置为0。
在MVPN over BIERv6中，BGP属性Prefix-SID用来携带BIERv6隧道封装的IPv6源地址，BIERv6组播源侧PE通过在1类路由Intra-AS I-PMSI A-D route和3类路由S-PMSI A-D route中携带Prefix-SID，将隧道源地址通告给接收者侧PE。接收者侧PE收到1类和3类路由后，根据路由携带的Route Target属性匹配本地的VPN实例或公网实例，并记录路由携带的Prefix-SID与VPN实例或公网实例的对应关系。接收侧PE收到BIERv6封装的组播报文时，会根据报文中的BIERv6隧道源地址找到对应的VPN实例或公网实例，在VPN实例或公网实例对应的MVPN实例中建立组播转发表项，并转发组播报文。
BGP Prefix-SID属性及其内容遵循RFC标准定义的格式要求，格式如图37所示。
BGP Prefix-SID各字段的含义如下：
· TLV Type：TLV的类型。取值为5，表示SRv6承载的是三层业务；取值为6，表示SRv6承载的是二层业务。
· TLV Length：TLV的长度。
· Reserved：保留字段。
· SRv6 Service Sub-TLVs：Prefix-SID的相关业务信息，为可变长度。
SRv6 Service Sub-TLV包含如下字段：
· SRv6 Service Sub-TLV Type：Prefix-SID业务信息的类型，固定取值为1，表示SRv6 SID Information Sub-TLV。
· SRv6 Service Sub-TLV Length：SRv6 Service Sub-TLV的长度。
· SRv6 Service Sub-TLV Value：SRv6 Service Sub-TLV的取值，长度可变。
类型为SRv6 SID Information Sub-TLV时，SRv6 Service Sub-TLV包含如下字段：
· SRv6 Service Sub-TLV Type：SRv6 Service Sub-TLV的类型，固定取值为1。
· SRv6 Service Sub-TLV Length：SRv6 SID Information Sub-TLV的长度。
· Reserverd1：保留字段。
· SRv6 SID Value：Prefix-SID的值。表示BIERv6隧道源地址的Src.DT4 SID和Src.DT6 SID由此字段携带。
· SRv6 SID Flags：Prefix-SID的标记，固定取值为0。
· SRv6 Endpoint Behavior：Prefix-SID的类型。取值0x45表示Src.DT4 SID，取值0x44表示Src.DT6 SID。
· Reserverd2：保留字段。
(1) MVPN扩展团体属性介绍
MVPN的扩展团体属性主要用于C-multicast路由的发布和接收，包括以下两种类型：
· Source AS Extended Community：该属性用于标识组播源所在的AS号，用于跨域场景。
· VRF Route Import Extended Community：该属性用于标识组播源侧PE的IP地址以及组播源所在的VPN实例。
Source AS Extended Community以及VRF Route Import Extended Community在扩展团体属性中的格式分别如图38和图39所示。
图38 Source AS Extended Community的格式
Source AS Extended Community包含如下字段：
· Type：扩展团体属性的类型，取值为0x00（表示2字节AS号类型的扩展团体属性）或0x02（表示4字节AS号类型的扩展团体属性）。
· Sub-Type：扩展团体属性的子类型，取值为0x09，表示该扩展团体属性为Source AS Extended Communit。
· Global Administrator：组播源所在的AS号，可以是2字节形式的AS号，也可以是4字节形式的AS号。
· Local Administrator：取值为0，暂无特殊含义。
图39 VRF Route Import Extended Community的格式
VRF Route Import Extended Community包含如下字段：
· Type：扩展团体属性的类型，取值为0x01（表示IPv4地址类型的扩展团体属性）或无取值（表示IPv6地址类型的扩展团体属性）。
· Sub-Type：扩展团体属性的子类型，取值为0x0b（IPv4地址类型的扩展团体属性时的取值）或0x000b（IPv6地址类型的扩展团体属性时的取值），表示该扩展团体属性为VRF Route Import Extended Community。
· IPv4/IPv6 address：组播源侧PE的IP地址。
· Local Administrator：组播源所处的VPN实例。
(2) MVPN扩展团体属性的工作机制
如图40所示，PE 1和PE 2都是组播源测PE，PE 3为接收侧PE。PE 1和PE 2都与VPN 1以及公网实例的站点相连，PE 1上VPN 1的VRF Route Import Extended Community值为1.1.1.1:1；PE 1上公网实例的VRF Route Import Extended Community值为1.1.1.1:0（公网实例的VRF Route Import Extended Community中Local Administrator的值必须为0）；PE 1上Source AS Extended Community的值为10:0。PE 2上VPN 1的VRF Route Import Extended Community值为2.2.2.2:1；PE 2上公网实例的VRF Route Import Extended Community值为2.2.2.2:0（公网实例的VRF Route Import Extended Community中Local Administrator的值必须为0）；PE 1上Source AS Extended Community的值为10:0。
图40 MVPN扩展团体属性工作机制
PE 1和PE 2分别与PE 3建立BGP MVPN地址族的BGP会话后，PE 1和PE 2都会向PE 3发布到组播源的单播路由信息，其中VPN实例的组播源单播路由信息通过BGP VPNv4或VPNv6路由携带，公网实例的组播源单播路由信息通过BGP IPv4/IPv6单播路由或BGP IPv4/IPv6组播路由携带。所有通告到组播源的单播路由信息的BGP路由均会携带Source AS Extended Community和VRF Route Import Extended Community。
PE 3接收到通告到组播源的单播路由信息的BGP路由后，会对BGP路由进行优选，然后将路由携带的Source AS Extended Community和VRF Route Import Extended Community存储下来，用于后续构造C-multicast路由。在本例中假设PE 3优选了来自PE 1的通告到VPN 1组播源的单播路由信息的BGP路由，以及优选了来自PE 2的通告到公网实例组播源的单播路由信息的BGP路由。
VPN实例VPN 1以及公网实例的C-multicast路由构造过程如下：
· 当PE 3收到来自CE 3的组播加入消息后，会构造C-multicast路由，然后向PE 1和PE 2发送，这个路由的Source AS字段为收到的Source AS Extended Community中的AS号，路由携带的Route Target属性为BGP优选路由的VRF Route Import Extended Community，即1.1.1.1:1。
¡ PE 1收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是1.1.1.1，即本地的源接口地址，接收C-multicast路由。随即PE 1根据RT属性中的Local Administrator确定C-multicast路由属于VPN实例VPN 1，将C-multicast路由添加到VPN 1的组播路由表中。
¡ PE 2收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是1.1.1.1，不是本地的源接口地址，丢弃C-multicast路由。
后续处于VPN 1的组播源发送组播报文时，由于仅PE 1形成了组播表项，组播报文会在PE 1进行BIERv6封装后通过BIERv6公网隧道发送到PE 3，在PE 3上进行解封装后转发到CE 3。
· 当PE 3收到来自CE 4的组播加入消息后，会构造C-multicast路由，然后向PE 1和PE 2发送，这个路由的Source AS字段为收到的Source AS Extended Community中的AS号，路由携带的Route Target属性为BGP优选路由的VRF Route Import Extended Community，即2.2.2.2:0。
¡ PE 2收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是2.2.2.2，即本地的源接口地址，接收C-multicast路由。随即PE 2根据RT属性中的Local Administrator确定C-multicast路由属于公网实例，将C-multicast路由添加到公网实例的组播路由表中。
¡ PE 1收到C-multicast路由后，对比C-multicast路由RT属性中携带的IP地址，发现是2.2.2.2，不是本地的源接口地址，丢弃C-multicast路由。
后续处于公网实例的组播源发送组播报文时，由于仅PE 2形成了组播表项，组播报文会在PE 2进行BIERv6封装后通过BIERv6公网隧道发送到PE 3，在PE 3上进行解封装后转发到CE 4。
NG MVPN over BIERv6运行机制与G-BIER类似，具体请参见“3.4.3 NG MVPN over G-BIER运行机制”。
NG MVPN over BIERv6转发过程如图41所示。
(1) Device A（Ingress PE节点，BIERv6域BFIR节点）从CE 1收到来自MVPN实例组播报文，然后依次进行如下处理：
a. 查找MVPN实例对应的组播转发表，确定组播报文在BIER类型的PMSI隧道上转发，并获取到BIER PMSI的BIFT ID为0x30100、Bit String为0111。
b. 根据BIFT ID和Bit String查找本地BIERv6转发表，确定向邻居Device B转发。
c. 复制组播报文，将IPv6目的地址封装为Device B的End.BIER SID，BIER封装的BIFT ID为0x30100、Bit String为0011（由“0111”与BIFT中Device B对应的F-BM值“0011”通过“位与”运算得到）。
(2) Device B收到报文，将报文的目的地址与本地配置的End.BIER SID进行匹配，若能匹配成功，则执行BIERv6转发，否则进行普通的IP转发。匹配成功后，根据BIFT ID=0x30100、BitString=0011查找本地BIERv6转发表，确定向邻居Device C和Device E转发。以向Device E转发为例，复制组播报文，将IPv6目的地址封装为Device E的End.BIER SID，BIER封装的BIFT ID为0x30100、Bit String为0100（由“0011”与BIFT中Device E对应的F-BM值“0100”通过“位与”运算得到）。
(3) Device E收到报文，将报文的目的地址与本地配置的End.BIER SID进行匹配，若能匹配成功，则执行End.BIER SID转发，否则进行普通的IP转发。同时，BIER封装的Bit String匹配到本节点BFR ID对应的Bit String，则表示本节点为BFER，将要对BIERv6报文做解封装进行后续的组播转发。通过将BIERv6报文中的IPv6头和BIERv6头解封装后得到IP组播报文，IP组播报文将根据MVPN实例对应组播转发表进行后续的组播转发。
BIERv6的可靠性保护实现与G-BIER类似，具体请参见“3.5 G-BIER的可靠性保护”。
BIERv6 OAM（Operations, Administration, and Maintenance，操作、管理和维护）用于检测BIERv6转发路径的连通性和定位BIERv6路径的故障点。BIERv6 OAM支持Ping和Tracert两种诊断方式：
· BIERv6 Ping用于检查BIERv6数据平面的连通性。
· BIERv6 Tracert在检查网络连接是否可达的同时，还可以分析BIERv6网路中什么地方发生了故障。
这两种诊断方式均首先使用IPv6头和UDP头对OAM Request报文进行内层封装，然后将封装后的OAM Request报文再封装外层BIERv6头，最后通过BIERv6隧道发送。BIERv6 OAM需要在响应端打开一个UDP监听端口，用于监听和接收OAM Request报文，默认的UDP端口号为49100。BIERv6 OAM响应端收到OAM Request报文后，通过UDP报文进行回复。
BIERv6 OAM支持的Ping和Tracert均使用BIERv6 Echo Request/Reply报文进行网络诊断。Echo Request/Reply报文的封装格式如图42所示。
图42 BIERv6 OAM Echo Request报文格式
BIERv6 OAM Request/Reply报文各字段的含义如下：
(1) BIERv6头部：有关BIERv6头部字段的详细介绍，请参见“4.1 BIERv6报文格式”。
(2) 内层IPv6头部：
¡ Source Address：32bits，IPv6源地址。对于Request报文，IPv6源地址和外层IPv6源地址保持一致；对于Reply报文，IPv6源地址为目的节点的BFR prefix。
¡ Destination Address：32bits，IPv6目的地址。对于Request报文，为固定值0:0:0:0:0:FFFF:7F00:1；对于Reply报文，对应于Request报文的外层IPv6源地址。
(3) UDP头部：
¡ Source Port：16bits，UDP源端口号。
¡ Destination Port：16bits，UDP目的端口号。
¡ UDP Length：16bits，UDP数据报长度。
¡ UDP Checksum：16bits，UDP校验值，可以检验数据在传输过程中是否被损坏。
BIERv6的Ping用于检测Underlay层的连通性，不依赖于任何基于BIERv6的组播业务配置，只要BIERv6的Underlay层部署完就可以进行。
BIERv6的Ping处理的基本过程如下：由BIER域任意节点发起BIERv6 Echo Request报文、由目标BFER节点响应BIERv6 Echo Reply报文，完成整个Ping过程。如果发起节点在一定的时间内没有收到目标BFER节点的响应，则打印timeout信息。
BIERv6 Ping的过程如图43所示。图中Ping过程的报文信息以Device A→Device B→Device C→Device D之间的报文交互为例。
Device A（Ping发起节点）根据命令指定的参数（目的节点的BFR ID列表等），查找本地BIER子域对应配置，获得BIER三元组信息（BSL、SD、SI），通过三元组信息可以唯一确定BIFT ID，通过BIFT ID查找本地BIERv6转发表，发起Ping过程。
(1) Device A按BIFT ID=0x30100查找本地BIERv6转发表，确定向邻居Device B转发Echo Request报文，转发时外层BIERv6封装的目的IPv6地址为Device B的End.BIER SID，BS为“0011”。
(2) 报文到达中间节点Device B和Device C后，中间节点按照BIERv6转发表进行组播转发，直到目的节点。
(3) 目的节点Device D收到Echo Request报文，向源节点Device A回复Echo Reply报文。
(4) Device A收到Echo Reply报文，报文关键字段与Device A发送的Echo Request报文不匹配，则忽略。匹配上，则输出应答信息。
(5) Device A在指定的等待时间内没有收到指定目的节点的应答，则输出超时信息。
BIERv6 Tracert运行机制包括以下三个阶段：
(1) 源端发起探测
从BIER TTL=1开始第一轮探测，TTL = 2/3/4/…进行后续的探测。
(2) 中间节点处理
中间节点收到Echo Request后，如果BIERv6头中的BIER TTL没有减到0，则正常转发。BIER TTL减到0后，如果存在转发表项，则返回Code为5的Echo Reply报文（Packet-Forward-Success，报文被成功转发），否则返回Code为8的Echo Reply报文（No matching entry in forwarding table，BIERv6转发表项中没有匹配的表项）。
(3) 目的端应答
BFER节点收到Echo Request后，返回Code为3或者4的Echo Reply报文。
¡ Code为3（Replying BFR is the only BFER in header Bitstring）：表示目的端应答BFR是BIERv6 OAM Echo Request报文头中所携带的BitString唯一对应的BFER。
¡ Code为4（Replying BFR is one of the BFER in header Bitstring）：表示目的端应答BFR是BIERv6 OAM Echo Request报文头中所携带的BitString对应的其中一个BFER。
已收到响应的BFR不再参与后续的探测，当所有待探测的节点都探测完成时即可结束探测。探测完成可以是源端收到所有待探测节点返回Code为3或者4的Echo Reply报文，或者达到系统默认的探测次数。探测完成后，源端打印到达探测BFER的路径信息。
BIERv6 Tracert过程第一轮（BIER TTL=1）如图44所示。
图44 BIERv6 Tracert过程第一轮
Device A（Tracert发起节点）根据命令指定的参数（目的节点的BFR ID列表等），查找本地BIER子域对应配置，获得BIER三元组信息（BSL、SD、SI），通过三元组信息可以唯一确定BIFT ID，通过BIFT ID查找本地BIERv6转发表，发起Tracert过程。
(1) Device A按BIFT ID=0x30100查找本地BIERv6转发表，确定向邻居Device B转发BIERv6 Echo Request报文，转发时外层BIERv6封装的目的IPv6地址为Device B的End.BIER SID、TTL为1、Downstream Mapping TLV携带Device B的BFR prefix。
(2) Device B收到的Echo Request报文后，TTL减为0，并向发起节点发送Echo Reply报文。由于Device B为Transit节点，发送的Echo Reply报文通过Downstream Mapping TLV携带下游Device C和Device E的BFR prefix，Responder BFR TLV携带Device B的BFR prefix。
(3) Device A收到Echo Reply报文后，将报文关键字段与Device A发送的Echo Request报文进行匹配，如果匹配失败，则忽略此响应报文，否则打印应答信息。
BIERv6 Tracert过程第二轮（BIER TTL=2）过程如图45所示。图中Tracert过程的报文信息以Device A→Device B→Device C→Device D第二轮报文交互为例。
图45 BIERv6 Tracert过程第二轮
(1) Device A按BIFT ID=0x30100查找本地BIERv6转发表，确定向邻居Device B转发BIERv6 Echo Request，转发时外层BIERv6封装的目的IPv6地址为Device B的End.BIER SID、TTL为2、Downstream Mapping TLV携带Device C和Device E的BFR prefix（从上一轮的Echo Reply中拷贝）。
(2) Device B按照BIERv6转发表进行组播转发，转发到Device C。
(3) Device C收到的Echo Request报文后，TTL减为0，并向发起节点发送Echo Reply报文。由于Device C为Transit节点，发送的Echo Reply报文携带通过Downstream Mapping TLV携带下游Device D的BFR prefix，Responder BFR TLV携带Device C的BFR prefix。
(4) Device A收到Echo Reply报文后，将报文关键字段与Device A发送的Echo Request报文进行匹配，如果匹配失败，则忽略此响应报文，否则打印应答信息。
后续轮次不赘述，处理与上述类似。
IPv6省干网和IPv6城域网处于不同的自治域，组播源通过省干网业务路由器PSR接入省干网路由器PB，向城域网的终端用户提供从运营商网络到家庭/企业网络IPTV业务。为了保证业务高可靠性，采用双根热备份方式，PSR 1和PSR 2分别为BIER主备双根，组播源通过以太网交换机SW 1和SW 2分别与主备双根连接。
IPTV服务中应用BIER技术，不需要建立从组播源侧节点到组播接收者侧节点的组播发分发树，中间节点的无需运行组播路由协议和维护组播转发状态。可以满足组播用户快速加入和组播业务快速部署的要求。
图46 在公网部署BIER组播业务典型组网应用
IPv6省干网和IPv6城域网处于不同的自治域，组播源通过省干网业务路由器PSR接入省干网路由器PB，向城域网的终端用户提供从运营商网络到家庭/企业网络IPTV业务。为了保证业务高可靠性，采用双根热备份方式。其中，PSR 1和PSR 2分别为BIER主备双根，组播源通以太网交换机SW 1和SW 2分别与主备双根连接。
在省网和城域网中应用BIER技术，处于VPN a的组播源Source 2通过CE 1接入城域网AS 21，组播数据通过运营商网络的MVPN承载，为位于相同VPN a的组播接收者提供组播服务。
图47 在MVPN部署BIER组播业务典型组网应用
· 中国移动IPv6组播G-BIER方案
· RFC8279：Multicast Using Bit Index Explicit Replication (BIER)
· RFC8296：Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks
· RFC8401：Bit Index Explicit Replication (BIER) Support via IS-IS
支持
售前咨询
售后咨询
人工在线咨询
