CN102025617B - Method and device for controlling congestion of Ethernet - Google Patents

Abstract

The invention discloses an Ethernet congestion control method and device. The method comprises: closing the entry port of the core network device with a congestion detection function and triggering a priority-based flow control PFC mechanism through a threshold; detecting whether the packet forwarded by the entry port is a congestion notification message CNM, and if the packet is determined to be a CNM , generate a PFC message according to the CNM; forward the CNM through the ingress port, and notify the peer device to suspend the data transmission of the corresponding queue according to the PFC message. By means of the technical scheme of the invention, the congestion problem can be fundamentally solved quickly and effectively.

Description

Ethernet congestion control method and device

technical field

The invention relates to the field of mobile communication, in particular to an Ethernet congestion control method and device.

Background technique

In related technologies, a data center is a center for providing enterprise application business services, and a center for data calculation, exchange, and storage. The data center combines advanced network technology and storage technology, carries more than 80% of the service requests and data storage capacity in the network, and provides services and operation platforms for the healthy operation of customers' business systems. Figure 1 is a schematic diagram of the data center network architecture in the prior art. As shown in Figure 1, in the enterprise data center, there are three distinct types of networks deployed: usually an Ethernet supporting IP traffic is deployed, and one or two networks supporting A storage area network for Fiber Channel storage traffic, an InfiniBand network supporting high-performance cluster computing. Deploying and managing these three distinct types of networks can bring high investment and operating costs to enterprises, so enterprises are eager to achieve consolidation on a unified array.

Ethernet stands out among many converged technologies because of its low cost, mature technology, and good scalability. This Ethernet converges data center LAN, storage area network, and high-performance computing applications into a single Ethernet interconnect. This Ethernet currently operates at 10Gbps and will eventually increase to 40G to 100Gbps.

At present, Ethernet itself is not optimized for providing storage and high-performance computing traffic services. Therefore, packet loss may occur when congestion occurs. To solve this problem, several protocols for ensuring lossless Ethernet have been formulated. Technologies, including Quantized Congestion Notification protocol (Quantized Congestion Notification protocol, referred to as QCN) for congestion control and priority-based flow control (Priority-based Flow Control, referred to as PFC). Figure 2 is a schematic diagram of the working principle of QCN in the prior art. As shown in Figure 2, QCN is a quantitative congestion control technology. Compared with other congestion management technologies, it adopts a relatively accurate backward congestion notification mechanism. The outbound port queue sets congestion detection points, and when congestion is detected, a Congestion Notification Message (CNM for short) is formed containing the degree of congestion, and the CNM is back-pressed to the source terminal that causes congestion, so that it reduces the corresponding The data transmission rate of the queue, QCN can find the source of congestion relatively accurately, and solve the congestion problem fundamentally, but its response speed is slow and cannot cope with the surge; Figure 3 is a schematic diagram of the working principle of PFC in the prior art, as shown in Figure 3 As shown, PFC is an enhancement to the Pause mechanism of 802.3ad. It divides the traffic into 8 priority levels according to the priority field of the VLAN tag in the 802.1Q protocol, and implements an independent Pause mechanism for each priority traffic. , PFC has a fast response speed, can quickly alleviate network congestion, and has obvious effects on network surge or short-term congestion. However, due to the characteristics of the protocol, PFC can only be used in a small range, and it does not fundamentally solve the network Congestion problem, for long-term congestion, there will still be packet loss. The joint use of the two protocols can temporarily relieve network congestion through PFC, and QCN uses PFC to alleviate the time for it to fundamentally solve the congestion problem.

Through the comprehensive application of the above two standards, the network congestion problem can be effectively solved and packet loss can be reduced. However, in practical applications, when these two mechanisms are used together, it is difficult to set the trigger thresholds of these two mechanisms, which can easily lead to protocol failure and even network packet loss. Figure 4 is a schematic diagram of the joint application of PFC and QCN in the prior art. As shown in Figure 4, the core network equipment E supports QCN and PFC. When the trigger threshold of PFC is set low, then PFC will act in advance and trigger the PFC mechanism. to A, B, C, D, and F, which will lead to the failure of the QCN protocol. When encountering long-term congestion, the PFC mechanism will cause congestion to spread or even packet loss.

