Network Operations

From a network operator’s perspective, arguably the most important use of traffic measurements lies in their ability to provide a detailed view of the state of the network, based on periodic summaries of traffic load and packet loss on individual links and/or paths. This information is crucial for operators to detect conditions such as increases in traffic demands and problems such as equipment failure and misuse of network resources. Hence, having an accurate and timely view of the flow of traffic across the network can help improve utilisation of resources and consequently, the performance experienced by the end-users/customers. Measurement functionality is deployed for this reason to operate in parallel with the network’s main forwarding mechanism, either within network nodes (e.g. SNMP, Netflow) or on dedicated measurement probes and terminals (e.g. OC3MON, PacketScope), attached on key links of the network. Passive measurements are usually preferred by operators since they

monitor the operational traffic of the network, and they can hence be used with high confidence for tasks such as network planning and dimensioning, as well as for accounting and billing services. Active measurement techniques are often complementarily used, however, since they operate on additionally generated (synthetic) traffic, there is an inevitable uncertainty that any generalised assumption of applicability of results to the actual network traffic flow will be to some degree hypothetical.

Operators responsible for managing and engineering individual Autonomous Systems (AS)s are mainly interested in network-wide representations of the traffic, in order to drive network- wide control actions, such as routing changes, traffic classification, traffic filtering and capacity planning [GrRe02]. In contrast, passive traffic measurements are single-point, operating either on a single link or being enabled on selected devices in the network. In the latter case, measurement-enabled forwarding devices (e.g. Netflow-enabled routers) are usually at the edges of the network, avoiding complexity and overhead at the core, where routers need to forward large amounts of aggregate traffic.

Figure 2-19: Path, Traffic, and Demand Matrices for Network Operations

As shown in Figure 2-19, there are three main network-wide traffic representations that can be derived by post-processing and correlating single-point passive measurements at different granularity levels, and estimating the corresponding matrices of the flow of traffic through an AS [GrRe02]. The path matrix specifies the temporal data volume for every path in the AS between every ingress and egress point, and represents the current state and behaviour of the network. The traffic matrix reveals the offered load of the network, by specifying the data volume per ingress-egress pair. Finally, the demand matrix expresses the volume of load originating from each ingress link and destined to a set of egress points [FeGL00].

A variety of network operations tasks can be based on populating each one of these traffic representations. Exemplarily, the path matrix can be used to determine the traffic intensities associated with each path in a network and to diagnose causes of congestion. The traffic matrix can be used to generate reports for customers based on the traffic volumes between the corresponding pairs of access links. The demand matrix can capture and predict how routing

affects the traffic travelling between domains. The evolution of path, traffic and demand matrices can be exploited to identify potential bottlenecks and guide capacity planning at longer timescales, and to tune intra-domain routing to alleviate congestion [GrRe02, FeGL01].

However, network-wide traffic representations can be very large objects and would only partially be populated in practice. In addition, the degree of measurement granularity is inversely proportional with their efficient, uniform and cost-effective deployment throughout an AS. For example, SNMP is widely implemented within network equipment to provide aggregated information about link load, but routers usually provide relatively limited, coarse grained load statistics. Measurement support at a finer granularity through e.g. RMON and/or flow measurements is very costly and not available on high-speed backbone links. Consequently, sufficient data through fine-grained, direct measurements (possibly on every link in a large network) which could potentially fully instantiate path, traffic and demand matrices is typically prohibitively expensive. Research therefore focuses on populating network-wide models by estimating traffic representations, based on partial measurement information, aggregate traffic statistics and simplifying assumptions about certain traffic characteristics and network topology. Such studies are often referred to as network tomography and traffic mapping, and can be overly complex involving several theoretical and practical orientations; their discussion is outside the scope of this thesis [VaGr03, MeTS02, CaDV00].

Practical systems addressing network operations are mainly focused on specific tasks that can be accomplished given the instrumentation of the network and the granularity of the measurement information available. As an example, one can consider a study within AT&T Labs which focused on the development of an infrastructure for traffic engineering within IP backbone networks. NetScope55 _{is a prototype system that consists of a set of software tools to}

manage the performance of backbone topologies (AS), by generating global views of network configuration and usage data collected from individual network elements [FeGL00]. These can be used to visualise the network-wide implications of local changes in traffic, configuration and control. Very briefly, NetScope consists of a set of configuration,

measurement, routing model, and visualisation modules, and a data model to combine all the diverse attributes of network links and nodes that are derived mainly from the first two modules. The configuration module extracts network-wide information from the configuration files of each router in the AS, and the measurement module determines traffic demands based

on detailed measurements at the periphery (edges) of the network56_{. The routing model} module combines the network topology and traffic demands to model how traffic would travel through the AS, and the visualisation module mainly displays the layer-three and layer-two connectivity of the network. NetScope is advertised as an extensible (distributed) and powerful platform for “what-if” traffic engineering investigations, by providing a simulated environment for experimenting with changes in network configurations, such as e.g. the optimisation of intra-domain routing based on the underlying topology and traffic demands [FeGL00].