1 / 19

Introduction on QoS enabled IP transport Networks

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. Introduction on QoS enabled IP transport Networks. Today’s networks: IntServ/RSVP and DiffServ integrated networks

imogene-murray
Download Presentation

Introduction on QoS enabled IP transport Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

More Related