“OpenStack发展历史”有3个回复

1. 理客 于 2013-01-25 5:41 上午

   SDN的产业链当然是最核心的问题；技术上，软件和OPEN可能都不是核心，多核的发展应该能满足SDN的工程商用，包括在转发层面，做大的问题是OF里的查表芯片的定义，首先这这个芯片的通用程度，比如是否从L1-L8都能支持？如果仔细考虑从L1到L8的查表需求，那么做出一个低成本、大容量的标准OF L1-L8查表芯片，个人觉得至少短期内是不可能的，长期也很难，所以按照trading-off的工程处理，这个查表芯片一定要简化，比如只支持L1-L4，有点麻烦的是VPN的处理，如果只处理标准的以太IP报文，会比较简单，但是如果增加VPN的实现，比如增加MPLS处理，又会带来非常多的复杂度。既然所有的互通都是由SDN集中控制，那么还需要额外的VPN技术来隔离吗？直接由SDN集中定义VPN就可以了，所以OF最终蜕化为最简单的处理：只处理L1到L4的标准以太IP报文，做成低成本、大容量的标准查表芯片，配合多核完成转发层面的处理，其他另类的超出L4的需求，还是通过traffic steering交给另外专门的设备处理，才是正解。所以SDN未来的结果可能是：基于通用CPU(intel/arm/MIPS)的集中控制分布计算的控制平面+多核处理器/NP或标准ETH/IP/L4查表芯片构成的转发平面，实现全部的标准化软硬件架构，把进入IP网络设备供应商的门槛降低一个数量级，不可能达到PC的水平，但可以和PC服务器的水平类似。

2. aaa 于 2013-01-25 5:43 上午

   SDN的产业链当然是最核心的问题；技术上，软件和OPEN可能都不是核心，多核的发展应该能满足SDN的工程商用，包括在转发层面，做大的问题是OF里的查表芯片的定义，首先这这个芯片的通用程度，比如是否从L1-L8都能支持？如果仔细考虑从L1到L8的查表需求，那么做出一个低成本、大容量的标准OF L1-L8查表芯片，个人觉得至少短期内是不可能的，长期也很难，所以按照trading-off的工程处理，这个查表芯片一定要简化，比如只支持L1-L4，有点麻烦的是VPN的处理，如果只处理标准的以太IP报文，会比较简单，但是如果增加VPN的实现，比如增加MPLS处理，又会带来非常多的复杂度。既然所有的互通都是由SDN集中控制，那么还需要额外的VPN技术来隔离吗？直接由SDN集中定义VPN就可以了，所以OF最终蜕化为最简单的处理：只处理L1到L4的标准以太IP报文，做成低成本、大容量的标准查表芯片，配合多核完成转发层面的处理，其他另类的超出L4的需求，还是通过traffic steering交给另外专门的设备处理，才是正解。
   所以SDN未来的结果可能是：基于通用CPU(intel/arm/MIPS)的集中控制分布计算的控制平面+多核处理器/NP或标准ETH/IP/L4查表芯片构成的转发平面，实现全部的标准化软硬件架构，把进入IP网络设备供应商的门槛降低一个数量级，不可能达到PC的水平，但可以和PC服务器的水平类似。

3. no name 于 2013-02-07 4:58 下午

   游戏吗？