ISO 21111-10:2021

INTERNATIONAL ISO
STANDARD 21111-10
First edition
2021-10
Road vehicles — In-vehicle Ethernet —
Part 10:
Transport layer and network layer
conformance test plans
Véhicules routiers — Ethernet embarqué —
Partie 10: Plans de test de conformité des couches transport et réseau
Reference number
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conventions . 4
6 CTP test system set-up and CTC structure . 4
6.1 General . 4
6.2 Test system set-up . 5
6.3 CTC definition . 6
6.4 Terminology used in CTCs . 7
6.5 IUT prerequisites – TCP/IP TestStub . 7
6.5.1 General . 7
6.5.2 TCP/IP TestStub service primitives . 7
6.5.3 Result codes . 8
7 Network and transport layers CTCs .8
7.1 NL – Address resolution protocol (ARP) . 8
7.1.1 General . 8
7.1.2 Referenced specification . 8
7.1.3 Test system topology – NL – ARP . 8
7.1.4 Test system topology and related CTC configuration . 9
7.1.5 CTC ARP overview . 9
7.1.6 ARP parameters used in CTCs . 10
7.1.7 ARP CTCs . 11
7.2 NL – Internet control message protocol version 4 (ICMPv4) . 42
7.2.1 General . 42
7.2.2 Referenced specification . 42
7.2.3 Test system topology – NL – ICMPv4. 42
7.2.4 Test system topology and related CTC configuration . 43
7.2.5 ICMPv4 parameters used in CTCs . 43
7.2.6 ICMPv4 CTCs .44
7.3 NL – Internet protocol version 4 (IPv4) .54
7.3.1 General .54
7.3.2 Referenced specification .54
7.3.3 Test system topology – NL – IPv4 .54
7.3.4 Test system topology and related CTC configuration . 55
7.3.5 IPv4 parameters used in CTCs . 55
7.3.6 IPv4 CTCs .56
7.4 NL – Dynamic configuration of IPv4 link local address .82
7.4.1 General .82
7.4.2 Referenced specification .82
7.4.3 Test system topology – NL – Dynamic configuration of IPv4 link local
address .82
7.4.4 Test system topology and related CTC configuration .83
7.4.5 Dynamic configuration of IPv4 parameters and constants used in CTCs .83
7.4.6 IPv4 autoconf CTCs .84
7.5 TL – User datagram protocol (UDP) . 117
7.5.1 General . 117
7.5.2 Referenced specification . 117
iii
7.5.3 Test system topology – TL – UDP . 118
7.5.4 Test system topology and related CTC configuration .118
7.5.5 UDP parameters used in CTCs . 118
7.5.6 UDP CTCs . 119
7.6 TL – Transmisison control protocol (TCP) .137
7.6.1 General .137
7.6.2 Referenced specification .138
7.6.3 Test system topology – TL – TCP . .138
7.6.4 Test system topology and related CTC configuration .138
7.6.5 TCP parameters used in CTCs .138
7.6.6 TCP CTCs .139
Bibliography . 205
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
A list of all parts in the ISO 21111 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
The ISO 21111 series includes in-vehicle Ethernet requirements and test plans that are disseminated in
other International Standards and complements them with additional test methods and requirements.
The resulting requirement and test plans are structured in different documents following the Open
Systems Interconnection (OSI) reference model and grouping the documents that depend on the
physical media and bit rate used.
In general, the Ethernet requirements are specified in ISO/IEC/IEEE 8802-3. The ISO 21111 series
provides supplemental specifications (e.g. wake-up, I/O functionality), which are required for in-vehicle
Ethernet applications. In road vehicles, Ethernet networks are used for different purposes requiring
different bit-rates. Currently, the ISO 21111 series specifies the 1-Gbit/s optical and 100-Mbit/s
electrical physical layer.
The ISO 21111 series contains requirement specifications and test methods related to the in-vehicle
Ethernet. This includes requirement specifications for physical layer entity (e.g. connectors, physical
layer implementations) providers, device (e.g. electronic control units, gateway units) suppliers, and
system (e.g. network systems) designers. Additionally, there are test methods specified for conformance
testing and for interoperability testing.
Safety (electrical safety, protection, fire, etc.) and electromagnetic compatibility (EMC) requirements
are out of the scope of the ISO 21111 series.
The structure of the specifications given in the ISO 21111 series complies with the Open Systems
[1] [2]
Interconnection (OSI) reference model specified in ISO/IEC 7498-1 and ISO/IEC 10731 .
ISO 21111-1 defines the terms which are used in this series of standards and provides an overview of
the standards for in-vehicle Ethernet including the complementary relations to ISO/IEC/IEEE 8802-3,
the document structure, type of physical entities, in-vehicle Ethernet specific functionalities and so on.
ISO 21111-2 specifies the interface between reconciliation sublayer and physical entity including
reduced gigabit media independent interface (RGMII), and the common physical entity wake-up and
synchronized link sleep functionalities, independent from physical media and bit rate.
ISO 21111-2 specifies supplemental requirements to a physical layer capable of transmitting
1-Gbit/s over plastic optical fibre compliant with ISO/IEC/IEEE 8802-3, with specific application to
communications inside road vehicles, and a test plan for physical entity conformance testing.
ISO 21111-4 specifies the optical components requirements and test methods for 1-Gbit/s optical
invehicle Ethernet.
ISO 21111-5 specifies, for 1-Gbit/s optical in-vehicle Ethernet, requirements on the physical layer at
system level, requirements on the interoperability test set-ups, the interoperability test plan that checks
the requirements for the physical layer at system level, requirements on the device-level physical layer
conformance test set-ups, and device-level physical layer conformance test plan that checks a set of
requirements for the OSI physical layer that are relevant for device vendors.
ISO 21111-6 specifies advanced features of an ISO/IEC/IEEE 8802-3 in-vehicle Ethernet physical layer
(often also called transceiver), e.g. for diagnostic purposes for in-vehicle Ethernet physical layers. It
specifies advanced physical layer features, wake-up and sleep features, physical layer test suite,
physical layer control requirements and conformance test plan, physical sublayers test suite and
physical sublayers requirements and conformance test plan.
ISO 21111-7 specifies the implementation for ISO/IEC/IEEE 8802-3:2021, which defines the interface
implementation for automotive applications together with requirements on components used to realize
this Bus Interface Network (BIN). ISO 21111-7 also defines further testing and system requirements
for systems implemented according to the system specification. In addition, ISO 21111-7 defines
the channels for tests of transceivers with a test wiring harness that simulates various electrical
communication channels.
vi
ISO 21111-8 specifies the transmission media, the channel performance and the tests for
ISO/IEC/IEEE 8802-3 in-vehicle Ethernet.
ISO 21111-9 specifies the data link layer requirements. It specifies the requirements for devices and
systems with bridge functionality.
This document specifies the transport layer and network layer requirements and conformance test
plans. It specifies the conformance test plans for devices and systems that include functionality related
with OSI layers from 4 and 3.
ISO 21111-11 specifies the application layer to session layer requirements and conformance test plans.
It specifies the conformance test plans for devices and systems that include functionality related with
OSI layers from 7 to 5.
Figure 1 shows the parts of the ISO 21111 series and the document structure.
Figure 1 — In-vehicle Ethernet documents reference according to OSI model
vii
INTERNATIONAL STANDARD ISO 21111-10:2021(E)
Road vehicles — In-vehicle Ethernet —
Part 10:
Transport layer and network layer conformance test plans
1 Scope
This document specifies in-vehicle Ethernet transport layer and network layer conformance test
plans (CTP) for electronic control units (ECUs). This document is a collection of all conformance test
cases which are recommended to be considered for automotive use and should be referred by car
manufacturers within their quality control processes.
The document includes conformance test plans for the address resolution protocol, Internet control
message protocol version 4, Internet protocol version 4, Internet protocol version 4 auto configuration,
user datagram protocol, transport control protocol, and dynamic host configuration protocol version 4.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 1: General concepts
ISO 21111-1, Road vehicles — In-vehicle Ethernet — Part 1: General information and definitions
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21111-1, ISO/IEC 9646-1 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
REPEAT
pseudo code command for an iteration
3.2
full-sized segment
segment with size equal to the effective send MSS
3.3
result code
value attributed to a result
3.4
generic result code
specific and universal value attributed to a result
3.5
full-window operation
IUT's TCP has reached a state where it is allowed to send data segments of size of test system Host-1's
entire receive without getting any acknowledgement from the test system Host-1
4 Symbols and abbreviated terms
4.1 Symbols
— empty table cell or feature undefined
V voltage of the battery
BAT
t
ARP-Dynamic-Cache-Timeout
time for which a dynamic entry is present in the ARP cache
t
ARP-Dynamic-Cache-Tolerance tolerance time for the ARP dynamic cache of the IUT to get refreshed
t
ARP-Tolerance IUT: tolerance time for the ARP cache of the IUT to get refreshed
LT: time variance associated to any wait-event
t
Valid-Time-To-Live
time interval of IP datagram send
t
Listen-Time
maximum time interval for which the LT waits for an ICMP reply
segment
t
Fragment-Reassemly-Timeout fragment reassembly timeout
t
Valid-Time-To-Live
value used in IP datagram send
t
Probe_Min
value of PROBE_MIN constant
t
Probe_Max value of PROBE_MAX constant
t
Announce_Wait value of ANNOUNCE_WAIT constant
t
Announce_Interval
value of ANNOUNCE_INTERVAL constant
t
Rate_Limit_Interval
value of RATE_LIMIT_INTERVAL constant
t
Defend_Interval value of DEFEND_INTERVAL constant
4.2 Abbreviated terms
ACK acknowlege
Addr address
AL application layer
ANVL automated network validation library
ARL address resolution lookup
ARP address resolution protocol
ASP abstract service primitive
CTC conformance test case
CTP conformance test plan
EMC electromagnetic compatibility
EOP end of option
ETS enhanced testability service
FIF filtering of incoming frames
FIN finish control flag
FINWAIT finish wait
GEN general requirements
GND ground
ICMP internet control message protocol
IHL Internet header length
IUT implementation under test
IUT-Iface IUT physical layer interface
ISN initial sequence number
LT lower tester
LT-Iface LT physical layer interface
MSL maximum segment lifetime
MSS maximum segment size
MTU maximum transmission unit
Mv manipulated value
NL network layer
NOP no operation
PCO points of control and observation
PHY physical layer
PSH push
QOS qualitiy of service and audio/video bridging
RCVD received
RCV.NXT receive next
RPC remote procedure call
RST reset
RTO retransmission timeout
SEQ sequence
SL session layer
SUT system under test
SYN synchronize control flag
SYN-RCVD SYN received
SYN-SENT SYN sent
TCP transmission control protocol
TIME time synchronisation
TL transport layer
UDP user datagram protocol
UT upper tester
5 Conventions
[2]
This document is based on OSI service conventions as specified in ISO/IEC 10731 .
6 CTP test system set-up and CTC structure
6.1 General
This document specifies a CTP according to the requirements as specified in the ISO/IEC 9646 series.
A CTP does not provide qualification of test results but expected responses of the IUT. A CTP is used by
a test house to develop a conformance test specification specific for the test system used in their lab
environment.
The CTCs specified in this document are organized in such a manner as to simplify the identification
of information related to a test and to facilitate in the actual testing process. CTCs are organized into
groups, primarily in order to reduce set-up time in the lab environment. The different groups typically
also tend to focus on specific aspects of device functionality.
A CTC reference name, e.g. "ARP_03 – ARP entry learned on ARP request (no ARP request)" is used to
organize the CTC name, where:
— CTC indicates that this is a conformance test case;
— name/subject of CTC;
— supplemental name, e.g. ARP, which is address resolution protocol;
— CTC number;
— after the hyphen a descriptive name of the CTC follows.
The CTC definitions themselves are intended to provide a high-level description of the purpose,
references, prerequisite, steps/procedures, expected responses, remarks, and methodologies pertinent
to each test (see 6.3).
6.2 Test system set-up
The test system topology follows ISO/IEC 9646-1 and consists of a test set-up which consists of a test
system and a system under test (SUT) connected via the physical medium. The test system implements
a UT and an LT. The UT uses the test control protocol (Figure 2, key 2) to control the LT. The LT supports
the functionality required to test the OSI layer (Figure 2, key 5, key 6, and key 7) of the IUT. The test
system uses IUT-specific set-up parameters (Figure 2, key 1) for testing the communication with the
IUT.
The control and measurement functionality is provided by direct logical access to the service interface
(dashed line) (Figure 2, key 3) and the associated parameters of the OSI layer. The UT in the IUT
(Figure 2, key 4) supports an equivalent part of the abstract service interface (ASPs, PCO) (dashed line)
(Figure 2, key 3) and the associated parameters to control and measure the state(s) of the IUT.
The UT conformance test controller in the test system manipulates the service primitive interface
parameters in the IUT via the ASPs (ETSs) and PCO of the OSI layers to fulfil the purpose of each CTC.
Key
1 set-up parameters (node's electronic data sheet)
2 test control protocol
3 points of control and observation (PCO) and abstract service primitives (ASPs) based on enhanced testability
services (ETS)
4 UT application with ETS interface
5 OSI layer 7 to 5 protocol
6 OSI layer 4 to 3 protocol
7 OSI layer 2 protocol
Figure 2 — Test system set-up
6.3 CTC definition
CTCs are independent of one another. Each CTC checks the behaviour of the IUT for a particular purpose
of this document. CTCs, which require variations of individual parameters, shall be repeated for each
value of the parameter. Each CTC is specified according to a common CTC structure as shown in Table 1.
Table 1 — CTC structure
Item Content
CTC # – Title CTC_x.y.z-a – CTC structure
Purpose The purpose is a brief statement outlining what the test attempts are to achieve. The test is
written at the functional level. It is recommended to begin the description of purpose with "This
CTC verifies …".
Reference The purpose of reference is to specify source material external to the test suite, including any
other references that might be helpful in understanding the test methodology and/or test results.
External sources are always referenced by number when mentioned in the test description. Any
other references not specified by number are stated with respect to the test suite document itself.
[13]
EXAMPLE AUTOSAR SOME/IP Protocol Specification, R20-11, PRS_SOMEIP_00042;
PRS_SOMEIP_00099; …
Prerequisite The purpose of prerequisites is to specify the test hardware and/or software needed to perform
the CTC. This is generally expressed in terms of minimum requirements. In some cases, specific
equipment manufacturer/model information may be provided.
EXAMPLE The IUT is running and offering the enhanced testability service.
Set-up The purpose of set-up is to describe the initial configuration of the test environment. Small
changes in the configuration should not be included here and are generally covered in the test
procedure below.
EXAMPLE The test system set-up shall be in accordance with Figure 3.
Step The test procedure includes the test description, which contains the systematic instructions
for carrying out the test. It provides a cookbook approach to testing and may be interspersed
with observable results. Each test step shall have a numeric number in ascending order.
1. Configure the IUT as master or as slave.
2. Establish a valid link with the IUT.
3. Monitor the transmissions from the IUT and cause the management to request a PMA reset
while simultaneously ceasing transmissions from the test system.
Iteration The purpose of test iterations is to include test procedure definitions, which are repeated more than once.
a) REPEAT step 2 to step 3 with the IUT configured as master, 1 time.
b) REPEAT step 2 to step 3 with the IUT configured as slave, 1 time.
Expected re- The purpose of expected response is to describe the expected results to be examined by the test
sponse system Host-1 in order to verify that the IUT is operating. When multiple values for an observable
are possible, this description provides a short discussion on how to interpret them. The deter-
mination of a pass or fail outcome for a particular test is generally based on the successful (or
unsuccessful) detection of a specific observable.
After iteration a): The IUT stops transmitting with tx_mode = SEND_N and starts
t r a n s m i t t i n g w i t h t x _ mo de = S E N D _ I f or 1 i t er a t ion a) . T he I U T s e t s
link_status = FAIL.
After iteration b): The IUT stops transmitting for 1 iteration b). The IUT sets
link_status = FAIL.
Remark The purpose of remarks is to describe known issues with the test procedure, which can affect
test results in certain situations. It can also refer the reader to test suite annexes and/or white
papers that can provide more detail regarding these issues.
6.4 Terminology used in CTCs
Table 2 specifies the terminology used in CTCs.
Table 2 — Terminology used in CTCs
Name Content
Upper tester (UT) Entity which is responsible for controlling the LT via the test control protocol and the
IUT UT ETS via the abstract service primitives (ASPs).
Lower tester (LT) Entity which is responsible for validating the implementation under test (IUT).
IUT_CONFIGURE This entry causes the IUT to configure/execute various commands for clearing cache,
adding static address, send echo request, etc.
IUT Implementation under test in the SUT.
CLEANUP This is a command, which causes the IUT to remove the static entry from its ARP cache.
6.5 IUT prerequisites – TCP/IP TestStub
6.5.1 General
The TCP/IP TestStub defines interfaces required to test the TCP/IP communication stack functionality.
The protocol parts covered by the TCP/IP TestStub include:
— UDP and TCP – socket connection establishment and termination;
— UDP and TCP – message transmission and reception.

