WO2015000357A1 - 拥塞控制方法、设备及系统 - Google Patents

拥塞控制方法、设备及系统 Download PDF

Info

Publication number
WO2015000357A1
WO2015000357A1 PCT/CN2014/079907 CN2014079907W WO2015000357A1 WO 2015000357 A1 WO2015000357 A1 WO 2015000357A1 CN 2014079907 W CN2014079907 W CN 2014079907W WO 2015000357 A1 WO2015000357 A1 WO 2015000357A1
Authority
WO
WIPO (PCT)
Prior art keywords
port
data packet
sent
source device
sink device
Prior art date
Application number
PCT/CN2014/079907
Other languages
English (en)
French (fr)
Inventor
戈文敏
严哲峰
王戎
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP14820452.2A priority Critical patent/EP3018868B1/en
Publication of WO2015000357A1 publication Critical patent/WO2015000357A1/zh
Priority to US14/983,184 priority patent/US10419349B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/17—Interaction among intermediate nodes, e.g. hop by hop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes

Definitions

  • the present invention relates to a wireless communication technology, and in particular, to a congestion control method, device, and system.
  • BACKGROUND OF THE INVENTION Content Centric Networking (CCN) believes that future networks should be based on direct content-based naming and routing.
  • CCN Content Centric Networking
  • the CCN network uses a flow control protocol that relies on the user request drive mode. This flow control protocol triggers continuous packet acquisition based on consecutive packet requests. Since the nodes in the CCN network have caching capabilities, the data received by the requester may come from the data source or from the cache of some nodes on the request path. Such packets of the same content are received in a variety of ways, for example, from a plurality of different nodes, with different Round Trip Time (RTT). In this way, the CCN network node is prone to a large amount of bursty traffic.
  • RTT Round Trip Time
  • Embodiments of the present invention provide a congestion control method, device, and system for timely and accurate congestion control of a CCN network node when a large amount of burst traffic occurs on a CCN network node.
  • an embodiment of the present invention provides a congestion control method, including: receiving, by a source device, a local anti-congestion response message sent by a sink device, where the local anti-congestion response message is the sink end The device sends, after determining that the length of the buffer data in the port sending queue of the second port corresponding to the first port in the sink device exceeds a threshold;
  • the source device suspends the data packet that needs to be sent to the second port by using the first port.
  • the source device is configured to suspend a data packet that is to be sent to the second port by using the first port, and includes: The source device sets the state of the port sending queue of the first port to an anti-congestion state; when the state of the port sending queue of the first port is an anti-congestion state, the source device acquires a pending data packet.
  • a data packet where the time to live refers to a lifetime of a request packet of the data packet received from the sink device.
  • the method further includes:
  • the source device receives, by using the first port, a local normal response message sent by the sink device through the second port, where the local normal response message is that the sink device determines the second
  • the length of the buffered data in the port sending queue of the port does not exceed the threshold and is sent to the first port by sending the local anti-congestion response message;
  • the source device restores the state of the port sending queue of the first port to a normal sending state.
  • the method further includes:
  • the source device receives, by using the first port, a request packet sent by the sink device through the second port, and if a data packet corresponding to the request packet is locally stored, detecting the first port Whether the length of the cached data in the port sending queue exceeds a threshold, and if yes, storing information of the data packet, a lifetime TTL corresponding to the data packet, and port information of the first port to the pending data packet In the table PCT, if it is not exceeded, detecting whether the state of the port sending queue of the first port is the anti-congestion state, and if so, the information of the data packet and the lifetime TTL corresponding to the data packet, And storing the port information of the first port into the PCT; if not, directly storing the data packet in a port sending queue of the first port.
  • an embodiment of the present invention provides a source device, including:
  • a message receiving module configured to receive, by using the first port, a local anti-congestion response message sent by the sink device, where the local anti-congestion response message is that the sink device determines the first device and the first device After the length of the buffered data in the port sending queue of the second port corresponding to the port exceeds the threshold, the sending queue cache management module is configured to suspend the data packet to be sent to the second port by using the first port. send.
  • the sending queue cache management module is specifically configured to: Setting a state of the port sending queue of the first port to an anti-congestion state;
  • a time-to-live TTL corresponding to the data packet sent by the first port to the second port in the PCT.
  • the data is sent to the second port by using the first port.
  • the packet where the lifetime is the lifetime of the request packet of the data packet received from the sink device.
  • the message receiving module is further configured to receive the sink by using the first port a local normal response message sent by the terminal device by using the second port, where the local normal response message is that the sink device determines that the length of the buffered data in the port sending queue of the second port does not exceed a threshold and Sending, by the first port, the local anti-congestion response message;
  • the sending queue cache management module is further configured to restore the state of the port sending queue of the first port to a normal sending state.
  • the message receiving module is further configured to receive the sink device by using the first port a request packet sent by the second port; correspondingly, the source device further includes:
  • a processing module configured to: if a data packet corresponding to the request packet is stored locally, detecting whether a length of the cached data in the port sending queue of the first port exceeds a threshold, and if yes, information about the data packet The time-to-live TTL corresponding to the data packet, and the port information of the first port are stored in the pending data packet table PCT; if not, the state of the port sending queue of the first port is detected as The anti-congestion state, if yes, storing information of the data packet, a lifetime TTL corresponding to the data packet, and port information of the first port in the PCT; if not, directly The data packet is stored in a port transmission queue of the first port.
  • an embodiment of the present invention provides a network system, including at least one source device, and at least one sink device;
  • the sink device is configured to send a ground anti-congestion response message after determining that the length of the buffer data in the port sending queue of the second port corresponding to the first port in the sink device exceeds a threshold;
  • the source device is configured to receive, by using the first port, a local anti-congestion response message sent by the sink device, and delay sending the data packet that needs to be sent to the second port by using the first port.
  • the source device is configured to suspend a data packet that needs to be sent to the second port by using the first port, Specifically, the source device is configured to set a state of the port sending queue of the first port to an anti-congestion state. In the state, when the status of the port sending queue of the first port is anti-congested, the pending packet table is obtained.
  • a time-to-live TTL corresponding to the data packet sent by the first port to the second port in the PCT.
  • the data is sent to the second port by using the first port.
  • the packet where the lifetime is the lifetime of the request packet of the data packet received from the sink device.
  • the sink device is further configured to: The length of the cached data in the queue does not exceed the threshold, and the local anti-congestion response message is sent to the first port, and the local normal response message is sent;
  • the source device is further configured to: receive, by using the first port, the local normal response message sent by the sink device by using the second port, and restore the state of the port sending queue of the first port to Normal transmission status.
  • the sink device is further configured to send a request packet by using the second port;
  • the source device is further configured to receive, by using the first port, the request packet sent by the sink device, and if a data packet corresponding to the request packet is locally stored, detecting the first port Whether the length of the cached data in the port sending queue exceeds a threshold, and if yes, storing information of the data packet, a lifetime TTL corresponding to the data packet, and port information of the first port to the pending data packet In the table PCT, if not exceeded, detecting whether the state of the port sending queue of the first port is the anti-congestion state, and if so, the information of the data packet and the lifetime TTL corresponding to the data packet, And storing the port information of the first port into the PCT; if not, directly storing the data packet in a port sending queue of the first port.
  • the sink device after determining that the length of the buffered data in the port sending queue of the second port exceeds the threshold, the sink device sends the first port corresponding to the second port to the source device.
  • the local anti-congestion response message informs the source device that the sink device is in a congested state and stops receiving the data packet sent by the source device to the second port.
  • the source device receives the local anti-congestion response message sent by the sink device.
  • the end device sets the state of the port sending queue of the first port corresponding to the second port to an anti-congestion state, and the source device delays sending the data packet to be sent to the second port through the first port in the anti-congestion state.
  • Embodiment 1 is a flowchart of Embodiment 1 of a congestion control method according to the present invention
  • Embodiment 2 is a flowchart of Embodiment 2 of a congestion control method according to the present invention
  • Embodiment 3 is a flowchart of Embodiment 3 of a congestion control method according to the present invention.
  • Embodiment 4 is a flowchart of Embodiment 4 of a congestion control method according to the present invention.
  • FIG. 5 is a schematic diagram of functions of a source device in the embodiment shown in FIG. 4;
  • Embodiment 5 is a flowchart of Embodiment 5 of a congestion control method according to the present invention.
  • FIG. 7 is a schematic diagram of functions of a sink device of the embodiment shown in FIG. 6;
  • Embodiment 8 is a schematic structural diagram of Embodiment 1 of a congestion control source device according to the present invention.
  • Embodiment 4 of a congestion control source device is a schematic structural diagram of Embodiment 4 of a congestion control source device according to the present invention.
  • Embodiment 1 of a CCN network system according to the present invention
  • FIG. 11 is a schematic structural diagram of an embodiment of a CCN network node device according to the present invention.
  • the technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention.
  • the embodiments are a part of the embodiments of the invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.
  • FIG. 1 is a flowchart of Embodiment 1 of a congestion control method according to the present invention.
  • the execution entity of this embodiment is a source device in a CCN network node, and the device can be implemented by software and/or hardware.
  • the solution of this embodiment is applied to the CCN network node, and can timely and accurately control the CCN network node when a large amount of burst traffic occurs on the CCN network node.
  • the method in this embodiment may include:
  • Step 101 The source device receives the local anti-congestion response message sent by the sink device through the first port.
  • the CCN network is essentially a point-to-multipoint network.
  • the CCN network relies on the user-driven drive mode flow control protocol. This flow control protocol triggers continuous packet acquisition based on continuous packet requests.
  • the CCN network node is the same. It can be used as both a source device and a sink device. Since the CCN network node has a caching function, the data packets received by the sink device may come to the data source, or may come to the cache of some network nodes on the request path, that is, the data packets received by the sink device may come. To multiple different source devices.
  • the local anti-congestion response message is sent by the sink device after determining that the length of the buffer data in the port sending queue of the second port corresponding to the first port in the sink device exceeds a threshold.
  • the port sending queue buffer of the second port is filled with the data packet, and the local port is sent to the first port corresponding to the second port in the source device to send a local anti-congestion response message.
  • the first port of the device suspends sending a data packet to the second port of the corresponding sink device.
  • Step 102 The source device temporarily suspends the data packet that needs to be sent to the second port through the first port. Specifically, after the first port corresponding to the second port in the source device receives the local anti-congestion response message sent by the sink device, the sink device is in a congested state, and the source device is the second device. The status of the port sending queue of the first port corresponding to the port is set to the anti-congestion state. In this case, the data packet sent to the second port through the first port is temporarily suspended, which reduces the packet traffic of the sink device. .
  • the sink device in this embodiment can also serve as a source device at the same time, and the source device can also serve as a sink device at the same time.
  • the sink device after determining that the length of the buffered data in the port sending queue of the second port exceeds the threshold, the sink device sends a local anti-congestion response message to the first port corresponding to the second port in the source device, and notifies the notification. If the source device is in a congested state and stops receiving the data packet sent by the source device to the second port, the source device sets the state of the port sending queue of the first port corresponding to the second port to anti-congestion. In the anti-congestion state, the source device suspends the data packet that needs to be sent to the second port through the first port, and implements congestion control when the CCN network node device has a large amount of packet traffic, and solves the CCN. When a large amount of bursty packet traffic occurs in a network node, it causes serious network congestion.
  • Embodiment 2 is a flowchart of Embodiment 2 of a congestion control method according to the present invention.
  • the source device is sent to the second port through the first port in an anti-congestion state.
  • the data packet of the port is suspended, which can be implemented in the following ways:
  • Step 201 The source device sets the state of the port sending queue of the first port to an anti-congestion state.
  • the TTL of the request packet is stored, for example, in a Pending Interest Table (PIT), and the PIT carries the TTL in order to limit the amount of PIT cache information.
  • PIT Pending Interest Table
  • the request packet information of the timeout is cleared from the PIT table. Therefore, the corresponding packet that arrives later will be discarded.
  • Step 203 When the TTL is reached, the source device sends a data packet to the second port by using the first port. Specifically, when the TTL is reached, the source device must send a data packet to the second port through the first port, regardless of whether the length of the buffer data in the port sending queue of the second port of the sink device exceeds a threshold, that is, Whether the second port of the sink device is in a congested state, otherwise the record in the PCT will be deleted when the TTL is exceeded.
  • a threshold that is, Whether the second port of the sink device is in a congested state, otherwise the record in the PCT will be deleted when the TTL is exceeded.
  • the state of the port sending queue of the first port is set to the anti-congestion state by the source device, and when the state of the port sending queue of the first port is the anti-congestion state, the source device acquires the PCT to pass the first The TTL corresponding to the data packet sent by the port to the second port. When the TTL is reached, the source device sends a data packet to the second port through the first port to ensure that the data packet is sent to the second port during its lifetime to avoid the source. Packet loss in the end device.
  • Embodiment 3 is a flowchart of Embodiment 3 of a congestion control method according to the present invention. Based on the method embodiment shown in FIG. 1 and FIG. 2, the method in this embodiment further includes:
  • Step 301 The source device receives, by using the first port, a local normal response message sent by the sink device through the second port.
  • the local normal response message is sent by the sink device after determining that the length of the cached data in the port transmission queue of the second port does not exceed a threshold and sends a local anti-congestion response message to the first port.
  • Step 302 The source device restores the state of the port sending queue of the first port to a normal sending state.
  • the sink device after determining that the length of the buffered data in the port sending queue of the second port does not exceed the threshold, the sink device sends a local anti-congestion response message to the first port corresponding to the second port in the source device, The sink device sends a local normal response message to the first port corresponding to the second port in the source device, and notifies the source device that the sink device can receive the data packet when the sink device is in a non-congested state, and the source device uses the first port.
  • the state of the port sending queue is restored to the normal sending state, which prevents the source device from being congested in time.
  • FIG. 4 is a flowchart of Embodiment 4 of a congestion control method according to the present invention.
  • FIG. 5 is a schematic diagram of functions of a source device in the embodiment shown in FIG.
  • the execution entity of this embodiment is a source device in a CCN network node, and the device can be implemented by software and/or hardware.
  • the solution of this embodiment is applied in a CCN network node.
  • the method in this embodiment may include:
  • Step 401 The source device receives the request packet sent by the sink device through the first port.
  • Step 402 Detect whether there is a data packet corresponding to the request packet in the local storage, and if yes, go to step 403; if not, the processing flow of the subsequent request packet is the same as the existing CCN network node processing flow.
  • Step 403 Detect whether the length of the buffer data in the port sending queue of the first port exceeds a threshold, and if yes, go to step 405; if no, go to step 404.
  • Step 404 Detect whether the status of the port sending queue of the first port is an anti-congestion state, and if yes, go to step 405; if no, go to step 406.
  • the length of the buffered data in the port sending queue of the first port does not exceed the threshold, it is detected whether the state of the port sending queue of the first port is an anti-congestion state, and if not the anti-congestion state, the data packet is directly stored. Go to the port of the first port to send the queue and send it out, otherwise go to step 405.
  • Step 405 Store the information of the data packet, the time-to-live TTL corresponding to the data packet, and the port information of the first port in the PCT.
  • the information of the corresponding data packet is stored in the PCT, and the data packet is not processed, and the process returns to step 401. If the length of the cached data in the port sending queue of the port is not exceeded, the packet is stored in the port sending queue of the port, and step 404 is performed. Otherwise, the time-to-live TTL corresponding to the data packet is deleted. Records in the PCT.
  • the information of the data packet, the lifetime TTL corresponding to the data packet, and the port information of the first port are stored in the PCT, and the data packet is stored in the port sending queue of the first port, and the data is The packet is suspended for transmission, as described in the embodiment shown in FIG.
  • the structure of the PCT can be, for example, the following table structure:
  • the v3/s0 name column stores the name information of the pending data packet
  • the TTL column stores the TTL of the packet corresponding to the request packet in the PIT table
  • the port number field stores the port number of the port sending queue where the packet is located, or the port number to be sent to the port sending queue.
  • Step 406 Store the data packet in a port sending queue of the first port.
  • the source device receives the request packet sent by the sink device through the second port through the first port, and if the data packet corresponding to the request packet is stored locally, detecting the port sending queue of the first port of the source device Whether the length of the cached data exceeds the threshold.
  • the information of the data packet, the lifetime TTL corresponding to the data packet, and the port information of the first port are stored in the PCT, and the data packet is not processed; if not, the data packet is not processed; Further detecting whether the status of the port sending queue of the first port of the source device is an anti-congestion state, and if so, storing the information of the data packet, the lifetime TTL corresponding to the data packet, and the port information of the first port in the PCT, The data packet is stored in the port sending queue of the first port and suspended for transmission; if not, the data packet is directly stored in the port sending queue of the second port and sent, and a large number of data packets can be generated on the CCN network node device. When traffic is flowing, hop-by-hop congestion control is performed in time.
  • FIG. 6 is a flowchart of Embodiment 5 of a congestion control method according to the present invention
  • FIG. 7 is a schematic diagram of functions of a sink device according to the embodiment shown in FIG. 6.
  • the execution entity of this embodiment is a sink device in a CCN network node, and the device can be implemented by software and/or hardware.
  • the solution of this embodiment is applied in a CCN network node.
  • the method in this embodiment includes:
  • Step 601 The sink device receives the data packet sent by the source device by using the second port.
  • Step 602 Detect whether the information of the request packet corresponding to the data packet is stored in the local PIT, and if yes, go to step 603; if no, go to step 604.
  • the PIT may store, for example, the TTL of the request packet, the second port of the request packet, and the name prefix of the request packet, so as to perform subsequent operations on the response packet of the request packet. If there is no matching request packet information in the local PIT, the packet is discarded.
  • Step 603 Detect whether the status of the port sending queue of the second port is an anti-congestion state. If yes, go to step 605; if no, go to step 606.
  • Step 604 Discard the data packet.
  • step 601 continue to receive the data packet.
  • Step 605 Store the information of the data packet, the TTL corresponding to the data packet, and the port information of the second port into the PCT.
  • the PCT can be used, for example, to record information about delayed packets in the port transmission queue.
  • Step 606 The sink device detects whether the length of the buffer data in the port sending queue of the second port exceeds a threshold. If yes, step 607 is performed; if no, step 608 is performed.
  • Step 607 The sink device sends a local anti-congestion response message message to the first port corresponding to the second port in the source device.
  • the source device sets the state of the port sending queue of the first port corresponding to the second port to an anti-congestion state, and the source device is in an anti-congestion state.
  • the data packet to be sent to the second port through the first port is temporarily suspended, and then proceeds to step 606.
  • Step 608 The sink device detects whether a local anti-congestion response message is sent to the first port corresponding to the second port in the source device. If yes, go to step 609. If no, go to step 6010.
  • the sink device detects whether the local anti-congestion is sent to the first port corresponding to the second port in the source device.
  • the message message is acknowledged, and the sink device is notified that the sink device is in a non-congested state, and the data packet sent by the source device can be received.
  • Step 609 The sink device sends a local normal response message to the first port corresponding to the second port in the source device, so that the source device restores the state of the port sending queue of the first port to the normal sending state.
  • the local normal response message/local anti-congestion response message recorder can be used, for example, to record that the sink device detects the length of the buffer data in the port transmission queue of the second port after the threshold value exceeds the threshold.
  • the first port corresponding to the second port in the end device sends the port information of the local anti-congestion response message, so that the port sending queue of the second port returns to normal, and then sends a local normal response to the first port corresponding to the second port.
  • Message message The source device is notified that the source device is in a non-congested state by sending a local normal response message, so that the source device restores the state of the port sending queue of the first port to the normal sending state, and timely controls the source device.
  • the data packet can prevent the source device from buffering a large number of data packets and prevent congestion from occurring at an early stage.
  • Step 6010 Forward the data packet to the port sending queue of the port matched by the PIT, delete the record of the corresponding request packet information in the PIT, and store the data packet.
  • the data packet is forwarded to the port sending queue of the port matched by the PIT.
  • the corresponding record in the PIT is deleted, indicating that the request for the request packet has been completed at this time, and the data packet is stored in the local data store (Content Store, referred to as CS).
  • the transmit queue cache manager can be used, for example, to perform the operations of step 603, step 606, and to set and record the port send queue status.
  • the Forward Information Base (FIB) is used to record the information of the forwarded request packet, such as the second port, name prefix, and so on.
  • step 608 and step 6010 can be performed simultaneously.
  • the sink device detects that the length of the buffered data in the port sending queue of the second port does not exceed the threshold, and sends a local anti-congestion response message to the first port corresponding to the second port in the source device.
  • the end device sends a local normal response message to the first port corresponding to the second port in the source device, and notifies the source device that the sink device can receive the data packet in the non-congested state, so that the source device sends the first port.
  • the status of the port sending queue is restored to the normal sending state, which can prevent the source device from being congested in time.
  • FIG. 8 is a schematic structural diagram of Embodiment 1 of a congestion control source device according to the present invention.
  • the source device 80 of this embodiment may include: a message receiving module 801 and a sending queue buffer management module 802, where The module 801 is configured to receive a local anti-congestion response message of the first port that is sent by the sink device, where the local anti-congestion response message is a second port that is determined by the sink device to determine the first port in the sink device. After the length of the buffered data in the port sending queue exceeds the threshold, the sending queue cache management module 802 is configured to suspend the data packet to be sent to the second port through the first port.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 1 , and the implementation principle and the technical effect are similar, and details are not described herein again.
  • the transmission queue cache management module 802 is specifically configured to:
  • the pending packet table PCT is obtained.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 2, and the implementation principle and the technical effect are similar, and details are not described herein again.
  • the message receiving module 801 is further configured to receive the sink device through the first port through the second The local normal response message sent by the port, where the local normal response message is that the sink device determines that the length of the buffered data in the port sending queue of the second port does not exceed the threshold and sends a local anti-congestion response message to the first port.
  • the sending queue cache management module 802 is further configured to restore the state of the port sending queue of the first port to a normal sending state.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 3, and the implementation principle and the technical effect are similar, and details are not described herein again.
  • FIG. 9 is a schematic structural diagram of Embodiment 4 of a congestion control source device according to the present invention. As shown in FIG. 9, on the basis of Embodiments 1 to 3 of the congestion control source device, the message receiving module 801 is further configured to pass The first port receives the request packet sent by the sink device through the second port.
  • the source device 80 of this embodiment may further include: a processing module 803, configured to: if the data packet corresponding to the request packet is stored locally, detecting whether the length of the buffer data in the port sending queue of the first port exceeds a threshold, if If yes, the information of the data packet, the time-to-live TTL corresponding to the data packet, and the port information of the first port are stored in the pending data packet table PCT; if not, the state of the port sending queue of the first port is detected as Anti-congestion status, if yes, store the information of the data packet, the lifetime TTL corresponding to the data packet, and the port information of the first port in the PCT; if not, directly store the data packet to the port sending queue of the first port in.
  • a processing module 803 configured to: if the data packet corresponding to the request packet is stored locally, detecting whether the length of the buffer data in the port sending queue of the first port exceeds a threshold, if If yes, the information of the data packet, the time-to-live
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 4, and the implementation principle and the technical effect are similar, and details are not described herein again.
  • the network system of this embodiment includes: at least one source device 80 and at least one sink device 90, wherein the sink device 90, And sending an anti-congestion response message after determining that the length of the buffered data in the port sending queue of the second port corresponding to the first port in the sink device exceeds a threshold, and the source device 80 is configured to pass the first port.
  • Receiving a local anti-congestion response message sent by the sink device, and sending the first port through the first port The data packet of the second port is suspended, and the implementation principle and technical effects are similar to those of the method embodiment shown in FIG. 1 , and details are not described herein again.
  • the source device 80 is configured to send the first port to the second port.
  • the data packet is suspended for transmission. Specifically, the following implementation manners can be adopted:
  • the source device 80 is configured to set a state of the port sending queue of the first port to an anti-congestion state, and obtain a pending data packet when the state of the port sending queue of the first port is an anti-congestion state.
  • a time-to-live TTL corresponding to the data packet sent by the first port to the second port in the PCT.
  • the data is sent to the second port by using the first port.
  • the packet where the lifetime is the lifetime of the request packet of the data packet received from the sink device.
  • the sink device 90 is further configured to cache data in a port sending queue of the second port. The length does not exceed the threshold, and the local anti-congestion response message is sent to the first port, and a local normal response message is sent;
  • the source device 80 is further configured to: receive, by using the first port, the local normal response message sent by the sink device by using the second port, and restore the state of the port sending queue of the first port. For normal sending status.
  • the implementation of the network system of the present embodiment is similar to the technical solution of the method embodiment shown in FIG. 3, and details are not described herein again.
  • the sink device 90 is further configured to send a request packet by using the second port;
  • the source device 80 is further configured to receive, by using the first port, the request packet sent by the sink device, and if the data packet corresponding to the request packet is locally stored, detecting the first port Whether the length of the cached data in the port sending queue exceeds a threshold, and if yes, storing the information of the data packet, the lifetime TTL corresponding to the data packet, and the port information of the first port to the pending data. If the packet is not over, the state of the port sending queue of the first port is detected as the anti-congestion state, and if so, the information of the data packet and the lifetime TTL corresponding to the data packet are And storing the port information of the first port into the PCT; if not, directly using the data packet Stored in the port send queue of the first port.
  • the implementation of the network system of the present embodiment is similar to the technical solution of the method embodiment shown in FIG. 4, and details are not described herein again.
  • FIG. 11 is a schematic structural diagram of an embodiment of a CCN network node device according to the present invention.
  • the CCN network node device 110 provided in this embodiment includes a processor 1101 and a memory 1102.
  • the memory 1102 stores execution instructions and data.
  • the processor 1101 communicates with the memory 1102.
  • the processor 1101 calls the execution instructions in the memory 1102 for performing the operations in any of the method embodiments of the present invention.
  • the device of this embodiment may be used to implement the technical solution of the congestion control method provided by any embodiment of the present invention, and the implementation principle and technical effects thereof are similar, and details are not described herein again.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the steps including the foregoing method embodiments are performed; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

