Download On-Demand Monitoring of Protocol

RTLG - RSVP Enabled Traffic Load Generator
for Intra-Domain and Inter-Domain QoS
Signalling Tests.
Ranganai Chaparadza,Yuri Glickmann
Peter H. Deussen
MoMe Workshop
Warsaw 2005
Acknowledgement: This work was funded by the Ministry of Education and Research of the Federal Republic of Germany together with
Siemens Information and Communication Networks (ICN) AG Munich. Fraunhofer-FOKUS 2005
page 1
Introduction on QoS enabled IP
transport Networks








Today’s networks: IntServ/RSVP and DiffServ integrated networks
IntServ/RSVP model - provides QoS via a reservation paradigm.
Diffserv model - provides QoS via a traffic differentiation and prioritisation
paradigm.
IntServ/RSVP is only used at the edge instead and DiffServ in the core network.
Per-flow state is pushed to the edge in order to avoid scalability and complexity
problems associated with the IntServ/RSVP model.
The DiffServ architecture – is tailored only to a set of "user plane" mechanisms
of providing QoS in IP networks (via traffic classification, DSCPs, PHBs, PDBs
etc) and does not cover any "signalling plane" aspect.
In such networks - there is a need to employ admission control mechanisms to
control access to the network’s transport resources.
Admission control mechanisms in such networks are implemented by some
policy servers instead and not by the routers (policy enforcement points).
Policy Servers can employ RSVP signalling and based upon the signalling
outcome, influence the edge routers in their decisions on packet classification,
marking, dropping and traffic conditioning.
Fraunhofer FOKUS 2005
page 2
Typical QoS enabled IP Network Domain with
peer domains

IntServ/RSVP - DiffServ integrated Carrier-class networks employ both
intra-domain and inter-domain QoS signalling for flows requiring special
treatment.
Fraunhofer FOKUS 2005
page 3
Testing aspects in QoS enabled IP
Transport Networks
1.
2.
3.
4.
5.
functional testing of QoS mechanisms.
performance testing of the network devices themselves as well as end-to-end
testing of the network as a whole.
Stress testing - conducted to determine the baseline and scalability.
QoS testing - involves measuring key QoS parameters such as packet delay,
jitter, packet loss, in the presence and in the absence of background traffic.
Background traffic is used to put the network into a certain condition during the
tests.
QoS signalling tests (both functional and signalling performance) - target the
functional and signalling performance aspects of the admission control and
resource control mechanisms.
Admission control determines whether the flow can/should be allowed to enter the
network. A policy control entity either accepts or rejects the resource request
depending on the implemented policy.
Fraunhofer FOKUS 2005
page 4
QoS Signalling Tests
QoS signalling tests involve the following procedures:
1. Stimulating the admission control and signalling handler components with
generated signalling messages to test the functional behavior of these
components.
2. Generating variable signalling traffic load to test the performance and scalability
of the signalling handler components by conducting load and stress testing.
3. Generating traffic that violates already negotiated QoS contracts. This is done to
verify that the policy enforcement devices are working correctly, by observing
the treatment offered to traffic not conforming to the negotiated contract.
4. Monitoring some routers and inferring end-to-end packet loss for some flows to
ensure correct treatment of different traffic profiles.
5. Emulating undesired behavior of some flows for robustness testing.
6. Emulating inter-domain QoS signalling to ensure that inter-domain admission
control policies can be tested.
Fraunhofer FOKUS 2005
page 5
Admission Control and Traffic
Matrices



Usually, admission control is done on the basis of availability of enough
resources to satisfy the QoS request without impacting QoS for the already
admitted flows.
In measurement based admission control (MBAC) , admission control decisions
are influenced by changes in the traffic matrix obtained by estimation algorithms
coupled with some measurements such as link utilization.
For both QoS testing and QoS signalling tests synthetic traffic matrices realized
by the traffic generator play an important role.
- For QoS testing the test results are matched against the corresponding
traffic matrices used in the test.
- For QoS signalling tests, the observed behaviour of the admission control
mechanisms is matched against the changes in the QoS traffic matrix,
which reveal resource utilization by QoS flows.
- The RTLG tool can generate a point-to-point traffic matrix and/or a point-tomultipoint traffic matrix.
- It is important that the traffic generator maintains a trace file that reflects the
traffic matrix at any point and all the changes along the time axis.
Fraunhofer FOKUS 2005
page 6
RSVP Signalling Messages






