谢谢主持人，我自我介绍一下，我叫鲁子奕：，熟悉的人都叫我杰瑞，非常高兴今天有机会跟大家在这里展现一下CENI未来网络实验和探索。有谁还不知道CENI的请举手。这两天大家都知道了。CENI是为了鼓励中国网络创新而搭的一个实验平台。

那么我们看一下，我会介绍一下CENI，再介绍一下CENI这个网络上的思路和架构，可能着重谈一到两个创新点，最后我们讲一下在CENI上我们是怎么实现网络资源的按需分配的。CENI的建设目的是为了建设一个大规模的网络实验的设施，这个是CENI的主要目的。那你就肯定要建一个全国范围内的网，一般来说我们就是说你传输是怎么搭的，这个就是传输，传输会新建80×100G的传输系统，大家看一下，我就不读了。这个是它的骨干网、边缘网、接入网，这里一共有四个核心节点，其中5个是超核节点，8个一级节点，27个二级节点，那么边缘网络现在规划的是30个，但是其实有可能是超过30个。大家会问什么是边缘网络，边缘网络就是你可以这样想，凡是接入的比如说你是数据中心，你一个学校，一个园区，对CENI来说其实都是边缘网络。

好的，下面我花一点时间着重讲一下CENI的网络设计。我们首先要给研究者提供一个真实的网络环境，其中包括骨干网、区域网、园区网、边缘网络或者是数据中心。第二本身我们在上面有很多用户或者是租户，我们怎么来按照这些租户的需求来分片网络，把网络资源可以进行按需分配，这其实就是CENI我们在设计的时候要考虑到的点，脱离了这两点我们就违背了CENI本身实验的目的。很有意思的是，CENI本身是给其他人提供一个实验网络，但是我们把CENI本身做成了一个实验网络，所以我们在这里试了什么事情呢？你可以看到很有意思的一些事情。针对第一点，我们提出了CENI的Zone设计、Region设计、Backboen设计。第二个我们主要是以交换机构造的骨干网，可能大家会比较好奇，因为熟悉我们的都知道联通的A网和一些大的运营商的骨干网都是我们参与做SDM化的，这些我们都是根据路由器来做的，比如说思科的或者是华为的或者是类似大品牌的路由器来做的。那么在CENI里面，我们很有幸用实验网本身做实验网，我们看看用白牌机和交换机能不能搭一个大规模的互联的骨干网，事实证明是可以的。第三个我要提的就是今天早晨赵慧玲在讲SP运营商开放的时候，不知道大家有没有注意到，有一个方向就是城域网的改造。在CENI上，我们在一年半甚至是在两年以前，我们就提出了城域网能不能用数据中心的方式来构建，用spine-Leaf的方式来构建，实际上我们现在已经是构造了整个城域网和区域网。这个里面的背景是这样的。因为老的网，知道现在的城域网接入网运营商很复杂，这个在当初设计的时候，很多时候我们考虑这个因素是以南北向的流量为主，我们经常说到南北向，所谓的南北向就是去英特网。那么在现在的流量，你如果再看的话，很多其实是东西向的，所谓东西向就是我可能这个流量不管是家庭的还是企业的流量，可能因为随着边缘计算越来越多，随着数据中心越来越多，其实很多流量是流到数据中心或者是流到边缘计算的节点去的，那么这些节点其实你是不上整个英特网的，也就是我们说是东西流的，那么东西向的话因为传统的设计问题，就是城域网对东西向是很不友好的流量，所以我们就考虑它是南北向直接出去的。而数据中心恰恰，因为大家知道当时为什么采取CLOS架构，因为传统的数据中心在这个之前是典型的三级，接入、汇聚、核心，那么为什么我们会把它扁平化到spine-Leaf架构，就是因为可以减少它的时延。这个方面我们在CENI上也做了一些尝试，下面我会提到一些。

在网络资源按需分配上，我们主要做的工作，大家还记得昨天柳院士发布了CNOS，我们是基于这个CNOS操作系统做了一系列的控制器，在上面也有一个统一的变换系统，所以对于租户来说，其实他所有的需求我们都是按照业务或者是按照看不到我的资源的，就是完全是以资源或者是业务的使用来下发，可以完成端到端的资源分配。

下面我分开讲一下各个地方我们做的一些设计，这个就是我们设计的Zone，它可以是一个校园网或者是一个数据中心，这个我就不多讲了，大家可能很熟悉，典型的Spine-Leaf而的架构，你要出南北向也好或者是东西向也好都是通过这个出去，所以这个大家都很熟了，我就忽略它了UNDERLAY是走IGP或者是BGP，实际上在数据中心里面我们可能见到的BGP更多，OVERLAY是BGP-EVPN。我说一句，我们是在三年前做过基于OPENFLOWER的数据中心的解决方案，最后的结果是不怎么好的，就是我们做小规模的可以，但是我们再大规模的时候，发生了很多服务器突然间一起上线，然后就出现了很大的瓶颈，那个时候我们就放弃了OPENFLOWER，以至于我们放弃了所有的OPENFLOWER方案，所以我们现在做的基本上还是ERPC的方式。

