- The service concerns, involving control and
management. Functionality both in the user’s
equipment and in the provider’s domain is
included. Typical issues are definition of ser-
vice and corresponding QoS (e.g. which
parameters to apply), integration of control
and management, elaboration of SLAs (con-
sidering multi-provider and multi-service) –
between providers and towards end-users,
applications capable of expressing their ser-
vice level demands, and so forth. - The business concerns, addressing processes
and (internal) models within an actor (e.g.
provider or user). Typical issues are descrip-
tion of internal processes for providing/deliv-
ering IP services, processes for collecting
and storing performance data from different
sources, methods for searching optimal
arrangements for delivering services.
Traffic Engineering should be aware of these
issues, incorporating appropriate procedures and
interfaces.
Naturally, the above-mentioned groups are just
giving one, non-exhaustive, way of dividing the
various issues. A further complicating fact is that
quite a few of the various issues are inter-depen-
dent, not making it easy to clearly separate the
questions to be addressed.
6.3.1 IP Transport Concerns
Several open issues for QoS related to transport
of IP packets are described in [RFC2990].
Although these were discussed above, they, as
well as others, are summarised in the following:
- Monitoring capabilities. How to monitor the
traffic flows, resource utilisation and QoS-
related performance in an efficient way? This
includes decision on what level of granularity
to look at, that is, what aggregate of flows,
and time-scale to apply. Furthermore, the
monitoring results must be applicable to docu-
ment the conditions stated in SLAs (which
well may refer to “higher-level” services).
Monitoring results are also used for further
tuning of resource configuration and traffic
handling. - Configuring resources. TE mechanisms are
needed to properly/efficiently configure the
network resources and control the traffic load
such that the SLA conditions are met. This
involves routing, allocation of resources (e.g.
bandwidth), admission control, and so forth.
Considering the multi-service network, this
is a rather complex matter where scalability
might become a particular challenge. Particu-
lar attention is placed on configuring re-
sources for carrying voice-over-IP (also likely
to involve gateways).- Completion of appropriate standards. At least
on a shorter term combinations of DiffServ
and MPLS are promoted for use in the core
network. Hence, completion of standards
within that area is needed, in particular to
simplify interoperability between domains.
Regarding access, IntServ may also be
applied. Then, solutions are needed for this as
well, in addition to mapping between IntServ
and DiffServ/MPLS.
Establishing an efficient IP-based network also
requests interworking with layers below and
above IP. For example, co-ordination of func-
tions in the optical layer and the IP layer should
be utilised. The same goes for applications and
other “higher layer” functions, like policy and
directory.6.3.2 Service Concerns
On quite a few occasions it is seen that specify-
ing the actual service to be delivered is not done
adequately. Hence, there may be some room for
interpretation both by the provider and by the
user. As more higher-level services (i.e. above
mere transport of IP packets) are “sold”, the TE
mechanisms should capture even these aspects.
This makes the scope somewhat broader than
what mainly springs to mind. Some essential
issues in this group are:- SLA/SLS/TCA/TCS. Elaborating agreements
and specifications at the proper level of detail
which are accurate, is still a challenge. De-
signing SLAs in a multi-provider/multi-ser-
vice environment raises additional challenges,
like how to relate two SLAs with independent
providers referring to the same access line/
user. Based on different events occurring in
the network, different users may be affected.
Ways of identifying service affecting faults
and which users that are bothered will then
be requested. Particular challenges may arise
from avoiding scalability problems. - Management models. Both service manage-
ment and network management have to be
completed for efficient management. Regard-
ing network management, issues like collect-
ing monitoring data, configuring network
resources (e.g. for MPLS paths) have to be
implemented. Regarding service management,
there are some suggestions for the need for
more centralised management architecture,
supported by stronger admit and control
mechanisms of flows at the edge of the core
network [ID_IPsm]. Then, the end-to-end (in-
cluding multi-domain) view should be taken
on by service management, compared to only