|
In Figure 1 for example, network provider A receives a transmission request from the video conferencing application server: {destination = application client, QoS_delay < 100 ms, QoS_rate = 1 Mbit/s }. Provider A knows from the inter-domain routing protocol BGP (Border Gateway Protocol) the two possible paths to the destination provider D: path_1=ABCD, path_2=ACD. Because each of the providers B and C wants to get the contract for the transit transmission from A to D, both offer information on their transmission quality and costs to provider A. The information from provider B to provider A is aggregated for the path BC and path CD (which provider B got from provider C). Now provider A is able to select between the two paths and informs the application server of the delay and the cost of a transmission via domain A to the application client. In order to support such business scenarios, the INTERMON project is focusing on the inter-domain traffic measurement and modelling aspects. Links between network providers generally have high capacities (ranging from 100 Mbit/s to 10 Gbit/s). However for transit traffic, this bandwidth may be reduced by the peering contracts between the providers. To monitor the link load, the data packets must firstly be monitored with the parameters {arrival time [µs or ns], length [bytes], flow_id}. The flow_id allows per-flow traffic monitoring, eg for incoming transit flows with different destinations. So the domain B provider in Figure 1 is able to monitor the traffic between the application servers at the entry and exit routers. In the INTERMON project this is called 'policy-driven monitoring and measurement', because different monitoring application requirements need different monitoring methods (eg for delay measurements, two monitoring points are necessary). The next step is for this information to become the input for a 'what if' analysis, eg: How much increase of delay or loss is caused by an increase of the transit traffic by x%? To find the answer, the INTERMON project derives inter-domain QoS simulation models. One of these is a so-called fluid approach. Obviously the simulation of complex inter-domain scenarios cannot be done by a per-packet simulation, due to the explosion in the number of simulation events that occur in such large-scale scenarios. For each event the simulator has to update the system state.
The first step towards a scalable simulation model is an approach in which traffic streams are modelled as chunks of fluid flows. The monitored individual packet arrivals are aggregated to traffic load events, eg per 100 ms, and the simulation process is now triggered by these traffic-load events (see Figure 2). On the basis of these models, the 'what-if' scenarios can be executed with the help of powerful existing continuous simulation modelling tools like SIMULINK. To optimally support the network operator/planner, a high degree of automation is employed to create the simulation. Topology information is imported into a graphical user interface (GUI) where the scenarios of interest ('what-if' changes) are configured, and the current load situation is fed from the monitoring database (IPFIX standard) into the simulation. In general, the fluid simulation algorithms run on a digital computer and the time progress of the differential equations will be approximated by discrete 'sufficiently small' time steps. The dependencies between simulation performance (accuracy, simulation time) and the size of the simulation time step will be investigated in the next project period. Running the fluid simulation with sufficiently small time intervals may be interpreted as a step backward to the granularity of the criticised per-packet simulation, but today's powerful numerical processors are able to solve the approximations for differential equations very efficiently. Finally, a very high degree of accuracy may not always be the main interest in large inter-domain scenarios and the ability to arbitrarily choose the trade-off between simulation accuracy and performance is a powerful feature. Link: Please contact: |
|
|