|
|
楼主 |
发表于 2005-1-27 11:03:00
|
显示全部楼层
因为这个是我为了学习，自己翻译的，我不能担保翻译的准确，如果要学iSCSI的协议，建议还是看英文的RFC。
先传第五章吧。
5. 登录和全功过程中的交涉
iSCSI参数的交涉可以发生在两个过程：可以在会话或连接建立时通过登录请求和响应来交涉；也可以在全功过程中通过文本请求和响应。双方的交涉在这两个过程交换的都是一对iSCSI-text-key=value文本。在本文中，我们把iSCSI-text-key简称为key。
key可以是一个值的声明，也可以是对值的请求交涉值，从它的具体表述隐示可以看出它是这两种中的哪一种。
对于用于声明的key，声明的一方为key设定一个值。该key的使用说明里介绍了哪些key可以为initiator所声明，而哪些可以为target所声明，或者是双方都可以声明。
对于请求交涉的key，请求方在key=value中给出一个key的值，key=value可以在登录或文本请求或响应里的数据部分中给出。另外的一方，决定是否使用该给定的值，或是否使用给定的值的中的一个，并把该值放于登录或文本请求或响应PDU中的key=value中。对于大多数的key来说，initiator和target都可以是交涉请求的发起者。
登录的过程分两个阶段 － 安全交涉阶段和操作参数交涉阶段。这两个阶段都是可选的，但至少有要有一个阶段，用以设置一些必须的参数。
如果有安全交涉阶段，它必须发生在操作参数交涉阶段之前。
从一个阶段进入下一阶段是由登录请求/响应PDU包头里的T(Transition)位来控制的。
initiator通过把T位设为1,表明它希望传输。Target在准备好后同意传输（并选择下一阶段）。在Login PDU包头中的一个字段将表示连接的当前阶段（CSG），另一字段用于表明请求进入的下一阶段（NSG），这一阶段将交由target选择是否进入。
文本交涉过程用于交涉和声明操作参数。交涉过程用PDU中的F (final) 位来控制。在文本交涉过程
中，initiator用F位来标识它已经准备好结束交涉，target以F位来默许交涉的结束。
由于某些key=value可能在单个PDU里装不下，在这种情况下，可以用C (continuation)位来标明还
有后继的PDU。
文本交涉过程中增加了一种机制，用来让target传送更多的数据给initiator。Target Task Tag，由
target发给initiator，并从initiator返回给target，如同一个书签，意为“继续”。如果重置为一个
“neutral value”，则表示“不用管后面的包”。
本章细述了各种key和数值，参数格式的文法规则，以及用于交涉不同类型参数的机制。
5.1. 文本格式
Initiator和target发送的是一系列用UTF-8 Unicode编码的key=value对。所有key都使用在本文档标
识的文本key和文本数值的表示方式，而且是大小写敏感的。
本文档中使用的下列的字符，用于构成文本项（十六进制数值表示Unicode编码）：
(a-z, A-Z) - 字母
(0-9) - 数字
" " (0x20) - 空格
"." (0x2e) - 点
"-" (0x2d) - 减号
"+" (0x2b) - 加号
"@" (0x40) - commercial at
"_" (0x5f) - 下划线
"=" (0x3d) - 等号
":" (0x3a) - 冒号
"/" (0x2f) - solidus or slash
"[" (0x5b) - 左中括号
"]" (0x5d) - 右中括号
null (0x00) - null separator
"," (0x2c) - 逗号
"~" (0x7e) - tilde
key=value配对可以存在于PDU整个范围内。如把文本或登录的请求或响应里的C位设为1，意味着initiator
或target将在一个PDU内传送部分的key=value配对，并在后续的PDU里继续传送。一系列承载数据片断
的PDU中的C位，除在最后一个PDU中设为0，其它均设为1。如果由单个PDU传送完整的key=value配对，
则C位设为0，表示该PDU为一个logical-text-data-segment (LTDS)。
包括在LTDS中最后或唯一的的每一对key=value，必须以一个空字符 (0x00)结束。
key名是在第一个"="的前面的任何字符串。术语key将在本文档中代表key-name。
数值是在第一个"="号后面的任何字符串，不包括结束符null。
下面的定义将被用于本文档的余下部分：
standard-label: A string of one or more characters that consist of
letters, digits, dot, minus, plus, commercial at, or underscore.
A standard-label MUST begin with a capital letter and must not
exceed 63 characters.
key-name: A standard-label.
text-value: A string of zero or more characters that consist of
letters, digits, dot, minus, plus, commercial at, underscore,
slash, left bracket, right bracket, or colon.
iSCSI-name-value: A string of one or more characters that consist
of minus, dot, colon, or any character allowed by the output of
the iSCSI string-prep template as specified in [RFC3722] (see
also Section 3.2.6.2 iSCSI Name Encoding).
iSCSI-local-name-value: A UTF-8 string; no null characters are
allowed in the string. This encoding is to be used for localized
(internationalized) aliases.
boolean-value: The string "Yes" or "No".
hex-constant: A hexadecimal constant encoded as a string that
starts with "0x" or "0X" followed by one or more digits or the
letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex-constants are
used to encode numerical values or binary strings. When used to
encode numerical values, the excessive use of leading 0 digits is
discouraged. The string following 0X (or 0x) represents a base16
number that starts with the most significant base16 digit,
followed by all other digits in decreasing order of significance
and ending with the least-significant base16 digit. When used to
encode binary strings, hexadecimal constants have an implicit
byte-length that includes four bits for every hexadecimal digit
of the constant, including leading zeroes. For example, a
hex-constant of n hexadecimal digits has a byte-length of (the
integer part of) (n+1)/2.
decimal-constant: An unsigned decimal number with the digit 0 or a
string of one or more digits that start with a non-zero digit.
Decimal-constants are used to encode numerical values or binary
strings. Decimal constants can only be used to encode binary
strings if the string length is explicitly specified. There is
no implicit length for decimal strings. Decimal-constant MUST
NOT be used for parameter values if the values can be equal or
greater than 2**64 (numerical) or for binary strings that can be
longer than 64 bits.
base64-constant: base64 constant encoded as a string that starts
with "0b" or "0B" followed by 1 or more digits or letters or plus
or slash or equal. The encoding is done according to [RFC2045]
and each character, except equal, represents a base64 digit or a
6-bit binary string. Base64-constants are used to encode
numerical-values or binary strings. When used to encode
numerical values, the excessive use of leading 0 digits (encoded
as A) is discouraged. The string following 0B (or 0b) represents
a base64 number that starts with the most significant base64
digit, followed by all other digits in decreasing order of
significance and ending with the least-significant base64 digit;
the least significant base64 digit may be optionally followed by
pad digits (encoded as equal) that are not considered as part of
the number. When used to encode binary strings, base64-constants
have an implicit
byte-length that includes six bits for every character of the
constant, excluding trailing equals (i.e., a base64-constant of n
base64 characters excluding the trailing equals has a byte-length
of ((the integer part of) (n*3/4)). Correctly encoded base64
strings cannot have n values of 1, 5 ... k*4+1.
numerical-value: An unsigned integer always less than 2**64 encoded
as a decimal-constant or a hex-constant. Unsigned integer
arithmetic applies to numerical-values.
large-numerical-value: An unsigned integer that can be larger than
or equal to 2**64 encoded as a hex constant, or
base64-constant. Unsigned integer arithmetic applies to
large-numeric-values.
numeric-range: Two numerical-values separated by a tilde where the
value to the right of tilde must not be lower than the value to
the left.
regular-binary-value: A binary string not longer than 64 bits
encoded as a decimal constant, hex constant, or base64-constant.
The length of the string is either specified by the key
definition or is the implicit byte-length of the encoded string.
large-binary-value: A binary string longer than 64 bits encoded as
a hex-constant or base64-constant. The length of the string is
either specified by the key definition or is the implicit
byte-length of the encoded string.
binary-value: A regular-binary-value or a large-binary-value.
Operations on binary values are key specific.
simple-value: Text-value, iSCSI-name-value, boolean-value,
numeric-value, a numeric-range, or a binary-value.
list-of-values: A sequence of text-values separated by a comma.
如果没有特殊标明，simple-value的最大长度（指的不是它的编码表示）是
255字节，不包括分隔符（逗号或空字节）。
任何iSCSI target和initiator必须支持在交涉序列中接收至少8192字节的
key=value数据。当提交或接受的认证方法显式要求使用很长的认证项，
initiator和target必须支持至少64k字节的key=value数值(见附录11.1.2 -
简单公钥证书)
5.2. 文本模式的交涉
在登录中或其后的过程里，可以通过交换文本信息来声明或交涉一些会话和
连接参数。
initiator以文本或登录的请求来启动声明或交涉过程，也用同样的方法表示
它准备完成声明交涉过程（通过把文本/登录请求中的F位/T位设为1）。由
于交涉的文本可以存在于整个PDU的范围内，如果文本/登录的请求/响应中的
C位设为了1，则F/T位就不能设为1。
target若收到C位为1的文本/登录的请求/响应，必须以无数据片断
(DataSegmentLength 0)来回答。若initiator收到C位为1的文本/登录的请求
/响应，必须以无数据片断(DataSegmentLength 0)来回答。
除非是为一般或特定key的交涉所要求，target和initiator不应该使用一个没
有数据片断的文本/登录的请求/响应。
声明的格式如下：
声明者-> <key>=<valuex>
一般情况下的文本交涉格式如下：
提出者-> <key>=<valuex>
接受者-> <key>={valuey>|NotUnderstood|Irrelevant|Reject}
由此看出，声明是一个单向的文本交换，而交涉是一个双向交换。
提出者或声明者可以是initiator和target，同样，接受者可以是initiator
也可以是target。Target在响应initiator给出的key=value配对时没有限制，
Target可以提出自己的key=value配对。
所有的交涉都是显式的（即，结果必须基于交换或声明的数值）。没有隐式
的提交方式。保守的设计同样要求默认数值不应当让后继的有严重影响的数
值对其有依赖性。
提交和定义的数值可以是数字值，用分隔于"~"的上限和下限定义的数字值的
范围，二进制值，文本，iSCSI-name-value，iSCSI-local-name-value，
boolean-value (Yes or NO)，或一系列用逗号分隔开的文本。范围，
large-numerical-value，iSCSI-name-value以及iSCSI-local-name-value只
有在显式同意的情况下才可以使用。
如果指定的key和当前的交涉无关，接受者可以用常量"Irrelevant"回应所有
的交涉。然而，回应"Irrelevant"并不代表交涉失败。回应"Irrelevant"说
明接受者选择的key与提交者提供的一系列的key无关。下面的例子演示了一
个使用"Irrelevant"的情形：
I->T OFMarker=Yes,OFMarkInt=2048~8192
T->I OFMarker=No,OFMarkInt=Irrelevant
I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
T->I X#vkey1=None,X#vkey2=Irrelevant
accept可以忽略任何它不理解的key。对于不理解的key的回应必须是
key=NotUnderstood。
常量"None"，"Reject"， "Irrelevant"，以及"NotUnderstood"为保留使用，
而且只能在本文描述的情形下使用。违犯这一原则将导致协议错误的发生（
如，把"Reject"，"NotUnderstood"， "Irrelevant"用于提交的数值）。
Reject和Irrelevant在允许的情形下是合法的交涉选项，但不建意对他们过度
使用。在接受者回应了key=value配对后，即便回应的数值为"Reject"，
"NotUnderstood"，或"Irrelevant"，交涉都被认为已完成的。重新发送key，
将被认为是重新交涉，这对许多的key来说是不允许的。
如果接受者发出了"Reject"作为回应，key将保持它原来的数值（如果没有设置
过，将被设为默认数值。如果当前数值对于提交者发送时所在的发送时会话和连
接是不能接收到的，提交者可以选择终止该会话或连接。
除了X扩展格式，所有本文中提到的key，都必须被initiator和target所支持，
并用本文档介绍的方法使用。如果在本文档说明的方法下使用这些key，接受方
不可以用"NotUnderstood"回应。
协议的实现者可以用一个"X-"的前缀，后面接上域名，定义新的key。使用IANA
前缀X#也可以用于定义新的key。比如，一个拥有exmaple.com的网络实体可以
发出：
X-com.exmaple.bar.foo.do_something=3
又或者，把一个新注册的key用于：
X#SuperCalyPhraGilistic=Yes
协议的实现者也可以定义新的数值，但新的数值只能用于新的key或认证机制上
（见11节，iSCSI安全文本key和认证机制），或解析（见12.1节，包头解析和
数据解析）。
当参数的动作或接受某个参数时，要依赖于其它的参数，依赖的规则和参数的
次序必须在参数中指明。
在登录过程（见第5.3节，登录过程），每一阶段都是一个独立的交涉。在全功
过程中，一个文本请求响应序列是一个交涉。交涉必须作为原子操作来处理。
比如，在交涉成功达成一致或由于失败而被忽略后，所有的交涉后的数值都必须
开始生效。
某些参数中可能有一致性的规则（如，parameter-x不能超过parameter-y，或
paramter-u不为1表示parameter-v为yes）。如果有这样的需要，一致性的规则
必须在key中表明。必须在所有的参数都可用后（现有的和新交涉出的），才检
查参数是否符合一致性规则。iSCSI target必须在新参数生效前进行一致性检查
。Initiator可以选择进行一致性检查。
iSCSI initiator和target可以在交涉未能在一个合理的时间或次数内结束时，
选择终止该交涉。
5.2.1. 列举交涉
在列举交涉中，发起方发送以优先级为序的一系列的数值（可能包含有"None"）
。
响应方必须以相同的key以及列表中第一个它所支持的（也是指定的发起者同意
的）数值作为响应。
常量"None"必须只用于表示缺失的功能上。而且，"None"只有在发起方提供的列
表中存在时才能被使用。
如果接受方不理解列表中任何一个数值，它必须忽略这个数值。如果接受方不支
持，不理解，或不允许使用提交方列表中的任何一个数值，它可以选择使用常量
"Reject"或结束该交涉。选择一个列表中不存在的数值必须被认为是协议错误。
5.2.2. 简单数值交涉
对于简单数值交涉，接受方必须以相同的key作为回应。接受方选择的数值将作为
交涉的结果。
当一个不允许的数值（如，没有在一个指定的范围内）被提交时，接受方可以
选择以"Reject"常量作为回应，又或者选择一个允许的数值。
当一个接受方选择了不允许的数值，将导致协议错误。选择的规则是针对特定的
key的。
对于数字值的范围，数值的选择必须在提交出的指定的范围内，或是"Reject"（
如果该范围是不可接受的）。
对于布尔值的交涉（即，这些交涉的结果是赋有Yes或No的key），接受方必须回
应以相同的key和交涉的结果，收到的数值并不决定交涉的结果。传回的最终数值
成为交涉的结果。回应数值的选择规则定义在接收到布尔函数中被定义，或是在
给定的数值中作一个选择。
特别地说，在以下两种情形下，回应是可选的：
- 布尔函数为"AND"且返回的数值为"No"，交涉的结果为"No"。
- 布尔函数为"OR"且返回的数值为"Yes"，交涉的结果为"Yes"。
所有情形下，响应都是必须的，接受方选择并发回的数值将作为交涉的结果。
5.3. 登录过程
登录过程在initiator和target之间建立一个iSCSI连接；同时建立一个新的会话
，或把接连维系到一个已有的会话。登录过程设置iSCSI协议参数，安全参数，同
时在initiator和target之间相互认证。
登录过程只通过登录请求和响应来实现。整个的登录过程被认为是单个的任务，
并拥有一个独立的Initiator Task Tag（就如有维系的SCSI命令）。
登录中使用默认的MaxRecvDataSegmentLength。
登录过程中，请求和响应的顺序如下：
- 登录初始请求
- 登录部分请求（可选的）
- 更多的登录请求和响应（可选的）
- 登录最终响应（必须的）
任何连接的登录初始请求必须包含InitiatorName key=value配对。第一个连接的
登录初始请求可能包含SessionTyep key=value配对。对于会话中的不是
"Discovery"的连接，登录初始请求必须包含Targetname key=value配对。
登录最终响应接受或拒绝登录请求。
登录过程可以包含安全交涉阶段(SecurityNegotiation stage)和登录操作交涉
(LoginOperationalNegotiation)阶段。这两个阶段都是可选的，但需要至少有其
中的一个阶段。被包含的阶段可以是空的，except for the madatory names。
在登录请求和响应中有一个字段(CSG)表明当前的交涉阶段(SecurityNegotiation
or LoginOperationalNegotiation)。如果在登录过程中两个阶段都有，安全交涉
阶段必须在登录操作阶段之前进行。
有些操作参数可以在登录过程后的文本请求和响应中交涉。
安全交涉必须在登录过程内完成。安全交涉使用的IPsec安全协议在第8章和
[RFC3723]里介绍。iSCSI支持的协议内的安全机制，只包含在登录时的认证过程
中。
在某些环境里，target和initiator不关心对相互的认证。这种情形下，可以过
在登录请求和响应里的认证。
initiator和target可能要交涉iSCSI认证参数。一旦交涉完成，该通道就被认为
是安全的。
大部分的认证key只能在指定的阶段里使用。安全交涉key出现于第11章，登录操
作交涉key出现于第12章。有限的一些key可以在这两个阶段里使用。
任何特定的登录请求和响应属于一个指定的阶段；这决定了请求和响应中允许的
交涉key。如果某个key用于不允许的阶段，将被认为是一个协议错误。
阶段的转换在一个载有T位和相同的CSG码的命令的交换（请求/响应）中进行在
这个交换中，后继的阶段在targer在"next stage"码(NSG)里标明。选择出的NSG
不可以超过initiator声明的数值。initiator可以在它准备好后发出一个转换请
求，但target只有在initiator发出请求后才能对转换给出响应。
在交涉的序列里，一对登录请求/响应的T位对下一对登录请求/响应的T位没有影
响。如果initiator把一对登录请求/响应的T位设为1，但得到T位的响应，可以把
下一个请求的T位设为0。
当initiator请求，target响应的时候，双方都切换到已选择的阶段。
Target不可以提交任何需要另一来自initiator的登录请求的T位为1的参数。
在登录中的阶段转换（包括进入和退出）在下列表格中的情形下才可以发生：
+------------------------------------------------------------------+
|从 开始-> | 安全 | 操作 | 全功 |
| | | | |
| V | | | |
+-----------------------------------------------------------------+
| (开始) | yes | yes | no |
+-----------------------------------------------------------------+
| 安全 | no | yes | yes |
+-----------------------------------------------------------------+
| 操作 | no | no | yes |
+-----------------------------------------------------------------+
接受登录请求的最后响应只可以对于登录请求的一个T位为1的响应，同时，请求和
响应双方都必须通过NSG表示接受下一阶段为全功过程。
Initiator和target都不可以尝试对同一个参数声明或交涉多次，除非对选定的key的
响应显式允许多次声明（如，TargetAddress）。Target和initiator必须能发现其它
不允许的参数进行重定义和重声明。如果这样的尝试被target发现了，target必须给
以予一个拒绝登录的响应（initiator错误）；如果是initiaotr发现了，则必须丢弃该
连接。
5.3.1. 登录过程的开始
登录过程以一个从initiator发往target的登录请求开始。初始的登录请求包括：
-initiator支持的协议版本
-iSCSI initiator名和iSCSI target名
-ISID，TSIH，和连接IDs
-initiator准备进入的交涉阶段。
一个登录过程可以建立一个新的会话，或是将一个连接加入到一个已有的会话中。
在一个给定的iSCSI节点（只由InitiatorName标识出）和一个由iSCSI TargetName和
Target Portal Group Tag定义的的iSCSI target之间，可能的登录结果在下表中定义：
+------------------------------------------------------------------+
|ISID | TSIH | CID | Target action |
+------------------------------------------------------------------+
|new | non-zero | any | 登录失败 |
| | | | ("会话不存在") |
+------------------------------------------------------------------+
|new | zero | any | 初始一个新会话 |
+------------------------------------------------------------------+
|existing | zero | any | 进行会话重申明 |
| | | | (见第5.3.5节) |
+------------------------------------------------------------------+
|existing | non-zero | new | 把一个新连接加入到 |
| | existing | | 会话中 |
+------------------------------------------------------------------+
|existing | non-zero |existing| 进行连接重申明 |
| | existing | | (见第5.3.4节) |
+------------------------------------------------------------------+
|existing | non-zero | any | 登录失败 |
| | new | | ("会话不存在") |
+------------------------------------------------------------------+
"existing"还是"new"，由target判定。
登录请求中还可以选择包含以下内容：
-安全参数
或
-iSCSI操作参数
和/或
-initiator准备进入的两个交涉阶段
target可以用以下的方式回应登录请求：
-带有登录拒绝的登录响应。这是一个发自target的直接拒绝，会导致连接的终止，
并且，如果使请求的连接是会话中的唯一的连接，该会话将被终止。T位，CSG和
NSG字段在这种情况下被保留。
-以登录接受作为登录的最后响应（T位为1，且请求和响应中的NSG皆为
FullFeaturePhase）。响应包含有target支持的协议版本，会话ID，也可能含有
iSCSI操作或安全参数（取决于当前所在的阶段）。
-以登录接受作为登录的部分响应（请求和响应中的NSG不全为FullFeaturePhase）
，这说明将开始一系列的交涉。响应包含有target支持的协议版本，以及安全或
iSCSI参数（在选择不使用安全机制的情形下）。
如果initiator决定放弃安全交涉阶段，它把登录请求中的CSG设为LoginOperational-
Negotiation，同时，target可以用一个登录响应来表明它不想接受没有安全交涉的
连接（见第10.13节，登录响应），并以认证失败的响应来终止连接（见第10.13.5
节，状态类和状态细节）。
如果initiator愿意交涉iSCSI安全，但不愿意作初始参数的提交，同时可以接受没有
iSCSI安全的连接，它发出T位为1，CSG为SecurityNegotiation，NSG为
LoginOperationalNegotiation。如果target也准备忽略安全机制，那么在登录响应中
只包含有TargetPortalGroupTag key（见第12.9节，TargetPortalGroupTag），T位为
1，CSG为SecurityNegotiation，以及NSG为LoginOperationalnegotiation。
如果initiator选择不带iSCSI安全的操作，且所有的操作参数都为默认值，它会发出
这样的一个登录请求：T 位为1 ，CSG为LoginOperationNegotiation，以及NSG为
FullFeaturePhase。如果target也准备忽略安全和完成它的LoginOperationNegotiation
，则登录响应的T位设为1，CSG为LoginOperationNegotiation，下一阶段的NSG为
FullFeaturePhase。
在登录过程中，iSCSI target必须在第一个登录响应PDU中返回
TargetPortalGroupTag key，这在所有给定了TargetName，且响应不为重定向的的
会话中都是允许的（即，第一个登录响应在第一个C位为0的登录请求后发出）。
TargetPortalGroupTag key的值表示服务于登录请求PDU的iSCSI接口组。如果在一
个特定的情形下，要考虑重新配置iSCSI接口组，iSCSI intiator应该使用这个key来
确定它的登录请求已经发给了它想与之通信的target接口组。
5.3.2. iSCSI安全交涉
安全交换设置安全机制，并且在initiator和target进行相互认证。针对交涉过程采用
的认证机制，交换的过程通过使用登录请求和响应中的'key=value'来实施。
intiator用以下方法引导交涉过程：
-intiator在登录请求中发出一个它支持的（认证机制）选项的有序列表。这些选项
以initiator的优先次序排列。initiator也可以发送私有或公有的扩展选项。
-对于initiator指定的选项列表，target必须回复以它所支持且允许的第一个选项，
除非它全都不支持，这种情形下，target应以"Reject"回应（见第5.2节，文本模式
的交涉）。这些参数用UTF8格式编码。要了解安全参数，见第11章。
-当initiator认为它准备好完成安全交涉阶段，就把T位设为1，并把NSG设为它想进
入的下一阶段。target在完成安全keys的交换后，将会在登录响应中把T位设为1，
并把NSG设为它想进入的下一阶段。选择好的下一阶段取决于target的响应。如果
下一阶段为FullFeaturePhase，target必须回应以一个载有TSIH值的登录请求。
如果安全交涉在target端失败了，target必须发出合适的登录响应PDU。如果安全
交涉在initiator处失败了，initiator应当关闭连接。
应当注意，如果initiator支持安全机制但并未准备好引导交涉时(Propose Option)，
则交涉可能由target来引导。
5.3.3. 登录过程中的操作参数交涉
登录过程中的操作参数交涉可能是：
-在第一个登录请求后即开始，如果initiator并没有提交安全/一致性的选项。
-在安全交涉后即开始，如果initiator和target进行了安全交涉。
操作参数交涉可能包含几对登录请求和响应的交换，这些交换由initiator发起和终止
。initiator必须以T位为1来表明它终止交涉的意图；target在最后的响应中把T位设为
1。
如果对于T位为1的登录请求，target以T位为0的响应回复，则如果initiator想切换阶
段，它就应该一直发送T位为1的登录请求（即便是空的请求），直到接收到T位为
1的响应，又或者收到一个要求它把T位设为0的key。
一些会话特定参数只能在会话的第一个连接（如，以一个包含一个值为0的TSIH的
的登录过程）中被指定。- 最先前的登录过程（如果，该会话有最大数量的连接）
会话在至少一个连接为FullFeaturePhase的情形下，为可操作会话。新的或是被替换
的连接只能在该会话为可操作后，才能被加入到该会话。
了解操作参数，见第12章
5.3.4. 连接重申明
连接重申明是这样的一个进程：当initiator以一个ISID-TSIH-CID联合体登录，但对
于target看来，该连接已在活动中，从而造成对于该CID的连接的隐式注销，且重申
明一个新的全功态的iSCSI连接来替换该活动中的连接。因此，连接重申明中的登录
PDU中的TSIH为非0，且CID为变。若旧连接在没有在先前时显式注销，登录请求令
则会令其注销。在只有一个连接的会话中，这可能意味着建立一个新的连接 ，
用于替代并clean up先前旧的连接。当target不支持多个全功态的连接时，也必须在
ErrorRecoveryLevel为2时支持开启第二个连接，在ErroRecoveryLevel小于2时，可
以选择支持开启第二个连接。
如果操作中的ErrorRecoveryLevel为2，连接重申明支持未来的任务重指派。如果操
作中的ErrorRecoveryLevel小于2，连接重申明做旧CID的替代，而不做任务重申明
。在这种情形下，target并不事先通知initiator，对于所有在旧CID的活动的任务，
必须立即被终止。
当initiator尝试连接重申明时，initiator连接状态必须为CLEANUP_WAIT
（第7.1.3节）。
实在地说，重申明是在进行一个新的连接的登录在基础上，对旧连接做隐式的注销
。
5.3.5 会话重申明，关闭，以及超时
会话重申明是当initiator以一个在target眼中为活动中的ISID登录时发生的进程。因
此，相应于ISID的会话的隐式注销和重申明一个替代旧会话的新的iSCSI会话（拥
有相同的ISID）。所有，会话重申明里，登录PDU中的TSIH为0。会话重申明导致
旧会话里所有活动中的任务的立即终止，此过程中，target不会事先通知initiator。
当initiator尝试会话重申明时，initiator会话状态必须为FAILED（见第7.3节，会话
状态表）。
会话的关闭是下述事件之一：
-成功的"会话关闭"注销。
-当会话中没有其它等待cleanup的连接，也没有任务等待重指派时，对于该会话中
最后一个全功态的连接的成功的"连接关闭"注销。
会话超时是在会话中没有任务等待重指派，且最后一个连接状态超时的事件。这使
该会话处于FREE状态（会话状态表中的N6传输？）。
5.3.5.1 连结通知的丢失
当以下任一事件发生之时，iSCSI层给SCSI层提供”I_T nexus loss”的通知：
a) 会话重申明的成功完成。
b) 会话关闭事件。
c) 会话超时事件。
有些SCSI对象清理动作可能由SCSI结点的通知而发生，见附录F。
－ Target中几种事件的清理效果 －。
5.3.6. 会话的延续和失败
会话的延续是这样的一种进程，它标明先前存在的会话将继续在连接重申明中使用，或用
新的CID添加一个连接。这些动作以该会话状态维系于新的传输连接中。
会话失败是这样的一种事件，当全功过程进入CLEANUP_WAIT状态（见第7.2节，initiator和
target的连接清理状态表），或是完成一个成功的恢复注销，因此导致所有活动中的任务
（这些任务在先前曾被维系于连接中）开始等待被重指派。
5.4. 在登录过程之外进行操作参数的交涉
一些操作参数可能在登录过程之外（之后）交涉
在全功阶段中的参数交涉用文本请示和响应来进行。由initiator用同一个initiaotr任务标签发起
和终止，操作参数交涉可以包含多个文本请求/响应的交换。initiator在表明要终止交涉的时候，
必须把F位设为1，而target必须在最后的响应里把F位设为1。
如果对于F位为1的一个文本请求，target给予F位为1的响应，而且initiator还想终止交涉，则
initiator应当一直发送F位为1的文本请求（即便为空），直到它收到F位为1的响应。不主张对
于一个F位为1的请求，用F位为0的空响应（没有key=value对）。
target不能对依赖于其它参数的文本请求回复以F位为1的响应。
在交涉序列中，一对文本请求/响应对中的F位设置与下一对里的F位设置无关。当一个initiator
发出F位为1的请求，收到F位为0的响应后，可能在下一请求里把F位设为0。
当target作出了F位为0的响应，则必须把target传输标签设置为默认值0xffffffff以外的值。
在收到一个载有值不为0xffffffff的target传输标签后，initiator可以发出载有值为0xffffffff的target传输
标签的文本请求来重置一个操作参数交涉。target可以用拒绝PDU来回复文本请求，以重置一
个操作参数交涉。
在插入操作参数交涉的重置之前，initiator和target都不应多次声明或交涉同一参数，除非是响
应一个显式允许多次声明的key（如，TargetAddress）。如果多次声明或交涉同一参数的情形
被target发觉，target必须发出原因码为"protocol error"的拒绝PDU，对于initiator，则用上面介绍
的方法重置交涉。
通过进行一交换交涉系列的参数交涉过程，只有在交涉系列完成后，参数才能生效。 |
|
IP卡
狗仔卡
发表于 2005-1-10 17:06:33
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