METHODANDARRANGEMENTFORPACKETMANAGEMENTINA
ROUTER
Field of invention The present invention relates to a method and an arrangement for packet management in a router and more particularly for control of dropped packets and storing information about dropped packets for management and measurement purposes. By storing information such as time, packet size and other useful information about the dropped packets, the invention enables loss measurement, error detection and other verification procedures.
State of the art
An Internet Protocol (IP) router typically receives IP packets on an incoming interface; checks the header of the packet for address (and possibly other) informa- tion; consults its routing table concerning where to send the packet; and finally sends the packet on an outgoing interface.
Since packets that are coming in simultaneously on several incoming interfaces may need to be sent out on the same outgoing interface, there is a queue for packets waiting to be sent. When queues are full, packets are "dropped". This means that they are deleted and not placed in the queue. A counter for "dropped packets" in the router is incremented each time a packet is dropped. This is a simplification of the actual process, which includes metering, shaping etc before the actual "dropping". However, for the sake of describing the present invention, it is not important how the packet to be dropped was selected.
Problem
IP networks are generally resilient to dropped packets. TCP (Transmission Control Protocol) will for example recognise that a packet has been dropped (through a timeout procedure) and re-transmit the packet. UDP (User Datagram Protocol) packets are normally not considered worth re-transmitting, and applications can sometimes do without them. However, it does affect the performance or other quality-related parameters, see below.
An increasingly popular service is to guarantee a certain level of Quality of Service (QoS). As part of such a guarantee, the amount of loss may need to be kept under a threshold, for example. Traffic may belong to different Quality Classes, each class having its associated loss threshold. If the routers only keep a sum of the packets dropped, it is not possible to see if the threshold for a certain class has been passed and thus to verify that the QoS level delivered was in parity with the guaranteed level.
If the router uses WRED (Weighted Random Early Detect) or similar schemes, the number of packets dropped for a certain class may be estimated as a part of the total number of dropped packets, according to the probability rate used by the algorithm. However, the figure will be an estimate at best. There is no way to find the exact number.
Solution
The invention makes it possible to identify all dropped packets. It is proposed to add the following functionality to the "dropper", i.e. that part of the router soft- ware, which is invoked when a packet is to be dropped:
When the router control software has decided that a packet should be dropped, the following actions should be carried out instead of just deleting the packet and incrementing a counter: copy and store relevant information about the packet to be dropped in a specific memory before the packet is dropped. The stored information is used later for various purposes. The invention provides information upon which statistical and other operations may be performed and enables new functionalities such as true loss measurement and error detection.
Summary of the invention The present invention provides a method for managing packets in a router comprising input ports for receiving packets, queues for storing packets before the packets are sent to output ports, routing logic for determining in which queue a packet is to be stored, and dropping logic for determining if a packet is to be dropped. According to the invention the method comprises the steps of, when a packet is to be dropped, copying information about the dropped packet, storing the information in an information memory, and removing the packet from its queue.
Preferably, the information includes current time, original packet size, router state, queue identification, and/or the reason why the packet was dropped. The invention also provides an arrangement for carrying out the method. The invention is defined in the independent claims 1 and 14 below, while preferred embodiments are set forth in the dependent claims.
Brief description of the drawings The invention will be described in detail below with reference to the accompanying drawings in which: fig. 1 is a schematic representation of a router according to the invention.
Detailed description of preferred embodiments
A block diagram of a router in accordance with the present invention is shown in fig. 1. Generally, the router is used to switch packets in a network. Packets are received at an input interface or several input ports. Routing logic checks the packet to determine the destination and sends the packet to the appropriate output port. Queues are associated with the output ports for temporarily storing the packets. A dropping logic checks the queues to see if there is a risk for overflow. If this is the case, packets are selected for dropping, i.e. the packet is removed from the queue. As is conventional, the number of packets may be counted by incrementing a special counter.
The present invention provides an improvement to the packet management by storing more in detail information about packets to be dropped. Instead of just removing the packet from the queue and incrementing the counter the following actions are carried out. 1. Copy the header part of the packet, including the header for the transport layer i.e. UTC UDP, to a specific memory or buffer for "information on dropped packets".
2. Store current time, original packet size and other useful information about the dropped packet (or router state) in the buffer. Other information, e.g. which queue it was dropped from and the reason it was dropped, could also be stored. Which information to store is preferably configurable through a management interface on the router.
3. Return to normal operation, i.e. remove packet from queue and increment counter for dropped packets. The buffer for "information on dropped packets" must be written to an external memory, e.g. a disk, at regular intervals, or at least often enough so that this buffer will never be full, i.e. to avoid overflow. The stored information should be accessible e.g. through SNMP (Simple Network Management Protocol) for management systems. The corresponding MIB (Management Information Base) parameters need to be standardised. By using filters, part of the information can be retrieved, e.g. in order to find the effects on a specific customer or the number of packets dropped for a specific quality class.
The following innovative functions are being made possible by means of the present invention. 1. Loss measurement a. Loss measurement according to the IETF (Internet
Engineering Task Force) IPPM, i.e. "Loss Period", which measures frequency and burstiness of loss, and "Loss Distance", which measures the spacing between loss periods, can be done by statistical operations on the collected data on dropped packets. Data needs to be collected for a time corresponding to the level of confi-
dence that is required in the measurement.
The method does not measure loss that is defined as packets arriving at the destination delayed more then the jitter buffer can handle. These packets are ignored by the application and infer the same performance and quality degradations as losses in a router on the data path.
2. Loss measurement b. Data corresponding to lost packets are stored at most until at time period relevant to the guarantee in the corresponding SLA (Service Level Agreement) has passed. If, for example, the loss is guaranteed to stay below j % in a 3 months period for Class Y, information on lost packets needs to be collected for 3 months. By comparing data about dropped packets with information about data rate (number of packets per second) sent, (this data needs to be measured by other means), it can be verified if the guarantee was honoured or not. However, if the loss rate, being continuously calculated following the agreed probability function (e.g. a gauss function) exceeds the agreed value, a breach of contract needs to be noted and measurements can start afresh.
3. Error Detection: Information stored about why and where a packet (or several packets) was dropped can be used to identify errors in the router software or hardware.
4. Traffic Engineering: Information about which queues that are being filled (and consequently drop packets) can be used for traffic engineering purposes.
5. The data on the dropped packets can also be used when verifying the correctness of e.g. WRED algorithm implementations in the router. The current way to do this is to compare the data packets transmitted with the data packets received through the router. In order to be statistically valid, the amount of data needs to be large, so the method is slow and requires huge amounts of storage capacity. By instead looking at the data stored from dropped packets, one could verify that the relationship between dropped packets from different levels of priority follows the theoretical model. The amount of data that needs to be processed is then much less.
6. Measurement on performance degradation in TCP-based applications. As was mentioned in the problem statement section above, TCP can cover up for lost packets by re-transmitting them. This will however affect throughput, both by the need to send a packet twice, but also since TCP lowers its transmission speed when packets are lost. If it is known which packets are lost, the effects on the corresponding data stream can be calculated. 7. Acknowledgement of quality degradation in UDP-based applications. As was also mentioned above, applications using UDP are often resilient to the loss of such packets. However, if the data stream is an audio or video stream, the perceived quality will be affected by the loss. Without knowing the application, the amount of impairment is almost impossible to calculate, but the fact that impairment was
effected can be acknowledged.
The proposed changes in the router adds to the load of the processor and requires memory space. However:
• Because the size of the "information on dropped packets" is much smaller than the packets they contain information about, there is a limited need for memory space for the buffer. An IP header plus TCPAJDP header is around 35 - 40 bytes compared to a complete FTP (File Transfer Protocol) packet, which may be 1500 to 4000 bytes. The total amount of data that is stored for each packet may be less than 100 bytes. • The extra load on the router processor will be minimal. The copy operation is similar to copy operations from one queue to another, only with less data.
• The router may be configured to perform the above actions only for packets of a certain class, e.g. packets belonging to class "Best Effort" are not saved, but only counted, while packets belonging to other classes are saved. This would save space and processor power in the router.
• An off-line activity can be to "compress" the stored data by removing duplicate information, e.g. replacing them with a number of duplicates stored with the first occurrence. A person skilled in the art will realise that the described embodiments of the invention may varied without departing from the scope of the following claims.