World Applied Programming, Vol (3), Issue (9), September 2013.

446-450
ISSN: 2222-2510
2013 WAP journal. www.tijournals.com

Methods nd Technologies Analysis of The Real-Time

Traffic Transmission Requests Servicing
Kostiantyn Polschykov

Katerina Kubrakova

Oleg Odaruschenko

Donbass State Engineering

Academy, Kramatorsk, Ukraine
konspol@rambler.ru

Poltava National Technical Yuri

Kondratyuk University, Ukraine
y.lyubchenko@gmail.com

Poltava National Technical Yuri

Kondratyuk University, Ukraine
skifs2005@mail.ru

Abstract: The requirements for the real-time traffic transmission in a telecommunication network are
considered. Modern technologies and methods maintaining multimedia traffics quality of service such as the
IntServ architecture of integrated services and differentiated services architecture DiffServ are also examined. It
is proposed to increase the network channels usage by buffering the requests for the real-time traffic
transmission. The implementation of this idea will provide smoothing the flow of incoming requests and allows
you to use network bandwidth more efficiently.
Keywords: real-time traffic, Best Effort, IntServ, DiffServ

I.

INTRODUCTION

The most part of information streams, transmitting in modern telecommunication networks with switching packets, form
multimedia traffic (voice or video). New multimedia applications video, IP-telephony, Internet radio, teleconferences,
distance learning and many others are intensively developed and implemented. Information transmission intensity,
initiated by the work of corresponding software, is high enough and near to the constant value. Therefore such kind of
traffic is frequently called streaming traffic or real time traffic. The requests arrival on the real time traffic transmission
varies randomly. When the users activity increases randomly, there is a temporary channel resources lack. This aspect
causes service denials of users requests. While requests appearance intensity decreases, the network load declines, the
network channels work in underloaded mode and there are pauses in their usage. Thus, the channels of modern
telecommunication networks are loaded nonuniformly; consequently, they are used ineffectively.
The purpose of this paper is substantiation of the ways of network usage enhancement during the real time traffic
transmission. To achieve this objective it is proposed to solve the actual scientific problem, consisting in critical analysis
of request service methods and technologies for the real time flows in a telecommunication network.
Multimedia applications, as a rule, are very sensitive to the end-to-end delay duration and to the delay periodicity
deviation (jitter). In such applications delays over some hundredths milliseconds are critical. At the same time
multimedia applications admit the loss of some data. This accidental packet loss may cause negligible failures while
playing back audio and video data and they can be disguised partly or completely [1; 2]. The requirements to the packet
delay carrying voice information end-to-end are described in ITU-T G.114 One way transmission time. According to
this document cut-through delay should not exceed 150 ms and delay variation determined by the buffer size should be
less than 40 ms.
For the qualitative voice transmission 1% packet loss and no more than one lost packet are acceptable. It is caused by the
reason that voice codec can correct the loss of voice fragment of 30 ms duration, but the standard packet contains the
voice sample of 20 ms duration [3].
Let us consider three main classes of multimedia applications (Fig.1): recorded streaming multimedia, real time
streaming multimedia and interactive real time multimedia.

446

Kostiantyn Polschykov, et al. World Applied Programming, Vol (3), No (9), September 2013.

Figure 1. Multimedia traffic classification

In the case of recorded streaming audio and video clients get on their demand compressed audio and video files, stored
on servers. Playback delay in such applications should be from 5 to 10 seconds. Playback should last as long as the
original record. This fact causes heavy delay restrictions in data delivery.
The applications of real time streaming audio and video assume receiving radio and TV live programs. The delays from
the users request to begin of playback are acceptable if their duration is about ten seconds.
Interactive real time audio and video assume users communication in real time. The data delivery delay in such
applications should not be more than several tenths seconds. While transmitting voice the delays in range of 150 ms are
not mentioned by the user. The delays from 150 to 400 ms are acceptable and the delays more than 400ms are supposed
as sufficient distortions [4].
Thus, for the qualitative real time applications transmission the following requirements should be fulfilled: end-to-end
delay and jitter are within normal range, but some data loss is acceptable.
There exist several approaches to the Quality of Service (QoS) maintenance, including real time traffic: Best Effort [5],
Integrated services (IntServ) [6] and Differentiated service (DiffServ) [7].
In Best Effort model the quality of service improvement is provided through the bandwidth throughput extension, but the
model has no means supporting QoS.
II.

INTEGRATED SERVICES ARCHITECTURE ANALYSIS

