西门子武汉电信IPTV解决方案承载网部分

武汉电信 IPTV解决方案 承载网部分 北京西门子通信网络 股份 有限公司 2005西门子版权所有 /webmoney 2 目 录 1 背景分析 .3 2 武汉电信 IP TV承载网部署分析 .6 2.1 武汉电信城域网 IP核心层 . 6 2.2 武汉电信城域网 IP边缘层 . 7 2.3 武汉电信城域网 IP层协议分析 . 8 2.4 武汉电信城域网汇聚层 . 9 2.5 武汉电信城域网用户接入层 . 9 3 承载网关键问题分析 . 11 3.1 接入汇聚层组播复制点的选择 . 11 3.2 部署组播需要注意的问题 . 17 3.2.1 组播上行的保证 . 17 在上行链路上使用 QoS控制机制 . 17 单独构建专用的组播传输通道 . 17 3.2.2 组播下行质量的保证 . 17 控制端口的用户数量 . 18 在用户下行链路上使用 QoS保证组播数据 . 18 3.3 组播安全性保证 . 19 4 不同用户规模网络模型分析 . 20 4.1 方案一：采用现有城域网直接承载（ 5-10万用户以下适用） . 20 4.1.1 组播 复制点在 BRAS上（适合最少用户时） . 20 4.1.2 组播复制点在 DSLAM上（适合较多用户时） . 21 4.2 方案二：在现有城域网上叠加 VPN承载 . 23 4.3 方案三：设置专网承载 . 25 4.4 西门子建议实施步骤 . 26 5 组播方案案例 . 27 5.1 上海组网方案 . 27 5.2 广西组网方案 . 28 6 附录：组播的实现原理 . 29 6.1 组播路由协议 PIM SM. 29 6.2 主机路由协议 IGMP. 32 6.3 MSDP协议 . 33 6.4 Anycast RP. 33 /webmoney 3 1 背景分析 目前， IPTV承载的最主要内容包括视频点播 (VOD)及电视频道 (TV)节目。为了能够实现较好的 IPTV效果，不仅对于节目源，编解码， 等视频处理部分有较高要求，对于目前武汉电信承载网也提出了新的要求， IPTV承载网要求能在带宽、频道切换时延、网络 QoS等方面提供 更好的 保证 。 带宽： 在采用西门子先进的 H.264编码基础上 要求每个 IPTV用户接入带宽达 到 2M左右，其中视频码流部分约 1.6M左右，包含声音、 PPPOE开销及其他负荷在内后建议采用 2M带宽。 频道切换时延：有线电视网的频道切换非常快， IPTV也应尽量减少端到端时延，据 IPTV用户调查，用户可接受 2秒的 TV频道切换时间及 10秒下的VOD切换时间。 QoS：丢包、抖动等都会严重影响 IPTV的收看质量，会让用户觉得IPTV比不上有线电视的感觉。 因此随着城域网发展，我们建议逐步在武汉电信城域网 部署 QoS，对于 IPTV等 能够带来收入、 性能敏感 的 业务建议分配较高的优先级，能够更好的保证 IPTV的质量 ,具体 QoS策略见方案描述。 IPTV承载网络的技术要求对国内电信运营商的宽带网络提出了 新的挑战，如果不在目前的宽带网络上应用组播等新技术，以目前的宽带网络的性能是无法满足大规模开展商用 IPTV业务的要求的。组播技术目前在国内电信运营商还没大规模应用，但它的特点使其特别适合 IPTV这类用户量大，消耗大带宽的业务。 组播 组播是指在 IP网络中，数据包以尽力传送的形式发送到所有网络节点的某个确定子集。 IP组播的基本思想是源 IP主机只发送一份数据，一个或多个接收者可接收相同数据的拷贝。组播的最大优点是节省了网络的带宽及服务器资源。不同用户如果接收同一个组播流，服务器只需发达一份数据 ，网络只需在用户的分支点进行复制，在分支点以上的网络只需传送一个数据流。 /webmoney 4 IPTV的 直播 类节目是最适合利用组播技术传输的，因为 TV类节目所有用户收看的都是同一个内容 ，西门子在实现直播业务 采用了主流厂商普遍采用的 组播技术，在武汉电信现有城域网络中实现 IPTV中应用组播需要考虑以下几个问题： 1.组播复制点问题 组播复制点即用户 IGMP请求的终结点。在组播复制点，网络设备根据端口是否有 IGMP请求向端口复制组播流。组播复制点越接近用户越能节省网络带宽。 但是对于设备的要求也就更高。 2.静态组播 VS动态组播 静态组播指组播分发树静态建立，组播流不管有没用户接收都沿分发树传输；动态组播指利用组播路由协议 (如 PIMSM/DM)动态建立组播分发树，组播分发树的建立是根据用户是否有 IGMP请求建立的。 由于动态组播需要建立组播分发树再进行组播数据的传输，而静态组播已经把组播数据传输到组播复制点，用户的 IGMP请求一经接收即可进行分发，所以静态组播的时延比动态组播小， 但是带宽浪费也比较严重。 3.组播 QoS 组播是基于 UDP协议的，这意味着组播没有丢包重传 机制。 这一方面减少了数据传输的延时， 但 另一方面也增加了 丢包对于视频效果的影响。因此对于 IP TV业务实行高优先级 的 QoS，从而得到较高的转发级别显得 尤为重要。 目前武汉电信 骨干网络 刚刚进行了扩容与升级 ， 骨干网络 QoS的保证能力大大提高 ，已经初步具备了实行 QoS的能力 。 但是对于接入网络由于建设时间较早，设备参差不齐导致对于 QoS支持能力不一致 ，因此我们认为武汉电信城域网络向支持 QoS的城域网演进的重点和难点在接入网络，应该加以着重的分析和讨论。 同时网络的 IPTV用户的容量对于 IP TV承载网所应该采取的策略 也有着重要的影响。 /webmoney 5 下面我们将对在武汉电信城域网络内实施 IP TV直播以及点播业务的技术方案在承载网层面的重点和要点进行分析。 /webmoney 6 2 武汉电信 IP TV承载 网 部署分析 IP TV 视频业务目前主要包括 VOD 点播以及直播业务以及增值业务 部分 ，其中 VOD 点播以及直播业务是最主要影响承载网部署的因素，由于点播业务与直播业务采用了不同的传送技术对于承载网的影响也不相同 。 点播业务采用较传统的点到点传送方式，与目前城域网上的流量 基本相似，对于承载网的影响相对简单，主要是对于 QoS 及带宽上的需求。 直播 业务采用了 当频道以组播 形式发送到网络中后，由网络边缘相应的组播复制点对媒体流进行复制，以有效减轻核心网络的压力。 直播业务所对应的组播流量 将 是目前武汉电信 承载网 上的一种全新的流量， 采用有效、合理的技术以及组网方案实现 IP 直播业务的传送是 IP TV 业务成功地要素之一，也是我们重点分析的内容。 武汉电信现有的承载网主要是针对点对点的单播业务设计 和实现 的 ，现有的承载网需要进行适当的演进和改造才能更好的适应 IP TV 业务， 对于武汉电信城域网我们可以分为两部分进行分析，一部分是启用了三层协议的 IP 层，另一个以二层接入为基础的接入层。对于 IP 层 我们 又可以进一步细分为 IP 核心层、 IP 边缘层 。对于接入层又可以细分为汇聚层以及用户接入层。下面我们将针对这几方面网络逐一进行分析、与建议。 2.1 武汉电信 城域网 IP 核心层 目前，武汉电信城域网 IP 骨干 部分 经过多次扩容目前情况 良好，无需大的改动能够较好 的适应 IP TV 业务的要求，原因简要分析 如下： IP 核心层 主要由 Cisco GSR12012、 GSR12416、 GSR12816 等高端路由器 搭建而成 ，总体 来讲 IP 核心层采用 高端 设备搭建。 性能、功能都比较先进，对组播有着比较好的支持能力。 武汉电信曾经在骨干网做过关于 组播的测试，测试结果比较令人满意。最近 IP 核心层 经过升级扩容，性能 、带宽得到了 进一步得到提升。 /webmoney 7 IP TV 的直播业务在经过 IP 层时采用组播方式传送，一个频道到一个组播复制点只需要一个数据流就可以了，无论该复制点下有多少用户在观看 。 因此可以节省大量的 IP 层 带宽资源 同时也减小了组播对于设备的压力。 2.2 武汉电信 城域网 IP 边缘层 目前武汉电信城域网 IP 边缘层路由器主要包括宽带接入服务器（ BRAS）以及业务路由器（ SR） 。目前宽带接入服务器的主要设备包括Juniper ERX1400 系列，以及华为 5200G产品为主。此 两款产品均属于业界较先进的 BRAS 产品，性能和功能都比较强。特别是 Juniper ERX1400 产品已经通过了多个国际组织和国内运营商的测试，被 普遍 认为是能够比较好的承担组播复制点工作的设备之一。 西门子推荐进行组播初期测试时尽量选用已经经过现网考验的 ERX 1400 设备作为初期测试的组播复制点，可能能够达到更好的效果 。 同时也应在华为 5200G产品上进行组播测试，为 全网推广做好准备工作。 武汉电信目前主要采用的 SR路由器为 Cisco 7600系列、 Cisco 6500系列 以及华为 8500系列。 目 前 武汉电信 IP 边缘层 还存在 着 部分设备在实现 透传 PPPoE 用户 数据的二层功能 的同时， 也负担着终结专线 用 户 VLAN 的三层的功能的情况，我们认为此种做法容易造成 L2/L3 边界不清晰 ，增加了设备的不稳定性同时也增加网管维护的难度 。 因此我们建议尽量将二层、三层网络点的边缘节点划分清晰，也就是将透传实现 PPPoE 透传功能的交换机于实现终结 VLAN 的交换机通过不同的设备分别实现。以保证二层、三层网络的清晰、高效。 更好的实现 IPTV 业务。 另外，目前武汉电信现网上也存在着 cisco 3550, Cisco 4500 系列 等中 低端交换机也承担 VLAN 终结任务的情况，我们认为从多年网络实际经验来看三层交换机设备在运行三层路由功能以及增值功能是的表现与路由器还是有一定差距，特别是 中低端交换机的三层性能更值得推敲。因此我们建议在城域网改造中尽量降低三层交换机的比例。 /webmoney 8 2.3 武汉电信 城域网 IP 层协议分析 对于武汉电信城域网 IP 层（包括 IP 核心层以及 IP 边缘层）采用何种组播协议是非常关键 的，影响到整个网络的运行效率以及稳定性。 组播路有技术虽然有很多，包括 PIM-SM、 PIM-DM、 MOSPF、MBGP 等，但是对于武汉电信而言选择并不困难。 但是 无论是从资源的合理优化，还是目前的技术的发展， PIM SM 协议都是目前最佳选用的协议。 包括上海电信在内绝大部分国内外运营商均采用了此种协议。 同时， PIM SM协议 需要一个 RP（组播汇聚点），所有的 PIM加入信息都要上传到 RP 点在进行建树，因此 RP 在组播中相当重要， RP 应为无单点故障，高可用性节点。 如果希望 实现冗余， 可在 每个组播域 选择 2台核心路由器担当 RP。考虑到通过 BSR或 Auto-RP 实现冗余起不到负载分担的目的，而且当主要 RP 失效时切换到备用 RP 有一个 PIM SM的协议收敛时间的问题，在此建议采用 Anycast RP 实现冗余和负载分担。 对于 武汉电信 IPTV 初期工程， 组播源 如果 集中在一个局域网中， 而RP 选 在组播源所在局域网直连的路由器或三层交换机上由于网络物理拓扑无冗余，可暂不考虑 RP 冗余的问题。 同时应该注意： 在城域网上开启组播应用时，所有的路由器端口应将PIM SM 模式打开，因为在双链路情况下，如只将某一链路相应端口打开，则在做 RPF 反向路径检测时，此组播路径未必为单播最好路径，这样就可能造成组播建立不起来而导致业务出现故障。 因此武汉电信 城域网 我们建议选 用 PIM-SM 稀疏模组播路由协议、 初期采用 单 点 RP 方式 ，随着网络发展逐渐过渡到采用 AnycastRP 方式 进行组播布置。 /webmoney 9 2.4 武汉电信 城域网 汇聚层 目前武汉电信汇聚层设备主要采用了 Cisco 4500 系列，以及华为 8500 系列，也存在少量 Cisco 3550 系列产品。汇聚交换机往往采用双上行结构，一条链路连接宽带接入服务器， 另一条上联 SR，用于专线业务。两条上行链路无法提供备份保护功能。 我们认为 如果将 IP TV 业务引入现网，武汉电信汇聚层 设备应该能够提供更好的备份机制，我们建议可以将汇聚的二层交换机通过光纤进行连接以起到备份作用。但如果二层汇聚 交换机启用普通的 STP 协议，对于故障 时间需要几十秒钟，就算采用 RSTP 协议仍然需要数秒钟的时间才能进行故障恢复，而对于不同于以往上网业务的 IP TV 业务 来讲数秒钟的网络中断很可能造成了连接的丢失，从而不得不重新建立连接，如果故障经常发生很容易造成用户满意度的降低。 因此，我们这里建议西门子 ERP（以太网环保护协议）很适合此种场合应用。 ERP 协议通过环形组网来达到链路保护的目的 。首先该协议采用环形组网，相比于双星连接可以很大程度上减少对于光纤数量的要求，对现网改动也较小。同时 理想情况下故障恢复的速度可以达到 50 毫秒级别，完全能够满足IP TV 需求，用户甚至感觉不到网络发生了中断。 另外 ERP 协议有着良好的兼容性，可以和其他不支持 ERP 协议的交换机共同工作。 因此我们建议可采用西门子推动的 ERP 协议用于武汉电信汇聚层网络。 2.5 武汉电信 城域网 用户接入层 武汉电信现有用户接入层主要由 DSLAM和低端交换机组成，其中 DSLAM数量最多，主要由华为、中兴 DSLAM搭建。 IPTV 业务平台及承载网络的主要服务对象为现有宽带接入用户，目前XDSL 已经成为宽带接入的主要手段。如果使用 ADSL 技术，其最大上行 /下行速率为 640Kbps/8Mbps。基本可以满足开展 IP TV 等宽带业务的带宽要求。但从“全业务，广覆盖”的角度出发，现有的 ADSL 应有计划的升级到 ADSL2 /webmoney 10 ，这样既可以满足对于高带宽的需求，也可以实现远距离接入以满足广覆盖的要求。可见，未来几年 ADSL2+将是宽带接入的主要形式。 对于 IP TV业务开展来说，基础就是承载网络中合理有效的组播部署， 为了方便的部署 IP TV业务，宽带接入局端设备必须支持 IGMP Snooping或者IGMP Proxy，基于用户端口的业务控制和分流也是必需的。能够基于用户端口加载 IP TV业 务属性，实现可控组播。灵活的 VLAN功能是实现业务分流的前提， SVLAN是很好的实现业务分流，用户隔离和定位的技术，宽带接入局端设备应支持 SVLAN功能。并且，考虑专线用户可能会有基于 VLAN的需求，因此 VLAN透传， VLAN终结和 VLAN翻译等功能将很有现实意义。 采用西门子方案情况下视频流只需要约 2M带宽，大大增加了可用的DSLAM范围。但我们仍建议对武汉电信 ADSL线路进行测试。 总体上来说， 对于 ADSL用户， 长度在 2.5公里之内的线路，速率可达到4M能够满足开展 IPTV业务的要求。在市区及郊区的县城 区域的实际线路情况，存在明显的差别，建议在实际开通业务时，还需进行实际测试。 通过 GTS系统，运维人员可以对 DSL的内线、外线进行测试，真正实现对宽带故障的“一点通”，不仅大大缩短了确定、排除故障的时间，而且减少了运维的人力成本。建议基于现网的 TAM工程要有条不紊的进行改造，而新供货的 DSLAM设备则明确要求具有 TAM功能。 虽然家庭娱乐通信方案是独立于承载网的，但如果运营商拥有高性能的承载网，则能够使业务的质量得到更可靠的保障。 具体说来，增值 业务驱动技术的发展 ， 基于新技术的 设备保障 增值 业务 的开展，有网络和设 备基础保证的新业务开展，才会最终带来 xDSL用户 ARPU值的提升和宽带业务的盈利。 /webmoney 11 3 承载网关键问题分析 3.1 接入汇聚层 组播复制点的选择 对于城域网承载 IP TV 业务有一个关键问题，就是 组播复制点的选择 ，这个问题决定着组播数据流在接入层次的工作 整体流程 ，同时也影响着 IP TV 实施 的难易程度，因此该问题是我们必须要认真面对和仔细分析的。 从目前 IP TV 发展情况来看，组播复制点通常在 选择在 BRAS 或者DSLAM上。 3.1.1 在 BRAS 上进行数据复制（少量用户阶段时推荐） 通常来讲组播复制点应该在距离用户的最近的三 层设备上，对于武汉电信最多的 PPPoE 用户而言组播复制的工作 自然可以 由 BRAS 承担。 如下图所示： BR A S 作组播复制点工作流程示意图V ideo on Deman dM idd le w ar eV er imat r ix T and b er gn Cu b eC A S /D RM Broadcast T V汇聚层I P Ed g e B R A S组播业务流组播复制在 IP Ed g e ，可采用 PP PoE 或 Web 方式认证优势接入网没有要求与其他业务共用平台运维集中控制劣势汇聚层带宽压力大 IP Edg e 设备性能要求高 在 BRAS 上进行组播数据复制，由 BRAS 作为 PPPoE 和组播的终结设备，同时 承载 传统 Internet上网和 IPTV 业务。 /webmoney 12 在这种模式下，用户将组播和一般的 Internet访问 都 封装在 PPPoE 的数据包里，通过 DSLAM 以及交换机等 二层传输设备，终结在作为宽带接入服务器的 BRAS 上。 DSLAM 及汇聚交换机对组播业务均不能感知 ，它们 不需要支持组播 ，也无法支持 。 对于由 ADSL Modem 发起 PPPoE 呼叫的 用户， ADSL Modem 需要支持IGMP Proxy，如果需要在系统中实现视频电话还需要支持对 SIP 协议的 NAT转换；对于由机顶盒发起 PPPoE 呼叫的用户， ADSL Modem 无任何特殊功能要求，但如果用户需要同时使用 IPTV 业务和基于 PC的 Internet业务则需要建立两个 PPPoE Session。 在 BRAS 实施组播数据复制的主要优势在于： BRAS 本身已经具有三层转发的能力，有能力支持组播数据的复制和转发，并且在 BRAS 上有相应的控制机制，来控制用户的组播服务的能力。不需要 DSLAM支持组播。 在 BRAS 上实施组播复制的主要弱点是，由于 BRAS 的接入用户相对集中，密度比较高，因此假如组播用户的密度较高的话，对 BRAS 的性能以及BRAS 与 DSLAM 间链路的带宽压力比较高，会对组播和传统 Internet 访问的稳定性产生一定影响。但组播协议本身对 BRAS 的 CPU 占用非常小，主要还是占用带宽，如果改用单播则肯定会占用更多的带宽。 ADSL 论坛正在起草一个标准，试图将 DSLAM 和 BRAS 协调在一起，由BRAS 作为控制单元负责组播控制信息的传送和解析，包括 IGMP 等，并有BRAS 控制在用户量较少时由 BRAS 复 制，当用户量较多时，转而将复制的工作交给 DSLAM。实现两种方式的平滑过渡。 目前 武汉电信 网上 的 Juniper ERX BRAS 设备宽带接入服务器有很好的组播复制和控制能力。已经在上海电信通过了组播 4000 用户无丢包的测试。同时 ERX 的组播协议和控制功能也很丰富，支持 PIM、 MSDP、 MBGP、 PIM SSM、 IGMP V1/V2/V3。 3.1.2 在 DSLAM 上进行组播复制（密集用户阶段时推荐） 众所周知，组播复制点距离用户约近，组播工作效率越高，因此如果将组播复制点向下推到 DSLAM 上组播流量将进一步得到优化 。 组播数据流示意图如 /webmoney 13 下：DS L AM作组播复制点工作示意图V ideo on De mandM iddle w a r eV e r ima t r ixnCu beC A S /D RMS URP A S S hiD 6 6 5 0 /7 0I P Ed g e组播业务流组播复制在 DSLA M 或接入交换机，采用 Web方式认证优势带宽利用率高单台设备性能压力小劣势现网接入设备面临压力运维部门压力较大 如果将组播流量封装在 PPPoE 的输数据包里， DSLAM 就无法感知相关的组播信息，因此要在 DLSAM上进行组播复制，组播流量就不能采用 PPPoE 而必须采用 IPoE 的封装方式，即机顶盒由 DHCP 服务器分配 IP 地址。 DHCP 服务器可以单独在城域汇聚网上设立，也可以利用 BRAS 启用 DHCP 功能。DSLAM 启用 IGMP Proxy 或 IGMP Snooping（建议采用 IGMP Proxy） ，DSLAM汇聚交换机 建议采用 IGMP Snooping，进行流量优化。 采用在 DSLAM 上进行组播 复制主要优势在于：组播复制点移到最接近用户的 DSLAM端，可以减轻对 BRAS 的性能以及 BRAS 与 DSLAM间链路的带宽压力。 采用在 DSLAM上进行组播复制主要弱点在于： DSLAM需要支持组播，计费和认证策略需要改变 。 两种方式比较如下： /webmoney 14 比较项 BRAS作为组播复制点 DSLAM作组播复制点 扩展性 随着用户的增加，需不断扩充DSLAM与 BRAS之间的带宽 带宽较为固定，较少随用户实际接入数量而改变。 设备能力 BRAS设备需要对组播报文在大量的逻辑端口上进行复制，对设备的性能影响较大。 需要进行组播 报文复制，建议通过二层硬件机制，减少对设备影响 资源情况 设备和带宽资源使用效率较低 设备和带宽资源使用效率较高， 业务质量保证 需制定细颗粒度的 IP层 qos机制。 可通过一、二、三层 qos嵌套机制解决。 安全性 网络安全问题需要考虑 如果业务网为相对专用网络，网络安全风险较低。 从上表可总结为：长期来看第二种方式是比较适当的选择，但也应该看到，第一种方式具有实施方便、对现有网络要求低、管理维护相对简单的特性，可作为初期试运行采用。 由于机顶盒不能使用 PPPoE，而需要采用 DHCP 方式， PC 用户使 用PPPoE 认证也失去了意义，因为 PC 同样可以通过 DHCP 方式获得 IP 地址。为了解决这类问题 这里又区分为两种模式： a) 同一用户的 PC或机顶盒都用 DHCP分配 IP地址。 此时 PC 或机顶盒都通过 DHCP 获得 IP 地址接入网络。此时为避免其他用户通过 DHCP 非法获取IP 地址，可以由 DSLAM 用 DHCP Option 82 报文上报 ADSL 端口号，并在DHCP 服务器上绑定端口的方式进行 PC 和机顶盒的接入认证。 提醒：机顶盒接入时还有 第二 层认证是 IPTV 平台中间件对机顶盒登录时的业务认证。 但这样对现有的 PC 上网用户计费模 式有所改变，基于现有的 DHCP 方案只能采用包月。 b) PC 用户继续用 PPPoE，机顶盒在 DHCP 服务器上进行 Mac 地址绑定。 这种模式需要 DHCP 服务器对机顶盒的 Mac 地址绑定来分配 IP 地址，由于机顶盒只局限于一个或某几个厂家，可以由 DHCP 服务器进行某一些地址段的 Mac 地址绑定。 提醒：机顶盒接入时还有 第二 层认证是 IPTV 平台中间件对机顶盒登录时的业务认证。 建议 Modem采用双 PVC上联 。 /webmoney 15 两种认证方式比较如下： PPPoE 认证方式 用户宽带上网和 IPTV 业务使用同一 VC 目前，宽带个人用户的 PPPeE 认证 要朝着唯一性限定的方向发展。为了实现用户绑定，采用 PPPoE 方式的只能在 DSLAM上实行每个用户独立的 VLAN， 的方式实现 对现有接入网冲击较大， QoS 保证困难 ，扩展性较差 BRAS 对组播的复制能力较差，同时需实施 QOS 策略。 适合业务运营初期 DHCP 认证方式 在 DSLAM设备上实现宽带上网业务与 IPTV 业务分离，采用专用链路连接到汇聚层设备上，绕过 BRAS 采用 DHCP OPTION 82，配合 ARP Inspection 以及DHCP 系统上层应用的安全控制技术，能够解决用户地址盗用和安全控制的问题。 方便组播及 QoS 的部署 适合大规模的运营 3.1.3 西门子 建议 对于 武汉电信 IPTV 试运行初期 ，用户数量较少 时 ，我们建议在 BRAS实现组播复制，这样参与组播的网元数量较少，有利于部署。这种在 BRAS 上进行组播复制的组网方式在上海、北京、广东、广西等地的电信网通已获得成功，且在这些案例中使用的 BRAS 型号 Juniper ERX 与武汉电信目前的主力BRAS 是一致的。 随着 IPTV 业务的开展，当 IPTV 业务发展到密集用户阶段，逐步将组播复制点下移到 DSLAM。同时从 Modem 开始使用双 PVC，把 IPTV 业务流和PC上网业务流区分到不同的逻辑网络中，以保证 IPTV 业务的 QoS，实现可溯源。另外，由于采用 DHCP 方式，需要对用户认证及可访问的地址域进行进一步的细化和研究。 /webmoney 16 组播复制点 BRAS组播复制 DSLAM组播复制 应用场合 少量用户，或用户分散 密集用户 认证方案 1 2 3 PC 用户接入Internet的认证 PPPoE PPPoE DHCP Option82 IPTV 机顶盒接入 IP 网络的认证 PPPoE DHCP Mac绑定 DHCP Option82 /webmoney 17 3.2 部署组播需要注意的问题 3.2.1 组播上行的保证 组播数据的绝大部分是下行数据， 在 武汉电信 IPTV 网络发展初期在BRAS 上作组播复制时， 由于复制发生在 BRAS 上 ，因此主要的组播数据发生在 BRAS 的下行端口，此时 BRAS 的上行端口主要用作组播源的数据进入，当上行端口的带宽得不到保证的时候，将直接影响组播数据的时延和抖动，因为上行端口为组播和单播公用，相互之间会有影响，而且上行端口的组 播源数据将会直接影响下行数据的复制和转发 ，确保足够的上行端口带宽对保证 IP TV业务的质量有重要作用。 针对这种情况，可采取的方法有两种： 在上行链路上使用 QoS控制机制 在上行链路上使用 QoS 机制，将组播信息的优先级提高，并保证其传输的时延和稳定性。这样能够保证组播源的数据质量，能够为用户组播的服务质量打好良好的基础。 单独构建专用的组播传输通道 为了保证组播源的质量，可以采 取的另一种方式就是使用单独的组播传输通道，将核心的组播数据和单 播 数据分开在两个不同的层面上（或不同的链路上）。使用成熟的有服务质量保证的组网方式，如 ATM， MPLS 等。这样能够有效保证组播源的质量。 3.2.2 组播下行质量的保证 对于武汉电信而言，组播的上行流量由于传递与高端核心路由器，往往拥有 较高的性能与较高的带宽，加之 IP TV 业务 在 IP 骨干层使用组播技术进行传送，减少了对于带宽的占用，因此组播上行流量往往较容易得到保证。 /webmoney 18 当组播上行链路有了保障之后，就需要考虑组播数据的下行链路的服务质量的问题。 特别是对于 BRAS 作组播复制点是，由于没有利用组播的优势，在BRAS 下行带宽占用比较严重特别是组播用户数量庞大时。而且 在 BRAS 的下行端口处，各种用户访问（包括单播和组播）是混合在一起的，因此完全有可能会造成相互之间的干扰，这种情况在出现端口超卖的地方会尤其明显。为了解决这个问题我们可以采取两个方面的 解决办法： 控制端口的用户数量 对于 BRAS 作组播复制点 时用户直播部分所占 下行 流量 与用户数量程正比关系，因此有必要对 BRAS 做出接入用户数量的最大限制。 BRAS 作组播复制点时首先应该考虑 BRAS 性能问题。 我们以 ERX 1400为例，上海关于 ERX 1400测试显示， ERX 可以以高性能支持 4000组播复制的用户，考虑到目前武汉电信 BRAS 设备普遍已经处于较高的负荷工作状态，因此我们建议每个 ERX 允许最大同时并发 1400组播用户，假设最高峰时有 70%使用直播业务 ，因此每个 ERX 最多可以开放 2000 IP TV 用户。 下面从流量方面加以分析 : 假设每个 ERX 最大 支持 2000 IPTV 用户， 正常情况时最大 70% 同时在线率， IP TV 每用户的视频带宽为 2M， 因此 IP TV 业务将新增占用约 2000*70%*2=2.8G左右带宽，因此如果 IP TV 用户数在一个 BRAS 上开到 2000，那么这个 BRAS 应该与汇聚层交换机之间应该增加 3条 GE 链路。 或者平均每增加 700 IP TV 用户应该增加一条 GE 接口。 对于汇聚层设备建议根据实际 流量占用 情况调整带宽 。 在用户下行链路上使用 QoS保证组播数据 当用户端口发生超卖的情 况，或者用户的流量模型超过了我们的预计的时候，我们可以采用在下行链路上保证用户 QoS 的方法，优先允许组播数据通过，保证组播流量的服务质量。 我们建议两种策略都应该武汉电信城域网内实施。也应该注意到，目前武汉电信城域网内接入设备厂家较多，型号也多种多样，在实行 QoS 之前应该统一考察接入层设备的 QoS 支持能力。 /webmoney 19 3.3 组播安全性保证 组播网络的实施，将为用户提供一种全新的广播类型的服务，同样网络上增加了新的安全隐患，这种安全的隐患主要集中在对服务的攻击。 这种攻击主要是用户 PC感染病毒或者网络黑客恶意产生的，攻击 的主要方式就是从用户端发出大量各种组播控制数据，阻塞核心 CPU对组播控制数据的处理能力，从而使正常用户的组播请求得不到响应，造成事实上的组播服务中断。 由于组播服务的单向性，大部分的组播流量应该是用户侧的下行流量，相反的用户侧的上行流量非常少，而且应该局限在可知的几个组播用户组之中。针对这种情况，我们可以在用户端的入口方向设置速率限制，将此方向的组播流量限制在很小的范围内，而且只能发出目标为已知组播组的数据，其他的将全部过滤，这样就可以将用户的攻击的程度降到最低，并且防止用户访问任何未经授权的组播组。 对 于初步阶段采用组播复制在 BRAS 上进行时，由于 IP TV 数据流与普通的上网数据流通过相同的 VC传递，因此安全问题更应该的得到重视。建议在现有基础上继续减小广播与的范围，也就是在一个 DSLAM上让一个 VLAN内的用户尽可能的减少，有利于进一步增强全网的安全性。 另外，对于用户访问组播的权限，可以通过 RADIUS 服务器，在用户登陆的时候，根据不同用户的属性，动态开放，不能不加区分的将所有用户的组播同时打开。 对于 后期阶段，组播复制点下移到 DSLAM上时可以事先在 DSLAM设备上实现宽带上网业务与 IPTV 业务分 离，同时采用逻辑上独立的链路连接到汇聚层设备上，进一步增强 IP TV 网络的安全性。同时建议采用 DHCP OPTION 82，配合 ARP Inspection以及 DHCP 系统上层应用的安全控制技术，解决用户地址盗用和安全控制的问题。 /webmoney 20 4 不同用户规模网络模型分析 随着网络规模的扩大， IPTV 用户数量一定会越来越多，当 IP TV 用户数量超过一定限额时，现有的承载网将很难很好的使用 IP TV 网络需求，那时新的技术可以应用在承载网以更好的满足 IP TV 的业务需求。 针对组播及内容分发， 从宏观上 讲 目前有 以下 几 种方 案 可供参考 ： 1、 直接采用现有 城域 网进行承载 ，分步骤实行一些 QoS 策略。 2、 在 现有城域网 上叠加 VPN进行承载 ，实行 QoS 策略。 3、 在 IPTV 头端设备和边缘路由器间采用直达链路或环设置专网承载 。 下面对三种方案进行比较及分析。 4.1 方案一： 采用现有城域网 直接 承载 （ 5-10万用户以下适用） 在现有城域网内直接承载最大的好处就是对网络改造较小，便于实施， 方案适用于 IP TV用户不太多时采用， 对现网改动相对较小。 西门子认为对于 5万用户的实现方式仍可以进一步依据组播复制点的位置划分为两部分 。 4.1.1 组播复制点在 BRAS 上（适合最少用户时） 如前所述 ，将组播复制点定位在 BRAS 时运营商只要对现网进行很小的改动就可以支持 IP TV 业务。但是能够以较高质量接入用户的数量也是最少的。 承载网上只需要对武汉电信 IP 网络 层次 进行调整即可，如前所述，采用PIM-SM 组播协议无疑是武汉电信 IP 层最好的选择。试运行时仅开启一个 RP作为 IP层的核心路由器。同时对于接入层不作调整，直接承载 IP TV业务。 通过 很少用户的试运行，武汉电信可以积累更方面的 IP TV 经验，包括组播运行经验，维护管理经验，以及用户推广经验等等。 /webmoney 21 我们建议，在 IP TV 业务试运行的同时，武汉电信可以进行一系列的城域网改造工程，或者改造准备 ，不仅逐渐完善现有城域网，同时也使得现有网络能够更好的承载 IP TV业务。 主要的改造方式包括，根据实际带宽占用情况扩展带宽、提高设备、链路可靠性，尽量避免单节点、单链路的故障。同时采用先进的技术缩短故障恢复速度，如西门子推动的 ERP协议可以将故障恢复速度降低到 50毫秒左右。 再有 ， 逐步实现对于现网设备的勘察， 摸清现网设备对于组播的支持能力，是否支持 IGMP Snooping、 IGMP Proxy 协议以及对于 QoS的支持能力等方面 ，为下一步组播复制点过渡到 DSLAM上做好准备。 4.1.2 组播复制点在 DSLAM上（适合较多 用户时） 随着 IP TV 用户数量的不断增多，武汉电信城域网应该逐渐实现将组播复制点下移到 DSLAM 上，对于以太网用户而言是下移到距离用户较近的交换机上。 如前所述，如果单台 BRAS接入 IP TV用户数量接近 2000，应该提前考虑该 BRAS 下 二层 设备是否能够很好的支持组播，具体来讲就是是否能够支持IGMP snooping和 IGMP proxy 协议以及足够的 QoS功能。 组播复制点下移之后，该 DSLAM建议开启 IGMP 协 议或者 IGMP Proxy协议，该 DSLAM 上行的二层设备建议开启 IGMP snooping。同时将上网流量和 IPTV流量映射到不同的 VC当中，用以进行较好的流量区分。 需要说明的是组播复制点下移 可以 分步骤完成，首先选择用户数量较多，汇聚层、接入层设备性能较强、功能较全的区域 进行组播复制点的下移工作 的测试 ，然后伴随着武汉电信城域网的改造根据实际情况逐渐实施。 建议通过机顶盒将 IP TV 部分流量通过 cos 标示出来优先级 ，用以更好的实现 QoS，我们建议 IP TV流量 cos可定义为 5。 IP核心层可采用双 RP模式工作，同时采用 Anycast技术，在对 RP进行备份同时，进行流量均衡。 /webmoney 22 利用现网， 我们认为 可以支持多达 5万的用户数量。如下图所示： Siemens AG, October 2004C om m un i c a t i ons方案 1 : 基于现有城域网（ 5 万用户）中间件电视频道通信控制器3 层交换机T a n d b e rg网管设备控制平台Vo D 服务器Vo D 网管区 1 区 14 区 15城域网骨干节点区 2B R A S B R A S B R A S B R A S安全数据中心（存储密钥）平台I PT V 头端设备平台流媒体平台（边缘）流媒体平台 ( 核心 )Vo D 内容管理系统SMG 内容中心DRMI PT V 媒体流（组播）流媒体平台（边缘）Vo D 服务器Vo D 服务器Vo D 服务器流媒体平台（边缘）流媒体平台（边缘）Vo D 服务器 如上图所示，方案 1 通过 武汉 电信城域网支持组播协议（ PIM）的 Internet平台实现组播。组播媒体流由 IPTV 头端设备发出，通过城域网的骨干节点后到达汇接层面（ 多 个区），再通过汇接层面达到 BRAS， 通过接入网络后到达用户 。 这种方案的优势是可以最大程度利用现有网络，不需要对网络进行很大的改造。 但是，其缺点 也非常明显。首先，此方案 对组播业务的 QoS 进行保障 有一定难度 ，一旦城域网出现问题，组播业务则无法正常开展。其次，对于组播协议（ PIM）的支持也存在问题。例如 Cisco 与 Juniper 设备间的 PIM 互通情况应提前进行测试。 /webmoney 23 4.2 方案二：在现有城域网上叠加 VPN承载 Siemens AG, October 2004C om m un i c a t i ons中间件T V C h a n n e l通信控制器3 层交换机T a n d b e rg网管设备区 1 区 14区 15C o r e N e tw o r k区 2B R A S B R A S B R A SB R A S控制平台安全数据中心（存储密钥）平台I PT V 头端设备平台Vo D 网管流媒体平台Vo D 内容管理系统SMG 内容中心DRM方案 2 : 基于 M P L S V P N （ 10 - 20 万用户）I PT V 媒体流（组播）流媒体平台（边缘）Vo D 服务器流媒体平台（边缘）流媒体平台（边缘）流媒体平台（边缘）Vo D 服务器Vo D 服务器M P L S V P NVo D 服务器Vo D 服务器 对于 本 方案， 目前来讲有两种技术可供选择 。一种为通过 BGP/MPLS 2547bis VPN 进行组播，而另一种为使用 L2 VPN（ VPLS, VPWS）进行组播 。 从原理上讲 L2 VPN 技术较适合以太城域网环境下的应用，因为它可以将武汉电信 IP TV 网络整个虚拟成一个专用网络，甚至包括了二层的接入网。但是我们也应该看到包括 VPLS、 H-VPLS 在内的以太网二层 VPN 协议还存在不少问题， L2 VPN 技术目前还未 完全 成熟 标准正在不断完善之中， 国内 也 没有大规模应用 实际案例。 因此我们不建议直接采用 L2 VPN协议在武汉电信城域网中。 我们建议在二层环境下可以通过最简单、被广泛支持 VLAN 技术对于二层网络进行逻辑上的划分。在武汉电信城域网 IP 层首先采用目前已经成熟的BGP MPLS L3 2547bis VPN。 来搭建三层的 IP TV 逻辑平台。 通过 此种方式 /webmoney 24 VPN 进行组播时， IPTV 头端设备平台及 多 个区流媒体平台的路由器构成MPLS VPN，这样组播流则被发送给各个区平台的路由器。 再由边缘路由器向区域网进行组播转发，转发时可以采用静态路由或其 PIM-SM协议。 这种方案有两个优势。首先，与 上个 方案一致， 本 方案也可以很大程度上利用现网。其次，可以利用一些 MPLS 保障网络健壮的特性， IPTV QoS 保障高于第一种方案。 同时这种方案 在 IP 层 也存在两个缺点。首先， 在同一 VPN 的边缘路由器之间如果采用 PIM-SM 协议进行组播路由， 不同厂家对于组播协议（ PIM）协议的支持及互通需要详细测试，否则风险性极大。其次，为了使用 MPLS VPN，需要在 7个区的流媒体平台加入 CE设备 （路由器） 。 本方案在二层范围要求有较大规模的二层域才能有利于二层 VLAN VPN的组建，否则可能经常面临 VLAN 透穿的问题。 在二层范围我们建议实施 VLAN stacking 技术或者西门子 VLAN switching 技术扩展城域网 VLAN 数量的范围，更好的实现二层范围内的 IP TV 逻辑网的建立。 /webmoney 25 4.3 方案三：设置专网承载 如果 IP TV 业务在武汉开展的非常成功，希望在大用户量的基础上，进一步提高 IP TV 服务质量，也可以采用为 IPTV 专门兴建一张网络的方法来解决 ,方案拓扑示意图如下： Siemens AG, October 2004C om m un i c a t i ons中间件T V C h a n n e l通信控制器3 层交换机T a n d b e rg网管设备区 1 区 14区 15C o r e N e tw o r k区 2B R A S B R A S B R A SB R A S控制平台安全数据中心（存储密钥）平台I PT V 头端设备平台Vo D 网管Vo D 内容管理系统SMG 内容中心DRM方案 3 : 使用专网（ 10 - 20 万用户）流媒体平台（边缘）流媒体平台（边缘）流媒体平台（边缘）I PT V 媒体流（组播）Vo D 服务器Vo D 服务器流媒体平台（核心）流媒体平台（边缘）Vo D 服务器Vo D 服务器Vo D 服务器 第三种方案为新建设一张网络传送 IPTV 组播媒体流。 也就是说 IP TV 网络与原有 internet 网络基本上相互独立，能够最有效避免两种不同的应用相互影响的情况，降低两张网设备性能要求，同时 QoS 最容易实施。但是本方案投资非常巨大，施工周期也很长，需要全面考虑后才能实施。 通过以上分析可以看出 ，以上三种方案各有优势，而随着用户量的增加，对业务 QoS 的保障将越来越重要。为了最终达到这个目的，西门子建议上海电信考虑对基于 ATM的城域网接入层和汇聚层设备进行升级，最终能够使网络演进为基于以太网的城域网。另外，随着用户的增加，建议将组播复制点由BRAS 移到 DSLAM，组播媒体流 可以 考虑使用 L2 VPN传送至 DSLAM。 /webmoney 26 从投资角度来看，第一种方案是短期内比较可行的方案；第二种方案及第三种方案均需要较大投资，由于购买不同厂家的设备投资差别较大，因此在方案确定后需要进行深入和细致的讨论。 因此，总的来说，第 一种方案能够比较快的部署业务，第三种方案可以作为今后考虑的方向。 4.4 西门子建议实施步骤 西门子建议，首先采用第一种方案并且直接将组播复制点放到 BRAS 上，进行试运行，一方面拓展用户，提高用户认知度。另一方面积极研究武汉电信现有城域网特别是二层网络的设备情况，准备好城域网改造的前期工作。 当用户达到一定规模时考虑逐渐将 复制点向下移到用户边缘侧，建议首先选择 BRAS 进行组播复制能力有限 且其对应的二层设备能力较强的节点进行下移测试。积累一定经验且城域网初步改造完毕后再向全网推广。 随着用户数量的拓展， 应该对于 IP TV 用户集中的区域进行扩容，同时 积极检测城域网流量状态，如果某些端口流量达到负荷上限应该尽快进行局部扩容。并且暂停该区域用户的申请。 城域网改造时不仅应该考虑到设备支持组播的能力，同时应该将设备支持QoS 能力情况也放到重要位置，对于不支持 QoS 的设备建议替换，以保证全网 QoS 的实现。 对于 IP TV 业务与普通数据业务的区分我们建议通过 CoS 标示来进行，也就是通过机顶盒将 IP TV 业务（直播、点播）数据流标有特殊的CoS 位 （如： 5），然后后续设备可以根据这个标示进行 QoS 处理。 建议将IP TV 业务的优先级 定为 高于普通上网业务，同时加大组播队列的数据缓存空间已降低组播的丢包率。 同时 IP 核心层采用 AnycastRP 技术等先进技术保证组播传递的可靠性。 随着用户数量的进一步增长，全网达到了 5万 -10万用户左右时西门子建议应该考虑采用虚拟专用的 IP TV 网络。具体采用何种策略需要依据当时城域网现状以及技术发展情况而定。 我们的建议是 如果 MPLS L2 VPN 技术已经非常成熟并且得到了多数厂商的支持价格 也较合理时。可以全网采用 MPLS L2 /webmoney 27 VPN技术。如果 MPLS L2 VPN 还没有完全成熟， 二层环境内 可以采用 VLAN技术进行虚拟 IP TV 专用网络，并且建议在二层平台之间搭建专用联路专门承载 IP TV 视频流直接通往 IP TV 平台。 具体方案 可参见西门子电信级以太网相关方案。 西门子认为现有武汉城域网进行优化改造后，应该可以 以较高性能承载 10万 -20万用户。 如果武汉电信网络发展到 20-30 万用户的 级别，也可以考虑城建单独的专用的 IP TV 网络，但是此种方案投资非常巨大，施工周期非常长。而且如果想兴建完全独立的 IP TV 网络将意味着每个家庭需要重新布放以太网线或者电话线。这样的工作量和投资是惊人的和难以估计的。 因此 我 们建议如果兴建专用网络，也是从 DSLAM和 用户交换机端以上的专用网络。 5 IPTV方案案例 5.1 上海组网方案 上海 BRAS 采用的是 Juniper的 ERX1400，每台 BRAS 通过 GE 口双链路直接上联到 IP MAN汇聚层，大容量的 DSLAM（ 500线以上）通过 155M ATM口，光纤直连 BRAS ；低容量的 DSLAM（ 500线以下）通过 ATM骨干网的收敛后，与 BRAS 的 622M ATM口联通。 城域核心网路由器和 BRAS 启用 PIM-SM组播路由协议和 IGMP 组播协议。组播复制点，初期取在 BRAS 上， PC和机顶盒用 户均采用 PPPoE方式接入，不更换用户 Modem， IPTV 的 PPPoE Session由机顶盒发起。不改变PCInternet登录帐户的计费方式， IPTV 的 PPPoE 登录帐户采用包月。 /webmoney 28 5.2 广西组网方案 S ie m e n s HZ B / B M NGN, Oct . 2 0 0 5Guangxi CT 组播经过 Ci sco 65 09 / H ua w e iNE80 / Juni p er E RX(B RAS ) / Hua w e iDSLAM南宁博览会场Inte rne tT an d b er g电视广播头端设备nCUBEVo D 服务器M y r i o中间件娱乐业务管理n A B L E管理系统TDCT an d b er g设备控制机顶盒 2电视频道v o i ced ata通信控制服务器南宁电信二枢纽楼交换机100 M650 9D SL A MB R A SN E80 组播路由经过 Cisco6509、 HuaweiNE80、 Juniper ERX(BRAS)、Huawei DSLAM。城域核心网路由器和 BRAS 启用 PIM-SM组播路由协议和IGMP 组播协议。组播复制点，取在 BRAS 上，用户 PPPoE 方式接入。 /webmoney 29 6 附录：组播的实现原理 下面着重介绍域内组播的实现原理。 组播技术从协议角度可分为主机路由协议和组播路由协议。主机路由协议存在于网络中的客户端、服务器以及路由器之间，使用主机路由协议，发送端可通告相关路由器它们将发送何种数据，接收到删除主机则可通告相关路由器是否对当前网络中其他主机发送的数据流感兴趣。最基本的主机路由器组播协议是 Internet组管理协议 IGMP，用于建立并维护路由器直连网段的组成员关系信息。 由于组播的组地址是虚拟的，无法从数据源一端路由到特定目的地，而只能建立一个从数据源到多个接 收端的无环路数据传输路径，所以组播路由协议的任务就是构建分发树结构从而形成组播路由。 6.1 组播路由协议 PIM SM PIM SM协议不仅是目前网络中应用最多的一种协议，也是跨域组播的基础所在。 1.1 RP， SPT和 RPT 在 PIM SM协议中最基本的概念就是 RP 点，组播分发树中的发送者和接收者都要汇集到此中央路由器并通过该点来了解对方是否存在， RP 从源（发送者）接收所有通信，并将通信转发给接收者。在一个 PIM SM域中 RP 并不一定只有一个，但对特定组播组 RP 只有一个， RP 同时还是域间组播路由协议的基础。 要把 组播数据发送给所有接收者，支持组播的路由器必须创建分布树（ Distribution trees）以控制 IP 组播数据包在网络中所经过的路径。信源树（ Source trees）和共享树（ shared trees）是两种基本类型的组播分别树： 信源树是最简单的组播分布树，它的根是组播源，各个支干形成一棵跨越网络到达所有接收者的生成树。由于这种树使用网络中的最短路径，因此也可称为最短路径树（ SPT）。 SPT中有一个（ S， G）项，其中 S 代表组播源， G代表组播组。 /webmoney 30 与信源树以信源作为根不同，共享树（ RPT）使用一个共用 的根，这个根位于网络中的某个地方，这个共享的根称为汇集点（ RP）。 1.2 RPF PIM SM中最重要的概念就是逆向路径转发 RPF，它是解决 Flooding问题的最优化形式，通过路由器的单播路由表实现。在 RPF的约束下，只有当特定接口 I是路由器 R到达源 S 必经的接口时， R才通过 I接收来自 S 的数据，并将它们转发到输出接口列表上的所有接口。 1.3 PIM SM域内组播路径的建立 1.3.1 RP 的确定 在 PIM SM中， RPT（共享树）建立的前提就是 RP 的确定，确定方法因版本的不同而不同： 在 PIM SM V1中，有静态和动态两种方法。在静态方式下，每个叶子路由器（ Leaf Router）上都要配置 RP 的 IP 地址；动态方式则采用 Auto-RP的方法（ Juniper和 Cisco均支持该特性），它首先通过 IP PIM send RP Announce命令指定某些路由器为 Candidate RP，它们向组地址为 9宣告， RP mapping agent对发送往组地址为 9的组宣告进行侦听以确定哪个为 RP，并向组地址为 0的组宣告，各叶子路由器侦听发往该组的宣告就可以知道 哪个 RP 可用。 在 PIM SM V2中，确定 RP 的方法同 Auto-RP 类似。首先配置某些路由器为 Candidate BSR（ Bootstrap Router，引导路由器）， Candidate BSR们通过选举的方式确定 BSR；配置为 Candidate RP 的路由器通过单播向 BSR宣告， BSR定期生成 “引导 ”消息，并逐跳地向整个域传播，域内所有路由器接收并保存由 BSR生成的 “引导 ”消息；最后一跳路由器 DR将组播地址映射到一个可以为该组播组提供服务的 Candidate RP 上，然后 DR将向该 RP 发送“Join / Leave”消息（或单播的 “Register”消息）。 1.3.2 加入到 RPT（共享树） 加入（ Join）过程由接收者发起。当接收者想加入某一组播组时，它将发送 IGMP 消息到其上游路由器 DR（即 RPT中的最后一跳路由器）， DR沿 /webmoney 31 着 RP 方向向上游的 PIM邻居发送 PIM（ *， G） “连接 ”消息，此 “连接 ”消息提供 3组播地址（该地址用于 PIM路由器定期发送 “呼叫 ”消息以发现邻近 PIM路由器，所以又称为 All PIM Router组地址）逐跳传播，这说明在 PIM SM域内，所有 PIM邻居都知道 该 “连接 ”消息，但只有指定的上游 PIM邻居才执行这一动作。当上游 PIM路由器接收到来自下游（ *， G）消息，它将检查组播路由表以确定用于 G组的（ *， G）状态是否存在。若存在，则表明已连接到了 RPT，且接收 “连接 ”消息的接口已写入 OIF（ Out Interface）列表中了；若该（ *， G）状态不存在，则在组播路由表中创建一个（ *， G）项，并将该接口写入至 OIF列表。 “连接 ”消息项 RP 方向继续发送，直到加入到 RPT。如果最后一跳路由器到 RP 的（ *， G）项建立了，则对特定组播组 G的组播流就能够到达已加入该组的所有接 收者。 1.3.3 节目源向 RP 的注册 在没有源的任何（ *， G）状态的情况下，第一跳路由器（ DR）可以从源接收组播数据，并将该组播数据包封装为 “注册 ”消息，然后将该消息单播至该组的 RP。 RP 打开每个 “注册 ”消息，将解开的数据包沿 RPT树向下传送。 一旦源到 RP 的路径建立， DR就开始将标准的组播数据包连同 “注册 ”向下发送至 RP（此时， RP