Practical Considerations for Enabling a srTCM Behavior in
Opnet Modeler
Pana Flavius and Put Ferdi
Leuven Institute for Research in Information Systems, Katholieke Universiteit Leuven, Leuven, Belgium
Keywords: Qos, Diffserv, srTCM, Simulation, OPNET.
Abstract: Different Quality of Service (QoS) mechanisms have been proposed over time. Differentiated Services
(DiffServ) represents one of the main QoS mechanisms developed, and is based on a strategy of traffic
differentiation. Introduced in order to be used within DiffServ, the single rate Three Color Marker (srTCM)
represents a policer which meters the IP packet stream and marks the traffic with different drop
probabilities. This paper presents the technical aspects of implementing the srTCM in one of the most
important network simulation tools on the market, OPNET Modeller. Practical considerations and a test
case of the proposed implementation are presented.
1 INTRODUCTION
Differentiated Services (DiffServ) represents a
scalable option for enabling QoS on the Internet.
The basic approach proposed by the DiffServ
mechanism is the differentiation of traffic based on
traffic classes (Blake, et al., 1998). These classes are
identified by the use of the Differentiated Service
Code Points (DSCP) introduced in (Nichols, Blake,
Baker and Black, 1998). Defined as the “externally
observable forwarding behavior applied to a
DiffServ node”, the forwarding path behavior is
identified as the Per Hop Behavior (PHB). Using
DSCP, DiffServ classifies each packet to a PHB at
every network node from the sender to the receiver
host.
Three important types of forwarding behavior or
PHB have been standardized over time. These are
the Default (DF) PHB, the Assured Forwarding (AF)
PHB and the Expedited Forwarding (EF) PHB.
The AF PHB is defined in four different PHB
groups with three PHBs in each group (Heinanen,
Baker, Weiss and Wroclawski, 1999). The PHB
groups are named AF classes and the three PHBs
defined in a class represent drop precedence levels
for that particular class. The introduction of AF
classes gives service providers the possibility to
differentiate between the offered services.
The Internet Engineering Task Force (IETF)
introduces also a series of specific implementers like
traffic markers and traffic shapers, in order to
support the functional requests of the PHBs.
Three different types of markers are introduced:
single rate Three Color Marker (srTCM) in
(Heinanen and Guerin, 1999a), two rate Three Color
Marker (trTCM) by (Heinanen and Guerin, 1999b)
and Time Sliding Window Three Color Marker
(TSWTCM) in (Fang, Seddigh and Nandy, 2000).
All the presented markers were intended to mark
packets that are treated by the AF PHB. Each of
them meters a traffic stream and marks packets to be
green, yellow or red. In the specific case of the AF
PHB, the color is coded as the drop precedence of
the packet. The main difference between the
proposed markers is the specific use of rates and
parameters in order to mark the packets.
OPNET Modeler represents nowadays one of the
most used simulation tools for network researchers
(OPNET, 2012). OPNET currently supports the
DiffServ mechanism, but it does not have an
implementation of the three markers previously
presented. Because of this drawback, some broader
simulation scenarios, like the examples proposed by
(Babiarz, Chan and Baker, 2006) could not be
analyzed.
The current work presents some practical
considerations on how to implement the srTCM
behavior in OPNET Modeler. Illustrated are also
some concepts that will further help researchers to
implement other types of markers, for example the
trTCM.
449
Flavius P. and Ferdi P..
Practical Considerations for Enabling a srTCM Behavior in Opnet Modeler.
DOI: 10.5220/0004052804490452
In Proceedings of the 2nd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH-2012),
pages 449-452
ISBN: 978-989-8565-20-4
Copyright
c
 2012 SCITEPRESS (Science and Technology Publications, Lda.)