提供一种拥塞控制方法、设备及系统。该拥塞控制方法包括：源端设备通过第一端口接收宿端设备发送的本地防拥塞应答消息，其中，所述本地防拥塞应答消息是所述宿端设备在确定所述宿端设备中与所述第一端口对应的第二端口的端口发送队列中缓存数据的长度超过阈值后发送的；所述源端设备对需通过所述第一端口发往所述第二端口的数据包进行暂缓发送。实现了对CNN网络中节点的数据包进行及时准确地逐跳拥塞控制。

Description

拥塞控制方法、 设备及系统 技术领域 本发明实施例涉及无线通信技术，尤其涉及一种拥塞控制方法、设备及系统。 背景技术 内容为中心网络（ Content Centric Networking, 简称 CCN )认为未来网络 应该以直接基于内容的命名和路由为基础。 作为 CCN的一个公共的准则， 内 容是由其名字进行唯一辨识、 路由以及获取的， 而与内容的位置无关。
目前对 CCN网络的传输控制机制研究较少。 CCN网络釆用依靠用户请求 驱动模式的流控协议， 这种流控协议基于连续的包请求， 触发连续的数据包 获取。 由于 CCN网络中节点具备緩存功能， 所以请求者接收到的数据可能来 自数据源处， 也可能来自请求路径上某些节点的緩存。 这样相同内容的数据 包便以多种多样的方式被接收， 例如， 从多个不同的节点， 以不同的往返时 间 （Round Trip Time, 简称 RTT ) 被接收。 这样 CCN网络节点就会容易出现 大量的突发流量， CCN网络节点上的緩存区被突发数据包填满了， 再出现的 数据包只能被丟弃， 造成严重的网络拥塞。 发明内容 本发明实施例提供一种拥塞控制方法、 设备及系统， 以解决 CCN网络节点出 现大量的突发流量时， 对 CCN网络节点进行及时准确的拥塞控制。
第一方面， 本发明实施例提供一种拥塞控制方法， 包括： 源端设备通过第一 端口接收宿端设备发送的本地防拥塞应答消息， 其中， 所述本地防拥塞应答消息 是所述宿端设备在确定所述宿端设备中与所述第一端口对应的第二端口的端口发 送队列中緩存数据的长度超过阈值后发送的；
所述源端设备对需通过所述第一端口发往所述第二端口的数据包进行暂緩发 送。
结合第一方面， 在第一方面的第一种可能的实现方式中， 所述源端设备对需 通过所述第一端口发往所述第二端口的数据包进行暂緩发送， 包括： 所述源端设备将所述第一端口的端口发送队列的状态设置为防拥塞状态； 当所述第一端口的端口发送队列的状态为防拥塞状态时， 所述源端设备获取 待定数据包表 PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的 生存时间 TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述 数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包 的生存时间。
结合第一方面、 第一方面的第一种可能的实现方式， 在第一方面的第二种可 能的实现方式中， 所述方法还包括：
所述源端设备通过所述第一端口接收所述宿端设备通过所述第二端口发送的 本地正常应答消息， 其中， 所述本地正常应答消息是所述宿端设备在确定所述第 二端口的端口发送队列中緩存数据的长度没有超过阈值且向所述第一端口发送过 所述本地防拥塞应答消息而发送的；
所述源端设备将所述第一端口的端口发送队列的状态恢复为正常发送状态。 结合第一方面的第一、 第二种可能的实现方式， 在第一方面的第三种可能的 实现方式中， 所述方法还包括：
所述源端设备通过所述第一端口接收所述宿端设备通过所述第二端口发送的 请求包， 若本地存储有与所述请求包对应的数据包， 则检测所述第一端口的端口 发送队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包的信息、 所 述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述待定数 据包表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的状态是否为 所述防拥塞状态，若是，则将所述数据包的信息、所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直接将所述数据包 存储到所述第一端口的端口发送队列中。
第二方面， 本发明实施例提供一种源端设备， 包括：
消息接收模块， 用于通过第一端口接收宿端设备发送的本地防拥塞应答消息， 其中， 所述本地防拥塞应答消息是所述宿端设备在确定所述宿端设备中与所述第 一端口对应的第二端口的端口发送队列中緩存数据的长度超过阈值后发送的； 发送队列緩存管理模块， 用于将需通过所述第一端口发往所述第二端口的数 据包进行暂緩发送。
结合第二方面， 在第二方面的第一种可能的实现方式中， 所述发送队列緩存 管理模块具体用于： 将所述第一端口的端口发送队列的状态设置为防拥塞状态；
当所述第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包表
PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的生存时间 TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包的生存时间。
结合第二方面、 第二方面的第一种可能的实现方式， 在第二方面的第二种可 能的实现方式中， 所述消息接收模块， 还用于通过所述第一端口接收所述宿端设 备通过所述第二端口发送的本地正常应答消息， 其中， 所述本地正常应答消息是 所述宿端设备在确定所述第二端口的端口发送队列中緩存数据的长度没有超过阈 值且向所述第一端口发送过所述本地防拥塞应答消息而发送的；
所述发送队列緩存管理模块， 还用于将所述第一端口的端口发送队列的状态 恢复为正常发送状态。
结合第二方面的第一、 二种可能的实现方式， 在第二方面的第三种可能的实 现方式中， 所述消息接收模块， 还用于通过所述第一端口接收所述宿端设备通过 所述第二端口发送的请求包； 相应地， 所述源端设备还包括：
处理模块， 用于若本地存储有与所述请求包对应的数据包， 则检测所述第一 端口的端口发送队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包 的信息、 所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到 所述待定数据包表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的 状态是否为所述防拥塞状态， 若是， 则将所述数据包的信息、 所述数据包对应的 生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直 接将所述数据包存储到所述第一端口的端口发送队列中。
第三方面， 本发明实施例提供一种网络系统， 包括至少一个源端设备， 以及 至少一个宿端设备；
所述宿端设备， 用于在确定所述宿端设备中与所述第一端口对应的第二端口 的端口发送队列中緩存数据的长度超过阈值后发送地防拥塞应答消息；
所述源端设备， 用于通过第一端口接收所述宿端设备发送的本地防拥塞应答 消息， 将需通过所述第一端口发往所述第二端口的数据包进行暂緩发送。
结合第三方面， 在第三方面的第一种可能的实现方式中， 所述源端设备， 用 于将需通过所述第一端口发往所述第二端口的数据包进行暂緩发送， 具体为： 所述源端设备， 用于将所述第一端口的端口发送队列的状态设置为防拥塞状 态， 当所述第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包表
PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的生存时间 TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包的生存时间。
结合第三方面、 第三方面的第一种可能的实现方式， 在第三方面的第二种可 能的实现方式中， 所述宿端设备， 还用于在确定所述第二端口的端口发送队列中 緩存数据的长度没有超过阈值且向所述第一端口发送过所述本地防拥塞应答消 息， 发送本地正常应答消息；
所述源端设备， 还用于通过所述第一端口接收所述宿端设备通过所述第二端 口发送的所述本地正常应答消息， 将所述第一端口的端口发送队列的状态恢复为 正常发送状态。
结合第三方面的第一、 二种可能的实现方式， 在第三方面的第三种可能的实 现方式中， 所述宿端设备， 还用于通过所述第二端口发送请求包；
所述源端设备， 还用于通过所述第一端口接收所述宿端设备发送的所述请求 包， 若本地存储有与所述请求包对应的数据包， 则检测所述第一端口的端口发送 队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包的信息、 所述数 据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述待定数据包 表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的状态是否为所述 防拥塞状态， 若是， 则将所述数据包的信息、 所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直接将所述数据包 存储到所述第一端口的端口发送队列中。
本发明实施例拥塞控制方法、 设备及系统， 宿端设备若在确定第二端口的端 口发送队列中緩存数据的长度超过阈值后， 则向源端设备中与第二端口对应的第 一端口发送本地防拥塞应答消息， 通知源端设备此时宿端设备处于拥塞状态， 停 止接收源端设备向第二端口发送的数据包， 则源端设备接收宿端设备发送的本地 防拥塞应答消息， 源端设备将与第二端口对应的第一端口的端口发送队列的状态 设置为防拥塞状态， 源端设备在防拥塞状态下对需通过第一端口发往第二端口的 数据包进行暂緩发送， 实现了在 CCN网络节点设备出现大量数据包流量时， 及时 地进行逐跳地拥塞控制， 解决了 CCN网络节点中出现大量突发数据包流量时， 会 造成严重的网络拥塞的问题。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例 或现有技术描述中所需要使用的附图作一简单地介绍， 显而易见地， 下面描述中 的附图是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性 劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明拥塞控制方法实施例一的流程图；
图 2为本发明拥塞控制方法实施例二的流程图；
图 3为本发明拥塞控制方法实施例三的流程图；
图 4为本发明拥塞控制方法实施例四的流程图；
图 5为图 4所示实施例的的源端设备的功能示意图；
图 6为本发明拥塞控制方法实施例五的流程图；
图 7为图 6所示实施例的的宿端设备的功能示意图；
图 8为本发明拥塞控制源端设备实施例一的结构示意图；
图 9为本发明拥塞控制源端设备实施例四的结构示意图；
图 10为本发明 CCN网络系统实施例一的结构示意图；
图 11为本发明 CCN网络节点设备实施例的结构示意图。 具体实施方式 为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发明实 施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所 描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实 施例， 本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施 例， 都属于本发明保护的范围。
图 1为本发明拥塞控制方法实施例一的流程图。 本实施例的执行主体为 CCN 网络节点中的源端设备， 该设备可以通过软件和 /或硬件实现。 本实施例的方案应 用在 CCN网络节点中， 能够在 CCN网络节点出现大量突发流量时， 对 CCN网络 节点进行及时准确的拥塞控制。 如图 1所示， 本实施例的方法可以包括：
步骤 101、 源端设备通过第一端口接收宿端设备发送的本地防拥塞应答消息。 CCN网络本质是点到多点的网络， CCN网络依靠用户请求驱动模式的流控协 议， 这种流控协议基于连续的包请求， 触发连续的数据包获取， CCN网络节点同 时既可作为源端设备也可作为宿端设备。 由于 CCN网络节点具备緩存功能， 所以 宿端设备接收到的数据包可能来至数据源处， 也可能来至请求路径上某些网络节 点的緩存， 也即宿端设备接收到的数据包可能来至多个不同的源端设备。
具体地， 所述本地防拥塞应答消息是所述宿端设备在确定所述宿端设备中与 所述第一端口对应的第二端口的端口发送队列中緩存数据的长度超过阈值后发送 的， 说明此时第二端口的端口发送队列緩存已经被数据包填满了， 处于拥塞状态， 则向源端设备中与第二端口对应的第一端口发送本地防拥塞应答消息消息， 此时 源端设备的第一端口暂緩向对应的宿端设备的第二端口发送数据包。
步骤 102、 源端设备对需通过第一端口发往第二端口的数据包进行暂緩发送。 具体地， 源端设备中与第二端口对应的第一端口接收到宿端设备发送的本地 防拥塞应答消息消息后， 说明此时宿端设备已经处于拥塞状态， 则源端设备将与 第二端口对应的第一端口的端口发送队列的状态设置为防拥塞状态， 此时对需通 过第一端口发往第二端口的数据包进行暂緩发送， 这样就会减少宿端设备的数据 包流量。
需要说明的是， 本实施例中的宿端设备同时也可作为源端设备， 源端设备同 时也可作为宿端设备。
本实施例， 宿端设备若在确定第二端口的端口发送队列中緩存数据的长度超 过阈值后， 则向源端设备中与第二端口对应的第一端口发送本地防拥塞应答消息 消息， 通知源端设备此时宿端设备处于拥塞状态， 停止接收源端设备向第二端口 发送的数据包， 则源端设备将与第二端口对应的第一端口的端口发送队列的状态 设置为防拥塞状态， 源端设备在防拥塞状态下对需通过第一端口发往第二端口的 数据包进行暂緩发送， 实现了在 CCN网络节点设备出现大量数据包流量时， 进行 拥塞控制， 解决了 CCN网络节点中出现大量突发数据包流量时， 会造成严重的网 络拥塞的问题。
图 2为本发明拥塞控制方法实施例二的流程图， 如图 2所示， 在图 1所示的 方法实施例一中源端设备在防拥塞状态下对需通过第一端口发往第二端口的数据 包进行暂緩发送， 具体可以通过以下方式实现：
步骤 201、 源端设备将第一端口的端口发送队列的状态设置为防拥塞状态。 步骤 202、 当第一端口的端口发送队列的状态为防拥塞状态时， 源端设备获取 待定数据包表 （ Pending Content Table, 简称 PCT ) 中需通过第一端口发往第二端 口的数据包对应的生存时间 （ Time To Live , 简称 TTL ) 。 具体地， PCT中存储有数据包对应的 TTL, 其中， 生存时间 TTL, 是指从所 述宿端设备接收的所述数据包的请求包的生存时间。 请求包的 TTL例如是存储在 待定请求包表 (Pending Interest Table, 简称 PIT)中， 而 PIT为了限制 PIT緩存信息 数量， 其中的请求包都携带 TTL, 超时的请求包信息会从 PIT表中清除， 这样后 续再到来的相应的数据包就会被丢弃。
步骤 203、 在到达 TTL时， 源端设备通过第一端口向第二端口发送数据包。 具体地， 在到达 TTL时， 源端设备必须通过第一端口向第二端口发送数据包， 无论此时宿端设备的第二端口的端口发送队列中緩存数据的长度是否超过阈值， 也即无论宿端设备的第二端口是否处于拥塞状态， 否则超过 TTL时， PCT中的记 录会被删除。
本实施例， 通过源端设备将第一端口的端口发送队列的状态设置为防拥塞状 态， 当第一端口的端口发送队列的状态为防拥塞状态时， 源端设备获取 PCT中欲 通过第一端口发往第二端口的数据包对应的 TTL, 在到达 TTL时， 源端设备通过 第一端口向第二端口发送数据包， 保证数据包在其生存时间内发往第二端口， 以 免在源端设备中丢包。
图 3为本发明拥塞控制方法实施例三的流程图， 在图 1、 2所示的方法实施例 基础上， 进一步地， 本实施例的方法还包括：
步骤 301、源端设备通过第一端口接收宿端设备通过第二端口发送的本地正常 应答消息。
具体地， 本地正常应答消息是宿端设备在确定第二端口的端口发送队列中緩 存数据的长度没有超过阈值且向第一端口发送过本地防拥塞应答消息而发送的。
步骤 302、 源端设备将第一端口的端口发送队列的状态恢复为正常发送状态。 本实施例， 宿端设备在确定第二端口的端口发送队列中緩存数据的长度没有 超过阈值后， 并且曾向源端设备中与第二端口对应的第一端口发送过本地防拥塞 应答消息消息， 则宿端设备向源端设备中与第二端口对应的第一端口发送本地正 常应答消息消息， 通知源端设备此时宿端设备处于非拥塞状态可以接收数据包， 源端设备将第一端口的端口发送队列的状态恢复为正常发送状态， 能够及时的防 止源端设备拥塞的发生。
图 4为本发明拥塞控制方法实施例四的流程图。 图 5为图 4所示实施例的源 端设备的功能示意图。 本实施例的执行主体为 CCN网络节点中的源端设备， 该设 备可以通过软件和 /或硬件实现。本实施例的方案应用在 CCN网络节点中。如图 4、 5所示， 在图 1、 2所示的方法实施例基础上， 进一步地， 本实施例的方法可以包 括：
步骤 401、 源端设备通过第一端口接收宿端设备发送的请求包。
步骤 402、 检测本地存储中是否有与请求包对应的数据包， 若是， 则转步骤 403 ; 若否， 则后续请求包的处理流程与现有的 CCN网络节点处理流程一样。
具体地， 如图 5所示， 例如可以检测 CS中是否有与请求包对应的数据包， 后 续请求包的处理流程如图 4虚线框内的流程与现有的 CCN网络节点处理流程一 样， 所涉及到的功能模块如图 5中所示， 此处不再赘述。
步骤 403、 检测第一端口的端口发送队列中緩存数据的长度是否超过阈值， 若 是， 则转步骤 405 ; 若否， 则转步骤 404。
具体地， 从哪个端口接收到请求包， 相应的数据包就从哪个端口发送出去， 这时就要检测第一端口的端口发送队列中緩存数据的长度是否超过阈值， 判断是 否处于拥塞状态， 如果处于拥塞状态则转步骤 405。
步骤 404、 检测第一端口的端口发送队列的状态是否为防拥塞状态， 若是， 则 转步骤 405 ; 若否， 则转步骤 406。
具体地， 检测到第一端口的端口发送队列中緩存数据的长度没有超过阈值， 则检测第一端口的端口发送队列的状态是否为防拥塞状态， 如果不是防拥塞状态， 则直接将数据包存储到第一端口的端口发送队列中并发送出去， 否则转步骤 405。
步骤 405、 将数据包的信息、 数据包对应的生存时间 TTL, 以及第一端口的端 口信息存储到 PCT中。
具体地， 如果第一端口的端口发送队列中緩存数据的长度超过阈值处于拥塞 状态， 就要把相应的数据包的信息存储在 PCT中， 此时对数据包不做处理， 返回 步骤 401中， 后续如果检测获知此端口的端口发送队列中緩存数据的长度没有超 过阈值， 再把数据包存储到此端口的端口发送队列中， 并执行步骤 404 , 否则超过 数据包对应的生存时间 TTL, 则删除 PCT中的记录。 如果处于防拥塞状态， 则将 数据包的信息、数据包对应的生存时间 TTL, 以及第一端口的端口信息存储到 PCT 中， 并把数据包存储到第一端口的端口发送队列中， 对数据包做暂緩发送处理， 如图 2所示实施例中所述。
PCT的结构例如可以是如下的表结构：
表 PCT
名字 TTL 端口号 /pare, com/ videos/Widget A. mpg/ 3ms 0
v3/s0 名字栏存储待定数据包的名字信息；
TTL栏存储数据包对应请求包在 PIT表中的 TTL;
端口号栏存储数据包所在端口发送队列的端口号、 或即将被发送到端口发送 队列的端口号。
步骤 406、 将数据包存储到第一端口的端口发送队列中。
本实施例， 源端设备通过第一端口接收宿端设备通过第二端口发送的请求包， 若本地存储有与请求包对应的数据包， 则检测源端设备的第一端口的端口发送队 列中緩存数据的长度是否超过阈值， 若超过， 则将数据包的信息、 数据包对应的 生存时间 TTL , 以及第一端口的端口信息存储到 PCT中 , 对数据包不做处理； 若 没有超过， 则进一步检测源端设备的第一端口的端口发送队列的状态是否为防拥 塞状态， 若是， 则将数据包的信息、 数据包对应的生存时间 TTL, 以及第一端口 的端口信息存储到 PCT中， 将数据包存储到第一端口的端口发送队列中并进行暂 緩发送； 若不是， 则直接将数据包存储到第二端口的端口发送队列中并发送， 能 够在 CCN网络节点设备出现大量数据包流量时， 及时进行逐跳地拥塞控制。
图 6为本发明拥塞控制方法实施例五的流程图， 图 7为图 6所示实施例的宿 端设备的功能示意图。 本实施例的执行主体为 CCN网络节点中的宿端设备， 该设 备可以通过软件和 /或硬件实现。本实施例的方案应用在 CCN网络节点中。如图 6、 7所示， 本实施例的方法包括：
步骤 601、 宿端设备通过第二端口接收源端设备发送的数据包。
步骤 602、 检测本地 PIT中是否存储有与数据包对应的请求包的信息， 若是， 则转步骤 603; 若否， 则转步骤 604。
具体地， 如图 6所示， PIT中例如可以存储请求包的 TTL、 发送请求包的第二 端口以及请求包的名字前缀等， 以便后续执行对请求包的响应数据包的操作。 如 果本地 PIT中没有与之匹配的请求包信息则丢弃此数据包。
步骤 603、 检测第二端口的端口发送队列的状态是否为防拥塞状态， 若是， 则 转步骤 605; 若否， 则转步骤 606。
具体地， 匹配到与数据包对应的请求包的信息之后， 检测第二端口的端口发 送队列的状态是否为防拥塞状态， 如果是的话， 则将数据包的信息、 数据包对应 的 TTL,以及第二端口的端口信息存储到 PCT中，进行暂緩发送；否则转步骤 606。 步骤 604、 丢弃数据包。
返回步骤 601 , 继续接收数据包。
步骤 605、 将数据包的信息、 数据包对应的 TTL , 以及第二端口的端口信息存 储到 PCT中。
如图 7所示， PCT例如可以用于记录端口发送队列中被延迟的数据包的相关 信息。
步骤 606、宿端设备检测第二端口的端口发送队列中緩存数据的长度是否超过 阈值， 若是， 则执行步骤 607; 若否， 则执行步骤 608。
步骤 607、宿端设备向源端设备中与第二端口对应的第一端口发送本地防拥塞 应答消息消息。
此时， 宿端设备已经处于拥塞状态， 并通知源端设备， 则源端设备将与第二 端口对应的第一端口的端口发送队列的状态设置为防拥塞状态， 源端设备在防拥 塞状态下对欲通过第一端口发往第二端口的数据包进行暂緩发送， 后续再继续执 行步骤 606。
步骤 608、宿端设备检测是否向源端设备中与第二端口对应的第一端口发送过 本地防拥塞应答消息消息， 若是， 则转步骤 609, 若否， 则转步骤 6010。
具体地， 如果宿端设备检测到第二端口的端口发送队列中緩存数据的长度没 有超过阈值， 则宿端设备检测是否向源端设备中与第二端口对应的第一端口发送 过本地防拥塞应答消息消息， 并通知此时宿端设备已经处于非拥塞状态， 可以接 收源端设备发来的数据包。
步骤 609、宿端设备向源端设备中与第二端口对应的第一端口发送本地正常应 答消息， 以使得源端设备将第一端口的端口发送队列的状态恢复为正常发送状态。
具体地， 如图 7所示， 本地正常应答消息 /本地防拥塞应答消息记录器例如可 以用于记录宿端设备在确定第二端口的端口发送队列中緩存数据的长度超过阈值 后时， 向源端设备中与第二端口对应的第一端口发送过本地防拥塞应答消息消息 的端口信息， 以便第二端口的端口发送队列恢复正常之后， 向与第二端口对应的 第一端口发送本地正常应答消息消息。 通过发送本地正常应答消息消息来通知源 端设备此时宿端设备处于非拥塞状态， 以使得源端设备将第一端口的端口发送队 列的状态恢复为正常发送状态， 及时控制源端设备中的数据包， 可以避免源端设 备緩存大量的数据包， 及早防止拥塞的发生。 步骤 6010、 将数据包转发到 PIT匹配的端口的端口发送队列中， 将 PIT中相 应的请求包信息的记录删除， 并存储数据包。
具体地， 如果此时第二端口的端口发送队列不是防拥塞状态， 并且第二端口 的端口发送队列中緩存数据的长度没有超过阈值， 则将数据包转发到 PIT匹配的 端口的端口发送队列中， 同时将 PIT中相应的记录删除， 表明此时已经完成了此 请求包的请求， 并将数据包存储在本地的数据包存储区 （Content Store, 简称 CS ) 中。
如图 7所示， 发送队列緩存管理器例如可以用于执行步骤 603、 步骤 606的操 作以及设置并记录端口发送队列状态。
图 7中转发信息库 （ Forward Information Base, 简称 FIB ) 用于记录被转发的 请求包的信息， 如第二端口、 名字前缀等。
需要说明的是， 步骤 608和步骤 6010可以同时执行。
本实施例， 宿端设备检测到第二端口的端口发送队列中緩存数据的长度没有 超过阈值， 并且曾向源端设备中与第二端口对应的第一端口发送过本地防拥塞应 答消息消息， 则宿端设备向源端设备中与第二端口对应的第一端口发送本地正常 应答消息消息， 通知源端设备此时宿端设备处于非拥塞状态可以接收数据包， 以 使得源端设备将第一端口的端口发送队列的状态恢复为正常发送状态， 能够及时 的防止源端设备拥塞的发生。
图 8为本发明拥塞控制源端设备实施例一的结构示意图， 如图 8所示， 本实 施例的源端设备 80可以包括： 消息接收模块 801和发送队列緩存管理模块 802, 其中， 消息接收模块 801 , 用于接收接收宿端设备发送的第一端口的本地防拥塞应 答消息， 其中， 所述本地防拥塞应答消息是宿端设备在确定宿端设备中与第一端 口对应的第二端口的端口发送队列中緩存数据的长度超过阈值后发送的； 发送队 列緩存管理模块 802, 用于将需通过第一端口发往第二端口的数据包进行暂緩发 送。
本实施例的装置， 可以用于执行图 1所示方法实施例的技术方案， 其实现原 理和技术效果类似， 此处不再赘述。
在本发明拥塞控制源端设备实施例二中， 在图 8所示实施例的基础上， 进一 步地， 所述发送队列緩存管理模块 802具体用于：
将第一端口的端口发送队列的状态设置为防拥塞状态；
当第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包表 PCT 中需通过第一端口发往第二端口的所述数据包对应的生存时间 TTL, 在到达 TTL 时， 通过第一端口向第二端口发送数据包， 其中， 生存时间 TTL, 是指从所述宿 端设备接收的所述数据包的请求包的生存时间。
本实施例的装置， 可以用于执行图 2所示方法实施例的技术方案， 其实现原 理和技术效果类似， 此处不再赘述。
在本发明拥塞控制源端设备实施例三中， 在拥塞控制源端设备实施例一、 二 的基础上， 进一步地， 消息接收模块 801 , 还用于通过第一端口接收宿端设备通过 第二端口发送的本地正常应答消息， 其中， 所述本地正常应答消息是宿端设备在 确定第二端口的端口发送队列中緩存数据的长度没有超过阈值且向第一端口发送 过本地防拥塞应答消息而发送的；
所述发送队列緩存管理模块 802 ,还用于将所述第一端口的端口发送队列的状 态恢复为正常发送状态。
本实施例的装置， 可以用于执行图 3所示方法实施例的技术方案， 其实现原 理和技术效果类似， 此处不再赘述。
图 9为本发明拥塞控制源端设备实施例四的结构示意图， 如图 9所示， 在拥 塞控制源端设备实施例一〜三的基础上， 进一步地， 消息接收模块 801 , 还用于通 过第一端口接收宿端设备通过第二端口发送的请求包。
本实施例的源端设备 80, 还可以包括： 处理模块 803 , 用于若本地存储有与 请求包对应的数据包， 则检测第一端口的端口发送队列中緩存数据的长度是否超 过阈值， 若超过， 则将数据包的信息、 数据包对应的生存时间 TTL, 以及第一端 口的端口信息存储到待定数据包表 PCT中； 若没有超过， 则检测第一端口的端口 发送队列的状态是否为防拥塞状态， 若是， 则将数据包的信息、 数据包对应的生 存时间 TTL, 以及第一端口的端口信息存储到 PCT中； 若不是， 则直接将数据包 存储到第一端口的端口发送队列中。
本实施例的装置， 可以用于执行图 4所示方法实施例的技术方案， 其实现原 理和技术效果类似， 此处不再赘述。
图 10为本发明 CCN网络系统实施例一的结构示意图， 如图 10所示， 本实施 例的网络系统包括： 至少一个源端设备 80和至少一个宿端设备 90 , 其中， 宿端设 备 90 , 用于在确定所述宿端设备中与所述第一端口对应的第二端口的端口发送队 列中緩存数据的长度超过阈值后发送地防拥塞应答消息， 源端设备 80用于通过第 一端口接收所述宿端设备发送的本地防拥塞应答消息， 将需通过所述第一端口发 往所述第二端口的数据包进行暂緩发送， 其实现原理和技术效果与图 1所示方法 实施例的技术方案类似， 此处不再赘述。
在本发明 CCN网络系统实施例二中， 在图 10所示实施例的基础上， 进一步 地， 所述源端设备 80, 用于将需通过所述第一端口发往所述第二端口的数据包进 行暂緩发送， 具体可以采用如下实现方式：
所述源端设备 80, 用于将所述第一端口的端口发送队列的状态设置为防拥塞 状态， 当所述第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包 表 PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的生存时间 TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包的生存时 间。
本实施例的网络系统， 其实现原理和技术效果与图 2所示方法实施例的技术 方案类似， 此处不再赘述。
在本发明 CCN网络系统实施例三中， 在系统实施例一、 二的基础上， 进一步 地， 所述宿端设备 90, 还用于在确定所述第二端口的端口发送队列中緩存数据的 长度没有超过阈值且向所述第一端口发送过所述本地防拥塞应答消息， 发送本地 正常应答消息；
所述源端设备 80, 还用于通过所述第一端口接收所述宿端设备通过所述第二 端口发送的所述本地正常应答消息， 将所述第一端口的端口发送队列的状态恢复 为正常发送状态。
本实施例的网络系统， 其实现原理和技术效果与图 3所示方法实施例的技术 方案类似， 此处不再赘述。
在本发明 CCN网络系统实施例四中， 在系统实施例一〜三的基础上， 进一步 地， 所述宿端设备 90, 还用于通过所述第二端口发送请求包；
所述源端设备 80, 还用于通过所述第一端口接收所述宿端设备发送的所述请 求包， 若本地存储有与所述请求包对应的数据包， 则检测所述第一端口的端口发 送队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包的信息、 所述 数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述待定数据 包表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的状态是否为所 述防拥塞状态， 若是， 则将所述数据包的信息、 所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直接将所述数据包 存储到所述第一端口的端口发送队列中。
本实施例的网络系统， 其实现原理和技术效果与图 4所示方法实施例的技术 方案类似， 此处不再赘述。
图 11为本发明 CCN网络节点设备实施例的结构示意图。 如图 11所示， 本实 施例提供的 CCN网络节点设备 110包括处理器 1101和存储器 1102。 其中， 存储 器 1102存储执行指令及数据， 当设备 110运行时， 处理器 1101与存储器 1102之 间通信， 处理器 1101调用存储器 1102中的执行指令， 用于执行本发明任意方法 实施例中的操作。
本实施例的设备， 可以用于执行本发明任意实施例所提供的拥塞控制方法的 技术方案， 其实现原理和技术效果类似， 此处不再赘述。
本领域普通技术人员可以理解： 实现上述各方法实施例的全部或部分步骤可 以通过程序指令相关的硬件来完成。 前述的程序可以存储于一计算机可读取存储 介质中。 该程序在执行时， 执行包括上述各方法实施例的步骤； 而前述的存储介 质包括： ROM、 RAM, 磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上各实施例仅用以说明本发明的技术方案， 而非对其限 制； 尽管参照前述各实施例对本发明进行了详细的说明， 本领域的普通技术人员 应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或者对其中 部分或者全部技术特征进行等同替换； 而这些修改或者替换， 并不使相应技术方 案的本质脱离本发明各实施例技术方案的范围。

