EP2507948A1

EP2507948A1 - Device and method for aggregating data received over a plurality of physical links

Info

Publication number: EP2507948A1
Application number: EP10784779A
Authority: EP
Inventors: Henri Teboulle
Original assignee: Sagemcom Energy and Telecom SAS
Current assignee: Sagemcom Energy and Telecom SAS
Priority date: 2009-11-30
Filing date: 2010-11-25
Publication date: 2012-10-10
Also published as: CN102640460B; CN102640460A; WO2011064287A1; FR2953354A1

Abstract

The invention relates to link aggregation at the link layer of a data communication system and, in particular, to a data distribution method in which link packets are divided up into blocks. Each block is provided with a sequence number and a flag indicating the last block of the packet. The blocks are routed independently over each physical link. The method allows the flexible management of all types of physical links and does not require the synchronisation of the physical links.

Description

An apparatus and method for aggregating data received over a plurality of physical links.

The present invention relates to the field of link aggregation at the link layer of a data transmission system. It relates more particularly to a device and a method for aggregating data received on a plurality of physical links.

The aggregation of physical links to compensate for bandwidth shortcomings is known. In particular, it is known to distribute the data packets of the link layer over a plurality of physical links according to the addressing data contained in the header of these packets. This solution leads to unsuitable solutions where the actual occupation of each physical link depends on the addressing information that is not correlated with the available bandwidths of each link. Other solutions cut the received data packets and distribute them directly on the physical links. These solutions require synchronization of the physical links to allow rebuilding the packets at the other end. The invention aims at solving the above problems by proposing a data method based on the division of the block link packets. Each block has a sequence number and a flag indicating the last block of the packet. Blocks are routed independently on each physical link. The distribution is made according to the bandwidths of each link. The described method makes it possible to flexibly manage any type of physical link and does not require synchronizing the physical links.

The invention relates to a data aggregation device that includes an external link for sending data packets; a plurality of internal physical links for receiving data packets; means for receiving a plurality of received data blocks on the plurality of internal physical links; means for deleting the header of each received data block which has a sequence number of said block within a data packet and a flag marking the last block of the packet; means for aggregating said blocks to reconstruct a data packet based on the sequence number of each block and the flag marking the last block and means for transmitting said data packet on the external link.

According to a particular embodiment of the invention, it comprises means for inserting a preamble at the beginning of the data packet.

According to a particular embodiment of the invention, the physical links having a GMII interface, the insertion means (10.10) of a preamble are means for inserting a GMII preamble.

According to a particular embodiment of the invention, the device further comprises means for calculating and inserting a checksum of the data packet at the end of the data packet.

The invention also relates to a method for aggregating data within a device having an external link for transmitting data and a plurality of internal physical links for receiving data that includes a step of receiving a plurality of data. received data blocks on the plurality of internal physical links; a step for deleting the header of each received data block which has a sequence number of said block within a data packet and a flag marking the last block of the packet; a step of aggregating the different blocks to reconstruct the data packet and a step of transmitting the data packet on the external link. According to a particular embodiment of the invention, it comprises a step of inserting a preamble at the beginning of each data packet.

According to a particular embodiment of the invention, the physical links having a GMII interface, the insertion step (7.3) of a preamble is a step of inserting a GMII preamble.

According to a particular embodiment of the invention, the method further comprises a step of calculating and inserting a checksum of the data packet at the end of the data packet.

The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of an exemplary embodiment, said description being given in relation to the attached drawings, among which:

Fig. 1 illustrates the operating diagram of the invention,

Fig. 2 illustrates the format of the data packets of an exemplary embodiment, FIG. 3 illustrates the splitting of the data packets in an exemplary embodiment of the invention,

Fig. 4 illustrates the operation of the transmitter in an exemplary embodiment of the invention,

Fig. 5 illustrates the general operation of the receiver in an exemplary embodiment of the invention,

Fig. 6 illustrates the operation of the reception on one of the physical links in an exemplary embodiment of the invention,

Fig. 7 illustrates the reconstruction of the frame in an exemplary embodiment of the invention,

Fig. 8 illustrates the general architecture of the transmitter, receiver, according to an exemplary embodiment of the invention,

Fig. 9 illustrates the architecture of the distribution block according to an exemplary embodiment of the invention,

Fig. 10 illustrates the architecture of the aggregation block according to an exemplary embodiment of the invention,

Fig. 11 illustrates the general operation of the transmission process according to an exemplary embodiment of the invention,

Fig. 12 illustrates the general operation of the reception process according to an exemplary embodiment of the invention. Fig. 1 illustrates the operating diagram of the invention. This concerns the aggregation of links in a packet communication network. The link aggregation occurs between two network devices 1.2 and 1.4. Each of these devices has a first link, called the external link, which allows it to receive and transmit data as data packets to other devices. The external link of the equipment 1.2 is the link 1.1. The external link of the 1.4 equipment is link 1.5.

A plurality of links 1.3, referred to as the internal links, connect the two devices 1 .2 and 1 .4. Each of its links can work according to its own physical technology. Each of these links has its own characteristics such as bandwidth, transmission latency and others.

The invention is based on specific hardware for managing internal links. With reference to the OSI model of the communication links, the invention intervenes at the level of the link layer to distribute the data received from the external link between the various internal links. The data received on these different internal links are aggregated to reconstruct the data packets of the link layer. The invention is therefore transparent for the link layer.

The exemplary embodiment is based on an Ethernet type link layer according to the international standard ISO / IEC 8802-3, but could be applied to other link layer standards. The physical layer used for links can be diverse, it can be radio communication, optical fiber, copper or others. The invention operates independently of the physical medium of the link. Some of these physical layers provide a guaranteed throughput, while others have a variable rate of flow over time. This is typically the case for radio transmissions subject to variations in the radio channel. According to some embodiments, the invention makes it possible to optimally use the variable bandwidth of this type of link.

Fig. 2 illustrates the format of the data packets of an exemplary embodiment. On the physical medium, the data packets 2.2, typically Ethernet, are transmitted preceded by a preamble 2.1 and followed by a checksum 2.3, typically of the type CRC (Cyclic redundancy check in English). The Ethernet packet itself consists of a 2.4 header and a 2.5 message body (payload). The data transiting on the external links are thus transmitted under this form: preamble bytes, bytes constituting the Ethernet packet and bytes of CRC.

Fig. 3 illustrates the splitting of data packets in an exemplary embodiment of the invention. When receiving the data packets, the preamble and CRC bytes outside the packet itself are discarded. The data packet is then divided into blocks. Advantageously, the blocks have a fixed size, but it is not necessary. In particular, since the received data packets may be of variable size, the last block may also be of variable size. According to the exemplary embodiment, the data packet is divided into blocks 3.10, 3.1 1, 3.12, 3.13 and 3.14, of 256 bytes, the last block can have a size of between 64 and 320 bytes to accommodate the size of the packet. received data.

To each block of data thus created is added a header 3.30, 3.31, 3.32, 3.33 and 3.34 which has at least two functions. A first is to allow to memorize the sequence of blocks constituting the data packet. To do this, a sequence number is stored in Γ header. A second function is to mark the end of the data packet. To do this, a flag indicates the last block constituting a data packet. According to the exemplary embodiment, the header has two bytes. The sequence number is coded on 14 bits, while a fifteenth bit serves as a flag and is set to 1 for the last block of the packet. The sixteenth bit is unused. The body of each block 3.20, 3.21, 3.22, 3.23 and 3.24 contains the data of the packet, respectively the parts 3.10, 3.11, 3.12, 3.13 and 3.14 of the data packet.

Choosing a relatively small block size makes it possible to have a flexible system whose granularity will make it possible to adapt to the diversity of the physical links constituting the aggregation. Too small, however, increases the amount of headers added and affects bandwidth usage. A wise choice of this block size is therefore made according to the type of physical link used. The fact of numbering the blocks allows a reordering of the blocks during the reconstruction of the packet and thus to manage links whose communication latency is different. In the absence of this mechanism, it is necessary to synchronize the links to ensure a reconstruction of the packet on arrival, which is not necessary here. There is therefore great flexibility in the choice of physical links used that can combine various technologies. Fig. 1 1 illustrates the general operation of the transmitter. It expresses the repetitive nature of the process in the form of an endless loop. The repeated process is illustrated in FIG. 4.

Fig. 4 illustrates the operation of the transmitter in an exemplary embodiment of the invention. The receive algorithm operates on a byte basis. In a first step 4.1, one receives a byte. It is then tested whether it is a preamble byte or CRC, step 4.2. If this is the case, we bypass the byte and return to the receipt of the next byte. Otherwise, the received byte 4.3 is stored in a receive buffer. This buffer works on a first in, first out, or FIFO (First In First Out) basis. Step 4.4 represents the output of a byte of this receive buffer to be transferred to a block build buffer. Advantageously, it includes adding a ninth bit to the byte to memorize whether the byte is the last byte of the block. One tests 4.5 then if it is the first byte of the current block. If this is the case, we test 4.6, if it is the last block of the received data packet. When it is the first byte of a block, the two bytes of header are added by positioning the sequence number of the block and the last block flag, steps 4.7 or 4.8. The bytes of the block build buffer are transferred in step 4.9 to the output buffer.

The bytes of the output buffer are extracted. It is tested whether the extracted byte is the first byte of a new block, step 4.10. If this test is positive, we determine the physical link that will be used to transmit the block in step 4.1. 1. The physical links being managed via a GMII {Gigabit Media Independent Interface in English), we must insert a GMII preamble before the first octet, step 4.12. The byte is then extracted in step 4.14.

In the case where there is no new block to extract, we test if a block is being extracted, step 4.13. If this is the case, we extract a byte in step 4.14, otherwise we do nothing during this passage and we loop over the entire flowchart.

The block is therefore sent on the physical link in the form of a GMII packet. These packets are normally terminated by a CRC checksum. Depending on the implementations of the GMII interfaces, GMII packages whose checksum is wrong will be accepted or not. Advantageously, a valid CRC of the block is inserted at the end thereof, this step is not shown in the figure. Fig. 12 illustrates the general operation of the reception process. During a first initialization step 12.1, a variable PI is initialized to 0 to signify that no block extraction is in progress on the channel 1. A variable P2 is initialized to 0 to signify that no extraction of block is in progress on channel 2. A Start Frame variable is initialized to 0 to signify that it is at the beginning of the frame. A finite frame variable is initialized to 1 to indicate that we are not at the end of the frame. These variables are used as semaphore for, respectively, the insertion of a header and a checksum at the beginning and at the end of the frame. Then, an endless loop is started on a reception step channel 1 12.2, a reception step channel 2 12.3, a concatenation step 12.4 and a step of extracting the output buffer 12.5. These steps will be detailed in the figures described below.

Fig. 5 details the operation of the receiver in an exemplary embodiment of the invention. According to the exemplary embodiment of the invention, two physical links constitute the aggregation. However, the disclosed method naturally extends to a plurality of physical links. A state variable is used by link and called Pi where i is the number of the physical link. The algorithm starts by testing these variables to determine if a block is being received on one of the links, ie if one of the variables is 1. These are steps 5.1 and 5.2. If a block is being received, it goes directly to the step of receiving said block 5.10 or 5.11. If no block is being received, it is tested whether a new block is available on one of the links, steps 5.3 and 5.4. If this is the case, the corresponding state variable is set to 1, steps 5.6 and 5.7. The 2 bytes of the block header are then deleted, steps 5.8 and 5.9. The flag indicating that a block is the last block of the packet that is present in the header is stored in a state variable called "Frame End". The word frame is used here to designate a data packet of the link layer. We then start the reception step on this physical link 5.10 or 5.1 1. The sequence numbers will be used to check the block order and rebuild the packet in the right order.

It should be noted that beforehand, the bytes of the preamble GMII and the possible

CRC GMII will have been discarded.

Fig. 6 illustrates the operation of the reception on one of the physical links in an exemplary embodiment of the invention. In step 6.1, a byte is transferred from the receive buffer of the physical link to the reconstruction buffer of the package. It is then tested whether it is the last byte of the block, step 6.2. If it is the case, step 6.3, the variable Pi of the current physical link is set to 0 to indicate the end of the step of receiving a block on this physical link. It is then tested whether the extracted block is the last block of the packet to be rebuilt in step 6.4, by testing the variable End Frame. If so, calculate and insert the CRC of the reconstructed packet, step 6.5, and set the End Frame variable to 1, step 6.6.

Fig. 7 illustrates the reconstruction of the frame in an exemplary embodiment of the invention. In step 7.1, it is tested whether the data packet is complete. If this is the case, we test if we are positioned at the beginning of the frame, step 7.2, by a Start Trame = 0 test. In this case, we insert a preamble GMII, step 7.3, we position the variable. at 1, step 7.4. One can then extract a byte from the buffer to the external link, step 7.5. If this byte is the last byte of the frame, step 7.6, set the Start Frame variable to 0 in step 7.7. The frames are thus extracted, byte by byte, to transmit them on the external link.

Fig. 8 illustrates the general architecture of the transmitter, receiver, according to an exemplary embodiment of the invention. The physical links use a Serialization / Deserialization "serdes" module, 8.1, 8.7 and 8.9, coupled respectively to a GMII module, 8.2, 8.6 and 8.8. The modules 8.1 and 8.2 represent the external link, while the modules 8.6 and 8.7, respectively 8.8 and 8.9 represent the internal physical links. The data received from the external link is directed to a distribution module 8.4 responsible for building the blocks and distributing them on the physical links. This module works according to the algorithms described above. The blocks received from the internal physical links are directed to an aggregation module 8.5 responsible for rebuilding the data packets of the link layer according to the algorithms defined above.

Advantageously, the device receives real-time information on the bandwidth available on each of the internal links. This information corresponds to a so-called ACM (Adaptive Code Modulation) mode available especially for radio links. This information is then received by a 8.3 bit rate management module. This module 8.3 then supplies the distribution module 8.4 with information on the current rates available on the physical links in the form of a signal. This information will be used by the distribution module to distribute data between internal links based on this available bandwidth. Fig. 9 illustrates the architecture of the distribution module according to an exemplary embodiment of the invention. The data packets arrive from the external link to the reception buffer 9.1. The bytes are then transferred to block buffer 9.2. This buffer has a size of 320 bytes in the exemplary embodiment, that is to say the maximum size of a block. Under the control of the status module 9.4, the blocks are then transferred to a block storage buffer 9.5. An insert module for block headers 9.3, allows to insert the 2 bytes of block headers under the control of the state module by setting the sequence number of the block and the variable of last block of the frame. A module 9.12 is responsible for calculating a CRC and inserting it if necessary in the buffer 9.5 under the control of the state module. This module is optional, especially in the case where modems accept packets with an erroneous GMII CRC. A signal sent by the buffer 9.2 to the state module allows the detection of frames greater than 320 bytes. In this way the status module 9.4 is warned in real time that the buffer 9.2 is full, and therefore that there is at least one complementary block to receive for the current data packet.

The module 9.6 controls the determination of the physical link on which each block will be sent, as well as the transmission of the blocks to the channels 9, 10 and 9. 1 1. Advantageously, it receives the signals 9.9 from the current rates of each of the links physical. It uses them to generate a synchronization signal proportional to the link rate for each link. This generation is made by a NCO (Numerically Controlled Oscillator in English) according to the received bit rate value. More precisely, thanks to the information on the received current rates, 9.9, the NCOs consisting of the adder 9.13 and the high-order bit selector MSB 9.14 make it possible to generate a synchronization signal proportional to the rate of the channel considered, for each channel. outgoing. This optimizes the use of the authorized bandwidth for each channel.

The signal from module 9.5 to module 9.6 indicates that this buffer has a block to transmit. A return signal called Enable ffo, allows the 9.6 module to control the byte byte output of the block. The NCO signals 1 and NC0 2 received from the NCOs are respectively synchronous byte of the transmission channels 1 and 2.

For each of the channels 1 and 2, 16-bit DC I and CC 2 current counters initialized at 0 are managed. At each 125 MHz top, with respect to the CC I counter of the channel 1, the following behavior is implemented: When "NCO 1" = 0 and "Enable fifo" = 1, CC I = CC I + 1 during the block and CC I = CC I + 6 if we are at the beginning of the block to take into account the encapsulation GFP {Generic Framing Procedure in English), which is in our example embodiment the encapsulation method used to transport the Ethernet frame via the modem.

When "NCO_l" = "Enable_fîfo", CC_1 remains unchanged.

