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
Document File: 2 page(s) / 30K

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:

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

OPTIONAL CHECKING IN AN I/O CHANNEL PROTOCOL

  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...