idnits 2.17.1 draft-ietf-ips-ifcp-08.txt: ** The Abstract section seems to be numbered -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(340): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(387): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(543): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(546): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(576): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(583): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(590): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(597): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(601): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(729): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(742): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(747): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1088): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1093): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2520): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3157): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4007): 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 65 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 a Security Considerations section. ** The document seems to lack an Authors' Addresses Section. ** There are 1109 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 324 has weird spacing: '...emented by an...' == Line 371 has weird spacing: '... Unlike a lay...' == Line 1398 has weird spacing: '...sulates and d...' == Line 1541 has weird spacing: '...Request expl...' == Line 1558 has weird spacing: '...Request expl...' == (6 more instances...) -- 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 (January 2002) is 8138 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: 'FC-FLA' is mentioned on line 4456, but not defined == Missing Reference: 'KEMCMP' is mentioned on line 4414, but not defined == Missing Reference: 'KEMALP' is mentioned on line 366, but not defined == Missing Reference: 'FC-AL2' is mentioned on line 4422, but not defined == Missing Reference: 'RFC1122' is mentioned on line 4459, but not defined == Missing Reference: 'RFC896' is mentioned on line 4425, but not defined ** Obsolete undefined reference: RFC 896 (Obsoleted by RFC 7805) == Missing Reference: 'RFC1323' is mentioned on line 4462, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) == Missing Reference: 'RFC2030' is mentioned on line 4437, but not defined ** Obsolete undefined reference: RFC 2030 (Obsoleted by RFC 4330) == Missing Reference: '0x0' is mentioned on line 2064, but not defined == Missing Reference: '0x1' is mentioned on line 2066, but not defined -- Looks like a reference, but probably isn't: '0' on line 2066 == Missing Reference: '0x00' is mentioned on line 2068, but not defined == Missing Reference: '0x0000' is mentioned on line 2071, but not defined == Missing Reference: '0x01' is mentioned on line 2456, but not defined == Missing Reference: 'FCS' is mentioned on line 3001, but not defined == Missing Reference: 'FC-VI' is mentioned on line 2817, but not defined == Missing Reference: 'RFC2625' is mentioned on line 4428, but not defined ** Obsolete undefined reference: RFC 2625 (Obsoleted by RFC 4338) == Missing Reference: 'RFC2131' is mentioned on line 4431, but not defined == Missing Reference: 'RFC2405' is mentioned on line 4479, but not defined == Missing Reference: 'RFC2709' is mentioned on line 4440, but not defined == Missing Reference: 'AES' is mentioned on line 4465, but not defined == Missing Reference: 'XCBC' is mentioned on line 4469, but not defined == Missing Reference: 'AESCTR' is mentioned on line 4474, but not defined == Missing Reference: 'RFC2923' is mentioned on line 4443, but not defined == Missing Reference: 'RFC1633' is mentioned on line 4448, but not defined == Missing Reference: 'RFC2475' is mentioned on line 4452, but not defined == Missing Reference: 'RFC3031' is mentioned on line 4482, but not defined == Missing Reference: 'MPSLDS' is mentioned on line 4486, but not defined == Missing Reference: 'DIFTERM' is mentioned on line 4491, but not defined == Missing Reference: 'KEMAbLP' is mentioned on line 4418, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-SW2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-GS3' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-ietf-ips-fcencapsulation-01 -- No information found for draft-ietf-ips - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ISNS' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) Summary: 16 errors (**), 0 flaws (~~), 38 warnings (==), 8 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 July 2002 Josh Tseng 5 Nishan Systems 7 Franco Travostino 8 Nortel Networks 10 David Robinson 11 Sun Microsystems 13 Wayland Jeong 14 Troika Networks 16 Rory Bolt 17 Quantum/ATL 19 Paul Rutherford 20 ADIC 22 Mark Edwards 23 Eurologic 25 January 2002 27 iFCP - A Protocol for Internet Fibre Channel Storage Networking 29 Status of this Memo 31 This document is an Internet-Draft and is in full conformance with 32 all provisions of Section 10 of RFC 2026 [RFC2026]. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. Internet-Drafts are draft documents valid for a maximum of 38 six months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet-Drafts 40 as reference material or to cite them other than as "work in 41 progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Comments 51 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 52 or to the author(s). 54 iFCP Revision 8 January 2002 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 4. Fibre Channel Communication Concepts.........................7 65 4.1 The Fibre Channel Network....................................7 66 4.2 Fabric Topologies............................................8 67 4.2.1 Switched Fibre Channel Fabrics..............................9 68 4.2.2 Mixed Fibre Channel Fabric.................................10 69 4.3 Fibre Channel Layers and Link Services......................11 70 4.3.1 Fabric-Supplied Link Services..............................12 71 4.4 Fibre Channel Nodes.........................................12 72 4.5 Fibre Channel Device Discovery..............................13 73 4.6 Fibre Channel Information Elements..........................13 74 4.7 Fibre Channel Frame Format..................................14 75 4.7.1 N_PORT Address Model.......................................14 76 4.8 Fibre Channel Transport Services............................15 77 4.9 Login Processes.............................................16 78 5. The iFCP Network Model......................................16 79 5.1 Fibre Channel Fabric Topologies Supported by iFCP...........18 80 5.2 iFCP Transport Services.....................................18 81 5.2.1 Fibre Channel Transport Services Supported by iFCP.........18 82 5.3 iFCP Device Discovery and Configuration Management..........19 83 5.4 iFCP Fabric Properties......................................19 84 5.4.1 Address Transparency.......................................20 85 5.4.2 Configuration Scalability..................................20 86 5.4.3 Fault Tolerance............................................20 87 5.5 The iFCP N_PORT Address Model...............................21 88 5.5.1 Operation in Address Transparent Mode......................22 89 5.5.2 Operation in Address Translation Mode......................23 90 5.5.3 Address Translation........................................24 91 6. iFCP Protocol...............................................27 92 6.1 Overview....................................................27 93 6.1.1 iFCP Transport Services....................................27 94 6.1.2 iFCP Support for Link Services............................28 95 6.2 TCP Stream Transport of iFCP Frames.........................29 96 6.2.1 iFCP Session Model.........................................29 97 6.2.2 iFCP Session Management....................................29 98 6.2.3 Terminating an N_PORT Login Session........................34 99 6.3 IANA Considerations.........................................35 100 6.4 Encapsulation of Fibre Channel Frames.......................35 101 6.4.1 Encapsulation Header Format................................36 102 6.4.2 SOF and EOF Delimiter Fields...............................39 103 6.4.3 Frame Encapsulation........................................40 104 6.4.4 Frame De-encapsulation.....................................40 105 7. TCP Session Control Messages................................41 106 7.1 Connection Bind (CBIND).....................................43 107 7.2 Unbind Connection (UNBIND)..................................46 108 iFCP Revision 8 January 2002 110 7.3 LTEST -- Test Connection Liveness...........................48 111 8. Fibre Channel Link Services.................................49 112 8.1 Special Link Service Messages...............................50 113 8.2 Link Services Requiring Payload Address Translation.........52 114 8.3 Fibre Channel Link Services Processed by iFCP...............54 115 8.3.1 Special Extended Link Services.............................55 116 8.3.2 Special FC-4 Link Services.................................68 117 8.4 FLOGI Service Parameters Supported by an iFCP Gateway.......70 118 9. iFCP Error Detection........................................72 119 9.1 Overview....................................................72 120 9.2 Stale Frame Prevention......................................72 121 9.2.1 Enforcing R_A_TOV Limits...................................73 122 10. Fabric Services Supported by an iFCP implementation.........75 123 10.1 F_PORT Server...............................................75 124 10.2 Fabric Controller...........................................75 125 10.3 Directory/Name Server.......................................75 126 10.4 Broadcast Server............................................76 127 10.4.1 Establishing the Broadcast Configuration.................76 128 10.4.2 Broadcast Session Management.............................77 129 11. iFCP Security...............................................78 130 11.1 Overview....................................................78 131 11.2 iFCP Security Operating Requirements........................78 132 11.2.1 Context..................................................78 133 11.2.2 Security Threats.........................................78 134 11.2.3 Interoperability Requirements with Security Gateways.....79 135 11.2.4 Statically and Dynamically Assigned IP Addresses.........79 136 11.2.5 Authentication Requirements..............................79 137 11.2.6 Confidentiality Requirements.............................80 138 11.2.7 Rekeying Requirements....................................80 139 11.2.8 Usage Requirements.......................................80 140 11.2.9 iSNS Role................................................80 141 11.3 iFCP Security Design........................................80 142 11.3.1 Enabling Technologies....................................80 143 11.3.2 Use of IKE and IPsec.....................................82 144 11.3.3 Signatures and Certificate-based authentication..........84 145 11.4 iSNS and iFCP Security......................................84 146 11.5 Use of iSNS to Distribute Security Policy...................85 147 11.6 Minimal Security Policy for an iFCP gateway.................86 148 12. Quality of Service Considerations...........................86 149 12.1 Minimal requirements........................................86 150 12.2 High-assurance..............................................86 151 13. Author's Addresses..........................................88 152 14. References..................................................90 153 14.1 Normative...................................................90 154 14.2 Non-Normative...............................................91 155 A. iFCP Support for Fibre Channel Link Services................93 156 A.1 Basic Link Services.........................................93 157 A.2 Link Services Processed Transparently.......................93 158 A.3 iFCP-Processed Link Services................................94 159 Full Copyright Statement.............................................97 160 iFCP Revision 8 January 2002 162 1. Abstract 164 This document specifies an architecture and gateway-to-gateway 165 protocol for the implementation of Fibre Channel fabric 166 functionality on a network in which TCP/IP switching and routing 167 elements replace Fibre Channel components. The protocol enables the 168 attachment of Fibre Channel devices to an IP network by supporting 169 the fabric services required by such devices. 171 2. About This Document 173 2.1 Conventions used in this document 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 177 this document are to be interpreted as described in RFC-2119 178 [RFC2119]. 180 All frame formats are in big endian network byte order. 182 2.2 Purpose of this document 184 This is a standards-track document, which specifies a protocol for 185 the implementation of Fibre Channel transport services on a TCP/IP 186 network. Some portions of this document contain material from 187 standards controlled by NCITS T10 and T11. This material is 188 included here for informational purposes only. The authoritative 189 information is given in the appropriate NCITS standards document. 191 The authoritative portions of this document specify the mapping of 192 standards-compliant fibre Channelprotocol implementations to 193 TCP/IP. This mapping includes sections of this document which 194 describe the "iFCP Protocol" (see section 6). 196 3. iFCP Introduction 198 iFCP is a gateway-to-gateway protocol, which provides Fibre Channel 199 fabric services to Fibre Channel devices over a TCP/IP network. 200 iFCP uses TCP to provide congestion control, error detection and 201 recovery. iFCP's primary objective is to allow interconnection and 202 networking of existing Fibre Channel devices at wire speeds over an 203 IP network. 205 The protocol and method of frame address translation described in 206 this document permit the attachment of Fibre Channel storage 207 devices to an IP-based fabric by means of transparent gateways. 209 The protocol achieves this transparency by allowing normal Fibre 210 Channel frame traffic to pass through the gateway directly, with 212 iFCP Revision 8 January 2002 214 provisions, where necessary, for intercepting and emulating the 215 fabric services required by a Fibre Channel device. 217 3.1 Definitions 219 Terms needed to clarify the concepts presented in this document are 220 presented here. 222 Locally Attached Device - With respect to a gateway, a Fibre 223 Channel device accessed through the Fibre Channel fabric to 224 which the gateway is attached. 226 Remotely Attached Device - With respect to a gateway, a Fibre 227 Channel device accessed from the gateway by means of the 228 iFCP protocol. 230 Address-translation mode � A mode of gateway operation in which the 231 scope of N_PORT fabric addresses for locally attached 232 devices are local to the iFCP gateway. 234 Address-transparent mode � A mode of gateway operation in which the 235 scope of N_PORT fabric addresses for all Fibre Channel 236 devices are unique to the logical fabric to which the 237 gateway belongs. 239 Gateway Region � The portion of the iFCP storage network accessed 240 through an iFCP gateway. Fibre Channel devices in the 241 region consist of all Fibre Channel devices locally 242 attached to the gateway. 244 Logical Fabric � The union of two or more gateway regions 245 configured to interoperate together in address-transparent 246 mode. 248 Fibre Channel Device - An entity implementing the functionality 249 accessed through an FC-4 application protocol. 251 Fibre Channel Node - A collection of one or more N_Ports controlled 252 by a level above the FC-2 layer. A node is attached to a 253 Fibre Channel fabric by means of the N_PORT interface 254 described in [FC-FS]. 256 Fibre Channel Network - A native Fibre Channel fabric and all 257 attached Fibre Channel nodes. 259 Fabric - The components of a network that provide the transport 260 services defined in [FC-FS]. A fabric may be implemented in 261 the IP framework by means of the architecture and protocols 262 discussed in this document. 264 Fabric Port - The interface through which an N_PORT accesses a 265 Fibre Channel fabric. The type of fabric port depends on 267 iFCP Revision 8 January 2002 269 the Fibre Channel fabric topology. In this specification, 270 all fabric port interfaces are considered to be 271 functionally equivalent. 273 FC-2 - The Fibre Channel transport services layer described in [FC- 274 FS]. 276 FC-4 - The Fibre Channel application layer. This layer is 277 functionally equivalent to the TCP/IP application layer. 279 iFCP Portal - An entity representing the point at which a logical 280 or physical iFCP device is attached to the IP network. The 281 network address of the iFCP portal consists of the IP 282 address and TCP port number. 284 N_PORT - An iFCP or Fibre Channel entity representing the interface 285 to Fibre Channel device functionality. This interface 286 implements the Fibre Channel N_PORT semantics specified in 287 [FC-FS]. Fibre Channel defines several variants of this 288 interface that are dependant on the Fibre Channel fabric 289 topology. As used in this document, the term applies 290 equally to all variants. 292 N_PORT fabric address - The address of an N_PORT within the Fibre 293 Channel fabric. 295 N_PORT ID -- The address of a locally attached N_PORT within a 296 gateway region. N_PORT I/Ds are assigned in accordance 297 with the Fibre Channel rules for address assignment 298 specified in [FC-FS]. 300 N_PORT Alias -- The N_PORT address assigned by a gateway to 301 represent a remote N_PORT accessed via the iFCP protocol. 302 When routing frame traffic in address translation mode, the 303 gateway automatically converts N_PORT aliases to N_PORT 304 network addresses and vice versa. 306 N_PORT Network Address - The address of an N_PORT in the IP fabric. 307 This address consists of the IP address of the iFCP Portal 308 and the N_PORT ID of the locally attached Fibre Channel 309 device. 311 F_PORT - The interface used by an N_PORT to access Fibre Channel 312 switched fabric functionality. 314 iFCP - The protocol discussed in this document. 316 Logical iFCP Device - The abstraction representing a single Fibre 317 Channel device as it appears on an iFCP network. 319 iSNS - The server functionality and IP protocol which provides 320 storage name services in an iFCP network. Fibre Channel 322 iFCP Revision 8 January 2002 324 Name services are implemented by an iSNS name server as 325 described in [ISNS]. 327 N_PORT Session - An association created when two N_PORTS have 328 executed a PLOGI operation. It is comprised of the N_PORTs 329 and TCP connection that carries traffic between them. 331 iFCP Frame - A Fibre Channel frame encapsulated in accordance with 332 the Common Encapsulation Specification [ENCAP] and this 333 specification. 335 Port Login (PLOGI) - The Fibre Channel Extended Link Service (ELS) 336 that establishes an N_PORT login session through the 337 exchange of identification and operation parameters between 338 an originating N_PORT and a responding N_PORT. 340 DOMAIN_ID � The value contained in the high-order byte of a 24-bit 341 N_PORT Fibre Channel address. 343 4. Fibre Channel Communication Concepts 345 Fibre Channel is a frame-based, serial technology designed for 346 peer-to-peer communication between devices at gigabit speeds and 347 with low overhead and latency. 349 This section contains a discussion of the Fibre Channel concepts 350 that form the basis for the iFCP network architecture and protocol 351 described in this document. Readers familiar with this material may 352 skip to section 5. 354 Material presented in this section is drawn from the following T11 355 specifications: 357 -- The Fibre Channel Framing and Signaling Interface, [FC-FS] 359 -- Fibre Channel Switch Fabric -2, [FC-SW2] 361 -- Fibre Channel Generic Services, [FC-GS3] 363 -- Fibre Channel Fabric Loop Attachment, [FC-FLA] 365 The reader will find an in-depth treatment of the technology in 366 [KEMCMP] and [KEMALP]. 368 4.1 The Fibre Channel Network 370 The fundamental entity in Fibre Channel is the Fibre Channel 371 network. Unlike a layered network architecture, a Fibre Channel 372 network is largely specified by functional elements and the 373 interfaces between them. As shown in Figure 1, these consist, in 374 part, of the following: 376 iFCP Revision 8 January 2002 378 a) N_PORTs -- The end points for Fibre Channel traffic. In the FC 379 standards, N_PORT interfaces have several variants, depending on 380 the topology of the fabric to which they are attached. As used 381 in this specification, the term applies to any one of the 382 variants. 384 b) FC Devices � The Fibre Channel devices to which the N_PORTs 385 provide access. 387 c) Fabric Ports -� The interface within a fabric that provides Fibre 388 Channel attachment for an N_PORT. The types of fabric port 389 depend on the fabric topology and are discussed in section 4.2. 391 d) The fabric infrastructure for carrying frame traffic between 392 N_PORTs. 394 e) Within a switched or mixed fabric (see section 4.2), a set of 395 auxiliary servers, including a name server for device discovery 396 and network address resolution. The types of service depend on 397 the network topology. 399 +--------+ +--------+ +--------+ +--------+ 400 | FC | | FC | | FC | | FC | 401 | Device | | Device |<-------->| Device | | Device | 402 |........| |........| |........| |........| 403 | N_PORT | | N_PORT | | N_PORT | | N_PORT | 404 +---+----+ +----+---+ +----+---+ +----+---+ 405 | | | | 406 +---+----+ +----+---+ +----+---+ +----+---+ 407 | Fabric | | Fabric | | Fabric | | Fabric | 408 | Port | | Port | | Port | | Port | 409 +========+===+========+==========+========+==+========+ 410 | Fabric | 411 | & | 412 | Fabric Services | 413 +-----------------------------------------------------+ 414 Figure 1 -- A Fibre Channel Network 416 The following sections describe Fibre Channel fabric topologies and 417 give an overview of the Fibre Channel communications model. 419 4.2 Fabric Topologies 421 The principal Fibre Channel fabric topologies consist of the 422 following: 424 a) Arbitrated Loop -- A series of N_PORTs connected together in 425 daisy-chain fashion. Data transmission between N_PORTs 426 requires arbitration for control of the loop in a manner 427 similar to a token ring network. 429 iFCP Revision 8 January 2002 431 b) Switched Fabric -- A fabric consisting of switching elements, 432 as described in section 4.2.1. 434 c) Mixed Fabric -- A fabric consisting of switches and "fabric- 435 attached" loops. A description can be found in [FC-FLA]. 437 Depending on the topology, the N_PORT and fabric port variants 438 through which a Fibre Channel device is attached to the network may 439 be one of the following: 441 Fabric Topology Fabric Port Type N_PORT Variant 442 --------------- ---------------- -------------- 444 Loop L_PORT NL_PORT 446 Switched F_PORT N_PORT 448 Mixed FL_PORT NL_PORT 450 F_PORT N_PORT 452 The differences in each N_PORT variant and its corresponding fabric 453 port are confined to the interactions between them. To an external 454 N_PORT, all fabric ports are transparent and all remote N_PORTs are 455 functionally identical. 457 4.2.1 Switched Fibre Channel Fabrics 459 An example of a multi-switch Fibre Channel fabric is shown below. 461 iFCP Revision 8 January 2002 463 +----------+ +----------+ 464 | FC | | FC | 465 | Device | | Device | 466 |..........| |..........| 467 | N_PORT |<........>| N_PORT | 468 +----+-----+ +-----+----+ 469 | | 470 +----+-----+ +-----+----+ 471 | F_PORT | | F_PORT | 472 ==========+==========+==========+==========+============== 473 | FC | | FC | 474 | Switch | | Switch | 475 +----------+ +----------+ Fibre Channel 476 |Inter- | |Inter- | Fabric 477 |Switch | |Switch | 478 |Interface | |Interface | 479 +-----+----+ +-----+----+ 480 | | 481 | | 482 +-----+----+----------+-----+----+ 483 |Inter- | |Inter- | 484 |Switch | |Switch | 485 |Interface | |Interface | 486 +----------+ +----------+ 487 | FC Switch | 488 | | 489 +--------------------------------+ 490 Figure 3 -- Multi-Switch Fibre Channel Fabric 492 The interface between switch elements is either proprietary or the 493 standards-compliant E_PORT interface described by the FC-SW2 494 specification, [FC-SW2]. 496 4.2.2 Mixed Fibre Channel Fabric 498 A mixed fabric contains one or more arbitrated loops connected to a 499 switched fabric as shown in Figure 4. 501 iFCP Revision 8 January 2002 503 +----------+ +----------+ +---------+ 504 | FC | | FC | | FC | 505 | Device | | Device | | Device | 506 |..........| |..........| |.........| 507 | N_PORT |<........>| NL_PORT +---+ NL_PORT | 508 +----+-----+ +-----+----+ +----+----+ 509 | | FC Loop | 510 +----+-----+ +-----+----+ | 511 | F_PORT | | FL_PORT +--------+ 512 | | | | 513 ==========+==========+==========+==========+============== 514 | FC | | FC | 515 | Switch | | Switch | 516 +----------+ +----------+ 517 |Inter- | |Inter- | 518 |Switch | |Switch | 519 |Interface | |Interface | 520 +-----+----+ +-----+----+ 521 | | 522 | | 523 +-----+----+----------+-----+----+ 524 |Inter- | |Inter- | 525 |Switch | |Switch | 526 |Interface | |Interface | 527 +----------+ +----------+ 528 | FC Switch | 529 | | 530 +--------------------------------+ 531 Figure 4 -- Mixed Fibre Channel Fabric 533 As noted previously, the protocol for communications between peer 534 N_PORTs is independent of the fabric topology, N_PORT variant and 535 type of fabric port to which an N_PORT is attached. 537 4.3 Fibre Channel Layers and Link Services 539 Fibre channel consists of the following layers: 541 FC-0 -- The interface to the physical media, 543 FC-1 �- The encoding and decoding of data and out-of-band physical 544 link control information for transmission over the physical media, 546 FC-2 �- The transfer of frames, sequences and Exchanges comprising 547 protocol information units. 549 FC-3 �- Common Services, 551 FC-4 �- Application protocols, such as FCP, the Fibre Channel SCSI 552 protocol. 554 iFCP Revision 8 January 2002 556 In addition to the layers defined above, Fibre Channel defines a 557 set of auxiliary operations, some of which are implemented within 558 the transport layer fabric, called link services. These are 559 required to manage the Fibre Channel environment, establish 560 communications with other devices, retrieve error information, 561 perform error recovery and other similar services. Some link 562 services are executed by the N_PORT. Others are implemented 563 internally within the fabric. These internal services are 564 described in the next section. 566 4.3.1 Fabric-Supplied Link Services 568 Servers internal to a switched fabric handle certain classes of 569 Link Service requests and service-specific commands. The servers 570 appear as N_PORTs located at the 'well-known' N_PORT fabric 571 addresses specified in [FC-FS]. Service requests use the standard 572 Fibre Channel mechanisms for N_PORT-to-N_PORT communications. 574 All switched fabrics must provide the following services: 576 Fabric F_PORT server � Services an N_PORT request to access the 577 fabric for communications. 579 Fabric Controller -- Provides state change information to inform 580 other FC devices when an N_PORT exits or enters the fabric (see 581 section 4.5). 583 Directory/Name Server � Allows N_PORTs to register information 584 in a database, retrieve information about other N_PORTs and 585 discover other devices as described in section 4.5. 587 A switched fabric may also implement the following optional 588 services: 590 Broadcast Address/Server �- Transmits single-frame, class 3 591 sequences to all N_PORTs. 593 Time Server �- Intended for the management of fabric-wide 594 expiration timers or elapsed time values and is not intended for 595 precise time synchronization. 597 Management Server � Collects and reports management information, 598 such as link usage, error statistics, link quality and similar 599 items. 601 Quality of Service Facilitator � Performs fabric-wide bandwidth 602 and latency management. 604 4.4 Fibre Channel Nodes 606 A Fibre Channel node has one or more fabric-attached N_PORTs. The 607 node and its N_PORTs have the following associated identifiers: 609 iFCP Revision 8 January 2002 611 a) A world-wide unique identifier for the node, 613 b) A world-wide unique identifier for each N_PORT associated with 614 the nodee, 616 c) For each N_PORT attached to a fabric, a 24-bit fabric-unique 617 address having the properties defined in section 4.7.1. The 618 fabric address is the address to which frames are sent. 620 Each world-wide unique identifier is a 64-bit binary quantity 621 having the format defined in [FC-FS]. 623 4.5 Fibre Channel Device Discovery 625 In a switched or mixed fabric, fibre channel devices and changes in 626 the device configuration may be discovered by means of services 627 provided by the Fibre Channel Name Server and Fabric Controller. 629 The Name Server provides registration and query services that allow 630 a Fibre Channel device to register its presence on the fabric and 631 discover the existence of other devices. For example, one type of 632 query obtains the fabric address of an N_PORT from its 64-bit 633 world-wide unique name. The full set of supported Fibre Channel 634 Name Server queries is specified in [FC-GS3]. 636 The Fabric Controller complements the static discovery capabilities 637 provided by the Name Server through a service that dynamically 638 alerts a Fibre Channel device whenever an N_PORT is added or 639 removed from the configuration. A Fibre Channel device receives 640 these notifications by subscribing to the service as specified in 641 [FC-FS]. 643 4.6 Fibre Channel Information Elements 645 The fundamental element of information in Fibre Channel is the 646 frame. A frame consists of a fixed header and up to 2112 bytes of 647 payload having the structure described in section 4.7. The maximum 648 frame size that may be transmitted between a pair of Fibre Channel 649 devices is negotiable up to the payload limit, based on the size of 650 the frame buffers in each Fibre Channel device and the path MTU 651 supported by the fabric. 653 Operations involving the transfer of information between N_PORT 654 pairs are performed through 'Exchanges'. In an Exchange, 655 information is transferred in one or more ordered series of frames 656 referred to as Sequences. 658 Within this framework, an upper layer protocol is defined in terms 659 of transactions carried by Exchanges. Each transaction, in turn, 660 consists of protocol information units, each of which is carried by 661 an individual Sequence within an Exchange. 663 iFCP Revision 8 January 2002 665 4.7 Fibre Channel Frame Format 667 A Fibre Channel frame consists of a header, payload and 32-bit CRC 668 bracketed by SOF and EOF delimiters. The header contains the 669 control information necessary to route frames between N_PORTs and 670 manage Exchanges and Sequences. The following diagram gives a 671 highly simplified view of the frame. 673 +-----------------------------+ 674 | Start-of-frame Delimiter | 675 +-----+-----------------------+<----+ 676 | | Destination N_PORT | | 677 | | Fabric Address (D_ID) | | 678 | | (24-bits) | | 679 +-----+-----------------------+ 24-byte 680 | | Source N_PORT | Frame 681 | | Fabric Address (S_ID) | Header 682 | | (24 bits) | | 683 +-----+-----------------------+ | 684 | Control information for | | 685 | frame type, Exchange | | 686 | management, IU | | 687 | segmentation and | | 688 | re-assembly | | 689 +-----------------------------+<----+ 690 | | 691 | Frame payload | 692 | (0 � 2112 bytes) | 693 | | 694 | | 695 | | 696 +-----------------------------+ 697 | CRC | 698 +-----------------------------+ 699 | End-of-Frame Delimiter | 700 +-----------------------------+ 701 Figure 6 -- Fibre Channel Frame Format 703 The source and destination N_PORT fabric addresses embedded in the 704 S_ID and D_ID fields represent the physical MAC addresses of 705 originating and receiving N_PORTs. 707 4.7.1 N_PORT Address Model 709 N_PORT fabric addresses are 24-bit values having the following 710 format defined by the Fibre Channel specification [FC-FS]: 712 iFCP Revision 8 January 2002 714 Bit 23 16 15 8 7 0 715 +-----------+------------+----------+ 716 | Domain ID | Area ID | Port ID | 717 +-----------+------------+----------+ 718 Figure 7 -- Fibre Channel Address Format 720 A Fibre Channel device acquires an address when it logs into the 721 fabric. Such addresses are volatile and subject to change based on 722 modifications in the fabric configuration. 724 In a Fibre Channel fabric, each switch element has a unique Domain 725 I/D assigned by the principal switch. The value of the Domain I/D 726 ranges from 1 to 239 (0xEF). Each switch element, in turn, 727 administers a block of addresses divided into area and port IDs. An 728 N_PORT connected to a F_PORT receives a unique fabric address 729 consisting of the switch�s Domain I/D concatenated with switch- 730 assigned area and port I/Ds. 732 A loop-attached NL_PORT (see Figure 4) obtains the Port ID 733 component of its address during the loop initialization process 734 described in [FC-AL2]. The area and domain I/Ds are supplied by the 735 fabric when the FLOGI is executed. 737 4.8 Fibre Channel Transport Services 739 N_PORTs communicate by means of the following classes of service 740 specified in the Fibre Channel standard ([FC-FS]): 742 Class 1 � A dedicated physical circuit connecting two N_PORTs. 744 Class 2 � A frame-multiplexed connection with end-to-end flow 745 control and delivery confirmation. 747 Class 3 � A frame-multiplexed connection with no provisions for 748 end-to-end flow control or delivery confirmation. 750 Class 4 - A connection-oriented service, based on a virtual circuit 751 model, providing confirmed delivery with bandwidth and latency 752 guarantees. 754 Class 6 - A reliable multicast service derived from class 1. 756 Class 2 and class 3 are the predominant services supported by 757 deployed Fibre Channel storage and clustering systems. 759 Class 3 service is similar to UDP or IP datagram service. Fibre 760 channel storage devices using this class of service rely on the ULP 761 implementation to detect and recover from transient device and 762 transport errors. 764 For class 2 and class 3 service, the Fibre Channel fabric is not 765 required to provide in-order delivery of frames unless explicitly 767 iFCP Revision 8 January 2002 769 requested by the frame originator (and supported by the fabric). If 770 ordered delivery is not in effect, it is the responsibility of the 771 frame recipient to reconstruct the order in which frames were sent 772 based on information in the frame header. 774 4.9 Login Processes 776 The Login processes are the means whereby an N_PORT establishes the 777 operating environment necessary to communicate with the fabric, 778 other N_PORTs and ULP implementations accessed via the N_PORT. 779 Three login operations are supported: 781 a) Fabric Login (FLOGI) -- An operation whereby the N_PORT 782 registers its presence on the fabric, obtains fabric 783 parameters, such as classes of service supported, and receives 784 its N_PORT address, 786 b) Port Login (PLOGI) -- An operation by which an N_PORT 787 establishes communication with another N_PORT. 789 c) Process Login (PRLOGI) -- An operation which establishes the 790 process-to-process communications associated with a specific 791 FC-4 ULP -- such as FCP-2, the Fibre Channel SCSI mapping. 793 Since N_PORT addresses are volatile, an N_PORT originating a login 794 (PLOGI) operation executes a Name Server query to discover the 795 Fibre Channel address of the remote device. A common query type 796 involves use of the world-wide unique name of an N_PORT to obtain 797 the 24-bit N_PORT Fibre Channel address to which the PLOGI request 798 is sent. 800 5. The iFCP Network Model 802 The iFCP protocol enables the implementation of Fibre Channel mixed 803 or switched fabric functionality on an IP network in which IP 804 components and technology replace the Fibre Channel switching and 805 routing infrastructure described in section 4.2. 807 The example of Figure 8 shows a Fibre Channel fabric with attached 808 devices. These access the fabric through an N_PORT interface 809 connected to a Fabric Port whose behavior is specified in [FC-FS]. 810 In this case, the N_PORT and Fabric Port represent any of the 811 variants described in section 4.2. 813 Within the Fibre Channel device domain, fabric-addressable entities 814 consist of other N_PORTs and devices internal to the fabric that 815 perform the fabric services defined in [FC-GS3]. 817 iFCP Revision 8 January 2002 819 Fibre Channel Network 820 +--------+ +--------+ 821 | FC | | FC | 822 | Device | | Device | 823 |........| |........| Fibre Channel 824 | N_PORT |<......>| N_PORT | Device Domain 825 +---+----+ +----+---+ ^ 826 | | | 827 +---+----+ +----+---+ | 828 | Fabric | | Fabric | | 829 | Port | | Port | | 830 ==========+========+========+========+============== 831 | Fabric & | | 832 | Fabric Services | v 833 | | Fibre Channel 834 +--------------------------+ Fabric Domain 835 Figure 8 -- A Fibre Channel Fabric 837 Gateway Region Gateway Region 838 +--------+ +--------+ +--------+ +--------+ 839 | FC | | FC | | FC | | FC | 840 | Device | | Device | Fibre | Device | | Device | Fibre 841 |........| |........| Channel |........| |........| Channel 842 | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device 843 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 844 | | | | ^ 845 +---+----+ +---+----+ +----+---+ +----+---+ | 846 | Fabric | | Fabric | | Fabric | | Fabric | | 847 | Port | | Port | | Port | | Port | | 848 =+========+==+========+===========+========+==+========+========== 849 | iFCP Layer |<--------->| iFCP Layer | | 850 |....................| ^ |....................| | 851 | iFCP Portal | | | iFCP Portal | v 852 +--------+-----------+ | +----------+---------+ IP 853 iFCP|Gateway Control iFCP|Gateway Network 854 | Data | 855 | | 856 | | 857 |<------Encapsulated Frames------->| 858 | +------------------+ | 859 | | | | 860 +------+ IP Network +--------+ 861 | | 862 +------------------+ 863 Figure 10 -- An iFCP Fabric 865 Figure 10 shows an implementation of an equivalent iFCP fabric 866 consisting of two gateways, each in control of a single gateway 867 region. 869 iFCP Revision 8 January 2002 871 Each iFCP gateway contains two standards-compliant fibre channel 872 ports and an iFCP Portal for attachment to the IP network. Fibre 873 Channel devices in the region are those directly connected to the 874 iFCP fabric through the gateway fabric ports. 876 Looking into the fabric port, the gateway appears as a Fibre 877 Channel switch element. At this interface, remote N_PORTs are 878 presented as fabric-attached devices. Conversely, on the IP network 879 side, the gateway presents each locally connected N_PORT as a 880 logical Fibre Channel device. 882 5.1 Fibre Channel Fabric Topologies Supported by iFCP 884 A property of this architecture, not shown in the examples, is that 885 the Fibre Channel fabric configuration and topology within the 886 gateway region are invisible to the IP network and other gateway 887 regions. That is, the topology in the gateway region, whether it 888 is loop- or switch-based, is hidden from the IP network and from 889 other gateway regions. As a result, support for specific FC fabric 890 topologies becomes a gateway implementation issue. In such cases, 891 the gateway may implement any standards-compliant Fibre Channel 892 interface by incorporating the functionality required to present 893 locally attached N_PORTs as logical iFCP devices. 895 5.2 iFCP Transport Services 897 N_PORT to N_PORT communications that traverse a TCP/IP network 898 require the intervention of the iFCP layer within the gateway. This 899 consists of the following operations: 901 a) Execution of the frame addressing and mapping functions 902 described in section 5.5. 904 b) Execution of fabric-supplied link services addressed to one of 905 the well-known Fibre Channel N_PORT addresses. 907 c) Encapsulation of Fibre Channel frames for injection into the 908 TCP/IP network and de-encapsulation of Fibre Channel frames 909 received from the TCP/IP network. 911 d) Establishment of an N_PORT login session in response to a PLOGI 912 directed to a remote device. 914 The following sections discuss the frame addressing mechanism and 915 the way in which it is used to achieve communications transparency 916 between N_PORTs. 918 5.2.1 Fibre Channel Transport Services Supported by iFCP 920 An iFCP fabric supports Class 2 and Class 3 Fibre Channel transport 921 services as specified in [FC-FS]. An iFCP fabric does not support 922 class 4, class 6 or the Class 1 (dedicated connection) service. An 924 iFCP Revision 8 January 2002 926 N_PORT discovers the classes of transport services supported by the 927 fabric during fabric login. 929 5.3 iFCP Device Discovery and Configuration Management 931 An iFCP implementation performs device discovery and iFCP fabric 932 management. through the Internet Storage Name Service defined in 933 [ISNS]. Access to an iSNS server is required to perform the 934 following functions:: 936 a) Emulation of the services provided by the Fibre Channel name 937 server described in section 4.3.1, including a mechanism for 938 asynchronously notifying an N_PORT of changes in the iFCP fabric 939 configuration, 941 b) Aggregation of gateways into iFCP fabrics for interoperation, 943 c) Segmentation of an iFCP fabric into Fibre Channel zones through 944 the definition and management of device discovery scopes, 945 referred to as 'discovery domains', 947 d) Storage and distribution of security policies as described in 948 section 11.2.9. 950 e) Implementation of the Fibre Channel broadcast mechanism. 952 5.4 iFCP Fabric Properties 954 A collection of iFCP gateways may be configured for interoperation 955 as either a bounded or unbounded iFCP fabric. 957 Gateways in a bounded iFCP fabric operate in address transparent 958 mode as described in section 5.5.1. In this mode, the scope of a 959 Fibre Channel N_PORT address is fabric-wide and is derived from 960 domain I/Ds issued by the iSNS server from a common pool. As 961 discussed below, the maximum number of domain I/Ds allowed by Fibre 962 Channel limits the configuration of a bounded iFCP fabric. 964 Gateways in an unbounded iFCP fabric operate in address translation 965 mode as described in section 5.5.2. In this mode, the scope of an 966 N_PORT address is local to a gateway region. For Fibre Channel 967 traffic between regions, the translation of frame-embedded N_PORT 968 addresses is performed by the gateway. As discussed below, an 969 unbounded iFCP fabric may have any number of switch elements and 970 gateways. 972 All iFCP gateways MUST unbounded iFCP fabrics. Support for bounded 973 iFCP fabrics is OPTIONAL. 975 The decision to support bounded iFCP fabrics in a gateway 976 implementation depends on the address transparency, configuration 977 scalability, and fault tolerance considerations discussed below. 979 iFCP Revision 8 January 2002 981 5.4.1 Address Transparency 983 Although an iFCP gateways in an unbounded fabric will convert 984 N_PORT addresses in the frame header and payload of standard link 985 service messages, the gateway cannot convert such addresses in the 986 payload of vendor- or user-specific Fibre Channel frame traffic. 988 Consequently, while both bounded and unbounded iFCP fabrics support 989 the standards-compliant FC-4 protocols and link services used by 990 mainstream Fibre Channel applications, a bounded iFCP fabric may 991 also support vendor- or user-specific protocol and link service 992 implementations that carry N_PORT I/Ds in the frame payload. 994 5.4.2 Configuration Scalability 996 The scalability limits of a bounded fabric configuration are a 997 consequence of the Fibre Channel address allocation policy 998 previously discussed. As noted, a bounded iFCP fabric using this 999 address allocation scheme is limited to a combined total of 238 1000 gateways and Fibre Channel switch elements. As the system expands, 1001 the network may grow to include many switch elements and gateways, 1002 each of which controls a small number of devices. In this case, 1003 the limitation in switch and gateway count may become a barrier to 1004 extending and fully integrating the storage network. 1006 Since N_PORT Fibre Channel addresses in an unbounded iFCP fabric 1007 are not fabric-wide, there are no architectural limits on the 1008 number of iFCP gateways, Fibre Channel devices and switch elements 1009 that may be internetworked. In exchange for improved scalability, 1010 however, implementations must consider the incremental overhead of 1011 address conversion as well as the address transparency issues 1012 discussed below. 1014 5.4.3 Fault Tolerance 1016 In an unbounded iFCP fabric, limiting the scope of an N_PORT 1017 address to a gateway region reduces the likelihood that 1018 reassignment of domain I/Ds caused by a disruption in one gateway 1019 region will cascade to others. 1021 In addition, a bounded iFCP fabric has an increased dependency on 1022 the iSNS server, which must act as the central address assignment 1023 authority. If connectivity with the server is lost, new DOMAIN_ID 1024 values cannot be automatically allocated as gateways and Fibre 1025 Channel switch elements are added to the logical fabric. 1027 Finally, adding a gateway to a bounded fabric is more likely to 1028 disrupt the operation of all devices in the gateway region along 1029 with those already in the fabric as new, fabric-wide N_PORT 1030 addresses are assigned. Furthermore, before the new gateway can be 1031 merged, its iSNS server must be slaved to the iSNS server in the 1032 bounded fabric to centralize the issuance of domain I/Ds. 1034 iFCP Revision 8 January 2002 1036 In contrast, adding a new gateway to an unbounded iFCP fabric can 1037 be done non-disruptively and requires only that new gateway's iSNS 1038 server import client attributes from the other iSNS servers. 1040 5.5 The iFCP N_PORT Address Model 1042 This section discusses iFCP extensions to the Fibre Channel 1043 addressing model of section 4.7.1, which are required for the 1044 transparent routing of frames between locally and remotely attached 1045 N_PORTs. 1047 In the iFCP protocol, an N_PORT is represented by the following 1048 addresses: 1050 a) A 24-bit N_PORT I/D. Depending on the gateway addressing mode, 1051 the scope is either local to a region or fabric-wide. In either 1052 mode, communications between N_PORTs in the same gateway region 1053 use the N_PORT I/D. 1055 b) A 24-bit N_PORT alias. An address assigned by a gateway 1056 operating in address translation mode to identify a remotely 1057 attached N_PORT. Frame traffic is directed to a remotely 1058 attached N_PORT by means of the N_PORT alias. 1060 c) An N_PORT network address. A tuple consisting of the gateway IP 1061 address, TCP port number and N_PORT I/D. The N_PORT network 1062 address identifies the source and destination N_PORTs for Fibre 1063 Channel traffic on the IP network. 1065 To provide transparent communications between remote and local 1066 N_PORTs, a gateway in address translation mode maintains an 1067 association between the remote N_PORT alias and the remote device's 1068 N_PORT network address. To establish this association the iFCP 1069 gateway assigns and manages Fibre Channel N_PORT fabric addresses 1070 as described in the following paragraphs. 1072 In an iFCP fabric, the iFCP gateway performs the address assignment 1073 and frame routing functions of an FC switch element. Unlike an FC 1074 switch, however, an iFCP gateway must also direct frames to 1075 external devices attached to remote gateways on the IP network. 1077 In order to be transparent to FC devices, the gateway must deliver 1078 such frames using only the 24-bit destination address in the frame 1079 header. By exploiting its control of address allocation and access 1080 to frame traffic entering or leaving the gateway region, it is able 1081 to achieve the necessary transparency. 1083 N_PORT addresses within a gateway region may be allocated in one of 1084 two ways: 1086 iFCP Revision 8 January 2002 1088 a) Address Translation Mode � A mode of N_PORT address assignment 1089 in which the scope of an N_PORT address is unique to the gateway 1090 region. The address of a remote device is represented in that 1091 gateway region by its gateway assigned N_PORT alias. 1093 b) Address Transparent Mode � A mode of N_PORT address assignment 1094 in which the scope of an N_PORT address is unique across the set 1095 of gateway regions comprising a bounded iFCP fabric. 1097 In address transparent mode, gateways within a bounded fabric 1098 cooperate in the assignment of addresses to locally attached 1099 N_PORTs. Each gateway in control of a region is responsible for 1100 obtaining and distributing unique domain I/Ds from the address 1101 assignment authority as described in section 5.5.1.1. Consequently, 1102 within the scope of a bounded fabric, the address of each N_PORT is 1103 unique. For that reason, gateway-assigned aliases are not required 1104 to represent remote N_PORTs. 1106 All iFCP implementations MUST support operation in address 1107 translation mode. Implementation of address transparent mode is 1108 OPTIONAL but MUST be provided if bounded iFCP fabric configurations 1109 are to be supported. 1111 The mode of gateway operation is settable in an implementation- 1112 specific manner. The implementation MUST NOT allow the mode to be 1113 changed after the gateway begins processing fibre channel frame 1114 traffic. 1116 5.5.1 Operation in Address Transparent Mode 1118 The following considerations and requirements apply to this mode of 1119 operation: 1121 a) iFCP gateways in address transparent mode will not interoperate 1122 with iFCP gateways that are not in transparent mode. 1124 b) When interoperating with locally attached Fibre Channel switch 1125 elements, each iFCP gateway MUST assume control of DOMAIN_ID 1126 assignments in accordance with the appropriate Fibre Channel 1127 standard or vendor-specific protocol specification. As 1128 described in section 5.5.1.1, DOMAIN_ID values assigned to FC 1129 switches in attached fabrics must be issued by the iSNS server. 1131 c) When operating in address transparent Mode, no Fibre Channel 1132 address translation SHALL take place. 1134 The process for establishing the TCP/IP context associated with an 1135 N_PORT login session in this mode is similar to that specified for 1136 address translation mode (section 5.5.2). 1138 5.5.1.1 Transparent Mode Domain I/D Management 1139 iFCP Revision 8 January 2002 1141 As described above, each gateway and Fibre Channel switch in a 1142 bounded iFCP fabric MUST have a unique domain I/D. In a gateway 1143 region containing Fibre Channel switch elements, each element 1144 obtains a domain I/D by querying the principal switch as described 1145 in \* MERGEFORMAT [FC-SW2] -- in this case the iFCP gateway 1146 itself. The gateway in turn may obtain domain I/Ds on demand from 1147 the iSNS name server acting as the central address allocation 1148 authority . In effect, the iSNS server assumes the role of master 1149 switch for the bounded fabric. In that case, the iSNS database 1150 contains: 1152 a) The definition for one or more bounded iFCP fabrics, 1154 b) For each bounded fabric, a world-wide unique name identifying 1155 each gateway in the fabric. A gateway in address transparent 1156 mode MUST reside in one and only one bounded fabric. 1158 In its role as principle switch, an iFCP gateway in address 1159 transparent mode SHALL obtain domain I/Ds for use in the gateway 1160 region by issuing the appropriate iSNS query using its world-wide 1161 name. 1163 5.5.1.2 Incompatibility with Address Translation Mode 1165 iFCP gateways in address transparent mode SHALL NOT originate or 1166 accept frames that do not have the TRN bit set to one in the iFCP 1167 flags field of the encapsulation header (see section 6.4.1). The 1168 iFCP gateway SHALL immediately terminate all N_PORT login sessions 1169 with the iFCP gateway from which it receives such frames. 1171 5.5.2 Operation in Address Translation Mode 1173 This section describes the process for managing the assignment of 1174 addresses within a gateway region, including the modification of FC 1175 frame addresses embedded in the frame header for frames sent and 1176 received from remotely attached N_PORTs. 1178 As described above, the scope of N_PORT addresses in this mode is 1179 local to the gateway region. A principal switch within the gateway 1180 region, possibly the iFCP gateway itself, oversees the assignment 1181 of such addresses in accordance with the rules specified in [FC-FS] 1182 and [FC-FLA]. 1184 The assignment of N_PORT addresses to locally attached devices is 1185 controlled by the switch element to which the device is connected. 1187 When a remotely attached N_PORT is accessed, the gateway assigns a 1188 locally significant N_PORT alias. This alias is used in place of 1189 the N_PORT I/D assigned by the remote gateway. To perform address 1190 conversion and enable the appropriate routing, the gateway 1191 maintains a table mapping N_PORT aliases to the appropriate TCP/IP 1192 connection context and N_PORT ID of all remotely accessed N_PORTs. 1194 iFCP Revision 8 January 2002 1196 The means by which translation table entries are created and 1197 updated are described in section 5.5.3. 1199 5.5.3 Address Translation 1201 This section describes how address translation SHALL be performed 1202 by a gateway operating in address translation mode. For descriptive 1203 purposes, the gateway is assumed to maintain a table containing one 1204 entry for each remotely attached N_PORT as shown in Figure 11. 1206 +--------------------------------+ 1207 | Network Address of Remote | 1208 | Gateway | 1209 +--------------------------------+ 1210 | N_PORT I/D of Remote N_PORT | 1211 +--------------------------------+ 1212 | N_PORT Alias | 1213 +--------------------------------+ 1214 | N_PORT World-wide Unique Name | 1215 +--------------------------------+ 1216 Figure 11 -- Address Translation Table Entry for Remote N_PORT 1218 Each entry contains the following information: 1220 Network Address of Remote Gateway -- IP address and TCP port 1221 number of the gateway to which the remote device is attached. 1223 N_PORT I/D -- N_PORT address assigned to the remote device by 1224 the remote iFCP gateway. 1226 N_PORT Alias -- N_PORT address assigned to the remote device by 1227 the 'local' iFCP gateway. 1229 N_PORT World-wide Unique Name -- 64-bit N_PORT world wide name 1230 as specified in [FC-FS]. 1232 An iFCP gateway SHALL have one and only one entry for each remotely 1233 attached N_PORT it accesses. If an entry does not exist, one SHALL 1234 be built in response to one of the following transactions: 1236 a) A Fibre Channel Name Server request issued by a locally-attached 1237 N_PORTs as part of Fibre Channel device discovery (see section 1238 4.5) or, 1240 b) An N_PORT PLOGI request received from the remote Fibre Channel 1241 device (see section 8.3.1.7). 1243 An iFCP gateway SHALL convert each Fibre Channel Name Server 1244 request to an iSNS server query. Information returned in response 1245 to the query includes the IP address, TCP port number, N_PORT ID 1246 and N_PORT world wide unique name for each remote device included 1247 in the query response. After building the table entry containing 1249 iFCP Revision 8 January 2002 1251 this information for a specific N_PORT, the iFCP layer SHALL create 1252 and add the 24-bit N_PORT alias. This alias SHALL then be returned 1253 to the local N_PORT as the Fibre Channel address of the remotely 1254 attached device. 1256 If a PLOGI is received from a remotely attached device and no 1257 translation table entry exists for that device, an entry SHALL be 1258 created using the following information: 1260 a) The world-wide unique name of the N_PORT contained in the PLOGI 1261 payload, 1263 b) The IP address and TCP port number of the remote device obtained 1264 from the TCP connection context, 1266 c) The N_PORT I/D obtained from the S_ID field in the PLOGI frame 1267 header. 1269 The N_PORT alias SHALL then be assigned and used in address 1270 translation as specified in section 5.5.2. 1272 5.5.3.1.1 Updating an Address Translation 1274 An address translation may become stale as the result of any event 1275 that invalidates or triggers a change in the fabric-assigned N_PORT 1276 network address of the remote device, such as a fabric 1277 reconfiguration or the device's removal or replacement. 1279 A collateral effect of such an event is that a Fibre Channel device 1280 that has been added or whose N_PORT I/D has changed will have no 1281 N_PORT login sessions. Consequently, frames directed to an N_PORT 1282 as the result of a stale translation table entry will be rejected 1283 or discarded by the receiving Fibre Channel device. 1285 Once the originating N_PORT learns of the reconfiguration, usually 1286 through the name serverstate change notification mechanism, the 1287 normal name server lookup and PLOGI mechanisms needed to 1288 reestablish the N_PORT login session will automatically purge such 1289 stale translations from the gateway. 1291 5.5.3.2 Frame Address Translation 1293 For outbound frames, the gateway-resident address translation SHALL 1294 be referenced to map the Destination N_PORT alias to the TCP 1295 connection context and N_PORT ID assigned by the remote gateway. 1296 The translation process for outbound frames is shown below. 1298 iFCP Revision 8 January 2002 1300 Raw Fibre Channel Frame 1301 +--------+-----------------------------------+ +--------------+ 1302 | | Destination N_PORT Alias |--->| Lookup TCP | 1303 +--------+-----------------------------------+ | connection | 1304 | | Source N_PORT ID | | context | 1305 +--------------------------------------------+ | and N_PORT ID| 1306 | | +------+-------+ 1307 | Control information, | | TCP 1308 | Payload and FC CRC | | conn 1309 | | | context 1310 +--------------------------------------------+ | & 1311 | N_PORT 1312 | ID 1313 | 1314 After Address Translation and Encapsulation | 1315 +--------------------------------------------+ | 1316 | FC Encapsulation Header | | 1317 +--------------------------------------------+ | 1318 | SOF Delimiter Word | | 1319 +============================================+ | 1320 | | Destination N_PORT ID |<----------+ 1321 +--------+-----------------------------------+ 1322 | | Source N_PORT ID | 1323 +--------+-----------------------------------+ 1324 | | 1325 | Control information, Payload | 1326 | and FC CRC | 1327 +============================================+ 1328 | EOF Delimiter Word | 1329 +--------------------------------------------+ 1330 Figure 13 -- Outbound Frame Address Translation 1332 For inbound frames, a translation SHALL be performed to regenerate 1333 the N_PORT alias from the TCP connection context and N_PORT ID 1334 contained in Source N_PORT I/D field of theencapsulated FC frame. 1335 The translation process for inbound frames is shown below. 1337 iFCP Revision 8 January 2002 1339 Network Format of Inbound Frame 1340 +--------------------------------------------+ TCP 1341 | FC Encapsulation Header | Connection 1342 +--------------------------------------------+ Context 1343 | SOF Delimiter Word | | 1344 +============================================+ V 1345 | | Destination N_PORT ID | +---+----+ 1346 +--------+-----------------------------------+ | Lookup | 1347 | | Source N_PORT ID |---->| Source | 1348 +--------+-----------------------------------+ | N_PORT | 1349 | | | Alias | 1350 | Control information, Payload | +----+---+ 1351 | and FC CRC | | Source 1352 +============================================+ | N_PORT 1353 | EOF Delimiter Word | | Alias 1354 +--------------------------------------------+ | 1355 | 1356 | 1357 Frame after Address Translation and De-encapsulation | 1358 +--------+-----------------------------------+ | 1359 | | Destination N_PORT ID | | 1360 +--------+-----------------------------------+ | 1361 | | Source N_PORT Alias |<---------+ 1362 +--------+-----------------------------------+ 1363 | | 1364 | Control information, Payload, | 1365 | and FC CRC | 1366 +--------------------------------------------+ 1367 Figure 14 -- Inbound Frame Address Translation 1369 In both cases, the gateway MUST recalculate the FC CRC after 1370 altering the frame contents. 1372 5.5.3.3 Incompatibility with Address Transparent Mode 1374 iFCP gateways in address translation mode SHALL NOT originate or 1375 accept frames that have the TRN bit set to one in the iFCP flags 1376 field of the encapsulation header. The iFCP gateway SHALL 1377 immediately abort all iFCP sessions with the iFCP gateway from 1378 which it receives such frames as described in section 6.2.3.2. 1380 6. iFCP Protocol 1382 6.1 Overview 1384 6.1.1 iFCP Transport Services 1386 The main function of the iFCP protocol layer is to transport Fibre 1387 Channel frame images between locally and remotely attached N_PORTs. 1389 When transporting frames to a remote N_PORT, the iFCP layer 1390 encapsulates and routes the Fibre Channel frames comprising each 1392 iFCP Revision 8 January 2002 1394 Fibre Channel Information Unit via a predetermined TCP connection 1395 for transport across the IP network. 1397 When receiving Fibre Channel frame images from the IP network, the 1398 iFCP layer de-encapsulates and delivers each frame to the 1399 appropriate N_PORT. 1401 The iFCP layer processes the following types of traffic: 1403 a) FC-4 frame images associated with a Fibre Channel application 1404 protocol. 1406 b) FC-2 frames comprising Fibre Channel link service requests and 1407 responses 1409 c) Fibre Channel broadcast frames 1411 d) iFCP control messages required to setup, manage or terminate an 1412 iFCP session. 1414 For FC-4 N_PORT traffic and most FC-2 messages the iFCP layer never 1415 interprets the contents of the frame payload. 1417 iFCP does interpret and process iFCP control messages and certain 1418 link service messages as described in section 6.1.2 1420 6.1.2 iFCP Support for Link Services 1422 iFCP must intervene in the processing of those Fibre Channel link 1423 service messages which contain N_PORT addresses in the message 1424 payload or require other special handling, such as an N_PORT login 1425 request (PLOGI). 1427 In the former case, an iFCP gateway operating in address 1428 translation mode MUSTsupplement the payload with additional 1429 information that enables the receiving gateway to convert such 1430 embedded N_PORT addresses to its frame of reference. 1432 For out-bound Fibre Channel frames comprising such a link service, 1433 the iFCP layer creates the supplemental information based on frame 1434 content, modifies the frame payload, then transmits the resulting 1435 Fibre Channel frame with supplemental data through the appropriate 1436 TCP connection. 1438 For incoming iFCP frames containing supplemented Fibre Channel link 1439 service frames, iFCP interprets the frame, including any 1440 supplemental information, modifies the frame content, and forwards 1441 the resulting frame to the destination N_PORT for further 1442 processing. 1444 Section 8.1 describes the processing of these link service messages 1445 in detail. 1447 iFCP Revision 8 January 2002 1449 6.2 TCP Stream Transport of iFCP Frames 1451 6.2.1 iFCP Session Model 1453 An iFCP session consists of the pair of N_PORTs comprising the 1454 session endpoints joined by a single TCP/IP connection. 1456 An N_PORT is identified by its network address consisting of: 1458 a) The N_PORT I/D assigned by the gateway to which the N_PORT is 1459 locally attached and 1461 b) The iFCP Portal address, consisting of its IP address and TCP 1462 port number. 1464 Since only one iFCP session may exist between a pair of N_PORTs, 1465 the iFCP session is uniquely identified by the network addresses of 1466 the session end points. 1468 TCP connections that may be used for iFCP sessions between pairs of 1469 iFCP portals are either "bound" or "unbound". An unbound 1470 connection is a TCP connection that is not actively supporting an 1471 iFCP session. A gateway implementation MAY establish a pool of 1472 unbound connections to reduce the session setup time. Such pre- 1473 existing TCP connections between iFCP Portals remain unbound and 1474 uncommitted until allocated to an iFCP session through a CBIND 1475 message (see section 7.1). 1477 When the iFCP layer detects a Port Login (PLOGI) message creating 1478 an iFCP session between a pair of N_PORTs, it may select an 1479 existing unbound TCP connection or establish a new TCP connection, 1480 and send the CBIND message down that TCP connection. This 1481 allocates the TCP connection to that PLOGI login session. 1483 6.2.2 iFCP Session Management 1485 This section describes the protocols for establishing and 1486 terminating an N_PORT login session. 1488 6.2.2.1 Creating an iFCP Session 1490 An iFCP session may be in one of the following states: 1492 a) OPEN -- The session state in which Fibre Channel frame images 1493 may be sent and received. 1495 b) OPEN PENDING -- The session state after a gateway has issued a 1496 CBIND request but no response has yet been received. No Fibre 1497 Channel frames may be sent. 1499 iFCP Revision 8 January 2002 1501 The gateway SHALL initiate the creation of an iFCP session in 1502 response to a PLOGI ELS directed to a remote N_PORT from a locally 1503 attached N_PORT as described in the following steps. 1505 a) If no iFCP session exists, allocate a TCP connection to the 1506 gateway to which the remote N_PORT is locally attached. An 1507 implementation may use an existing connection in the Unbound 1508 state or a new connection may be created and placed in the 1509 Unbound state. The network address of the remote gateway is 1510 obtained from the address translation table created as described 1511 in section 5.5.3 1513 b) If a connection cannot be allocated or created due to limited 1514 resources, the gateway SHALL terminate the PLOGI with an LS_RJT 1515 response. The Reason Code field in the LS_RJT message shall be 1516 set to 0x09 (Unable to Perform Command Request) and the Reason 1517 Explanation SHALL be set to 0x29 (Insufficient Resources to 1518 Support Login). 1520 c) If an iFCP session in the OPEN state already exists to the 1521 remote N_PORT, the gateway SHALL forward the PLOGI ELS using the 1522 existing session. 1524 d) If the iFCP session does not exist, the gateway SHALL issue a 1525 CBIND session control message (see section 7.1) and place the 1526 session in the OPEN PENDING state. 1528 e) If a CBIND response is returned with one of the following 1529 statuses, the PLOGI shall be terminated with an LS_RJT message. 1530 Depending on the CBIND failure status, the Reason Code and 1531 Reason Explanation SHALL be set to the following values 1532 specified in [FC-FS]. 1534 iFCP Revision 8 January 2002 1536 CBIND Failure LS_RJT Reason LS_RJT Reason Code 1537 Status Code Explanation 1538 ------------- ------------- ------------------ 1540 Unspecified Unable to Perform No additional 1541 Reason (16) Command Request explanation (0x00) 1542 (0x09) 1544 No Such Device Unable to Perform Invalid N_PORT Name 1545 (17) Command Request (0x0D). 1546 (0x09) 1548 Lack of Unable to Perform Insufficient 1549 Resources (19) Command Request Resources to Support 1550 (0x09). Login (0x29). 1552 Incompatible Unable to Perform No additional 1553 address Command Request Explanation (0x00) 1554 translation mode (0x09) 1555 (20) 1557 Incorrect iFCP Unable to Perform No additional 1558 protocol version Command Request explanation (0x00) 1559 number (21) (0x09) 1561 f) A CBIND response with a CBIND STATUS of "N_PORT session already 1562 exists" indicates that the remote gateway has concurrently 1563 initiated a CBIND request to create an iFCP session between the 1564 same pair of N_PORTs. The receiving gateway SHALL terminate this 1565 attempt, return the connection to the Unbound state and prepare 1566 to respond to an incoming CBIND request as described below. 1568 The gateway receiving a CBIND request SHALL respond as follows: 1570 a) If the receiver has a duplicate iFCP session in the OPEN PENDING 1571 state, then the receiving gateway SHALL compare the Source Port 1572 Name in the incoming CBIND payload with the Destination Port 1573 Name. 1575 b) If the Source Port Name is greater, the receiver SHALL issue a 1576 CBIND response of "Success" and SHALL place the session in the 1577 OPEN state. 1579 c) If the Source Port Name is less, the receiver shall issue a 1580 CBIND RESPONSE of Failed - N_PORT session already exists. The 1581 state of the receiver-initiated iFCP session SHALL BE unchanged. 1583 d) If there is no duplicate iFCP session, the receiving gateway 1584 SHALL issue a CBIND response. If a status of Success is 1585 returned, the receiving gateway SHALL create the iFCP session 1586 and place it in the OPEN state. 1588 iFCP Revision 8 January 2002 1590 6.2.2.2 Monitoring iFCP Connectivity 1592 During extended periods of inactivity, an iFCP session may be 1593 terminated due to a hardware failure within the gateway or through 1594 loss of TCP/IP connectivity. The latter may occur when the session 1595 traverses a stateful intermediate device, such as a NAPT box or 1596 firewall, that detects and purges connections it believes to be 1597 idle. 1599 To test session liveness, expedite the detection of connectivity 1600 failures, and avoid spontaneous connection termination, an iFCP 1601 gateway may maintain a low level of session activity and monitor 1602 the session by requesting that the remote gateway periodically 1603 transmit the LTEST message described in section 7.3. All iFCP 1604 gateways SHALL support liveness testing as described in this 1605 specification. 1607 A gateway requests the LTEST heartbeat by specifying a non-zero 1608 value for the LIVENESS TEST INTERVAL in the CBIND request or 1609 response message as described in section 7.1. If both gateways 1610 wish to monitor liveness, each must set the LIVENESS TEST INTERVAL 1611 in the CBIND request or response. 1613 Upon receiving such a request, the gateway providing the 1614 connectivity probe SHALL transmit LTEST messages at the specified 1615 interval. The first message SHALL be sent as soon as the iFCP 1616 session enters the OPEN state. LTEST messages SHALL NOT be sent 1617 when the iFCP session is not in the OPEN state. 1619 An iFCP session SHALL be aborted as described in section 6.2.3.2 1620 if: 1622 a) The contents of the LTEST message are incorrect 1624 b) An LTEST message is not received within twice the specified 1625 interval or the iFCP session has been quiescent for longer than 1626 twice the specified interval. 1628 The gateway to receive the LTEST message SHALL measure the 1629 interval for the first expected LTEST message from when the 1630 session is placed in the OPEN state. Thereafter, the interval 1631 SHALL be measured relative to the last LTEST message received. 1633 To maximize liveness test coverage, LTEST messages SHOULD flow 1634 through all the gateway components used to enter and retrieve Fibre 1635 Channel frames from the IP network. 1637 In addition to monitoring a session, information in the LTEST 1638 message encapsulation header may also be used to compute an 1639 estimate of network propagation delay as described in section 1640 9.2.1. The propagation delay limit SHALL NOT be enforced however. 1642 iFCP Revision 8 January 2002 1644 6.2.2.3 Use of TCP Features and Settings 1646 This section describes ground rules for the use of TCP features in 1647 an iFCP session. The core TCP protocol is defined in [RFC793]. 1648 TCP implementation requirements and guidelines are specified in 1649 [RFC1122]. 1651 +-----------+------------+--------------+------------+------------+ 1652 | Feature | Applicable | RFC | Peer-wise | Requirement| 1653 | | RFCs | Status | agreement | Level | 1654 | | | | required? | | 1655 +===========+============+==============+============+============+ 1656 | Keep Alive| [RFC1122] | None | No | Should not | 1657 | |(discussion)| | | use | 1658 +-----------+------------+--------------+------------+------------+ 1659 | Tiny | [RFC896] | Standard | No | Should not | 1660 | Segment | | | | use | 1661 | Avoidance | | | | | 1662 | (Nagle) | | | | | 1663 +-----------+------------+--------------+------------+------------+ 1664 | Window | [RFC1323] | Proposed | No | Should use | 1665 | Scale | | Standard | | | 1666 +-----------+------------+--------------+------------+------------+ 1667 | Wrapped | [RFC1323] | Proposed | No | Should use | 1668 | Sequence | | Standard | | | 1669 | Protection| | | | | 1670 | (PAWS) | | | | | 1671 +-----------+------------+--------------+------------+------------+ 1672 Table 1 -- Usage of Optional TCP Features 1674 The following sections describe these options in greater detail. 1676 6.2.2.3.1 Keep Alive 1678 Keep Alive speeds the detection and cleanup of dysfunctional TCP 1679 connections by sending traffic when a connection would otherwise be 1680 idle. The issues are discussed in [RFC1122]. 1682 In order to test the device more comprehensively, Fibre Channel 1683 applications, such as storage, may implement an equivalent keep 1684 alive function at the FC4 level. For that reason and the 1685 considerations described in [RFC1122], keep alive at the transport 1686 layer should not be implemented. 1688 6.2.2.3.2 'Tiny' Segment Avoidance (Nagle) 1690 The Nagle algorithm described in [RFC896] is designed to avoid the 1691 overhead of small segments by delaying transmission in order to 1692 agglomerate transfer requests into a large segment. In iFCP, such 1693 small transfers often contain I/O requests. Hence, the 1694 transmission delay of the Nagle algorithm may decrease I/O 1695 throughput. The Nagle algorithm should therefore not be used. 1697 iFCP Revision 8 January 2002 1699 6.2.2.3.3 Window Scale 1701 Window scaling, as specified in [RFC1323], allows full utilization 1702 of links with large bandwidth - delay products and should be 1703 supported by an iFCP implementation. 1705 6.2.2.3.4 Wrapped Sequence Protection (PAWS) 1707 TCP segments are identified with 32-bit sequence numbers. In 1708 networks with large bandwidth - delay products, it is therefore 1709 possible for more than one TCP segment with the same sequence 1710 number to be in flight. In iFCP, receipt of such a sequence out of 1711 order may cause out-of-order frame delivery or data corruption. 1712 Consequently, this feature SHOULD be supported as described in 1713 [RFC1323]. 1715 6.2.3 Terminating an N_PORT Login Session 1717 An N_PORT login session SHALL be terminated or aborted in response 1718 to one of the following events: 1720 a) An LS_RJT response is returned to the gateway that issued the 1721 PLOGI ELS. The gateway SHALL forward the LS_RJT to the local 1722 N_PORT and complete the session as described in section 1723 6.2.3.1. 1725 b) An ACC received from a remote device in response to a LOGO. The 1726 gateway SHALL forward the ACC to the local N_PORT and complete 1727 the session as described in section 6.2.3.1. 1729 c) For an FC frame received from the IP network, a gateway detects 1730 a CRC error in the encapsulation header. The gateway shall 1731 abort the session as described in section 6.2.3.2. 1733 d) The TCP connection associated with the login session fails for 1734 any reason. The gateway detecting the failed connection shall 1735 abort the session as described in section 6.2.3.2. 1737 The disposition of the associated TCP connection is described in 1738 sections 6.2.3.1 and 6.2.3.2 1740 6.2.3.1 N_PORT Login Session Completion 1742 An N_PORT login session is completed in response to a rejected 1743 PLOGI request as described in section 6.2.3 or a successful LOGO 1744 ELS. 1746 The gateway receiving one of the above responses shall issue an 1747 Unbind session control ELS as described in section 7.2. 1749 iFCP Revision 8 January 2002 1751 In response to the Unbind message, either gateway may choose to 1752 close the TCP connection or return it to a pool of unbound 1753 connections. 1755 6.2.3.2 Aborting an N_PORT Login Session 1757 An N_PORT login session SHALL be aborted if the TCP connection is 1758 spontaneously terminated or whenever one of the following occurs: 1760 a) An encapsulation error is detected as described in section 1761 6.4.3. 1763 b) The gateway receives an encapsulated frame from a gateway 1764 operating in an incompatible address translation mode as 1765 specified in section 5.5.3.3 or 5.5.1.2. 1767 In any event, the TCP connection SHOULD be terminated with a 1768 connection reset (RST). If the local N_PORT has logged in to the 1769 remote N_PORT, the gateway SHALL send a LOGO to the local N_PORT. 1771 6.3 IANA Considerations 1773 The IANA-assigned port for iFCP traffic is port number 3420. 1775 An iFCP Portal may initiate a connection using any TCP port number 1776 consistent with its implementation of the TCP/IP stack, provided 1777 each port number is unique. To prevent the receipt of stale data 1778 associated with a previous connection using a given port number, 1779 the provisions of [RFC1323], Appendix B SHOULD be observed. 1781 6.4 Encapsulation of Fibre Channel Frames 1783 This section describes the iFCP encapsulation of Fibre Channel 1784 frames. The encapsulation is based on the common encapsulation 1785 format defined in [ENCAP]. 1787 The format of an encapsulated frame is shown below: 1789 +--------------------+ 1790 | Header | 1791 +--------------------+-----+ 1792 | SOF | f | 1793 +--------------------+ F r | 1794 | FC frame content | C a | 1795 +--------------------+ m | 1796 | EOF | e | 1797 +--------------------+-----+ 1798 Figure 15 -- Encapsulation Format 1800 The encapsulation consists of a 7-word header, an SOF delimiter 1801 word, the FC frame (including the Fibre Channel CRC), and an EOF 1802 delimiter word. The header and delimiter formats are described in 1804 iFCP Revision 8 January 2002 1806 the following sections. When operating in Address Translation mode, 1807 (see section 5.5.2) the iFCP gateway must recalculate the Fibre 1808 Channel CRC. 1810 6.4.1 Encapsulation Header Format 1812 W|------------------------------Bit------------------------------| 1813 o| | 1814 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1815 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| 1816 +---------------+---------------+---------------+---------------+ 1817 0| Protocol# | Version | -Protocol# | -Version | 1818 +---------------+---------------+---------------+---------------+ 1819 1| Reserved (must be zero) | 1820 +---------------+---------------+---------------+---------------+ 1821 2| LS_COMMAND | iFCP Flags | SOF | EOF | 1822 +-----------+---+---------------+-----------+---+---------------+ 1823 3| Flags | Frame Length | -Flags | -Frame Length | 1824 +-----------+-------------------+-----------+-------------------+ 1825 4| Time Stamp [integer] | 1826 +---------------------------------------------------------------+ 1827 5| Time Stamp [fraction] | 1828 +---------------------------------------------------------------+ 1829 6| CRC | 1830 +---------------------------------------------------------------+ 1832 Common Encapsulation Fields: 1834 iFCP Revision 8 January 2002 1836 Protocol# IANA-assigned protocol number 1837 identifying the protocol using the 1838 encapsulation. For iFCP the value is 1839 (/TBD/). 1841 Version Encapsulation version 1843 -Protocol# Ones complement of the protocol# 1845 -Version Ones complement of the version 1847 Flags Encapsulation flags (see 6.4.1.1) 1849 Frame Length Contains the length of the entire FC 1850 Encapsulated frame including the FC 1851 Encapsulation Header and the FC frame 1852 (including SOF and EOF words) in units 1853 of 32-bit words. 1855 -Flags Ones-complement of the Flags field. 1857 -Frame Length Ones-complement of the Frame Length 1858 field. 1860 Time Stamp [integer] Integer component of the frame time 1861 stamp in SNTP format [RFC2030]. 1863 Time Stamp Fractional component of the time stamp 1864 [fraction] in SNTP format [RFC2030]. 1866 CRC Header CRC. MUST be valid for iFCP. 1868 The time stamp fields are used to enforce the limit on the 1869 lifetime of a Fibre Channel frame as described in section 1870 9.2.1. 1872 iFCP-specific fields: 1874 iFCP Revision 8 January 2002 1876 LS_COMMAND For a special link service ACC 1877 response to be processed by iFCP, the 1878 LS_COMMAND field SHALL contain bits 31 1879 through 24 of the LS_COMMAND to which 1880 the ACC applies. Otherwise the 1881 LS_COMMAND field shall be set to zero. 1883 iFCP Flags iFCP-specific flags (see below) 1885 SOF Copy of the SOF delimiter encoding 1886 (see section 6.4.2) 1888 EOF Copy of the EOF delimiter encoding 1889 (see section 6.4.2) 1891 The iFCP flags word has the following format: 1893 |------------------------Bit----------------------------| 1894 | | 1895 | 23 22 21 20 19 18 17 16 | 1896 +------+------+------+------+------+------+------+------+ 1897 | Reserved | SES | TRN | SPC | 1898 +------+------+------+------+------+------+------+------+ 1899 Figure 16 -- iFCP Flags Word 1901 iFCP Flags: 1903 SES 1 = Session control frame (TRN and SPC MUST be 1904 0) 1906 TRN 1 = Address transparent mode enabled 1908 0 = Address translation mode enabled 1910 SPC 1 = Frame is part of an ELS requiring special 1911 processing by iFCP prior to forwarding to 1912 the destination N_PORT. 1914 6.4.1.1 Common Encapsulation Flags 1916 The iFCP usage of the common encapsulation flags is shown below: 1918 iFCP Revision 8 January 2002 1920 |------------------------Bit--------------------------| 1921 | | 1922 | 31 30 29 28 27 26 | 1923 +--------------------------------------------+--------+ 1924 | Reserved | CRCV | 1925 +--------------------------------------------+--------+ 1927 For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 1929 6.4.2 SOF and EOF Delimiter Fields 1931 The format of the delimiter fields is shown below. 1933 W|------------------------------Bit------------------------------| 1934 o| | 1935 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1936 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| 1937 +---------------+---------------+-------------------------------+ 1938 0| SOF | SOF | -SOF | -SOF | 1939 +---------------+---------------+-------------------------------+ 1940 1| | 1941 +----- FC frame content -----+ 1942 | | 1943 +---------------+---------------+-------------------------------+ 1944 n| EOF | EOF | -EOF | -EOF | 1945 +---------------+---------------+-------------------------------+ 1946 Figure 17 -- FC Frame Encapsulation Format 1948 SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the 1949 following subset of the SOF fields described in [ENCAP]. 1951 +-------+----------+ 1952 | FC | | 1953 | SOF | SOF Code | 1954 +-------+----------+ 1955 | SOFi2 | 0x2D | 1956 | SOFn2 | 0x35 | 1957 | SOFi3 | 0x2E | 1958 | SOFn3 | 0x36 | 1959 +-------+----------+ 1960 Table 2-- Translation of FC SOF Values to SOF Field Contents 1962 -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the 1963 ones complement of the value in the SOF fields. 1965 EOF (bits 31-24 and 23-16 in word n): iFCP uses the following 1966 subset of EOF fields specified in [ENCAP]. 1968 iFCP Revision 8 January 2002 1970 +-------+----------+ 1971 | FC | | 1972 | EOF | EOF Code | 1973 +-------+----------+ 1974 | EOFn | 0x41 | 1975 | EOFt | 0x42 | 1976 +-------+----------+ 1977 Table 3 -- Translation of FC EOF Values to EOF Field Contents 1979 -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain the 1980 one's complement of the value in the EOF fields. 1982 iFCP implementations SHALL place a copy of the SOF and EOF 1983 delimiter codes in the appropriate header fields. 1985 6.4.3 Frame Encapsulation 1987 A Fibre Channel Frame to be encapsulated MUST first be validated as 1988 described in [FC-FS]. Any frames received from a locally attached 1989 Fibre Channel device that do not pass the validity tests in [FC-FS] 1990 SHALL be discarded by the gateway. 1992 Frames types submitted for encapsulation and forwarding on the IP 1993 network SHALL have one of the SOF delimiters in Table 2 and an EOF 1994 delimiter from Table 3. Other valid frame types MUST be processed 1995 internally by the gateway as specified in the appropriate Fibre 1996 Channel specification. 1998 Prior to submitting a frame for encapsulation, a gateway in address 1999 translation mode SHALL replace the D_ID address, and, if processing 2000 a special ELS requiring the inclusion of supplemental data, SHALL 2001 format the frame payload and add the supplemental information as 2002 specified in section 8.1. The gateway SHALL then calculate a new 2003 FC CRC on the reformatted frame. 2005 A gateway in address transparent mode MAY encapsulate and transmit 2006 the frame image without recalculating the FC CRC. 2008 The frame originator MUST then create and fill in the header and 2009 the SOF and EOF delimiter words as specified above. 2011 6.4.4 Frame De-encapsulation 2013 The receiving gateway SHALL perform de-encapsulation as follows: 2015 Upon receiving the encapsulated frame, the gateway SHALL check the 2016 header CRC. If the header CRC is invalid, the gateway SHALL 2017 terminate the N_PORT login session as described in section 6.2.3.2. 2019 After validating the header CRC, the receiving gateway SHALL verify 2020 the frame propagation delay as described in section 9.2.1. If the 2021 propagation delay is too long, the frame SHALL be discarded. 2023 iFCP Revision 8 January 2002 2025 Otherwise, the gateway SHALL check the SOF and EOF in the 2026 encapsulation header. A frame SHALL be discarded if it has an SOF 2027 code that is not in Table 2 or an EOF code that is not in Table 3. 2029 The gateway shall then de-encapsulate the frame. If operating in 2030 address translation mode, the gateway SHALL: 2032 a) Check the FC CRC and discard the frame if the CRC is invalid. 2034 b) Replace the S_ID with the N_PORT alias of the frame originator 2036 c) If processing an augmented ELS, replace the ELS frame with a 2037 copy whose payload has been modified as specified in section 2038 8.1. 2040 The de-encapsulated frame SHALL then be delivered to the N_PORT 2041 specified in the D_ID field. If the frame contents have been 2042 modified by the receiving gateway, a new FC CRC SHALL be 2043 calculated. 2045 7. TCP Session Control Messages 2047 TCP session control messages are used to create and manage an iFCP 2048 session as described in section 6.2.2. They are passed between peer 2049 iFCP Portals and are only processed within the iFCP layer. 2051 The message format is based on the Fibre Channel extended link 2052 service message template shown below. 2054 iFCP Revision 8 January 2002 2056 Word 2057 3124 23<---------------Bits------------------------->0 2058 +------------+------------------------------------------------+ 2059 0| R_CTL | D_ID [0x00 00 00] | 2060 |[Req = 0x22]| [Destination of extended link Service request] | 2061 |[Rep = 0x23]| | 2062 +------------+------------------------------------------------+ 2063 1| CS_CTL | S_ID [0x00 00 00] | 2064 | [0x0] | [Source of extended link service request] | 2065 +------------+------------------------------------------------+ 2066 2|TYPE [0x1] | F_CTL [0] | 2067 +------------+------------------+-----------------------------+ 2068 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | 2069 |[0x0] | | | 2070 +------------+------------------+-----------------------------+ 2071 4| OX_ID [0x0000] | RX_ID_[0x0000] | 2072 +-------------------------------+-----------------------------+ 2073 5| Parameter | 2074 | [ 00 00 00 00 ] | 2075 +-------------------------------------------------------------+ 2076 6| LS_COMMAND | 2077 | [Session Control Command Code] | 2078 +-------------------------------------------------------------+ 2079 7| | 2080 .| Additional Session Control Parameters | 2081 .| ( if any ) | 2082 n| | 2083 +=============================================================+ 2084 n| Fibre Channel CRC | 2085 +| | 2086 1+=============================================================+ 2087 Figure 18 -- Format of Session Control Message 2089 The LS_COMMAND value for the response remains the same as that used 2090 for the request. 2092 The session control ELS frame is terminated with a Fibre Channel 2093 CRC. The frame SHALL be encapsulated and de-encapsulated according 2094 to the rules specified in section 6.4. 2096 The encapsulation header for the link Service frame carrying a TCP 2097 ELS message SHALL be set as follows: 2099 Encapsulation Header Fields: 2101 iFCP Revision 8 January 2002 2103 LS_COMMAND 0 2105 iFCP Flags SES = 1 2107 TRN = 0 2109 INT = 0 2111 SOF code SOFi3 encoding (0x2E) 2113 EOF code EOFt encoding (0x42) 2115 The encapsulation time stamp words SHALL be set as described for 2116 each message type. 2118 The SOF and EOF delimiter words SHALL be set based on the SOF and 2119 EOF codes specified above. 2121 The following lists the session control messages and their 2122 corresponding LS_COMMAND values. 2124 Request LS_COMMAND Short Name iFCP Support 2125 ------- ---------- ---------- ----------- 2126 Connection Bind 0xE0 CBIND REQUIRED 2127 Unbind Connection 0xE4 UNBIND REQUIRED 2128 Test Connection Liveness 0xE5 LTEST Required 2130 7.1 Connection Bind (CBIND) 2132 As described in section 6.2.2.1, the CBIND message and response are 2133 used to bind an N_PORT login session to a specific TCP connection 2134 and establish an iFCP session. In the CBIND request message, the 2135 source and destination N_Ports are identified by the N_PORT network 2136 address (iFCP portal address and N_PORT ID). The time stamp words 2137 in the encapsulation header shall be set to zero in the request and 2138 response message frames. 2140 The following shows the format of the CBIND request. 2142 iFCP Revision 8 January 2002 2144 +------+------------+------------+-----------+----------+ 2145 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2146 +------+------------+------------+-----------+----------+ 2147 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2148 +------+------------+------------+-----------+----------+ 2149 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2150 | | (Seconds) | | | 2151 +------+-------------------------+-----------+----------+ 2152 | 2 | USER INFO | 2153 +------+------------+------------+-----------+----------+ 2154 | 3 | | 2155 +------+ SOURCE N_PORT NAME | 2156 | 4 | | 2157 +------+------------------------------------------------+ 2158 | 5 | | 2159 +------+ DESTINATION N_PORT NAME | 2160 | 6 | | 2161 +------+------------------------------------------------+ 2163 Addr Mode: The addressing mode of the originating 2164 gateway. 0 = Address Translation mode, 1 = 2165 Address Transparent mode. 2167 iFCP Ver: iFCP version number. SHALL be set to 1. 2169 LIVENESS TEST If non-zero, requests that the receiving 2170 INTERVAL: gateway transmit an LTEST message at the 2171 specified interval in seconds. 2173 USER INFO: Contains any data desired by the requestor. 2174 This information MUST be echoed by the 2175 recipient in the CBIND response message. 2177 SOURCE N_PORT NAME: The World Wide Port Name (WWPN) of the 2178 N_PORT locally attached to the gateway 2179 originating the CBIND request. 2181 DESTINATION N_PORT The World Wide Port Name (WWPN) of the 2182 NAME: N_PORT locally attached to the gateway 2183 receiving the CBIND request. 2185 The following shows the format of the CBIND response. 2187 iFCP Revision 8 January 2002 2189 +------+------------+------------+-----------+----------+ 2190 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2191 +------+------------+------------+-----------+----------+ 2192 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2193 +------+------------+------------+-----------+----------+ 2194 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2195 | | (Seconds) | | | 2196 +------+-------------------------+-----------+----------+ 2197 | 2 | USER INFO | 2198 +------+------------+------------+-----------+----------+ 2199 | 3 | | 2200 +------+ SOURCE N_PORT NAME | 2201 | 4 | | 2202 +------+------------------------------------------------+ 2203 | 5 | | 2204 +------+ DESTINATION N_PORT NAME | 2205 | 6 | | 2206 +------+-------------------------+----------------------+ 2207 | 7 | Reserved | CBIND Status | 2208 +------+-------------------------+----------------------+ 2209 | 8 | Reserved | CONNECTION HANDLE | 2210 +------+-------------------------+----------------------+ 2211 Total Length = 32 2213 iFCP Revision 8 January 2002 2215 Addr Mode: The address translation mode of the 2216 responding gateway. 0 = Address 2217 Translation mode, 1 = Address Transparent 2218 mode. 2220 iFCP Ver: iFCP version number. Shall be set to 1. 2222 LIVENESS TEST If non-zero, requests that the gateway 2223 INTERVAL: receiving the CBIND RESPONSE transmit an 2224 LTEST message at the specified interval in 2225 seconds. 2227 USER INFO: Echoes the value received in the USER INFO 2228 field of the CBIND request message. 2230 SOURCE PORT NAME: Contains the World Wide Port Name (WWPN) of 2231 the N_PORT locally attached to the gateway 2232 issuing the CBIND request. 2234 DESTINATION PORT Contains the World Wide Port Name (WWPN) of 2235 NAME: the N_PORT locally attached to the gateway 2236 issuing the CBIND response. 2238 CBIND STATUS: Indicates success or failure of the CBIND 2239 request. CBIND values are shown below. 2241 CONNECTION HANDLE: Contains a value assigned by the gateway to 2242 identify the connection. The connection 2243 handle is required when issuing the UNBIND 2244 request. 2246 CBIND Status Description 2247 ------------ ----------- 2249 0 Successful � No other status 2250 1 � 15 Reserved 2251 16 Failed � Unspecified Reason 2252 17 Failed � No such device 2253 18 Failed � N_PORT session already exists 2254 19 Failed � Lack of resources 2255 20 Failed - Incompatible address translation mode 2256 21 Failed - Incorrect protocol version number 2257 Others Reserved 2259 7.2 Unbind Connection (UNBIND) 2261 UNBIND is used to release a bound TCP connection and return it to 2262 the pool of unbound TCP connections. This message is transmitted 2263 in the connection that is to be unbound. The time stamp words in 2265 iFCP Revision 8 January 2002 2267 the encapsulation header shall be set to zero in the request and 2268 response message frames. 2270 The following is the format of the UNBIND request message. 2272 +------+------------+------------+-----------+----------+ 2273 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2274 +------+------------+------------+-----------+----------+ 2275 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2276 +------+------------+------------+-----------+----------+ 2277 | 1 | USER INFO | 2278 +------+------------+------------+-----------+----------+ 2279 | 2 | Reserved | CONNECTION HANDLE | 2280 +------+------------+------------+----------------------+ 2281 | 3 | Reserved | 2282 +------+------------+------------+-----------+----------+ 2283 | 4 | Reserved | 2284 +------+------------+------------+-----------+----------+ 2286 USER INFO Contains any data desired by the requestor. 2287 This information MUST be echoed by the 2288 recipient in the UNBIND response message. 2290 CONNECTION HANDLE: Contains the gateway-assigned value from 2291 the CBIND request. 2293 The following shows the format of the UNBIND response message. 2295 +------+------------+------------+-----------+----------+ 2296 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2297 +------+------------+------------+-----------+----------+ 2298 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2299 +------+------------+------------+-----------+----------+ 2300 | 1 | USER INFO | 2301 +------+------------+------------+-----------+----------+ 2302 | 2 | Reserved | CONNECTION HANDLE | 2303 +------+------------+------------+-----------+----------+ 2304 | 3 | Reserved | 2305 +------+------------+------------+-----------+----------+ 2306 | 4 | Reserved | 2307 +------+------------+------------+-----------+----------+ 2308 | 5 | Reserved | UNBIND STATUS | 2309 +------+------------+------------+-----------+----------+ 2311 iFCP Revision 8 January 2002 2313 USER INFO Echoes the value received in the USER INFO 2314 field of the UNBIND request message. 2316 CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in 2317 the UNBIND request message. 2319 UNBIND STATUS: Indicates the success or failure of the 2320 UNBIND request as follows: 2322 Unbind Status Description 2323 ------------- ----------- 2325 0 Successful � No other status 2326 1 � 15 Reserved 2327 16 Failed � Unspecified Reason 2328 18 Failed � Connection ID Invalid 2329 Others Reserved 2331 7.3 LTEST -- Test Connection Liveness 2333 The LTEST message is sent at the interval specified in the CBIND 2334 request or response payload. The LTEST encapsulation time stamp 2335 SHALL be set as described in section 9.2.1 and may be used by the 2336 receiver to compute an estimate of propagation delay. However, the 2337 propagation delay limit SHALL NOT be enforced. 2339 iFCP Revision 8 January 2002 2341 +------+------------+------------+-----------+----------+ 2342 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2343 +------+------------+------------+-----------+----------+ 2344 | 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 | 2345 +------+------------+------------+-----------+----------+ 2346 | 1 | LIVENESS TEST INTERVAL | Reserved | 2347 | | (Seconds) | | 2348 +------+-------------------------+----------------------+ 2349 | 2 | COUNT | 2350 +------+------------+------------+-----------+----------+ 2351 | 3 | | 2352 +------+ SOURCE N_PORT NAME | 2353 | 4 | | 2354 +------+------------------------------------------------+ 2355 | 5 | | 2356 +------+ DESTINATION N_PORT NAME | 2357 | 6 | | 2358 +------+------------------------------------------------+ 2360 LIVENESS TEST Copy of the LIVENESS TEST INTERVAL 2361 INTERVAL: specified in the CBIND request or reply 2362 message. 2364 COUNT: Monotonically increasing value, initialized 2365 to 0 and incremented by one for each 2366 successive LTEST message. 2368 SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME 2369 specified in the CBIND request. 2371 DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT 2372 NAME: NAME specified in the CBIND request. 2374 8. Fibre Channel Link Services 2376 Link services provide a set of Fibre Channel functions that allow a 2377 port to send control information or request another port to perform 2378 a specific control function. 2380 There are three types of link services: 2382 a) Basic 2384 b) Extended 2386 c) ULP-specific (FC-4) 2388 iFCP Revision 8 January 2002 2390 Each link service message (request and reply) is carried by a Fibre 2391 Channel sequence, and can be segmented into multiple frames. 2393 The iFCP Layer is responsible for transporting link service 2394 messages across the IP fabric. This includes mapping Link Service 2395 messages appropriately from the domain of the Fibre Channel 2396 transport to that of the IP network. This process may require 2397 special processing and the inclusion of supplemental data by the 2398 iFCP layer. 2400 Each link service is processed according to one of the following 2401 rules: 2403 a) Transparent � The link service message and reply MUST be 2404 transported to the receiving N_PORT by the iFCP gateway without 2405 altering the message payload. The link service message and reply 2406 are not processed by the iFCP implementation. 2408 b) Special - Applies to alink service reply or request requiring 2409 iFCP intervention before forwarding to the destination N_PORT. 2410 Such messages may contain Fibre Channel addresses in the payload 2411 or may require other special processing. 2413 c) Rejected � When issued by a locally attached N_PORT, the 2414 specified link service request MUST be rejected by the iFCP 2415 implementation. The gateway SHALL respond to a rejected link 2416 service message by returning an LS_RJT response with a Reason 2417 Code of 0x0B (Command Not Supported) and a Reason Code 2418 Explanation of 0x0 (No Additional Explanation). 2420 This section describes the processing for special link services, 2421 including the manner in which supplemental data is added to the ELS 2422 payload. 2424 Appendix A enumerates all link services and the iFCP processing 2425 policy that applies to each. 2427 8.1 Special Link Service Messages 2429 Special link service messages require the intervention of the iFCP 2430 layer before forwarding to the destination N_PORT. Such 2431 intervention is required in order to: 2433 a) Service any link service message which requires special 2434 handling, such as a PLOGI. 2436 b) In address translation mode only, service any link service 2437 message which has an N_PORT address in the payload. 2439 Such messages are transmitted in a Fibre Channel frame having the 2440 format shown in Figure 19 for extended link services or Figure 21 2441 for FC-4 link services.: 2443 iFCP Revision 8 January 2002 2445 Word 2446 31 24 23 0 2447 +------------+------------------------------------------------+ 2448 0| R_CTL | D_ID | 2449 |[Req = 0x22]|[Destination of extended link Service request] | 2450 |[Rep = 0x23]| | 2451 +------------+------------------------------------------------+ 2452 1| CS_CTL | S_ID | 2453 | | [Source of extended link service request] | 2454 +------------+------------------------------------------------+ 2455 2| TYPE | F_CTL | 2456 | [0x01] | | 2457 +------------+------------------+-----------------------------+ 2458 3| SEQ_ID | DF_CTL | SEQ_CNT | 2459 +------------+------------------+-----------------------------+ 2460 4| OX_ID | RX_ID | 2461 +-------------------------------+-----------------------------+ 2462 5| Parameter | 2463 | [ 00 00 00 00 ] | 2464 +-------------------------------------------------------------+ 2465 6| LS_COMMAND | 2466 | [Extended Link Service Command Code] | 2467 +-------------==----------------------------------------------+ 2468 7| | 2469 .| Additional Service Request Parameters | 2470 .| ( if any ) | 2471 n| | 2472 +-------------------------------------------------------------+ 2473 Figure 19 -- Format of an Extended Link Service Frame 2475 iFCP Revision 8 January 2002 2477 Word 2478 31 24 23 0 2479 +------------+------------------------------------------------+ 2480 0| R_CTL | D_ID | 2481 |[Req = 0x32]| [Destination of FC-4 link Service request] | 2482 |[Rep = 0x33]| | 2483 +------------+------------------------------------------------+ 2484 1| CS_CTL | S_ID | 2485 | | [Source of FC-4 link service request] | 2486 +------------+------------------------------------------------+ 2487 2| TYPE | F_CTL | 2488 | (FC-4 | | 2489 | specific) | | 2490 +------------+------------------+-----------------------------+ 2491 3| SEQ_ID | DF_CTL | SEQ_CNT | 2492 +------------+------------------+-----------------------------+ 2493 4| OX_ID | RX_ID | 2494 +-------------------------------+-----------------------------+ 2495 5| Parameter | 2496 | [ 00 00 00 00 ] | 2497 +-------------------------------------------------------------+ 2498 6| LS_COMMAND | 2499 | [FC-4 Link Service Command Code] | 2500 +-------------------------------------------------------------+ 2501 7| | 2502 .| Additional Service Request Parameters | 2503 .| ( if any ) | 2504 n| | 2505 +-------------------------------------------------------------+ 2506 Figure 21 -- Format of an FC-4 Link Service Frame 2508 8.2 Link Services Requiring Payload Address Translation 2510 This section describes the handling for link service frames 2511 containing N_PORT addresses in the frame payload. Such addresses 2512 SHALL only be translated when the gateway is operating in address 2513 translation mode. When operating in address transparent mode, 2514 these addresses SHALL NOT be translated. In addition, such link 2515 service messages SHALL NOT be sent as special frames unless other 2516 processing by the iFCP layer is required. 2518 Supplemental data includes information required by the receiving 2519 gateway to convert an N_PORT address in the payload to an N_PORT 2520 address in the receiving gateway�s address space. The following 2521 rules define the manner in which such supplemental data is packaged 2522 and referenced. 2524 For an N_PORT address field, the gateway originating the frame MUST 2525 set the value in the payload to identify the address translation 2526 type as follows: 2528 iFCP Revision 8 January 2002 2530 0x00 00 01 � The gateway receiving the frame from the IP 2531 network MUST replace the contents of the field with the N_PORT 2532 alias of the frame originator. This translation type MUST be 2533 used when the address to be converted is that of the source 2534 N_PORT. 2536 0x00 00 02 � The gateway receiving the frame from the IP 2537 network MUST replace the contents of the field with the N_PORT 2538 I/D of the destination N_PORT. This translation type MUST be 2539 used when the address to be converted is that of the 2540 destination N_PORT 2542 0x00 00 03 � The gateway receiving the frame from the IP 2543 network MUST reference the specified supplemental data to set 2544 the field contents. The supplemental information is the 64-bit 2545 world wide identifier of the N_PORT as set forth in the Fibre 2546 Channel specification [FC-FS]. If not otherwise part of the 2547 ELS, this information MUST be appended in accordance with the 2548 applicable link service description. Unless specified 2549 otherwise, this translation type SHALL NOT be used if the 2550 address to be converted corresponds to that of the frame 2551 originator or recipient. 2553 Since Fibre Channel addressing rules prohibit the assignment of 2554 fabric addresses with a domain I/D of 0, the above codes will never 2555 correspond to valid N_PORT fabric IDs. 2557 For translation type 3, the receiving gateway SHALL obtain the 2558 information needed to fill in the field in the link service frame 2559 payload by converting the specified N_PORT world-wide identifier to 2560 a gateway IP address and N_PORT ID. This information MUST be 2561 obtained through a name server query. If the N_PORT is locally 2562 attached, the gateway MUST fill in the field with the N_PORT ID. 2563 If the N_PORT is remotely attached, the gateway MUST assign and 2564 fill in the field with an N_PORT alias. If an N_PORT alias has 2565 already been assigned, it MUST be reused. 2567 In the event that the sending gateway cannot obtain the world wide 2568 identifier of an N_PORT, or a receiving gateway cannot obtain the 2569 IP address and N_PORT ID, the gateway detecting the error SHALL 2570 terminate the request with an LS_RJT message as described in [FCS]. 2571 The Reason Code SHALL be set to 0x07 (protocol error) and the 2572 Reason Explanation SHALL be set to 0x1F (Invalid N_PORT 2573 identifier). 2575 Supplemental data is sent with the link service request or ACC 2576 frames in one of the following ways: 2578 a) By appending the necessary data to the end of the link service 2579 frame. 2581 b) By extending the sequence with additional frames. 2583 iFCP Revision 8 January 2002 2585 In the first case, a new frame SHALL be created whose length 2586 includes the supplemental data. The procedure for extending the 2587 link service sequence with additional frames is dependent on the 2588 link service type. 2590 After applying the supplemental data, the receiving gateway SHALL 2591 forward the resulting link service frames to the destination N_PORT 2592 with the supplemental information removed. 2594 When the ACC response requires iFCP intervention,, the receiving 2595 gateway MUST act as a proxy for the originator, retaining the state 2596 needed to process the response from the N_PORT to which the request 2597 was directed. 2599 8.3 Fibre Channel Link Services Processed by iFCP 2601 The following Extended and FC-4 Link Service Messages must receive 2602 special processing. 2604 Extended Link Service Messages LS_COMMAND Mnemonic 2605 ------------------------------ ---------- -------- 2606 Abort Exchange 0x06 00 00 00 ABTX 2607 Discover Address 0x52 00 00 00 ADISC 2608 Discover Address Accept 0x02 00 00 00 ADISC ACC 2609 FC Address Resolution Protocol 0x55 00 00 00 FARP-REPLY 2610 Reply 2611 FC Address Resolution Protocol 0x54 00 00 00 FARP-REQ 2612 Request 2613 Logout 0x05 00 00 00 LOGO 2614 Port Login 0x30 00 00 00 PLOGI 2615 Read Exchange Status Block 0x08 00 00 00 RES 2616 Read Exchange Status Block 0x02 00 00 00 RES ACC 2617 Accept 2618 Read Link Error Status Block 0x0F 00 00 00 RLS 2619 Read Sequence Status Block 0x09 00 00 00 RSS 2620 Reinstate Recovery Qualifier 0x12 00 00 00 RRQ 2621 Request Sequence Initiative 0x0A 00 00 00 RSI 2622 Third Party Process Logout 0x24 00 00 00 TPRLO 2623 Third Party Process Logout 0x02 00 00 00 TPRLO ACC 2624 Accept 2626 FC-4 Link Service Messages LS_COMMAND Mnemonic 2627 -------------------------- ---------- -------- 2628 FCP Read Exchange Concise 0x13 00 00 00 REC 2629 FCP Read Exchange Concise 0x02 00 00 00 REC ACC 2630 Accept 2632 Each encapsulated Fibre Channel frame that is part of a special 2633 link service MUST have the SPC bit set to one in the iFCP FLAGS 2634 field of the encapsulation header as specified in section 6.4.1. 2636 iFCP Revision 8 January 2002 2638 Supplemental data (if any) MUST be appended as described in the 2639 following section. 2641 The formats of each special link service message, including 2642 supplemental data where applicable, are shown in the following 2643 sections. Eachdescription shows the basic format, as specified in 2644 the applicable FC standard, followed by supplemental data as shown 2645 in the example below. 2647 +------+------------+------------+-----------+----------+ 2648 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2649 +------+------------+------------+-----------+----------+ 2650 | 0 | LS_COMMAND | 2651 +------+------------+------------+-----------+----------+ 2652 | 1 | | 2653 | . | | 2654 | . | Link Service Frame Payload | 2655 | | | 2656 | n | | 2657 +======+============+============+===========+==========+ 2658 | n+1 | | 2659 | . | Supplemental Data | 2660 | . | (if any) | 2661 | n+k | | 2662 +======+================================================+ 2663 Figure 23 -- Special Link Service Frame Payload 2665 8.3.1 Special Extended Link Services 2667 The following sections define extended link services for which 2668 special processing is required. 2670 8.3.1.1 Abort Exchange (ABTX) 2672 ELS Format: 2674 +------+------------+------------+-----------+----------+ 2675 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2676 +------+------------+------------+-----------+----------+ 2677 | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | 2678 +------+------------+------------+-----------+----------+ 2679 | 1 | RRQ Status | Exchange Originator S_ID | 2680 +------+------------+------------+-----------+----------+ 2681 | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| 2682 +------+------------+------------+-----------+----------+ 2683 | 3-10 | Optional association header (32 bytes | 2684 +======+============+============+===========+==========+ 2686 Fields Requiring Translation Supplemental Data 2687 Address Translation Type (see (type 3 only) 2689 iFCP Revision 8 January 2002 2691 ------------------- section 8.2) ------------ 2692 ----------- 2694 Exchange Originator 1, 2 N/A 2695 S_ID 2697 Other Special Processing: 2699 None 2701 8.3.1.2 Discover Address (ADISC) 2703 Format of ADISC ELS: 2705 +------+------------+------------+-----------+----------+ 2706 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2707 +------+------------+------------+-----------+----------+ 2708 | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | 2709 +------+------------+------------+-----------+----------+ 2710 | 1 | Reserved | Hard address of ELS Originator | 2711 +------+------------+------------+-----------+----------+ 2712 | 2-3 | Port Name of Originator | 2713 +------+------------+------------+-----------+----------+ 2714 | 4-5 | Node Name of originator | 2715 +------+------------+------------+-----------+----------+ 2716 | 6 | Rsvd | N_PORT I/D of ELS Originator | 2717 +======+============+============+===========+==========+ 2719 Fields Requiring Translation Supplemental Data 2720 Address Translation Type (see (type 3 only) 2721 ------------------- section 8.2) ------------ 2722 ------------- 2724 N_PORT I/D of ELS 1 N/A 2725 Originator 2727 Other Special Processing: 2729 The Hard Address of the ELS originator SHALL be set to 0. 2731 8.3.1.3 Discover Address Accept (ADISC ACC) 2733 Format of ADISC ACC ELS: 2735 +------+------------+------------+-----------+----------+ 2736 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2737 +------+------------+------------+-----------+----------+ 2739 iFCP Revision 8 January 2002 2741 | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | 2742 +------+------------+------------+-----------+----------+ 2743 | 1 | Reserved | Hard address of ELS Originator | 2744 +------+------------+------------+-----------+----------+ 2745 | 2-3 | Port Name of Originator | 2746 +------+------------+------------+-----------+----------+ 2747 | 4-5 | Node Name of originator | 2748 +------+------------+------------+-----------+----------+ 2749 | 6 | Rsvd | N_PORT I/D of ELS Originator | 2750 +======+============+============+===========+==========+ 2752 Fields Requiring Translation Supplemental Data 2753 Address Translation Type (see (type 3 only) 2754 ------------------- section 8.2) ------------ 2755 ------------ 2757 N_PORT I/D of ELS 1 N/A 2758 Originator 2760 Other Special Processing: 2762 The Hard Address of the ELS originator SHALL be set to 0. 2764 8.3.1.4 FC Address Resolution Protocol Reply (FARP-REPLY) 2766 The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS 2767 (see section 8.3.1.5) to perform the address resolution services 2768 required by the FC-VI protocol [FC-VI] and the Fibre Channel 2769 mapping of IP and ARP specified in RFC 2625 [RFC2625]. 2771 Format of FARP-REPLY ELS: 2773 iFCP Revision 8 January 2002 2775 +------+------------+------------+-----------+----------+ 2776 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2777 +------+------------+------------+-----------+----------+ 2778 | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | 2779 +------+------------+------------+-----------+----------+ 2780 | 1 | Match Addr | Requesting N_PORT Identifier | 2781 | | Code Points| | 2782 +------+------------+------------+-----------+----------+ 2783 | 2 | Responder | Responding N_PORT Identifier | 2784 | | Action | | 2785 +------+------------+------------+-----------+----------+ 2786 | 3-4 | Requesting N_PORT Port_Name | 2787 +------+------------+------------+-----------+----------+ 2788 | 5-6 | Requesting N_PORT Node_Name | 2789 +------+------------+------------+-----------+----------+ 2790 | 7-8 | Responding N_PORT Port_Name | 2791 +------+------------+------------+-----------+----------+ 2792 | 9-10 | Responding N_PORT Node_Name | 2793 +------+------------+------------+-----------+----------+ 2794 | 11-14| Requesting N_PORT IP Address | 2795 +------+------------+------------+-----------+----------+ 2796 | 15-18| Responding N_PORT IP Address | 2797 +======+============+============+===========+==========+ 2799 Fields Requiring Translation Supplemental Data 2800 Address Translation Type (see (type 3 only) 2801 ------------------- section 8.2) ----------------- 2802 ------------- 2804 Requesting N_PORT 2 N/A 2805 Identifier 2807 Responding N_PORT 1 N/A 2808 identifier 2810 Other Special Processing: 2812 None. 2814 8.3.1.5 FC Address Resolution Protocol Request (FARP-REQ) 2816 The FARP-REQ ELS is used to in conjunction with the FC-VI protocol 2817 [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP 2818 and FC address resolution in an FC fabric. The FARP-REQ ELS is 2819 usually directed to the fabric broadcast server at well-known 2820 address 0xFF-FF-FF for retransmission to all attached N_PORTs. 2822 iFCP Revision 8 January 2002 2824 Section 10.4 describes the iFCP implementation of FC broadcast 2825 server functionality in an iFCP fabric. 2827 Format of FARP_REQ ELS: 2829 +------+------------+------------+-----------+----------+ 2830 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2831 +------+------------+------------+-----------+----------+ 2832 | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | 2833 +------+------------+------------+-----------+----------+ 2834 | 1 | Match Addr | Requesting N_PORT Identifier | 2835 | | Code Points| | 2836 +------+------------+------------+-----------+----------+ 2837 | 2 | Responder | Responding N_PORT Identifier | 2838 | | Action | | 2839 +------+------------+------------+-----------+----------+ 2840 | 3-4 | Requesting N_PORT Port_Name | 2841 +------+------------+------------+-----------+----------+ 2842 | 5-6 | Requesting N_PORT Node_Name | 2843 +------+------------+------------+-----------+----------+ 2844 | 7-8 | Responding N_PORT Port_Name | 2845 +------+------------+------------+-----------+----------+ 2846 | 9-10 | Responding N_PORT Node_Name | 2847 +------+------------+------------+-----------+----------+ 2848 | 11-14| Requesting N_PORT IP Address | 2849 +------+------------+------------+-----------+----------+ 2850 | 15-18| Responding N_PORT IP Address | 2851 +======+============+============+===========+==========+ 2853 Fields Requiring Translation Supplemental Data 2854 Address Translation Type (see (type 3 only) 2855 ------------------- section 8.2) ----------------- 2856 ----------- 2858 Requesting N_PORT 3 Requesting N_PORT 2859 Identifier Port Name 2861 Responding N_PORT 3 Responding N_PORT 2862 Identifier Port Name 2864 Other Special Processing: 2866 None. 2868 8.3.1.6 Logout (LOGO) 2870 ELS Format: 2872 iFCP Revision 8 January 2002 2874 +------+------------+------------+-----------+----------+ 2875 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2876 +------+------------+------------+-----------+----------+ 2877 | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | 2878 +------+------------+------------+-----------+----------+ 2879 | 1 | Rsvd | N_PORT I/D being logged out | 2880 +------+------------+------------+-----------+----------+ 2881 | 2-3 | Port name of the LOGO originator (8 bytes) | 2882 +======+============+============+===========+==========+ 2884 This ELS shall always be sent as an augmented ELS regardless of the 2885 translation mode in effect. 2887 Fields Requiring Translation Supplemental Data 2888 Address Translation Type(see (type 3 only) 2889 ------------------- section 8.2) -------------- 2890 ----------- 2892 N_PORT I/D Being 1 N/A 2893 Logged Out 2895 Other Special Processing: 2897 See section 6.2.3.1. 2899 8.3.1.7 Port Login (PLOGI) and PLOGI ACC 2901 PLOGI provides the mechanism for establishing a login session 2902 between two N_PORTs. In iFCP, a PLOGI request addressed to a 2903 remotely attached N_PORT may trigger the creation of an iFCP 2904 session, if one does not already exist. Otherwise, the PLOGI and 2905 ACC payloads MUST be passed transparently to the destination 2906 N_PORT. 2908 The PLOGI request and ACC response carry information identifying 2909 the originating N_PORT, including specification of its capabilities 2910 and limitations. If the destination N_PORT accepts the login 2911 request, it sends an accept (an ACC frame with PLOGI payload), 2912 specifying its capabilities and limitations. This exchange 2913 establishes the operating environment for the two N_PORTs. 2915 The following figure is duplicated from [FC-FS], and shows the 2916 PLOGI message format for both request and accept (ACC) response. A 2917 port will reject a PLOGI request by transmitting an LS_RJT message, 2918 which contains no payload. 2920 iFCP Revision 8 January 2002 2922 Byte 2923 Offset 2924 +----------------------------------+ 2925 0 | LS_COMMAND | 4 Bytes 2926 +----------------------------------+ 2927 4 | COMMON SERVICE PARAMETERS | 16 Bytes 2928 +----------------------------------+ 2929 20 | PORT NAME | 8 Bytes 2930 +----------------------------------+ 2931 28 | NODE NAME | 8 Bytes 2932 +----------------------------------+ 2933 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes 2934 +----------------------------------+ 2935 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes 2936 +----------------------------------+ 2937 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes 2938 +----------------------------------+ 2939 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes 2940 +----------------------------------+ 2941 102 | VENDOR VERSION LEVEL | 16 Bytes 2942 +----------------------------------+ 2943 Total Length = 116 bytes 2944 Figure 24 -- Format of PLOGI Request and ACC Payloads 2946 Details on the above fields, including common and class-based 2947 service parameters, can be found in [FC-FS]. 2949 8.3.1.8 Read Exchange Status Block (RES) 2951 ELS Format: 2953 +------+------------+------------+-----------+----------+ 2954 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2955 +------+------------+------------+-----------+----------+ 2956 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 2957 +------+------------+------------+-----------+----------+ 2958 | 1 | Rsvd | Exchange Originator S_ID | 2959 +------+------------+------------+-----------+----------+ 2960 | 2 | OX_ID | RX_ID | 2961 +------+------------+------------+-----------+----------+ 2962 | 3-10 | Association header (may be optionally req�d) | 2963 +======+============+============+===========+==========+ 2964 | 11-12| Port name of the Exchange Originator (8 bytes) | 2965 +======+============+============+===========+==========+ 2967 iFCP Revision 8 January 2002 2969 Fields Requiring Translation Supplemental Data 2970 Address Translation Type(see (type 3 only) 2971 ------------------- section 8.2) ------------------ 2972 ----------- 2974 Exchange Originator 1, 2 or 3 Port Name of the 2975 S_ID Exchange Originator 2977 Other Special Processing: 2979 None. 2981 8.3.1.9 Read Exchange Status Block Accept 2983 Format of ELS Accept Response: 2985 +------+------------+------------+-----------+----------+ 2986 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2987 +------+------------+------------+-----------+----------+ 2988 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 2989 +------+------------+------------+-----------+----------+ 2990 | 1 | OX_ID | RX_ID | 2991 +------+------------+------------+-----------+----------+ 2992 | 2 | Rsvd | Exchange Originator N_PORT ID | 2993 +------+------------+------------+-----------+----------+ 2994 | 3 | Rsvd | Exchange Responder N_PORT ID | 2995 +------+------------+------------+-----------+----------+ 2996 | 4 | Exchange Status Bits | 2997 +------+------------+------------+-----------+----------+ 2998 | 5 | Reserved | 2999 +------+------------+------------+-----------+----------+ 3000 | 6�n | Service Parameters and Sequence Statuses | 3001 | | as described in [FCS] | 3002 +======+============+============+===========+==========+ 3003 |n+1- | Port name of the Exchange Originator (8 bytes) | 3004 |n+2 | | 3005 +======+============+============+===========+==========+ 3006 |n+3- | Port name of the Exchange Responder (8 bytes) | 3007 |n+4 | | 3008 +======+============+============+===========+==========+ 3010 iFCP Revision 8 January 2002 3012 Fields Requiring Translation Supplemental Data 3013 Address Translation Type(see (type 3 only) 3014 ------------------- section 8.2) ------------------ 3015 ----------- 3017 Exchange Originator 1, 2 or 3 Port Name of the 3018 N_PORT I/D Exchange Originator 3020 Exchange Responder 1, 2 or 3 Port Name of the 3021 N_PORT I/D Exchange Responder 3023 When supplemental data is required, the ELS SHALL be extended by 4 3024 words as shown above. If the translation type for the Exchange 3025 Originator N_PORT I/D or the Exchange Responder N_PORT I/D is 1 or 3026 2, the corresponding 8-byte port name SHALL be set to all zeros. 3028 Other Special Processing: 3030 None. 3032 8.3.1.10 Read Link Error Status (RLS) 3034 ELS Format: 3036 +------+------------+------------+-----------+----------+ 3037 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3038 +------+------------+------------+-----------+----------+ 3039 | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | 3040 +------+------------+------------+-----------+----------+ 3041 | 1 | Rsvd | N_PORT Identifier | 3042 +======+============+============+===========+==========+ 3043 | 2-3 | Port name of the N_PORT (8 bytes) | 3044 +======+============+============+===========+==========+ 3046 Fields Requiring Translation Supplemental Data (type 3047 Address Translation Type(see 3 only) 3048 ------------------- section 8.2) ------------------ 3049 ----------- 3051 N_PORT Identifier 1, 2 or 3 Port Name of the N_PORT 3053 Other Special Processing: 3055 None. 3057 8.3.1.11 Read Sequence Status Block (RSS) 3059 ELS Format: 3061 iFCP Revision 8 January 2002 3063 +------+------------+------------+-----------+----------+ 3064 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3065 +------+------------+------------+-----------+----------+ 3066 | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | 3067 +------+------------+------------+-----------+----------+ 3068 | 1 | SEQ_ID | Exchange Originator S_ID | 3069 +------+------------+------------+-----------+----------+ 3070 | 2 | OX_ID | RX_ID | 3071 +======+============+============+===========+==========+ 3072 | 3-4 |Port name of the Exchange Originator (8 bytes) | 3073 +======+============+============+===========+==========+ 3075 Fields Requiring Translation Supplemental Data 3076 Address Translation Type(see (type 3 only) 3077 ------------------- section 8.2) ------------------ 3078 ----------- 3080 Exchange Originator 1, 2 or 3 Port Name of the 3081 S_ID Exchange Originator 3083 Other Special Processing: 3085 None. 3087 8.3.1.12 Reinstate Recovery Qualifier (RRQ) 3089 ELS Format: 3091 +------+------------+------------+-----------+----------+ 3092 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3093 +------+------------+------------+-----------+----------+ 3094 | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | 3095 +------+------------+------------+-----------+----------+ 3096 | 1 | Rsvd | Exchange Originator S_ID | 3097 +------+------------+------------+-----------+----------+ 3098 | 2 | OX_ID | RX_ID | 3099 +------+------------+------------+-----------+----------+ 3100 | 3-10 | Association header (may be optionally req�d) | 3101 +======+============+============+===========+==========+ 3103 Fields Requiring Translation Supplemental Data 3104 Address Translation Type(see (type 3 only) 3105 ------------------- section 8.2) ------------------ 3106 ----------- 3108 Exchange Originator 1 or 2 N/A 3109 S_ID 3111 iFCP Revision 8 January 2002 3113 Other Special Processing: 3115 None. 3117 8.3.1.13 Request Sequence Initiative (RSI) 3119 ELS Format: 3121 +------+------------+------------+-----------+----------+ 3122 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3123 +------+------------+------------+-----------+----------+ 3124 | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | 3125 +------+------------+------------+-----------+----------+ 3126 | 1 | Rsvd | Exchange Originator S_ID | 3127 +------+------------+------------+-----------+----------+ 3128 | 2 | OX_ID | RX_ID | 3129 +------+------------+------------+-----------+----------+ 3130 | 3-10 | Association header (may be optionally req�d) | 3131 +======+============+============+===========+==========+ 3133 Fields Requiring Translation Supplemental Data 3134 Address Translation Type(see (type 3 only) 3135 ------------------- section 8.2) ------------------ 3136 ----------- 3138 Exchange Originator 1 or 2 N/A 3139 S_ID 3141 Other Special Processing: 3143 None. 3145 8.3.1.14 Third Party Process Logout (TPRLO) 3147 TPRLO provides a mechanism for an N_PORT (third party) to remove 3148 one or more process login sessions that exist between the 3149 destination N_PORT and other N_PORTs specified in the command. 3150 This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, 3151 each of which when combined with the destination N_PORT identifies 3152 a process login to be terminated by the command. 3154 iFCP Revision 8 January 2002 3156 +--------+------------+--------------------+----------------------+ 3157 | Word | Bits 31�24 | Bits 23�16 | Bits 15 - 0 | 3158 +--------+------------+--------------------+----------------------+ 3159 | 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length | 3160 +--------+------------+--------------------+----------------------+ 3161 | 1 | TPRLO Logout Parameter Page 0 | 3162 +--------+--------------------------------------------------------+ 3163 | 5 | TPRLO Logout Parameter Page 1 | 3164 +--------+--------------------------------------------------------+ 3165 .... 3166 +--------+--------------------------------------------------------+ 3167 |(4*n)+1 | TPRLO Logout Parameter page n | 3168 +--------+--------------------------------------------------------+ 3169 Figure 25 -- Format of TPRLO ELS 3171 Each TPRLO parameter page contains parameters identifying one or 3172 more image pairs and may be associated with a single FC4 protocol 3173 type, common to all FC4 protocol types between the specified image 3174 pair, or global to all specified image pairs. The format of aTPRLO 3175 page requiring address translation is shown in Figure 26. 3176 Additional information on TPRLO can be found in [FC-FS]. 3178 +------+------------+------------+-----------+----------+ 3179 | Word | Bits 31�24 | Bits 23�16 | Bits 15-8 | Bits 7-0 | 3180 +------+------------+------------+-----------+----------+ 3181 | 0 | TYPE Code | TYPE CODE | | 3182 | | or | EXTENSION | TPRLO Flags | 3183 | | Common SVC | | | 3184 | | Parameters | | | 3185 +------+------------+------------+-----------+----------+ 3186 | 1 | Third Party Process Associator | 3187 +------+------------+------------+-----------+----------+ 3188 | 2 | Responder Process Associator | 3189 +------+------------+------------+-----------+----------+ 3190 | 3 | Reserved | Third Party Originator N_PORT ID | 3191 +======+============+============+===========+==========+ 3192 | 4-5 | World Wide Name of Third Party Originator | 3193 | | N_PORT | 3194 +------+------------------------------------------------+ 3195 Figure 26 -- Format of an Augmented TPRLO Parameter Page 3197 The TPRLO flags that affect the processing of the supplementedELS 3198 are as follows: 3200 Bit 12: Global Process logout. When set to one, this bit 3201 indicates that all image pairs for all N_PORTs of the 3202 specified FC4 protocol shall be invalidated. When the 3203 value of this bit is one, only one logout parameter page 3204 is permitted in the TPRLO payload. 3206 Bit 13: Third party Originator N_PORT Validity. When set to 3207 one, this bit indicates that word 3, bits 23-00 (Third 3209 iFCP Revision 8 January 2002 3211 Party Originator N_PORT ID) are meaningful. 3213 If bit 13 has a value of zero and bit 12 has a value of one in the 3214 TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. 3216 Otherwise the originating gateway SHALL process the ELS as follows: 3218 a) The first word of the TPRLO payload SHALL NOT be modified. 3220 b) Each TPRLO parameter page shall be extended by two words as 3221 shown in Figure 26. 3223 c) If word 0, bit 13 (Third Party Originator N_PORT I/D validity) 3224 in the TPRLO flags field has a value of one, then the sender 3225 shall place the world-wide port name of the fibre channel 3226 device's N_PORT in the extension words. The N_PORT I/D SHALL be 3227 set to 3. Otherwise, the contents of the extension words and 3228 the Third Party Originator N_PORT ID SHALL be set to zero. 3230 d) The ELS originator SHALL set the SPC bit in the encapsulation 3231 header of each augmented frame comprising the ELS (see section 3232 6.4.1). 3234 e) If the ELS contains a single TPRLO parameter page, the 3235 originator SHALL increase the frame length as necessary to 3236 include the extended parameter page. 3238 f) If the ELS to be augmented contains multiple TPRLO parameter 3239 pages, the FC frames created to contain the augmented ELS 3240 payload SHALL NOT exceed the maximum frame size that can be 3241 accepted by the destination N_PORT. 3243 Each Fibre Channel frame SHALL contain an integer number of 3244 extended TPRLO parameter pages. The maximum number of extended 3245 TPRLO parameter pages in a frame SHALL be limited to the number 3246 that can be held without exceeding the above upper limit. New 3247 frames resulting from the extension of the TPRLO pages to 3248 include the supplemental data shall be created by extending the 3249 SEQ_CNT in the Fibre Channel frame header. The SEQ_ID SHALL NOT 3250 be modified. 3252 The gateway receiving the augmented TPRLO ELS SHALL generate ELS 3253 frames to be sent to the destination N_PORT by copying word 0 of 3254 the ELS payload and processing each augmented parameter page as 3255 follows: 3257 a) If word 0, bit 13 has a value of one, create a parameter page by 3258 copying words 0 through 2 of the augmented parameter page. The 3259 Third Party Originator N_PORT I/D in word 3 shall be generated 3261 iFCP Revision 8 January 2002 3263 by referencing the supplemental data as described in section 3264 8.2. 3266 b) If word 0, bit 13 has a value of zero, create a parameter page 3267 by copying words 0 through 3 of the augmented parameter page. 3269 The size of each frame to be sent to the destination N_PORT MUST 3270 NOT exceed the maximum frame size that the destination N_PORT can 3271 accept. The sequence identifier in each frame header SHALL be 3272 copied from the augmented ELS and the sequence count shall be 3273 monotonically increasing. 3275 8.3.1.15 Third Party Logout Accept (TPRLO ACC) 3277 The format of the TPRLO ACC frame is shown in Figure 28. 3279 +--------+------------+--------------------+----------------------+ 3280 | Word | Bits 31�24 | Bits 23�16 | Bits 15 - 0 | 3281 +--------+------------+--------------------+----------------------+ 3282 | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | 3283 +--------+------------+--------------------+----------------------+ 3284 | 1 | TPRLO Logout Parameter Page 0 | 3285 +--------+--------------------------------------------------------+ 3286 | 5 | TPRLO Logout Parameter Page 1 | 3287 +--------+--------------------------------------------------------+ 3288 .... 3289 +--------+--------------------------------------------------------+ 3290 |(4*n)+1 | TPRLO Logout Parameter page n | 3291 +--------+--------------------------------------------------------+ 3292 Figure 28 -- Format of TPRLO ACC ELS 3294 The format of the parameter page and rules for parameter page 3295 augmentation are as specified in section 8.3.1.14. 3297 8.3.2 Special FC-4 Link Services 3299 The following sections define FC-4 link services for which special 3300 processing is required. 3302 8.3.2.1 FC-4 Link Services defined by FCP 3304 8.3.2.1.1 Read Exchange Concise (REC) 3306 Link Service Request Format: 3308 iFCP Revision 8 January 2002 3310 +------+------------+------------+-----------+----------+ 3311 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3312 +------+------------+------------+-----------+----------+ 3313 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3314 +------+------------+------------+-----------+----------+ 3315 | 1 | Rsvd | Exchange Originator S_ID | 3316 +------+------------+------------+-----------+----------+ 3317 | 2 | OX_ID | RX_ID | 3318 +======+============+============+===========+==========+ 3319 | 3-4 |Port name of the exchange originator (8 bytes) | 3320 | | (present only for translation type 3) | 3321 +======+============+============+===========+==========+ 3323 Fields Requiring Translation Supplemental Data 3324 Address Translation Type(see (type 3 only) 3325 ------------------- section 8.2) ------------------ 3326 ----------- 3328 Exchange Originator 1, 2 or 3 Port Name of the 3329 S_ID Exchange 3330 Originator 3332 Other Special Processing: 3334 None. 3336 8.3.2.1.2 Read Exchange Concise Accept (REC ACC) 3338 Format of REC ACC Response: 3340 iFCP Revision 8 January 2002 3342 +------+------------+------------+-----------+----------+ 3343 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3344 +------+------------+------------+-----------+----------+ 3345 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3346 +------+------------+------------+-----------+----------+ 3347 | 1 | OX_ID | RX_ID | 3348 +------+------------+------------+-----------+----------+ 3349 | 2 | Rsvd | Exchange Originator N_PORT ID | 3350 +------+------------+------------+-----------+----------+ 3351 | 3 | Rsvd | Exchange Responder N_PORT ID | 3352 +------+------------+------------+-----------+----------+ 3353 | 4 | Data Transfer Count | 3354 +------+------------+------------+-----------+----------+ 3355 | 5 | Exchange Status | 3356 +======+============+============+===========+==========+ 3357 | 6-7 |Port name of the Exchange Originator (8 bytes) | 3358 +======+============+============+===========+==========+ 3359 | 8-9 |Port name of the Exchange Responder (8 bytes) | 3360 +======+============+============+===========+==========+ 3362 Fields Requiring Translation Supplemental Data 3363 Address Translation Type(see (type 3 only) 3364 ------------------- section 8.2) ------------------ 3365 ----------- 3367 Exchange Originator 1, 2 or 3 Port Name of the 3368 N_PORT I/D Exchange Originator 3370 Exchange Responder 1, 2 or 3 Port Name of the 3371 N_PORT I/D Exchange Responder 3373 When supplemental data is required, the frame SHALL always be 3374 extended by 4 words as shown above. If the translation type for 3375 the Exchange Originator N_PORT I/D or the Exchange Responder N_PORT 3376 I/D is 1 or 2, the corresponding 8-byte port name SHALL be set to 3377 all zeros. 3379 Other Special Processing: 3381 None. 3383 8.4 FLOGI Service Parameters Supported by an iFCP Gateway 3385 The FLOGI ELS is issued by an N_PORT that wishes to access the 3386 fabric transport services. 3388 The format of the FLOGI request and FLOGI ACC payloads are 3389 identical to the PLOGI request and ACC payloads described in 3390 section 8.3.1.7. The figure in that section is duplicated below 3391 for convenience. 3393 iFCP Revision 8 January 2002 3395 Byte 3396 Offset 3397 +----------------------------------+ 3398 0 | LS_COMMAND | 4 Bytes 3399 +----------------------------------+ 3400 4 | COMMON SERVICE PARAMETERS | 16 Bytes 3401 +----------------------------------+ 3402 20 | PORT NAME | 8 Bytes 3403 +----------------------------------+ 3404 28 | NODE NAME | 8 Bytes 3405 +----------------------------------+ 3406 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes 3407 +----------------------------------+ 3408 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes 3409 +----------------------------------+ 3410 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes 3411 +----------------------------------+ 3412 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes 3413 +----------------------------------+ 3414 102 | VENDOR VERSION LEVEL | 16 Bytes 3415 +----------------------------------+ 3416 Figure 30 -- FLOGI Request and ACC Payload Format 3418 A full description of each parameter is given in [FC-FS]. 3420 This section tabulates the protocol-dependant service parameters 3421 supported by a fabric port attached to an iFCP gateway. 3423 The service parameters carried in the payload of an FLOGI extended 3424 link service request MUST be set in accordance with 3425 Table 4. 3427 iFCP Revision 8 January 2002 3429 +-----------------------------------------+---------------+ 3430 | | Fabric Login | 3431 | Service Parameter | Class | 3432 | +---+---+---+---+ 3433 | | 1 | 2 | 3 | 4 | 3434 +-----------------------------------------+---+---+---+---+ 3435 | Class Validity | n | M | M | n | 3436 +-----------------------------------------+---+---+---+---+ 3437 | Service Options | | 3438 +-----------------------------------------+---+---+---+---+ 3439 | Intermix Mode | n | n | n | n | 3440 +-----------------------------------------+---+---+---+---+ 3441 | Stacked Connect-Requests | n | n | n | n | 3442 +-----------------------------------------+---+---+---+---+ 3443 | Sequential Delivery | n | M | M | n | 3444 +-----------------------------------------+---+---+---+---+ 3445 | Dedicated Simplex | n | n | n | n | 3446 +-----------------------------------------+---+---+---+---+ 3447 | Camp on | n | n | n | n | 3448 +-----------------------------------------+---+---+---+---+ 3449 | Buffered Class 1 | n | n | n | n | 3450 +-----------------------------------------+---+---+---+---+ 3451 | Priority | n | n | n | n | 3452 +-----------------------------------------+---+---+---+---+ 3453 | Initiator/Recipient Control | | 3454 +-----------------------------------------+---+---+---+---+ 3455 | Clock synchronization ELS capable | n | n | n | n | 3456 +-----------------------------------------+---+---+---+---+ 3457 Table 4 -- FLOGI Service Parameter Settings 3459 Notes: 3461 1) "n" indicates a parameter or capability that is not 3462 supported by the iFCP protocol. 3464 2) "M" indicates an applicable parameter that MUST be 3465 supported by an iFCP gateway. 3467 9. iFCP Error Detection 3469 9.1 Overview 3471 [FC-FS] defines error detection and recovery procedures. These 3472 Fibre Channel-defined mechanisms continue to be available in the 3473 iFCP environment. 3475 9.2 Stale Frame Prevention 3477 Recovery from Fibre Channel protocol error conditions requires that 3478 frames associated with a failed or aborted Exchange drain from the 3479 fabric before Exchange resources can be safely reused. 3481 iFCP Revision 8 January 2002 3483 Since a Fibre Channel fabric may not preserve frame order, there is 3484 no deterministic way to purge such frames. Instead, the fabric 3485 guarantees that frame the lifetime will not exceed a specific limit 3486 (R_A_TOV). 3488 R_A_TOV is defined in [FC-FS] as "the maximum transit time within a 3489 fabric to guarantee that a lost frame will never emerge from the 3490 fabric". For example, a value of 2 x R_A_TOV is the minimum time 3491 that the originator of an ELS request or FC-4 link service request 3492 must wait for the response to that request. The Fibre Channel 3493 default value for R_A_TOV is 10 seconds. 3495 An iFCPgateway SHALL actively enforce limits on R_A_TOV as 3496 described in section 9.2.1. 3498 9.2.1 Enforcing R_A_TOV Limits 3500 The R_A_TOV limit on frame lifetimes SHALL be enforced by means of 3501 the time stamp in the encapsulation header (see section 6.4.1) as 3502 described in this section. 3504 The budget for R_A_TOV SHOULD include allowances for the 3505 propagation delay through the gateway regions of the sending and 3506 receiving N_PORTs plus the propagation delay through the IP 3507 network. This latter component is referred to in this 3508 specification as IP_TOV. 3510 IP_TOV should be set well below the value of R_A_TOV specified for 3511 the iFCP fabric and should be stored in the iSNS server. IP_TOV 3512 should be set to 50 percent of R_A_TOV. 3514 The following paragraphs describe the requirements for 3515 synchronizing gateway time bases and the rules for measuring and 3516 enforcing propagation delay limits. 3518 The protocol for synchronizing a gateway time base is SNTP 3519 [RFC2030]. In order to insure that all gateways are time-aligned, a 3520 gateway SHOULD obtain the address of an SNTP-compatible time server 3521 via an iSNS query. If multiple time server addresses are returned 3522 by the query, the servers must be synchronized and the gateway may 3523 use any server in the list. Alternatively, the server may return a 3524 multicast group address in support of operation in Anycast mode. 3525 Implementation of Anycast mode is as specified in [RFC2030], 3526 including the precautions defined in that document. Multicast mode 3527 SHOULD NOT be used. 3529 An SNTP server may use any one of the time reference sources listed 3530 in [RFC2030]. The resolution of the time reference MUST be 125 3531 milliseconds or better. 3533 Stability of the SNTP server and gateway time bases should be 100 3534 ppm or better. 3536 iFCP Revision 8 January 2002 3538 With regard to its time base, the gateway is in either the 3539 Synchronized or Unsynchronized state. When in the Unsynchronized 3540 state, the gateway SHALL: 3542 a) Set the time stamp field to 0,0 for all outgoing frames 3544 b) Ignore the time stamp field for all incoming frames. 3546 When in the synchronized state, the gateway SHALL 3548 a) Set the time stamp field for each outgoing frame in accordance 3549 with the gateway's internal time base 3551 b) Check the time stamp field of each incoming frame, following 3552 validation of the encapsulation header CRC as described in 3553 section 6.4.4. 3555 c) If the incoming frame has a time stamp of 0,0, the receiving 3556 gateway SHALL NOT test the frame to determine if it is stale. 3558 d) If the incoming frame has a non-zero time stamp, the receiving 3559 gateway SHALL compute the absolute value of the time in flight 3560 and SHALL compare it against the value of IP_TOV specified for 3561 the IP fabric. 3563 e) If the result in step (d) exceeds IP_TOV, the encapsulated 3564 frame shall be discarded. Otherwise, the frame shall be de- 3565 encapsulated as described in section 6.4.4. 3567 A gateway SHALL enter the Synchronized state upon receiving a 3568 successful response to an SNTP query. 3570 A gateway shall enter the Unsynchronized state: 3572 a) Upon power up and before successful completion of an SNTP query 3574 b) Whenever the gateway looses contact with the SNTP server such 3575 that the gateway's time base may no longer be in alignment with 3576 that of the SNTP server. The criterion for determining loss of 3577 contact is implementation specific. 3579 Following loss of contact, it is recommended that the gateway enter 3580 the Unsynchronized state when the estimated time base drift 3581 relative to the SNTP reference is greater than ten percent of the 3582 IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and 3583 IP_TOV equals 5 seconds, the maximum allowable loss of contact 3584 duration would be about 42 minutes.) 3586 In response to loss of synchronization, a gateway enforcing R_A_TOV 3587 limits as described in this section should abort all N_PORT login 3588 sessions as described in section 6.2.3.2. 3590 iFCP Revision 8 January 2002 3592 10. Fabric Services Supported by an iFCP implementation 3594 An iFCP gateway implementation MUST support the following fabric 3595 services: 3597 N_PORT ID Value Description Section 3598 --------------- ----------- ------- 3599 0xFF-FF-FE F_PORT Server 10.1 3601 0xFF-FF-FD Fabric Controller 10.2 3603 0xFF-FF-FC Directory/Name Server 10.3 3605 In addition, an iFCP gateway MAY support the FC broadcast server 3606 functionality described in section 10.4. 3608 10.1 F_PORT Server 3610 The F_PORT server SHALL support the FLOGI ELS as described in 3611 section 8.4 as well as the following ELSs specified in [FC-FS]: 3613 a) Request for fabric service parameters (FDISC), 3615 b) Request for the link error status (RLS), 3617 c) Read Fabric Timeout Values (RTV). 3619 10.2 Fabric Controller 3621 The Fabric Controller SHALL support the following ELSs as specified 3622 in [FC-FS]: 3624 a) State Change Notification (SCN), 3626 b) Registered State Change Notification (RSCN), 3628 c) State Change Registration (SCR). 3630 10.3 Directory/Name Server 3632 The Directory/Name server provides a registration service allowing 3633 an N_PORT to record or query the database for information about 3634 other N_PORTs. The services are defined in [FC-GS3]. The queries 3635 are issued as FC-4 transactions using the FC-CT command transport 3636 protocol specified in [FC-GS3]. 3638 iFCP Revision 8 January 2002 3640 In iFCP, name server requests are translated to the iSNS queries 3641 defined in [ISNS]. The definitions of name server objects are 3642 specified in [FC-GS3]. 3644 The name server SHALL support record and query operations for 3645 directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) 3646 and MAY support the FC-4 specific services as defined in [FC-GS3]. 3648 10.4 Broadcast Server 3650 Fibre Channel frames are broadcast throughout the fabric by 3651 addressing them to the Fibre Channel broadcast server at well-known 3652 Fibre Channel address 0xFF-FF-FF. The broadcast server then 3653 replicates and delivers the frame to each attached N_PORT in all 3654 zones to which the originating device belongs. Only class 3 3655 (datagram) service is supported. 3657 In an iFCP system, the Fibre Channel broadcast function is emulated 3658 by means of a two-tier architecture comprised of the following 3659 elements: 3661 a) A local broadcast server residing in each iFCP gateway. The 3662 local server distributes broadcast traffic within the gateway 3663 region and forwards outgoing broadcast traffic to a global 3664 server for distribution throughout the network. 3666 b) A global broadcast server which re-distributes broadcast 3667 traffic to the local server in each participating gateway. 3669 c) An iSNS discovery domain defining the scope over which 3670 broadcast traffic is propagated. The discovery domain is 3671 populated with a global broadcast server and the set of local 3672 servers it supports. 3674 The local and global broadcast servers are logical iFCP devices 3675 that communicate using the iFCP protocol. The servers have an 3676 N_PORT Network Address consisting of an iFCP portal address and an 3677 N_PORT I/D set to the well-known Fibre Channel address of the FC 3678 broadcast server (0xff-ff-ff). 3680 As noted above, an N_PORT originates a broadcast by directing frame 3681 traffic to the Fibre Channel broadcast server. The gateway-resident 3682 local server distributes a copy of the frame locally and forwards a 3683 copy to the global server for redistribution to the local servers 3684 on other gateways. The global server MUST NOT echo a broadcast 3685 frame to the originating local server. 3687 10.4.1 Establishing the Broadcast Configuration 3689 The broadcast configuration is managed using facilities provided by 3690 the iSNS server. Specifically: 3692 iFCP Revision 8 January 2002 3694 a) An iSNS discovery domain is created and seeded with the network 3695 address of the global broadcast server N_PORT. The global 3696 server is identified as such by setting the appropriate N_PORT 3697 entity attribute. 3699 b) Using the management interface, each broadcast server is preset 3700 with the identity of the broadcast domain.. 3702 During power up, each gateway SHALL invoke the iSNS service to 3703 register its local broadcast server in the broadcast discovery 3704 domain. After registration, the local server SHALL wait for the 3705 global broadcast server to establish an iFCP session. 3707 The global server SHALL register with the iSNS server as follows: 3709 a) The server SHALL query the iSNS name server by attribute to 3710 obtain the world-wide port name of the N_PORT pre-configured to 3711 provide global broadcast services. 3713 b) If the world-wide port name obtained above does not correspond 3714 to that of the server issuing the query, the N_PORT SHALL NOT 3715 perform global broadcast functions for N_PORTs in that discovery 3716 domain. 3718 c) Otherwise, the global server N_PORT shall register with the 3719 discovery domain and query the iSNS server to identify all 3720 currently-registered local servers. 3722 d) The global broadcast server shall initiate an iFCP session with 3723 each local broadcast server in the domain. When a new local 3724 server registers, the global server SHALL receive a state change 3725 notification and respond by initiating an iFCP session with the 3726 newly added server. The gateway SHALL obtain these 3727 notifications using the iSNS provisions for lossless delivery. 3729 Upon receiving the CBIND request to initiate the iFCP session, the 3730 local server SHALL record the world-wide port name and N_PORT 3731 network address of the global server. 3733 10.4.2 Broadcast Session Management 3735 After the initial broadcast session is established, the local or 3736 global broadcast server MAY choose to manage the session in one of 3737 the following ways depending on resource requirements and the 3738 anticipated level of broadcast traffic: 3740 a) A server MAY keep the session open continuously. Since 3741 broadcast sessions are often quiescent for long periods of 3742 time, the server SHOULD monitor session connectivity as 3743 described in section 6.2.2.2. 3745 iFCP Revision 8 January 2002 3747 b) A server MAY open the broadcast session on demand, only when 3748 broadcast traffic is to be sent. If the session is reopened by 3749 the global server, the local server SHALL replace the 3750 previously recorded network address of the global broadcast 3751 server. 3753 O 3755 11. iFCP Security 3757 11.1 Overview 3759 iFCP relies upon the IPSec protocol suite to provide data 3760 confidentiality and authentication services and IKE as the key 3761 management protocol. Section 11.2 describes the security 3762 requirements arising from iFCP�s operating environment while 3763 Section 11.3 describes the resulting design choices, their 3764 requirement levels, and how they apply to the iFCP protocol. 3766 11.2 iFCP Security Operating Requirements 3768 11.2.1 Context 3770 iFCP is a protocol designed for use by gateway devices deployed in 3771 enterprise data centers. Such environments typically have security 3772 gateways designed to provide network security through isolation 3773 from public networks. Furthermore, iFCP data may need to traverse 3774 security gateways in order to support SAN-to-SAN connectivity 3775 across public networks. 3777 11.2.2 Security Threats 3779 Communicating iFCP gateways are vulnerable to attacks. Examples of 3780 attacks include attempts by an adversary to: 3782 a) Acquire confidential data and identities by snooping data 3783 packets. 3785 b) Modify packets containing iFCP data and control messages. 3787 c) Inject new packets into the iFCP session. 3789 d) Hijack the TCP connection carrying the iFCP session. 3791 e) Launch denial of service attacks against the iFCP gateway. 3793 f) Disrupt security negotiation process. 3795 g) Impersonate a legitimate security gateway. 3797 h) Compromise communication with the iSNS server. 3799 iFCP Revision 8 January 2002 3801 It is imperative to thwart these attacks, given that an iFCP 3802 gateway is the last line of defense for a whole Fibre Channel 3803 island, which may include several hosts and switches. To do so, the 3804 iFCP protocol MUST define confidentiality, authentication, 3805 integrity, and replay protection on a per-datagram basis. It also 3806 MUST define a scalable approach to key management. Conformant 3807 implementations of the iFCP protocol MAY use such definitions. 3809 11.2.3 Interoperability Requirements with Security Gateways 3811 Enterprise data center networks are considered mission-critical 3812 facilities that must be isolated and protected from all possible 3813 security threats. Such networks are usually protected by security 3814 gateways, which at a minimum provide a shield against denial of 3815 service attacks. The iFCP security architecture must be able to 3816 leverage the protective services of the existing security 3817 infrastructure, including firewall protection, NAT and NAPT 3818 services, and IPSec VPN services available on existing security 3819 gateways. 3821 11.2.4 Statically and Dynamically Assigned IP Addresses 3823 As iFCP gateways and switches are deployed within enterprise 3824 networks, it is expected that, like most routers and switches, 3825 gateway IP addresses will be statically assigned. Consequently, 3826 IKE and IPSec features focused on supporting DHCP and other dynamic 3827 IP address assignment capabilities for mobile hosts are not 3828 strictly required. Since the iFCP protocol cannot rule out the use 3829 of dynamically assigned IP addresses however, the security 3830 definitions for the iFCP protocol shall not exhibit any 3831 vulnerability in the case of dynamically assigned IP addresses 3832 (e.g., via DHCP [RFC2131]). 3834 11.2.5 Authentication Requirements 3836 iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by 3837 either or both peer gateways. Consequently, bi-directional 3838 authentication of peer gateways MUST be provided. 3840 Fibre Channel, operating system and user identities are transparent 3841 to the iFCP protocol. IKE and IPSec authentication used to protect 3842 iFCP traffic shall be based upon the IP addresses of the 3843 communicating peer gateways. 3845 iFCP gateways shall use Discovery Domain information obtained from 3846 the iSNS server [ISNS] to determine whether the initiating Fibre 3847 Channel N_PORT should be allowed access to the target N_PORT. 3848 N_PORT identities used in the Port Login (PLOGI) process shall be 3849 considered authenticated provided the PLOGI request is received 3850 from the remote gateway over a secure, IPSec-protected connection. 3852 iFCP Revision 8 January 2002 3854 There is no requirement that the identities used in authentication 3855 be kept confidential. 3857 11.2.6 Confidentiality Requirements 3859 iFCP traffic may traverse insecure public networks, and therefore 3860 implementations MUST have per-packet encryption capabilities to 3861 provide confidentiality. 3863 11.2.7 Rekeying Requirements 3865 Due to the high data transfer rates and the amount of data 3866 involved, an iFCP gateway implementation MUST support the 3867 capability to rekey each phase 2 security association in time 3868 intervals as often as every 25 seconds. The iFCP gateway MUST 3869 provide the capability for forward secrecy in the rekeying process. 3871 11.2.8 Usage Requirements 3873 It must be possible for compliant iFCP implementations to 3874 administratively disable any and all security mechanisms. It must 3875 also be possible to apply different security requirements to 3876 individual N_PORT login session. Implementations may elect to 3877 expose such fine level of control through a management interface or 3878 through interaction with the iSNS. 3880 11.2.9 iSNS Role 3882 iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways 3883 use iSNS for discovery services, and MAY use security policies 3884 configured in the iSNS database as the basis for algorithm 3885 negotiation in IKE. The iSNS specification defines mechanisms to 3886 secure communication between an iFCP gateway and iSNS server(s). 3887 Additionally, such specification indicates how elements of security 3888 policy concerning individual iFCP sessions can be retrieved from 3889 iSNS server(s). 3891 11.3 iFCP Security Design 3893 11.3.1 Enabling Technologies 3895 Applicable technology from IPsec and IKE is defined in the 3896 following suite of specifications: 3898 [RFC2401] Security Architecture for the Internet Protocol 3900 [RFC2402] IP Authentication Header 3902 [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH 3904 [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV 3906 iFCP Revision 8 January 2002 3908 [RFC2406] IP Encapsulating Security Payload 3910 [RFC2407] The Internet IP Security Domain of Interpretation for 3911 ISAKMP 3913 [RFC2408] Internet Security Association and Key Management 3914 Protocol (ISAKMP) 3916 [RFC2409] The Internet Key Exchange (IKE) 3918 [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC 3920 [RFC2451] The ESP CBC-Mode Cipher Algorithms 3922 [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains 3924 The implementation of IPsec and IKE is required according the 3925 following guidelines. 3927 Support for the IP Encapsulating Security Payload (ESP) [RFC2406] 3928 is MANDATORY to implement. As stated in [RFC2406], the following 3929 authentication algorithms MUST be implemented: 3931 a) HMAC with SHA1 [RFC2404] 3933 b) NULL authentication 3935 The Advanced Encryption Standard [AES] in CBC MAC mode with 3936 Extended Cipher Block Chaining [XCBC] SHOULD be implemented. 3938 The following encryption algorithms MUST be implemented: 3940 a) NULL encryption [RFC2410] 3942 b) 3DES in CBC mode [RFC2451] 3944 AES counter mode encryption [AESCTR] SHOULD be implemented. 3946 Implementation of DES in CBC mode [RFC2405] is OPTIONAL. It is 3947 recommended that DES in CBC mode SHOULD NOT be used due to its 3948 inherent weakness. It is in fact well known that DES is crackable 3949 with modest computation resources, and so is inappropriate for use 3950 in any iFCP deployment scenario requiring levels of security. 3952 A conformant iFCP protocol implementation MUST implement IPsec ESP 3953 [RFC2406] in tunnel mode [RFC2401]. If minimizing the size of IPsec 3954 headers is a concern, transport mode should be supported. It shall 3955 be noted that transport mode continues to have a MUST implement 3956 requirement in those host scenarios where [RFC2401] makes it a MUST 3958 iFCP Revision 8 January 2002 3960 (see Sections 3.3 and 4.1 of [RFC2401]). 3962 Regarding key management, iFCP implementations MUST support IKE 3963 [RFC2409] for peer authentication, negotiation of security 3964 associations, and key management, using the IPsec DOI. Manual 3965 keying MUST NOT be used since it does not provide the necessary 3966 keying support. According to [RFC2409], pre-shared secret key 3967 authentication is MANDATORY to implement, whereas certificate-based 3968 peer authentication using digital signatures MAY be implemented 3969 (see section 11.3.3 regarding the use of certificates). [RFC2409] 3970 defines the following requirement levels for IKE Modes: 3972 Phase-1 Main Mode MUST be implemented 3974 Phase-1 Aggressive Mode SHOULD be implemented 3976 Phase-2 Quick Mode MUST be implemented 3978 Phase-2 Quick Mode with key exchange payload MUST be implemented. 3980 Phase-1 Main Mode SHOULD NOT be used in conjunction with pre-shared 3981 keys, due to Main Mode�s vulnerability to men-in-the-middle- 3982 attackers when group pre-shared keys are used. iFCP therefore 3983 requires that Aggressive Mode MUST be implemented as a valid 3984 alternative to Main Mode. 3986 Peer authentication using the public key encryption methods 3987 outlined in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used. 3989 In all Phase 1 Modes, iFCP MUST use IP addresses as identities. 3991 The Phase 2 Quick Mode exchanges used to negotiate protection for 3992 the TCP connections used by iFCP MUST explicitly carry the Identity 3993 Payload fields (IDci and IDcr). The DOI [RFC2407] provides for 3994 several types of identification data. However, when used in 3995 conformant iFCP security implementations, each ID Payload MUST 3996 carry a single IP address and a single non-zero TCP port number, 3997 and MUST NOT use the IP Subnet or IP Address Range formats. This 3998 allows the Phase 2 security association to correspond to specific 3999 TCP and iFCP connections. 4001 11.3.2 Use of IKE and IPsec 4003 Each IP address supporting iFCP communication shall be capable of 4004 establishing one or more Phase-1 IKE Security Associations (SA) to 4005 other IP addresses configured as peer iFCP gateways, using the IP 4006 address as the identity. Such a security association may be 4007 established at a gateway�s initialization time, or may be deferred 4009 iFCP Revision 8 January 2002 4011 until the first TCP connection with security requirements is 4012 established. 4014 Unlike Phase-1 SAs, a Phase-2 SA maps to an individual TCP 4015 connection. It protects the setup process of the underlying TCP 4016 connection and all its subsequent TCP traffic. TCP connections 4017 protected by the phase 2 SA are either in the unbound state, or are 4018 bound to a specific N_PORT login session. The creation of an IKE 4019 Phase-2 SA may be triggered by a policy rule supplied through a 4020 management interface, or by N_PORT properties registered with the 4021 iSNS server. Similarly, the use of Key Exchange payload in Quick 4022 Mode for perfect forward secrecy may be dictated through a 4023 management interface or by N_PORT properties registered with the 4024 iSNS server. This specification allows multiple implementation 4025 strategies, in which the establishment of an IKE Phase-2 SA occurs 4026 at different times. Examples of implementation strategies include: 4028 a) The definition of a unique security policy for all TCP 4029 connections regardless of their bound or unbound state. Thus, an 4030 unbound TCP connection can be bound to an N_PORT login session 4031 without the need to incur a new IKE Phase-2 SA. 4033 b) Multiple security policies for unbound TCP connections and 4034 active N_PORT login sessions. In this case, an unbound TCP 4035 connection becomes bound to an N_PORT login session after 4036 establishing a new IKE Phase-2 SA matching the new security 4037 policy for that N_PORT session. 4039 c) The implementation does not support unbound connections. In this 4040 case, a new IKE Phase-2 SA and TCP connection must be started 4041 from scratch anytime a new N_PORT login session is created. 4043 If the implementation does use unbound TCP connections, then an IKE 4044 Phase-2 SA MUST protect each of such unbound connections. 4046 As expected, the successful establishment of a IKE Phase-2 SA 4047 results in the creation of two uni-directional IPsec SAs fully 4048 qualified by the tuple . 4050 Should a TCP connection be torn down (as opposed to joining a pool 4051 of unbound connections), the associated Phase-2 SA SHALL be 4052 terminated upon expiration of the TIME WAIT timeout value 4053 (according to [RFC793]). 4055 Upon receiving a Phase 1 delete message, an iFCP implementation 4056 SHALL tear down all the Phase 2 SAs spawned from that Phase 1 SA, 4057 followed by the Phase 1 SA itself. Upon receiving a Phase 2 delete 4058 message, iFCP implementations will behave according to the state of 4059 the TCP connection protected by the SA in question. If the TCP 4060 session was terminated (either via FINs or RSTs), then a Phase 2 4061 delete message SHALL terminate the IPsec SAs and any state formerly 4062 associated with that Phase 2 SA. If, however, the TCP session is 4064 iFCP Revision 8 January 2002 4066 maintained, then a Phase 2 delete message shall trigger a new Quick 4067 Mode exchange. To minimize the use of SA resources while the TCP 4068 connection is idle, the creation of the security association may be 4069 deferred until data is sent over the connection. 4071 11.3.3 Signatures and Certificate-based authentication 4073 Conformant iFCP implementations MAY support peer authentication via 4074 digital signatures and X.509 certificates. When X.509 certificate 4075 authentication is chosen within IKE, each iFCP gateway needs the 4076 certificate credentials of each peering iFCP gateway in order to 4077 establish a security association with that peer. 4079 Certificate credentials used by iFCP gateways MUST be those of the 4080 machine. Certificate credentials MAY be bound to the interface (IP 4081 Address) of the iFCP gateway used for the iFCP session, or the 4082 fabric WWN of the iFCP gateway itself. Since the value of a machine 4083 certificate is inversely proportional to the ease with which an 4084 attacker can obtain one under false pretenses, it is advisable that 4085 the machine certificate enrollment process be strictly controlled. 4086 For example, only administrators may have the ability to enroll a 4087 machine with a machine certificate. User certificates SHOULD NOT be 4088 used by iFCP gateways for establishment of SA's protecting iFCP 4089 sessions. 4091 If the gateway does not have the peer iFCP gateway's certificate 4092 credentials, then it can obtain them by 4094 a) Using the iSNS protocol to query for the peer gateway's 4095 certificate(s) stored in a trusted iSNS server, or 4097 b) Through use of the ISAKMP Certificate Request Payload (CRP) 4098 [RFC2408] to request the certificate(s) directly from the peer 4099 iFCP gateway. 4101 When certificate chains are long enough, then IKE exchanges using 4102 UDP as the underlying transport may yield IP fragments, which are 4103 known to work poorly across some intervening routers, firewalls, 4104 and NA(P)T boxes. As a result, the endpoints may be unable to 4105 establish an IPsec security association. The solutions to this 4106 problem are to send the end-entry machine certificate rather than 4107 the chain, to reduce the size of the certificate chain, to use IKE 4108 implementations over a reliable transport protocol (e.g., TCP) 4109 assisted by Path MTU discovery and code against black-holing as in 4110 [RFC2923], or to install network components that can properly 4111 handle fragments. 4113 IKE negotiators SHOULD check the pertinent Certificate Revocation 4114 List (CRL) [RFC2408] before accepting a certificate for use in 4115 IKE's authentication procedures. 4117 11.4 iSNS and iFCP Security 4118 iFCP Revision 8 January 2002 4120 iFCP is required to use iSNS for discovery and management services. 4121 Consequently, the security of the iSNS protocol has an impact on 4122 the security of iFCP gateways. In particular, the following 4123 threats exist: 4125 a) An attacker could alter iSNS protocol messages, so as to direct 4126 iFCP gateways to establish connections with rogue peer devices, 4127 or to weaken/eliminate IPSec protection for iFCP traffic. 4129 b) An attacker could masquerade as the real iSNS server using false 4130 iSNS heartbeat messages. This could cause iFCP gateways to use 4131 rogue iSNS servers. 4133 c) An attacker could gain knowledge about iFCP gateways by snooping 4134 iSNS protocol messages. Such information could aid an attacker 4135 in mounting a direct attack on iFCP gateways, such as a denial- 4136 of-service attack or outright physical theft. 4138 To address these threats, the following capabilities are required: 4140 a) Unicast iSNS protocol messages need to have both confidentiality 4141 and authentication support. 4143 b) Multicast iSNS protocol messages such as the iSNS heartbeat 4144 message need to have authentication support. 4146 There is no requirement that the communicating identities in iSNS 4147 protocol messages be kept confidential. Specifically, the identity 4148 and location of the iSNS server shall not be considered 4149 confidential. 4151 However, in order to protect against an attacker masquerading as 4152 the real iSNS server, the iSNS server MUST have the capability to 4153 allow client gateways to authenticate broadcast or multicast 4154 messages such as the iSNS heartbeat. The iSNS authentication block 4155 (which is identical in format to the SLP authentication block) may 4156 be used for this purpose. Note that the authentication block is 4157 used only for iSNS broadcast or multicast messages, and SHOULD NOT 4158 be used in unicast iSNS messages. 4160 For protecting unicast iSNS protocol messages, iSNS servers MUST 4161 support the ESP protocol in tunnel mode for iFCP client gateways. 4163 11.5 Use of iSNS to Distribute Security Policy 4165 Once communication between iFCP gateways and the iSNS server have 4166 been secured through use of IPSec, the iFCP gateways have the 4167 capability to discover the security settings that they need to use 4168 to protect iFCP traffic. This provides a potential scaling 4169 advantage over device-by-device configuration of individual 4170 security policies for each iFCP gateway. 4172 iFCP Revision 8 January 2002 4174 The iSNS server stores security settings for each iFCP gateway. 4175 These security settings include use or non-use of IPSec, IKE, Main 4176 Mode, Aggressive Mode, PFS, Pre-shared Key, and certificates. These 4177 settings can be retrieved by peer iFCP gateways, who can then take 4178 the appropriate action. For example, IKE may not be enabled for a 4179 particular iFCP gateway. If a peer gateway can learn of this in 4180 advance by consulting the iSNS server, it will not need to waste 4181 time and resources attempting to initiate an IKE session with that 4182 iFCP gateway. 4184 Additionally, the iSNS server can store policies that are used for 4185 ISAKMP phase 1 and phase 2 negotiations between iFCP gateways. The 4186 ISAKMP payload format includes a series of one or more proposals 4187 that the iFCP gateway will use when negotiating the appropriate 4188 IPSec policy to use to protect iFCP traffic. 4190 11.6 Minimal Security Policy for an iFCP gateway 4192 An iFCP implementation MAY be able to administratively disable 4193 security mechanisms for individual N_PORT login sessions. This 4194 implies that IKE and IPsec security associations may not be 4195 established for one or more of such sessions. A configuration of 4196 this type may be accomplished through a management interface or 4197 through attributes set in the iSNS server. 4199 For most IP networks, it is inappropriate to assume physical 4200 security, administrative security, and correct configuration of the 4201 network and all attached nodes (a physically isolated network in a 4202 test lab may be an exception). Therefore, authentication SHOULD be 4203 used in order to provide a minimal assurance that connections have 4204 initially been opened with the intended counterpart. The minimal 4205 iFCP security policy thus only states that an iFCP gateway SHOULD 4206 authenticate its iSNS server(s) as described in [ISNS]. 4208 12. Quality of Service Considerations 4210 12.1 Minimal requirements 4212 Conforming iFCP protocol implementations SHALL correctly 4213 communicate gateway-to-gateway even across one or more intervening 4214 best-effort IP regions. The timings with which such gateway-to 4215 gateway communication is performed, however, will greatly depend 4216 upon BER, packet losses, latency, and jitter experienced throughout 4217 the best-effort IP regions. The higher these parameters, the higher 4218 will be the gap measured between iFCP observed behaviors and 4219 baseline iFCP behaviors (i.e., as produced by two iFCP gateways 4220 directly connected to one another). 4222 12.2 High-assurance 4224 It is expected that many iFCP deployments will benefit from a high 4225 degree of assurance regarding the behavior of intervening IP 4227 iFCP Revision 8 January 2002 4229 regions, with resulting high-assurance on the overall end-to-end 4230 path, as directly experienced by Fibre Channel applications. Such 4231 assurance on the IP behaviors stems from the intervening IP regions 4232 supporting standard Quality-of-Service (QoS) techniques, fully 4233 complementary to iFCP, such as: 4235 a) Congestion avoidance by over-provisioning of the network 4237 b) Integrated Services [RFC1633] QoS 4239 c) Differentiated Services [RFC2475] QoS 4241 d) Multi-Protocol Label Switching [RFC3031]. 4243 One may load an MPLS forwarding equivalence class (FEC) with QoS 4244 class significance, in addition to other considerations such as 4245 protection and diversity for the given path. The complementarity 4246 and compatibility of MPLS with Differentiated Services is 4247 explored in [MPSLDS], wherein the PHB bits are copied to the EXP 4248 bits of the MPLS shim header. 4250 In the most general definition, two iFCP gateways are separated by 4251 one or more independently managed IP regions, some of which 4252 implement some of the QoS solutions mentioned above. A QoS-capable 4253 IP region supports the negotiation and establishment of a service 4254 contract specifying the forwarding service through the region. Such 4255 contract and its negotiation rules are outside the scope of this 4256 document. In the case of IP regions with DiffServ QoS, the reader 4257 should refer to Service Level Specifications (SLS) and Traffic 4258 Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other 4259 aspects of a service contract are expected to be non-technical and 4260 thus outside of the IETF scope. 4262 Due to the fact that Fibre Channel Class 2 and Class 3 do not 4263 currently support fractional bandwidth guarantees, and that iFCP is 4264 committed to supporting Fibre Channel semantics, it is impossible 4265 for an iFCP gateway to autonomously infer bandwidth requirements 4266 from streaming Fibre Channel traffic. Rather, the requirements on 4267 bandwidth or other network parameters need to be administratively 4268 set into an iFCP gateway, or into the entity that will actually 4269 negotiate the forwarding service on the gateway's behalf. Depending 4270 on the QoS techniques available, the stipulation of a forwarding 4271 service may require interaction with network ancillary functions 4272 such admission control and bandwidth brokers (via RSVP or other 4273 signalling protocols that an IP region may accept). 4275 The administrator of a iFCP gateway may negotiate a forwarding 4276 service with IP region(s) for one, several, or all of an iFCP 4277 gateway's TCP sessions used by an iFCP gateway. Alternately, this 4278 responsibility may be delegated to a node downstream. Since one TCP 4279 connection is dedicated to each N_PORT login session , the traffic 4281 iFCP Revision 8 January 2002 4283 in an individual N_PORT to N_PORT session can be singled out by 4284 iFCP-unaware network equipment as well. 4286 To render the best emulation of Fibre Channel possible over IP, it 4287 is anticipated that typical forwarding services will specify a 4288 fixed amount of bandwidth, null losses, and, to a lesser degree of 4289 relevance, low latency, and low jitter. For example, an IP region 4290 using DiffServ QoS may support SLSs of this nature by applying EF 4291 DSCPs to the iFCP traffic. 4293 13. Author's Addresses 4295 Charles Monia Franco Travostino 4296 Rod Mullendore Director, Content 4297 Josh Tseng Internetworking Lab, 4298 Nortel Networks 4299 Nishan Systems 3 Federal Street 4300 3850 North First Street Billerica, MA 01821 4301 San Jose, CA 95134 Phone: 978-288-7708 4302 Phone: 408-519-3986 Email: 4303 Email: travos@nortelnetworks.com 4304 cmonia@nishansystems.com 4306 iFCP Revision 8 January 2002 4308 David Robinson Wayland Jeong 4309 Sun Microsystems Troika Networks 4310 Senior Staff Engineer Vice President, Hardware 4311 M/S UNWK16-301 Engineering 4312 901 San Antonio Road 2829 Townsgate Road Suite 4313 Palo Alto, CA 94303-4900 200 4314 Phone: 510-936-2337 Westlake Village, CA 91361 4315 Email: Phone: 805-370-2614 4316 David.Robinson@sun.com Email: 4317 wayland@troikanetworks.com 4319 Rory Bolt Paul Rutherford 4320 Quantum/ATL ADIC 4321 Director, System Design Vice President, Technology & 4322 101 Innovation Drive Software 4323 Irvine, CA 92612 1143 Willows Road N.E. 4324 Phone: 949-856-7760 P.O. Box 97057 4325 Email: rbolt@atlp.com Redmond, WA 98073-9757 4326 Phone: 425-881-8004 4327 Email: 4328 paul.rutherford@adic.com 4330 Mark Edwards 4331 Senior Systems Architect 4332 Eurologic Development, Ltd. 4333 4th Floor, Howard House 4334 Queens Ave, UK. BS8 1SD 4335 Phone: +44 (0)117 930 9600 4336 Email: 4337 medwards@eurologic.com 4339 iFCP Revision 8 January 2002 4341 14. References 4343 14.1 Normative 4345 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 4346 3", BCP 9, RFC 2026, October 1996. 4348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4349 Requirement Levels", BCP 14, RFC 2119, March 1997 4351 [FC-FS] dpANS X3.XXX-200X, "Fibre Channel Framing and Signaling 4352 Interface", Revision 1.5, NCITS Project 1331-D, February 4353 2001 4355 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- 4356 SW2)", revision 5.2, NCITS Project 1305-D, May 2001 4358 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- 4359 GS3)", revision 7.01, NCITS Project 1356-D, November 2000 4361 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 4362 September, 1981 4364 [ENCAP] Weber, et-al., "FC Frame Encapsulation", draft-ietf-ips- 4365 fcencapsulation-01.txt, May 2001 4367 [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service", 4368 draft-ietf-ips-04.txt, July 2001 4370 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 4371 1981 4373 [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture 4374 for the Internet Protocol", November 1998 4376 [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication 4377 Header", November 1998 4379 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4380 ESP and AH", RFC 2404, November 1998 4382 [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security 4383 Protocol", November 1998 4385 [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of 4386 Interpretation for ISAKMP", November 1998 4388 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 4389 RFC 2408, "Internet Security Association and Key Management 4390 Protocol (ISAKMP)" November 1998 4392 iFCP Revision 8 January 2002 4394 [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key 4395 Exchange (IKE)", November 1998 4397 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4398 Its use with IPSEC", RFC 2410, November 1998 4400 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4401 Algorithms", RFC 2451, November 1998 4403 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4404 ESP and AH", RFC 2404, November 1998 4406 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4407 Its use with IPSEC", RFC 2410, November 1998 4409 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4410 Algorithms", RFC 2451, November 1998 4412 14.2 Non-Normative 4414 [KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", 4415 Northwest Learning Associates Inc., 2000, ISBN 0-931836-84- 4416 0 4418 [KEMAbLP] Kembel, R., "The Fibre Channel Consultant, Arbitrated 4419 Loop", Robert W. Kembel, Northwest Learning Associates, 4420 2000, ISBN 0-931836-84-0 4422 [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 4423 2)", revision 7.0, NCITS Project 1133D, April 1999 4425 [RFC896] Nagel, J., "Congestion Control in IP/TCP Networks", RFC 4426 896, January 1984 4428 [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre 4429 Channel", June 1999 4431 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 4432 2131, March 1997 4434 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4435 Algorithm With Explicit IV" RFC 2405, November 1998 4437 [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol 4438 (SNTP)" Version 4, October 1996 4440 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 4441 NAT Domains", RFC 2709, October 1999 4443 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 4444 2923, September 2000 4446 iFCP Revision 8 January 2002 4448 [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated 4449 Services in the Internet Architecture: an Overview", RFC 4450 1633, June 1994 4452 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4453 and W. Weiss, "An Architecture for Differentiated 4454 Services", RFC 2475, December 1998 4456 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- 4457 FLA)", revision 2.7, NCITS Project 1235-D, August 1997 4459 [RFC1122] Braden, S., "Requirements for Internet Hosts -- 4460 Communication Layers", RFC 1122, October 1989 4462 [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High 4463 Performance", RFC 1323, May, 1992 4465 [AES] FIPS Publication XXX, "Advanced Encyption Standard (AES)", 4466 Draft, 2001, Available from 4467 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf 4469 [XCBC] Black, J., Rogaway, P., "A Suggestion for Handling Arbitrary 4470 Length Messages with the CBC MAC". Available from 4471 http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc- 4472 mac/xcbc-mac-spec.pdf 4474 [AESCTR] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-Mode 4475 Encryption", 2001. Available from 4476 http://csrc.nist.gov/encryption/modes/proposedmodes/ctr/ctr 4477 -spec.pdf 4479 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4480 Algorithm With Explicit IV" RFC 2405, November 1998 4482 [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi- 4483 Protocol Label Switching Architecture", RFC 3031, January 4484 2001 4486 [MPSLDS] F. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. 4487 Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 4488 Differentiated Services", draft-ietf-mpls-diff-ext-09.txt, 4489 April 2001. 4491 [DIFTERM] Grossman, D., "New Terminology and Clarifications for 4492 Diffserv", draft-ietf-diffserv-new-terms-07.txt, December 4493 2001 4495 iFCP Revision 8 January 2002 4497 Appendix A 4499 A. iFCP Support for Fibre Channel Link Services 4501 For reference purposes, this appendix enumerates all the Fibre 4502 Channel link services and the manner in which each shall be 4503 processed by an iFCP implementation. The iFCP processing policies 4504 are defined in section 8. 4506 In the following sections, the name of a link service specific to a 4507 particular FC-4 protocol is prefaced by a mnemonic identifying the 4508 protocol. 4510 A.1 Basic Link Services 4512 The basic link services are shown in the following table. 4514 Basic Link Services 4516 Name Description iFCP Policy 4517 ---- ----------- ---------- 4519 ABTS Abort Sequence Transparent 4520 BA_ACC Basic Accept Transparent 4521 BA_RJT Basic Reject Transparent 4522 NOP No Operation Transparent 4523 PRMT Preempted Rejected 4524 (Applies to 4525 Class 1 only) 4526 RMC Remove Connection Rejected 4527 (Applies to 4528 Class 1 only) 4530 A.2 Link Services Processed Transparently 4532 The following link service requests and responses MUST be processed 4533 transparently as defined in section 8. 4535 Link Services Processed Transparently 4537 Name Description 4538 ---- ----------- 4540 ACC Accept 4541 ADVC Advise Credit 4542 CSR Clock Synchronization Request 4543 CSU Clock Synchronization Update 4544 ECHO Echo 4545 ESTC Estimate Credit 4546 ESTS Establish Streaming 4547 FACT Fabric Activate Alias_ID 4549 iFCP Revision 8 January 2002 4551 FAN Fabric Address Notification 4552 FCP_RJT FCP FC-4 Link Service Reject 4553 FCP SRR FCP Sequence Retransmission Request 4554 FDACT Fabric Deactivate Alias_ID 4555 FDISC Discover F_Port Service Parameters 4556 FLOGI F_Port Login 4557 GAID Get Alias_ID 4558 LCLM Login Control List Management 4559 LINIT Loop Initialize 4560 LIRR Link Incident Record Registration 4561 LPC Loop Port Control 4562 LS_RJT Link Service Reject 4563 LSTS Loop Status 4564 NACT N_Port Activate Alias_ID 4565 NDACT N_Port Deactivate Alias_ID 4566 PDISC Discover N_Port Service Parameters 4567 PRLI Process Login 4568 PRLO Process Logout 4569 QoSR Quality of Service Request 4570 RCS Read Connection Status 4571 RLIR Registered Link Incident Report 4572 RNC Report Node Capability 4573 RNFT Report Node FC-4 Types 4574 RNID Request Node Identification Data 4575 RPL Read Port List 4576 RPS Read Port Status Block 4577 RPSC Report Port Speed Capabilities 4578 RSCN Registered State Change Notification 4579 RTV Read Timeout Value 4580 RVCS Read Virtual Circuit Status 4581 SBRP Set Bit-error Reporting Parameters 4582 SCL Scan Remote Loop 4583 SCN State Change Notification 4584 SCR State Change Registration 4585 TEST Test 4586 TPLS Test Process Login State 4588 A.3 iFCP-Processed Link Services 4590 The following extended and FC-4 link services are processed by the 4591 iFCP implementation as described in the referenced section listed 4592 in the table. 4594 Special Link Services 4596 Name Description Section 4597 ---- ----------- ------- 4599 ABTX Abort Exchange 8.3.1.1 4600 ADISC Discover Address 8.3.1.2 4601 ADISC ACC Discover Address Accept 8.3.1.3 4603 iFCP Revision 8 January 2002 4605 FARP-REPLY Fibre Channel Address 8.3.1.4 4606 Resolution Protocol Reply 4607 FARP-REQ Fibre Channel Address 8.3.1.5 4608 Resolution Protocol Request 4609 LOGO N_PORT Logout 8.3.1.6 4610 PLOGI Port Login 8.3.1.7 4611 FCP REC FCP Read Exchange Concise 8.3.2.1.1 4612 FCP REC ACC FCP Read Exchange Concise 8.3.2.1.2 4613 Accept 4614 RES Read Exchange Status Block 8.3.1.8 4615 RES ACC Read Exchange Status Block 8.3.1.9 4616 Accept 4617 RLS Read Link Error Status Block 8.3.1.10 4618 RRQ Reinstate Recovery Qualifier 8.3.1.12 4619 RSI Request Sequence Initiative 8.3.1.13 4620 RSS Read Sequence Status Block 8.3.1.11 4621 TPRLO Third Party Process Logout 8.3.1.14 4622 TPRLO ACC Third Party Process Logout 8.3.1.15 4623 Accept 4625 iFCP Revision 8 January 2002 4626 iFCP Revision 8 January 2002 4628 Full Copyright Statement 4630 "Copyright (C) The Internet Society, January 2002. All Rights 4631 Reserved. This document and translations of it may be copied and 4632 furnished to others, and derivative works that comment on or 4633 otherwise explain it or assist in its implmentation may be 4634 prepared, copied, published and distributed, in whole or in part, 4635 without restriction of any kind, provided that the above copyright 4636 notice and this paragraph are included on all such copies and 4637 derivative works. However, this document itself may not be modified 4638 in any way, such as by removing the copyright notice or references 4639 to the Internet Society or other Internet organizations, except as 4640 needed for the purpose of developing Internet standards in which 4641 case the procedures for copyrights defined in the Internet 4642 Standards process must be followed, or as required to translate it 4643 into languages other than English. 4645 The limited permissions granted above are perpetual and will not be 4646 revoked by the Internet Society or its successors or assigns. 4648 This document and the information contained herein is provided on 4649 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4650 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4651 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4652 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4655 iFCP Revision 8 January 2002 4657 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 4658 1981