Claims

权 利 要 求
1、 一种拥塞控制方法， 其特征在于， 包括：
源端设备通过第一端口接收宿端设备发送的本地防拥塞应答消息， 其中， 所 述本地防拥塞应答消息是所述宿端设备在确定所述宿端设备中与所述第一端口对 应的第二端口的端口发送队列中緩存数据的长度超过阈值后发送的；
所述源端设备对需通过所述第一端口发往所述第二端口的数据包进行暂緩发 送。
2、 根据权利要求 1所述的方法， 其特征在于， 所述源端设备对需通过所述第 一端口发往所述第二端口的数据包进行暂緩发送， 包括：
所述源端设备将所述第一端口的端口发送队列的状态设置为防拥塞状态； 当所述第一端口的端口发送队列的状态为防拥塞状态时， 所述源端设备获取 待定数据包表 PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的 生存时间 TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述 数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包 的生存时间。
3、 根据权利要求 1或 2所述的方法， 其特征在于， 所述方法还包括： 所述源端设备通过所述第一端口接收所述宿端设备通过所述第二端口发送的 本地正常应答消息， 其中， 所述本地正常应答消息是所述宿端设备在确定所述第 二端口的端口发送队列中緩存数据的长度没有超过阈值且向所述第一端口发送过 所述本地防拥塞应答消息而发送的；
所述源端设备将所述第一端口的端口发送队列的状态恢复为正常发送状态。
4、 根据权利要求 2或 3所述的方法， 其特征在于， 所述方法还包括： 所述源端设备通过所述第一端口接收所述宿端设备通过所述第二端口发送的 请求包， 若本地存储有与所述请求包对应的数据包， 则检测所述第一端口的端口 发送队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包的信息、 所 述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述待定数 据包表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的状态是否为 所述防拥塞状态，若是，则将所述数据包的信息、所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直接将所述数据包 存储到所述第一端口的端口发送队列中。
5、 一种源端设备， 其特征在于， 包括： 消息接收模块，用于通过第一端口接收宿端设备发送的本地防拥塞应答消息， 其中， 所述本地防拥塞应答消息是所述宿端设备在确定所述宿端设备中与所述第 一端口对应的第二端口的端口发送队列中緩存数据的长度超过阈值后发送的； 发送队列緩存管理模块， 用于将需通过所述第一端口发往所述第二端口的数 据包进行暂緩发送。
6、 根据权利要求 5所述的源端设备， 其特征在于， 所述发送队列緩存管理模 块具体用于：
将所述第一端口的端口发送队列的状态设置为防拥塞状态；
当所述第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包表 PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的生存时间
TTL , 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包的生存时 间。
7、 根据权利要求 5或 6所述的源端设备， 其特征在于，
所述消息接收模块， 还用于通过所述第一端口接收所述宿端设备通过所述第 二端口发送的本地正常应答消息， 其中， 所述本地正常应答消息是所述宿端设备 在确定所述第二端口的端口发送队列中緩存数据的长度没有超过阈值且向所述第 一端口发送过所述本地防拥塞应答消息而发送的；
所述发送队列緩存管理模块， 还用于将所述第一端口的端口发送队列的状态 恢复为正常发送状态。
8、 根据权利要求 6或 7所述的源端设备， 其特征在于， 所述消息接收模块， 还用于通过所述第一端口接收所述宿端设备通过所述第二端口发送的请求包； 相 应地， 所述源端设备还包括：
处理模块， 用于若本地存储有与所述请求包对应的数据包， 则检测所述第一 端口的端口发送队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包 的信息、 所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到 所述待定数据包表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的 状态是否为所述防拥塞状态， 若是， 则将所述数据包的信息、 所述数据包对应的 生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直 接将所述数据包存储到所述第一端口的端口发送队列中。
9、 一种网络系统， 其特征在于， 包括至少一个源端设备， 以及至少一个宿端 设备：
所述宿端设备， 用于在确定所述宿端设备中与所述第一端口对应的第二端口 的端口发送队列中緩存数据的长度超过阈值后发送地防拥塞应答消息；
所述源端设备， 用于通过第一端口接收所述宿端设备发送的本地防拥塞应答 消息， 将需通过所述第一端口发往所述第二端口的数据包进行暂緩发送。
10、 根据权利要求 9所述的网络系统， 其特征在于， 所述源端设备， 用于将 需通过所述第一端口发往所述第二端口的数据包进行暂緩发送， 具体为：
所述源端设备， 用于将所述第一端口的端口发送队列的状态设置为防拥塞状 态， 当所述第一端口的端口发送队列的状态为防拥塞状态时， 获取待定数据包表 PCT中需通过所述第一端口发往所述第二端口的所述数据包对应的生存时间
TTL, 在到达所述 TTL时， 通过所述第一端口向所述第二端口发送所述数据包， 其中， 所述生存时间， 是指从所述宿端设备接收的所述数据包的请求包的生存时 间。
11、 根据权利要求 9或 10所述的网络系统， 其特征在于，
所述宿端设备， 还用于在确定所述第二端口的端口发送队列中緩存数据的长 度没有超过阈值且向所述第一端口发送过所述本地防拥塞应答消息， 发送本地正 常应答消息；
所述源端设备， 还用于通过所述第一端口接收所述宿端设备通过所述第二端 口发送的所述本地正常应答消息， 将所述第一端口的端口发送队列的状态恢复为 正常发送状态。
12、 根据权利要求 10或 11所述的网络系统， 其特征在于，
所述宿端设备， 还用于通过所述第二端口发送请求包；
所述源端设备， 还用于通过所述第一端口接收所述宿端设备发送的所述请求 包， 若本地存储有与所述请求包对应的数据包， 则检测所述第一端口的端口发送 队列中緩存数据的长度是否超过阈值， 若超过， 则将所述数据包的信息、 所述数 据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述待定数据包 表 PCT中； 若没有超过， 则检测所述第一端口的端口发送队列的状态是否为所述 防拥塞状态， 若是， 则将所述数据包的信息、 所述数据包对应的生存时间 TTL, 以及所述第一端口的端口信息存储到所述 PCT中； 若不是， 则直接将所述数据包 存储到所述第一端口的端口发送队列中。
PCT/CN2014/079907 2013-07-03 2014-06-16 拥塞控制方法、设备及系统 WO2015000357A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP14820452.2A EP3018868B1 (en) 2013-07-03 2014-06-16 Congestion method, device and system
US14/983,184 US10419349B2 (en) 2013-07-03 2015-12-29 Congestion method, device and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310277336.8 2013-07-03
CN201310277336.8A CN104283808B (zh) 2013-07-03 2013-07-03 拥塞控制方法、设备及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/983,184 Continuation US10419349B2 (en) 2013-07-03 2015-12-29 Congestion method, device and system

