Dual use rate policer and re-marking logic

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application claims priority of U.S. Provisional Patent Application No. 60/264,156 filed Jan. 25, 2001 entitled DUAL USE RATE POLICER AND RE-MARKING LOGIC.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

N/A

BACKGROUND OF THE INVENTION

0003The present invention relates generally to communications systems, and more specifically to a dual use rate policing and re-marking apparatus for packet switched communications networks.

0004A conventional communications system includes a plurality of nodes interconnected by a plurality of data transmission paths to form at least one communications network. The plurality of nodes includes at least one node configurable as an ingress node for originating a data path and at least one node configurable as an egress node for terminating a data path through the network. Each node on the network typically comprises a computerized device such as a switch that can be used to interconnect two or more of the plurality of data paths. Each switch includes at least one input port and at least one output port coupled to respective data paths and is typically configured to allow each output port to receive digital data in the form of, e.g., data packets from any input port. The switch determines the appropriate output port for a particular packet by accessing information contained in a header field of the packet.

0005In the conventional communications system, a Class of Services (CoS) contract is typically formed between an operator of the communications network and a user of the network specifying the user's parameters for transmitting data on the network. For example, the CoS contract may specify that the user has a 500 kilobyte/second (KB/s) bandwidth for transmitting packets on the network. Further, each switch that constitutes an ingress node on the communications network may be configured to police data traffic on the network to assure that the network's users are in compliance with the terms of their respective CoS contracts. For example, each switch constituting an ingress node may include at least one queue configured to buffer a user's packet flow for a particular class of service. The switch typically determines the required class of service for each packet in the flow by accessing information in the packet header field. The switch may also include at least one token bucket associated with the queue for metering the buffered packet flow to determine whether the packets conform to the bandwidth requirements of the CoS contract. In the event it is determined that the user's packets conform to the terms of the CoS contract, the switch typically allows the packets to pass on the network via the appropriate output port(s). In the event at least one of the user's packets fails to comply with the CoS contract terms, the switch may mark the packet as non-conforming or simply drop the non-conforming packet from the network.

0006One drawback of conventional communications systems is that the network switches included therein cannot easily enforce CoS contracts that include terms for multiple classes of service. For example, a CoS contract may specify that a user of the communications network has a 500 KB/s bandwidth for a first packet flow, a 250 KB/s bandwidth for a second packet flow, a 200 KB/s bandwidth for a third packet flow, a 100 KB/s bandwidth for a fourth packet flow, and a total bandwidth of 1 megabyte/second (MB/s) for an aggregated packet flow comprising a mix of the multiple classes of service. Policing such a CoS contract can be problematic not only because the network switches are required to police the primary packet flows but also because the switches must police one or more aggregated flows. Further, a switch's ultimate disposition of a packet, e.g., whether the switch passes the packet, marks the packet as non-conforming, or drops the packet from the network, can depend not only on the specified data transmission rate for the corresponding primary packet flow but also on the amount of bandwidth currently available in the aggregated flow. This can further complicate the policing and enforcement of CoS contracts.

0007It would therefore be desirable to have an apparatus and method for policing CoS contracts of users of a communications network. Such an apparatus would be capable of policing CoS contracts that include terms for one or more classes of service. It would also be desirable to have an apparatus for policing CoS contracts that can appropriately re-mark packets with new CoS parameters to reduce data loss and assure that as much data traffic as possible is allowed to pass on the network.

BRIEF SUMMARY OF THE INVENTION

0008In accordance with the present invention, an apparatus and method for performing rate policing and re-marking in a packet switched communications network is disclosed that can be used to enforce and/or monitor Class of Services (CoS) contracts including terms for single or multiple classes of service. Benefits of the presently disclosed rate policing and re-marking apparatus are achieved by providing dual use rate policing and re-marking logic that combines flow record and token bucket processing to allow rate policing and re-marking of both primary and aggregated packet flows.

0009In one embodiment, a network switch and the dual use rate policing and re-marking logic are provided within a switching system configured as an ingress node on the communications network. The switch receives at least one data packet transmitted on the network, extracts information from at least one header field of the packet including at least one Ingress CoS (ICoS) parameter, an identifier of a primary flow (the “primary flow ID”) established for the packet, and a packet byte count, and provides the extracted header information to the rate policing/re-marking logic. Next, the rate policing/re-marking logic performs flow record and token bucket processing on the primary packet flow to determine whether the packets of the primary flow conform to the bandwidth requirements specified in the respective ICoS contract. In the event the primary flow is a sub-flow of at least one aggregated packet flow, the rate policing/re-marking logic also performs flow record and token bucket processing on the aggregated flow to determine whether the packets of the aggregated flow comply with the terms of the ICoS contract. Based on the token bucket processing results, the rate policing/re-marking logic provides an indication of an appropriate action to the switch. Such actions may include passing the packet unmodified on the network, passing the packet re-marked with a new egress CoS (ECoS), or dropping the packet from the network. The switch then performs the indicated action on the packet.

0010The dual use rate policing and re-marking logic comprises an input configurable to receive the packet header information from the switch, an output configurable to pass the packet disposition information to the switch, a flow record processor configured to perform flow record and token bucket processing on the primary flow and any aggregated flow established for the packet, a flow record memory configured to store a respective flow record for each established primary and aggregated flow, a token bucket addend memory configured to store respective token bucket addend and maximum values, and a statistics memory configured to store token bucket processing statistics for system-level use.

0011The flow record processor includes a flow record processor control unit, a token bucket processor, a token bucket update control unit, an aggregated flow identifier (the “aggregated flow ID”) look-up table, and an action table. The flow record processor control unit is configured to control the operation of the rate policing/re-marking logic by receiving the packet header information from the switch via the logic input, coordinating the activities of the token bucket processor and the token bucket update control unit based on the received packet header information, and passing the resulting packet disposition information to the switch via the logic output. Each flow record stored in the flow record memory includes a pointer to a location in the action table and a token bucket value for a particular packet flow. Further, each token bucket addend and maximum value pair stored in the token bucket addend memory corresponds to respective addend and maximum values for a particular token bucket value.

0012The token bucket processor is configured to execute mathematical operations required for the token buckets of the primary and aggregated packet flows. The token bucket processor may subtract the packet byte count from the corresponding token bucket value, periodically add the addend value to the token bucket value, and compare the resulting token bucket value to the corresponding maximum value to ascertain whether the maximum value of the token bucket has been exceeded. In the event the sign of the token bucket value is negative after subtracting the packet byte count, it may be concluded that the packet does not conform to the bandwidth requirements specified in the respective ICoS contract. In the event the token bucket value remains non-negative after the subtraction operation, it may be concluded that the packet complies with the terms of the ICoS contract and the new token bucket value for the packet flow may then be stored in the appropriate location of the flow record memory. Next, the token bucket processing results are provided to the flow record processor control unit, which passes corresponding packet disposition information to the switch for subsequent disposition of the packet.

