Dynamic assignment of traffic classes to a priority queue in a packet forwarding device
1 like262 views
The document provides details about European Patent EP 1 142 213 B1 related to a method for dynamically assigning traffic classes to priority queues in packet forwarding devices, specifically aimed at improving the management of packet queues in telecommunications. It describes challenges in packet queuing and introduces solutions that allow for automatic adjustments of traffic priorities based on bandwidth consumption. The invention involves hardware capable of executing user-defined traffic management policies to efficiently manage network traffic flows.
![EP 1 142 213 B1
1 2
5
10
15
20
25
30
35
40
45
50
55
2
Description
FIELD OF THE INVENTION
[0001] The present invention relates to the field of tel-ecommunications,
and more particularly to dynamic as-signment
of traffic classes to queues having different pri-ority
levels.
BACKGROUND OF THE INVENTION
[0002] The flow of packets through packet-switched
networks is controlled by switches and routers that for-ward
packets based on destination information included
in the packets themselves. A typical switch or router in-cludes
a number of input/output (I/O) modules connect-ed
to a switching fabric, such as a crossbar or shared
memory switch. In some switches and routers, the
switching fabric is operated at a higher frequency than
the transmission frequency of the I/O modules so that
the switching fabric may deliver packets to an I/O mod-ule
faster than the I/O module can output them to the
network transmission medium. In these devices, pack-ets
are usually queued in the I/O module to await trans-mission.
[0003] One problem that may occur when packets are
queued in the I/O module or elsewhere in a switch or
router is that the queuing delay per packet varies de-pending
on the amount of traffic being handled by the
switch. Variable queuing delays tend to degrade data
streams produced by real-time sampling (e.g., audio
and video) because the original time delays between
successive packets in the stream convey the sampling
interval and are therefore needed to faithfully reproduce
the source information. Another problem is that results
from queuing packets in a switch or router is that data
from a relatively important source, such as a shared
server, may be impeded by data from less important
sources, resulting in bottlenecks.
[0004] One possible solution to this is described in In-ternational
Application Number WO 99 00949. In this
application a method whereby queues are prioritised is
disclosed and the priority of a flow may be lowered.
However, flows are packets forwarded within the subnet
and therefore requiring no header modification. There-fore,
a method for prioritising packets from/to sources/
destinations outside the subnet is required.
SUMMARY OF THE INVENTION
[0005] A method and apparatus for dynamic assign-ment
of classes of traffic to a priority queue in accord-ance
with Claims 1 and 9 respectively are disclosed.
Bandwidth consumption by one or more types of packet
traffic received in a packet forwarding device is moni-tored.
The queue assignment of at least one type of
packet traffic is automatically changed from a queue
having a first priority to a queue having a second priority
if the bandwidth consumption exceeds the threshold.
[0006] Other features and advantages of the inven-tion
will be apparent from the accompanying drawings
and from the detailed description that follows below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The present invention is illustrated by way of
example and not limitation in the figures of the accom-panying
drawings in which like references indicate sim-ilar
elements and in which:
Fig.1 illustrates a packet forwarding device that can
be used to implement embodiments of the present
invention;
Fig. 2A illustrates queue fill logic implemented by a
queue manager in a quad interface device;
Fig. 2B illustrates queue drain logic according to
one embodiment;
Fig: 3 illustrates the flow of a packet within the
switch of Fig. 1;
Fig. 4 illustrates storage of an entry in an address
resolution table managed by an address resolution
unit;
Fig. 5 is a diagram of the software architecture of
the switch of Fig. 1 according to one embodiment;
and
Fig. 6 illustrates an example of dynamic assignment
of traffic classes to a priority queue.
DETAILED DESCRIPTION
[0008] A packet forwarding device in which selected
classes of network traffic may be dynamically assigned
for priority queuing is disclosed. In one embodiment, the
packet forwarding device includes a Java virtual ma-chine
for executing user-coded Java applets received
from a network management server (NMS). A Java-to-native
interface (JNI) is provided to allow the Java ap-plets
to obtain error information and traffic statistics from
the device hardware and to allow the Java applets to
write configuration information to the device hardware,
including information that indicates which classes of
traffic should be queued in priority queues. The Java ap-plets
implement user-specified traffic management pol-icies
based on real-time evaluation of the error informa-tion
and traffic statistics to provide dynamic control of
the priority queuing assignments. These and other as-pects
and advantages of the present invention are de-scribed
below.
[0009] Fig. 1 illustrates a packet forwarding device 17
that can be used to implement embodiments of the
present invention. For the purposes of the present de-scription,
the packet forwarding device 17 is assumed
to be a switch that switches packets between ingress
and egress ports based on media access control (MAC)
addresses within the packets. In an alternate embodi-ment,
the packet forwarding device 17 may be a router](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-2-320.jpg)
![EP 1 142 213 B1
3 4
5
10
15
20
25
30
35
40
45
50
55
3
that routes packets according to destination internet
protocol (IP) addresses or a routing switch that performs
both MAC address switching and IP address routing.
The techniques and structures disclosed herein are ap-plicable
generally to a device that forwards packets in a
packet switching network. Also, the term packet is used
broadly herein to refer to a fixed-length cell, a variable
length frame or any other information structure that is
self-contained as to its destination address.
[0010] The switch 17 includes a switching fabric 12
coupled to a plurality of I/O units (only I/O units 1 and
16 are depicted) and to a processing unit 10. The
processing unit includes at least a processor 31 (which
may be a microprocessor, digital signal processor or mi-crocontroller)
coupled to a memory 32 via a bus 33. In
one embodiment, each I/O unit 1, 16 includes four phys-ical
ports P1-P4 coupled to a quad media access con-troller
(QMAC) 14A, 14B via respective transceiver in-terface
units 21A-24A, 21B-24B. Each I/O unit 1, 16 also
includes a quad interface device (QID) 16A, 16B, an ad-dress
resolution unit (ARU) 15A, 15B and a memory
18A,18B, interconnected as shown in Fig. 1. Preferably,
the switch 17 is modular with at least the I/O units 1, 16
being implemented on port cards (not shown) that can
be installed in a backplane (not shown) of the switch 17.
In one implementation, each port card includes four I/O
units and therefore supports up to 16 physical ports. The
switch backplane includes slots for up to six port cards,
so that the switch 17 can be scaled according to cus-tomer
needs to support between 16 and 96 physical
ports. In alternate embodiments, each I/O unit 1, 16 may
support more or fewer physical ports, each port card
may support more or fewer I/O units 1, 16 and the switch
17 may support more or fewer port cards. For example,
the I/O unit 1 shown in Fig.1 may be used to support
four 10baseT transmission lines (i.e.,10 Mbps (mega-bit
per second), twisted-pair) or four 100baseF transmis-sion
lines (100 Mbps, fiber optic), while a different I/O
unit (not shown) may be used to support a single
1000baseF transmission line (1000 Mbps, fiber optic).
Nothing disclosed herein should be construed as limit-ing
embodiments of the present invention to use with a
particular transmission medium, I/O unit, port card or
chassis configuration.
[0011] Still referring to Fig.1, when a packet 25 is re-ceived
on physical port P1, it is supplied to the corre-sponding
physical transceiver 21A which performs any
necessary signal conditioning (e.g., optical to electrical
signal conversion) and then forwards the packet 25 to
the QMAC 14A. The QMAC 14A buffers packets re-ceived
from the four physical transceivers 21A-24A as
necessary, forwarding one packet at a time to the QID
16A. Receive logic within the QID 16A notifies the ARU
15A that the packet 25 has been received. The ARU
computes a table index based on the destination MAC
address within the packet 25 and uses the index to iden-tify
an entry in a forwarding table that corresponds to the
destination MAC address. In packet forwarding devices
that operate on different protocol layers of the packet (e.
g., routers), a forwarding table may be indexed based
on other destination information contained within the
packet.
[0012] According to one embodiment, the forwarding
table entry identified based on the destination MAC ad-dress
indicates the switch egress port to which the pack-et
25 is destined and also whether the packet is part of
a MAC-address based virtual local area network
(VLAN), or a port-based VLAN. (As an aside, a VLAN is
a logical grouping of MAC addresses (a MAC-address-based
VLAN) or a logical grouping of physical ports (a
port-based VLAN).) The forwarding table entry further
indicates whether the packet 25 is to be queued in a
priority queue in the I/O unit that contains the destination
port. As discussed below, priority queuing may be spec-ified
based on a number of conditions, including, but not
limited to, whether the packet is part of a particular IP
flow, or whether the packet is destined for a particular
port, VLAN or MAC address.
[0013] According to one embodiment, the QID 16A,
16B segments the packet 25 into a plurality of fixed-length
cells 26 for transmission through the switching
fabric 12. Each cell includes a header 28 that identifies
it as a constituent of the packet 25 and that identifies
the destination port for the cell (and therefore for the
packet 25). The header 28 of each cell also includes a
bit 29 indicating whether the cell is the beginning cell of
a packet and also a bit 30 indicating whether the packet
25 to which the cell belongs is to be queued in a priority
queue or a best effort queue on the destined I/O unit.
[0014] The switching fabric 12 forwards each cell to
the I/O unit indicated by the cell header 28. In the ex-emplary
data flow shown in Fig.1, the constituent cells
26 of the packet 25 are assumed to be forwarded to I/O
unit 16 where they are delivered to transmit logic within
the QID 16B. The transmit logic in the QID 16B includes
a queue manager (not shown) that maintains a priority
queue and a best effort queue in the memory 18B. In
one embodiment, the memory 18B is resolved into a
pool of buffers, each large enough to hold a complete
packet. When the beginning cell of the packet 25 is de-livered
to the QID 16B, the queue manager obtains a
buffer from the pool and appends the buffer to either the
priority queue or the best effort queue according to
whether the priority bit 30 is set in the beginning cell. In
one embodiment, the priority queue and the best effort
queue are each implemented by a linked list, with the
queue manager maintaining respective pointers to the
head and tail of each linked list. Entries are added to the
tail of the queue list by advancing the tail pointer to point
to a newly allocated buffer that has been appended to
the linked list, and entries are popped off the head of the
queue by advancing the head pointer to point to the next
buffer in the linked list and returning the spent buffer to
the pool.
[0015] After a buffer is appended to either the priority
queue or the best effort queue, the beginning cell and](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-3-320.jpg)
![EP 1 142 213 B1
5 6
5
10
15
20
25
30
35
40
45
50
55
4
subsequent cells are used to reassemble the packet 25
within the buffer. Eventually the packet 25 is popped off
the head of the queue and delivered to an egress port
via the QMAC 14B and the physical transceiver (e.g.,
23B) in an egress operation. This is shown by way of
example in Fig. 1 by the egress of packet 25 from phys-ical
port P3 of I/O unit 16.
[0016] Fig. 2A illustrates queue fill logic implemented
by the queue manager in the QID. Starting at block 51,
a cell is received in the QID from the switching fabric.
The beginning cell bit in the cell header is inspected at
decision block 53 to determine if the cell is the beginning
cell of a packet. If so, the priority bit in the cell header is
inspected at decision block 55 to determine whether to
allocate an entry in the priority queue or the best effort
queue for packet reassembly. If the priority bit is set, an
entry in the priority queue is allocated at block 57 and
the priority queue entry is associated with the portion of
the cell header that identifies the cell as a constituent of
a particular packet at block 59. If the priority bit in the
cell header is not set, then an entry in the best effort
queue is allocated at block 61 and the best effort queue
entry is associated with the portion of the cell header
that identifies the cell as a constituent of a particular
packet at block 63.
[0017] Returning to decision block 53, if the beginning
cell bit in the cell header is not set, then the queue entry
associated with the cell header is identified at block 65.
The association between the cell header and the queue
entry identified at block 65 was established earlier in ei-ther
block 59 or block 63. Also, identification of the
queue entry in block 65 may include inspection of the
priority bit in the cell to narrow the identification effort to
either the priority queue or the best effort queue. In block
67, the cell is combined with the preceding cell in the
queue entry in a packet reassembly operation. If the re-assembly
operation in block 67 results in a completed
packet (decision block 69), then the packet is marked
as ready for transmission in block 71. In one embodi-ment,
the packet is marked by setting a flag associated
with the queue entry in which the packet has been re-assembled.
Other techniques for indicating that a pack-et
is ready for transmission may be used in alternate
embodiments.
[0018] Fig. 2B illustrates queue drain logic according
to one embodiment. At decision block 75, the entry at
the head of the priority queue is inspected to determine
if it contains a packet ready for transmission. If so, the
packet is transmitted at block 77 and the corresponding
priority queue entry is popped off the head of the priority
queue and deallocated at block 79. If a ready packet is
not present at the head of the priority queue, then the
entry at the head of the best effort queue is inspected
at decision block 81. If a packet is ready at the head of
the best effort queue, it is transmitted at block 83 and
the corresponding best effort queue entry is popped off
the head of the best effort queue and deallocated in
block 85. Note that, in the embodiment illustrated in Fig.
2B, packets are drained from the best effort queue only
after the priority queue has been emptied. In alternate
embodiments, a timer, counter or similar logic element
may be used to ensure that the best effort queue 105 is
serviced at least every so often or at least after every N
number of packets are transmitted from the priority
queue, thereby ensuring at least a threshold level of
service to best effort queue.
[0019] Fig. 3 illustrates the flow of a packet within the
switch 17 of Fig. 1. A packet is received in the switch at
block 91 and used to identify an entry in a forwarding
table called the address resolution (AR) table at block
93. At decision block 95, a priority bit in the AR table
entry is inspected to determine whether the packet be-longs
to a class of traffic that has been selected for pri-ority
queuing. If the priority bit is set, the packet is seg-mented
into cells having respective priority bits set in
their headers in block 97. If the priority bit is not set, the
packet is segmented into cells having respective priority
bits cleared their cell headers in block 99. The constitu-ent
cells of each packet are forwarded to an egress I/O
unit by the switching fabric. In the egress I/O unit, the
priority bit of each cell is inspected (decision block 101)
and used to direct the cell to an entry in either the priority
queue 103 or the best effort queue 105 where it is com-bined
with other cells to reassemble the packet.
[0020] Fig. 4 illustrates storage of an entry in the ad-dress
resolution (AR) table managed by the ARU. In one
embodiment, the AR table is maintained in a high speed
static random access memory (SRAM) coupled to the
ARU. Alternatively, the AR table may be included in a
memory within an application-specific integrated circuit
(ASIC) that includes the ARU. Generally, the ARU
stores an entry in the AR table in response to packet
forwarding information from the processing unit. The
processing unit supplies packet forwarding information
to be stored in each AR table in the switch whenever a
new association between a destination address and a
switch egress port is learned. In one embodiment, an
address-to-port association is learned by transmitting a
packet that has an unknown egress port assignment on
each of the egress ports of the switch and associating
the destination address of the packet with the egress
port at which an acknowledgment is received. Upon
learning the association between the egress port and
the destination address, the processing unit issues for-warding
information that includes, for example, an iden-tifier
of the newly associated egress port, the destination
MAC address, an identifier of the VLAN associated with
the MAC address (if any), an identifier of the VLAN as-sociated
with the egress port (if any), the destination IP
address, the destination IP port (e.g., transmission con-trol
protocol (TCP), universal device protocol (UDP) or
other IP port) and the IP protocol (e.g., HTTP, FTP or
other IP protocol). The source IP address, source IP port
and source IP protocol may also be supplied to fully
identify an end-to-end IP flow.
[0021] Referring to Fig. 4, forwarding information 110](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-4-320.jpg)
![EP 1 142 213 B1
7 8
5
10
15
20
25
30
35
40
45
50
55
5
is received from the processing unit at block 115. At
block 117, the ARU stores the forwarding information in
an AR table entry. At decision block 119, the physical
egress port identifier stored in the AR table entry is com-pared
against priority configuration information to deter-mine
if packets destined for the egress port have been
selected for priority egress queuing. If so, the priority bit
is set in the AR table entry in block 127. Thereafter, in-coming
packets that index the newly stored table entry
will be queued in the priority queue to await transmis-sion.
If packets destined for the egress port have not
been selected for priority queuing, then at decision block
121 the MAC address stored in the AR table entry is
compared against the priority configuration information
to determine if packets destined for the MAC address
have been selected for priority egress queuing. If so, the
priority bit is set in the AR table entry in block 127. If
packets destined for the MAC address have not been
selected for priority egress queuing, then at decision
block 123 the VLAN identifier stored in the AR table en-try
(if present) is compared against the priority configu-ration
information to determine if packets destined for
the VLAN have been selected for priority egress queu-ing.
If so, the priority bit is set in the AR table entry in
block 127. If packets destined for the VLAN have not
been selected for priority egress queuing, then at block
125 the IP flow identified by the IP address, IP port and
IP protocol in the AR table is compared against the pri-ority
configuration information to determine if packets
that form part of the IP flow have been selected for pri-ority
egress queuing. If so, the priority bit is set in the
AR table entry, otherwise the priority bit is not set. Yet
other criteria may be considered in assigning priority
queuing in alternate embodiments. For example, priority
queuing may be specified for a particular IP protocol (e.
g., FTP, HTTP). Also, the ingress port, source MAC ad-dress
or source VLAN of a packet may also be used to
determine whether to queue the packet in the priority
egress packet. More specifically, in one embodiment,
priority or best effort queuing of unicast traffic is deter-mined
based on destination parameters (e.g., egress
port, destination MAC address or destination IP ad-dress),
while priority or best effort queuing of multicast
traffic is determined based on source parameters (e.g.,
ingress port, source MAC address or source IP ad-dress).
[0022] Fig. 5 is a diagram of the software architecture
of the switch 17 of Fig.1 according to one embodiment.
An operating system 143 and device drivers 145 are
provided to interface with the device hardware 141. For
example, device drivers are provided to write configura-tion
information and AR storage entries to the ARUs in
respective I/O units. Also, the operating system 143 per-forms
memory management functions and other system
services in response to requests from higher level soft-ware.
Generally, the device drivers 145 extend the serv-ices
provided by the operating system and are invoked
in response to requests for operating system service
that involve device-specific operations.
[0023] The device management code 147 is executed
by the processing unit (e.g., element 10 of Fig.1) to per-form
system level functions, including management of
forwarding entries in the distributed AR tables and man-agement
of forwarding entries in a master forwarding
table maintained in the memory of the processing unit.
The device management code 147 also includes rou-tines
for invoking device driver services, for example, to
query the ARU for traffic statistics and error information,
or to write updated configuration information to the
ARUs, including priority queuing information. Further,
the device management code 147 includes routines for
writing updated configuration information to the ARUs,
as discussed below in reference to Fig. 6. In one imple-mentation,
the device management code 147 is native
code, meaning that the device management code 147
is a compiled set of instructions that can be executed
directly by a processor in the processing unit to carry
out the device management functions.
[0024] In one embodiment, the device management
code 147 supports the operation of a Java client 160
that includes a number of Java applets, including a mon-itor
applet 157, a policy enforcement applet 159 and a
configuration applet 161. A Java applet is an instantia-tion
of a Java class that includes one or more methods
for self initialization (e.g., a constructor method called
"Applet()"), and one or more methods for communicat-ing
with a controlling application. Typically the control-ling
application for a Java applet is a web browser exe-cuted
on a general purpose computer. In the software
architecture shown in Fig. 5, however, a Java applica-tion
called Data Communication Interface (DCI) 153 is
the controlling application for the monitor, policy en-forcement
and configuration applets 157,159,161. The
DCI application 153 is executed by a Java virtual ma-chine
149 to manage the download of Java applets from
a network management server (NMS) 170. A library of
Java objects 155 is provided for use by the Java applets
157,159,161 and the DCI application 153.
[0025] In one implementation, the NMS 170 supplies
Java applets to the switch 17 in a hyper-text transfer
protocol (HTTP) data stream. Other protocols may also
be used. The constituent packets of the HTTP data
stream are addressed to the IP address of the switch
and are directed to the processing unit after being re-ceived
by the I/O unit coupled to the NMS 170. After
authenticating the HTTP data stream, the DCI applica-tion
153 stores the Java applets provided in the data
stream in the memory of the processing unit and exe-cutes
a method to invoke each applet. An applet is in-voked
by supplying the Java virtual machine 149 with
the address of the constructor method of the applet and
causing the Java virtual machine 149 to begin execution
of the applet code. Program code defining the Java vir-tual
machine 149 is executed to interpret the platform
independent byte codes of the Java applets 157, 159,
161 into native instructions that can be executed by a](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-5-320.jpg)
![EP 1 142 213 B1
9 10
5
10
15
20
25
30
35
40
45
50
55
6
processor within the processing unit.
[0026] According to one embodiment, the monitor ap-plet
157, policy enforcement applet 159 and configura-tion
applet 161 communicate with the device manage-ment
code 147 through a Java-native interface (JNI)
151. The JNI 151 is essentially an application program-ming
interface (API) and provides a set of methods that
can be invoked by the Java applets 157,159, 161 to
send messages and receive responses from the device
management code 147. In one implementation, the JNI
151 includes methods by which the monitor applet 157
can request the device management code 147 to gather
error information and traffic statistics from the device
hardware 141. The JNI 151 also includes methods by
which the configuration applet 161 can request the de-vice
management code 147 to write configuration infor-mation
to the device hardware 141. More specifically,
the JNI 151 includes a method by which the configura-tion
applet 161 can indicate that priority queuing should
be performed for specified classes of traffic, including,
but not limited to, the classes of traffic discussed above
in reference to Fig. 4. In this way, a user-coded config-uration
applet 161 may be executed by the Java virtual
machine 149 within the switch 17 to invoke a method in
the JNI 151 to request the device management code
147 to write information that assigns selected classes
of traffic to be queued in the priority egress queue. In
effect, the configuration applet 161 assigns virtual
queues defined by the selected classes of traffic to feed
into the priority egress queue.
[0027] Although a Java virtual machine 149 and Java
applets 157,159,161 have been described, other virtual
machines, interpreters and scripting languages may be
used in alternate embodiments. Also, as discussed be-low,
more or fewer Java applets may be used to perform
the monitoring, policy enforcement and configuration
functions in alternate embodiments.
[0028] Fig. 6 illustrates an example of dynamic as-signment
traffic classes to a priority queue. An exem-plary
network includes switches A and B coupled togeth-er
at physical ports 32 and 1, respectively. Suppose that
a network administrator or other user determines that
an important server 175 on port 2 of switch A requires
a relatively high quality of service (QoS), and that, at
least in switch B, the required QoS can be provided by
ensuring that at least 20% of the egress capacity of
switch B, port 1 is reserved for traffic destined to the
MAC address of the server 175. One way to ensure that
20% egress capacity is reserved to traffic destined for
the server 175 is to assign priority queuing for packets
destined to the MAC address of the server 175, but not
for other traffic. While such an assignment would ensure
priority egress to the server traffic, it also may result in
unnecessarily high bandwidth allocation to the server
175, potentially starving other important traffic or caus-ing
other important traffic to become bottlenecked be-hind
less important traffic in the best effort queue. For
example, suppose that there are at least two other MAC
address destinations, MAC address A and MAC ad-dress
B, to which the user desires to assign priority
queuing, so long as the egress capacity required by the
server-destined traffic is available. In that case, it would
be desirable to dynamically configure the MAC address
A and MAC address B traffic to be queued in either the
priority queue or the best effort queue according to ex-isting
traffic conditions. In at least one embodiment, this
is accomplished using monitor, policy enforcement and
configuration applets that have been downloaded to
switch B and which are executed in a Java client in
switch B as described above in reference to Fig. 5.
[0029] Fig. 6 includes exemplary pseudocode listings
of monitor, policy enforcement and configuration applets
178,179,180 that can be used to ensure that at least
20% of the egress capacity of switch B, port 1 is re-served
for traffic destined to the server 175, but without
unnecessarily denying priority queuing assignment to
traffic destined for MAC addresses A and B. After initial-ization,
the monitor applet 178 repeatedly measures of
the port 1 line utilization from the device hardware. In
one embodiment, the ARU in the I/O unit that manages
port 1 keeps a count of the number of packets destined
for particular egress ports, packets destined for partic-ular
MAC addresses, packets destined for particular
VLANS, packets that form part of a particular IP flow,
packets having a particular IP protocol, and so forth. The
ARU also tracks the number of errors associated with
these different classes of traffic, the number of packets
from each class of traffic that are dropped, and other
statistics. By determining the change in these different
statistics per unit time, a utilization factor may be gen-erated
that represents the percent utilization of the ca-pacity
of an egress port, an I/O unit or the overall switch.
Error rates and packet drop rates may also be generat-ed.
[0030] In one embodiment, the monitor applet 178
measures line utilization by invoking methods in the JNI
to read the port 1 line utilization resulting from traffic des-tined
for MAC address A and for MAC address B every
10 milliseconds.
[0031] The policy enforcement applet 179 includes
variables to hold the line utilization percentage of traffic
destined for MAC address A (A%), the line utilization
percentage of traffic destined for MAC address B (B%),
the queue assignment (i.e., priority or best effort) of traf-fic
destined for the server MAC address (QA_S), the
queue assignment of traffic destined for MAC address
A (QA_A) and the queue assignment of traffic destined
for MAC address B. Also, a constant, DELTA, is defined
to be 5% and the queue assignments for the MAC ad-dress
A, MAC address B and server MAC address traffic
are initially set to the priority queue.
[0032] The policy enforcement applet 179 also in-cludes
a forever loop in which the line utilization per-centages
A% and B% are obtained from the monitor ap-plet
178 and used to determine whether to change the
queue assignments QA_A and QA_B. If the MAC ad-](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-6-320.jpg)
![EP 1 142 213 B1
11 12
5
10
15
20
25
30
35
40
45
50
55
7
dress A traffic and the MAC address B traffic are both
assigned to the priority queue (the initial configuration)
and the sum of the line utilization percentages A% and
B% exceeds 80%, then less than 20% line utilization re-mains
for the server-destined traffic. In that event, the
MAC address A traffic is reassigned from the priority
queue to the best effort queue (code statement 181). If
the MAC address A traffic is assigned to the best effort
queue and the MAC address B traffic is assigned to the
priority queue, then the MAC address A traffic is reas-signed
to the priority queue if the sum of the line utiliza-tion
percentages A% and B% drops below 80% less
DELTA (code statement 183). The DELTA parameter
provides a deadband to prevent rapid changing of pri-ority
queue assignment.
[0033] If the MAC address A traffic is assigned to the
best effort queue and the MAC address B traffic is as-signed
to the priority queue and the line utilization per-centage
B% exceeds 80%, then less than 20% line uti-lization
remains for the server-destined traffic. Conse-quently,
the MAC address B traffic is reassigned from
the priority queue to the best effort queue (code state-ment
185). If the MAC address B traffic is assigned to
the best effort queue and the line utilization percentage
B% drops below 80% less DELTA, then the MAC ad-dress
B traffic is reassigned to the priority queue (code
statement 187). Although not specifically provided for in
the exemplary pseudocode listing of Fig. 6, the policy
enforcement applet 179 may treat the traffic destined for
the MAC A and MAC B addresses more symmetrically
by including additional statements to conditionally as-sign
traffic destined for MAC address A to the priority
queue, but not traffic destined for MAC address B. In the
exemplary pseudocode listing of Fig. 6, the policy en-forcement
applet 179 delays for 5 milliseconds at the
end of each pass through the forever loop before repeat-ing.
[0034] The configuration applet 180 includes varia-bles,
QA_A and QA_B, to hold the queue assignments
of the traffic destined for the MAC addresses A and B,
respectively. Variables LAST_QA_A and LAST_QA_B
are also provided to record the history (i.e., most recent
values) of the QA_A and QA_B values. The
LAST_QA_A and LAST_QA_B variables are initialized
to indicate that traffic destined for the MAC addresses
A and B is assigned to the priority queue.
[0035] Like the monitor and policy enforcement ap-plets
178,179, the configuration applet 180 includes a
forever loop in which a code sequence is executed fol-lowed
by a delay. In the exemplary listing of Fig. 6, the
first operation performed by the configuration applet 180
within the forever loop is to obtain the queue assign-ments
QA_A and QA_B from the policy enforcement ap-plet
179. If the queue assignment indicated by QA_A is
different from the queue assignment indicated by
LAST_QA_A, then a JNI method is invoked to request
the device code to reconfigure the queue assignment of
the traffic destined for MAC address A according to the
new QA_A value. The new QA_A value is then copied
into the LAST_QA_A variable so that subsequent queue
assignment changes are detected. If the queue assign-ment
indicated by QA_B is different from the queue as-signment
indicated by LAST_QA_B, then a JNI method
is invoked to request the device code to reconfigure the
queue assignment of the traffic destined for MAC ad-dress
B according to the new QA_B value. The new
QA_B value is then copied into the LAST_QA_B varia-ble
so that subsequent queue assignment changes are
detected. By this operation, and the operation of the
monitor and policy enforcement applets 178, 179, traffic
destined for the MAC addresses A and B is dynamically
assigned to the priority queue according to real-time
evaluations of the traffic conditions in the switch.
[0036] Although a three-applet implementation is il-lustrated
in Fig. 6, more or fewer applets may be used
in an alternate embodiment. For example, the functions
of the monitor, policy enforcement and configuration ap-plets
178,179,180 may be implemented in a single ap-plet.
Alternatively, multiple applets may be provided to
perform policy enforcement or other functions using dif-ferent
queue assignment criteria. For example, one pol-icy
enforcement applet may make priority queue assign-ments
based on destination MAC addresses, while an-other
policy enforcement applet makes priority queue
assignments based on error rates or line utilization of
higher level protocols. Multiple monitor applets or con-figuration
applets may similarly be provided.
[0037] Although queue assignment policy based on
destination MAC address is illustrated in Fig. 6, myriad
different queue assignment criteria may be used in other
embodiments. For example, instead of monitoring and
updating queue assignment based on traffic to destina-tion
MAC addresses, queue assignments may be up-dated
on other traffic patterns, including traffic to spec-ified
destination ports, traffic from specified source
ports, traffic from specified source MAC addresses, traf-fic
that forms part of a specified IP flow, traffic that is
transmitted using a specified protocol (e.g., HTTP, FTP
or other protocols) and so forth. Also, queue assign-ments
may be updated based on environmental condi-tions
such as time of day, changes in network configu-ration
(e.g., due to failure or congestion at other network
nodes), error rates, packet drop rates and so forth. Mon-itoring,
policy enforcement and configuration applets
that combine many or all of the above-described criteria
may be implemented to provide sophisticated traffic
handling capability in a packet forwarding device.
[0038] Although dynamic assignment of traffic class-es
to a priority egress queue has been emphasized, the
methods and apparatuses described herein may alter-natively
be used to assign traffic classes to a hierarchi-cal
set of queues anywhere in a packet forwarding de-vice
including, but not limited to, ingress queues and
queues associated with delivering and receiving pack-ets
from the switching fabric. Further, although the
queue assignment of traffic classes has been described](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-7-320.jpg)
![EP 1 142 213 B1
13 14
5
10
15
20
25
30
35
40
45
50
55
8
in terms of a pair of queues (priority and best effort), ad-ditional
queues in a prioritization hierarchy may be used
without departing from the spirit and scope of the
present invention.
[0039] In the foregoing specification, the invention
has been described with reference to specific exemplary
embodiments thereof. It will, however, be evident that
various modifications and changes may be made to the
specific exemplary embodiments without departing from
the broader spirit and scope of the invention as set forth
in the appended claims. Accordingly, the specification
and drawings are to be regarded in an illustrative rather
than a restrictive sense.
Claims
1. A method suitable for use within a packet forward-ing
device (17) characterised by the steps of
monitoring bandwidth consumption by one or
more types of packet traffic (25) received in the
packet forwarding device (17) comprising determin-ing
a measure of bandwidth consumption in the
packet forwarding device (17) due to traffic associ-ated
with a particular destination network address;
determining whether the bandwidth con-sumption
by the one or more types of packet traffic
(25) exceeds a threshold; and
automatically changing assignment of at least
one type of packet traffic of the one or more types
of packet traffic from a queue having a first priority
to a queue having a second priority if the bandwidth
consumption exceeds the threshold.
2. The method of claim 1 further comprising receiving
program code in the packet forwarding device (17)
after installation of the packet forwarding device
(17) in a packet communications network and
wherein said monitoring, determining and automat-ically
changing is implemented by the executing
program code.
3. The method of claim 2 wherein receiving the pro-gram
code comprises receiving a sequence of vir-tual
machine instructions and wherein executing
the program code comprises executing the se-quence
of virtual machine instructions using a vir-tual
machine included in the packet forwarding de-vice
(17).
4. The method of claim 3 wherein receiving the se-quence
of virtual machine instructions comprises
receiving a sequence of Java byte codes and
wherein executing the sequence of virtual machine
instructions using a virtual machine comprises ex-ecuting
the sequence of Java byte codes in a Java
virtual machine included in the packet forwarding
device.
5. The method of claim 1 wherein monitoring band-width
consumption by one or more types of packet
traffic (25) received in the packet forwarding device
(17) comprises determining a measure of band-width
consumption in the packet forwarding device
(17) due to traffic associated with a physical port on
the forwarding device (17).
6. The method of claim 1 wherein determining a meas-ure
of bandwidth consumption in the packet for-warding
device (17) due to traffic (25) associated
with the particular network address comprises de-termining
a measures of bandwidth consumption
due to traffic (25) associated with a particular media
access control, MAC, address.
7. The method of claim 1 wherein monitoring band-width
consumption by one or more types of packet
traffic received in the packet forwarding device (17)
comprises determining a measure of bandwidth
consumption in the packet forwarding device due to
traffic associated with a particular communications
protocol.
8. The method of claim 7 wherein determining a meas-ure
of bandwidth consumption in the packet for-warding
device (17) due to traffic (25) associated
with the particular communications protocol com-prises
determining a measure of bandwidth con-sumption
in the packet forwarding device (17) due
to traffic (25) associated with at least one of the fol-lowing
protocols: file transfer protocol, FTP, hyper-text
transfer protocol, HTTP, transmission control
protocol/internet protocol, TCP/IP.
9. A packet forwarding apparatus (17) comprising:
a plurality of input/output, I/O, ports to transmit
and receive packets of information;
first and second queues to buffer the packets
prior to transmission via one or more of the I/O
ports, packets (25) buffered in the first queue
having higher transmission priority than pack-ets
(25) buffered in the second queue, and
characterised by
queue assignment logic to assign the packets
(25) to be buffered in either the first queue or
the second queue according to a packet type
associated with each packet (25), each of the
packets (25) being associated with at least one
of a plurality of packet types; and
one or more agents (157) to monitor bandwidth
consumption by packets (25) associated with a
first packet type of the plurality of packet types,
monitoring bandwidth consumption comprising
determining a measure of bandwidth consump-tion
in the packet forwarding device (17) due to
traffic associated with a particular destination](https://image.slidesharecdn.com/ep1142213b1-141031121813-conversion-gate01/85/Dynamic-assignment-of-traffic-classes-to-a-priority-queue-in-a-packet-forwarding-device-8-320.jpg)
Dynamic assignment of traffic classes to a priority queue in a packet forwarding device
- 1. Europäisches Patentamt European Patent Office Office européen des brevets Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). Printed by Jouve, 75001 PARIS (FR) (19) EP 1 142 213 B1 *EP001142213B1* (11) EP 1 142 213 B1 (12) EUROPEAN PATENT SPECIFICATION (45) Date of publication and mention of the grant of the patent: 23.11.2005 Bulletin 2005/47 (21) Application number: 00901402.8 (22) Date of filing: 07.01.2000 (51) Int Cl.7: H04L 12/56, H04L 29/06 (86) International application number: PCT/US2000/000428 (87) International publication number: WO 2000/041368 (13.07.2000 Gazette 2000/28) (54) DYNAMIC ASSIGNMENT OF TRAFFIC CLASSES TO A PRIORITY QUEUE IN A PACKET FORWARDING DEVICE DYNAMISCHE ZUWEISUNG VERKEHRSKLASSEN AN EINER PRIORITÄTSWARTESCHLANGE IN EINER PAKETBEFÖRDERUNGSVORRICHTUNG AFFECTATION DYNAMIQUE DE CLASSES DE TRAFIC A UNE FILE D’ATTENTE PRIORITAIRE DANS UN DISPOSITIF DE REACHEMINEMENT DE PAQUETS (84) Designated Contracting States: DE FR GB (30) Priority: 08.01.1999 US 227389 (43) Date of publication of application: 10.10.2001 Bulletin 2001/41 (73) Proprietor: Nortel Networks Limited St.Laurent, Québec H4S 2A9 (CA) (72) Inventors: • LAVIAN, Tal, I. Sunnyvale, CA 94087 (US) • LAU, Stephen Milpitas, CA 95035 (US) (74) Representative: Mackenzie, Andrew Bryan et al Marks & Clerk 45 Grosvenor Road St. Albans, Hertfordshire AL1 3AW (GB) (56) References cited: EP-A- 0 872 979 WO-A-99/00949 • TENNENHOUSE D L ET AL: "A SURVEY OF ACTIVE NETWORK RESEARCH" IEEE COMMUNICATIONS MAGAZINE,US,IEEE SERVICE CENTER. PISCATAWAY, N.J, vol. 35, no. 1, 1 January 1997 (1997-01-01), pages 80-86, XP000683447 ISSN: 0163-6804
- 2. EP 1 142 213 B1 1 2 5 10 15 20 25 30 35 40 45 50 55 2 Description FIELD OF THE INVENTION [0001] The present invention relates to the field of tel-ecommunications, and more particularly to dynamic as-signment of traffic classes to queues having different pri-ority levels. BACKGROUND OF THE INVENTION [0002] The flow of packets through packet-switched networks is controlled by switches and routers that for-ward packets based on destination information included in the packets themselves. A typical switch or router in-cludes a number of input/output (I/O) modules connect-ed to a switching fabric, such as a crossbar or shared memory switch. In some switches and routers, the switching fabric is operated at a higher frequency than the transmission frequency of the I/O modules so that the switching fabric may deliver packets to an I/O mod-ule faster than the I/O module can output them to the network transmission medium. In these devices, pack-ets are usually queued in the I/O module to await trans-mission. [0003] One problem that may occur when packets are queued in the I/O module or elsewhere in a switch or router is that the queuing delay per packet varies de-pending on the amount of traffic being handled by the switch. Variable queuing delays tend to degrade data streams produced by real-time sampling (e.g., audio and video) because the original time delays between successive packets in the stream convey the sampling interval and are therefore needed to faithfully reproduce the source information. Another problem is that results from queuing packets in a switch or router is that data from a relatively important source, such as a shared server, may be impeded by data from less important sources, resulting in bottlenecks. [0004] One possible solution to this is described in In-ternational Application Number WO 99 00949. In this application a method whereby queues are prioritised is disclosed and the priority of a flow may be lowered. However, flows are packets forwarded within the subnet and therefore requiring no header modification. There-fore, a method for prioritising packets from/to sources/ destinations outside the subnet is required. SUMMARY OF THE INVENTION [0005] A method and apparatus for dynamic assign-ment of classes of traffic to a priority queue in accord-ance with Claims 1 and 9 respectively are disclosed. Bandwidth consumption by one or more types of packet traffic received in a packet forwarding device is moni-tored. The queue assignment of at least one type of packet traffic is automatically changed from a queue having a first priority to a queue having a second priority if the bandwidth consumption exceeds the threshold. [0006] Other features and advantages of the inven-tion will be apparent from the accompanying drawings and from the detailed description that follows below. BRIEF DESCRIPTION OF THE DRAWINGS [0007] The present invention is illustrated by way of example and not limitation in the figures of the accom-panying drawings in which like references indicate sim-ilar elements and in which: Fig.1 illustrates a packet forwarding device that can be used to implement embodiments of the present invention; Fig. 2A illustrates queue fill logic implemented by a queue manager in a quad interface device; Fig. 2B illustrates queue drain logic according to one embodiment; Fig: 3 illustrates the flow of a packet within the switch of Fig. 1; Fig. 4 illustrates storage of an entry in an address resolution table managed by an address resolution unit; Fig. 5 is a diagram of the software architecture of the switch of Fig. 1 according to one embodiment; and Fig. 6 illustrates an example of dynamic assignment of traffic classes to a priority queue. DETAILED DESCRIPTION [0008] A packet forwarding device in which selected classes of network traffic may be dynamically assigned for priority queuing is disclosed. In one embodiment, the packet forwarding device includes a Java virtual ma-chine for executing user-coded Java applets received from a network management server (NMS). A Java-to-native interface (JNI) is provided to allow the Java ap-plets to obtain error information and traffic statistics from the device hardware and to allow the Java applets to write configuration information to the device hardware, including information that indicates which classes of traffic should be queued in priority queues. The Java ap-plets implement user-specified traffic management pol-icies based on real-time evaluation of the error informa-tion and traffic statistics to provide dynamic control of the priority queuing assignments. These and other as-pects and advantages of the present invention are de-scribed below. [0009] Fig. 1 illustrates a packet forwarding device 17 that can be used to implement embodiments of the present invention. For the purposes of the present de-scription, the packet forwarding device 17 is assumed to be a switch that switches packets between ingress and egress ports based on media access control (MAC) addresses within the packets. In an alternate embodi-ment, the packet forwarding device 17 may be a router
- 3. EP 1 142 213 B1 3 4 5 10 15 20 25 30 35 40 45 50 55 3 that routes packets according to destination internet protocol (IP) addresses or a routing switch that performs both MAC address switching and IP address routing. The techniques and structures disclosed herein are ap-plicable generally to a device that forwards packets in a packet switching network. Also, the term packet is used broadly herein to refer to a fixed-length cell, a variable length frame or any other information structure that is self-contained as to its destination address. [0010] The switch 17 includes a switching fabric 12 coupled to a plurality of I/O units (only I/O units 1 and 16 are depicted) and to a processing unit 10. The processing unit includes at least a processor 31 (which may be a microprocessor, digital signal processor or mi-crocontroller) coupled to a memory 32 via a bus 33. In one embodiment, each I/O unit 1, 16 includes four phys-ical ports P1-P4 coupled to a quad media access con-troller (QMAC) 14A, 14B via respective transceiver in-terface units 21A-24A, 21B-24B. Each I/O unit 1, 16 also includes a quad interface device (QID) 16A, 16B, an ad-dress resolution unit (ARU) 15A, 15B and a memory 18A,18B, interconnected as shown in Fig. 1. Preferably, the switch 17 is modular with at least the I/O units 1, 16 being implemented on port cards (not shown) that can be installed in a backplane (not shown) of the switch 17. In one implementation, each port card includes four I/O units and therefore supports up to 16 physical ports. The switch backplane includes slots for up to six port cards, so that the switch 17 can be scaled according to cus-tomer needs to support between 16 and 96 physical ports. In alternate embodiments, each I/O unit 1, 16 may support more or fewer physical ports, each port card may support more or fewer I/O units 1, 16 and the switch 17 may support more or fewer port cards. For example, the I/O unit 1 shown in Fig.1 may be used to support four 10baseT transmission lines (i.e.,10 Mbps (mega-bit per second), twisted-pair) or four 100baseF transmis-sion lines (100 Mbps, fiber optic), while a different I/O unit (not shown) may be used to support a single 1000baseF transmission line (1000 Mbps, fiber optic). Nothing disclosed herein should be construed as limit-ing embodiments of the present invention to use with a particular transmission medium, I/O unit, port card or chassis configuration. [0011] Still referring to Fig.1, when a packet 25 is re-ceived on physical port P1, it is supplied to the corre-sponding physical transceiver 21A which performs any necessary signal conditioning (e.g., optical to electrical signal conversion) and then forwards the packet 25 to the QMAC 14A. The QMAC 14A buffers packets re-ceived from the four physical transceivers 21A-24A as necessary, forwarding one packet at a time to the QID 16A. Receive logic within the QID 16A notifies the ARU 15A that the packet 25 has been received. The ARU computes a table index based on the destination MAC address within the packet 25 and uses the index to iden-tify an entry in a forwarding table that corresponds to the destination MAC address. In packet forwarding devices that operate on different protocol layers of the packet (e. g., routers), a forwarding table may be indexed based on other destination information contained within the packet. [0012] According to one embodiment, the forwarding table entry identified based on the destination MAC ad-dress indicates the switch egress port to which the pack-et 25 is destined and also whether the packet is part of a MAC-address based virtual local area network (VLAN), or a port-based VLAN. (As an aside, a VLAN is a logical grouping of MAC addresses (a MAC-address-based VLAN) or a logical grouping of physical ports (a port-based VLAN).) The forwarding table entry further indicates whether the packet 25 is to be queued in a priority queue in the I/O unit that contains the destination port. As discussed below, priority queuing may be spec-ified based on a number of conditions, including, but not limited to, whether the packet is part of a particular IP flow, or whether the packet is destined for a particular port, VLAN or MAC address. [0013] According to one embodiment, the QID 16A, 16B segments the packet 25 into a plurality of fixed-length cells 26 for transmission through the switching fabric 12. Each cell includes a header 28 that identifies it as a constituent of the packet 25 and that identifies the destination port for the cell (and therefore for the packet 25). The header 28 of each cell also includes a bit 29 indicating whether the cell is the beginning cell of a packet and also a bit 30 indicating whether the packet 25 to which the cell belongs is to be queued in a priority queue or a best effort queue on the destined I/O unit. [0014] The switching fabric 12 forwards each cell to the I/O unit indicated by the cell header 28. In the ex-emplary data flow shown in Fig.1, the constituent cells 26 of the packet 25 are assumed to be forwarded to I/O unit 16 where they are delivered to transmit logic within the QID 16B. The transmit logic in the QID 16B includes a queue manager (not shown) that maintains a priority queue and a best effort queue in the memory 18B. In one embodiment, the memory 18B is resolved into a pool of buffers, each large enough to hold a complete packet. When the beginning cell of the packet 25 is de-livered to the QID 16B, the queue manager obtains a buffer from the pool and appends the buffer to either the priority queue or the best effort queue according to whether the priority bit 30 is set in the beginning cell. In one embodiment, the priority queue and the best effort queue are each implemented by a linked list, with the queue manager maintaining respective pointers to the head and tail of each linked list. Entries are added to the tail of the queue list by advancing the tail pointer to point to a newly allocated buffer that has been appended to the linked list, and entries are popped off the head of the queue by advancing the head pointer to point to the next buffer in the linked list and returning the spent buffer to the pool. [0015] After a buffer is appended to either the priority queue or the best effort queue, the beginning cell and
- 4. EP 1 142 213 B1 5 6 5 10 15 20 25 30 35 40 45 50 55 4 subsequent cells are used to reassemble the packet 25 within the buffer. Eventually the packet 25 is popped off the head of the queue and delivered to an egress port via the QMAC 14B and the physical transceiver (e.g., 23B) in an egress operation. This is shown by way of example in Fig. 1 by the egress of packet 25 from phys-ical port P3 of I/O unit 16. [0016] Fig. 2A illustrates queue fill logic implemented by the queue manager in the QID. Starting at block 51, a cell is received in the QID from the switching fabric. The beginning cell bit in the cell header is inspected at decision block 53 to determine if the cell is the beginning cell of a packet. If so, the priority bit in the cell header is inspected at decision block 55 to determine whether to allocate an entry in the priority queue or the best effort queue for packet reassembly. If the priority bit is set, an entry in the priority queue is allocated at block 57 and the priority queue entry is associated with the portion of the cell header that identifies the cell as a constituent of a particular packet at block 59. If the priority bit in the cell header is not set, then an entry in the best effort queue is allocated at block 61 and the best effort queue entry is associated with the portion of the cell header that identifies the cell as a constituent of a particular packet at block 63. [0017] Returning to decision block 53, if the beginning cell bit in the cell header is not set, then the queue entry associated with the cell header is identified at block 65. The association between the cell header and the queue entry identified at block 65 was established earlier in ei-ther block 59 or block 63. Also, identification of the queue entry in block 65 may include inspection of the priority bit in the cell to narrow the identification effort to either the priority queue or the best effort queue. In block 67, the cell is combined with the preceding cell in the queue entry in a packet reassembly operation. If the re-assembly operation in block 67 results in a completed packet (decision block 69), then the packet is marked as ready for transmission in block 71. In one embodi-ment, the packet is marked by setting a flag associated with the queue entry in which the packet has been re-assembled. Other techniques for indicating that a pack-et is ready for transmission may be used in alternate embodiments. [0018] Fig. 2B illustrates queue drain logic according to one embodiment. At decision block 75, the entry at the head of the priority queue is inspected to determine if it contains a packet ready for transmission. If so, the packet is transmitted at block 77 and the corresponding priority queue entry is popped off the head of the priority queue and deallocated at block 79. If a ready packet is not present at the head of the priority queue, then the entry at the head of the best effort queue is inspected at decision block 81. If a packet is ready at the head of the best effort queue, it is transmitted at block 83 and the corresponding best effort queue entry is popped off the head of the best effort queue and deallocated in block 85. Note that, in the embodiment illustrated in Fig. 2B, packets are drained from the best effort queue only after the priority queue has been emptied. In alternate embodiments, a timer, counter or similar logic element may be used to ensure that the best effort queue 105 is serviced at least every so often or at least after every N number of packets are transmitted from the priority queue, thereby ensuring at least a threshold level of service to best effort queue. [0019] Fig. 3 illustrates the flow of a packet within the switch 17 of Fig. 1. A packet is received in the switch at block 91 and used to identify an entry in a forwarding table called the address resolution (AR) table at block 93. At decision block 95, a priority bit in the AR table entry is inspected to determine whether the packet be-longs to a class of traffic that has been selected for pri-ority queuing. If the priority bit is set, the packet is seg-mented into cells having respective priority bits set in their headers in block 97. If the priority bit is not set, the packet is segmented into cells having respective priority bits cleared their cell headers in block 99. The constitu-ent cells of each packet are forwarded to an egress I/O unit by the switching fabric. In the egress I/O unit, the priority bit of each cell is inspected (decision block 101) and used to direct the cell to an entry in either the priority queue 103 or the best effort queue 105 where it is com-bined with other cells to reassemble the packet. [0020] Fig. 4 illustrates storage of an entry in the ad-dress resolution (AR) table managed by the ARU. In one embodiment, the AR table is maintained in a high speed static random access memory (SRAM) coupled to the ARU. Alternatively, the AR table may be included in a memory within an application-specific integrated circuit (ASIC) that includes the ARU. Generally, the ARU stores an entry in the AR table in response to packet forwarding information from the processing unit. The processing unit supplies packet forwarding information to be stored in each AR table in the switch whenever a new association between a destination address and a switch egress port is learned. In one embodiment, an address-to-port association is learned by transmitting a packet that has an unknown egress port assignment on each of the egress ports of the switch and associating the destination address of the packet with the egress port at which an acknowledgment is received. Upon learning the association between the egress port and the destination address, the processing unit issues for-warding information that includes, for example, an iden-tifier of the newly associated egress port, the destination MAC address, an identifier of the VLAN associated with the MAC address (if any), an identifier of the VLAN as-sociated with the egress port (if any), the destination IP address, the destination IP port (e.g., transmission con-trol protocol (TCP), universal device protocol (UDP) or other IP port) and the IP protocol (e.g., HTTP, FTP or other IP protocol). The source IP address, source IP port and source IP protocol may also be supplied to fully identify an end-to-end IP flow. [0021] Referring to Fig. 4, forwarding information 110
- 5. EP 1 142 213 B1 7 8 5 10 15 20 25 30 35 40 45 50 55 5 is received from the processing unit at block 115. At block 117, the ARU stores the forwarding information in an AR table entry. At decision block 119, the physical egress port identifier stored in the AR table entry is com-pared against priority configuration information to deter-mine if packets destined for the egress port have been selected for priority egress queuing. If so, the priority bit is set in the AR table entry in block 127. Thereafter, in-coming packets that index the newly stored table entry will be queued in the priority queue to await transmis-sion. If packets destined for the egress port have not been selected for priority queuing, then at decision block 121 the MAC address stored in the AR table entry is compared against the priority configuration information to determine if packets destined for the MAC address have been selected for priority egress queuing. If so, the priority bit is set in the AR table entry in block 127. If packets destined for the MAC address have not been selected for priority egress queuing, then at decision block 123 the VLAN identifier stored in the AR table en-try (if present) is compared against the priority configu-ration information to determine if packets destined for the VLAN have been selected for priority egress queu-ing. If so, the priority bit is set in the AR table entry in block 127. If packets destined for the VLAN have not been selected for priority egress queuing, then at block 125 the IP flow identified by the IP address, IP port and IP protocol in the AR table is compared against the pri-ority configuration information to determine if packets that form part of the IP flow have been selected for pri-ority egress queuing. If so, the priority bit is set in the AR table entry, otherwise the priority bit is not set. Yet other criteria may be considered in assigning priority queuing in alternate embodiments. For example, priority queuing may be specified for a particular IP protocol (e. g., FTP, HTTP). Also, the ingress port, source MAC ad-dress or source VLAN of a packet may also be used to determine whether to queue the packet in the priority egress packet. More specifically, in one embodiment, priority or best effort queuing of unicast traffic is deter-mined based on destination parameters (e.g., egress port, destination MAC address or destination IP ad-dress), while priority or best effort queuing of multicast traffic is determined based on source parameters (e.g., ingress port, source MAC address or source IP ad-dress). [0022] Fig. 5 is a diagram of the software architecture of the switch 17 of Fig.1 according to one embodiment. An operating system 143 and device drivers 145 are provided to interface with the device hardware 141. For example, device drivers are provided to write configura-tion information and AR storage entries to the ARUs in respective I/O units. Also, the operating system 143 per-forms memory management functions and other system services in response to requests from higher level soft-ware. Generally, the device drivers 145 extend the serv-ices provided by the operating system and are invoked in response to requests for operating system service that involve device-specific operations. [0023] The device management code 147 is executed by the processing unit (e.g., element 10 of Fig.1) to per-form system level functions, including management of forwarding entries in the distributed AR tables and man-agement of forwarding entries in a master forwarding table maintained in the memory of the processing unit. The device management code 147 also includes rou-tines for invoking device driver services, for example, to query the ARU for traffic statistics and error information, or to write updated configuration information to the ARUs, including priority queuing information. Further, the device management code 147 includes routines for writing updated configuration information to the ARUs, as discussed below in reference to Fig. 6. In one imple-mentation, the device management code 147 is native code, meaning that the device management code 147 is a compiled set of instructions that can be executed directly by a processor in the processing unit to carry out the device management functions. [0024] In one embodiment, the device management code 147 supports the operation of a Java client 160 that includes a number of Java applets, including a mon-itor applet 157, a policy enforcement applet 159 and a configuration applet 161. A Java applet is an instantia-tion of a Java class that includes one or more methods for self initialization (e.g., a constructor method called "Applet()"), and one or more methods for communicat-ing with a controlling application. Typically the control-ling application for a Java applet is a web browser exe-cuted on a general purpose computer. In the software architecture shown in Fig. 5, however, a Java applica-tion called Data Communication Interface (DCI) 153 is the controlling application for the monitor, policy en-forcement and configuration applets 157,159,161. The DCI application 153 is executed by a Java virtual ma-chine 149 to manage the download of Java applets from a network management server (NMS) 170. A library of Java objects 155 is provided for use by the Java applets 157,159,161 and the DCI application 153. [0025] In one implementation, the NMS 170 supplies Java applets to the switch 17 in a hyper-text transfer protocol (HTTP) data stream. Other protocols may also be used. The constituent packets of the HTTP data stream are addressed to the IP address of the switch and are directed to the processing unit after being re-ceived by the I/O unit coupled to the NMS 170. After authenticating the HTTP data stream, the DCI applica-tion 153 stores the Java applets provided in the data stream in the memory of the processing unit and exe-cutes a method to invoke each applet. An applet is in-voked by supplying the Java virtual machine 149 with the address of the constructor method of the applet and causing the Java virtual machine 149 to begin execution of the applet code. Program code defining the Java vir-tual machine 149 is executed to interpret the platform independent byte codes of the Java applets 157, 159, 161 into native instructions that can be executed by a
- 6. EP 1 142 213 B1 9 10 5 10 15 20 25 30 35 40 45 50 55 6 processor within the processing unit. [0026] According to one embodiment, the monitor ap-plet 157, policy enforcement applet 159 and configura-tion applet 161 communicate with the device manage-ment code 147 through a Java-native interface (JNI) 151. The JNI 151 is essentially an application program-ming interface (API) and provides a set of methods that can be invoked by the Java applets 157,159, 161 to send messages and receive responses from the device management code 147. In one implementation, the JNI 151 includes methods by which the monitor applet 157 can request the device management code 147 to gather error information and traffic statistics from the device hardware 141. The JNI 151 also includes methods by which the configuration applet 161 can request the de-vice management code 147 to write configuration infor-mation to the device hardware 141. More specifically, the JNI 151 includes a method by which the configura-tion applet 161 can indicate that priority queuing should be performed for specified classes of traffic, including, but not limited to, the classes of traffic discussed above in reference to Fig. 4. In this way, a user-coded config-uration applet 161 may be executed by the Java virtual machine 149 within the switch 17 to invoke a method in the JNI 151 to request the device management code 147 to write information that assigns selected classes of traffic to be queued in the priority egress queue. In effect, the configuration applet 161 assigns virtual queues defined by the selected classes of traffic to feed into the priority egress queue. [0027] Although a Java virtual machine 149 and Java applets 157,159,161 have been described, other virtual machines, interpreters and scripting languages may be used in alternate embodiments. Also, as discussed be-low, more or fewer Java applets may be used to perform the monitoring, policy enforcement and configuration functions in alternate embodiments. [0028] Fig. 6 illustrates an example of dynamic as-signment traffic classes to a priority queue. An exem-plary network includes switches A and B coupled togeth-er at physical ports 32 and 1, respectively. Suppose that a network administrator or other user determines that an important server 175 on port 2 of switch A requires a relatively high quality of service (QoS), and that, at least in switch B, the required QoS can be provided by ensuring that at least 20% of the egress capacity of switch B, port 1 is reserved for traffic destined to the MAC address of the server 175. One way to ensure that 20% egress capacity is reserved to traffic destined for the server 175 is to assign priority queuing for packets destined to the MAC address of the server 175, but not for other traffic. While such an assignment would ensure priority egress to the server traffic, it also may result in unnecessarily high bandwidth allocation to the server 175, potentially starving other important traffic or caus-ing other important traffic to become bottlenecked be-hind less important traffic in the best effort queue. For example, suppose that there are at least two other MAC address destinations, MAC address A and MAC ad-dress B, to which the user desires to assign priority queuing, so long as the egress capacity required by the server-destined traffic is available. In that case, it would be desirable to dynamically configure the MAC address A and MAC address B traffic to be queued in either the priority queue or the best effort queue according to ex-isting traffic conditions. In at least one embodiment, this is accomplished using monitor, policy enforcement and configuration applets that have been downloaded to switch B and which are executed in a Java client in switch B as described above in reference to Fig. 5. [0029] Fig. 6 includes exemplary pseudocode listings of monitor, policy enforcement and configuration applets 178,179,180 that can be used to ensure that at least 20% of the egress capacity of switch B, port 1 is re-served for traffic destined to the server 175, but without unnecessarily denying priority queuing assignment to traffic destined for MAC addresses A and B. After initial-ization, the monitor applet 178 repeatedly measures of the port 1 line utilization from the device hardware. In one embodiment, the ARU in the I/O unit that manages port 1 keeps a count of the number of packets destined for particular egress ports, packets destined for partic-ular MAC addresses, packets destined for particular VLANS, packets that form part of a particular IP flow, packets having a particular IP protocol, and so forth. The ARU also tracks the number of errors associated with these different classes of traffic, the number of packets from each class of traffic that are dropped, and other statistics. By determining the change in these different statistics per unit time, a utilization factor may be gen-erated that represents the percent utilization of the ca-pacity of an egress port, an I/O unit or the overall switch. Error rates and packet drop rates may also be generat-ed. [0030] In one embodiment, the monitor applet 178 measures line utilization by invoking methods in the JNI to read the port 1 line utilization resulting from traffic des-tined for MAC address A and for MAC address B every 10 milliseconds. [0031] The policy enforcement applet 179 includes variables to hold the line utilization percentage of traffic destined for MAC address A (A%), the line utilization percentage of traffic destined for MAC address B (B%), the queue assignment (i.e., priority or best effort) of traf-fic destined for the server MAC address (QA_S), the queue assignment of traffic destined for MAC address A (QA_A) and the queue assignment of traffic destined for MAC address B. Also, a constant, DELTA, is defined to be 5% and the queue assignments for the MAC ad-dress A, MAC address B and server MAC address traffic are initially set to the priority queue. [0032] The policy enforcement applet 179 also in-cludes a forever loop in which the line utilization per-centages A% and B% are obtained from the monitor ap-plet 178 and used to determine whether to change the queue assignments QA_A and QA_B. If the MAC ad-
- 7. EP 1 142 213 B1 11 12 5 10 15 20 25 30 35 40 45 50 55 7 dress A traffic and the MAC address B traffic are both assigned to the priority queue (the initial configuration) and the sum of the line utilization percentages A% and B% exceeds 80%, then less than 20% line utilization re-mains for the server-destined traffic. In that event, the MAC address A traffic is reassigned from the priority queue to the best effort queue (code statement 181). If the MAC address A traffic is assigned to the best effort queue and the MAC address B traffic is assigned to the priority queue, then the MAC address A traffic is reas-signed to the priority queue if the sum of the line utiliza-tion percentages A% and B% drops below 80% less DELTA (code statement 183). The DELTA parameter provides a deadband to prevent rapid changing of pri-ority queue assignment. [0033] If the MAC address A traffic is assigned to the best effort queue and the MAC address B traffic is as-signed to the priority queue and the line utilization per-centage B% exceeds 80%, then less than 20% line uti-lization remains for the server-destined traffic. Conse-quently, the MAC address B traffic is reassigned from the priority queue to the best effort queue (code state-ment 185). If the MAC address B traffic is assigned to the best effort queue and the line utilization percentage B% drops below 80% less DELTA, then the MAC ad-dress B traffic is reassigned to the priority queue (code statement 187). Although not specifically provided for in the exemplary pseudocode listing of Fig. 6, the policy enforcement applet 179 may treat the traffic destined for the MAC A and MAC B addresses more symmetrically by including additional statements to conditionally as-sign traffic destined for MAC address A to the priority queue, but not traffic destined for MAC address B. In the exemplary pseudocode listing of Fig. 6, the policy en-forcement applet 179 delays for 5 milliseconds at the end of each pass through the forever loop before repeat-ing. [0034] The configuration applet 180 includes varia-bles, QA_A and QA_B, to hold the queue assignments of the traffic destined for the MAC addresses A and B, respectively. Variables LAST_QA_A and LAST_QA_B are also provided to record the history (i.e., most recent values) of the QA_A and QA_B values. The LAST_QA_A and LAST_QA_B variables are initialized to indicate that traffic destined for the MAC addresses A and B is assigned to the priority queue. [0035] Like the monitor and policy enforcement ap-plets 178,179, the configuration applet 180 includes a forever loop in which a code sequence is executed fol-lowed by a delay. In the exemplary listing of Fig. 6, the first operation performed by the configuration applet 180 within the forever loop is to obtain the queue assign-ments QA_A and QA_B from the policy enforcement ap-plet 179. If the queue assignment indicated by QA_A is different from the queue assignment indicated by LAST_QA_A, then a JNI method is invoked to request the device code to reconfigure the queue assignment of the traffic destined for MAC address A according to the new QA_A value. The new QA_A value is then copied into the LAST_QA_A variable so that subsequent queue assignment changes are detected. If the queue assign-ment indicated by QA_B is different from the queue as-signment indicated by LAST_QA_B, then a JNI method is invoked to request the device code to reconfigure the queue assignment of the traffic destined for MAC ad-dress B according to the new QA_B value. The new QA_B value is then copied into the LAST_QA_B varia-ble so that subsequent queue assignment changes are detected. By this operation, and the operation of the monitor and policy enforcement applets 178, 179, traffic destined for the MAC addresses A and B is dynamically assigned to the priority queue according to real-time evaluations of the traffic conditions in the switch. [0036] Although a three-applet implementation is il-lustrated in Fig. 6, more or fewer applets may be used in an alternate embodiment. For example, the functions of the monitor, policy enforcement and configuration ap-plets 178,179,180 may be implemented in a single ap-plet. Alternatively, multiple applets may be provided to perform policy enforcement or other functions using dif-ferent queue assignment criteria. For example, one pol-icy enforcement applet may make priority queue assign-ments based on destination MAC addresses, while an-other policy enforcement applet makes priority queue assignments based on error rates or line utilization of higher level protocols. Multiple monitor applets or con-figuration applets may similarly be provided. [0037] Although queue assignment policy based on destination MAC address is illustrated in Fig. 6, myriad different queue assignment criteria may be used in other embodiments. For example, instead of monitoring and updating queue assignment based on traffic to destina-tion MAC addresses, queue assignments may be up-dated on other traffic patterns, including traffic to spec-ified destination ports, traffic from specified source ports, traffic from specified source MAC addresses, traf-fic that forms part of a specified IP flow, traffic that is transmitted using a specified protocol (e.g., HTTP, FTP or other protocols) and so forth. Also, queue assign-ments may be updated based on environmental condi-tions such as time of day, changes in network configu-ration (e.g., due to failure or congestion at other network nodes), error rates, packet drop rates and so forth. Mon-itoring, policy enforcement and configuration applets that combine many or all of the above-described criteria may be implemented to provide sophisticated traffic handling capability in a packet forwarding device. [0038] Although dynamic assignment of traffic class-es to a priority egress queue has been emphasized, the methods and apparatuses described herein may alter-natively be used to assign traffic classes to a hierarchi-cal set of queues anywhere in a packet forwarding de-vice including, but not limited to, ingress queues and queues associated with delivering and receiving pack-ets from the switching fabric. Further, although the queue assignment of traffic classes has been described
- 8. EP 1 142 213 B1 13 14 5 10 15 20 25 30 35 40 45 50 55 8 in terms of a pair of queues (priority and best effort), ad-ditional queues in a prioritization hierarchy may be used without departing from the spirit and scope of the present invention. [0039] In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made to the specific exemplary embodiments without departing from the broader spirit and scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. Claims 1. A method suitable for use within a packet forward-ing device (17) characterised by the steps of monitoring bandwidth consumption by one or more types of packet traffic (25) received in the packet forwarding device (17) comprising determin-ing a measure of bandwidth consumption in the packet forwarding device (17) due to traffic associ-ated with a particular destination network address; determining whether the bandwidth con-sumption by the one or more types of packet traffic (25) exceeds a threshold; and automatically changing assignment of at least one type of packet traffic of the one or more types of packet traffic from a queue having a first priority to a queue having a second priority if the bandwidth consumption exceeds the threshold. 2. The method of claim 1 further comprising receiving program code in the packet forwarding device (17) after installation of the packet forwarding device (17) in a packet communications network and wherein said monitoring, determining and automat-ically changing is implemented by the executing program code. 3. The method of claim 2 wherein receiving the pro-gram code comprises receiving a sequence of vir-tual machine instructions and wherein executing the program code comprises executing the se-quence of virtual machine instructions using a vir-tual machine included in the packet forwarding de-vice (17). 4. The method of claim 3 wherein receiving the se-quence of virtual machine instructions comprises receiving a sequence of Java byte codes and wherein executing the sequence of virtual machine instructions using a virtual machine comprises ex-ecuting the sequence of Java byte codes in a Java virtual machine included in the packet forwarding device. 5. The method of claim 1 wherein monitoring band-width consumption by one or more types of packet traffic (25) received in the packet forwarding device (17) comprises determining a measure of band-width consumption in the packet forwarding device (17) due to traffic associated with a physical port on the forwarding device (17). 6. The method of claim 1 wherein determining a meas-ure of bandwidth consumption in the packet for-warding device (17) due to traffic (25) associated with the particular network address comprises de-termining a measures of bandwidth consumption due to traffic (25) associated with a particular media access control, MAC, address. 7. The method of claim 1 wherein monitoring band-width consumption by one or more types of packet traffic received in the packet forwarding device (17) comprises determining a measure of bandwidth consumption in the packet forwarding device due to traffic associated with a particular communications protocol. 8. The method of claim 7 wherein determining a meas-ure of bandwidth consumption in the packet for-warding device (17) due to traffic (25) associated with the particular communications protocol com-prises determining a measure of bandwidth con-sumption in the packet forwarding device (17) due to traffic (25) associated with at least one of the fol-lowing protocols: file transfer protocol, FTP, hyper-text transfer protocol, HTTP, transmission control protocol/internet protocol, TCP/IP. 9. A packet forwarding apparatus (17) comprising: a plurality of input/output, I/O, ports to transmit and receive packets of information; first and second queues to buffer the packets prior to transmission via one or more of the I/O ports, packets (25) buffered in the first queue having higher transmission priority than pack-ets (25) buffered in the second queue, and characterised by queue assignment logic to assign the packets (25) to be buffered in either the first queue or the second queue according to a packet type associated with each packet (25), each of the packets (25) being associated with at least one of a plurality of packet types; and one or more agents (157) to monitor bandwidth consumption by packets (25) associated with a first packet type of the plurality of packet types, monitoring bandwidth consumption comprising determining a measure of bandwidth consump-tion in the packet forwarding device (17) due to traffic associated with a particular destination
- 9. EP 1 142 213 B1 15 16 5 10 15 20 25 30 35 40 45 50 55 9 network address, and to automatically change assignment of packets (25) associated with the first packet type from the first queue to the sec-ond queue if bandwidth consumption of pack-ets (25) associated with the first packet type ex-ceeds a threshold. 10. The apparatus (17) of claim 9 further comprising: a processing unit (10) coupled to the plurality of I/O ports, the processing unit including a memory (32) and a processor (31); and a data communications interface to receive pro-gram code in the memory (32) of processing unit (10) after installation of the packet forward-ing device (17) in a packet communications net-work and wherein the one or more agents are implemented by execution of the program code in the processor (31) of the processing unit (10). 11. The apparatus (17) of claim 10 wherein the packet forwarding device (17) further comprises program code that, when executed by the processing unit (10) implements a virtual machine, and wherein the program code received via the data communica-tions interface comprises a sequence of instruc-tions that is executed by the virtual machine to im-plement one or more agents. 12. The apparatus (17) of claim 11 wherein the program code received via the data communications inter-face includes a sequence of Java byte codes and wherein the virtual machine is a Java virtual ma-chine. 13. The apparatus (17) of claim 9 wherein the first pack-et type comprises packets (25) associated with a particular one of the I/O ports. 14. The apparatus (17) of claim 9 wherein the first pack-et type comprises packets (25) associated with a particular network address. 15. The apparatus (17) of claim 14 wherein the partic-ular network address is a particular media access control, MAC, address. 16. The apparatus (17) of claim 9 wherein the first pack-et type comprises packets (25) associated with a particular communications protocol. 17. The apparatus (17) of claim 16 wherein the partic-ular communications protocol is a hyper-text trans-fer protocol, HTTP. 18. The apparatus (17) of claim 16 wherein the partic-ular communications protocol is a file transfer pro-tocol, FTP. 19. A communications network comprising a packet for-warding device (17), the packet forwarding device (17) including: a plurality of input/output, I/O, ports to transmit and receive packets (25) of information from one or more other devices in the communica-tions network; first and second queues to buffer the packets (25) prior to transmission via one or more of the I/O ports, packets (25) buffered in the first queue having higher transmission priority than packets (25) buffered in the second queue; and characterised by queue assignment logic to assign the packets (25) to be buffered in either the first queue or the second queue according to a packet type associated with each packet (25), each of the packets (25) being associated with at least one of a plurality of packet types; and one or more agents (157) to monitor bandwidth consumption by packets (25) associated with a first packet type of the plurality of packet types, monitoring bandwidth consumption comprising determining a measure of bandwidth consump-tion in the packet forwarding device (17) due to traffic associated with a particular destination network address and to automatically change assignment of packets (25) associated with the first packet type from the first queue to the sec-ond queue if bandwidth consumption of pack-ets (25) associated with the first packet type ex-ceeds a threshold. 20. The communications network of claim 19 wherein the packet forwarding device (17) further includes: a processing unit (10) coupled to the plurality of I/O ports, the processing unit (10) including a memory (32) and a processor (31); and a data communications interface to receive pro-gram code in the memory (32) of processing unit (10) after installation of the packet forward-ing device (17) in the communications network and wherein the one or more agents are imple-mented by execution of the program code in the processor (31) of the processing unit (10). 21. The communications network of claim 20 wherein the packet forwarding device (17) further includes program code that, when executed by the process-ing unit (10) implements a virtual machine, and wherein the program code received via the data communications interface includes a sequence of instructions that is executed by the virtual machine to implement one or more agents.
- 10. EP 1 142 213 B1 17 18 5 10 15 20 25 30 35 40 45 50 55 10 Patentansprüche 1. Verfahren, das zur Verwendung in einer Paket-Wei-terleitungseinrichtung (17) geeignet ist, gekenn-zeichnet durch die folgenden Schritte: Überwachen des Bandbreitenverbrauchs durch einen oder mehrere Typen von in der Pa-ket- Weiterleitungseinrichtung (17) empfange-nem Paketverkehr (25) unter Einschluss der Feststellung einer Messung des Bandbreiten-verbrauchs in der Paket-Weiterleitungseinrich-tung (17) aufgrund von Verkehr, der einer be-stimmten Ziel-Netzwerkadresse zugeordnet ist; Feststellen, ob der Bandbreitenverbrauch durch eine oder mehrere Typen des Paketver-kehrs (25) einen Schwellenwert übersteigt; und automatisches Ändern der Zuordnung von zu-mindest einem Typ des Paketverkehrs des ei-nen Typs oder der mehreren Typen von Paket-verkehr von einer Warteschlange, die eine er-ste Priorität hat, zu einerWarteschlange, die ei-ne zweite Priorität hat, wenn der Bandbreifen-verbrauch den Schwellenwert übersteigt. 2. Verfahren nach Anspruch 1, das weiterhin den Empfang von Programmcode in der Paket-Weiter-leitungseinrichtung (17) nach der Installation der Paket-Weiterleitungseinrichtung (17) in einem Pa-ket- KommunikationsNetzwerk umfasst, und bei dem das Überwachen, Feststellen und automati-sche Ändern durch die Ausführung des Programm-codes realisiert wird. 3. Verfahren nach Anspruch 2, bei dem das Empfan-gen des Programmcodes das Empfangen einer Fol-ge von virtuellen Maschinenbefehlen umfasst, und bei dem die Ausführung des Programmcodes die Ausführung der Folge von virtuellen Maschinenbe-fehlen unter Verwendung einer virtuellen Maschine umfasst, die in der PaketWeiterteitungseinrichtung (17) enthalten ist. 4. Verfahren nach Anspruch 3, bei dem der Empfang der Folge von virtuellen Maschinenbefehlen den Empfang einer Folge von Java-Bytecodes umfasst, und bei dem die Ausführung der Folge von virtuel-len Maschinenbefehlen unter Verwendung einer Ja-va- Maschine die Ausführung der Folge von Java- Bytecodes in einer virtuellen Java-Maschine um-fasst, die in der der Paket-Weiterleitungseinrich-tung enthalten ist. 5. Verfahren nach Anspruch 1, bei dem die Überwa-chung des Bandbreitenverbrauchs durch einen oder mehrere Typen von Paketverkehr (25), der in der Paket-Weiterleitungseinrichtung (17) empfan-gen wird, die Feststellung einer Messung des Band-breitenverbrauchs in der Paket-Weiterleitungsein-richtung (17) aufgrund des Verkehrs umfasst, der einem physikalischen Port auf der Weiterleitungs-einrichtung (17) zugeordnet ist. 6. Verfahren nach Anspruch 1, bei dem die Feststel-lung einer Messung des Bandbreitenverbrauchs in der Paket-Weüerteitungseinrichtung (17) aufgrund des der bestimmten Netzwerkadresse zugeordne-ten Verkehrs (25) die Feststellung einer Messung des Bandbreitenverbrauchs aufgrund des Verkehrs (25) umfasst, der einer bestimmten Medienzu-gangssteuer- (MAC-) Adresse zugeordnet ist. 7. Verfahren nach Anspruch 1, bei dem die Überwa-chung des Bandbreitenverbrauchs durch einen oder mehrere Typen von Paketverkehr, der in der Paket-Weiterleitungseinrichtung (17) empfangen wird, die Feststellung einer Messung des Bandbrei-tenverbrauchs in der Paket-Weiterleitungseinrich-tung aufgrund des Verkehrs umfasst, der einem be-stimmten Kommunikationssprotokoll zugeordnet ist. 8. Verfahren nach Anspruch 7, bei dem die Feststel-lung einer Messung des Bandbreitenverbrauchs in der Paket-Weiterleitungseinrichtung (17) aufgrund von Verkehr (25), der dem bestimmten Kommuni-kationsprotokoll zugeordnet ist, die Feststellung ei-ner Messung des Bandbreitenverbrauchs in der Pa-ket- Weiterleitungseinrichtung (17) aufgrund von Verkehr (25) umfasst, der zumindest einem der fol-genden Protokolle zugeordnet ist: Dateiübertra-gungsprotokoll, FTP, Hypertext-Übertragungspro-tokoll, HTTP, Übertragungssteuerprotokoll/Inter-netprotokoll, TCP/IP. 9. Paket-Weiterleitungseinrichtung (17) mit: einer Mehrzahl von Eingangs/Ausgangs-, I/O-, Ports zum Senden und Empfangen von Pake-ten von Informationen; ersten und zweiten Warteschlangen zum Puf-fern der Pakete vor der Aussendung über einen oder mehrere der I/O-Ports, wobei Pakete (25), die in der ersten Warteschlange gepuffert wer-den, eine höhere Übertragungspriorität haben, als Pakete (25), die in der zweiten Warte-schlange gepuffert werden, und gekennzeich-net durch: eine Warteschlangen-Zuordnungslogik zum Zuordnen der zu puffernden Pakete (25) in entweder der erstenWarteschlange oder der zweiten Warteschlange entspre-chend einem Paketiyp, der jedem Paket (25) zugeordnet ist, wobei jedes der Pake-
- 11. EP 1 142 213 B1 19 20 5 10 15 20 25 30 35 40 45 50 55 11 te (25) zumindest einem einer Vielzahl von Pakettypen zugeordnet ist; und einen oder mehrere Agenten (157) zur Überwachung des Bandbreitenverbrauchs durch Pakete (25), die einem ersten Pa-kettyp der Vielzahl von Pakettypen zuge-ordnet sind, wobei die Überwachung des Bandbreitenverbrauchs die Feststellung einer Messung des Bandbreitenver-brauchs in der Paket-Weiterleitungsein-richtung (17) aufgrund von Verkehr um-fasst, der einer bestimmten Ziel-Netzwerk-adresse zugeordnet ist, und zur automati-schen Änderung der Zuordnung von Pake-ten (25), die dem ersten Pakettyp zugeord-net sind, von der ersten Warteschlange zu der zweiten Warteschlange, wenn der Bandbreitenverbrauch von Paketen (25), die dem ersten Pakettyp zugeordnet sind, einen Schwellenwert übersteigt. 10. Vorrichtung (17) nach Anspruch 9, die weiterhin fol-gendes umfasst: eine Verarbeitungseinheit (10), die mit der Viel-zahl von I/O-Ports verbunden ist, wobei die Ver-arbeitungseinheit einen Speicher (32) und ei-nen Prozessor (31) einschließt; und eine Datenkommunikations-Schnittstelle zum Empfang von Programmcode in dem Speicher (32) der Verarbeitungseinheit (10) nach der In-stallation der Paket-Weiterleitungseinrichtung (17) in einem Paket-Kommunikations-Netz-werk, wobei der eine oder mehrere Agenten durch Ausführen des Programmcodes in dem Prozessor (31) der Verarbeitungseinheit (10) realisiert wird (werden). 11. Vorrichtung (17) nach Anspruch 10, bei der die Pa-ket- Weiterleitungseinrichtung (17) weiterhin Pro-grammcode umfasst, der bei seiner Ausführung durch die Verarbeitungseinheit (10) eine virtuelle Maschine realisiert, und bei dem der über die Da-tenkommunikations- Schnittstelle empfangene Pro-grammcode eine Folge von Befehlen umfasst, die von der virtuellen Maschine ausgeführt werden, um einen oder mehrere Agenten zu realisieren. 12. Vorrichtung (17) nach Anspruch 11, bei dem der über die Datenkommunikations-Schnittstelle emp-fangene Programmcode eine Folge von Java-Byte-codes umfasst, und bei der die virtuelle Maschine eine virtuelle Java-Maschine ist. 13. Vorrichtung (17) nach Anspruch 9, bei der der erste Pakettyp Pakete (25) umfasst, die einen bestimm-ten einen der I/O-Ports zugeordnet sind. 14. Vorrichtung (17) nach Anspruch 9, bei dem der er-ste Pakettyp Pakete (25) umfasst, die einer be-stimmten Netzwerkadresse zugeordnet sind. 15. Vorrichtung (17) nach Anspruch14, bei dem die be-stimmte Netzwerkadresse eine bestimmte Medien-zugriffssteuer-, MAC, Adresse ist. 16. Vorrichtung (17) nach Anspruch 9, bei der der erste Pakettyp Pakete (25) umfasst, die einen bestimm-ten Kommunikationsprotokoll zugeordnet sind. 17. Vorrichtung (17) nach Anspruch 16, bei dem das bestimmte Kommunikationsprotokoll ein Hypertext-Übertragungsprotokoll, HTTP, ist. 18. Vorrichtung (17) nach Anspruch 16, bei dem das bestimmte Kommunikationsprotokoll ein Dateiüber-tragungsprotokoll, FTP, ist. 19. Kommunika5onsnetzwerk, das eine Paket-Weiter-leitungseinrichtung (17) umfasst, wobei die Paket- Weiterleitungseinrichtung (17) folgendes ein-schließt: eine Vielzahl von Eingangs-/Ausgangs-, I/O-, Ports zum Senden und Empfangen von Pake-ten (25) an Informationen von einer oder meh-reren anderen Einrichtungen in dem Kommuni-kationsnetzwerk; erste und zweite Warteschlangen zum Puffern der Pakete (25) vor der Aussendung über einen oder mehrere I/O-Ports, wobei in der ersten Warteschlange gepufferte Pakete (25) eine hö-here Übertragungspriorität als Pakete (25) ha-ben, die in der zweiten Warteschlange gepuf-fert werden, gekennzeichnet durch: eineWarteschlangen-Zuordnungslogik zur Zuordnung der Pakete (25), die in entwe-der der ersten Warteschlange oder der zweiten Warteschlange zu puffern sind, entsprechend einem Pakettyp, der jedem Paket (25) zugeordnet ist, wobei jedes der Pakete (25) zumindest einem einer Viel-zahl von Pakettypen zugeordnet ist; und einen oder mehrere Agenten (157) zur Überwachung des Bandbreitenverbrauchs durch Pakete (25), die einem ersten Pa-kettyp der Vielzahl von Pakettypen zuge-ordnet sind, wobei die Überwachung des Bandbreitenverbrauchs die Feststellung einer Messung des Bandbreitenver-brauchs in der Paket-Weiterleitungsein-richtung (17) aufgrund von Verkehr um-fasst, der einer bestimmten Ziel-Netzwerk-adresse zugeordnet ist, und zur automati-schen Änderung der Zuordnung von Pake-
- 12. EP 1 142 213 B1 21 22 5 10 15 20 25 30 35 40 45 50 55 12 ten (25), die dem ersten Pakettyp zugeord-net sind, von der ersten Warteschlange zu der zweiten Warteschlange, wenn der Bandbreitenverbrauch von Paketen (25), die dem ersten Pakettyp zugeordnet sind, einen Schwellenwert übersteigt. 20. Kommunikationsnetzwerk nach Anspruch 19, bei dem die Paket-Weiterleitungseinrichtung (17) wei-terhin folgendes einschließt: eine Verarbeitungseinheit (10), die mit der Viel-zahl von I/O-Ports gekoppelt ist, wobei die Ver-arbeitungseinheit (10) einen Speicher (32) und einen Prozessor (31) einschließt; und eine Datenkommunikations-Schnittstelle zum Empfang von Programmcode in dem Speicher (32) der Verarbeitungseinheit (10) nach der In-stallation der Paket-Weiterleitungseinrichtung (17) in dem Kommunikationsnetzwerk, wobei der eine oder mehrere Agenten durch eine Aus-führung des Programmcodes in dem Prozessor (31) der Verarbeitungseinheit (10) realisiert ist (sind). 21. Kommunikationsnetzwerk nach Anspruch 20, bei dem die Paket-Weiterleitungseinrichtung (17) wei-terhin Programmcode einschließt, der bei seiner Ausführung durch die Verarbeitungseinheit (10) ei-ne virtuelle Maschine realisiert. und wobei der über die Datenkommunikations-Schnittstelle empfange-ne Programmcode eine Folge von Befehlen ein-schließt, die von der virtuellen Maschine ausgeführt werden, um einen oder mehrere Agenten zu reali-sieren. Revendications 1. Un procédé convenant pour l'utilisation dans un dis-positif d'acheminement de paquets (17), caractéri-sé par les étapes consistant à: surveiller la consommation de largeur de bande par un ou plusieurs types de trafic de paquets (25) reçu dans le dispositif d'acheminement de paquets (17), ceci comprenant la détermination d'une mesure de consommation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du trafic associé à une adresse de réseau de destination particulière; déterminer si la consommation de largeur de bande par le ou les types de trafic de paquets (25) dépasse un seuil; et changer automatiquement l'assignation d'au moins un type de trafic de paquets parmi le ou les types de trafic de paquets, pour la faire pas-ser d'une file d'attente ayant une première prio-rité à une file d'attente ayant une deuxième priorité, si la consommation de largeur de ban-de dépasse le seuil. 2. Le procédé selon la revendication 1, comprenant en outre la réception d'un code de programme dans le dispositif d'acheminement de paquets (17) après l'installation du dispositif d'acheminement de pa-quets (17) dans un réseau de communication par paquets, et dans lequel la surveillance, la détermi-nation et le changement automatique sont accom-plis par le code de programme qui s'exécute. 3. Le procédé selon la revendication 2, dans lequel la réception du code de programme comprend la ré-ception d'une séquence d'instructions de machine virtuelle, et dans lequel l'exécution du code de pro-gramme comprend l'exécution de la séquence d'instructions de machine virtuelle, en utilisant une machine virtuelle incluse dans le dispositif d'ache-minement de paquets (17). 4. Le procédé selon la revendication 3, dans lequel la réception de la séquence d'instructions de machine virtuelle comprend la réception d'une séquence de pseudo-codes Java, et dans lequel l'exécution de la séquence d'instructions de machine virtuelle en utilisant une machine virtuelle comprend l'exécution de la séquence de pseudo-codes Java dans une machine virtuelle Java incluse dans le dispositif d'acheminement de paquets. 5. Le procédé selon la revendication 1, dans lequel la surveillance de la consommation de largeur de ban-de par un ou plusieurs types de trafic de paquets (25) reçu dans le dispositif d'acheminement de pa-quets (17) comprend la détermination d'une mesure de consommation de largeur de bande dans le dis-positif d'acheminement de paquets (17) sous l'effet du trafic associé à un port physique sur le dispositif d'acheminement (17). 6. Le procédé selon la revendication 1, dans lequel la détermination d'une mesure de consommation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du trafic (25) associé à l'adresse de réseau particulière, comprend la déter-mination d'une mesure de consommation de lar-geur de bande due au trafic (25) associé à une adresse de commande d'accès au support, MAC, particulière. 7. Le procédé selon la revendication 1, dans lequel la surveillance de la consommation de largeur de ban-de par un ou plusieurs types de trafic de paquets reçu dans le dispositif d'acheminement de paquets (17) comprend la détermination d'une mesure de largeur de bande dans le dispositif d'acheminement
- 13. EP 1 142 213 B1 23 24 5 10 15 20 25 30 35 40 45 50 55 13 de paquets sous l'effet du trafic associé à un proto-cole de communication particulier. 8. Le procédé selon la revendication 7, dans lequel la détermination d'une mesure de consommation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du trafic (25) associé au protocole de communication particulier, com-prend la détermination d'une mesure de consom-mation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du tra-fic (25) associé à un au moins des protocoles suivants : protocole de transfert de fichiers, FTP, protocole de transfert hyper-texte, HTTP, protocole de commande de transmission / protocole Internet, TCP/IP. 9. Un appareil d'acheminement de paquets (17) comprenant : une multiplicité de ports d'entrée / sortie, I/O, pour émettre et recevoir des paquets d'informa-tion; des première et seconde files d'attente pour en-registrer les paquets en tampon avant l'émis-sion par l'intermédiaire d'un ou plusieurs des ports d'I/O, des paquets (25) enregistrés en tampon dans la première file d'attente ayant une priorité d'émission plus élevée que des pa-quets (25) enregistrés en tampon dans la se-conde file d'attente, et caractérisé par une logique d'assignation de file d'attente pour assigner l'enregistrement des paquets (25) en tampon dans la première file d'attente ou la se-conde file d'attente conformément à un type de paquet associé à chaque paquet (25), chacun des paquets (25) étant associé à au moins un d'une multiplicité de types de paquets; et un ou plusieurs agents (157) pour surveiller la consommation de largeur de bande par des pa-quets (25) associés à un premier type de pa-quet de la multiplicité de types de paquets, la surveillance de la consommation de largeur de bande comprenant la détermination d'une me-sure de consommation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du trafic associé à une adresse de réseau de destination particulière, et pour changer automatiquement l'assignation de pa-quets (25) associés au premier type de paquet, pour la faire passer de la première file d'attente à la seconde file d'attente si la consommation de largeur de bande de paquets (25) associés au premier type de paquet dépasse un seuil. 10. L'appareil (17) selon la revendication 9, compre-nant en outre: une unité de traitement (10) couplée à la mul-tiplicité de ports d'I/O, l'unité de traitement in-cluant une mémoire (32) et un processeur (31); et une interface de transmission de données pour recevoir un code de programme dans la mé-moire (32) de l'unité de traitement (10) après l'installation du dispositif d'acheminement de paquets (17) dans un réseau de transmission de paquets, et dans lequel le ou les agents sont mis en oeuvre par l'exécution du code de pro-gramme dans le processeur (31) de l'unité de traitement (10). 11. L'appareil (17) selon la revendication 10, dans le-quel le dispositif d'acheminement de paquets (17) comprend en outre un code de programme qui, lors-qu'il est exécuté par l'unité de traitement (10) réalise une machine virtuelle, et dans lequel le code de pro-gramme reçu par l'intermédiaire de l'interface de transmission de données comprend une séquence d'instructions qui est exécutée par la machine vir-tuelle pour mettre en oeuvre un ou plusieurs agents. 12. L'appareil (17) selon la revendication 11, dans le-quel le code de programme reçu par l'intermédiaire de l'interface de transmission comprend une sé-quence de pseudo-codes Java, et dans lequel la machine virtuelle est une machine virtuelle Java. 13. L'appareil (17) selon la revendication 9, dans lequel le premier type de paquet comprend des paquets (25) associés à l'un particulier des ports d'I/O. 14. L'appareil (17) selon la revendication 9, dans lequel le premier type de paquet comprend des paquets (25) associés à une adresse de réseau particulière. 15. L'appareil (17) selon la revendication 14, dans le-quel l'adresse de réseau particulière est une adres-se de commande d'accès au support, MAC, parti-culière. 16. L'appareil (17) selon la revendication 9, dans lequel le premier type de paquet comprend des paquets (25) associés à un protocole de communication par-ticulier. 17. L'appareil (17) selon la revendication 16, dans le-quel le protocole de communication particulier est un protocole de transfert hyper-texte, HTTP. 18. L'appareil (17) selon la revendication 16, dans le-quel le protocole de communication particulier est un protocole de transfert de fichiers, FTP. 19. Un réseau de communication comprenant un dis-positif d'acheminement de paquets (17), le disposi-
- 14. EP 1 142 213 B1 25 26 5 10 15 20 25 30 35 40 45 50 55 14 tif d'acheminement de paquets (17) incluant : une multiplicité de ports d'entrée / sortie, I/O, pour émettre et recevoir des paquets (25) d'in-formation en relation avec un ou plusieurs autres dispositifs dans le réseau de communi-cation; des première et seconde files d'attente pour en-registrer les paquets (25) en tampon avant l'émission par un ou plusieurs des ports d'I/O, des paquets (25) enregistrés en tampon dans la première file d'attente ayant une priorité d'émission plus élevée que des paquets (25) enregistrés en tampon .dans la seconde file d'attente; et caractérisé par une logique d'assignation de file d'attente pour assigner l'enregistrement des paquets (25) en tampon dans la première file d'attente ou la se-conde file d'attente conformément à un type de paquet associé à chaque paquet (25), chacun des paquets (25) étant associé à au moins un d'une multiplicité de types de paquets; et un ou plusieurs agents (157) pour surveiller la consommation de largeur de bande par des pa-quets (25) associés à un premier type de pa-quet de la multiplicité de types de paquet, la surveillance de la consommation de largeur de bande comprenant la détermination d'une me-sure de consommation de largeur de bande dans le dispositif d'acheminement de paquets (17) sous l'effet du trafic associé à une adresse de réseau de destination particulière, et pour changer automatiquement l'assignation de pa-quets (25) associés au premier type de paquet, pour la faire passer de la première file d'attente à la seconde file d'attente si la consommation de largeur de bande de paquets (25) associés au premier type de paquet dépasse un seuil. 20. Le réseau de communication selon la revendication 19, dans lequel le dispositif d'acheminement de pa-quets (17) comprend en outre : une unité de traitement (10) couplée à la mul-tiplicité de ports d'I/O, l'unité de traitement (10) incluant une mémoire (32) et un processeur (31); et une interface de transmission de données pour recevoir un code de programme dans la mé-moire (32) de l'unité de traitement (10) après l'installation du dispositif d'acheminement de paquets (17) dans le réseau de communica-tion, et dans lequel le ou les agents sont mis en oeuvre par l'exécution du code de programme dans le processeur (31) de l'unité de traitement (10). 21. Le réseau de communication selon la revendication 20, dans lequel le dispositif d'acheminement de pa-quets (17) comprend en outre un code de program-me qui, lorsqu'il est exécuté par l'unité de traitement (10), réalise une machine virtuelle, et dans lequel le code de programme reçu par l'intermédiaire de l'interface de transmission de données comprend une séquence d'instructions qui est exécutée par la machine virtuelle pour mettre en oeuvre un ou plu-sieurs agents.
- 15. EP 1 142 213 B1 15
- 16. EP 1 142 213 B1 16
- 17. EP 1 142 213 B1 17
- 18. EP 1 142 213 B1 18
- 19. EP 1 142 213 B1 19
- 20. EP 1 142 213 B1 20
- 21. EP 1 142 213 B1 21
- 22. EP 1 142 213 B1 22