DiffServ CoS Simulation -- IPVCoSS Simulator
IPVCoSS Basic Principles
|
IPVCoSS (IP VPN Class of Service Simulator) is a stand-alone program, written in C and without any prerequisites,
that enables you to set up a network topology and inject traffic at ingress points.
IPVCoSS is focused on IP data forwarding performance and assumes that data paths
are pre-established. It can be configured to handle classes of service and to
simulate one or more IP VPNs over a Service Provider backbone.
The network configuration is based on a data model and the data structures
are built at initialization time. During its active phase, IPVCoSS runs a
loop fictitiously cadenced at 100 nanoseconds (one tenth of microsecond) and
at each tick, it analyses and ensures the progression of IP packets at each node
and port.
The transfer activity is triggered by the generation of IP flows,
according to parameters such as volume, throughput and packet size.
In output, IPVCoSS produces QoS final reports, QoS regular samples and, if required,
a chronological trace of events.
|
Figure 1: IPVCoSS Environment
|
|
The key elements of a network configuration are the ports.
Ports are unidirectional and belong to a node. They are identified by a number,
and their main attribute is the interface type, determining the rate.
The 100-nanosecond clock accuracy enables IPVCoSS to process correctly IP interfaces
ranging from E1 (2 Mbps) to STM-16 (2.5 Gbps).
There is no explicit notion of links between nodes and the network topology is
defined by the mapping between ports:
- An input port (IPORT) is a traffic ingress point at which a single IP flow,
identified by a letter, is generated. An IPORT maps to an output port
within the same node.
- An output port (OPORT) is an internal OPORT when it maps to one or more OPORTs
in another node. The distance to this adjacent node is a key parameter
of an internal OPORT.
- An output port is an egress OPORT when it does not map to another OPORT.
The conventional IP routing scheme is not used and paths are pre-determined by
simple filtering, at OPORT level, based on flow identifiers. These paths
represent MPLS label switched paths (LSP) in a core network.
Figure 2: IPVCoSS Configuration
|
IPVCoSS Elementary Trials
The throughput of an IP flow is a parameter especially difficult to measure
accurately because it varies permanently, depending on the initial traffic profile
at the source. For assessing this throughput at the final end point, or at any
intermediate point, one can consider as a reference either the volume or the duration.
With the volume-based approach, throughput is calculated at a packet limit,
when the volume is known, while with the time-based approach, it is calculated
by collecting the measurements at regular intervals.
IPVCoSS - Throughput Calculation
-- 10 January 2005, v1.0
In the following documents, we review some elementary cases that will enable
you to getting used to traces and reports. For all these cases there is no class
of service mechanisms yet. The output ports have a single best effort (BE) queue
with a depth set to 100 ms, excepted for the case illustrating congestion where
it is set to the very low value of 1ms. Examples are purposely short and
selected such as enabling a visual perception by time diagrams.
IPVCoSS - Single Flows
-- 10 January 2005, v1.0
IPVCoSS - Multiple Flows
-- 10 January 2005, v1.0
|
