EFM ETHERNET IN THE FIRST MILE CONSORTIUM Technical Document Last Updated: March 23, 2005 12:43pm Ethernet in the First Mile Consortium 121 Technology Drive, Suite 2 InterOperability Laboratory Durham, NH 03824 University of New Hampshire Phone: +1-603-862-7053 http://www.iol.unh.edu/consortiums/efm 2005 University of New Hampshire InterOperability Laboratory
MODIFICATION RECORD March 23, 2005 v1.1 Released - Mainly editorial updates July 2, 2004 v1.0 Released - Updated test suite to reference D3.3 - Modifications to tests 65.1.4 - Added Group 3 tests - Added PICS coverage information to each group heading. February 16, 2004 v0.1 Released - Initial version of test suite Ethernet in the First Mile Consortium 2
ACKNOWLEDGMENTS The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite. Eric Lynskey University of New Hampshire Ethernet in the First Mile Consortium 3
INTRODUCTION Overview The University of New Hampshire s InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a device under test (DUT) can be tested against other implementations of a standard. This suite of tests has been developed to help implementers evaluate the functioning of their Clause 65 based products. The tests do not determine if a product fully conforms to IEEE Std 802.3ah-2004. Rather, they provide one method to isolate problems within an EPON device. Note: successful completion of tests contained in this suite does not guarantee that the tested device is fully compliant or that it will operate with all other compliant devices. Organization of Tests The tests contained in this document are organized to simplify the identification of information related to a test and to facilitate in the actual testing process. Each test contains an identification section that describes the test and provides cross-reference information. The discussion section covers background information and specifies why the test is to be performed. Tests are grouped by similar functions and further organized by technology. Each test contains the following information: Test Number The Test Number associated with each test follows a simple grouping structure. Listed first is the Test Group Number followed by the test's number within the group. This allows for the addition of future tests to the appropriate groups of the test suite without requiring the renumbering of the subsequent tests. Purpose The purpose is a brief statement outlining what the test attempts to achieve. The test is written at the functional level. References The references section lists cross-references to the IEEE 802.3 standards and other documentation that might be helpful in understanding and evaluating the test and results. Resource Requirements The requirements section specifies the hardware, and test equipment that will be needed to perform the test. The items contained in this section are special test devices or other facilities, which may not be available on all devices. Last Modification This specifies the date of the last modification to this test. Discussion The discussion covers the assumptions made in the design or implementation of the test as well as known limitations. Other items specific to the test are covered here. Test Setup The setup section describes the configuration of the test environment. Small changes in the configuration should be included in the test procedure. Procedure The procedure section of the test description contains the step-by-step instructions for carrying out the test. It provides a cookbook approach to testing, and may be interspersed with observable results. Ethernet in the First Mile Consortium 4
Observable Results The observable results section lists specific items that can be examined by the tester to verify that the DUT is operating properly. When multiple values are possible for an observable result, this section provides a short discussion on how to interpret them. The determination of a pass or fail for a certain test is often based on the successful (or unsuccessful) detection of a certain observable result. Possible Problems This section contains a description of known issues with the test procedure, which may affect test results in certain situations. Ethernet in the First Mile Consortium 5
TABLE OF CONTENTS MODIFICATION RECORD...2 ACKNOWLEDGMENTS...3 INTRODUCTION...4 TABLE OF CONTENTS...6 GROUP 1: Preamble modifications...7 Test #65.1.1 Preamble transmission...8 Test #65.1.2 Mode and logical_link_id transmission...10 Test #65.1.3 CRC-8 generation...11 Test #65.1.4 SLD parsing...12 Test #65.1.5 parsing...14 Test #65.1.6 CRC-8 checking...15 GROUP 2: Data Detection...16 Test #65.2.1 Buffer depth...17 Test #65.2.2 Laser control...18 GROUP 3: System Tests...19 Test #65.3.1 Unidirectional operation...20 Test #65.3.2 Enabling of OLT and ONU...21 Test #65.3.3 Loop timing...22 Test #65.3.4 Delay variation...23 GROUP 4: Forward Error Correction...24 Ethernet in the First Mile Consortium 6
GROUP 1: Preamble modifications Overview: The following tests cover modifications made to the preamble for P2MP devices that implement the RS defined in Clause 65. Both the transmission and reception of frames is tested. The PICS items related to this group of tests is: FS2, FS3, PM1, PM2, PM3, PM4, PM5, PM6, PM7, and PM8. Ethernet in the First Mile Consortium 7
Test #65.1.1 Preamble transmission Purpose: To verify that the DUT transmits the proper preamble for all frames. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3 [2] IEEE Std 802.3ah-2004 table 65-1 [3] Preamble modifications for P2MP networks whitepaper Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: The broadcast nature of a point to multipoint (P2MP) network means that it is necessary to perform packet filtration within the reconciliation sublayer (RS). A receiving RS will only accept packets addressed to itself and will discard other packets. The mechanism for performing this filtering function is described in the above references. The preamble and start of frame delimiter (SFD), which are the first 8 header bytes of a frame, have been modified to contain an identifier () and CRC check of this value. Figure 1 shows the specified modifications to the preamble. SPD CRC8 Preamble DA SA Length/ Type Data/Pad FCS 8-bytes 6-bytes 6-bytes 2-bytes 46-1500 bytes 4-bytes Figure 1. Preamble modifications for P2MP networks On transmission, the first two bytes of preamble are unaltered. The third byte of preamble is replaced with an SPD containing the value 0xD5. The fourth and fifth octets are also transmitted without modification. The sixth and seventh octets contain a concatenation of the mode and bits of the DUT. Finally, the SFD is replaced by an 8- bit CRC value that encompasses data from the SPD field through the CRC8 field. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Instruct the DUT to transmit the following frames to the sniffer: Discovery GATE, Normal GATE, Broadcast DATA, Unicast DATA, REGISTER 2. Observe all transmissions from the DUT. Case 2: DUT is an ONU 1. Instruct the DUT to transmit the following frames to the sniffer: REPORT, REGISTER_REQ, REGISTER_ACK, Unicast DATA, Broadcast DATA. 2. Observe all transmissions from the DUT. Ethernet in the First Mile Consortium 8
Observable results: a. For all frames transmitted by the DUT, preamble bytes 1, 2, 4, and 5 should be transmitted unaltered as 0x. b. For all frames transmitted by the DUT, preamble byte 3 should be replaced with 0xD5. c. For all frames transmitted by the DUT, preamble bytes 6 and 7 should be replaced with <mode, logical_link_id[14:8] and logical_link_id[7:0], respectively. d. For all frames transmitted by the DUT, the SFD should be replaced with the properly calculated CRC8. Possible Problems: It is possible that the DUT will delete the first byte of preamble upon transmission through the PCS. When this happens, the frame should be parsed as if the first byte of preamble were really the second byte. Ethernet in the First Mile Consortium 9
Test #65.1.2 Mode and logical_link_id transmission Purpose: To verify that the DUT properly transmits its mode and logical_link_id information. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.1 [2] IEEE Std 802.3ah-2004 subclause 65.1.3.2.2 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: The sixth and seventh bytes of preamble are replaced with the two-byte field. This field contains a concatenation of the mode and logical_link_id values. Byte 6 contains <mode, logical_link_id[14:8]> and byte 7 contains logical_link_id[7:0]. The mode bit takes on a value of 0 for an ONU and may take on a value of either 0 or 1 for an OLT. When transmitting on a unicast channel, the OLT will set this bit to 0. When transmitting on a broadcast or multicast channel, the OLT will set this bit to 1. The logical_link_id variable should take on the value of 0x7FFF for an unregistered ONU and may take on any value other than 0x7FFF for a registered ONU. An OLT may transmit frames with any value in this variable. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Instruct the DUT to transmit Discovery GATE, Normal GATE, REGISTER, Unicast DATA, and Broadcast DATA frames to the sniffer. 2. Observe all transmissions from the DUT. Case 2: DUT is an ONU 1. Instruct the DUT to transmit REGISTER_REQ, REGISTER_ACK, REPORT, Unicast DATA, and Broadcast DATA frames to the sniffer. 2. Observe all transmissions from the DUT. Observable results: Case 1: DUT is an OLT a. Discovery GATE frames should have mode bit set to 1 and broadcast logical_link_id (0x7FF). b. REGISTER frames should have mode bit set to 1 and broadcast logical_link_id. c. Normal GATE frames should have mode bit set to 0 and unicast logical_link_id. d. Unicast DATA frames should have mode bit set to 1 and unicast logical_link_id. e. Broadcast DATA frames should have mode bit set to 1 and broadcast logical_link_id. Case 2: DUT is an ONU a. REGISTER_REQ frames should have mode bit set to 0 and broadcast logical_link_id. b. REGISTER_ACK frames should have mode bit set to 0 and unicast logical_link_id. c. REPORT frames should have mode bit set to 0 and unicast logical_link_id. d. Unicast DATA frames should have mode bit set to 0 and unicast logical_link_id. e. Broadcast DATA frames should have mode bit set to 0 and unicast logical_link_id. Possible Problems: None. Ethernet in the First Mile Consortium 10
Test #65.1.3 CRC-8 generation Purpose: To verify that the DUT properly calculates the value of the 8-bit CRC in the preamble. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.2.3 [2] IEEE Std 802.3ah-2004 figure 65-2 [3] Preamble modifications for P2MP networks whitepaper Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: The final byte of preamble contained within a P2MP frame is replaced with an 8-bit cyclic redundancy check (CRC8) value. This value is computed as a function of the data contained between the SPD and CRC8, or six bytes in total. The formula for computing the CRC is: G(x) = x 8 + x 2 + x + 1. Reference [3] describes the algorithm in more detail and provides an example for comparison. Although parallel implementations may be used within a system, the value generated by both the parallel and serial implementations are identical. The CRC is calculated for every frame and the initial value of the register is reinitialized to 0x00 at the beginning of each frame. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: 1. Instruct the DUT to transmit frames to the sniffer. 2. Observe all transmissions from the DUT. Observable results: a. All frames transmitted by the DUT should contain a properly calculated CRC8 value, and the DUT should initialize the CRC8 shift register with 0x00 before each frame. Possible Problems: None. Ethernet in the First Mile Consortium 11
Test #65.1.4 SLD parsing Purpose: To verify that the DUT properly parses the SLD in a received frame. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.3 [2] IEEE Std 802.3ah-2004 subclause 65.1.3.3.1 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Upon reception of a P2MP frame, the DUT must parse the preamble to try and find the SLD. Under normal conditions, the SLD may be found in the second or third byte of preamble. If the SLD is not found in either of these two locations at the receiving RS, the frame should be discarded. If the SLD is found, it should be replaced with valid preamble (0x) and passed up to the receiving MAC. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: 1. Instruct the testing station to transmit frames to the DUT with the Preamble/SFD replaced with the patterns shown below. a. b. c. d. e. f. g. h.* D5 CRC8 D5 CRC8 CRC8 CRC8 D5 CRC8 D5 CRC8 01 D5 02 03 CRC8 D5 D5 00 CRC8 * Note that in case h, the frame is constructed such that the fourth byte of preamble contains 0xD5, which the RS should pass through without modification. The MAC, however, will recognize this as the SFD and will assume that the next byte will be the first byte of the MAC destination address. The frame is constructed such that if the RS passes the fourth and fifth bytes of preamble without modification and replaces the two bytes of with 0x and the CRC8 with SFD, then the CRC will be valid. Therefore, the real frame will begin at the fourth byte of preamble. 2. Observe management and indications on the DUT. 3. Repeat steps 1 and 2 for each of the test cases shown above. Observable results: a. The DUT should accept the frame with the pattern shown in case a. b. The DUT should accept the frame with the pattern shown in case b. c. The DUT should discard the frame with the pattern shown in case c. d. The DUT should discard the frame with the pattern shown in case d. e. The DUT should discard the frame with the pattern shown in case e f. The DUT should discard the frame with the pattern shown in case f g. The DUT should replace the SLD with 0x before passing it up to the MAC. The DUT should also pass up the two bytes of preamble preceding and following the SLD unaltered. h. The DUT should replace each modified byte of preamble with 0x and the CRC8 with the SFD. Ethernet in the First Mile Consortium 12
Possible Problems: It may not be possible to verify that the DUT replaces the SLD with 0x or passes up the preceding and following bytes of preamble without modification. Ethernet in the First Mile Consortium 13
Test #65.1.5 parsing Purpose: To verify that the DUT properly parses the in a received frame. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.3 [2] IEEE Std 802.3ah-2004 subclause 65.1.3.3.2 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Upon reception of a P2MP frame, the DUT must parse the to determine whether or not to accept the frame. The comparison is different depending if the DUT is an OLT or ONU. If the DUT is an OLT, it ignores the received mode bit and only looks at the received logical_link_id. If the logical_link_id is 0x7FFF and an enabled MAC exists with the same logical_link_id, the frame should be accepted. If the logical_link_id is anything else and an enabled unicast MAC exists with an identical logical_link_id, the frame should be accepted. All other frames should be discarded. For an ONU, if the received mode bit is 0 and the logical_link_id matches its own logical_link_id, the frame should be accepted. If the received mode bit is 1 and the logical_link_id is 0x7FFF or does not match its own logical_link_id, the frame should be accepted. All other frames should be discarded. For all received frames by either the ONU or OLT, the should be replaced with 0x. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Transmit a frame to the DUT with a mode bit of 0 and of 0x7FFF. 2. Observe management and indications on the DUT. 3. Repeat, transmitting a frame to the DUT with a mode bit of 1 and of 0x7FFF. 4. Repeat, transmitting a frame to the DUT with mode bit 0 and of enabled unicast MAC. 5. Repeat, transmitting a frame to the DUT with mode bit 1 and of enabled unicast MAC. 6. Repeat, transmitting a frame to the DUT with mode bit 0 and of disabled unicast MAC. 7. Repeat, transmitting a frame to the DUT with mode bit 1 and of disabled unicast MAC. Case 2: DUT is an ONU 1. Transmit a frame to the DUT with a mode bit of 0 and of the DUT. 2. Observe management and indications on the DUT. 3. Repeat, transmitting a frame to the DUT with mode bit 0 and not that of the DUT. 4. Repeat, transmitting a frame to the DUT with mode bit 1 and of the DUT. 5. Repeat, transmitting a frame to the DUT with mode bit 1 and not that of the DUT. Observable results: Case 1: DUT is an OLT a. The DUT should accept the frames in parts 1, 3, 4, and 5. The DUT should discard the frames in parts 6 and 7. For frames that are accepted, the DUT should replace the with 0x. Case 2: DUT is an ONU a. The DUT should accept the frames in parts 1 and 5. The DUT should discard the frames in parts 3 and 4. For frames that are accepted, the DUT should replace the with 0x. Possible Problems: It may not be possible to verify that the DUT replaces the with 0x. Ethernet in the First Mile Consortium 14
Test #65.1.6 CRC-8 checking Purpose: To verify that the DUT properly checks the value of the CRC in the received frame. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.3 [2] IEEE Std 802.3ah-2004 subclause 65.1.3.3.3 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Upon reception of a P2MP frame, the DUT must verify that the received CRC8 value is correct. The CRC is calculated from the SPD through the CRC8 and the value is compared to that received. If the values match, the frame should be accepted and the CRC8 replaced with an SFD. If the CRC is incorrect, the frame should be discarded. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: 1. Instruct the testing station to transmit a frame to the DUT with a valid CRC8. 2. Observe management and indications on the DUT. 3. Repeat, transmitting frames to the DUT with an invalid CRC8. Observable results: a. The DUT should accept all frames that have a valid CRC8 and discard all frames that have an invalid CRC8. b. On frames that are accepted, the DUT should replace the CRC8 with an SFD. Possible Problems: None. Ethernet in the First Mile Consortium 15
GROUP 2: Data Detection Overview: The following tests cover considerations necessary for data detection and operation of a P2MP network. The PICS items related to this group of tests are: DD1, DD2, and DD3. Ethernet in the First Mile Consortium 16
Test #65.2.1 Buffer depth Purpose: To verify that the DUT properly transmits the correct amount of idle before its first frame. References: [1] IEEE Std 802.3ah-2004 subclause 65.2.2.1 [2] IEEE Std 802.3ah-2004 subclause 65.2.2.2.1 [3] IEEE Std 802.3ah-2004 figure 65-5 [4] IEEE Std 802.3ah-2004 figure 65-6 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: When an ONU is waiting to be granted a transmission window by the OLT, it does so with its laser turned off. At the beginning of the transmission window, the ONU will turn on its laser and then must transmit a certain amount of idle before the beginning of the first frame. The idle is necessary to allow the OLT to stabilize its receiver for the specific ONU. Since the OLT is connected to a number of different ONUs, it must re-synchronize and lock on to each ONU s laser every time it is to receive something from an active ONU. The amount of time this takes is referred to as SyncTime. This value is relayed to the ONU by the OLT during the discovery process. The default value of this time, and therefore the amount of idle the DUT must transmit before beginning a frame is 848ns. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: 1. Instruct the testing station to inform the DUT that the SyncTime is X ns. 2. Instruct the DUT to transmit a frame to the testing station. 3. Observe all outputs from the DUT. 4. Repeat steps 1-3, modifying the value of SyncTime. Observable results: a. The DUT should transmit at idle for at least SyncTime before transmitting its first frame. Possible Problems: If the DUT is not an ONU, this test cannot be done. Ethernet in the First Mile Consortium 17
Test #65.2.2 Laser control Purpose: To verify that the DUT properly controls its laser between transmissions. References: [1] IEEE Std 802.3ah-2004 subclause 65.2.2.1 [2] IEEE Std 802.3ah-2004 figure 65-5, figure 65-6 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: When the buffer of the DUT is filled with idle, it should turn its laser off. As data enters the buffer, the laser turns on and the DUT transmits the appropriate amount of idle before beginning to transmit data. Upon completion of its time window, the DUT will stop transmitting frames and turn off its laser. If the gap between consecutive frames is large enough, the DUT should also turn off its laser and then go through the process of transmitting the additional idle again. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Instruct the DUT to transmit frames with various amounts of idle between them. 2. Observe all transmissions from the DUT. Case 2: DUT is an ONU 1. Determine the size of the laser control buffer of the DUT and set this to B size. 2. Instruct the DUT to transmit two frames with less than B size of idle between them. 3. Observe all transmissions from the DUT. 4. Repeat steps 1-3 with a gap of B size between the two frames. 5. Repeat steps 1-3 with a gap of greater than B size between the two frames. 6. If possible, repeat steps 1-5, varying the size of the buffer of the DUT. Observable results: Case 1: DUT is an OLT a. The DUT should never turn its laser off. Case 2: DUT is an ONU a. When transmitting frames with less than B size of idle between them, the DUT should not turn its laser off between frames. b. When transmitting frames with equal to or greater than B size of idle between them, the DUT should turn its laser off between frames. Possible Problems: If the DUT is not an ONU, this test cannot be done. Ethernet in the First Mile Consortium 18
GROUP 3: System Tests Overview: The following tests cover considerations necessary for system level operation of a P2MP network. The PICS items related to this group of tests are: OM1, FS1, BMC1, and DV1. Ethernet in the First Mile Consortium 19
Test #65.3.1 Unidirectional operation Purpose: To verify that the PCS of the OLT properly operates in unidirectional mode and that the PCS of the ONU does not operate in unidirectional mode. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.2 [2] IEEE Std 802.3ah-2004 subclause 66.2.2 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Unidirectional operation is what allows the OLT to properly operate and manage the EPON. The OLT has the ability to transmit frames when it is not receiving anything from any of the ONUs, or when its receiver is not properly synchronized to an incoming bit stream. Since the OLT must be able to switch from ONU to ONU, its receiver status will constantly being going up and down. Unidirectional mode allows the OLT to operate as if it has a link all the time. Conversely, the ONU cannot operate in unidirectional mode, and in fact, cannot transmit anything until it is told to do so by the OLT. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Connect the receiver of the DUT to a valid stream of idle. 2. Instruct the DUT to transmit data frames to the testing station. 3. Repeat steps 1 and 2, with the receiver of the DUT disconnected. Case 2: DUT is an ONU 1. Connect the receiver of the DUT to a valid stream of idle. 2. Instruct the DUT to transmit data frames to the testing station. 3. Repeat steps 1 and 2, with the receiver of the DUT disconnected. 4. Repeat steps 1 and 2, with the receiver connected to an OLT and have the OLT grant the ONU time to transmit frames. Observable results: Case 1: DUT is an OLT a. The DUT should be able to transmit frames regardless of whether or not its receiver is locked on to an incoming bit stream. Case 2: DUT is an ONU a. The DUT should only transmit frames when granted by the OLT. Ethernet in the First Mile Consortium 20
Test #65.3.2 Enabling of OLT and ONU Purpose: To verify that the enable variable is properly set for both an ONU and OLT. References: [1] IEEE Std 802.3ah-2004 subclause 65.1.3.1 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: The enable variable is always set to true for an ONU MAC. For an OLT MAC, the enable variable is set to true when a logical_link_id and mode has been assigned to that specific MAC, and false when the MAC is not in use. Test Setup: Connect the DUT to the emulator and sniffer. Procedure: Case 1: DUT is an OLT 1. Assign a mode and logical_link_id to one of the MACs of the DUT. 2. Query management of the DUT. 3. Repeat steps 1 and 2, but do not assign a mode and logical_link_id to the MAC. 4. Repeat steps 1 through 3 for each MAC contained within the DUT. Case 2: DUT is an ONU 1. Register the DUT on the EPON with an OLT. 2. Query management of the DUT. 3. Repeat steps 1 and 2, but do not register the DUT on the EPON. Observable results: Case 1: DUT is an OLT a. The DUT should enable a MAC only when a logical_link_id and mode is assigned to it. Case 2: DUT is an ONU a. The DUT should always enable its MAC. Ethernet in the First Mile Consortium 21
Test #65.3.3 Loop timing Purpose: To verify that the ONU operates at the same time basis as the OLT. References: [1] IEEE Std 802.3ah-2004 subclause 65.3.1.2 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Due to the timing constraints of MPCP, it is necessary for the ONU to operate at the same time basis as the OLT. The ONU needs to track the received clock from the OLT and use that as its transmit clock. As of July 2, 2004, this test is under development. A complete description of the procedures and observable results should be available in a future revision of this test suite. Ethernet in the First Mile Consortium 22
Test #65.3.4 Delay variation Purpose: To verify that the delay variation through the RS, PCS, and PMA is no more than 16 bit times. References: [1] IEEE Std 802.3ah-2004 subclause 65.3.3 Resource Requirements: EPON sniffer capable of monitoring all transmissions originating from the OLT or ONU Emulator capable of communicating with either ONU or OLT Last Modification: March 23, 2005 Discussion: Due to the strict timing and timestamps necessary for proper operation of MPCP, it is a requirement that the delay variation through the PHY of the OLT and ONU is no more than 16 bit times. As of July 2, 2004, this test is under development. A complete description of the procedures and observable results should be available in a future revision of this test suite. Ethernet in the First Mile Consortium 23
GROUP 4: Forward Error Correction Overview: The following tests cover considerations necessary for operation of forward error correction on a P2MP network. The PICS items related to this group of tests are: FE1, FE2, SM1, SM2, SM3. Please note that as of July 1, 2004, these tests are still under development and should be released in a future version of the test suite. Ethernet in the First Mile Consortium 24