分享

        陈首席盛情邀请，可惜很惭愧没什么好东西拿得出手，在无聊而忙碌的生活和工作中，不小心翻出来一个朋友的邮件，朋友的单位高手如云，认为没有价值，我觉得还有点意思，简单修改一下，拿出来给弯曲的网友眇一下     

       运营商是商人运营的，作为一种商人，其网络建设是不会逃离资本主义的本质的：即资本家/老板，或者说应该说资本，是最自私冷血和无情的，其终极目标以最低的成本（TCO）获得多大的利益（money）。资本理智的天然逐利性使其本质上和什么自由平等人权人性没有关系，不管你红绿黑白颜色如何变化，马甲如何换都是没用的，资本却万变不离其宗，聪明得以不变应万变，我要的是利益最大化，其他一切都是借口和工具，管你什么颜色。

        上面主要是国富论的原则，至于能使资本主义在道德束缚下不断改良而得以长青的道德情操论，没有在这里予以更多关注和考虑的，或者说，资本主义的道德情操的高尚只是主观行为下带来的客观意义，怎么讲？不做道德束缚，就不能稳定的获取利益，所以可能本质上还是有利益所在前提或者成分。离题太远了，还能转回来是大荣的风格。

        当然最理想的状况是最高追求，现实中各个运营商根据自己的企业文化、实际资源、能力、地位和用户情况等，采取一个现实的平衡点。比如H3G是典型的商人，所以把成本看得更重；北欧的运营商喜欢交换机；中小运营商因为光线资源限制系统用ring+CWDM，传输背景或者IP能力弱的运营商更喜欢GUI网管，而IP强大的运营商觉得CLI挺好；考虑固网移动融合的运营商喜欢FMC

        没有谁比客户自己更在意如何能把钱花得更值？所以运营商的建网理念和网络设计，都是经过认真仔细深入的考虑的，尤其是大T，仔细看里面的东西，开始看看到许多不合理的地方，但是不停的考虑下去，随着对客户综合情况了解的不断深入，就会逐渐发现不得不选择客户建议的方案，一时还很难发现更好的方案，所以如果要对其优化，就需要在此基础上再进一步考虑。当然，运营商也有自己视角的局限，对于供应商，也需要跳出客户的角度，从更多的角度深入考虑，才可能提出合情合理的，让客户感到压力的问题，并给出优化方案。这其中还涉及到具体运营商内部的政治问题，比如基于其部门利益会故意合理遗漏一些需求，比如GPON的方案需求，所以有时方案就会有些异常点。

      以上细节不便展开，主要目的是希望我们在做网络规划和研发时能抓住IP网络的重点，在把握机会的同时，把真正的重点抓住，毕竟，无论如何，在通讯真正快速发展的不长的30多年时间里，我们发现错误总是能在一定时间内被纠正，即使不是很及时，大的比如ATM,ISDN,X25,小的到FR,窄带，ATM DSLAM等，虽然这些错误或者是过渡技术仍然或多或少的还留在existing network成为legacy，但不表明他们正确。他们只是在警示我们他们仍在，在网络的下一步演进中，不能无理的忽略他们的存在，即使phase out，也给一个合理的说法和exit。

       IP网络本来纯是一个自由开放的自主智能的网络，和电信网络是很不同思路和方向。IP网络完全是应用和内容主导下建立的网络体系，其演进和发展也是从应用需要开始。但是，IP网络作为资本主义产物，它能提供比其他方式高几倍的性价比，这是资本本质的体现，所以IP必胜，IP万岁。在电信要使用IP承载情况下，一些关键需求必须得到合理解决，不仅仅是技术上，是包括TCO上合理解决，最主要的就是如何保证用户的业务体验：QoE

      QoE表现为：网络的运行中的变化在客户业务体验的容忍度内，或者使客户不感知到网络running中的变化，或者感知但不抱怨。其中包括：平时要稳定运行，出问题时能在客户的容忍度内恢复。网络的设计就是要以此为目标：即以最小的成本得到这个结果。当然具体到整体设计还要考虑到扩展性，future-proof等问题，都放进来太复杂，在此不做全面考虑。网络设计支撑QOE的主要是QOS、可靠性和安全，安全没有深入考虑，下面主要考虑QOS和可靠性

