idnits 2.17.1 draft-ietf-ips-fcencapsulation-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: standards-track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Seconds' on line 394 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2469 (ref. '7') -- Obsolete informational reference (is this intentional?): RFC 2030 (ref. '9') (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '10') (Obsoleted by RFC 5226) -- No information found for draft-ietf-ips-fcovertcpip-__ - is the name correct? -- No information found for draft-ietf-ips-ifcp-__ - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group R. Weber 3 INTERNET-DRAFT Brocade 4 5 (Expires November, 2002) M. Rajagopal 6 Category: standards-track LightSand Communications 8 F. Travostino 9 Nortel Networks 10 FC Frame Encapsulation 11 M. O'Donnell 12 McDATA 14 C. Monia 15 Nishan Systems 17 M. Merhar 18 Pirus Networks 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC 2026 [1]. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as Reference 32 material or to cite them other than as "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/lid-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on November 8, 2002. 42 Abstract 44 This is the ips (IP Storage) working group draft describing the 45 common Fibre Channel frame encapsulation format and a procedure for 46 the measurement and calculation of frame transit time through the IP 47 network. This specification is intended for use by any IETF protocol 48 that encapsulates Fibre Channel (FC) frames. This draft describes a 49 frame header containing information mandated for encapsulating, 50 transmitting, de-encapsulating, and calculating the transit times of 51 FC frames. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [2]. 59 Table Of Contents 61 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . . 3 63 3. The FC Encapsulation Header . . . . . . . . . . . . . . . . . . 4 64 3.1 FC Encapsulation Header Format . . . . . . . . . . . . . . . . 4 65 3.2 FC Encapsulation Header Validation . . . . . . . . . . . . . . 7 66 3.2.1 Redundancy Based FC Encapsulation Header Validation . . . . . 7 67 3.2.2 CRC Based FC Encapsulation Header Validation . . . . . . . . 7 68 4. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . . 8 69 5. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1 FC Frame Content . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 10 72 5.3 FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 8. Informative References . . . . . . . . . . . . . . . . . . . . 13 76 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 80 Appendix 81 A Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15 82 B Encapsulating Protocol Requirements . . . . . . . . . . . . . . 16 83 C IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 85 Warning to Readers Familiar With Fibre Channel: Both Fibre 86 Channel and IETF standards use the same byte transmission order. 87 However, the bit and byte numbering is different. See appendix A 88 for guidance. 90 1. Scope 92 This document describes common mechanisms for the transport 93 of Fibre Channel frames over an IP network, including the 94 encapsulation format and a mechanism for enforcing the Fibre 95 Channel frame lifetime limits. 97 The organization responsible for the Fibre Channel standards (INCITS 98 Technical Committee T11) has determined that some functions and 99 modes of operation are not interoperable to the degree required 100 by the IETF (see FC-MI [8]). This draft includes applicable T11 101 interoperability determinations in the form of restrictions on the 102 use of this encapsulation mechanism. 104 Use of these mechanisms in an encapsulating protocol requires an 105 additional document to specify the encapsulating protocol specific 106 functionality and appropriate security considerations. Because 107 security considerations for this encapsulation depend on how it is 108 used by encapsulating protocols, they are taken up in encapsulating 109 protocol specific documents. 111 2. Encapsulation Concepts 113 The smallest unit of data transmission and routing in Fibre Channel 114 (FC) is the frame. FC frames include a Start Of Frame (SOF), End Of 115 Frame (EOF), and the contents of the Fibre Channel frame. The 116 Fibre Channel frame includes a Cyclic Redundancy Check (CRC) code 117 that provides error detection for the contents of the frame. FC 118 frames are variable length. To facilitate transporting FC frames 119 over an IP based transport such as TCP the native FC frame needs 120 to be contained in (encapsulated in) a slightly larger structure 121 as shown in figure 1. 123 +--------------------+ 124 | Header | 125 +--------------------+-----+ 126 | SOF | f | 127 +--------------------+ F r | 128 | FC frame content | C a | 129 +--------------------+ m | 130 | EOF | e | 131 +--------------------+-----+ 133 Fig. 1 - FC frame Encapsulation 135 The format and content of an FC frame are described in the FC 136 standards (e.g., FC-FS [3], FC-SW-2 [4], and FC-PI [5]). Of 137 importance to this encapsulation is the FC requirement that all 138 frames SHALL contain a CRC for detection of transmission errors. 140 3. The FC Encapsulation Header 142 3.1 FC Encapsulation Header Format 144 Figure 2 shows the format of the required FC Encapsulation Header. 146 W|------------------------------Bit------------------------------| 147 o| | 148 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| 149 d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| 150 +---------------+---------------+---------------+---------------+ 151 0| Protocol# | Version | -Protocol# | -Version | 152 +---------------+---------------+---------------+---------------+ 153 1| | 154 +----- Encapsulating Protocol Specific ----+ 155 2| | 156 +-----------+-------------------+-----------+-------------------+ 157 3| Flags | Frame Length | -Flags | -Frame Length | 158 +-----------+-------------------+-----------+-------------------+ 159 4| Time Stamp [Seconds] | 160 +---------------------------------------------------------------+ 161 5| Time Stamp [Seconds Fraction] | 162 +---------------------------------------------------------------+ 163 6| CRC | 164 +---------------------------------------------------------------+ 166 Fig. 2 - FC Encapsulation Header Format 168 The fields in the FC Encapsulation Header are defined as follows. 170 Protocol#: The Protocol# field SHALL contain a number that indicates 171 which encapsulating protocol is employing the FC Encapsulation. 172 The values in the Protocol# field are assigned by IANA (see 173 appendix C). 175 Version: The Version field SHALL contain 0x01 to indicate that this 176 version of the FC Encapsulation is being used. All other values are 177 reserved for future versions of the FC Encapsulation. 179 -Protocol#: The -Protocol# field SHALL contain the one's complement 180 of the contents of the Protocol# field. FC Encapsulation receivers 181 SHOULD either validate the CRC or compare the Protocol# and - 182 Protocol# fields to verify that an FC Encapsulation Header is 183 being processed according to a policy defined by the encapsulating 184 protocol. 186 -Version: The -Version field SHALL contain the one's complement of 187 the contents of the Version field. FC Encapsulation receivers SHOULD 188 either validate the CRC or compare the Version and -Version fields 189 to verify that an FC Encapsulation Header is being processed 190 according to a policy defined by the encapsulating protocol. 192 Encapsulating Protocol Specific: The usage of these words differs 193 based on the contents of the Protocol# field, i.e., the usage of 194 these words is defined by the encapsulating protocol that is 195 employing this encapsulation. 197 Flags: The Flags bits provide information about the usage of the 198 FC Encapsulation Header as shown in figure 3. 200 |------------------------Bit--------------------------| 201 | | 202 | 0 1 2 3 4 5 | 203 +--------------------------------------------+--------+ 204 | Reserved | CRCV | 205 +--------------------------------------------+--------+ 207 Fig. 3 - Flags Field Format 209 Reserved Flags bits: These bits are reserved for use by future 210 versions of the FC Encapsulation and SHALL be set to zero on send. 211 Encapsulating protocols employing the encapsulation described in 212 this specification MAY require checking for zero on receive, however 213 doing so has the potential to create incompatibilities with future 214 versions of this encapsulation. Changes in the usage of the Reserved 215 Flags bits MUST be identified by changes in the contents of the 216 Version field. Encapsulating protocols employing the encapsulation 217 described in this specification MUST NOT make use of the Reserved 218 Flags bits in any fashion other than that described in this 219 specification. 221 CRCV (CRC Valid Flag): A CRCV bit value of one indicates that 222 the contents of the CRC field are valid. A CRCV bit value of zero 223 indicates that the contents of the CRC field are invalid. The value 224 of the CRCV bit SHALL be constant for all FC Encapsulation Headers 225 sent on a given connection. 227 Frame Length: The Frame Length field contains the length of the 228 entire FC Encapsulated frame including the FC Encapsulation Header 229 and the FC frame (including SOF and EOF words). This length is 230 based on a unit of 32-bit words. All FC frames are 32-bit-word- 231 aligned and the FC Encapsulation Header is always word-aligned; 232 therefore a32-bit word length is acceptable. 234 -Flags: The -Flags field SHALL contain the one's complement of the 235 contents of the Flags field. FC Encapsulation receivers SHOULD 236 either validate the CRC or compare the Flags and -Flags fields to 237 verify that an FC Encapsulation Header is being processed according 238 to a policy defined by the encapsulating protocol. 240 -Frame Length: The -Frame Length field SHALL contain the one's 241 complement of the contents of the Frame Length field. FC 242 Encapsulation receivers SHOULD either validate the CRC or compare 243 the Frame Length and -Frame Length fields to verify that an FC 244 Encapsulation Header is being processed according to a policy 245 defined by the encapsulating protocol. 247 Time Stamp [Seconds]: The Time Stamp [Seconds] field contains zero 248 or the number of seconds since 0 hour on 1 January 1900 at the time 249 the FC Encapsulated frame is place in the outgoing data stream. 251 Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction] 252 field contains the fraction of the second at the time the FC 253 Encapsulated frame is place in the outgoing data stream. Non- 254 significant low order bits may be set to zero. Table 1 shows 255 some example Time Stamp [Seconds Fraction] values. 257 +------------+--------------------+ 258 | | Time Stamp | 259 | Second | [Seconds Fraction] | 260 +------------+--------------------+ 261 | n.50000... | 0x80000000 | 262 | n.25000... | 0x40000000 | 263 | n.12500... | 0x20000000 | 264 +------------+--------------------+ 266 Table 1 Example Time Stamp [Seconds Fraction] values 268 Note that, since some time in 1968 (second 2,147,483,648) the 269 most significant bit (bit 0 of Time Stamp [Seconds]) has been 270 set and that the field will overflow some time in 2036 (second 271 4,294,967,296). Should FCIP be in use in 2036, some external 272 means will be necessary to qualify time relative to 1900 and time 273 relative to 2036 (and other multiples of 136 years). There will 274 exist a 200-picosecond interval, henceforth ignored, every 136 275 years when the 64-bit field will be 0, which by convention is 276 interpreted as an invalid or unavailable timestamp. 278 The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words 279 follow the in time format described in Simple Network Time Protocol 280 (SNTP) Version 4 [9]. The contents of the Time Stamp [Seconds] and 281 Time Stamp [Seconds Fraction] words SHALL be set as described in 282 section 4. 284 CRC: When the CRCV Flag bit is zero, the CRC field SHALL contain 285 zero. When the CRCV Flag bit is one, the CRC field SHALL contain a 286 CRC for words 0 to 5 of the FC Encapsulation Header computed using 287 the equations, polynomial, initial value, and bit order defined for 288 Fibre Channel in FC-FS [3]. Using this algorithm, the bit order of 289 the resulting CRC corresponds to that of FC-1 layer. The CRC 290 transmitted over the IP network shall correspond to the equivalent 291 value converted to FC-2 format as specified in FC-FS. 293 3.2 FC Encapsulation Header Validation 295 Two mechanisms are provided for validating an FC Encapsulation 296 Header: 298 - Redundancy based 299 - CRC based 301 The two mechanisms address the needs of two different design and 302 operating environments. 304 3.2.1 Redundancy Based FC Encapsulation Header Validation 306 Redundancy based validation of an FC Encapsulation Header relies 307 on duplicated and one's complemented fields in the header. 309 Encapsulating protocols that use redundancy based validation SHOULD 310 define how receiving devices use one's complement fields to verify 311 header validity. 313 Header validation based on redundancy is a stepwise process in 314 that the first word is validated, then the second, then the third 315 and so on. A decision that a candidate header is not valid may be 316 reached before the complete header is available. 318 3.2.2 CRC Based FC Encapsulation Header Validation 320 CRC based validation of an FC Encapsulation Header relies on a CRC 321 located in the last word of the header. 323 Header validation based on the CRC defined in section 3.1 requires 324 computing the CRC for all bytes preceding the CRC word, and 325 comparing the results to the CRC word's contents. 327 4. Measuring Fibre Channel Frame Transit Time 329 To comply with FC-FS [3], an FC Fabric must specify and limit the 330 lifetime of a frame. In an FC Fabric comprised of IP-connected 331 elements, one component of the frame's lifetime is the time required 332 to traverse the connection. To ensure that the total frame lifetime 333 remains within the limits required by the FC Fabric, the 334 encapsulation described in this specification contains provisions 335 for recording the departure time of an encapsulated frame injected 336 into a connection. If the encapsulated frame originator and 337 recipient have access to aligned and synchronized time bases, 338 the transit time through the IP network can then be computed. 340 When originating an encapsulated frame, an entity that does not 341 support transit time calculation SHALL always set the Time Stamp 342 [Seconds] and Time Stamp [Seconds Fraction] fields to zero. When 343 receiving an encapsulated frame, an entity that does not support 344 transit time calculation SHALL ignore the contents of the Time 345 Stamp words. 347 The encapsulating protocol SHALL specify whether or not 348 implementation support is required. The encapsulating protocol 349 SHALL specify those conditions under which a received encapsulated 350 frame MUST have its transit time checked before forwarding. 352 Encapsulating and de-encapsulating entities that support this 353 feature MUST have access to: 355 a) An internal time base having the stability and resolution 356 necessary to comply with the requirements of the encapsulating 357 protocol specification; and 359 b) A time base that is synchronized and aligned with the time base 360 of other entities to which encapsulated frames may be sent or 361 received. The encapsulating protocol specification MUST describe 362 the synchronization and alignment procedure. 364 With respect to its ability to measure and set transit time for 365 encapsulated frames exchanged with another device, an entity is 366 either in the Synchronized or Unsynchronized state. An entity is 367 in the Unsynchronized state upon power-up and transitions to the 368 Synchronized state once it has aligned its time base in accordance 369 with the applicable encapsulating protocol specification. 371 An entity MUST return to the Unsynchronized state if it is unable 372 to maintain synchronization of its time base as required by the 373 encapsulating protocol specification. 375 The policy for forwarding frames while in the Unsynchronized state 376 SHALL be defined by the encapsulating protocol specification. 378 If processing frames in the Unsynchronized state is permitted by 379 the encapsulating protocol specification, the entity SHALL: 381 a) When de-encapsulating a frame, ignore the Time Stamp words. 382 For example, if a calculated transit time exceeds a value that 383 could cause the frame to violate FC maximum time in transit 384 limits, the encapsulating protocol may specify that the frame is 385 to be discarded; and 387 b) When encapsulating a frame set the Time Stamp [Seconds] and 388 Time Stamp [Seconds Fraction] words to zero. For example, 389 an encapsulating protocol may specify that frames for which 390 transit time cannot be determined are never to be forwarded 391 over FC. 393 When encapsulating a frame, an entity in the Synchronized state 394 SHALL record the value of the time base in the Time Stamp [Seconds] 395 and Time Stamp [Seconds Fraction] words in the encapsulation header. 397 When de-encapsulating a frame, an entity in the Synchronized state 398 SHALL: 400 a) Test the Time Stamp words to determine if they contain a time 401 b) as specified in [9]. If the time stamp is valid, the receiving 402 entity SHALL compute the transit time by calculating the 403 difference between its time base and the departure time recorded 404 in the frame header. The receiving entity SHALL process the 405 calculated transit time and the de-encapsulated frame in 406 accordance with the applicable encapsulating protocol 407 specification; or 409 c) If both Time Stamp words have a value of zero, the receiving 410 entity SHALL de-encapsulate the frame without computing the 411 transit time. The disposition of the frame and any other actions 412 by the recipient SHALL be defined by the encapsulating protocol 413 specification. 415 Note: For most purposes, communication between entities is possible 416 only while in the Synchronized state. 418 5. The FC Frame 420 5.1 FC Frame Content 422 Figure 4 shows the structure of a general FC-2 frame format. 424 +------------------+ 425 | SOF | 426 +------------------+ 427 | FC frame content | 428 +------------------+ 429 | EOF | 430 +------------------+ 431 Fig. 4 - General FC-2 Frame Format 433 As shown in figure 4, the FC frame content is defined as the data 434 between the EOF and SOF delimiters (including the FC CRC) after 435 conversion from FC-1 to FC-2 format as specified by FC-FS [3]. 437 When Fibre Channel devices convert the FC frame content to the FC-0 438 physical transport, an encoding is applied to the FC frame content 439 (e.g., 8b/10b encoding like that used in Gigbit Ethernet) for 440 reasons that include redundancy and low level timing synchronization 441 between sender and receiver. With the exceptions of SOF and EOF [3] 442 all discussion of FC frame content in this document is at the 8-bit 443 byte level, prior to the application of any such encoding. 445 The 8-bit bytes in the FC frame content can be translated directly 446 for transmission over an IP Network. However, the FC SOF and EOF 447 employ special 10b characters that have no 8b equivalents. 448 Therefore, special byte placement and 8-bit character encodings 449 are required to represent SOF and EOF. 451 5.2 Bit and Byte Ordering 453 The Encapsulation Header, SOF, FC frame content (see section 5.1), 454 and EOF are mapped to TCP using the big endian byte ordering, which 455 corresponds to the standard network byte order or canonical form [7]. 457 5.3 FC SOF and EOF 459 As described in section 5.1, representation of FC SOF and EOF in an 460 IP Network byte stream requires special formatting and 8-bit code 461 definitions. Therefore, the encapsulated FC frame SHALL have the 462 format shown in figure 5. The redundancy of the SOF/EOF 463 representation in the encapsulation format results from concerns 464 that the information be protected from transmission errors. 466 W|------------------------------Bit------------------------------| 467 o| | 468 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| 469 d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| 470 +---------------+---------------+-------------------------------+ 471 0| SOF | SOF | -SOF | -SOF | 472 +---------------+---------------+-------------------------------+ 473 1| | 474 +----- FC frame content -----+ 475 | | 476 +---------------+---------------+-------------------------------+ 477 n| EOF | EOF | -EOF | -EOF | 478 +---------------+---------------+-------------------------------+ 480 Fig. 5 - FC Frame Encapsulation Format 482 Note: The number of 8-bit bytes in the FC frame content is always 483 a multiple of four. 485 SOF: The SOF fields contain the encoded SOF value selected from 486 table 2. 488 +-------+------+-------+ +-------+------+-------+ 489 | FC | SOF | | | FC | SOF | | 490 | SOF | Code | Class | | SOF | Code | Class | 491 +-------+------+-------+ +-------+------+-------+ 492 | SOFf | 0x28 | F | | SOFi4 | 0x29 | 4 | 493 | SOFi2 | 0x2D | 2 | | SOFn4 | 0x31 | 4 | 494 | SOFn2 | 0x35 | 2 | | SOFc4 | 0x39 | 4 | 495 | SOFi3 | 0x2E | 3 | +-------+------+-------+ 496 | SOFn3 | 0x36 | 3 | 497 +-------+------+-------+ 499 Table 2 Translation of FC SOF values to SOF field contents 501 -SOF: The -SOF fields contain the one's complement of the value in 502 the SOF fields. Encapsulation receivers SHOULD validate the SOF 503 field according to a policy defined by the encapsulating protocol. 505 EOF: The EOF fields contain the encoded EOF value selected from 506 table 3. 508 +-------+------+---------+ +--------+------+-------+ 509 | FC | EOF | | | FC | EOF | | 510 | EOF | Code | Class | | EOF | Code | Class | 511 +-------+------+---------+ +--------+------+-------+ 512 | EOFn | 0x41 | 2,3,4,F | | EOFdt | 0x46 | 4 | 513 | EOFt | 0x42 | 2,3,4,F | | EOFdti | 0x4E | 4 | 514 | EOFni | 0x49 | 2,3,4,F | | EOFrt | 0x44 | 4 | 515 | EOFa | 0x50 | 2,3,4,F | | EOFrti | 0x4F | 4 | 516 +-------+------+---------+ +--------+------+-------+ 518 Table 3 Translation of FC EOF values to EOF field contents 520 -EOF: The -EOF fields contain the one's complement of the value in 521 the EOF fields. Encapsulation receivers SHOULD validate the EOF 522 field according to a policy defined by the encapsulating protocol. 524 Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 2 and 525 table 3 (e.g., SOFi1 and SOFn1). However, FC-MI [8] identifies these 526 codes as not interoperable, so they are not listed in this 527 specification. 529 6. Security 531 This document describes the encapsulation format only. Actual use 532 of this format in a encapsulating protocol requires an additional 533 document to specify the encapsulating protocol functionality and 534 appropriate security considerations. Because security considerations 535 for this encapsulation depend on how it is used by encapsulating 536 protocols, they SHALL be described in encapsulating protocol 537 specific documents. 539 7. Normative References 541 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 542 9, RFC 2026, October 1996. 544 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 545 Levels", BCP 14, RFC 2119, March 1997. 547 [3] Fibre Channel Framing and Signaling (FC-FS), T11 Project 548 1331-D, (http://www.t11.org/t11/docreg.nsf/ldl/fc-fs). 550 Note: The Fibre Channel frame structure and CRC features 551 referenced by this draft, while formally described in FC-FS, 552 are substantially unchanged from similar features described 553 in Fibre Channel Physical and Signaling Interface (FC-PH), 554 ANSI X3.290-1994, June 1, 1994. 556 [4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001, 557 May 23, 2001. 559 [5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002, 560 August 18, 2000. 562 [6] Fibre Channel Backbone -2 (FC-BB-2), T11 Project 1466-D, (http:// 563 www.t11.org/t11/docreg.nsf/ldl/fc-bb-2). 565 Note: Published T11 standards are available from the INCITS 566 online store http://www.incits.org, or the ANSI online store, 567 http://www.ansi.org. 569 [7] Narten, T. and C. Burton, "A Caution on The Canonical Ordering 570 of Link-Layer Addresses", RFC 2469, December 1998. 572 8. Informative References 574 [8] Fibre Channel Methodologies for Interconnects (FC-MI), T11 575 Project 1377-D, (http://www.t11.org/t11/docreg.nsf/ldl/fc-mi). 577 [9] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 578 IPv4, IPv6 and OSI", RFC 2030, October 1996. 580 [10] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 581 Considerations Section in RFCs", RFC 2434, October 1998. 583 [11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over 584 TCP/IP (FCIP)", draft-ietf-ips-fcovertcpip-__.txt, Work in 585 Progress. 587 [12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre 588 Channel Storage Networking", draft-ietf-ips-ifcp-__.txt, Work in 589 Progress. 591 9. Authors' Addresses 593 Ralph Weber Murali Rajagopal 594 ENDL Texas SV Systems Inc. 595 representing Brocade Comm. 518 Valley Way 596 Suite 102 PMB 178 Milpitas, CA 95035 597 18484 Preston Road USA 598 Dallas, TX 75252 Phone: +1 949 280 6516 599 USA Email: muralir@cox.net 600 Phone: +1 214 912 1373 601 Email: roweber@acm.org 603 Franco Travostino Michael E. O'Donnell 604 Technology Center McDATA Corporation 605 Nortel Networks, Inc. 310 Interlocken Parkway 606 600 Technology Park Broomfield, Co. 80021 607 Billerica, MA 01821 USA 608 USA Phone: +1 303 460 4142 609 Phone: +1 978 288 7708 Fax: +1 303 465 4996 610 Email: travos@nortelnetworks.com Email: modonnell@mcdata.com 612 Charles Monia Milan J. Merhar 613 Nishan Systems 43 Nagog Park 614 3850 North First Street Pirus Networks 615 San Jose, CA 95134 Acton, MA 01720 616 USA USA 617 Phone: +1 408 519 3986 Phone: +1 978 206 9124 618 Email: cmonia@nishansystems.com Email: Milan@pirus.com 620 10. Acknowledgements 622 The authors express their appreciation to Mr. Vi Chau 623 (vchau1@cox.net) for his contributions to the design team that 624 developed this document. Mr. Chau is no longer working in this 625 technology. 627 The authors are also grateful to Mr. David Black, Mr. Mallikarjun 628 Chadalapaka, and Mr. Robert Elliott for their reviews of this 629 specification. 631 11. Full Copyright Statement 633 Copyright (C) The Internet Society (2002). All Rights Reserved. 635 This document and translations of it may be copied and furnished to 636 others, and derivative works that comment on or otherwise explain it 637 or assist in its implementation may be prepared, copied, published 638 and distributed, in whole or in part, without restriction of any 639 kind, provided that the above copyright notice and this paragraph 640 are included on all such copies and derivative works. However, this 641 document itself may not be modified in any way, such as by removing 642 the copyright notice or references to the Internet Society or other 643 Internet organizations, except as needed for the purpose of 644 developing Internet standards in which case the procedures for 645 copyrights defined in the Internet Standards process must be 646 followed, or as required to translate it into languages other than 647 English. 649 The limited permissions granted above are perpetual and will not be 650 revoked by the Internet Society or its successors or assigns. 652 This document and the information contained herein is provided on an 653 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 654 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 656 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 657 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Appendix A - Fibre Channel Bit and Byte Numbering Guidance 661 Both Fibre Channel and IETF standards use the same byte transmission 662 order. However, the bit and byte numbering is different. 664 Fibre Channel bit and byte numbering can be observed if the data 665 structure heading shown in figure 6, is cut and pasted at the top 666 of figure 2 and figure 5. 668 W|------------------------------Bit------------------------------| 669 o| | 670 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 671 d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| 673 Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering 675 Fibre Channel bit numbering for the Flags field can be observed 676 if the data structure heading shown in figure 7, is cut and 677 pasted at the top of figure 3. 679 |------------------------Bit--------------------------| 680 | | 681 | 31 30 29 28 27 26 | 683 Fig. 7 - Fibre Channel Flags Bit Numbering 685 Appendix B - Encapsulating Protocol Requirements 687 This appendix lists the requirements placed on the encapsulating 688 protocols that employ this encapsulation. The requirements listed 689 here are suggested or described elsewhere in this document, but 690 their collection in this appendix serves to assist encapsulating 691 protocol authors in meeting all obligations placed upon them. 693 Encapsulating Protocol Specific Data 695 Encapsulating protocols employing this encapsulation SHALL: 697 - specify the IANA assigned number used in the Protocol# field 698 - specify the contents of the Encapsulating Protocol Specific field 700 Encapsulating protocols employing this encapsulation SHALL define 701 the procedures and policies necessary for verifying that an FC 702 Encapsulation Header is being processed. 704 Encapsulating protocols employing this encapsulation SHALL define 705 the procedures and policies necessary for the detection of over age 706 frames. The items to be specified and the choices available to an 707 encapsulating protocol specification are as follows: 709 a) The encapsulating protocol requirements for measuring transit 710 times. The encapsulating protocol MAY allow implementation of 711 transit time measurement to be optional. 713 b) The requirements or guidelines for stability and resolution of 714 the entity's time base. 716 c) The procedure for synchronizing an entity's time base, including 717 the criteria for entering the Synchronized and Unsynchronized 718 states. 720 d) The forwarding (or lack of forwarding) of frame traffic while in 721 the Unsynchronized state. 723 The specification MAY allow an entity in the Unsynchronized 724 state to continue processing frame traffic. 726 e) The procedure to be followed when frames are received that do 727 not have a valid time stamp. 729 The specification MAY allow such frames to be accepted by the 730 entity. 732 f) Requirements for setting and testing the transit time limit and 733 the procedure to be followed when a received frame is discarded 734 due to its transit time exceeding the limit. 736 Appendix C - IANA Considerations 738 The Protocol# (Protocol Number) field is an identifier number used 739 to distinguish between the encapsulating protocols that employ this 740 FC frame encapsulation. Values used in the Protocol# field are to be 741 assigned from a new, separate registry that is maintained by IANA. 743 All values in the Protocol# field are to be registered with and 744 assigned by IANA with the following exceptions. 746 - Protocol# value 0 should not be assigned until after all other 747 values have been assigned. 749 - Protocol# values 240-255 inclusive must be set aside for private 750 use amongst cooperating systems. 752 Following the policies outlined in [10], Protocol# values not listed 753 above are to be assigned only for Standards Track RFCs approved by 754 the IESG. 756 In addition to creating the FC Frame Encapsulation Protocol Number 757 Registry, the standards action of this RFC allocates the following 758 two values from the registry: 760 - Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/ 761 IP) encapsulating protocol [11]. 763 - Protocol# value 2 assigned to the iFCP (A Protocol for Internet 764 Fibre Channel Storage Networking) encapsulating protocol [12].