In the prior art, there is a solution to set the trigger threshold of PFC higher, and the threshold of QCN is set relatively lower, and try to ensure that QCN acts before PFC. This solution also has a problem: the queue detected by the QCN mechanism , is to aggregate the traffic of multiple ingress ports. As shown in Figure 4, one QCN of the core network device E has an egress port corresponding to 3 ingress ports. Usually, the cache of the egress port is larger than the cache of the ingress port. Assume that the cache of the egress port 500K, each inbound port cache is 100K, QCN acts on the outbound port, set its trigger threshold to 20% of the cache, that is, 100k, PFC acts on the ingress port, set its trigger threshold to 80% of the cache, that is, 80K, only When the sum of a certain priority queue buffer of three ingress ports is greater than 100K and each ingress port buffer is less than 80K (for example, all reach 34K), QCN takes effect before PFC. If the sum of the two ingress ports is less than 20K, then the ingress port greater than 80K will trigger PFC first, causing the QCN protocol to fail. If it is congested for a long time, it will cause congestion diffusion and packet loss. It can be seen that the problem of congestion diffusion and packet loss caused by triggering PFC first and then QCN protocol failure can not be well solved through threshold configuration.

Contents of the invention

The present invention provides an Ethernet congestion control method and device to solve the problem of congestion diffusion and packet loss caused by triggering PFC first and then QCN protocol failure after threshold configuration in the prior art cannot be solved.

The present invention provides an Ethernet congestion control method, comprising:

Turn off the ingress port of the core network equipment with the congestion detection function and trigger the priority-based flow control PFC mechanism through the threshold;

Detect whether the packet forwarded by the incoming port is a congestion notification message CNM, and generate a PFC message according to the CNM if the packet is determined to be a CNM;

Forward the CNM through the ingress port, and notify the peer device to suspend the data transmission of the corresponding queue according to the PFC message.

Preferably, when the edge device connected to the terminal determines that the terminal does not support the Quantized Congestion Notification Protocol QCN, it also includes: the edge device detects in a predetermined manner whether the message forwarded by its own ingress port is CNM, and when it is determined that the message is In the case of CNM, a PFC message is generated according to the CNM, and the terminal is notified to suspend data transmission of the corresponding queue according to the PFC message.

The present invention also provides an Ethernet congestion control device, comprising:

The closing module is used to close the ingress port of the core network equipment with the congestion detection function and trigger the priority-based flow control PFC mechanism through the threshold;

The first detection generation module is used to detect whether the packet forwarded by the incoming port is a congestion notification message CNM, and when it is determined that the packet is a CNM, generates a PFC message according to the CNM;

The sending module is configured to forward the CNM through the ingress port, and notify the peer device to suspend the data transmission of the corresponding queue according to the PFC message.

Preferably, the Ethernet congestion control device further includes: a second detection generation module, configured to detect the message forwarded by its own ingress port in a predetermined manner when it is determined that the terminal connected to itself does not support the quantized congestion notification protocol QCN Whether it is CNM, if it is determined that the message is CNM, generate a PFC message according to the CNM, and notify the terminal to suspend the data transmission of the corresponding queue according to the PFC message.

The beneficial effects of the present invention are as follows:

The PFC with corresponding priority is triggered by the CNM message, which solves the problem that the threshold configuration in the prior art cannot solve the problem of congestion diffusion and packet loss caused by the failure of the QCN protocol after triggering the PFC first. When the QCN mechanism generates a CNM message each time, The PFC with the corresponding priority of the port will be triggered through the back pressure port. PFC can quickly respond and alleviate network congestion. QCN instructs the terminal to adjust the corresponding flow rate through the CNM message, fundamentally solving the congestion problem quickly and effectively.

Description of drawings

FIG. 1 is a schematic diagram of a data center network architecture in the prior art;

Fig. 2 is a schematic diagram of the working principle of QCN in the prior art;

Fig. 3 is a schematic diagram of the working principle of PFC in the prior art;

Fig. 4 is a schematic diagram of the joint application of PFC and QCN in the prior art;

