From 8e10420ae0516f985e080cc4af7f4b1001f29060 Mon Sep 17 00:00:00 2001 From: Maryam Tahhan Date: Sun, 22 Mar 2015 16:54:03 +0000 Subject: TestSpec: Add LTD.Throughput.RFC6201.ResetTime Add a definition for RFC 6201 Reset Time Test Change-Id: I31cd5befb1e662697fe4d8ff81caa229ae6bfb64 JIRA: VSPERF-13 Signed-off-by: Maryam Tahhan Reviewed-by: Al Morton --- test_spec/vswitchperf_ltd.md | 53 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/test_spec/vswitchperf_ltd.md b/test_spec/vswitchperf_ltd.md index 2b023cfb..7cbbed2b 100644 --- a/test_spec/vswitchperf_ltd.md +++ b/test_spec/vswitchperf_ltd.md @@ -680,6 +680,59 @@ The following represents possible deployments which can help to determine the pe - Any outliers in the Throughput stability. - Any unexpected variation in Throughput stability. +
+ + - #####Test ID: LTD.Throughput.RFC6201.ResetTime + **Title**: RFC 6201 Reset Time Test + + **Prerequisite Test**: N\A + + **Priority**: + + **Description**: + + The aim of this test is to determine the length of time it takes the DUT to recover from a reset. For each frame size previously defined under [Default Test Parameters](#DefaultParams), traffic should be sent to the DUT under normal conditions. During the duration of the test and while the traffic flows are passing through the DUT, the DUT should be reset and the Reset time measured. The Reset time is the total time that a device is determined to be out of operation and includes the time to perform the reset and the time to recover from it (cf. [RFC6201]) + + [RFC6201] defines two methods to measure the Reset time: + - Frame-Loss Method: which requires the monitoring of the number of lost frames and calculates the Reset time based on the number of frames lost and the offered rate according to the following formula: + 

+                              Frames_lost (packets)
+          Reset_time = -------------------------------------
+                         Offered_rate (packets per second)
+
+ - Timestamp Method: which measures the time from which the last frame is forwarded from the DUT to the time the first frame is forwarded after the reset. This involves time-stamping all transmitted frames and recording the timestamp of the last frame that was received prior to the reset and also measuring the timestamp of the first frame that is received after the reset. The Reset time is the difference between these two timestamps. + + According to [RFC6201] the choice of method depends on the test tool's capability; the Frame-Loss method SHOULD be used if the test tool supports: + - Counting the number of lost frames per stream. + - Transmitting test frame despite the physical link status. + + whereas the Timestamp method SHOULD be used if the test tool supports: + - Timestamping each frame. + - Monitoring received frame's timestamp. + - Transmitting frames only if the physical link status is up. + + **Expected Result**: + + **Metrics collected** + + The following are the metrics collected for this test: + - Average Reset Time. + + Results of this test should include the following information: + - Throughput in Fps and Mbps. + - Average Frame Loss. + - Average Reset Time in milliseconds. + - Number of trials. + - Protocol: IPv4, IPv6, MPLS, etc. + - Frame Size in Octets + - Port Media: Ethernet, Gigabit Ethernet (GbE), etc. + - Port Speed: 10 Gbps, 40 Gbps etc. + - Interface Encapsulation: Ethernet, Ethernet VLAN, etc. + + **Deployment scenario**: + + - Physical → virtual switch → physical. +
[RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt) [RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt) -- cgit 1.2.3-korg