CN101527686B - 一种数据交换方法和设备 - Google Patents

Abstract

本发明公开了一种数据交换方法和设备，涉及网络技术，实现方法简单，节省系统资源，且进行单播交换时，下行方向信元顺序重排代价较低，进行多播交换时，调度较易，数据通过率较高。本发明实施例提供的数据交换方法，包括：接收信元的交换请求；根据所述交换请求，对所述交换请求进行仲裁，获取仲裁结果；根据所述仲裁结果，对所述信元执行相应的交换，所述交换包括单播交换和多播交换。

Description

一种数据交换方法和设备

技术领域

本发明涉及网络技术，尤其涉及一种数据交换方法和交换设备。

背景技术

随着网络技术的飞速发展及网络应用的日益普及，要求网络交换系统能够同时支持单播(unicast)和多播(multicast)方式的数据交换。

图1为一个网络交换系统的结构示意图，左端的接口系统，具体实现可以是n个线卡或者是n个交换网接口(Fabric Interface)芯片等，该系统中的任一个设备所输出数据信元(cell)或者数据包(packet)，可通过中间的交换网(SwitchFabric)系统中的任一个交换设备，如m个交换网芯片或是网板等，到达右端的接口系统中的任一设备(如线卡)，即目的端口。也就是说入端口发送的数据信元或数据包(为简化描述，本文用信元做统称)可以通过不同的交换网芯片到达目的端口。

目前，交叉交换(Crossbar，简写为XB)机制为一种实现中间交换网系统的常用交换机制。利用XB交换机制进行数据交换时，首先，入端口向交换网系统提出调度申请(Request)，表明本线卡有信元需要去往某个目的端口；然后，交换网系统依据所有线卡提出的申请按照一定的匹配算法进行仲裁调度后，产生交换仲裁授权(Grant)并将授权信息通知所有线卡。在收到各线卡根据Grant发出的信元之后，XB再按照之前匹配的结果配置各个入端口到出端口的交叉连接(Crosspoint)，完成数据交换。

另外，XB交换网在配置Crosspoint前，可能需要先在入口处用一定的缓存(Buffer)对从不同入端口先后接收到的信元进行偏差补偿(deskew)。

在实现本发明的过程中，发明人发现现有技术中至少存在如下问题：XB交换机制具有集中调度的特点，其调度算法和调度过程适合于单播数据的交换，不适合多播数据交换，若利用已有的XB交换机制实现多播数据交换，要大量占用入端口至中间级交换网的带宽，即若XB同时处理单播数据和多播数据时，会降低数据交换的效率，并增加系统资源。

发明内容

本发明的实施例提供了一种数据交换方法和设备，以对信元分别进行单播交换和多播交换。

根据本发明的一方面，提供一种数据交换方法，该方法包括：

接收信元的交换请求；

根据所述交换请求，对所述交换请求进行仲裁，获取仲裁结果；

根据所述仲裁结果，为所述信元分配相应的入口带宽和出口带宽；

当所述仲裁结果为对所述信元执行单播交换时，利用交叉Crossbar机制对所述信元进行单播交换；或者，

当所述仲裁结果为对所述信元执行多播交换时，利用存储转发Store andForward机制对所述信元进行多播交换。

根据本发明的另一方面，还提供一种交换设备，所述设备包括：

接收单元，用于接收信元的交换请求；仲裁单元，用于根据所述接收单元接收到的交换请求，对所述交换请求进行仲裁，获取仲裁结果，根据所述仲裁结果，为所述信元分配相应的入口带宽和出口带宽；交换单元，用于根据所述仲裁单元的仲裁结果，对所述信元执行相应的交换，所述交换包括单播交换和多播交换，其中，当信元由所述仲裁单元确定为执行单播交换时，利用Crossbar机制对所述信元进行单播交换；当信元由所述仲裁单元确定为执行多播交换时，利用Store and Forward机制对所述信元进行多播交换。

