专利名称：在以太网网络中进行流调度的方法
技术领域：
本发明涉及计算机和通信网络中的服务质量保证和调度领域，特别是介质访问子层的服务质量保证和调度，如符合IEEE 802.3的以太 网的服务质量保证和调度。具体地，本发明涉及--种在以太网网络中 进行流调度的方法，能够非常有效地支持那些低带宽低延迟的服务， 例如VoIP (基于IP的语音)业务，并且使得网桥之间的不同步性所导 致的延迟尽量降低。
背景技术：
为了保证以太网的服务质量，IEEE成立了家居以太网 (residential Ethernet)研究组。在该组的最新研究报告中，引入 了125微秒为单位的调度周期。在每个周期内部，代表多媒体应用的同 步流量比代表传统以太网应用的异步流量有更高的优先权进行发送。 为了防止同步流量过多时异步流量被饿死，每个周期的同步流量的最 大利用率限制在75%。选用125微秒周期的主要原因是参考已有的IEEE 1394标准，该标准目前被广泛用来连接音频/视频设备；另一个原因是 短的调度周期比较容易提供低延迟和低抖动。在125微秒周期的基础上，研究报告中给出了如何对同步流量进 行调度，从而达到较低的延迟和抖动的机制一一踱步(Pacing):通过保持每个同步帧直到该帧相应的发送时间，踱步机制在整个 流的路径上维护着流量的模式，从而保证了低的抖动边界和网络中缓 存空间的分布化。具体的来说，同步A类帧被控制以防它们(比预计) 较早的离开交换机，其中控制指阻塞从第n个周期来的同步A类帧，直 到第n+p个周期的开始。第n+p个周期开始，且第n+p-1个周期的非A类 帧处理完毕之后，传输器开始发送这些来自第n个周期的A类帧，这些帧对于下个网桥而言就成了从n+p个周期来的。另外，每个网桥的延迟、抖动和缓存需求由踱步中的参数p所决定。从本质上来说，踱步属于非工作守恒的调度机制。踱步机制在延迟和带宽分配粒度之间存在平衡。也就是说，如果想要较小的延迟， 则带宽分配粒度必定比较大，反之亦然。踱步机制通过调节调度周期 的长短来在延迟和带宽分配粒度之间进行平衡。调度周期越短，则延 迟越小，带宽分配粒度越大。而调度周期越长，则延迟越大，带宽分 配粒度越小。为了获得低延迟，家居以太网研究组选择了非常短的调度周期(125微秒)，这就造成了非常粗糙的带宽分配。即使应用选择 使用128字节的小型帧且不考虑帧间隙，最低的可分配带宽也达到了 8. 192兆位每秒(Mbps)。对于目前的重要应用IP电话而言，所占用的带 宽一般只有3 12千位每秒(Kbps)，带宽的浪费达到了99. 8%。为了解决该问题，家居以太网研究组在报告中采用了基于速率的 优先权调度机制，如图2所示，具体的来说，A类流量又被细分成四个 子类，分别是CLASS—A0、 CLASS—Al、 CLASS—A2和CLASS—A3。对于这四 个子类，其调度周期从原来的125微秒分别变成125微秒、500微秒、2 毫秒和8毫秒。CLASS—AO子类代表了最高速率的流量，这些流量以8KHz 的频率周期性的进行发送，而CLASS—A1、 CLASS—A2和CLASS—A3则依次 代表了更低速率的流量，如工P电话等。更多流量子类的引入给用户提供了流量优先级方面更多的选择， 然而，这种方案仍然没有解决延迟和带宽分配粒度之间的问题。也就 是说，我们仍然需要牺牲延迟来达到更高的网络利用率。对于低带宽、 低延迟需求的IP电话类业务而言，仍然意味着很大的带宽浪费。在有效地支持低带宽低延迟需求的应用(例如IP电话或者交互式 游戏)等方面，目前以太网中的方法很难有效地支持此类应用。具体 的来说，对于8毫秒才发送一次数据的低速率流而言，由于为该流保留 资源的时隙和该流产生数据的不同步性，因此最大8毫秒的等待时间是 不可避免的。然而，我们希望这种不同步性所造成的大延迟在整个端 到端传输的过程中只出现一次。也就是说，通过网桥之间进行协作调 度，使得网桥之间的不同步性所导致的延迟尽量降低。发明内容为了克服现有技术中的上述问题提出了本发明。因此，本发明的 目的是提出一种在以太网网络中进行流调度的方法，能够非常有效地支持那些低带宽低延迟的服务，例如VoIP业务，并且使得网桥之间的 不同步性所导致的延迟尽量降低。为了实现上述目的，根据本发明，提出了一种在网络中进行流调度的方法，包括发送端产生并经由多个网桥向接收端发送新流的流 描述/调度信息，所述流描述/调度信息包括该流的带宽需求B、端到端 延迟需求D、当前累计的延迟d和流产生/预留转发周期编号S;以及接 收到该流描述/调度信息的网桥，找到从上游节点接收到的流产生/预留转发周期编号S之后、能够满足所述流描述/调度信息中的带宽需求B的第一个周期，作为预留转发周期，该网桥记录该预留转发周期的编号T并更新该流描述/调度信息中的流产生/预留转发周期编号S和当前 累计的延迟d，在当前累计延迟d小于端到端延迟需求D的情况下，继续 向下游网桥传送该流描述/调度信息，直到到达接收端为止。优选地，当接收端接收到该流描述/调度信息时，该接收端检查 当前累计延迟d是否小于端到端延迟需求D，如果是，则所述流调度成功，否则，拒绝该新流。优选地，所述方法还包括在网桥处，在当前累计延迟d大于或等于端到端延迟需求D的情况下，则拒绝该新流。优选地，在发送者处，流描述/调度信息中的当前累计的延迟d等于o。优选地，当前网桥处的当前累计的延迟d等于上游节点处的延迟 加上当前网桥处所找到的预留转发周期相对于上游节点处的流产生/ 预留转发周期的差值。优选地，所述流调度是基于超帧进行的，所述超帧包括64个周期， 每个周期为125微秒。优选地，当前网桥处的当前累计的延迟d为上游节点处的延迟d加 上O. 000125*((T-S+64) MOD 64)， M0D为取模运算。优选地，发送端、各个网桥和接收端之间是超帧同步的。 优选地，所述方法应用于低速率、低延迟需求的业务。 优选地，所述网络为以太网。
通过参考以下结合附图对所采用的优选实施例的详细描述，本发 明的上述目的、优点和特征将变得显而易见，其中图l是示出了根据本发明的流调度方法的示例的示意图； 图2是示出了现有技术的基于速率优先权的调度方法的示意图； 图3是示出了本发明中所采用的超帧结构的示意图； 图4是示出了根据本发明的协同调度方案(延迟约束为8个周期)和现有技术的踱步调度方案的调度结果的延迟分布图；图5是示出了根据本发明的协同调度方案(延迟约束为32个周期)和现有技术的基于速率的优先权调度机制方案(优先级CLASS—Al)的调度结果的延迟分布图；以及图6是示出了根据本发明的协同调度方案(延迟约束为128个周期)和现有技术的基于速率的优先权调度机制方案;(优先级CLASS—A2)的调度结果的延迟分布图；具体实施方式
为了能够更好在网桥之间进行协作调度，本发明定义了基于超帧 的调度框架、以及网桥之间的协作算法。超帧从编号为64的倍数的调 度周期开始，其长度等于64个调度周期(每个调度周期为125微秒)， 即8毫秒。图3给出了超帧的结构。在踱步方案中，如果没有流的加入和离 开，每个周期的调度表应该是不变的。对于本发明而言，超帧中的每 个调度周期的调度表都可能不同。这里，调度表包括每个流的特征描 述、以及一定时期内每个流被允许通过的流量大小。基于超帧的调度 算法根据当前网桥的调度表、以及邻居网桥的调度表，来判断一个新 的流是否能够被接纳。如果是的话，对这个新的流进行调度安排，并分配资源。网桥之间的协作算法在邻居网桥之间交换流调度信息，使得调度 算法能够借助此类信息尽量降低端到端的延迟。当调度算法根据当前 网桥和邻居网桥的调度表(包含流调度信息)对新的流进行调度后， 协作算法把更新后的调度表发送给邻居网桥。协作算法主要有两个功能第一个功能是超帧起始位置的同步， 简称超帧同步；第二个功能是在网桥之间交换调度表(流调度信息)。对于第一个功能，目前的家居以太网已经引入了全网同步的概 念，在此基础上很容易进行超帧同步。目前家居以太网中，设备之间交换信息来选择一个时钟精度高的设备作为首席主设备(Grand Master),所有的其它设备直接或间接跟该设备进行时间同步。当选定 了首席主设备后，由该设备决定超帧起始位置，并向全网广播。其余 设备把首席主设备发布的超帧起始位置也作为自己的超帧起始位置， 从而达到了全网超帧起始位置的同步。对于协作算法的第二个功能，为了减少不必要的更新和交互，可 以只对变化的流调度信息进行交互。具体来说，在接纳控制阶段，上 游的网桥把新流的调度表，即在哪些周期内允许该流进行传输，以及 这些周期内允许传输多少的信息，发送给下游的网桥。这里下游和上 游以流的发送者为参照物，对于两个网桥而言，靠近发送者的称为上 游，远离发送者的称为下游。在流调度过程中会涉及接纳控制算法。在给出接纳控制算法之 前，需要先引入空余能力的概念。空余能力指网桥的某个端口上，一 定时间范围内，还能传送的A类流量。考虑到A类流量被细分为四个子 类，空余能力需要在这四个子类的不同周期长度上分别进行统计(即 125微秒，500微秒，2毫秒和8毫秒)。根据空余能力的定义，如果在某 个子类的周期长度上，空余能力小于零，则说明当前的流大于网桥的 处理能力，即网桥无法满足当前所有流的需求。反之，则网桥能够满 足当前所有流的需求。因此，控制接纳算法需要检査加入新的流后， 所有四个子类的周期上的空余能力是否大于等于零。如果是，则新的 流可以被接纳；否则，需要拒绝新的流。在前面定义的协作算法的前提下，网桥只知道端到端的延迟需求 以及从发送者到自己为止共需要多少时间，而不清楚从自己到接收者 的状况。为了使得流不超过端到端的延迟需求，对每个网桥来说，需要尽可能地减少流排队所需的延迟。另外，为了与踱步(Pacing)机制 兼容，在周期K收到的流最早只能在K+1转发。由此，本发明给出的调度算法如下发送者把新流的相关信息(流描述/调度信息，此处为流描述信 息)向接收者发送，其间需要经过多个网桥，并且此处的流描述信息包括该流的带宽需求B、端到端延迟需求D、当前累计的延迟d和流产生周期编号S;当网桥捕获到该流的信息后，寻找从预计接收到该流的周期(从上游节点接收到的流产生/预留转发周期编号s)之后、能够满足流带宽需求的首个周期作为该流的预留转发周期；网桥更新流描述/调度信息(在网桥处为流调度信息)，包括累计 延迟d和周期编号S (流产生/预留转发周期编号，在网桥处，为流预留 转发周期编号)。当前网桥处的当前累计的延迟d为上游节点处的延迟d 加上O. 000125*((T-S+64) MOD 64)， M0D为取模运算。如果更新后的累计延迟小于端到端延迟需求，则把该流调度信息 继续向接收者转发；否则，拒绝该流。当接收者收到新流的流描述/调度信息后，检查累计延迟是否小 于端到端延迟需求，如果是，则说明成功地进行了调度，否则，拒绝 该流。下面将参考附图来描述本发明的优选实施例。 图l是示出了根据本发明的流调度方法的示例的示意图。 如图1所示，假设从发送者到接收者的路径上有N个网桥，新流所占用的带宽为7，端到端延迟需求为80，发送者产生流所在的周期为l。以该例为基础的算法运行步骤如下第一步，发送者把该流的描述信息，即带宽B等于7、端到端延迟需求D等于80、流所在的周期d等于l、累积的延迟S为0，向接收者发送；如图l的发送者所在行所示。第二步，网桥l接收到发送者的信息后，检査自己从流所在的周 期的下一个周期开始(即第2个周期)，第一个剩余带宽大于7的周期。从图l网桥l所在行可以看出，周期2的剩余带宽等于5，不满足要求， 周期3的剩余带宽等于10，为第一个满足要求的周期。第三步，网桥1在周期3为新流保留资源。同时，把流所在的周期 更新为3，累积的延迟更新为2，带宽和端到端延迟需求保持不变。第四步，由于累计的延迟小于端到端延迟需求，网桥l把这些更 新后的信息继续向接收者进行发送。如图l的网桥l所在行所示。第五步，网桥2接收到网桥1转发过来的信息后，检查自己从流所 在的周期的下一个周期开始(即第4个周期)，第一个剩余带宽大于7 的周期。从图1网桥2所在行可以看出，周期4的剩余带宽等于10，满足 要求，即为第一个满足要求的周期。第六步，网桥2在周期4为新流保留资源。同时，把流所在的周期 更新为4，累积的延迟更新为3，带宽和端到端延迟需求保持不变。第七步，网桥2把这些更新后的信息继续向接收者进行发送。如 图1的网桥2所在行所示，并在各网桥处重复上述操作，直到网桥N;第八步，网桥N接收到网桥N-l转发过来的信息后，检査自己从流 所在的周期的下一个周期开始(即第l个周期)，第一个剩余带宽大于7 的周期。从图1网桥N所在行可以看出，周期1的剩余带宽等于5，不满 足要求，周期2的剩余带宽等于15，为第一个满足要求的周期。第九步，网桥N在周期15为新流保留资源。同时，把流所在的周 期更新为2，累积的延迟更新为65，带宽和端到端延迟需求保持不变。第十步，网桥N把这些更新后的信息继续向接收者进行发送。如 图1的网桥N所在行所示。第十一步，接收者接收到网桥N转发过来的信息后，检査出累计 延迟不超过端到端延迟需求，则该流成功的进行了调度。下面将说明本发明如何能够有效地支持低带宽，低延迟需求的应 用，例如VoIP业务。如现有技术部分所阐明的，目前同步以太网很难有效地支持低带 宽、低延迟需求的应用，例如IP电话和在线游戏等交互式应用。本发明给同步以太网提供了支持该类交互式应用的能力。我们以下面的简 单例子来说明该问题假设VoIP的流使用256字节的帧，两个帧之间的最小间距为16字 节，同步以太网的带宽为100Mb/lGb，周期长度为125微秒，可以保留 的带宽占总带宽的75%。100Mbps的快速以太网交换机每个周期能够保留的字节数为<formula>formula see original document page 11</formula>类似地，1Gbps的快速以太网交换机每个周期能够保留的字节数为<formula>formula see original document page 11</formula>如果资源预留策略选择每个周期都保留，则 100Mbps的快速以太网交换机能够支持的VoIP流数目为<formula>formula see original document page 11</formula>1Gbps的快速以太网交换机能够支持的VoIP流数目为<formula>formula see original document page 11</formula>在这种状态下，每个流实际占用的带宽为 1 x 109 x<formula>formula see original document page 11</formula>交换机所带来的延迟(统计平均)为125微秒实际上，VoIP所需要的带宽一般只有十几到几十Kbps，每个周期 都保留的预留策略带宽浪费超过99%。如果资源预留策略采用现有技术的基于速率的优先权调度机制， 并选用CLASS—Al子类，g口4个周期预留一次，则100Mbps的快速以太网交换机能够支持的VoIP流数目为 4" = 16个流1Gbps的快速以太网交换机能够支持的VoIP流数目为43乂4 = 172个流在这种状态下，每个流实际占用的带宽为l"0、7气4馬ps172交换机所带来的延迟(统计平均)为1^1 = 250微秒2如果资源预留策略采用基于速率的优先权调度机制，并选用 CLASS—A2子类，即16个周期预留一次，则100Mbps的快速以太网交换机能够支持的VoIP流数目为 4xl6-64个流1Gbps的快速以太网交换机能够支持的VoIP流数目为 43乂16 = 688个流在这种状态下，每个流实际占用的带宽为jxl09 x75%3L688交换机所带来的延迟(统计平均)为1^ = 1000微秒=1毫秒2如果资源预留策略采用现有技术的基于速率的优先权调度机制， 并选用CLASS—A3子类，即64个周期预留一次，则100Mbps的快速以太网交换机能够支持的VoIP流数目为 4乂64 = 256个流1Gbps的快速以太网交换机能够支持的VoIP流数目为 43x64-2,752个流在这种状态下，每个流实际占用的带宽为1X109 x气272Kbps2752交换机所带来的延迟(统计平均)为125*6、4000微秒=4毫秒2选用CLASS一A3子类时，交换机可以支持的流数目比起CLASS—Al (即每个周期都保留)子类要大大增加，同时带宽浪费也大大减少， 但CLASS一A3子类每经过一个交换机的延迟统计平均约为4毫秒，对于 VoIP业务来说是难以接受的。如果选用本发明所定义的协作式调度算法，交换机能接纳的流数，以及延迟依赖于网络拓扑、流分布、端到端延迟需求、当前的资 源预留状况，上游交换机选定的周期等一系列参数，难以像上面的调 度方法那样直接给出确定性的数值。但每个流实际占用的带宽比较容易计算出来，即(256 + 1fi6)x8 =272Kbps 125xl06x64下面我们用模拟试验来给出交换机能接纳的流数和延迟这两个 参数。试验的主千拓扑是一棵高度为4的完全4叉树，树上的每个节点都 为交换机，即共有1+4+16+64 = 85个交换机。接着，115个主机被随机 地安插在这些交换机上。具体的来说，对于每一个主机，随机从85个 交换机中选出一个，并把该端节点连接到这个随机选出的交换机上。 交换机之间的所有链路，以及交换机和端节点之间的链路均设为lGbps 全双工。这样，网络中共有200个节点，以及它们之间的4+16+64+115 =199条lGbps全双工链路。接下来，我们随机产生了20000个VoIP流，每个流的源节点和目 的节点都在上述115个主机中随机选取。VoIP的数据帧大小为256字节， 帧间距为16字节。我们把这些VoIP流逐个加到网络中进行资源预留， 并察看在其它所有配置都相同的情况下，本发明所定义的调度算法和家居以太网研究组在研究报告中提出的踱步机制和基于速率的优先权 调度机制的输出结果。图4给出了本发明所定义的调度算法和现有技术的踱步调度算法 的对比输出结果，即上述20000个VoIP流在这两种调度算法下的延迟分 布密度图。在这张图中，延迟需求被定义为为8个周期的长度，即l毫 秒；横轴为流的延迟，O代表那些由于资源不足，或者延迟超过需求而 被拒绝的流；纵轴为某个延迟的流的数目。从图中可以看出，使用踱 步调度算法时，这些VoIP流量绝大部分被拒绝(91.390，而使用本发明 所定义的调度算法时，只有少部分(23.2。/。)被拒绝,，而网络可以接纳的 流数从1731提升到15343，增加了786.4%。注意该提升是在没有损失任 何延迟的情况下得到的，这说明相比踱步调度算法，本发明所定义的 调度算法能够非常有效地支持那些对延迟需求非常严格的流。下面我们考虑现有技术的基于速率的优先权调度机制。家居以太网研究组共定义了4种优先权，即CLASS—A0、 CLASS—Al、 CLASS—A2和 CLASS—A3，分别在每l/4/16/64个周期保留一次。其中CLASS—AO和 Pacing方案一致，CLASS一A3的延迟过大(达到每跳8毫秒)，因此下面 主要针对CLASS—A1和CLASS一A2这两种优先级的进行模拟。图5给出了本发明所定义的调度算法和基于速率的优先权调度机 制中CLASS—Al的对比输出结果，即上述20000个VoIP流在这两种调度算 法下的延迟分布密度图。在这张图中，延迟需求被定义为32个周期的 长度，即4毫秒；横轴为流的延迟，O代表那些由于资源不足，或者延 迟超过需求而被拒绝的流；纵轴为某个延迟的流的数目。从图中可以 看出，使用CLASS一A1优先级的流接受的数目从CLASS—AO (即踱步机制) 的1731提高到3844，增加了122. 1%，但跟本发明所定义的调度算法能 够接受的流数目15370比起来，还是有很大的差距。类似地，图6给出了本发明所定义的调度算法和基于速率的优先 权调度机制中CLASS—A2的输出结果，其中延迟需求被定义为128个周期 的长度，即16毫秒；从图中可以看出，使用CLASS一A2优先级的流接受 的数目从CLASS—AO (即踱步机制)的1731提高到7656，增加了342.3%， 但仍然低于本发明所定义的调度算法能够接受的流数目15368。从上面的试验可以看出，在相同配置的情况下，本发明所定义的 调度算法即使在最严格延迟需求(l毫秒)的情况下，能够接纳的流数 (15343)不仅远好于Pacing能够接纳的流数(1731)，而且也明显优于基 于速率的优先权调度机制中较低优先级CLASS—A2的流数(7656)，这说 明相对于目前家居以太网研究组所给出的算法，本发明所定义的调度 算法能够非常有效地支持那些对延迟需求非常严格的流。尽管以上已经结合本发明的优选实施例示出了本发明，但是本领 域的技术人员将会理解，在不脱离本发明的精神和范围的情况下，可 以对本发明进行各种修改、替换和改变。因此，本发明不应由上述实 施例来限定，而应由所附权利要求及其等价物来限定。
权利要求
1. 一种在网络中进行流调度的方法，包括发送端产生并经由多个网桥向接收端发送新流的流描述/调度信息，所述流描述/调度信息包括该流的带宽需求B、端到端延迟需求D、当前累计的延迟d和流产生/预留转发周期编号S；以及接收到该流描述/调度信息的网桥，找到从上游节点接收到的流产生/预留转发周期编号S之后、能够满足所述流描述/调度信息中的带宽需求B的第一个周期，作为预留转发周期，该网桥记录该预留转发周期的编号T并更新该流描述/调度信息中的流产生/预留转发周期编号S和当前累计的延迟d，在当前累计延迟d小于端到端延迟需求D的情况下，继续向下游网桥传送该流描述/调度信息，直到到达接收端为止。
2、 根据权利要求l所述的方法，其特征在于当接收端接收到该流描述/调度信息时，该接收端检査当前累计延迟d是否小于端到端延迟需求D，如果是，则所述流调度成功，否则，拒绝该新流。
3、 根据权利要求l所述的方法，其特征在于还包括在网桥处，在当前累计延迟d大于或等于端到端延迟需求D的情况下，则拒绝该新流。
4、 根据权利要求l所述的方法，其特征在于在发送端处，流描述/调度信息中的当前累计的延迟d等于0。
5、 根据权利要求l所述的方法，其特征在于当前网桥处的当前累计的延迟d等于上游节点处的延迟加上当前网桥处所找到的预留转发周期相对于上游节点处的流产生/预留转发周期的差值。
6、 根据权利要求l所述的方法，其特征在于所述流调度是基于超帧进行的，所述超帧包括64个周期，每个周期为125微秒。
7、 根据权利要求6所述的方法，其特征在于当前网桥处的当前累计的延迟d为上游节点处的延迟d加上O. 000125*((T-S+64) MOD 64)， MOD为取模运算。
8、 根据权利要求6所述的方法，其特征在于发送端、各个网桥和接收端之间是超帧同步的。
9、 根据权利要求l所述的方法，其特征在于所述方法应用于低 速率、低延迟需求的业务。
10、 根据权利要求l所述的方法，其特征在于所述网络为以太网。
全文摘要
根据本发明，提出了一种在网络中进行流调度的方法，包括发送端产生并经由多个网桥向接收端发送新流的流描述/调度信息，所述流描述/调度信息包括该流的带宽需求B、端到端延迟需求D、当前累计的延迟d和流产生/预留转发周期编号S；以及接收到该流描述/调度信息的网桥，找到从上游节点接收到的流产生/预留转发周期编号S之后、能够满足所述流描述/调度信息中的带宽需求B的第一个周期，作为预留转发周期，该网桥记录该预留转发周期的编号T并更新该流描述/调度信息中的流产生/预留转发周期编号S和当前累计的延迟d，在当前累计延迟d小于端到端延迟需求D的情况下，继续向下游网桥传送该流描述/调度信息，直到到达接收端为止。
文档编号H04L12/56GK101237386SQ20071000331
公开日2008年8月6日 申请日期2007年2月2日 优先权日2007年2月2日
发明者起 吴, 黄周松 申请人:北京三星通信技术研究有限公司;三星电子株式会社