The TCP/IP TestStub is specified in Reference [14] (AUTOSAR). This document references a subset of
the AUTOSAR specification.
6.5.2 TCP/IP TestStub service primitives
Table 3 references AUTOSAR Testability Protocol and Service Primitives, TC Release 1.1.0, '6.10 Service
[14]
Primitives' . A subset of service primitives are supported by the UT to observe and control the TCP/
IP UT TestStub in the IUT.
Table 3 provides an overview of the service primitives, the identifier, applicability and applicability of
UDP and TCP.
Table 3 — TCP/IP TestStub methods (service primitives)
Method name (service primitive) Identifier Applicability UDP TCP
GET_VERSION 1 optional — —
START_TEST 2 mandatory — —
END_TEST 3 mandatory — —
CLOSE_SOCKET 0 — mandatory mandatory
CREATE_AND_BIND 1 — mandatory mandatory
SEND_DATA 2 — mandatory mandatory
RECEIVE_AND_FORWARD 3 — mandatory mandatory
LISTEN_AND_ACCEPT 4 — — mandatory
CONNECT 5 — — mandatory
SHUTDOWN 7 — — optional
Key
— empty cell/undefined
6.5.3 Result codes
Due to different stack implementations there is no generic way to retrieve specific result codes. Only
generic result codes are supported. The generic result codes of the TCP/IP TestStub methods (see
Table 3) are E_OK and E_NOK.
7 Network and transport layers CTCs
7.1 NL – Address resolution protocol (ARP)
7.1.1 General
[8]
The objective of this subclause is to specify CTCs for the ARP from RFC 826:1982 .
7.1.2 Referenced specification
[8]
RFC 826:1982 specifies an Ethernet address resolution protocol. All CTCs in 7.1 are in accordance
with this RFC.
7.1.3 Test system topology – NL – ARP
Figure 3 shows the test system topology – NL – ARP.
Key
1 IUT-specific set-up parameters (electronic data sheet)
2 test control protocol
3 PCO and ASPs based on ETS
4 UT TestStub application
5 OSI layer 3 ARP interaction
Figure 3 — Test system topology – NL – ARP
7.1.4 Test system topology and related CTC configuration
Test system Host-1 configuration required for the tests in the following sections pertaining to ARP
tests.
— Correct IUT MAC address for the IUT interface (IUT-Iface-0) connected to LT interface (LT-Iface-0).
— All CTCs that use an IP interface need to perform ARP packet exchange. This ARP fragment exchange
is performed after the IUT interface is configured with an IP address. Using this fragment exchange
the LT automatically learns the MAC address of IUT. The learned MAC address is then used in the
CTCs to send segments to the IUT.
— All CTCs in this conformance test plan require the IUT to be configured with only one IP interface
(IUT-Iface-0).
7.1.5 CTC ARP overview
Table 4 shows the CTC ARP overview.
Table 4 — CTC ARP overview
Specification document Subclause
Test category Test number (s)
number
RFC 826: an Ethernet address resolution
7.1.7.1 Packet generation CTC_ARP_01 to CTC_ARP_15
protocol, Packet generation
RFC 826: an Ethernet address resolution 7.1.7.2 Packet reception CTC_ARP_16 to CTC_ARP_49
protocol, Packet reception
7.1.6 ARP parameters used in CTCs
7.1.6.1 User defined configuration parameters for IUT
The configuration parameter values are user defined. Table 5 defines the user defined configuration
parameters for IUT.
Table 5 — User defined configuration parameters for IUT
Parameter used in CTCs Content
t
This is the time for which a dynamic entry is present in the ARP cache. This timeout
ARP-Dynamic-Cache-Timeout
is only effective if it has been configured using the script named ARP IUT configure
ARP dynamic cache entry timeout command.
t
ARP-Tolerance This is the tolerance time for the ARP cache of the IUT to get refreshed.
t
This is the tolerance time for the ARP dynamic cache of the IUT to get refreshed.
ARP-Dynamic-Cache-Tolerance
t is specified in Formula (1).
ARP-Dynamic-Cache-Tolerance
t = t t (1)
ARP-Dynamic-Cache-Tolerance ARP-Tolerance + ARP-Dynamic-Cache-Timeout
7.1.6.2 User defined configuration parameters for LT
The configuration set-up parameter values are user defined. Table 6 specifies the user defined
configuration parameters for the LT.
Table 6 — User defined configuration parameters for LT
Parameter used in CTCs Content
Host-1 This denotes ARP Host-1 simulated in the LT.
Host-1-IP This denotes IP address of Host-1.
IUT-Iface-0 This denotes the IUT interface to which the LT Host-1 is connected.
IUT-Iface-0-IP This denotes IP address of IUT-Iface-0.
Param-Listen-Time This is the maximum time interval for which the LT waits for a fragment for
cases when a certain event has been triggered on the IUT either by some
protocol timer or using some external mechanism.
MAC-Addr-1 The first unused MAC address that the LT can use for emulating specific
topologies needed in the CTC.
MAC-Addr-2 The second unused MAC address that the LT can use for emulating specific
topologies needed in test. This is auto generated as consecutive to MAC-Addr-1.
MAC-Addr-3 The third unused MAC address that the LT can use for emulating specific
topologies needed in the CTC. This is auto generated as consecutive to
MAC-Addr-2.
IUT-Iface-0-MAC-Addr This is the MAC address of IUT-Iface-0 of the IUT.
Arbitrary-MAC-Addr This indicates an arbitrary MAC address. This value is equal to 12:34:56:78:90:00.
Table 6 (continued)
Parameter used in CTCs Content
Unknown-ARP-Hardware-Type This indicates an unknown/wrong value of a hardware type resolution
segment.
Unknown-Hardware-Addr-Len This indicates an unknown/wrong length of a hardware address.
Unknown-ARP-Prot-Type This indicates an unknown/wrong value of a protocol type.
Unknown-Prot-Addr-Len This indicates an unknown/wrong length of a protocol address.
t
This value depicts the time variance associated to any wait-event.
ARP-Tolerance
Eth-Addr-Len The length in bytes of the Ethernet MAC address that has the value 6.
Arbit-MAC-Addr This indicates an arbitrary MAC address.
ARP-Hardware-Eth This indicates the ARP hardware type “Ethernet” (0001 ).
MAC-Addr-1 MAC address 1
ARP-Hardware-Type-Unknown This indicates an unknown ARP hardware type.
ARP-Protocol-IP This indicates the ARP protocol type “IP” (0800 ).
ARP-Protocol-Unknown This indicates an unknown ARP protocol type.
IP-First-Unused_Addr-Iface-1 This indicates an IP address that is currently not assigned to the IUT in-
terface IUT-Iface-0.
Operation-Request This indicates the ARP operation code “Request” (0001 ).
Operation-Response This indicates the ARP operation code “Response” (0002 ).
7.1.7 ARP CTCs
7.1.7.1 CTC_ARP – Packet generation
Table 7 specifies the ARP_03 – ARP entry learned on ARP request (no ARP request) test case.
Table 7 — ARP_03 – ARP entry learned on ARP request (no ARP request)
Item Content
CTC # – Title CTC_ARP_03 – ARP entry learned on ARP request (no ARP request)
Purpose This CTC verifies that when the LT sends an ARP request to the IUT, an entry of Host-1-IP, MAC-Ad-
dr-1 gets added to the IUT's ARP cache. When the UT causes the IUT to send a UDP datagram
using the new ARP cache entry, the IUT does not send any ARP request.
[8]
Reference RFC 826:1982, Packet generation
Prerequisite The IUT shall be powered on and shall be linked-up with the test system. The IUT shall implement
the TCP/IP TestStub in accordance with 6.5. The IUT shall be running and the TCP/IP TestStub
shall be active.
Set-up The test system set-up shall be in accordance with Figure 3.
The test system shall be parameterized in accordance with the configuration set-up parameters
as specified in 7.1.6.1 and 7.1.6.2.
Table 7 (continued)
Item Content
Step 1. The UT shall configure the IUT to clear the dynamic entries in the ARP cache of IUT-Iface-0
containing:
— IP address Host-1-IP.
2. The LT shall send the ARP request to the IUT through IUT-Iface-0 containing:
— ARP sender IP address set to Host-1-IP;
— ARP target IP address set to IUT-Iface-0-IP;
— Ethernet source address set to MAC-Addr-1.
3. The LT shall wait t second(s) for the ARP cache of the IUT to get refreshed.
ARP-Tolerance
4. The UT shall configure the IUT to send a UDP datagram from IUT-Iface-0 with:
— ARP sender IP address set to IUT-Iface-0-IP;
— ARP target IP address set to Host-1-IP.
5. The LT shall listen Param-Listen-Time on LT-Iface-0.
Iteration Not applicable
Expected re- After step 5: The IUT shall not send an ARP request.
sponse
Remark —
Table 8 specifies the ARP_04 – ARP entry learned on ARP request (ARP entry used).
Table 8 — ARP_04 – ARP entry learned on ARP request (ARP entry used)
Item Content
CTC # – Title CTC_ARP_04 – ARP entry learned on ARP request (ARP entry used)
Purpose This CTC verifies that when the LT sends an ARP request to the IUT, an entry of Host-1-IP, MAC-Ad-
dr-1 gets added to the IUT's ARP cache. When the UT causes the IUT to send a UDP datagram
using the new ARP cache entry, the IUT sends the expected UDP datagram.
[8]
Reference RFC 826:1982, Packet generation
Prerequisite The IUT shall be powered on and shall be linked-up with the test system. The IUT shall implement
the TCP/IP TestStub in accordance with 6.5. The IUT shall be running and the TCP/IP TestStub
shall be active.
Set-up The test system set-up shall be in accordance with Figure 3.
The test system shall be parameterized in accordance with the configuration set-up parameters
as specified in 7.1.6.1 and 7.1.6.2.
Table 8 (continued)
Item Content
Step 1. The UT shall configure the IUT to clear the dynamic entries in the ARP cache of
IUT-Iface-0 containing:
— IP address Host-1-IP.
2. The LT shall send ARP request to IUT through IUT-Iface-0 containing:
— ARP sender IP address set to Host-1-IP;
— ARP target IP address set to IUT-Iface-0-IP;
— Ethernet source address set to MAC-Addr-1.
3. The LT shall wait up to t second(s) for the ARP cache of IUT to get refreshed.
ARP-Tolerance
4. The UT shall configure the IUT to send a UDP datagram from IUT-Iface-0 with:
— source IP address set to IUT-Iface-0-IP;
— destination IP address set to Host-1-IP.
5. The LT shall listen up to Param-Listen-Time on LT-Iface-0.
Iteration Not applicable
Expected re-
After step 5: The IUT sends the UDP datagram.
sponse
Remark —
Table 9 specifies the ARP_05 – ARP entry learned on gratuitous ARP response (no ARP request).
Table 9 — ARP_05 – ARP entry learned on gratuitous ARP response (no ARP request)
Item Content
CTC # – Title CTC_ARP_05 – ARP entry learned on gratuitous ARP response (no ARP request)
Purpose This CTC verifies that when the LT sends a gratuitous ARP response to the IUT, an entry of Host-
1-IP, MAC-Addr-1 gets added to the IUT's ARP cache. When the UT causes the IUT to send a UDP
datagram using the new ARP cache entry, the IUT does not send any ARP request.
[8]
Reference RFC 826:1982, Packet generation
Prerequisite The IUT shall be powered on and shall be linked-up with the test system. The IUT shall implement
the TCP/IP TestStub in accordance with 6.5. The IUT shall be running and the TCP/IP TestStub
shall be active.
Set-up The test system set-up shall be in accordance with Figure 3.
The test system shall be parameterized in accordance with the configuration set-up parameters
as specified in 7.1.6.1 and 7.1.6.2.
Table 9 (continued)
Item Content
Step 1. The UT shal
...