关于QOS的主要场景：

1，   在完全没有拥塞的情况下，什么意思，就是报文都不缓存，这才是真正的线速转发，以线路的速度转发，这种情况不存在任何拥塞，这样的IP网络和传统的电路或者光网络是没有区别的，但是这样的网络成本肯定也是和传统网络一样的，没有了基于报文的统计复用，成本高的不是一两倍，所以IP网络的肯定是要存贮转发的，这是IP网络作为以包交换为基础的数据网络的的基本特征之一

2，   存贮转发是必须考虑的，所以PQ是必须支持的，对于语音和视频，以及一些协议等是必须要做PQ的，这点已经是公理，在没有丢包情况下，也需要PQ

3，   在有丢包情况下，上面的就不够了，为了保证特殊情况下高优先级不把低优先级吃死，所以CIR是必须做的，PIR最好也支持了，有其灵活的场景应用，即使网络负载设计保证了没有丢包也可能需要做

4，   基于用户的QOS，涉及到对队列数目的需求问题。一般来讲，是不需要做基于用户的QOS的，除了DSLAM/BRAS或者某些特殊网络设计情况下。所以普通网络不需要海量比如上百K的队列。注意：QOS不是一个纯技术问题，也就是必须和网络带宽规划、运营商的客户业务经验带宽模型配合，完全靠技术解决一个是很难，再一个是即使解决了，也是复杂的高成本的方案。这里的用户，指的是个人用户，比如residential用户，其他用户，比如enterprise，business一般来讲不可能需要这么大队列的。

5，   关于H-QOS，我认为是必要的，在做FMC的时候，对网络是带来很大的风险的，把三个网络合成一个，原来一个网络的中的问题现在要影响3个网络，所以如何既融合网络，又隔离网络？如果做得不好，在商业运营中，可能还不如3个独立网络的TCO低。在隔离中，可以考虑使用LR/VR，是很好optional的模型，但是如何把这个模型如何到FMC中？这个模型如何解决可能带来的复杂的运维和故障定位问题，至少近期是不会考虑大规模商用的。所以对不同种类的业务，我们需要给他们一个好的管理方式，基于队列的QOS还可以用来做网络监控，此时不一定要H-QOS，使用一个QUEUE来管理所有此类业务，即使不配置任何带宽，也是一个不错的监控方式，这种情况下，用的队列不多，成本是很低的。 

        在管道提供这个业务中，有最高统计复用度的IP成本肯定最低，在传统网络，运营商把业务的复用留给了客户解决，只提供一个没有弹性的硬管道，简单，可靠，有质量保证，但是客户间的带宽是无法在承载网上做复用的，这个成本是不能适应大量用户的灵活的数据流量需求的，IP推进的程度越深，网络带宽的复用度越高。

      QOS解决的是拥塞情况下的带宽管理，所以一定要和带宽规划结合。对于CAC的情况，有点复杂，如果不和业务管理系统配合，通过设备的技术解决，比如ECN/PCT或者magicQ，我认为是不合理的，前者即使接近了RFC，但是基本上还是早早出局，后者虽然有最好的带宽利用率和完美的方案，但是复杂的队列设计带来的成本基本上很难实际部署的。IP网络万一出现CAC问题怎么办？许多运营商都没考虑，因为语音的CAC不在IP承载，而广电级和电信级的IP视频还没有普及到那个地步，但是是否有可能发生，比如911在美国重演，如果解决不好会出现部分拥塞影响了大量用户的情况。视频CAC是个需要深入研究的方向 

     QOS技术中基于用户的QOS、灵活的H-QOS和CAC是需要细细研究的问题，这些问题理解好了，队列数目的实际需求也就出来了

      其他还有带宽和性能检测、预警问题，需要和网管一起，给出好的系统方案。总之QOS问题是个带宽管理问题，不能完全依靠复杂的技术解决，基于用户的QOS，H-QOS，CAC都是复杂的技术，需要和带宽规划，系统管理等结合做开发和方案，才是解决之道，不能全靠蛮力用纯技术解决。 