0013The token bucket update control unit is configured to update the token bucket values stored in the flow record memory using the corresponding token bucket addend and maximum values stored in the token bucket addend memory. The token bucket update control unit includes a programmable interval counter that determines a time interval between successive token bucket updates, and a flow ID counter that provides output values corresponding to the primary and aggregated packet flow IDs. Each time the interval counter expires, the token bucket update control unit sends read requests to the flow record memory and the token bucket addend memory. The output value provided by the flow ID counter serves as the read address for the flow record memory and the token bucket addend memory. The flow record and token bucket addend memories then provide the corresponding token bucket and addend/maximum values, respectively, to the token bucket update control unit, which in turn provides these values to the token bucket processor. Next, the token bucket processor adds the addend value to the token bucket value and compares the resulting token bucket value to the corresponding maximum value. In the event the resulting token bucket value is less than or equal to the maximum value, the token bucket processor stores the new token bucket value for the packet flow in the appropriate location of the flow record memory. In the event the resulting token bucket value is greater than the maximum value, the token bucket processor stores the maximum value as the new token bucket value.

0014The aggregated flow ID look-up table is configured to store at least one aggregated flow ID for each primary flow. The primary flow ID serves as a pointer to a location in the aggregated flow ID look-up table where the corresponding aggregated flow ID is stored. Further, the aggregated flow ID serves as the read address in the flow record memory where the action table pointer and the token bucket value for the corresponding aggregated flow are stored. In the event the aggregated flow ID look-up table stores a valid aggregated flow ID for the primary flow, the token bucket processor performs token bucket processing for the aggregated flow and provides the token bucket processing results to the flow record processor control unit, which passes corresponding packet disposition information to the switch for subsequent disposition of the packet.

0015The action table is configured to store representations of a plurality of addressable actions for each primary and aggregated flow that define the ultimate disposition of each packet not conforming to the requirements of the respective ICoS contract. The plurality of addressable actions includes re-marking the packet with a new ECoS parameter and dropping the packet from the network. Based at least on the ICoS parameters for the non-conforming packet, the flow record processor control unit accesses a representation of an appropriate action from the action table and provides corresponding packet disposition information to the switch, which subsequently performs the indicated action on the packet.

0016In the disclosed embodiment, single or multiple levels of operations may be performed by the rate policing/re-marking device on each data packet. The rate policing/re-marking logic may be configured to perform single-level operations such as single-level policing, single-level re-marking, and single-level accounting, and/or multi-level operations such as two-level policing, two-level re-marking, two-level policing/re-marking, and two level accounting.

0017The rate policing/re-marking logic may be configured to perform single-level policing, re-marking, and/or accounting operations to enforce and/or monitor compliance with ICoS contracts that include terms for single classes of service. Such ICoS contracts are generally associated with primary packet flows. Further, the rate policing/re-marking logic may be configured to perform multi-level policing, re-marking, and/or accounting operations to enforce and/or monitor compliance with ICoS contracts that include terms for multiple classes of service. Such ICoS contracts are generally associated with primary packet flows that are sub-flows of one or more aggregated packet flows, in which each of the primary and aggregated flows must comply with the parameters of a particular class of service.

0018By providing the dual use rate policing and re-marking logic configured to combine flow record and token bucket processing for both primary and aggregated packet flows, network switches can more easily enforce CoS contracts that include terms for single or multiple classes of service.

0019Other features, functions, and aspects of the invention will be evident from the Detailed Description of the Invention that follows.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

0020The invention will be more fully understood with reference to the following Detailed Description of the Invention in conjunction with the drawings of which:

0021<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram depicting a communications system including at least one ingress node according to the present invention;

0022<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram depicting an illustrative embodiment of a switching system constituting the ingress node of <figref idref="DRAWINGS">FIG. 1</figref>;

0023<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram depicting an illustrative embodiment of dual use rate policing and re-marking logic included in the switching system of <figref idref="DRAWINGS">FIG. 2</figref>;

0024<figref idref="DRAWINGS">FIG. 4</figref> depicts an illustrative format for packet header information;

0025<figref idref="DRAWINGS">FIG. 5</figref> depicts an illustrative format for packet disposition information;

0026<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram representing exemplary process blocks for the dual use rate policing and re-marking logic of <figref idref="DRAWINGS">FIG. 3</figref>;

0027<figref idref="DRAWINGS">FIG. 7</figref> depicts an illustrative format for a flow record;

0028<figref idref="DRAWINGS">FIG. 8</figref> depicts an illustrative format for a token bucket addend/maximum value;

0029<figref idref="DRAWINGS">FIG. 9</figref> depicts an illustrative format for a statistics memory address/data;

0030<figref idref="DRAWINGS">FIG. 10</figref> depicts an illustrative format for an aggregated flow identifier;

0031<figref idref="DRAWINGS">FIG. 11</figref> depicts an illustrative format for an action table;

0032<figref idref="DRAWINGS">FIG. 12</figref> depicts an illustrative format for an action field included in the action table of <figref idref="DRAWINGS">FIG. 11</figref>; and

0033<figref idref="DRAWINGS">FIGS. 13</figref><i>a</i>–<b>13</b><i>b </i>depict a pseudo code representation of a method of performing rate policing and re-marking in a communications network using the dual use rate policing and re-marking logic of <figref idref="DRAWINGS">FIG. 3</figref>.

DETAILED DESCRIPTION OF THE INVENTION

0034U.S. Provisional Patent Application No. 60/264,156 filed Jan. 25, 2001 is incorporated herein by reference.

0035A method of performing rate policing and re-marking in a packet switched communications network is provided that can be used to police packet flows on the network for contract enforcement and billing purposes. Such policing of packet flows is achieved by providing dual use rate policing and re-marking logic that combines flow record and token bucket processing to allow rate policing and re-marking of data packets transmitted on the network in both primary and aggregated packet flows.

0036<figref idref="DRAWINGS">FIG. 1</figref> depicts an illustrative embodiment of a communications system <b>100</b> comprising a communications network <b>102</b> that includes at least one ingress node configured to perform rate policing and re-marking of packets transmitted on the network <b>102</b>, in accordance with the present invention. For example, the network <b>102</b> may comprise at least one packet switched communications network. In the illustrated embodiment, the network <b>102</b> includes a plurality of nodes <b>110</b>–<b>117</b> interconnected by a plurality of data transmission paths <b>120</b>. The plurality of nodes <b>110</b>–<b>117</b> includes at least one ingress node configured to originate a data path and at least one egress node configured to terminate a data path through the network <b>102</b>. For example, the network <b>102</b> may be configured to establish a packet flow for one or more packets transmitted from a source device <b>104</b> coupled to the network <b>102</b> at the node <b>110</b> to a destination device <b>105</b> coupled to the network <b>102</b> at the node <b>111</b>. Accordingly, the node <b>110</b> may be configured as an ingress node and the node <b>111</b> may be configured as an egress node for transmitting packets from the source device <b>104</b> to the destination device <b>105</b> via at least one data path traversing one or more of the intermediate nodes <b>115</b>–<b>117</b>.

