4.1 Non-functional Requirements
The generic non-functional requirements given
in [ID_tepri] are:
- Usability. This is a human factor aspect refer-
ring to the ease of deployment and operation
of a TE system. - Automation. Commonly, as many functions as
possible should be automated, reducing the
human effort to control and analyse the infor-
mation and network state. This is even
stronger for a larger network. - Scalability. The TE system should scale well
when the number of routers, links, traffic
flows, subscribers, etc. grows. This may imply
that a scalable TE architecture is applied. - Stability. This is an essential requirement for
an operational system avoiding adverse results
for certain combinations of input and state
information. - Flexibility. A TE system should be flexible
both in terms of the optimisation policy and
the scope. An example of scope is that addi-
tional classes should be considered in case
these are introduced into the network. Another
aspect of flexibility is that some subsystems of
the TE system could be enabled/disabled. - Visibility. Mechanisms to collect information
from the network elements and analyse the
data have to be present in a TE system. These
would then allow for presenting the opera-
tional conditions of the network. - Simplicity. A TE system should be as simple
as possible, that is considered from the out-
side, not necessarily using simple algorithms.
Simplicity is particularly important for the
human interface. - Efficiency. As little demanding, in terms of
processing and memory resources, as possible
is requested. However, this also refers to the
result from the TE system being obtained in
a timely manner. - Reliability. A TE system should be available,
in the operational state, when needed. - Survivability. Recovering from a failure and
maintaining the operation is requested, in par-
ticular for the more critical functions of a TE
system. Commonly, this requires that some
redundancy is introduced. - Correctness. A correct response (according
to the algorithms implemented) has to be ob-
tained from a TE system.- Maintainability. It should be simple to main-
tain a TE system. - Extensibility. It should be easy to extend a TE
system, e.g. when introducing new functions
and when the underlying network is extended. - Interoperability. Open standards should be
used for the interfaces in order to simplify
interoperation with other systems. - Security. Means supporting integrity, informa-
tion concealment, etc. have to be imple-
mented.
- Maintainability. It should be simple to main-
As mentioned, some of these requirements may
be mandatory while others are optional for a par-
ticular TE system.4.2 Functional Requirements
Some functional requirements are also described
in [ID_tepri], such as those related to:- Routing. An efficient routing system should
take both traffic characteristics and network
constraints into account when deriving the
better routing schemes. A load splitting ratio
among alternative paths should be config-
urable allowing for more flexibility in the traf-
fic distribution. Some routes of subsets of traf-
fic should also be controllable without affect-
ing routes of other traffic flows. This has par-
ticular relevance when several classes are pre-
sent in the network. In order to convey infor-
mation on topology, link characteristics and
traffic load, several of the relevant routing
protocols have to be enhanced. An example
is constraint-based routing which is gaining
Box B Protection Types
Protection types for MPLS networks are categorised as: i) link protection
(backup LSP is disjoint from the working LSP at the particular link for which pro-
tection is required), being a link local repair; ii) node protection (backup LSP is
disjoint from the working LSP at the node considered); iii) path protection (pro-
tect a working LSP from failure at any point along its path, hence the back up
and working LSPs are both node and link disjoint); and iv) segment protection
(failure within a domain is corrected within that domain).
Segment protection can also be to reroute an LSP locally, e.g. between the
routers connected to the failed link (as opposed to end-to-end rerouting of an
LSP).
Protection options are typically given by m:n, where mrefers to the number of
working LSPs to be protected and nrefers to the number of backup LSPs. Com-
mon combinations seen are 1:1, k:1, and 1:k. The second can be used when the
traffic load of the working LSP is to be distributed, e.g. due to bandwidth require-
ments. A protection option called 1+1 is also used when the traffic is sent both
on the working LSP and the backup LSP. Then the egress LSR selects one of
the two LSPs.