我们看看我们这个Region的设计，你可以把这里理解成一个区域王或者是城域网，在这里我们没有看到城域网的设计，我们把整个网也看成是一个Spine-leaf的架构，但是具体我们可以在后面看到大的组网，现在的CENI的结构我们知道可以开通12个点，还是不需要这么复杂或者说这么多节点的区域网的设计，所以在这里我们把很多设备合二为一了。它的region的设计也是这样的。我们看一下我们Backbone的设计，我们可以看看我们的Zone，还是region设计，还是Backbone设计，我们用的VPNP4，有可能大家说我们要并存，我建三层的VPN可以用P4，我用二层的VPN就用其他的，其实不是的。大家可以看到，在于整个Backbone网上，我们只用了P4这一个来做的。UNDERLAY在这里，我们就用了IGP，我们没有做任何的改变，但是OVERLAY用的是BGP-EVPN。这个里面我们用的是转发面的骨干网上的MPLS+SRTE，这个我们想其实我们公司最早做这个是在两年前，那个时候也是最早的一个MPLS+SRTE网络。我们在CENI上也是沿用了这个，当时有几个选择，第一个选择其实是SRv6，但是为什么不用SRv6呢？第一是因为它不成熟，第二个是转发效率太低，因为可能大家也知道，BAT也在试这个SRv6，我们也希望用SRv6，但是MPS的效率很高，但是你要用IPv6的话，你要是没有专门的ACK转发效率就太低，所以综合考虑下来，我们还是使用了基于SRv6的CENI的Backbone设计。

这里还有一个比较有意思的就是我们用交换机代替了路由器，它其实带来了多方面的不同，当然，最主要的是大家可以知道，路由器就是有很大量的转发表，因为他本身是给英特网设计的，那么在交换机上就没有这么大的转发表，如果只是从转发表来说你无所谓，因为我们这个网本来就是一个专网。本身Backbone完成的任务就是让他们可以互通，所以你可以看到从某一个Region连到另外一个Region，这个中间其实是一个骨干网，是一个跨很多节点的骨干网。所以看完这么多，可能大家会觉得这个CENI挺简单的，但是其实它还是有一些特殊的考量在里面。

整个的网络结构我这里就划了一个示意图，其实我们大家看一下我们的设计准则，就是在设计的时候，当然我们也综合了一些我们以前碰到的一些坑，碰到的一些问题，尤其是在大网设计上。我们的设计准则，第一个当然是无单点故障，第二个是控制器一定不参与转发面，任何形式的转发面控制器都不参与，所以这样的话，就是控制器的失联都不会影响现有的业务，但是它有可能会影响新业务的下发。最后一个就是分布和集中相结合，很简单，我举一个例子，这一点可能一般大家都会忽略，尤其是对大网来说这个很重要。为什么很重要呢？我举一个例子，网络故障，很多人说我网络故障没有关系，我知道了这个网络故障，重新算一下，让你的流量重新走就可以了，听起来很美好，其实这是不可能的，因为在大网上，我们先不说控制器可能会失联，我们说一个简单的问题，不管怎么样你都要几十毫秒来计，但是如果你从这里再下去就是几百毫秒下去客户不通了，在大网上那是不可承受的，我们要求在大网上是要五十毫秒之内通。所以这种情况下我们要的是自恢复，我们先保证他同，随后我们控制器可以慢慢的算，算完了以后重新把最优的方式下发下去，但是你一定要先保证它通过，这样就造成了我们在设计的时候有各种各样的中间切换倒换的机制，其实都是保证一点就是保证在五十毫秒之内。

大家可以看一下，这个左边其实大家说好像没有那么复杂啊？确实是的，因为我们很多的功能都把比如石中剑的某一个P的交换机其实也结合了这个功能，但是到最后如果你的区域网上面的比较多，可能还没有到我们的Region设计，但是在现在的情况下，大家可以看一下，我们在这个蓝色下面的就是接入，我们的接入可以出口比如说DC的出口交换机，或九是一个企业，或者是一个园区的出口交换机都可以，它连上来以后，其实我们把那个叫做PE，其实你可以把这个PE认为是一个Leaf，因为它其实是和另外一个PE建了一个OVERLAY，所以在这个时候，比如说我们说这里我不用它也可以，因为这个中间只要保证网络通，一个基本的IP协议它也是通的，所以这个其实在我们最初做运营商的时候，我们就特别在意这个，在这里我们所有的设想就是你要保证最基本的通畅。因为时间关系我就不细讲了，大家可以看一下，下面有很多不同的颜色其实就表明在这个里面走的是什么路由协议转发面是什么。

