idnits 2.17.1 draft-ietf-ips-ifcp-10.txt: -(270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(321): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(444): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(600): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(603): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(608): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(633): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(640): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(647): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(654): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(658): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(786): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(799): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(804): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1143): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1149): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2649): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3412): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4103): 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 66 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. ** There are 1117 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([SECIPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 348 has weird spacing: '...emented by an...' == Line 1394 has weird spacing: '...sulates and d...' == Line 1623 has weird spacing: '...Request expl...' == Line 1640 has weird spacing: '...Request expl...' == Line 2252 has weird spacing: '...rt Name iFCP ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2002) is 8100 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: '0x0' is mentioned on line 2192, but not defined == Missing Reference: '0x1' is mentioned on line 2194, but not defined -- Looks like a reference, but probably isn't: '0' on line 2194 == Missing Reference: '0x00' is mentioned on line 2196, but not defined == Missing Reference: '0x0000' is mentioned on line 2199, but not defined == Missing Reference: '0x01' is mentioned on line 2585, but not defined == Missing Reference: 'FC-VI' is mentioned on line 2943, but not defined == Missing Reference: 'FCS' is mentioned on line 3135, but not defined == Missing Reference: 'AESCBC' is mentioned on line 4065, but not defined == Missing Reference: 'AESCTR2' is mentioned on line 4069, but not defined == Unused Reference: 'RFC791' is defined on line 4452, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 4511, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-ips-fcencapsulation-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-GS3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-SW2' -- 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'SECIPS' == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-07 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2030 (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2625 (Obsoleted by RFC 4338) -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) Summary: 11 errors (**), 0 flaws (~~), 21 warnings (==), 13 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 August 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 Mark Edwards 20 Eurologic 22 February 2002 24 iFCP - A Protocol for Internet Fibre Channel Storage Networking 26 Status of this Memo 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC 2026 [RFC2026]. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. Internet-Drafts are draft documents valid for a maximum of 35 six months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet-Drafts 37 as reference material or to cite them other than as "work in 38 progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Comments 48 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 49 or to the author(s). 51 iFCP Revision 10 February 2002 53 Status of this Memo...................................................1 54 Comments..............................................................1 55 Abstract..............................................................5 56 Acknowledgements......................................................5 57 Change Log............................................................5 58 1. About This Document..........................................5 59 1.1 Conventions used in this document............................5 60 1.1.1 Data Structures Internal to an Implementation................6 61 1.2 Purpose of this document.....................................6 62 2. iFCP Introduction............................................6 63 2.1 Definitions..................................................6 64 3. Fibre Channel Communication Concepts.........................9 65 3.1 The Fibre Channel Network....................................9 66 3.2 Fabric Topologies...........................................10 67 3.2.1 Switched Fibre Channel Fabrics..............................11 68 3.2.2 Mixed Fibre Channel Fabric..................................12 69 3.3 Fibre Channel Layers and Link Services......................13 70 3.3.1 Fabric-Supplied Link Services...............................14 71 3.4 Fibre Channel Nodes.........................................14 72 3.5 Fibre Channel Device Discovery..............................15 73 3.6 Fibre Channel Information Elements..........................15 74 3.7 Fibre Channel Frame Format..................................16 75 3.7.1 N_PORT Address Model........................................16 76 3.8 Fibre Channel Transport Services............................17 77 3.9 Login Processes.............................................18 78 4. The iFCP Network Model......................................18 79 4.1 Fibre Channel Fabric Topologies Supported by iFCP...........20 80 4.2 iFCP Transport Services.....................................20 81 4.2.1 Fibre Channel Transport Services Supported by iFCP..........20 82 4.3 iFCP Device Discovery and Configuration Management..........21 83 4.4 iFCP Fabric Properties......................................21 84 4.4.1 Address Transparency........................................21 85 4.4.2 Configuration Scalability...................................22 86 4.4.3 Fault Tolerance.............................................22 87 4.5 The iFCP N_PORT Address Model...............................23 88 4.6 Operation in Address Transparent Mode.......................24 89 4.6.1 Transparent Mode Domain I/D Management......................25 90 4.6.2 Incompatibility with Address Translation Mode...............25 91 4.7 Operation in Address Translation Mode.......................25 92 4.7.1 Outbound Frame Address Translation..........................26 93 4.7.2 Inbound Frame Address Translation...........................27 94 4.7.3 Incompatibility with Address Transparent Mode...............28 95 5. iFCP Protocol...............................................28 96 5.1 Overview....................................................28 97 5.1.1 iFCP Transport Services.....................................28 98 5.1.2 iFCP Support for Link Services..............................29 99 5.2 TCP Stream Transport of iFCP Frames.........................30 100 5.2.1 iFCP Session Model..........................................30 101 5.2.2 iFCP Session Management.....................................30 102 5.2.3 Terminating an iFCP Session.................................37 103 5.3 IANA Considerations.........................................38 104 iFCP Revision 10 February 2002 106 5.4 Encapsulation of Fibre Channel Frames.......................38 107 5.4.1 Encapsulation Header Format.................................39 108 5.4.2 SOF and EOF Delimiter Fields................................42 109 5.4.3 Frame Encapsulation.........................................43 110 5.4.4 Frame De-encapsulation......................................43 111 6. TCP Session Control Messages................................44 112 6.1 Connection Bind (CBIND).....................................46 113 6.2 Unbind Connection (UNBIND)..................................49 114 6.3 LTEST -- Test Connection Liveness...........................51 115 7. Fibre Channel Link Services.................................52 116 7.1 Special Link Service Messages...............................53 117 7.2 Link Services Requiring Payload Address Translation.........55 118 7.3 Fibre Channel Link Services Processed by iFCP...............57 119 7.3.1 Special Extended Link Services..............................58 120 7.3.2 Special FC-4 Link Services..................................71 121 7.4 FLOGI Service Parameters Supported by an iFCP Gateway.......73 122 8. iFCP Error Detection........................................75 123 8.1 Overview....................................................75 124 8.2 Stale Frame Prevention......................................75 125 8.2.1 Enforcing R_A_TOV Limits....................................76 126 9. Fabric Services Supported by an iFCP implementation.........78 127 9.1 F_PORT Server...............................................78 128 9.2 Fabric Controller...........................................78 129 9.3 Directory/Name Server.......................................78 130 9.4 Broadcast Server............................................79 131 9.4.1 Establishing the Broadcast Configuration....................79 132 9.4.2 Broadcast Session Management................................80 133 10. iFCP Security...............................................81 134 10.1 Overview....................................................81 135 10.2 iFCP Security Threats and Scope.............................81 136 10.2.1 Context.....................................................81 137 10.2.2 Security Threats............................................81 138 10.2.3 Interoperability with Security Gateways.....................82 139 10.2.4 Authentication..............................................82 140 10.2.5 Confidentiality.............................................82 141 10.2.6 Rekeying....................................................82 142 10.2.7 Authorization...............................................83 143 10.2.8 Policy control..............................................83 144 10.2.9 iSNS Role...................................................83 145 10.3 iFCP Security Design........................................83 146 10.3.1 Enabling Technologies.......................................83 147 10.3.2 Use of IKE and IPsec........................................85 148 10.3.3 Signatures and Certificate-based Authentication.............86 149 10.4 iSNS and iFCP Security......................................87 150 10.5 Use of iSNS to Distribute Security Policy...................87 151 10.6 Minimal Security Policy for an iFCP gateway.................87 152 11. Quality of Service Considerations...........................88 153 11.1 Minimal requirements........................................88 154 11.2 High-assurance..............................................88 155 12. Author's Addresses..........................................89 156 13. Normative References........................................90 157 14. Non-Normative References....................................91 158 iFCP Revision 10 February 2002 160 A. iFCP Support for Fibre Channel Link Services................94 161 A.1 Basic Link Services.........................................94 162 A.2 Link Services Processed Transparently.......................94 163 A.3 Special Link Services.......................................95 164 Full Copyright Statement.............................................97 165 iFCP Revision 10 February 2002 167 Abstract 169 This document specifies an architecture and gateway-to-gateway 170 protocol for the implementation of fibre channel fabric 171 functionality over an IP network. This functionality is provided 172 through TCP protocols for fibre channel frame transport and the 173 distributed fabric services specified by the fibre channel 174 standards. The architecture enables internetworking of fibre 175 channel devices through gateway-accessed regions having the fault 176 isolation properties of autonomous systems and the scalability of 177 the IP network. 179 Acknowledgements 181 The authors are indebted to those who contributed material or who 182 took the time to carefully review and critique this specification 183 including David Black (EMC), Victor Firoiu (Nortel), Robert Peglar 184 (XIOtech), Elizabeth Rodriguez, Naoke Watanabe (HDS) and members of 185 the IPS working group. For review of the iFCP security policy, the 186 authors are further indebted to the authors of the IPS security 187 draft {SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran 188 (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan 189 (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), 190 and Jesse Walker (Intel). 192 Change Log 194 Revision 9 to Revision 10 196 - Changed 'N_PORT login session' to 'iFCP session' throughout. 197 - To better articulate the rules for frame processing, address 198 translation and iFCP session management, added the iFCP session 199 descriptor and remote N_PORT descriptor as gateway internal data 200 structures. Rewrote sections on Address modes (4.5, 4.6, 4.7) 201 frame encapsulation and de-encapsulation (5.4 and 5.4.4) and iFCP 202 session management (5.2.2). 203 - Revised section 10 (Security) to align with latest draft of 204 [SECIPS]. 205 - Modified the rules for iFCP frame encapsulation and de- 206 encapsulation (sections 5.4 and 5.4.4) to discard frames with 207 invalid N_PORT addresses. 208 - Modified PLOGI (section 7.3.1.7) to reject a PLOGI addressed to an 209 invalid N_PORT address. 211 1. About This Document 213 1.1 Conventions used in this document 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 218 iFCP Revision 10 February 2002 220 this document are to be interpreted as described in RFC-2119 221 [RFC2119]. 223 All frame formats are in big endian network byte order. 225 1.1.1 Data Structures Internal to an Implementation 227 To facilitate the specification of required behavior, this document 228 may define and refer to internal data structures within an iFCP 229 implementation. Such structures are intended for explanatory 230 purposes only and need not be instantiated within an implementation 231 as described in this specification. 233 1.2 Purpose of this document 235 This is a standards-track document, which specifies a protocol for 236 the implementation of fibre channel transport services on a TCP/IP 237 network. Some portions of this document contain material from 238 standards controlled by NCITS T10 and T11. This material is 239 included here for informational purposes only. The authoritative 240 information is given in the appropriate NCITS standards document. 242 The authoritative portions of this document specify the mapping of 243 standards-compliant fibre channel protocol implementations to 244 TCP/IP. This mapping includes sections of this document which 245 describe the "iFCP Protocol" (see section 5). 247 2. iFCP Introduction 249 iFCP is a gateway-to-gateway protocol, which provides fibre channel 250 fabric services to fibre channel devices over a TCP/IP network. 251 iFCP uses TCP to provide congestion control, error detection and 252 recovery. iFCP's primary objective is to allow interconnection and 253 networking of existing fibre channel devices at wire speeds over an 254 IP network. 256 The protocol and method of frame address translation described in 257 this document permit the attachment of fibre channel storage 258 devices to an IP-based fabric by means of transparent gateways. 260 The protocol achieves this transparency by allowing normal fibre 261 channel frame traffic to pass through the gateway directly, with 262 provisions, where necessary, for intercepting and emulating the 263 fabric services required by a fibre channel device. 265 2.1 Definitions 267 Terms needed to clarify the concepts presented in this document are 268 presented here. 270 Address-translation mode � A mode of gateway operation in which the 271 scope of N_PORT fabric addresses for locally attached 273 iFCP Revision 10 February 2002 275 devices are local to the iFCP gateway region in which the 276 devices reside. 278 Address-transparent mode � A mode of gateway operation in which the 279 scope of N_PORT fabric addresses for all fibre channel 280 devices are unique to the bounded iFCP fabric to which the 281 gateway belongs. 283 Bounded iFCP Fabric � The union of two or more gateway regions 284 configured to interoperate together in address-transparent 285 mode. 287 DOMAIN_ID � The value contained in the high-order byte of a 24-bit 288 N_PORT fibre channel address. 290 F_PORT - The interface used by an N_PORT to access fibre channel 291 switched fabric functionality. 293 Fabric - The components of a network that provide the transport 294 services defined in [FC-FS]. A fabric may be implemented in 295 the IP framework by means of the architecture and protocols 296 discussed in this document. 298 Fabric Port - The interface through which an N_PORT accesses a 299 fibre channel fabric. The type of fabric port depends on 300 the fibre channel fabric topology. In this specification, 301 all fabric port interfaces are considered to be 302 functionally equivalent. 304 FC-2 - The fibre channel transport services layer described in [FC- 305 FS]. 307 FC-4 - The fibre channel application layer. This layer is 308 functionally equivalent to the TCP/IP application layer. 310 Fibre Channel Device - An entity implementing the functionality 311 accessed through an FC-4 application protocol. 313 Fibre Channel Network - A native fibre channel fabric and all 314 attached fibre channel nodes. 316 Fibre Channel Node - A collection of one or more N_PORTs controlled 317 by a level above the FC-2 layer. A node is attached to a 318 fibre channel fabric by means of the N_PORT interface 319 described in [FC-FS]. 321 Gateway Region � The portion of an iFCP fabric accessed through an 322 iFCP gateway. Fibre channel devices in the region consist 323 of all fibre channel devices locally attached to the 324 gateway. 326 iFCP Revision 10 February 2002 328 iFCP - The protocol discussed in this document. 330 iFCP Frame - A fibre channel frame encapsulated in accordance with 331 the Common Encapsulation Specification [ENCAP] and this 332 specification. 334 iFCP Portal - An entity representing the point at which a logical 335 or physical iFCP device is attached to the IP network. The 336 network address of the iFCP portal consists of the IP 337 address and TCP port number to which a request is sent when 338 creating the TCP connection for an iFCP session (see 339 section 5.2.1). 341 iFCP Session - An association created when an N_PORT sends a PLOGI 342 request to a remotely attached N_PORT. It is comprised of 343 the N_PORTs and TCP connection that carries traffic between 344 them. 346 iSNS - The server functionality and IP protocol that provides 347 storage name services in an iFCP network. Fibre channel 348 name services are implemented by an iSNS name server as 349 described in [ISNS]. 351 Locally Attached Device - With respect to a gateway, a fibre 352 channel device accessed through the fibre channel fabric to 353 which the gateway is attached. 355 Logical iFCP Device - The abstraction representing a single fibre 356 channel device as it appears on an iFCP network. 358 N_PORT - An iFCP or fibre channel entity representing the interface 359 to fibre channel device functionality. This interface 360 implements the fibre channel N_PORT semantics specified in 361 [FC-FS]. Fibre channel defines several variants of this 362 interface that depend on the fibre channel fabric topology. 363 As used in this document, the term applies equally to all 364 variants. 366 N_PORT Alias -- The N_PORT address assigned by a gateway to 367 represent a remote N_PORT accessed via the iFCP protocol. 368 When routing frame traffic in address translation mode, the 369 gateway automatically converts N_PORT aliases to N_PORT 370 network addresses and vice versa. 372 N_PORT fabric address - The address of an N_PORT within the fibre 373 channel fabric. 375 N_PORT ID -- The address of a locally attached N_PORT within a 376 gateway region. N_PORT IDs are assigned in accordance with 377 the fibre channel rules for address assignment specified in 378 [FC-FS]. 380 iFCP Revision 10 February 2002 382 N_PORT Network Address - The address of an N_PORT in the iFCP 383 fabric. This address consists of the IP address and TCP 384 port number of the iFCP Portal and the N_PORT ID of the 385 locally attached fibre channel device. 387 Port Login (PLOGI) - The fibre channel Extended Link Service (ELS) 388 that establishes an iFCP session through the exchange of 389 identification and operation parameters between an 390 originating N_PORT and a responding N_PORT. 392 Remotely Attached Device - With respect to a gateway, a fibre 393 channel device accessed from the gateway by means of the 394 iFCP protocol. 396 Unbounded iFCP Fabric - The union of two or more gateway regions 397 configured to interoperate together in address-translation 398 mode. 400 3. Fibre Channel Communication Concepts 402 Fibre channel is a frame-based, serial technology designed for 403 peer-to-peer communication between devices at gigabit speeds and 404 with low overhead and latency. 406 This section contains a discussion of the fibre channel concepts 407 that form the basis for the iFCP network architecture and protocol 408 described in this document. Readers familiar with this material may 409 skip to section 4. 411 Material presented in this section is drawn from the following T11 412 specifications: 414 -- The Fibre Channel Framing and Signaling Interface, [FC-FS] 416 -- Fibre Channel Switch Fabric -2, [FC-SW2] 418 -- Fibre Channel Generic Services, [FC-GS3] 420 -- Fibre Channel Fabric Loop Attachment, [FC-FLA] 422 The reader will find an in-depth treatment of the technology in 423 [KEMCMP] and [KEMALP]. 425 3.1 The Fibre Channel Network 427 The fundamental entity in fibre channel is the fibre channel 428 network. Unlike a layered network architecture, a fibre channel 429 network is largely specified by functional elements and the 430 interfaces between them. As shown in Figure 1, these consist, in 431 part, of the following: 433 iFCP Revision 10 February 2002 435 a) N_PORTs -- The end points for fibre channel traffic. In the FC 436 standards, N_PORT interfaces have several variants, depending on 437 the topology of the fabric to which they are attached. As used 438 in this specification, the term applies to any one of the 439 variants. 441 b) FC Devices � The fibre channel devices to which the N_PORTs 442 provide access. 444 c) Fabric Ports -� The interfaces within a fabric that provide fibre 445 channel attachment for an N_PORT. The types of fabric port 446 depend on the fabric topology and are discussed in section 3.2. 448 d) The fabric infrastructure for carrying frame traffic between 449 N_PORTs. 451 e) Within a switched or mixed fabric (see section 3.2), a set of 452 auxiliary servers, including a name server for device discovery 453 and network address resolution. The types of service depend on 454 the network topology. 456 +--------+ +--------+ +--------+ +--------+ 457 | FC | | FC | | FC | | FC | 458 | Device | | Device |<-------->| Device | | Device | 459 |........| |........| |........| |........| 460 | N_PORT | | N_PORT | | N_PORT | | N_PORT | 461 +---+----+ +----+---+ +----+---+ +----+---+ 462 | | | | 463 +---+----+ +----+---+ +----+---+ +----+---+ 464 | Fabric | | Fabric | | Fabric | | Fabric | 465 | Port | | Port | | Port | | Port | 466 +========+===+========+==========+========+==+========+ 467 | Fabric | 468 | & | 469 | Fabric Services | 470 +-----------------------------------------------------+ 471 Figure 1 -- A Fibre Channel Network 473 The following sections describe fibre channel fabric topologies and 474 give an overview of the fibre channel communications model. 476 3.2 Fabric Topologies 478 The principal fibre channel fabric topologies consist of the 479 following: 481 a) Arbitrated Loop -- A series of N_PORTs connected together in 482 daisy-chain fashion. Data transmission between N_PORTs 483 requires arbitration for control of the loop in a manner 484 similar to a token ring network. 486 iFCP Revision 10 February 2002 488 b) Switched Fabric -- A fabric consisting of switching elements, 489 as described in section 3.2.1. 491 c) Mixed Fabric -- A fabric consisting of switches and "fabric- 492 attached" loops. A description can be found in [FC-FLA]. 494 Depending on the topology, the N_PORT and fabric port variants 495 through which a fibre channel device is attached to the network may 496 be one of the following: 498 Fabric Topology Fabric Port Type N_PORT Variant 499 --------------- ---------------- -------------- 501 Loop L_PORT NL_PORT 503 Switched F_PORT N_PORT 505 Mixed FL_PORT NL_PORT 507 F_PORT N_PORT 509 The differences in each N_PORT variant and its corresponding fabric 510 port are confined to the interactions between them. To an external 511 N_PORT, all fabric ports are transparent and all remote N_PORTs are 512 functionally identical. 514 3.2.1 Switched Fibre Channel Fabrics 516 An example of a multi-switch fibre channel fabric is shown below. 518 iFCP Revision 10 February 2002 520 +----------+ +----------+ 521 | FC | | FC | 522 | Device | | Device | 523 |..........| |..........| 524 | N_PORT |<........>| N_PORT | 525 +----+-----+ +-----+----+ 526 | | 527 +----+-----+ +-----+----+ 528 | F_PORT | | F_PORT | 529 ==========+==========+==========+==========+============== 530 | FC | | FC | 531 | Switch | | Switch | 532 +----------+ +----------+ Fibre Channel 533 |Inter- | |Inter- | Fabric 534 |Switch | |Switch | 535 |Interface | |Interface | 536 +-----+----+ +-----+----+ 537 | | 538 | | 539 +-----+----+----------+-----+----+ 540 |Inter- | |Inter- | 541 |Switch | |Switch | 542 |Interface | |Interface | 543 +----------+ +----------+ 544 | FC Switch | 545 | | 546 +--------------------------------+ 547 Figure 2 -- Multi-Switch Fibre Channel Fabric 549 The interface between switch elements is either proprietary or the 550 standards-compliant E_PORT interface described by the FC-SW2 551 specification, [FC-SW2]. 553 3.2.2 Mixed Fibre Channel Fabric 555 A mixed fabric contains one or more arbitrated loops connected to a 556 switched fabric as shown in Figure 3. 558 iFCP Revision 10 February 2002 560 +----------+ +----------+ +---------+ 561 | FC | | FC | | FC | 562 | Device | | Device | | Device | 563 |..........| |..........| |.........| 564 | N_PORT |<........>| NL_PORT +---+ NL_PORT | 565 +----+-----+ +-----+----+ +----+----+ 566 | | FC Loop | 567 +----+-----+ +-----+----+ | 568 | F_PORT | | FL_PORT +--------+ 569 | | | | 570 ==========+==========+==========+==========+============== 571 | FC | | FC | 572 | Switch | | Switch | 573 +----------+ +----------+ 574 |Inter- | |Inter- | 575 |Switch | |Switch | 576 |Interface | |Interface | 577 +-----+----+ +-----+----+ 578 | | 579 | | 580 +-----+----+----------+-----+----+ 581 |Inter- | |Inter- | 582 |Switch | |Switch | 583 |Interface | |Interface | 584 +----------+ +----------+ 585 | FC Switch | 586 | | 587 +--------------------------------+ 588 Figure 3 -- Mixed Fibre Channel Fabric 590 As noted previously, the protocol for communications between peer 591 N_PORTs is independent of the fabric topology, N_PORT variant and 592 type of fabric port to which an N_PORT is attached. 594 3.3 Fibre Channel Layers and Link Services 596 Fibre channel consists of the following layers: 598 FC-0 -- The interface to the physical media, 600 FC-1 �- The encoding and decoding of data and out-of-band physical 601 link control information for transmission over the physical media, 603 FC-2 �- The transfer of frames, sequences and Exchanges comprising 604 protocol information units. 606 FC-3 �- Common Services, 608 FC-4 �- Application protocols, such as FCP, the fibre channel SCSI 609 protocol. 611 iFCP Revision 10 February 2002 613 In addition to the layers defined above, fibre channel defines a 614 set of auxiliary operations, some of which are implemented within 615 the transport layer fabric, called link services. These are 616 required to manage the fibre channel environment, establish 617 communications with other devices, retrieve error information, 618 perform error recovery and other similar services. Some link 619 services are executed by the N_PORT. Others are implemented 620 internally within the fabric. These internal services are 621 described in the next section. 623 3.3.1 Fabric-Supplied Link Services 625 Servers internal to a switched fabric handle certain classes of 626 Link Service requests and service-specific commands. The servers 627 appear as N_PORTs located at the 'well-known' N_PORT fabric 628 addresses specified in [FC-FS]. Service requests use the standard 629 fibre channel mechanisms for N_PORT-to-N_PORT communications. 631 All switched fabrics must provide the following services: 633 Fabric F_PORT server � Services an N_PORT request to access the 634 fabric for communications. 636 Fabric Controller -- Provides state change information to inform 637 other FC devices when an N_PORT exits or enters the fabric (see 638 section 3.5). 640 Directory/Name Server � Allows N_PORTs to register information 641 in a database, retrieve information about other N_PORTs and 642 discover other devices as described in section 3.5. 644 A switched fabric may also implement the following optional 645 services: 647 Broadcast Address/Server �- Transmits single-frame, class 3 648 sequences to all N_PORTs. 650 Time Server �- Intended for the management of fabric-wide 651 expiration timers or elapsed time values and is not intended for 652 precise time synchronization. 654 Management Server � Collects and reports management information, 655 such as link usage, error statistics, link quality and similar 656 items. 658 Quality of Service Facilitator � Performs fabric-wide bandwidth 659 and latency management. 661 3.4 Fibre Channel Nodes 663 A fibre channel node has one or more fabric-attached N_PORTs. The 664 node and its N_PORTs have the following associated identifiers: 666 iFCP Revision 10 February 2002 668 a) A worldwide unique identifier for the node, 670 b) A worldwide unique identifier for each N_PORT associated with the 671 node, 673 c) For each N_PORT attached to a fabric, a 24-bit fabric-unique 674 address having the properties defined in section 3.7.1. The 675 fabric address is the address to which frames are sent. 677 Each worldwide unique identifier is a 64-bit binary quantity having 678 the format defined in [FC-FS]. 680 3.5 Fibre Channel Device Discovery 682 In a switched or mixed fabric, fibre channel devices and changes in 683 the device configuration may be discovered by means of services 684 provided by the fibre channel Name Server and Fabric Controller. 686 The Name Server provides registration and query services that allow 687 a fibre channel device to register its presence on the fabric and 688 discover the existence of other devices. For example, one type of 689 query obtains the fabric address of an N_PORT from its 64-bit 690 worldwide unique name. The full set of supported fibre channel name 691 server queries is specified in [FC-GS3]. 693 The Fabric Controller complements the static discovery capabilities 694 provided by the Name Server through a service that dynamically 695 alerts a fibre channel device whenever an N_PORT is added or 696 removed from the configuration. A fibre channel device receives 697 these notifications by subscribing to the service as specified in 698 [FC-FS]. 700 3.6 Fibre Channel Information Elements 702 The fundamental element of information in fibre channel is the 703 frame. A frame consists of a fixed header and up to 2112 bytes of 704 payload having the structure described in section 3.7. The maximum 705 frame size that may be transmitted between a pair of fibre channel 706 devices is negotiable up to the payload limit, based on the size of 707 the frame buffers in each fibre channel device and the path maximum 708 transmission unit (MTU) supported by the fabric. 710 Operations involving the transfer of information between N_PORT 711 pairs are performed through 'Exchanges'. In an Exchange, 712 information is transferred in one or more ordered series of frames 713 referred to as Sequences. 715 Within this framework, an upper layer protocol is defined in terms 716 of transactions carried by Exchanges. Each transaction, in turn, 717 consists of protocol information units, each of which is carried by 718 an individual Sequence within an Exchange. 720 iFCP Revision 10 February 2002 722 3.7 Fibre Channel Frame Format 724 A fibre channel frame consists of a header, payload and 32-bit CRC 725 bracketed by SOF and EOF delimiters. The header contains the 726 control information necessary to route frames between N_PORTs and 727 manage Exchanges and Sequences. The following diagram gives a 728 highly simplified view of the frame. 730 +-----------------------------+ 731 | Start-of-frame Delimiter | 732 +-----+-----------------------+<----+ 733 | | Destination N_PORT | | 734 | | Fabric Address (D_ID) | | 735 | | (24-bits) | | 736 +-----+-----------------------+ 24-byte 737 | | Source N_PORT | Frame 738 | | Fabric Address (S_ID) | Header 739 | | (24 bits) | | 740 +-----+-----------------------+ | 741 | Control information for | | 742 | frame type, Exchange | | 743 | management, IU | | 744 | segmentation and | | 745 | re-assembly | | 746 +-----------------------------+<----+ 747 | | 748 | Frame payload | 749 | (0 � 2112 bytes) | 750 | | 751 | | 752 | | 753 +-----------------------------+ 754 | CRC | 755 +-----------------------------+ 756 | End-of-Frame Delimiter | 757 +-----------------------------+ 758 Figure 4 -- Fibre Channel Frame Format 760 The source and destination N_PORT fabric addresses embedded in the 761 S_ID and D_ID fields represent the physical MAC addresses of 762 originating and receiving N_PORTs. 764 3.7.1 N_PORT Address Model 766 N_PORT fabric addresses are 24-bit values having the following 767 format defined by the fibre channel specification [FC-FS]: 769 iFCP Revision 10 February 2002 771 Bit 23 16 15 8 7 0 772 +-----------+------------+----------+ 773 | Domain ID | Area ID | Port ID | 774 +-----------+------------+----------+ 775 Figure 5 -- Fibre Channel Address Format 777 A fibre channel device acquires an address when it logs into the 778 fabric. Such addresses are volatile and subject to change based on 779 modifications in the fabric configuration. 781 In a fibre channel fabric, each switch element has a unique Domain 782 I/D assigned by the principal switch. The value of the Domain I/D 783 ranges from 1 to 239 (0xEF). Each switch element, in turn, 784 administers a block of addresses divided into area and port IDs. An 785 N_PORT connected to a F_PORT receives a unique fabric address 786 consisting of the switch�s Domain I/D concatenated with switch- 787 assigned area and port I/Ds. 789 A loop-attached NL_PORT (see Figure 3) obtains the Port ID 790 component of its address during the loop initialization process 791 described in [FC-AL2]. The area and domain I/Ds are supplied by the 792 fabric when the FLOGI is executed. 794 3.8 Fibre Channel Transport Services 796 N_PORTs communicate by means of the following classes of service 797 specified in the fibre channel standard ([FC-FS]): 799 Class 1 � A dedicated physical circuit connecting two N_PORTs. 801 Class 2 � A frame-multiplexed connection with end-to-end flow 802 control and delivery confirmation. 804 Class 3 � A frame-multiplexed connection with no provisions for 805 end-to-end flow control or delivery confirmation. 807 Class 4 - A connection-oriented service, based on a virtual circuit 808 model, providing confirmed delivery with bandwidth and latency 809 guarantees. 811 Class 6 - A reliable multicast service derived from class 1. 813 Class 2 and class 3 are the predominant services supported by 814 deployed fibre channel storage and clustering systems. 816 Class 3 service is similar to UDP or IP datagram service. Fibre 817 channel storage devices using this class of service rely on the ULP 818 implementation to detect and recover from transient device and 819 transport errors. 821 For class 2 and class 3 service, the fibre channel fabric is not 822 required to provide in-order delivery of frames unless explicitly 824 iFCP Revision 10 February 2002 826 requested by the frame originator (and supported by the fabric). If 827 ordered delivery is not in effect, it is the responsibility of the 828 frame recipient to reconstruct the order in which frames were sent 829 based on information in the frame header. 831 3.9 Login Processes 833 The Login processes are FC-2 operations that allow an N_PORT to 834 establish the operating environment necessary to communicate with 835 the fabric, other N_PORTs and ULP implementations accessed via the 836 N_PORT. Three login operations are supported: 838 a) Fabric Login (FLOGI) -- An operation whereby the N_PORT 839 registers its presence on the fabric, obtains fabric 840 parameters, such as classes of service supported, and receives 841 its N_PORT address, 843 b) Port Login (PLOGI) -- An operation by which an N_PORT 844 establishes communication with another N_PORT. 846 c) Process Login (PRLOGI) -- An operation which establishes the 847 process-to-process communications associated with a specific 848 FC-4 ULP -- such as FCP-2, the fibre channel SCSI mapping. 850 Since N_PORT addresses are volatile, an N_PORT originating a login 851 (PLOGI) operation executes a Name Server query to discover the 852 fibre channel address of the remote device. A common query type 853 involves use of the worldwide unique name of an N_PORT to obtain 854 the 24-bit N_PORT fibre channel address to which the PLOGI request 855 is sent. 857 4. The iFCP Network Model 859 The iFCP protocol enables the implementation of fibre channel mixed 860 or switched fabric functionality on an IP network in which IP 861 components and technology replace the fibre channel switching and 862 routing infrastructure described in section 3.2. 864 The example of Figure 6 shows a fibre channel fabric with attached 865 devices. These access the fabric through an N_PORT interface 866 connected to a Fabric Port whose behavior is specified in [FC-FS]. 867 In this case, the N_PORT and Fabric Port represent any of the 868 variants described in section 3.2. 870 Within the fibre channel device domain, fabric-addressable entities 871 consist of other N_PORTs and devices internal to the fabric that 872 perform the fabric services defined in [FC-GS3]. 874 iFCP Revision 10 February 2002 876 Fibre Channel Network 877 +--------+ +--------+ 878 | FC | | FC | 879 | Device | | Device | 880 |........| |........| Fibre Channel 881 | N_PORT |<......>| N_PORT | Device Domain 882 +---+----+ +----+---+ ^ 883 | | | 884 +---+----+ +----+---+ | 885 | Fabric | | Fabric | | 886 | Port | | Port | | 887 ==========+========+========+========+============== 888 | Fabric & | | 889 | Fabric Services | v 890 | | Fibre Channel 891 +--------------------------+ Fabric Domain 892 Figure 6 -- A Fibre Channel Fabric 894 Gateway Region Gateway Region 895 +--------+ +--------+ +--------+ +--------+ 896 | FC | | FC | | FC | | FC | 897 | Device | | Device | Fibre | Device | | Device | Fibre 898 |........| |........| Channel |........| |........| Channel 899 | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device 900 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 901 | | | | ^ 902 +---+----+ +---+----+ +----+---+ +----+---+ | 903 | Fabric | | Fabric | | Fabric | | Fabric | | 904 | Port | | Port | | Port | | Port | | 905 =+========+==+========+===========+========+==+========+========== 906 | iFCP Layer |<--------->| iFCP Layer | | 907 |....................| ^ |....................| | 908 | iFCP Portal | | | iFCP Portal | v 909 +--------+-----------+ | +----------+---------+ IP 910 iFCP|Gateway Control iFCP|Gateway Network 911 | Data | 912 | | 913 | | 914 |<------Encapsulated Frames------->| 915 | +------------------+ | 916 | | | | 917 +------+ IP Network +--------+ 918 | | 919 +------------------+ 920 Figure 7 -- An iFCP Fabric 922 Figure 7 shows an implementation of an equivalent iFCP fabric 923 consisting of two gateways, each in control of a single gateway 924 region. 926 iFCP Revision 10 February 2002 928 Each iFCP gateway contains two standards-compliant fibre channel 929 ports and an iFCP Portal for attachment to the IP network. Fibre 930 channel devices in the region are those locally connected to the 931 iFCP fabric through the gateway fabric ports. 933 Looking into the fabric port, the gateway appears as a fibre 934 channel switch element. At this interface, remote N_PORTs are 935 presented as fabric-attached devices. Conversely, on the IP network 936 side, the gateway presents each locally connected N_PORT as a 937 logical fibre channel device. 939 4.1 Fibre Channel Fabric Topologies Supported by iFCP 941 A property of this architecture is that the fibre channel fabric 942 configuration and topology within the gateway region behave like an 943 autonomous system whose internals are invisible to the IP network 944 and other gateway regions. As a result, support for specific FC 945 fabric topologies becomes a gateway implementation issue. In such 946 cases, the gateway may support any standards-compliant fibre 947 channel fabric type by incorporating the functionality required to 948 present locally attached N_PORTs as logical iFCP devices. 950 4.2 iFCP Transport Services 952 N_PORT to N_PORT communications that traverse a TCP/IP network 953 require the intervention of the iFCP layer within the gateway. This 954 consists of the following operations: 956 a) Execution of the frame addressing and mapping functions 957 described in section 4.5. 959 b) Execution of fabric-supplied link services addressed to one of 960 the well-known fibre channel N_PORT addresses. 962 c) Encapsulation of fibre channel frames for injection into the 963 TCP/IP network and de-encapsulation of fibre channel frames 964 received from the TCP/IP network. 966 d) Establishment of an iFCP session in response to a PLOGI directed 967 to a remote device. 969 Section 4.5 discusses the iFCP frame addressing mechanism and the 970 way in which it is used to achieve communications transparency 971 between N_PORTs. 973 4.2.1 Fibre Channel Transport Services Supported by iFCP 975 An iFCP fabric supports Class 2 and Class 3 fibre channel transport 976 services as specified in [FC-FS]. An iFCP fabric does not support 977 class 4, class 6 or the Class 1 (dedicated connection) service. An 978 N_PORT discovers the classes of transport services supported by the 979 fabric during fabric login. 981 iFCP Revision 10 February 2002 983 4.3 iFCP Device Discovery and Configuration Management 985 An iFCP implementation performs device discovery and iFCP fabric 986 management through the Internet Storage Name Service defined in 987 [ISNS]. Access to an iSNS server is required to perform the 988 following functions: 990 a) Emulate the services provided by the fibre channel name server 991 described in section 3.3.1, including a mechanism for 992 asynchronously notifying an N_PORT of changes in the iFCP fabric 993 configuration, 995 b) Aggregate gateways into iFCP fabrics for interoperation, 997 c) Segment an iFCP fabric into fibre channel zones through the 998 definition and management of device discovery scopes, referred 999 to as 'discovery domains', 1001 d) Store and distribute security policies as described in section 1002 10.2.9. 1004 e) Implementation of the fibre channel broadcast mechanism. 1006 4.4 iFCP Fabric Properties 1008 A collection of iFCP gateways may be configured for interoperation 1009 as either a bounded or unbounded iFCP fabric. 1011 Gateways in a bounded iFCP fabric operate in address transparent 1012 mode as described in section 4.6. In this mode, the scope of a 1013 fibre channel N_PORT address is fabric-wide and is derived from 1014 domain I/Ds issued by the iSNS server from a common pool. As 1015 discussed below, the maximum number of domain I/Ds allowed by fibre 1016 channel limits the configuration of a bounded iFCP fabric. 1018 Gateways in an unbounded iFCP fabric operate in address translation 1019 mode as described in section 4.7. In this mode, the scope of an 1020 N_PORT address is local to a gateway region. For fibre channel 1021 traffic between regions, the translation of frame-embedded N_PORT 1022 addresses is performed by the gateway. As discussed below, an 1023 unbounded iFCP fabric may have any number of switch elements and 1024 gateways. 1026 All iFCP gateways MUST support unbounded iFCP fabrics. Support for 1027 bounded iFCP fabrics is OPTIONAL. 1029 The decision to support bounded iFCP fabrics in a gateway 1030 implementation depends on the address transparency, configuration 1031 scalability, and fault tolerance considerations discussed below. 1033 4.4.1 Address Transparency 1034 iFCP Revision 10 February 2002 1036 Although iFCP gateways in an unbounded fabric will convert N_PORT 1037 addresses in the frame header and payload of standard link service 1038 messages, a gateway cannot convert such addresses in the payload of 1039 vendor- or user-specific fibre channel frame traffic. 1041 Consequently, while both bounded and unbounded iFCP fabrics support 1042 standards-compliant FC-4 protocol implementations and link services 1043 used by mainstream fibre channel applications, a bounded iFCP 1044 fabric may also support vendor- or user-specific protocol and link 1045 service implementations that carry N_PORT IDs in the frame payload. 1047 4.4.2 Configuration Scalability 1049 The scalability limits of a bounded fabric configuration are a 1050 consequence of the fibre channel address allocation policy 1051 discussed in section 3.7.1. As noted, a bounded iFCP fabric using 1052 this address allocation scheme is limited to a combined total of 1053 239 gateways and fibre channel switch elements. As the system 1054 expands, the network may grow to include many switch elements and 1055 gateways, each of which controls a small number of devices. In 1056 this case, the limitation in switch and gateway count may become a 1057 barrier to extending and fully integrating the storage network. 1059 Since N_PORT fibre channel addresses in an unbounded iFCP fabric 1060 are not fabric-wide, there are no architectural limits on the 1061 number of iFCP gateways, fibre channel devices and switch elements 1062 that may be internetworked. In exchange for improved scalability, 1063 however, implementations must consider the incremental overhead of 1064 address conversion as well as the address transparency issues 1065 discussed in section 4.4.1. 1067 4.4.3 Fault Tolerance 1069 In an unbounded iFCP fabric, limiting the scope of an N_PORT 1070 address to a gateway region reduces the likelihood that 1071 reassignment of domain I/Ds caused by a disruption in one gateway 1072 region will cascade to others. 1074 In addition, a bounded iFCP fabric has an increased dependency on 1075 the iSNS server, which must act as the central address assignment 1076 authority. If connectivity with the server is lost, new DOMAIN_ID 1077 values cannot be automatically allocated as gateways and fibre 1078 channel switch elements are added to the fabric. 1080 Finally, adding a gateway to a bounded fabric is more likely to 1081 disrupt the operation of all devices in the gateway region along 1082 with those already in the fabric as new, fabric-wide N_PORT 1083 addresses are assigned. Furthermore, before the new gateway can be 1084 merged, its iSNS server must be slaved to the iSNS server in the 1085 bounded fabric to centralize the issuance of domain I/Ds. 1087 iFCP Revision 10 February 2002 1089 In contrast, adding a new gateway to an unbounded iFCP fabric can 1090 be done non-disruptively and requires only that new gateway's iSNS 1091 server import client attributes from the other iSNS servers. 1093 4.5 The iFCP N_PORT Address Model 1095 This section discusses iFCP extensions to the fibre channel 1096 addressing model of section 3.7.1, which are required for the 1097 transparent routing of frames between locally and remotely attached 1098 N_PORTs. 1100 In the iFCP protocol, an N_PORT is represented by the following 1101 addresses: 1103 a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a 1104 locally attached device. Depending on the gateway addressing 1105 mode, the scope is either local to a region or a bounded iFCP 1106 fabric. In either mode, communications between N_PORTs in the 1107 same gateway region use the N_PORT ID. 1109 b) A 24-bit N_PORT alias. A fibre channel N_PORT address assigned 1110 by a gateway operating in address translation mode to identify a 1111 remotely attached N_PORT. Frame traffic is directed to a 1112 remotely attached N_PORT by means of the N_PORT alias. 1114 c) An N_PORT network address. A tuple consisting of the gateway IP 1115 address, TCP port number and N_PORT ID. The N_PORT network 1116 address identifies the source and destination N_PORTs for fibre 1117 channel traffic on the IP network. 1119 To provide transparent communications between a remote and local 1120 N_PORT, a gateway MUST maintain an iFCP session descriptor (see 1121 section 5.2.2.2) reflecting the association between the fibre 1122 channel address representing the remote N_PORT and the remote 1123 device's N_PORT network address. To establish this association the 1124 iFCP gateway assigns and manages fibre channel N_PORT fabric 1125 addresses as described in the following paragraphs. 1127 In an iFCP fabric, the iFCP gateway performs the address assignment 1128 and frame routing functions of an FC switch element. Unlike an FC 1129 switch, however, an iFCP gateway must also direct frames to 1130 external devices attached to remote gateways on the IP network. 1132 In order to be transparent to FC devices, the gateway must deliver 1133 such frames using only the 24-bit destination address in the frame 1134 header. By exploiting its control of address allocation and access 1135 to frame traffic entering or leaving the gateway region, it is able 1136 to achieve the necessary transparency. 1138 N_PORT addresses within a gateway region may be allocated in one of 1139 two ways: 1141 iFCP Revision 10 February 2002 1143 a) Address Translation Mode � A mode of N_PORT address assignment 1144 in which the scope of an N_PORT fibre channel address is unique 1145 to the gateway region. The address of a remote device is 1146 represented in that gateway region by its gateway-assigned 1147 N_PORT alias. 1149 b) Address Transparent Mode � A mode of N_PORT address assignment 1150 in which the scope of an N_PORT fibre channel address is unique 1151 across the set of gateway regions comprising a bounded iFCP 1152 fabric. 1154 In address transparent mode, gateways within a bounded fabric 1155 cooperate in the assignment of addresses to locally attached 1156 N_PORTs. Each gateway in control of a region is responsible for 1157 obtaining and distributing unique domain I/Ds from the address 1158 assignment authority as described in section 4.6.1. Consequently, 1159 within the scope of a bounded fabric, the address of each N_PORT is 1160 unique. For that reason, gateway-assigned aliases are not required 1161 to represent remote N_PORTs. 1163 All iFCP implementations MUST support operation in address 1164 translation mode. Implementation of address transparent mode is 1165 OPTIONAL but, of course, must be provided if bounded iFCP fabric 1166 configurations are to be supported. 1168 The mode of gateway operation is settable in an implementation- 1169 specific manner. The implementation MUST NOT allow the mode to be 1170 changed after the gateway begins processing fibre channel frame 1171 traffic. 1173 4.6 Operation in Address Transparent Mode 1175 The following considerations and requirements apply to this mode of 1176 operation: 1178 a) iFCP gateways in address transparent mode will not interoperate 1179 with iFCP gateways that are not in address transparent mode. 1181 b) When interoperating with locally attached fibre channel switch 1182 elements, each iFCP gateway MUST assume control of DOMAIN_ID 1183 assignments in accordance with the appropriate fibre channel 1184 standard or vendor-specific protocol specification. As 1185 described in section 4.6.1, DOMAIN_ID values assigned to FC 1186 switches internal to the gateway region must be issued by the 1187 iSNS server. 1189 c) When operating in address transparent Mode, fibre channel 1190 address translation SHALL NOT take place. 1192 When operating in address transparent mode, however, the gateway 1193 MUST establish and maintain the context of each iFCP session in 1194 accordance with section 5.2.2. 1196 iFCP Revision 10 February 2002 1198 4.6.1 Transparent Mode Domain I/D Management 1200 As described in section 4.6, each gateway and fibre channel switch 1201 in a bounded iFCP fabric MUST have a unique domain I/D. In a 1202 gateway region containing fibre channel switch elements, each 1203 element obtains a domain I/D by querying the principal switch as 1204 described in [FC-SW2] -- in this case the iFCP gateway itself. The 1205 gateway in turn MUST obtain domain I/Ds on demand from the iSNS 1206 name server acting as the central address allocation authority. In 1207 effect, the iSNS server assumes the role of principal switch for 1208 the bounded fabric. In that case, the iSNS database contains: 1210 a) The definition for one or more bounded iFCP fabrics, 1212 b) For each bounded fabric, a worldwide unique name identifying 1213 each gateway in the fabric. A gateway in address transparent 1214 mode MUST reside in one and only one bounded fabric. 1216 In its role as principal switch within the gateway region, an iFCP 1217 gateway in address transparent mode SHALL obtain domain I/Ds for 1218 use in the gateway region by issuing the appropriate iSNS query 1219 using its worldwide name. 1221 4.6.2 Incompatibility with Address Translation Mode 1223 Except for the session control frames specified in section 6, iFCP 1224 gateways in address transparent mode SHALL NOT originate or accept 1225 frames that do not have the TRN bit set to one in the iFCP flags 1226 field of the encapsulation header (see section 5.4.1). The iFCP 1227 gateway SHALL immediately terminate all iFCP sessions with the iFCP 1228 gateway from which it receives such frames. 1230 4.7 Operation in Address Translation Mode 1232 This section describes the process for managing the assignment of 1233 addresses within a gateway region that is part of an unbounded iFCP 1234 fabric, including the modification of FC frame addresses embedded 1235 in the frame header for frames sent and received from remotely 1236 attached N_PORTs. 1238 As described in section 4.5, the scope of N_PORT addresses in this 1239 mode is local to the gateway region. A principal switch within the 1240 gateway region, possibly the iFCP gateway itself, oversees the 1241 assignment of such addresses in accordance with the rules specified 1242 in [FC-FS] and [FC-FLA]. 1244 The assignment of N_PORT addresses to locally attached devices is 1245 controlled by the switch element to which the device is connected. 1247 The assignment of N_PORT addresses for remotely attached devices is 1248 controlled by the gateway through which the remote device is 1249 accessed. In this case, the gateway MUST assign a locally 1251 iFCP Revision 10 February 2002 1253 significant N_PORT alias to be used in place of the N_PORT ID 1254 assigned by the remote gateway. The N_PORT alias is assigned during 1255 device discovery as described in section 5.2.2.1. 1257 To perform address conversion and enable the appropriate routing, 1258 the gateway MUST establish an iFCP session and generate the 1259 information required to map each N_PORT alias to the appropriate 1260 TCP/IP connection context and N_PORT ID of the remotely accessed 1261 N_PORT. The means by which these mappings are created and updated 1262 are specified in section 5.2.2.2. As described in that section, 1263 the required mapping information is represented by the iFCP session 1264 descriptor reproduced in Figure 8. 1266 +-----------------------+ 1267 |TCP Connection Context | 1268 +-----------------------+ 1269 | Local N_PORT ID | 1270 +-----------------------+ 1271 | Remote N_PORT ID | 1272 +-----------------------+ 1273 | Remote N_PORT Alias | 1274 +-----------------------+ 1275 Figure 8 -- iFCP Session Descriptor (from section 5.2.2.2) 1277 The role of the session descriptor in address translation is 1278 specified in sections 4.7.1 and 4.7.2 for inbound and outbound 1279 frame traffic. 1281 4.7.1 Outbound Frame Address Translation 1283 For frames to be sent on the IP network, the iFCP session 1284 descriptor SHALL be referenced to map the Destination N_PORT alias 1285 to the TCP connection context and N_PORT ID assigned by the remote 1286 gateway. The translation process for outbound frames is shown in 1287 Figure 9. 1289 iFCP Revision 10 February 2002 1291 Raw Fibre Channel Frame 1292 +--------+-----------------------------------+ +--------------+ 1293 | | Destination N_PORT Alias |--->| Lookup TCP | 1294 +--------+-----------------------------------+ | connection | 1295 | | Source N_PORT ID | | context | 1296 +--------------------------------------------+ | and N_PORT ID| 1297 | | | from session | 1298 | | | descriptor | 1299 | | +------+-------+ 1300 | Control information, | | TCP 1301 | Payload and FC CRC | | conn 1302 | | | context 1303 +--------------------------------------------+ | & 1304 | N_PORT 1305 | ID 1306 | 1307 After Address Translation and Encapsulation | 1308 +--------------------------------------------+ | 1309 | FC Encapsulation Header | | 1310 +--------------------------------------------+ | 1311 | SOF Delimiter Word | | 1312 +============================================+ | 1313 | | Destination N_PORT ID |<----------+ 1314 +--------+-----------------------------------+ 1315 | | Source N_PORT ID | 1316 +--------+-----------------------------------+ 1317 | | 1318 | Control information, Payload | 1319 | and FC CRC | 1320 +============================================+ 1321 | EOF Delimiter Word | 1322 +--------------------------------------------+ 1323 Figure 9 -- Outbound Frame Address Translation 1325 4.7.2 Inbound Frame Address Translation 1327 For inbound frames received from the IP network, a translation 1328 SHALL be performed to regenerate the N_PORT alias from the TCP 1329 connection context and N_PORT ID contained in the Source N_PORT ID 1330 (S_ID) field of the encapsulated FC frame. The translation process 1331 for inbound frames is shown in Figure 10. 1333 iFCP Revision 10 February 2002 1335 Network Format of Inbound Frame 1336 +--------------------------------------------+ TCP 1337 | FC Encapsulation Header | Connection 1338 +--------------------------------------------+ Context 1339 | SOF Delimiter Word | | 1340 +============================================+ V 1341 | | Destination N_PORT ID | +-------+------+ 1342 +--------+-----------------------------------+ | Lookup source| 1343 | | Source N_PORT ID |---->| N_PORT Alias | 1344 +--------+-----------------------------------+ | from session | 1345 | | | descriptor | 1346 | | +-------+------+ 1347 | Control information, Payload | | 1348 | and FC CRC | | Source 1349 +============================================+ | N_PORT 1350 | EOF Delimiter Word | | Alias 1351 +--------------------------------------------+ | 1352 | 1353 | 1354 Frame after Address Translation and De-encapsulation | 1355 +--------+-----------------------------------+ | 1356 | | Destination N_PORT ID | | 1357 +--------+-----------------------------------+ | 1358 | | Source N_PORT Alias |<------------+ 1359 +--------+-----------------------------------+ 1360 | | 1361 | Control information, Payload, | 1362 | and FC CRC | 1363 +--------------------------------------------+ 1364 Figure 10 -- Inbound Frame Address Translation 1366 For all inbound and outbound frames, the gateway MUST recalculate 1367 the FC CRC after altering the frame contents. 1369 4.7.3 Incompatibility with Address Transparent Mode 1371 iFCP gateways in address translation mode SHALL NOT originate or 1372 accept frames that have the TRN bit set to one in the iFCP flags 1373 field of the encapsulation header. The iFCP gateway SHALL 1374 immediately abort all iFCP sessions with the iFCP gateway from 1375 which it receives such frames as described in section 5.2.3.2. 1377 5. iFCP Protocol 1379 5.1 Overview 1381 5.1.1 iFCP Transport Services 1383 The main function of the iFCP protocol layer is to transport fibre 1384 channel frame images between locally and remotely attached N_PORTs. 1386 iFCP Revision 10 February 2002 1388 When transporting frames to a remote N_PORT, the iFCP layer 1389 encapsulates and routes the fibre channel frames comprising each 1390 fibre channel Information Unit via a predetermined TCP connection 1391 for transport across the IP network. 1393 When receiving fibre channel frame images from the IP network, the 1394 iFCP layer de-encapsulates and delivers each frame to the 1395 appropriate N_PORT. 1397 The iFCP layer processes the following types of traffic: 1399 a) FC-4 frame images associated with a fibre channel application 1400 protocol. 1402 b) FC-2 frames comprising fibre channel link service requests and 1403 responses 1405 c) Fibre channel broadcast frames 1407 d) iFCP control messages required to setup, manage or terminate an 1408 iFCP session. 1410 For FC-4 N_PORT traffic and most FC-2 messages the iFCP layer never 1411 interprets the contents of the frame payload. 1413 iFCP does interpret and process iFCP control messages and certain 1414 link service messages as described in section 5.1.2 1416 5.1.2 iFCP Support for Link Services 1418 iFCP must intervene in the processing of those fibre channel link 1419 service messages that contain N_PORT addresses in the message 1420 payload or require other special handling, such as an N_PORT login 1421 request (PLOGI). 1423 In the former case, an iFCP gateway operating in address 1424 translation mode MUST supplement the payload with additional 1425 information that enables the receiving gateway to convert such 1426 embedded N_PORT addresses to its frame of reference. 1428 For out-bound fibre channel frames comprising such a link service, 1429 the iFCP layer creates the supplemental information based on frame 1430 content, modifies the frame payload, then transmits the resulting 1431 fibre channel frame with supplemental data through the appropriate 1432 TCP connection. 1434 For incoming iFCP frames containing supplemented fibre channel link 1435 service frames, iFCP MUST interpret the frame, including any 1436 supplemental information, modify the frame content, and forward the 1437 resulting frame to the destination N_PORT for further processing. 1439 iFCP Revision 10 February 2002 1441 Section 7.1 describes the processing of these link service messages 1442 in detail. 1444 5.2 TCP Stream Transport of iFCP Frames 1446 5.2.1 iFCP Session Model 1448 An iFCP session consists of the pair of N_PORTs comprising the 1449 session endpoints joined by a single TCP/IP connection. 1451 An N_PORT is identified by its network address consisting of: 1453 a) The N_PORT ID assigned by the gateway to which the N_PORT is 1454 locally attached and 1456 b) The iFCP Portal address, consisting of its IP address and TCP 1457 port number. 1459 Since only one iFCP session may exist between a pair of N_PORTs, 1460 the iFCP session is uniquely identified by the network addresses of 1461 the session end points. 1463 TCP connections that may be used for iFCP sessions between pairs of 1464 iFCP portals are either "bound" or "unbound". An unbound 1465 connection is a TCP connection that is not actively supporting an 1466 iFCP session. A gateway implementation MAY establish a pool of 1467 unbound connections to reduce the session setup time. Such pre- 1468 existing TCP connections between iFCP Portals remain unbound and 1469 uncommitted until allocated to an iFCP session through a CBIND 1470 message (see section 6.1). 1472 When the iFCP layer receives a Port Login (PLOGI) message creating 1473 an iFCP session between a pair of N_PORTs, it may select an 1474 existing unbound TCP connection or establish a new TCP connection 1475 and send the CBIND message down that TCP connection. This 1476 allocates the TCP connection to that PLOGI login session. 1478 5.2.2 iFCP Session Management 1480 This section describes the protocols and data structures required 1481 to establish and terminate an iFCP session. 1483 5.2.2.1 The Remote N_PORT Descriptor 1485 In order to establish an iFCP session, an iFCP gateway MUST 1486 maintain information allowing it to locate a remotely attached 1487 N_PORT. For explanatory purposes, such information is assumed to 1488 reside in a descriptor having the format shown in Figure 11. 1490 iFCP Revision 10 February 2002 1492 +--------------------------------+ 1493 | N_PORT Worldwide Unique Name | 1494 +--------------------------------+ 1495 | iFCP Portal Address | 1496 +--------------------------------+ 1497 | N_PORT ID of Remote N_PORT | 1498 +--------------------------------+ 1499 | N_PORT Alias | 1500 +--------------------------------+ 1501 Figure 11 -- Remote N_PORT Descriptor 1503 Each descriptor aggregates the following information about a 1504 remotely attached N_PORT: 1506 N_PORT Worldwide Unique Name -- 64-bit N_PORT world wide name 1507 as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely 1508 identified by this parameter. 1510 iFCP Portal Address -- The IP address and TCP port number 1511 referenced when requesting creation of the TCP connection 1512 associated with an iFCP session. 1514 N_PORT ID -- N_PORT fibre channel address assigned to the 1515 remote device by the remote iFCP gateway. 1517 N_PORT Alias -- N_PORT fibre channel address assigned to the 1518 remote device by the 'local' iFCP gateway when operating in 1519 address translation mode. 1521 An iFCP gateway SHALL have one and only one descriptor for each 1522 remote N_PORT it accesses. If a descriptor does not exist, one 1523 SHALL be created in response to an iSNS name server query. Such 1524 queries may be result from: 1526 a) A fibre channel Name Server request originated by a locally 1527 attached N_PORT (see sections 3.5 and 9.3), or 1529 b) A CBIND request received from a remote fibre channel device (see 1530 section 5.2.2.2). 1532 When creating a descriptor in response to an incoming CBIND 1533 request, the iFCP gateway SHALL perform an iSNS name server query 1534 using the worldwide port name of the remote N_PORT in the SOURCE 1535 N_PORT NAME field within the CBIND payload. The descriptor SHALL 1536 be filled in using the query results. 1538 After creating the descriptor, a gateway operating in address 1539 translation mode SHALL create and add the 24-bit N_PORT alias. 1541 5.2.2.1.1 Updating a Remote N_PORT Descriptor 1542 iFCP Revision 10 February 2002 1544 A Remote N_PORT descriptor SHALL only be updated as the result of 1545 an iSNS query that returns information for the specified worldwide 1546 port name. Following such an update, a new N_PORT alias SHALL NOT 1547 be assigned. 1549 Until such an update occurs, the contents of a descriptor may 1550 become stale as the result of any event that invalidates or 1551 triggers a change in the N_PORT network address of the remote 1552 device, such as a fabric reconfiguration or the device's removal or 1553 replacement. 1555 A collateral effect of such an event is that a fibre channel device 1556 that has been added or whose N_PORT ID has changed will have no 1557 active N_PORT logins. Consequently, FC-4 traffic directed to such 1558 an N_PORT as the result of a stale descriptor will be rejected or 1559 discarded. 1561 Once the originating N_PORT learns of the reconfiguration, usually 1562 through the name server state change notification mechanism, the 1563 name server lookup needed to reestablish the iFCP session will 1564 automatically purge such stale data from the gateway. 1566 5.2.2.2 Creating an iFCP Session 1568 An iFCP session may be in one of the following states: 1570 a) OPEN -- The session state in which fibre channel frame images 1571 may be sent and received. 1573 b) OPEN PENDING -- The session state after a gateway has issued a 1574 CBIND request but no response has yet been received. No fibre 1575 channel frames may be sent. 1577 The gateway SHALL initiate the creation of an iFCP session in 1578 response to a PLOGI ELS directed to a remote N_PORT from a locally 1579 attached N_PORT as described in the following steps. 1581 a) Using the D_ID field in the PLOGI frame header, locate the 1582 remote N_PORT descriptor. If no descriptor exists, the iFCP 1583 gateway SHALL return a response of LS_RJT, with a Reason Code of 1584 'Unable to Perform Command Request' (0x09) and a Reason Code 1585 Explanation of 'Invalid N_PORT_ID' (0x1F). An iFCP session SHALL 1586 NOT be created. 1588 b) If no iFCP session exists, allocate a TCP connection to the 1589 gateway to which the remote N_PORT is locally attached. An 1590 implementation may use an existing connection in the Unbound 1591 state or a new connection may be created and placed in the 1592 Unbound state. 1594 When creating a connection, the IP address and TCP Port number 1596 iFCP Revision 10 February 2002 1598 SHALL be obtained by referencing the remote N_PORT descriptor as 1599 specified in section 5.2.2.1. 1601 c) If a connection cannot be allocated or created due to limited 1602 resources, the gateway SHALL terminate the PLOGI with an LS_RJT 1603 response. The Reason Code field in the LS_RJT message shall be 1604 set to 0x09 (Unable to Perform Command Request) and the Reason 1605 Explanation SHALL be set to 0x29 (Insufficient Resources to 1606 Support Login). 1608 d) The gateway SHALL then issue a CBIND session control message 1609 (see section 6.1) and place the session in the OPEN PENDING 1610 state. 1612 e) If a CBIND response is returned with one of the following 1613 statuses, the PLOGI SHALL be terminated with an LS_RJT message. 1614 Depending on the CBIND failure status, the Reason Code and 1615 Reason Explanation SHALL be set to the following values 1616 specified in [FC-FS]. 1618 CBIND Failure LS_RJT Reason LS_RJT Reason Code 1619 Status Code Explanation 1620 ------------- ------------- ------------------ 1622 Unspecified Unable to Perform No additional 1623 Reason (16) Command Request explanation (0x00) 1624 (0x09) 1626 No Such Device Unable to Perform Invalid N_PORT Name 1627 (17) Command Request (0x0D). 1628 (0x09) 1630 Lack of Unable to Perform Insufficient 1631 Resources (19) Command Request Resources to Support 1632 (0x09). Login (0x29). 1634 Incompatible Unable to Perform No additional 1635 address Command Request Explanation (0x00) 1636 translation mode (0x09) 1637 (20) 1639 Incorrect iFCP Unable to Perform No additional 1640 protocol version Command Request explanation (0x00) 1641 number (21) (0x09) 1643 f) A CBIND response with a CBIND STATUS of "N_PORT session already 1644 exists" indicates that the remote gateway has concurrently 1645 initiated a CBIND request to create an iFCP session between the 1646 same pair of N_PORTs. The receiving gateway SHALL terminate this 1647 attempt, return the connection to the Unbound state and prepare 1648 to respond to an incoming CBIND request as described below. 1650 iFCP Revision 10 February 2002 1652 The gateway receiving a CBIND request SHALL respond as follows: 1654 a) If the receiver has a duplicate iFCP session in the OPEN PENDING 1655 state, then the receiving gateway SHALL compare the Source 1656 N_PORT Name in the incoming CBIND payload with the Destination 1657 N_PORT Name. 1659 b) If the Source N_PORT Name is greater, the receiver SHALL issue a 1660 CBIND response of "Success" and SHALL place the session in the 1661 OPEN state. 1663 c) If the Source N_PORT Name is less, the receiver shall issue a 1664 CBIND RESPONSE of Failed - N_PORT session already exists. The 1665 state of the receiver-initiated iFCP session SHALL BE unchanged. 1667 d) If there is no duplicate iFCP session in the OPEN PENDING state, 1668 the receiving gateway SHALL issue a CBIND response. If a status 1669 of Success is returned, the receiving gateway SHALL create the 1670 iFCP session and place it in the OPEN state. 1672 e) If a remote N_PORT descriptor does not exist, one SHALL be 1673 created and filled in as described in section 5.2.2.1. 1675 Once the session is placed in the OPEN state, an iFCP session 1676 descriptor SHALL be created containing the following information: 1678 +-----------------------+ 1679 |TCP Connection Context | 1680 +-----------------------+ 1681 | Local N_PORT ID | 1682 +-----------------------+ 1683 | Remote N_PORT ID | 1684 +-----------------------+ 1685 | Remote N_PORT Alias | 1686 +-----------------------+ 1687 Figure 12 -- iFCP Session Descriptor 1689 TCP Connection Context -- Information required to identify the TCP 1690 connection associated with the iFCP session. 1692 Local N_PORT ID -- N_PORT ID of the locally attached fibre channel 1693 device. 1695 Remote N_PORT ID -- N_PORT ID assigned to the remote device by the 1696 remote gateway. 1698 Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the 1699 local gateway when operating in address translation mode. If in 1700 this mode, the gateway SHALL copy this parameter from the Remote 1701 N_PORT descriptor. Otherwise, it is not filled in. 1703 5.2.2.3 Monitoring iFCP Connectivity 1704 iFCP Revision 10 February 2002 1706 During extended periods of inactivity, an iFCP session may be 1707 terminated due to a hardware failure within the gateway or through 1708 loss of TCP/IP connectivity. The latter may occur when the session 1709 traverses a stateful intermediate device, such as a NA(P)T box or 1710 firewall, that detects and purges connections it believes to be 1711 idle. 1713 To test session liveness, expedite the detection of connectivity 1714 failures, and avoid spontaneous connection termination, an iFCP 1715 gateway may maintain a low level of session activity and monitor 1716 the session by requesting that the remote gateway periodically 1717 transmit the LTEST message described in section 6.3. All iFCP 1718 gateways SHALL support liveness testing as described in this 1719 specification. 1721 A gateway requests the LTEST heartbeat by specifying a non-zero 1722 value for the LIVENESS TEST INTERVAL in the CBIND request or 1723 response message as described in section 6.1. If both gateways 1724 wish to monitor liveness, each must set the LIVENESS TEST INTERVAL 1725 in the CBIND request or response. 1727 Upon receiving such a request, the gateway providing the 1728 connectivity probe SHALL transmit LTEST messages at the specified 1729 interval. The first message SHALL be sent as soon as the iFCP 1730 session enters the OPEN state. LTEST messages SHALL NOT be sent 1731 when the iFCP session is not in the OPEN state. 1733 An iFCP session SHALL be aborted as described in section 5.2.3.2 1734 if: 1736 a) The contents of the LTEST message are incorrect, or 1738 b) An LTEST message is not received within twice the specified 1739 interval or the iFCP session has been quiescent for longer than 1740 twice the specified interval. 1742 The gateway to receive the LTEST message SHALL measure the 1743 interval for the first expected LTEST message from when the 1744 session is placed in the OPEN state. Thereafter, the interval 1745 SHALL be measured relative to the last LTEST message received. 1747 To maximize liveness test coverage, LTEST messages SHOULD flow 1748 through all the gateway components used to enter and retrieve fibre 1749 channel frames from the IP network, including the mechanisms for 1750 encapsulating and de-encapsulating fibre channel frames. 1752 In addition to monitoring a session, information in the LTEST 1753 message encapsulation header may also be used to compute an 1754 estimate of network propagation delay as described in section 1755 8.2.1. However, the propagation delay limit SHALL NOT be enforced 1756 for LTEST traffic. 1758 iFCP Revision 10 February 2002 1760 5.2.2.4 Use of TCP Features and Settings 1762 This section describes ground rules for the use of TCP features in 1763 an iFCP session. The core TCP protocol is defined in [RFC793]. 1764 TCP implementation requirements and guidelines are specified in 1765 [RFC1122]. 1767 +-----------+------------+--------------+------------+------------+ 1768 | Feature | Applicable | RFC | Peer-wise | Requirement| 1769 | | RFCs | Status | agreement | Level | 1770 | | | | required? | | 1771 +===========+============+==============+============+============+ 1772 | Keep Alive| [RFC1122] | None | No | Should not | 1773 | |(discussion)| | | use | 1774 +-----------+------------+--------------+------------+------------+ 1775 | Tiny | [RFC896] | Standard | No | Should not | 1776 | Segment | | | | use | 1777 | Avoidance | | | | | 1778 | (Nagle) | | | | | 1779 +-----------+------------+--------------+------------+------------+ 1780 | Window | [RFC1323] | Proposed | No | Should use | 1781 | Scale | | Standard | | | 1782 +-----------+------------+--------------+------------+------------+ 1783 | Wrapped | [RFC1323] | Proposed | No | Should use | 1784 | Sequence | | Standard | | | 1785 | Protection| | | | | 1786 | (PAWS) | | | | | 1787 +-----------+------------+--------------+------------+------------+ 1788 Table 1 -- Usage of Optional TCP Features 1790 The following sections describe these options in greater detail. 1792 5.2.2.4.1 Keep Alive 1794 Keep Alive speeds the detection and cleanup of dysfunctional TCP 1795 connections by sending traffic when a connection would otherwise be 1796 idle. The issues are discussed in [RFC1122]. 1798 In order to test the device more comprehensively, fibre channel 1799 applications, such as storage, may implement an equivalent keep 1800 alive function at the FC-4 level. Alternatively, periodic liveness 1801 test messages may be issued as described in section 5.2.2.3. 1802 Because of these more comprehensive end-to-end mechanisms and the 1803 considerations described in [RFC1122], keep alive at the transport 1804 layer should not be implemented. 1806 5.2.2.4.2 'Tiny' Segment Avoidance (Nagle) 1808 The Nagle algorithm described in [RFC896] is designed to avoid the 1809 overhead of small segments by delaying transmission in order to 1810 agglomerate transfer requests into a large segment. In iFCP, such 1811 small transfers often contain I/O requests. Hence, the 1813 iFCP Revision 10 February 2002 1815 transmission delay of the Nagle algorithm may decrease I/O 1816 throughput. Therefore, the Nagle algorithm should not be used. 1818 5.2.2.4.3 Window Scale 1820 Window scaling, as specified in [RFC1323], allows full utilization 1821 of links with large bandwidth - delay products and should be 1822 supported by an iFCP implementation. 1824 5.2.2.4.4 Wrapped Sequence Protection (PAWS) 1826 TCP segments are identified with 32-bit sequence numbers. In 1827 networks with large bandwidth - delay products, it is possible for 1828 more than one TCP segment with the same sequence number to be in 1829 flight. In iFCP, receipt of such a sequence out of order may cause 1830 out-of-order frame delivery or data corruption. Consequently, this 1831 feature SHOULD be supported as described in [RFC1323]. 1833 5.2.3 Terminating an iFCP Session 1835 An iFCP session SHALL be terminated or aborted in response to one 1836 of the following events: 1838 a) An LS_RJT response is returned to the gateway that issued the 1839 PLOGI ELS. The gateway SHALL forward the LS_RJT to the local 1840 N_PORT and complete the session as described in section 1841 5.2.3.1. 1843 b) An ACC received from a remote device in response to a LOGO. The 1844 gateway SHALL forward the ACC to the local N_PORT and complete 1845 the session as described in section 5.2.3.1. 1847 c) For an FC frame received from the IP network, a gateway detects 1848 a CRC error in the encapsulation header. The gateway shall 1849 abort the session as described in section 5.2.3.2. 1851 d) The TCP connection associated with the login session fails for 1852 any reason. The gateway detecting the failed connection shall 1853 abort the session as described in section 5.2.3.2. 1855 Upon terminating an iFCP session, the iFCP session descriptor SHALL 1856 be deleted. The disposition of the associated TCP connection is 1857 described in sections 5.2.3.1 and 5.2.3.2. 1859 5.2.3.1 iFCP Session Completion 1861 An iFCP session is completed in response to a rejected PLOGI 1862 request as described in section 5.2.3 or a successful LOGO ELS. 1864 The gateway receiving one of the above responses SHALL issue an 1865 Unbind session control ELS as described in section 6.2. 1867 iFCP Revision 10 February 2002 1869 In response to the Unbind message, either gateway may choose to 1870 close the TCP connection or return it to a pool of unbound 1871 connections. 1873 5.2.3.2 Aborting an iFCP Session 1875 An iFCP session SHALL be aborted if the TCP connection is 1876 spontaneously terminated or whenever one of the following occurs: 1878 a) An encapsulation error is detected as described in section 1879 5.4.3. 1881 b) The gateway receives an encapsulated frame from a gateway 1882 operating in an incompatible address translation mode as 1883 specified in section 4.7.3 or 4.6.2. 1885 In any event, the TCP connection SHOULD be terminated with a 1886 connection reset (RST). If the local N_PORT has logged in to the 1887 remote N_PORT, the gateway SHALL send a LOGO to the local N_PORT. 1889 5.3 IANA Considerations 1891 The IANA-assigned port for iFCP traffic is port number 3420. 1893 An iFCP Portal may initiate a connection using any TCP port number 1894 consistent with its implementation of the TCP/IP stack, provided 1895 each port number is unique. To prevent the receipt of stale data 1896 associated with a previous connection using a given port number, 1897 the provisions of [RFC1323], Appendix B SHOULD be observed. 1899 5.4 Encapsulation of Fibre Channel Frames 1901 This section describes the iFCP encapsulation of fibre channel 1902 frames. The encapsulation is based on the common encapsulation 1903 format defined in [ENCAP]. 1905 The format of an encapsulated frame is shown below: 1907 +--------------------+ 1908 | Header | 1909 +--------------------+-----+ 1910 | SOF | f | 1911 +--------------------+ F r | 1912 | FC frame content | C a | 1913 +--------------------+ m | 1914 | EOF | e | 1915 +--------------------+-----+ 1916 Figure 13 -- Encapsulation Format 1918 The encapsulation consists of a 7-word header, an SOF delimiter 1919 word, the FC frame (including the fibre channel CRC), and an EOF 1921 iFCP Revision 10 February 2002 1923 delimiter word. The header and delimiter formats are described in 1924 the following sections. 1926 When operating in Address Translation mode, (see section 4.7) the 1927 iFCP gateway must recalculate the fibre channel CRC. 1929 5.4.1 Encapsulation Header Format 1931 W|------------------------------Bit------------------------------| 1932 o| | 1933 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1934 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| 1935 +---------------+---------------+---------------+---------------+ 1936 0| Protocol# | Version | -Protocol# | -Version | 1937 +---------------+---------------+---------------+---------------+ 1938 1| Reserved (must be zero) | 1939 +---------------+---------------+---------------+---------------+ 1940 2| LS_COMMAND | iFCP Flags | SOF | EOF | 1941 +-----------+---+---------------+-----------+---+---------------+ 1942 3| Flags | Frame Length | -Flags | -Frame Length | 1943 +-----------+-------------------+-----------+-------------------+ 1944 4| Time Stamp [integer] | 1945 +---------------------------------------------------------------+ 1946 5| Time Stamp [fraction] | 1947 +---------------------------------------------------------------+ 1948 6| CRC | 1949 +---------------------------------------------------------------+ 1951 Common Encapsulation Fields: 1953 iFCP Revision 10 February 2002 1955 Protocol# IANA-assigned protocol number 1956 identifying the protocol using the 1957 encapsulation. For iFCP the value is 1958 (/TBD/). 1960 Version Encapsulation version 1962 -Protocol# Ones complement of the protocol# 1964 -Version Ones complement of the version 1966 Flags Encapsulation flags (see 5.4.1.1) 1968 Frame Length Contains the length of the entire FC 1969 Encapsulated frame including the FC 1970 Encapsulation Header and the FC frame 1971 (including SOF and EOF words) in units 1972 of 32-bit words. 1974 -Flags Ones-complement of the Flags field. 1976 -Frame Length Ones-complement of the Frame Length 1977 field. 1979 Time Stamp [integer] Integer component of the frame time 1980 stamp in SNTP format [RFC2030]. 1982 Time Stamp Fractional component of the time stamp 1983 [fraction] in SNTP format [RFC2030]. 1985 CRC Header CRC. MUST be valid for iFCP. 1987 The time stamp fields are used to enforce the limit on the 1988 lifetime of a fibre channel frame as described in section 1989 8.2.1. 1991 iFCP-specific fields: 1993 iFCP Revision 10 February 2002 1995 LS_COMMAND For a special link service ACC 1996 response to be processed by iFCP, the 1997 LS_COMMAND field SHALL contain bits 31 1998 through 24 of the LS_COMMAND to which 1999 the ACC applies. Otherwise the 2000 LS_COMMAND field shall be set to zero. 2002 iFCP Flags iFCP-specific flags (see below) 2004 SOF Copy of the SOF delimiter encoding 2005 (see section 5.4.2) 2007 EOF Copy of the EOF delimiter encoding 2008 (see section 5.4.2) 2010 The iFCP flags word has the following format: 2012 |------------------------Bit----------------------------| 2013 | | 2014 | 23 22 21 20 19 18 17 16 | 2015 +------+------+------+------+------+------+------+------+ 2016 | Reserved | SES | TRN | SPC | 2017 +------+------+------+------+------+------+------+------+ 2018 Figure 14 -- iFCP Flags Word 2020 iFCP Flags: 2022 SES 1 = Session control frame (TRN and SPC MUST be 2023 0) 2025 TRN 1 = Address transparent mode enabled 2027 0 = Address translation mode enabled 2029 SPC 1 = Frame is part of a link service message 2030 requiring special processing by iFCP prior 2031 to forwarding to the destination N_PORT. 2033 5.4.1.1 Common Encapsulation Flags 2035 The iFCP usage of the common encapsulation flags is shown below: 2037 iFCP Revision 10 February 2002 2039 |------------------------Bit--------------------------| 2040 | | 2041 | 31 30 29 28 27 26 | 2042 +--------------------------------------------+--------+ 2043 | Reserved | CRCV | 2044 +--------------------------------------------+--------+ 2046 For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 2048 5.4.2 SOF and EOF Delimiter Fields 2050 The format of the delimiter fields is shown below. 2052 W|------------------------------Bit------------------------------| 2053 o| | 2054 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 2055 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| 2056 +---------------+---------------+-------------------------------+ 2057 0| SOF | SOF | -SOF | -SOF | 2058 +---------------+---------------+-------------------------------+ 2059 1| | 2060 +----- FC frame content -----+ 2061 | | 2062 +---------------+---------------+-------------------------------+ 2063 n| EOF | EOF | -EOF | -EOF | 2064 +---------------+---------------+-------------------------------+ 2065 Figure 15 -- FC Frame Encapsulation Format 2067 SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the 2068 following subset of the SOF fields described in [ENCAP]. 2070 +-------+----------+ 2071 | FC | | 2072 | SOF | SOF Code | 2073 +-------+----------+ 2074 | SOFi2 | 0x2D | 2075 | SOFn2 | 0x35 | 2076 | SOFi3 | 0x2E | 2077 | SOFn3 | 0x36 | 2078 +-------+----------+ 2079 Table 2-- Translation of FC SOF Values to SOF Field Contents 2081 -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the 2082 ones complement of the value in the SOF fields. 2084 EOF (bits 31-24 and 23-16 in word n): iFCP uses the following 2085 subset of EOF fields specified in [ENCAP]. 2087 iFCP Revision 10 February 2002 2089 +-------+----------+ 2090 | FC | | 2091 | EOF | EOF Code | 2092 +-------+----------+ 2093 | EOFn | 0x41 | 2094 | EOFt | 0x42 | 2095 +-------+----------+ 2096 Table 3 -- Translation of FC EOF Values to EOF Field Contents 2098 -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain the 2099 one's complement of the value in the EOF fields. 2101 iFCP implementations SHALL place a copy of the SOF and EOF 2102 delimiter codes in the appropriate header fields. 2104 5.4.3 Frame Encapsulation 2106 A fibre channel Frame to be encapsulated MUST first be validated as 2107 described in [FC-FS]. Any frames received from a locally attached 2108 fibre channel device that do not pass the validity tests in [FC-FS] 2109 SHALL be discarded by the gateway. 2111 Following frame validation, the S_ID and D_ID fields in the frame 2112 header SHALL be referenced to lookup the iFCP session descriptor 2113 (see section 5.2.2.2). If no iFCP session descriptor exists, the 2114 frame SHALL be discarded. 2116 Frames types submitted for encapsulation and forwarding on the IP 2117 network SHALL have one of the SOF delimiters in Table 2 and an EOF 2118 delimiter from Table 3. Other valid frame types MUST be processed 2119 internally by the gateway as specified in the appropriate fibre 2120 channel specification. 2122 Prior to submitting a frame for encapsulation, a gateway in address 2123 translation mode SHALL replace the D_ID address, and, if processing 2124 a special link service message requiring the inclusion of 2125 supplemental data, SHALL format the frame payload and add the 2126 supplemental information as specified in section 7.1. The gateway 2127 SHALL then calculate a new FC CRC on the reformatted frame. 2129 A gateway in address transparent mode MAY encapsulate and transmit 2130 the frame image without recalculating the FC CRC. 2132 The frame originator MUST then create and fill in the header and 2133 the SOF and EOF delimiter words as specified above. 2135 5.4.4 Frame De-encapsulation 2137 The receiving gateway SHALL perform de-encapsulation as follows: 2139 iFCP Revision 10 February 2002 2141 Upon receiving the encapsulated frame, the gateway SHALL check the 2142 header CRC. If the header CRC is invalid, the gateway SHALL 2143 terminate the iFCP session as described in section 5.2.3.2. 2145 After validating the header CRC, the receiving gateway SHALL verify 2146 the frame propagation delay as described in section 8.2.1. If the 2147 propagation delay is too long, the frame SHALL be discarded. 2148 Otherwise, the gateway SHALL check the SOF and EOF in the 2149 encapsulation header. A frame SHALL be discarded if it has an SOF 2150 code that is not in Table 2 or an EOF code that is not in Table 3. 2152 The gateway shall then de-encapsulate the frame. If operating in 2153 address translation mode, the gateway SHALL: 2155 a) Check the FC CRC and discard the frame if the CRC is invalid. 2157 b) Lookup the iFCP session descriptor using the TCP connection 2158 context and D_ID in the frame header. If no iFCP session 2159 descriptor exists, the frame SHALL be discarded. 2161 c) If operating in address translation mode, replace the S_ID with 2162 the N_PORT alias obtained from the iFCP session descriptor. 2164 d) If processing a special link service message, replace the frame 2165 with a copy whose payload has been modified as specified in 2166 section 7.1. 2168 The de-encapsulated frame SHALL then be delivered to the N_PORT 2169 specified in the D_ID field. If the frame contents have been 2170 modified by the receiving gateway, a new FC CRC SHALL be 2171 calculated. 2173 6. TCP Session Control Messages 2175 TCP session control messages are used to create and manage an iFCP 2176 session as described in section 5.2.2. They are passed between peer 2177 iFCP Portals and are only processed within the iFCP layer. 2179 The message format is based on the fibre channel extended link 2180 service message template shown below. 2182 iFCP Revision 10 February 2002 2184 Word 2185 3124 23<---------------Bits------------------------->0 2186 +------------+------------------------------------------------+ 2187 0| R_CTL | D_ID [0x00 00 00] | 2188 |[Req = 0x22]| [Destination of extended link Service request] | 2189 |[Rep = 0x23]| | 2190 +------------+------------------------------------------------+ 2191 1| CS_CTL | S_ID [0x00 00 00] | 2192 | [0x0] | [Source of extended link service request] | 2193 +------------+------------------------------------------------+ 2194 2|TYPE [0x1] | F_CTL [0] | 2195 +------------+------------------+-----------------------------+ 2196 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | 2197 |[0x0] | | | 2198 +------------+------------------+-----------------------------+ 2199 4| OX_ID [0x0000] | RX_ID_[0x0000] | 2200 +-------------------------------+-----------------------------+ 2201 5| Parameter | 2202 | [ 00 00 00 00 ] | 2203 +-------------------------------------------------------------+ 2204 6| LS_COMMAND | 2205 | [Session Control Command Code] | 2206 +-------------------------------------------------------------+ 2207 7| | 2208 .| Additional Session Control Parameters | 2209 .| ( if any ) | 2210 n| | 2211 +=============================================================+ 2212 n| Fibre Channel CRC | 2213 +| | 2214 1+=============================================================+ 2215 Figure 16 -- Format of Session Control Message 2217 The LS_COMMAND value for the response remains the same as that used 2218 for the request. 2220 The session control ELS frame is terminated with a fibre channel 2221 CRC. The frame SHALL be encapsulated and de-encapsulated according 2222 to the rules specified in section 5.4. 2224 The encapsulation header for the link Service frame carrying a 2225 session control message SHALL be set as follows: 2227 Encapsulation Header Fields: 2229 iFCP Revision 10 February 2002 2231 LS_COMMAND 0 2233 iFCP Flags SES = 1 2235 TRN = 0 2237 INT = 0 2239 SOF code SOFi3 encoding (0x2E) 2241 EOF code EOFt encoding (0x42) 2243 The encapsulation time stamp words SHALL be set as described for 2244 each message type. 2246 The SOF and EOF delimiter words SHALL be set based on the SOF and 2247 EOF codes specified above. 2249 The following lists the session control messages and their 2250 corresponding LS_COMMAND values. 2252 Request LS_COMMAND Short Name iFCP Support 2253 ------- ---------- ---------- ----------- 2254 Connection Bind 0xE0 CBIND REQUIRED 2255 Unbind Connection 0xE4 UNBIND REQUIRED 2256 Test Connection Liveness 0xE5 LTEST REQUIRED 2258 6.1 Connection Bind (CBIND) 2260 As described in section 5.2.2.2, the CBIND message and response are 2261 used to bind an N_PORT login to a specific TCP connection and 2262 establish an iFCP session. In the CBIND request message, the 2263 source and destination N_PORTs are identified by their worldwide 2264 port names. The time stamp words in the encapsulation header SHALL 2265 be set to zero in the request and response message frames. 2267 The following shows the format of the CBIND request. 2269 iFCP Revision 10 February 2002 2271 +------+------------+------------+-----------+----------+ 2272 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2273 +------+------------+------------+-----------+----------+ 2274 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2275 +------+------------+------------+-----------+----------+ 2276 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2277 | | (Seconds) | | | 2278 +------+-------------------------+-----------+----------+ 2279 | 2 | USER INFO | 2280 +------+------------+------------+-----------+----------+ 2281 | 3 | | 2282 +------+ SOURCE N_PORT NAME | 2283 | 4 | | 2284 +------+------------------------------------------------+ 2285 | 5 | | 2286 +------+ DESTINATION N_PORT NAME | 2287 | 6 | | 2288 +------+------------------------------------------------+ 2290 Addr Mode: The addressing mode of the originating 2291 gateway. 0 = Address Translation mode, 1 = 2292 Address Transparent mode. 2294 iFCP Ver: iFCP version number. SHALL be set to 1. 2296 LIVENESS TEST If non-zero, requests that the receiving 2297 INTERVAL: gateway transmit an LTEST message at the 2298 specified interval in seconds. If set to 2299 zero, LTEST messages SHALL NOT be sent. 2301 USER INFO: Contains any data desired by the requestor. 2302 This information MUST be echoed by the 2303 recipient in the CBIND response message. 2305 SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the 2306 N_PORT locally attached to the gateway 2307 originating the CBIND request. 2309 DESTINATION N_PORT The Worldwide Port Name (WWPN) of the 2310 NAME: N_PORT locally attached to the gateway 2311 receiving the CBIND request. 2313 The following shows the format of the CBIND response. 2315 iFCP Revision 10 February 2002 2317 +------+------------+------------+-----------+----------+ 2318 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2319 +------+------------+------------+-----------+----------+ 2320 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2321 +------+------------+------------+-----------+----------+ 2322 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2323 | | (Seconds) | | | 2324 +------+-------------------------+-----------+----------+ 2325 | 2 | USER INFO | 2326 +------+------------+------------+-----------+----------+ 2327 | 3 | | 2328 +------+ SOURCE N_PORT NAME | 2329 | 4 | | 2330 +------+------------------------------------------------+ 2331 | 5 | | 2332 +------+ DESTINATION N_PORT NAME | 2333 | 6 | | 2334 +------+-------------------------+----------------------+ 2335 | 7 | Reserved | CBIND Status | 2336 +------+-------------------------+----------------------+ 2337 | 8 | Reserved | CONNECTION HANDLE | 2338 +------+-------------------------+----------------------+ 2339 Total Length = 36 2341 iFCP Revision 10 February 2002 2343 Addr Mode: The address translation mode of the 2344 responding gateway. 0 = Address 2345 Translation mode, 1 = Address Transparent 2346 mode. 2348 iFCP Ver: iFCP version number. Shall be set to 1. 2350 LIVENESS TEST If non-zero, requests that the gateway 2351 INTERVAL: receiving the CBIND RESPONSE transmit an 2352 LTEST message at the specified interval in 2353 seconds. If zero, LTEST messages SHALL NOT 2354 be sent. 2356 USER INFO: Echoes the value received in the USER INFO 2357 field of the CBIND request message. 2359 SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of 2360 the N_PORT locally attached to the gateway 2361 issuing the CBIND request. 2363 DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of 2364 NAME: the N_PORT locally attached to the gateway 2365 issuing the CBIND response. 2367 CBIND STATUS: Indicates success or failure of the CBIND 2368 request. CBIND values are shown below. 2370 CONNECTION HANDLE: Contains a value assigned by the gateway to 2371 identify the connection. The connection 2372 handle is required when issuing the UNBIND 2373 request. 2375 CBIND Status Description 2376 ------------ ----------- 2378 0 Successful � No other status 2379 1 � 15 Reserved 2380 16 Failed � Unspecified Reason 2381 17 Failed � No such device 2382 18 Failed � N_PORT session already exists 2383 19 Failed � Lack of resources 2384 20 Failed - Incompatible address translation mode 2385 21 Failed - Incorrect protocol version number 2386 Others Reserved 2388 6.2 Unbind Connection (UNBIND) 2390 UNBIND is used to release a bound TCP connection and. optionally, 2391 return it to the pool of unbound TCP connections. This message is 2393 iFCP Revision 10 February 2002 2395 transmitted in the connection that is to be unbound. The time 2396 stamp words in the encapsulation header shall be set to zero in the 2397 request and response message frames. 2399 The following is the format of the UNBIND request message. 2401 +------+------------+------------+-----------+----------+ 2402 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2403 +------+------------+------------+-----------+----------+ 2404 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2405 +------+------------+------------+-----------+----------+ 2406 | 1 | USER INFO | 2407 +------+------------+------------+-----------+----------+ 2408 | 2 | Reserved | CONNECTION HANDLE | 2409 +------+------------+------------+----------------------+ 2410 | 3 | Reserved | 2411 +------+------------+------------+-----------+----------+ 2412 | 4 | Reserved | 2413 +------+------------+------------+-----------+----------+ 2415 USER INFO Contains any data desired by the requestor. 2416 This information MUST be echoed by the 2417 recipient in the UNBIND response message. 2419 CONNECTION HANDLE: Contains the gateway-assigned value from 2420 the CBIND request. 2422 The following shows the format of the UNBIND response message. 2424 +------+------------+------------+-----------+----------+ 2425 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2426 +------+------------+------------+-----------+----------+ 2427 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2428 +------+------------+------------+-----------+----------+ 2429 | 1 | USER INFO | 2430 +------+------------+------------+-----------+----------+ 2431 | 2 | Reserved | CONNECTION HANDLE | 2432 +------+------------+------------+-----------+----------+ 2433 | 3 | Reserved | 2434 +------+------------+------------+-----------+----------+ 2435 | 4 | Reserved | 2436 +------+------------+------------+-----------+----------+ 2437 | 5 | Reserved | UNBIND STATUS | 2438 +------+------------+------------+-----------+----------+ 2440 iFCP Revision 10 February 2002 2442 USER INFO Echoes the value received in the USER INFO 2443 field of the UNBIND request message. 2445 CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in 2446 the UNBIND request message. 2448 UNBIND STATUS: Indicates the success or failure of the 2449 UNBIND request as follows: 2451 Unbind Status Description 2452 ------------- ----------- 2454 0 Successful � No other status 2455 1 � 15 Reserved 2456 16 Failed � Unspecified Reason 2457 18 Failed � Connection ID Invalid 2458 Others Reserved 2460 6.3 LTEST -- Test Connection Liveness 2462 The LTEST message is sent at the interval specified in the CBIND 2463 request or response payload. The LTEST encapsulation time stamp 2464 SHALL be set as described in section 8.2.1 and may be used by the 2465 receiver to compute an estimate of propagation delay. However, the 2466 propagation delay limit SHALL NOT be enforced. 2468 iFCP Revision 10 February 2002 2470 +------+------------+------------+-----------+----------+ 2471 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2472 +------+------------+------------+-----------+----------+ 2473 | 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 | 2474 +------+------------+------------+-----------+----------+ 2475 | 1 | LIVENESS TEST INTERVAL | Reserved | 2476 | | (Seconds) | | 2477 +------+-------------------------+----------------------+ 2478 | 2 | COUNT | 2479 +------+------------+------------+-----------+----------+ 2480 | 3 | | 2481 +------+ SOURCE N_PORT NAME | 2482 | 4 | | 2483 +------+------------------------------------------------+ 2484 | 5 | | 2485 +------+ DESTINATION N_PORT NAME | 2486 | 6 | | 2487 +------+------------------------------------------------+ 2489 LIVENESS TEST Copy of the LIVENESS TEST INTERVAL 2490 INTERVAL: specified in the CBIND request or reply 2491 message. 2493 COUNT: Monotonically increasing value, initialized 2494 to 0 and incremented by one for each 2495 successive LTEST message. 2497 SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME 2498 specified in the CBIND request. 2500 DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT 2501 NAME: NAME specified in the CBIND request. 2503 7. Fibre Channel Link Services 2505 Link services provide a set of fibre channel functions that allow a 2506 port to send control information or request another port to perform 2507 a specific control function. 2509 There are three types of link services: 2511 a) Basic 2513 b) Extended 2515 c) ULP-specific (FC-4) 2517 Each link service message (request and reply) is carried by a fibre 2518 channel sequence, and can be segmented into multiple frames. 2520 iFCP Revision 10 February 2002 2522 The iFCP Layer is responsible for transporting link service 2523 messages across the IP network. This includes mapping Link Service 2524 messages appropriately from the domain of the fibre channel 2525 transport to that of the IP network. This process may require 2526 special processing and the inclusion of supplemental data by the 2527 iFCP layer. 2529 Each link service MUST be processed according to one of the 2530 following rules: 2532 a) Transparent � The link service message and reply MUST be 2533 transported to the receiving N_PORT by the iFCP gateway without 2534 altering the message payload. The link service message and reply 2535 are not processed by the iFCP implementation. 2537 b) Special - Applies to a link service reply or request requiring 2538 iFCP intervention before forwarding to the destination N_PORT. 2539 Such messages may contain fibre channel addresses in the payload 2540 or may require other special processing. 2542 c) Rejected � When issued by a locally attached N_PORT, the 2543 specified link service request MUST be rejected by the iFCP 2544 implementation. The gateway SHALL respond to a rejected link 2545 service message by returning an LS_RJT response with a Reason 2546 Code of 0x0B (Command Not Supported) and a Reason Code 2547 Explanation of 0x0 (No Additional Explanation). 2549 This section describes the processing for special link services, 2550 including the manner in which supplemental data is added to the 2551 message payload. 2553 Appendix A enumerates all link services and the iFCP processing 2554 policy that applies to each. 2556 7.1 Special Link Service Messages 2558 Special link service messages require the intervention of the iFCP 2559 layer before forwarding to the destination N_PORT. Such 2560 intervention is required in order to: 2562 a) Service any link service message that requires special handling, 2563 such as a PLOGI. 2565 b) In address translation mode only, service any link service 2566 message that has an N_PORT address in the payload. 2568 Such messages SHALL be transmitted in a fibre channel frame having 2569 the format shown in Figure 17 for extended link services or Figure 2570 18 for FC-4 link services.: 2572 iFCP Revision 10 February 2002 2574 Word 2575 31 24 23 0 2576 +------------+------------------------------------------------+ 2577 0| R_CTL | D_ID | 2578 |[Req = 0x22]|[Destination of extended link Service request] | 2579 |[Rep = 0x23]| | 2580 +------------+------------------------------------------------+ 2581 1| CS_CTL | S_ID | 2582 | | [Source of extended link service request] | 2583 +------------+------------------------------------------------+ 2584 2| TYPE | F_CTL | 2585 | [0x01] | | 2586 +------------+------------------+-----------------------------+ 2587 3| SEQ_ID | DF_CTL | SEQ_CNT | 2588 +------------+------------------+-----------------------------+ 2589 4| OX_ID | RX_ID | 2590 +-------------------------------+-----------------------------+ 2591 5| Parameter | 2592 | [ 00 00 00 00 ] | 2593 +-------------------------------------------------------------+ 2594 6| LS_COMMAND | 2595 | [Extended Link Service Command Code] | 2596 +-------------==----------------------------------------------+ 2597 7| | 2598 .| Additional Service Request Parameters | 2599 .| ( if any ) | 2600 n| | 2601 +-------------------------------------------------------------+ 2602 Figure 17 -- Format of an Extended Link Service Frame 2604 iFCP Revision 10 February 2002 2606 Word 2607 31 24 23 0 2608 +------------+------------------------------------------------+ 2609 0| R_CTL | D_ID | 2610 |[Req = 0x32]| [Destination of FC-4 link Service request] | 2611 |[Rep = 0x33]| | 2612 +------------+------------------------------------------------+ 2613 1| CS_CTL | S_ID | 2614 | | [Source of FC-4 link service request] | 2615 +------------+------------------------------------------------+ 2616 2| TYPE | F_CTL | 2617 | (FC-4 | | 2618 | specific) | | 2619 +------------+------------------+-----------------------------+ 2620 3| SEQ_ID | DF_CTL | SEQ_CNT | 2621 +------------+------------------+-----------------------------+ 2622 4| OX_ID | RX_ID | 2623 +-------------------------------+-----------------------------+ 2624 5| Parameter | 2625 | [ 00 00 00 00 ] | 2626 +-------------------------------------------------------------+ 2627 6| LS_COMMAND | 2628 | [FC-4 Link Service Command Code] | 2629 +-------------------------------------------------------------+ 2630 7| | 2631 .| Additional Service Request Parameters | 2632 .| ( if any ) | 2633 n| | 2634 +-------------------------------------------------------------+ 2635 Figure 18 -- Format of an FC-4 Link Service Frame 2637 7.2 Link Services Requiring Payload Address Translation 2639 This section describes the handling for link service frames 2640 containing N_PORT addresses in the frame payload. Such addresses 2641 SHALL only be translated when the gateway is operating in address 2642 translation mode. When operating in address transparent mode, 2643 these addresses SHALL NOT be translated and such link service 2644 messages SHALL NOT be sent as special frames unless other 2645 processing by the iFCP layer is required. 2647 Supplemental data includes information required by the receiving 2648 gateway to convert an N_PORT address in the payload to an N_PORT 2649 address in the receiving gateway�s address space. The following 2650 rules define the manner in which such supplemental data shall be 2651 packaged and referenced. 2653 For an N_PORT address field, the gateway originating the frame MUST 2654 set the value in the payload to identify the address translation 2655 type as follows: 2657 iFCP Revision 10 February 2002 2659 0x00 00 01 � The gateway receiving the frame from the IP 2660 network MUST replace the contents of the field with the N_PORT 2661 alias of the frame originator. This translation type MUST be 2662 used when the address to be converted is that of the source 2663 N_PORT. 2665 0x00 00 02 � The gateway receiving the frame from the IP 2666 network MUST replace the contents of the field with the N_PORT 2667 ID of the destination N_PORT. This translation type MUST be 2668 used when the address to be converted is that of the 2669 destination N_PORT 2671 0x00 00 03 � The gateway receiving the frame from the IP 2672 network MUST reference the specified supplemental data to set 2673 the field contents. The supplemental information is the 64-bit 2674 world wide identifier of the N_PORT as set forth in the fibre 2675 channel specification [FC-FS]. If not otherwise part of the 2676 link service payload, this information MUST be appended in 2677 accordance with the applicable link service description. Unless 2678 specified otherwise, this translation type SHALL NOT be used if 2679 the address to be converted corresponds to that of the frame 2680 originator or recipient. 2682 Since fibre channel addressing rules prohibit the assignment of 2683 fabric addresses with a domain I/D of 0, the above codes will never 2684 correspond to valid N_PORT fabric IDs. 2686 For translation type 3, the receiving gateway SHALL obtain the 2687 information needed to fill in the field in the link service frame 2688 payload by converting the specified N_PORT worldwide identifier to 2689 a gateway IP address and N_PORT ID. This information MUST be 2690 obtained through an iSNS name server query. If the N_PORT is 2691 locally attached, the gateway MUST fill in the field with the 2692 N_PORT ID. If the N_PORT is remotely attached, the gateway MUST 2693 fill in the field with the N_PORT alias obtained from the remote 2694 N_PORT descriptor (see section 5.2.2.1). 2696 If the sending gateway cannot obtain the worldwide identifier of an 2697 N_PORT, or the receiving gateway's iSNS query is unsuccessful, the 2698 gateway detecting the error SHALL terminate the request with an 2699 LS_RJT message as described in [FC-FS]. The Reason Code SHALL be 2700 set to 0x07 (protocol error) and the Reason Explanation SHALL be 2701 set to 0x1F (Invalid N_PORT identifier). 2703 Supplemental data is sent with the link service request or ACC 2704 frames in one of the following ways: 2706 a) By appending the necessary data to the end of the link service 2707 frame. 2709 b) By extending the sequence with additional frames. 2711 iFCP Revision 10 February 2002 2713 In the first case, a new frame SHALL be created whose length 2714 includes the supplemental data. The procedure for extending the 2715 link service sequence with additional frames is dependent on the 2716 link service type. 2718 After applying the supplemental data, the receiving gateway SHALL 2719 forward the resulting link service frames to the destination N_PORT 2720 with the supplemental information removed. 2722 When the ACC response requires iFCP intervention, the receiving 2723 gateway MUST act as a proxy for the originator, retaining the state 2724 needed to process the response from the N_PORT to which the request 2725 was directed. 2727 7.3 Fibre Channel Link Services Processed by iFCP 2729 The following Extended and FC-4 Link Service Messages must receive 2730 special processing. 2732 Extended Link Service Messages LS_COMMAND Mnemonic 2733 ------------------------------ ---------- -------- 2734 Abort Exchange 0x06 00 00 00 ABTX 2735 Discover Address 0x52 00 00 00 ADISC 2736 Discover Address Accept 0x02 00 00 00 ADISC ACC 2737 FC Address Resolution Protocol 0x55 00 00 00 FARP-REPLY 2738 Reply 2739 FC Address Resolution Protocol 0x54 00 00 00 FARP-REQ 2740 Request 2741 Logout 0x05 00 00 00 LOGO 2742 Port Login 0x30 00 00 00 PLOGI 2743 Read Exchange Status Block 0x08 00 00 00 RES 2744 Read Exchange Status Block 0x02 00 00 00 RES ACC 2745 Accept 2746 Read Link Error Status Block 0x0F 00 00 00 RLS 2747 Read Sequence Status Block 0x09 00 00 00 RSS 2748 Reinstate Recovery Qualifier 0x12 00 00 00 RRQ 2749 Request Sequence Initiative 0x0A 00 00 00 RSI 2750 Third Party Process Logout 0x24 00 00 00 TPRLO 2751 Third Party Process Logout 0x02 00 00 00 TPRLO ACC 2752 Accept 2754 FC-4 Link Service Messages LS_COMMAND Mnemonic 2755 -------------------------- ---------- -------- 2756 FCP Read Exchange Concise 0x13 00 00 00 REC 2757 FCP Read Exchange Concise 0x02 00 00 00 REC ACC 2758 Accept 2760 Each encapsulated fibre channel frame that is part of a special 2761 link service MUST have the SPC bit set to one in the iFCP FLAGS 2762 field of the encapsulation header as specified in section 5.4.1. 2764 iFCP Revision 10 February 2002 2766 Supplemental data (if any) MUST be appended as described in the 2767 following section. 2769 The formats of each special link service message, including 2770 supplemental data where applicable, are shown in the following 2771 sections. Each description shows the basic format, as specified in 2772 the applicable FC standard, followed by supplemental data as shown 2773 in the example below. 2775 +------+------------+------------+-----------+----------+ 2776 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2777 +------+------------+------------+-----------+----------+ 2778 | 0 | LS_COMMAND | 2779 +------+------------+------------+-----------+----------+ 2780 | 1 | | 2781 | . | | 2782 | . | Link Service Frame Payload | 2783 | | | 2784 | n | | 2785 +======+============+============+===========+==========+ 2786 | n+1 | | 2787 | . | Supplemental Data | 2788 | . | (if any) | 2789 | n+k | | 2790 +======+================================================+ 2791 Figure 19 -- Special Link Service Frame Payload 2793 7.3.1 Special Extended Link Services 2795 The following sections define extended link services for which 2796 special processing is required. 2798 7.3.1.1 Abort Exchange (ABTX) 2800 ELS Format: 2802 +------+------------+------------+-----------+----------+ 2803 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2804 +------+------------+------------+-----------+----------+ 2805 | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | 2806 +------+------------+------------+-----------+----------+ 2807 | 1 | RRQ Status | Exchange Originator S_ID | 2808 +------+------------+------------+-----------+----------+ 2809 | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| 2810 +------+------------+------------+-----------+----------+ 2811 | 3-10 | Optional association header (32 bytes | 2812 +======+============+============+===========+==========+ 2814 iFCP Revision 10 February 2002 2816 Fields Requiring Translation Supplemental Data 2817 Address Translation Type (see (type 3 only) 2818 ------------------- section 7.2) ------------ 2819 ----------- 2821 Exchange Originator 1, 2 N/A 2822 S_ID 2824 Other Special Processing: 2826 None 2828 7.3.1.2 Discover Address (ADISC) 2830 Format of ADISC ELS: 2832 +------+------------+------------+-----------+----------+ 2833 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2834 +------+------------+------------+-----------+----------+ 2835 | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | 2836 +------+------------+------------+-----------+----------+ 2837 | 1 | Reserved | Hard address of ELS Originator | 2838 +------+------------+------------+-----------+----------+ 2839 | 2-3 | Port Name of Originator | 2840 +------+------------+------------+-----------+----------+ 2841 | 4-5 | Node Name of originator | 2842 +------+------------+------------+-----------+----------+ 2843 | 6 | Rsvd | N_PORT ID of ELS Originator | 2844 +======+============+============+===========+==========+ 2846 Fields Requiring Translation Supplemental Data 2847 Address Translation Type (see (type 3 only) 2848 ------------------- section 7.2) ------------ 2849 ------------- 2851 N_PORT ID of ELS 1 N/A 2852 Originator 2854 Other Special Processing: 2856 The Hard Address of the ELS originator SHALL be set to 0. 2858 7.3.1.3 Discover Address Accept (ADISC ACC) 2860 Format of ADISC ACC ELS: 2862 iFCP Revision 10 February 2002 2864 +------+------------+------------+-----------+----------+ 2865 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2866 +------+------------+------------+-----------+----------+ 2867 | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | 2868 +------+------------+------------+-----------+----------+ 2869 | 1 | Reserved | Hard address of ELS Originator | 2870 +------+------------+------------+-----------+----------+ 2871 | 2-3 | Port Name of Originator | 2872 +------+------------+------------+-----------+----------+ 2873 | 4-5 | Node Name of originator | 2874 +------+------------+------------+-----------+----------+ 2875 | 6 | Rsvd | N_PORT ID of ELS Originator | 2876 +======+============+============+===========+==========+ 2878 Fields Requiring Translation Supplemental Data 2879 Address Translation Type (see (type 3 only) 2880 ------------------- section 7.2) ------------ 2881 ------------ 2883 N_PORT ID of ELS 1 N/A 2884 Originator 2886 Other Special Processing: 2888 The Hard Address of the ELS originator SHALL be set to 0. 2890 7.3.1.4 FC Address Resolution Protocol Reply (FARP-REPLY) 2892 The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS 2893 (see section 7.3.1.5) to perform the address resolution services 2894 required by the FC-VI protocol [FC-VI] and the fibre channel 2895 mapping of IP and ARP specified in RFC 2625 [RFC2625]. 2897 Format of FARP-REPLY ELS: 2899 iFCP Revision 10 February 2002 2901 +------+------------+------------+-----------+----------+ 2902 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2903 +------+------------+------------+-----------+----------+ 2904 | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | 2905 +------+------------+------------+-----------+----------+ 2906 | 1 | Match Addr | Requesting N_PORT Identifier | 2907 | | Code Points| | 2908 +------+------------+------------+-----------+----------+ 2909 | 2 | Responder | Responding N_PORT Identifier | 2910 | | Action | | 2911 +------+------------+------------+-----------+----------+ 2912 | 3-4 | Requesting N_PORT Port_Name | 2913 +------+------------+------------+-----------+----------+ 2914 | 5-6 | Requesting N_PORT Node_Name | 2915 +------+------------+------------+-----------+----------+ 2916 | 7-8 | Responding N_PORT Port_Name | 2917 +------+------------+------------+-----------+----------+ 2918 | 9-10 | Responding N_PORT Node_Name | 2919 +------+------------+------------+-----------+----------+ 2920 | 11-14| Requesting N_PORT IP Address | 2921 +------+------------+------------+-----------+----------+ 2922 | 15-18| Responding N_PORT IP Address | 2923 +======+============+============+===========+==========+ 2925 Fields Requiring Translation Supplemental Data 2926 Address Translation Type (see (type 3 only) 2927 ------------------- section 7.2) ----------------- 2928 ------------- 2930 Requesting N_PORT 2 N/A 2931 Identifier 2933 Responding N_PORT 1 N/A 2934 identifier 2936 Other Special Processing: 2938 None. 2940 7.3.1.5 FC Address Resolution Protocol Request (FARP-REQ) 2942 The FARP-REQ ELS is used to in conjunction with the FC-VI protocol 2943 [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP 2944 and FC address resolution in an FC fabric. The FARP-REQ ELS is 2945 usually directed to the fabric broadcast server at well-known 2946 address 0xFF-FF-FF for retransmission to all attached N_PORTs. 2948 iFCP Revision 10 February 2002 2950 Section 9.4 describes the iFCP implementation of FC broadcast 2951 server functionality in an iFCP fabric. 2953 Format of FARP_REQ ELS: 2955 +------+------------+------------+-----------+----------+ 2956 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 2957 +------+------------+------------+-----------+----------+ 2958 | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | 2959 +------+------------+------------+-----------+----------+ 2960 | 1 | Match Addr | Requesting N_PORT Identifier | 2961 | | Code Points| | 2962 +------+------------+------------+-----------+----------+ 2963 | 2 | Responder | Responding N_PORT Identifier | 2964 | | Action | | 2965 +------+------------+------------+-----------+----------+ 2966 | 3-4 | Requesting N_PORT Port_Name | 2967 +------+------------+------------+-----------+----------+ 2968 | 5-6 | Requesting N_PORT Node_Name | 2969 +------+------------+------------+-----------+----------+ 2970 | 7-8 | Responding N_PORT Port_Name | 2971 +------+------------+------------+-----------+----------+ 2972 | 9-10 | Responding N_PORT Node_Name | 2973 +------+------------+------------+-----------+----------+ 2974 | 11-14| Requesting N_PORT IP Address | 2975 +------+------------+------------+-----------+----------+ 2976 | 15-18| Responding N_PORT IP Address | 2977 +======+============+============+===========+==========+ 2979 Fields Requiring Translation Supplemental Data 2980 Address Translation Type (see (type 3 only) 2981 ------------------- section 7.2) ----------------- 2982 ----------- 2984 Requesting N_PORT 3 Requesting N_PORT 2985 Identifier Port Name 2987 Responding N_PORT 3 Responding N_PORT 2988 Identifier Port Name 2990 Other Special Processing: 2992 None. 2994 7.3.1.6 Logout (LOGO) 2996 ELS Format: 2998 iFCP Revision 10 February 2002 3000 +------+------------+------------+-----------+----------+ 3001 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3002 +------+------------+------------+-----------+----------+ 3003 | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | 3004 +------+------------+------------+-----------+----------+ 3005 | 1 | Rsvd | N_PORT ID being logged out | 3006 +------+------------+------------+-----------+----------+ 3007 | 2-3 | Port name of the LOGO originator (8 bytes) | 3008 +======+============+============+===========+==========+ 3010 This ELS shall always be sent as an augmented ELS regardless of the 3011 translation mode in effect. 3013 Fields Requiring Translation Supplemental Data 3014 Address Translation Type(see (type 3 only) 3015 ------------------- section 7.2) -------------- 3016 ----------- 3018 N_PORT ID Being 1 N/A 3019 Logged Out 3021 Other Special Processing: 3023 See section 5.2.3.1. 3025 7.3.1.7 Port Login (PLOGI) and PLOGI ACC 3027 A PLOGI ELS establishes fibre channel communications between two 3028 N_PORTs and triggers the creation of an iFCP session if one does 3029 not exist. 3031 The PLOGI request and ACC response carry information identifying 3032 the originating N_PORT, including a specification of its 3033 capabilities. If the destination N_PORT accepts the login request, 3034 it sends an Accept response (an ACC frame with PLOGI payload), 3035 specifying its capabilities. This exchange establishes the 3036 operating environment for the two N_PORTs. 3038 The following figure is duplicated from [FC-FS], and shows the 3039 PLOGI message format for both the request and Accept (ACC) 3040 response. An N_PORT will reject a PLOGI request by transmitting an 3041 LS_RJT message containing no payload. 3043 iFCP Revision 10 February 2002 3045 +------+------------+------------+-----------+----------+ 3046 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3047 +------+------------+------------+-----------+----------+ 3048 | 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 | 3049 | | Acc = 0x2 | | | | 3050 +------+------------+------------+-----------+----------+ 3051 | 1-4 | Common Service Parameters | 3052 +------+------------+------------+-----------+----------+ 3053 | 5-6 | N_PORT Name | 3054 +------+------------+------------+-----------+----------+ 3055 | 7-8 | Node Name | 3056 +------+------------+------------+-----------+----------+ 3057 | 9-12 | Class 1 Service Parameters | 3058 +------+------------+------------+-----------+----------+ 3059 |13-17 | Class 2 Service Parameters | 3060 +------+------------+------------+-----------+----------+ 3061 |18-21 | Class 3 Service Parameters | 3062 +------+------------+------------+-----------+----------+ 3063 |22-25 | Class 4 Service Parameters | 3064 +------+------------+------------+-----------+----------+ 3065 |26-29 | Vendor Version Level | 3066 +======+============+============+===========+==========+ 3067 Figure 20 -- Format of PLOGI Request and ACC Payloads 3069 Details of the above fields, including common and class-based 3070 service parameters, can be found in [FC-FS]. 3072 Special Processing 3074 As specified in section 5.2.2.2, a PLOGI request addressed to a 3075 remotely attached N_PORT MUST cause the creation of an iFCP 3076 session if one does not exist. Otherwise, the PLOGI and PLOGI 3077 ACC payloads MUST be passed transparently to the destination 3078 N_PORT using the existing iFCP session. In either case, the 3079 SPC bit must be set in the frame encapsulation header as 3080 specified in 5.4.3. 3082 7.3.1.8 Read Exchange Status Block (RES) 3084 ELS Format: 3086 +------+------------+------------+-----------+----------+ 3087 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3088 +------+------------+------------+-----------+----------+ 3089 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3090 +------+------------+------------+-----------+----------+ 3091 | 1 | Rsvd | Exchange Originator S_ID | 3092 +------+------------+------------+-----------+----------+ 3093 | 2 | OX_ID | RX_ID | 3094 +------+------------+------------+-----------+----------+ 3095 | 3-10 | Association header (may be optionally req�d) | 3096 +======+============+============+===========+==========+ 3098 iFCP Revision 10 February 2002 3100 | 11-12| Port name of the Exchange Originator (8 bytes) | 3101 +======+============+============+===========+==========+ 3103 Fields Requiring Translation Supplemental Data 3104 Address Translation Type(see (type 3 only) 3105 ------------------- section 7.2) ------------------ 3106 ----------- 3108 Exchange Originator 1, 2 or 3 Port Name of the 3109 S_ID Exchange Originator 3111 Other Special Processing: 3113 None. 3115 7.3.1.9 Read Exchange Status Block Accept 3117 Format of ELS Accept Response: 3119 +------+------------+------------+-----------+----------+ 3120 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3121 +------+------------+------------+-----------+----------+ 3122 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3123 +------+------------+------------+-----------+----------+ 3124 | 1 | OX_ID | RX_ID | 3125 +------+------------+------------+-----------+----------+ 3126 | 2 | Rsvd | Exchange Originator N_PORT ID | 3127 +------+------------+------------+-----------+----------+ 3128 | 3 | Rsvd | Exchange Responder N_PORT ID | 3129 +------+------------+------------+-----------+----------+ 3130 | 4 | Exchange Status Bits | 3131 +------+------------+------------+-----------+----------+ 3132 | 5 | Reserved | 3133 +------+------------+------------+-----------+----------+ 3134 | 6�n | Service Parameters and Sequence Statuses | 3135 | | as described in [FCS] | 3136 +======+============+============+===========+==========+ 3137 |n+1- | Port name of the Exchange Originator (8 bytes) | 3138 |n+2 | | 3139 +======+============+============+===========+==========+ 3140 |n+3- | Port name of the Exchange Responder (8 bytes) | 3141 |n+4 | | 3142 +======+============+============+===========+==========+ 3144 iFCP Revision 10 February 2002 3146 Fields Requiring Translation Supplemental Data 3147 Address Translation Type(see (type 3 only) 3148 ------------------- section 7.2) ------------------ 3149 ----------- 3151 Exchange Originator 1, 2 or 3 Port Name of the 3152 N_PORT ID Exchange Originator 3154 Exchange Responder 1, 2 or 3 Port Name of the 3155 N_PORT ID Exchange Responder 3157 When supplemental data is required, the ELS SHALL be extended by 4 3158 words as shown above. If the translation type for the Exchange 3159 Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, 3160 the corresponding 8-byte port name SHALL be set to all zeros. 3162 Other Special Processing: 3164 None. 3166 7.3.1.10 Read Link Error Status (RLS) 3168 ELS Format: 3170 +------+------------+------------+-----------+----------+ 3171 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3172 +------+------------+------------+-----------+----------+ 3173 | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | 3174 +------+------------+------------+-----------+----------+ 3175 | 1 | Rsvd | N_PORT Identifier | 3176 +======+============+============+===========+==========+ 3177 | 2-3 | Port name of the N_PORT (8 bytes) | 3178 +======+============+============+===========+==========+ 3180 Fields Requiring Translation Supplemental Data (type 3181 Address Translation Type(see 3 only) 3182 ------------------- section 7.2) ------------------ 3183 ----------- 3185 N_PORT Identifier 1, 2 or 3 Port Name of the N_PORT 3187 Other Special Processing: 3189 None. 3191 7.3.1.11 Read Sequence Status Block (RSS) 3193 ELS Format: 3195 iFCP Revision 10 February 2002 3197 +------+------------+------------+-----------+----------+ 3198 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3199 +------+------------+------------+-----------+----------+ 3200 | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | 3201 +------+------------+------------+-----------+----------+ 3202 | 1 | SEQ_ID | Exchange Originator S_ID | 3203 +------+------------+------------+-----------+----------+ 3204 | 2 | OX_ID | RX_ID | 3205 +======+============+============+===========+==========+ 3206 | 3-4 |Port name of the Exchange Originator (8 bytes) | 3207 +======+============+============+===========+==========+ 3209 Fields Requiring Translation Supplemental Data 3210 Address Translation Type(see (type 3 only) 3211 ------------------- section 7.2) ------------------ 3212 ----------- 3214 Exchange Originator 1, 2 or 3 Port Name of the 3215 S_ID Exchange Originator 3217 Other Special Processing: 3219 None. 3221 7.3.1.12 Reinstate Recovery Qualifier (RRQ) 3223 ELS Format: 3225 +------+------------+------------+-----------+----------+ 3226 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3227 +------+------------+------------+-----------+----------+ 3228 | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | 3229 +------+------------+------------+-----------+----------+ 3230 | 1 | Rsvd | Exchange Originator S_ID | 3231 +------+------------+------------+-----------+----------+ 3232 | 2 | OX_ID | RX_ID | 3233 +------+------------+------------+-----------+----------+ 3234 | 3-10 | Association header (may be optionally req�d) | 3235 +======+============+============+===========+==========+ 3237 Fields Requiring Translation Supplemental Data 3238 Address Translation Type(see (type 3 only) 3239 ------------------- section 7.2) ------------------ 3240 ----------- 3242 Exchange Originator 1 or 2 N/A 3243 S_ID 3245 iFCP Revision 10 February 2002 3247 Other Special Processing: 3249 None. 3251 7.3.1.13 Request Sequence Initiative (RSI) 3253 ELS Format: 3255 +------+------------+------------+-----------+----------+ 3256 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3257 +------+------------+------------+-----------+----------+ 3258 | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | 3259 +------+------------+------------+-----------+----------+ 3260 | 1 | Rsvd | Exchange Originator S_ID | 3261 +------+------------+------------+-----------+----------+ 3262 | 2 | OX_ID | RX_ID | 3263 +------+------------+------------+-----------+----------+ 3264 | 3-10 | Association header (may be optionally req�d) | 3265 +======+============+============+===========+==========+ 3267 Fields Requiring Translation Supplemental Data 3268 Address Translation Type(see (type 3 only) 3269 ------------------- section 7.2) ------------------ 3270 ----------- 3272 Exchange Originator 1 or 2 N/A 3273 S_ID 3275 Other Special Processing: 3277 None. 3279 7.3.1.14 Third Party Process Logout (TPRLO) 3281 TPRLO provides a mechanism for an N_PORT (third party) to remove 3282 one or more process login sessions that exist between the 3283 destination N_PORT and other N_PORTs specified in the command. 3284 This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, 3285 each of which when combined with the destination N_PORT identifies 3286 a process login to be terminated by the command. 3288 iFCP Revision 10 February 2002 3290 +--------+------------+--------------------+----------------------+ 3291 | Word | Bits 31�24 | Bits 23�16 | Bits 15 - 0 | 3292 +--------+------------+--------------------+----------------------+ 3293 | 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length | 3294 +--------+------------+--------------------+----------------------+ 3295 | 1 | TPRLO Logout Parameter Page 0 | 3296 +--------+--------------------------------------------------------+ 3297 | 5 | TPRLO Logout Parameter Page 1 | 3298 +--------+--------------------------------------------------------+ 3299 .... 3300 +--------+--------------------------------------------------------+ 3301 |(4*n)+1 | TPRLO Logout Parameter page n | 3302 +--------+--------------------------------------------------------+ 3303 Figure 21 -- Format of TPRLO ELS 3305 Each TPRLO parameter page contains parameters identifying one or 3306 more image pairs and may be associated with a single FC-4 protocol 3307 type, common to all FC-4 protocol types between the specified image 3308 pair, or global to all specified image pairs. The format of a TPRLO 3309 page requiring address translation is shown in Figure 22. 3310 Additional information on TPRLO can be found in [FC-FS]. 3312 +------+------------+------------+-----------+----------+ 3313 | Word | Bits 31�24 | Bits 23�16 | Bits 15-8 | Bits 7-0 | 3314 +------+------------+------------+-----------+----------+ 3315 | 0 | TYPE Code | TYPE CODE | | 3316 | | or | EXTENSION | TPRLO Flags | 3317 | | Common SVC | | | 3318 | | Parameters | | | 3319 +------+------------+------------+-----------+----------+ 3320 | 1 | Third Party Process Associator | 3321 +------+------------+------------+-----------+----------+ 3322 | 2 | Responder Process Associator | 3323 +------+------------+------------+-----------+----------+ 3324 | 3 | Reserved | Third Party Originator N_PORT ID | 3325 +======+============+============+===========+==========+ 3326 | 4-5 | Worldwide Name of Third Party Originator | 3327 | | N_PORT | 3328 +------+------------------------------------------------+ 3329 Figure 22 -- Format of an Augmented TPRLO Parameter Page 3331 The TPRLO flags that affect supplemented ELS processing are as 3332 follows: 3334 Bit 12: Global Process logout. When set to one, this bit 3335 indicates that all image pairs for all N_PORTs of the 3336 specified FC-4 protocol shall be invalidated. When the 3337 value of this bit is one, only one logout parameter page 3338 is permitted in the TPRLO payload. 3340 Bit 13: Third party Originator N_PORT Validity. When set to 3341 one, this bit indicates that word 3, bits 23-00 (Third 3343 iFCP Revision 10 February 2002 3345 Party Originator N_PORT ID) are meaningful. 3347 If bit 13 has a value of zero and bit 12 has a value of one in the 3348 TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. 3350 Otherwise the originating gateway SHALL process the ELS as follows: 3352 a) The first word of the TPRLO payload SHALL NOT be modified. 3354 b) Each TPRLO parameter page shall be extended by two words as 3355 shown in Figure 22. 3357 c) If word 0, bit 13 (Third Party Originator N_PORT ID validity) 3358 in the TPRLO flags field has a value of one, then the sender 3359 shall place the worldwide port name of the fibre channel 3360 device's N_PORT in the extension words. The N_PORT ID SHALL be 3361 set to 3. Otherwise, the contents of the extension words and 3362 the Third Party Originator N_PORT ID SHALL be set to zero. 3364 d) The ELS originator SHALL set the SPC bit in the encapsulation 3365 header of each augmented frame comprising the ELS (see section 3366 5.4.1). 3368 e) If the ELS contains a single TPRLO parameter page, the 3369 originator SHALL increase the frame length as necessary to 3370 include the extended parameter page. 3372 f) If the ELS to be augmented contains multiple TPRLO parameter 3373 pages, the FC frames created to contain the augmented ELS 3374 payload SHALL NOT exceed the maximum frame size that can be 3375 accepted by the destination N_PORT. 3377 Each fibre channel frame SHALL contain an integer number of 3378 extended TPRLO parameter pages. The maximum number of extended 3379 TPRLO parameter pages in a frame SHALL be limited to the number 3380 that can be held without exceeding the above upper limit. New 3381 frames resulting from the extension of the TPRLO pages to 3382 include the supplemental data shall be created by extending the 3383 SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT 3384 be modified. 3386 The gateway receiving the augmented TPRLO ELS SHALL generate ELS 3387 frames to be sent to the destination N_PORT by copying word 0 of 3388 the ELS payload and processing each augmented parameter page as 3389 follows: 3391 a) If word 0, bit 13 has a value of one, create a parameter page by 3392 copying words 0 through 2 of the augmented parameter page. The 3393 Third Party Originator N_PORT ID in word 3 shall be generated by 3394 referencing the supplemental data as described in section 7.2. 3396 iFCP Revision 10 February 2002 3398 b) If word 0, bit 13 has a value of zero, create a parameter page 3399 by copying words 0 through 3 of the augmented parameter page. 3401 The size of each frame to be sent to the destination N_PORT MUST 3402 NOT exceed the maximum frame size that the destination N_PORT can 3403 accept. The sequence identifier in each frame header SHALL be 3404 copied from the augmented ELS and the sequence count shall be 3405 monotonically increasing. 3407 7.3.1.15 Third Party Logout Accept (TPRLO ACC) 3409 The format of the TPRLO ACC frame is shown in Figure 23. 3411 +--------+------------+--------------------+----------------------+ 3412 | Word | Bits 31�24 | Bits 23�16 | Bits 15 - 0 | 3413 +--------+------------+--------------------+----------------------+ 3414 | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | 3415 +--------+------------+--------------------+----------------------+ 3416 | 1 | TPRLO Logout Parameter Page 0 | 3417 +--------+--------------------------------------------------------+ 3418 | 5 | TPRLO Logout Parameter Page 1 | 3419 +--------+--------------------------------------------------------+ 3420 .... 3421 +--------+--------------------------------------------------------+ 3422 |(4*n)+1 | TPRLO Logout Parameter page n | 3423 +--------+--------------------------------------------------------+ 3424 Figure 23 -- Format of TPRLO ACC ELS 3426 The format of the parameter page and rules for parameter page 3427 augmentation are as specified in section 7.3.1.14. 3429 7.3.2 Special FC-4 Link Services 3431 The following sections define FC-4 link services for which special 3432 processing is required. 3434 7.3.2.1 FC-4 Link Services defined by FCP 3436 7.3.2.1.1 Read Exchange Concise (REC) 3438 Link Service Request Format: 3440 iFCP Revision 10 February 2002 3442 +------+------------+------------+-----------+----------+ 3443 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3444 +------+------------+------------+-----------+----------+ 3445 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3446 +------+------------+------------+-----------+----------+ 3447 | 1 | Rsvd | Exchange Originator S_ID | 3448 +------+------------+------------+-----------+----------+ 3449 | 2 | OX_ID | RX_ID | 3450 +======+============+============+===========+==========+ 3451 | 3-4 |Port name of the exchange originator (8 bytes) | 3452 | | (present only for translation type 3) | 3453 +======+============+============+===========+==========+ 3455 Fields Requiring Translation Supplemental Data 3456 Address Translation Type(see (type 3 only) 3457 ------------------- section 7.2) ------------------ 3458 ----------- 3460 Exchange Originator 1, 2 or 3 Port Name of the 3461 S_ID Exchange 3462 Originator 3464 Other Special Processing: 3466 None. 3468 7.3.2.1.2 Read Exchange Concise Accept (REC ACC) 3470 Format of REC ACC Response: 3472 iFCP Revision 10 February 2002 3474 +------+------------+------------+-----------+----------+ 3475 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3476 +------+------------+------------+-----------+----------+ 3477 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3478 +------+------------+------------+-----------+----------+ 3479 | 1 | OX_ID | RX_ID | 3480 +------+------------+------------+-----------+----------+ 3481 | 2 | Rsvd | Exchange Originator N_PORT ID | 3482 +------+------------+------------+-----------+----------+ 3483 | 3 | Rsvd | Exchange Responder N_PORT ID | 3484 +------+------------+------------+-----------+----------+ 3485 | 4 | Data Transfer Count | 3486 +------+------------+------------+-----------+----------+ 3487 | 5 | Exchange Status | 3488 +======+============+============+===========+==========+ 3489 | 6-7 |Port name of the Exchange Originator (8 bytes) | 3490 +======+============+============+===========+==========+ 3491 | 8-9 |Port name of the Exchange Responder (8 bytes) | 3492 +======+============+============+===========+==========+ 3494 Fields Requiring Translation Supplemental Data 3495 Address Translation Type(see (type 3 only) 3496 ------------------- section 7.2) ------------------ 3497 ----------- 3499 Exchange Originator 1, 2 or 3 Port Name of the 3500 N_PORT ID Exchange Originator 3502 Exchange Responder 1, 2 or 3 Port Name of the 3503 N_PORT ID Exchange Responder 3505 When supplemental data is required, the frame SHALL always be 3506 extended by 4 words as shown above. If the translation type for 3507 the Exchange Originator N_PORT ID or the Exchange Responder N_PORT 3508 ID is 1 or 2, the corresponding 8-byte port name SHALL be set to 3509 all zeros. 3511 Other Special Processing: 3513 None. 3515 7.4 FLOGI Service Parameters Supported by an iFCP Gateway 3517 The FLOGI ELS is issued by an N_PORT that wishes to access the 3518 fabric transport services. 3520 The format of the FLOGI request and FLOGI ACC payloads are 3521 identical to the PLOGI request and ACC payloads described in 3522 section 7.3.1.7. 3524 iFCP Revision 10 February 2002 3526 +------+------------+------------+-----------+----------+ 3527 | Word | Bits 31�24 | Bits 23�16 | Bits 15�8 | Bits 7-0 | 3528 +------+------------+------------+-----------+----------+ 3529 | 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 | 3530 | | Acc = 0x2 | | | | 3531 +------+------------+------------+-----------+----------+ 3532 | 1-4 | Common Service Parameters | 3533 +------+------------+------------+-----------+----------+ 3534 | 5-6 | N_PORT Name | 3535 +------+------------+------------+-----------+----------+ 3536 | 7-8 | Node Name | 3537 +------+------------+------------+-----------+----------+ 3538 | 9-12 | Class 1 Service Parameters | 3539 +------+------------+------------+-----------+----------+ 3540 |13-17 | Class 2 Service Parameters | 3541 +------+------------+------------+-----------+----------+ 3542 |18-21 | Class 3 Service Parameters | 3543 +------+------------+------------+-----------+----------+ 3544 |22-25 | Class 4 Service Parameters | 3545 +------+------------+------------+-----------+----------+ 3546 |26-29 | Vendor Version Level | 3547 +======+============+============+===========+==========+ 3548 Figure 24 -- FLOGI Request and ACC Payload Format 3550 A full description of each parameter is given in [FC-FS]. 3552 This section tabulates the protocol-dependent service parameters 3553 supported by a fabric port attached to an iFCP gateway. 3555 The service parameters carried in the payload of an FLOGI extended 3556 link service request MUST be set in accordance with 3557 Table 4. 3559 iFCP Revision 10 February 2002 3561 +-----------------------------------------+---------------+ 3562 | | Fabric Login | 3563 | Service Parameter | Class | 3564 | +---+---+---+---+ 3565 | | 1 | 2 | 3 | 4 | 3566 +-----------------------------------------+---+---+---+---+ 3567 | Class Validity | n | M | M | n | 3568 +-----------------------------------------+---+---+---+---+ 3569 | Service Options | | 3570 +-----------------------------------------+---+---+---+---+ 3571 | Intermix Mode | n | n | n | n | 3572 +-----------------------------------------+---+---+---+---+ 3573 | Stacked Connect-Requests | n | n | n | n | 3574 +-----------------------------------------+---+---+---+---+ 3575 | Sequential Delivery | n | M | M | n | 3576 +-----------------------------------------+---+---+---+---+ 3577 | Dedicated Simplex | n | n | n | n | 3578 +-----------------------------------------+---+---+---+---+ 3579 | Camp on | n | n | n | n | 3580 +-----------------------------------------+---+---+---+---+ 3581 | Buffered Class 1 | n | n | n | n | 3582 +-----------------------------------------+---+---+---+---+ 3583 | Priority | n | n | n | n | 3584 +-----------------------------------------+---+---+---+---+ 3585 | Initiator/Recipient Control | | 3586 +-----------------------------------------+---+---+---+---+ 3587 | Clock synchronization ELS capable | n | n | n | n | 3588 +-----------------------------------------+---+---+---+---+ 3589 Table 4 -- FLOGI Service Parameter Settings 3591 Notes: 3593 1) "n" indicates a parameter or capability that is not 3594 supported by the iFCP protocol. 3596 2) "M" indicates an applicable parameter that MUST be 3597 supported by an iFCP gateway. 3599 8. iFCP Error Detection 3601 8.1 Overview 3603 [FC-FS] defines error detection and recovery procedures. These 3604 fibre channel-defined mechanisms continue to be available in the 3605 iFCP environment. 3607 8.2 Stale Frame Prevention 3609 Recovery from fibre channel protocol error conditions requires that 3610 frames associated with a failed or aborted exchange drain from the 3611 fabric before exchange resources can be safely reused. 3613 iFCP Revision 10 February 2002 3615 Since a fibre channel fabric may not preserve frame order, there is 3616 no deterministic way to purge such frames. Instead, the fabric 3617 guarantees that frame the lifetime will not exceed a specific limit 3618 (R_A_TOV). 3620 R_A_TOV is defined in [FC-FS] as "the maximum transit time within a 3621 fabric to guarantee that a lost frame will never emerge from the 3622 fabric". For example, a value of 2 x R_A_TOV is the minimum time 3623 that the originator of an ELS request or FC-4 link service request 3624 must wait for the response to that request. The fibre channel 3625 default value for R_A_TOV is 10 seconds. 3627 An iFCP gateway SHALL actively enforce limits on R_A_TOV as 3628 described in section 8.2.1. 3630 8.2.1 Enforcing R_A_TOV Limits 3632 The R_A_TOV limit on frame lifetimes SHALL be enforced by means of 3633 the time stamp in the encapsulation header (see section 5.4.1) as 3634 described in this section. 3636 The budget for R_A_TOV SHOULD include allowances for the 3637 propagation delay through the gateway regions of the sending and 3638 receiving N_PORTs plus the propagation delay through the IP 3639 network. This latter component is referred to in this 3640 specification as IP_TOV. 3642 IP_TOV should be set well below the value of R_A_TOV specified for 3643 the iFCP fabric and should be stored in the iSNS server. IP_TOV 3644 should be set to 50 percent of R_A_TOV. 3646 The following paragraphs describe the requirements for 3647 synchronizing gateway time bases and the rules for measuring and 3648 enforcing propagation delay limits. 3650 The protocol for synchronizing a gateway time base is SNTP 3651 [RFC2030]. In order to insure that all gateways are time-aligned, a 3652 gateway SHOULD obtain the address of an SNTP-compatible time server 3653 via an iSNS query. If multiple time server addresses are returned 3654 by the query, the servers must be synchronized and the gateway may 3655 use any server in the list. Alternatively, the server may return a 3656 multicast group address in support of operation in Anycast mode. 3657 Implementation of Anycast mode is as specified in [RFC2030], 3658 including the precautions defined in that document. Multicast mode 3659 SHOULD NOT be used. 3661 An SNTP server may use any one of the time reference sources listed 3662 in [RFC2030]. The resolution of the time reference MUST be 125 3663 milliseconds or better. 3665 Stability of the SNTP server and gateway time bases should be 100 3666 ppm or better. 3668 iFCP Revision 10 February 2002 3670 With regard to its time base, the gateway is in either the 3671 Synchronized or Unsynchronized state. When in the Unsynchronized 3672 state, the gateway SHALL: 3674 a) Set the time stamp field to 0,0 for all outgoing frames 3676 b) Ignore the time stamp field for all incoming frames. 3678 When in the synchronized state, the gateway SHALL 3680 a) Set the time stamp field for each outgoing frame in accordance 3681 with the gateway's internal time base 3683 b) Check the time stamp field of each incoming frame, following 3684 validation of the encapsulation header CRC as described in 3685 section 5.4.4. 3687 c) If the incoming frame has a time stamp of 0,0, the receiving 3688 gateway SHALL NOT test the frame to determine if it is stale. 3690 d) If the incoming frame has a non-zero time stamp, the receiving 3691 gateway SHALL compute the absolute value of the time in flight 3692 and SHALL compare it against the value of IP_TOV specified for 3693 the IP fabric. 3695 e) If the result in step (d) exceeds IP_TOV, the encapsulated 3696 frame shall be discarded. Otherwise, the frame shall be de- 3697 encapsulated as described in section 5.4.4. 3699 A gateway SHALL enter the Synchronized state upon receiving a 3700 successful response to an SNTP query. 3702 A gateway shall enter the Unsynchronized state: 3704 a) Upon power up and before successful completion of an SNTP query 3706 b) Whenever the gateway looses contact with the SNTP server such 3707 that the gateway's time base may no longer be in alignment with 3708 that of the SNTP server. The criterion for determining loss of 3709 contact is implementation specific. 3711 Following loss of contact, it is recommended that the gateway enter 3712 the Unsynchronized state when the estimated time base drift 3713 relative to the SNTP reference is greater than ten percent of the 3714 IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and 3715 IP_TOV equals 5 seconds, the maximum allowable loss of contact 3716 duration would be about 42 minutes.) 3718 In response to loss of synchronization, a gateway enforcing R_A_TOV 3719 limits as described in this section MUST abort all iFCP sessions as 3720 described in section 5.2.3.2. 3722 iFCP Revision 10 February 2002 3724 9. Fabric Services Supported by an iFCP implementation 3726 An iFCP gateway implementation MUST support the following fabric 3727 services: 3729 N_PORT ID Value Description Section 3730 --------------- ----------- ------- 3731 0xFF-FF-FE F_PORT Server 9.1 3733 0xFF-FF-FD Fabric Controller 9.2 3735 0xFF-FF-FC Directory/Name Server 9.3 3737 In addition, an iFCP gateway MAY support the FC broadcast server 3738 functionality described in section 9.4. 3740 9.1 F_PORT Server 3742 The F_PORT server SHALL support the FLOGI ELS as described in 3743 section 7.4 as well as the following ELSs specified in [FC-FS]: 3745 a) Request for fabric service parameters (FDISC), 3747 b) Request for the link error status (RLS), 3749 c) Read Fabric Timeout Values (RTV). 3751 9.2 Fabric Controller 3753 The Fabric Controller SHALL support the following ELSs as specified 3754 in [FC-FS]: 3756 a) State Change Notification (SCN), 3758 b) Registered State Change Notification (RSCN), 3760 c) State Change Registration (SCR). 3762 9.3 Directory/Name Server 3764 The Directory/Name server provides a registration service allowing 3765 an N_PORT to record or query the database for information about 3766 other N_PORTs. The services are defined in [FC-GS3]. The queries 3767 are issued as FC-4 transactions using the FC-CT command transport 3768 protocol specified in [FC-GS3]. 3770 iFCP Revision 10 February 2002 3772 In iFCP, each name server request MUST be translated to the 3773 appropriate iSNS query defined in [ISNS]. The definitions of name 3774 server objects are specified in [FC-GS3]. 3776 The name server SHALL support record and query operations for 3777 directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) 3778 and MAY support the FC-4 specific services as defined in [FC-GS3]. 3780 9.4 Broadcast Server 3782 Fibre channel frames are broadcast throughout the fabric by 3783 addressing them to the fibre channel broadcast server at well-known 3784 fibre channel address 0xFF-FF-FF. The broadcast server then 3785 replicates and delivers the frame to each attached N_PORT in all 3786 zones to which the originating device belongs. Only class 3 3787 (datagram) service is supported. 3789 In an iFCP system, the fibre channel broadcast function is emulated 3790 by means of a two-tier architecture comprised of the following 3791 elements: 3793 a) A local broadcast server residing in each iFCP gateway. The 3794 local server distributes broadcast traffic within the gateway 3795 region and forwards outgoing broadcast traffic to a global 3796 server for distribution throughout the iFCP fabric. 3798 b) A global broadcast server which re-distributes broadcast 3799 traffic to the local server in each participating gateway. 3801 c) An iSNS discovery domain defining the scope over which 3802 broadcast traffic is propagated. The discovery domain is 3803 populated with a global broadcast server and the set of local 3804 servers it supports. 3806 The local and global broadcast servers are logical iFCP devices 3807 that communicate using the iFCP protocol. The servers have an 3808 N_PORT Network Address consisting of an iFCP portal address and an 3809 N_PORT ID set to the well-known fibre channel address of the FC 3810 broadcast server (0xFF-FF-FF). 3812 As noted above, an N_PORT originates a broadcast by directing frame 3813 traffic to the fibre channel broadcast server. The gateway-resident 3814 local server distributes a copy of the frame locally and forwards a 3815 copy to the global server for redistribution to the local servers 3816 on other gateways. The global server MUST NOT echo a broadcast 3817 frame to the originating local server. 3819 9.4.1 Establishing the Broadcast Configuration 3821 The broadcast configuration is managed using facilities provided by 3822 the iSNS server. Specifically: 3824 iFCP Revision 10 February 2002 3826 a) An iSNS discovery domain is created and seeded with the network 3827 address of the global broadcast server N_PORT. The global 3828 server is identified as such by setting the appropriate N_PORT 3829 entity attribute. 3831 b) Using the management interface, each broadcast server is preset 3832 with the identity of the broadcast domain. 3834 During power up, each gateway SHALL invoke the iSNS service to 3835 register its local broadcast server in the broadcast discovery 3836 domain. After registration, the local server SHALL wait for the 3837 global broadcast server to establish an iFCP session. 3839 The global server SHALL register with the iSNS server as follows: 3841 a) The server SHALL query the iSNS name server by attribute to 3842 obtain the worldwide port name of the N_PORT pre-configured to 3843 provide global broadcast services. 3845 b) If the worldwide port name obtained above does not correspond to 3846 that of the server issuing the query, the N_PORT SHALL NOT 3847 perform global broadcast functions for N_PORTs in that discovery 3848 domain. 3850 c) Otherwise, the global server N_PORT SHALL register with the 3851 discovery domain and query the iSNS server to identify all 3852 currently-registered local servers. 3854 d) The global broadcast server SHALL initiate an iFCP session with 3855 each local broadcast server in the domain. When a new local 3856 server registers, the global server SHALL receive a state change 3857 notification and respond by initiating an iFCP session with the 3858 newly added server. The gateway SHALL obtain these 3859 notifications using the iSNS provisions for lossless delivery. 3861 Upon receiving the CBIND request to initiate the iFCP session, the 3862 local server SHALL record the worldwide port name and N_PORT 3863 network address of the global server. 3865 9.4.2 Broadcast Session Management 3867 After the initial broadcast session is established, the local or 3868 global broadcast server MAY choose to manage the session in one of 3869 the following ways depending on resource requirements and the 3870 anticipated level of broadcast traffic: 3872 a) A server MAY keep the session open continuously. Since 3873 broadcast sessions are often quiescent for long periods of 3874 time, the server SHOULD monitor session connectivity as 3875 described in section 5.2.2.3. 3877 iFCP Revision 10 February 2002 3879 b) A server MAY open the broadcast session on demand only when 3880 broadcast traffic is to be sent. If the session is reopened by 3881 the global server, the local server SHALL replace the 3882 previously recorded network address of the global broadcast 3883 server. 3885 10. iFCP Security 3887 10.1 Overview 3889 iFCP relies upon the IPSec protocol suite to provide data 3890 confidentiality and authentication services and IKE as the key 3891 management protocol. Section 10.2 describes the security 3892 requirements arising from iFCP�s operating environment while 3893 Section 10.3 describes the resulting design choices, their 3894 requirement levels, and how they apply to the iFCP protocol. 3896 Detailed considerations for use of IPsec and IKE with the iFCP 3897 protocol can be found in [SECIPS]. 3899 10.2 iFCP Security Threats and Scope 3901 10.2.1 Context 3903 iFCP is a protocol designed for use by gateway devices deployed in 3904 enterprise data centers. Such environments typically have security 3905 gateways designed to provide network security through isolation 3906 from public networks. Furthermore, iFCP data may need to traverse 3907 security gateways in order to support SAN-to-SAN connectivity 3908 across public networks. 3910 10.2.2 Security Threats 3912 Communicating iFCP gateways may be subjected to attacks, including 3913 attempts by an adversary to: 3915 a) Acquire confidential data and identities by snooping data 3916 packets. 3918 b) Modify packets containing iFCP data and control messages. 3920 c) Inject new packets into the iFCP session. 3922 d) Hijack the TCP connection carrying the iFCP session. 3924 e) Launch denial of service attacks against the iFCP gateway. 3926 f) Disrupt the security negotiation process. 3928 g) Impersonate a legitimate security gateway. 3930 h) Compromise communication with the iSNS server. 3932 iFCP Revision 10 February 2002 3934 It is imperative to thwart these attacks, given that an iFCP 3935 gateway is the last line of defense for a whole fibre channel 3936 island, which may include several hosts and fibre channel switches. 3937 To do so, the iFCP protocol MUST support confidentiality, data 3938 origin authentication, integrity, and replay protection on a per- 3939 datagram basis. It also MUST provide bi-directional authentication 3940 of the communication endpoints. Finally, it MUST have a scalable 3941 approach to key management. Conformant implementations of the iFCP 3942 protocol MAY use such security definitions. 3944 10.2.3 Interoperability with Security Gateways 3946 Enterprise data center networks are considered mission-critical 3947 facilities that must be isolated and protected from all possible 3948 security threats. Such networks are usually protected by security 3949 gateways, which at a minimum provide a shield against denial of 3950 service attacks. The iFCP security architecture is capable of 3951 leveraging the protective services of the existing security 3952 infrastructure, including firewall protection, NAT and NAPT 3953 services, and IPSec VPN services available on existing security 3954 gateways. 3956 10.2.4 Authentication 3958 iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by 3959 either or both peer gateways. Consequently, bi-directional 3960 authentication of peer gateways MUST be provided. 3962 iFCP gateways MUST use Discovery Domain information obtained from 3963 the iSNS server [ISNS] to determine whether the initiating fibre 3964 channel N_PORT should be allowed access to the target N_PORT. 3965 N_PORT identities used in the Port Login (PLOGI) process shall be 3966 considered authenticated provided the PLOGI request is received 3967 from the remote gateway over a secure, IPSec-protected connection. 3969 There is no requirement that the identities used in authentication 3970 be kept confidential. 3972 10.2.5 Confidentiality 3974 iFCP traffic may traverse insecure public networks, and therefore 3975 implementations MUST have per-packet encryption capabilities to 3976 provide confidentiality. 3978 10.2.6 Rekeying 3980 Due to the high data transfer rates and the amount of data 3981 involved, an iFCP implementation MUST support the capability to 3982 rekey each phase 2 security association in the time intervals 3983 dictated by sequence number space exhaustion at a given link rate. 3984 In the rekeying scenario described in [SECIPS], for example, 3986 iFCP Revision 10 February 2002 3988 rekeying events happen as often as every 27.5 seconds at 10 Gbps 3989 rates. 3991 The iFCP gateway MUST provide the capability for forward secrecy in 3992 the rekeying process. 3994 10.2.7 Authorization 3996 Authorization is outside of the scope of this specification, and is 3997 seen as fully orthogonal to the iFCP security design. Such design, 3998 however, includes key authorization-enabling features in the form 3999 of Identity Payload (e.g., ID_FQDN), certificate-based 4000 authentication (e.g., with X509v3 certificates), and discovery 4001 domains [ISNS]. 4003 10.2.8 Policy control 4005 This specification allows any and all security mechanisms in an 4006 iFCP gateway to be administratively disabled. Security policies 4007 MUST have at most iFCP Portal resolution. Administrators may gain 4008 control over security policies through an adequately secured 4009 interaction with a management interface or with iSNS. 4011 10.2.9 iSNS Role 4013 iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways 4014 use iSNS for discovery services, and MAY use security policies 4015 configured in the iSNS database as the basis for algorithm 4016 negotiation in IKE. The iSNS specification defines mechanisms to 4017 secure communication between an iFCP gateway and iSNS server(s). 4018 Additionally, such specification indicates how elements of security 4019 policy concerning individual iFCP sessions can be retrieved from 4020 iSNS server(s). 4022 10.3 iFCP Security Design 4024 10.3.1 Enabling Technologies 4026 Applicable technology from IPsec and IKE is defined in the 4027 following suite of specifications: 4029 [RFC2401] Security Architecture for the Internet Protocol 4031 [RFC2402] IP Authentication Header 4033 [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH 4035 [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV 4037 [RFC2406] IP Encapsulating Security Payload 4039 iFCP Revision 10 February 2002 4041 [RFC2407] The Internet IP Security Domain of Interpretation for 4042 ISAKMP 4044 [RFC2408] Internet Security Association and Key Management 4045 Protocol (ISAKMP) 4047 [RFC2409] The Internet Key Exchange (IKE) 4049 [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC 4051 [RFC2451] The ESP CBC-Mode Cipher Algorithms 4053 [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains 4055 The implementation of IPsec and IKE is required according the 4056 following guidelines. 4058 Support for the IP Encapsulating Security Payload (ESP) [RFC2406] 4059 is MANDATORY to implement. iFCP implementations MUST support anti- 4060 replay services. 4062 For data origin authentication and integrity with ESP, HMAC with 4063 SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption 4064 Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining 4065 [XCBC] SHOULD be implemented in accordance with [AESCBC]. 4067 For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be 4068 implemented, and AES counter mode encryption [AESCTR] SHOULD be 4069 implemented according to [AESCTR2]. NULL encryption MUST be 4070 supported as well, as defined in [RFC2410]. DES in CBC mode SHOULD 4071 NOT be used due to its inherent weakness. Since it is known to be 4072 crackable with modest computation resources, it is inappropriate 4073 for use in any iFCP deployment scenario. 4075 A conformant iFCP protocol implementation MUST implement IPsec ESP 4076 [RFC2406] in tunnel mode [RFC2401]. However, it shall be noted that 4077 Transport mode MUST be implemented in host scenarios where it is 4078 required for compliance with [RFC2401]. 4080 Regarding key management, iFCP implementations MUST support IKE 4081 [RFC2409] for bi-directional peer authentication, negotiation of 4082 security associations, and key management, using the IPsec DOI. 4083 There is no requirement that the identities used in authentication 4084 be kept confidential. Manual keying MUST NOT be used since it does 4085 not provide the necessary keying support. According to [RFC2409], 4086 pre-shared secret key authentication is MANDATORY to implement, 4087 whereas certificate-based peer authentication using digital 4088 signatures MAY be implemented (see section 10.3.3 regarding the use 4089 of certificates). [RFC2409] defines the following requirement 4090 levels for IKE Modes: 4092 iFCP Revision 10 February 2002 4094 Phase-1 Main Mode MUST be implemented 4096 Phase-1 Aggressive Mode SHOULD be implemented 4098 Phase-2 Quick Mode MUST be implemented 4100 Phase-2 Quick Mode with key exchange payload MUST be implemented. 4102 With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with 4103 pre-shared keys, due to Main Mode�s vulnerability to man-in-the- 4104 middle-attackers when group pre-shared keys are used. In this 4105 scenario, Aggressive Mode SHOULD be used instead. iFCP therefore 4106 requires that Aggressive Mode MUST be implemented as a valid 4107 alternative to Main Mode. Peer authentication using the public key 4108 encryption methods outlined in [RFC2409] SHOULD NOT be used. 4110 The Phase 2 Quick Mode exchanges used to negotiate protection for 4111 the SAs used by iFCP MUST explicitly carry the Identity Payload 4112 fields (IDci and IDcr). The DOI [RFC2407] provides for several 4113 types of Identity Payloads. Conformant iFCP implementations will 4114 typically use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack 4115 supports IPv6), or ID_FQDN Identity Payloads. The ID_USER_FQDN, IP 4116 Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN Identity 4117 Payloads SHOULD NOT be used. The ID_KEY_ID Identity Payload MUST 4118 NOT be used. 4120 10.3.2 Use of IKE and IPsec 4122 A conformant iFCP Portal is capable of establishing one or more IKE 4123 Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase- 4124 1 SA may be established when an iFCP Portal is initialized, or may 4125 be deferred until the first TCP connection with security 4126 requirements is established. 4128 An IKE Phase-2 SA protects one or more TCP connections within the 4129 same iFCP Portal. More specifically, the successful establishment 4130 of an IKE Phase-2 SA results in the creation of two uni-directional 4131 IPsec SAs fully qualified by the tuple . These SAs protect the setup process of the 4133 underlying TCP connections and all their subsequent TCP traffic. 4134 Each of the TCP connections protected by an SA is either in the 4135 unbound state, or is bound to a specific iFCP session. 4137 In summary, at any point in time: 4139 -- There exist 0..M IKE Phase-1 SAs between peer iFCP portals 4141 -- Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs 4143 -- Each IKE Phase-2 SA protects 0..Z TCP connections 4145 iFCP Revision 10 February 2002 4147 The creation of an IKE Phase-2 SA may be triggered by a policy rule 4148 supplied through a management interface or by iFCP Portal 4149 properties registered with the iSNS server. Similarly, the use of a 4150 Key Exchange payload in Quick Mode for perfect forward secrecy may 4151 be dictated through a management interface or by an iFCP Portal 4152 policy rule registered with the iSNS server. 4154 If an iFCP implementation makes use of unbound TCP connections, and 4155 such connections belong to an iFCP Portal with security 4156 requirements, then the unbound connections MUST be protected by an 4157 SA at all times just like bounded connections. 4159 Upon receiving an IKE Phase-2 delete message, there is no 4160 requirement to terminate the protected TCP connections or delete 4161 the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be 4162 associated with multiple TCP connections, terminating such 4163 connections might in fact be inappropriate and untimely. An iFCP 4164 Portal must instead attempt to create a new Phase-2 SA while there 4165 are outstanding iFCP sessions. 4167 To minimize the number of active Phase-2 SAs, IKE Phase-2 delete 4168 messages may be sent for Phase-2 SAs whose TCP connections have not 4169 handled data traffic for a while. To minimize the use of SA 4170 resources while the associated TCP connections are idle, creation 4171 of a new SA may be deferred until new data is to be sent over the 4172 connections. 4174 10.3.3 Signatures and Certificate-based Authentication 4176 Conformant iFCP implementations MAY support peer authentication via 4177 digital signatures and certificates. When certificate 4178 authentication is chosen within IKE, each iFCP gateway needs the 4179 certificate credentials of each peer iFCP gateway in order to 4180 establish a security association with that peer. 4182 Certificate credentials used by iFCP gateways MUST be those of the 4183 machine. Certificate credentials MAY be bound to the interface (IP 4184 Address or FQDN) of the iFCP gateway used for the iFCP session, or 4185 the fabric WWN of the iFCP gateway itself. Since the value of a 4186 machine certificate is inversely proportional to the ease with 4187 which an attacker can obtain one under false pretenses, it is 4188 advisable that the machine certificate enrollment process be 4189 strictly controlled. For example, only administrators may have the 4190 ability to enroll a machine with a machine certificate. User 4191 certificates SHOULD NOT be used by iFCP gateways for establishment 4192 of SA's protecting iFCP sessions. 4194 If the gateway does not have the peer iFCP gateway's certificate 4195 credentials, then it can obtain them by 4197 a) Using the iSNS protocol to query for the peer gateway's 4198 certificate(s) stored in a trusted iSNS server, or 4200 iFCP Revision 10 February 2002 4202 b) Through use of the ISAKMP Certificate Request Payload (CRP) 4203 [RFC2408] to request the certificate(s) directly from the peer 4204 iFCP gateway. 4206 When certificate chains are long enough, then IKE exchanges using 4207 UDP as the underlying transport may yield IP fragments, which are 4208 known to work poorly across some intervening routers, firewalls, 4209 and NA(P)T boxes. As a result, the endpoints may be unable to 4210 establish an IPsec security association. 4212 Due to these fragmentation shortcomings, IKE is most appropriate 4213 for intra-domain usage. Known solutions to the fragmentation 4214 problem are to send the end-entry machine certificate rather than 4215 the chain, to reduce the size of the certificate chain, to use IKE 4216 implementations over a reliable transport protocol (e.g., TCP) 4217 assisted by Path MTU discovery and code against black-holing as in 4218 [RFC2923], or to install network components that can properly 4219 handle fragments. 4221 IKE negotiators SHOULD check the pertinent Certificate Revocation 4222 List (CRL) [RFC2408] before accepting a certificate for use in 4223 IKE's authentication procedures. 4225 10.4 iSNS and iFCP Security 4227 iFCP implementations MUST use iSNS for discovery and management 4228 services. Consequently, the security of the iSNS protocol has an 4229 impact on the security of iFCP gateways. For a discussion of 4230 potential threats to iFCP gateways through use of iSNS, see [ISNS]. 4232 To provide security for iFCP gateways using the iSNS protocol for 4233 discovery and management services, the IPSec/ESP protocol in tunnel 4234 mode MUST be supported for iFCP gateways. Further discussion of 4235 iSNS security implementation requirements is found in [ISNS]. Note 4236 that iSNS security requirements match those for iFCP described in 4237 section 10.3. 4239 10.5 Use of iSNS to Distribute Security Policy 4241 Once communication between iFCP gateways and the iSNS server have 4242 been secured through use of IPSec, the iFCP gateways have the 4243 capability to discover the security settings that they need to use 4244 (or not use) to protect iFCP traffic. This provides a potential 4245 scaling advantage over device-by-device configuration of individual 4246 security policies for each iFCP gateway. It also provides an 4247 efficient means for each iFCP gateway of discovering the use or 4248 non-use of specific security capabilities by peer gateways. 4250 Further discussion on use of iSNS to distribute security policies 4251 is found in [ISNS]. 4253 10.6 Minimal Security Policy for an iFCP gateway 4254 iFCP Revision 10 February 2002 4256 An iFCP implementation may be able to administratively disable 4257 security mechanisms for an iFCP Portal through a management 4258 interface or through security policy elements set in the iSNS 4259 server. As a consequence, IKE or IPsec security associations will 4260 not be established for any iFCP sessions that traverse the portal. 4262 For most IP networks, it is inappropriate to assume physical 4263 security, administrative security, and correct configuration of the 4264 network and all attached nodes (a physically isolated network in a 4265 test lab may be an exception). Therefore, authentication SHOULD be 4266 used in order to provide a minimal assurance that connections have 4267 initially been opened with the intended counterpart. The minimal 4268 iFCP security policy thus only states that an iFCP gateway SHOULD 4269 authenticate its iSNS server(s) as described in [ISNS]. 4271 11. Quality of Service Considerations 4273 11.1 Minimal requirements 4275 Conforming iFCP protocol implementations SHALL correctly 4276 communicate gateway-to-gateway even across one or more intervening 4277 best-effort IP regions. The timings with which such gateway-to 4278 gateway communication is performed, however, will greatly depend 4279 upon BER, packet losses, latency, and jitter experienced throughout 4280 the best-effort IP regions. The higher these parameters, the higher 4281 will be the gap measured between iFCP observed behaviors and 4282 baseline iFCP behaviors (i.e., as produced by two iFCP gateways 4283 directly connected to one another). 4285 11.2 High-assurance 4287 It is expected that many iFCP deployments will benefit from a high 4288 degree of assurance regarding the behavior of intervening IP 4289 regions, with resulting high-assurance on the overall end-to-end 4290 path, as directly experienced by fibre channel applications. Such 4291 assurance on the IP behaviors stems from the intervening IP regions 4292 supporting standard Quality-of-Service (QoS) techniques, fully 4293 complementary to iFCP, such as: 4295 a) Congestion avoidance by over-provisioning of the network, 4297 b) Integrated Services [RFC1633] QoS, 4299 c) Differentiated Services [RFC2475] QoS 4301 d) Multi-Protocol Label Switching [RFC3031]. 4303 One may load an MPLS forwarding equivalence class (FEC) with QoS 4304 class significance, in addition to other considerations such as 4305 protection and diversity for the given path. The complementarity 4306 and compatibility of MPLS with Differentiated Services is 4308 iFCP Revision 10 February 2002 4310 explored in [MPSLDS], wherein the PHB bits are copied to the EXP 4311 bits of the MPLS shim header. 4313 In the most general definition, two iFCP gateways are separated by 4314 one or more independently managed IP regions, some of which 4315 implement some of the QoS solutions mentioned above. A QoS-capable 4316 IP region supports the negotiation and establishment of a service 4317 contract specifying the forwarding service through the region. Such 4318 contract and its negotiation rules are outside the scope of this 4319 document. In the case of IP regions with DiffServ QoS, the reader 4320 should refer to Service Level Specifications (SLS) and Traffic 4321 Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other 4322 aspects of a service contract are expected to be non-technical and 4323 thus outside of the IETF scope. 4325 Due to the fact that fibre channel Class 2 and Class 3 do not 4326 currently support fractional bandwidth guarantees, and that iFCP is 4327 committed to supporting fibre channel semantics, it is impossible 4328 for an iFCP gateway to autonomously infer bandwidth requirements 4329 from streaming fibre channel traffic. Rather, the requirements on 4330 bandwidth or other network parameters need to be administratively 4331 set into an iFCP gateway, or into the entity that will actually 4332 negotiate the forwarding service on the gateway's behalf. Depending 4333 on the QoS techniques available, the stipulation of a forwarding 4334 service may require interaction with network ancillary functions 4335 such admission control and bandwidth brokers (via RSVP or other 4336 signaling protocols that an IP region may accept). 4338 The administrator of a iFCP gateway may negotiate a forwarding 4339 service with IP region(s) for one, several, or all of an iFCP 4340 gateway's TCP sessions used by an iFCP gateway. Alternately, this 4341 responsibility may be delegated to a node downstream. Since one TCP 4342 connection is dedicated to each iFCP session, the traffic in an 4343 individual N_PORT to N_PORT session can be singled out by iFCP- 4344 unaware network equipment as well. 4346 To render the best emulation of fibre channel possible over IP, it 4347 is anticipated that typical forwarding services will specify a 4348 fixed amount of bandwidth, null losses, and, to a lesser degree of 4349 relevance, low latency, and low jitter. For example, an IP region 4350 using DiffServ QoS may support SLSs of this nature by applying EF 4351 DSCPs to the iFCP traffic. 4353 12. Author's Addresses 4355 Charles Monia Franco Travostino 4356 Rod Mullendore Director, Content 4357 Josh Tseng Internetworking Lab, 4358 Nortel Networks 4359 Nishan Systems 3 Federal Street 4360 3850 North First Street Billerica, MA 01821 4361 San Jose, CA 95134 Phone: 978-288-7708 4363 iFCP Revision 10 February 2002 4365 Phone: 408-519-3986 Email: 4366 Email: travos@nortelnetworks.com 4367 cmonia@nishansystems.com 4369 David Robinson Wayland Jeong 4370 Sun Microsystems Troika Networks 4371 Senior Staff Engineer Vice President, Hardware 4372 M/S UNWK16-301 Engineering 4373 901 San Antonio Road 2829 Townsgate Road Suite 4374 Palo Alto, CA 94303-4900 200 4375 Phone: 510-936-2337 Westlake Village, CA 91361 4376 Email: Phone: 805-370-2614 4377 David.Robinson@sun.com Email: 4378 wayland@troikanetworks.com 4380 Rory Bolt Mark Edwards 4381 Quantum/ATL Senior Systems Architect 4382 Director, System Design Eurologic Development, Ltd. 4383 101 Innovation Drive 4th Floor, Howard House 4384 Irvine, CA 92612 Queens Ave, UK. BS8 1SD 4385 Phone: 949-856-7760 Phone: +44 (0)117 930 9600 4386 Email: rbolt@atlp.com Email: 4387 medwards@eurologic.com 4389 13. Normative References 4391 [ENCAP] Weber, et-al., "FC Frame Encapsulation", draft-ietf-ips- 4392 fcencapsulation-01.txt, May 2001 4394 [FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling 4395 Interface", Revision 1.7, NCITS Project 1331-D, February 4396 2002 4398 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- 4399 GS3)", revision 7.01, NCITS Project 1356-D, November 2000 4401 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- 4402 SW2)", revision 5.2, NCITS Project 1305-D, May 2001 4404 [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service", 4405 draft-ietf-ips-08.txt, February 2002 4407 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 4408 3", BCP 9, RFC 2026, October 1996. 4410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4411 Requirement Levels", BCP 14, RFC 2119, March 1997 4413 iFCP Revision 10 February 2002 4415 [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture 4416 for the Internet Protocol", November 1998 4418 [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication 4419 Header", November 1998 4421 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4422 ESP and AH", RFC 2404, November 1998 4424 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4425 ESP and AH", RFC 2404, November 1998 4427 [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security 4428 Protocol", November 1998 4430 [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of 4431 Interpretation for ISAKMP", November 1998 4433 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 4434 RFC 2408, "Internet Security Association and Key Management 4435 Protocol (ISAKMP)" November 1998 4437 [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key 4438 Exchange (IKE)", November 1998 4440 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4441 Its use with IPSEC", RFC 2410, November 1998 4443 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4444 Its use with IPSEC", RFC 2410, November 1998 4446 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4447 Algorithms", RFC 2451, November 1998 4449 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4450 Algorithms", RFC 2451, November 1998 4452 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 4453 1981 4455 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 4456 September, 1981 4458 [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over 4459 IP", revision 9, February 2002 4461 14. Non-Normative References 4463 [AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", 4464 Draft, 2001, Available from 4466 iFCP Revision 10 February 2002 4468 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf 4470 [AESCTR] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-Mode 4471 Encryption", 2001. Available from 4472 http://csrc.nist.gov/encryption/modes/proposedmodes/ctr/ctr 4473 -spec.pdf 4475 [DIFTERM] Grossman, D., "New Terminology and Clarifications for 4476 Diffserv", draft-ietf-diffserv-new-terms-07.txt, December 4477 2001 4479 [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 4480 2)", revision 7.0, NCITS Project 1133D, April 1999 4482 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- 4483 FLA)", revision 2.7, NCITS Project 1235-D, August 1997 4485 [KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated 4486 Loop", Robert W. Kembel, Northwest Learning Associates, 4487 2000, ISBN 0-931836-84-0 4489 [KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", 4490 Northwest Learning Associates Inc., 2000, ISBN 0-931836-84- 4491 0 4493 [MPSLDS] F. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. 4494 Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 4495 Differentiated Services", draft-ietf-mpls-diff-ext-09.txt, 4496 April 2001. 4498 [RFC1122] Braden, S., "Requirements for Internet Hosts -- 4499 Communication Layers", RFC 1122, October 1989 4501 [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High 4502 Performance", RFC 1323, May, 1992 4504 [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated 4505 Services in the Internet Architecture: an Overview", RFC 4506 1633, June 1994 4508 [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol 4509 (SNTP)" Version 4, October 1996 4511 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 4512 2131, March 1997 4514 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4515 Algorithm With Explicit IV" RFC 2405, November 1998 4517 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4518 Algorithm With Explicit IV" RFC 2405, November 1998 4520 iFCP Revision 10 February 2002 4522 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4523 and W. Weiss, "An Architecture for Differentiated 4524 Services", RFC 2475, December 1998 4526 [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre 4527 Channel", June 1999 4529 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 4530 NAT Domains", RFC 2709, October 1999 4532 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 4533 2923, September 2000 4535 [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi- 4536 Protocol Label Switching Architecture", RFC 3031, January 4537 2001 4539 [RFC896] Nagel, J., "Congestion Control in IP/TCP Networks", RFC 4540 896, January 1984 4542 [XCBC] Black, J., Rogaway, P., "A Suggestion for Handling Arbitrary 4543 Length Messages with the CBC MAC". Available from 4544 http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc- 4545 mac/xcbc-mac-spec.pdf 4547 iFCP Revision 10 February 2002 4549 Appendix A 4551 A. iFCP Support for Fibre Channel Link Services 4553 For reference purposes, this appendix enumerates all the fibre 4554 channel link services and the manner in which each shall be 4555 processed by an iFCP implementation. The iFCP processing policies 4556 are defined in section 7. 4558 In the following sections, the name of a link service specific to a 4559 particular FC-4 protocol is prefaced by a mnemonic identifying the 4560 protocol. 4562 A.1 Basic Link Services 4564 The basic link services are shown in the following table. 4566 Basic Link Services 4568 Name Description iFCP Policy 4569 ---- ----------- ---------- 4571 ABTS Abort Sequence Transparent 4572 BA_ACC Basic Accept Transparent 4573 BA_RJT Basic Reject Transparent 4574 NOP No Operation Transparent 4575 PRMT Preempted Rejected 4576 (Applies to 4577 Class 1 only) 4578 RMC Remove Connection Rejected 4579 (Applies to 4580 Class 1 only) 4582 A.2 Link Services Processed Transparently 4584 The link service requests and responses of Table 5 MUST be 4585 processed transparently as defined in section 7. 4587 Name Description 4588 ---- ----------- 4590 ACC Accept 4591 ADVC Advise Credit 4592 CSR Clock Synchronization Request 4593 CSU Clock Synchronization Update 4594 ECHO Echo 4595 ESTC Estimate Credit 4596 ESTS Establish Streaming 4597 FACT Fabric Activate Alias_ID 4598 FAN Fabric Address Notification 4599 FCP_RJT FCP FC-4 Link Service Reject 4601 iFCP Revision 10 February 2002 4603 FCP SRR FCP Sequence Retransmission Request 4604 FDACT Fabric Deactivate Alias_ID 4605 FDISC Discover F_Port Service Parameters 4606 FLOGI F_Port Login 4607 GAID Get Alias_ID 4608 LCLM Login Control List Management 4609 LINIT Loop Initialize 4610 LIRR Link Incident Record Registration 4611 LPC Loop Port Control 4612 LS_RJT Link Service Reject 4613 LSTS Loop Status 4614 NACT N_Port Activate Alias_ID 4615 NDACT N_Port Deactivate Alias_ID 4616 PDISC Discover N_Port Service Parameters 4617 PRLI Process Login 4618 PRLO Process Logout 4619 QoSR Quality of Service Request 4620 RCS Read Connection Status 4621 RLIR Registered Link Incident Report 4622 RNC Report Node Capability 4623 RNFT Report Node FC-4 Types 4624 RNID Request Node Identification Data 4625 RPL Read Port List 4626 RPS Read Port Status Block 4627 RPSC Report Port Speed Capabilities 4628 RSCN Registered State Change Notification 4629 RTV Read Timeout Value 4630 RVCS Read Virtual Circuit Status 4631 SBRP Set Bit-error Reporting Parameters 4632 SCL Scan Remote Loop 4633 SCN State Change Notification 4634 SCR State Change Registration 4635 TEST Test 4636 TPLS Test Process Login State 4637 Table 5--link Services Processed Transparently 4639 A.3 Special Link Services 4641 The extended and FC-4 link services of Table 6 are processed by an 4642 iFCP implementation as described in the sections referenced in the 4643 table. 4645 Name Description Section 4646 ---- ----------- ------- 4648 ABTX Abort Exchange 7.3.1.1 4649 ADISC Discover Address 7.3.1.2 4650 ADISC ACC Discover Address Accept 7.3.1.3 4651 FARP-REPLY Fibre Channel Address 7.3.1.4 4652 Resolution Protocol Reply 4653 FARP-REQ Fibre Channel Address 7.3.1.5 4654 Resolution Protocol Request 4656 iFCP Revision 10 February 2002 4658 LOGO N_PORT Logout 7.3.1.6 4659 PLOGI Port Login 7.3.1.7 4660 FCP REC FCP Read Exchange Concise 7.3.2.1.1 4661 FCP REC ACC FCP Read Exchange Concise 7.3.2.1.2 4662 Accept 4663 RES Read Exchange Status Block 7.3.1.8 4664 RES ACC Read Exchange Status Block 7.3.1.9 4665 Accept 4666 RLS Read Link Error Status Block 7.3.1.10 4667 RRQ Reinstate Recovery Qualifier 7.3.1.12 4668 RSI Request Sequence Initiative 7.3.1.13 4669 RSS Read Sequence Status Block 7.3.1.11 4670 TPRLO Third Party Process Logout 7.3.1.14 4671 TPRLO ACC Third Party Process Logout 7.3.1.15 4672 Accept 4673 Table 6-- Special Link Services 4674 iFCP Revision 10 February 2002 4676 Full Copyright Statement 4678 "Copyright (C) The Internet Society, February 2002. All Rights 4679 Reserved. This document and translations of it may be copied and 4680 furnished to others, and derivative works that comment on or 4681 otherwise explain it or assist in its implementation may be 4682 prepared, copied, published and distributed, in whole or in part, 4683 without restriction of any kind, provided that the above copyright 4684 notice and this paragraph are included on all such copies and 4685 derivative works. However, this document itself may not be modified 4686 in any way, such as by removing the copyright notice or references 4687 to the Internet Society or other Internet organizations, except as 4688 needed for the purpose of developing Internet standards in which 4689 case the procedures for copyrights defined in the Internet 4690 Standards process must be followed, or as required to translate it 4691 into languages other than English. 4693 The limited permissions granted above are perpetual and will not be 4694 revoked by the Internet Society or its successors or assigns. 4696 This document and the information contained herein is provided on 4697 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4698 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4699 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4700 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4701 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4703 iFCP Revision 10 February 2002