本发明实施例提供的技术方案，采用一种混合的机制实现单播和多播信元的交换，对信元的交换请求进行仲裁，并根据仲裁结果来对信元执行单播交换还是多播交换，可以实现对信元分别进行单播交换和多播交换，并从而提高了数据交换的效率、节省了系统资源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为一种网络交换系统的结构示意图；

图2为本发明实施例一提供的数据交换方法流程图；

图3为SM机制下一种交换网芯片的内部结构示意图；

图4为本发明实施例一中的共享缓存交换机制方法示意图；

图5为本发明实施例一中的共享缓存交换机制下一种典型实现方式示意图；

图6为本发明实施例二提供的一种交换设备结构示意图；

图7为本发明实施例二提供的另一种交换设备结构示意图；

图8为本发明实施例二提供的另一种交换设备结构示意图；

图9为本发明实施例二提供的另一种交换设备结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例一提供了一种数据交换方法，如图3所示，该方法包括：

步骤21：接收信元的交换请求；

上行的信元在进行数据交换之前，需要向交换网系统发送交换请求，该交换请求可携带在该信元的头部，或采用其它合适的实现方式，如发送单独的交换请求消息。信元还可以在头部加入信元类型信息，以指示该信元的类型，如该信元为多播信元、单播信元或空信元等。

交换网系统可根据信元类型进一步确认与已仲裁授权进行交换的信元类型是否一致。

但不限于此，根据需要或应用的网络协议，在信元头部还可包括其它所需的信息，例如，目的端口标识，用于指示输入端口对应的输出端口；当考虑到支持QoS时，还可携带优先级位(Priority bit)，以区分单播/多播请求的优先级，或不同数据源的优先级，或各线卡的优先级等。

其中，对上述信元类型、目标端口标识、优先级位的具体实现方式不做限制，例如，对单播交换，目标端口标识可携带在单播请求中，也可使用独立的比特位进行表示。

如表1所示，给出了一种信元头部数据结构的实现方式。该交换请求包括多播请求和单播请求。可选的，如表2所示，为多播请求和单播请求的一种实现方式，多播请求占用1bit，单播信元请求占用n bit，n的值可由目的端口的数量确定，如有16个目的端口，则n的取值为16，每一比特位可对应一个输出端的目的端口，但不限于此，包括利用任何其它适合的形式提出单播请求或多播请求。

当上行有单播信元需要进行交换时，则根据单播信元的目的端口将单播请求n bit中对应比特位置为有效；这时，当上行有多播信元需要进行交换时，可同时将多播请求置为有效。

进一步的，信元头上还须指示本信元Payload对应的信元类型，根据该信元类型至少可区分单、多播信元。

表1

多播请求

单播请求

信元类型

Payload

表2

？？？？(1bit)

？？？？(n  bit)

步骤22：根据所述交换请求，交换网内的仲裁机制(Arbiter)对交换请求进行仲裁，以获取仲裁结果。

在本实施例中，该仲裁结果为仲裁对所述信元执行相应的交换，所述交换包括单播交换和多播交换。这里的主要以单播交换和多播交换为例进行了说明，但不排除其它适合的交换方式。在本实施例中，也可以理解为该仲裁结果为对所述信元执行单播交换还是执行多播交换。

对初次的数据交换，上行线卡向交换网系统发送携带单播请求和/或多播请求的空信元，仲裁机制根据该交换请求的类型，仲裁授权执行相应的交换，如单播交换或多播交换。下一次发送数据时，如表1所示，上行在信元头部填充payload、该信元的信元类型，及用于后续再一次数据交换的单播请求和/或多播请求。

交换网一方面根据仲裁机制已作出的仲裁结果将信元所携带的payload完成交换。另一方面，仲裁机制根据当前信元头携带的交换请求仲裁授权下次的数据交换。重复上述操作，从而保证了数据交换的连续执行。

仲裁机制可根据已接受的多播信元和服务质量Qos策略，利用所述信元的交换请求，获取所述仲裁结果。