可靠性的问题

      关键是网络故障的处理，尽量减少故障的恢复时间，具体什么标准？就是用户不感知，或者即使感知也不会抱怨，更有甚者是即使抱怨，但在我运营商的允许范围内，包括愿意付出罚款，比如我付出罚款的代价比我要解决这个问题的总代价（包括市场影响）要小的多，那我为什么要解决。具体还包括故障预警、隔离、恢复（临时修复和完全恢复）等

        实际网络设计，考虑得更深入，除了用户感知的问题，还有故障的影响范围问题，尤其是FMC情况下，这个变得更重要，如何让故障的影响范围最小，也就是在最小的范围内修改，使得不产生对其他部分的影响，这个付出的成本是要考虑的。不能简单的以客户不抱怨为标准。比如客户重拨一下，也不会抱怨，从客户角度看应该是可以的，但是从全网角度看，却可能产生风险。要知道，越靠近CORE的故障，影响越大，这一点是运营商和供应商都认可的公理，如果这个点的故障使通过它的海量的SESSION中断，即使可以重建，但是能否快速重建？会给应用层的服务器带来很大挑战，他们需要做针对性的设计，否则可能崩溃。即使快速重建解决了，那么因大量连接重建给网络带来的突然冲击，也是对网络系统的一次考验。这种冲击的考验，不是运营商愿意看到的。很多时候，爱情是经不起考验的，有几个傻瓜会没事就试图用苛刻的5个9去考验爱情，运营商不傻，更不相信爱情，所以把在合理成本下把故障控制在最小范围的网络技术和设计是很必要的

        具体来说，基于通用CPU的软件系统，SESSION的最小检测时间是一般是1秒，也就是说，我们E2E的故障恢复时间应该小于1秒，那么保险起见，应该至少是700-800毫秒，那么如果大T再有点追求，那么小于500MS应是一个比较好的结果。此时本地的故障恢复时间小于100MS和可能是需要的。基于此，华为10MS的BFD HELLO报文,30MS检测时间是比AL的100MS HELLO，300MS的检测时间要有相当的优势的。

       IP系统容易发生问题，在于其每个节点作为智能节点，做了大量的路由处理，在海量情况下，是容易发生问题的，所以如何减少上面提到的故障对应用层会话的影响，减少对路由计算的影响也是一个重要的考虑。I-SPF，下一跳分离等都是在这个方向上努力改进的技术案例。在这方面，SDH因为提供的容易的物理链路保护，通过CAPEX解决了路由计算的问题。在RPR技术已经废弃的情况下，IP网络需要进一步提供好的方案减少路由的flapping.

        快速感知和慢速感知故障上，是一个矛盾，什么意思？我们希望快速感知，是希望能快速切换到备份路径，但是如果路由收敛也快速的做了，这在闪断的情况下，路由又需快速收敛回去，这一来一回是很容易出问题的，即使一次不出，如果多次，就可能出了，所以，你看久经考验有多不容易，一些重大网上问题就是这么出来的，这是通用问题。所以，是不是可以做一定的抑制，FRR可以做，但是路由收敛可以等一等，做一下flapping抑制

      总之，E2E可靠性，原则是尽量减少故障的影响范围和恢复时间。这需要和网络规划一起做，包括故障引起的路由flapping尽量少。但无论如何，在需要快速收敛的和FRR时候，BFD for everything不是噱头，是现实需要的。大T的大在于其海量的业务和用户。在BFD的效率、下一条分离等此类方向的关键技术上，可能还有潜力可以继续挖。关于各种可靠性之间的联动，是个比较复杂的问题，对于大T，设计不好，很容易出问题，所以方案和开发，如何能在减少复杂联动情况下实现E2E的保护，即使慢一点，也可能比复杂的联动好，这个是可以继续研究的

        每个运营商都有很有意思网络理念和网络设计，但是市场情况是非常复杂的，有时候即使运营商错了，但是就是不改，你也不得不FOLLOW，否则就出局，此时需要好好考虑这到底是不是主流需求？ 

分享