ISO/IEC TR 14165-314:2013 情報技術—ファイバーチャネル—パート314：アビオニクス環境—リモートダイレクトメモリアクセス（FC-AE-RDMA） | ページ 6

3.1 用語と定義

このドキュメントでは、次の用語と定義が適用されます。

3 Terms, definitions, abbreviations and conventions

3.2 Abbreviations and acronyms

Abbreviations and acronyms applicable to this technical report are listed below. Abbreviations and acronyms for commonly used terms defined in referenced standards are not listed here.

3.3 Editorial conventions

3.3.1 Overview

In this technical report, a number of conditions, mechanisms, sequences, parameters, events, states, or similar terms that do not have their normal English meaning are printed with the following conventions.

• • The first letter of each word in uppercase and the rest lowercase (e.g., Exchange, Class, etc.).
• • A term consisting of multiple words, with the first letter of each word in uppercase and the rest lowercase and each word separated from the other by an underscore (_) character. A word may consist of an acronym or abbreviation, which would be printed in uppercase. (e.g., NL_Port, Transfer_Length, etc.).

All terms and words not conforming to the conventions noted above have the normal technical English meanings.

Numbered items in this technical report do not represent any priority. Any priority is explicitly indicated.

In all of the figures, tables and text of this technical report, the most significant bit of a binary quantity is shown on the left side. Exceptions to this convention are indicated in the appropriate clauses.

The term “shall” is used to indicate a mandatory rule. If such a rule is not followed, the results are unpredictable unless indicated otherwise.

The term “should” is used to indicate flexibility of choice with a strongly preferred alternative; equivalent to the phrase “it is strongly recommended”.

The term “may” is used to indicate flexibility of choice with no implied preference; equivalent to “may or may not”.

The fields or control bits that are not applicable shall be set as required by the defining standard or technical specification or technical report.

If a field or a control bit in a frame is specified as not meaningful, the entity that receives the frame shall not check that field or control bit.

In several tables within this report, there is a column on the right side of the table labelled “Notes”. These notes are NORMATIVE and shall be considered requirements of this report.

In the event of conflict between the text, tables and figures in this technical report, the following precedence shall be used: tables (highest), text and figures (lowest).

3.3.2 Binary notation

Binary notation may be used to represent some fields. Single bit fields are represented using the binary values 0 and 1. For multiple bit fields, the binary value is enclosed in single quotation marks followed by the letter b. For example, a four-byte field containing a binary value may be represented as ‘00000000 11111111 10011000 11111010’b.

3.3.3 Hexadecimal notation

Hexadecimal notation may be used to represent some fields. When this is done, the value is enclosed in single quotation marks and preceded by the word hex. For example, a four-byte field containing a binary value of ‘00000000 11111111 10011000 11111010’b is shown in hexadecimal format as hex ’00 FF 98 FA’.

3.3.4 Applicability and use of this technical report

The usual definitions of the following words do not apply. The following definitions shall be read carefully.

Required : If a feature or parameter value is Required, it means that it shall be used between compliant implementations. Compliant implementations are required to implement the feature. Interoperability is not guaranteed if Required features are not implemented. Each Required feature will include a note that describes the condition(s) in which the feature shall be used.

Invocable : If a feature or parameter value is Invocable, it means that it may be used between compliant implementations. Compliant implementations are required to implement the feature. Invocable is different from Required in that an implementation may use the feature if needed, but is not required to use it. No discovery process is necessary prior to use of an Invocable feature.

Allowed : If a feature or parameter value is Allowed, it means that it may be used between compliant implementations. Compliant implementations are not required to implement the feature. Typically, the potential user of an Allowed feature may determine if an implementation supports it via an Invocable discovery process.

Prohibited : If a feature is Prohibited, it means that it shall not be used between compliant implementations. This report does not Prohibit the implementation of features, only their use between compliant implementations. Interoperability is not guaranteed if Prohibited features are used.

Table 1 summarizes the above definitions.

Table 2 and Table A.1 list features described in the various Fibre Channel standards and technical reports. These tables indicate whether the features are Required, Prohibited, Invocable, or Allowed for compliance with this technical report; or whether a parameter is Required to be a particular value for compliance with this report. Features or parameters that are not listed do not affect the interoperability of FC-AE-RDMA devices.

The following legend is used for table entries in Clause 4:

Bibliography