Fig. 5 is the flowchart of the Ethernet congestion control method of the embodiment of the present invention;

Fig. 6 is the detailed processing flowchart of the Ethernet congestion control method of the embodiment of the present invention;

FIG. 7 is a schematic diagram of a network architecture according to an embodiment of the present invention;

Fig. 8 is a schematic structural diagram of an Ethernet congestion control device according to an embodiment of the present invention.

Detailed ways

In order to solve the problem of congestion spread and packet loss caused by triggering PFC first and then QCN protocol failure in the prior art through threshold configuration, the present invention provides an Ethernet congestion control method and device, which can effectively solve the two problems in the network. If two protocols are used at the same time, the protocol will fail, which will cause packet loss. The present invention will be described in further detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain the present invention, not to limit the present invention.

method embodiment

According to an embodiment of the present invention, a method for controlling Ethernet congestion is provided. FIG. 5 is a flow chart of the method for controlling congestion in Ethernet according to an embodiment of the present invention. As shown in FIG. 5 , the congestion control method for Ethernet according to an embodiment of the present invention The method includes the following processing:

Step 501, close the ingress port of the core network equipment with the congestion detection function and trigger the priority-based flow control PFC mechanism through the threshold, that is, close the PFC initiator function. Wherein, the core network equipment with the congestion detection function has the function of triggering the PFC through the CNM message at the ingress port.

Step 502, detecting whether the packet forwarded by the incoming port is a congestion notification message CNM, and if the packet is determined to be a CNM, generating a PFC message according to the CNM;

The key fields contained in the CNM and PFC messages involved in step 502 and their meanings will be described in detail below.

Key fields contained in CNM and their meanings:

1. CN-TAG: For the frame carrying CN-TAG, directly extract its CN-TAG. For the data frame not carrying CN-TAG, this field is filled with 0.

2. CNM PDU:

Version: all 0, the receiver ignores it and does not process it;

Reserved: all 0, ignored by the receiving end, and not processed;

Quantized feedback: The Fb value calculated by the congestion detection point (CP) is used to instruct the terminal RP to adjust the rate;

CPID: uniquely identifies a CP in CDN;

Qoffset(signed integer): Indicates the cpQoffset value of the CP in units of 64octets.

QDelta(signed integer): Indicates the cpQDelta value of the CP in units of 64octets.

Encapsulated priority: The priority value of the data frame that triggers the CNM message.

Encapsulated D-mac: The destination MAC address of the data frame that triggers the CNM message;

Encapsulated MSDU length: Indicates the length of the encapsulated MSDU field;

encapsulated MSDU: a maximum of 64 octets, including the first part of the data frame data unit mac_service_data_unit that triggers the CNM message.

The key fields contained in the PFC message and their meanings:

1. Destination Address: the destination address, which can be 01-80-C2-00-00-01;

2. Source Address: the source address, which can be the address of the sender, and the Ethertype is 88-08;

3. The control opcode is 01-01 to indicate the PFC frame;

4. The lower 8 bits of the Priority_enable_vector field correspond to each priority respectively, and are used to indicate whether the time field of each subsequent priority is valid;

5. The time[n] field indicates the length of time for each priority traffic to stop sending.

Specifically, step 502 needs to perform the following processing:

Step 1, detect the source media access control MAC address of the message forwarded by the ingress port, and judge whether the source MAC address of the message is the MAC address of the self-equipment;

Step 2, if the judgment is yes, then judge whether the protocol data unit type of the message identifies the message as CNM;

Step 3. If the judgment is yes, it is determined that the message is CNM.

That is to say, in step 1-step 3, when the port forwards the data message, the source address of the message is monitored. Whether the source MAC address of the message is its own MAC address, that is, to determine whether the message is sent by itself; for the message whose source address is its own MAC address, according to whether the "PDU TYPE" field contained in the CNM is 0X22e7( 0X22e7 is the CNM mark), to judge whether it is CNM, if it is judged to be yes, then start the mechanism of triggering PFC by CNM.

Step 4, in the case of determining that the message is CNM, according to the encapsulation priority carried in the CNM, determine the priority corresponding to the tentative indication in the PFC message;

