idnits 2.17.1 draft-ietf-ips-fcencapsulation-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2030 (ref. '7') (Obsoleted by RFC 4330) ** Downref: Normative reference to an Informational RFC: RFC 2469 (ref. '8') Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Weber 3 Brocade 4 (Expires: November 10, 2001) 5 Category: standards-track M. Rajagopal 6 LightSand Communications 8 F. Travostino 9 FC Frame Encapsulation Nortel Networks 11 V. Chau 12 Gadzoox Networks 14 M. O'Donnell 15 McDATA 17 C. Monia 18 Nishan Systems 20 M. Merhar 21 Pirus Networks 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026 [1]. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on November 10, 2001. 46 Abstract 48 This is the ips (IP Storage) working group draft describing the 49 common encapsulation format for use by any IETF protocol that 50 encapsulates Fibre Channel (FC) frames. This draft describes a 51 frame header containing information mandated for encapsulating, 52 transmitting, and de-encapsulating FC frames. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [2]. 60 1. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . 3 61 2. The FC Encapsulation Header . . . . . . . . . . . . . . . . . 4 62 2.1 FC Encapsulation Header Format . . . . . . . . . . . . . . . 4 63 2.2 FC Encapsulation Header Validation . . . . . . . . . . . . . 6 64 2.2.1 Redundancy based FC Encapsulation Header validation . . . . 6 65 2.2.2 CRC based FC Encapsulation Header validation . . . . . . . 7 66 3. The FC frame . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1 FC frame content . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . 7 69 3.3 FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 10 73 7. Full Copyright Statement . . . . . . . . . . . . . . . . . . 11 75 Annex 76 A Protocol Requirements . . . . . . . . . . . . . . . . . . . . 12 77 B IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 1. Encapsulation Concepts 81 The smallest unit of data transmission and routing in Fibre Channel 82 (FC) is the frame. FC frames include a Start Of Frame (SOF), End 83 Of Frame (EOF), CRC coverage of the FC Payload for error detection. 84 FC frames have several possible lengths. To facilitate transporting 85 FC frames over TCP the native FC frame needs to be contained in 86 (encapsulated in) a slightly larger structure as shown in Figure 1. 88 +--------------------+ 89 | Header | 90 +--------------------+-----+ 91 | SOF | f | 92 +--------------------+ F r | 93 | FC frame content | C a | 94 +--------------------+ m | 95 | EOF | e | 96 +--------------------+-----+ 98 Fig. 1 - FC frame Encapsulation 100 The format and content of an FC frame is described in the FC 101 standards (e.g., FC-FS [3], FC-SW-2 [4], and FC-PI [5]). Of 102 importance to this encapsulation is the FC requirement that all 103 frames SHALL contain an CRC for detection of transmission errors. 105 This document describes the encapsulation format only. Actual use of 106 this format in a protocol requires an additional document to specify 107 the protocol functionality and appropriate security considerations. 108 Because security considerations for this encapsulation depend on how 109 it is used by protocols, they are taken up in protocol-specific 110 documents. 112 2. The FC Encapsulation Header 114 2.1 FC Encapsulation Header Format 116 Figure 2 shows the format of the required FC Encapsulation Header. 118 W|------------------------------Bit------------------------------| 119 o| | 120 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 121 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| 122 +---------------+---------------+---------------+---------------+ 123 0| Protocol# | Version | -Protocol# | -Version | 124 +---------------+---------------+---------------+---------------+ 125 1| | 126 +----- Protocol Specific ----+ 127 2| | 128 +-----------+-------------------+-----------+-------------------+ 129 3| Flags | Frame Length | -Flags | -Frame Length | 130 +-----------+-------------------+-----------+-------------------+ 131 4| Time Stamp [integer] | 132 +---------------------------------------------------------------+ 133 5| Time Stamp [fraction] | 134 +---------------------------------------------------------------+ 135 6| CRC | 136 +---------------------------------------------------------------+ 138 Fig. 2 - FC Encapsulation Header Format 140 The fields in the FC Encapsulation Header are defined as follows. 142 Protocol (bits 31-24 in word 0): The Protocol# field SHALL contain 143 a number that indicates which protocol is employing the FC 144 Encapsulation. The values in the Protocol# field are assigned 145 by IANA [6]. The following values are known to be in use: 147 FCIP -- TO BE ASSIGNED by IANA 148 iFCP -- TO BE ASSIGNED by IANA 150 Version (bits 23-16 in word 0): The Version field SHALL contain 0x1 151 to indicate that this version of the FC Encapsulation is being used. 152 All other values are reserved for future versions of the FC 153 Encapsulation. 155 -Protocol# (bits 15-8 in word 0): The -Protocol# field contains 156 the ones complement of the contents of the Protocol# field. FC 157 Encapsulation receivers may compare the Protocol# and -Protocol# 158 fields as an additional verification that an FC Encapsulation Header 159 is being processed. 161 -Version (bits 7-0 in word 0): The -Version field contains the ones 162 complement of the contents of the Version field. FC Encapsulation 163 receivers may compare the Version and -Version fields as an 164 additional verification that an FC Encapsulation Header is being 165 processed. 167 Protocol Specific (words 1 and 2): The usage of these words differs 168 based on the contents of the Protocol# field, i.e., the usage of this 169 word is defined by the protocol that is employing this encapsulation. 171 Flags (bits 31-26 in word 3): The Flags bits provide information 172 about the usage of the FC Encapsulation Header as shown in Figure 3. 174 Note: Implementers are advised to consult the specifications of 175 protocols that use this header to determine how each individual 176 protocol uses the bits in the Flags field. 178 |------------------------Bit--------------------------| 179 | | 180 | 31 30 29 28 27 26 | 181 +--------------------------------------------+--------+ 182 | Reserved | CRCV | 183 +--------------------------------------------+--------+ 185 Fig. 3 - Flags Field Format 187 Reserved (Flags, bits 31-27 in word 3): These bits are reserved 188 for use by future versions of the FC Encapsulation and SHALL be 189 set to zero on send. Protocols employing this encapsulation MAY 190 require checking for zero on receive, however doing so has the 191 potential to create incompatibilities with future versions of this 192 encapsulation. Changes in the usage of the Reserved Flags bits 193 MUST be identified by changes in the contents of the Version 194 field. Protocols employing this encapsulation MUST NOT make use 195 of the Reserved Flags bits in any fashion other than that 196 described here. 198 CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one 199 indicates that the contents of the CRC field are valid. A CRCV bit 200 value of zero indicates that CRC are invalid. Some protocols may 201 always check the CRC without regard for the state of this bit. The 202 value of the CRCV bit SHALL be constant for all FC Encapsulation 203 Headers sent on a given TCP connection. 205 Frame Length (bits 25-16 in word 3): The Frame Length field contains 206 the length of the entire FC Encapsulated frame including the FC 207 Encapsulation Header and the FC frame (including SOF and EOF words). 208 This length is based on a unit of 32-bit words. All FC frames are 209 32-bit-word-aligned and the FC Encapsulation Header SHALL always be 210 word-aligned; therefore a 32-bit word length is acceptable. 212 -Flags (bits 15-10 in word 3): The -Flags field contains the ones 213 complement of the contents of the Flags field. FC Encapsulation 214 receivers may compare the Flags and -Flags fields as an additional 215 verification that an FC Encapsulation Header is being processed. 217 -Frame Length (bits 9-0 in word 3): The -Frame Length field contains 218 the ones complement of the contents of the Frame Length field. FC 219 Encapsulation receivers may compare the Frame Length and -Frame 220 Length fields as an additional verification that an FC Encapsulation 221 Header is being processed. 223 Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The 224 two Time Stamp contain time at which the FC Encapsulated frame was 225 sent as known to the sender. The format of integer and fraction Time 226 Stamp word values is specified in Simple Network Time Protocol (SNTP) 227 Version 4 [7]. When the sending time is unknown, the Time Stamp 228 [integer] and Time Stamp [fraction] words SHALL contain zero. 230 CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL 231 contain zero. When the CRCV Flag bit is one, the CRC field SHALL 232 contain a CRC for words 0 to 5 of the FC Encapsulation Header 233 computed using the polynomial, initial value, and bit order defined 234 for Fibre Channel[3]. 236 2.2 FC Encapsulation Header Validation 238 Two mechanisms are provided for validating an FC Encapsulation 239 Header: 241 o Redundancy based 242 o CRC based 244 The two mechanisms address the needs of two different design and 245 operating environments. 247 2.2.1 Redundancy based FC Encapsulation Header validation 249 Redundancy based validation of an FC Encapsulation Header relies on 250 duplicated and one's complemented fields in the header. 252 Validation of a header using redundancy may be accomplished using 253 very simple logic (e.g., XORs and comparisons). Header validation 254 based on redundancy also is a step wise process in that the first 255 word is validated, then the second, then the third and so on. A 256 decision that a candidate header is not valid may be reached before 257 the complete header is available. 259 2.2.2 CRC based FC Encapsulation Header validation 261 CRC based validation of an FC Encapsulation Header relies on a CRC 262 located in the last word of the header. 264 Validation of a header using the CRC may be accomplished using a very 265 straight forward algorithm, compute the CRC for all bytes preceding 266 the CRC word and compare the results to the CRC word's contents. The 267 number of comparisons required to perform CRC validation is exactly 268 one and the method for computing the CRC is well known with proven 269 implementations. 271 3. The FC frame 273 3.1 FC frame content 275 Figure 4 shows the structure of a general FC-2 frame format. 277 +------------------+ 278 | SOF | 279 +------------------+ 280 | FC frame content | 281 +------------------+ 282 | EOF | 283 +------------------+ 285 Fig. 4 - General FC-2 Frame Format 287 3.2 Bit and Byte Ordering 289 FC frames are mapped to TCP using the big endian byte ordering, which 290 corresponds to the standard network byte order or canonical form [8]. 292 3.3 FC SOF and EOF 294 The FC frame content is composed of 8-bit bytes that can be 295 translated directly for transmission over TCP. The SOF and EOF 296 require 8b/10b special characters that cannot be translated directly 297 to 8-bit bytes, encoded values are required. 299 For this reason, the encapsulated FC frame SHALL have the format 300 shown in figure 5. The redundancy of the SOF/EOF representation in 301 the encapsulation format results from concerns that the information 302 be protected from transmission errors. 304 W|------------------------------Bit------------------------------| 305 o| | 306 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 307 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| 308 +---------------+---------------+-------------------------------+ 309 0| SOF | SOF | -SOF | -SOF | 310 +---------------+---------------+-------------------------------+ 311 1| | 312 +----- FC frame content -----+ 313 | | 314 +---------------+---------------+-------------------------------+ 315 n| EOF | EOF | -EOF | -EOF | 316 +---------------+---------------+-------------------------------+ 318 Fig. 5 - FC Frame Encapsulation Format 320 SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain 321 the encoded SOF value selected from table 1. 323 +-------+----------+ 324 | FC | | 325 | SOF | SOF Code | 326 +-------+----------+ 327 | SOFf | 0x28 | 328 | SOFi2 | 0x2D | 329 | SOFn2 | 0x35 | 330 | SOFi3 | 0x2E | 331 | SOFn3 | 0x36 | 332 +-------+----------+ 334 Table 1 Translation of 335 FC SOF values to SOF 336 field contents 338 -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the 339 one's complement of the value in the SOF fields. 341 EOF (bits 31-24 and 23-16 in word n): The EOF fields contain the 342 encoded EOF value selected from table 2. 344 +-------+----------+ 345 | FC | | 346 | EOF | EOF Code | 347 +-------+----------+ 348 | EOFn | 0x41 | 349 | EOFt | 0x42 | 350 | EOFni | 0x49 | 351 | EOFa | 0x50 | 352 +-------+----------+ 354 Table 2 Translation of 355 FC EOF values to EOF 356 field contents 358 -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain the 359 one's complement of the value in the EOF fields. 361 4. Security 363 This document describes the encapsulation format only. Actual use of 364 this format in a protocol requires an additional document to specify 365 the protocol functionality and appropriate security considerations. 366 Because security considerations for this encapsulation depend on how 367 it is used by protocols, they SHALL be described in protocol-specific 368 documents. 370 5. References 372 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 373 BCP 9, RFC 2026, October 1996. 375 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 376 Levels", BCP 14, RFC 2119, March 1997 378 [3] T11/Project 1331-D/Rev 1.20 "Fibre Channel Framing and 379 Signaling", (FC-FS) February 16, 2001 (www.t11.org) 381 [4] NCITS 321-200x (ANSI) T11/Project 1305-D/Rev 4.9 "Fibre Channel 382 Switch-Fabric-2", (FC-SW-2) November 14, 2000 (www.t11.org) 384 [5] NCITS 352-200x (ANSI) T11/Project 1306-D/Rev 9 "Fibre Channel 385 Physical Interfaces", (FC-PI) August 18, 2000 (www.t11.org) 387 [6] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700, 388 October, 1994. 390 [7] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 391 IPv4, IPv6 and OSI", RFC 2030, October 1996. 393 [8] Narten, T. and C. Burton, "A Caution on The Canonical Ordering 394 of Link-Layer Addresses", RFC 2469, December 1998. 396 6. Author's Addresses 398 Ralph O. Weber Murali Rajagopal 399 Representing Brocade Comm. LightSand Communications, Inc. 400 ENDL Texas 375 Los Coches St. 401 PMB 178 Milpitas, CA 95035 402 18484 Preston Road US 403 Suite 102 404 Dallas, TX 75252 Phone: +1 408 404 3164 405 US Email: muralir@lightsand.com 407 Phone: +1 214 912 1373 408 Email: rweber@brocade.com 410 Franco Travostino Vi Chau 411 Technology Center Gadzoox Networks, Inc. 412 Nortel Networks, Inc. 16241 Laguna Canyon Road 413 600 Technology Park Suite 100 414 Billerica, MA 01821 Irvine, CA 92618 415 US US 417 Phone: +1 978 288 7708 Phone: +1 949 789 4639 418 Email: travos@nortelnetworks.com Email: vchau@gadzoox.com 420 Michael E. O'Donnell Charles Monia 421 McDATA Corporation Nishan Systems 422 310 Interlocken Parkway 3850 North First Street 423 Broomfield, Co. 80021 San Jose, CA 95134 424 US US 426 Phone: +1 303 460 4142 Phone: +1 408 519 3986 427 Email: modonnell@mcdata.com Email: cmonia@nishansystems.com 428 Milan Merhar 429 Pirus Networks 430 43 Nagog Park 431 Acton MA 01720 432 US 434 Phone: +1 978 206 9124 435 Email: milan@pirus.com 437 7. Full Copyright Statement 439 Copyright (C) The Internet Society (2001). All Rights Reserved. 441 This document and translations of it may be copied and furnished to 442 others, and derivative works that comment on or otherwise explain it 443 or assist in its implementation may be prepared, copied, published 444 and distributed, in whole or in part, without restriction of any 445 kind, provided that the above copyright notice and this paragraph 446 are included on all such copies and derivative works. However, this 447 document itself may not be modified in any way, such as by removing 448 the copyright notice or references to the Internet Society or other 449 Internet organizations, except as needed for the purpose of 450 developing Internet standards in which case the procedures for 451 copyrights defined in the Internet Standards process must be 452 followed, or as required to translate it into languages other than 453 English. 455 The limited permissions granted above are perpetual and will not be 456 revoked by the Internet Society or its successors or assigns. 458 This document and the information contained herein is provided on an 459 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 460 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 461 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 462 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 463 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Annex A - Protocol Requirements 467 This annex lists the requirements placed on the protocols that employ 468 this encapsulation. The requirements listed here are suggested or 469 described elsewhere in this document, but their collection in this 470 annex serves to assist protocol authors in meeting all obligations 471 placed upon them. 473 Protocol Specific Data 475 Protocols employing this encapsulation SHALL: 477 o specify the IANA assigned number used in the Protocol# field 478 o specify the contents of the Protocol Specific field 480 CRC 482 Protocols employing this encapsulation SHALL either: 484 1) Require a valid CRC to be sent and the CRCV Flag bit to be sent as 485 one, or 486 2) Require the CRC field to be sent as zero and the CRCV Flag bit to 487 be sent as zero. 489 Annex B - IANA Considerations 491 The Protocol# (Protocol Number, bits 31-24 in word 0 of the 492 Encapsulation Header) field is an identifier number used to 493 distinguish between the protocols that employ this encapsulation. 494 Values used in the Protocol# field are to be assigned from a new, 495 separate registry that is maintained by IANA in accordance with RFC 496 1700 [6]. 498 All values in the Protocol# field are to be registered with and 499 assigned by IANA with the following exceptions. 501 o Protocol# value 0 should not be assigned until after all other 502 values have been assigned. 504 o Protocol# values 240-255 inclusive must be set aside for private 505 use amongst cooperating systems. 507 Standards action on this RFC should be accompanied by IANA assignment 508 of the following two Protocol# values: 510 o Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/IP) 511 protocol being developed in draft-ietf-ips-fcovertcpip-__.txt. 513 o Protocol# value 2 assigned to the iFCP (A Protocol for Internet 514 Fibre Channel Storage Networking) protocol being developed in 515 draft-ietf-ips-ifcp-__.txt. 517 Requests for assignments of Protocol# values must be accompanied by 518 an RFC which describes how this encapsulation is employed. If the 519 RFC is not on the standards-track (i.e., it is an informational or 520 experimental RFC), it must be explicitly reviewed and approved by the 521 IESG before the RFC is published and Protocol# value is assigned. 522 It is requested that the ips working group chairs or the Transport 523 Services area directors be notified when any new Protocol# value 524 assignment is requested.