PATH: - Carries the data flow information from the sender to the receiver. The
PATH message reserves the path that sender data and reservation messages
from the receiver must take.
- PATH messages contain bandwidth requirements, traffic characteristics
(Tspec), end-to-end path characteristics (Adspec) and addressing
information.
RESV: - Carries the reservation request from the receiver.
- RESV messages contain a Tspec, the actual bandwidth reservation
(Rspec), reservation style, the service level requested, and the source IP
address (filterspec). The Tspec, Rspec and Service Class are referred to as
the FlowSpec.
PATH-ERR: - Indicates an error in response to the PATH message.
RESV-ERR: - Indicates an error in response to the RESV message.
PATH-TEAR: - Removes the PATH state along the route.
RESV-TEAR: - Removes the reservation along the route.
Fraunhofer FOKUS 2005
page 7
The RTLG Tool, its Sender and
Receiver parts

RTLG consists of two parts, the sender (RTLG.send) and the
receiver (RTLG.receive).
Fraunhofer FOKUS 2005
page 8
RTLG generated synthetic traffic matrices,
flow characteristics and measurements








RTLG can generate a point-to-point traffic matrix and/or a point-to-multipoint
traffic matrix.
RTLG is based on the tool pair RUDE/CRUDE. RUDE - Real-Time UDP Data
Emitter.
Initiates and terminates QoS signalling using RSVP for each flow requiring QoS.
Emulates QoS contract violations.
Provides the ability for a flow to re-negotiate QoS.
Emulates undesired flow behavior for testing admission control mechanisms
and resource control and management mechanisms.
Two types of traffic streams can be generated.
- The CONSTANT stream consists of a steady flow of UDP packets of
specified size, sent out at specified rate.
- The TRACE stream consists of UDP packets with packet sizes and interpacket gaps specified separately for each packet in a trace file.
The TOS field in the IP header of the generated packets can also be set.
Fraunhofer FOKUS 2005
page 9
RTLG generated synthetic traffic matrices,
flow characteristics and measurements





Each generated packet contains a flow identifier, a sequence number and the
transmission timestamp.
RTLG, is driven by a configuration file (Traffic Matrix Specification), which
specifies for each flow:
- the start time, flow identifier, source port, destination IP address and port,
packet rate and size and stop time.
- specifies additional behavior (signalling behavior) for each flow requiring
QoS (non-best effort flow).
The packet size and rate can be modified at any time during the transmission.
- Minimum modification rate of a flow ~ 2ms.
CRUDE (Collector for RUDE) performs the logging of the received user (UDP)
packets generated by RTLG/RUDE.
- stream identifier (flow id), a sequence number of the packet within the
stream, transmitting timestamp, receiving timestamp and the packet size in
bytes.
RTLG can generate traffic matrices at two different granularity levels, namely IPlevel and application level (UDP ports).
Fraunhofer FOKUS 2005
page 10
RTLG implementation model
Fraunhofer FOKUS 2005
page 11
Behavioral Aspects of the RTLG
Components







The sender part of RTLG sends best-effort flows as well as QoS signalled flows.
Receiving a PATH-ERROR message from the network means admission has
not been granted and the sender can repeat admission requests at the rate
specified by the user.
In decentralized admission control the PATH message will be relayed to all the
necessary parties along the route until it reaches the receiver, which will then
respond by sending a RESV message upstream, specifying the willingness to
accept or admit the flow, or a PATH-ERROR message upstream to indicate that
the requesting flow can not be admitted.
The receiver can be interpreted to mean either some QoS signalling termination
point or the intended destination host of the flow.
RTLG can be used for tests covering intra-domain and inter-domain QoS
signalling depending on the basis used to differentiate intra-domain from interdomain QoS signalling.
The RTLG sender and receiver parts log every necessary detail about each
flow: flow start time,flow identifier, address details, modification time and stop
time.
Additionally, RTLG logs the QoS signalling initiation time, admission time,
outgoing RSVP objects, asynchronous events from the network, RSVP objects
of the received messages and, monitors the admission state of each flow.
Fraunhofer FOKUS 2005
page 12
Demonstration of how to conduct QoS
signalling tests using RTLG
Fraunhofer FOKUS 2005
page 13
Traffic Matrix behaviour specification
file
START NOW
# flow 0030 to ip 10.19.2.9 3002 is turned-on right after start-up
000 0030 ON 3002 10.19.2.9:3002 CONSTANT 112 754
# QoS spec for the flow 0030,
# it is a QoS flow(requires QoS signalling)
TOS 0030 0xfc #DSCP code marking
RSVP 77 10.19.0.140 0030
# flow 0040 is a "best-effort" flow (no QoS signalling required)
5000 0040 ON 3003 10.19.3.10:3004 CONSTANT 112 754
# initial QoS spec, flow 050 is a QoS flow
# (requires QoS signalling), starts after 1s
1000 0050 ON 3004 10.19.3.10:3005 CONSTANT 200 316
RSVP 77 10.19.1.139 0050
TOS 0050 0xfc
# modification of bandwidth for flow 0030
# after 17 seconds -> PATH-TEAR is sent first
17000 0030 MODIFY CONSTANT 100 200
# turn off flow 030 after 60 seconds
60000 0030 OFF
41000 0040 OFF
90000 0050 OFF
Fraunhofer FOKUS 2005
page 14
Flow Modifications during the flow‘s
lifetime