Step 5. Determine the time length of the suspension indication in the PFC message according to the field used to indicate the degree of congestion carried in the CNM.

That is to say, in step 4-step 5, it is necessary to analyze the CNM message, trigger the generation of the corresponding priority PAUSE indication of PFC according to the encapsulation priority carried by it, and according to the information used to indicate the degree of congestion carried in the CNM PDU Field indicating the duration of the pause. Specifically, according to the "Encapsulated priority" field in the CNM, determine the priority queue of the PFC mechanism, and set the "priority_enable_vector" field in the PFC message; according to the "QntzFb" field in the CNM, determine the duration of the corresponding priority pause, And set the "time(n)" field in the PFC message.

Step 503, forward the CNM through the ingress port, and notify the peer device to suspend the data transmission of the corresponding queue according to the PFC message. That is to say, in step 503, the CNM message is normally forwarded on the port, and the technical solution of the embodiment of the present invention does not affect the QCN mechanism.

The processing flow of the technical solution of the embodiment of the present invention will be described in detail below in conjunction with the accompanying drawings. FIG. 6 is a detailed processing flow chart of the Ethernet congestion control method of the embodiment of the present invention. As shown in FIG. 6 , it includes the following processing:

Step 601 , at the ingress port of the core network device that starts the QCN mechanism, close the PFCinitiator function of the port, and start the function of triggering the PFC mechanism through the CNM. Among them, the PFC initiator function is a mechanism to trigger PFC by judging the buffer threshold of the ingress port;

Step 602, the port that starts this function monitors the source MAC of its forwarded message;

Step 603, judging whether the message source address is its own MAC address, if so, then execute step 604, otherwise go to step 607;

Step 604, judge the message message PDU type, if it is 0x22e7, then prove that the message is CNM, execute step 605, otherwise go to step 607;

Step 605, start the mechanism of triggering the PFC through the CNM message of the QCN, and construct the PFC message according to the encapsulation information of the CNM message. This processing should not affect the normal forwarding of CNM messages on ports;

Step 606, using the corresponding queue of the PFC message pause generated in step 605;

Step 607, the data message is not a CNM message, and it is processed according to the normal forwarding process.

In practical applications, when the edge device connected to the terminal determines that the terminal does not support the quantized congestion notification protocol QCN, the PFC mechanism can be triggered at the edge of the QCN network, including the following processing: the edge device detects the information forwarded by its ingress port in a predetermined way If the message is CNM, if it is determined that the message is CNM, a PFC message is generated according to the CNM, and the terminal is notified to suspend the data transmission of the corresponding queue according to the PFC message. Wherein, the aforementioned predetermined method is: the edge device judges whether the protocol data unit type of the packet identifies whether the packet is CNM, and if it judges yes, determines that the packet is CNM. That is to say, the edge device does not need to determine whether the CNM is sent by itself.

The above processing is mainly to deal with the situation that the terminal does not support QCN. In the above situation, it is only necessary to move the function of the ingress port in the technical solution of the embodiment of the present invention to the edge of the QCN network (the network device directly connected to the terminal). Figure 7 is a schematic diagram of the network architecture of the embodiment of the present invention. Under the network architecture shown in Figure 7, assuming that A does not support QCN, that is, A cannot recognize CNM messages, then the mechanism of triggering PFC through QCN is activated on the ingress port of device D to solve the congestion problem.

In the following, the technical solution of the embodiment of the present invention will be illustrated with reference to FIG. 7 .

Under the network architecture shown in Figure 7, E is the core network device configured with the congestion detection function. The QCN mechanism sets the congestion detection point CP on its outbound port. The CP performs congestion detection on queues with a priority of 1. E The ingress ports of all have enabled the function of triggering PFC through the QCN, and the original ingress port threshold triggers the PFC mechanism to be disabled. In the embodiment of the present invention, it is assumed that the network congestion is caused by device A, and the CP point of the egress port of device E detects congestion. , then a CNM message containing priority 1 is formed, and the original path backpressures to device A to notify it to reduce the data transmission rate of the relative priority queue. The ingress port of device E detects the forwarded packets processed by it. The PDU type field judges that the message is a CNM message, then parses the CNM to generate a PFC message. In the PFC message, the priority_enable_vector priority is 1 and the corresponding bit position is set. The time length of time (1) is set according to the degree of congestion, and the PFC mechanism is started. Notify D to suspend the data transmission of the queue with priority 1.

