城域网IPTV承载优化方案

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页

联系客服:779662525#qq.com(#替换为@)