When "NCO l" = 1 and "Enable fifo" = 0, CC I = CC I - 1, CC I always remaining at least equal to 0.

CC I functions as an integrator representative of the imbalance between the number of bytes actually transmitted by the modem located after channel 1 and the number of bytes extracted from buffer 9.5.

A symmetric integrator is implemented for channel 2.

When a complete block has been extracted from the buffer 9.5, the counters CC I and CC 2 are compared to a programmable threshold for each channel, Threshold 1 and Threshold 2. If CC I <Threshold l and CC I <= CC 2, we decide to take the next block from buffer 9.5 to channel 1. Similarly, if CC 2 <Threshold_2 and CC 2 <CC I, we decide to release the next one Block 9.5 to channel 2. In other cases, nothing is done.

The module 9.6 checks the output of the bytes constituting the block storage buffer blocks as well as the insertion of a GMII preamble using the insertion modules 9.8 and 9.7 to constitute the signals 9.10 and 9.11 transmitted on each of the blocks. physical links. These signals are therefore characterized in that they consist of data blocks representing an ordered sequence of bytes of a data packet of the link layer. In addition, each of these blocks has a header with a sequence number and a flag to indicate that the current block is the last block of the data packet.

Optionally, the CRC insertion module 9.12 is added at the end of each block to satisfy GMII implementations that do not accept blocks having an erroneous CRC.

Fig. 10 illustrates the architecture of the aggregation module according to an exemplary embodiment of the invention. The data arriving from each of the internal links therefore consist of blocks according to the invention. These blocks are processed by GMII 10.1 and 10.2 preamble retrieval modules and also, optionally, CRC GMII removal. The blocks are then stored in receive buffers, one per link, 10.3 and 10.4. The state module 10.5 then checks the aggregation of these modules. To do this, he receives the sequence numbers of each block and the fill level of the receive buffers. It then determines the buffer to be emptied of the contents of a block, it is the block whose number is the next expected in chronological order. The 2 bytes of the block header are discarded and its body is transferred to the output buffer 10.8. Control of selector 10.7 is used to insert the CRC of the data packet at the end of the last block of the frame using the CRC 10.6 calculation module. The transmission of the frame on the external link is managed by the module 10.9 which manages the transmission of data and the insertion at the head of each frame of a preamble GMII prepared by the preamble insertion module 10.10.

The invention described here in the Ethernet framework and using an embodiment with two physical links naturally extends to any number of physical links. It can be applied to any link protocol regardless of the physical technology used for the different links.

Claims

1 / Data aggregation device comprising:

an external link enabling the transmission of data packets;

a plurality of internal physical links allowing the reception of data blocks;

means for receiving (10.1, 10.2) a plurality of data blocks received on the plurality of internal physical links;

means for deleting the header of each received data block which comprises a sequence number of said block within a data packet and a flag marking the last block of the packet;

means for aggregating said blocks to reconstruct a data packet according to the sequence number of each block and the flag marking the last block;

means for transmitting said data packet on the external link, characterized in that it furthermore comprises:

means for calculating and inserting (10.6) a checksum of the data packet at the end of the data packet. Data aggregation device according to claim 1, characterized in that it comprises means (10.10) for inserting a preamble at the beginning of the data packet.

3 / device for aggregating data according to claim 2, characterized in that, the physical links having a GMII interface, the insertion means (10.10) of a preamble are means for inserting a preamble GMII.

4 / A method of aggregating data within a device having an external link for transmitting data and a plurality of internal physical links for receiving data blocks comprising:

a step (5.10, 5.1 1) of receiving a plurality of data blocks received on the plurality of internal physical links; a step (5.8, 5.9) for deleting Γ header of each received data block which includes a sequence number of said block within a data packet and a flag marking the last block of the packet;

a step (12.4) of aggregating the different blocks to reconstitute the data packet;

a step (12.5) for transmitting the data packet on the external link, characterized in that it furthermore comprises:

a step (6.5) for calculating and inserting a checksum of the data packet at the end of the data packet.

5 / method of data distribution according to claim 4, characterized in that it comprises a step (7.3) of inserting a preamble at the beginning of each data packet.

6 / A method of data distribution according to claim 5, characterized in that, the physical links having a GMII interface, the insertion step (7.3) of a preamble is a step of inserting a preamble GMII.