In the embodiment of the present invention, if device A does not support QCN, then D analyzes the CNM it receives, and judges whether the field "PDU type" in CNM is 0x22e7, and if so, confirms that the message is CNM, according to CNM Generate a PFC message to notify A to suspend the data transmission of the queue with priority 1.

It can be seen from the above description that the embodiment of the present invention effectively solves the problem of the validity of the protocol jointly used by QCN and PFC. When the core network entity is congested, the egress port first detects the congestion situation, and creates a CNM message according to the congestion situation. CNM The message will be back-pressed to the corresponding terminal through the ingress port, and the ingress port will trigger the PFC mechanism through the identification and analysis of the CNM, and pause the corresponding priority queue. The congestion diffusion problem caused by the PFC mechanism will eventually be resolved with the entry into force of QCN, which can fundamentally solve the congestion problem quickly and effectively.

Device embodiment

According to an embodiment of the present invention, an Ethernet congestion control device is provided. FIG. 8 is a schematic structural diagram of an Ethernet congestion control device according to an embodiment of the present invention. As shown in FIG. 8 , the Ethernet congestion control device according to an embodiment of the present invention The device includes: a closing module 80, a first detection generating module 82, and a sending module 84, and each module of the embodiment of the present invention will be described in detail below.

The closing module 80 is used to close the ingress port of the core network equipment with the congestion detection function and trigger the priority-based flow control PFC mechanism through the threshold, that is, close the PFC initiator function.

The first detection generation module 82 is used to detect whether the packet forwarded by the incoming port is a congestion notification message CNM, and when it is determined that the packet is a CNM, generates a PFC message according to the CNM;

The key fields contained in the CNM and PFC messages involved in the first detection generation module 82 and their meanings will be described in detail below.

Key fields contained in CNM and their meanings:

1. CN-TAG: For the frame carrying CN-TAG, directly extract its CN-TAG. For the data frame not carrying CN-TAG, this field is filled with 0.

2. CNM PDU:

Version: all 0, the receiver ignores it and does not process it;

Reserved: all 0, ignored by the receiving end, and not processed;

Quantized feedback: The Fb value calculated by the congestion detection point (CP) is used to instruct the terminal RP to adjust the rate;

CPID: uniquely identifies a CP in CDN;

Qoffset(signed integer): Indicates the cpQoffset value of the CP in units of 64octets.

QDelta(signed integer): Indicates the cpQDelta value of the CP in units of 64octets.

Encapsulated priority: The priority value of the data frame that triggers the CNM message.

Encapsulated D-mac: The destination MAC address of the data frame that triggers the CNM message;

Encapsulated MSDU length: Indicates the length of the encapsulated MSDU field;

encapsulated MSDU: a maximum of 64 octets, including the first part of the data frame data unit mac_service_data_unit that triggers the CNM message.

The key fields contained in the PFC message and their meanings:

1. Destination Address: the destination address, which can be 01-80-C2-00-00-01;

2. Source Address: the source address, which can be the address of the sender, and the Ethertype is 88-08;

3. The control opcode is 01-01 to indicate the PFC frame;

4. The lower 8 bits of the Priority_enable_vector field correspond to each priority respectively, and are used to indicate whether the time field of each subsequent priority is valid;

5. The time[n] field indicates the length of time for each priority traffic to stop sending.

Specifically, the first detection generation module 82 specifically includes:

The first judging submodule is used to detect the source media access control MAC address of the message forwarded by the ingress port, and judge whether the source MAC address of the message is the MAC address of its own device;

The second judging submodule is used to determine whether the protocol data unit type of the message identifies the message as CNM when the first judging submodule judges as yes;

The determining submodule is used to determine that the message is CNM when the second judging submodule judges as yes;

When the port forwards a data packet, the first detection generation module 82 needs to monitor the source address of the packet. In practical applications, the first judging submodule can judge the packet according to the "SA=CP bridge address" field included in the CNM. Whether the source MAC address of the text is its own MAC address, that is, judge whether the message is sent by itself; for the message whose source address is its own MAC address, the second judging submodule is based on the "PDU TYPE" field contained in the CNM Whether it is 0X22e7 (0X22e7 is a CNM mark) to judge whether it is CNM, if it is judged as yes, then determine that the submodule determines that the message is CNM, and the mechanism of triggering PFC by CNM can be started.

The first generation submodule is used to determine the priority corresponding to the tentative indication in the PFC message according to the encapsulation priority carried in the CNM;

The second generating submodule is used to determine the time length of the suspension indication in the PFC message according to the field used to indicate the degree of congestion carried in the CNM.

The first detection generation module 82 also needs to parse the CNM message, trigger the generation of the PFC corresponding priority PAUSE indication according to the encapsulation priority carried by it, and indicate the pause according to the field for indicating the degree of congestion carried in the CNM PDU length of time. Specifically, the first generation submodule determines the priority queue for the PFC mechanism according to the "Encapsulated priority" field in the CNM, and sets the "priority_enable_vector" field in the PFC message; field, determine the duration of the corresponding priority pause, and set the "time(n)" field in the PFC message.

The sending module 84 is configured to forward the CNM through the ingress port, and notify the peer device to suspend the data transmission of the corresponding queue according to the PFC message. That is to say, the CNM message is normally forwarded on the port, and the technical solution of the embodiment of the present invention does not affect the QCN mechanism.

The specific flowchart of the above processing can be understood with reference to FIG. 6 .

In practical applications, when the edge device connected to the terminal determines that the terminal does not support the quantized congestion notification protocol QCN, the second detection generation module in the device can trigger the PFC mechanism at the edge of the QCN network to detect its own incoming traffic in a predetermined manner. Whether the message forwarded by the port is CNM, if it is determined that the message is CNM, generate a PFC message according to the CNM, and notify the terminal to suspend the data transmission of the corresponding queue according to the PFC message. Wherein, the aforementioned predetermined method is: judging whether the protocol data unit type of the message identifies whether the message is CNM, and if it is judged to be yes, then determining that the message is CNM. That is to say, the second detection generating module does not need to judge whether the CNM is sent by itself.

The above processing is mainly to deal with the situation that the terminal does not support QCN. In the above situation, it is only necessary to move the function of the ingress port in the technical solution of the embodiment of the present invention to the edge of the QCN network (the network device directly connected to the terminal). Under the network architecture shown in Figure 7, it is assumed that A does not Support QCN, that is, if A cannot recognize CNM messages, then the ingress port of device D starts the mechanism of triggering PFC through QCN to solve the congestion problem.

In the following, the technical solution of the embodiment of the present invention will be illustrated with reference to FIG. 7 .

Under the network framework shown in Figure 7, E is the core network equipment (the Ethernet congestion control device described in the embodiment of the present invention) configured with the congestion detection function, and the QCN mechanism sets the congestion detection point CP at its outgoing port, The CP performs congestion detection on queues with a priority of 1. The ingress ports of E all enable the function of triggering PFC through the QCN, and the original ingress port threshold triggers the PFC mechanism to be disabled. As a result of A, the CP point of the egress port of device E detects congestion, and a CNM message containing priority 1 is formed, and the original path backpressures to device A, instructing it to reduce the data transmission rate of the relative priority queue, and the ingress port of device E Detect the forwarding packet processed by it. When the message is judged to be a CNM message according to the source address and the PDU type field, the CNM is parsed to generate a PFC message. In the PFC message, the priority_enable_vector priority is 1 and the corresponding bit position is set, time (1) The time length is set according to the degree of congestion, the PFC mechanism is started, and D is notified to suspend the data transmission of the queue with priority 1.

In the embodiment of the present invention, if device A does not support QCN, then D analyzes the CNM it receives, and judges whether the field "PDU type" in CNM is 0x22e7, and if so, confirms that the message is CNM, according to CNM Generate a PFC message to notify A to suspend the data transmission of the queue with priority 1.

