|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FC Encapsulation WG Last Call commentsComments flagged with [E] for editorial, [T] for technical. ----- FC Encapsulation -06 ----- -- Section 1 - Scope The organization responsible for the Fibre Channel standards (NCITS Technical Committee T11) has determined that some functions and modes of operation are not interoperable to the degree required by the IETF. This draft includes applicable T11 interoperability determinations in the form of restrictions on the use of this encapsulation mechanism. [E] Is there an official citation for this statement? It really needs one to be published in an archival unchangeable format such as an RFC. -- Section 2 - Encapsulation Concepts FC frames have several possible lengths. [E] Should read "variable length" or something like that - this implies several possible choices of fixed length, which is incorrect. To facilitate transporting FC frames over TCP the native FC frame needs to be contained in (encapsulated in) a slightly larger structure as shown in figure 1. [E] The use of TCP in this context is overly restrictive. This encapsulation is in principle applicable to any means of transport over IP, including TCP, SCTP, UDP, and carrier pigeon ;-), even though in practice all the initial uses will use TCP. The format and content of an FC frame is described in the FC [E] "is" --> "are" -- Section 3 - The FC Encapsulation Header -- Section 3.1 - FC Encapsulation Header Format The values in the Protocol# field are assigned by IANA [8]. The following values are known to be in use: - FCIP -- TO BE ASSIGNED by IANA - iFCP -- TO BE ASSIGNED by IANA [T] Delete the text starting with "The following values" and insert a forward reference to the IANA Consideration section. FC Encapsulation receivers may compare the Protocol# and -Protocol# fields as an additional verification that an FC Encapsulation Header is being processed. FC Encapsulation receivers may compare the Version and -Version fields as an additional verification that an FC Encapsulation Header is being processed. [T] Those "may"s are misleading. I think "SHOULD" is appropriate, but I could accept "SHOULD"s that only applied when the CRC is not valid. Flags (bits 31-26 in word 3): The Flags bits provide information about the usage of the FC Encapsulation Header as shown in figure 3. Note: Implementers are advised to consult the specifications of protocols that use this header to determine how each individual protocol uses the bits in the Flags field. [T] The "Note:" paragraph is part of the CRCV issue (see below), and probably needs to be deleted as part of resolving that issue. This paragraph also has the additional problem in that it implies that protocol specific uses of the reserved flags are allowed, which is not the case. Reserved (Flags, bits 31-27 in word 3): These bits are reserved for use by future versions of the FC Encapsulation and SHALL be set to zero on send. Protocols employing this encapsulation MAY require checking for zero on receive, however doing so has the potential to create incompatibilities with future versions of this encapsulation. [E] Second sentence is poorly worded. Suggested rewrite: Protocols employing this encapsulation SHOULD ignore the Reserved bits on receive in order to avoid creating incompatibilities with possible future versions of this encapsulation. I believe this change is editorial, and it also applies to the -Flags and -Frame Length fields. CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one indicates that the contents of the CRC field are valid. A CRCV bit value of zero indicates that CRC are invalid. Some protocols may always check the CRC without regard for the state of this bit. The value of the CRCV bit SHALL be constant for all FC Encapsulation Headers sent on a given TCP connection. [T] The "Some protocols may always check the CRC ..." is the CRCV issue that Mallikarjun also found and that has been problematic in the past. I believe that what's going on here is that all protocols have to check the Protocol#, and once that's been checked, the implementation knows whether there's supposed to be a CRC there and hence doesn't need to look at CRCV. In practice this won't cause problems, as including the CRC when it's not supposed to be there is harmless, and failing to include it when it should be there will almost certainly cause a CRC check failure. I offer a proposal to resolve this by expanding the Protocol # registry that IANA will create so that each registered protocol must supply not only its name and an RFC reference, but also whether the protocol uses (Yes) or does not use (No) the CRC in this header. The above text could then be revised to make the CRCV check at the receiver OPTIONAL in all cases because its value can be inferred from the protocol#. [E] Also need to generalize away from TCP connection to allow possible future use with other transports. [T] Here or in the description of the Protocol Specific fields, a warning to implementers is needed says some sort of error checking redundancy (e.g., the ones complements found elsewhere in the header) SHOULD (or MUST) be used when the CRC is not used. This warning should be duplicated in Section 3.2.1. This is a technical comment, but should not be controversial. Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The two Time Stamp fields contain time at which the FC Encapsulated frame was sent as known to the sender. The format of integer and fraction Time Stamp word values is specified in Simple Network Time Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp [integer] and Time Stamp [fraction] words SHALL be set as described in section 4. [E] For convenience, it might be good to summarize those formats here with an indication that [9] is the normative authority. I don't feel strongly about this, though. [T] We have a problem here - RFC 2030 is Informational, and hence can't be referenced in a normative fashion from a standards track document. I'll talk to Ralph offline about how to get around this. CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL contain zero. When the CRCV Flag bit is one, the CRC field SHALL contain a CRC for words 0 to 5 of the FC Encapsulation Header computed using the polynomial, initial value, and bit order defined for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order of the resulting CRC corresponds to that of FC-1 layer. The CRC transmitted over the IP network shall correspond to the equivalent value converted to FC-2 format as specified in FC-FS. [E] I realize that FC-FS is the latest and greatest version of the FC frame standard, BUT, referencing a project in progress for this sort of basic CRC mechanism is an invitation to procedural problems. Can this reference be changed to FC-PH accompanied by a note that FC-FS is supplanting FC-PH, but will make *no* changes in this area? Note that I'm comfortable with the earlier reference to FC-FS for frame contents. -- Section 3.2.1 [T] The warning that the protocol-specific fields SHOULD (or MUST) be protected by redundancy needs to go here. Redundancy based header validation can be built from simple logic (e.g., XORs and comparisons). Header validation based on redundancy also is a step wise process in that the first word is validated, then the second, then the third and so on. A decision that a candidate header is not valid may be reached before the complete header is available. [E] First sentence is superfluous and probably should be deleted as it's rather hardware-oriented. -- Section 3.2.2 CRC based header validation employs a straight forward algorithm (e.g., compute the CRC for all bytes preceding the CRC word and compare the results to the CRC word's contents). The number of comparisons required to perform CRC validation is exactly one and the method for computing the CRC is well known with proven implementations. [E] Last sentence is superfluous and probably should be deleted as it's rather hardware-oriented. -- Section 4 - Measuring Fibre Channel frame transit time To comply with FC-FS [3], an FC Fabric must specify and limit the lifetime of a frame. [E] Same comment as before about referencing FC-FS. Can this be changed to reference FC-PH with a note that FC-FS won't change this ... or is FC-FS tinkering with things here? When originating an encapsulated frame, an entity that does not support transit time calculation SHALL always set the Time Stamp [integer] and Time Stamp [fraction] fields to zero. When receiving an encapsulated frame, an entity that does not support transit time calculation SHALL ignore the contents of the Time Stamp words. The protocol SHALL specify whether or not implementation support is required. [T] This is about "MUST/SHOULD/MAY implement". Need a similar requirement on the protocol to specify "MUST/SHOULD/MAY use" and under what conditions. The policy for processing frames while in the Unsynchronized state SHALL be defined by the protocol specification, including whether or not the entity may continue to send and receive frames from the IP network. [T] On the receive side, this condition appears to be specified in the wrong direction. Receiving frames from the IP network cannot possibly cause problems, the issues are in forwarding (stale) frames into FC. When de-encapsulating a frame, an entity in the Synchronized state SHALL: [E] While the sub-bullets are correct, they leave a reader unfamiliar with FC somewhat high and dry. I would include a "for example" in both a) and b), along the lines of: a) For example, if a calculated transit time exceeds a value that could cause the frame to violate FC maximum time in transit limits (Time Out Values), the protocol may specify that the frame is to be discarded. b) For example, a protocol may specify that frames for which transit time cannot be determined are never to be forwarded over FC. [T] At the end of this section, it would be good to warn protocol designers that well-designed protocols are unlikely to accomplish useful communication when the communicating entities are in different states, and hence protocol designers need to consider how to coordinate state transitions, especially the Unsynchronized to Synchronized transition on startup and an unexpected Synchronized to Unsynchronized transition (e.g., caused by loss of contact with an external time service). This is related to some issues that Mallikarjun found. -- Section 5 - The FC frame -- Section 5.1 - FC frame content As shown in figure 4, the FC frame content is defined as the data between the EOF and SOF delimiters (including the FC CRC) after conversion from FC-1 to FC-2 format as specified by FC-FS [3]. [E] This needs some more explanation. The important things that need to be said are: - FC uses the same 8b/10b encoding as Gigabit Ethernet in which each 8 bit byte is transmitted using 10 bits on the wire for reasons that include redundancy and low level timing synchronization between sender and receiver. - All discussion of FC frame content in this draft is at the 8b level prior to 8b->10b expansion on send or after 10b->8b reduction on receive. The Gigabit Ethernet reference is particularly important in increasing accessibility of this document to a network-savvy, but new to FC audience. -- Section 5.3 - FC SOF and EOF The FC frame content is composed of 8-bit bytes that can be translated directly for transmission over TCP. The FC SOF and EOF [3] require 8b/10b special characters that cannot be translated directly to 8-bit bytes, encoded values are required. [E] I think this paragraph needs to be moved to Section 5.1, and replaced with a sentence here that refers back to it. One important editorial change is "8b/10b special characters that cannot be translated directly to 8-bit bytes" should be changed to "10b special characters that have no 8b equivalents" or something like that. SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain the encoded SOF value selected from table 1. [T] As we've learned from the Class 4 adventure, this table is subject to change/extension. IANA will need to manage it, and will need some sort of allocation guidelines to remain consistent with whatever mechanism produced this peculiar set of values. While we probably don't want to allow value recycling, we may want to write some text dealing with retiring values (making them no longer usable). This also applies to the EOF values in Table 2. Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies these codes as not interoperable, so they are not listed in this specification. [T] There are a couple of problems here. If FC-BB-2 has assigned values to SOF and EOF encodings that MUST NOT be used with FCIP, then we need to instruct IANA to reserve and not allocate those values. As part of allocating future values in this table, we need to (1) instruct the author(s) of the draft/RFC doing the allocation to ensure that T11.3 review of the proposed allocation is obtained (2) that the IPS WG chair(s) (if the IPS WG still exists) and the Transport ADs are informed of this review, and (3) that IANA allocates the values approved by T11.3 as opposed to choosing values. Since Murali's been appointed as T11's official liaison to IETF, I think it's his responsibility to suggest a coordination process. -- Section 7 - Normative References I would really like to remove the normative reference to FC-FS, substituting FC-PH with a note that FC-FS will replace FC-PH. I don't object to an FC-FS reference where it's really needed, but the portions of FC-FS that this draft relies on are sufficiently basic and stable that an FC-PH reference will make their stability clear. The FC-BB-2 and FC-MI references for SOF and EOF codes need to become non-normative as part of setting up the IANA registry and management process. The FC-SW-2 reference may not need to be normative here. RFC 1700 is almost certainly the wrong reference to instruct IANA on what procedures to follow. See RFC 2434 for guidance on this topic, although it may not be necessary to reference it. -- ANNEX A - Protocol Requirements [E] I think this should be an Appendix, rather than an Annex. Some changes may be in order here based on the above comments. -- ANNEX B - IANA Considerations [T] This needs to be made somewhat more explicit and direct. IANA is looking for simple straightforward instructions roughly of the form "IANA is instructed to do <X>". in particular, the following sentence is a problem: Standards action on this RFC should be accompanied by IANA assignment of the following two Protocol# values: It should read something like: In addition to creating the FC Encapsulation Protocol Number Registry, the standards action of this RFC allocates the following two values from this registry: While one normally asks IANA to allocate values, the exception is that when creating a registry, one can instruct IANA as to what the initial contents are (i.e., a new registry does not have to be created empty). [T] Also, earlier comments suggest that the Protocol# registry needs to be expanded with a CRC field (Yes/No) and that registries need to be created for the SOF and EOF values. It is requested that the ips working group chairs or the Transport Services area directors be notified when any new Protocol# value assignment is requested. [T] Given that an approved RFC is required, this sentence seems redundant. If the intent was notification of the IPS WG chairs and/or ADs when a an I-D draft is submitted that will cause a Protocol# assignment if/when approved as an RFC, the language needs to say that and should be rephrased to require notification of the IP Storage WG chairs (don't use WG acronyms here) and notification of the Transport ADs instead in the case that the IPS WG does not exist or is not active. [T] Also see previous comments about needing to set up an IANA registry for SOF and EOF values. I'll work with Ralph on crafting the right IANA instructions. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Mon Mar 18 19:18:14 2002 9191 messages in chronological order |