0037It is understood that packets may be similarly transmitted on the network <b>102</b> between any two or more of a plurality of devices <b>104</b>–<b>108</b> via an ingress node and at least one egress node on the network <b>102</b>. Accordingly, each of the nodes <b>110</b>–<b>114</b> is configurable as an ingress node or an egress node for transmitting packets between two or more of the devices <b>104</b>–<b>108</b> via at least one data path traversing one or more of the intermediate nodes <b>115</b>–<b>117</b>.

0038For example, each of the nodes <b>110</b>–<b>117</b> on the network <b>102</b> may comprise a network device such as a router or network switch. Further, each of the devices <b>104</b>–<b>108</b> may comprise a computer system such as a client, a server, or a gateway to another network. Moreover, the network <b>102</b> may comprise a Local Area Network (LAN), a Wide Area Network (WAN), a global computer network such as the Internet, or any other network configured to communicably couple the devices <b>104</b>–<b>108</b> to one another.

0039Those of ordinary skill in the art will appreciate that a Class of Services (CoS) contract may be formed between an operator of a communications network and a user of the network specifying the user's parameters for transmitting data on the network. For example, the user of the network <b>102</b> may be the user of the device <b>104</b> coupled to the network <b>102</b> at the node <b>110</b>. Further, the CoS contract may indicate that the user of the device <b>104</b> has a 500 kilobyte/second (KB/s) bandwidth for a first packet flow, a 250 KB/s bandwidth for a second packet flow, a 200 KB/s bandwidth for a third packet flow, a 100 KB/s bandwidth for a fourth packet flow, and a total bandwidth of 1 megabyte/second (MB/s) for an aggregated packet flow comprising a mix of the multiple classes of service. Accordingly, the user of the device <b>104</b> may transmit packets at or below the data transmission rates indicated in the CoS contract or in bursts so long as the bandwidth requirements of the CoS contract are not exceeded over time.

0040<figref idref="DRAWINGS">FIG. 2</figref> depicts an illustrative embodiment of an ingress node such as the node <b>110</b> on the communications network <b>102</b> (see <figref idref="DRAWINGS">FIG. 1</figref>). Because the nodes <b>111</b>–<b>114</b> are configurable as ingress nodes to receive packets from corresponding devices <b>104</b>–<b>108</b> communicably coupled thereto for subsequent transmission on the network <b>102</b>, each of the nodes <b>111</b>–<b>114</b> may be configured like the node <b>110</b> of <figref idref="DRAWINGS">FIG. 2</figref>.

0041As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the ingress node <b>110</b> comprises a switching system including a switch <b>220</b> and dual use rate policing and re-marking logic <b>200</b>. The switch <b>220</b> includes one or more input ports <b>1</b>-P communicably coupled to the device <b>104</b> and one or more output ports <b>1</b>-Q coupled to at least one data path <b>120</b> in the network <b>102</b> (see <figref idref="DRAWINGS">FIG. 1</figref>). In the illustrated embodiment, the switch <b>220</b> is configured to allow each of the output ports <b>1</b>-Q to receive digital data in the form of packets from any one of the input ports <b>1</b>-P. For example, the switch <b>220</b> may determine the appropriate output port(s) <b>1</b>-Q for a particular packet by extracting information contained in a header field of the packet. The switch <b>220</b> may also include at least one queue (not shown) configured to buffer a user's packet flow for a particular class of service. For example, the switch <b>220</b> may include a high-priority queue configured to buffer packet flows for a constant bit-rate service class and a low-priority queue configured to buffer packet flows for a “best-effort” service class.

0042The switching system <b>110</b> polices data traffic received from the source device <b>104</b> via the input ports <b>1</b>-P to ascertain whether the user of the device <b>104</b> is in compliance with the terms of the respective CoS contract. Specifically, the rate policing and re-marking logic <b>200</b> is configured to receive information extracted from the header field of a packet received at one of the input ports <b>1</b>-P via a port interface <b>221</b>, determine whether the packet conforms to the bandwidth requirements specified in the CoS contract using the packet header information, and provide packet disposition information to the switch <b>220</b> via the port interface <b>221</b> indicating an appropriate action to take on the packet. Based on the packet disposition information provided by the rate policing/re-marking logic <b>200</b>, the switch <b>220</b> may pass the packet unmodified on the network <b>102</b> (see <figref idref="DRAWINGS">FIG. 1</figref>), pass the packet re-marked with at least one new CoS parameter, or drop the packet from the network <b>102</b>.

0043<figref idref="DRAWINGS">FIG. 3</figref> depicts an illustrative embodiment of the dual use rate policing/re-marking logic <b>200</b> included in the switching system <b>110</b> (see <figref idref="DRAWINGS">FIG. 2</figref>). In the illustrated embodiment, the rate policing/re-marking logic <b>200</b> includes a packet header information input <b>324</b> configured to receive the packet header information from the switch <b>220</b> and a packet disposition information output <b>326</b> configured to pass the packet disposition information to the switch <b>220</b>. The rate policing/re-marking logic <b>200</b> further includes a flow record processor <b>300</b> configured to receive the packet header information from the input <b>324</b>, perform a combination of flow record and token bucket processing using the packet header information, and provide the packet disposition information to the output <b>326</b> based on the token bucket processing results.

0044Specifically, when the switch <b>220</b> receives a packet at one of the input ports <b>1</b>-P (see <figref idref="DRAWINGS">FIG. 2</figref>), the switch <b>220</b> extracts information from at least one header field of the incoming packet including at least one Ingress CoS (ICoS) parameter for the packet, an identifier of the primary flow (the “primary flow ID”) established for the packet, and an indication of the length of the packet (e.g., the packet byte count), and provides this packet header information to the input <b>324</b> (see <figref idref="DRAWINGS">FIG. 3</figref>).

0045<figref idref="DRAWINGS">FIG. 4</figref> depicts an illustrative format <b>400</b> for the packet header information provided by the switch <b>220</b> to the input <b>324</b> (see <figref idref="DRAWINGS">FIG. 3</figref>). In the illustrated format, the packet header information comprises two (2) consecutive words <b>402</b> and <b>404</b>. The first word <b>402</b> includes a field containing the primary flow ID and a field containing the ICoS parameters. The ICoS field includes a Discard Eligibility (DE) field and a Priority (PRI) bit, the functions of which are described below. The second word <b>404</b> includes the packet byte count.

