idnits 2.17.1 draft-ietf-ips-ifcp-02.txt: ** The Abstract section seems to be numbered -(286): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(476): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(478): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(676): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1387): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1459): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1467): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1483): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1581): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1663): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1752): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1864): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1872): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1947): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1955): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2027): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2052): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2259): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 52 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11.1 Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11. Security' ) ** 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 are 822 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 606 has weird spacing: '...TRN bit set t...' == Line 607 has weird spacing: '... the iFCP ...' == Line 1022 has weird spacing: '...Request expl...' == Line 2293 has weird spacing: '...rt Name iFCP ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: This section describes the handling for ELS frames containing N_PORT addresses in the ELS payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated and such ELS messages SHALL not be sent as augmented frames unless other special processing is required. -- 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.) -- The document date (May 2001) is 8376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 3170 looks like a reference -- Missing reference section? '2' on line 167 looks like a reference -- Missing reference section? 'FC-FS' on line 249 looks like a reference -- Missing reference section? 'FGS' on line 303 looks like a reference -- Missing reference section? 'FCS' on line 1993 looks like a reference -- Missing reference section? 'FC-SW' on line 2623 looks like a reference -- Missing reference section? 'FC-PH' on line 2834 looks like a reference -- Missing reference section? 'FC-PH-2' on line 2837 looks like a reference -- Missing reference section? 'FC-PH-3' on line 2840 looks like a reference -- Missing reference section? 'ENCAP' on line 1103 looks like a reference -- Missing reference section? 'SNTP' on line 1176 looks like a reference -- Missing reference section? '22' on line 1421 looks like a reference -- Missing reference section? 'FC-VI' on line 1742 looks like a reference -- Missing reference section? '0x0' on line 2228 looks like a reference -- Missing reference section? '0x1' on line 2230 looks like a reference -- Missing reference section? '0' on line 2230 looks like a reference -- Missing reference section? '0x00' on line 2232 looks like a reference -- Missing reference section? '0x0000' on line 2235 looks like a reference -- Missing reference section? 'FCP-2' on line 2823 looks like a reference -- Missing reference section? 'IntServ' on line 2731 looks like a reference -- Missing reference section? 'DiffServ' on line 2733 looks like a reference -- Missing reference section? 'MPLS' on line 2735 looks like a reference -- Missing reference section? 'SAM' on line 2811 looks like a reference -- Missing reference section? 'SAM-2' on line 2813 looks like a reference -- Missing reference section? 'SPC' on line 2816 looks like a reference -- Missing reference section? 'SPC-2' on line 2818 looks like a reference -- Missing reference section? 'FCP' on line 2821 looks like a reference -- Missing reference section? 'FC-FG' on line 2843 looks like a reference -- Missing reference section? 'FC-GS-2' on line 2846 looks like a reference -- Missing reference section? 'FC-AL' on line 2849 looks like a reference -- Missing reference section? 'FC-AL-2' on line 2852 looks like a reference -- Missing reference section? 'FC-PLDA' on line 2855 looks like a reference -- Missing reference section? 'FC-FLA' on line 2858 looks like a reference -- Missing reference section? 'FC-TAPE' on line 2861 looks like a reference -- Missing reference section? 'RFC768' on line 2866 looks like a reference -- Missing reference section? 'RFC791' on line 2868 looks like a reference -- Missing reference section? 'RFC1146' on line 2871 looks like a reference -- Missing reference section? 'RFC2401' on line 2875 looks like a reference -- Missing reference section? 'RFC2402' on line 2877 looks like a reference -- Missing reference section? 'RFC2406' on line 2879 looks like a reference -- Missing reference section? 'RFC2407' on line 2881 looks like a reference -- Missing reference section? 'RFC2408' on line 2883 looks like a reference -- Missing reference section? 'RFC2409' on line 2886 looks like a reference -- Missing reference section? 'RFC2460' on line 2888 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 46 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage Working Group Charles Monia 3 INTERNET DRAFT Rod Mullendore 4 Expires November 2001 Josh Tseng 5 Nishan Systems 7 Franco Travostino 8 Victor Firoiu 9 Nortel Networks 11 David Robinson 12 Sun Microsystems 14 Wayland Jeong 15 Troika Networks 17 Rory Bolt 18 Quantum/ATL 20 Paul Rutherford 21 ADIC 23 Mark Edwards 24 Eurologic 26 May 2001 28 iFCP - A Protocol for Internet Fibre Channel Storage Networking 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance 33 with all provisions of Section 10 of RFC2026 [1]. 35 Internet-Drafts are working documents of the Internet 36 Engineering Task Force (IETF), its areas, and its working 37 groups. Note that other groups may also distribute working 38 documents as Internet-Drafts. Internet-Drafts are draft 39 documents valid for a maximum of six months and may be 40 updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed 48 at http://www.ietf.org/shadow.html. 50 Comments 52 Comments should be sent to the ips mailing list 53 (ips@ece.cmu.edu) or to the author(s). 55 Monia, et al. Standards Track 1 56 Status of this Memo..............................................1 57 Comments.........................................................1 58 1. Abstract................................................4 59 2. About This Document.....................................4 60 2.1 Conventions used in this document.......................4 61 2.2 Purpose of this document................................4 62 3. iFCP Introduction.......................................4 63 3.1 Definitions.............................................5 64 3.2 The iFCP Network Model..................................6 65 3.3 The N_PORT Addressing Model.............................8 66 3.3.1 Operation in Address Transparent Mode.................11 67 3.3.2 Operation in Address Translation Mode.................12 68 3.4 iFCP Layered Services..................................16 69 3.4.1 Application Layer.....................................17 70 3.4.2 FC-4 Layer (FCP)......................................18 71 3.4.3 FC-2 Layer............................................18 72 3.4.4 iFCP Layer............................................18 73 4. iFCP Protocol..........................................19 74 4.1 Overview...............................................19 75 4.1.1 iFCP Transport Services...............................19 76 4.1.2 iFCP Support for Link Services........................19 77 4.2 Mandatory FC-2 Functionality...........................19 78 4.3 FC-2 Functionality Not Supported.......................19 79 4.4 Optional FC-2 Functionality............................20 80 5. TCP Stream Transport of iFCP Frames....................20 81 5.1 TCP Session Model......................................20 82 5.2 IFCP Session Management................................20 83 5.2.1 Creating an N_PORT Login Session......................20 84 5.2.2 Terminating an N_PORT Login Session...................21 85 5.3 TCP Port Numbers.......................................22 86 6. Encapsulation of Fibre Channel Frames..................23 87 6.1 Encapsulation Header Format............................23 88 6.1.1 Common Encapsulation Flags............................25 89 6.2 SOF and EOF Delimiter Fields...........................26 90 6.3 Frame Encapsulation and De-encapsulation...............27 91 7. Link Services..........................................28 92 7.1 Augmented Link Service Messages........................29 93 7.2 Augmented Link Services Requiring Payload Address 94 Translation.....................................................30 95 7.3 Augmented Link Services................................31 96 7.3.1 Abort Exchange (ABTX).................................32 97 7.3.2 Discover Address (ADISC)..............................33 98 7.3.3 Discover Address Accept (ADISC ACC)...................34 99 7.3.4 FC Address Resolution Protocol Reply (FARP-REPLY).....34 100 7.3.5 FC Address Resolution Protocol Request (FARP-REQ).....36 101 7.3.6 Logout (LOGO).........................................37 102 7.3.7 Port Login (PLOGI)....................................37 103 7.3.8 Read Exchange Concise.................................38 104 7.3.9 Read Exchange Concise Accept..........................39 105 7.3.10 Read Exchange Status Block (RES)....................40 106 7.3.11 Read Exchange Status Block Accept...................40 108 Monia Standards Track 2 109 7.3.12 Read Link Error Status (RLS)........................41 110 7.3.13 Read Sequence Status Block (RSS)....................42 111 7.3.14 Reinstate Recovery Qualifier (RRQ)..................43 112 7.3.15 Request Sequence Initiative (RSI)...................43 113 7.3.16 Third Party Process Logout (TPRLO)..................44 114 8. TCP Session Control Messages..........................45 115 8.1 Connection Bind (CBIND)...............................47 116 8.2 Unbind Connection (UNBIND)............................49 117 9. iFCP Error Detection..................................50 118 9.1 Overview..............................................50 119 9.2 Timer Definitions and Stale Frame Detection...........50 120 9.2.1 Error_Detect_Timeout (E_D_TOV).......................50 121 9.2.2 Resource Allocation Timeout (R_A_TOV.................51 122 10. Fabric Services Supported by an iFCP implementation...52 123 10.1 iFCP Support for the FC Broadcast Service.............53 124 11. Security..............................................54 125 11.1 Overview..............................................54 126 11.2 Physical Security.....................................54 127 11.3 Controlling Access....................................54 128 11.4 Authentication and Encryption.........................54 129 11.5 Storage Firewalls.....................................55 130 12. Quality of Service Considerations.....................55 131 12.1 Minimal requirements..................................55 132 12.2 High-assurance........................................55 133 13. References............................................57 134 13.1 Relevant SCSI (T10) Specifications....................57 135 10.2 Relevant Fibre Channel (T11) Specifications.........58 136 10.3 Relevant RFC Documents..............................58 137 10.4 Other Reference Documents...........................59 138 14. Author's Addresses....................................59 139 A. iFCP Support for Fibre Channel Link Services..........61 140 A.1 Basic Link Services...................................61 141 A.2 Link Services Processed Transparently.................61 142 A.3 Augmented Link Services...............................62 143 B. Performance of The Multi-Connection iFCP Session Model 64 144 B.1 Relationship of Throughput to Packet Losses...........64 145 B.2 Background............................................65 146 Full Copyright Statement.......................................67 148 Monia Standards Track 3 149 1. Abstract 151 This document specifies an architecture and gateway-to-gateway 152 protocol for the implementation of Fibre Channel fabric 153 functionality on a network in which TCP/IP switching and 154 routing elements replace Fibre Channel components. The 155 protocol enables the attachment of existing Fibre Channel 156 storage products to an IP network by supporting the fabric 157 services required by such devices. 159 2. About This Document 161 2.1 Conventions used in this document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 164 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described 166 in RFC-2119 [2]. 168 All frame formats are in big endian network byte order. 170 2.2 Purpose of this document 172 This is a standards-track document, which specifies a protocol 173 for the implementation of Fibre Channel transport services on 174 a TCP/IP network. Some portions of this document contain 175 material from standards controlled by NCITS T10 and T11. This 176 material is included here for informational purposes only. The 177 authoritative information is given in the appropriate NCITS 178 standards document. 180 The authoritative portions of this document specify the 181 protocol for mapping standards-compliant fibre Channel storage 182 and adapter implementations to TCP/IP. This mapping includes 183 sections of this document which describe the "iFCP Protocol" 184 (see section 4). 186 3. iFCP Introduction 188 iFCP is a gateway-to-gateway protocol, which provides Fibre 189 Channel fabric services to FCP-based Fibre Channel devices 190 over a TCP/IP network. iFCP uses TCP to provide congestion 191 control, error detection and recovery. iFCP's primary 192 objective is to allow interconnection and networking of 193 existing Fibre Channel devices at wire speeds over an IP 194 network. 196 The protocol and method of frame translation described in this 197 document permit the transparent attachment of Fibre Channel 199 Monia Standards Track 4 200 storage devices to an IP-based fabric by means of lightweight 201 gateways. 203 The protocol achieves this transparency through an address 204 translation process that allows normal frame traffic to pass 205 through the gateway directly, with provisions for intercepting 206 and emulating the fabric services required by an FCP device. 208 3.1 Definitions 210 Terms needed to clarify the concepts presented in this 211 document are presented here. 213 Address-translation mode � A mode of gateway operation in 214 which the scope of N_PORT fabric addresses for locally 215 attached devices are local to the iFCP gateway. 217 Address-transparent mode � A mode of gateway operation in 218 which the scope of N_PORT fabric addresses for all 219 fibre channel devices are unique to the logical fabric 220 to which the gateway belongs. 222 Gateway Region � The portion of the storage network accessed 223 through an iFCP gateway. Devices in the region consist 224 of all fibre channel devices directly attached to the 225 gateway. 227 Logical Fabric � A collection of iFCP gateways configured to 228 interoperate together in address-transparent mode. 230 Fibre Channel Network - A native fibre channel fabric and all 231 attached Fibre Channel devices. 233 Fabric - The part of a Fibre Channel network that provides the 234 transport services defined in the FC-FS specification. 235 A fabric may be implemented in the IP framework by 236 means of the architecture and protocols discussed in 237 this document. 239 FC-2 - The Fibre Channel transport services layer described in 240 the FC-FS specification. 242 FCP Portal - An IP-addressable entity representing the point 243 at which a logical or physical iFCP device is attached 244 to the IP network. 246 N_PORT - An iFCP or Fibre Channel entity representing the 247 interface to Fibre Channel device functionality. This 248 interface implements the Fibre Channel N_PORT 249 semantics specified in the FC-FS standard [FC-FS]. 251 Monia Standards Track 5 252 N_PORT fabric address - The address of an N_PORT within the 253 Fibre Channel fabric. 255 N_PORT Network Address - The address of an N_PORT in the IP 256 fabric. This address consists of the IP address of 257 the FCP Portal and the N_PORT ID of the directly- 258 attached Fibre Channel device. 260 F_PORT - The interface used by an N_PORT to access Fibre 261 Channel fabric and fabric services functionality. 263 iFCP - The protocol discussed in this document. 265 Logical FCP Device - The abstraction representing a single 266 Fibre Channel device as it appears on an iFCP network. 268 iSNS - The protocol by which storage name services are 269 implemented. Resolution of Fibre Channel network 270 object names is provided by an iSNS name server. 272 N_PORT Session - An association created when two N_PORTS have 273 executed a PLOGI operation. It is comprised of the 274 N_PORTs and TCP connection that carries traffic 275 between them. 277 iFCP Frame - The frame inserted into the TCP stream which 278 contains the Fibre Channel frame and iFCP header. 280 Port Login (PLOGI) - The Fibre Channel Extended Link Service 281 (ELS) that establishes an N_PORT login session through 282 the exchange of identification and operation 283 parameters between an originating N_PORT and a 284 responding N_PORT. 286 DOMAIN_ID � The value contained in the high-order byte of a 287 24-bit N_PORT fibre channel address. 289 3.2 The iFCP Network Model 291 The purpose of the iFCP protocol is to enable the 292 implementation if Fibre Channel fabric functionality on an IP 293 network in which IP components and technology replace the 294 fibre channel infrastructure. 296 The following diagram shows a Fibre Channel fabric with 297 attached devices. These are connected to the fabric through 298 N_PORT and F_PORT interfaces, whose behavior is specified in 299 [FGS]. 301 Within the Fibre Channel device domain, fabric-addressable 302 entities consist of other N_PORTs and devices internal to the 303 fabric that perform the fabric services defined in [FGS]. In 305 Monia Standards Track 6 306 this case, the N_PORT Fibre Channel addresses are 24-bit 307 quantities that are unique within the scope of the FC fabric. 308 N_PORTs that perform fabric services are assigned well-known 309 addresses starting at the top end of the 24-bit Fibre Channel 310 address space. 312 Fibre Channel Network 313 +--------+ +--------+ 314 | FC | | FC | 315 | Device | | Device | 316 |........| |........| Fibre Channel 317 | N_PORT |<------>| N_PORT | Device Domain 318 +---+----+ +----+---+ ^ 319 | | | 320 +---+----+ +----+---+ | 321 | F_PORT | | F_PORT | | 322 ==========+========+========+========+============== 323 | Fabric & | | 324 | Fabric Services | v 325 | | Fibre Channel 326 +--------------------------+ Fabric Domain 328 An iFCP Network with iFCP Gateways 330 Fibre Channel Devices Fibre Channel Devices 331 +--------+ +--------+ +--------+ +--------+ 332 | FC | | FC | | FC | | FC | 333 | Device | | Device | Fibre | Device | | Device | Fibre 334 |........| |........| Channel |........| |........| Channel 335 | N_PORT | | N_PORT |<--------->| N_PORT | | N_PORT | Device 336 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 337 | | | | ^ 338 +---+----+ +---+----+ +----+---+ +----+---+ | 339 | F_PORT | | F_PORT | | F_PORT | | F_PORT | | 340 =+========+==+========+===========+========+==+========+========== 341 | iFCP Layer |<--------->| iFCP Layer | | 342 |....................| ^ |....................| | 343 | FCP Portal | | | FCP Portal | v 344 +--------+-----------+ | +----------+---------+ IP 345 | Control | Fabric 346 | Data | 347 | | 348 | | 349 |<------Encapsulated Frames------->| 350 | +------------------+ | 351 | | | | 352 +------+ IP Network +--------+ 353 | | 354 +------------------+ 356 Monia Standards Track 7 357 The above diagram shows the simplest implementation of an 358 equivalent iFCP fabric. Two gateway regions are shown. Each 359 consists of Fibre Channel devices directly connected to the 360 iFCP fabric through F_PORTs implemented as part of the edge 361 switch or gateway. 363 Looking into the F_PORT on the Fibre Channel side of the 364 gateway, the network appears as a Fibre Channel fabric. Here, 365 the gateway presents remote N_PORTs as directly attached 366 devices. Conversely, on the IP network side, the gateway 367 presents each locally connected N_PORT as a logical fibre 368 channel device. 370 An important property of this gateway architecture is that the 371 fabric configuration and topology within the gateway region 372 are opaque to the IP network. That is, the topology in the 373 fibre channel domain, whether it is loop- or switch-based, is 374 hidden from the IP network and from other gateways. 375 Consequently, support for such FC fabric topologies becomes a 376 gateway implementation option. In such cases, the gateway 377 incorporates whatever functionality is required to distil and 378 present locally attached N_PORTs (or NL_PORTs) as logical iFCP 379 devices. 381 N_PORT to N_PORT communications that traverse a TCP/IP network 382 require the intervention of the iFCP layer. This consists of 383 the following operations: 385 a) Execution of the frame addressing and mapping functions 386 described in section 3.3. 388 b) Execution of fabric-supplied link services addressed to 389 one of the well-known Fibre Channel N_PORT addresses. 391 c) Encapsulation of Fibre Channel frames for injection into 392 the TCP/IP network and de-encapsulate Fibre Channel frames 393 received from the TCP/IP network. 395 d) Establishment of an N_PORT login session in response to a 396 PLOGI directed to a remote device. 398 The following sections discuss the frame addressing mechanism 399 and the way in which it is used to achieve communications 400 transparency between N_PORTs. 402 3.3 The N_PORT Addressing Model 404 This section discusses the role of the N_PORT addressing model 405 in the routing of frames between locally and remotely attached 406 N_PORTs. 408 Monia Standards Track 8 409 In the case of a remote N_PORT, where the frame traffic must 410 traverse the IP network, the gateway must perform this routing 411 transparently with respect to the locally attached N_PORT. 413 To provide such transparency, the gateway maintains an 414 association between the fibre channel address of a remote 415 N_PORT, as seen by a locally attached device, and the 416 corresponding address of the remote device on the IP network. 417 To establish this association the iFCP gateway assigns and 418 manages fibre channel N_PORT fabric addresses as described in 419 the following sections. 421 The fabric address of an N_PORT device is a 24-bit value 422 having the following format defined by the fibre channel 423 specification [FCS]: 425 Bit 23 16 15 8 7 0 426 +-----------+------------+----------+ 427 | Domain ID | Area ID | Port ID | 428 +-----------+------------+----------+ 429 Fibre Channel Address Format 431 Such addresses are volatile and subject to change based on 432 modifications in the fabric configuration. 434 In a fibre channel fabric, each switch element has a unique 435 Domain I/D assigned by a master switch. The value of the 436 Domain I/D ranges from 1 to 239 (0xEF). Each switch in turn 437 controls a 65K block of addresses divided into area and port 438 IDs. N_PORTs logging into the fabric receive a unique fabric 439 address consisting of the switch�s Domain I/D concatenated 440 with switch-assigned area and port I/Ds. 442 These N_PORT addresses are carried in the fibre channel frame 443 as shown in the following diagram. 445 Bit 31 24 23 0 446 +--------+-----------------------------------+ 447 Word 0 | | Destination N_PORT Address (D_ID) | 448 +--------+-----------------------------------+ 449 Word 1 | | Source N_PORT Address (S_ID) | 450 +--------+-----------------------------------+ 451 . | | 452 . | Control information | 453 . | and Payload | 454 Word 527 +--------------------------------------------+ 455 (Max) Fibre Channel Address Fields within a Frame 457 The D_ID and S_ID fields represent the fabric addresses of the 458 source and destination N_PORTs respectively. 460 Monia Standards Track 9 461 In an iFCP storage fabric, the iFCP gateway replaces the FC 462 switch element as the device responsible for N_PORT address 463 assignment and frame routing. Unlike an FC switch, however, an 464 iFCP gateway must route frames between N_PORTs within the 465 gateway region or to external devices attached to remote 466 gateways on the IP network. 468 In order to be FC-compatible, the gateway must route such 469 frames using only the embedded 24-bit address. By exploiting 470 its control of address allocation and access to frame traffic 471 entering or leaving the gateway region, it is able to achieve 472 the necessary transparency. 474 The gateway may allocate device addresses in one of two ways: 476 a) Address Transparent Mode � A mode of address assignment in 477 which several gateways collaborate to form a �logical 478 fabric�. Each gateway in control of a region is responsible 479 for obtaining and distributing unique domain I/Ds from the 480 address assignment authority as described in section 481 3.3.1.1. Consequently, within the scope of the logical 482 fabric, the address of each N_PORT is unique. For that 483 reason, gateway-assigned aliases are not required to 484 represent remote N_PORTs. 486 b) Address Translation Mode � A mode of address assignment in 487 which the scope of all N_PORT device addresses, including 488 remote devices, is local to each gateway region. The 489 address of a remote device is represented by a gateway 490 assigned N_PORT alias. 492 All iFCP implementations MUST support operation in address 493 translation mode. Support for address transparent mode is 494 optional. 496 The choice of addressing mode involves the tradeoffs between 497 scalability, and transparency discussed below. 499 The scalability constraints are a consequence of the Fibre 500 Channel address allocation policy described above. As noted, 501 an IP fabric using this address allocation scheme is limited 502 to a combined total of 239 gateways and fibre channel switch 503 elements. As the system expands, an IP fabric may consist of 504 many switch elements distributed throughout the enterprise, 505 each of which controls a small number of devices. In this 506 case, the limitation in switch count may become a barrier to 507 extending and fully integrating the storage network. 509 Address Translation mode avoids this limitation by decoupling 510 N_PORT fabric addresses from the constraints of fabric-wide 511 address space management. Consequently, a virtually unlimited 513 Monia Standards Track 10 514 number of iFCP gateways, Fibre Channel devices and switch 515 elements may be internetworked. This mode of address 516 allocation also simplifies management of the IP storage fabric 517 configuration by eliminating the need for a centralized 518 address-assignment authority. 520 A consequence of address translation mode is that the 24-bit 521 N_PORT address is no longer unique across the storage network. 522 As a result, when processing frame traffic to or from remote 523 N_PORTs, the gateway must intervene to translate the 24-bit 524 N_PORT addresses between the sending and receiving gateways. 525 These address operations involve: 527 a) Translating the N_PORT I/Ds in the frame header and 529 b) Translating N_PORT I/Ds carried in the payload of certain 530 extended link service messages. 532 The process of N_PORT I/D translation for the frame header is 533 described in section 3.3.2. The processing for link services 534 with frame addresses in the payload is described in section 535 7.1. 537 The details of the address transparent and address translation 538 operational modes are discussed in the following sections. 540 3.3.1 Operation in Address Transparent Mode 542 The use of address transparent mode is an alternative where 543 address transparency is desired. In addition to the 544 scalability limits discussed above, the following 545 considerations and requirements pertain to this mode of 546 operation: 548 a) There is increased dependency on the services of a central 549 address assignment authority, such as iSNS. If connectivity 550 with the server is lost, new DOMAIN_ID values cannot be 551 automatically allocated as gateways and fibre channel 552 switch elements are added to the logical fabric. As a 553 result, new gateways and switch elements cannot be 554 automatically added to the ip fabric. Of course, it is 555 always possible to add and manage such additional 556 components manually. 558 b) Coordination of iSNS servers is required. Multiple iFCP 559 gateways set up with independently-administered address 560 servers must be completely torn down and slaved under a 561 single iSNS name server before they can be configured into 562 the same logical fabric. In contrast, operation in address 563 translation mode requires only that the independent iSNS 564 servers import client attributes from other iSNS servers, 566 Monia Standards Track 11 567 before clients under different iSNS authorities can be made 568 to interoperate. 570 c) iFCP gateways in transparent mode will not interoperate 571 with iFCP gateways that are not in transparent mode. 573 d) When interoperating with locally attached Fibre Channel 574 fabrics, the iFCP gateway MUST assume control of DOMAIN_ID 575 assignments in accordance with the appropriate Fibre 576 Channel standard or specification. As described in section 577 3.3.1.1, DOMAIN_ID values assigned to FC switches in 578 attached fabrics must be issued by the iSNS server or 579 manually assigned. 581 e) When operating in address transparent Mode, no fibre 582 channel address translation SHALL take place, and no link 583 service Messages shall be augmented with additional 584 information by the iFCP layer. 586 The process for establishing the TCP/IP context associated 587 with an N_PORT login session in this mode is similar to that 588 specified for address translation mode (section 3.3.2). 590 3.3.1.1 Transparent Mode Domain I/D Management 592 As described above, each gateway and fibre channel switch in a 593 logical fabric must have a unique domain I/D. In a gateway 594 region containing fibre channel switch elements, each element 595 obtains a domain I/D by querying a master switch element as 596 described in [FC-SW] -- in this case the iFCP gateway itself. 597 The gateway in turn may obtain domain I/Ds on demand from a 598 central address allocation authority, such as an iSNS name 599 server or manually from a pre-assigned block of IDs. In that 600 sense, the address authority (e.g., iSNS) assumes the role of 601 master switch for the logical fabric. 603 3.3.1.2 Incompatibility with Address Translation Mode 605 iFCP gateways in address transparent mode shall not originate 606 or accept frames that do not have the TRN bit set to one in 607 the iFCP flags field of the encapsulation header (see section 608 6.1). The iFCP gateway shall immediately terminate any N_PORT 609 sessions with the iFCP gateway from which it receives such 610 frames. 612 3.3.2 Operation in Address Translation Mode 614 This section summarizes the process for modifying FC frame 615 addresses embedded in the frame header. 617 Monia Standards Track 12 618 As described above, the iFCP gateway is responsible for 619 assigning Fibre Channel N_PORT addresses to locally and 620 remotely attached N_PORTs. 622 For remotely attached N_PORTs, the gateway assigns an N_PORT 623 alias used in place of the N_PORT address assigned by the 624 remote gateway. To perform this function and enable the 625 appropriate routing, the gateway builds and maintains a table 626 that maps N_PORT aliases to the appropriate TCP/IP connection 627 and N_PORT ID of all external N_PORTs. 629 The gateway opportunistically builds the store of N_PORT 630 addresses and TCP/IP connections for remotely attached devices 631 in the IP fabric by: 633 a) Intercepting name service requests issued by locally- 634 attached N_PORTs as described below or, 636 b) Intercepting incoming N_PORT login requests from external 637 Fibre Channel devices and outgoing N_PORT login requests 638 directed to remote N_PORTs. Such requests are used to 639 establish the N_PORT login session as described in section 640 5.1. 642 In response to name server requests, the iSNS server returns 643 the IP address and N_PORT ID pair of the remote device. The IP 644 address is mapped to the connection context. After saving the 645 context and N_PORT ID, the iFCP layer creates the 24-bit 646 N_PORT alias that is returned to the local N_PORT as the Fibre 647 Channel address of the external device. 649 3.3.2.1 Translation Table Maintenance 651 The contents of the gateway�s address translation tables are 652 updated opportunistically, in response to the name service 653 queries and PLOGI requests described previously. There is no 654 need to invalidate entries in response to changes in the 655 fabric configuration, since any potentially stale entries 656 caused by such events are self-correcting as described below. 658 Once a fabric has achieved steady-state operation, any event 659 that causes a change in the fibre channel address of a device 660 also causes the device to terminate all N_PORT sessions. In 661 the process of resuming operation, the status of the device, 662 including its new address, is reflected in the name server�s 663 database. The new state of the device is advertised using the 664 appropriate state change notifications. These, in turn, 665 trigger the series of port login operations described below. 667 For inbound PLOGI requests, the iFCP gateway simply updates 668 the translation table, generates the N_PORT alias and forwards 670 Monia Standards Track 13 671 the request to the local N_PORT for processing as described 672 above. 674 For outbound requests, a fabric-attached fibre channel device 675 usually precedes the PLOGI with a name server query to obtain 676 the device�s new N_PORT address. At this point, the iFCP 677 gateway intercepts such a request, performs the necessary iSNS 678 query, creates the translation table entry and returns the 679 assigned N_PORT alias to the requester. 681 After issuing the PLOGI, the N_PORT verifies that it has 682 logged in with the expected device by checking the device name 683 returned in the PLOGI response. 685 An N_PORT that attempts to execute a PLOGI without first 686 querying the name server is still required to confirm the 687 device name as described above. 689 3.3.2.2 Frame Address Translation 691 For outbound frames, the table of external N_PORT network 692 addresses are referenced to map the Destination N_PORT alias 693 and Source N_PORT ID to a TCP connection identifier and the 694 N_PORT ID assigned by the remote gateway. The translation 695 process for outbound frames is shown below. 697 Monia Standards Track 14 698 Raw Fibre Channel Frame 699 +--------+-----------------------------------+ +--------------+ 700 | | Destination N_PORT Alias |--->| Lookup TCP | 701 +--------+-----------------------------------+ | connection | 702 | | Source N_PORT ID |--->| and N_PORT ID| 703 +--------+-----------------------------------+ +------+-------+ 704 | | | TCP 705 | Control information | | Conn 706 | and Payload | | & 707 +--------------------------------------------+ | N_PORT 708 | ID 709 | 710 After Address Translation and TCP/IP Encapsulation | 711 +--------------------------------------------+ Conn | 712 | iFCP Encapsulation |<----------+ 713 | Header | Context | 714 +========+===================================+ | 715 | | Destination N_PORT ID |<----------+ 716 +--------+-----------------------------------+ 717 | | Source N_PORT ID | 718 +--------+-----------------------------------+ 719 | | 720 | Control information | 721 | and Payload | 722 +--------------------------------------------+ 724 For inbound frames, the store regenerates the N_PORT alias 725 from the TCP connection context and N_PORT ID contained in the 726 encapsulated FC frame. The translation process for inbound 727 frames is shown below. 729 Monia Standards Track 15 730 Network Format of Inbound Frame 731 +--------------------------------------------+ Conn. +--------+ 732 | iFCP Encapsulation Header |------>| N_PORT | 733 | |Context| Alias | 734 +========+===================================+ | Lookup | 735 | | Destination N_PORT ID | | | 736 +--------+-----------------------------------+ | | 737 | | Source N_PORT ID |------>| | 738 +--------+-----------------------------------+ +----+---+ 739 | | |N_PORT 740 | Control information | |Alias 741 | and Payload | | 742 +--------------------------------------------+ | 743 | 744 | 745 | 746 Frame after Address Translation and De-encapsulation | 747 +--------+-----------------------------------+ | 748 | | Destination N_PORT ID | | 749 +--------+-----------------------------------+ | 750 | | Source N_PORT Alias |<-----------+ 751 +--------+-----------------------------------+ 752 | | 753 | Control information | 754 | and Payload | 755 +--------------------------------------------+ 757 3.3.2.3 Incompatibility with Address Transparent Mode 759 iFCP gateways in address translation mode shall not originate 760 or accept frames that have the TRN bit set to one in the iFCP 761 flags field of the encapsulation header. The iFCP gateway 762 shall immediately abort any N_PORT login sessions with the 763 iFCP gateway from which it receives such frames as described 764 in section 5.2.2.2. 766 3.4 iFCP Layered Services 768 The following diagram shows the functional layers for host 769 devices that support FCP. 771 As shown, iFCP provides a set of layered services that 772 transparently provide the transport services required by FCP 773 devices. Using the iFCP framework, any existing host FCP 774 implementation will execute with no modifications required. 776 The iFCP protocol layer consists of the data transport 777 services and iFCP-specific Link Services. This layer provides 778 transport services specific to Fibre Channel devices as 779 specified in [FC-PH], [FC-PH-2], and [FC-PH-3]. 781 Monia Standards Track 16 782 This is illustrated in the following diagram, which shows the 783 IP Fabric consisting of the TCP/IP network and the iFCP Layer. 784 The IP Fabric provides the transport services for FCP, and is 785 a direct replacement for the transport services provided by a 786 Fibre Channel fabric. Meanwhile, the components in the Fibre 787 Channel Device Domain remain unchanged. 789 +---------------------------------------+ - - - - - - - 790 | Storage & Backup Applications | 791 +---------------------------------------+ 792 | Operating System | Application 793 +--------------------+ | Layer 794 | SCSI | | 795 +--------------------+ | - - - - - - - 796 | FCP | | FC-4 Layer 797 +------------+-------+------------------+ - - - - - - - 798 | | Link Services | 799 | +--------------------------+ FC-2 Layer ^ 800 | | | 801 | N_PORT - F_PORT Interface | Fibre Channel 802 | | Device Domain 803 <=============================================================> 804 | | IP Fabric 805 | iFCP Data Transport Service | | 806 | | v 807 | +---------------+ 808 | |iFCP Specific | iFCP Layer 809 | |Link Services | 810 +-----------------------+---------------+ - - - - - - 811 | | 812 | TCP | Transport 813 | | Layer 814 +---------------------------------------+ - - - - - - 815 | | 816 | IP | Network 817 | | Layer 818 +---------------------------------------+ - - - - - - 819 | | 820 | Physical Transport | Link Layer 821 | | 822 +---------------------------------------+ - - - - - - 824 In the figure shown above, each layer leverages the services 825 of the layer below it. 827 3.4.1 Application Layer 829 This includes the operating system, Storage and Backup 830 applications, and the SCSI driver. This layer interfaces with 831 FCP and Link Services in the FC-2 and FC-4 layers. 833 Monia Standards Track 17 834 3.4.2 FC-4 Layer (FCP) 836 FCP is the Fibre Channel FC-4 layer application protocol used 837 to communicate with devices implementing the SCSI-3 command 838 set and architectural model. Basically, FCP divides each SCSI 839 I/O operation into a series of information units to be 840 transferred between the initiator and target. 842 3.4.3 FC-2 Layer 844 The FC-2 Layer provides the facilities for Link Services and 845 transfer of Fibre Channel information units as described 846 below. 848 3.4.3.1 Link Service Messages 850 Fibre Channel defines a series of link services defined in 851 Fibre Channel Physical and Signaling Interface specification 852 (FC-PH, FC-PH-2, FC-PH-3). These Link Service Messages 853 provide a set of defined functions that allow a Fibre Channel 854 port to send control information, or to request another port 855 to perform a specific function. Some Link Service messages 856 reference services provided internally within the Fibre 857 Channel fabric. 859 3.4.3.2 N_PORT Interface 861 This is an interface which provides access to Fibre Channel 862 device functionality. The N_PORT interface is responsible for 863 segmentation and reassembly of information units from Fibre 864 Channel frames. 866 3.4.3.3 F_PORT Interface 868 This is the interface through which the N_PORT accesses the 869 Fibre Channel fabric. 871 3.4.4 iFCP Layer 873 The iFCP layer provides three essential services for FCP-based 874 storage products: 876 a) Transport of Fibre Channel frames and Link Service 877 messages between N_PORTs 879 b) Support for special Link Service messages needed by iFCP 880 to manage the transmission of storage data on a IP 881 network. 883 c) Augmentation of some Link Service messages with additional 884 data needed in the iFCP environment. 886 Monia Standards Track 18 887 The iFCP layer maps Fibre Channel frames to a predetermined 888 TCP connection for transport. Additionally, many link service 889 messages can similarly be transported without modification 890 over a TCP connection. 892 4. iFCP Protocol 894 4.1 Overview 896 4.1.1 iFCP Transport Services 898 The iFCP transport services map the Fibre Channel frames 899 comprising each FCP IU and Link Service message to a 900 predetermined TCP connection for transport across an IP 901 network. When receiving FCP-based storage data from the 902 network, the iFCP layer transports, and delivers each 903 resulting frame to the appropriate N_PORT. Except for the 904 augmented ELS requests in section 7.1, the iFCP layer never 905 interprets the contents of the frame payload. 907 For incoming iFCP frames with control data, iFCP interprets 908 the augmented information, modifies the frame content 909 accordingly, and may forward the resulting frame to the N_PORT 910 for further processing. 912 For out-bound Fibre Channel frames that require control data, 913 the iFCP layer creates the augmented information based on 914 frame content, modifies the frame content, then transmits the 915 resulting Fibre Channel frame with augmented data through the 916 appropriate TCP connection. 918 4.1.2 iFCP Support for Link Services 920 Some Link Service messages contain N_PORT addresses in the 921 payload. When a gateway operating in address translation mode 922 encounters such messages, it will augment the information in 923 the payload by adding additional information. The receiving 924 gateway will reference the augmented information in order to 925 reconstruct the original Link Service message. The 926 reconstructed frames are then forwarded to the receiving 927 N_PORT for further processing. 929 Section 7.1 describes augmented Link Services in detail. 931 4.2 Mandatory FC-2 Functionality 933 [To be specified] 935 4.3 FC-2 Functionality Not Supported 937 [To be specified] 939 Monia Standards Track 19 940 4.4 Optional FC-2 Functionality 942 [To be specified] 944 5. TCP Stream Transport of iFCP Frames 946 TCP connections MAY be established between FCP_Portals that 947 have discovered each other through a naming service or through 948 manual configuration. If a TCP connection is not maintained 949 between the FCP_Portals, then a change in the status of remote 950 N_PORTs must be discovered through a central name server 951 authority. 953 Multiple TCP connections may exist between pairs of FCP 954 Portals. Such connections are either "bound" or "unbound". 955 An unbound connection is a TCP connection that is not actively 956 supporting an N_PORT login session. Pre-existing TCP 957 connections between FCP Portals remain unbound and uncommitted 958 until a CBIND message (see section 7.2.2) has been transmitted 959 through them. 961 When the iFCP layer detects a Port Login (PLOGI) message 962 creating a login session between a pair of N_PORTs, it will 963 select an existing unbound TCP connection or establish a new 964 TCP connection, and send the CBIND message down that TCP 965 connection. This allocates the TCP connection to that PLOGI 966 login session. A TCP connection may not be bound to more than 967 one N_PORT login session. 969 5.1 TCP Session Model 971 iFCP uses a single TCP connection to transport all Fibre 972 Channel frames between unique pairs of N_PORTs. A TCP 973 connection may be used by one and only one N_PORT login 974 session. 976 5.2 IFCP Session Management 978 This section describes the protocols for establishing and 979 terminating an N_PORT login session. One and only one N_PORT 980 login session SHALL exist between an N_PORT pair. 982 5.2.1 Creating an N_PORT Login Session 984 The gateway SHALL initiate the creation of an N_PORT login 985 session in response to a PLOGI ELS directed to a remote N_PORT 986 from a locally attached N_PORT as described in the following 987 steps. 989 a) Allocate a TCP connection to the remote gateway. An 990 existing connection in the Unbound state may be used or a 992 Monia Standards Track 20 993 new connection may be created and placed in the Unbound 994 state. 996 b) If a connection cannot be allocated or created, the gateway 997 SHALL terminate the PLOGI with an LS_RJT response. The 998 Reason Code field in the LS_RJT message shall be set to 999 0x09 (Unable to Perform Command Request) and the Reason 1000 Explanation SHALL be set to 0x29 (Insufficient Resources to 1001 Support Login). 1003 c) If an N_PORT login session already exists to the remote 1004 N_PORT, the gateway SHALL forward the PLOGI ELS using the 1005 existing session. 1007 d) If the N_PORT login session does not exist, the gateway 1008 SHALL issue a CBIND session control message (see section 0) 1009 to allocate the connection and SHALL place the connection 1010 in the Bound state if successful. 1012 e) In the event that the CBIND message fails, the PLOGI shall 1013 be terminated with an LS_REJ message. Depending on the 1014 CBIND failure status, the Reason Code and Reason 1015 Explanation SHALL be set as shown in the following table. 1017 CBIND Failure LS_RJT Reason LS_RJT Reason Code 1018 Status Code Explanation 1019 ------------- ------------- ------------------ 1021 Unspecified Unable to Perform No additional 1022 Reason (0x10) Command Request explanation (0x00) 1023 (0x0D) 1025 No Such Device Unable to Perform Invalid N_PORT Name 1026 (0x11) Command Request (0x0D). 1027 (0x0D) 1029 N_PORT Login Unable to Perform Invalid N_PORT Name 1030 Session Already Command Request (0x0D). 1031 Exists (0x12) (0x0D) 1033 Lack of Unable to Perform Insufficient 1034 Resources (0x13) Command Request Resources to Support 1035 (0x0D). Login (0x29). 1037 5.2.2 Terminating an N_PORT Login Session 1039 An N_PORT login session SHALL be terminated or aborted in 1040 response to one of the following events: 1042 a) An LS_RJT response is returned to the gateway that issued 1043 the PLOGI ELS. The gateway shall forward the LS_RJT to 1045 Monia Standards Track 21 1046 the local N_PORT and complete the session as described in 1047 section 5.2.2.1. 1049 b) An ACC received from a remote device in response to a 1050 LOGO. The gateway shall forward the ACC to the local 1051 N_PORT and complete the session as described in section 1052 5.2.2.1. 1054 c) For an FC frame received from the IP network, a gateway 1055 detects a CRC error in the encapsulation header. The 1056 gateway shall abort the session as described in section 1057 5.2.2.2. 1059 d) The TCP connection associated with the login session fails 1060 for any reason. The gateway detecting the failed 1061 connection shall abort the session as described in section 1062 5.2.2.2. 1064 5.2.2.1 N_PORT Login Session Completion 1066 An N_PORT login session is completed in response to a rejected 1067 PLOGI request or a successful LOGO ELS. 1069 The gateway receiving one of the above responses shall issue 1070 an Unbind session control ELS as described in section 8.2. An 1071 Unbind error shall be considered a fatal gateway error. 1073 In response to the Unbind message, either gateway may choose 1074 to close the connection or return it to the pool of unbound 1075 connections. 1077 5.2.2.2 Aborting an N_PORT Login Session 1079 An N_PORT login session SHALL be aborted if the TCP connection 1080 is spontaneously terminated or for any other reason described 1081 in this specification. 1083 In any event, the TCP connection shall be closed. If the 1084 local N_PORT has logged in to the remote N_PORT, the gateway 1085 SHALL send a LOGO to the local N_PORT. 1087 5.3 TCP Port Numbers 1089 An FCP Portal uses a single port number to receive TCP 1090 connection requests for iFCP over TCP. All TCP connections 1091 established between FCP Portals must be directed to the 1092 registered well known port number assigned by the IANA. 1094 An FCP Portal may use any TCP port number consistent with its 1095 implementation of the TCP/IP stack to initiate a TCP 1096 connection, but each port number must be unique. 1098 Monia Standards Track 22 1099 6. Encapsulation of Fibre Channel Frames 1101 This section describes the iFCP encapsulation of Fibre Channel 1102 frames. The encapsulation is based on the common 1103 encapsulation format defined in [ENCAP]. 1105 The format of an encapsulated frame is shown below: 1107 +--------------------+ 1108 | Header | 1109 +--------------------+-----+ 1110 | SOF | f | 1111 +--------------------+ F r | 1112 | FC frame content | C a | 1113 +--------------------+ m | 1114 | EOF | e | 1115 +--------------------+-----+ 1116 Encapsulation Format 1118 As shown, the encapsulation consists of a 7-word header, an 1119 SOF delimiter word, the FC frame (including the fibre channel 1120 CRC), and an EOF delimiter word. The header and delimiter 1121 formats are described in the following sections. 1123 6.1 Encapsulation Header Format 1125 W|------------------------------Bit------------------------------| 1126 o| | 1127 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1128 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| 1129 +---------------+---------------+---------------+---------------+ 1130 0| Protocol# | Version | -Protocol# | -Version | 1131 +---------------+---------------+---------------+---------------+ 1132 1| Reserved (must be zero) | 1133 +---------------+---------------+---------------+---------------+ 1134 2| LS_COMMAND | iFCP Flags | SOF | EOF | 1135 +-----------+---+---------------+-----------+---+---------------+ 1136 3| Flags | Frame Length | -Flags | -Frame Length | 1137 +-----------+-------------------+-----------+-------------------+ 1138 4| Time Stamp [integer] | 1139 +---------------------------------------------------------------+ 1140 5| Time Stamp [fraction] | 1141 +---------------------------------------------------------------+ 1142 6| CRC | 1143 +---------------------------------------------------------------+ 1145 Common Encapsulation Fields: 1147 Monia Standards Track 23 1148 Protocol# IANA-assigned protocol number 1149 identifying the protocol using the 1150 encapsulation. For iFCP the value is 1151 (/TBD/). 1153 Version Encapsulation version 1155 -Protocol# Ones complement of the protocol# 1157 -Version Ones complement of the version 1159 Flags Encapsulation flags (see 6.1.1) 1161 Frame Length Contains the length of the entire FC 1162 Encapsulated frame including the FC 1163 Encapsulation Header and the FC frame 1164 (including SOF and EOF words) in units 1165 of 32-bit words. 1167 -Flags Ones-complement of the Flags field. 1169 -Frame Length Ones-complement of the Frame Length 1170 field. 1172 Time Stamp [integer] Integer component of the frame time 1173 stamp in SNTP format [SNTP]. 1175 Time Stamp Fractional component of the time stamp 1176 [fraction] in SNTP format [SNTP]. 1178 CRC Header CRC. MUST be valid for iFCP. 1180 The time stamp fields are used to enforce the limit on the 1181 lifetime of a fibre channel frame as described in section 1182 9.2.2.1. 1184 iFCP-specific fields: 1186 Monia Standards Track 24 1187 LS_COMMAND For an augmented ELS ACC response, the 1188 LS_COMMAND field SHALL contain bits 31 1189 through 24 of the LS_COMMAND to which 1190 the ACC applies. Otherwise the 1191 LS_COMMAND field shall be set to zero. 1193 IFCP Flags IFCP-specific flags (see below) 1195 SOF Copy of the SOF delimiter encoding 1196 (see section 6.2) 1198 EOF Copy of the EOF delimiter encoding 1199 (see section 6.2) 1201 The iFCP flags word has the following format: 1203 |------------------------Bit----------------------------| 1204 | | 1205 | 23 22 21 20 19 18 17 16 | 1206 +------+------+------+------+------+------+------+------+ 1207 | CPL | Reserved | SES | TRN | AUG | 1208 +------+------+------+------+------+------+------+------+ 1210 iFCP Flags: 1212 CPL Compliance level: 1214 1 = Encapsulation complies with draft 1215 standard or RFC of iFCP or the 1216 encapsulation specification 1218 0 = Encapsulation complies with 1219 standards track version of iFCP or 1220 the encapsulation specification 1222 SES 1 = Session control frame (TRN and AUG MUST be 1223 0) 1225 TRN 1 = Address transparent mode enabled 1227 0 = Address translation mode enabled 1229 AUG 1 = Augmented frame. 1231 6.1.1 Common Encapsulation Flags 1233 The iFCP usage of the common encapsulation flags is shown 1234 below: 1236 Monia Standards Track 25 1237 |------------------------Bit--------------------------| 1238 | | 1239 | 31 30 29 28 27 26 | 1240 +--------------------------------------------+--------+ 1241 | Reserved | CRCV | 1242 +--------------------------------------------+--------+ 1244 For iFCP, the CRC field MUST be valid and CRCV MUST be set to 1245 one. 1247 6.2 SOF and EOF Delimiter Fields 1249 The format of the delimiter fields is shown below. 1251 W|------------------------------Bit------------------------------| 1252 o| | 1253 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1254 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| 1255 +---------------+---------------+-------------------------------+ 1256 0| SOF | SOF | -SOF | -SOF | 1257 +---------------+---------------+-------------------------------+ 1258 1| | 1259 +----- FC frame content -----+ 1260 | | 1261 +---------------+---------------+-------------------------------+ 1262 n| EOF | EOF | -EOF | -EOF | 1263 +---------------+---------------+-------------------------------+ 1265 FC Frame Encapsulation Format 1267 SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields 1268 contain the encoded SOF value selected from the table below. 1270 +-------+----------+ 1271 | FC | | 1272 | SOF | SOF Code | 1273 +-------+----------+ 1274 | SOFf | 0x28 | 1275 | SOFi2 | 0x2D | 1276 | SOFn2 | 0x35 | 1277 | SOFi3 | 0x2E | 1278 | SOFn3 | 0x36 | 1279 +-------+----------+ 1281 Translation of FC SOF 1282 values to SOF field contents 1284 -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain 1285 the ones complement of the value in the SOF fields. 1287 Monia Standards Track 26 1288 EOF (bits 31-24 and 23-16 in word n): The EOF fields contain 1289 the encoded EOF value selected from the table below. 1291 +-------+----------+ 1292 | FC | | 1293 | EOF | EOF Code | 1294 +-------+----------+ 1295 | EOFn | 0x41 | 1296 | EOFt | 0x42 | 1297 | EOFni | 0x49 | 1298 | EOFa | 0x50 | 1299 +-------+----------+ 1301 Translation of FC EOF values 1302 to EOF field contents 1304 -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain 1305 the one's complement of the value in the EOF fields. 1307 iFCP implementations shall place a copy of the SOF and EOF 1308 delimiter codes in the appropriate header fields. 1310 6.3 Frame Encapsulation and De-encapsulation 1312 When encapsulating a frame, the frame originator MUST fill in 1313 the header and the SOF and EOF delimiter words as specified 1314 above. 1316 The receiving gateway SHALL perform de-encapsulation as 1317 follows: 1319 Upon receiving the encapsulated frame, the gateway SHALL check 1320 the header CRC. If the CRC is invalid, the gateway SHALL 1321 terminate the N_PORT login session as described in section 1322 5.2.2.2. 1324 If the CRC is valid, any additional header validity checks are 1325 optional. If a header check is unsuccessful, the N_PORT login 1326 session SHALL be terminated as described in section 5.2.2.2. 1327 After header validation, the receiving gateway MAY generate 1328 the FC frame delimiters by: 1330 a) Using the EOF and SOF codes in the encapsulation header or 1332 b) By referencing the SOF and EOF delimiter words. 1334 If the EOF and SOF delimiter words are used, the gateway must 1335 validate the delimiter contents by verifying that the code is 1336 legal and that the delimiter contents conform to the formats 1337 shown above. If an invalid delimiter is detected, the gateway 1338 SHALL terminate the N_PORT login session as specified in 1339 section5.2.2.2. 1341 Monia Standards Track 27 1342 If the EOF and SOF in the header are used, the gateway MAY 1343 ignore the contents of the delimiter words. The gateway 1344 SHOULD verify that the SOF and EOF codes in the header are 1345 legal. If an illegal code is detected, the gateway shall 1346 terminate the N_PORT login session as specified in section 1347 5.2.2.2. 1349 After validating the encapsulation, the receiving gateway MAY 1350 verify the frame propagation delay as described in section 1351 9.2.2.1. 1353 7. Link Services 1355 Link services provide a set of functions that allow a port to 1356 send control information or request another port to perform a 1357 specific function. 1359 Each Link Service message (response and reply) is carried by a 1360 Fibre Channel sequence, and can be segmented into multiple 1361 frames. 1363 The iFCP Layer is responsible for transporting Link Service 1364 messages across the IP fabric. This includes mapping Link 1365 Service messages appropriately from the domain of the Fibre 1366 Channel transport to that of the IP network. This process may 1367 involve manipulation of field values as the Link Service 1368 message travels to and from the IP and Fibre Channel fabrics. 1369 It also may also require the inclusion of augmented data by 1370 the iFCP layer. 1372 Each link service or extended link service is processed 1373 according to one of the following rules: 1375 a) Transparent � The link service message and reply MUST be 1376 transported to the receiving N_PORT by the iFCP gateway 1377 without altering the message payload. The link service 1378 message and reply are not processed by the iFCP 1379 implementation. 1381 b) Augmented - Applies to an extended link service reply or 1382 request containing fibre channel addresses in the payload 1383 or requiring other special processing by the iFCP 1384 implementation. The processing for augmented link services 1385 is described in this section. 1387 c) Rejected � When issued by a directly attached N_PORT, the 1388 specified link service request MUST be rejected by the iFCP 1389 implementation. The gateway SHALL respond to a rejected 1390 link service message by returning an LS_RJT response with a 1391 Reason Code of 0x0B (Command Not Supported) and a Reason 1392 Code Explanation of 0x0 (No Additional Explanation). 1394 Monia Standards Track 28 1395 This section describes the processing for augmented link 1396 services, including the manner in which augmentation data is 1397 transmitted over the IP network. 1399 Appendix A enumerates all link services and the iFCP 1400 processing policy that applies to each. 1402 7.1 Augmented Link Service Messages 1404 Augmentation applies to extended link service requests that 1405 require the intervention of the iFCP layer. Such intervention 1406 is required in order to: 1408 a) Service any ELS that requires special handling, such as a 1409 PLOGI. 1411 b) In address translation mode only, service any ELS which has 1412 an N_PORT address in the payload. 1414 Such ELS messages are transmitted in a fibre channel frame 1415 having the following format: 1417 Word 1418 31<-bit>24 23<------------------Bit---------------------->0 1419 +----------+------------------------------------------------+ 1420 0| R_CTL | D_ID | 1421 | [22] | [Destination of extended link Service request] | 1422 +----------+------------------------------------------------+ 1423 1| CS_CTL | S_ID | 1424 | | [Source of extended link service request] | 1425 +----------+------------------------------------------------+ 1426 2| TYPE | F_CTL | 1427 +----------+------------------+-----------------------------+ 1428 3| SEQ_ID | DF_CTL | SEQ_CNT | 1429 +----------+------------------+-----------------------------+ 1430 4| OX_ID | RX_ID | 1431 +-----------------------------+-----------------------------+ 1432 5| Parameter | 1433 | [ 00 00 00 00 ] | 1434 +-----------------------------------------------------------+ 1435 6| LS_COMMAND | 1436 | [Extended Link Service Command Code] | 1437 +-----------------------------------------------------------+ 1438 7| | 1439 .| Additional Service Request Parameters | 1440 .| ( if any ) | 1441 n| | 1442 +-----------------------------------------------------------+ 1443 Format of ELS Frame 1445 Monia Standards Track 29 1446 7.2 Augmented Link Services Requiring Payload Address 1447 Translation 1449 This section describes the handling for ELS frames containing 1450 N_PORT addresses in the ELS payload. Such addresses SHALL only 1451 be translated when the gateway is operating in address 1452 translation mode. When operating in address transparent mode, 1453 these addresses SHALL NOT be translated and such ELS messages 1454 SHALL not be sent as augmented frames unless other special 1455 processing is required. 1457 Supplemental data includes information required by the 1458 receiving gateway to convert an N_PORT address in the payload 1459 to an N_PORT address in the receiving gateway�s address 1460 space. The following rules define the manner in which such 1461 supplemental data is packaged and referenced. 1463 For an N_PORT address field, the gateway originating the frame 1464 MUST set the value in the payload to identify the address 1465 translation type as follows: 1467 0x00 00 00 � The gateway receiving the frame from the IP 1468 network MUST reference the augmentation data to set the 1469 field contents as described below. The augmentation 1470 information is the 64-bit world wide identifier of the 1471 N_PORT as set forth in the fibre channel specification. If 1472 not otherwise part of the ELS, this information MUST be 1473 appended as described below. This translation type SHALL 1474 NOT be used when the address to be converted corresponds 1475 to that of the frame originator or recipient. 1477 0x00 00 01 � The gateway receiving the frame from the IP 1478 network MUST replace the contents of the field with the 1479 N_PORT alias of the frame originator. This translation 1480 type MUST be used when the address to be converted is 1481 that of the source N_PORT. 1483 0x00 00 02 � The gateway receiving the frame from the IP 1484 network MUST replace the contents of the field with the 1485 N_PORT I/D of the destination N_PORT. This translation 1486 type MUST be used when the address to be converted is that 1487 of the destination N_PORT 1489 Since fibre channel addressing rules prohibit the assignment 1490 of fabric addresses with a domain I/D of 0, the above codes 1491 will never correspond to valid N_PORT fabric IDs. 1493 For translation type 0, the receiving gateway SHALL obtain the 1494 information needed to fill in the ELS field by converting the 1495 specified N_PORT world-wide identifier to a gateway IP address 1496 and N_PORT ID. This information MUST be obtained through a 1497 name server query. If the N_PORT is locally attached, the 1499 Monia Standards Track 30 1500 gateway MUST fill in the field with the N_PORT ID. If the 1501 N_PORT is remotely attached, the gateway MUST assign and fill 1502 in the field with an N_PORT alias. If an N_PORT alias has 1503 already been assigned, it MUST be reused. 1505 In the event that the sending gateway cannot obtain the world 1506 wide identifier of an N_PORT, or a receiving gateway cannot 1507 obtain the IP address and N_PORT ID, the gateway detecting the 1508 error SHALL terminate the request with an LS_RJT message as 1509 described in [FCS]. The Reason Code SHALL be set to 0x07 1510 (protocol error) and the Reason Explanation SHALL be set to 1511 0x1F (Invalid N_PORT identifier). 1513 [Editor�s note: Such errors, when detected by the receiving 1514 gateway, may be indicative of a serious problem requiring a 1515 more drastic response. Therefore, this section should be 1516 regarded as tentative.] 1518 Supplemental data is sent with the ELS request or ACC frames 1519 in one of the following ways: 1521 a) By appending the necessary data to the end of the ELS 1522 frame. 1524 b) By extending the sequence through the addition of 1525 additional frames. 1527 In the first case, a new frame SHALL be created whose length 1528 includes the supplemental data. The procedure for extending 1529 the ELS sequence with additional frames is /TBS/. 1531 After applying the supplemental data, the receiving gateway 1532 SHALL forward the resulting ELS to the destination N_PORT with 1533 the supplemental information removed. 1535 When the ACC response must be augmented, the receiving gateway 1536 must act as a proxy for the originator, retaining the state 1537 needed to process the response from the N_PORT to which the 1538 request was directed. 1540 7.3 Augmented Link Services 1542 The following Link Service Messages must receive special 1543 processing or be supplemented with additional control data. 1544 When the iFCP header encapsulates one of these Extended Link 1545 Service messages in the iFCP payload, the AUG bit must be set 1546 to one in the iFCP FLAGS field as specified in section 6.1 and 1547 the supplemental data (if any) must be appended as described 1548 in the following section. An ELS ACC frame that is augmented 1549 must be similarly formatted. 1551 Monia Standards Track 31 1552 Link Service Message LS_COMMAND Mnemonic 1553 -------------------- ---------- -------- 1554 Abort Exchange 0x06 00 00 00 ABTX 1555 Discover Address 0x52 00 00 00 ADISC 1556 Discover Address Accept 0x02 00 00 00 ADISC ACC 1557 FC Address Resolution Protocol 0x55 00 00 00 FARP-REPLY 1558 Reply 1559 FC Address Resolution Protocol 0x54 00 00 00 FARP-REQ 1560 Request 1561 Logout 0x05 00 00 00 LOGO 1562 Port Login 0x30 00 00 00 PLOGI 1563 Read Exchange Concise 0x13 00 00 00 REC 1564 Read Exchange Concise Accept 0x02 00 00 00 REC ACC 1565 Read Exchange Status Block 0x08 00 00 00 RES 1566 Read Exchange Status Block 0x02 00 00 00 RES ACC 1567 Accept 1568 Read Link Error Status Block 0x0F 00 00 00 RLS 1569 Read Sequence Status Block 0x09 00 00 00 RSS 1570 Reinstate Recovery Qualifier 0x12 00 00 00 RRQ 1571 Request Sequence Initiative 0x0A 00 00 00 RSI 1572 Third Party Process Logout 0x24 00 00 00 TPRLO 1574 The formats of each augmented ELS, including supplemental data 1575 where applicable, are shown in the following sections. Each 1576 ELS diagram shows the basic format, as specified in the 1577 applicable FC standard, followed by supplemental data as shown 1578 below. 1580 +------+------------+------------+-----------+----------+ 1581 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1582 +------+------------+------------+-----------+----------+ 1583 | 0 | LS_COMMAND | 1584 +------+------------+------------+-----------+----------+ 1585 | 1 | | 1586 | . | | 1587 | . | ELS Payload | 1588 | | | 1589 | n | | 1590 +======+============+============+===========+==========+ 1591 | n+1 | | 1592 | . | Supplemental Data | 1593 | . | (if any) | 1594 | n+k | | 1595 +======+================================================+ 1596 ELS Diagram (single FC Frame Format) 1598 7.3.1 Abort Exchange (ABTX) 1600 ELS Format: 1602 Monia Standards Track 32 1603 +------+------------+------------+-----------+----------+ 1604 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1605 +------+------------+------------+-----------+----------+ 1606 | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | 1607 +------+------------+------------+-----------+----------+ 1608 | 1 | RRQ Status | Exchange Originator S_ID | 1609 +------+------------+------------+-----------+----------+ 1610 | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| 1611 +------+------------+------------+-----------+----------+ 1612 | 3-10 | Optional association header (32 bytes | 1613 +======+============+============+===========+==========+ 1615 Fields Requiring Translation Supplemental Data 1616 Address Translation Type (see (type 0 only) 1617 ------------------- section 7.2) ------------ 1618 ----------- 1620 Exchange Originator 1, 2 N/A 1621 S_ID 1623 Other Special Processing: 1625 None 1627 7.3.2 Discover Address (ADISC) 1629 Format of ADISC ELS: 1631 +------+------------+------------+-----------+----------+ 1632 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1633 +------+------------+------------+-----------+----------+ 1634 | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | 1635 +------+------------+------------+-----------+----------+ 1636 | 1 | Reserved | Hard address of ELS Originator | 1637 +------+------------+------------+-----------+----------+ 1638 | 2-3 | Port Name of Originator | 1639 +------+------------+------------+-----------+----------+ 1640 | 4-5 | Node Name of originator | 1641 +------+------------+------------+-----------+----------+ 1642 | 6 | Rsvd | N_PORT I/D of ELS Originator | 1643 +======+============+============+===========+==========+ 1645 Monia Standards Track 33 1646 Fields Requiring Translation Supplemental Data 1647 Address Translation Type (see (type 0 only) 1648 ------------------- section 7.2) ------------ 1649 ------------- 1651 N_PORT I/D of ELS 1 N/A 1652 Originator 1654 Other Special Processing: 1656 The Hard Address of the ELS originator shall be set to 0. 1658 7.3.3 Discover Address Accept (ADISC ACC) 1660 Format of ADISC ACC ELS: 1662 +------+------------+------------+-----------+----------+ 1663 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1664 +------+------------+------------+-----------+----------+ 1665 | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | 1666 +------+------------+------------+-----------+----------+ 1667 | 1 | Reserved | Hard address of ELS Originator | 1668 +------+------------+------------+-----------+----------+ 1669 | 2-3 | Port Name of Originator | 1670 +------+------------+------------+-----------+----------+ 1671 | 4-5 | Node Name of originator | 1672 +------+------------+------------+-----------+----------+ 1673 | 6 | Rsvd | N_PORT I/D of ELS Originator | 1674 +======+============+============+===========+==========+ 1676 Fields Requiring Translation Supplemental Data 1677 Address Translation Type (see (type 0 only) 1678 ------------------- section 7.2) ------------ 1679 ------------ 1681 N_PORT I/D of ELS 1 N/A 1682 Originator 1684 Other Special Processing: 1686 The Hard Address of the ELS originator SHALL be set to 0. 1688 7.3.4 FC Address Resolution Protocol Reply (FARP- 1689 REPLY) 1691 Monia Standards Track 34 1692 The FARP-REPLY ELS is used in conjunction with the FARP-REQ 1693 ELS (see section 7.3.5) to perform the address resolution 1694 services required by the FC-VI protocol [FC-VI]. 1696 Format of FARP-REPLY ELS: 1698 +------+------------+------------+-----------+----------+ 1699 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1700 +------+------------+------------+-----------+----------+ 1701 | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | 1702 +------+------------+------------+-----------+----------+ 1703 | 1 | Match Addr | Requesting N_PORT Identifier | 1704 | | Code Points| | 1705 +------+------------+------------+-----------+----------+ 1706 | 2 | Responder | Responding N_PORT Identifier | 1707 | | Action | | 1708 +------+------------+------------+-----------+----------+ 1709 | 3-4 | Requesting N_PORT Port_Name | 1710 +------+------------+------------+-----------+----------+ 1711 | 5-6 | Requesting N_PORT Node_Name | 1712 +------+------------+------------+-----------+----------+ 1713 | 7-8 | Responding N_PORT Port_Name | 1714 +------+------------+------------+-----------+----------+ 1715 | 9-10 | Responding N_PORT Node_Name | 1716 +------+------------+------------+-----------+----------+ 1717 | 11-14| Requesting N_PORT IP Address | 1718 +------+------------+------------+-----------+----------+ 1719 | 15-18| Responding N_PORT IP Address | 1720 +======+============+============+===========+==========+ 1722 Fields Requiring Translation Supplemental Data 1723 Address Translation Type (see (type 0 only) 1724 ------------------- section 7.2) ----------------- 1725 ------------- 1727 Requesting N_PORT 2 N/A 1728 Identifier 1730 Responding N_PORT 1 N/A 1731 identifier 1733 Other Special Processing: 1735 None. 1737 Monia Standards Track 35 1738 7.3.5 FC Address Resolution Protocol Request (FARP- 1739 REQ) 1741 The FARP-REQ ELS is used to in conjunction with the FC-VI 1742 protocol [FC-VI] to perform IP and FC address resolution in an 1743 FC fabric. The FARP-REQ ELS is usually directed to the fabric 1744 broadcast server at well-known address 0xFF FF FF for 1745 retransmission to all attached N_PORTs. Section 10.1 describes 1746 the iFCP implementation of FC broadcast server functionality 1747 in an iFCP fabric. 1749 Format of FARP_REQ ELS: 1751 +------+------------+------------+-----------+----------+ 1752 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1753 +------+------------+------------+-----------+----------+ 1754 | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | 1755 +------+------------+------------+-----------+----------+ 1756 | 1 | Match Addr | Requesting N_PORT Identifier | 1757 | | Code Points| | 1758 +------+------------+------------+-----------+----------+ 1759 | 2 | Responder | Responding N_PORT Identifier | 1760 | | Action | | 1761 +------+------------+------------+-----------+----------+ 1762 | 3-4 | Requesting N_PORT Port_Name | 1763 +------+------------+------------+-----------+----------+ 1764 | 5-6 | Requesting N_PORT Node_Name | 1765 +------+------------+------------+-----------+----------+ 1766 | 7-8 | Responding N_PORT Port_Name | 1767 +------+------------+------------+-----------+----------+ 1768 | 9-10 | Responding N_PORT Node_Name | 1769 +------+------------+------------+-----------+----------+ 1770 | 11-14| Requesting N_PORT IP Address | 1771 +------+------------+------------+-----------+----------+ 1772 | 15-18| Responding N_PORT IP Address | 1773 +======+============+============+===========+==========+ 1775 Fields Requiring Translation Supplemental Data 1776 Address Translation Type (see (type 0 only) 1777 ------------------- section 7.2) ----------------- 1778 ----------- 1780 Requesting N_PORT 0 Requesting N_PORT 1781 Identifier Port Name 1783 Responding N_PORT 1 N/A 1784 Identifier 1786 Other Special Processing: 1788 Monia Standards Track 36 1789 None. 1791 7.3.6 Logout (LOGO) 1793 ELS Format: 1795 +------+------------+------------+-----------+----------+ 1796 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1797 +------+------------+------------+-----------+----------+ 1798 | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | 1799 +------+------------+------------+-----------+----------+ 1800 | 1 | Rsvd | N_PORT I/D being logged out | 1801 +------+------------+------------+-----------+----------+ 1802 | 2-3 | Port name of the LOGO originator (8 bytes) | 1803 +======+============+============+===========+==========+ 1805 This ELS shall always be sent as an augmented ELS regardless 1806 of the translation mode in effect. 1808 Fields Requiring Translation Supplemental Data 1809 Address Translation Type(see (type 0 only) 1810 ------------------- section 7.2) -------------- 1811 ----------- 1813 N_PORT I/D Being 0, 1 or 2 Port Name of LOGO 1814 Logged Out Originator 1816 Other Special Processing: 1818 See section 5.2.2.1. 1820 7.3.7 Port Login (PLOGI) 1822 PLOGI provides the mechanism for establishing a login session 1823 between two N_PORTs. The PLOGI request carries information 1824 identifying the originating N_PORT, including specification of 1825 its capabilities and limitations. If the destination N_PORT 1826 accepts the login request, it sends an accept (an ACC frame 1827 with PLOGI payload), specifying its capabilities and 1828 limitations. This exchange establishes the operating 1829 environment for the two N_PORTs. 1831 The following figure is duplicated from FC-PH, and shows the 1832 PLOGI message format for both request and accept (ACC) 1833 response. A port will reject a PLOGI request by transmitting 1834 an LS_RJT message, which contains no payload. 1836 Monia Standards Track 37 1837 Byte 1838 Offset 1839 +----------------------------------+ 1840 0 | LS_COMMAND | 4 Bytes 1841 +----------------------------------+ 1842 4 | COMMON SERVICE PARAMETERS | 16 Bytes 1843 +----------------------------------+ 1844 20 | PORT NAME | 8 Bytes 1845 +----------------------------------+ 1846 28 | NODE NAME | 8 Bytes 1847 +----------------------------------+ 1848 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes 1849 +----------------------------------+ 1850 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes 1851 +----------------------------------+ 1852 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes 1853 +----------------------------------+ 1854 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes 1855 +----------------------------------+ 1856 102 | VENDOR VERSION LEVEL | 16 Bytes 1857 +----------------------------------+ 1858 Total Length = 116 bytes 1860 Details on the above fields, including common and class-based 1861 service parameters, can be found in [FC-PH]. The above PLOGI 1862 message is transported by the iFCP layer without modification. 1864 [Editor�s note: The service parameter details that apply to 1865 an iFCP environment are /TBS/.] 1867 7.3.8 Read Exchange Concise 1869 ELS Format: 1871 +------+------------+------------+-----------+----------+ 1872 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1873 +------+------------+------------+-----------+----------+ 1874 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 1875 +------+------------+------------+-----------+----------+ 1876 | 1 | Rsvd | Exchange Originator S_ID | 1877 +------+------------+------------+-----------+----------+ 1878 | 2 | OX_ID | RX_ID | 1879 +======+============+============+===========+==========+ 1880 | 3-4 |Port name of the exchange originator (8 bytes) | 1881 | | (present only for translation type 0) | 1882 +======+============+============+===========+==========+ 1884 Monia Standards Track 38 1885 Fields Requiring Translation Supplemental Data 1886 Address Translation Type(see (type 0 only) 1887 ------------------- section 7.2) ------------------ 1888 ----------- 1890 Exchange Originator 0, 1 or 2 Port Name of the 1891 S_ID Exchange 1892 Originator 1894 Other Special Processing: 1896 None. 1898 7.3.9 Read Exchange Concise Accept 1900 Format of ACC Response: 1902 +------+------------+------------+-----------+----------+ 1903 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1904 +------+------------+------------+-----------+----------+ 1905 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 1906 +------+------------+------------+-----------+----------+ 1907 | 1 | OX_ID | RX_ID | 1908 +------+------------+------------+-----------+----------+ 1909 | 2 | Rsvd | Exchange Originator N_PORT ID | 1910 +------+------------+------------+-----------+----------+ 1911 | 3 | Rsvd | Exchange Responder N_PORT ID | 1912 +------+------------+------------+-----------+----------+ 1913 | 4 | Data Transfer Count | 1914 +------+------------+------------+-----------+----------+ 1915 | 5 | Exchange Status | 1916 +======+============+============+===========+==========+ 1917 | 6-7 |Port name of the Exchange Originator (8 bytes) | 1918 +======+============+============+===========+==========+ 1919 | 8-9 |Port name of the Exchange Responder (8 bytes) | 1920 +======+============+============+===========+==========+ 1922 Fields Requiring Translation Supplemental Data 1923 Address Translation Type(see (type 0 only) 1924 ------------------- section 7.2) ------------------ 1925 ----------- 1927 Exchange Originator 0, 1 or 2 Port Name of the 1928 N_PORT I/D Exchange Originator 1930 Exchange Responder 0, 1 or 2 Port Name of the 1931 N_PORT I/D Exchange Responder 1933 Monia Standards Track 39 1934 When supplemental data is required, the ELS shall be always be 1935 extended by 4 words as shown above. Unused words in the 1936 extended fields SHALL be set to 0. 1938 Other Special Processing: 1940 None. 1942 7.3.10 Read Exchange Status Block (RES) 1944 ELS Format: 1946 +------+------------+------------+-----------+----------+ 1947 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1948 +------+------------+------------+-----------+----------+ 1949 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 1950 +------+------------+------------+-----------+----------+ 1951 | 1 | Rsvd | Exchange Originator S_ID | 1952 +------+------------+------------+-----------+----------+ 1953 | 2 | OX_ID | RX_ID | 1954 +------+------------+------------+-----------+----------+ 1955 | 3-10 | Association header (may be optionally req�d) | 1956 +======+============+============+===========+==========+ 1957 | 11-18| Port name of the Exchange Originator (8 bytes) | 1958 +======+============+============+===========+==========+ 1960 Fields Requiring Translation Supplemental Data 1961 Address Translation Type(see (type 0 only) 1962 ------------------- section 7.2) ------------------ 1963 ----------- 1965 Exchange Originator 0, 1 or 2 Port Name of the 1966 S_ID Exchange Originator 1968 Other Special Processing: 1970 None. 1972 7.3.11 Read Exchange Status Block Accept 1974 Format of ELS Accept Response: 1976 Monia Standards Track 40 1977 +------+------------+------------+-----------+----------+ 1978 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 1979 +------+------------+------------+-----------+----------+ 1980 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 1981 +------+------------+------------+-----------+----------+ 1982 | 1 | OX_ID | RX_ID | 1983 +------+------------+------------+-----------+----------+ 1984 | 2 | Rsvd | Exchange Originator N_PORT ID | 1985 +------+------------+------------+-----------+----------+ 1986 | 3 | Rsvd | Exchange Responder N_PORT ID | 1987 +------+------------+------------+-----------+----------+ 1988 | 4 | Exchange Status Bits | 1989 +------+------------+------------+-----------+----------+ 1990 | 5 | Reserved | 1991 +------+------------+------------+-----------+----------+ 1992 | 6�n | Service Parameters and Sequence Statuses | 1993 | | as described in [FCS] | 1994 +======+============+============+===========+==========+ 1995 |n+1- | Port name of the Exchange Originator (8 bytes) | 1996 |n+8 | | 1997 +======+============+============+===========+==========+ 1998 |n+9- | Port name of the Exchange Responder (8 bytes) | 1999 |n+16 | | 2000 +======+============+============+===========+==========+ 2002 Fields Requiring Translation Supplemental Data 2003 Address Translation Type(see (type 0 only) 2004 ------------------- section 7.2) ------------------ 2005 ----------- 2007 Exchange Originator 0, 1 or 2 Port Name of the 2008 N_PORT I/D Exchange Originator 2010 Exchange Responder 0, 1 or 2 Port Name of the 2011 N_PORT I/D Exchange Responder 2013 When supplemental data is required, the ELS SHALL be extended 2014 by 4 words as shown above. Unused words in the extended fields 2015 SHALL be set to 0. 2017 Other Special Processing: 2019 None. 2021 7.3.12 Read Link Error Status (RLS) 2023 ELS Format: 2025 Monia Standards Track 41 2026 +------+------------+------------+-----------+----------+ 2027 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2028 +------+------------+------------+-----------+----------+ 2029 | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | 2030 +------+------------+------------+-----------+----------+ 2031 | 1 | Rsvd | N_PORT Identifier | 2032 +======+============+============+===========+==========+ 2033 | 2-9 | Port name of the N_PORT (8 bytes) | 2034 +======+============+============+===========+==========+ 2036 Fields Requiring Translation Supplemental Data (type 2037 Address Translation Type(see 0 only) 2038 ------------------- section 7.2) ------------------ 2039 ----------- 2041 N_PORT Identifier 0, 1 or 2 Port Name of the N_PORT 2043 Other Special Processing: 2045 None. 2047 7.3.13 Read Sequence Status Block (RSS) 2049 ELS Format: 2051 +------+------------+------------+-----------+----------+ 2052 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2053 +------+------------+------------+-----------+----------+ 2054 | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | 2055 +------+------------+------------+-----------+----------+ 2056 | 1 | SEQ_ID | Exchange Originator S_ID | 2057 +------+------------+------------+-----------+----------+ 2058 | 2 | OX_ID | RX_ID | 2059 +======+============+============+===========+==========+ 2060 | 3-4 |Port name of the Exchange Originator (8 bytes) | 2061 +======+============+============+===========+==========+ 2063 Fields Requiring Translation Supplemental Data 2064 Address Translation Type(see (type 0 only) 2065 ------------------- section 7.2) ------------------ 2066 ----------- 2068 Exchange Originator 0, 1 or 2 Port Name of the 2069 S_ID Exchange Originator 2071 Other Special Processing: 2073 Monia Standards Track 42 2074 None. 2076 7.3.14 Reinstate Recovery Qualifier (RRQ) 2078 ELS Format: 2080 +------+------------+------------+-----------+----------+ 2081 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2082 +------+------------+------------+-----------+----------+ 2083 | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | 2084 +------+------------+------------+-----------+----------+ 2085 | 1 | Rsvd | Exchange Originator S_ID | 2086 +------+------------+------------+-----------+----------+ 2087 | 2 | OX_ID | RX_ID | 2088 +------+------------+------------+-----------+----------+ 2089 | 3-10 | Association header (may be optionally req�d) | 2090 +======+============+============+===========+==========+ 2092 Fields Requiring Translation Supplemental Data 2093 Address Translation Type(see (type 0 only) 2094 ------------------- section 7.2) ------------------ 2095 ----------- 2097 Exchange Originator 1 or 2 N/A 2098 S_ID 2100 Other Special Processing: 2102 None. 2104 7.3.15 Request Sequence Initiative (RSI) 2106 ELS Format: 2108 +------+------------+------------+-----------+----------+ 2109 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2110 +------+------------+------------+-----------+----------+ 2111 | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | 2112 +------+------------+------------+-----------+----------+ 2113 | 1 | Rsvd | Exchange Originator S_ID | 2114 +------+------------+------------+-----------+----------+ 2115 | 2 | OX_ID | RX_ID | 2116 +------+------------+------------+-----------+----------+ 2117 | 3-10 | Association header (may be optionally req�d) | 2118 +======+============+============+===========+==========+ 2120 Monia Standards Track 43 2121 Fields Requiring Translation Supplemental Data 2122 Address Translation Type(see (type 0 only) 2123 ------------------- section 7.2) ------------------ 2124 ----------- 2126 Exchange Originator 1 or 2 N/A 2127 S_ID 2129 Other Special Processing: 2131 None. 2133 7.3.16 Third Party Process Logout (TPRLO) 2135 TPRLO provides a mechanism for an N_PORT (third party) to 2136 remove one or more login sessions that exists between the 2137 destination N_PORT and other N_PORTs specified in the command. 2138 This command includes one or more TPRLO LOGOUT PARAMETER 2139 PAGEs, each of which when combined with the destination N_PORT 2140 identifies a SCSI login session which shall be terminated by 2141 the command. 2143 Byte 2144 Offset 2145 +----------------------------------+ 2146 0 | LS_COMMAND | 1 Byte 2147 +----------------------------------+ 2148 1 | PAGE LENGTH (0x10) | 1 Byte 2149 +----------------------------------+ 2150 2 | PAYLOAD LENGTH (0x14) | 2 Bytes 2151 +----------------------------------+ 2152 4 | TPRLO LOGOUT PARAMETER PAGE 1 | 2-4 Bytes 2153 +----------------------------------+ 2154 | . . . . | M Bytes 2155 +----------------------------------+ 2156 | TPRLO LOGOUT PARAMETER PAGE N | 2-4 Bytes 2157 +----------------------------------+ 2158 Total Length = Variable 2160 Each TPRLO LOGOUT PARAMETER PAGE identifies a remote N_PORT 2161 which when combined with the destination N_PORT identifies a 2162 SCSI session to be terminated. The TPRLO LOGOUT PARAMETER 2163 PAGE is of the following format: 2165 Monia Standards Track 44 2166 Byte 2167 Offset 2168 +----------------------------------+ 2169 0 | TYPE CODE | 1 Byte 2170 +----------------------------------+ 2171 1 | TYPE CODE EXTENSION | 1 Byte 2172 +----------------------------------+ 2173 2 | TPRLO FLAGS | 2 Bytes 2174 +----------------------------------+ 2175 4 | ORIG PROCESS ASSOC (if present) | 4 Bytes 2176 +----------------------------------+ 2177 8 | RESP PROCESS ASSOC (if present) | 4 Bytes 2178 +----------------------------------+ 2179 12 | RESERVED | 1 Byte 2180 +----------------------------------+ 2181 13 | THIRD PARTY ORIGINATOR N_PORT ID | 3 Bytes 2182 +----------------------------------+ 2184 When the iFCP header contains a TPRLO message (including the 2185 ACC response), iFCP supplemental data field will contain the 2186 PORT_NAME(s) (WWPN) identifying the N_PORT described by the 2187 equivalent TPRLO LOGOUT PARAMETER PAGE(s). If more than one 2188 TPRLO LOGOUT PARAMETER PAGE is contained in the Link Service 2189 message, the corresponding PORT_NAME shall also be included. 2190 PORT_NAMEs shall be listed in the same order as the equivalent 2191 TPRLO LOGOUT PARAMETER PAGEs in the original Link Service 2192 message. 2194 [The format for passing supplemental data is /TBS/] 2196 Additionally, the THIRD PARTY ORIGINATOR N_PORT ID field in 2197 each TPRLO LOGOUT PARAMETER PAGE shall be cleared when it is 2198 sent by the originating gateway. This applies to both the 2199 original Link Service message and the ACC response. 2201 When the iFCP layer receives a TPRLO message, it shall use the 2202 latter to replace the THIRD PARTY ORIGINATOR N_PORT ID in the 2203 original Link Service message, before forwarding it on to the 2204 upper Fibre Channel layers. 2206 Additional information on TPRLO can be found in [FC-PH-2]. 2208 8. TCP Session Control Messages 2210 TCP session control messages are used to create and manage 2211 N_PORT login session.. They are passed between peer FCP 2212 Portals, and are only processed within the iFCP layer. The 2213 response to a TCP session control message (if any) will echo 2214 the original request. 2216 Monia Standards Track 45 2217 The message format is based on the extended link service 2218 message template shown below. 2220 Word 2221 3124 23<---------------Bits------------------------->0 2222 +----------+------------------------------------------------+ 2223 0| R_CTL | D_ID [0x00 00 00] | 2224 |[Req = 22]| [Destination of extended link Service request] | 2225 |[Rep = 23 | | 2226 +----------+------------------------------------------------+ 2227 1| CS_CTL | S_ID [0x00 00 00] | 2228 | [0x0] | [Source of extended link service request] | 2229 +----------+------------------------------------------------+ 2230 2|TYPE [0x1]| F_CTL [0] | 2231 +----------+------------------+-----------------------------+ 2232 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | 2233 |[0x0] | | | 2234 +----------+------------------+-----------------------------+ 2235 4| OX_ID [0x0000] | RX_ID_[0x0000] | 2236 +-----------------------------+-----------------------------+ 2237 5| Parameter | 2238 | [ 00 00 00 00 ] | 2239 +-----------------------------------------------------------+ 2240 6| LS_COMMAND | 2241 | [Session Control Command Code] | 2242 +-----------------------------------------------------------+ 2243 7| | 2244 .| Additional Session Control Parameters | 2245 .| ( if any ) | 2246 n| | 2247 +===========================================================+ 2248 n| Fibre Channel CRC | 2249 +| | 2250 1+===========================================================+ 2251 Format of Session Control Message 2253 The LS_COMMAND value for the response remains the same as that 2254 used for the request. 2256 The session control ELS frame is terminated with a fibre 2257 channel CRC. 2259 {Editor�s note: Since these messages are never passed to the 2260 fibre channel device, the use of the FC ELS format is not 2261 required. However, leveraging the format may benefit a 2262 gateway implementation. Depending on the tradeoffs, therefore, 2263 the format may be modified to eliminate use of the ELS as a 2264 message template.] 2266 The encapsulation header for the link Service frame carrying a 2267 TCP ELS message SHALL be set as follows: 2269 Monia Standards Track 46 2270 Encapsulation Header Fields: 2272 LS_COMMAND 0 2274 iFCP Flags SES = 1 2276 TRN = 0 2278 AUG = 0 2280 SOF code SOFi3 encoding (0x2E) 2282 EOF code EOFn encoding (0x50) 2284 Time Stamp Integer 0,0 2285 and Fraction fields 2287 The SOF and EOF delimiter words SHALL be set based on the SOF 2288 and EOF codes specified above. 2290 The following lists the TCP Link Service messages and their 2291 corresponding LS_COMMAND values. 2293 Request LS_COMMAND Short Name iFCP Support 2294 ------- ---------- ---------- ----------- 2295 Control Connection Bind 0xE0 CBIND REQUIRED 2296 Unbind Connection 0xE4 UNBIND REQUIRED 2298 8.1 Connection Bind (CBIND) 2300 The CBIND message binds an N_PORT login session to a specific 2301 TCP connection in preparation for establishing an N_PORT login 2302 session. In the CBIND request message, the source and 2303 destination N_Ports are identified by the N_PORT network 2304 address (iFCP portal address and N_PORT ID). 2306 The following shows the format of the CBIND request. 2308 Monia Standards Track 47 2309 +------+------------+------------+-----------+----------+ 2310 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2311 +------+------------+------------+-----------+----------+ 2312 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2313 +------+------------+------------+-----------+----------+ 2314 | 1 | User Info | 2315 +------+------------+------------+-----------+----------+ 2316 | 2 | Interface Speed | 2317 +------+------------+------------+-----------+----------+ 2318 | 3 | | 2319 +------+ SOURCE PORT NAME | 2320 | 4 | | 2321 +------+------------------------------------------------+ 2322 | 5 | | 2323 +------+ DESTINATION PORT NAME | 2324 | 6 | | 2325 +------+------------------------------------------------+ 2327 USER INFO - Contains any data desired by the requester. This 2328 info MUST be echoed by the recipient in the CBIND response 2329 message. 2331 SOURCE PORT NAME - Contains the originating N_PORT's World 2332 Wide Port Name (WWPN). 2334 DESTINATION PORT NAME - Contains the destination N_PORT's 2335 World Wide Port Name (WWPN). 2337 The following shows the format of the CBIND response. 2339 +------+------------+------------+-----------+----------+ 2340 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2341 +------+------------+------------+-----------+----------+ 2342 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2343 +------+------------+------------+-----------+----------+ 2344 | 1 | User Info | 2345 +------+------------+------------+-----------+----------+ 2346 | 2 | | 2347 +------+ SOURCE PORT NAME | 2348 | 3 | | 2349 +------+------------------------------------------------+ 2350 | 4 | | 2351 +------+ DESTINATION PORT NAME | 2352 | 5 | | 2353 +------+-------------------------+----------------------+ 2354 | 6 | Reserved | CBIND Status | 2355 +------+-------------------------+----------------------+ 2356 | 7 | Reserved | CONNECTION HANDLE | 2357 +------+-------------------------+----------------------+ 2358 Total Length = 26 2360 Monia Standards Track 48 2361 USER INFO - Contains the same value received in the USER INFO 2362 field of the CBIND request message. 2364 DESTINATION PORT NAME - Contains the destination N_PORT's 2365 World Wide Port Name (WWPN). 2367 CBIND STATUS - Indicates success or failure of the CBIND 2368 request. CBIND values are shown below. 2370 Value Description 2371 ----- ----------- 2373 0 Successful � No other status 2374 1 � 15 Reserved 2375 16 Failed � Unspecified Reason 2376 17 Failed � No such device 2377 18 Failed � N_PORT session already exists 2378 19 Failed � Lack of resources 2379 Others Reserved 2381 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the 2382 FCP Portal to identify the control connection. 2384 8.2 Unbind Connection (UNBIND) 2386 UNBIND is used to release a bound TCP connection and return it 2387 to the pool of unbound TCP connections. This message is 2388 transmitted in the connection that is to be unbound. 2390 The following is the format of the UNBIND request message. 2392 Byte MSb LSb 2393 Offset 7 6 5 4 3 2 1 0 2394 +----------------------------------+ 2395 0 | LS_COMMAND (0xE4000000) | 4 Bytes 2396 +----------------------------------+ 2397 4 | USER INFO | 4 Bytes 2398 +----------------------------------+ 2399 8 | CONNECTION HANDLE | 4 Bytes 2400 +----------------------------------+ 2401 12 | RESERVED | 8 Bytes 2402 +----------------------------------+ 2403 Total Length = 20 2405 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the 2406 FCP Portal to identify the connection 2408 The following shows the format of the UNBIND response message. 2410 Monia Standards Track 49 2411 Byte MSb LSb 2412 Offset 7 6 5 4 3 2 1 0 2413 +----------------------------------+ 2414 0 | LS_COMMAND (0xE4000000) | 4 Bytes 2415 +----------------------------------+ 2416 4 | USER INFO | 4 Bytes 2417 +----------------------------------+ 2418 8 | CONNECTION HANDLE | 4 Bytes 2419 +----------------------------------+ 2420 16 | RESERVED | 10 Bytes 2421 +----------------------------------+ 2422 26 | UNBIND STATUS | 2 Bytes 2423 +----------------------------------+ 2424 28 | RESERVED | 2 Bytes 2425 +----------------------------------+ 2426 Total Length = 26 2428 UNBIND STATUS - Indicates the success or failure of the UNBIND 2429 request. 2431 Value Description 2432 ----- ----------- 2434 0 Successful � No other status 2435 1 � 15 Reserved 2436 16 Failed � Unspecified Reason 2437 17 Failed � No such device 2438 18 Failed � Connection ID Invalid 2439 Others Reserved 2441 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the 2442 FCP Portal to identify the unbound connection. 2444 9. iFCP Error Detection 2446 9.1 Overview 2448 [FCP-2], [FC-PH], and [FC-PH-2] define error detection and 2449 recovery procedures. These Fibre Channel-defined mechanisms 2450 continue to be available in the iFCP environment. 2452 9.2 Timer Definitions and Stale Frame Detection 2454 9.2.1 Error_Detect_Timeout (E_D_TOV) 2456 E_D_TOV is "a reasonable timeout value for detection of a 2457 response to a timed event". The default value specified by 2458 FC-FS of 2 seconds will be also used as the iFCP default 2459 value. 2461 Monia Standards Track 50 2462 E_D_TOV is the maximum time allowed between the transmission 2463 of consecutive data frames within a sequence. For Class 2 2464 service, E_D_TOV specifies the maximum time interval between 2465 transmission of a frame, and receipt of the ACK for that 2466 frame. 2468 E_D_TOV MAY be specified individually for each gateway. If a 2469 gateway-specific value is not set, the gateway SHALL obtain 2470 the value from the iSNS name server. 2472 9.2.2 Resource Allocation Timeout (R_A_TOV 2474 R_A_TOV is defined in FC-PH-2 as "the maximum transit time 2475 within a fabric to guarantee that a lost frame will never 2476 emerge from the fabric". A value of 2 x R_A_TOV is the 2477 minimum time that the originator of an ELS request or FC-4 ELS 2478 request shall wait for the response to that request. The fibre 2479 channel default value for R_A_TOV is 10 seconds. 2481 R_A_TOV MAY be specified individually for each gateway. If a 2482 gateway-specific value is not set, the gateway SHALL obtain 2483 the value from the iSNS name server. The iFCP fabric MAY 2484 actively enforce limits on R_A_TOV as described in section 2485 9.2.2.1. 2487 9.2.2.1 Enforcing R_A_TOV Limits 2489 The R_A_TOV limit on frame lifetimes MAY be enforced by means 2490 of the time stamp in the encapsulation header (see section 2491 6.1) as described in this section. 2493 If enforced by a gateway, the propagation delay time limit 2494 (MAX_PROP_DELAY) SHOULD be set well below the value of R_A_TOV 2495 specified for the iFCP fabric and SHOULD be stored in the iSNS 2496 server. A rule of thumb is to set MAX_PROP_DELAY to 50 percent 2497 of R_A_TOV. 2499 The following paragraphs describe the requirements for 2500 synchronizing gateway time bases and the rules for measuring 2501 and enforcing propagation delay limits. 2503 The protocol for synchronizing a gateway time base is SNTP. In 2504 order to insure that all gateways are time-aligned, a gateway 2505 SHOULD obtain the address of an SNTP server via an iSNS query. 2506 If multiple SNTP server addresses are returned by the query, 2507 the servers must be synchronized and the gateway may use any 2508 server in the list. Alternatively, the server may return a 2509 multicast group address in support of operation in Anycast 2510 mode. Implementation of Anycast mode is as specified in RFC 2511 2030, including the precautions defined in that document. 2512 Multicast mode SHOULD NOT be used. 2514 Monia Standards Track 51 2515 An SNTP server may use any one of the time reference sources 2516 listed in RFC 2030. The resolution of the time reference MUST 2517 be 125 milliseconds or better. 2519 With regard to the time base, the gateway is in either the 2520 synchronized or unsychronized state. When in the 2521 unsynchronized state, the gateway SHALL: 2523 a) Set the time stamp field to 0,0 for all outgoing frames 2525 b) Ignore the time stamp field for all incoming frames. 2527 When in the synchronized state, the gateway SHALL 2529 a) Set the time stamp field for each outgoing frame in 2530 accordance with the gateway's internal time base 2532 b) Check the time stamp field of each incoming frame. 2534 c) If the incoming frame has a time stamp of 0,0, the 2535 receiving gateway SHALL NOT test the frame to determine if 2536 it is stale. 2538 d) If the incoming frame has a non-zero time stamp, the 2539 receiving gateway shall compute the time in flight and 2540 compare it against the value of MAX_PROP_DELAY specified 2541 for the IP fabric. 2543 e) If the result in step (d) exceeds MAX_PROP_DELAY, the 2544 frame shall be discarded. Otherwise, the frame shall be 2545 accepted. 2547 A gateway SHALL enter the synchronized state upon receiving a 2548 successful response to an SNTP query. 2550 A gateway shall enter the unsynchronized state: 2552 a) Upon power up and before successful completion of an SNTP 2553 query 2555 b) Whenever the gateway looses contact with the SNTP server. 2557 If synchronization is lost, the gateway MAY choose to abort 2558 all N_PORT login sessions with all remote gateways. 2560 10. Fabric Services Supported by an iFCP implementation 2562 An iFCP gateway implementation MUST support the following 2563 fabric services: 2565 N_PORT ID Value Description Section 2566 --------------- ----------- ------- 2568 Monia Standards Track 52 2569 0xFF FF FE F_PORT Server /TBS/ 2571 0xFF FF FD Fabric Controller /TBS/ 2573 0xFF FF FC Directory/Name Server /TBS/ 2575 In addition, an iFCP gateway MAY support the FC broadcast 2576 server functionality described in section 10.1. 2578 10.1 iFCP Support for the FC Broadcast Service 2580 In Fibre Channel, frames are broadcast by addressing them to 2581 the broadcast server at well-known address 0xff ff ff. The 2582 broadcast server then replicates and delivers the frame to 2583 each attached N_PORT in all zones to which the originating 2584 device belongs. Only class 3 (datagram) service is supported. 2586 In an iFCP/iSNS system, the broadcast functionality MAY be 2587 implemented within each gateway by an iFCP broadcast server. 2588 The broadcast server has an N_PORT I/D of 0xff ff ff. 2589 Outgoing frames to be broadcast are directed to the broadcast 2590 server by locally attached N_PORTs. The broadcast server then 2591 redistributes such frames as follows: 2593 a) One copy is sent to each locally attached N_PORT in the 2594 same zone as the originator. 2596 b) One copy is sent to the broadcast server in each remote 2597 gateway via a UDP datagram, The D_ID field is set to the 2598 well-known address of the broadcast server. The datagram 2599 encapsulation format is identical to the iFCP 2600 encapsulation format described in section 6. 2602 On receiving an iFCP broadcast datagram via UDP, the broadcast 2603 server SHALL: 2605 a) Validate the header as described in section 6.3. If the 2606 header is invalid, the frame SHALL be discarded. 2608 b) Convert the S_ID N_PORT address in the frame to an N_PORT 2609 alias as described in section 3.3.2, if address translation 2610 mode is in effect. 2612 c) If the AUG bit is set in the iFCP flags field, perform any 2613 special processing required by the ELS, including 2614 translation of any addresses in the payload. 2616 Monia Standards Track 53 2617 d) Replicate and redistribute the frame to all locally 2618 attached N_PORTs in the discovery domain of the sender. 2620 If no broadcast server is implemented, the receiving gateway 2621 SHALL discard an incoming broadcast frame from a remote 2622 gateway. Frames received from locally attached N_PORTs shall 2623 be processed as specified in [FC-SW]. 2625 11. Security 2627 11.1 Overview 2629 As with any other IP-based network, an iFCP storage network 2630 has security issues which must be addressed with the 2631 appropriate security policies and enforcement resources. 2632 There are various levels of security paradigms which when 2633 applied appropriately to an iFCP network can provide 2634 sufficient levels of security, including data integrity, 2635 authentication, and privacy, depending on user needs. 2637 11.2 Physical Security 2639 Most existing SCSI and Fibre Channel interconnections are 2640 deployed in private, physically isolated environments where 2641 hostile entities are not provided access to the SCSI and Fibre 2642 Channel interconnects. This is the most basic security 2643 mechanism, and may be a sufficient model in some cases for an 2644 iFCP network. 2646 11.3 Controlling Access 2648 A second level of security is the use of zoning. Zoning 2649 specifies which devices are allowed to communicate, and is 2650 similar in concept to VLAN (Virtual Local Area Network) 2651 technology. Zoning information is maintained in a Name 2652 Server. 2654 11.4 Authentication and Encryption 2656 Where additional levels of data integrity and privacy are 2657 required for iFCP, existing IPSec specifications can be 2658 applied to iFCP. Because IPSec is a layer-3 technology and 2659 has no knowledge of TCP, UDP, or higher-level protocols such 2660 as iFCP and FCP, it can be applied transparently to iFCP. The 2661 following IETF documents describe the operational framework 2662 and automatic keying mechanisms for IPSec. 2664 RFC2401 Security Architecture for the Internet Protocol 2666 RFC2402 IP Authentication Header 2668 Monia Standards Track 54 2669 RFC2406 IP Encapsulating Security Payload 2671 RFC2407 The Internet IP Security Domain of Interpretation for 2672 ISAKMP 2674 RFC2408 Internet Security Association and Key Management 2675 Protocol (ISAKMP) 2677 RFC2409 The Internet Key Exchange (IKE) 2679 11.5 Storage Firewalls 2681 Firewalls are a common and proven methodology for securing 2682 access to IP-based networks, and they can be appropriate for 2683 use in IP-based storage networks as well. A firewall is a 2684 choke point through which all transit traffic must transit in 2685 order to pass between two separate networks. Since all iFCP 2686 traffic uses a well-known IANA-assigned TCP port number, it 2687 can easily be recognized and inspected. 2689 Access to storage resources can be secured by setting up a 2690 single gateway through which all outside non-secured traffic 2691 must pass through in order to access resources in the storage 2692 network. Such a firewall can be a proxy host operating at the 2693 session or application layer, requiring authentication before 2694 allowing traffic to pass. It can also be a stateful 2695 inspection gateway which understands the iFCP protocol, and 2696 can passively inspect and discover security threats as they 2697 transit the gateway. A third option is to use a standard 2698 router access control list to filter authorized traffic based 2699 upon static parameters such as IP addresses and TCP port 2700 numbers. 2702 12. Quality of Service Considerations 2704 12.1 Minimal requirements 2706 Conforming iFCP protocol implementations SHALL correctly 2707 communicate gateway-to-gateway even across one or more 2708 intervening best-effort IP regions. The timings with which 2709 such gateway-to gateway communication is performed, however, 2710 will greatly depend upon BER, packet losses, latency, and 2711 jitter experienced throughout the best-effort IP regions. The 2712 higher these parameters, the higher will be the gap measured 2713 between iFCP observed behaviors and baseline iFCP behaviors 2714 (i.e., as produced by two iFCP gateways directly attached to 2715 one another). 2717 12.2 High-assurance 2719 Monia Standards Track 55 2720 It is expected that many iFCP deployments will benefit from a 2721 high degree of assurance on the behaviors of the intervening 2722 IP regions, with resulting high-assurance on the overall end- 2723 to-end path, as directly experienced by Fibre Channel 2724 applications. Such assurance on the IP behaviors stems from 2725 the intervening IP regions supporting standard Quality-of- 2726 Service (QoS) techniques, fully complementary to iFCP, such 2727 as: 2729 a) Congestion avoidance by over-provisioning of the network 2731 b) Integrated Services [IntServ] QoS 2733 c) .Differentiated Services [DiffServ] QoS 2735 d) .Multi-Protocol Label Switching [MPLS] 2737 In the most general definition, two iFCP gateways are 2738 separated by one or more independently managed IP regions, 2739 some of which implement some of the QoS solutions mentioned 2740 above. The IP regions with these QoS solutions are said to 2741 support Service Level Agreements (SLAs). Such agreements 2742 finalize requirements on network parameters such as bandwidth, 2743 loss, latency, jitter, burst length. The requirements may be 2744 expressed in absolute or relative terms, and apply to a 2745 unidirectional flow of packets. Depending on the QoS 2746 techniques available, the dynamic stipulation of a SLA may 2747 require the iFCP gateway to interact with network ancillary 2748 functions such admission control and bandwidth brokers (with 2749 RSVP or other signalling protocols that an IP region may 2750 accept). 2752 Due to the fact that Fibre Channel Class 2 and Class 3 do not 2753 support fractional bandwidth guarantees, and that iFCP is 2754 committed to supporting current Fibre Channel semantics, it is 2755 impossible for an iFCP gateway to autonomously infer bandwidth 2756 requirements from streaming Fibre Channel traffic. Rather, the 2757 requirements on bandwidth or other network parameters need to 2758 be injected out-of-band into a iFCP gateway (or the node that 2759 will actually negotiate the SLA on the gateway's behalf) 2760 through mechanisms outside the scope of this specification 2761 (e.g., through a management interface into the iFCP gateway). 2763 The administrator of a iFCP gateway MAY thus stipulate a 2764 Service Level Agreement with the local IP region for one, 2765 several, or all of an iFCP gateway's TCP sessions used by 2766 iFCP. Alternately, this responsibility may be delegated to a 2767 node downstream. Should an iFCP implementation support 2768 multiple tuples over the same TCP connection, 2769 and should such a connection be subject to a SLA, then all 2770 these tuples will share in the same SLA and 2771 the resulting treatment by the network. For finer granularity 2773 Monia Standards Track 56 2774 of QoS behaviors, iFCP implementations MAY elect to dedicate a 2775 distinct TCP connection to each active tuple. 2776 This is the way an individual tuple can enjoy 2777 a customized SLA. 2779 To render the best emulation of Fibre Channel possible over 2780 IP, it is anticipated that typical SLAs will specify a fixed 2781 amount of bandwidth, null losses, and, to a lesser degree of 2782 relevance, low latency, and low jitter. For example, an IP 2783 region using DiffServ QoS may support SLAs of this nature by 2784 applying EF DSCPs to the iFCP traffic. For the same SLA, 2785 another IP region might as well use a different DSCP or 2786 different QoS techniques alltogether. The way different QoS 2787 techniques are re-mapped at the edge of different intervening 2788 IP regions is beyond the scope of this specification. 2790 [T11/00-603V0] describes a proposal to add fractional 2791 bandwidth guarantees to Class 2 and 3 (migrating it from Class 2792 4). In such proposal, the bandwidth parameters would surface 2793 in the FLOGI request and accept, and PLOGI request and accept. 2794 In this case, it will become possible for an iFCP gateway to 2795 trap this information and autonomously remap it onto the SLA 2796 negotiation mechanism required by the local IP region, without 2797 resorting to out-of-band QoS management. Such an in-band QoS 2798 mechanism would result in true end-to-end provisioning of 2799 network resources. Forthcoming revisions of this iFCP 2800 specification will build upon this new opportunity. 2802 13. References 2804 13.1 Relevant SCSI (T10) Specifications 2806 The following documents are available from: Global 2807 Engineering, 15 Inverness Way East, Englewood, CO 80112-5704. 2808 Telephone (800) 854-7179 or (303) 792-2181, Fax: (303) 792- 2809 2192 2811 [SAM] SCSI-3 Architecture Model (SAM), ANSI X3.270-1996 2813 [SAM-2] SCSI Architecture Model-2 (SAM-2), Project 1157-D, 2814 revision 11 2816 [SPC] SCSI Primary Commands (SPC), ANSI X3.301-1997 2818 [SPC-2] SCSI Primary Commands-2 (SPC-2), Project 1236-D, 2819 revision 16 2821 [FCP] Fibre Channel Protocol for SCSI (FCP), ANSI X3.269-1996 2823 [FCP-2] Fibre Channel Protocol for SCSI, Second Revision (FCP- 2824 2), Project 1144D, revision 04 2826 Monia Standards Track 57 2827 10.2 Relevant Fibre Channel (T11) Specifications 2829 The following documents are available from: Global 2830 Engineering, 15 Inverness Way East, Englewood, CO 80112-5704. 2831 Telephone (800) 854-7179 or (303) 792-2181, Fax: (303) 792- 2832 2192 2834 [FC-PH] Fibre Channel Physical and Signaling Interface (FC-PH) 2835 Rev 4.3, ANSI X3.230:1994 2837 [FC-PH-2] Fibre Channel Physical and Signaling Interface (FC-PH- 2838 2) Rev 7.4, ANSI X3.297:1997 2840 [FC-PH-3] Fibre Channel Physical and Signaling Interface (FC-PH- 2841 3) Rev 9.4, ANSI X3.303:1998 2843 [FC-FG] Fibre Channel Generic Requirements (FC-FG) Rev 3.5 ANS 2844 X3.289:1996 2846 [FC-GS-2] Fibre Channel Generic Services (FC-GS-2) Rev 5.2, ANSI 2847 NCITS 288 2849 [FC-AL] Fibre Channel Arbitrated Loop (FC-AL) Rev 4.5, ANSI 2850 X3.272:1996 2852 [FC-AL-2] Fibre Channel Arbitrated Loop (FC-AL-2) Rev 7.0, NCITS 2853 32:1999 2855 [FC-PLDA] Fibre Channel Private Loop SCSI Direct Attachment (FC 2856 LDA), NCITS TR-19:1998 2858 [FC-FLA] Fibre Channel Fabric Loop Attachment (FC-FLA), NCITS 2859 TR-20:1998 2861 [FC-TAPE] Fibre Channel Tape and Tape Medium Changers (FC-TAPE), 2862 NCITS TR-24:1999 2864 10.3 Relevant RFC Documents 2866 [RFC768] User Datagram Protocol 2868 [RFC791] Internet Protocol, DARPA Internet Program Protocol 2869 Specification 2871 [RFC1146] TCP Alternate Checksum Options 2873 Monia Standards Track 58 2875 [RFC2401] Security Architecture for Internet Protocol 2877 [RFC2402] IP Authentication Header 2879 [RFC2406] Encapsulating Security Protocol (ESP) 2881 [RFC2407] The Internet IP Security Domain for ISAKMP 2883 [RFC2408] Internet Security Association and Key Management 2884 Protocol (ISAKMP) 2886 [RFC2409] The Internet Key Exchange (IKE) 2888 [RFC2460] Internet Protocol, Version 6 (IPv6) Specification 2890 10.4 Other Reference Documents 2892 Fibre Channel, Gigabit Communications and I/O for Computer 2893 Networks, Alan F. Beener, McGraw-Hill, ISBN 0-07-005669-2 2895 The Fibre Channel Consultant, A Comprehensive Introduction, 2896 Robert W. Kembel, Northwest Learning Associates, ISBN 0- 2897 931836-82-6 2899 The Fibre Channel Consultant, Arbitrated Loop, Rober W. 2900 Kembel, Connectivity Solutions, a division of Northwest 2901 Learning Associates, ISBN 0-931836-84-0 2903 14. Author's Addresses 2905 Charles Monia Franco Travostino 2906 Rod Mullendore Director, Content 2907 Josh Tseng Internetworking Lab, 2909 Nishan Systems Victor Firoiu 2910 3850 North First Street 2911 San Jose, CA 95134 Nortel Networks 2912 Phone: 408-519-3986 3 Federal Street 2913 Email: Billerica, MA 01821 2914 cmonia@nishansystems.com Phone: 978-288-7708 2915 Email: 2916 travos@nortelnetworks.com 2918 David Robinson Wayland Jeong 2919 Sun Microsystems Troika Networks 2920 Senior Staff Engineer Vice President, Hardware 2921 M/S UNWK16-301 Engineering 2922 901 San Antonio Road 2829 Townsgate Road Suite 2923 Palo Alto, CA 94303-4900 200 2925 Monia Standards Track 59 2926 Phone: 510-936-2337 Westlake Village, CA 91361 2927 Email: Phone: 805-370-2614 2928 David.Robinson@sun.com Email: 2929 wayland@troikanetworks.com 2931 Rory Bolt Paul Rutherford 2932 Quantum/ATL ADIC 2933 Director, System Design Vice President, Technology & 2934 101 Innovation Drive Software 2935 Irvine, CA 92612 1143 Willows Road N.E. 2936 Phone: 949-856-7760 P.O. Box 97057 2937 Email: rbolt@atlp.com Redmond, WA 98073-9757 2938 Phone: 425-881-8004 2939 Email: 2940 paul.rutherford@adic.com 2942 Mark Edwards 2943 Senior Systems Architect 2944 Eurologic Development, Ltd. 2945 4th Floor, Howard House 2946 Queens Ave, UK. BS8 1SD 2947 Phone: +44 (0)117 930 9600 2948 Email: 2949 medwards@eurologic.com 2951 Monia Standards Track 60 2952 Appendix A 2954 A. iFCP Support for Fibre Channel Link Services 2956 For reference purposes, this appendix enumerates all the fibre 2957 channel link services and the manner in which each shall be 2958 processed by an iFCP implementation. The iFCP processing 2959 policies are defined in section 7. 2961 A.1 Basic Link Services 2963 The basic link services are shown in the following table. 2965 Basic Link Services 2967 Name Description iFCP Policy 2968 ---- ----------- ---------- 2970 ABTS Abort Sequence Transparent 2971 BA_ACC Basic Accept Transparent 2972 BA_RJT Basic Reject Transparent 2973 NOP No Operation Transparent 2974 PRMT Preempted Rejected 2975 (Applies to 2976 Class 1 only) 2977 RMC Remove Connection Rejected 2978 (Applies to 2979 Class 1 only) 2981 A.2 Link Services Processed Transparently 2983 The following link service requests and responses MUST be 2984 processed transparently as defined in section 7. 2986 ELSs Processed Transparently 2988 Name Description 2989 ---- ----------- 2991 ACC Accept 2992 ADVC Advise Credit 2993 CSR Clock Synchronization Request 2994 CSU Clock Synchronization Update 2995 ECHO Echo 2996 ESTC Estimate Credit 2997 ESTS Establish Streaming 2998 FACT Fabric Activate Alias_ID 2999 FAN Fabric Address Notification 3000 FDACT Fabric Deactivate Alias_ID 3001 FDISC Discover F_Port Service 3002 Parameters 3004 Monia Standards Track 61 3005 FLOGI F_Port Login 3006 GAID Get Alias_ID 3007 LCLM Login Control List Management 3008 LINIT Loop Initialize 3009 LIRR Link Incident Record 3010 Registration 3011 LPC Loop Port Control 3012 LS_RJT Link Service Reject 3013 LSTS Loop Status 3014 NACT N_Port Activate Alias_ID 3015 NDACT N_Port Deactivate Alias_ID 3016 PDISC Discover N_Port Service 3017 Parameters 3018 PRLI Process Login 3019 PRLO Process Logout 3020 QoSR Quality of Service Request 3021 RCS Read Connection Status 3022 RLIR Registered Link Incident Report 3023 RNC Report Node Capability 3024 RNFT Report Node FC-4 Types 3025 RNID Request Node Identification 3026 Data 3027 RPL Read Port List 3028 RPS Read Port Status Block 3029 RPSC Report Port Speed Capabilities 3030 RSCN Registered State Change 3031 Notification 3032 RTIN Request Topology Information 3033 RTV Read Timeout Value 3034 RVCS Read Virtual Circuit Status 3035 SBRP Set Bit-error Reporting 3036 Parameters 3037 SCL Scan Remote Loop 3038 SCN State Change Notification 3039 SCR State Change Registration 3040 TEST Test 3041 TPLS Test Process Login State 3043 A.3 Augmented Link Services 3045 The following extended link services are augmented with 3046 additional data and processed by the iFCP implementation as 3047 described in the referenced section listed in the table. 3049 Augmented Link Services 3051 Name Description Section 3052 ---- ----------- ------- 3054 ABTX Abort Exchange 7.3.1 3055 ADISC Discover Address 7.3.2 3057 Monia Standards Track 62 3058 ADISC Discover Address Accept 7.3.3 3059 ACC 3060 FARP- Fibre Channel Address 7.3.4 3061 REPLY Resolution Protocol Reply 3062 FARP-REQ Fibre Channel Address 7.3.5 3063 Resolution Protocol Request 3064 LOGO N_PORT Logout 7.3.6 3065 PLOGI Port Login 7.3.7 3066 REC Read Exchange Concise 7.3.8 3067 REC ACC Read Exchange Concise Accept 7.3.9 3068 RES Read Exchange Status Block 7.3.10 3069 RES ACC Read Exchange Status Block 7.3.11 3070 Accept 3071 RLS Read Link Error Status Block 7.3.12 3072 RRQ Reinstate Recovery Qualifier 7.3.14 3073 RSI Request Sequence Initiative 7.3.15 3074 RSS Read Sequence Status Block 7.3.13 3075 TPRLO Third Party Process Logout 7.3.16 3077 Monia Standards Track 63 3078 Appendix B 3080 B. Performance of The Multi-Connection iFCP Session Model 3082 This appendix provides a quantitative analysis of the claim 3083 that N TCP connections carrying the traffic of all the 3084 sessions active between gateways provide 3085 significantly higher aggregate average throughput than a 3086 single TCP connection carrying the same 3087 sessions. The analysis shows that the difference is 3088 proportional to the square of the number of TCP sessions, N. 3090 This analyses is based on three fundamental assumptions: (i) 3091 all the available bandwidth in a link is available to iFCP 3092 traffic, (ii) the sender has always data ready to send (as is 3093 most likely the case with a backup application), and (iii) the 3094 maximum window size at the two TCP ends (i.e., the iFCP 3095 gateways) is set to the link nominal capacity multiplied by 3096 the round-trip-time (so as to have the highest chances of 3097 saturating the link yet without unduly raising buffering 3098 requirements at the end nodes). The N^2 factor that emerges 3099 from this analysis is essentially due to the way TCP 3100 congestion control reacts to packet losses. 3102 B.1 Relationship of Throughput to Packet Losses 3104 There are several reasons for packet losses: network 3105 congestion, link errors and network errors. Network congestion 3106 is pervasive in current IP networks, where the only way to 3107 control congestion is through dropping packets. Techniques for 3108 loss prevention, such as traffic engineering, admission 3109 control and bandwidth reservation, are not widely deployed and 3110 hence are not a factor in the behavior of existing networks. 3112 Even in a perfectly engineered network, link errors occur. 3113 Assuming a link error rate equal to that specified for Fibre 3114 Channel (10^-12) and a 10Gb/s link, there is one error every 3115 100 seconds. Network errors also occur with significant 3116 frequency in IP networks. Jonathan Stone and Craig Partridge 3117 recently reported in Sigcomm 2000 that network errors caught 3118 by the TCP checksum occur with significant frequency. Between 3119 one packet in 1100 and 1 in 32000 have errors get past the 3120 link CRC and are detected by the TCP/IP checksum. 3122 TCP throughput is impacted by each packet loss. Following 3123 TCP's congestion control algorithm (supported by the Tahoe, 3124 Reno, New-Reno, and SACK implementations) each packet loss 3125 results in the TCP sender's congestion window being reduced to 3126 half of its current value, and therefore (assuming constant 3127 Round Trip Time), TCP's throughput is halved. After that, the 3128 window increases by roughly one packet every two Round Trip 3129 Times (assuming the widely-used Delayed-Acknowledgement 3131 Monia Standards Track 64 3132 algorithm). The temporary decrease in TCP's rate translates 3133 into a missed opportunity to transmit a given amount of data. 3134 As we show in the following Background section, for N storage 3135 connections sharing an IP "pipe" of rate E, the amount of data 3136 missing the opportunity to be transmitted due to a packet loss 3137 is: 3139 D(N) = E^2/(N^2)*RTT^2/(256*M) 3141 where RTT = Round Trip Time, M = packet size. 3143 For example, for a set of N=100 connections totaling E=10Gb/s, 3144 RTT=10ms, M=1500B, the data not transmitted in time due to a 3145 packet loss is D(N)=2.6MB. For the same set transported over 3146 one TCP session, the data not sent in time is D(1)= 26GB, a 3147 10,000 fold increase. The time interval for TCP to recover its 3148 sending rate to its initial value after a packet loss is I(N)= 3149 0.833 seconds in the case N TCP connections, and 3150 I(1)=83.3seconds in the case of a single TCP connection. 3151 Observe that in the latter case, the time to recover its rate, 3152 I(1)=83.3s, is of the same order of magnitude as the time 3153 between two packet losses due exclusively to a link Bit Error 3154 Rate of 10^-12. In other words, a packet loss occurs almost 3155 immediately after TCP has recovered its rate. 3157 This means that a single TCP connection delivers on average 3158 about 3/4 of the required 10Gb/s rate, since 1/4 of the rate 3159 is lost during the time the TCP rate is increasing linearly 3160 from 1/2 to full rate. (More precisely, the effective rate is 3161 8.27Gb/s because 1/4 of the rate is lost during 83.3s, and the 3162 time between two errors is now 120.825s due to a decreased 3163 sending rate). By comparison, N TCP connections deliver 3164 approximately 9.99979Gb/s (i.e., lost 1/4 of one TCP full rate 3165 of 100Mb/s during 0.833s out of a 100s interval). 3167 If the impact of TCP checksum errors is also considered, the 3168 TCP sending rate is limited to an average of 3169 (8M/RTT)sqrt(3/4p), where p is the probability of packet loss 3170 (see [1] for details). For M=1500, RTT=10ms and p=1/32000, TCP 3171 throughput is about 240Mb/s. For p=1/1100, maximum TCP 3172 throughput is 34.4Mb/s. Therefore, to fill a 10Gb/s line, 3173 about 42 simultaneous TCP flows are required (in the case 3174 where p=1/32000) or 291 TCP flows (in the case where 3175 p=1/1100). 3177 Practically, for these reasons the iFCP protocol supports 3178 combinations of M tuples using N TCP 3179 connections, with M, N >= 1, and with an individual tuple using at most one TCP connection (thus M >= N). 3182 B.2 Background. 3184 Monia Standards Track 65 3185 For a TCP session to sustain a rate of C bits/second, the 3186 TCP's maximum congestion window W (measured in number of 3187 packets) has to be at least W0=RTT*C/(8*M) where RTT = Round 3188 Trip Time in seconds, M = packet size in Bytes. The following 3189 analyses assumes W=W0. Later, the problems with the 3190 alternative W>W0 are discussed. 3192 The time needed by the TCP sender to recover from a single 3193 packet loss and have its sending rate reach the previous C 3194 value is 3196 I = 2*RTT*W/2 = RTT*W = RTT^2*C/(8*M). 3198 The total amount of data (in Bytes) missing the opportunity to 3199 be transmitted in this time interval I is: 3201 D = C/8*I/4 = C^2*RTT^2/(256*M) 3203 Consider a set of tuples sharing an IP "pipe" 3204 of rate E to be transported in N TCP sessions. Assuming all 3205 connections are processed equally, each TCP session sends at a 3206 rate of E/N. One packet loss impacts only one TCP session, and 3207 thus, the total amount of data missing the opportunity to be 3208 transmitted due to a packet loss is 3210 D(N) = E^2/(N^2)*RTT^2/(256*M). 3212 On the other hand, if the same set of tuples 3213 sharing an IP "pipe" of rate E is transported in one TCP 3214 session only, the total amount of data losing the opportunity 3215 to be transmitted due to a packet loss is 3217 D(1) = E^2*RTT^2/(256*M) = D(N)*N^2. 3219 The impact of packet losses on the single-TCP solution can be 3220 reduced by configuring the maximum congestion window to be 3221 larger than the bandwidth*delay product, W>W0. But in this 3222 case, only W0 packets can be in transit on the line, while the 3223 rest (up to the current window size) need to be stored in a 3224 queue at the line's ingress. In order to provide full line 3225 rate utilization assuming periodic losses, the maximum 3226 congestion window should be at least 2*W0, due to TCP's 3227 congestion 3229 Monia Standards Track 66 3230 Full Copyright Statement 3232 "Copyright (C) The Internet Society (date). All Rights 3233 Reserved. This document and translations of it may be copied 3234 and furnished to others, and derivative works that comment on 3235 or otherwise explain it or assist in its implmentation may be 3236 prepared, copied, published and distributed, in whole or in 3237 part, without restriction of any kind, provided that the above 3238 copyright notice and this paragraph are included on all such 3239 copies and derivative works. However, this document itself may 3240 not be modified in any way, such as by removing the copyright 3241 notice or references to the Internet Society or other Internet 3242 organizations, except as needed for the purpose of developing 3243 Internet standards in which case the procedures for copyrights 3244 defined in the Internet Standards process must be followed, or 3245 as required to translate it into languages other than English. 3247 The limited permissions granted above are perpetual and will 3248 not be revoked by the Internet Society or its successors or 3249 assigns. 3251 This document and the information contained herein is provided 3252 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 3253 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3254 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 3255 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 3256 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 3257 PARTICULAR PURPOSE." 3259 1 Bradner, S., "The Internet Standards Process -- Revision 3", 3260 BCP 9, RFC 2026, October 1996. 3262 2 Bradner, S., "Key words for use in RFCs to Indicate 3263 Requirement Levels", BCP 14, RFC 2119, March 1997 3265 Monia Standards Track 67