Four types of bandwidth modifications to a flow are supported at any time
between the start time and its stop time of a flow.
The difference between these four modification types is how the RSVP session
is adapted to the new bandwidth.
1. RSVP session termination at the modification point. The modification first
tears down the previous QoS contract (i.e. a PATH-TEAR message is
emitted), and the flow is continued with different bandwidth parameters.
2. RSVP session inheritance. This modification changes only the bandwidth of
a particular flow, but leaves the RSVP session unchanged. Thus, it is
possible to send on a higher bandwidth without renegotiation i.e. to emulate
QoS traffic contract violation.
3. RSVP renegotiation. This modification causes the traffic generator to
renegotiate the changed bandwidth. The flow transmission is not
interrupted.
4. RSVP negotiation with interrupted flow transmission. This behavior is
actually achieved using a combination of start and stop commands for a
particular flow and requires changing the id of the restarted flow.
Fraunhofer FOKUS 2005
page 15
RTLG Logging functionality
Logging
Enti
ty
Time-stamp
of
an
event
Logged details: RSVP sender/receiver, flow ID, flow state, message
types etc.
sender
20:40:26.014
10.19.2.9:3002 30
receiver
20:40:26.031
received PATH for 10.19.2.9/3002,17 FlowID=30
receiver
20:40:26.035
sending RESV for 10.19.2.9/3002,17 to 10.19.0.140 FlowID=30
sender
20:40:26.051
10.19.2.9:3002 30
sender
20:40:27.012
10.19.3.10:3005 50
receiver
20:40:27.027
received PATH for 10.19.3.10/3005,17 FlowID=50
receiver
20:40:27.031
sending PATH-ERROR for 10.19.3.10/3005,17 to 10.19.1.139 FlowID=50
sender
20:40:27.045
10.19.2.9:3002 50
Not Admitted: PATH-ERROR rcvd
sender
20:40:43.011
10.19.2.9:3002 30
Start modification: PATH-TEAR Send
sender
20:40:43.015
10.19.2.9:3002 30
Requesting for Admission: PATH send
receiver
20:40:43.026
received PATH-TEAR for 10.19.2.9/3002,17 FlowID=30
receiver
20:40:43.030
sending RESV-TEAR for 10.19.2.9/3002,17 to 10.19.0.140 FlowID=30
sender
20:41:26.008
10.19.2.9:3002 30
Fraunhofer FOKUS 2005
Requesting for Admission: PATH send
Admitted: RESV rcvd
Requesting for Admission: PATH send
Stop time reached: PATH-TEAR Send
page 16
CRUDE logged user traffic(UDP)
ID=30 SEQ=6 SRC=10.19.0.140:3002 DST=10.19.2.9:3002
Tx=1074075998.955231 Rx=1074075257.202783 SIZE=10000
ID=30 SEQ=7 SRC=10.19.0.140:3002 DST=10.19.2.9:3002
Tx=1074075998.955921 Rx=1074075257.203559 SIZE=10000
…
ID=30 SEQ=2031 SRC=10.19.0.140:3002 DST=10.19.2.9:3002
Tx=1074076003.966693 Rx=1074075262.244369 SIZE=10000
ID=40 SEQ=2032 SRC=10.19.1.139:3003 DST=10.19.3.10:3004
Tx=1074076003.966754 Rx=1074075262.244430 SIZE=10000
ID=30 SEQ=2033 SRC=10.19.0.140:3002 DST=10.19.2.9:3002
Tx=1074076003.967226 Rx=1074075262.244902 SIZE=10000
ID=40 SEQ=2034 SRC=10.19.1.139:3003 DST=10.19.3.10:3004
Tx=1074076003.967288 Rx=1074075262.244964 SIZE=10000
…
Fraunhofer FOKUS 2005
page 17
Conclusions and Further Work





The script driven synthetic traffic generation employed by RTLG enables the
test developer to model complex traffic models and dynamic traffic matrices
required for QoS signalling tests.
There is still some work to be done in developing a tool, which can automatically
generate large and complex configuration files (traffic behaviour files).
Developing a tool to ease the test results analysis and the visualization of the
test results since a lot of data must to be gathered and filtered from log files,
trace files and the script files during the analysis of the results.
We are developing a scenario specification language, which allows one to
describe a flow or aggregate flows at a higher level of abstraction.
Making RTLG interactive and reactive so that new flows can be created on
demand and so that QoS signalling initiations for certain user chosen flows can
be made to depend on the results of the previous QoS negotiation for some
other user chosen flow(s).
Fraunhofer FOKUS 2005
page 18
THANK YOU.......!!!!
Fraunhofer FOKUS 2005
page 19