0046A flow ID is a number assigned to a packet flow and is generally used to associate one or more packets in the flow with data traffic belonging to a particular network user. It should be understood that a packet flow may have one or more flow IDs assigned thereto. For example, a primary packet flow may be part of an aggregated packet flow and may therefore have both a primary flow ID and an aggregated flow ID assigned thereto. Further, a primary flow ID assigned to a first flow may serve as an aggregated flow ID for one or more second flows. Moreover, although each primary packet flow typically has a unique primary flow ID, a plurality of primary flows may share the same aggregated flow ID.

0047In the presently disclosed embodiment, the packet header information input <b>324</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) includes a First-In First-Out (FIFO) buffer (not shown) configured to buffer the extracted packet header information provided by the switch <b>220</b>. The input <b>324</b> passes the buffered packet header information to the flow record processor <b>300</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) for subsequent flow record and token bucket processing.

0048The flow record processor <b>300</b> includes a flow record processor control unit <b>302</b>, a token bucket processor <b>304</b>, a token bucket update control unit <b>306</b>, an aggregated flow identifier (the “aggregated flow ID”) look-up table <b>308</b>, and an action table <b>310</b>. The flow record processor <b>300</b> is configured to receive the packet header information from the input <b>324</b>, perform flow record and token bucket processing using the received packet header information, and pass the resulting packet disposition information to the switch <b>220</b> (see <figref idref="DRAWINGS">FIG. 2</figref>) via the output <b>326</b>.

0049<figref idref="DRAWINGS">FIG. 5</figref> depicts an illustrative format <b>500</b> for the packet disposition information provided to the switch <b>220</b> by the flow record processor <b>300</b> (see <figref idref="DRAWINGS">FIG. 3</figref>). In the illustrated format, the packet disposition information includes an Egress CoS (ECoS) field and a Drop bit. Like the ICoS field, the ECoS field includes a DE field and a PRI bit. In the event the flow record processor <b>300</b> determines that a packet is conforming and should be passed unmodified on the network, the flow record processor <b>300</b> fills the ECoS field with data from the ICoS field (see <figref idref="DRAWINGS">FIG. 4</figref>) and de-asserts the Drop bit. In the event the flow record processor <b>300</b> determines that the packet is non-conforming and should be dropped from the network, the flow record processor <b>300</b> asserts the Drop bit. Because the flow record processor <b>300</b> performs token bucket processing on packets in the order in which they arrive, there is no need to include the corresponding flow ID in the packet disposition information.

0050<figref idref="DRAWINGS">FIG. 6</figref> depicts exemplary process blocks that may be performed by the flow record processor <b>300</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) to police data traffic. For example, the data traffic may comprise at least one packet in one or more primary packet flows. Accordingly, as shown in <figref idref="DRAWINGS">FIG. 6</figref>, packet header information corresponding to primary packet flows <b>1</b>.<b>1</b>–<b>1</b>.I may be provided to rate policing/re-marking process blocks <b>602</b>.<b>1</b>–<b>602</b>.I, which then perform a single level of rate policing/re-marking operations on the primary packet flows <b>1</b>.<b>1</b>–<b>1</b>.I to generate packet disposition information. Next, the rate policing/re-marking process blocks <b>602</b>.<b>1</b>–<b>602</b>.I provide the packet disposition information to the switch <b>220</b> (see <figref idref="DRAWINGS">FIG. 2</figref>) for subsequent disposition of the packets.

0051The data traffic may further comprise a plurality of primary packet flows that are sub-flows of an aggregation of secondary packet flows. Accordingly, as shown in <figref idref="DRAWINGS">FIG. 6</figref>, packet header information corresponding to primary packet flows <b>2</b>.<b>1</b>–<b>2</b>.J may be provided to rate policing/re-marking process blocks <b>604</b>.<b>1</b>–<b>604</b>.J, which then perform a first level of rate policing/re-marking operations on the primary flows <b>2</b>.<b>1</b>–<b>2</b>.J to generate packet disposition information for the flows <b>2</b>.<b>1</b>–<b>2</b>.J. Next, the rate policing/re-marking process blocks <b>604</b>.<b>1</b>–<b>604</b>.J provide packet header information corresponding to secondary packet flows <b>3</b>.<b>1</b>–<b>3</b>.J to a rate policing/re-marking process block <b>608</b>, which performs a second level of rate policing/re-marking operations on the aggregated flows <b>3</b>.<b>1</b>–<b>3</b>.J to generate packet disposition information for the flows <b>3</b>.<b>1</b>–<b>3</b>.J. The rate policing/re-marking process block <b>608</b> then provides the packet disposition information for the aggregated flows <b>3</b>.<b>1</b>–<b>3</b>.J to the switch <b>220</b> for subsequent disposition of the packets.

0052Moreover, the data traffic may comprise a plurality of primary packet flows that are sub-flows of a first aggregation of secondary packet flows, and one or more primary packet flows that are sub-flows of a second aggregation of packet flows including the first aggregation of flows. Accordingly, packet header information corresponding to primary packet flows <b>4</b>.<b>1</b>–<b>4</b>.K may be provided to rate policing/re-marking process blocks <b>606</b>.<b>1</b>–<b>606</b>.K, which then perform a first level of rate policing/re-marking operations on the primary flows <b>4</b>.<b>1</b>–<b>4</b>.K to generate packet disposition information for the flows <b>4</b>.<b>1</b>–<b>4</b>.K.

0053Next, the rate policing/re-marking process blocks <b>606</b>.<b>1</b>–<b>606</b>.K provide packet header information corresponding to secondary flows <b>5</b>.<b>1</b>–<b>5</b>.K to a rate policing/re-marking process block <b>610</b>. Further, packet header information corresponding to primary packet flows <b>6</b>.<b>1</b>–<b>6</b>.L may be provided to the rate policing/re-marking process block <b>610</b>, which performs a second level of rate policing/re-marking operations on the aggregated flows <b>5</b>.<b>1</b>–<b>5</b>.K and <b>6</b>.<b>1</b>–<b>6</b>.L to generate packet disposition information for the flows <b>5</b>.<b>1</b>–<b>5</b>.K and <b>6</b>.<b>1</b>–<b>6</b>.L. The rate policing/re-marking process block <b>610</b> provides the packet disposition information for the aggregated flows <b>5</b>.<b>1</b>–<b>5</b>.K and <b>6</b>.<b>1</b>–<b>6</b>.L to the switch <b>220</b> for subsequent disposition of the packets. It should be appreciated that the flow record processor <b>300</b> may be configured to police alternative aggregations of primary and/or secondary packet flows.