下面我说一下我们在CENI上怎么进行网络资源的按需分配。我刚才基本上讲了，大家看最下面这一层，基本上就是借助网络也好，骨干网络也好，或者其实我们现在也支持各种的云商，在中间这一层其实就是控制器以及对整个网络现在实施的情况。再上层其实是编排器，那对客户来说，其实他看到的是最上层的业务编排器，业务编排器的功能我就不读了，大家可以拍照或者是看一下，这些就是最基本的从业务的角度我们应该具有的功能。那么我们把它从业务变成了API下发给控制器，这个就是控制器的被向API，对于控制器来面它还有一个南向API，他就是有控制设备或者是接口。这个是基本的功能。对于不同的控制器我就大概讲一下，就是不同的控制器他做了什么工作。对于骨干网控制器，他主要做的工作就是来回调度，根据各种状态网络来进行选路。当然，我们支持路由器也支持交换机，是在一个统一的VPN的网络协议下。

我这里要稍微讲一下，就是流量调度到底难在什么地方，因为它是在头端的PE上，一般你就会把整个Pass打上去，大家觉得很简单，我就这样决定整个路径，但是你仔细想想它的问题实际上很多，我们举一个最简单的例子。右边这个图开始的时候，你们看，他其实走的是上面的那根线，就是一般来说和IGP是吻合的，就是最短路径，如果说C和D之间，这个Link满了，或者说你的阈值超过了，我就要走下面这个线，听起来很简单，因为这个满了，但是你仔细想一下，这个里面涉及到多少问题。首先你要知道这个Link是满了，那我们就要有一个监控，那么这个监控的频率是多少？这就是一个问题。第二个就是你这个Link满和Link故障是两个事情，Link满你可以慢慢调，但是如果他有故障的话你就及时的解决。第二个最重要的就是你怎么选这个路，你看起来很简单，但是你实际想一下，如果说40个节点或者是更多节点的时候，在这个网络上，你怎么能够选择出一条路来，你怎么知道这个路是可以的，因为这个路上不仅是有你这个点，也有其他很多人的点，你可能很自然的就想到一个办法，我当初这个开这个业务的时候，我就选择了它，这是一个办法，但是这个带来的问题就是你整个网络的使用率不高，因为大家知道他开10兆可能很多时候只用到10%到20%，那么我们还是要进行动态调解的。第二，我们最终的目的是A到Z，你可以认为是北京到上海，那么在中间要建几条路呢？这个路径是预建的吗？还是说我发现它满了以后我临时再去建的呢？我是按照什么原则来挑这几条路呢？这是一个非常有意思的话题。即使我把这个路的问题都解决了，更大的问题在第三个，我怎么知道，我怎么知道A到Z里面哪些流量要调节出去？因为A到Z就相当于北京到上海，我不可能对每一个租户都进行一个探测，所以A到Z之间的SRTE的路径一定是共享的，也就是说在A到Z这个不管是蓝色的还是下面这个黄色的路上，其实有很多的流量是共享的，那么问题就来了，我知道C到Z是快满了，那么我把哪些流量调走呢？我如果都调走了那黄色的就都满了，所以这就带来了一个很大的问题，就是我怎么调。这个里面有两种办法。在我们的实践中我们发现路由器就是我刚才说到的，就是我们可以把它进行精确调节，也就是我知道在这条链路上有300个流量，我要清楚的知道，我清楚的知道调其中两个流量走这条路就好了，所以就相当于拥挤了，我知道哪些流量绕路走就可以了，这是可以做到的。在CENI上我们采取的是A到Z我不知道什么流量应该调，但是我有办法在A到Z的路上满的情况下再给你造两条路或者是三条路，然后看看是不是满足我们的条件。然后我们会建完一条路让流量，因为流量哈希以后会自动走这条路。我们会看满足不满足，如果不满足我们就继续扩，当然我们现在也在跟交换机的厂商也在讨论是不是可以给我们更精细的统计，这样的话我们就是不用盲目的扩路，而是采用精确的分流的方法来做。

这个就是接入网或者是城域网或者是区域网控制器要做的事情，它其实我们是希望它做灵活多种的接入，包括数据中心接入、边缘网络、包括企业校园网的接入都在这里，所以这个其实我相信最近大家都听过很多SD-WAN包括这种概念都是融合在这个里面，所以我们会又支持英特网又支持专线，我们也支持各种上联方式，很重要的是我们会基于APP进行智能选路。如果大家感兴趣的话，其实这个里面的细节也有很多，比如说基于APP怎么智能选路，你怎么来看这条路的状态。这个就是CENI的DC控制器，大家想一想，就是骨干网接入然后导入数据中心，然后我们也是做了一套针对CENI的DC控制器，简单来说求是Spine-Leaf的架构，然后会基于BGP-EVPN建立OVERLAY虚拟网络，我们也失陪多种云资源，可以裸金属也可以是虚机也可以是容器，当然我们也可以多厂商网络设备统一纳管，所有的其实都包括了对网络UNDERLAY和OVERLAY虚拟网络的监控。

因为时间的关系我今天主要介绍的就是这么多，主要是让大家了解一下我们怎么考虑这个CENI网络用交换机搭的，中间也有我们的想法，欢迎大家批评指正和交流。谢谢。