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

1
RTLG - RSVP Enabled Traffic Load Generator for
Intra-Domain and Inter-Domain QoS Signalling
Tests.Ranganai Chaparadza,Yuri GlickmannPeter
H. DeussenMoMe Workshop Warsaw 2005
2
Introduction on QoS enabled IP transport Networks

• Todays 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 networks 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.

3
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.

4
Testing aspects in QoS enabled IP Transport
Networks

• 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.

5
QoS Signalling Tests

• QoS signalling tests involve the following
  procedures
• Stimulating the admission control and signalling
  handler components with generated signalling
  messages to test the functional behavior of these
  components.
• Generating variable signalling traffic load to
  test the performance and scalability of the
  signalling handler components by conducting load
  and stress testing.
• 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.
• Monitoring some routers and inferring end-to-end
  packet loss for some flows to ensure correct
  treatment of different traffic profiles.
• Emulating undesired behavior of some flows for
  robustness testing.
• Emulating inter-domain QoS signalling to ensure
  that inter-domain admission control policies can
  be tested.

6
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-to-multipoint
  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.

7
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.

8
The RTLG Tool, its Sender and Receiver parts

• RTLG consists of two parts, the sender
  (RTLG.send) and the receiver (RTLG.receive).

9
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 inter-packet 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.

10
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 IP-level and
  application level (UDP ports).

11
RTLG implementation model
12
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
  inter-domain 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.

13
Demonstration of how to conduct QoS signalling
tests using RTLG
14
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.93002 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.103004
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.103005
CONSTANT 200 316 RSVP 77 10.19.1.139 0050 TOS
0050 0xfc modification of bandwidth for flow
0030 after 17 seconds -gt 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
15
Flow Modifications during the flows 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.
• 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.
• 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.
• RSVP renegotiation. This modification causes the
  traffic generator to renegotiate the changed
  bandwidth. The flow transmission is not
  interrupted.
• 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.

16
RTLG Logging functionality
Logging Entity Time-stamp of an event Logged details RSVP sender/receiver, flow ID, flow state, message types etc.
sender 204026.014 10.19.2.93002 30 Requesting for Admission PATH send
receiver 204026.031 received PATH for 10.19.2.9/3002,17 FlowID30
receiver 204026.035 sending RESV for 10.19.2.9/3002,17 to 10.19.0.140 FlowID30
sender 204026.051 10.19.2.93002 30 Admitted RESV rcvd
sender 204027.012 10.19.3.103005 50 Requesting for Admission PATH send
receiver 204027.027 received PATH for 10.19.3.10/3005,17 FlowID50
receiver 204027.031 sending PATH-ERROR for 10.19.3.10/3005,17 to 10.19.1.139 FlowID50
sender 204027.045 10.19.2.93002 50 Not Admitted PATH-ERROR rcvd
sender 204043.011 10.19.2.93002 30 Start modification PATH-TEAR Send
sender 204043.015 10.19.2.93002 30 Requesting for Admission PATH send
receiver 204043.026 received PATH-TEAR for 10.19.2.9/3002,17 FlowID30
receiver 204043.030 sending RESV-TEAR for 10.19.2.9/3002,17 to 10.19.0.140 FlowID30
sender 204126.008 10.19.2.93002 30 Stop time reached PATH-TEAR Send
17
CRUDE logged user traffic(UDP)
ID30 SEQ6 SRC10.19.0.1403002
DST10.19.2.93002 Tx1074075998.955231
Rx1074075257.202783 SIZE10000 ID30 SEQ7
SRC10.19.0.1403002 DST10.19.2.93002
Tx1074075998.955921 Rx1074075257.203559
SIZE10000 ID30 SEQ2031 SRC10.19.0.1403002
DST10.19.2.93002 Tx1074076003.966693
Rx1074075262.244369 SIZE10000 ID40 SEQ2032
SRC10.19.1.1393003 DST10.19.3.103004
Tx1074076003.966754 Rx1074075262.244430
SIZE10000 ID30 SEQ2033 SRC10.19.0.1403002
DST10.19.2.93002 Tx1074076003.967226
Rx1074075262.244902 SIZE10000 ID40 SEQ2034
SRC10.19.1.1393003 DST10.19.3.103004
Tx1074076003.967288 Rx1074075262.244964
SIZE10000
18
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).

19

• THANK YOU.......!!!!