Publications (1)

Publication Number Publication Date
WO2015000357A1 true WO2015000357A1 (zh) 2015-01-08

Family

ID=52143085

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/079907 WO2015000357A1 (zh) 2013-07-03 2014-06-16 拥塞控制方法、设备及系统

Country Status (4)

Country Link
US (1) US10419349B2 (zh)
EP (1) EP3018868B1 (zh)
CN (1) CN104283808B (zh)
WO (1) WO2015000357A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112751776A (zh) * 2019-10-30 2021-05-04 华为技术有限公司 拥塞控制方法和相关装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102384282B1 (ko) * 2017-06-09 2022-04-07 삼성전자주식회사 무선 통신 시스템에서 혼잡을 제어하기 위한 장치 및 방법
CN110968430A (zh) * 2018-09-28 2020-04-07 北京京东尚科信息技术有限公司 基于消息队列的处理方法和消息队列
CN109257770B (zh) * 2018-10-10 2022-05-06 京信网络系统股份有限公司 过载控制方法、装置、系统及设备
CN112751778A (zh) * 2019-10-30 2021-05-04 阿里巴巴集团控股有限公司 数据传输控制方法及装置，拥塞检测及装置，服务器系统
CN110971595B (zh) * 2019-11-22 2021-08-24 浙江中控技术股份有限公司 一种网络通信方法和系统
CN111865716B (zh) * 2020-06-30 2023-07-18 新华三信息技术有限公司 一种端口拥塞检测方法、装置、设备及机器可读存储介质
CN114915595B (zh) * 2022-03-11 2023-08-01 北京邮电大学 突发包装配方法和电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101253729A (zh) * 2005-10-11 2008-08-27 思科技术公司 后向拥塞通知的方法和设备
CN102025617A (zh) * 2010-11-26 2011-04-20 中兴通讯股份有限公司 以太网拥塞控制方法及装置
CN102223675A (zh) * 2011-06-08 2011-10-19 大唐移动通信设备有限公司 拥塞告警及处理方法、系统和设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100505675C (zh) 2004-01-08 2009-06-24 电子科技大学 一种基于蚂蚁算法的分布式自组网动态路由方法
US20060056308A1 (en) * 2004-05-28 2006-03-16 International Business Machines Corporation Method of switching fabric for counteracting a saturation tree occurring in a network with nodes
US9185036B2 (en) * 2005-03-23 2015-11-10 Alcatel Lucent Method and apparatus for flow control of data in a network
CN100505608C (zh) * 2007-01-19 2009-06-24 北京航空航天大学 一种适合卫星网络的自适应拥塞控制方法及系统
CN100536605C (zh) * 2007-02-28 2009-09-02 华为技术有限公司 无线通信网络中拥塞控制方法及其装置
US8218442B2 (en) * 2008-09-11 2012-07-10 Juniper Networks, Inc. Methods and apparatus for flow-controllable multi-staged queues
US8194543B2 (en) * 2008-12-18 2012-06-05 Intel Mobile Communications GmbH Methods of data traffic shaping, apparatus and wireless device
US8204060B2 (en) * 2009-01-30 2012-06-19 Palo Alto Research Center Incorporated Method and system for facilitating forwarding a packet in a content-centric network
KR101715080B1 (ko) 2011-06-09 2017-03-13 삼성전자주식회사 네임 기반의 네트워크 시스템에서 펜딩 테이블의 오버플로우를 방지하는 노드 장치 및 방법
US9013995B2 (en) * 2012-05-04 2015-04-21 Telefonaktiebolaget L M Ericsson (Publ) Congestion control in packet data networking

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101253729A (zh) * 2005-10-11 2008-08-27 思科技术公司 后向拥塞通知的方法和设备
CN102025617A (zh) * 2010-11-26 2011-04-20 中兴通讯股份有限公司 以太网拥塞控制方法及装置
CN102223675A (zh) * 2011-06-08 2011-10-19 大唐移动通信设备有限公司 拥塞告警及处理方法、系统和设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3018868A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112751776A (zh) * 2019-10-30 2021-05-04 华为技术有限公司 拥塞控制方法和相关装置

