XXXX城域网IPTV承载优化方案

第3章 ITV业务承载优化目标

本期针对广西联通城域网进行ITV业务承载优化，同时考虑到远期大规模部署的延续性，从以下几个方面进行优化：

接入平面ITV流与普通上网流分离，即多PVC/VLAN改造 ? FTTx（LAN接入）、楼道交换机进行多vlan规划/改造；

ITV业务采用DHCP Server发起认证的增强型IPOE用户认证方式 ? DHCP option60+DHCP option82+RADIUS Server+DHCP Server；

三层组播PIM-SM部署

? ITV平台第二阶段建设新增2台RP路由器做为PIM-SM组播域的

Anycast RP；

? 在城域网骨干层相关设备部署PIM-SM； ? ITV平台按规划的频道组播地址改造为组播源。 组播复制点下移至大容量二层接入/汇聚设备

? 直挂SR/BRAS的园区SW/OLT选择一条链路通过组播引流vlan动态

下拉组播流，启用跨vlan组播复制；

? 通过汇聚交换机上联的DSLAM/园区SW/OLT选择一条链路通过组播引

流vlan动态下拉组播流，启用跨vlan组播复制；

? 在汇聚交换机透传组播引流vlan，针对此vlan启用IGMP snooping进

行二层组播复制；

端到端的Qos部署

? 在城域网与ITV平台互联端口进行ITV流的IP优先级标记为5； ? 在城域网承载层面采用Diff-Serv机制部署三层Qos，为ITV业务保留

一定的带宽，从带宽、时延等方面满足IPTV业务开展的Qos需要； ? 在IGMP路由器下行端口的出方向上将ITV报文的DSCP映射到

802.1p，从而在接入网所有设备上通过802.1p对ITV流以及IGMP协议报文进行带宽保证；

? 在接入网所有设备上通过802.1p实现带宽保证和队列调度；

第3页

XXXX城域网IPTV承载优化方案

通过以上多个方面的优化改造，实现了ITV流与普通业务流分离，在此基础上可以进行二层Qos策略及业务流量分离调整；实现BTV组播功能，并使其组播复制点下移更贴近用户，节省城域网链路带宽；对ITV业务下行流量实现了端到端的Qos保障，使ITV业务质量得到保障。

第4页

XXXX城域网IPTV承载优化方案

第4章 ITV业务DHCP规划

4.1 ITV业务DHCP需求

在ITV发展之初，由于业务规模不大，为了拓展市场，ITV业务常与上网业务捆绑销售。在网络承载方式上，为了快速融入现网，ITV业务使用和普通PPPOE相同的物理平面，并与普通PPPOE用户使用相同的认证方式，给ITV快速融入现网提供技术层面的支撑，给以捆绑销售为主的销售模式带来可能，保障了ITV业务稳步的发展。

电信业战略转型不断地推进，做为战略转型的重要一步的ITV业务将迎来大发展时代，ITV业务在不断丰富节目内容的同时，加强了作为一个用户平台互动能力，ITV业务已经成为独立产品面向市场。在ITV业务规模不断扩大的同时，对ITV业务质量提出了更高的要求。而ITV业务现行的运行机制已不能满足以及支撑ITV业务的快速发展，在网络结构和认证方式上均没有提供业务所需的独立性。

在ITV用户地址分配及认证方式上采用DHCP方式，从对ITV业务发展的角度来说，不仅提供了业务独立的地址分配和认证方式，而且相对于普通PPPOE用户认证方式来说DHCP采用集中试的地址分配和认证方式，拥有更为丰富的和灵活的地址管理手段，不仅简化了ITV业务维护量，而且为业务独立和业务不间断发展提供了有力的技术支持。

4.2 DHCP实现ITV用户地址分配及认证

DHCP的全称是动态主机配置协议（Dynamic Host Configuration Protocol），使用它的目的是为了减轻TCP/IP网络的规划、管理和维护的负担。DHCP采取经典的C/S架构，DHCP服务器通常选择由运行DHCP软件的服务器或者路由器，客户则需要与服务器协商来获取IP地址。

对于ITV业务DHCP使用规则中，可以分为两个阶段，SR兼做DHCP服务器阶段和专用DHCP服务器阶段，使用过程中主要有三个方面的内容：DHCP地址分配，DHCP认证和DHCP服务器的冗余备份。

4.2.1 DHCP地址分配

在ITV业务开展前期，可以采用SR兼做DHCP服务器的方式。即SR监听STB的DHCP请求，并根据请求直接给STB分配地址。考虑到安全需要，可以限制DHCP client MAC地址段的方式。这种方式在网络侧不进行用户的认证和计费，相关功能由ITV平台对机顶盒内置帐号认证的方式来实现。

第5页

XXXX城域网IPTV承载优化方案

随着ITV及其他IPOE认证业务的发展，可以考虑建立全省DHCP认证平台，对所有IPOE用户在网络侧进行认证。此时ITV SR将接收到的请求及相关认证信息Relay至DHCP服务器。过程如下：

? DHCP服务器承担着给ITV用户分配地址

? Radius服务器对ITV网络帐号进行认证和计费（如果采用Radius认证的话） ? 网络承载：网络部分不承担分配地址的工作，但是需要保证能将用户的请求正

常的传递给DHCP服务器。在目前的城域网架构中，BAS和SR为二层和三层的分界点。ITV用户的DHCP请求在二层会以广播的形式发送给BAS/SR，在默认情况下，这些广播包是不会继续向核心层面转发的，所以DHCP请求到不了DHCP服务器。此时，需要在BAS/SR上开启DHCP-relay的功能，将DHCP请求relay给DHCP服务器。其他的网络设备，都能正常的透传DHCP包，所以不需要做其他的额外配置。

4.2.2 DHCP认证方式

用户认证也是ITV需要解决的一个环节。目前采用的认证方式，是拨号的用户名，密码通过BAS在radius服务器上做认证。

当采用DHCP的方式以后，认证就需要通过DHCP服务器搜集用户信息后，发送给radius做联动认证。DHCP可以通过一些可选字段，如option 60/82等信息来搜集信息，当然也可以通过MAC地址等信息对用户身份作认证。

目前，服务器厂商推荐的认证方式如下：

? MAC地址认证，通过将STB的MAC地址批量导入DHCP服务器的MAC池，启动基

于MAC地址的过滤，可以保证只有合法的STB才能从DHCP获取地址。阿朗的QIP目前已经支持，不需要额外的认证系统。

? 采用Radius认证，即DHCP服务器将收到的报文透传给Radius系统，并等待

认证系统的认证返回结果，再决定是否继续分配地址。该方案需要认证系统的配合，而且根据我们的经验认证系统往往成为DHCP（DHCP的处理能力2400个/秒）分配系统的瓶颈，增加系统的复杂性。因此我们不建议该方式。 ? 还有一种方式是不在IP层进行认证，只在IPTV的业务层进行认证。因为基本

的IPTV业务都采用包月的方式，目前大多采用这种方式。

根据广西联通建设需求，建议前期采用网络侧不认证的方式，后期采购DHCP服务器后采用MAC地址认证的方式，Radius认证须在服务器认证效率得到保障的前提下才

第6页