例如，当信元的交换请求中同时存在单、多播请求时，若仲裁机制判断出已接受的在存储器Memory中的多播信元存储量较少，且Qos策略为多播交换优先于单播交换时，做出的仲裁结果为接受多播请求，分配多播带宽；若仲裁机制判断出已接受的在存储器Memory中的多播信元存储量较多，且根据Qos策略当前应当处理单播交换时，如Qos策略为每服务3次单播请求，进行1次多播请求，而当前应服务单播请求时，做出的仲裁结果为接收单播请求，分配单播带宽。但不限于此，仲裁机制可同时根据已接受的多播信元和Qos策略进行仲裁，也可单独依据已接受的多播信元或Qos策略做出仲裁，或以其中一种作为主要的依据，将另一种作为参考的依据。

由于单播和多播通过交换网的方式不同，在同时进行单播交换和多播交换时，在获取到仲裁结果后，本发明实施例一还包括：根据所述仲裁结果，为信元分配带宽。在本实施例中，该带宽包括入口带宽和出口带宽。

为所述信元分配相应的入口带宽主要包括如下处理：

如果从入端口接收到的信元的交换请求中同时存在单、多播请求，对提出请求的信元，仲裁机制根据已接受的在存储器Memory中的多播信元存储量和服务质量Qos策略，获取仲裁结果，根据该仲裁结果判断是接受单播请求屏蔽多播请求，还是接受多播请求屏蔽单播请求。也就是说，仲裁机制能够对交换请求做出一种“过滤”式的处理，在此基础上，再进行出口带宽分配。

例如，来自入端口线卡1的信元同时携带单播和多播请求，若仲裁机制接受多播请求，为该信元分配多播带宽用以从入口线卡接收该多播信元，并屏蔽该信元的单播交换请求；若仲裁机制接受所述线卡1的信元的单播请求，为该信元分配单播带宽用以从入口线卡接收该单播信元，并屏蔽该信元的多播请求。

如果接受了多播请求，则仲裁机制会在仲裁完成之后，将允许多播发送的授权(grant)通过信元头传递给入端口线卡。最终该grant对应的多播信元会利用所分配的入端口带宽传到交换网，并存储在Shared Memory中，见步骤33描述。

为所述信元分配相应的出口带宽主要包括如下处理：

仲裁机制根据memory中多播信元的多播请求和已通过入口带宽分配处理的单播请求，用QoS策略分配出口带宽。

存储在Shared Memory中的多播信元会按照其扇出进行复制，并进入响应的目的队列中。如果队列非空，则可以向Arbiter提多播出队请求。

对多播信元，先为其调度入口带宽，再为其调度出口带宽，入口带宽和出口带宽的调度通常为两个步骤，对单播信元按照Crossbar机制进行带宽调度。即Arbiter首先依据本芯片内memory的多播信元缓存情况以及Qos的策略，在单、多播之间调度交换网的入口带宽，如当分配结果是首先分配多播带宽时，则屏蔽相应端口的单播请求，否则当分配结果是首先分配单播带宽时，屏蔽该端口的多播请求。

Arbiter再根据“过滤”之后的单播请求和本身Memory内的多播请求分配出口带宽。在一次入口带宽和出口带宽调度完成之后，由于单播请求可能不能获得出口带宽，所以其占用的入口带宽也会被释放，此时Arbiter还可以将剩余的入口带宽再次分配给入端口的多播请求。

步骤23：根据该仲裁结果，对接收的该信元执行交换，所述交换包括单播交换和多播交换。

本发明实施例中利用交叉(Crossbar)机制对相应的的信元进行单播交换，利用存储转发(Store and Forward)机制对相应的信元进行多播交换。

在获取到仲裁结果，执行完入口和出口带宽分配后，按照仲裁结果进行当前的数据交换。在本发明实施例中采用了Store and Forward机制中的SharedMemory机制对多播信元进行处理，但不局限于此，包括Store and Forward机制的其他实现方式。相关描述适用于文中相同部分的内容。

根据表1中的信元类型区分单、多播信元，当当前处理的信元类型与已仲裁授权的交换方式一致时，分别执行相应的处理，如根据Crossbar机制，利用分配的单播带宽，对相应的信元进行单播交换；根据Shared Memory机制，利用分配的多播带宽，对相应的信元进行多播交换。

以上描述了用Crossbar和Shared Memory分别对单播和多播信元进行处理的交换网机制。为了便于理解，图2示出了一种简化的示意方式。为了清楚地理解本发明的优点，在本实施例中，Store and Forward机制典型的实现方式为基于共享缓存(Shared Memory，简写为SM)的交换。这里对先对本发明实施例中的Shared Memory交换机制的实现方式进行更详细地描述。

图3所示为SM机制下一种交换网芯片的内部结构示意图。左边n个入端口进来的信元都要缓存在中间的同一个Shared Memory中，Memory内存储空间会按照出端口划分为n个独立的缓存区域或者用链表(link list)的方式共享，每个独立的缓存区域或者链表对应一个目的端口队列。在调度出队时，各出端口从对应独立的缓存区域中读取信元输出。

图3所示的SM机制中，因为所有端口会同时对一个Memory读写数据信元，所以对Memory的读写带宽的要求为2nr，其中r为端口速率。这样大带宽的Memory很难实现，因此实际上SM通常采用多个Memory的机制。

如图4所示，需要交换的信元首先进入左侧的交换网系统，交换网系统为该信元分配入口带宽。该信元按照要到达的目的端口缓存在对应的Memory中，或者按负载均衡(Load Balance)的方式平均分发到中间级的Memory中；输出信元时，交换网系统为该信元分配出口带宽，在Memory中对该信元进行复制，将信元从对应的Memory中读出，经过右边的交换网系统抵达目的端口。应当理解图4中两个交换网系统，可由同一的交换网系统实现。

图5为图4的一种实现示例。以16个入端口、16个出端口和4个存储器为例进行说明。来自16个入端口的信元缓存进4个Memory中，经4个Memory的读端口将信元交叉发送至多路复用器(MULTIPLEXER，MUX)，由MUX输出到右边的16个出端口。可选的，可在信元进入Memory之前实现信元的交叉发送。即在Shared Memory机制下，设置了Memory用于缓存数据，当Memory中有空闲的存储空间，可通过流控通知上行线卡输入信元。信元以存储并发送的方式实现数据的交换。

由于SM交换机制在交换网中增加了缓存，在输入和输出端口之间不需要进行如XB一样的匹配过程，只要缓存有空闲，就可以通过流控通知上行线卡输入多播信元。SM接收到的空间多播信元会先Memory内完成复制，再用类似单播的机制按出口分别调度。

在本发明实施例一中，利用了Crossbar和Shared Memory两种数据交换机制的特点，单播信元采用Crossbar机制进行交换，而多播信元采用Shared Memory机制进行交换。信元从入端口输入后，将多播信元复制成多份并缓存到相关联的多个memory中，完成多播信元的入队操作，输出时按照上述调度算法输出；将单播信元根据交换请求建立入端口到出端口连接的最大匹配，通过该连接输出该信元。

由上所述，本发明实施例提供的技术方案，采用一种混合的机制实现单播和多播信元的交换，对单播信元采用交叉交换机制，无需配置大容量的存储器，对多播信元采用共享缓存交换机制，无需入端口线卡和交换网之间的复杂调度算法，且减少了线头阻塞，解决了现有技术中用单一机制进行数据的单播和多播交换时带来的问题。本发明实施例通过一种简单的实现方法，能够节省系统资源，且进行单播交换时，下行方向信元顺序重排代价较低，进行多播交换时，数据通过率较高。

本发明实施例二提供了一种交换设备，如图6所示，所述设备包括：

接收单元61，用于接收信元的交换请求；

仲裁单元62，用于根据所述接收单元61接收到的交换请求，对交换请求进行仲裁，以获取仲裁结果。该仲裁结果为仲裁对所述信元执行相应的交换，所述交换包括单播交换和多播交换。在本实施例中，也可以理解为该仲裁结果为仲裁对所述信元执行单播交换还是执行多播交换；

交换单元63，用于根据所述仲裁单元62的仲裁结果，对所述信元执行相应的交换，所述交换包括单播交换和多播交换。

当信元由所述仲裁单元62确定为执行单播交换时，交换单元63利用Crossbar机制对所述信元进行单播交换，或者，当信元由所述仲裁单元62确定为执行多播交换时，交换单元63利用Store and Forward机制对所述信元进行多播交换。

其中，所述接收单元61接收的交换请求包括单播请求和多播请求。仲裁单元62可根据已接受的多播信元和服务质量Qos策略，利用所述信元的交换请求，获取所述仲裁结果。当信元的交换请求中同时存在单、多播请求时，若仲裁单元62判断出已接受的在存储器Memory中的多播信元存储量较少，且Qos策略为多播交换优先于单播交换时，做出的仲裁结果为接受多播请求，分配多播带宽；若仲裁单元62判断出已接受的在存储器Memory中的多播信元存储量较多，且根据Qos策略当前应当处理单播交换时，如Qos策略为每服务3次单播请求，进行1次多播请求，而当前应服务单播请求时，做出的仲裁结果为接收单播请求，分配单播带宽。但不限于此，仲裁单元62可同时根据已接受的多播信元和Qos策略进行仲裁，也可单独依据已接受的多播信元或Qos策略做出仲裁，或以其中一种作为主要的依据，将另一种作为参考的依据。

进一步的，考虑到单播和多播通过交换网的方式不同，所述仲裁单元62还用于根据所述仲裁结果为该信元分配带宽。在本实施例中，为该信元分配带宽包括为信元分配相应的入口带宽和出口带宽。

对多播信元需要设置存储器以进行对接收到的信元进行存储和复制，而考虑到传输中的时延，对单播信元通常在交换前也会进行短暂的存储，以消除输入链路接收到信元时的时间偏差，在本发明实施例二中，将单播信元和多播信元统一由同一个交换单元63进行处理。

为了便于管理，交换单元63中设置的存储器可同时用于单播信元和多播信元的存储，这时所述交换单元63还用于存储执行交换时的单播信元和多播信元。可在交换单元63的存储器中开辟较小的一块存储区域用于单播信元的存储，将剩余的存储区域用于多播信元的存储。

如图7所示，这种处理方式，将单播信元与多播信元的输入和输出路径合一，在与出端口对应的Memory中留出一个独立的缓存区域，只用于存储单播信元，剩余的缓存区域用于存储多播信元。即每个Memory的缓存空间分为两部分，一部分只缓存单播信元，一部分只缓存多播信元。

单播信元在从入端口进入交换系统之前不再进行延时存储，单播信元从入端口输入后，依据其要输出到的目的端口，缓存到对应的Memory的单播缓存空间。和多播信元处理方法不同的是，单播信元不存在复制多份进行输出的过程，只需要缓存在一个Memory中，以消除时间偏差。采用这种单播信元与多播信元数据交换路径合一的方式时，可以节省交换芯片中的走线资源并便于管理。

可选的，本发明实施例二提供的另一种交换设备，如图8所示，其中交换单元可由单播交换单元和多播交换单元来实现，该设备包括：

接收单元81，用于接收信元的交换请求；

仲裁单元82，用于根据所述接收单元81接收到的交换请求，对交换请求进行仲裁，获取仲裁结果。该仲裁结果为仲裁对所述信元执行相应的交换，所述交换包括单播交换和多播交换。在本实施例中，也可以理解为该仲裁结果为仲裁对所述信元执行单播交换还是执行多播交换；

单播交换单元83，用于当信元由所述仲裁单元82确定为执行单播交换时，利用Crossbar机制对所述信元进行单播交换；

多播交换单元84，用于当信元由所述仲裁单元82确定为执行多播交换时，利用Store and Forward机制对所述信元进行多播交换。