To sum up, the embodiment of the present invention triggers the PFC of the corresponding priority through the CNM message, which solves the problem that the threshold configuration in the prior art cannot solve the problem of congestion diffusion and packet loss caused by the failure of the QCN protocol after the PFC is triggered first. Every time the QCN mechanism generates a CNM message, it will trigger the PFC of the corresponding priority of the port through the back pressure port. PFC can quickly respond to and alleviate network congestion. Resolve congestion problems quickly and efficiently.

Although preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, and therefore, the scope of the present invention should not be limited to the above-described embodiments.

Claims (8)

1. an Ethernet jamming control method, is characterized in that, comprising:

Close the equipment of the core network inbound port passing threshold triggering with congestion detection function machine-processed based on the Flow Control PFC of priority;

Whether the message detecting the forwarding of described inbound port is congestion notification message CNM, when determining that described message is described CNM, generates PFC message according to described CNM; Wherein, whether the message that the described inbound port of described detection forwards is that congestion notification message CNM comprises: detect the source MAC address of the described message that described inbound port forwards, and judges that whether the source MAC of described message is the MAC Address of equipment of itself; If the judgment is Yes, then judging whether the protocol Data Unit type of described message identifies described message is CNM; If the judgment is Yes, then determine that described message is CNM;

Forward described CNM by described inbound port, and notify that opposite equip. suspends the data transmission of respective queue according to described PFC message.

2. the method for claim 1, is characterized in that, described method also comprises:

When the edge device be connected with terminal determines that described terminal is not supported to quantize congestion notification agreement QCN, whether the message that the inbound port that described edge device detects self in a predefined manner forwards is described CNM, when determining that described message is described CNM, generate described PFC message according to described CNM, and notify that described terminal suspends the data transmission of respective queue according to described PFC message.

3. method as claimed in claim 1 or 2, is characterized in that, generates PFC message comprise according to described CNM:

According to the encapsulation priority of carrying in described CNM, determine the priority corresponding to tentative instruction in described PFC message;

According to the field being used to indicate Congestion Level SPCC of carrying in described CNM, determine the time span suspending instruction described in described PFC message.

4. method as claimed in claim 2, it is characterized in that, described predetermined way is:

It is CNM that described edge device judges whether the protocol Data Unit type of described message identifies described message, if the judgment is Yes, then determines that described message is CNM.

5. an Ethernet congestion control device, is characterized in that, comprising:

Closing module, machine-processed based on the Flow Control PFC of priority for closing the equipment of the core network inbound port passing threshold triggering with congestion detection function;

First detects generation module, and whether the message forwarded for detecting described inbound port is congestion notification message CNM, and when determining that described message is described CNM, generates PFC message according to described CNM; Described first detects generation module specifically comprises: first judges submodule, and the source MAC address for the described message forwarded described inbound port detects, and judges that whether the source MAC of described message is the MAC Address of equipment of itself; Second judges submodule, and for when described first judges that submodule is judged as YES, then judging whether the protocol Data Unit type of described message identifies described message is CNM; Determine submodule, for when described second judges that submodule is judged as YES, determine that described message is CNM;

Sending module, for forwarding described CNM by described inbound port, and notifies that opposite equip. suspends the data transmission of respective queue according to described PFC message.

6. device as claimed in claim 5, it is characterized in that, described device also comprises:

Second detects generation module, for not supporting in the terminal determining to be connected with self to quantize congestion notification agreement QCN, whether the message that the inbound port detecting self in a predefined manner forwards is described CNM, when determining that described message is described CNM, generate described PFC message according to described CNM, and notify that described terminal suspends the data transmission of respective queue according to described PFC message.

7. device as claimed in claim 5, is characterized in that, described first detects generation module specifically comprises:

First generates submodule, for according to the encapsulation priority of carrying in described CNM, determines the priority corresponding to tentative instruction in described PFC message;

Second generates submodule, for according to the field being used to indicate Congestion Level SPCC of carrying in described CNM, determines the time span suspending instruction described in described PFC message.

8. device as claimed in claim 6, it is characterized in that, described predetermined way is: judging whether the protocol Data Unit type of described message identifies described message is CNM, if the judgment is Yes, then determines that described message is CNM.