In any layered communication protocol, all the layers above physical layer will utilize some form of protocol data units to accomplish the protocol defined. Here for the simplicity, referring all the protocol data units as transactions.

Physical layer error injection requires a different thought process and will be covered in another blog. Following will focus on the higher layers transaction field error injection.

Transaction field error injection for higher layers of communication protocol will have to cover following.

Field error injection

Typically transactions are made up multiple fields. All the fields even including the reserved fields can be corrupted.

Fields are of two categories. One is the transaction type and second is supporting fields specific to transaction type. Transaction type identifies the functionality of the specific transaction and supporting fields provide the additional information specific to this transaction type.

For all the fields,  legal corruption range should be identified and it should be covered. For example a sequence number field in packet should be capable of being corrupted with the sequence numbers for which acknowledgement is awaited or unused sequence numbers of future.

One interesting question that comes up is, Should the transaction type be corrupted with the other valid transaction types? Answer is NO. This can lead to lots of scenarios that are not valid. Transaction type corruption should be dealt as sequence corruption described below.

Sequence error injection

Set of transaction exchanges forms the protocol. There are pre-defined legal sequences of the exchanging the transactions. Now any violation in this pre-defined sequence leads to sequence corruption.

Sequence corruptions have to be carefully thought out. These are not directly due to imperfection in physical line but result of an indirect effect of that.

Following are some such examples:

• A lost transaction can make receiver see the next transaction and thus experience a sequence corruption.
• Legal transaction following a corrupted transaction
• Peers going out of synchronization can result in scenarios appearing as sequence corruptions.

Again the point to keep in mind is that error handling covers the physical line imperfections. Imperfections in the real operating environments out of our control and not the design implementation mistakes which are under control.

Note that transaction corruptions have to be exercised on both the directions of the bi-directional interface.