IntServ architecture assumes that for the real time applications qualitative servicing it is enough to reserve the necessary
bandwidth. Thus, the reserved bandwidth and available bandwidth definition means should be implemented in every
router. RSVP (Resource ReSerVation Protocol) is a basis of IntServ architecture, which allows resource reservation to
applications [8].
RSVP works the following way (Fig.2). Host initiating transmission (in the following sender) sends PATH message to
the receiving host (in the following receiver). Every interior node (router) forwards this message to the next node
defined in a routing protocol (for example, OSPF or RIP). After getting PATH message, receiver answers with RESV
message, which immediately reserves resources on the nodes. RESV message has the same route as PATH message [8].

Figure 2. RSVP functioning mechanism

447

Kostiantyn Polschykov, et al. World Applied Programming, Vol (3), No (9), September 2013.

Resource reservation on every transit node can be either accepted or rejected. If on any step of transmission there is a
rejection, then RESV message transmission is interrupted, and the error message is forwarded to the sender. As an
example let us consider the case of bandwidth lack. If after the pass-through validation the negative result is received,
then the router rejects the reservation request and sends to the receiver option message RESV Error, testifying the error.
The error in this message is specified with help of ERROR_Spec object. Its parameters (Fig. 3, Fig. 4) are given in RFC
2205. There are two types of this object: for IPv4 and IPv6. These objects contain error node address (in IPv4 protocol
4 bytes, in IPv6 16 bytes); flags corresponding to the error and error code and value.

Figure 3. Object ERROR_Spec format for IPv4

Figure 4. Object ERROR_Spec format for IPv6

In this case Error Code is 01, it means that access control denied. Error value is: ssur cccc cccc cccc. 12 least significant
bits can point at error cause (for example, delay value is too big).
In modern telecommunication networks RSVP protocol is used for long-time connections support. RSVP protocol also
can be used in MPLS networks for the formation of the routs, switching by the label (LSP Label Switching Path).
RSVP protocol has a sufficient disadvantage: if the streams number increases, information processing of all the streams
decays the network throughput rate. In other words, when the multimedia traffic transmission requests number rises the
network is overloaded with service information [8].
III.

DIFFERENTIATED SERVICE ARCHITECTURE ANALYSIS

The main purpose of the DiffServ model is in development of scalable and flexible methods distinguishing service
layers, i.e. to serve different traffic classes according to their requirements. As a rule, these classes have different cost,
which is mentioned in Service Level Agreement (SLA). In addition to this, if the transmitted traffic volume is more than
it is said in SLA, then the quality of service is not guaranteed [7]. First of all it is important for multimedia traffic, which
has heavy restrictions on the delay, jitter and packet loss.
In differentiated services architecture all the packets are classified with DS field marking in IPv4 or IPv6. For example,
the most prioritized multimedia traffic is marked: EF (46) voice transmission (by default 25% of bandwidth is
guaranteed), AF41 (34) interactive video (by default 25% of bandwidth is guaranteed), CS4 (32) interactive video
(by default 27% of bandwidth is guaranteed). After the service type determination the corresponding PHB-policy (Per
Hop Behavior) solutions are developed. PHB is a behavior scenario for the network node with the packets with different
DSCP field values [7]. All the packets of the traffic stream with the specific service requirements carry the same DSCP
field value. In DiffServ architecture there are two types of PHB-policy: AF PHB (Assured Forwarding) for data traffic
and EF PHB (Expedited Forwarding) for higher priority multimedia traffic. It is necessary to point out the requirements
of the low packet loss; jitter and delay are guaranteed within the domain boundaries and traffic volume.

448

Kostiantyn Polschykov, et al. World Applied Programming, Vol (3), No (9), September 2013.

The multiprotocol label switching technology (MPLS) is also realization of DiffServ model [9]. This technology
provides multimedia transmission through the virtual private networks (VPN) with guaranteed QoS. Therefore the
RSVP-TE (RSVP Traffic Engineering) protocol [10] is used in MPLS technology.
RSVP-TE protocol is an extension of existing RSVP protocol with LSP path signalization (LSP Label Switched Path).
RSVP-TE protocol uses signal messages of RSVP, but it adds definite extensions for traffic engineering mechanisms
support (Fig. 5). TE-RSVP protocol creates explicitly routed LSP path (ER-LSP) TE-tunnel setup. TE-tunnel, built on
the basis of LSP has the only sender (it is the first path node) and the only receiver the last path node [10].
The head router initiates TE-tunnel setup, sending RSVP PATH message to the tunnel destination point IP-address with
the SRO object (Source Route Object), which determines an explicit route.

Figure 5. RSVP-TE protocol functioning

