This paper finishing from Juniper Networks distinguished engineer Sukhdev Kapur speech at the "TF Chinese community established the first full-cum-Conference", an increase of TF description of the function, pdf click to download. https://tungstenfabric.org.cn/assets/uploads/files/powering-edge-cloud-and-multi-cloud-with-tungsten-fabric-sukhdev-kapur.pdf more conference information, please "TF Chinese community "No public replies back," the inaugural meeting of the "get. 
Juniper Networks distinguished engineer Sukhdev Kapur
Hello everybody, my name is SukhdevKapur, from Tungsten Fabric (hereinafter referred to as TF) Community Technology Steering Committee, following me tell you about the status quo TF architecture and technology, and the latest developments.
TF architecture and deployment model
我们可以看一下这张TF的宏观架构图，整体图描述是设备的物理连接，而右上角有虚机之间的逻辑网络，TF基本的工作原理和机制，就是你创建VM或者POD，然后（通过SDN）把它们放到这些逻辑网络里。
在这些逻辑网络中，你能够以根据自己业务需要，放置任何虚机、PODS、或者裸服务器，它们的物理位置在哪里没有关系，它们可能会在一个集群里，也可能在一个机架中，这都没有关系。
大家再看一下它下面底层的部分，TF会利用虚拟的路由器（计算节点上），来负责是这些虚拟的工作负载的转发，而左边是一个物理网络的连接，例如一个裸机的物理网络，一旦你做好了网络定义，它可能会和实际网络连接，也可能会和右边逻辑网络里头虚拟网络的虚机来进行连接
第四部分（上半部分）是CONTRAILController（SDN控制器），是做配置控制分析和CSN的。
第五部分是网关的功能，它可能是一个物理网关，或者是一个虚拟的网关，当数据中心的虚机需要对外互联的时候，通过IP的组网——也就是MPLS这种协议——进出骨干网络。
所有这一切，都是通过一个ORCHESTRATOR编排器去管理，它可能是OpenStack、K8s或OpenShift，通过API来调度TF来工作。
TF中Vrouter的体系架构概述
这张图说的是TF的路由vRouter的架构，左上角是vRouter的Agent，主要是控制的部分，在这里它会通过路由的学习，VRFs的定义，以及策略的定义，如果虚拟路由器要进行策略的执行，必须是由Agent去控制的：它来决定网络的流量是允许通过,还是拒绝，如果允许的话，应该把它转发到哪个位置。
你可以看到，vRouter有一个转发的路径，学习的路径进行封装，然后做二层或者三层的数据流量的转发。
vRouter的部署模式
这是TF虚拟路由器的四种部署模式，左上角是默认的模式，在内核的vRouter部署。
右上角呢？如果你在一个高吞吐、高流量的状态下，网络支持DPPK的话，TF可以有的DPDKvRouter的部署。
左下角其实是一种混合部署的模式，如果你有好几个VNF这种虚拟网络的功能，可以用到SR-IOV的话，可以采用SR-IOV和内核的vRouter共存的混合模式。
第四种就是基于SmartNIC的vRouter，也就是说，这些VM可以充分地利用到所有处理器的能力。
TF与Kubernetes的集成
大家再来看一下TF和Kubernetes（以下简称K8s）的集成，首先，TF的CONTRAIL Controller会和K8s通过API进行通讯，那么，某一个指定的位置，它是如何得到IP地址以及策略的呢？首先，K8s会和TF的Scheduler也就是调度管理程序进行通讯，再通过调度管理程序和CNI Plugin插件进行联系，在左上角就表示vRouter是如何获得在K8s这边的策略，去进行IPAM的读取和执行的，简单一点说，K8s的管理器会和TF的CONTRAIL Controller进行通讯，确定网络的策略，然后TF的Controller会把这个策略发布到vRouter。
TF的微服务架构
TF的技术演进，一开始主要是基于虚机部署，后来开始支持容器技术，现在已经演进到了微服务（Microservices）的架构。目前我们的TF在部署是完全采用containers的方式进行部署，大概有27-30个左右的image。
K8s环境下的网络隔离
K8s是一个非常扁平的网络，租户和租户之间可以进行任意的沟通，工作负载之间也是这样。
基于这样的场景，我们就通过网络策略的执行，去实现网络中租户的隔离，也就是说，只是在指定区域内的用户之间，才可以进行沟通。
那么在TF这一层，我们把管理又向前推进了一步，即在一个租户的空间之内，我们也可以决定哪个位置和哪个位置可以沟通，也就是哪个POD和哪个POD通讯。
TF提供的统一策略管理功能
下面为大家介绍一下TF的独特的策略框架。假设我们有一个应用，该应用有三层，分成三层，分别是Web层、应用层和数据库层。而这个应用的生命周期会有三个阶段，分别是开发的阶段，部署准备的阶段，和最后的生产阶段。
不同的阶段可能部署在不同的网络环境，甚至于不同的云平台中，那么在最上面的开发阶段，不同的层之间（层也是tie的概念），会有一些安全的访问策略（图中P1的策略也），而这个策略可能在部署准备阶段也需要（图中P2的策略）在生产阶段也需要，在不使用TF的情况下，很有可能会出现重复的策略，而是用TF之后，我们可以只使用一个策略
我们所做的就是把策略的管理进行了简化，首先就是降低了复杂性，简化管理，提高了可伸缩度。一旦定义好了策略，你就可以在各种各样的环境之下，进行规模性的、可伸缩的复用，包括公有云、私有云，以及多云的环境。
给大家介绍一个实际的策略框架用例。
假设我们有一个应用，我们允许它的Web层和应用层进行沟通，那么不管是在开发阶段，还是在生产阶段，我们都可以使用这样一个定义，比如在开发阶段的Web层，也可以和生产环境下的应用层进行沟通。
但是，也许我们并不希望有这样的事情发生，我们不希望某一个开发人员能够随意修改在生产环境下的代码。这时你不用去改变策略，只需要在策略里头加上App Match Deployment的标签，它可以去规定——比如说只有在开发阶段的Web层和开发阶段的应用层才可以进行通信。
同样地，如果你的应用是一个地理分布式的应用，你可以通过定义策略，让在地理区域A的Web层和在地理区域B的应用层之间进行通信。
如果你不希望这种跨层、跨区域的通信产生，就在AppMatch Deployment的后头再加上End Site。所以说这个match，不光是它的部署，还有它的位置，你都要把它match一下。
我们再加一层，你看我们第二个策略的意思，就是说只要是这个站点我们match上了，匹配上了，那么它们都可以和数据库进行访问。
这样的一种策略在管理方面非常的有用。如果你有一个非常大型的跨地理区域分布式的金融应用，它可能使用了多个网络，网络上还有数百种的应用，这个时候你只需要一个策略，就可以对整个分布式的金融应用进行管理。
一个界面，搞定多云部署
同时，TF还可以实现多云部署的自动化管理。比如说我们在驻地这里自动创建了一个叫做多云的网关MC-GW，它会建立一个通道，和在云端的（比如说AWS上的）同样的部署，自动地进行安全的连接。
这里也要看，你在云上部署的工作负载到底是什么种类的。有了这个工作负载，你可以在本地云的环境下进行管理，而TF能够给你一个多云的可视性。
大家可以看一下，如果你自己去进行多云管理，需要通过很多的流程来实现。而TF只需要一个单一的图形用户界面，就能够轻松地进行多云管理，你需要做的，只是做几下点击的动作。
多云环境的服务链
下面来介绍一下TF的多云服务链。大家看到最上面有两个网络在驻地，左边的是2.2.2.4，右边的是3.3.3.5，然后有一个服务的实例，假设服务实例是POD的虚拟化服务，通过TF的服务链，可以将工作负载从左边的网络传到右边。
同样地，如果要在不同的公有云上也去部署这样的虚拟网络，你可以通过TF，从驻地到多云建立这样一个服务链。
我来总结一下，只需要一个SDN的控制器，就能够去管理连接——不管是金属裸机、K8s CNI、OpenStack，还是左边的各种边缘的站点——并且提供非常丰富的网络功能。
TF与Akraino的集成
TF在边缘计算的环境下也做出了自己的贡献，这是另外一个开源的项目，TF实现了和Akraino的集成，能够为边缘计算这样的场景提供支持，它是纯基于K8s原生基础架构的，非常适用于轻量级的，像工业自动化这种应用。基本上它部署的环境是非常小的，目标行业主要是电信运营商和企业级用户。
这是另外一个Akraino和TF集成的用例，主要是打造电信云，目前美国电信运营商AT&T就做了这样的一个架构部署。这里主要是使用SR-IOV这种虚拟化，我们所做的就是把TF作为一个单一的SDN，它的部署模式包含了以上所有类型。
这是第三个用例，它是一种叫做微云的软件堆栈，主要应用于移动的场景，例如手机游戏，工作负载是移动化的这种架构。
在这里我们是怎么做的？首先，我们有一个DME（分布式的匹配引擎），它知道有多少个设备或者多少个移动用户接入进来，并根据移动用户的数量，启动微云资源管理器去做信息传递；然后微云资源管理器就会匹配到相应的资源；接下来CRM会和TF的控制器进行沟通，来进行这种资源的部署；再到下面一层，通过vRouter的转发层，和TF的控制器进行联系。
TF与OpenStack的集成
熟悉OpenStack的朋友都知道，它有两种部署模式，一种是单一的插件方式，另一种是基于ML2的部署。
TF专门有一个Networking Open Contrail，可以将TF作为一个ML2的插件去启动。这样做有什么好处呢？我们可以同时去运行基于OVS、SR-IOV和vRouter的这工作。
你可以用OpenStack来运行OVS、SR-IOV的工作负载，并且在网络层面使用我们的TF去进行管理。
Learn more about Fabric Tungsten
TF introduce Chinese community
TF main features and use cases
TF how it works
Detailed vRouter architecture
Focus on micro letter: TF Chinese community 