0054It is noted that the total available bandwidth for an aggregated flow may be substantially less than the sum of the bandwidths for the primary flows that are sub-flows of the aggregated flow. In this case, rate policing and re-marking of the primary and aggregated flows may be performed using “fair queuing”. For example, the switch <b>220</b> (see <figref idref="DRAWINGS">FIG. 2</figref>) may be configured to scan the plurality of primary flows at the input ports <b>1</b>-P “round robin” by sequentially taking the first packet from each primary flow and performing rate policing and re-marking on that packet. Such fair queuing may alternatively be performed on a byte-by-byte basis instead of packet-by-packet. Moreover, because the switch <b>220</b> may buffer the primary flows for different service classes, rate policing and re-marking of the primary and aggregated flows may be performed using “weighted fair queuing”. For example, the switch <b>220</b> may be configured to scan the buffered primary flows and take more packets from the flows that are buffered for high service classes than those buffered for low service classes. Other ways of implementing rate policing and re-marking of primary and aggregated flows on a fair basis are also possible.

0055The flow record processor control unit <b>302</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) is configured to receive the packet header information comprising the ICoS parameter, the primary flow ID, and the packet byte count from the input <b>324</b>, and provide the received primary flow ID and packet byte count to the token bucket processor <b>304</b>, which fetches a flow record corresponding to the primary flow established for the packet from a flow record memory <b>322</b> using the primary flow ID as the read address.

0056<figref idref="DRAWINGS">FIG. 7</figref> depicts an illustrative format <b>700</b> for the flow record fetched from the flow record memory <b>322</b> by the token bucket processor <b>304</b>. In the illustrated format, the flow record includes a field containing a signed token bucket value for the packet flow, and a field containing a pointer to a location in an action table <b>310</b> (see <figref idref="DRAWINGS">FIG. 3</figref>), the function of which is described below.

0057The flow record processor control unit <b>302</b> further provides the primary flow ID to the token bucket update control unit <b>306</b>, which fetches token bucket addend and maximum values for the primary flow from a token bucket addend memory <b>320</b> using the primary flow ID as the read address.

0058<figref idref="DRAWINGS">FIG. 8</figref> depicts an illustrative format <b>800</b> for the token bucket addend and maximum values fetched from the token bucket addend memory <b>320</b> by the token bucket update control unit <b>306</b>. The illustrated token bucket addend/maximum value format <b>800</b> comprises two (2) consecutive words <b>802</b> and <b>804</b>. The first word <b>802</b> includes a field containing the token bucket addend value, and the second word <b>804</b> includes a field containing the token bucket maximum value.

0059Moreover, the flow record processor control unit <b>302</b> provides at least one statistic related to the token bucket processing results to a statistics memory <b>328</b>, which stores the statistic for system-level use.

0060<figref idref="DRAWINGS">FIG. 9</figref> depicts an illustrative format <b>900</b> for the statistic data and an address of the statistics memory <b>328</b> at which the statistic is stored. The illustrated statistics address and data format <b>900</b> includes a write address <b>902</b> and statistics data <b>904</b>. The write address <b>902</b> includes a field containing the primary flow ID, and a STAT field that may be used to address one of a plurality of predetermined statistics such as the number of packets passed, the number of packets re-marked, the number of packets dropped from a respective primary flow, and the number of packets dropped from a respective aggregated flow. The statistics data <b>904</b> includes a field containing the statistic to be stored in the location of the statistics memory <b>328</b> pointed at by the write address <b>902</b>. For example, the token bucket addend memory <b>320</b>, the flow record memory <b>322</b>, and the statistics memory <b>328</b> may comprise respective static Random Access Memories (RAMs).

0061The token bucket processor <b>304</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) is configured to execute mathematical operations required to process the respective token buckets of the primary flow and any aggregated packet flow(s). A token bucket value for a packet flow generally corresponds to the total number of bytes that may be transmitted via the flow during a predetermined period of time. After receiving the primary flow ID and the packet byte count from the flow record processor control unit <b>302</b> and fetching the flow record corresponding to the primary flow from the flow record memory <b>322</b>, the token bucket processor <b>304</b> subtracts the packet byte count from the corresponding token bucket value.

0062In the event the sign of the token bucket value is negative after subtracting the packet byte count, it is concluded that the packet does not conform to the bandwidth requirements for the primary flow specified in the ICoS contract. In the event the token bucket value remains non-negative after subtracting the packet byte count, it is concluded that the packet complies with the terms of the ICoS contract and the token bucket processor <b>304</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Next, the token bucket processor <b>304</b> determines whether the primary packet flow is a sub-flow of an aggregation of secondary packet flows by attempting to fetch a valid aggregated flow ID for the primary flow from the aggregated flow ID look-up table <b>308</b> using the primary flow ID as the read address. For example, the aggregated flow ID look-up table <b>308</b> and the action table <b>310</b> may comprise respective RAMs.

0063<figref idref="DRAWINGS">FIG. 10</figref> depicts an illustrative format <b>1000</b> for the aggregated flow ID fetched from the aggregated flow ID look-up table <b>308</b> by the token bucket processor <b>304</b>. The illustrated aggregated flow ID format <b>1000</b> includes a field containing the aggregated flow ID and a Valid (V) bit. In the event the V bit is de-asserted, it is concluded that no aggregated flow exists for the primary flow. In the event the V bit is asserted, it is concluded that the primary flow is a sub-flow of an aggregated flow and the corresponding aggregated flow ID is contained in the aggregated flow ID field.

0064The token bucket processor <b>304</b> (see <figref idref="DRAWINGS">FIG. 3</figref>) fetches a flow record corresponding to the aggregated flow from the flow record memory <b>322</b> using the valid aggregated flow ID as the read address. In the presently disclosed embodiment, the flow record for the aggregated flow conforms to the flow record format <b>700</b> depicted in <figref idref="DRAWINGS">FIG. 7</figref>. The token bucket processor <b>304</b> then performs token bucket processing on the aggregated flow in a manner similar to that described above for the primary flow.

0065The token bucket update control unit <b>306</b> is configured for periodically updating the respective token bucket values stored in the flow record memory <b>322</b> using the corresponding token bucket addend and maximum values fetched from the token bucket addend memory <b>320</b>. In the presently disclosed embodiment, the token bucket update control unit <b>306</b> includes a programmable interval counter (not shown) that determines a time interval between successive token bucket updates, and a flow ID counter (not shown) that provides output values corresponding to the primary and aggregated packet flow IDs. Each token bucket update operation comprises adding the token bucket addend value to the corresponding token bucket value and comparing the resulting token bucket value to the corresponding maximum token bucket value to ascertain whether the maximum value for that token bucket has been exceeded. For example, the maximum token bucket value may be used as a “clamp” value to prevent a packet flow with a bursting nature from temporarily saturating the network with sustained periods of activity. By controlling the frequency of the token bucket updates and the respective magnitudes of the token bucket addend and maximum values for a particular packet flow, the flow record processor <b>300</b> can enforce the bandwidth of the packet flow on the network.