The head router initiates TE-tunnel setup, sending RSVP PATH message to the tunnel destination point IP-address with
the SRO object (Source Route Object), which determines an explicit route.
The IP-address and pointers list determining the next destination point is contained in SRO. When PATH message is
received it is necessary to setup the LSP path based on Label Route Object (LRO). LRO is contained in PATH message,
it generates RSVP reservation request message (RESV). In RESV message the label object LABEL is contained. The
network node after receiving RESV message uses LABEL for all the traffic transmission through this path. After the ERLSP is formed, TE-tunnel is installed. Besides of that channel access control system determines whether free resources
are available in the network and also removes existing tunnels if their priority is higher than other tunnels [10].
If the requested bandwidth is unavailable the PATH Error message with 01 code is sent to the sender, access control
error 02 with error code 0x002, where 002 means that requested bandwidth is unavailable. If the requested
bandwidth is less than available, traffic transmission begins.
Nevertheless DiffServ architecture is an improvement of existing service models, it has sufficient disadvantages. Quality
of service is guaranteed within one domain and only for the determined traffic volume. I.e. traffic exceeding this volume
is not transmitted qualitatively. Thus, MPLS network cannot guarantee quality of service in case of overload.

449

Kostiantyn Polschykov, et al. World Applied Programming, Vol (3), No (9), September 2013.

IV.

CONCLUSION

Analysis that has been provided shows that technologies of real time traffic transmission, which are applied in modern
telecommunication networks, do not provide effective network channels usage. Random nature and irregularity of
multimedia traffic transmission requests arrival causes temporary overloads. On the other hand time slots with
underloaded network channels can appear. The considered models IntServ and DiffServ suppose the rejection for the
requests received during channel resources lack. Such requests can be served later when the necessary bandwidth
appears. However, such technologies are not developed yet in modern networks.
For the network channels usage improvement it makes sense to use the multimedia traffic transmission requests
buffering. Realization of this idea would assure requests flow smoothing. Therefore bandwidth throughput will be used
more effectively.
The substantiation of requests queue application provides the necessity of another important problem solution consisting
of maximum queue value choice. A large number of requests in a buffer enhance the quality of service, because more
requests are served and a few of them are rejected. On the other side, the more requests are in the queue, the longer users
have to wait before their request is served that would have negative effect on quality of service [11].
Therefore, further investigations in this area should be devoted to memory capacity choice of the real time traffic
transmission requests in a telecommunication network.
REFERENCES
[1]
[2]

[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]

Koucheryavy Y., Molchanov D., Harju J. Performance Evaluation of Multimedia Services in Heterogeneous Wireless
Environment. In Proceedings of EUNICE 2003 Summer School, September 2003, Balaton Lake, Hungary.
Polschykov K., Strjuk O., Rvachova N.The Methodology of Modeling Available for Data Traffic Bandwidth
Telecommunications Network. Proceedings of the X International Conference Modern Problems of Radio Engineering,
Telecommunications and Computer Science TCSET2010. Lviv Slavske, 2010. P. 158.
Vegensha Sh. Quality of Service in IP networks. Moscow, 2003. 386 pp.
Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach, 6/E. Addison-Wesley, 2013. 864 pp.
Gevros P., Crowcroft J., Rirstein P., Bhatti S. Congestion Control Mechanisms and the Best Effort Services Model. IEEE
Network, May/June 2001, pp. 1626.
Braden R., Clark D., Shenker S. Integrated Services in the Internet Architecture: an Overview. RFC 1633. June 1994.
Available from: http://www.rfc-editor.org/rfc/rfc1633.txt.
Grossman D. New Terminology and Clarifications for Diffserv. RFC 3260. April 2002. Available from: http://www.rfceditor.org/rfc/rfc3260.txt.
Braden R., Zhang L., Berson S., Herzog S., Jamin S. Resource ReSerVation Protocol (RSVP) Version 1 Functional
Specification. RFC 2205. September 1997. Available from: http://www.rfc-editor.org/rfc/rfc2205.txt.
Rosen E., Viswanathan A., Callon R. Multiprotocol Label Switching Architecture. RFC 3031. January 2001. Available from:
http://www.rfc-editor.org/rfc/rfc3031.txt.
Awduche D., Berger L., Li T., Srinivasan V., Swallow G. RSVP-TE: Extensions to RSVP for LSP Tunnels. RFC 3209
Decemder 2001. Available from: http://www.rfc-editor.org/rfc/rfc3209.txt.
Polschykov K.A., Odaruschenko O.N., Lyubchenko K.N. Analytic model of the real time traffic transmission requests service
in a telecommunication network. Radioelectronic and Computer Systems. Kharkiv, 2013. Vol. 5 (64). pp. 313318.

450