要有光
在IP化的大环境下，所有业务场景的组网方式本质上全部都是基于以太，同时无论技术如何演进，传输层永远都离不开波分。
每一种热点技术在退潮后都会留下一点真正有价值的东西，SDN就给我们留下了SD-WAN，企业希望使用SD-WAN解决带宽不足的问题。带宽不足比较类似交通拥堵，当疏通交通拥堵时，关键是让车辆尽快驶离路面。而站在司机的角度，他会选择绕行避开拥堵，绕行延长了车辆在路面的停留时间，从而导致拥堵传导到其它路段。SD-WAN是以企业诉求为出发点开发的，它没有提供新的资源，而是用一种低效的方式挖掘富余带宽，所以也存在与交通拥堵类似的问题。当带宽总量充足，而仅仅是结构性不足时，SD-WAN技术确实有正面作用，能够节省成本。但是当大家都开始部署SD-WAN时，由于缺少全局协调，边际效应快速收敛，会反过来加剧网络拥塞。
SD-WAN无法解决带宽资源不足，它只是证明了带宽不足的严重程度。在限定投入的情况下，唯一有效的方法就是减少穿通迂回，让所有流量都直接从业务源流向业务宿。什么技术能达到这种效果？只有光。
穿越迷雾
说光传输可以取代以太在网络中的地位，好像有违常识，以数据迁移场景为例：运营公有云业务的公司都有通过离线存储设备进行数据迁移的方案，谷歌的Transfer Appliance、亚马逊的Snowball、阿里巴巴的闪电立方。原因是当数据量很大时，通过专线传输数据在成本和时间效率上比不上公路运输存储设备。如果我们拿物流业的运作效率与传输网比较，会发现传输网的响应速度确实很讽刺。领先的物流企业可以跨省次晨送达，也就是不超过24小时完成一单业务。而开通一条波长链路，一般都在两周上下。物流业全程都是手工操作，传输链路大多数情况下只有源宿端需要连接光纤，相当于快递的收件和派件。运作效率差异如此大的原因在于，与物流这种单一封闭系统不同，传输网存在两个巨大的豁口。
第一个豁口是业务端口与传输端口失配。业务端口绝对多数都是以太，以太只有一层开销，没有OTN这种分段嵌套的开销体系，所以只有以太端口之间可以相互协商。以太端口与传输端口之间无法互相感知。在当前的业务规模和割接频度下，即使将以太端口和传输端口共同管理，也无法识别它们之间的承载关系。以太的管理软件无法获得传输电路的度量数据，不能相应优化路由。传输侧也不能获得以太端口的真实状态，例如当出现业务中断时，传输无法知道是业务下线了，还是尾纤故障。在这种限制条件下，不可能使用网络协议直接驱动传输电路建立。
我们知道PCI-E是最成熟普及的板载接口类型，是网络上绝大多数业务数据的起点。类似SDH时代的POS端口，填补第一个豁口的办法是直接将OTN接口下沉到PCI-E插槽，推出PCI-E”OTN卡”。 以FPGA芯片作为粘合剂，将以太芯片和OTN成帧芯片结合在一起。考虑到时钟在网络中的重要性，以太芯片最好同时支持1588v2时钟。原来业务设备上的多个以太端口变成一个2.5G/10G/40G/100G的OTN光口。通过FPGA编程，业务设备可以得到多个MAC地址。
.jpg)
例如一台服务器上有一个10G OTN卡，带一个OTU2灰光模块，接入OTN设备的UNI接口中进行调度。我们可以通过软件配置第1个ODU0承载传统的千兆以太业务，这个ODU0信号不会调度到波分系统中，而是直接调度到另一个连接到交换机或者路由器的客户侧单元，就像MSTP中的”Native Ethernet”。这样新的组网方式与原来的组网是完全兼容的，存量业务不受影响。剩余的7个ODU0，我们可以配置最多7个不同的MAC地址，也可以利用ODUflex得到数倍千兆的连接。业务设备通过ODUk电路直接连接到位于不同地域的交换机或者与其它业务设备直连。没有穿通过程中以太到OTN的封装解封装处理，可以减少数百微秒时延。同时以太只出现在业务两端，网络中只有OTN一层，简化了网络结构。所有的网络连接都是在光域发生的，利用OTN的分层开销体系，电路上每一次封装复用都能得到动态跟踪和统一管理。业务设备上部署的应用也可以利用开销和管理平面，对自己的电路进行管理。我们甚至可以通过FPGA编程将OTN解出的信号绕过以太直接导入到PCI-E时序，相当于PCI-E直连，实现直接内存访问（DMA）或者访问云上的显卡等传统以太难以企及的硬件资源。
”OTN卡”的本质就是将几种成熟的技术组合在一起，所有的芯片都是公开发售的，不存在太高的技术门槛。OTN卡的尺寸和热设计比照显卡，可以使用多个槽位。与以太网卡相比，在成本上主要是增加了一个OTN成帧芯片和一个FPGA芯片，如果业务设备原来就有多个以太端口，整体成本甚至可能降低。未来连PC也能使用2.5G的OTN卡，一个ODU0承载IP，另一个ODU0用于VR游戏这样的点播业务。OTN下沉与传输端口成本下降会交替影响，进入良性循环。回到数据迁移的例子，如果传输专线的月租金能够降低到目前的十分之一左右，OTN就会取代以太成为主流技术。
第二个豁口是跨厂商跨域的子网间连接与协同。如果单纯看硬件，跨厂商互连是可行的，运营商有成熟的组网方案。一般是在不同厂商的两个电框之间的一对线路板上安装100G 灰光模块，使用标准的编码方式对接，代价就是增加一次光电转换。
真正的问题在管理平面上。传统的OSS系统都是基于TMF814/854标准开发的，但是TMF标准描述的只是理想模型，与传输设备的实现出入很大，它只描述符合什么特征时就如何定义模型，没有反向排除那些似是而非的理解方式。结果导致每个厂商对模型的理解都不一样。运营商和传统OSS厂商又不具备自行统一模型的能力，依赖于从厂商网管取得网络模型。运营商、OSS厂商、设备商三方形成多对多的交叉适配关系。最后所有的网络数据都采集上来了，用户得到的只是很多电子表格，而业务仍然是一堆零件，无法运转。这些网络数据中还掺杂了大量由于厂商网管开发人员不想处理而透传上来的垃圾数据，厂商仍然可以用标准建议解释得头头是道无可反驳。这种情况导致两个问题，一个是跨厂商难以统一管理，第二即使同一厂商，由于存量数据和业务数据量过于庞大，不可能开发出具备足够管理容量的全域OSS。抛开管理容量，厂商开发的各种SDN/NFV协同层产品虽然功能很完善，但是仍然不能用于跨厂商互联，因为这类系统都要求竞争对手设备按照自身的接口格式接入，而竞争对手往往也想推广自己的系统和自己的接口。
能够弥合所有厂商的管理系统必然是一个所有参与方都能接受的中立系统，大家的利益都不应该受到伤害。应该避免厂商迫于商务压力而按运营商要求多头适配，如果存在多套系统平行演进，每套系统都会发现不同的问题，设备商会疲于应付，产品质量更难收敛，系统功能上很难演进提升。应该确保管理系统可以落地，为基层的运维人员营造良好的操作体验，平滑演进，不要追求空洞的线性指标，搞成“八个黄鹂鸣翠柳，四行白鹭上青天”。
TransX就是能够满足上述中立要求的传输管理平台。基于TransX，设备厂商能够实现一次集成多次准入，运营商能够更加平滑地将设备导入到现网上线运行，OSS厂商能够快速交付定制需求，消除延期风险。TransX坚持南向照单全收，北向通俗易懂。在厂商接入上，只采集刚性的物理存量和业务，只要数据是完整的，无论是什么形式，TransX都能快速适配。实践检验，厂商首次对接TransX的完成时间基本都是3周，已有对接案例的厂商能在一周以内完成一个项目配套。在用户界面上，TransX面向运维人员设计，将网络规划的建网思路可视化，而不是将厂商的设备形态可视化，营造尽在掌握的意境。在全域管理上，TransX采用堆叠冒泡的方式管理存量，跨域连接相关的存量会自动向高阶域迁移。对于跨域业务管理，系统根据上下文自动切片，实时组合成一个新的逻辑域，避免将全域常驻内存。通过这些方式，TransX能够实现没有容量限制的全域跨厂商拉通管理。
补齐了这两个豁口就得到了泛在光传送网络。泛在光传送网有两个特征：一、所有的业务设备自带OTN接口，能够无缝地接入光网络；二、传送网内部各个域之间是打通的，业务不需要落地转接，就能从源端直达宿端。泛在光传送网不是要缩小时延或者消减成本，而是要从应用层到物理层打通网络，以适应网络流量在空间和时间分布上的不确定性，达到效率最高。
仰望星空
传送网的建设成本非常大，也是运营商最后一块无法货币化的网络资产。而泛在光传送网是端到端可运营的网络，既能满足企业对带宽的饥渴，又能消化建网成本。
泛在光传送网用商业循环驱动网络演进，逐步解决带宽不足的问题，最终实现“流量自由”。泛在光传送网将与边缘计算结合起来，像电力设施一样，每个社区、每栋办公楼都应该部署一个能提供存储、计算、网络服务的节点，泛在光传送网为这些节点提供互联的同时，也将业务终端接入进来，提供8K视频、VR游戏这种面向个人的点播业务。手机厂商已经在讨论将通信激光器用于人脸识别，未来结合自由空间光通信技术，OTN甚至可以下沉到移动终端，轻薄便携的个人设备，也能用光直连到边缘节点，以较低的能耗获得强大的功能。
泛在光传送网是全光网络的一种落地形式，也是以太网在光域的延续。泛在光传送网要打破传统传送网基于运维体系和线路编码方式构建的封闭堡垒，传输业务下沉会开辟许多新的应用门类，原来的传输参与者能发现许多新机会点，同时也需要使用数通已有的协议体系来充实。 
