WO1995015637A1 - Control of overload situations in frame relay network - Google Patents

Control of overload situations in frame relay network Download PDF

Info

Publication number
WO1995015637A1
WO1995015637A1 PCT/FI1994/000535 FI9400535W WO9515637A1 WO 1995015637 A1 WO1995015637 A1 WO 1995015637A1 FI 9400535 W FI9400535 W FI 9400535W WO 9515637 A1 WO9515637 A1 WO 9515637A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
congestion
node
virtual channel
traffic
Prior art date
Application number
PCT/FI1994/000535
Other languages
French (fr)
Inventor
Juha Pajuvirta
Heikki Salovuori
Jorma MATKASELKÄ
Mika Kasslin
Seppo PYHÄLAMMI
Mikko Olkkonen
Richard Fehlmann
Mikko Laiho
Original Assignee
Nokia Telecommunications Oy
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 Nokia Telecommunications Oy filed Critical Nokia Telecommunications Oy
Priority to US08/647,955 priority Critical patent/US5970048A/en
Priority to EP95901462A priority patent/EP0739562A1/en
Priority to JP51542495A priority patent/JP3305326B2/en
Priority to AU10692/95A priority patent/AU689518B2/en
Publication of WO1995015637A1 publication Critical patent/WO1995015637A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433Allocation of priorities to traffic types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/16Flow control; Congestion control in connection oriented networks, e.g. frame relay
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback

Definitions

  • the invention relates to a method according to the preamble of appended claim 1 and a system according to the preamble of appended claim 7 for congestion management in a frame relay network.
  • Congestion means a situation in which the number of transmission requests exceeds the transmission capacity at a certain network point (called a bottle- neck resource) at a specific time. Congestion usually results in overload conditions, as a result of which the buffers overflow, for instance, and so packets will be retransmitted either by the network or the subscriber.
  • the function of congestion management (CM) is to maintain a balance between the transmission requests and the transmission capacity so that the bottle-neck resources operate on an optimal level, and the sub ⁇ scribers are offered service in a way that assures fairness. Congestion management can be divided into congestion avoidance (CA) and congestion recovery (CR) .
  • CA congestion avoidance
  • CR congestion recovery
  • Congestion avoidance methods aim at preventing the occurrence of congestion in the network by dynamically adjusting the bandwidth of the subscribers in accordance with network congestion conditions and/or by altering the network routing so that part of the traffic load of the bottle-neck resources is shifted to idle resources.
  • the purpose of recovery methods is to restore the operation of the bottle-neck resources to an optimal level if the avoidance methods have failed to prevent the occurrence of congestion.
  • the frame relay (FR) technique is a packet- switched network technique used for the transmission of frames of varying length in place of the packet-switched network connections presently in use.
  • the protocol (X.25) applied generally in the present packet-switched networks requires plenty of processing and the trans ⁇ mission equipment is expensive, as a result of which the speeds also remain low. These matters are due to the fact that the X.25 standard was developed when the transmission connections used were still rather prone to transmission errors.
  • the starting point of the frame relay technique was a considerably lower transmission line error probability. It has therefore been possible to discard a number of unnecessary functions in the frame relay technique, which makes the delivery of frames rapid and efficient.
  • the Frame Mode Bearer Service is described generally in CCITT recommendation 1.233 (Reference 1) and the associated protocol in recommendation Q.922 (Reference 2). Congestion in an FR network and congestion management mechanisms are described in CCITT recommendation 1.370 (Reference 3).
  • CCITT recommendation 1.333 Congestion in an FR network and congestion management mechanisms are described in CCITT recommendation 1.370 (Reference 3).
  • nodes In the FR network hierarchies presently in use, nodes have reception and transmission buffers corres- ponding only to the physical channels, i.e. the traffic of several different virtual channels and applications passes through the same buffer. Buffers are emptied as far as possible to links outbound from the node irre ⁇ spective of the total level of congestion in the network. Links outbound from the node are thus loaded as much as possible even if the frame will probably be discarded closer to the middle of the network (at a congested node) . In addition to wasting the network resources, discarding of frames at trunk nodes of the network affects the applications using the network in the form of longer throughput delays. (The virtual channel refers to a virtual connection portion having the length of one transmission link while the virtual connection is the actual packet-switched end-to-end FR connection. )
  • Frames arriving at the node thus pass through the entire node on the FIFO principle. Due to the burstiness of the traffic in a frame relay network, it often follows from the above that one virtual channel takes a major part of the buffering and relay capacity of a node. This affects the other virtual channels supplying traffic to the node both as longer throughput delays and as higher frame loss probabilities. Even one virtual channel with a highly bursty or unsatisfactory nature may cause the other virtual channels of the connection to be subjected to a considerable fall in the service level.
  • the object of the present invention is to obviate the drawbacks described above and to provide a new type of congestion management method in an FR network to allow the network resources to be utilized more fairly and more efficiently than before. This is achieved with the method of the invention, which is characterized by what is disclosed in the characterizing part of appended claim 1.
  • the system of the invention is characterized by what is disclosed in the character ⁇ izing part of appended claim 7.
  • the idea of the invention is to transmit con ⁇ area notifications from the network nodes to the subscriber node of the virtual channel whose frame is received at the node, and to control the amount of traffic supplied by each virtual channel from a sub ⁇ scriber node towards the network in virtual-channel-specific buffers of the subscriber node, for instance according to the total level of congestion in the network indicated by these congestion notifications.
  • the method of the invention allows the relay capacity of a single node and, above all, of the entire network to be equitably divided between all subscribers.
  • FIG. 1 illustrates a typical operating environment of the method according to the invention
  • FIG. 2 illustrates an FR network subscriber node according to the invention
  • Figure 3 illustrates the format of a frame to be delivered in an FR network
  • Figure 4 illustrates the delivery of congestion notifications in the network
  • Figure 5a illustrates the changing of bandwidth according to congestion notifications in a first exemplary case
  • Figure 5b illustrates the changing of bandwidth according to congestion notifications in a second exemplary case
  • Figure 6 illustrates an FR network trunk node according to the invention.
  • a frame relay network can be used by several different applications, which do not require similar services. It is therefore advantageous to employ the method of the invention in a network where the services are divided into different classes according to the applications, taking into account the two most signific ⁇ ant parameters ( frame loss probability and delay) .
  • Such a solution is disclosed in Finnish Patent Application No. 925671.
  • the services be divided into three classes as follows:
  • class 1 offers interactive service where the delay is kept short
  • the second service class (class 2) offers a low frame loss probability without the delay having any great significance
  • the third service class (class 3) offers both a short delay and a low frame loss probability.
  • FIG. 1 shows an FR network offering public network services, that is, a frame relay network 12 interconnecting local area networks 11 of different offices A...E of a single corporation or a plurality of corporations.
  • the local area network 11 of each office has access to the FR service via a local area network bridge 13 and a data link indicated with the references 14a...14e, respectively.
  • connection between an FR subscriber A...E and an FR network node N is known per se, wherefore it will not be described more closely herein. More detailed information about local area networks and bridges used in their interconnection can be found e.g. in an article by Michael Grimshaw LAN Interconnections Technology , Telecommunications,
  • a typical feature of the known node structure of the FR network is that the same buffer is used for all frames, assuming that they are routed to the same physical connection.
  • buffers corresponding to the above- described service classes are provided at the output boundary of all network nodes and at the input boundary having trunk connections.
  • Figure 2 illustrates this kind of solution at a trunk node in the network.
  • the node receives FR frames originally assembled in the bridges 13 of the subscriber connections ( Figure 1).
  • the frame of the subscriber LAN 11 is inserted into the informa ⁇ tion field of the FR frame in the bridge 13 (with the exception of timing bits and other similar bits).
  • Figure 3 illustrates the insertion of a LAN frame 38 into the information field of an FR frame 39.
  • the address field preceding the information field comprises two octets (bits 1 to 8).
  • the bits 3 to 8 of the first octet and the bits 5 to 8 of the second octet form a data link connection identifier DLCI, which indicates to the node e.g. the virtual connection and virtual channel to which a particular frame belongs.
  • the virtual channels are distinguished from each other by means of the data link connection identifier.
  • the data link connection identifier is unambiguous only over a single virtual channel, and it may change in the node on transition to the next virtual channel.
  • the bit 2 of the second address field octet is also significant for the discarding of frames. In accordance with the CCITT recommendation, it is allowable to discard a frame e.g. under congestion conditions if the DE bit of the frame has been set to one. As the other bits in the FR frame are not relevant to the present invention, they will not be described more closely herein. References 2 and 4 mentioned above are referred to for a more detailed description.
  • the subscriber connections 14a, 14b, etc. are connected at first to an identification unit 61, which receives FR frames formed in bridges 13 ( Figure 1).
  • the identification unit 61 reads the data link connection identifier DLCI from the address field of the frame, and forwards the frame to an input buffer 62....62 n corresponding to the virtual connection indicated by the identifier.
  • Each data link has a specific selector S3 which selects frames from the input buffers of each virtual channel and forwards them to a centralized router 16, which routes the frames further to a classification unit 43 of the correct data link (the figure shows only one outbound data link).
  • the classification unit 43 reads the identifier DLCI from the address field of the frame and selects from table T the service class corresponding to the virtual channel indicated by the identifier. On the basis of the classification it has completed, the classification unit 43 applies each frame to an output buffer 64a, 64b or 64c corresponding to the service class of the frame. Each outbound data link thus has three output buffers, one for each service class.
  • the selector S4 reads the frames from these service-class- specific buffers further to the trunk connection.
  • Traffic transmitted by the subscribers over the FR network is thus buffered on the input side of the subscriber node specifically for each virtual connection.
  • Incoming frames 39 are chained dynamically over each virtual connection.
  • the chain length has a predetermined allowable maximum value; this is smaller in service classes 1 and 3 and greater in service class 2.
  • the selector S3 reads the buffers 62 1 ...62 n e.g. in proportion to the amount of traffic allocated to them, whereby the fairness principle is met.
  • the amount of traffic supplied to the network 12 by each virtual channel is adjusted in the virtual-channel-specific buffers 62 1 ...62 n so that the amount of traffic varies depending on the level of congestion in the network around a basic value sold to the channel in question.
  • the total amount of traffic supplied to the inner parts of the network is thus based on the service level sold to the virtual channel, on bandwidth, and on the total level of congestion in the network; of these, the service level and the bandwidth determine a certain basic value, around which the amount of traffic is adjusted according to what the total level of congestion is in the network.
  • the adjustment is performed by trans ⁇ mitting congestion notifications from the network to the subscriber node of the virtual channel whose frame was received; the amount of traffic supplied towards the network from the subscriber node buffer corresponding to this virtual channel within a given time interval of a predetermined length is controlled according to the contents of the congestion notifications received from the network during this interval.
  • the congestion noti ⁇ fications are connected to the control unit 65 controlling the selector S3 in the subscriber node, said control unit controlling the amount of data read from each virtual- channel-specific buffer according to the contents of the congestion notifications. Each buffer is thus emptied on the basis of its own parameters and its own congestion notifications.
  • the method of the invention can be compared to a floodgate: the traffic which each virtual-channel-specific buffer allows to be transmitted to the network is controlled (by means of the control unit 65) by a system which functions as a floodgate, restricting the amount of data read from the buffer, i.e. adjusting the bandwidth of the virtual channel.
  • This floodgate is a system which is bound to the service parameter Be described above, and which allows only a certain amount of data to be transmitted from a virtual-channel-specific buffer towards the network at a certain period of time.
  • Tc/3 has often the length of Is.
  • the nodes of the network transmit the above-mentioned congestion noti- fications M in a backward direction to the subscriber nodes. These congestion notifications indicate the fill rate of the buffers at the node in question.
  • This mechanism is illustrated in Figure 4.
  • the nodes of the network are indicated by references Nl...N4, and the subscribers by references S.
  • a service-class- specific buffer at a network node e.g. at node Nl in Figure 2
  • the node transmits a congestion notification in a backward direction to the subscriber node (N2 in Figure 4) of the virtual channel whose frame was received.
  • the node (Nl) identifies the correct virtual channel as described above by means of the data link connection identifier DLCI.
  • the height of the floodgate determining the emptying rate of each virtual-channel-specific buffer at the subscriber node is adjusted according to the contents of the congestion notifications received from the network on said virtual channel in such a way that a higher load corresponds to a smaller bandwidth. Adjustment of the bandwidth during the interval Tc/3 is preferably performed according to the most severe con ⁇ area notification received during said interval. If the virtual channel does not receive any congestion notification during the interval Tc/3, the bandwidth of the channel is automatically increased according to the invention at the beginning of the following interval. The increase can be determined to be e.g. 10%.
  • the initial value for the bandwidth is the value Bc+Be sold to the channel, i.e. the maximum which the amount of traffic is not allowed to exceed under any circum ⁇ stances.
  • congestion notifications it is possible to indicate, for example, three different levels of congestion, whereby the changes in bandwidth correspond- ing to them (which are all calculated on the basis of the maximum value) may be, for instance, similar to those indicated in the following table.
  • Figures 5a and 5b show two different examples of adjustment according to the invention.
  • the vertical axis represents the height of the floodgate (i.e. bandwidth), whereas the horizontal axis represents time consisting of successive intervals having the length of Tc/3.
  • a congestion notification M with severity degree 1 is at first received, wherefore the bandwidth is reduced immediately.
  • a second congestion notification M with severity degree 2 is received, wherefore the bandwidth is again reduced immediately.
  • the last, third notification M received during the interval Tc/3 has the degree of severity 3, wherefore the bandwidth is again reduced immediately (having then the lowest possible value).
  • the bandwidth of the channel grows automatically (instant T2) after this interval (at the beginning of the following interval Tc/3) .
  • the bandwidth is thus reduced immediately on reception of a congestion notification which is the most severe received so far during the interval in question, but the bandwidth can grow only if no congestion notifications are received during the interval Tc/3. In this case, the growth takes place after the interval in question has ended.
  • the bandwidth If the bandwidth has exceeded the value Be, it drops according to a preferred embodiment of the invention to the value Be immediately on reception of the first congestion notification, wherefore the above- described limits set for the changes are not followed in this special case. This ensures rapid reaction above all to instantaneous congestion. In all cases, however, the bandwidth is adjusted upwards as described above.
  • Each degree of severity of a congestion noti ⁇ fication, bound to the fill rate of the buffers located at the network nodes, can be set to correspond e.g. to the fill rate limits given in the following table:
  • Each node of the network monitors the fill rates of the service-class-specific buffers continuous ⁇ ly.
  • the node transmits a congestion notification M in the direction from which the frame was received, to the sub ⁇ scriber node of the virtual channel in question. If the fill rate of the buffer is less than 20%, an incoming frame does not lead to the transmission of a congestion notification.
  • an interval Tl of a predeter ⁇ mined length is set by a timer at the node; during this interval, no new congestion notifications are transmitted to the virtual channel in question.
  • the length of the interval Tl may be, for example, 100 ms (i.e.
  • Congestion notifications M should be delivered to egress nodes extremely fast to enable rapid reaction to congestion.
  • these congestion notifications form a separate, fourth service class, for which separate service-class-specific buffers are provided at the nodes.
  • this embodiment is shown in Figure 5, in which the buffers 44d and 45d corresponding to the service class of congestion notifications are indicated by broken lines.
  • an FR frame 39 of the format described above is connected at first to a classifica ⁇ tion unit 43 specific for each data link.
  • the classi ⁇ fication unit 43 reads the data link connection identifier from the address field of the frame, and selects the service class corresponding to the virtual channel indicated by the identifier.
  • the virtual channels and the respective service classes are stored in a table T.
  • the classification unit 43 applies each frame to an input buffer corresponding to the service class of the frame.
  • Each inbound data link has thus four input buffers, one for each service class 1 to 3 and one for congestion notifications.
  • Each data link has a specific selector SI which selects the frames from the service- class-specific buffers and forwards them within the node.
  • the frames On the output side of the trunk node, the frames are connected to an interface corresponding to their own data link. At this interface they are supplied in accordance with the service class selected on the input side of the node to one of the service-class-specific output buffers, from which the selector S2 reads the frames further to the trunk connection.
  • Each outbound data link has thus four output buffers, one for each service class 1 to 3 and one for congestion notifica- tions.
  • classification units may be provided separately for each data link even on the output side of the node, in which case classification data need not be transferred within the node.
  • the above-described traffic control allows the relay capacity of a single node and, above all, of the entire network to be equitably divided between the different subscribers.
  • the method of the invention allows the traffic to be efficiently controlled by buffering the additional traffic transmitted by the channel that sent the burst.
  • the channels operating within the limits of committed traffic still get their traffic through the network with a short delay.
  • the traffic on each virtual channel thus varies around the value Be.
  • each virtual-channel-specific buffer can be read by the selector S3 either only once or several times.
  • the degree of severity of congestion notifications can also be bound to any resource whose congestion level is monitored continuously. In this case, it is possible to employ, for instance, the method disclosed in Finnish Patent Application No. 925670, according to which a congestion level is determined for a resource of the network, the value of the congestion level having a certain relationship with the values of the service levels.

Abstract

The invention relates to a method and a system for congestion management in a Frame Relay network. The method comprises determining the virtual channel associated with a frame to be transmitted when it is received at a network node. In order for the relay capacity of the network to be equitably divided between all subscribers (a) data is buffered at the input boundary of the subscriber node to virtual-channel-specific buffers (621...62n), (b) congestion notifications (M) are transmitted in a backward direction from the network nodes to the subscriber node of the virtual channel whose frame is received at that particular moment, and (c) the amount of traffic supplied towards the network from the subscriber node buffer corresponding to said virtual channel during a certain interval having a predetermined length is controlled on the basis of the contents of congestion notifications (M) received from the network during said interval.

Description

Control of overload situations in frame relay network
The invention relates to a method according to the preamble of appended claim 1 and a system according to the preamble of appended claim 7 for congestion management in a frame relay network.
Congestion means a situation in which the number of transmission requests exceeds the transmission capacity at a certain network point (called a bottle- neck resource) at a specific time. Congestion usually results in overload conditions, as a result of which the buffers overflow, for instance, and so packets will be retransmitted either by the network or the subscriber. The function of congestion management (CM) is to maintain a balance between the transmission requests and the transmission capacity so that the bottle-neck resources operate on an optimal level, and the sub¬ scribers are offered service in a way that assures fairness. Congestion management can be divided into congestion avoidance (CA) and congestion recovery (CR) . Congestion avoidance methods aim at preventing the occurrence of congestion in the network by dynamically adjusting the bandwidth of the subscribers in accordance with network congestion conditions and/or by altering the network routing so that part of the traffic load of the bottle-neck resources is shifted to idle resources. The purpose of recovery methods, in turn, is to restore the operation of the bottle-neck resources to an optimal level if the avoidance methods have failed to prevent the occurrence of congestion.
The frame relay (FR) technique is a packet- switched network technique used for the transmission of frames of varying length in place of the packet-switched network connections presently in use. The protocol (X.25) applied generally in the present packet-switched networks requires plenty of processing and the trans¬ mission equipment is expensive, as a result of which the speeds also remain low. These matters are due to the fact that the X.25 standard was developed when the transmission connections used were still rather prone to transmission errors. The starting point of the frame relay technique was a considerably lower transmission line error probability. It has therefore been possible to discard a number of unnecessary functions in the frame relay technique, which makes the delivery of frames rapid and efficient. The Frame Mode Bearer Service is described generally in CCITT recommendation 1.233 (Reference 1) and the associated protocol in recommendation Q.922 (Reference 2). Congestion in an FR network and congestion management mechanisms are described in CCITT recommendation 1.370 (Reference 3). For a more detailed description of the FR technique, reference is made to An Overview of Frame Relay Techno- l g , Datapro Management of Data Communications, McGraw- Hill Incorporated, April 1991, (Reference 4) as well as the above-mentioned recommendations.
In the FR network hierarchies presently in use, nodes have reception and transmission buffers corres- ponding only to the physical channels, i.e. the traffic of several different virtual channels and applications passes through the same buffer. Buffers are emptied as far as possible to links outbound from the node irre¬ spective of the total level of congestion in the network. Links outbound from the node are thus loaded as much as possible even if the frame will probably be discarded closer to the middle of the network (at a congested node) . In addition to wasting the network resources, discarding of frames at trunk nodes of the network affects the applications using the network in the form of longer throughput delays. (The virtual channel refers to a virtual connection portion having the length of one transmission link while the virtual connection is the actual packet-switched end-to-end FR connection. )
Even though the traffic received from virtual channels is monitored on subscriber connections on the basis of general service parameters Be, Be and CIR, the monitoring is not effected when frames are forwarded from the subscriber node. [Parameter Be (committed burst size) represents the maximum amount of data the sub¬ scriber can transmit over the network within a certain time slot Tc (usually Tc=ls); parameter Be (excess burst size) represents the amount of data by which the sub- scriber can exceed the value Be within the time slot Tc; and parameter CIR (committed information rate) represents the data transmission rate guaranteed by the network under normal conditions, CIR=Bc/Tc. These para¬ meters are defined in Reference 3. ] From the reception buffer, the frame is routed to the correct channel- specific transmission buffer. Frames arriving at the node thus pass through the entire node on the FIFO principle. Due to the burstiness of the traffic in a frame relay network, it often follows from the above that one virtual channel takes a major part of the buffering and relay capacity of a node. This affects the other virtual channels supplying traffic to the node both as longer throughput delays and as higher frame loss probabilities. Even one virtual channel with a highly bursty or unsatisfactory nature may cause the other virtual channels of the connection to be subjected to a considerable fall in the service level.
The object of the present invention is to obviate the drawbacks described above and to provide a new type of congestion management method in an FR network to allow the network resources to be utilized more fairly and more efficiently than before. This is achieved with the method of the invention, which is characterized by what is disclosed in the characterizing part of appended claim 1. The system of the invention is characterized by what is disclosed in the character¬ izing part of appended claim 7.
The idea of the invention is to transmit con¬ gestion notifications from the network nodes to the subscriber node of the virtual channel whose frame is received at the node, and to control the amount of traffic supplied by each virtual channel from a sub¬ scriber node towards the network in virtual-channel- specific buffers of the subscriber node, for instance according to the total level of congestion in the network indicated by these congestion notifications.
The method of the invention allows the relay capacity of a single node and, above all, of the entire network to be equitably divided between all subscribers. In the following, the invention and its preferred embodiments will be described in greater detail with reference to the examples illustrated in the accompanying drawings, in which
Figure 1 illustrates a typical operating environment of the method according to the invention,
Figure 2 illustrates an FR network subscriber node according to the invention,
Figure 3 illustrates the format of a frame to be delivered in an FR network, Figure 4 illustrates the delivery of congestion notifications in the network,
Figure 5a illustrates the changing of bandwidth according to congestion notifications in a first exemplary case, Figure 5b illustrates the changing of bandwidth according to congestion notifications in a second exemplary case, and
Figure 6 illustrates an FR network trunk node according to the invention.
A frame relay network can be used by several different applications, which do not require similar services. It is therefore advantageous to employ the method of the invention in a network where the services are divided into different classes according to the applications, taking into account the two most signific¬ ant parameters ( frame loss probability and delay) . Such a solution is disclosed in Finnish Patent Application No. 925671. In this application, it is suggested that the services be divided into three classes as follows:
- the first service class (class 1) offers interactive service where the delay is kept short,
- the second service class (class 2) offers a low frame loss probability without the delay having any great significance, and
- the third service class (class 3) offers both a short delay and a low frame loss probability.
Each trunk connection of a network realized in this way has service-class-specific buffers, one for each service class. A subscriber node, in turn, has virtual-channel-specific buffers on the side of the subscriber connection. These solutions will be described more closely below; otherwise reference is made to the Finnish patent application cited above. Figure 1 shows an FR network offering public network services, that is, a frame relay network 12 interconnecting local area networks 11 of different offices A...E of a single corporation or a plurality of corporations. The local area network 11 of each office has access to the FR service via a local area network bridge 13 and a data link indicated with the references 14a...14e, respectively. The connection between an FR subscriber A...E and an FR network node N is known per se, wherefore it will not be described more closely herein. More detailed information about local area networks and bridges used in their interconnection can be found e.g. in an article by Michael Grimshaw LAN Interconnections Technology , Telecommunications,
February 1991, and in LShiverk o-opas , Leena Jaakonmaki, Suomen ATK-kustannus Oy, 1991, which are incorporated herein by reference.
A typical feature of the known node structure of the FR network is that the same buffer is used for all frames, assuming that they are routed to the same physical connection. According to the present invention, on the contrary, buffers corresponding to the above- described service classes are provided at the output boundary of all network nodes and at the input boundary having trunk connections. Figure 2 illustrates this kind of solution at a trunk node in the network. The node receives FR frames originally assembled in the bridges 13 of the subscriber connections (Figure 1). The frame of the subscriber LAN 11 is inserted into the informa¬ tion field of the FR frame in the bridge 13 (with the exception of timing bits and other similar bits). Figure 3 illustrates the insertion of a LAN frame 38 into the information field of an FR frame 39. It also shows a typical FR network frame format where the address field preceding the information field comprises two octets (bits 1 to 8). The bits 3 to 8 of the first octet and the bits 5 to 8 of the second octet form a data link connection identifier DLCI, which indicates to the node e.g. the virtual connection and virtual channel to which a particular frame belongs. The virtual channels are distinguished from each other by means of the data link connection identifier. The data link connection identifier, however, is unambiguous only over a single virtual channel, and it may change in the node on transition to the next virtual channel. The bit 2 of the second address field octet, called a DE bit (Discard Eligibility Indicator), is also significant for the discarding of frames. In accordance with the CCITT recommendation, it is allowable to discard a frame e.g. under congestion conditions if the DE bit of the frame has been set to one. As the other bits in the FR frame are not relevant to the present invention, they will not be described more closely herein. References 2 and 4 mentioned above are referred to for a more detailed description. At a subscriber node on the periphery of the network (Figure 2), the subscriber connections 14a, 14b, etc., (which in the example illustrated in Figure 2 are connected to the same node) are connected at first to an identification unit 61, which receives FR frames formed in bridges 13 (Figure 1). The identification unit 61 reads the data link connection identifier DLCI from the address field of the frame, and forwards the frame to an input buffer 62....62n corresponding to the virtual connection indicated by the identifier. Each data link has a specific selector S3 which selects frames from the input buffers of each virtual channel and forwards them to a centralized router 16, which routes the frames further to a classification unit 43 of the correct data link (the figure shows only one outbound data link). The classification unit 43 reads the identifier DLCI from the address field of the frame and selects from table T the service class corresponding to the virtual channel indicated by the identifier. On the basis of the classification it has completed, the classification unit 43 applies each frame to an output buffer 64a, 64b or 64c corresponding to the service class of the frame. Each outbound data link thus has three output buffers, one for each service class. The selector S4 reads the frames from these service-class- specific buffers further to the trunk connection.
Traffic transmitted by the subscribers over the FR network is thus buffered on the input side of the subscriber node specifically for each virtual connection. Incoming frames 39 are chained dynamically over each virtual connection. Depending on the service class of the virtual connection, the chain length has a predetermined allowable maximum value; this is smaller in service classes 1 and 3 and greater in service class 2. The selector S3 reads the buffers 621...62n e.g. in proportion to the amount of traffic allocated to them, whereby the fairness principle is met.
According to the invention, the amount of traffic supplied to the network 12 by each virtual channel is adjusted in the virtual-channel-specific buffers 621...62n so that the amount of traffic varies depending on the level of congestion in the network around a basic value sold to the channel in question. The total amount of traffic supplied to the inner parts of the network is thus based on the service level sold to the virtual channel, on bandwidth, and on the total level of congestion in the network; of these, the service level and the bandwidth determine a certain basic value, around which the amount of traffic is adjusted according to what the total level of congestion is in the network. The adjustment is performed by trans¬ mitting congestion notifications from the network to the subscriber node of the virtual channel whose frame was received; the amount of traffic supplied towards the network from the subscriber node buffer corresponding to this virtual channel within a given time interval of a predetermined length is controlled according to the contents of the congestion notifications received from the network during this interval. The congestion noti¬ fications, indicated in Figure 2 by reference M, are connected to the control unit 65 controlling the selector S3 in the subscriber node, said control unit controlling the amount of data read from each virtual- channel-specific buffer according to the contents of the congestion notifications. Each buffer is thus emptied on the basis of its own parameters and its own congestion notifications.
As regards the subscriber node, the method of the invention can be compared to a floodgate: the traffic which each virtual-channel-specific buffer allows to be transmitted to the network is controlled (by means of the control unit 65) by a system which functions as a floodgate, restricting the amount of data read from the buffer, i.e. adjusting the bandwidth of the virtual channel. This floodgate is a system which is bound to the service parameter Be described above, and which allows only a certain amount of data to be transmitted from a virtual-channel-specific buffer towards the network at a certain period of time. As to the resolu- tion of monitoring the bandwidth of the virtual channel, it is possible to use a time interval having the length of e.g. Tc/3 (Tc has often the length of Is). During each interval having the length of Tc/3, the buffer is emptied to an outbound connection towards the network by an amount allowed by the height of the floodgate. The rest of the frames are left in the buffer to wait for the next interval of Tc/3.
According to the invention, the nodes of the network transmit the above-mentioned congestion noti- fications M in a backward direction to the subscriber nodes. These congestion notifications indicate the fill rate of the buffers at the node in question. This mechanism is illustrated in Figure 4. The nodes of the network are indicated by references Nl...N4, and the subscribers by references S. When a service-class- specific buffer at a network node, e.g. at node Nl in Figure 2, exceeds a certain fill rate, e.g. 20%, the node transmits a congestion notification in a backward direction to the subscriber node (N2 in Figure 4) of the virtual channel whose frame was received. The node (Nl) identifies the correct virtual channel as described above by means of the data link connection identifier DLCI.
The height of the floodgate determining the emptying rate of each virtual-channel-specific buffer at the subscriber node (i.e. the bandwidth offered to the virtual channel) is adjusted according to the contents of the congestion notifications received from the network on said virtual channel in such a way that a higher load corresponds to a smaller bandwidth. Adjustment of the bandwidth during the interval Tc/3 is preferably performed according to the most severe con¬ gestion notification received during said interval. If the virtual channel does not receive any congestion notification during the interval Tc/3, the bandwidth of the channel is automatically increased according to the invention at the beginning of the following interval. The increase can be determined to be e.g. 10%. The initial value for the bandwidth is the value Bc+Be sold to the channel, i.e. the maximum which the amount of traffic is not allowed to exceed under any circum¬ stances.
By congestion notifications it is possible to indicate, for example, three different levels of congestion, whereby the changes in bandwidth correspond- ing to them (which are all calculated on the basis of the maximum value) may be, for instance, similar to those indicated in the following table.
Degree of severity of Change in bandwidth congestion notification
1 -10%
2 -15%
3 -20%
To illustrate the principles described above, Figures 5a and 5b show two different examples of adjustment according to the invention. The vertical axis represents the height of the floodgate (i.e. bandwidth), whereas the horizontal axis represents time consisting of successive intervals having the length of Tc/3. In the case illustrated in Figure 5a, a congestion notification M with severity degree 1 is at first received, wherefore the bandwidth is reduced immediately. After that a second congestion notification M with severity degree 2 is received, wherefore the bandwidth is again reduced immediately. The last, third notification M received during the interval Tc/3 has the degree of severity 3, wherefore the bandwidth is again reduced immediately (having then the lowest possible value). As no congestion notifications are received during the follow¬ ing interval Tc/3, the bandwidth of the channel grows automatically (instant T2) after this interval (at the beginning of the following interval Tc/3) .
In the case illustrated in Figure 5b, the order of the congestion notifications in time domain is reverse. At first a congestion notification with severity degree 3 is received, wherefore the bandwidth is reduced immediately to the lowest possible value. The other congestion notifications received during the interval do not change the bandwidth further, no matter what their degree of severity is. If a congestion noti¬ fication with severity degree 2 were received at first, only a congestion notification with severity degree 3 would cause the bandwidth to be further reduced.
According to the invention, the bandwidth is thus reduced immediately on reception of a congestion notification which is the most severe received so far during the interval in question, but the bandwidth can grow only if no congestion notifications are received during the interval Tc/3. In this case, the growth takes place after the interval in question has ended.
If the bandwidth has exceeded the value Be, it drops according to a preferred embodiment of the invention to the value Be immediately on reception of the first congestion notification, wherefore the above- described limits set for the changes are not followed in this special case. This ensures rapid reaction above all to instantaneous congestion. In all cases, however, the bandwidth is adjusted upwards as described above.
Each degree of severity of a congestion noti¬ fication, bound to the fill rate of the buffers located at the network nodes, can be set to correspond e.g. to the fill rate limits given in the following table:
Fill rate calculated on Degree of severity of total buffer capacity congestion
20...39% 1
40...59% 2
60...100% 3 Each node of the network monitors the fill rates of the service-class-specific buffers continuous¬ ly. When a new frame is received at a congested node, the node transmits a congestion notification M in the direction from which the frame was received, to the sub¬ scriber node of the virtual channel in question. If the fill rate of the buffer is less than 20%, an incoming frame does not lead to the transmission of a congestion notification. Simultaneously with the transmission of a congestion notification, an interval Tl of a predeter¬ mined length is set by a timer at the node; during this interval, no new congestion notifications are transmitted to the virtual channel in question. The length of the interval Tl may be, for example, 100 ms (i.e. about one third of the interval Tc/3). In this way it is ensured that several congestion notifications are not transmitted in vain on one burst occurring on the virtual channel. When the timer has timed off, it is again possible, if necessary, to transmit a congestion notification to the virtual channel.
Congestion notifications M should be delivered to egress nodes extremely fast to enable rapid reaction to congestion. According to a preferred embodiment of the invention, these congestion notifications form a separate, fourth service class, for which separate service-class-specific buffers are provided at the nodes. As regards the subscriber node, this means that the output side of the node is provided with a fourth output buffer, indicated in Figure 2 by broken lines and the reference 64d.
As regards the trunk node of the network, this embodiment is shown in Figure 5, in which the buffers 44d and 45d corresponding to the service class of congestion notifications are indicated by broken lines. At the trunk node, an FR frame 39 of the format described above is connected at first to a classifica¬ tion unit 43 specific for each data link. The classi¬ fication unit 43 reads the data link connection identifier from the address field of the frame, and selects the service class corresponding to the virtual channel indicated by the identifier. The virtual channels and the respective service classes are stored in a table T. On the basis of the classification it has completed, the classification unit 43 applies each frame to an input buffer corresponding to the service class of the frame. Each inbound data link has thus four input buffers, one for each service class 1 to 3 and one for congestion notifications. Each data link has a specific selector SI which selects the frames from the service- class-specific buffers and forwards them within the node. On the output side of the trunk node, the frames are connected to an interface corresponding to their own data link. At this interface they are supplied in accordance with the service class selected on the input side of the node to one of the service-class-specific output buffers, from which the selector S2 reads the frames further to the trunk connection. Each outbound data link has thus four output buffers, one for each service class 1 to 3 and one for congestion notifica- tions. Alternatively, classification units may be provided separately for each data link even on the output side of the node, in which case classification data need not be transferred within the node.
The above-described traffic control allows the relay capacity of a single node and, above all, of the entire network to be equitably divided between the different subscribers. In the event of instantaneous congestion, caused by burstiness of the traffic, the method of the invention allows the traffic to be efficiently controlled by buffering the additional traffic transmitted by the channel that sent the burst. Thus the channels operating within the limits of committed traffic still get their traffic through the network with a short delay. The traffic on each virtual channel thus varies around the value Be.
In the event of continuous congestion, the procedure is otherwise similar but the traffic exceeding the relay capacity of the network must be discarded when there is overflow in the virtual-channel-specific buffers. Even in such a case, the discarding of traffic affects the virtual channels which overload the network; the traffic of the other channels hardly needs to be slowed down at all. For discarding frames, it is advant¬ ageous to use the method disclosed in co-pending Finnish Patent Application No. 93xxxx, according to which the entire contents of a buffer are discarded when a frame is received in a buffer which is full. For a more detailed description of this method, reference is made to the above-mentioned co-pending patent application. If there is idle relay capacity in the network, no congestion notifications are transmitted, whereby the channel bandwidths may grow to the maximum value Be+Be set for them. In this case, both the committed traffic and the excess traffic are read from the buffers to the inner parts of the network. The capacity of the network will thus be utilized even in quiet times, and additional traffic will be treated correctly.
Although the invention has been described above with reference to the examples shown in the accompanying drawings, it will be obvious that the invention is not restricted to these examples, but can be modified within the scope of the inventive concept disclosed above and in the appended claims. In its details, the internal structure of the nodes, for example, may vary in many ways, even though the adjustment based on congestion notifications is performed according to the idea of the invention. During the interval Tc/3, for example, each virtual-channel-specific buffer can be read by the selector S3 either only once or several times. The degree of severity of congestion notifications can also be bound to any resource whose congestion level is monitored continuously. In this case, it is possible to employ, for instance, the method disclosed in Finnish Patent Application No. 925670, according to which a congestion level is determined for a resource of the network, the value of the congestion level having a certain relationship with the values of the service levels.

Claims

Claims
1. A method for congestion management in a Frame Relay network comprising subscriber nodes to which subscribers (A...E) are connected over data links (14a...l4e), said method comprising determining the virtual channel associated with a frame (39) to be transmitted when it is received at a network node, c h a r a c t e r i z e d in that - data is buffered at the input boundary of a subscriber node to virtual-channel-specific buffers (621...62n),
- congestion notifications (M) are transmitted in a backward direction from the network nodes to the subscriber node of the virtual channel whose frame is received at that particular moment, and
- the amount of traffic supplied towards the network from the subscriber node buffer corresponding to said virtual channel during a certain interval having a predetermined length is controlled on the basis of the contents of congestion notifications (M) received from the network during said interval.
2. A method according to claim 1, c h a r a c ¬ t e r i z e d in that the degree of severity of congestion notifications is bound to the fill rate of the buffers at a node, whereby a certain severity degree corresponds to each fill rate range, and a change of constant magnitude in the amount of traffic supplied towards the network during said interval corresponds to a certain severity degree of congestion.
3. A method according to claim 1, c h a r a c ¬ t e r i z e d in that if no congestion notifications belonging to the virtual channel are transmitted during said interval, the amount of traffic at the subscriber node is increased by a certain constant value without, however, exceeding an allowed maximum value.
4. A method according to claim 3, c h a r a c ¬ t e r i z e d in that when the amount of traffic exceeds the amount of committed burst size (Be), the amount of traffic is reduced to a value corresponding to the committed burst size (Be) immediately on reception of a congestion notification (M).
5. A method according to claim l, c h a r a c - t e r i z e d in that the amount of traffic is controlled according to the most severe congestion noti¬ fication received during said interval.
6. A method according to claim 1, c h a r a c ¬ t e r i z e d in that after the transmission a congestion notification, the transmission of a following congestion notification to the same virtual channel is prevented for a predetermined time in order to prevent several congestion notifications from being sent in vain on one burst occurring on the virtual channel.
7. A system for congestion management in a
Frame Relay network comprising a plurality of nodes (N; N1...N4) between which data is transmitted, at least part of said nodes being subscriber nodes to which sub¬ scribers (A...E) of the network are connected over data links (14a...l4e), c h a r a c t e r i z e d in that
- virtual-channel-specific buffers (621...62n) to which data is buffered are provided at the input boundary of a subscriber node,
- the nodes comprise means for transmitting congestion notifications (M) in a backward direction to the subscriber node of the virtual channel whose frame is received at that particular moment, and
- a subscriber node comprises means (65, S3) for controlling the amount of traffic supplied towards the network from the buffer corresponding to said virtual channel during a certain interval having a pre¬ determined length, said controlling being performed on the basis of the contents of congestion notifications (M) received from the network during said interval.
PCT/FI1994/000535 1993-11-30 1994-11-29 Control of overload situations in frame relay network WO1995015637A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US08/647,955 US5970048A (en) 1993-11-30 1994-11-29 Control of overload situations in frame relay network
EP95901462A EP0739562A1 (en) 1993-11-30 1994-11-29 Control of overload situations in frame relay network
JP51542495A JP3305326B2 (en) 1993-11-30 1994-11-29 Overload state control in frame relay networks
AU10692/95A AU689518B2 (en) 1993-11-30 1994-11-29 Control of overload situations in frame relay network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI935365 1993-11-30
FI935365A FI94815C (en) 1993-11-30 1993-11-30 Method and apparatus for handling congestion situations in a frame switching network

Publications (1)

Publication Number Publication Date
WO1995015637A1 true WO1995015637A1 (en) 1995-06-08

Family

ID=8539055

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI1994/000535 WO1995015637A1 (en) 1993-11-30 1994-11-29 Control of overload situations in frame relay network

Country Status (7)

Country Link
US (1) US5970048A (en)
EP (1) EP0739562A1 (en)
JP (1) JP3305326B2 (en)
CN (1) CN1141701A (en)
AU (1) AU689518B2 (en)
FI (1) FI94815C (en)
WO (1) WO1995015637A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997039555A1 (en) * 1996-04-12 1997-10-23 Dsc Communications A/S A method and a network element for transferring data packets in a teletransmission network
WO2000011629A1 (en) * 1998-08-07 2000-03-02 Dinbis Ab Method and means for traffic route control
GB2343344A (en) * 1998-10-28 2000-05-03 3Com Technologies Ltd Communication switch including input throttling to reduce output congestion
US6667985B1 (en) 1998-10-28 2003-12-23 3Com Technologies Communication switch including input bandwidth throttling to reduce output congestion

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6847611B1 (en) 1990-12-10 2005-01-25 At&T Corp. Traffic management for frame relay switched data service
US6185223B1 (en) * 1996-12-04 2001-02-06 Conexant Systems, Inc. Apparatus and method for providing fire wall protection for systems in communication with an a synchronous transfer mode system
US6192422B1 (en) * 1997-04-16 2001-02-20 Alcatel Internetworking, Inc. Repeater with flow control device transmitting congestion indication data from output port buffer to associated network node upon port input buffer crossing threshold level
JPH10336202A (en) * 1997-06-03 1998-12-18 Fuji Xerox Co Ltd Data transfer device and its method
US6081524A (en) 1997-07-03 2000-06-27 At&T Corp. Frame relay switched data service
JPH11177619A (en) * 1997-12-15 1999-07-02 Nec Corp Terminal side congestion control method for frame relay network
US6130880A (en) * 1998-03-20 2000-10-10 3Com Corporation Method and apparatus for adaptive prioritization of multiple information types in highly congested communication devices
US6879993B1 (en) * 1999-02-25 2005-04-12 Nortel Networks Limited Apparatus and method for binding a connection-oriented client to a communication channel
US6650618B1 (en) * 1999-07-01 2003-11-18 Nortel Networks Limited Method and apparatus for managing communications between nodes in a bi-directional ring network
EP1238496B1 (en) * 1999-12-18 2008-08-06 Roke Manor Research Limited Improvements in or relating to internet access
GB9929877D0 (en) * 1999-12-18 2000-02-09 Roke Manor Research TCP/IP output rate determination and feedback control
US8161182B1 (en) * 2000-01-26 2012-04-17 Cisco Technology, Inc. Managing network congestion using dynamically advertised congestion status
US7058723B2 (en) * 2000-03-14 2006-06-06 Adaptec, Inc. Congestion control for internet protocol storage
US6954429B2 (en) * 2000-04-05 2005-10-11 Dyband Corporation Bandwidth control system
JP2002077251A (en) * 2000-08-28 2002-03-15 Nec Corp Data transmission system, data repeater system and method therefor
US7415025B1 (en) 2000-12-29 2008-08-19 Cisco Technology, Inc. Method and apparatus for clearing a large number of connections in an ATM network
US7394764B2 (en) * 2001-12-14 2008-07-01 Sasken Communication Technologies Limited Technique for improving transmission control protocol performance in lossy networks
US7734808B1 (en) 2001-12-18 2010-06-08 Cisco Technology, Inc. End-to-end congestion control in a Fibre Channel network
US7596627B2 (en) 2001-12-18 2009-09-29 Cisco Technology, Inc. Methods and apparatus for network congestion control
US7570584B1 (en) 2002-03-29 2009-08-04 Cisco Technology, Inc. Network-wide congestion control of SPVC signaling messages
US7161904B2 (en) * 2002-06-04 2007-01-09 Fortinet, Inc. System and method for hierarchical metering in a virtual router based network switch
US7409460B1 (en) 2003-05-12 2008-08-05 F5 Networks, Inc. Method and apparatus for managing network traffic
CN100366027C (en) * 2003-06-26 2008-01-30 华为技术有限公司 Method for realizing frame reliable transmission in frame relay network
US7809007B2 (en) * 2004-03-05 2010-10-05 David Mayhew Low cost implementation for a device utilizing look ahead congestion management
US7672243B2 (en) * 2004-06-04 2010-03-02 David Mayhew System and method to identify and communicate congested flows in a network fabric
JP4334424B2 (en) * 2004-07-09 2009-09-30 富士通株式会社 Network resource, service discovery method, and relay node device
US20060028988A1 (en) * 2004-08-09 2006-02-09 Kumar Gopal N Decreased random opening procedure for overload control
US8762567B2 (en) * 2004-08-13 2014-06-24 Alcatel Lucent Adaptive permutation group method for overload control
US8788640B1 (en) 2005-08-16 2014-07-22 F5 Networks, Inc. Employing rate shaping class capacities and metrics to balance connections
US9270580B1 (en) 2009-08-28 2016-02-23 Brocade Communications Systems, Inc. Method and system for traffic isolation in a network
US9391849B2 (en) * 2009-11-06 2016-07-12 Brocade Communications Systems, Inc. Back pressure remediation
US8891368B2 (en) * 2009-11-06 2014-11-18 Brocade Communications Systems, Inc. Presentation of a selected port
US8593964B1 (en) 2009-11-06 2013-11-26 Brocade Communications Systems, Inc. Method and system for traffic management
US8885657B2 (en) * 2009-11-06 2014-11-11 Brocade Communications Systems, Inc. Automatic switch port selection
US20110270972A1 (en) * 2010-04-30 2011-11-03 The Regents Of The University Of California Virtual topology adaptation for resource optimization in telecommunication networks
US8842537B2 (en) * 2010-08-30 2014-09-23 Tellabs Operations, Inc. Configuring traffic allocations in a router
US10652627B2 (en) * 2017-03-31 2020-05-12 Intel Corporation Controlling digital video bandwidth utilization with a virtualized communication hub
US10225211B2 (en) * 2017-07-20 2019-03-05 Arris Enterprises Llc Statistical multiplexer with service priority weighting

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0499150A1 (en) * 1991-02-12 1992-08-19 Hitachi, Ltd. Method of and system for controlling packet-rate in communication network
US5163046A (en) * 1989-11-30 1992-11-10 At&T Bell Laboratories Dynamic window sizing in a data network
WO1993005596A1 (en) * 1991-09-09 1993-03-18 Adaptive Corporation Method and apparatus for asynchronous transfer mode (atm) network
WO1993014605A1 (en) * 1992-01-21 1993-07-22 Codex Corporation Rate-based adaptive congestion control system and method for integrated packet networks
EP0576122A2 (en) * 1992-04-27 1993-12-29 Nippon Telegraph And Telephone Corporation Packet network and method for congestion avoidance in packet networks

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0334039A (en) * 1989-06-30 1991-02-14 Nec Corp Fault message control system for network control
US5115429A (en) * 1990-08-02 1992-05-19 Codex Corporation Dynamic encoding rate control minimizes traffic congestion in a packet network
AU8636391A (en) * 1990-10-10 1992-05-20 British Telecommunications Public Limited Company Network traffic management
JPH05103046A (en) * 1991-05-20 1993-04-23 Fujitsu Ltd Alarm suppression system
WO1993000537A1 (en) * 1991-06-25 1993-01-07 Boytim Mark R Vacuum relief fitting for sanitary silos
GB2261798B (en) * 1991-11-23 1995-09-06 Dowty Communications Ltd Packet switching networks
FI92361C (en) * 1992-12-14 1994-10-25 Nokia Telecommunications Oy Procedure for controlling overload situations in a frame switching network and a node for a frame switching network
US5436891A (en) * 1993-01-14 1995-07-25 Motorola, Inc. Method and system for traffic management in cell relay networks
JP3187230B2 (en) * 1993-09-06 2001-07-11 株式会社東芝 Congestion control method and congestion control device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5163046A (en) * 1989-11-30 1992-11-10 At&T Bell Laboratories Dynamic window sizing in a data network
EP0499150A1 (en) * 1991-02-12 1992-08-19 Hitachi, Ltd. Method of and system for controlling packet-rate in communication network
WO1993005596A1 (en) * 1991-09-09 1993-03-18 Adaptive Corporation Method and apparatus for asynchronous transfer mode (atm) network
WO1993014605A1 (en) * 1992-01-21 1993-07-22 Codex Corporation Rate-based adaptive congestion control system and method for integrated packet networks
EP0576122A2 (en) * 1992-04-27 1993-12-29 Nippon Telegraph And Telephone Corporation Packet network and method for congestion avoidance in packet networks

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997039555A1 (en) * 1996-04-12 1997-10-23 Dsc Communications A/S A method and a network element for transferring data packets in a teletransmission network
US6529476B1 (en) 1996-04-12 2003-03-04 Tellabs Denmark A/S Method and a network element for transferring data packets in a teletransmission network
WO2000011629A1 (en) * 1998-08-07 2000-03-02 Dinbis Ab Method and means for traffic route control
GB2343344A (en) * 1998-10-28 2000-05-03 3Com Technologies Ltd Communication switch including input throttling to reduce output congestion
GB2343344B (en) * 1998-10-28 2000-08-09 3Com Technologies Ltd Communication switch including input throttling to reduce output congestion
US6667985B1 (en) 1998-10-28 2003-12-23 3Com Technologies Communication switch including input bandwidth throttling to reduce output congestion

Also Published As

Publication number Publication date
JPH09508764A (en) 1997-09-02
FI935365A (en) 1995-05-31
FI94815C (en) 1995-10-25
EP0739562A1 (en) 1996-10-30
AU689518B2 (en) 1998-04-02
US5970048A (en) 1999-10-19
FI94815B (en) 1995-07-14
CN1141701A (en) 1997-01-29
AU1069295A (en) 1995-06-19
FI935365A0 (en) 1993-11-30
JP3305326B2 (en) 2002-07-22

Similar Documents

Publication Publication Date Title
US5970048A (en) Control of overload situations in frame relay network
EP0788698B1 (en) A method for congestion management in a frame relay network and a node in a frame relay network
EP0732019B1 (en) Control of overload situations in frame relay network
AU598409B2 (en) Communications systems
EP0275678B1 (en) Packet switching system arranged for congestion control through bandwidth management
EP0275679B1 (en) Packet switching system arranged for congestion control
AU703228B2 (en) Data link interface for packet-switched network
US6424624B1 (en) Method and system for implementing congestion detection and flow control in high speed digital network
US6683872B1 (en) Variable rate digital switching system
EP0673573B1 (en) A method for congestion management in a frame relay network and a node in a frame relay network
US5956322A (en) Phantom flow control method and apparatus
US7016302B1 (en) Apparatus and method for controlling queuing of data at a node on a network
EP0524467B1 (en) Bandwidth management system in communication
AU717162B2 (en) Improved phantom flow control method and apparatus
WO1998043395A9 (en) Improved phantom flow control method and apparatus

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 94194846.3

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW NL NO NZ PL PT RO RU SD SE SI SK TJ TT UA US UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE MW SD SZ AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995901462

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 08647955

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1995901462

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: CA

WWW Wipo information: withdrawn in national office

Ref document number: 1995901462

Country of ref document: EP