0066Each time the interval counter expires, the token bucket update control unit <b>306</b> sends read requests to the token bucket addend memory <b>320</b> and the flow record memory <b>322</b> using the output value of the flow ID counter as the read address. The token bucket addend memory <b>320</b> then provides the corresponding token bucket addend and maximum values, and the flow record memory <b>322</b> provides the corresponding token bucket value, to the token bucket update control unit <b>306</b>, which in turn provides these values to the token bucket processor <b>304</b>. Next, the token bucket processor <b>304</b> adds the addend value to the token bucket value and compares the resulting token bucket value to the corresponding maximum token bucket value. In the event the resulting token bucket value is less than or equal to the corresponding maximum value, the token bucket processor <b>304</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b>. In the event the resulting token bucket value is greater than the corresponding maximum value, the token bucket processor <b>304</b> stores the maximum value as the new token bucket value.

0067It is noted that when the update of a token bucket value by the token bucket update control unit <b>306</b> coincides with the processing of a corresponding primary or aggregated flow by the token bucket processor <b>304</b>, the update of the token bucket value can be combined with the processing of the corresponding packet flow. For example, the token bucket processor <b>304</b> may add the addend value to the token bucket value before subtracting the packet byte count from the token bucket value. This may cause some packets to be passed unmodified that might otherwise have been re-marked or dropped from the network but for the coinciding token bucket update operation.

0068The token bucket processor <b>304</b> provides the action table pointer for the primary or aggregated packet flow and an indication of whether the packet is conforming or non-conforming to the flow record processor control unit <b>302</b>. In the event the packet conforms to the bandwidth requirements of the respective ICoS contract, the flow record processor control unit <b>302</b> fills the ECoS field of the packet disposition information with the data from the ICoS field (see <figref idref="DRAWINGS">FIG. 4</figref>) and de-asserts the Drop bit (see <figref idref="DRAWINGS">FIG. 5</figref>). In the event the packet fails to comply with the respective ICoS contract, the flow record processor control unit <b>302</b> determines the ultimate disposition of the non-conforming packet by accessing an appropriate action from the action table <b>310</b> (see <figref idref="DRAWINGS">FIG. 3</figref>).

0069The action table <b>310</b> is configured to store representations of a plurality of addressable actions for primary and aggregated flows that define the ultimate disposition of non-conforming packets in the respective flows. For example, the plurality of addressable actions may include re-marking a non-conforming packet with a new ECoS parameter and dropping a non-conforming packet from the network. The flow record processor control unit <b>302</b> uses the action table pointer and a selected CoS parameter as an offset to the action table pointer to fetch a representation of the action to be taken on the non-conforming packet from the action table <b>310</b>, and provides packet disposition information indicative of that action to the output <b>326</b>.

0070<figref idref="DRAWINGS">FIG. 11</figref> depicts an illustrative format <b>1100</b> for the addressable actions stored in the action table <b>310</b> (see <figref idref="DRAWINGS">FIG. 3</figref>). The illustrated action table data format <b>1100</b> includes a field containing a plurality of primary flow action fields, a field containing a plurality of aggregated flow action fields, and a New bit, the function of which is described below.

0071<figref idref="DRAWINGS">FIG. 12</figref> depicts an illustrative format <b>1200</b> for the respective primary flow and aggregated flow action fields (see <figref idref="DRAWINGS">FIG. 11</figref>). As shown in <figref idref="DRAWINGS">FIG. 12</figref>, each action field is subdivided into a plurality of action fields AF<b>0</b>–AF<b>7</b> containing representations of actions to be taken on non-conforming packets. It is noted that the total number of primary flow action fields may be different from the total number of aggregated flow action fields.

0072Each of the action fields AF<b>0</b>–AF<b>7</b> of <figref idref="DRAWINGS">FIG. 12</figref> is further subdivided into a Discard Eligibility (DE) field, a priority (PRI) bit, a Drop bit, and a Whole Number (WN) bit. In the illustrated format, the DE field contains the Least Significant Bits (LSBs) of a predetermined CoS parameter, and the PRI bit is the Most Significant Bit (MSB) of the predetermined CoS parameter. For example, the respective CoS parameters stored in the action fields AF<b>0</b>–AF<b>7</b> may be used in re-marking non-conforming packets with new ECoS parameters. The Drop bit is asserted when the action to be taken on the non-conforming packet comprises dropping the packet from the network. Further, the WN bit is asserted when the action to be taken on the non-conforming packet comprises re-marking the packet and allowing the re-marked packet to pass on the network. In this case, the Drop bit is de-asserted. For example, a non-conforming packet may be re-marked with a new ECoS parameter that lowers its priority from, e.g., a high priority to a low priority to allow the non-conforming packet to be dropped more easily at a subsequent node on the network. This provides the communications system with a more flexible response to data traffic that arrives in short intense bursts but does not exceed the total bandwidth allotment over time.

0073In the presently disclosed embodiment, the ICoS parameter, i.e., the bits in the DE field and the PRI bit of the ICoS field (see <figref idref="DRAWINGS">FIG. 4</figref>), is used as an offset to the action table pointer for the primary flow to select the primary flow action field AF<b>0</b>–AF<b>7</b> (see <figref idref="DRAWINGS">FIG. 12</figref>) containing the action to be taken on a non-conforming packet in the primary flow. In the event the primary flow is not a sub-flow of an aggregated flow, as indicated by the V bit in the aggregated flow ID format <b>1000</b> (see <figref idref="DRAWINGS">FIG. 10</figref>), the bits in the DE field and the PRI bit of the selected primary flow action field AF<b>0</b>–AF<b>7</b> may be used as the new ECoS parameter when re-marking a non-conforming packet.

0074In the event the primary flow is a sub-flow of an aggregated flow and the New bit (see <figref idref="DRAWINGS">FIG. 11</figref>) is de-asserted, the DE and PRI bits of the ICoS field are used as an offset to the action table pointer for the aggregated flow to select the aggregated flow action field AF<b>0</b>–AF<b>7</b> containing the action to be taken on a non-conforming packet in the aggregated flow. In the event the New bit is asserted, the DE and PRI bits of the previously selected primary flow action field AF<b>0</b>–AF<b>7</b> are used as the offset to the action table pointer for the aggregated flow to select the appropriate aggregated flow action field AF<b>0</b>–AF<b>7</b>. As in the token bucket operation for the primary flow, the bits in the DE field and the PRI bit of the selected aggregated flow action field AF<b>0</b>–AF<b>7</b> may be used as the new ECoS parameter when re-marking a non-conforming packet. The flow record processor control unit <b>302</b> then provides the packet disposition information with the appropriate bit values in the Drop and ECoS fields (see <figref idref="DRAWINGS">FIG. 5</figref>) to the switch <b>220</b>, which subsequently performs the indicated action on the packet.

