Browse Prior Art Database

OPTIONAL CHECKING IN AN I/O CHANNEL PROTOCOL

IP.com Disclosure Number: IPCOM000014008D
Original Publication Date: 2000-Nov-20
Included in the Prior Art Database: 2003-Jun-19

Publishing Venue

IBM

Abstract

An new I/O protocol could require a CRC to protect the payloads from corruption when going across internal busses and adapter cards which do not have complete checking; this CRC would have to be generated by the sender and checked by the receiver. With such a capability, total protection of the payload within a box would exist, since the other parts of the system involved in creating the payload are already checked. Protection of the payload during transmission over the Fibre Channel link uses a separate CRC on the link, as defined by the standard. However, there are some implementations where providing the additional protection when going across internal busses, adapter cards, and processors which are not fully checked would be extremely difficult and costly, and could cause delays in delivering a product. Furthermore, if the attached box already uses many inadequately checked engines, the additional checking when going across some internal busses, adapter cards, and engines may provide negligible additional value since it is only checking one of many places where data may be corrupted. By making the additional protection data optional for both senders and receivers, the rate of delivery of products supporting the new protocol is maximized while minimizing costs. Making this optional leaves the decision to the product owner as to whether their product should support the additional protection data, based on the product's usage, characteristics, and competitive situation. This defines a way of adding optionality to the protocols for both the generation of the protection data and the checking of the protection data, but without requiring configuration data to be provided to either side to indicate how the other one behaves. Furthermore, the protocols permit independent decisions about the generation vs. the checking of data, e.g., an implementation can generate protection data without checking, or vice versa. A sender can choose to always generate the protection data, without requiring awareness of whether the receiver checks this data or whether the receiver will provide such protection data. Thus, a sender does not require configuration information about the behavior of each potential receiver, which reduces development cost and avoids mainline code to determine whether it should provide protection data when communicating with a specific receiver. Similarly, a receiver can choose to never check protection data without configuration information about whether any particular sender provides protection data. There are 4 cases: sender always generates protection data, sender is capable of checking protection data it receives sender always generates protection data, sender never checks protection data it receives receiver never checks protection data it receives, always generates protection data it sends