于业务量类别X，在子端口级别，在运行时，可以给每个子端口成员管 道分配可用带宽的相同份额。较低需求的管道未使用的带宽将重新平均分配给需求相对高 的管道。如此，属于较高需求管道的业务量类别X的分组将被限制，而属于较低需求管道的 业务量类别X的分组不受影响。另外，可用的带宽可以被共享，因此可以被更充分地利用。
[0168] 子端口业务量类别超额订购管理被配置为至少部分地基于子端口成员管道所体 验的当前的需求，确定水印（即阈值），并周期性地更新水印。水印可以用来限制每个管道 被允许发送的业务量类别X的业务量。例如，对于四个（即TCO、TC1、TC2、TC3)业务量类 别的配置，业务量类别X可对应于业务量类别TC3 (例如，尽力而为）。在本实施例中，对于 所有子端口成员管道，假定子端口TC3的上限（例如tc_credits)被设置为子端口速率的 100%，并且管道TC3的上限（例如tc_credits)被设置为所有子端口成员管道的管道速率 的 100 % 〇
[0169] 可以在每一业务量类别上限实施周期的开始，在子端口级别，确定水印。然后，可 以将水印传播到所有子端口成员管道，并且可以在整个当前实施周期被所有的子端口成员 管道利用。表3示出了水印传播的一个例子。
[0170]表3
[0171] ------
[0172] /^Initialization^/
[0173] /*subport level*/
[0174] subport-period-id = 0
[0175] /*pipe level*/
[0176] pipe-period id = 0
[0177] /*credit update*/
[0178] /*subport level*/
[0179] if (time >= subport tc time) {
[0180] subport-wm = water-mark-update ()；
[0181] subport tc time = time+subport_tc_pefiod ；
[0182] subport-period-id++ ;
[0183] }
[0184] /*pipe level*/
[0185] if (pipe-period-id ! = subport-period-id) {
[0186] pipe_ov_credits = subport-wm木pipe-weight ;
[0187] pipe-period ID = subport-pefiod-id ;
[0188] }
[0189] /^credit consumption^/
[0190] /*pipe level*/
[0191] pkt_credits = pk_len+flame_overhead ；
[0192] if (pipe_ov_credits >= pkt_credits) {
[0193] pipe_ov-credits- = pkt_credits ；
[0194] }
[0195] 在当前实施周期的开始（与前一实施周期的结束重合），可以至少部分地基于在 前一个周期的开始分配给TC3的，在前一周期的结束时没有被子端口成员管道所使用的带 宽量，来调整水印的值。。
[0196] 如果有未被使用的子端口TC3带宽，那么，可增大当前周期的水印值，以便鼓励子 端口成员管道消耗更多的带宽。否则，可降低水印值，，以在TC3的子端口成员管道之间实 施相等的带宽消耗。
[0197] 水印值的增加或减少可以以相对较小的增量来进行，因此，可以在多个实施周期 内到达平衡状态。这种状态可能随时会改变，因为TC3的子端口成员管道体验需求变化，例 如，由于需求的增大（当水印应该降低时）或需求减少时（当水印应该增大时）所致。
[0198] 当需求低时，水印可以设置得相对较高，以使水印不会阻碍子端口成员管道消耗 更多的带宽。可以选择水印的最高值作为为子端口成员管道所配置的最高速率。表4包括 了示出水印操作的伪代码的一个例子。
[0199]表 4
[0200] /^Initialization^/
[0201] /*subportlevel*/
[0202] WM=WM-MAX
[0203] /*credit update*/
[0204] /木subportlevel(water-mark-update)木/
[0205] tc0_cons = subport_tcO_credits_per_period_subport_tcO_credits
[0206]tcl_cons= subport_tcl_credits_per_period_subport_tcl_credits
[0207]tc2_cons= subport_tc2_credits_per_period_subport_tc2_credits
[0208]tc3_cons= subport_tc3_credits_per_period_subport_tc3_credits
[0209]tc3_cons_max=subport_tc3_credits_per_period_(tc0_cons+tcl_cons+tc2_ cons)；
[0210] if(tc3_consumption> (tc3consumption_max_MTU)){
[0211] wm- = wm > > 7 ；
[0212] if(wm<WM_MIN)碰=WM_MIN;
[0213] }else{
[0214] wm+ = (wm >> 7)+l ；
[0215]if(wm>WM_MAX)碰=WM_MAX;
[0216] }
[0217] 因此，可管理子端口业务量类别超额订购，并且未使用的带宽可以被低优先级的 业务量类别进行共享。因此，可用的带宽可被更充分地利用。
[0218] 因此，调度器模块，例如调度器253,被配置为对于网络设备实现业务量管理。调度 器可以包括大约数万的队列，所述队列被配置为存储与，例如几万或更多业务量流相关联 的分组。换句话说，多个流可以被映射到队列中，从而，业务量流的数量可以大于或等于队 列的数量。如本文所述，调度器被配置为利用调度层次结构和相关联的数据结构，以支持业 务量管理操作。
[0219] 在一个实施例中，网络设备200(例如监管器模块247)可以被配置为实现业务量 监管。业务量监管通常被配置为将业务量流限制为可以由，例如SLA指定的速率。监管可 以包括计量、标记和/或丢弃由网络设备200接收到的分组。监管可以包括单速率三色标 记（srTCM)和/或双速率三色标记器（trTCM)，它们可以符合或兼容于由互联网工程任务组 (IETF)于1999年9月公布的标题为ASingleRateThreeColorMarker(单速率三色标 记器）的RFC2697和/或标题为ATwoRateThreeColorMarker(双速率三色标记器） 的RFC2698。计量被配置来确定所接收到的分组是否是在一个或更多流速率限制之内，标记 (例如将接收到的分组标记为绿色、黄色或红色）被配置为指出计量的结果。
[0220] 监管器模块247被配置为实现可以用于计量的一个或多个令牌桶。令牌桶被配置 为对于相对小的带宽业务量流（例如大约每秒几十兆比特的线路速率）以及对于相对高的 带宽业务量流（例如大约每秒几个、数十或更高吉比特的线路速率），提供相对高的精确度 (例如大约1%)。如本文所述，在一些实施例中，精度是可配置的。令牌桶可以使用轮询 模式，而不是中断模式来实现，并且被配置为利用时间戳寄存器，例如时间戳寄存器223,而 不是高精度计时器。可以在没有对于令牌桶更新的硬性的截止时间的情况下，实现令牌桶 (例如不使用可能会影响性能的周期性的计时器回调）。
[0221] -般来说，srTCM技术为每个业务量流定义了两个令牌桶（标记为承诺和多余）， 两个桶共享相同的令牌更新速率。可以以承诺信息速率（CIR)参数所定义的速率（以每秒 IP(互联网协议）分组字节为单位）给"承诺"桶供应令牌。"承诺"桶的大小由承诺突发大 小（CBS)参数定义（以字节为单位）。可以以与承诺桶相同的速率给"多余"桶供应令牌。 "多余"桶的大小由多余突发大小（EBS)参数定义（单位为字节）。
[0222] 一般来说，trTCM技术为每个流量流定义了两个令牌桶，两个桶（标记为承诺和峰 值）以独立速率利用令牌来更新。类似于srTCM技术，可以以由CIR参数所定义的速率给 承诺桶供应令牌，承诺桶大小由CBS参数来定义（以字节为单位）。可以以由峰值信息速率 (PIR)参数所定义的速率给峰值桶供应令牌。P桶的大小由峰值突发大小（PBS)参数定义 (以字节为单位）。
[0223] 对于srTCM和trTCM两者，当输入颜色设置为绿色时，彩色盲模式在功能上等效于 彩色感知模式。对于色彩感知模式，具有红色的输入颜色标记的分组只用红色的输出颜色 来标记，而标记为黄色的输入颜色的分组可以用黄色或红色的输出颜色来标记。在适当情 况下，可以实现截然不同于色彩感知模式的色彩盲模式，因为色盲模式相比彩色感知模式 计算量不是那么大。
[0224] 对于每一个输入分组，srTCM和/或trTCM技术的操作包括更新承诺和过量（对 于srTCM)或峰值（对于trTCM)令牌桶。例如，可以从处理器时间戳寄存器读取当前时间， 可以识别自上次桶更新的时间量，可以计算相关联的令牌数（根据预先配置的桶速率）。桶 中的令牌数被预先配置的桶大小所限制。可以基于IP分组的大小和在承诺与过量（srTCM) 或峰值（trTCM)的桶中当前可用的令牌数量来确定当前分组的输出颜色。对于颜色感知模 式，也可以考虑分组的输入颜色（如果有的话）。当输出颜色不是红色的时，则从承诺和/ 或过量（srTCM)或承诺和/或峰值（trTCM)中减去等于IP分组的长度的令牌的数量，这取 决于技术和分组的输出颜色。
[0225] 与本发明一致的被用于监控的令牌桶被配置为使用多个输入参数。输入参数包括 HZ，每秒处理器周期的数目（即处理器频率）、对应于当前时间的时间和对应于流量流速率 (每秒字节数）的tb_rate。可以通过读取处理器时间戳计数器（例如时间戳寄存器223) 来获取时间，因此以处理器周期来计量。
[0226] 令牌桶可利用每个业务量流的永久性数据结构。例如，数据结构可以包括，tb_ time、tb_tokens、tb_size、tb_period和tb_tokens_per_period〇tb_time对应于令牌桶 的最新更新的时间。tb_tokens对应于令牌桶中的当前的可用令牌的数量。通常，一个令牌 对应于一个字节的分组数据。tb_size是令牌桶的上限。tb_period对应于计量令牌桶更 新周期，即对于每一次桶更新可以消失的处理器周期的数量。tb_tokens_per_period对应 于在每次更新时要添加到令牌桶的令牌的数量。tb_period和tb_tokens_per_period可用 来对于相对较小带宽业务量和对于相对高带宽业务量两者，实现相对高的精度（例如大约 1% )〇
[0227] 图13示出了与本发明的一个实施例相一致的被配置为初始化令牌桶的示例性操 作的流程图1300。例如，操作可以由监管器模块247来执行。流程图1300的操作开始于初 始化1302。操作1304包括设置最小计量令牌桶更新周期TB_PERIOD_MIN(即对于每一次令 牌桶更新，可以消失的处理器周期的最小数）。TB_PERIOD_MIN的值是可配置的，与令牌桶 操作的容差（即期望的精确度）相关。例如，TB_PERIODA_MIN可被设置为100,对应于1% 的容差。操作1306包括确定计量令牌桶更新周期tb_period(对于每一次令牌桶更新，可 以消失的处理器周期的数量）。tb_peri〇d可以被确定为每秒处理器周期的数目除以业务 量流速率（每秒字节数）。因此，tb_peri〇d相当于业务量流的每个字节的处理器周期。
[0228] 在操作1308可以确定计量令牌桶更新周期是否大于或等于最小计量令牌桶更新 周期。如果计量令牌桶更新周期大于或等于最小计量令牌桶更新周期，则在操作1310,可将 每次更新要添加到令牌桶的令牌数设定为1。程序流程在操作1316结束。如果计量令牌桶 更新周期不大于或等于最小计量令牌桶更新周期，那么可以在操作1312确定在每次更新 时要添加到令牌桶的令牌数。可接着在操作1314确定计量令牌桶更新周期。程序流程在 操作1316结束。
[0229] 表5包括示出了与本发明的一个实施例相一致的初始化令牌桶的伪代码的一个 例子。表5的示例性伪代码是流程图1300的操作的一个例子。
[0230]表5
[0231] /*Token bucket initialization*/
[0232] TB PERIOD MIN = 100 ；/*Configurable, set to lOOfor1%tolerance*/
[0233] tb_period = HZ/tb_rote ；/*Floating point division*/
[0234] if (tb_period >= TB_PERIOD_MIN)
[0235]tb_tokens_per_period=1 ；
[0236]else{
[0237]tb_tokens_per_period=ceil(TB_PERIOD_MIN/tb_period)；/*Rounduptothe nextintegeroffloatingpointdivisionresult*/
[0238]tb_period= (HZ*tb_tokens_per_period)/tb_rate；}
[0239] 在第一个例子中，对于带有具有2. 5GHz(千兆赫）的处理器频率（HZ)的处理器 以及配置了 11Mbps(每秒兆比特）的线路速率的网络接口的网络设备，业务量流速率（tb_ rate)为1. 375兆字节每秒。Tb_period可确定为2. 5GHz/l. 375兆字节每秒=1818. 18周 期 / 字节。对于 100 的TB_PERIOD_MIN，tb_period大于TB_PERIOD_MIN，从而tb_tokens_ per_period可以被设置为1。
[0240] 在第二示例中，使用相同的处理器和相同TB_PERIOD_MIN= 100,但具有7Gbps的 线路速率，tb_rate是每秒0. 875千兆字节，tb_period为每字节2. 86个周期。因为tb_ period不大于或等于TB_PERIOD_MIN，tb_tokens_per_period被确定ceil(100/2. 86)= ceil(34.96) = 35。然后，新的tb_period可确定为（HZ*tb_tokens_per_period)/tb_rate =(2. 5千兆赫*35)/0. 875千兆字节/秒=100。因此，对于每100个处理器周期，35个令 牌可以被添加到令牌桶。
[0241] 第一示例对应于相对低带宽线路速率，而第二示例对应于相对高带宽线路速率。 令牌是不连续的，即每个令牌都对应于一个字节，在整数个处理器周期（即tb_peri〇d)，令 牌可被添加到令牌桶。如果处理器的频率不是业务量流速率的整数倍，则处理器频率除以 流量流速率的结果可以被截断。在第一个例子中，将1818. 18截断为1818,对精度导致低于 百分之一的影响。在第二示例中，例如，将2. 86截断为2,导致约30 %的错误。
[0242] 流程图1300的操作和表5中的伪代码被配置为减少相对高带宽流的错误，而不会 影响相对低带宽流。令牌被添加到令牌桶的总速率（以及由令牌桶实现的相关联的计量） 不会被流程图1300的操作改变。相反，可以以对应于多个处理器周期的间隔添加多个令 牌。例如，在第二个例子中，100个处理器周期除以35个令牌（即字节）对应于每2. 86个 处理器周期1个令牌。对于100个处理器周期的间隔，正负1个处理器周期的变化对应正 负1%。因此，对于相对高的速率的业务量流，可以实现计量，并可以保持计量精度。
[0243] 图14示出了与本发明的一个实施例相一致的被配置为更新令牌桶的示例性操作 的流程图1400。例如，操作可以由监管器模块247响应于新的分组到达网络设备200来执 行。流程图1400的操作开始于更新1402。在操作1404确定最近的桶更新以来的桶更新间 隔的数量（即计量令牌桶更新周期数）。在操作1406中可以确定（即更新）最近桶更新的 时间。在操作1408中可以更新可用的令牌的数量。例如，可以至少部分地基于自从最近桶 更新之后桶更新间隔的数量以及在每一次更新时要添加到令牌桶的令牌的数量，来更新可 用令牌的数量。在操作1410中可以确定可用的令牌的数量是否超过令牌桶的上限。如果 可用的令牌的数量超过了令牌桶的上限，则在操作1412可以将桶中的可用令牌数量设置 为上限。更新可以在操作1414结束。
[0244] 表6包含了示出与本发明的一个实施例相一致的更新（即补充）令牌桶的伪代码 的一个例子。表6的示例性伪代码是流程图1400的操作的一个例子。
[0245]表6
[0246] /氺Token bucket update(replenish)run-time operation. Executed on new packet arrival*/
[0247] n_periods = (time_tb_time)/tb_period ;
[0248] tb_time+ = n_periods氺tb_period ;
[0249] tb_tokens+ = n_periods氺tb_tokens_per_period ;
[0250] if(tb_tokens > tbsize)
[0251] tb_tokens = tb_size ；
[0252] 图15示出了