Also Published As

Publication number Publication date
CN104283808B (zh) 2019-03-26
US10419349B2 (en) 2019-09-17
EP3018868A4 (en) 2016-07-20
US20160134540A1 (en) 2016-05-12
EP3018868A1 (en) 2016-05-11
CN104283808A (zh) 2015-01-14
EP3018868B1 (en) 2019-01-09

Similar Documents

Publication Publication Date Title
WO2015000357A1 (zh) 拥塞控制方法、设备及系统
US9705808B2 (en) Flow aware buffer management for data center switches
JP7030815B2 (ja) 輻輳イベント中にメッセージを廃棄するための方法、システム、およびコンピュータ読取可能媒体
JP5967090B2 (ja) 通信システム、制御装置、ノードの制御方法およびプログラム
US9867068B2 (en) Wirespeed TCP session optimization for networks having radio segments
US20060203730A1 (en) Method and system for reducing end station latency in response to network congestion
US20060221825A1 (en) Congestion control network relay device and method
WO2016062106A1 (zh) 报文处理方法、装置及系统
JP5673841B2 (ja) データ通信装置，データ送信方法及び計算機システム
WO2020253488A1 (zh) 拥塞控制方法及装置、通信网络、计算机存储介质
WO2018121742A1 (zh) 一种流数据的传输方法和装置
JP2005204092A (ja) 帯域制御機能を有するストレージスイッチ
CN113076280B (zh) 一种数据传输方法及相关设备
US11533656B2 (en) Method of traffic and congestion control for a network with quality of service
WO2012072045A1 (zh) 一种cdn网络中的数据传输方法、网络节点及系统
CN112737940A (zh) 一种数据传输的方法和装置
JP5087595B2 (ja) エッジノード、ウィンドウサイズ制御方法およびプログラム
TW202335471A (zh) 網路流壅塞管理裝置及其方法
CN109219944A (zh) 用于减小分组网络中mtu大小的系统和方法
JP4365798B2 (ja) データフレーム転送装置およびデータフレーム転送方法
US11924106B2 (en) Method and system for granular dynamic quota-based congestion management
TWI831622B (zh) 網路流壅塞管理裝置及其方法
CN109327402B (zh) 拥塞管理方法及装置
KR20230044079A (ko) 정보 중심 네트워크에 포함되는 노드의 제어 방법, 및 시스템
Kinnear WindowTree: Explicit congestion notification and route labeling for congestion control in content centric networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14820452

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2014820452

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE