多业务融合IP承载网络组织与设计燃烧机

多业务融合IP承载网络组织与设计

多业务融合IP承载网络组织与设计 2011： 以IP技术为基础的数据业务正在快速发展，同时许多网络和业务都在围绕IP技术进行融合，IP网络作为多业务承载平台是网络发展的趋势，正在蓬勃发展和紧锣密鼓准备中的NGN和3G业务网络以及逐渐兴起的IPTV业务，需要充分依赖于IP网络技术。 另外，以MPLS技术为基础的VPN企业互联业务市场需求强劲，高质量要求的IDC业务也是将来新的业务增长点。面对竞争和多业务融合发展的需求，许多电信运营商作出了网络技术转型的重大战略举措——建设具有融合多业务能力的IP/MPLS承载网络。 业务对网络的需求 电信业务发展的整体趋势是从话音到数据、视频综合的多媒体业务，具体地说，可以大致分为语音、交互式视频（视频会议、可视电话等）、流媒体视频（IPTV、视频监控等）、企业互连和数据等业务，每类业务又存在多种实际业务形式。不同业务特征存在较大的差别，对承载网络存在不同的需求。 因此，这些业务的融合客观上需要有与之相适应的承载网络。业务的发展对承载网络提出了新的要求：业务量的快速增长对网络承载能力提出挑战；话音、交互式视频、流媒体业务对IP网络QoS提出更高的要求，同时要求网络具有快速路由收敛和故障保护能力；IPTV流媒体业务客观上要求网络具有组播（Multicast）能力；企业互连提出了MPLSVPN组网要求，多数大企业存在语音、视频、商业交易等多业务同时运行需求，对网络QoS提出了新的要求；业务盈利模式对QoS的差异化要求。 因此，多业务融合IP承载网络应该是因特网与电信网技术的结合，即IP/MPLS＋QoS模式。应当是有服务质量保证、安全、可维护、可管理的电信级IP网络。 网络组织与路由设计 网络组织 多业务融合IP承载网络设计的总体目标是要达到“容量可扩展、用户可识别、业务可区分、质量可控制、网络可管理”。设计思路是实现“骨干网络简洁化、业务实现边缘化、网络结构高效化、流量调整灵活化、故障影响局部化”。 网络建设规模根据业务发展的需求进行设计，按照如下原则进行：设备交换容量（最大端口配置容量）根据今后3年的流量预测设计，链路带宽按照当前的流量预测设计，尽量做到网络建成后的几年内不再进行节点和设备扩容，只要增加链路带宽和相应的接口卡，保证多业务融合IP承载网络的相对稳定。在网络覆盖方面，要考虑到网络扁平化的原则，使业务能力直接覆盖到全国大多数城市节点，通过少量的延伸方式实现业务全国覆盖；同时，还需要考虑到电信运营上海外扩张发展的需要，在业务发展前景好的海外城市节点实现网络覆盖。此外，还需要考虑与其它现有网络（如CN2与ChinaNet）并行运行和故障备份的要求，在关键的城市节点进行互连。 网络设计包括两个网络功能层面和4个网络结构层次，实现承载和业务提供相对独立。两个功能层面分别是高速转发层（骨干网络）和业务提供层；4个结构层次是核心层、汇接层、边缘层和业务接入层。骨干网络只负责数据的高速转发，设备互通问题相对较少，可以适当引入多厂商设备，降低网络建设成本；业务提供层使用同一厂商设备，以减少业务互通障碍，保证业务提供，便于业务管理。所有业务在边缘实现，只能通过业务路由器（SR/PE）接入，包括软交换、视频会议、VPN业务、互联网专线、ATM/FR/DDN业务接入等等。业务升级或者新业务的增加、安全控制等只须在边缘层进行，保证骨干网络的稳定。运营商内部网络间互连通过骨干网络，比如城域网互连、IDC等等。 拓扑设计的思路是，在保证网络层次化的同时实现网络扁平化，提高网络效率、实现路由路径最短化。以业务量为依据，打破行政区域，实现跨省汇接、减少汇接节点、减少汇接层次、减少端到端路由跳数；在核心节点、汇接节点和边缘节点重叠的节点，内部简化为一个层次。核心节点的选择，充分考虑业务流量、传输资源状况和地理位置因素，根据业务QoS、网络容灾和转发效率要求，采用全网状结构互连，保证在正常情况下，核心节点间延时小于15ms；同一局向之间至少使用两条链路互连，采用不同的传输路由，相互之间优先备份，控制故障影响的范围。汇接节点设置根据流量流向，充分考虑网络结构的优化，打破行政区域限制，至少连接两个核心节点，实现两个局向负载分担、故障备份；在经济紧密联系、互相之间通信量大的部分省份，引入区域网络概念，实现跨省汇接，同时边缘节点可以直接连接核心节点。此外，对于业务量较小的地市，不单独设置节点，而是就近合并城域网，控制节点数量。 路由设计 路由设计要求实现网络流量的均衡性，实现流量调整的灵活性。如前面所述，网络结构设计采用了扁平化的设计思路，同样在路由设计上也采用扁平化的思路。将大颗粒的省份和城市分布在不同的局向，保证整体上流量均衡，通过IGP路由策略实现；以城域网为单元进行微调，使用IGP和BGP相结合的调整方法，尽量实现流量均衡，提高链路利用率，控制链路利用率均衡性相差在20％以内。 在IGP设计方面，还要求实现网络故障情况下具有良好的控制能力、加快网络收敛时间、提高网络的稳定性、适当控制IGP路由表容量。IGP采用简单高效稳定的ISIS协议，所有路由器在同一ISIS Level 2平面内，通过科学的Metric设计，可以有效控制链路故障影响范围。 关键技术应用设计 MPLS设计 MPLS技术发展相对成熟，但在中国全国范围这样大规模的网络上部署，在世界范围内还是首次，具有极大的挑战性。对于多业务融合IP承载网络，MPLS技术应用是全面提供新型业务，尤其是VPN业务和FRR保护。MPLS技术最大的挑战是其标签的分发能力、标签收敛速度、标签表和标签转发表容量、标签表的维护能力等。多业务融合IP承载全网所有路由器运行MPLS，采用LDP协议分发标签，为控制标签表和标签转发表的数量，全网只针对关键的路由进行标签分发；同时为提高标签收敛速度，全网所有路由器LDP相关定时器进行优化设定，并统一标签的发布和管理模式。 MPLS流量工程TE可以实现流量均衡、提高带宽利用率，基于TE的FRR可提供50ms级别的链路、节点保护，能够更好地满足实时业务的要求。多业务融合IP承载网络，如CN2网络，运行初期带宽相对充足，TE对提高带宽利用率、缓解网络拥塞的作用并不明显也不迫切。而目前DWDM提供的10G/2.5G波分链路没有保护机制，无法满足50ms级别的链路保护的要求，使用FRR则可以实现这一目的。 QoS设计 QoS技术是统一承载网络内部资源分配的手段，是将统一的IP承载网络逻辑上分为不同的资源子网。比如3G，软交换、MPLS VPN、ATM等都可以单独建网，现在采用IP/MPLS技术建设融合网络，所有网络业务容量叠加，通过QoS技术分配资源给不同的业务。多业务融合IP/MPLS承载网络设计中，需要考虑在链路适度轻载的基础上，全网部署基于DiffServ的QoS技术，提供不同等级的服务，针对不同等级业务分配不同的冗余资源，满足高等级业务的突发，保证高等级业务不受低等级业务的影响，实现语音、数据和视频等不同业务在同一张网络上的融合承载。 网络组播设计 由于IPTV类型业务占用的带宽高，可以利用广播形式提供业务，因此客观上要求承载具有组播能力。在具体设计中，在全网开启组播功能，采用ASM模型进行部署，整个骨干网络设置为一个PIM-SM域，并通过设置组播边界、分组过滤等对组播流量进行控制和管理。骨干网RP设置在核心节点信息源较集中的位置。多业务融合IP承载通过MBGP和MSDP协议实现跨域组播，连接城域网，并为企业客户以及ICP等提供中国电信的组播业务。 IPv6设计 IPv4存在地址空间及在应用管理灵活性、安全性等方面的缺陷，使互联网逐渐转向以IPv6为基础的下一代互联网是不可避免的大趋势。因此，网络设计要求具有运行IPv6的能力，所有的路由器具备运行IPv4/IPv6双协议栈的能力，同时使IPv6业务具备硬件转发的能力。 对于CN2网络，鉴于IPv6技术及其业务发展还处于试验发展之中，商用业务还较少，因此初期暂不在全网P设备启用IPv6功能，通过在全网PE路由器上部署MPLS6PE功能，利用MPLS多协议能力承载IPv6接入商用业务，可使IPv6业务在全网范围内开展。 网络安全设计 在网络安全设计方面，多业务融合IP承载网络需要在网络结构、路由协议、防攻击、控制垃圾流量等各个方面进行安全的设计。 设备要求 多业务融合IP承载网络的目标是大容量、高质量、高安全和可管理的多业务承载网络，不仅要求路由器具有大容量高性能，还要求具备IGP/BGP快速路由收敛、MPLS VPN和FRR、组播、QoS、IPv6能力，还需要支持各类协议平稳重启和流量采集等技术（xFlow等）。 如在CN2网络设计中，根据业务量预测和网络结构设计的需要，骨干P路由器采用了A、B、C三档次的高端路由器设备，业务PE路由器采用D、E两个档次的设备。不同档次设备的容量要求不同，对于业务路由器要求具有丰富的业务特征。设备选型过程中，所有类型的路由器都经过了严格的测试。测试数据表明，通过IP网络设备能够胜任多业务承载网络的要求。今后，随着多业务融合IP承载业务增长，容量不断扩大，多业务融合IP承载将逐步进行多机级联集群技术，试验使用更高速率的接口类型。 综上所述，多业务融合IP/MPLS承载网络可为电信网络的发展奠定一个统一的有高质量保证的业务承载平台。通过精心设计、部署、网络验收测试以及多种业务加载运行，充分表明IP/MPLS多业务融合网络能够实现承载包括企业VPN互联、软交换、3G、IPTV、视频会议、视频监控、高质量大客户互联网专线接入和高质量IDC等有QoS保证需求的关键业务。有理由相信，这种网络的建设将加快电信运营商的网络与技术转型，也在很大程度上促进我国网络业务的全面发展和向融合网络的演进步伐。 (end)

呼叫中心平台

呼叫中心系统

云客服

客服系统

客服系统