其中，所述接收单元81接收的交换请求包括单播请求和/或多播请求。进一步的，所述仲裁单元82还用于根据仲裁结果为该信元分配带宽。在本实施例中，为该信元分配带宽包括为信元分配相应的入口带宽和出口带宽。

本发明实施例二中由单播交换单元83和多播交换单元84分别对单播信元和多播信元进行交换，如图9所示，为本发明实施例二提供的另一种交换设备结构示意图，其中的存储器只用于多播信元的存储，而单播信元时延偏差的消除在信元进入所述交换设备之前完成。

本发明设备实施例中各功能单元的具体实现方法参见本发明的装置实施例。

本发明实施例提供的技术方案，采用一种混合的机制实现单播和多播信元的交换，对单播信元采用交叉交换机制，无需配置大容量的存储器，对多播信元采用共享缓存交换机制，无需复杂的调度算法，且减小了线头阻塞，解决了现有技术中用单一机制进行数据的单播和多播交换时带来的问题。本发明实施例通过一种简单的实现方法，能够节省系统资源，且进行单播交换时，下行方向信元顺序重排代价较低，进行多播交换时，数据通过率较高。

本发明实施例还提供的一种交换系统，所述系统具有上述的交换设备，以用于单播和多播的数据交换。

本领域普通技术人员可以理解实现上述实施例中的全部或部分步骤，可以通过程序指令相关硬件完成。所述实施例对应的软件可以存储在一个计算机可存储读取的介质中。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (6)

1.一种数据交换方法，其特征在于，该方法包括：

接收信元的交换请求；

根据所述交换请求，对所述交换请求进行仲裁，获取仲裁结果；

根据所述仲裁结果，为所述信元分配相应的入口带宽和出口带宽；

当所述仲裁结果为对所述信元执行单播交换时，利用交叉Crossbar机制对所述信元进行单播交换；或者，

当所述仲裁结果为对所述信元执行多播交换时，利用存储转发Store and Forward机制对所述信元进行多播交换。

2.根据权利要求1所述的方法，其特征在于，还包括：

根据已接受的多播信元和服务质量Qos策略，对所述信元的交换请求进行仲裁，获取所述仲裁结果，其中，所述信元的交换请求包括单播请求和多播请求。

3.根据权利要求1所述的方法，其特征在于，所述为所述信元分配相应的入口带宽包括：

根据所述仲裁结果确定接受所述信元的单播请求时，为所述信元分配相应的入口带宽并屏蔽所述信元的多播请求；

或者，

根据所述仲裁结果确定接受所述信元的多播请求时，为所述信元分配相应的入口带宽并屏蔽所述信元的单播请求；

其中，所述信元的交换请求为入端口接收到的信元发送的交换请求。

4.根据权利要求3所述的方法，其特征在于，所述为所述信元分配相应的出口带宽包括：

根据已接受的多播信元的多播请求和已分配入口带宽信元的单播请求，为信元分配出口带宽。

5.一种交换设备，其特征在于，所述设备包括：

接收单元，用于接收信元的交换请求；

仲裁单元，用于根据所述接收单元接收到的交换请求，对所述交换请求进行仲裁，获取仲裁结果，根据所述仲裁结果，为所述信元分配相应的入口带宽和出口带宽；

交换单元，用于根据所述仲裁单元的仲裁结果，对所述信元执行相应的交换，所述交换包括单播交换和多播交换，其中，当信元由所述仲裁单元确定为执行单播交换时，利用Crossbar机制对所述信元进行单播交换；当信元由所述仲裁单元确定为执行多播交换时，利用Store and Forward机制对所述信元进行多播交换。

6.根据权利要求5所述的设备，其特征在于，还包括：

所述接收单元接收的交换请求包括单播请求和多播请求；

所述仲裁单元还用于根据已接受的多播信元和服务质量Qos策略，对所述接收单元接收到的信元的交换请求进行仲裁，获取所述仲裁结果。 

Images