0075The presently disclosed embodiment will be better understood with reference to the following illustrative examples. In a first example, the rate policing/re-marking logic <b>200</b> (see <figref idref="DRAWINGS">FIG. 2</figref>) is configured to perform single-level rate policing of a packet in a primary flow received by the switch <b>220</b>. In this example, the valid (V) bit in the aggregated flow ID format <b>1000</b> (see <figref idref="DRAWINGS">FIG. 10</figref>) is de-asserted, and the Drop bit in the primary flow action fields AF<b>0</b>–AF<b>7</b> (see <figref idref="DRAWINGS">FIG. 12</figref>) is asserted. In the event the rate policing/re-marking logic <b>200</b> determines that the packet conforms to the requirements of the respective ICoS contract (i.e., the token bucket value for the primary flow remains non-negative after subtracting the packet byte count), the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Next, the rate policing/re-marking logic <b>200</b> de-asserts the Drop bit and uses the original ICoS data to fill the ECoS field in the packet disposition information (see <figref idref="DRAWINGS">FIG. 5</figref>). The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b>, thereby informing the switch <b>220</b> to pass packet unmodified on the network. In the event the rate policing/re-marking logic <b>200</b> determines that the packet is non-conforming (i.e., the token bucket value for the primary flow is negative after subtracting the packet byte count), the rate policing/re-marking logic <b>200</b> uses the asserted Drop bit in the selected primary flow action field to fill the corresponding field in the packet disposition information (see <figref idref="DRAWINGS">FIG. 5</figref>), and then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to drop the non-conforming packet from the network.

0076In a second example, the rate policing/re-marking logic <b>200</b> is configured to perform single-level accounting of a packet in a primary flow. In this example, the valid (V) bit in the aggregated flow ID format <b>1000</b> (see <figref idref="DRAWINGS">FIG. 10</figref>) is de-asserted, the Drop bit in the primary flow action fields AF<b>0</b>–AF<b>7</b> is de-asserted, and the Whole Number (WN) bit in the primary flow action fields AF<b>0</b>–AF<b>7</b> (see <figref idref="DRAWINGS">FIG. 12</figref>) is either asserted or de-asserted (both cases are considered below). Further, the PRI and DE bits in the primary flow action fields AF<b>0</b>–AF<b>7</b> are set to the same values as in the ICoS field (see <figref idref="DRAWINGS">FIG. 4</figref>). In the event the rate policing/re-marking logic <b>200</b> determines that the packet is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Next, the rate policing/re-marking logic <b>200</b> de-asserts the Drop bit and uses the original ICoS data to fill the ECoS field in the packet disposition information. The rate policing/re-marking logic <b>200</b> then stores a statistic indicating that the packet in the primary flow is passed on the network at the appropriate address of the statistics memory <b>328</b>. Next, the rate policing/re-marking logic <b>200</b> provides the packet disposition information to the switch <b>220</b>, thereby informing the switch <b>220</b> to pass the packet unmodified on the network. In the event the rate policing/re-marking logic <b>200</b> determines that the packet is non-conforming and the WN bit is de-asserted, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. If the token bucket underflows or goes from negative to positive, or if the WN bit is asserted, then the rate policing/re-marking logic <b>200</b> does not store the new token bucket value in the flow record memory <b>322</b>. Next, the rate policing/re-marking logic <b>200</b> uses the Drop, PRI, and DE bits in the selected primary flow action field to fill the corresponding fields in the packet disposition information (see <figref idref="DRAWINGS">FIG. 5</figref>). In effect, the non-conforming packet is “re-marked” with the original ICoS parameter. The rate policing/re-marking logic <b>200</b> then stores a statistic indicating that the non-conforming packet is re-marked at the appropriate address of the statistics memory <b>328</b>. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the re-marked packet on the network.

0077In a third example, the rate policing/re-marking logic <b>200</b> is configured to perform single-level re-marking of a packet in a primary flow. In this example, the valid (V) bit in the aggregated flow ID format <b>1000</b> is de-asserted, the Drop bit in the primary flow action fields AF<b>0</b>–AF<b>7</b> is de-asserted, and the Whole Number (WN) bit in the primary flow action fields AF<b>0</b>–AF<b>7</b> is either asserted or de-asserted (both cases are considered below). Further, the PRI and DE bits in the respective primary flow action fields AF<b>0</b>-AF<b>7</b> are set to conform to predetermined CoS parameters. In the event the rate policing/re-marking logic <b>200</b> determines that the packet is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Next, the rate policing/re-marking logic <b>200</b> de-asserts the Drop bit and uses the ICoS data to fill the ECoS field in the packet disposition information. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b>, thereby informing the switch <b>220</b> to pass the packet unmodified on the network. In the event the rate policing/re-marking logic <b>200</b> determines that the packet is non-conforming and the WN bit is de-asserted, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. If the WN bit is asserted, then the rate policing/re-marking logic <b>200</b> does not store the new token bucket value in the flow record memory <b>322</b>. Next, the rate policing/re-marking logic <b>200</b> uses the Drop, PRI, and DE bits in the selected primary flow action field to fill the corresponding fields in the packet disposition information. In this way, the non-conforming packet is re-marked with a new ECoS parameter. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the re-marked packet on the network.

0078In a fourth example, the rate policing/re-marking logic <b>200</b> is configured to perform two-level policing/re-marking of a packet in a primary flow, which is a sub-flow of an aggregated packet flow. For example, such two-level policing/re-marking may be performed to enforce an ICoS contract specifying that a network user has a total bandwidth of 100 MB/s with 300 KB/s of high priority data traffic. Further, the ICoS contract may stipulate that any traffic above 100 MB/s is to be dropped from the network <b>102</b>. In this case, the token bucket for the primary flow is set up to enforce the specified 300 KB/s data transmission rate and the token bucket for the aggregated flow is set up to enforce the specified 100 MB/s transmission rate.

0079In this fourth example, the valid (V) bit in the aggregated flow ID format <b>1000</b> is asserted. In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the primary flow is non-conforming, the rate policing/re-marking logic <b>200</b> does not perform the token bucket operation for the aggregated flow. The rate policing/re-marking logic <b>200</b> then asserts the Drop bit in the packet disposition information and provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to drop the packet from the network.

0080In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the primary flow is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Next, the rate policing/re-marking logic <b>200</b> performs token bucket processing for the aggregated flow. In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the aggregated flow is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the aggregated flow. It is noted that the rate policing/re-marking logic <b>200</b> may defer storing the new token bucket value for the primary flow in the flow record memory <b>322</b> until the token bucket processing results for the aggregated flow are known so as not to penalize the primary flow for traffic dropped by the aggregate. Next, the rate policing/re-marking logic <b>200</b> de-asserts the Drop bit and uses the data in the ICoS field to fill the ECoS field in the packet disposition information. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the packet unmodified on the network.

0081In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the aggregated flow is non-conforming, the WN bit is examined to determine whether to store the new token bucket value in the flow record memory <b>322</b> for the aggregated flow. If the WN bit is de-asserted, then the new aggregated token bucket value is stored. Otherwise, the new aggregated token bucket value is not stored. Next, the rate policing/re-marking logic <b>200</b> uses the Drop, PRI, and DE bits in the selected aggregated flow action field to fill the corresponding fields in the packet disposition information. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the re-marked packet on the network.

0082In a fifth example, the rate policing/re-marking logic <b>200</b> is configured to perform two-level re-marking/re-marking of a packet in a primary flow, which is a sub-flow of an aggregated packet flow. For example, such two-level re-marking/re-marking may be performed to enforce an ICoS contract specifying that a network user has a total bandwidth of 100 MB/s including 300 KB/s of high priority traffic with any remaining traffic passed on an opportunistic basis, i.e., if there is enough bandwidth available in the aggregated flow.

0083In this fifth example, the valid (V) bit in the aggregated flow ID format <b>1000</b> is asserted, and the New bit in the action table format <b>1100</b> (see <figref idref="DRAWINGS">FIG. 11</figref>) is either asserted or de-asserted (both cases are considered below). Further, the Drop bits in the primary and aggregated action fields AF<b>0</b>–AF<b>7</b> are de-asserted. In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the primary flow is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the primary flow. Further, the data in the ICoS field remains unmodified. In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the primary flow is non-conforming, the rate policing/re-marking logic <b>200</b> optionally stores the new token bucket value for the primary flow depending on the value of the WN bit. Further, the PRI and DE bits from the selected primary action field are used to fill (i.e., re-mark) the ICoS field. If the New bit is asserted, then the PRI and DE bits from the selected primary action field are also used to select the aggregated flow action field during token bucket processing for the aggregated flow. If the New bit is de-asserted, then the original PRI and DE bits from the ICoS field are used to select the aggregated flow action field.

0084Next, the rate policing/re-marking logic <b>200</b> performs token bucket processing for the aggregated flow. In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the aggregated flow is conforming, the rate policing/re-marking logic <b>200</b> stores the new token bucket value in the appropriate location of the flow record memory <b>322</b> for the aggregated flow. Next, the rate policing/re-marking logic <b>200</b> de-asserts the Drop bit and uses the data in the ICoS field to fill the ECoS field in the packet disposition information. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the packet unmodified or re-marked on the network (depending on whether the packet in the primary flow is determined to be conforming or non-conforming). In the event the rate policing/re-marking logic <b>200</b> determines that the packet in the aggregated flow is non-conforming, the WN bit is examined to determine whether to store the new token bucket value in the flow record memory <b>322</b> for the aggregated flow. Next, the rate policing/re-marking logic <b>200</b> uses the Drop, PRI, and DE bits in the selected aggregated flow action field to fill (i.e., re-mark) the ECoS field in the packet disposition information. The rate policing/re-marking logic <b>200</b> then provides the packet disposition information to the switch <b>220</b> to inform the switch <b>220</b> to pass the re-marked packet on the network.

0085The presently disclosed method of performing rate policing and re-marking in a communications network is represented in pseudo code in <figref idref="DRAWINGS">FIGS. 13</figref><i>a</i>–<b>13</b><i>b </i>for a computer program written in a language such as C. It should be understood that the method steps depicted in <figref idref="DRAWINGS">FIG. 13</figref> are merely exemplary and that alternative steps may be employed to enforce and/or monitor CoS contracts including terms for single or multiple classes of service. It is also understood that the method represented by the pseudo code is performed at an ingress node on the network configured to receive an incoming packet, extract header information from the packet including an ICoS parameter (CCOS), a primary flow ID, and a packet byte count (B), and use the extracted packet header information to perform flow record and token bucket processing on the packet.

0086As shown in <figref idref="DRAWINGS">FIG. 13</figref><i>a</i>, a primary token bucket test is performed on the incoming packet. Specifically, B is subtracted from the token bucket value for the primary flow (PTB). If PTB−B&lt;0, then the incoming packet fails to conform to the bandwidth requirements of the primary flow. CCOS is then used to fetch the primary action table entry (AT<b>1</b>) for the non-conforming packet. If Drop(AT<b>1</b>, CCOS)=True (i.e., if the Drop bit is asserted in AT<b>1</b>), then the packet is dropped from the network and the method is performed on the next incoming packet. If the Drop bit is de-asserted, then the packet is re-marked with a new class of service (NCCOS), which is obtained from AT<b>1</b>. Further, if the whole number (WN) bit is de-asserted in AT<b>1</b>, then PTB=PTB−B. Moreover, if PTB−B≧0, then PTB=PTB−B.

0087As shown in <figref idref="DRAWINGS">FIG. 13</figref><i>b</i>, if V=False (i.e., if the Valid (V) bit is de-asserted in a corresponding aggregated flow ID for the incoming packet), then the primary flow is not a sub-flow of an aggregated flow and NCCOS is written in the header field of the corresponding outgoing packet. The method is then performed on the next incoming packet. If the V bit is asserted, then an aggregated token bucket test is performed on the incoming packet. Further, if UseNewCCOS=True (i.e., if the New bit is asserted in the corresponding action table data), then CCOS=NCCOS. Next, B is subtracted from the token bucket value for the aggregated flow (ATB). If ATB−B&lt;0, then the incoming packet fails to conform to the bandwidth requirements of the aggregated flow. CCOS is then used to fetch the aggregated action table entry (AT<b>2</b>) for the non-conforming packet. If Drop(AT<b>2</b>, CCOS)=True (i.e., if the Drop bit is asserted in AT<b>2</b>), then the packet is dropped from the network and the method is performed on the next incoming packet. If the Drop bit is de-asserted, then the packet is re-marked with NCCOS, which is obtained from AT<b>2</b>. Further, if the whole number (WN) bit is de-asserted in AT<b>2</b>, then ATB=ATB−B. Moreover, if ATB−B≧0, then ATB=ATB−B. Finally, NCCOS is written in the header field of the outgoing packet, and the method is performed on the next incoming packet.

0088It will further be appreciated by those of ordinary skill in the art that modifications to and variations of the above-described dual use rate policer and re-marking logic may be made without departing from the inventive concepts disclosed herein. Accordingly, the invention should not be viewed as limited except as by the scope and spirit of the appended claims.