Contingent Allegiance Condition (CAC)

A Contingent Allegiance Condition (CAC) is a SCSI “condition” that exists after there is some kind of problem.  What I usually say during class is “these are big words for ‘Hey – We have an error.’ – or some other kind of problem”.

I often find that if you move the words around, it is easier to understand the concepts from the SCSI standards.  Here is an example:

A Contingent Allegiance Condition is:  a Condition (state) that is Contingent (dependent) upon the Allegiance (connection) between two entities, or components, in a SCSI-based system.

Now for the translation – and I will try to keep it short.  In the universe of Storage Area Networking, which is almost entirely SCSI based, the first thing we have to do to be able to issue a command is to make a connection, between the Initiator, through the Target, and finally to the Logical Unit, or at least the code that represents the Logical Unit.  Making this connection establishes what is called a Nexus – or I_T_L Nexus.  I like to refer to a nexus as a “process ID” – or identifier – for every command within the system.

Since a storage area network, or even a relatively small parallel SCSI system can have multiple initiators, targets, and logical units, it is important to uniquely identify each command, or process, that is sent through the system.  That way, we can keep track of all the commands that have been issued and reconnect them back with the original initiator that issued the command.

So that is where the “Contingent Allegiance” part of a CAC comes in – its all about the Nexus, and the connection that it represents.

Now the “Condition” part is simply a “state” that is not considered “normal”.  You see, when everything works in a SCSI system, the normal “flow” is:

  • Make a connection (establish a Nexus)
  • Issue a command (from initiator to target)
  • Process the command (Target moves data to or from storage, if needed)
  • Receive GOOD status (00h code)
  • Close the connection (Nexus “goes away”)

When something goes wrong, then you do NOT receive GOOD status – you most often get back a CHECK CONDITION status (02h code) from the target.  This is how the initiator is informed that an error occurred.

The other part you are supposed to know is that the target has generated some sense data, which will explain why the error occurred.  And this is where the CAC and Nexus part comes in – the target is supposed to keep the sense information based on the nexus, and that particular command.

What clears this Contingent Allegiance Condition? Normally it is when the same initiator issues another command to that same target and logical unit (remember – its all about the nexus).  Usually, the next command is a REQUEST SENSE command, which retrieves the sense data from the device, and it can be decoded by the initiator.  Based on this sense data, the initiator should take the appropriate recovery action.  What action will the initiator take?  The answer is – it depends.  It depends on the content of the sense data.

Please let me know if you have any questions or comments.

Incoming search terms for the article: