- Penetration: giving the fraction of potential
users that use the applications; - Number of sources: giving the number of
potential users.
Again, these calculations could be done in a
number of ways. Moreover, the values have to
be referenced to a certain level in the network,
as schematically given in Figure 8.
This is due to the distribution of the traffic,
given by the traffic matrices, and the effect that
different link rates and other capacity units have
on the traffic characteristics. Naturally, this dis-
tribution might differ for the different applica-
tions, e.g. due to accessing servers that are
located at certain sites.
3 Characterising Applications
3.1 Traffic Flows and Service
Implementation
A service class refers to a coherent way of treat-
ing traffic flows. That is, it includes traffic han-
dling mechanisms/parameters and it may include
features like support of multicast, security and
mobility. Identifying the proper set of service
classes would also be an essential point in the
business decisions taken by an actor.
The mapping of traffic flows resulting from the
use of applications into the set of service classes
may be a non-trivial task. Besides, a service
class and accompanying ways of handling the
traffic flows may refer to different aggregation
levels and portions of the network as described
in the previous chapter.
Traffic handling is the set of rules applied by the
control and network management system. On
this set of rules decisions like how to handle
flows in the network can be made. A segregation
scheme is applied when the set of network re-
sources is divided for groups of traffic flows.
That is, some traffic flows get preference for an
amount of resources. Traffic flows with different
characteristics are allocated to different Class of
Service (CoS) based on various criteria, such as
different bitrate demands or different QoS re-
quirements (e.g. delay variation, loss ratio).
These may also be considered when CoS indi-
cators are assigned. For some services, other
aspects like blocking, control delays and
dependability requirements can be examined.
The routing scheme can differ for different traf-
fic streams.
Various factors may influence the resulting traf-
fic load experienced by a network. In several
cases feedback effects may be present, like flow
control algorithms implemented by TCP and
charging schemes. How to reach an efficient
interplay with the demand applying such effects
is a major area where several questions still
remain unanswered. A further example of the
technical feedback is illustrated in Figure 6.In addition to the service characterisation men-
tioned so far, issues related to implementation
could be considered. For instance, three ways
of supporting services could be relevant:i) Service with connectivity to a predefined set
of destination points. One example can be a
virtual leased capacity service. In this case
the Service Level Agreement (SLA) speci-
fies the allowed traffic towards these desti-
nation points (pipe model); there are no spa-
tial gambling and the necessary resources
can be reserved in the network.ii) Service with call admission control function-
ality. IP telephony may be implemented with
call admission control deciding whether to
accept or reject a given call request based on
knowledge about the available resources in
the network. If resources are not available,
the service is blocked, otherwise the neces-
sary resources can be reserved and the con-
nection established.iii) A one-to-any service without call admission
control functionality. In this case the SLA
only controls the volume of the traffic flow-
ing over one user-network interface (of each
class and both directions). This is called a
hose SLA. The SLA is therefore not enough
to control the volume of traffic in a given
direction, i.e. a kind of spatial gambling on
traffic volume.The three types provide various means for con-
trolling the traffic flows and resource usage. For
some types the result might be less efficient
resource utilisation, but then likely accompanied
by less complexity.3.2 Inherent Characteristics of
Applications and Traffic Flows
As stated in [Robe01] traffic descriptors should
satisfy three requirements:- Useful for resource allocation;
- Understandable by the user;
- Verifiable at the network ingress.
It is further stated that in practise it is impossible
to fulfil all these requirements.From the outset, two types of traffic flows have
been used – elastic flows and inelastic flows. As
understood by the former, it can adapt itself to
conditions such as network congestion. This is