Side_1_360

expressing the results have to be decided

upon.

• Delay; being a measure of the time taken for
  a packet to travel from one point to the other.
  The other point could be the same as the first
  point for round-trip delay. Interval and result
  presentations have to be found as above.


• Path; giving the hops that a packet traverses
  between the end points.


• Lifetime; being the total time that the flow of
  IP packets exists. For a permanent flow, e.g. a
  backbone link, the lifetime would be infinite
  unless there are failures or other changes in
  the network topology. For dynamic flows,
  there may be challenges attached to deciding
  when a flow is started and when it is stopped.

A series of RFCs has been issued for specific
performance metrics:

• RFC 2330 Framework for IP Performance
  Metrics


• RFC 2678 IPPM Metrics for Measuring
  Connectivity


• RFC 2679 A One-Way Delay Metric for IPPM


• RFC 2680 A One-Way Packet Loss Metric
  for IPPM


• RFC 2681 A Round-Trip Delay Metric for
  IPPM

There are multiple purposes of doing measure-
ments including modifying routing for network
utilisation, detect threshold crossing for chang-
ing capacity allocation, observing trends, ob-
serving conditions in SLAs, etc. In particular,
measurements are crucial to allow for proactive
and real-time TE actions. As one aspect of TE
is to reach high utilisation of the network, appro-
priate load balancing is needed, asking for mea-
surements of the traffic in different directions
and on the different links, in order to balance
the traffic. Policy-based TE in connection with
measurements allow for considering the policy
attributes on paths when carrying out actions
triggered by measurement results. Such policy
attributes include priority, pre-emption, resil-
ience, resource classes and policing.

Performance parameters related to forwarding of
IP packets have also been described in ITU-T,
e.g. see [Y1540] and [Y1541]. These include IP
packet delay variation, IP packet error ratio, IP
packet loss ratio, IP packet transfer reference
event, IP packet throughput, IP packet transfer
delay, and spurious packet ratio.

8.2 Real-time Traffic Flow

Measurement

The IETF’s Real-time Traffic Flow Measure-

ment (RTFM) Working Group has described a

measurement architecture to provide a method

for gathering traffic flow information, see

[RFC2722]. The model proposed is based on the

concepts of meters and traffic flows given as:

• Meters observe packets as they pass by a single
  point on their way through the network and
  classify them into certain groups. For each such
  group a meter will accumulate certain attributes
  (such as number of packets and bytes). These
  metered traffic groups may correspond to a
  user, a host system, a network, a particular
  transport address (e.g. a port), etc. Meters are
  placed at measurement points and selectively
  record network activity as directed by its con-
  figuration settings. Meters can also aggregate,
  transform and further process the recorded
  activity before the data is stored.


• Traffic flow is said to be a logical entity
  equivalent to a call or connection. A flow is
  a portion of traffic that belongs to one of the
  metered traffic groups mentioned above.
  Attribute values (source/destination addresses,
  number of packets, etc.) associated with a
  flow are aggregate quantities reflecting events
  that take place. Flows are stored in the meter’s
  flow table.

A traffic meter has a set of rules which specify

the flows of interest. One way to identify a flow

is by stating values of its address attributes.

Annex C in [RFC2722] provides a list of flow

attributes.

As well as flows and meters, the traffic model

measurement includes managers (to configure

and control meters), meter readers (to transport

recorded data from meter to analysis applica-

tions), and analysis applications (to process the

data from meters readings so as to produce what-

ever reports are required).

NetraMet is an implementation of the RTFM

Architecture, which has been available since

1993. Details of the implementation and experi-
      ence gained with NetraMet are recorded in
      [RFC2123].

9 Concluding Remarks

This paper has discussed several issues central

to carrying out network planning and network

design studies. Besides finding efficient algo-

rithms for conducting these studies, input data

must also be assessed. Here, as in several other

areas, one faces the trade-offs between tractabil-

ity and accuracy. On the one hand the traffic

flows and the network resource could be mod-