## 2 Testing Ethernet Based QoS
### Ethernet Test Models  
The IETF recommendation RFC 2544 describes standard and general test methodologies for Ethernet-based services, regardless of network elements' manufacturer [10; 11; 12; 13; 14]. In this regard, a single network element can be a device under test (DUT). This test is usually applied in the manufacturing of network equipment, and conducted in a laboratory environment. As is shown in Figure 2, a dual-port Ethernet test instrument is needed for this purpose, and no information on the overall network is acquired this way. Furthermore, testing an Ethernet network end-to-end, or its various sections, as well as transmission paths, is usually conducted after installation and during regular maintenance. For this purpose, distinct transmitting and receiving test devices are located either end-to-end or spanning section(s) of interest (see Figure 3). However, often a single test device is used as both transmitter and receiver, while at the far end, the appropriate loopback is made, but not only at layer L1, which used to be the case with classical SDH networks. Rather, the loopback device in this case must implement both L2- and L3-related functionality to swap the source and destination MAC and IP  
Figure 1: Carrier Ethernet system with multiple sections. Figure 3: End-to-end testing. Figure 2: Dual-port testing of a single network element. addresses, respectively, and return the received Ethernet frame (carrying the encapsulated IP packet) back to the transmitter (see Figure 4). In this case, the results pertain to the round trip, essentially implying twice as many sections involved in the test path (and accordingly impacting latency, throughput, errored frame/packet rate, etc.). This reduces the capability of fault isolation. Various standard Ethernet frame lengths can be used for testing, such as 64, 128, 256, 512, 1024, 1280, and 1518 Bytes. If Ethernet virtual LANs are implemented, then test frames also include a VLAN header, implying a maximal frame length of 1522 Bytes [15; 16]. Let us now consider testing throughput, latency, and jitter. **Throughput** is defined as the maximal count of transportable Ethernet frames in units of time. It is measured as a QoS indicator of whether the user is being delivered the committed bandwidth, and it is assessed either taking into account the (lost) Ethernet frames with a bad frame check sequence (FCS) of up to 10% of the total count of Ethernet frames during the test period, or allowing no loss of Ethernet frames at all in throughput assessment [2]. Furthermore, a larger throughput is achieved by using fewer longer Ethernet frames than by using more smaller ones, since the total relative frame overhead includes inter-frame spacing as well, and is smaller in the first case. Testing throughput starts with the maximal count of frames per second, which is reduced until the errored frames count is zero. (Test devices use special algorithms for determining the resolution and dynamics of frame count reduction as a function of instantaneous throughput.) **A latency** measurement provides integral results that include propagation and processing delay. It can also be measured at the network layer as the time that an IP packet needs to traverse through the network from its source to destination. In any case of end-to-end delay measurements, it is important to time-synchronize transmitting and receiving test instruments (if distinct ones are used; see Figure 3). If average Ethernet frame or IP packet delay is longer than 2 s, these are considered lost and not taken into account in delay calculation. Delay variation, which is commonly referred to as jitter, is important for the transport of real-time services, such as in voice-over-IP (VoIP) or IPTV [2]. **The frame loss rate** is defined as the relative count of the frames that either did not arrive at the destination or have bad cyclic redundancy check (CRC) due to bit errors, increased delay, congestion, wrong priority, and QoS setup of multiple Ethernet ports sharing the communication link.