Generic cell rate algorithm - Revision history

Kvng: Adding short description: "Network scheduling algorithm used in ATM"

2024-08-08T14:55:26Z

Adding short description: "Network scheduling algorithm used in ATM"

← Previous revision		Revision as of 14:55, 8 August 2024
Line 1:		Line 1:
			{{Short description\|Network scheduling algorithm used in ATM}}
	The '''generic cell rate algorithm''' (GCRA) is a [[leaky bucket]]-type [[scheduling algorithm]] for the [[network scheduler]] that is used in [[Asynchronous Transfer Mode]] (ATM) networks.<ref name="ATMF-GCRA"/><ref name="ITU-T-GCRA"/> It is used to measure the timing of [[Asynchronous Transfer Mode#The structure of an ATM cell\|cells]] on [[Virtual circuit\|virtual channel]]s (VCs) and or [[Virtual Paths]] (VPs) against [[Bandwidth (signal processing)\|bandwidth]] and [[jitter]] limits contained in a [[traffic contract]] for the VC or VP to which the cells belong. Cells that do not conform to the limits given by the traffic contract may then be re-timed (delayed) in [[traffic shaping]], or may be dropped (discarded) or reduced in priority (demoted) in [[Traffic policing (communications)\|traffic policing]]. Nonconforming cells that are reduced in priority may then be dropped, in preference to higher priority cells, by downstream components in the network that are experiencing congestion. Alternatively they may reach their destination (VC or VP termination) if there is enough capacity for them, despite them being excess cells as far as the contract is concerned: see [[priority control]]<!-- another page in need of a rewrite -->.		The '''generic cell rate algorithm''' (GCRA) is a [[leaky bucket]]-type [[scheduling algorithm]] for the [[network scheduler]] that is used in [[Asynchronous Transfer Mode]] (ATM) networks.<ref name="ATMF-GCRA"/><ref name="ITU-T-GCRA"/> It is used to measure the timing of [[Asynchronous Transfer Mode#The structure of an ATM cell\|cells]] on [[Virtual circuit\|virtual channel]]s (VCs) and or [[Virtual Paths]] (VPs) against [[Bandwidth (signal processing)\|bandwidth]] and [[jitter]] limits contained in a [[traffic contract]] for the VC or VP to which the cells belong. Cells that do not conform to the limits given by the traffic contract may then be re-timed (delayed) in [[traffic shaping]], or may be dropped (discarded) or reduced in priority (demoted) in [[Traffic policing (communications)\|traffic policing]]. Nonconforming cells that are reduced in priority may then be dropped, in preference to higher priority cells, by downstream components in the network that are experiencing congestion. Alternatively they may reach their destination (VC or VP termination) if there is enough capacity for them, despite them being excess cells as far as the contract is concerned: see [[priority control]]<!-- another page in need of a rewrite -->.

Turtlecrown: /* Dual Leaky Bucket Controller */ add wikilink

2024-07-11T13:29:16Z

Dual Leaky Bucket Controller: add wikilink

← Previous revision		Revision as of 13:29, 11 July 2024
Line 50:		Line 50:
	If the cells arrive in a burst at a rate higher than 1/PCR (MBS cells arrive in less than (MBS - 1)/PCR - ''τ''<sub>''PCR''</sub>), or more than MBS cells arrive at the PCR, or bursts of MBS cells arrive closer than IMT apart, the dual leaky bucket will detect this and delay (shaping) or drop or de-prioritize (policing) enough cells to make the connection conform.		If the cells arrive in a burst at a rate higher than 1/PCR (MBS cells arrive in less than (MBS - 1)/PCR - ''τ''<sub>''PCR''</sub>), or more than MBS cells arrive at the PCR, or bursts of MBS cells arrive closer than IMT apart, the dual leaky bucket will detect this and delay (shaping) or drop or de-prioritize (policing) enough cells to make the connection conform.

	Figure 3 shows the reference algorithm for SCR and PCR control for both Cell Loss Priority (CLP) values 1 (low) and 0 (high) cell flows, i.e. where the cells with both priority values are treated the same. Similar reference algorithms where the high and low priority cells are treated differently are also given in Annex A to I.371 .<ref name="ITU-T-GCRA"/>		Figure 3 shows the reference algorithm for SCR and PCR control for both [[Cell Loss Priority]] (CLP) values 1 (low) and 0 (high) cell flows, i.e. where the cells with both priority values are treated the same. Similar reference algorithms where the high and low priority cells are treated differently are also given in Annex A to I.371 .<ref name="ITU-T-GCRA"/>

	==See also==		==See also==

Kvng: added Category:Asynchronous Transfer Mode using HotCat

2023-04-17T15:05:26Z

added Category:Asynchronous Transfer Mode using HotCat

← Previous revision		Revision as of 15:05, 17 April 2023
Line 74:		Line 74:
	[[Category:Teletraffic]]		[[Category:Teletraffic]]
	[[Category:Network scheduling algorithms]]		[[Category:Network scheduling algorithms]]
			[[Category:Asynchronous Transfer Mode]]

Beland: convert special characters (via WP:JWB)

2021-03-24T06:02:16Z

convert special characters (via WP:JWB)

← Previous revision		Revision as of 06:02, 24 March 2021
Line 15:		Line 15:
	However, while there are possible advantages in understanding this leaky bucket description, it does not necessarily result in the best (fastest) code if implemented directly. This is evidenced by the relative number of actions to be performed in the flow diagrams for the two descriptions (figure 1).		However, while there are possible advantages in understanding this leaky bucket description, it does not necessarily result in the best (fastest) code if implemented directly. This is evidenced by the relative number of actions to be performed in the flow diagrams for the two descriptions (figure 1).

	The description in terms of the continuous state leaky bucket algorithm is given by the ITU-T as follows: ~~“The~~ continuous-state leaky bucket can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content is increased by the increment ''T'' for each conforming cell... If at a cell arrival the content of the bucket is less than or equal to the limit value ''~~τ~~'', then the cell is conforming; otherwise, the cell is non-conforming. The capacity of the bucket (the upper bound of the counter) is (''T'' + ''~~τ~~'')” .<ref name="ITU-T-GCRA"/> It is worth noting that because the leak is one unit of content per unit time, the increment for each cell ''T'' and the limit value ''τ'' are in units of time.		The description in terms of the continuous state leaky bucket algorithm is given by the ITU-T as follows: "The continuous-state leaky bucket can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content is increased by the increment ''T'' for each conforming cell... If at a cell arrival the content of the bucket is less than or equal to the limit value ''τ'', then the cell is conforming; otherwise, the cell is non-conforming. The capacity of the bucket (the upper bound of the counter) is (''T'' + ''τ'')" .<ref name="ITU-T-GCRA"/> It is worth noting that because the leak is one unit of content per unit time, the increment for each cell ''T'' and the limit value ''τ'' are in units of time.

	Considering the flow diagram of the continuous state leaky bucket algorithm, in which ''T'' is the emission interval and ''τ'' is the limit value: What happens when a cell arrives is that the state of the bucket is calculated from its state when the last conforming cell arrived, ''X'', and how much has leaked out in the interval, ''t<sub>a</sub>'' – ''LCT''. This current bucket value is then stored in ''X' '' and compared with the limit value ''τ''. If the value in ''X' '' is not greater than ''τ'', the cell did not arrive too early and so conforms to the contract parameters; if the value in ''X' '' is greater than ''τ'', then it does not conform. If it conforms then, if it conforms because it was late, i.e. the bucket empty (''X' '' <= 0), ''X'' is set to ''T''; if it was early, but not too early, (''τ'' >= ''X' '' > 0), ''X'' is set to ''X' '' + ''T''.		Considering the flow diagram of the continuous state leaky bucket algorithm, in which ''T'' is the emission interval and ''τ'' is the limit value: What happens when a cell arrives is that the state of the bucket is calculated from its state when the last conforming cell arrived, ''X'', and how much has leaked out in the interval, ''t<sub>a</sub>'' – ''LCT''. This current bucket value is then stored in ''X' '' and compared with the limit value ''τ''. If the value in ''X' '' is not greater than ''τ'', the cell did not arrive too early and so conforms to the contract parameters; if the value in ''X' '' is greater than ''τ'', then it does not conform. If it conforms then, if it conforms because it was late, i.e. the bucket empty (''X' '' <= 0), ''X'' is set to ''T''; if it was early, but not too early, (''τ'' >= ''X' '' > 0), ''X'' is set to ''X' '' + ''T''.
Line 25:		Line 25:
	The virtual scheduling algorithm, while not so obviously related to such an easily accessible analogy as the leaky bucket, gives a clearer understanding of what the GCRA does and how it may be best implemented. As a result, direct implementation of this version can result in more compact, and thus faster, code than a direct implementation of the leaky bucket description.		The virtual scheduling algorithm, while not so obviously related to such an easily accessible analogy as the leaky bucket, gives a clearer understanding of what the GCRA does and how it may be best implemented. As a result, direct implementation of this version can result in more compact, and thus faster, code than a direct implementation of the leaky bucket description.

	The description in terms of the virtual scheduling algorithm is given by the ITU-T as follows: ~~“The~~ virtual scheduling algorithm updates a Theoretical Arrival Time (TAT), which is the 'nominal' arrival time of the cell assuming cells are sent equally spaced at an emission interval of ''T'' corresponding to the cell rate ''Λ'' [= 1/''T''] when the source is active. If the actual arrival time of a cell is not 'too early' relative to the ''TAT'' and tolerance ''τ'' associated to the cell rate, i.e. if the actual arrival time is after its theoretical arrive time minus the limit value (t<sub>a</sub> > ''TAT'' – ''τ''), then the cell is conforming; otherwise, the cell is nonconforming" .<ref name="ITU-T-GCRA"/> If the cell is nonconforming then ''TAT'' is left unchanged. If the cell is conforming, and arrived before its TAT (equivalent to the bucket not being empty but being less than the limit value), then the next cell's ''TAT'' is simply ''TAT'' + ''T''. However, if a cell arrives after its ''TAT'', then the ''TAT'' for the next cell is calculated from this cell's arrival time, not its ''TAT''. This prevents credit building up when there is a gap in the transmission (equivalent to the bucket becoming less than empty).		The description in terms of the virtual scheduling algorithm is given by the ITU-T as follows: "The virtual scheduling algorithm updates a Theoretical Arrival Time (TAT), which is the 'nominal' arrival time of the cell assuming cells are sent equally spaced at an emission interval of ''T'' corresponding to the cell rate ''Λ'' [= 1/''T''] when the source is active. If the actual arrival time of a cell is not 'too early' relative to the ''TAT'' and tolerance ''τ'' associated to the cell rate, i.e. if the actual arrival time is after its theoretical arrive time minus the limit value (t<sub>a</sub> > ''TAT'' – ''τ''), then the cell is conforming; otherwise, the cell is nonconforming" .<ref name="ITU-T-GCRA"/> If the cell is nonconforming then ''TAT'' is left unchanged. If the cell is conforming, and arrived before its TAT (equivalent to the bucket not being empty but being less than the limit value), then the next cell's ''TAT'' is simply ''TAT'' + ''T''. However, if a cell arrives after its ''TAT'', then the ''TAT'' for the next cell is calculated from this cell's arrival time, not its ''TAT''. This prevents credit building up when there is a gap in the transmission (equivalent to the bucket becoming less than empty).

	This version of the algorithm works because ''τ'' defines how much earlier a cell can arrive than it would if there were no jitter: see [[leaky bucket#Delay Variation Tolerance\|leaky bucket: delay variation tolerance]]. Another way to see it is that ''TAT'' represents when the bucket will next empty, so a time ''τ'' before that is when the bucket is exactly filled to the limit value. So, in either view, if it arrives more than ''τ'' before ''TAT'', it is too early to conform.		This version of the algorithm works because ''τ'' defines how much earlier a cell can arrive than it would if there were no jitter: see [[leaky bucket#Delay Variation Tolerance\|leaky bucket: delay variation tolerance]]. Another way to see it is that ''TAT'' represents when the bucket will next empty, so a time ''τ'' before that is when the bucket is exactly filled to the limit value. So, in either view, if it arrives more than ''τ'' before ''TAT'', it is too early to conform.

23.241.155.122: /* Fix the link to leaky bucket maximum burst size chapter */

2020-05-14T17:06:34Z

Fix the link to leaky bucket maximum burst size chapter

← Previous revision		Revision as of 17:06, 14 May 2020
Line 46:		Line 46:

	[[Image:Dual LBC.JPG\|thumb\|500px\| Figure 3: Reference algorithm for Sustainable Cell Rate (SCR) and Peak Cell Rate (PCR) for CLP = 0 + 1 cell flow]]		[[Image:Dual LBC.JPG\|thumb\|500px\| Figure 3: Reference algorithm for Sustainable Cell Rate (SCR) and Peak Cell Rate (PCR) for CLP = 0 + 1 cell flow]]
	In the dual leaky bucket, one bucket is applied to the traffic with an emission interval of 1/SCR and a limit value ''τ''<sub>''SCR''</sub> that gives an MBS that is the number of cells in the message: see [[leaky bucket#Maximum ~~Burst~~ ~~Size~~]]. The second bucket has an emission interval of 1/PCR and a limit value ''τ''<sub>''PCR''</sub> that allows for the CDV up to that point in the path of the connection: see [[leaky bucket#Delay Variation Tolerance]]. Cells are then allowed through at the PCR, with jitter of ''τ''<sub>''PCR''</sub>, up to a maximum number of MBS cells. The next burst of MBS cells will then be allowed through starting MBS x 1/SCR after the first.		In the dual leaky bucket, one bucket is applied to the traffic with an emission interval of 1/SCR and a limit value ''τ''<sub>''SCR''</sub> that gives an MBS that is the number of cells in the message: see [[leaky bucket#Maximum burst size]]. The second bucket has an emission interval of 1/PCR and a limit value ''τ''<sub>''PCR''</sub> that allows for the CDV up to that point in the path of the connection: see [[leaky bucket#Delay Variation Tolerance]]. Cells are then allowed through at the PCR, with jitter of ''τ''<sub>''PCR''</sub>, up to a maximum number of MBS cells. The next burst of MBS cells will then be allowed through starting MBS x 1/SCR after the first.

	If the cells arrive in a burst at a rate higher than 1/PCR (MBS cells arrive in less than (MBS - 1)/PCR - ''τ''<sub>''PCR''</sub>), or more than MBS cells arrive at the PCR, or bursts of MBS cells arrive closer than IMT apart, the dual leaky bucket will detect this and delay (shaping) or drop or de-prioritize (policing) enough cells to make the connection conform.		If the cells arrive in a burst at a rate higher than 1/PCR (MBS cells arrive in less than (MBS - 1)/PCR - ''τ''<sub>''PCR''</sub>), or more than MBS cells arrive at the PCR, or bursts of MBS cells arrive closer than IMT apart, the dual leaky bucket will detect this and delay (shaping) or drop or de-prioritize (policing) enough cells to make the connection conform.

Julian wang.666: /* Virtual scheduling description */

2017-08-23T03:05:48Z

Virtual scheduling description

← Previous revision		Revision as of 03:05, 23 August 2017
Line 25:		Line 25:
	The virtual scheduling algorithm, while not so obviously related to such an easily accessible analogy as the leaky bucket, gives a clearer understanding of what the GCRA does and how it may be best implemented. As a result, direct implementation of this version can result in more compact, and thus faster, code than a direct implementation of the leaky bucket description.		The virtual scheduling algorithm, while not so obviously related to such an easily accessible analogy as the leaky bucket, gives a clearer understanding of what the GCRA does and how it may be best implemented. As a result, direct implementation of this version can result in more compact, and thus faster, code than a direct implementation of the leaky bucket description.

	The description in terms of the ~~continuous~~ ~~state leaky bucket~~ algorithm is given by the ITU-T as follows: “The virtual scheduling algorithm updates a Theoretical Arrival Time (TAT), which is the 'nominal' arrival time of the cell assuming cells are sent equally spaced at an emission interval of ''T'' corresponding to the cell rate ''Λ'' [= 1/''T''] when the source is active. If the actual arrival time of a cell is not 'too early' relative to the ''TAT'' and tolerance ''τ'' associated to the cell rate, i.e. if the actual arrival time is after its theoretical arrive time minus the limit value (t<sub>a</sub> > ''TAT'' – ''τ''), then the cell is conforming; otherwise, the cell is nonconforming" .<ref name="ITU-T-GCRA"/> If the cell is nonconforming then ''TAT'' is left unchanged. If the cell is conforming, and arrived before its TAT (equivalent to the bucket not being empty but being less than the limit value), then the next cell's ''TAT'' is simply ''TAT'' + ''T''. However, if a cell arrives after its ''TAT'', then the ''TAT'' for the next cell is calculated from this cell's arrival time, not its ''TAT''. This prevents credit building up when there is a gap in the transmission (equivalent to the bucket becoming less than empty).		The description in terms of the virtual scheduling algorithm is given by the ITU-T as follows: “The virtual scheduling algorithm updates a Theoretical Arrival Time (TAT), which is the 'nominal' arrival time of the cell assuming cells are sent equally spaced at an emission interval of ''T'' corresponding to the cell rate ''Λ'' [= 1/''T''] when the source is active. If the actual arrival time of a cell is not 'too early' relative to the ''TAT'' and tolerance ''τ'' associated to the cell rate, i.e. if the actual arrival time is after its theoretical arrive time minus the limit value (t<sub>a</sub> > ''TAT'' – ''τ''), then the cell is conforming; otherwise, the cell is nonconforming" .<ref name="ITU-T-GCRA"/> If the cell is nonconforming then ''TAT'' is left unchanged. If the cell is conforming, and arrived before its TAT (equivalent to the bucket not being empty but being less than the limit value), then the next cell's ''TAT'' is simply ''TAT'' + ''T''. However, if a cell arrives after its ''TAT'', then the ''TAT'' for the next cell is calculated from this cell's arrival time, not its ''TAT''. This prevents credit building up when there is a gap in the transmission (equivalent to the bucket becoming less than empty).

	This version of the algorithm works because ''τ'' defines how much earlier a cell can arrive than it would if there were no jitter: see [[leaky bucket#Delay Variation Tolerance\|leaky bucket: delay variation tolerance]]. Another way to see it is that ''TAT'' represents when the bucket will next empty, so a time ''τ'' before that is when the bucket is exactly filled to the limit value. So, in either view, if it arrives more than ''τ'' before ''TAT'', it is too early to conform.		This version of the algorithm works because ''τ'' defines how much earlier a cell can arrive than it would if there were no jitter: see [[leaky bucket#Delay Variation Tolerance\|leaky bucket: delay variation tolerance]]. Another way to see it is that ''TAT'' represents when the bucket will next empty, so a time ''τ'' before that is when the bucket is exactly filled to the limit value. So, in either view, if it arrives more than ''τ'' before ''TAT'', it is too early to conform.

Julian wang.666: /* Leaky bucket description */

2017-08-22T03:16:37Z

Leaky bucket description

← Previous revision		Revision as of 03:16, 22 August 2017
Line 17:		Line 17:
	The description in terms of the continuous state leaky bucket algorithm is given by the ITU-T as follows: “The continuous-state leaky bucket can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content is increased by the increment ''T'' for each conforming cell... If at a cell arrival the content of the bucket is less than or equal to the limit value ''τ'', then the cell is conforming; otherwise, the cell is non-conforming. The capacity of the bucket (the upper bound of the counter) is (''T'' + ''τ'')” .<ref name="ITU-T-GCRA"/> It is worth noting that because the leak is one unit of content per unit time, the increment for each cell ''T'' and the limit value ''τ'' are in units of time.		The description in terms of the continuous state leaky bucket algorithm is given by the ITU-T as follows: “The continuous-state leaky bucket can be viewed as a finite capacity bucket whose real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content is increased by the increment ''T'' for each conforming cell... If at a cell arrival the content of the bucket is less than or equal to the limit value ''τ'', then the cell is conforming; otherwise, the cell is non-conforming. The capacity of the bucket (the upper bound of the counter) is (''T'' + ''τ'')” .<ref name="ITU-T-GCRA"/> It is worth noting that because the leak is one unit of content per unit time, the increment for each cell ''T'' and the limit value ''τ'' are in units of time.

	Considering the flow diagram of the continuous state leaky bucket algorithm, in which ''T'' is the emission interval and ''τ'' is the limit value: What happens when a cell arrives is that the state of the bucket is calculated from its state when the last conforming cell arrived, ''X'', and how much has leaked out in the interval, ''t<sub>a</sub>'' – ''LCT''. This current bucket value is then stored in ''X' '' and compared with the limit value ''τ''. If the value in ''X' '' is not greater than ''τ'', the cell did not arrive too early and so conforms to the contract parameters; if the value in ''X' '' is greater than ''τ'', then it does not conform. If it conforms then, if it conforms because it was late, i.e. the bucket empty (''X' '' <= 0), ''X'' is set to ''T''; if it was early, but not too early, (''τ'' >= ''X' '' > 0), ''X'' is set to ''X' '' + ''τ''.		Considering the flow diagram of the continuous state leaky bucket algorithm, in which ''T'' is the emission interval and ''τ'' is the limit value: What happens when a cell arrives is that the state of the bucket is calculated from its state when the last conforming cell arrived, ''X'', and how much has leaked out in the interval, ''t<sub>a</sub>'' – ''LCT''. This current bucket value is then stored in ''X' '' and compared with the limit value ''τ''. If the value in ''X' '' is not greater than ''τ'', the cell did not arrive too early and so conforms to the contract parameters; if the value in ''X' '' is greater than ''τ'', then it does not conform. If it conforms then, if it conforms because it was late, i.e. the bucket empty (''X' '' <= 0), ''X'' is set to ''T''; if it was early, but not too early, (''τ'' >= ''X' '' > 0), ''X'' is set to ''X' '' + ''T''.

	Thus the flow diagram mimics the leaky bucket analogy (used as a meter) directly, with ''X'' and ''X' '' acting as the analogue of the bucket.		Thus the flow diagram mimics the leaky bucket analogy (used as a meter) directly, with ''X'' and ''X' '' acting as the analogue of the bucket.

Graham.Fountain: /* Leaky bucket description */ Change links to match changes in LB page

2017-08-15T09:42:10Z

Leaky bucket description: Change links to match changes in LB page

← Previous revision		Revision as of 09:42, 15 August 2017
Line 11:		Line 11:
	===Leaky bucket description===		===Leaky bucket description===

	The description in terms of the [[leaky bucket]] algorithm may be the easier of the two to understand from a conceptual perspective, as it is based on a simple analogy of a bucket with a leak: see figure 1 on the [[leaky bucket]] page. However, there has been confusion in the literature over the application of the leaky bucket analogy to produce an algorithm, which has crossed over to the GCRA. The GCRA should be considered as a version of [[leaky bucket#~~The Leaky Bucket Algorithm as~~ a ~~Meter~~\|the leaky bucket as a meter]] rather than [[leaky bucket#~~The Leaky Bucket Algorithm as~~ a ~~Queue~~\|the leaky bucket as a queue]].		The description in terms of the [[leaky bucket]] algorithm may be the easier of the two to understand from a conceptual perspective, as it is based on a simple analogy of a bucket with a leak: see figure 1 on the [[leaky bucket]] page. However, there has been confusion in the literature over the application of the leaky bucket analogy to produce an algorithm, which has crossed over to the GCRA. The GCRA should be considered as a version of [[leaky bucket#As a meter\|the leaky bucket as a meter]] rather than [[leaky bucket#As a queue\|the leaky bucket as a queue]].

	However, while there are possible advantages in understanding this leaky bucket description, it does not necessarily result in the best (fastest) code if implemented directly. This is evidenced by the relative number of actions to be performed in the flow diagrams for the two descriptions (figure 1).		However, while there are possible advantages in understanding this leaky bucket description, it does not necessarily result in the best (fastest) code if implemented directly. This is evidenced by the relative number of actions to be performed in the flow diagrams for the two descriptions (figure 1).

Magioladitis: /* References */clean up, replaced: ISBN 0-13-393828-X → {{ISBN|0-13-393828-X}} using AWB (12151)

2017-06-22T14:52:49Z

References: clean up, replaced: ISBN 0-13-393828-X → {{ISBN|0-13-393828-X}} using AWB (12151)

← Previous revision		Revision as of 14:52, 22 June 2017
Line 67:		Line 67:
	<ref name="UPC_NPC" >ITU-T, ''Traffic control and congestion control in B ISDN'', Recommendation I.371, International Telecommunication Union, 2004, page 17</ref>		<ref name="UPC_NPC" >ITU-T, ''Traffic control and congestion control in B ISDN'', Recommendation I.371, International Telecommunication Union, 2004, page 17</ref>
	<ref name="ITU-T-GCRA" >ITU-T, ''Traffic control and congestion control in B ISDN'', Recommendation I.371, International Telecommunication Union, 2004, Annex A, page 87.</ref>		<ref name="ITU-T-GCRA" >ITU-T, ''Traffic control and congestion control in B ISDN'', Recommendation I.371, International Telecommunication Union, 2004, Annex A, page 87.</ref>
	<ref name="ATMF-GCRA" >ATM Forum, The User Network Interface (UNI), v. 3.1, ISBN 0-13-393828-X, Prentice Hall PTR, 1995.</ref>		<ref name="ATMF-GCRA" >ATM Forum, The User Network Interface (UNI), v. 3.1, {{ISBN\|0-13-393828-X}}, Prentice Hall PTR, 1995.</ref>
	}}		}}

Kvng: added Category:Network scheduling algorithms using HotCat

2015-04-22T15:38:10Z

added Category:Network scheduling algorithms using HotCat

← Previous revision		Revision as of 15:38, 22 April 2015
Line 73:		Line 73:
	[[Category:Networking algorithms]]		[[Category:Networking algorithms]]
	[[Category:Teletraffic]]		[[Category:Teletraffic]]
			[[Category:Network scheduling algorithms]]