加入收藏 | 设为首页 | 会员中心 | 我要投稿 | RSS
您当前的位置:首页 > 教程文章 > 前沿研究 > 软件定义网络

从端口层面对比下openflow和传统交换机

时间:2014-03-17 19:42:25  来源:  作者:

 

端口的传说

TCP/IP网络四层模型中的最底层是数据链路层,该层以比特位为单位传输数据。最开始传输数据的速率是非常的慢,香农提出了信息论的几个基础性概念的定义和定理。然而随着网络需求的新增和新技术的出现,100G的双工端口标准是最近的趋势。端口有电口和光口之分,不同的端口用的传输线缆介质也会有不同,而线缆的价格也是不菲的;好的线缆不仅仅是传输速率的大带宽,还有传输的低误码、线缆信息的标准性、传输性能的稳定性和使用寿命等因素。端口的标准在维基百科(http://en.wikipedia.org/wiki/10-gigabit_Ethernet)有基本概念的解释可以参考。而需要注意的是,交换机端口速率中的M就是106,G则代表是109,这里进制不是1024,而是1000。

交换机的每一个端口都有一个网卡,这个网卡由MAC和PHY组成,现在通常二者是集成在外观上看着是一体的一个芯片里。通俗来说,PHY就是将电信号或者光信号转换后的电信号成转换成比特位的零和壹,MAC层再根据这些比特位来从其中筛选某些比特位组成数据帧,即通常说的一个报文。

相连的两个端口通常还需要支持自协商和端口速率的设置,因为可能两个端口支持的最大速率是不同的,两者需要协商出一个合适的速率进行通信,比如一个百兆口和十兆口相连,最终通常自协商的结果是按照10M来进行速率传输,当然这种情况下也可以人为的将百兆口设置成10M的工作模式,并关闭两端的自协商功能以按照10M的速率传输数据,值得一提的是万兆口和千兆或者百兆进行相连时无法支持自协商,需要人工模式强制万兆口为千兆或者百兆模式才可以工作。

当两个端口传输数据时,端口速率被确定后,如何确定一个数据帧的到来和结束哪?或者说特定端口速率的端口到底传输的报文的有效比特的速率是多少?其实当发送数据报文的设备将报文封装成比特位后在传输介质上传输,前面需要有8个字节的前导帧,前七个字节为0xAA,最后一个自己为0XAB,对接收设备而言标志着一个帧的开始;报文结束后还需要加上4byte的FCS,来确保设备接收的报文从MAC到数据段的正确性,此部分算在报文长度之内;而在传输过程中还有12byte的帧间隙(或者叫帧间距,IFG(Interframe Gap)的来对各个数据帧进行物理隔离,因为现在以太网的传输基本是CSMA/CD方式。并且,数据报文在被编码成物理比特位的时候,保证数据报文内容的物理比特位不会有前导帧或帧间隙的内容。所有上面的20个字节(8+12)都是不包含在 报文的MTU里,但是却实实在在的占用了端口传输的带宽。以交换机两个万兆口传输MTU为64字节无tag报文,因为报文在交换机芯片内部会先被打上一个4字节的TAG(数据报文TAG的识别和添加后文详细再说),这样万兆端口在1秒内能传输64字节(6字节DMAC+6字节SMAC+2字节类型/长度+46字节数据+4字节FCS)报文的个数为(这个速率的计算单位一般为PPS,packet per second):

10*109/(8*(64+4+8+12)) = 14204545PPS

对于带TAG的报文(6字节DMAC+6字节SMAC+2字节TPID+2字节vlan tag+2字节类型/长度+42字节数据+4字节FCS)是:

10*109/(8*(64+8+12)) = 14880952PPS

所以从理论计算上也可以证明,当数据报文MTU支持的越大时,传输过程中所用的20byte的字节所占的带宽比例也就越小,这样带宽利用率也就越高;所以如果整个传输路径如果都能保证开启jumbo功能,且最大MTU一致,那么某些场景下比如存储等功能就可以最大限度的以传输长报文来获取提高利用带宽的效率。所以端口的速率不一定对所有报文传输效率是一致的。

端口另外一个重要的功能,就是端口统计,统计内容包括端口接收和发送报文分别的总个数、错误帧数、丢弃帧数以及各个长度区间范围内的报文数目,这方面的相关标准有若干个RFC来定义,但是交换芯片可以有多种不同的支持或者支持程度。个数统计比较容易。识别出来数据帧后进行加和即可,比较难于处理的是速率的解析。和通常理解的不太一样,无论是BCM还是MVL等传统交换芯片,端口的速率并没有用测速的meter来进行支持(meter其实不能用来测速,只能用来限速),而很多是上层通过软件来计算获取的。计算的方法是固定时间间隔内(通常是5S,有的高级交换机可以有命令来支持在一定范围内设置该值)利用软件主动读取计数,然后时间间隔过后再读取计数一次,然后用前后两次读取的计数差除以时间间隔就获取了该时间间隔内的平均端口速率。当然这样的计算处理方法不是十分的精确,但是基本是能满足我们统计的需求的。Openflow标准1.3中流表的counter统计内容包括:

of flow counter

交换机端口另一个重要功能是流控(FC, FLOW CONTROL),其实流控属于宽泛的QOS功能;值得提及的是流控功能属于入口的功能,因为流控的产生原因虽然有可能是因为出口的阻塞,比如HOL,但是却是由于入口接收的数据帧过多或无法及时转出而导致入口的buffer耗尽产生的,此时接收报文的交换机入端口就会向发送报文的交换机的发送流控帧告诉对方慢点发甚至停止发送报文,等到接收报文的交换机端口有buffer了再给对方发送继续发送报文的通知,这样就可以防止通信中有因为阻塞而发生丢包。对交换机测试流控时数据帧中的两个值需要注意,一方面是流控帧的标识是DMAC为01-80-C2-00-00-01、操作符为1且ETHERTYPE为0X8808,另一个方面是通知对方停止发包的时间参数是操作参数里的数字一定要被设上,而且这个值是以当前传输介质传输速率传512位的时间,范围是:0-65535。需要说明的是流控功能在数据中心很多时候会被关闭,因为和POE功能、STP协议类似这会使得数据链路的传输效率降低,而靠网络规划来规避网络阻塞或者特定场景下容忍一定限度的丢包。QOS在同一个端口上可以针对不同的流基于差异服务模型进行分类处理,如果一个端口开启了流控,即使较低优先级的流发生了阻塞,也会导致较高优先级的流被停止,这种情况是不太合理的,所以提出了PFC(priority FC)的概念,就是阻塞交换机的入口根据阻塞报文优先级发送流控报文,对端交换机根据PFC帧来确定哪种优先级的报文被停止转发,而其他优先级的报文可以继续转发。

传统交换机的端口分为业务口、回环口和CPU口。业务口主要是用于传输数据包括常见的面板口和汇聚口等,回环口会将所有转向它的数据再送回给交换芯片,而CPU口则是交换芯片和CPU通信的网口,主要是将某些控制报文和协议报文送上CPU进行软件协议栈进行处理的用途。另外,对于机架设备还存在各个交换芯片之间传输数据所用的背板口。OPENFLOW交换机端口在标准端口里分为三类:physical ports,logical ports和reserved ports。physical ports对应交换机的面板port,即硬件中存在的端口;logical ports包括汇聚口、回环口和隧道用途的端口等;reserved ports主要用于传统转发的端口和广播口、与controller通信的端口、入端口等概念;openflow1.3标准中规定openflow交换机最多可支持65280个端口,不过通常256端口已经很多了。从这个层面上来讲,OPENFLOW交换机是兼容了以前交换机的,并对交换机的端口从本身需求出发做了扩展,OPENFLOW技术作为转发层面的机制对物理层没有太大的贡献——这方面来讲,也是很多网络技术的一个共同特征,就是兼容原来的技术,从原来的技术扩展发展而来,此类技术可以称之为改革性技术;还有一类是革命性技术,就是如果采用新的技术就需要彻底废弃原来的技术,否则两台设备就无法直接使用新技术,典型的例子就是OSPF和RIP两种路由协议,当然后来OSPF定义了特定的LSA类型来引入外部路由并传播到OSPF的区域内。所以OPENFLOW交换机的网络无论最终是成功还是失败或者是一定范围内被使用,但其都不会在一夜之间取代传统交换机,而在其慢慢成长过程中需要和传统网络的交换机进行通信就需要一些工作来保证二者能兼容性工作,那么这就是我的第一篇openflow方面的专利。

来顶一下
返回首页
返回首页
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
推荐资讯
在CentOS下搭建Android 开发环境
在CentOS下搭建Androi
轻松搭建属于自己的Ubuntu发行版
轻松搭建属于自己的Ub
利用SUSE Studio 打造自己的个性化Linux发行版
利用SUSE Studio 打造
那些采用PHP技术的IT大企业
那些采用PHP技术的IT大
相关文章
    无相关信息
栏目更新
栏目热门