The paper is organized as follow. In section 2
practical considerations are illustrated on how to
implement srTCM in OPNET Modeler. In section 3
we will test our implementation. Concluding
remarks are given in section 4.
2 IMPLEMENTATION
The configuration of the srTCM is done by
assigning three traffic parameters: the Committed
Information Rate (CIR), the Committed Burst Size
(CBS) and Excess Burst Size (EBS). The way in
which the marker should work is presented in
(Heinanen and Guerin, 1999a). The behavior is
specified in terms of two token buckets: a bucket
“C” associated with the CBS value, and a bucket
“E” associated with EBS. Both buckets share a
common rate CIR.
Initially the token count for each bucket equals
the maximum size of that token bucket, meaning that
both buckets are full. The token count for bucket C
(TC) equals CBS and for bucket E (TE) equals EBS.
The token counts TC and TE are updated CIR times
per second in the following manner: if TC is less
than CBS, TC is incremented with one token, else if
TE is less than EBS then TE is incremented with one
token. If both token counts are at their maximum
values then neither TE nor TC can be incremented.
Figure 1 illustrates the srTCM operations.
Figure 1: The operations of srTCM.
OPNET implements a policer using the
Committed Access Rate (CAR) algorithm (OPNET,
2010). This type of policer enables the device to
limit any input or output transmission rate on a
specific interface. More information on how the
CAR algorithms functions can be found in the Cisco
documentation (Cisco, 2012). So as to implement
the srTCM algorithm in OPNET we are going to
start from the already implemented CAR algorithm.
The only difference that exists between the
srTCM specification and our OPNET
implementation is that in the latter case the EBS is
not specified directly, but must be derived from
another parameter, named Extended Burst Size
(XBS). Because XBS represents the total volume of
the two token buckets, EBS must be equal to the
difference between XBS and CBS.
In what follows we present the pseudo code used
for implementing srTCM in OPNET Modeler.
Pseudo code used for updating the token bucket:
total tokens = total tokens + CIR *
(simulation time – update time);
update time = simulation time;
if (total tokens > CBS)
{if (debt > 0)
{if (total tokens - CBS >= debt)
{total tokens = CBS;
Debt = 0;}
else
{debt = debt – (total tokens – CBS);
total tokens = CBS;}
}
else total tokens = CBS;
}
The first part of the pseudo code is in charge of
updating the token bucket; this code is already
partially implemented in OPNET as part of the CAR
algorithm. Figure 2 illustrates the behaviour of the
implemented srTCM in OPNET.
Figure 2: Implementation of srTCM.
The variable total tokens implements
simultaneously two functions. First it is used to
register the total amount of tokens that are available
after a certain amount of time. And secondly, it is
used to implement the token bucket C (as is defined
in the RFC), where the value of this variable
represents in fact what is defined as TC. This
variable ranges from the value ‘0’ (when no tokens
are available in bucket C) to a value equal to CBS
(when the bucket is full).
The debt variable presented in the pseudo-code,
represents the free space in the second bucket
(bucket E). The value of this variable can be used to
retrieve the value of TE, where TE is equal to EBS
minus the value of debt. The variable debt ranges
from a value equal to EBS (when no tokens are
available in bucket E), to a value of ‘0’ (when
?
CIR
CBS
TC
BucketC
EBS
TE
BucketE
OverflowfrombucketC
?
CIR
CBS
EBS
TC
TE
‘debt ’
BucketC
BucketE
OverflowfrombucketC
‘totaltokens’
SIMULTECH2012-2ndInternationalConferenceonSimulationandModelingMethodologies,Technologiesand
Applications
450

b
ucket
E
Prev
i
of the t
o
the upd
a
p
resente
d
tokens,
a
tokens i
necessa
r
specific
a
the val
u
necessa
r
On t
h
it is ch
e
not. If t
h
b
ucket i
b
ucket
a
of the
E
necessa
r
token c
o
are put
t
case wh
e
that tot
a
equals t
o
Next
actual
d
p
rocedu
r
Orig
i
confor
m
the pac
k
first bu
c
subtract
e
Howeve
r
total to
k
enough
t
compari
n
p
acket s
the pack
value is
or “yell
o
Pse
u
if(pac
k
{tota
l
packe
t
else
{
potent
i
pack
e
if(po
t
else
}
E
is full of tok
e
i
ously we dis
c
o
tal tokens v
a
a
te of the tok
d
pseudo c
o
a
n if stateme
n
i
s bigger tha
n
r
y so as t
o
a
tions of the
m
u
e is less th
a
r
y for updatin
g
h
e other hand
e
cked whethe
r
h
e debt is big
g
s not full, th
a
re put in the
Excess Burs
t
r
y are availab
l
o
unts for both
t
o their maxi
m
e
n the two t
o
a
l tokens is b
o
0.
the pseudo
c
d
ecision ma
k
r
e is presente
d
i
nally it is
m
ing or “gree
n
k
et size is le
s
c
ket. If this
e
d from th
e
r
, if the pack
e
k
ens variabl
e
t
okens in the
n
g the value
ize against t
h
k
et is marked
a
less, then the
o
w”.
u
do code used
f
k
et size <
l
tokens =
t
size;}
i
al debt =
e
t size;
t
ential de
b
{traffic
_
{traffic
_
debt = p
o
e
ns).
c
ussed the do
a
riable. This
d
en buckets.
W
o
de that aft
e
n
t checks if t
h
n
the CBS.
T
o
comply
w
m
arke
r
. In th
e
a
n CBS, no
g
the token b
u
if the value i
s
r
the second
g
er than zero
,
e excess tok
e
second buck
e
t
Size. If
m
l
e, they are ju
s
buckets (tota
l
m
um value. T
h
o
kens buckets
igger than C
B
c
ode used for
k
ing or the
d
.
assumed th
a
n
“. It is then
s
s than the t
o
is true th
e
e
total am
o
et
size excee
d
e
, it is chec
k
second buck
e
of the debt
h
e EBS. If th
e
a
s violating,
o
packet is ma
r
f
or the markin
g
total tok
e
total tok
e
debt +
b
t > EBS)
_
violate =
_
exceed =
t
o
tential d
e
u
ble function
a
d
uality is us
e
W
e can see i
n
e
r the updat
e
h
e total amou
n
T
his conditi
o
w
ith the ori
g
e
simple case
o
ther actions
u
ckets.
s
bigger than
C
bucket is fu
l
meaning tha
t
e
ns from the
e
t up to the
v
m
ore tokens
s
t ignored an
d
l
tokens and
d
h
is being als
o
are full mea
n
B
S and that
implementin
g
actual mar
k
a
t the pack
e
checked wh
e
o
ken count o
f
e
packet siz
e
o
unt of to
k
d
s the value o
f
k
ed if there
e
t. This is don
variable plu
s
e
value is bi
g
o
r “red”, and i
f
r
ked as excee
d
g
procedures:
e
ns)
e
ns –
true;}
t
rue;
e
bt;}
ality
e
d in
n
the
e
of
n
t of
o
n is
g
inal
that
s
are
C
BS
l
l or
t
the
first
v
alue
than
d
the
d
ebt)
o
the
n
ing
debt
g
the
king
e
t is
e
ther
f
the
e
is
k
ens.
f
the
are
n
e by
s
the
g
ger,
f
the
ding
3
In
co
n
p
ol
i
as
a
tes
t
the
wh
i
b
ot
t
ce
n
to
p
de
fi
ha
n
p
ar
a
the
lo
w
im
p
co
n
is s
is
C
S
o
Se
r
Se
r
Se
r
Se
r
MODE
L
order to test
n
structed a si
m
i
cing the mo
d
a
srTCM ma
r
t
our implem
e
links in the
t
i
ch operate
t
leneck link
n
ter of the top
o
p
oint DS1 lin
k
Four pairs of
Fig
u
fi
ned. All the
n
d side) to the
Table 1
p
a
meters. All
t
Assured Fo
r
w
est level of d
r
p
lementation
s
n
forming (kee
p
m
alle
r
than T
C
BS, that in t
h
Ta
b
o
urce Sink
r
ver 1 Client 1
r
ver 2 Client 2
r
ver 3 Client 3
r
ver 4 Client 4
L
TESTIN
G
the present
e
m
ulation sce
n
d
ified CAR al
g
r
ker. The net
w
e
ntation can
b
opology are
1
at 100 M
b
connecting t
h
o
logy. This b
o
k
which opera
t
traffic source
u
re 3: Network
traffic flows
client (lef
t
h
a
p
resents th
e
t
he traffic is
d
r
warding (A
F
r
op probabilit
y
s
hould be ab
l
p
the AF21 c
C. The bigge
s
h
is scenario is
b
le 1: Traffic p
a
A
FTP
Inter requ
e
time
(seconds
)
exponenti
(360)
exponenti
(360)
exponenti
(150)
HTTP( 2 types of
objects/ page)
exponenti
(1)
G
e
d implemen
t
n
ario that use
s
g
orithm whic
h
w
ork topolog
y
b
e seen in fig
u
1
00BaseT du
p
b
ps, except
h
e two rout
e
o
ttleneck link
a
tes at 1.544
M
e
s and sinks a
r
Topology.
from the ser
v
a
nd side).
e
associate
d
d
efined as bel
o
F
) class 2, h
a
t
y (AF 21). T
h
l
e to mark a
p
c
lass) if the p
a
s
t possible va
l
set to 1 Mbit
.
a
rameters.
A
pplications
e
st
s
)
File size
(
i
al
50 0
0
i
al
25 000
i
al
5 000
0
i
al
object 1
consta
n
(x1 ob
j
/page)
object 2
unifor
m
10000
)
object
s
t
ation we
s
as edge
h
behaves
y
used to
u
re 3. All
p
lex links
for the
e
rs in the
is a point
M
bps.
r
e
v
er (righ
t
d
traffic
o
nging to
a
ving the
h
e srTCM
p
acket as
a
cket size
l
ue of TC
.
The
(
bytes)
0
0
000
0
00
n
t (1000)
j
ect
m
(2000,
)
(x7
s
/ page)
PracticalConsiderationsforEnablingasrTCMBehaviorinOpnetModeler
451

packets should be marked as exceeding (AF 22
class) if the size is bigger than TC, but not bigger
than TE. The value associated with the XBS in this
case is 50 Mbit. And finally, the packet should be
marked as violating (AF23 class) when the packet
size exceeds both TC and TE.
Figure 4 presents the statistics collected at the
Client Backbone node. We can see in figure 4 that
the srTCM implementation marks the traffic flow
with three different DSCPs depending of the volume
of traffic and on the value of the three parameters
(CIR, CBS and EBS).
The traffic of the AF 2 class associated with the
lowest level of drop precedence (AF21) is colored
green and varies slightly above the value of the
defined CIR of 100000 bits. The highest value of
around 200000 bits can be noticed in the first
seconds of the simulation. This type of behavior is
normal, because in the beginning the first token
bucket is full and tokens can be “borrowed” from
this bucket. But, after some time the bucket becomes
empty and since traffic is arriving faster than the
refill rate of the tokens, the bucket does not have
time to get refilled and the traffic will be marked as
“green” (AF21) only up to the value of the defined
CIR. However, we can notice that the green traffic is
constantly above this CIR. The reason for this is that
violating traffic marked as AF23 does not consume
any tokens, thus giving the chance to the token
bucket to accumulate tokens.
Concerning the second level of drop precedence
(AF22) colored yellow, we can see that the tokens
associated with this class are all consumed in the
first minute of the simulation. Afterwards, because
the traffic volume surpasses the CIR, the second
bucket does not get a chance to receive any tokens.
This type of behavior is due to the fact that the
srTCM recommendation specifies that the second
bucket can be refilled only if the first bucket is full.
Figure 4: Obtained results.
This kind of problem can be avoided using
trTCM instead of srTCM. With trTCM each token
bucket has associated a distinct rate which refills the
bucket.
The third level of drop precedence AF23
(colored red) is associated will all the traffic which
does not receive tokens from any of the token
buckets. We can see that this type of marking starts
only after all the tokens are consumed.
4 CONCLUSIONS
The current paper presents an implementation of the
srTCM in OPNET Modeler. Pseudo code used for
this implementation is presented. The
implementation itself is tested to demonstrate the
accuracy of the implementation. The model testing
section of this paper demonstrates that the behavior
associated with the modified CAR algorithm is
identical to a srTCM behavior.
REFERENCES
Babiarz, J., Chan, K., Baker, F., 2006, Configuration
Guidelines for DiffServ Service Classes, RFC 4594.
Blake, S., Black, D., Carlson, E., Davies, E., Weiss, Z.,
1998, An Architecture for Differentiated Services,
RFC 2475.
Cisco Inc, 2012, Cisco IOS Software Releases 11.1,
[online] Available at: < http://www.cisco.com/
en/US/docs/ios/11_1/feature/guide/CAR.html >,
[Accessed 20 February 2012].
Fang, W., Seddigh, N., Nandy, B., 2000, A Time Sliding
Window Three Colour Marker(TSWTCM), RFC
2859.
Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., 1999,
Assured Forwarding PHB Group, RFC 2597.
Heinanen, J., Guerin, R., 1999a, A Single Rate Three
Color Marker, RFC 2697.
Heinanen, J., Guerin, R., 1999b, A Two Rate Three Color
Marker, RFC 2698.
Nichols, K., Blake, S., Baker, F., Black, D., 1998,
Definition of the Differentiated Services Field (DS
Field ) in the IPv4 and IPv6 Headers, RFC 2474.
OPNET 2010, OPNET Modeler Documentation Set,
Version: 16.0, 10/14/10.
OPNET Inc., 2012, [online] Available at:
<http://www.opnet.com> [Accessed 10 February
2012].
SIMULTECH2012-2ndInternationalConferenceonSimulationandModelingMethodologies,Technologiesand
Applications
452