idnits 2.17.1 draft-ietf-ips-ifcp-12.txt: -(735): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2560): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4068): 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 1283 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 1313 has weird spacing: '...sulates and d...' == Line 1730 has weird spacing: '... of the event...' == Line 2076 has weird spacing: '...replace the S...' -- 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 (December 2002) is 7803 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FC-FS' is mentioned on line 3721, but not defined == Missing Reference: 'FCP-2' is mentioned on line 277, but not defined == Missing Reference: 'ENCAP' is mentioned on line 1992, but not defined == Missing Reference: '0x0' is mentioned on line 2107, but not defined == Missing Reference: '0x1' is mentioned on line 2109, but not defined -- Looks like a reference, but probably isn't: '0' on line 2109 == Missing Reference: '0x00' is mentioned on line 2111, but not defined == Missing Reference: '0x0000' is mentioned on line 2114, but not defined == Missing Reference: '0x01' is mentioned on line 2498, but not defined == Missing Reference: 'FC-VI' is mentioned on line 2866, but not defined == Missing Reference: 'FCS' is mentioned on line 3085, but not defined == Unused Reference: 'RFC1119' is defined on line 4384, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 4425, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 4477, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ciph-aes-xcbc-mac-02 -- Possible downref: Normative reference to a draft: ref. 'AESCTR' -- 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 1305 (ref. 'RFC1119') (Obsoleted by RFC 5905) ** 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) == Outdated reference: A later version (-19) exists of draft-ietf-ips-security-12 == 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: 14 errors (**), 0 flaws (~~), 20 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Storage Working Group Charles Monia 2 INTERNET DRAFT Rod Mullendore 3 Expires December 2002 4 Document: draft-ietf-ips-ifcp-12.txt Nishan Systems 5 Category: Standards Track 6 Franco Travostino 7 Nortel Networks 9 Wayland Jeong 10 Troika Networks 12 Mark Edwards 13 Eurologic 15 June 2002 17 iFCP - A Protocol for Internet Fibre Channel Storage Networking 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026 [RFC2026]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or made obsolete by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Comments 41 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 42 or to the author(s). 44 Status of this Memo...................................................1 45 Comments..............................................................1 46 Abstract..............................................................5 47 Acknowledgements......................................................5 48 1. About This Document..........................................6 49 1.1 Conventions used in this document............................6 50 1.1.1 Data Structures Internal to an Implementation................6 51 1.2 Purpose of this document.....................................6 52 2. iFCP Introduction............................................6 53 2.1 Definitions..................................................7 54 3. Fibre Channel Communication Concepts.........................9 55 3.1 The Fibre Channel Network...................................10 56 3.2 Fibre Channel Network Topologies............................11 57 3.2.1 Switched Fibre Channel Fabrics..............................11 58 3.2.2 Mixed Fibre Channel Fabric..................................12 59 3.3 Fibre Channel Layers and Link Services......................13 60 3.3.1 Fabric-Supplied Link Services...............................14 61 3.4 Fibre Channel Nodes.........................................14 62 3.5 Fibre Channel Device Discovery..............................15 63 3.6 Fibre Channel Information Elements..........................15 64 3.7 Fibre Channel Frame Format..................................16 65 3.7.1 N_PORT Address Model........................................16 66 3.8 Fibre Channel Transport Services............................17 67 3.9 Login Processes.............................................18 68 4. The iFCP Network Model......................................18 69 4.1 iFCP Transport Services.....................................21 70 4.1.1 Fibre Channel Transport Services Supported by iFCP..........21 71 4.2 iFCP Device Discovery and Configuration Management..........21 72 4.3 iFCP Fabric Properties......................................21 73 4.3.1 Address Transparency........................................22 74 4.3.2 Configuration Scalability...................................22 75 4.3.3 Fault Tolerance.............................................23 76 4.4 The iFCP N_PORT Address Model...............................23 77 4.5 Operation in Address Transparent Mode.......................25 78 4.5.1 Transparent Mode Domain ID Management.......................25 79 4.5.2 Incompatibility with Address Translation Mode...............26 80 4.6 Operation in Address Translation Mode.......................26 81 4.6.1 Inbound Frame Address Translation...........................27 82 4.6.2 Incompatibility with Address Transparent Mode...............28 83 5. iFCP Protocol...............................................28 84 5.1 Overview....................................................28 85 5.1.1 iFCP Transport Services.....................................28 86 5.1.2 iFCP Support for Link Services..............................29 87 5.2 TCP Stream Transport of iFCP Frames.........................30 88 5.2.1 iFCP Session Model..........................................30 89 5.2.2 iFCP Session Management.....................................30 90 5.2.3 Terminating iFCP Sessions...................................37 91 5.3 Fibre Channel Frame Encapsulation...........................39 92 5.3.1 Encapsulation Header Format.................................39 93 5.3.2 SOF and EOF Delimiter Fields................................43 94 5.3.3 Frame Encapsulation.........................................44 95 5.3.4 Frame De-encapsulation......................................44 96 6. TCP Session Control Messages................................45 97 6.1 Connection Bind (CBIND).....................................47 98 6.2 Unbind Connection (UNBIND)..................................50 99 6.3 LTEST -- Test Connection Liveness...........................52 100 7. Fibre Channel Link Services.................................53 101 7.1 Special Link Service Messages...............................54 102 7.2 Link Services Requiring Payload Address Translation.........56 103 7.3 Fibre Channel Link Services Processed by iFCP...............58 104 7.3.1 Special Extended Link Services..............................60 105 7.3.2 Special FC-4 Link Services..................................75 106 7.4 FLOGI Service Parameters Supported by an iFCP Gateway.......77 107 8. iFCP Error Detection........................................79 108 8.1 Overview....................................................79 109 8.2 Stale Frame Prevention......................................79 110 8.2.1 Enforcing R_A_TOV Limits....................................80 111 9. Fabric Services Supported by an iFCP implementation.........81 112 9.1 F_PORT Server...............................................82 113 9.2 Fabric Controller...........................................82 114 9.3 Directory/Name Server.......................................82 115 9.4 Broadcast Server............................................83 116 9.4.1 Establishing the Broadcast Configuration....................83 117 9.4.2 Broadcast Session Management................................84 118 9.4.3 Standby Global Broadcast Server.............................85 119 10. iFCP Security...............................................85 120 10.1 Overview....................................................85 121 10.2 iFCP Security Threats and Scope.............................85 122 10.2.1 Context.....................................................85 123 10.2.2 Security Threats............................................85 124 10.2.3 Interoperability with Security Gateways.....................86 125 10.2.4 Authentication..............................................86 126 10.2.5 Confidentiality.............................................86 127 10.2.6 Rekeying....................................................86 128 10.2.7 Authorization...............................................87 129 10.2.8 Policy control..............................................87 130 10.2.9 iSNS Role...................................................87 131 10.3 iFCP Security Design........................................87 132 10.3.1 Enabling Technologies.......................................87 133 10.3.2 Use of IKE and IPsec........................................89 134 10.3.3 Signatures and Certificate-based Authentication.............91 135 10.4 iSNS and iFCP Security......................................92 136 10.5 Use of iSNS to Distribute Security Policy...................92 137 10.6 Minimal Security Policy for an iFCP gateway.................92 138 11. Quality of Service Considerations...........................92 139 11.1 Minimal requirements........................................92 140 11.2 High-assurance..............................................93 141 12. IANA Considerations.........................................94 142 13. Author's Addresses..........................................94 143 14. Normative References........................................95 144 15. Non-Normative References....................................96 145 A. iFCP Support for Fibre Channel Link Services................99 146 A.1 Basic Link Services.........................................99 147 A.2 Pass-Through Link Services..................................99 148 A.3 Special Link Services......................................100 149 B. Supporting the Fibre Channel Loop Topology.................102 150 B.1 Remote Control of a Public Loop............................102 151 Full Copyright Statement............................................103 152 Notice of Intellectual Property Rights..............................103 153 Abstract 155 This document specifies an architecture and gateway-to-gateway 156 protocol for the implementation of fibre channel fabric 157 functionality over an IP network. This functionality is provided 158 through TCP protocols for fibre channel frame transport and the 159 distributed fabric services specified by the fibre channel 160 standards. The architecture enables internetworking of fibre 161 channel devices through gateway-accessed regions having the fault 162 isolation properties of autonomous systems and the scalability of 163 the IP network. 165 Acknowledgements 167 The authors are indebted to those who contributed material or who 168 took the time to carefully review and critique this specification 169 including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu 170 (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth 171 Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members 172 of the IPS working group. For review of the iFCP security policy, 173 the authors are further indebted to the authors of the IPS security 174 draft [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran 175 (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan 176 (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), 177 and Jesse Walker (Intel). 179 1. About This Document 181 1.1 Conventions used in this document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 185 this document are to be interpreted as described in RFC-2119 186 [RFC2119]. 188 Unless specified otherwise, numeric quantities are given as decimal 189 values. 191 All diagrams that portray bit and byte ordering, including the 192 depiction of structures defined by fibre channel standards, adhere 193 to the IETF conventions where bit 0 is the most significant bit and 194 the first addressable byte is in the upper left hand corner. This 195 IETF convention differs from that used for INCITS T11 fibre channel 196 standards, in which bit 0 is the least significant bit. 198 1.1.1 Data Structures Internal to an Implementation 200 To facilitate the specification of required behavior, this document 201 may define and refer to internal data structures within an iFCP 202 implementation. Such structures are intended for explanatory 203 purposes only and need not be instantiated within an implementation 204 as described in this specification. 206 1.2 Purpose of this document 208 This is a standards-track document, which specifies a protocol for 209 the implementation of fibre channel transport services on a TCP/IP 210 network. Some portions of this document contain material from 211 standards controlled by INCITS T10 and T11. This material is 212 included here for informational purposes only. The authoritative 213 information is given in the appropriate NCITS standards document. 215 The authoritative portions of this document specify the mapping of 216 standards-compliant fibre channel protocol implementations to 217 TCP/IP. This mapping includes sections of this document which 218 describe the "iFCP Protocol" (see section 5). 220 2. iFCP Introduction 222 iFCP is a gateway-to-gateway protocol, which provides fibre channel 223 fabric services to fibre channel devices over a TCP/IP network. 224 iFCP uses TCP to provide congestion control, error detection and 225 recovery. iFCP's primary objective is to allow interconnection and 226 networking of existing fibre channel devices at wire speeds over an 227 IP network. 229 The protocol and method of frame address translation described in 230 this document permit the attachment of fibre channel storage 231 devices to an IP-based fabric by means of transparent gateways. 233 The protocol achieves this transparency by allowing normal fibre 234 channel frame traffic to pass through the gateway directly, with 235 provisions, where necessary, for intercepting and emulating the 236 fabric services required by a fibre channel device. 238 2.1 Definitions 240 Terms needed to describe the concepts presented in this document 241 are presented here. 243 Address-translation mode -- A mode of gateway operation in which 244 the scope of N_PORT fabric addresses for locally attached 245 devices are local to the iFCP gateway region in which the 246 devices reside. 248 Address-transparent mode -- A mode of gateway operation in which 249 the scope of N_PORT fabric addresses for all fibre channel 250 devices are unique to the bounded iFCP fabric to which the 251 gateway belongs. 253 Bounded iFCP Fabric -- The union of two or more gateway regions 254 configured to interoperate together in address-transparent 255 mode. 257 DOMAIN_ID -- The value contained in the high-order byte of a 24-bit 258 N_PORT fibre channel address. 260 F_PORT -- The interface used by an N_PORT to access fibre channel 261 switched fabric functionality. 263 Fabric -- From [FC-FS]: "The entity which interconnects N_PORTs 264 attached to it and is capable of routing frames by using 265 only the address information in the fibre channel frame." 267 Fabric Port -- The interface through which an N_PORT accesses a 268 fibre channel fabric. The type of fabric port depends on 269 the fibre channel fabric topology. In this specification, 270 all fabric port interfaces are considered to be 271 functionally equivalent. 273 FC-2 -- The fibre channel transport services layer described in 274 [FC-FS]. 276 FC-4 -- The fibre channel mapping of an upper layer protocol, such 277 as [FCP-2], the fibre channel to SCSI mapping. 279 Fibre Channel Device -- An entity implementing the functionality 280 accessed through an FC-4 application protocol. 282 Fibre Channel Network -- A native fibre channel fabric and all 283 attached fibre channel nodes. 285 Fibre Channel Node -- A collection of one or more N_PORTs 286 controlled by a level above the FC-2 layer. A node is 287 attached to a fibre channel fabric by means of the N_PORT 288 interface described in [FC-FS]. 290 Gateway Region -- The portion of an iFCP fabric accessed through an 291 iFCP gateway by a remotely attached N_PORT. Fibre channel 292 devices in the region consist of all those locally attached 293 to the gateway. 295 iFCP -- The protocol discussed in this document. 297 iFCP Frame -- A fibre channel frame encapsulated in accordance with 298 the FC Frame Encapsulation Specification [ENCAP] and this 299 specification. 301 iFCP Portal -- An entity representing the point at which a logical 302 or physical iFCP device is attached to the IP network. The 303 network address of the iFCP portal consists of the IP 304 address and TCP port number to which a request is sent when 305 creating the TCP connection for an iFCP session (see 306 section 5.2.1). 308 iFCP Session -- An association comprised of a pair of N_PORTs and a 309 TCP connection that carries traffic between them. An iFCP 310 session may be created as the result of a PLOGI fibre 311 channel login operation. 313 iSNS -- The server functionality and IP protocol that provide 314 storage name services in an iFCP network. Fibre channel 315 name services are implemented by an iSNS name server as 316 described in [ISNS]. 318 Locally Attached Device -- With respect to a gateway, a fibre 319 channel device accessed through the fibre channel fabric to 320 which the gateway is attached. 322 Logical iFCP Device -- The abstraction representing a single fibre 323 channel device as it appears on an iFCP network. 325 N_PORT -- An iFCP or fibre channel entity representing the 326 interface to fibre channel device functionality. This 327 interface implements the fibre channel N_PORT semantics 328 specified in [FC-FS]. Fibre channel defines several 329 variants of this interface that depend on the fibre channel 330 fabric topology. As used in this document, the term 331 applies equally to all variants. 333 N_PORT Alias -- The N_PORT address assigned by a gateway to 334 represent a remote N_PORT accessed via the iFCP protocol. 336 N_PORT fabric address -- The address of an N_PORT within the fibre 337 channel fabric. 339 N_PORT ID -- The address of a locally attached N_PORT within a 340 gateway region. N_PORT IDs are assigned in accordance with 341 the fibre channel rules for address assignment specified in 342 [FC-FS]. 344 N_PORT Network Address -- The address of an N_PORT in the iFCP 345 fabric. This address consists of the IP address and TCP 346 port number of the iFCP Portal and the N_PORT ID of the 347 locally attached fibre channel device. 349 Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS) 350 that establishes an iFCP session through the exchange of 351 identification and operation parameters between an 352 originating N_PORT and a responding N_PORT. 354 Remotely Attached Device -- With respect to a gateway, a fibre 355 channel device accessed from the gateway by means of the 356 iFCP protocol. 358 Unbounded iFCP Fabric -- The union of two or more gateway regions 359 configured to interoperate together in address-translation 360 mode. 362 3. Fibre Channel Communication Concepts 364 Fibre channel is a frame-based, serial technology designed for 365 peer-to-peer communication between devices at gigabit speeds and 366 with low overhead and latency. 368 This section contains a discussion of the fibre channel concepts 369 that form the basis for the iFCP network architecture and protocol 370 described in this document. Readers familiar with this material may 371 skip to section 4. 373 Material presented in this section is drawn from the following T11 374 specifications: 376 -- The Fibre Channel Framing and Signaling Interface, [FC-FS] 378 -- Fibre Channel Switch Fabric -2, [FC-SW2] 380 -- Fibre Channel Generic Services, [FC-GS3] 381 -- Fibre Channel Fabric Loop Attachment, [FC-FLA] 383 The reader will find an in-depth treatment of the technology in 384 [KEMCMP] and [KEMALP]. 386 3.1 The Fibre Channel Network 388 The fundamental entity in fibre channel is the fibre channel 389 network. Unlike a layered network architecture, a fibre channel 390 network is largely specified by functional elements and the 391 interfaces between them. As shown in Figure 1, these consist, in 392 part, of the following: 394 a) N_PORTs -- The end points for fibre channel traffic. In the FC 395 standards, N_PORT interfaces have several variants, depending on 396 the topology of the fabric to which they are attached. As used 397 in this specification, the term applies to any one of the 398 variants. 400 b) FC Devices -- The fibre channel devices to which the N_PORTs 401 provide access. 403 c) Fabric Ports -- The interfaces within a fibre channel network 404 that provide attachment for an N_PORT. The types of fabric port 405 depend on the fabric topology and are discussed in section 3.2. 407 d) The network infrastructure for carrying frame traffic between 408 N_PORTs. 410 e) Within a switched or mixed fabric (see section 3.2), a set of 411 auxiliary servers, including a name server for device discovery 412 and network address resolution. The types of service depend on 413 the network topology. 415 +--------+ +--------+ +--------+ +--------+ 416 | FC | | FC | | FC | | FC | 417 | Device | | Device |<-------->| Device | | Device | 418 |........| |........| |........| |........| 419 | N_PORT | | N_PORT | | N_PORT | | N_PORT | 420 +---+----+ +----+---+ +----+---+ +----+---+ 421 | | | | 422 +---+----+ +----+---+ +----+---+ +----+---+ 423 | Fabric | | Fabric | | Fabric | | Fabric | 424 | Port | | Port | | Port | | Port | 425 +========+===+========+==========+========+==+========+ 426 | Fabric | 427 | & | 428 | Fabric Services | 429 +-----------------------------------------------------+ 430 Figure 1 -- A Fibre Channel Network 432 The following sections describe fibre channel network topologies 433 and give an overview of the fibre channel communications model. 435 3.2 Fibre Channel Network Topologies 437 The principal fibre channel network topologies consist of the 438 following: 440 a) Arbitrated Loop -- A series of N_PORTs connected together in 441 daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are 442 referred to as NL_PORTs. Data transmission between NL_PORTs 443 requires arbitration for control of the loop in a manner 444 similar to a token ring network. 446 b) Switched Fabric -- A network consisting of switching elements, 447 as described in section 3.2.1. 449 c) Mixed Fabric -- A network consisting of switches and "fabric- 450 attached" loops. A description can be found in [FC-FLA]. A 451 loop-attached N_PORT (NL_PORT), is connected to the loop 452 through an L_PORT and accesses the fabric by way of an FL_PORT. 454 Depending on the topology, the N_PORT and its means of network 455 attachment may be one of the following: 457 FC Network Network Interface N_PORT Variant 458 Topology ----------------- -------------- 459 --------------- 460 Loop L_PORT NL_PORT 462 Switched F_PORT N_PORT 464 Mixed FL_PORT via L_PORT NL_PORT 466 F_PORT N_PORT 468 The differences in each N_PORT variant and its corresponding fabric 469 port are confined to the interactions between them. To an external 470 N_PORT, all fabric ports are transparent and all remote N_PORTs are 471 functionally identical. 473 3.2.1 Switched Fibre Channel Fabrics 475 An example of a multi-switch fibre channel fabric is shown in 476 Figure 2. 478 +----------+ +----------+ 479 | FC | | FC | 480 | Device | | Device | 481 |..........| |..........| 482 | N_PORT |<........>| N_PORT | 483 +----+-----+ +-----+----+ 484 | | 485 +----+-----+ +-----+----+ 486 | F_PORT | | F_PORT | 487 ==========+==========+==========+==========+============== 488 | FC | | FC | 489 | Switch | | Switch | 490 +----------+ +----------+ Fibre Channel 491 |Inter- | |Inter- | Fabric 492 |Switch | |Switch | 493 |Interface | |Interface | 494 +-----+----+ +-----+----+ 495 | | 496 | | 497 +-----+----+----------+-----+----+ 498 |Inter- | |Inter- | 499 |Switch | |Switch | 500 |Interface | |Interface | 501 +----------+ +----------+ 502 | FC Switch | 503 | | 504 +--------------------------------+ 505 Figure 2 -- Multi-Switch Fibre Channel Fabric 507 The interface between switch elements is either proprietary or the 508 standards-compliant E_PORT interface described by the FC-SW2 509 specification, [FC-SW2]. 511 3.2.2 Mixed Fibre Channel Fabric 513 A mixed fabric contains one or more arbitrated loops connected to a 514 switched fabric as shown in Figure 3. 516 +----------+ +----------+ +---------+ 517 | FC | | FC | | FC | 518 | Device | | Device | | Device | 519 |..........| FC |..........| |.........| 520 | N_PORT |<........>| NL_PORT +---+ NL_PORT | 521 +----+-----+ Traffic +-----+----+ +----+----+ 522 | | FC Loop | 523 +----+-----+ +-----+----+ | 524 | F_PORT | | FL_PORT +--------+ 525 | | | | 526 ==========+==========+==========+==========+============== 527 | FC | | FC | 528 | Switch | | Switch | 529 +----------+ +----------+ 530 |Inter- | |Inter- | 531 |Switch | |Switch | 532 |Interface | |Interface | 533 +-----+----+ +-----+----+ 534 | | 535 | | 536 +-----+----+----------+-----+----+ 537 |Inter- | |Inter- | 538 |Switch | |Switch | 539 |Interface | |Interface | 540 +----------+ +----------+ 541 | FC Switch | 542 | | 543 +--------------------------------+ 544 Figure 3 -- Mixed Fibre Channel Fabric 546 As noted previously, the protocol for communications between peer 547 N_PORTs is independent of the fabric topology, N_PORT variant and 548 type of fabric port to which an N_PORT is attached. 550 3.3 Fibre Channel Layers and Link Services 552 Fibre channel consists of the following layers: 554 FC-0 -- The interface to the physical media, 556 FC-1 -- The encoding and decoding of data and out-of-band physical 557 link control information for transmission over the physical media, 559 FC-2 -- The transfer of frames, sequences and Exchanges comprising 560 protocol information units. 562 FC-3 -- Common Services, 564 FC-4 -- Application protocols such as the fibre channel protocol 565 for SCSI (FCP). 567 In addition to the layers defined above, fibre channel defines a 568 set of auxiliary operations, some of which are implemented within 569 the transport layer fabric, called link services. These are 570 required to manage the fibre channel environment, establish 571 communications with other devices, retrieve error information, 572 perform error recovery and other similar services. Some link 573 services are executed by the N_PORT. Others are implemented 574 internally within the fabric. These internal services are 575 described in the next section. 577 3.3.1 Fabric-Supplied Link Services 579 Servers internal to a switched fabric handle certain classes of 580 Link Service requests and service-specific commands. The servers 581 appear as N_PORTs located at the 'well-known' N_PORT fabric 582 addresses specified in [FC-FS]. Service requests use the standard 583 fibre channel mechanisms for N_PORT-to-N_PORT communications. 585 All switched fabrics must provide the following services: 587 Fabric F_PORT server -- Services N_PORT requests to access the 588 fabric for communications. 590 Fabric Controller -- Provides state change information to inform 591 other FC devices when an N_PORT exits or enters the fabric (see 592 section 3.5). 594 Directory/Name Server - Allows N_PORTs to register information 595 in a database, retrieve information about other N_PORTs and 596 discover other devices as described in section 3.5. 598 A switched fabric may also implement the following optional 599 services: 601 Broadcast Address/Server -- Transmits single-frame, class 3 602 sequences to all N_PORTs. 604 Time Server -- Intended for the management of fabric-wide 605 expiration timers or elapsed time values and not intended for 606 precise time synchronization. 608 Management Server - Collects and reports management information, 609 such as link usage, error statistics, link quality and similar 610 items. 612 Quality of Service Facilitator - Performs fabric-wide bandwidth 613 and latency management. 615 3.4 Fibre Channel Nodes 617 A fibre channel node has one or more fabric-attached N_PORTs. The 618 node and its N_PORTs have the following associated identifiers: 620 a) A worldwide unique identifier for the node, 622 b) A worldwide unique identifier for each N_PORT associated with the 623 node, 625 c) For each N_PORT attached to a fabric, a 24-bit fabric-unique 626 address having the properties defined in section 3.7.1. The 627 fabric address is the address to which frames are sent. 629 Each worldwide unique identifier is a 64-bit binary quantity having 630 the format defined in [FC-FS]. 632 3.5 Fibre Channel Device Discovery 634 In a switched or mixed fabric, fibre channel devices and changes in 635 the device configuration may be discovered by means of services 636 provided by the fibre channel Name Server and Fabric Controller. 638 The Name Server provides registration and query services that allow 639 a fibre channel device to register its presence on the fabric and 640 discover the existence of other devices. For example, one type of 641 query obtains the fabric address of an N_PORT from its 64-bit 642 worldwide unique name. The full set of supported fibre channel name 643 server queries is specified in [FC-GS3]. 645 The Fabric Controller complements the static discovery capabilities 646 provided by the Name Server through a service that dynamically 647 alerts a fibre channel device whenever an N_PORT is added or 648 removed from the configuration. A fibre channel device receives 649 these notifications by subscribing to the service as specified in 650 [FC-FS]. 652 3.6 Fibre Channel Information Elements 654 The fundamental element of information in fibre channel is the 655 frame. A frame consists of a fixed header and up to 2112 bytes of 656 payload having the structure described in section 3.7. The maximum 657 frame size that may be transmitted between a pair of fibre channel 658 devices is negotiable up to the payload limit, based on the size of 659 the frame buffers in each fibre channel device and the path maximum 660 transmission unit (MTU) supported by the fabric. 662 Operations involving the transfer of information between N_PORT 663 pairs are performed through 'Exchanges'. In an Exchange, 664 information is transferred in one or more ordered series of frames 665 referred to as Sequences. 667 Within this framework, an upper layer protocol is defined in terms 668 of transactions carried by Exchanges. Each transaction, in turn, 669 consists of protocol information units, each of which is carried by 670 an individual Sequence within an Exchange. 672 3.7 Fibre Channel Frame Format 674 A fibre channel frame consists of a header, payload and 32-bit CRC 675 bracketed by SOF and EOF delimiters. The header contains the 676 control information necessary to route frames between N_PORTs and 677 manage Exchanges and Sequences. The following diagram gives a 678 schematic view of the frame. 680 Bit 0 31 681 +-----------------------------+ 682 Word 0 | Start-of-frame Delimiter | 683 +-----+-----------------------+<----+ 684 | | Destination N_PORT | | 685 1 | | Fabric Address (D_ID) | | 686 | | (24 bits) | | 687 +-----+-----------------------+ 24-byte 688 | | Source N_PORT | Frame 689 2 | | Fabric Address (S_ID) | Header 690 | | (24 bits) | | 691 +-----+-----------------------+ | 692 3 | Control information for | | 693 . | frame type, Exchange | | 694 . | management, IU | | 695 . | segmentation and | | 696 6 | re-assembly | | 697 +-----------------------------+<----+ 698 7 | | 699 . | Frame payload | 700 . | (0 - 2112 bytes) | 701 . | | 702 . | | 703 . | | 704 +-----------------------------+ 705 . | CRC | 706 +-----------------------------+ 707 n | End-of-Frame Delimiter | 708 +-----------------------------+ 709 Figure 4 -- Fibre Channel Frame Format 711 The source and destination N_PORT fabric addresses embedded in the 712 S_ID and D_ID fields represent the physical addresses of 713 originating and receiving N_PORTs respectively. 715 3.7.1 N_PORT Address Model 717 N_PORT fabric addresses are 24-bit values having the following 718 format defined by the fibre channel specification [FC-FS]: 720 Bit 0 7 8 15 16 23 721 +-----------+------------+----------+ 722 | Domain ID | Area ID | Port ID | 723 +-----------+------------+----------+ 724 Figure 5 -- Fibre Channel Address Format 726 A fibre channel device acquires an address when it logs into the 727 fabric. Such addresses are volatile and subject to change based on 728 modifications in the fabric configuration. 730 In a fibre channel fabric, each switch element has a unique Domain 731 ID assigned by the principal switch. The value of the Domain ID 732 ranges from 1 to 239 (0xEF). Each switch element, in turn, 733 administers a block of addresses divided into area and port IDs. An 734 N_PORT connected to a F_PORT receives a unique fabric address 735 consisting of the switch�s Domain ID concatenated with switch- 736 assigned area and port IDs. 738 A loop-attached NL_PORT (see Figure 3) obtains the Port ID 739 component of its address during the loop initialization process 740 described in [FC-AL2]. The area and domain IDs are supplied by the 741 fabric when the fabric login (FLOGI) is executed. 743 3.8 Fibre Channel Transport Services 745 N_PORTs communicate by means of the following classes of service 746 specified in the fibre channel standard ([FC-FS]): 748 Class 1 - A dedicated physical circuit connecting two N_PORTs. 750 Class 2 - A frame-multiplexed connection with end-to-end flow 751 control and delivery confirmation. 753 Class 3 - A frame-multiplexed connection with no provisions for 754 end-to-end flow control or delivery confirmation. 756 Class 4 -- A connection-oriented service, based on a virtual 757 circuit model, providing confirmed delivery with bandwidth and 758 latency guarantees. 760 Class 6 -- A reliable multicast service derived from class 1. 762 Class 2 and class 3 are the predominant services supported by 763 deployed fibre channel storage and clustering systems. 765 Class 3 service is similar to UDP or IP datagram service. Fibre 766 channel storage devices using this class of service rely on the ULP 767 implementation to detect and recover from transient device and 768 transport errors. 770 For class 2 and class 3 service, the fibre channel fabric is not 771 required to provide in-order delivery of frames unless explicitly 772 requested by the frame originator (and supported by the fabric). If 773 ordered delivery is not in effect, it is the responsibility of the 774 frame recipient to reconstruct the order in which frames were sent 775 based on information in the frame header. 777 3.9 Login Processes 779 The Login processes are FC-2 operations that allow an N_PORT to 780 establish the operating environment necessary to communicate with 781 the fabric, other N_PORTs and ULP implementations accessed via the 782 N_PORT. Three login operations are supported: 784 a) Fabric Login (FLOGI) -- An operation whereby the N_PORT 785 registers its presence on the fabric, obtains fabric parameters 786 such as classes of service supported, and receives its N_PORT 787 address, 789 b) Port Login (PLOGI) -- An operation by which an N_PORT 790 establishes communication with another N_PORT. 792 c) Process Login (PRLOGI) -- An operation which establishes the 793 process-to-process communications associated with a specific 794 FC-4 ULP -- such as FCP-2, the fibre channel SCSI mapping. 796 Since N_PORT addresses are volatile, an N_PORT originating a login 797 (PLOGI) operation executes a Name Server query to discover the 798 fibre channel address of the remote device. A common query type 799 involves use of the worldwide unique name of an N_PORT to obtain 800 the 24-bit N_PORT fibre channel address to which the PLOGI request 801 is sent. 803 4. The iFCP Network Model 805 The iFCP protocol enables the implementation of fibre channel 806 fabric functionality on an IP network in which IP components and 807 technology replace the fibre channel switching and routing 808 infrastructure described in section 3.2. 810 The example of Figure 6 shows a fibre channel network with attached 811 devices. Each device accesses the network through an N_PORT 812 connected to an interface whose behavior is specified in [FC-FS] or 813 [FC-AL2]. In this case, the N_PORT represents any of the variants 814 described in section 3.2. The interface to the fabric may be an 815 L_PORT, F_PORT or FL_PORT. 817 Within the fibre channel device domain, addressable entities 818 consist of other N_PORTs and fibre channel devices internal to the 819 network that perform the fabric services defined in [FC-GS3]. 821 Fibre Channel Network 822 +--------+ +--------+ 823 | FC | | FC | 824 | Device | | Device | 825 |........| FC |........| Fibre Channel 826 | N_PORT |<......>| N_PORT | Device Domain 827 +---+----+ Traffic+----+---+ ^ 828 | | | 829 +---+----+ +----+---+ | 830 | Fabric | | Fabric | | 831 | Port | | Port | | 832 ==========+========+========+========+============== 833 | FC Network & | | 834 | Fabric Services | v 835 | | Fibre Channel 836 +--------------------------+ Network Domain 837 Figure 6 -- A Fibre Channel Network 839 Gateway Region Gateway Region 840 +--------+ +--------+ +--------+ +--------+ 841 | FC | | FC | | FC | | FC | 842 | Device | | Device | | Device | | Device | Fibre 843 |........| |........| FC |........| |........| Channel 844 | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device 845 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 846 | | | | ^ 847 +---+----+ +---+----+ +----+---+ +----+---+ | 848 | F_PORT | | F_PORT | | F_PORT | | F_PORT | | 849 =+========+==+========+===========+========+==+========+========== 850 | iFCP Layer |<--------->| iFCP Layer | | 851 |....................| ^ |....................| | 852 | iFCP Portal | | | iFCP Portal | v 853 +--------+-----------+ | +----------+---------+ IP 854 iFCP|Gateway Control iFCP|Gateway Network 855 | Data | 856 | | 857 | | 858 |<------Encapsulated Frames------->| 859 | +------------------+ | 860 | | | | 861 +------+ IP Network +--------+ 862 | | 863 +------------------+ 864 Figure 7 -- An iFCP Fabric Example 866 One example of an equivalent iFCP fabric is shown in Figure 7. The 867 fabric consists of two gateway regions, each accessed by a single 868 iFCP gateway. 870 Each gateway contains two standards-compliant F_PORTs and an iFCP 871 Portal for attachment to the IP network. Fibre channel devices in 872 the region are those locally connected to the iFCP fabric through 873 the gateway fabric ports. 875 Looking into the fabric port, the gateway appears as a fibre 876 channel switch element. At this interface, remote N_PORTs are 877 presented as fabric-attached devices. Conversely, on the IP network 878 side, the gateway presents each locally connected N_PORT as a 879 logical fibre channel device. 881 Extrapolating to the general case, each gateway region behaves like 882 an autonomous system whose configuration is invisible to the IP 883 network and other gateway regions. Consequently, in addition to the 884 F_PORT shown in the example, a gateway implementation may 885 transparently support the following fibre channel interfaces: 887 Inter-Switch Link -- A fibre channel switch-to-switch interface 888 used to access a region containing fibre channel switch 889 elements. An implementation may support the E_PORT defined 890 by [FC-SW2] or one of the proprietary interfaces provided 891 by various fibre channel switch vendors. In this case, the 892 gateway acts as a border switch connecting the gateway 893 region to the IP network. 895 FL_PORT -- An interface that provides fabric access for loop- 896 attached fibre channel devices as specified in [FC-FLA]. 898 L_PORT -- An interface through which a gateway may emulate the 899 fibre channel loop environment specified in [FC-AL2]. As 900 discussed in appendix B, the gateway presents remotely 901 accessed N_PORTS as loop-attached devices. 903 The manner in which these interfaces are provided by a gateway is 904 implementation-specific and therefore beyond the scope of this 905 document. 907 Although each region is connected to the IP network through one 908 gateway, a region may incorporate multiple gateways for added 909 performance and fault tolerance. To do so: 911 a) The gateways MUST coordinate the assignment of N_PORT IDs and 912 aliases such that each N_PORT has one and only one address and 914 b) All iFCP traffic between a given remote and local N_PORT pair 915 MUST flow through the same iFCP session (see section 5.2.1). 916 However, iFCP sessions to a given remotely attached N_PORT need 917 not traverse the same gateway. 919 Coordinating address assignments and managing the flow of traffic 920 is implementation-specific and outside the scope of this 921 specification. 923 4.1 iFCP Transport Services 925 N_PORT to N_PORT communications that traverse a TCP/IP network 926 require the intervention of the iFCP layer within the gateway. This 927 consists of the following operations: 929 a) Execution of the frame addressing and mapping functions 930 described in section 4.4. 932 b) Encapsulation of fibre channel frames for injection into the 933 TCP/IP network and de-encapsulation of fibre channel frames 934 received from the TCP/IP network. 936 c) Establishment of an iFCP session in response to a PLOGI directed 937 to a remote device. 939 Section 4.4 discusses the iFCP frame addressing mechanism and the 940 way in which it is used to achieve communications transparency 941 between N_PORTs. 943 4.1.1 Fibre Channel Transport Services Supported by iFCP 945 An iFCP fabric supports Class 2 and Class 3 fibre channel transport 946 services as specified in [FC-FS]. An iFCP fabric does not support 947 class 4, class 6 or the Class 1 (dedicated connection) service. An 948 N_PORT discovers the classes of transport services supported by the 949 fabric during fabric login. 951 4.2 iFCP Device Discovery and Configuration Management 953 An iFCP implementation performs device discovery and iFCP fabric 954 management through the Internet Storage Name Service defined in 955 [ISNS]. Access to an iSNS server is required to perform the 956 following functions: 958 a) Emulate the services provided by the fibre channel name server 959 described in section 3.3.1, including a mechanism for 960 asynchronously notifying an N_PORT of changes in the iFCP fabric 961 configuration, 963 b) Aggregate gateways into iFCP fabrics for interoperation, 965 c) Segment an iFCP fabric into fibre channel zones through the 966 definition and management of device discovery scopes, referred 967 to as 'discovery domains', 969 d) Store and distribute security policies as described in section 970 10.2.9. 972 e) Implementation of the fibre channel broadcast mechanism. 974 4.3 iFCP Fabric Properties 975 A collection of iFCP gateways may be configured for interoperation 976 as either a bounded or unbounded iFCP fabric. 978 Gateways in a bounded iFCP fabric operate in address transparent 979 mode as described in section 4.5. In this mode, the scope of a 980 fibre channel N_PORT address is fabric-wide and is derived from 981 domain IDs issued by the iSNS server from a common pool. As 982 discussed in section 4.3.2, the maximum number of domain IDs 983 allowed by fibre channel limits the configuration of a bounded iFCP 984 fabric. 986 Gateways in an unbounded iFCP fabric operate in address translation 987 mode as described in section 4.6. In this mode, the scope of an 988 N_PORT address is local to a gateway region. For fibre channel 989 traffic between regions, the translation of frame-embedded N_PORT 990 addresses is performed by the gateway. As discussed below, the 991 number of switch elements and gateways in an unbounded iFCP fabric 992 may exceed the limits of a conventional fibre channel fabric. 994 All iFCP gateways MUST support unbounded iFCP fabrics. Support for 995 bounded iFCP fabrics is OPTIONAL. 997 The decision to support bounded iFCP fabrics in a gateway 998 implementation depends on the address transparency, configuration 999 scalability, and fault tolerance considerations given in the 1000 following sections. 1002 4.3.1 Address Transparency 1004 Although iFCP gateways in an unbounded fabric will convert N_PORT 1005 addresses in the frame header and payload of standard link service 1006 messages, a gateway cannot convert such addresses in the payload of 1007 vendor- or user-specific fibre channel frame traffic. 1009 Consequently, while both bounded and unbounded iFCP fabrics support 1010 standards-compliant FC-4 protocol implementations and link services 1011 used by mainstream fibre channel applications, a bounded iFCP 1012 fabric may also support vendor- or user-specific protocol and link 1013 service implementations that carry N_PORT IDs in the frame payload. 1015 4.3.2 Configuration Scalability 1017 The scalability limits of a bounded fabric configuration are a 1018 consequence of the fibre channel address allocation policy 1019 discussed in section 3.7.1. As noted, a bounded iFCP fabric using 1020 this address allocation scheme is limited to a combined total of 1021 239 gateways and fibre channel switch elements. As the system 1022 expands, the network may grow to include many switch elements and 1023 gateways, each of which controls a small number of devices. In 1024 this case, the limitation in switch and gateway count may become a 1025 barrier to extending and fully integrating the storage network. 1027 Since N_PORT fibre channel addresses in an unbounded iFCP fabric 1028 are not fabric-wide, the limits imposed by fibre channel address 1029 allocation only apply within the gateway region. Across regions, 1030 the number of iFCP gateways, fibre channel devices and switch 1031 elements that may be internetworked are not constrained by these 1032 limits. In exchange for improved scalability, however, 1033 implementations must consider the incremental overhead of address 1034 conversion as well as the address transparency issues discussed in 1035 section 4.3.1. 1037 4.3.3 Fault Tolerance 1039 In a bounded iFCP fabric, address reassignment caused by a fault or 1040 reconfiguration, such as the addition of a new gateway region, may 1041 cascade to other regions, causing fabric-wide disruption as new 1042 N_PORT addresses are assigned. Furthermore, before a new gateway 1043 can be merged into the fabric, its iSNS server must be slaved to 1044 the iSNS server in the bounded fabric to centralize the issuance of 1045 domain IDs. In an unbounded iFCP fabric coordinating the iSNS 1046 databases requires only that the iSNS servers exchange client 1047 attributes with one another. 1049 A bounded iFCP fabric also has an increased dependency on the 1050 availability of the iSNS server, which must act as the central 1051 address assignment authority. If connectivity with the server is 1052 lost, new DOMAIN_ID values cannot be automatically allocated as 1053 gateways and fibre channel switch elements are added. 1055 4.4 The iFCP N_PORT Address Model 1057 This section discusses iFCP extensions to the fibre channel 1058 addressing model of section 3.7.1, which are required for the 1059 transparent routing of frames between locally and remotely attached 1060 N_PORTs. 1062 In the iFCP protocol an N_PORT is represented by the following 1063 addresses: 1065 a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a 1066 locally attached device. Depending on the gateway addressing 1067 mode, the scope is either local to a region or a bounded iFCP 1068 fabric. In either mode, communications between N_PORTs in the 1069 same gateway region use the N_PORT ID. 1071 b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned 1072 by each gateway operating in address translation mode to 1073 identify a remotely attached N_PORT. Frame traffic is 1074 intercepted by an iFCP gateway and directed to a remotely 1075 attached N_PORT by means of the N_PORT alias. The address 1076 assigned by each gateway is unique within the scope of the 1077 gateway region. 1079 c) An N_PORT network address. A tuple consisting of the gateway IP 1080 address, TCP port number and N_PORT ID. The N_PORT network 1081 address identifies the source and destination N_PORTs for fibre 1082 channel traffic on the IP network. 1084 To provide transparent communications between a remote and local 1085 N_PORT, a gateway MUST maintain an iFCP session descriptor (see 1086 section 5.2.2.2) reflecting the association between the fibre 1087 channel address representing the remote N_PORT and the remote 1088 device's N_PORT network address. To establish this association the 1089 iFCP gateway assigns and manages fibre channel N_PORT fabric 1090 addresses as described in the following paragraphs. 1092 In an iFCP fabric, the iFCP gateway performs the address assignment 1093 and frame routing functions of an FC switch element. Unlike an FC 1094 switch, however, an iFCP gateway must also direct frames to 1095 external devices attached to remote gateways on the IP network. 1097 In order to be transparent to FC devices, the gateway must deliver 1098 such frames using only the 24-bit destination address in the frame 1099 header. By exploiting its control of address allocation and access 1100 to frame traffic entering or leaving the gateway region, the 1101 gateway is able to achieve the necessary transparency. 1103 N_PORT addresses within a gateway region may be allocated in one of 1104 two ways: 1106 a) Address Translation Mode - A mode of N_PORT address assignment 1107 in which the scope of an N_PORT fibre channel address is unique 1108 to the gateway region. The address of a remote device is 1109 represented in that gateway region by its gateway-assigned 1110 N_PORT alias. 1112 b) Address Transparent Mode - A mode of N_PORT address assignment 1113 in which the scope of an N_PORT fibre channel address is unique 1114 across the set of gateway regions comprising a bounded iFCP 1115 fabric. 1117 In address transparent mode, gateways within a bounded fabric 1118 cooperate in the assignment of addresses to locally attached 1119 N_PORTs. Each gateway in control of a region is responsible for 1120 obtaining and distributing unique domain IDs from the address 1121 assignment authority as described in section 4.5.1. Consequently, 1122 within the scope of a bounded fabric, the address of each N_PORT is 1123 unique. For that reason, gateway-assigned aliases are not required 1124 to represent remote N_PORTs. 1126 All iFCP implementations MUST support operation in address 1127 translation mode. Implementation of address transparent mode is 1128 OPTIONAL but, of course, must be provided if bounded iFCP fabric 1129 configurations are to be supported. 1131 The mode of gateway operation is settable in an implementation- 1132 specific manner. The implementation MUST NOT: 1134 a) Allow the mode to be changed after the gateway begins processing 1135 fibre channel frame traffic 1137 b) Permit operation in more than one mode at a time or 1139 c) Establish an iFCP session with a gateway that is not in the same 1140 mode. 1142 4.5 Operation in Address Transparent Mode 1144 The following considerations and requirements apply to this mode of 1145 operation: 1147 a) iFCP gateways in address transparent mode will not interoperate 1148 with iFCP gateways that are not in address transparent mode. 1150 b) When interoperating with locally attached fibre channel switch 1151 elements, each iFCP gateway MUST assume control of DOMAIN_ID 1152 assignments in accordance with the appropriate fibre channel 1153 standard or vendor-specific protocol specification. As 1154 described in section 4.5.1, DOMAIN_ID values assigned to FC 1155 switches internal to the gateway region must be issued by the 1156 iSNS server. 1158 c) When operating in address transparent Mode, fibre channel 1159 address translation SHALL NOT take place. 1161 When operating in address transparent mode, however, the gateway 1162 MUST establish and maintain the context of each iFCP session in 1163 accordance with section 5.2.2. 1165 4.5.1 Transparent Mode Domain ID Management 1167 As described in section 4.5, each gateway and fibre channel switch 1168 in a bounded iFCP fabric has a unique domain ID. In a gateway 1169 region containing fibre channel switch elements, each element 1170 obtains a domain ID by querying the principal switch as described 1171 in [FC-SW2] -- in this case the iFCP gateway itself. The gateway 1172 in turn obtains domain IDs on demand from the iSNS name server 1173 acting as the central address allocation authority. In effect, the 1174 iSNS server assumes the role of principal switch for the bounded 1175 fabric. In that case, the iSNS database contains: 1177 a) The definition for one or more bounded iFCP fabrics, 1179 b) For each bounded fabric, a worldwide unique name identifying 1180 each gateway in the fabric. A gateway in address transparent 1181 mode MUST reside in one and only one bounded fabric. 1183 As the Principal Switch within the gateway region, an iFCP gateway 1184 in address transparent mode SHALL obtain domain IDs for use in the 1185 gateway region by issuing the appropriate iSNS query using its 1186 worldwide name. 1188 4.5.2 Incompatibility with Address Translation Mode 1190 Except for the session control frames specified in section 6, iFCP 1191 gateways in address transparent mode SHALL NOT originate or accept 1192 frames that do not have the TRP bit set to one in the iFCP flags 1193 field of the encapsulation header (see section 5.3.1). The iFCP 1194 gateway SHALL immediately terminate all iFCP sessions with the iFCP 1195 gateway from which it receives such frames. 1197 4.6 Operation in Address Translation Mode 1199 This section describes the process for managing the assignment of 1200 addresses within a gateway region that is part of an unbounded iFCP 1201 fabric, including the modification of FC frame addresses embedded 1202 in the frame header for frames sent and received from remotely 1203 attached N_PORTs. 1205 As described in section 4.4, the scope of N_PORT addresses in this 1206 mode is local to the gateway region. A principal switch within the 1207 gateway region, possibly the iFCP gateway itself, oversees the 1208 assignment of such addresses in accordance with the rules specified 1209 in [FC-FS] and [FC-FLA]. 1211 The assignment of N_PORT addresses to locally attached devices is 1212 controlled by the switch element to which the device is connected. 1214 The assignment of N_PORT addresses for remotely attached devices is 1215 controlled by the gateway through which the remote device is 1216 accessed. In this case, the gateway MUST assign a locally 1217 significant N_PORT alias to be used in place of the N_PORT ID 1218 assigned by the remote gateway. The N_PORT alias is assigned during 1219 device discovery as described in section 5.2.2.1. 1221 To perform address conversion and enable the appropriate routing, 1222 the gateway MUST establish an iFCP session and generate the 1223 information required to map each N_PORT alias to the appropriate 1224 TCP/IP connection context and N_PORT ID of the remotely accessed 1225 N_PORT. The means by which these mappings are created and updated 1226 are specified in section 5.2.2.2. As described in that section, 1227 the required mapping information is represented by the iFCP session 1228 descriptor reproduced in Figure 8. 1230 +-----------------------+ 1231 |TCP Connection Context | 1232 +-----------------------+ 1233 | Local N_PORT ID | 1234 +-----------------------+ 1235 | Remote N_PORT ID | 1236 +-----------------------+ 1237 | Remote N_PORT Alias | 1238 +-----------------------+ 1239 Figure 8 -- iFCP Session Descriptor (from section 5.2.2.2) 1241 Except for frames comprising special link service messages (see 1242 section 7.2), outbound frames are encapsulated and sent without 1243 modification. Address translation is deferred until receipt from 1244 the IP network as specified in section 4.6.1. 1246 4.6.1 Inbound Frame Address Translation 1248 For inbound frames received from the IP network, the receiving 1249 gateway SHALL reference the session descriptor to fill in the D_ID 1250 field with the destination N_PORT ID and the S_ID field with the 1251 N_PORT alias it assigned. The translation process for inbound 1252 frames is shown in Figure 9. 1254 Network Format of Inbound Frame 1255 +--------------------------------------------+ iFCP 1256 | FC Encapsulation Header | Session 1257 +--------------------------------------------+ Descriptor 1258 | SOF Delimiter Word | | 1259 +========+===================================+ V 1260 | | D_ID Field | +--------+-----+ 1261 +--------+-----------------------------------+ | Lookup source| 1262 | | S_ID Field | | N_PORT Alias | 1263 +--------+-----------------------------------+ | and | 1264 | Control Information, Payload | | destination | 1265 | and FC CRC | | N_PORT ID | 1266 | | +--------+-----+ 1267 | | | 1268 | | | 1269 +============================================+ | 1270 | EOF Delimiter Word | | 1271 +--------------------------------------------+ | 1272 | 1273 | 1274 Frame after Address Translation and De-encapsulation | 1275 +--------+-----------------------------------+ | 1276 | | Destination N_PORT ID |<-------------+ 1277 +--------+-----------------------------------+ | 1278 | | Source N_PORT Alias |<-------------+ 1279 +--------+-----------------------------------+ 1280 | | 1281 | Control information, Payload, | 1282 | and FC CRC | 1283 +--------------------------------------------+ 1284 Figure 9 -- Inbound Frame Address Translation 1286 The receiving gateway SHALL consider the contents of the S_ID and 1287 D_ID fields to be undefined when received. After replacing these 1288 fields, the gateway MUST recalculate the FC CRC. 1290 4.6.2 Incompatibility with Address Transparent Mode 1292 iFCP gateways in address translation mode SHALL NOT originate or 1293 accept frames that have the TRP bit set to one in the iFCP flags 1294 field of the encapsulation header. The iFCP gateway SHALL 1295 immediately abort all iFCP sessions with the iFCP gateway from 1296 which it receives such frames as described in section 5.2.3. 1298 5. iFCP Protocol 1300 5.1 Overview 1302 5.1.1 iFCP Transport Services 1304 The main function of the iFCP protocol layer is to transport fibre 1305 channel frame images between locally and remotely attached N_PORTs. 1307 When transporting frames to a remote N_PORT, the iFCP layer 1308 encapsulates and routes the fibre channel frames comprising each 1309 fibre channel Information Unit via a predetermined TCP connection 1310 for transport across the IP network. 1312 When receiving fibre channel frame images from the IP network, the 1313 iFCP layer de-encapsulates and delivers each frame to the 1314 appropriate N_PORT. 1316 The iFCP layer processes the following types of traffic: 1318 a) FC-4 frame images associated with a fibre channel application 1319 protocol. 1321 b) FC-2 frames comprising fibre channel link service requests and 1322 responses 1324 c) Fibre channel broadcast frames 1326 d) iFCP control messages required to setup, manage or terminate an 1327 iFCP session. 1329 For FC-4 N_PORT traffic and most FC-2 messages the iFCP layer never 1330 interprets the contents of the frame payload. 1332 iFCP does interpret and process iFCP control messages and certain 1333 link service messages as described in section 5.1.2 1335 5.1.2 iFCP Support for Link Services 1337 iFCP must intervene in the processing of those fibre channel link 1338 service messages that contain N_PORT addresses in the message 1339 payload or require other special handling, such as an N_PORT login 1340 request (PLOGI). 1342 In the former case, an iFCP gateway operating in address 1343 translation mode MUST supplement the payload with additional 1344 information that enables the receiving gateway to convert such 1345 embedded N_PORT addresses to its frame of reference. 1347 For out-bound fibre channel frames comprising such a link service, 1348 the iFCP layer creates the supplemental information based on frame 1349 content, modifies the frame payload, then transmits the resulting 1350 fibre channel frame with supplemental data through the appropriate 1351 TCP connection. 1353 For incoming iFCP frames containing supplemented fibre channel link 1354 service frames, iFCP must interpret the frame, including any 1355 supplemental information, modify the frame content, and forward the 1356 resulting frame to the destination N_PORT for further processing. 1358 Section 7.1 describes the processing of these link service messages 1359 in detail. 1361 5.2 TCP Stream Transport of iFCP Frames 1363 5.2.1 iFCP Session Model 1365 An iFCP session consists of the pair of N_PORTs comprising the 1366 session endpoints joined by a single TCP/IP connection. No more 1367 than one iFCP session SHALL exist between a given pair of N_PORTs. 1369 An N_PORT is identified by its network address consisting of: 1371 a) The N_PORT ID assigned by the gateway to which the N_PORT is 1372 locally attached and 1374 b) The iFCP Portal address, consisting of its IP address and TCP 1375 port number. 1377 Since only one iFCP session may exist between a pair of N_PORTs, 1378 the iFCP session is uniquely identified by the network addresses of 1379 the session end points. 1381 TCP connections that may be used for iFCP sessions between pairs of 1382 iFCP portals are either "bound" or "unbound". An unbound 1383 connection is a TCP connection that is not actively supporting an 1384 iFCP session. A gateway implementation MAY establish a pool of 1385 unbound connections to reduce the session setup time. Such pre- 1386 existing TCP connections between iFCP Portals remain unbound and 1387 uncommitted until allocated to an iFCP session through a CBIND 1388 message (see section 6.1). 1390 When the iFCP layer creates an iFCP session, it may select an 1391 existing unbound TCP connection or establish a new TCP connection 1392 and send the CBIND message down that TCP connection. This 1393 allocates the TCP connection to that iFCP session. 1395 5.2.2 iFCP Session Management 1397 This section describes the protocols and data structures required 1398 to establish and terminate an iFCP session. 1400 5.2.2.1 The Remote N_PORT Descriptor 1402 In order to establish an iFCP session, an iFCP gateway MUST 1403 maintain information allowing it to locate a remotely attached 1404 N_PORT. For explanatory purposes, such information is assumed to 1405 reside in a descriptor having the format shown in Figure 10. 1407 +--------------------------------+ 1408 | N_PORT Worldwide Unique Name | 1409 +--------------------------------+ 1410 | iFCP Portal Address | 1411 +--------------------------------+ 1412 | N_PORT ID of Remote N_PORT | 1413 +--------------------------------+ 1414 | N_PORT Alias | 1415 +--------------------------------+ 1416 Figure 10 -- Remote N_PORT Descriptor 1418 Each descriptor aggregates the following information about a 1419 remotely attached N_PORT: 1421 N_PORT Worldwide Unique Name -- 64-bit N_PORT world wide name 1422 as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely 1423 identified by this parameter. 1425 iFCP Portal Address -- The IP address and TCP port number 1426 referenced when requesting creation of the TCP connection 1427 associated with an iFCP session. 1429 N_PORT ID -- N_PORT fibre channel address assigned to the 1430 remote device by the remote iFCP gateway. 1432 N_PORT Alias -- N_PORT fibre channel address assigned to the 1433 remote device by the 'local' iFCP gateway when operating in 1434 address translation mode. 1436 An iFCP gateway SHALL have one and only one descriptor for each 1437 remote N_PORT it accesses. If a descriptor does not exist, one 1438 SHALL be created using the information returned by an iSNS name 1439 server query. Such queries may be result from: 1441 a) A fibre channel Name Server request originated by a locally 1442 attached N_PORT (see sections 3.5 and 9.3), or 1444 b) A CBIND request received from a remote fibre channel device (see 1445 section 5.2.2.2). 1447 When creating a descriptor in response to an incoming CBIND 1448 request, the iFCP gateway SHALL perform an iSNS name server query 1449 using the worldwide port name of the remote N_PORT in the SOURCE 1450 N_PORT NAME field within the CBIND payload. The descriptor SHALL 1451 be filled in using the query results. 1453 After creating the descriptor, a gateway operating in address 1454 translation mode SHALL create and add the 24-bit N_PORT alias. 1456 5.2.2.1.1 Updating a Remote N_PORT Descriptor 1457 A Remote N_PORT descriptor SHALL only be updated as the result of 1458 an iSNS query to obtain information for the specified worldwide 1459 port name or from information returned by an iSNS state change 1460 notification. Following such an update, a new N_PORT alias SHALL 1461 NOT be assigned. 1463 Before such an update, the contents of a descriptor may have become 1464 stale as the result of an event that invalidated or triggered a 1465 change in the N_PORT network address of the remote device, such as 1466 a fabric reconfiguration or the device's removal or replacement. 1468 A collateral effect of such an event is that a fibre channel device 1469 that has been added or whose N_PORT ID has changed will have no 1470 active N_PORT logins. Consequently, FC-4 traffic directed to such 1471 an N_PORT as the result of a stale descriptor will be rejected or 1472 discarded. 1474 Once the originating N_PORT learns of the reconfiguration, usually 1475 through the name server state change notification mechanism, 1476 information returned in the notification or the subsequent name 1477 server lookup needed to reestablish the iFCP session will 1478 automatically purge such stale data from the gateway. 1480 5.2.2.1.2 Deleting a Remote N_PORT Descriptor 1482 Deleting a remote N_PORT descriptor is equivalent to freeing up the 1483 corresponding N_PORT alias for reuse, consequently the descriptor 1484 MUST NOT be deleted while there are any iFCP sessions that 1485 reference the remote N_PORT. 1487 Descriptors eligible for deletion should be removed based on a last 1488 in, first out policy. 1490 5.2.2.2 Creating an iFCP Session 1492 An iFCP session may be in one of the following states: 1494 OPEN -- The session state in which fibre channel frame images may 1495 be sent and received. 1497 OPEN PENDING -- The session state after a gateway has issued a 1498 CBIND request but no response has yet been received. No fibre 1499 channel frames may be sent. 1501 The session may be initiated in response to a PLOGI ELS (see 1502 section 7.3.1.7) or for any other implementation-specific reason. 1504 The gateway SHALL create the iFCP session as follows: 1506 a) Locate the remote N_PORT descriptor corresponding to the session 1507 end point. If creating the session in order to forward a fibre 1508 channel frame, the session endpoint may be obtained by 1509 referencing the remote N_PORT alias contained in the frame 1510 header D_ID field. If no descriptor exists, an iFCP session 1511 SHALL NOT be created. 1513 b) Allocate a TCP connection to the gateway to which the remote 1514 N_PORT is locally attached. An implementation may use an 1515 existing connection in the Unbound state or a new connection may 1516 be created and placed in the Unbound state. 1518 When creating a connection, the IP address and TCP Port number 1519 SHALL be obtained by referencing the remote N_PORT descriptor as 1520 specified in section 5.2.2.1. 1522 c) If the TCP connection cannot be allocated or cannot be created 1523 due to limited resources the gateway SHALL terminate session 1524 creation. 1526 d) If the TCP connection is aborted for any reason before the iFCP 1527 session enters the OPEN state, the gateway SHALL respond in 1528 accordance with section 5.2.3 and MAY terminate the attempt to 1529 create a session or MAY try again to establish the TCP 1530 connection. 1532 e) The gateway SHALL then issue a CBIND session control message 1533 (see section 6.1) and place the session in the OPEN PENDING 1534 state. 1536 f) If a CBIND response is returned with a status other than 1537 "Success" or "iFCP session already exists", the session SHALL be 1538 terminated and the TCP connection returned to the Unbound state. 1540 g) A CBIND STATUS of "iFCP session already exists" indicates that 1541 the remote gateway has concurrently initiated a CBIND request to 1542 create an iFCP session between the same pair of N_PORTs. A 1543 gateway receiving such a response SHALL terminate this attempt 1544 and process the incoming CBIND request in accordance with 1545 section 5.2.2.3. 1547 h) In response to a CBIND STATUS of "Success", the gateway SHALL 1548 place the session in the OPEN state. 1550 Once the session is placed in the OPEN state, an iFCP session 1551 descriptor SHALL be created containing the information shown in 1552 Figure 11: 1554 +-----------------------+ 1555 |TCP Connection Context | 1556 +-----------------------+ 1557 | Local N_PORT ID | 1558 +-----------------------+ 1559 | Remote N_PORT ID | 1560 +-----------------------+ 1561 | Remote N_PORT Alias | 1562 +-----------------------+ 1563 Figure 11 -- iFCP Session Descriptor 1565 TCP Connection Context -- Information required to identify the TCP 1566 connection associated with the iFCP session. 1568 Local N_PORT ID -- N_PORT ID of the locally attached fibre channel 1569 device. 1571 Remote N_PORT ID -- N_PORT ID assigned to the remote device by the 1572 remote gateway. 1574 Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the 1575 local gateway when operating in address translation mode. If in 1576 this mode, the gateway SHALL copy this parameter from the Remote 1577 N_PORT descriptor. Otherwise, it is not filled in. 1579 5.2.2.3 Responding to a CBIND Request 1581 The gateway receiving a CBIND request SHALL respond as follows: 1583 a) If the receiver has a duplicate iFCP session in the OPEN PENDING 1584 state, then the receiving gateway SHALL compare the Source 1585 N_PORT Name in the incoming CBIND payload with the Destination 1586 N_PORT Name. 1588 b) If the Source N_PORT Name is greater, the receiver SHALL issue a 1589 CBIND response of "Success" and SHALL place the session in the 1590 OPEN state. 1592 c) If the Source N_PORT Name is less, the receiver shall issue a 1593 CBIND RESPONSE of Failed - N_PORT session already exists. The 1594 state of the receiver-initiated iFCP session SHALL BE unchanged. 1596 d) If there is no duplicate iFCP session in the OPEN PENDING state, 1597 the receiving gateway SHALL issue a CBIND response. If a status 1598 of Success is returned, the receiving gateway SHALL create the 1599 iFCP session and place it in the OPEN state. An iFCP session 1600 descriptor SHALL be created as described in section 5.2.2.2. 1602 e) If a remote N_PORT descriptor does not exist, one SHALL be 1603 created and filled in as described in section 5.2.2.1. 1605 5.2.2.4 Monitoring iFCP Connectivity 1606 During extended periods of inactivity, an iFCP session may be 1607 terminated due to a hardware failure within the gateway or through 1608 loss of TCP/IP connectivity. The latter may occur when the session 1609 traverses a stateful intermediate device, such as a NA(P)T box or 1610 firewall, that detects and purges connections it believes are 1611 unused. 1613 To test session liveness, expedite the detection of connectivity 1614 failures, and avoid spontaneous connection termination, an iFCP 1615 gateway may maintain a low level of session activity and monitor 1616 the session by requesting that the remote gateway periodically 1617 transmit the LTEST message described in section 6.3. All iFCP 1618 gateways SHALL support liveness testing as described in this 1619 specification. 1621 A gateway requests the LTEST heartbeat by specifying a non-zero 1622 value for the LIVENESS TEST INTERVAL in the CBIND request or 1623 response message as described in section 6.1. If both gateways 1624 wish to monitor liveness, each must set the LIVENESS TEST INTERVAL 1625 in the CBIND request or response. 1627 Upon receiving such a request, the gateway providing the heartbeat 1628 SHALL transmit LTEST messages at the specified interval. The first 1629 message SHALL be sent as soon as the iFCP session enters the OPEN 1630 state. LTEST messages SHALL NOT be sent when the iFCP session is 1631 not in the OPEN state. 1633 An iFCP session SHALL be terminated as described in section 5.2.3 1634 if: 1636 a) The contents of the LTEST message are incorrect, or 1638 b) An LTEST message is not received within twice the specified 1639 interval or the iFCP session has been quiescent for longer than 1640 twice the specified interval. 1642 The gateway to receive the LTEST message SHALL measure the 1643 interval for the first expected LTEST message from when the 1644 session is placed in the OPEN state. Thereafter, the interval 1645 SHALL be measured relative to the last LTEST message received. 1647 To maximize liveness test coverage, LTEST messages SHOULD flow 1648 through all the gateway components used to enter and retrieve fibre 1649 channel frames from the IP network, including the mechanisms for 1650 encapsulating and de-encapsulating fibre channel frames. 1652 In addition to monitoring a session, information in the LTEST 1653 message encapsulation header may also be used to compute an 1654 estimate of network propagation delay as described in section 1655 8.2.1. However, the propagation delay limit SHALL NOT be enforced 1656 for LTEST traffic. 1658 5.2.2.5 Use of TCP Features and Settings 1660 This section describes ground rules for the use of TCP features in 1661 an iFCP session. The core TCP protocol is defined in [RFC793]. 1662 TCP implementation requirements and guidelines are specified in 1663 [RFC1122]. 1665 +-----------+------------+--------------+------------+------------+ 1666 | Feature | Applicable | RFC | Peer-wise | Requirement| 1667 | | RFCs | Status | agreement | Level | 1668 | | | | required? | | 1669 +===========+============+==============+============+============+ 1670 | Keep Alive| [RFC1122] | None | No | Should not | 1671 | |(discussion)| | | use | 1672 +-----------+------------+--------------+------------+------------+ 1673 | Tiny | [RFC896] | Standard | No | Should not | 1674 | Segment | | | | use | 1675 | Avoidance | | | | | 1676 | (Nagle) | | | | | 1677 +-----------+------------+--------------+------------+------------+ 1678 | Window | [RFC1323] | Proposed | No | Should use | 1679 | Scale | | Standard | | | 1680 +-----------+------------+--------------+------------+------------+ 1681 | Wrapped | [RFC1323] | Proposed | No | SHOULD use | 1682 | Sequence | | Standard | | | 1683 | Protection| | | | | 1684 | (PAWS) | | | | | 1685 +-----------+------------+--------------+------------+------------+ 1686 Table 1 -- Usage of Optional TCP Features 1688 The following sections describe these options in greater detail. 1690 5.2.2.5.1 Keep Alive 1692 Keep Alive speeds the detection and cleanup of dysfunctional TCP 1693 connections by sending traffic when a connection would otherwise be 1694 idle. The issues are discussed in [RFC1122]. 1696 In order to test the device more comprehensively, fibre channel 1697 applications, such as storage, may implement an equivalent keep 1698 alive function at the FC-4 level. Alternatively, periodic liveness 1699 test messages may be issued as described in section 5.2.2.4. 1700 Because of these more comprehensive end-to-end mechanisms and the 1701 considerations described in [RFC1122], keep alive at the transport 1702 layer should not be implemented. 1704 5.2.2.5.2 'Tiny' Segment Avoidance (Nagle) 1706 The Nagle algorithm described in [RFC896] is designed to avoid the 1707 overhead of small segments by delaying transmission in order to 1708 agglomerate transfer requests into a large segment. In iFCP, such 1709 small transfers often contain I/O requests. Hence, the 1710 transmission delay of the Nagle algorithm may decrease I/O 1711 throughput. Therefore, the Nagle algorithm should not be used. 1713 5.2.2.5.3 Window Scale 1715 Window scaling, as specified in [RFC1323], allows full utilization 1716 of links with large bandwidth - delay products and should be 1717 supported by an iFCP implementation. 1719 5.2.2.5.4 Wrapped Sequence Protection (PAWS) 1721 TCP segments are identified with 32-bit sequence numbers. In 1722 networks with large bandwidth - delay products, it is possible for 1723 more than one TCP segment with the same sequence number to be in 1724 flight. In iFCP, receipt of such a sequence out of order may cause 1725 out-of-order frame delivery or data corruption. Consequently, this 1726 feature SHOULD be supported as described in [RFC1323]. 1728 5.2.3 Terminating iFCP Sessions 1730 iFCP sessions SHALL be terminated in response to one of the events 1731 in Table 2: 1733 +-------------------------------------------+---------------------+ 1734 | Event | iFCP Sessions | 1735 | | to Terminate | 1736 +===========================================+=====================+ 1737 | PLOGI terminated with LS_RJT response | Peer N_PORT | 1738 +-------------------------------------------+---------------------+ 1739 | State change notification indicating | All iFCP Sessions | 1740 | N_PORT removal or reconfiguration. | from the | 1741 | | reconfigured N_PORT | 1742 +-------------------------------------------+---------------------+ 1743 | LOGO ACC response from peer N_PORT | Peer N_PORT | 1744 +-------------------------------------------+---------------------+ 1745 | ACC response to LOGO ELS sent to F_PORT | All iFCP sessions | 1746 | server (D_ID = 0xFF-FF-FE) (fabric | from the originating| 1747 | logout) | N_PORT | 1748 +-------------------------------------------+---------------------+ 1749 | Implicit N_PORT LOGO as defined in | All iFCP sessions | 1750 | [FC-FS] | from the N_PORT | 1751 | | logged out | 1752 +-------------------------------------------+---------------------+ 1753 | LTEST Message Error (see section 5.2.2.4) | Peer N_PORT | 1754 +-------------------------------------------+---------------------+ 1755 | Non fatal encapsulation error as | Peer N_PORT | 1756 | specified in section 5.3.3 | | 1757 +-------------------------------------------+---------------------+ 1758 | Failure of the TCP connection associated | Peer N_PORT | 1759 | with the iFCP session | | 1760 +-------------------------------------------+---------------------+ 1761 | Receipt of an UNBIND session control | Peer N_PORT | 1762 | message | | 1763 +-------------------------------------------+---------------------+ 1764 | Gateway enters the Unsynchronized state | All iFCP sessions | 1765 | (see section 8.2.1) | | 1766 +-------------------------------------------+---------------------+ 1767 | Gateway detects incorrect address mode | All iFCP sessions | 1768 | to peer gateway(see section 4.6.2) | with peer gateway | 1769 +-------------------------------------------+---------------------+ 1770 Table 2-- Session Termination Events 1772 If a session is being terminated due to an incorrect address mode 1773 with the peer gateway, the TCP connection SHALL be aborted by means 1774 of a connection reset (RST) without performing an UNBIND. 1775 Otherwise, if the TCP connection is still open following the event, 1776 the gateway SHALL shut down the connection as follows: 1778 a) Stop sending fibre channel frames over the TCP connection. 1780 b) Discard all incoming traffic, except for an UNBIND session 1781 control message. 1783 c) If an UNBIND message is received at any time, return a response 1784 in accordance with section 6.2. 1786 d) If session termination was not triggered by an UNBIND message, 1787 issue the UNBIND session control message as described in section 1788 6.2. 1790 e) If the UNBIND message completes with a status of Success, the 1791 TCP connection MAY remain open at the discretion of either 1792 gateway and may be kept in a pool of unbound connections in 1793 order to speed the creation of a new iFCP session. 1795 If the UNBIND fails for any reason, the TCP connection MUST be 1796 terminated. In this case, the connection SHOULD be aborted with 1797 a connection reset (RST). 1799 For each terminated session, the session descriptor SHALL be 1800 deleted. If a session was terminated by an event other than an 1801 implicit LOGO or a LOGO ACC response, the gateway shall issue a 1802 LOGO to the locally attached N_PORT on behalf of the remote N_PORT. 1804 To recover resources, either gateway may spontaneously close an 1805 unbound TCP connection at any time. If a gateway terminates a 1806 connection with a TCP close operation, the peer gateway MUST 1807 respond by executing a TCP close. 1809 5.3 Fibre Channel Frame Encapsulation 1811 This section describes the iFCP encapsulation of fibre channel 1812 frames. The encapsulation complies with the common encapsulation 1813 format defined in [ENCAP], portions of which are included here for 1814 convenience. 1816 The format of an encapsulated frame is shown below: 1818 +--------------------+ 1819 | Header | 1820 +--------------------+-----+ 1821 | SOF | f | 1822 +--------------------+ F r | 1823 | FC frame content | C a | 1824 +--------------------+ m | 1825 | EOF | e | 1826 +--------------------+-----+ 1827 Figure 12 -- Encapsulation Format 1829 The encapsulation consists of a 7-word header, an SOF delimiter 1830 word, the FC frame (including the fibre channel CRC), and an EOF 1831 delimiter word. The header and delimiter formats are described in 1832 the following sections. 1834 5.3.1 Encapsulation Header Format 1835 W|------------------------------Bit------------------------------| 1836 o| | 1837 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| 1838 d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| 1839 +---------------+---------------+---------------+---------------+ 1840 0| Protocol# | Version | -Protocol# | -Version | 1841 +---------------+---------------+---------------+---------------+ 1842 1| Reserved (must be zero) | 1843 +---------------+---------------+---------------+---------------+ 1844 2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF | 1845 +-----------+---+---------------+-----------+---+---------------+ 1846 3| Flags | Frame Length | -Flags | -Frame Length | 1847 +-----------+-------------------+-----------+-------------------+ 1848 4| Time Stamp [integer] | 1849 +---------------------------------------------------------------+ 1850 5| Time Stamp [fraction] | 1851 +---------------------------------------------------------------+ 1852 6| CRC | 1853 +---------------------------------------------------------------+ 1854 Figure 13 --- Encapsulation Header Format 1856 Common Encapsulation Fields: 1858 Protocol# IANA-assigned protocol number 1859 identifying the protocol using the 1860 encapsulation. For iFCP, the value 1861 assigned by [ENCAP] is 2. 1863 Version Encapsulation version as specified in 1864 [ENCAP] 1866 -Protocol# Ones complement of the protocol# 1868 -Version Ones complement of the version 1870 Flags Encapsulation flags (see 5.3.1.1) 1872 Frame Length Contains the length of the entire FC 1873 Encapsulated frame including the FC 1874 Encapsulation Header and the FC frame 1875 (including SOF and EOF words) in units 1876 of 32-bit words. 1878 -Flags Ones-complement of the Flags field. 1880 -Frame Length Ones-complement of the Frame Length 1881 field. 1883 Time Stamp [integer] Integer component of the frame time 1884 stamp as specified in [ENCAP]. 1886 Time Stamp Fractional component of the time stamp 1887 [fraction] as specified in [ENCAP]. 1889 CRC Header CRC. MUST be valid for iFCP. 1891 The time stamp fields are used to enforce the limit on the 1892 lifetime of a fibre channel frame as described in section 1893 8.2.1. 1895 iFCP-specific fields: 1897 LS_COMMAND_ACC For a special link service ACC 1898 response to be processed by iFCP, the 1899 LS_COMMAND_ACC field SHALL contain a 1900 copy of bits 0 through 7 of the 1901 LS_COMMAND to which the ACC applies. 1902 Otherwise the LS_COMMAND_ACC field 1903 SHALL be set to zero. 1905 iFCP Flags iFCP-specific flags (see below) 1907 SOF Copy of the SOF delimiter encoding 1908 (see section 5.3.2) 1910 EOF Copy of the EOF delimiter encoding 1911 (see section 5.3.2) 1913 The iFCP flags word has the following format: 1915 |------------------------Bit----------------------------| 1916 | | 1917 | 8 9 10 11 12 13 14 15 | 1918 +------+------+------+------+------+------+------+------+ 1919 | Reserved | SES | TRP | SPC | 1920 +------+------+------+------+------+------+------+------+ 1921 Figure 14 -- iFCP Flags Word 1923 iFCP Flags: 1925 SES 1 = Session control frame (TRP and SPC MUST be 1926 0) 1928 TRP 1 = Address transparent mode enabled 1930 0 = Address translation mode enabled 1932 SPC 1 = Frame is part of a link service message 1933 requiring special processing by iFCP prior 1934 to forwarding to the destination N_PORT. 1936 5.3.1.1 Common Encapsulation Flags 1938 The iFCP usage of the common encapsulation flags defined in [ENCAP] 1939 is shown in Figure 15: 1941 |------------------------Bit--------------------------| 1942 | | 1943 | 0 1 2 3 4 5 | 1944 +--------------------------------------------+--------+ 1945 | Reserved | CRCV | 1946 +--------------------------------------------+--------+ 1947 Figure 15 -- iFCP Common Encapsulation Flags 1949 For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 1951 5.3.2 SOF and EOF Delimiter Fields 1953 The format of the delimiter fields is shown below. 1955 W|------------------------------Bit------------------------------| 1956 o| | 1957 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3| 1958 d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| 1959 +---------------+---------------+---------------+---------------+ 1960 0| SOF | SOF | -SOF | -SOF | 1961 +---------------+---------------+---------------+---------------+ 1962 1| | 1963 +----- FC frame content -----+ 1964 | | 1965 +---------------+---------------+---------------+---------------+ 1966 n| EOF | EOF | -EOF | -EOF | 1967 +---------------+---------------+---------------+---------------+ 1968 Figure 16 -- FC Frame Encapsulation Format 1970 SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following 1971 subset of the SOF fields specified in [ENCAP]. For convenience, 1972 these are reproduced in Table 3. The authoritative encodings 1973 should be obtained from [ENCAP]. 1975 +-------+----------+ 1976 | FC | | 1977 | SOF | SOF Code | 1978 +-------+----------+ 1979 | SOFi2 | 0x2D | 1980 | SOFn2 | 0x35 | 1981 | SOFi3 | 0x2E | 1982 | SOFn3 | 0x36 | 1983 +-------+----------+ 1984 Table 3-- Translation of FC SOF Values to SOF Field Contents 1986 -SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the 1987 ones complement of the value in the SOF fields. 1989 EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset 1990 of EOF fields specified in [ENCAP]. For convenience, these are 1991 reproduced in Table 4. The authoritative encodings should be 1992 obtained from [ENCAP]. 1994 +-------+----------+ 1995 | FC | | 1996 | EOF | EOF Code | 1997 +-------+----------+ 1998 | EOFn | 0x41 | 1999 | EOFt | 0x42 | 2000 +-------+----------+ 2001 Table 4 -- Translation of FC EOF Values to EOF Field Contents 2003 -EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the 2004 one's complement of the value in the EOF fields. 2006 iFCP implementations SHALL place a copy of the SOF and EOF 2007 delimiter codes in the appropriate header fields. 2009 5.3.3 Frame Encapsulation 2011 A fibre channel Frame to be encapsulated MUST first be validated as 2012 described in [FC-FS]. Any frames received from a locally attached 2013 fibre channel device that do not pass the validity tests in [FC-FS] 2014 SHALL be discarded by the gateway. 2016 If the frame is a PLOGI ELS, the creation of an iFCP session as 2017 described in section 7.3.1.7 may precede encapsulation. Once the 2018 session has been created, frame encapsulation SHALL proceed as 2019 follows. 2021 The S_ID and D_ID fields in the frame header SHALL be referenced to 2022 lookup the iFCP session descriptor (see section 5.2.2.2). If no 2023 iFCP session descriptor exists, the frame SHALL be discarded. 2025 Frame types submitted for encapsulation and forwarding on the IP 2026 network SHALL have one of the SOF delimiters in Table 3 and an EOF 2027 delimiter from Table 4. Other valid frame types MUST be processed 2028 internally by the gateway as specified in the appropriate fibre 2029 channel specification. 2031 If operating in address translation mode and processing a special 2032 link service message requiring the inclusion of supplemental data, 2033 the gateway SHALL format the frame payload and add the supplemental 2034 information specified in section 7.1. The gateway SHALL then 2035 calculate a new FC CRC on the reformatted frame. 2037 Otherwise, the frame contents SHALL NOT be modified and the gateway 2038 MAY encapsulate and transmit the frame image without recalculating 2039 the FC CRC. 2041 The frame originator MUST then create and fill in the header and 2042 the SOF and EOF delimiter words as specified in sections 5.3.1 and 2043 5.3.2. 2045 5.3.4 Frame De-encapsulation 2046 The receiving gateway SHALL perform de-encapsulation as follows: 2048 Upon receiving the encapsulated frame, the gateway SHALL check the 2049 header CRC. If the header CRC is valid, the receiving gateway SHALL 2050 check the iFCP flags field. If one of the error conditions in Table 2051 5 is detected, the gateway SHALL handle the error as specified in 2052 section 5.2.3. 2054 +------------------------------+-------------------------+ 2055 | Condition | Error Type | 2056 +==============================+=========================+ 2057 | Header CRC Invalid | Encapsulation error | 2058 +------------------------------+-------------------------+ 2059 | SES = 1, TRP or SPC not 0 | Encapsulation error | 2060 +------------------------------+-------------------------+ 2061 | SES = 0, TRP set incorrectly | Incorrect address mode | 2062 +------------------------------+-------------------------+ 2063 Table 5 -- Encapsulation Header Errors 2065 The receiving gateway SHALL then verify the frame propagation delay 2066 as described in section 8.2.1. If the propagation delay is too 2067 long, the frame SHALL be discarded. Otherwise, the gateway SHALL 2068 check the SOF and EOF in the encapsulation header. A frame SHALL 2069 be discarded if it has an SOF code that is not in Table 3 or an EOF 2070 code that is not in Table 4. 2072 The gateway SHALL then de-encapsulate the frame as follows: 2074 a) Check the FC CRC and discard the frame if the CRC is invalid. 2076 b) If operating in address translation mode, replace the S_ID 2077 field with the N_PORT alias of the frame originator and the D_ID 2078 with the N_PORT ID of the frame recipient. Both parameters 2079 SHALL be obtained from the iFCP session descriptor. 2081 c) If processing a special link service message, replace the frame 2082 with a copy whose payload has been modified as specified in 2083 section 7.1. 2085 The de-encapsulated frame SHALL then be forwarded to the N_PORT 2086 specified in the D_ID field. If the frame contents have been 2087 modified by the receiving gateway, a new FC CRC SHALL be 2088 calculated. 2090 6. TCP Session Control Messages 2092 TCP session control messages are used to create and manage an iFCP 2093 session as described in section 5.2.2. They are passed between peer 2094 iFCP Portals and are only processed within the iFCP layer. 2096 The message format is based on the fibre channel extended link 2097 service message template shown below. 2099 Word 2100 0<--Bits-->7 8<---------------Bits------------------------>31 2101 +------------+------------------------------------------------+ 2102 0| R_CTL | D_ID [0x00 00 00] | 2103 |[Req = 0x22]| [Destination of extended link Service request] | 2104 |[Rep = 0x23]| | 2105 +------------+------------------------------------------------+ 2106 1| CS_CTL | S_ID [0x00 00 00] | 2107 | [0x0] | [Source of extended link service request] | 2108 +------------+------------------------------------------------+ 2109 2|TYPE [0x1] | F_CTL [0] | 2110 +------------+------------------+-----------------------------+ 2111 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | 2112 |[0x0] | | | 2113 +------------+------------------+-----------------------------+ 2114 4| OX_ID [0x0000] | RX_ID_[0x0000] | 2115 +-------------------------------+-----------------------------+ 2116 5| Parameter | 2117 | [ 00 00 00 00 ] | 2118 +-------------------------------------------------------------+ 2119 6| LS_COMMAND | 2120 | [Session Control Command Code] | 2121 +-------------------------------------------------------------+ 2122 7| | 2123 .| Additional Session Control Parameters | 2124 .| ( if any ) | 2125 n| | 2126 +=============================================================+ 2127 n| Fibre Channel CRC | 2128 +| | 2129 1+=============================================================+ 2130 Figure 17 -- Format of Session Control Message 2132 The LS_COMMAND value for the response remains the same as that used 2133 for the request. 2135 The session control frame is terminated with a fibre channel CRC. 2136 The frame SHALL be encapsulated and de-encapsulated according to 2137 the rules specified in section 5.3. 2139 The encapsulation header for the link Service frame carrying a 2140 session control message SHALL be set as follows: 2142 Encapsulation Header Fields: 2144 LS_COMMAND_ACC 0 2146 iFCP Flags SES = 1 2148 TRP = 0 2150 INT = 0 2152 SOF code SOFi3 encoding (0x2E) 2154 EOF code EOFt encoding (0x42) 2156 The encapsulation time stamp words SHALL be set as described for 2157 each message type. 2159 The SOF and EOF delimiter words SHALL be set based on the SOF and 2160 EOF codes specified above. 2162 Table 6 lists the values assigned to byte 0 of the LS_COMMAND field 2163 for iFCP session control messages. 2165 +--------------+-------------------------+----------+-------------+ 2166 | LS_COMMAND | Function | Mnemonic | iFCP | 2167 | field, byte 0| | | Support | 2168 +--------------+-------------------------+----------+-------------+ 2169 | 0xE0 | Connection Bind | CBIND | REQUIRED | 2170 +--------------+-------------------------+----------+-------------+ 2171 | 0xE4 | Unbind Connection | UNBIND | REQUIRED | 2172 +--------------+-------------------------+----------+-------------+ 2173 | 0xE5 | Test Connection Liveness| LTEST | REQUIRED | 2174 +--------------+-------------------------+----------+-------------+ 2175 | 0x01-0x7F | Vendor-specific | | | 2176 +--------------+-------------------------+----------+-------------+ 2177 | 0x00 | Reserved -- Unassignable| | | 2178 +--------------+-------------------------+----------+-------------+ 2179 | All other | Reserved | | | 2180 | values | | | | 2181 +--------------+-------------------------+----------+-------------+ 2182 Table 6 -- Session Control LS_COMMAND Field, Byte 0 Values 2184 6.1 Connection Bind (CBIND) 2186 As described in section 5.2.2.2, the CBIND message and response are 2187 used to bind an N_PORT login to a specific TCP connection and 2188 establish an iFCP session. In the CBIND request message, the 2189 source and destination N_PORTs are identified by their worldwide 2190 port names. The time stamp words in the encapsulation header SHALL 2191 be set to zero in the request and response message frames. 2193 The following shows the format of the CBIND request. 2195 +------+------------+------------+-----------+----------+ 2196 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2197 +------+------------+------------+-----------+----------+ 2198 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2199 +------+------------+------------+-----------+----------+ 2200 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2201 | | (Seconds) | | | 2202 +------+-------------------------+-----------+----------+ 2203 | 2 | USER INFO | 2204 +------+------------+------------+-----------+----------+ 2205 | 3 | | 2206 +------+ SOURCE N_PORT NAME | 2207 | 4 | | 2208 +------+------------------------------------------------+ 2209 | 5 | | 2210 +------+ DESTINATION N_PORT NAME | 2211 | 6 | | 2212 +------+------------------------------------------------+ 2214 Addr Mode: The addressing mode of the originating 2215 gateway. 0 = Address Translation mode, 1 = 2216 Address Transparent mode. 2218 iFCP Ver: iFCP version number. SHALL be set to 1. 2220 LIVENESS TEST If non-zero, requests that the receiving 2221 INTERVAL: gateway transmit an LTEST message at the 2222 specified interval in seconds. If set to 2223 zero, LTEST messages SHALL NOT be sent. 2225 USER INFO: Contains any data desired by the requestor. 2226 This information MUST be echoed by the 2227 recipient in the CBIND response message. 2229 SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the 2230 N_PORT locally attached to the gateway 2231 originating the CBIND request. 2233 DESTINATION N_PORT The Worldwide Port Name (WWPN) of the 2234 NAME: N_PORT locally attached to the gateway 2235 receiving the CBIND request. 2237 The following shows the format of the CBIND response. 2239 +------+------------+------------+-----------+----------+ 2240 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2241 +------+------------+------------+-----------+----------+ 2242 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2243 +------+------------+------------+-----------+----------+ 2244 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2245 | | (Seconds) | | | 2246 +------+-------------------------+-----------+----------+ 2247 | 2 | USER INFO | 2248 +------+------------+------------+-----------+----------+ 2249 | 3 | | 2250 +------+ SOURCE N_PORT NAME | 2251 | 4 | | 2252 +------+------------------------------------------------+ 2253 | 5 | | 2254 +------+ DESTINATION N_PORT NAME | 2255 | 6 | | 2256 +------+-------------------------+----------------------+ 2257 | 7 | Reserved | CBIND Status | 2258 +------+-------------------------+----------------------+ 2259 | 8 | Reserved | CONNECTION HANDLE | 2260 +------+-------------------------+----------------------+ 2261 Total Length = 36 2263 Addr Mode: The address translation mode of the 2264 responding gateway. 0 = Address 2265 Translation mode, 1 = Address Transparent 2266 mode. 2268 iFCP Ver: iFCP version number. Shall be set to 1. 2270 LIVENESS TEST If non-zero, requests that the gateway 2271 INTERVAL: receiving the CBIND RESPONSE transmit an 2272 LTEST message at the specified interval in 2273 seconds. If zero, LTEST messages SHALL NOT 2274 be sent. 2276 USER INFO: Echoes the value received in the USER INFO 2277 field of the CBIND request message. 2279 SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of 2280 the N_PORT locally attached to the gateway 2281 issuing the CBIND request. 2283 DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of 2284 NAME: the N_PORT locally attached to the gateway 2285 issuing the CBIND response. 2287 CBIND STATUS: Indicates success or failure of the CBIND 2288 request. CBIND values are shown below. 2290 CONNECTION HANDLE: Contains a value assigned by the gateway to 2291 identify the connection. The connection 2292 handle is required when issuing the UNBIND 2293 request. 2295 CBIND Status Description 2296 ------------ ----------- 2298 0 Success 2299 1 - 15 Reserved 2300 16 Failed - Unspecified Reason 2301 17 Failed - No such device 2302 18 Failed - iFCP session already exists 2303 19 Failed - Lack of resources 2304 20 Failed - Incompatible address translation mode 2305 21 Failed - Incorrect protocol version number 2306 22 Failed - Gateway not Synchronized (see section 2307 8.2) 2308 Others Reserved 2310 6.2 Unbind Connection (UNBIND) 2311 UNBIND is used to terminate an iFCP session and disassociate the 2312 TCP connection as described in section 5.2.3. 2314 The UNBIND message is transmitted over the connection that is to be 2315 unbound. The time stamp words in the encapsulation header shall be 2316 set to zero in the request and response message frames. 2318 The following is the format of the UNBIND request message. 2320 +------+------------+------------+-----------+----------+ 2321 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2322 +------+------------+------------+-----------+----------+ 2323 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2324 +------+------------+------------+-----------+----------+ 2325 | 1 | USER INFO | 2326 +------+------------+------------+-----------+----------+ 2327 | 2 | Reserved | CONNECTION HANDLE | 2328 +------+------------+------------+----------------------+ 2329 | 3 | Reserved | 2330 +------+------------+------------+-----------+----------+ 2331 | 4 | Reserved | 2332 +------+------------+------------+-----------+----------+ 2334 USER INFO Contains any data desired by the requestor. 2335 This information MUST be echoed by the 2336 recipient in the UNBIND response message. 2338 CONNECTION HANDLE: Contains the gateway-assigned value from 2339 the CBIND request. 2341 The following shows the format of the UNBIND response message. 2343 +------+------------+------------+-----------+----------+ 2344 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2345 +------+------------+------------+-----------+----------+ 2346 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2347 +------+------------+------------+-----------+----------+ 2348 | 1 | USER INFO | 2349 +------+------------+------------+-----------+----------+ 2350 | 2 | Reserved | CONNECTION HANDLE | 2351 +------+------------+------------+-----------+----------+ 2352 | 3 | Reserved | 2353 +------+------------+------------+-----------+----------+ 2354 | 4 | Reserved | 2355 +------+------------+------------+-----------+----------+ 2356 | 5 | Reserved | UNBIND STATUS | 2357 +------+------------+------------+-----------+----------+ 2358 USER INFO Echoes the value received in the USER INFO 2359 field of the UNBIND request message. 2361 CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in 2362 the UNBIND request message. 2364 UNBIND STATUS: Indicates the success or failure of the 2365 UNBIND request as follows: 2367 Unbind Status Description 2368 ------------- ----------- 2370 0 Successful - No other status 2371 1 - 15 Reserved 2372 16 Failed - Unspecified Reason 2373 18 Failed - Connection ID Invalid 2374 Others Reserved 2376 6.3 LTEST -- Test Connection Liveness 2378 The LTEST message is sent at the interval specified in the CBIND 2379 request or response payload. The LTEST encapsulation time stamp 2380 SHALL be set as described in section 8.2.1 and may be used by the 2381 receiver to compute an estimate of propagation delay. However, the 2382 propagation delay limit SHALL NOT be enforced. 2384 +------+------------+------------+-----------+----------+ 2385 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2386 +------+------------+------------+-----------+----------+ 2387 | 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 | 2388 +------+------------+------------+-----------+----------+ 2389 | 1 | LIVENESS TEST INTERVAL | Reserved | 2390 | | (Seconds) | | 2391 +------+-------------------------+----------------------+ 2392 | 2 | COUNT | 2393 +------+------------+------------+-----------+----------+ 2394 | 3 | | 2395 +------+ SOURCE N_PORT NAME | 2396 | 4 | | 2397 +------+------------------------------------------------+ 2398 | 5 | | 2399 +------+ DESTINATION N_PORT NAME | 2400 | 6 | | 2401 +------+------------------------------------------------+ 2403 LIVENESS TEST Copy of the LIVENESS TEST INTERVAL 2404 INTERVAL: specified in the CBIND request or reply 2405 message. 2407 COUNT: Monotonically increasing value, initialized 2408 to 0 and incremented by one for each 2409 successive LTEST message. 2411 SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME 2412 specified in the CBIND request. 2414 DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT 2415 NAME: NAME specified in the CBIND request. 2417 7. Fibre Channel Link Services 2419 Link services provide a set of fibre channel functions that allow a 2420 port to send control information or request another port to perform 2421 a specific control function. 2423 There are three types of link services: 2425 a) Basic 2427 b) Extended 2429 c) ULP-specific (FC-4) 2431 Each link service message (request and reply) is carried by a fibre 2432 channel sequence, and can be segmented into multiple frames. 2434 The iFCP Layer is responsible for transporting link service 2435 messages across the IP network. This includes mapping Link Service 2436 messages appropriately from the domain of the fibre channel 2437 transport to that of the IP network. This process may require 2438 special processing and the inclusion of supplemental data by the 2439 iFCP layer. 2441 Each link service MUST be processed according to one of the 2442 following rules: 2444 a) Pass-through - The link service message and reply MUST be 2445 delivered to the receiving N_PORT by the iFCP protocol layer 2446 without altering the message payload. The link service message 2447 and reply are not processed by the iFCP protocol layer. 2449 b) Special - Applies to a link service reply or request requiring 2450 the intervention of the iFCP layer before forwarding to the 2451 destination N_PORT. Such messages may contain fibre channel 2452 addresses in the payload or may require other special 2453 processing. 2455 c) Rejected - When issued by a locally attached N_PORT, the 2456 specified link service request MUST be rejected by the iFCP 2457 gateway. The gateway SHALL return an LS_RJT response with a 2458 Reason Code of 0x0B (Command Not Supported) and a Reason Code 2459 Explanation of 0x0 (No Additional Explanation). 2461 This section describes the processing for special link services, 2462 including the manner in which supplemental data is added to the 2463 message payload. 2465 Appendix A enumerates all link services and the iFCP processing 2466 policy that applies to each. 2468 7.1 Special Link Service Messages 2470 Special link service messages require the intervention of the iFCP 2471 layer before forwarding to the destination N_PORT. Such 2472 intervention is required in order to: 2474 a) Service any link service message that requires special handling, 2475 such as a PLOGI. 2477 b) In address translation mode only, service any link service 2478 message that has an N_PORT address in the payload. 2480 Unless otherwise specified in the link service description, support 2481 for each special link service is MANDATORY. 2483 Such messages SHALL be transmitted in a fibre channel frame having 2484 the format shown in Figure 18 for extended link services or Figure 2485 19 for FC-4 link services. 2487 Word 2488 0<---Bit-->7 8<-------------------------------------------->31 2489 +------------+------------------------------------------------+ 2490 0| R_CTL | D_ID | 2491 |[Req = 0x22]|[Destination of extended link Service request] | 2492 |[Rep = 0x23]| | 2493 +------------+------------------------------------------------+ 2494 1| CS_CTL | S_ID | 2495 | | [Source of extended link service request] | 2496 +------------+------------------------------------------------+ 2497 2| TYPE | F_CTL | 2498 | [0x01] | | 2499 +------------+------------------+-----------------------------+ 2500 3| SEQ_ID | DF_CTL | SEQ_CNT | 2501 +------------+------------------+-----------------------------+ 2502 4| OX_ID | RX_ID | 2503 +-------------------------------+-----------------------------+ 2504 5| Parameter | 2505 | [ 00 00 00 00 ] | 2506 +-------------------------------------------------------------+ 2507 6| LS_COMMAND | 2508 | [Extended Link Service Command Code] | 2509 +-------------==----------------------------------------------+ 2510 7| | 2511 .| Additional Service Request Parameters | 2512 .| ( if any ) | 2513 n| | 2514 +-------------------------------------------------------------+ 2515 Figure 18 -- Format of an Extended Link Service Frame 2517 Word 2518 0<---Bit-->7 8<-------------------------------------------->31 2519 +------------+------------------------------------------------+ 2520 0| R_CTL | D_ID | 2521 |[Req = 0x32]| [Destination of FC-4 link Service request] | 2522 |[Rep = 0x33]| | 2523 +------------+------------------------------------------------+ 2524 1| CS_CTL | S_ID | 2525 | | [Source of FC-4 link service request] | 2526 +------------+------------------------------------------------+ 2527 2| TYPE | F_CTL | 2528 | (FC-4 | | 2529 | specific) | | 2530 +------------+------------------+-----------------------------+ 2531 3| SEQ_ID | DF_CTL | SEQ_CNT | 2532 +------------+------------------+-----------------------------+ 2533 4| OX_ID | RX_ID | 2534 +-------------------------------+-----------------------------+ 2535 5| Parameter | 2536 | [ 00 00 00 00 ] | 2537 +-------------------------------------------------------------+ 2538 6| LS_COMMAND | 2539 | [FC-4 Link Service Command Code] | 2540 +-------------------------------------------------------------+ 2541 7| | 2542 .| Additional Service Request Parameters | 2543 .| ( if any ) | 2544 n| | 2545 +-------------------------------------------------------------+ 2546 Figure 19 -- Format of an FC-4 Link Service Frame 2548 7.2 Link Services Requiring Payload Address Translation 2550 This section describes the handling for link service frames 2551 containing N_PORT addresses in the frame payload. Such addresses 2552 SHALL only be translated when the gateway is operating in address 2553 translation mode. When operating in address transparent mode, 2554 these addresses SHALL NOT be translated and such link service 2555 messages SHALL NOT be sent as special frames unless other 2556 processing by the iFCP layer is required. 2558 Supplemental data includes information required by the receiving 2559 gateway to convert an N_PORT address in the payload to an N_PORT 2560 address in the receiving gateway�s address space. The following 2561 rules define the manner in which such supplemental data shall be 2562 packaged and referenced. 2564 For an N_PORT address field, the gateway originating the frame MUST 2565 set the value in the payload to identify the address translation 2566 type as follows: 2568 0x00 00 01 - The gateway receiving the frame from the IP 2569 network MUST replace the contents of the field with the N_PORT 2570 alias of the frame originator. This translation type MUST be 2571 used when the address to be converted is that of the source 2572 N_PORT. 2574 0x00 00 02 - The gateway receiving the frame from the IP 2575 network MUST replace the contents of the field with the N_PORT 2576 ID of the destination N_PORT. This translation type MUST be 2577 used when the address to be converted is that of the 2578 destination N_PORT 2580 0x00 00 03 - The gateway receiving the frame from the IP 2581 network MUST reference the specified supplemental data to set 2582 the field contents. The supplemental information is the 64-bit 2583 world wide identifier of the N_PORT as set forth in the fibre 2584 channel specification [FC-FS]. If not otherwise part of the 2585 link service payload, this information MUST be appended in 2586 accordance with the applicable link service description. Unless 2587 specified otherwise, this translation type SHALL NOT be used if 2588 the address to be converted corresponds to that of the frame 2589 originator or recipient. 2591 Since fibre channel addressing rules prohibit the assignment of 2592 fabric addresses with a domain ID of 0, the above codes will never 2593 correspond to valid N_PORT fabric IDs. 2595 If the sending gateway cannot obtain the worldwide identifier of an 2596 N_PORT, the gateway SHALL terminate the request with an LS_RJT 2597 message as described in [FC-FS]. The Reason Code SHALL be set to 2598 0x07 (protocol error) and the Reason Explanation SHALL be set to 2599 0x1F (Invalid N_PORT identifier). 2601 Supplemental data is sent with the link service request or ACC 2602 frames in one of the following ways: 2604 a) By appending the necessary data to the end of the link service 2605 frame. 2607 b) By extending the sequence with additional frames. 2609 In the first case, a new frame SHALL be created whose length 2610 includes the supplemental data. The procedure for extending the 2611 link service sequence with additional frames is dependent on the 2612 link service type. 2614 For each field requiring address translation, the receiving gateway 2615 SHALL reference the translation type encoded in the field and 2616 replace it with the N_PORT address as shown in Table 7: 2618 +------------------+------------------------------------+ 2619 | Translation | N_PORT Translation | 2620 | Type Code | | 2621 +------------------+------------------------------------+ 2622 | 0x00 00 01 | Replace field contents with N_PORT | 2623 | | alias of frame originator. | 2624 +------------------+------------------------------------+ 2625 | 0x00 00 02 | Replace field contents with N_PORT | 2626 | | ID of frame recipient. | 2627 +------------------+------------------------------------+ 2628 | | Lookup N_PORT via iSNS query. | 2629 | | If locally attached, replace with | 2630 | 0x00 00 03 | N_PORT ID. | 2631 | | If remotely attached, replace with | 2632 | | N_PORT alias from remote N_PORT . | 2633 | | descriptor (see section 5.2.2.1). | 2634 +------------------+------------------------------------+ 2635 Table 7 -- Link Service Address Translation 2637 For translation type 3, the receiving gateway SHALL obtain the 2638 information needed to fill in the field in the link service frame 2639 payload by converting the specified N_PORT worldwide identifier to 2640 a gateway IP address and N_PORT ID. This information MUST be 2641 obtained through an iSNS name server query. If the query is 2642 unsuccessful, the gateway SHALL terminate the request with an 2643 LS_RJT response message as described in [FC-FS]. The Reason Code 2644 SHALL be set to 0x07 (protocol error) and the Reason Explanation 2645 SHALL be set to 0x1F (Invalid N_PORT identifier). 2647 After applying the supplemental data, the receiving gateway SHALL 2648 forward the resulting link service frames to the destination N_PORT 2649 with the supplemental information removed. 2651 7.3 Fibre Channel Link Services Processed by iFCP 2653 The following Extended and FC-4 Link Service Messages must receive 2654 special processing. 2656 Extended Link Service LS_COMMAND Mnemonic 2657 Messages ---------- -------- 2658 ---------------------- 2659 Abort Exchange 0x06 00 00 00 ABTX 2660 Discover Address 0x52 00 00 00 ADISC 2661 Discover Address Accept 0x02 00 00 00 ADISC ACC 2662 FC Address Resolution 0x55 00 00 00 FARP-REPLY 2663 Protocol Reply 2664 FC Address Resolution 0x54 00 00 00 FARP-REQ 2665 Protocol Request 2666 Logout 0x05 00 00 00 LOGO 2667 Port Login 0x30 00 00 00 PLOGI 2668 Read Exchange Status Block 0x08 00 00 00 RES 2669 Read Exchange Status Block 0x02 00 00 00 RES ACC 2670 Accept 2671 Read Link Error Status 0x0F 00 00 00 RLS 2672 Block 2673 Read Sequence Status Block 0x09 00 00 00 RSS 2674 Reinstate Recovery 0x12 00 00 00 RRQ 2675 Qualifier 2676 Request Sequence 0x0A 00 00 00 RSI 2677 Initiative 2678 Scan Remote Loop 0x7B 00 00 00 SRL 2679 Third Party Process Logout 0x24 00 00 00 TPRLO 2680 Third Party Process Logout 0x02 00 00 00 TPRLO ACC 2681 Accept 2683 FC-4 Link Service Messages LS_COMMAND Mnemonic 2684 -------------------------- ---------- -------- 2685 FCP Read Exchange Concise 0x13 00 00 00 REC 2686 FCP Read Exchange Concise 0x02 00 00 00 REC ACC 2687 Accept 2689 Each encapsulated fibre channel frame that is part of a special 2690 link service MUST have the SPC bit set to one in the iFCP FLAGS 2691 field of the encapsulation header as specified in section 5.3.1. 2692 If an ACC link service response requires special processing, the 2693 responding gateway SHALL place a copy of LS_COMMAND bits 0 through 2694 7 from the link service request frame in the LS_COMMAND_ACC field 2695 of the ACC encapsulation header. Supplemental data (if any) MUST be 2696 appended as described in the following section. 2698 The format of each special link service message, including 2699 supplemental data where applicable, is shown in the following 2700 sections. Each description shows the basic format, as specified in 2701 the applicable FC standard, followed by supplemental data as shown 2702 in the example below. 2704 +------+------------+------------+-----------+----------+ 2705 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2706 +------+------------+------------+-----------+----------+ 2707 | 0 | LS_COMMAND | 2708 +------+------------+------------+-----------+----------+ 2709 | 1 | | 2710 | . | | 2711 | . | Link Service Frame Payload | 2712 | | | 2713 | n | | 2714 +======+============+============+===========+==========+ 2715 | n+1 | | 2716 | . | Supplemental Data | 2717 | . | (if any) | 2718 | n+k | | 2719 +======+================================================+ 2720 Figure 20 -- Special Link Service Frame Payload 2722 7.3.1 Special Extended Link Services 2724 The following sections define extended link services for which 2725 special processing is required. 2727 7.3.1.1 Abort Exchange (ABTX) 2729 ELS Format: 2731 +------+------------+------------+-----------+----------+ 2732 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2733 +------+------------+------------+-----------+----------+ 2734 | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | 2735 +------+------------+------------+-----------+----------+ 2736 | 1 | RRQ Status | Exchange Originator S_ID | 2737 +------+------------+------------+-----------+----------+ 2738 | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| 2739 +------+------------+------------+-----------+----------+ 2740 | 3-10 | Optional association header (32 bytes | 2741 +======+============+============+===========+==========+ 2743 Fields Requiring Translation Supplemental Data 2744 Address Translation Type (see (type 3 only) 2745 ------------------- section 7.2) ------------ 2746 ----------- 2748 Exchange Originator 1, 2 N/A 2749 S_ID 2751 Other Special Processing: 2753 None 2755 7.3.1.2 Discover Address (ADISC) 2757 Format of ADISC ELS: 2759 +------+------------+------------+-----------+----------+ 2760 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2761 +------+------------+------------+-----------+----------+ 2762 | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | 2763 +------+------------+------------+-----------+----------+ 2764 | 1 | Reserved | Hard address of ELS Originator | 2765 +------+------------+------------+-----------+----------+ 2766 | 2-3 | Port Name of Originator | 2767 +------+------------+------------+-----------+----------+ 2768 | 4-5 | Node Name of originator | 2769 +------+------------+------------+-----------+----------+ 2770 | 6 | Rsvd | N_PORT ID of ELS Originator | 2771 +======+============+============+===========+==========+ 2773 Fields Requiring Translation Supplemental Data 2774 Address Translation Type (see (type 3 only) 2775 ------------------- section 7.2) ------------ 2776 ------------- 2778 N_PORT ID of ELS 1 N/A 2779 Originator 2781 Other Special Processing: 2783 The Hard Address of the ELS originator SHALL be set to 0. 2785 7.3.1.3 Discover Address Accept (ADISC ACC) 2787 Format of ADISC ACC ELS: 2789 +------+------------+------------+-----------+----------+ 2790 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2791 +------+------------+------------+-----------+----------+ 2792 | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | 2793 +------+------------+------------+-----------+----------+ 2794 | 1 | Reserved | Hard address of ELS Originator | 2795 +------+------------+------------+-----------+----------+ 2796 | 2-3 | Port Name of Originator | 2797 +------+------------+------------+-----------+----------+ 2798 | 4-5 | Node Name of originator | 2799 +------+------------+------------+-----------+----------+ 2800 | 6 | Rsvd | N_PORT ID of ELS Originator | 2801 +======+============+============+===========+==========+ 2803 Fields Requiring Translation Supplemental Data 2804 Address Translation Type (see (type 3 only) 2805 ------------------- section 7.2) ------------ 2806 ------------ 2808 N_PORT ID of ELS 1 N/A 2809 Originator 2811 Other Special Processing: 2813 The Hard Address of the ELS originator SHALL be set to 0. 2815 7.3.1.4 FC Address Resolution Protocol Reply (FARP-REPLY) 2817 The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS 2818 (see section 7.3.1.5) to perform the address resolution services 2819 required by the FC-VI protocol [FC-VI] and the fibre channel 2820 mapping of IP and ARP specified in RFC 2625 [RFC2625]. 2822 Format of FARP-REPLY ELS: 2824 +------+------------+------------+-----------+----------+ 2825 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2826 +------+------------+------------+-----------+----------+ 2827 | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | 2828 +------+------------+------------+-----------+----------+ 2829 | 1 | Match Addr | Requesting N_PORT Identifier | 2830 | | Code Points| | 2831 +------+------------+------------+-----------+----------+ 2832 | 2 | Responder | Responding N_PORT Identifier | 2833 | | Action | | 2834 +------+------------+------------+-----------+----------+ 2835 | 3-4 | Requesting N_PORT Port_Name | 2836 +------+------------+------------+-----------+----------+ 2837 | 5-6 | Requesting N_PORT Node_Name | 2838 +------+------------+------------+-----------+----------+ 2839 | 7-8 | Responding N_PORT Port_Name | 2840 +------+------------+------------+-----------+----------+ 2841 | 9-10 | Responding N_PORT Node_Name | 2842 +------+------------+------------+-----------+----------+ 2843 | 11-14| Requesting N_PORT IP Address | 2844 +------+------------+------------+-----------+----------+ 2845 | 15-18| Responding N_PORT IP Address | 2846 +======+============+============+===========+==========+ 2848 Fields Requiring Translation Supplemental Data 2849 Address Translation Type (see (type 3 only) 2850 ------------------- section 7.2) ----------------- 2851 ------------- 2853 Requesting N_PORT 2 N/A 2854 Identifier 2856 Responding N_PORT 1 N/A 2857 identifier 2859 Other Special Processing: 2861 None. 2863 7.3.1.5 FC Address Resolution Protocol Request (FARP-REQ) 2865 The FARP-REQ ELS is used to in conjunction with the FC-VI protocol 2866 [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP 2867 and FC address resolution in an FC fabric. The FARP-REQ ELS is 2868 usually directed to the fabric broadcast server at well-known 2869 address 0xFF-FF-FF for retransmission to all attached N_PORTs. 2871 Section 9.4 describes the iFCP implementation of FC broadcast 2872 server functionality in an iFCP fabric. 2874 Format of FARP_REQ ELS: 2876 +------+------------+------------+-----------+----------+ 2877 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2878 +------+------------+------------+-----------+----------+ 2879 | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | 2880 +------+------------+------------+-----------+----------+ 2881 | 1 | Match Addr | Requesting N_PORT Identifier | 2882 | | Code Points| | 2883 +------+------------+------------+-----------+----------+ 2884 | 2 | Responder | Responding N_PORT Identifier | 2885 | | Action | | 2886 +------+------------+------------+-----------+----------+ 2887 | 3-4 | Requesting N_PORT Port_Name | 2888 +------+------------+------------+-----------+----------+ 2889 | 5-6 | Requesting N_PORT Node_Name | 2890 +------+------------+------------+-----------+----------+ 2891 | 7-8 | Responding N_PORT Port_Name | 2892 +------+------------+------------+-----------+----------+ 2893 | 9-10 | Responding N_PORT Node_Name | 2894 +------+------------+------------+-----------+----------+ 2895 | 11-14| Requesting N_PORT IP Address | 2896 +------+------------+------------+-----------+----------+ 2897 | 15-18| Responding N_PORT IP Address | 2898 +======+============+============+===========+==========+ 2900 Fields Requiring Translation Supplemental Data 2901 Address Translation Type (see (type 3 only) 2902 ------------------- section 7.2) ----------------- 2903 ----------- 2905 Requesting N_PORT 3 Requesting N_PORT 2906 Identifier Port Name 2908 Responding N_PORT 3 Responding N_PORT 2909 Identifier Port Name 2911 Other Special Processing: 2913 None. 2915 7.3.1.6 Logout (LOGO) and LOGO ACC 2917 ELS Format: 2919 +------+------------+------------+-----------+----------+ 2920 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2921 +------+------------+------------+-----------+----------+ 2922 | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | 2923 +------+------------+------------+-----------+----------+ 2924 | 1 | Rsvd | N_PORT ID being logged out | 2925 +------+------------+------------+-----------+----------+ 2926 | 2-3 | Port name of the LOGO originator (8 bytes) | 2927 +======+============+============+===========+==========+ 2929 This ELS SHALL always be sent as a special ELS regardless of the 2930 translation mode in effect. 2932 Fields Requiring Translation Supplemental Data 2933 Address Translation Type(see (type 3 only) 2934 ------------------- section 7.2) -------------- 2935 ----------- 2937 N_PORT ID Being 1 N/A 2938 Logged Out 2940 Other Special Processing: 2942 See section 5.2.3. 2944 7.3.1.7 Port Login (PLOGI) and PLOGI ACC 2946 A PLOGI ELS establishes fibre channel communications between two 2947 N_PORTs and triggers the creation of an iFCP session if one does 2948 not exist. 2950 The PLOGI request and ACC response carry information identifying 2951 the originating N_PORT, including a specification of its 2952 capabilities. If the destination N_PORT accepts the login request, 2953 it sends an Accept response (an ACC frame with PLOGI payload), 2954 specifying its capabilities. This exchange establishes the 2955 operating environment for the two N_PORTs. 2957 The following figure is duplicated from [FC-FS], and shows the 2958 PLOGI message format for both the request and Accept (ACC) 2959 response. An N_PORT will reject a PLOGI request by transmitting an 2960 LS_RJT message containing no payload. 2962 +------+------------+------------+-----------+----------+ 2963 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2964 +------+------------+------------+-----------+----------+ 2965 | 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 | 2966 | | Acc = 0x2 | | | | 2967 +------+------------+------------+-----------+----------+ 2968 | 1-4 | Common Service Parameters | 2969 +------+------------+------------+-----------+----------+ 2970 | 5-6 | N_PORT Name | 2971 +------+------------+------------+-----------+----------+ 2972 | 7-8 | Node Name | 2973 +------+------------+------------+-----------+----------+ 2974 | 9-12 | Class 1 Service Parameters | 2975 +------+------------+------------+-----------+----------+ 2976 |13-17 | Class 2 Service Parameters | 2977 +------+------------+------------+-----------+----------+ 2978 |18-21 | Class 3 Service Parameters | 2979 +------+------------+------------+-----------+----------+ 2980 |22-25 | Class 4 Service Parameters | 2981 +------+------------+------------+-----------+----------+ 2982 |26-29 | Vendor Version Level | 2983 +======+============+============+===========+==========+ 2984 Figure 21 -- Format of PLOGI Request and ACC Payloads 2986 Details of the above fields, including common and class-based 2987 service parameters, can be found in [FC-FS]. 2989 Special Processing 2991 As specified in section 5.2.2.2, a PLOGI request addressed to a 2992 remotely attached N_PORT MUST cause the creation of an iFCP 2993 session if one does not exist. Otherwise, the PLOGI and PLOGI 2994 ACC payloads MUST be passed through without modification to the 2995 destination N_PORT using the existing iFCP session. In either 2996 case, the SPC bit must be set in the frame encapsulation header 2997 as specified in 5.3.3. 2999 If the CBIND to create the iFCP session fails, the issuing 3000 gateway SHALL terminate the PLOGI with an LS_RJT response. The 3001 Reason Code and Reason Code Explanation SHALL be selected from 3002 Table 8 based on the CBIND failure status. 3004 +---------------+-------------------+---------------------+ 3005 | CBIND Failure | LS_RJT Reason | LS_RJT Reason Code | 3006 | Status | Code | Explanation | 3007 +===============+===================+=====================+ 3008 | Unspecified | Unable to Perform | No additional | 3009 | Reason (16) | Command Request | explanation (0x00) | 3010 | | (0x09) | | 3011 +---------------+-------------------+---------------------+ 3012 | No Such | Unable to Perform | Invalid N_PORT | 3013 | Device (17) | Command Request | Name (0x0D) | 3014 | | (0x09) | | 3015 +---------------+-------------------+---------------------+ 3016 | Lack of | Unable to Perform | Insufficient | 3017 | Resources (19)| Command Request | Resources to Support| 3018 | | (0x09) | Login (0x29) | 3019 +---------------+-------------------+---------------------+ 3020 | Incompatible | Unable to Perform | No additional | 3021 | Address | Command Request | explanation (0x00) | 3022 | Translation | (0x09) | | 3023 | Mode (20) | | | 3024 +---------------+-------------------+---------------------+ 3025 | Incorrect iFCP| Unable to Perform | No additional | 3026 | Protocol | Command Request | explanation (0x00) | 3027 | version number| (0x09) | | 3028 | (21) | | | 3029 +---------------+-------------------+---------------------+ 3030 | Gateway not | Unable to Perform | No additional | 3031 | Synchronized | Command Request | explanation (0x00) | 3032 | (22) | (0x09) | | 3033 +---------------+-------------------+---------------------+ 3034 Table 8 -- PLOGI LS_RJT Status for CBIND Failures 3036 7.3.1.8 Read Exchange Status Block (RES) 3038 ELS Format: 3040 +------+------------+------------+-----------+----------+ 3041 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3042 +------+------------+------------+-----------+----------+ 3043 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3044 +------+------------+------------+-----------+----------+ 3045 | 1 | Rsvd | Exchange Originator S_ID | 3046 +------+------------+------------+-----------+----------+ 3047 | 2 | OX_ID | RX_ID | 3048 +------+------------+------------+-----------+----------+ 3049 | 3-10 | Association header (may be optionally req�d) | 3050 +======+============+============+===========+==========+ 3051 | 11-12| Port name of the Exchange Originator (8 bytes) | 3052 +======+============+============+===========+==========+ 3053 Fields Requiring Translation Supplemental Data 3054 Address Translation Type(see (type 3 only) 3055 ------------------- section 7.2) ------------------ 3056 ----------- 3058 Exchange Originator 1, 2 or 3 Port Name of the 3059 S_ID Exchange Originator 3061 Other Special Processing: 3063 None. 3065 7.3.1.9 Read Exchange Status Block Accept (RES ACC) 3067 Format of ELS Accept Response: 3069 +------+------------+------------+-----------+----------+ 3070 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3071 +------+------------+------------+-----------+----------+ 3072 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3073 +------+------------+------------+-----------+----------+ 3074 | 1 | OX_ID | RX_ID | 3075 +------+------------+------------+-----------+----------+ 3076 | 2 | Rsvd | Exchange Originator N_PORT ID | 3077 +------+------------+------------+-----------+----------+ 3078 | 3 | Rsvd | Exchange Responder N_PORT ID | 3079 +------+------------+------------+-----------+----------+ 3080 | 4 | Exchange Status Bits | 3081 +------+------------+------------+-----------+----------+ 3082 | 5 | Reserved | 3083 +------+------------+------------+-----------+----------+ 3084 | 6-n | Service Parameters and Sequence Statuses | 3085 | | as described in [FCS] | 3086 +======+============+============+===========+==========+ 3087 |n+1- | Port name of the Exchange Originator (8 bytes) | 3088 |n+2 | | 3089 +======+============+============+===========+==========+ 3090 |n+3- | Port name of the Exchange Responder (8 bytes) | 3091 |n+4 | | 3092 +======+============+============+===========+==========+ 3093 Fields Requiring Translation Supplemental Data 3094 Address Translation Type(see (type 3 only) 3095 ------------------- section 7.2) ------------------ 3096 ----------- 3098 Exchange Originator 1, 2 or 3 Port Name of the 3099 N_PORT ID Exchange Originator 3101 Exchange Responder 1, 2 or 3 Port Name of the 3102 N_PORT ID Exchange Responder 3104 When supplemental data is required, the ELS SHALL be extended by 4 3105 words as shown above. If the translation type for the Exchange 3106 Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, 3107 the corresponding 8-byte port name SHALL be set to all zeros. 3109 Other Special Processing: 3111 None. 3113 7.3.1.10 Read Link Error Status (RLS) 3115 ELS Format: 3117 +------+------------+------------+-----------+----------+ 3118 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3119 +------+------------+------------+-----------+----------+ 3120 | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | 3121 +------+------------+------------+-----------+----------+ 3122 | 1 | Rsvd | N_PORT Identifier | 3123 +======+============+============+===========+==========+ 3124 | 2-3 | Port name of the N_PORT (8 bytes) | 3125 +======+============+============+===========+==========+ 3127 Fields Requiring Translation Supplemental Data (type 3128 Address Translation Type(see 3 only) 3129 ------------------- section 7.2) ------------------ 3130 ----------- 3132 N_PORT Identifier 1, 2 or 3 Port Name of the N_PORT 3134 Other Special Processing: 3136 None. 3138 7.3.1.11 Read Sequence Status Block (RSS) 3140 ELS Format: 3142 +------+------------+------------+-----------+----------+ 3143 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3144 +------+------------+------------+-----------+----------+ 3145 | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | 3146 +------+------------+------------+-----------+----------+ 3147 | 1 | SEQ_ID | Exchange Originator S_ID | 3148 +------+------------+------------+-----------+----------+ 3149 | 2 | OX_ID | RX_ID | 3150 +======+============+============+===========+==========+ 3151 | 3-4 |Port name of the Exchange Originator (8 bytes) | 3152 +======+============+============+===========+==========+ 3154 Fields Requiring Translation Supplemental Data 3155 Address Translation Type(see (type 3 only) 3156 ------------------- section 7.2) ------------------ 3157 ----------- 3159 Exchange Originator 1, 2 or 3 Port Name of the 3160 S_ID Exchange Originator 3162 Other Special Processing: 3164 None. 3166 7.3.1.12 Reinstate Recovery Qualifier (RRQ) 3168 ELS Format: 3170 +------+------------+------------+-----------+----------+ 3171 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3172 +------+------------+------------+-----------+----------+ 3173 | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | 3174 +------+------------+------------+-----------+----------+ 3175 | 1 | Rsvd | Exchange Originator S_ID | 3176 +------+------------+------------+-----------+----------+ 3177 | 2 | OX_ID | RX_ID | 3178 +------+------------+------------+-----------+----------+ 3179 | 3-10 | Association header (may be optionally req�d) | 3180 +======+============+============+===========+==========+ 3182 Fields Requiring Translation Supplemental Data 3183 Address Translation Type(see (type 3 only) 3184 ------------------- section 7.2) ------------------ 3185 ----------- 3187 Exchange Originator 1 or 2 N/A 3188 S_ID 3189 Other Special Processing: 3191 None. 3193 7.3.1.13 Request Sequence Initiative (RSI) 3195 ELS Format: 3197 +------+------------+------------+-----------+----------+ 3198 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3199 +------+------------+------------+-----------+----------+ 3200 | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | 3201 +------+------------+------------+-----------+----------+ 3202 | 1 | Rsvd | Exchange Originator S_ID | 3203 +------+------------+------------+-----------+----------+ 3204 | 2 | OX_ID | RX_ID | 3205 +------+------------+------------+-----------+----------+ 3206 | 3-10 | Association header (may be optionally req�d) | 3207 +======+============+============+===========+==========+ 3209 Fields Requiring Translation Supplemental Data 3210 Address Translation Type(see (type 3 only) 3211 ------------------- section 7.2) ------------------ 3212 ----------- 3214 Exchange Originator 1 or 2 N/A 3215 S_ID 3217 Other Special Processing: 3219 None. 3221 7.3.1.14 Scan Remote Loop (SRL) 3223 SRL allows a remote loop to be scanned to detect changes in the 3224 device configuration. Any changes will trigger a fibre channel 3225 state change notification and subsequent update of the iSNS 3226 database. 3228 ELS Format: 3230 +------+------------+------------+-----------+----------+ 3231 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3232 +------+------------+------------+-----------+----------+ 3233 | 0 | Cmd = 0x7B | Reserved | 3234 +------+------------+------------+-----------+----------+ 3235 | 1 | Flag | Address Identifier of the FL_PORT | 3236 | | | (see B.1) | 3237 +======+============+============+===========+==========+ 3238 | 2-3 | World-Wide Name of the Remote FL_PORT | 3239 +======+============+============+===========+==========+ 3241 Fields Requiring Translation Supplemental Data 3242 Address Translation Type(see (type 3 only) 3243 ------------------- section 7.2) ------------------ 3244 ----------- 3246 Address Identifier 3 World-Wide Name of 3247 of the FL_PORT the remote FL_PORT 3249 Other Special Processing: 3251 The D_ID field is the address of the Domain Controller associated 3252 with the remote loop. The format of the Domain Controller address 3253 is hex �FF FC' || Domain_ID, where Domain_ID is the gateway- 3254 assigned alias representing. the remote gateway or switch element 3255 being queried. The D_ID after translation by the remote gateway 3256 identifies the gateway or switch element to be scanned within the 3257 remote gateway region. 3259 The FLAG field defines the scope of the SRL. If set to 0, all loop 3260 port interfaces on the given switch element or gateway are scanned. 3261 If set to one, the loop port interface on the gateway or switch 3262 element to be scanned MUST be specified in bits 8 through 31. 3264 If the Flag field is zero the SRL request SHALL NOT be sent as a 3265 special ELS. 3267 If the Domain_ID represents a remote switch or gateway and an iFCP 3268 session to the remote Domain Controller does not exist, the 3269 requesting gateway SHALL create the iFCP session. 3271 7.3.1.15 Third Party Process Logout (TPRLO) 3273 TPRLO provides a mechanism for an N_PORT (third party) to remove 3274 one or more process login sessions that exist between the 3275 destination N_PORT and other N_PORTs specified in the command. 3276 This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, 3277 each of which when combined with the destination N_PORT identifies 3278 a process login to be terminated by the command. 3280 +--------+------------+--------------------+----------------------+ 3281 | Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 | 3282 +--------+------------+--------------------+----------------------+ 3283 | 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length | 3284 +--------+------------+--------------------+----------------------+ 3285 | 1 | TPRLO Logout Parameter Page 0 | 3286 +--------+--------------------------------------------------------+ 3287 | 5 | TPRLO Logout Parameter Page 1 | 3288 +--------+--------------------------------------------------------+ 3289 .... 3290 +--------+--------------------------------------------------------+ 3291 |(4*n)+1 | TPRLO Logout Parameter page n | 3292 +--------+--------------------------------------------------------+ 3293 Figure 22 -- Format of TPRLO ELS 3295 Each TPRLO parameter page contains parameters identifying one or 3296 more image pairs and may be associated with a single FC-4 protocol 3297 type, common to all FC-4 protocol types between the specified image 3298 pair, or global to all specified image pairs. The format of a TPRLO 3299 page requiring address translation is shown in Figure 23. 3300 Additional information on TPRLO can be found in [FC-FS]. 3302 +------+------------+------------+-----------+----------+ 3303 | Word | Bits 0-7 | Bits 8-15 | Bits 16-31 | 3304 +------+------------+------------+-----------+----------+ 3305 | 0 | TYPE Code | TYPE CODE | | 3306 | | or | EXTENSION | TPRLO Flags | 3307 | | Common SVC | | | 3308 | | Parameters | | | 3309 +------+------------+------------+-----------+----------+ 3310 | 1 | Third Party Process Associator | 3311 +------+------------+------------+-----------+----------+ 3312 | 2 | Responder Process Associator | 3313 +------+------------+------------+-----------+----------+ 3314 | 3 | Reserved | Third Party Originator N_PORT ID | 3315 +======+============+============+===========+==========+ 3316 | 4-5 | Worldwide Name of Third Party Originator | 3317 | | N_PORT | 3318 +------+------------------------------------------------+ 3319 Figure 23 -- Format of an Augmented TPRLO Parameter Page 3321 The TPRLO flags that affect supplemented ELS processing are as 3322 follows: 3324 Bit 18: Third party Originator N_PORT Validity. When set to 3325 one, this bit indicates that word 3, bits 8-31 (Third 3326 Party Originator N_PORT ID) are meaningful. 3328 Bit 19: Global Process logout. When set to one, this bit 3329 indicates that all image pairs for all N_PORTs of the 3330 specified FC-4 protocol shall be invalidated. When the 3331 value of this bit is one, only one logout parameter page 3332 is permitted in the TPRLO payload. 3334 If bit 18 has a value of zero and bit 19 has a value of one in the 3335 TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. 3337 Otherwise the originating gateway SHALL process the ELS as follows: 3339 a) The first word of the TPRLO payload SHALL NOT be modified. 3341 b) Each TPRLO parameter page shall be extended by two words as 3342 shown in Figure 23. 3344 c) If word 0, bit 18 (Third Party Originator N_PORT ID validity) 3345 in the TPRLO flags field has a value of one, then the sender 3346 shall place the worldwide port name of the fibre channel 3347 device's N_PORT in the extension words. The N_PORT ID SHALL be 3348 set to 3. Otherwise, the contents of the extension words and 3349 the Third Party Originator N_PORT ID SHALL be set to zero. 3351 d) The ELS originator SHALL set the SPC bit in the encapsulation 3352 header of each augmented frame comprising the ELS (see section 3353 5.3.1). 3355 e) If the ELS contains a single TPRLO parameter page, the 3356 originator SHALL increase the frame length as necessary to 3357 include the extended parameter page. 3359 f) If the ELS to be augmented contains multiple TPRLO parameter 3360 pages, the FC frames created to contain the augmented ELS 3361 payload SHALL NOT exceed the maximum frame size that can be 3362 accepted by the destination N_PORT. 3364 Each fibre channel frame SHALL contain an integer number of 3365 extended TPRLO parameter pages. The maximum number of extended 3366 TPRLO parameter pages in a frame SHALL be limited to the number 3367 that can be held without exceeding the above upper limit. New 3368 frames resulting from the extension of the TPRLO pages to 3369 include the supplemental data SHALL be created by extending the 3370 SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT 3371 be modified. 3373 The gateway receiving the augmented TPRLO ELS SHALL generate ELS 3374 frames to be sent to the destination N_PORT by copying word 0 of 3375 the ELS payload and processing each augmented parameter page as 3376 follows: 3378 a) If word 0, bit 18 has a value of one, create a parameter page by 3379 copying words 0 through 2 of the augmented parameter page. The 3380 Third Party Originator N_PORT ID in word 3 shall be generated by 3381 referencing the supplemental data as described in section 7.2. 3383 b) If word 0, bit 18 has a value of zero, create a parameter page 3384 by copying words 0 through 3 of the augmented parameter page. 3386 The size of each frame to be sent to the destination N_PORT MUST 3387 NOT exceed the maximum frame size that the destination N_PORT can 3388 accept. The sequence identifier in each frame header SHALL be 3389 copied from the augmented ELS and the sequence count SHALL be 3390 monotonically increasing. 3392 7.3.1.16 Third Party Logout Accept (TPRLO ACC) 3394 The format of the TPRLO ACC frame is shown in Figure 24. 3396 +--------+------------+--------------------+----------------------+ 3397 | Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 | 3398 +--------+------------+--------------------+----------------------+ 3399 | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | 3400 +--------+------------+--------------------+----------------------+ 3401 | 1 | TPRLO Logout Parameter Page 0 | 3402 +--------+--------------------------------------------------------+ 3403 | 5 | TPRLO Logout Parameter Page 1 | 3404 +--------+--------------------------------------------------------+ 3405 .... 3406 +--------+--------------------------------------------------------+ 3407 |(4*n)+1 | TPRLO Logout Parameter page n | 3408 +--------+--------------------------------------------------------+ 3409 Figure 24 -- Format of TPRLO ACC ELS 3411 The format of the parameter page and rules for parameter page 3412 augmentation are as specified in section 7.3.1.15. 3414 7.3.2 Special FC-4 Link Services 3416 The following sections define FC-4 link services for which special 3417 processing is required. 3419 7.3.2.1 FC-4 Link Services defined by FCP 3421 7.3.2.1.1 Read Exchange Concise (REC) 3423 Link Service Request Format: 3425 +------+------------+------------+-----------+----------+ 3426 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3427 +------+------------+------------+-----------+----------+ 3428 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3429 +------+------------+------------+-----------+----------+ 3430 | 1 | Rsvd | Exchange Originator S_ID | 3431 +------+------------+------------+-----------+----------+ 3432 | 2 | OX_ID | RX_ID | 3433 +======+============+============+===========+==========+ 3434 | 3-4 |Port name of the exchange originator (8 bytes) | 3435 | | (present only for translation type 3) | 3436 +======+============+============+===========+==========+ 3438 Fields Requiring Translation Supplemental Data 3439 Address Translation Type(see (type 3 only) 3440 ------------------- section 7.2) ------------------ 3441 ----------- 3443 Exchange Originator 1, 2 or 3 Port Name of the 3444 S_ID Exchange 3445 Originator 3447 Other Special Processing: 3449 None. 3451 7.3.2.1.2 Read Exchange Concise Accept (REC ACC) 3453 Format of REC ACC Response: 3455 +------+------------+------------+-----------+----------+ 3456 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3457 +------+------------+------------+-----------+----------+ 3458 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3459 +------+------------+------------+-----------+----------+ 3460 | 1 | OX_ID | RX_ID | 3461 +------+------------+------------+-----------+----------+ 3462 | 2 | Rsvd | Exchange Originator N_PORT ID | 3463 +------+------------+------------+-----------+----------+ 3464 | 3 | Rsvd | Exchange Responder N_PORT ID | 3465 +------+------------+------------+-----------+----------+ 3466 | 4 | Data Transfer Count | 3467 +------+------------+------------+-----------+----------+ 3468 | 5 | Exchange Status | 3469 +======+============+============+===========+==========+ 3470 | 6-7 |Port name of the Exchange Originator (8 bytes) | 3471 +======+============+============+===========+==========+ 3472 | 8-9 |Port name of the Exchange Responder (8 bytes) | 3473 +======+============+============+===========+==========+ 3475 Fields Requiring Translation Supplemental Data 3476 Address Translation Type(see (type 3 only) 3477 ------------------- section 7.2) ------------------ 3478 ----------- 3480 Exchange Originator 1, 2 or 3 Port Name of the 3481 N_PORT ID Exchange Originator 3483 Exchange Responder 1, 2 or 3 Port Name of the 3484 N_PORT ID Exchange Responder 3486 When supplemental data is required, the frame SHALL always be 3487 extended by 4 words as shown above. If the translation type for 3488 the Exchange Originator N_PORT ID or the Exchange Responder N_PORT 3489 ID is 1 or 2, the corresponding 8-byte port name SHALL be set to 3490 all zeros. 3492 Other Special Processing: 3494 None. 3496 7.4 FLOGI Service Parameters Supported by an iFCP Gateway 3498 The FLOGI ELS is issued by an N_PORT that wishes to access the 3499 fabric transport services. 3501 The format of the FLOGI request and FLOGI ACC payloads are 3502 identical to the PLOGI request and ACC payloads described in 3503 section 7.3.1.7. 3505 +------+------------+------------+-----------+----------+ 3506 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3507 +------+------------+------------+-----------+----------+ 3508 | 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 | 3509 | | Acc = 0x2 | | | | 3510 +------+------------+------------+-----------+----------+ 3511 | 1-4 | Common Service Parameters | 3512 +------+------------+------------+-----------+----------+ 3513 | 5-6 | N_PORT Name | 3514 +------+------------+------------+-----------+----------+ 3515 | 7-8 | Node Name | 3516 +------+------------+------------+-----------+----------+ 3517 | 9-12 | Class 1 Service Parameters | 3518 +------+------------+------------+-----------+----------+ 3519 |13-17 | Class 2 Service Parameters | 3520 +------+------------+------------+-----------+----------+ 3521 |18-21 | Class 3 Service Parameters | 3522 +------+------------+------------+-----------+----------+ 3523 |22-25 | Class 4 Service Parameters | 3524 +------+------------+------------+-----------+----------+ 3525 |26-29 | Vendor Version Level | 3526 +======+============+============+===========+==========+ 3527 Figure 25 -- FLOGI Request and ACC Payload Format 3529 A full description of each parameter is given in [FC-FS]. 3531 This section tabulates the protocol-dependent service parameters 3532 supported by a fabric port attached to an iFCP gateway. 3534 The service parameters carried in the payload of an FLOGI extended 3535 link service request MUST be set in accordance with 3536 Table 9. 3538 +-----------------------------------------+---------------+ 3539 | | Fabric Login | 3540 | Service Parameter | Class | 3541 | +---+---+---+---+ 3542 | | 1 | 2 | 3 | 4 | 3543 +-----------------------------------------+---+---+---+---+ 3544 | Class Validity | n | M | M | n | 3545 +-----------------------------------------+---+---+---+---+ 3546 | Service Options | | 3547 +-----------------------------------------+---+---+---+---+ 3548 | Intermix Mode | n | n | n | n | 3549 +-----------------------------------------+---+---+---+---+ 3550 | Stacked Connect-Requests | n | n | n | n | 3551 +-----------------------------------------+---+---+---+---+ 3552 | Sequential Delivery | n | M | M | n | 3553 +-----------------------------------------+---+---+---+---+ 3554 | Dedicated Simplex | n | n | n | n | 3555 +-----------------------------------------+---+---+---+---+ 3556 | Camp on | n | n | n | n | 3557 +-----------------------------------------+---+---+---+---+ 3558 | Buffered Class 1 | n | n | n | n | 3559 +-----------------------------------------+---+---+---+---+ 3560 | Priority | n | n | n | n | 3561 +-----------------------------------------+---+---+---+---+ 3562 | Initiator/Recipient Control | | 3563 +-----------------------------------------+---+---+---+---+ 3564 | Clock synchronization ELS capable | n | n | n | n | 3565 +-----------------------------------------+---+---+---+---+ 3566 Table 9 -- FLOGI Service Parameter Settings 3568 Notes: 3570 1) "n" indicates a parameter or capability that is not 3571 supported by the iFCP protocol. 3573 2) "M" indicates an applicable parameter that MUST be 3574 supported by an iFCP gateway. 3576 8. iFCP Error Detection 3578 8.1 Overview 3580 This section specifies provisions for error detection and recovery 3581 in addition to those in [FC-FS], which continue to be available in 3582 the iFCP network environment. 3584 8.2 Stale Frame Prevention 3586 Recovery from fibre channel protocol error conditions requires that 3587 frames associated with a failed or aborted exchange drain from the 3588 fabric before exchange resources can be safely reused. 3590 Since a fibre channel fabric may not preserve frame order, there is 3591 no deterministic way to purge such frames. Instead, the fabric 3592 guarantees that frame the lifetime will not exceed a specific limit 3593 (R_A_TOV). 3595 R_A_TOV is defined in [FC-FS] as "the maximum transit time within a 3596 fabric to guarantee that a lost frame will never emerge from the 3597 fabric". For example, a value of 2 x R_A_TOV is the minimum time 3598 that the originator of an ELS request or FC-4 link service request 3599 must wait for the response to that request. The fibre channel 3600 default value for R_A_TOV is 10 seconds. 3602 An iFCP gateway SHALL actively enforce limits on R_A_TOV as 3603 described in section 8.2.1. 3605 8.2.1 Enforcing R_A_TOV Limits 3607 The R_A_TOV limit on frame lifetimes SHALL be enforced by means of 3608 the time stamp in the encapsulation header (see section 5.3.1) as 3609 described in this section. 3611 The budget for R_A_TOV SHOULD include allowances for the 3612 propagation delay through the gateway regions of the sending and 3613 receiving N_PORTs plus the propagation delay through the IP 3614 network. This latter component is referred to in this 3615 specification as IP_TOV. 3617 IP_TOV should be set well below the value of R_A_TOV specified for 3618 the iFCP fabric and should be stored in the iSNS server. IP_TOV 3619 should be set to 50 percent of R_A_TOV. 3621 The following paragraphs describe the requirements for 3622 synchronizing gateway time bases and the rules for measuring and 3623 enforcing propagation delay limits. 3625 The protocol for synchronizing a gateway time base is SNTP 3626 [RFC2030]. In order to insure that all gateways are time-aligned, a 3627 gateway SHOULD obtain the address of an SNTP-compatible time server 3628 via an iSNS query. If multiple time server addresses are returned 3629 by the query, the servers must be synchronized and the gateway may 3630 use any server in the list. Alternatively, the server may return a 3631 multicast group address in support of operation in Anycast mode. 3632 Implementation of Anycast mode is as specified in [RFC2030], 3633 including the precautions defined in that document. Multicast mode 3634 SHOULD NOT be used. 3636 An SNTP server may use any one of the time reference sources listed 3637 in [RFC2030]. The resolution of the time reference MUST be 125 3638 milliseconds or better. 3640 Stability of the SNTP server and gateway time bases should be 100 3641 ppm or better. 3643 With regard to its time base, the gateway is in either the Synchronized 3644 or Unsynchronized state. 3646 When in the synchronized state, the gateway SHALL 3648 a) Set the time stamp field for each outgoing frame in accordance 3649 with the gateway's internal time base 3651 b) Check the time stamp field of each incoming frame, following 3652 validation of the encapsulation header CRC as described in 3653 section 5.3.4. 3655 c) If the incoming frame has a time stamp of 0,0 and is not one of 3656 the session control frames that require a 0,0 time stamp (see 3657 section 6), the frame SHALL be discarded. 3659 d) If the incoming frame has a non-zero time stamp, the receiving 3660 gateway SHALL compute the absolute value of the time in flight 3661 and SHALL compare it against the value of IP_TOV specified for 3662 the IP fabric. 3664 e) If the result in step (d) exceeds IP_TOV, the encapsulated 3665 frame shall be discarded. Otherwise, the frame shall be de- 3666 encapsulated as described in section 5.3.4. 3668 A gateway SHALL enter the Synchronized state upon receiving a 3669 successful response to an SNTP query. 3671 A gateway shall enter the Unsynchronized state: 3673 a) Upon power up and before successful completion of an SNTP query 3675 b) Whenever the gateway looses contact with the SNTP server such 3676 that the gateway's time base may no longer be in alignment with 3677 that of the SNTP server. The criterion for determining loss of 3678 contact is implementation specific. 3680 Following loss of contact, it is recommended that the gateway enter 3681 the Unsynchronized state when the estimated time base drift 3682 relative to the SNTP reference is greater than ten percent of the 3683 IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and 3684 IP_TOV equals 5 seconds, the maximum allowable loss of contact 3685 duration would be about 42 minutes.) 3687 As the result of a transition from the Synchronized to the 3688 Unsynchronized state, a gateway MUST abort all iFCP sessions as 3689 described in section 5.2.3. While in the Unsynchronized state, a 3690 gateway SHALL NOT permit the creation of new iFCP sessions. 3692 9. Fabric Services Supported by an iFCP implementation 3693 An iFCP gateway implementation MUST support the following fabric 3694 services: 3696 N_PORT ID Value Description Section 3697 --------------- ----------- ------- 3698 0xFF-FF-FE F_PORT Server 9.1 3700 0xFF-FF-FD Fabric Controller 9.2 3702 0xFF-FF-FC Directory/Name Server 9.3 3704 In addition, an iFCP gateway MAY support the FC broadcast server 3705 functionality described in section 9.4. 3707 9.1 F_PORT Server 3709 The F_PORT server SHALL support the FLOGI ELS as described in 3710 section 7.4 as well as the following ELSs specified in [FC-FS]: 3712 a) Request for fabric service parameters (FDISC), 3714 b) Request for the link error status (RLS), 3716 c) Read Fabric Timeout Values (RTV). 3718 9.2 Fabric Controller 3720 The Fabric Controller SHALL support the following ELSs as specified 3721 in [FC-FS]: 3723 a) State Change Notification (SCN), 3725 b) Registered State Change Notification (RSCN), 3727 c) State Change Registration (SCR). 3729 9.3 Directory/Name Server 3731 The Directory/Name server provides a registration service allowing 3732 an N_PORT to record or query the database for information about 3733 other N_PORTs. The services are defined in [FC-GS3]. The queries 3734 are issued as FC-4 transactions using the FC-CT command transport 3735 protocol specified in [FC-GS3]. 3737 In iFCP, each name server request MUST be translated to the 3738 appropriate iSNS query defined in [ISNS]. The definitions of name 3739 server objects are specified in [FC-GS3]. 3741 The name server SHALL support record and query operations for 3742 directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) 3743 and MAY support the FC-4 specific services as defined in [FC-GS3]. 3745 9.4 Broadcast Server 3747 Fibre channel frames are broadcast throughout the fabric by 3748 addressing them to the fibre channel broadcast server at well-known 3749 fibre channel address 0xFF-FF-FF. The broadcast server then 3750 replicates and delivers the frame to each attached N_PORT in all 3751 zones to which the originating device belongs. Only class 3 3752 (datagram) service is supported. 3754 In an iFCP system, the fibre channel broadcast function is emulated 3755 by means of a two-tier architecture comprised of the following 3756 elements: 3758 a) A local broadcast server residing in each iFCP gateway. The 3759 local server distributes broadcast traffic within the gateway 3760 region and forwards outgoing broadcast traffic to a global 3761 server for distribution throughout the iFCP fabric. 3763 b) A global broadcast server which re-distributes broadcast 3764 traffic to the local server in each participating gateway. 3766 c) An iSNS discovery domain defining the scope over which 3767 broadcast traffic is propagated. The discovery domain is 3768 populated with a global broadcast server and the set of local 3769 servers it supports. 3771 The local and global broadcast servers are logical iFCP devices 3772 that communicate using the iFCP protocol. The servers have an 3773 N_PORT Network Address consisting of an iFCP portal address and an 3774 N_PORT ID set to the well-known fibre channel address of the FC 3775 broadcast server (0xFF-FF-FF). 3777 As noted above, an N_PORT originates a broadcast by directing frame 3778 traffic to the fibre channel broadcast server. The gateway-resident 3779 local server distributes a copy of the frame locally and forwards a 3780 copy to the global server for redistribution to the local servers 3781 on other gateways. The global server MUST NOT echo a broadcast 3782 frame to the originating local server. 3784 9.4.1 Establishing the Broadcast Configuration 3786 The broadcast configuration is managed using facilities provided by 3787 the iSNS server. Specifically: 3789 a) An iSNS discovery domain is created and seeded with the network 3790 address of the global broadcast server N_PORT. The global 3791 server is identified as such by setting the appropriate N_PORT 3792 entity attribute. 3794 b) Using the management interface, each broadcast server is preset 3795 with the identity of the broadcast domain. 3797 During power up, each gateway SHALL invoke the iSNS service to 3798 register its local broadcast server in the broadcast discovery 3799 domain. After registration, the local server SHALL wait for the 3800 global broadcast server to establish an iFCP session. 3802 The global server SHALL register with the iSNS server as follows: 3804 a) The server SHALL query the iSNS name server by attribute to 3805 obtain the worldwide port name of the N_PORT pre-configured to 3806 provide global broadcast services. 3808 b) If the worldwide port name obtained above does not correspond to 3809 that of the server issuing the query, the N_PORT SHALL NOT 3810 perform global broadcast functions for N_PORTs in that discovery 3811 domain. 3813 c) Otherwise, the global server N_PORT SHALL register with the 3814 discovery domain and query the iSNS server to identify all 3815 currently-registered local servers. 3817 d) The global broadcast server SHALL initiate an iFCP session with 3818 each local broadcast server in the domain. When a new local 3819 server registers, the global server SHALL receive a state change 3820 notification and respond by initiating an iFCP session with the 3821 newly added server. The gateway SHALL obtain these 3822 notifications using the iSNS provisions for lossless delivery. 3824 Upon receiving the CBIND request to initiate the iFCP session, the 3825 local server SHALL record the worldwide port name and N_PORT 3826 network address of the global server. 3828 9.4.2 Broadcast Session Management 3830 After the initial broadcast session is established, the local or 3831 global broadcast server MAY choose to manage the session in one of 3832 the following ways depending on resource requirements and the 3833 anticipated level of broadcast traffic: 3835 a) A server MAY keep the session open continuously. Since 3836 broadcast sessions are often quiescent for long periods of 3837 time, the server SHOULD monitor session connectivity as 3838 described in section 5.2.2.4. 3840 b) A server MAY open the broadcast session on demand only when 3841 broadcast traffic is to be sent. If the session is reopened by 3842 the global server, the local server SHALL replace the 3843 previously recorded network address of the global broadcast 3844 server. 3846 9.4.3 Standby Global Broadcast Server 3848 An implementation may designate a local server to assume the duties 3849 of the global broadcast server in the event of a failure. The 3850 local server may use the LTEST message to determine if the global 3851 server is functioning and may assume control if not. 3853 When assuming control, the standby server must register with the 3854 iSNS server as the global broadcast server in place of the failed 3855 server and must install itself in the broadcast discovery domain as 3856 specified in steps c) and d)of section 9.4.1. 3858 10. iFCP Security 3860 10.1 Overview 3862 iFCP relies upon the IPSec protocol suite to provide data 3863 confidentiality and authentication services, and IKE as the key 3864 management protocol. Section 10.2 describes the security 3865 requirements arising from iFCP�s operating environment while 3866 Section 10.3 describes the resulting design choices, their 3867 requirement levels, and how they apply to the iFCP protocol. 3869 Detailed considerations for use of IPsec and IKE with the iFCP 3870 protocol can be found in [SECIPS]. 3872 10.2 iFCP Security Threats and Scope 3874 10.2.1 Context 3876 iFCP is a protocol designed for use by gateway devices deployed in 3877 enterprise data centers. Such environments typically have security 3878 gateways designed to provide network security through isolation 3879 from public networks. Furthermore, iFCP data may need to traverse 3880 security gateways in order to support SAN-to-SAN connectivity 3881 across public networks. 3883 10.2.2 Security Threats 3885 Communicating iFCP gateways may be subjected to attacks, including 3886 attempts by an adversary to: 3888 a) Acquire confidential data and identities by snooping data 3889 packets. 3891 b) Modify packets containing iFCP data and control messages. 3893 c) Inject new packets into the iFCP session. 3895 d) Hijack the TCP connection carrying the iFCP session. 3897 e) Launch denial of service attacks against the iFCP gateway. 3899 f) Disrupt the security negotiation process. 3901 g) Impersonate a legitimate security gateway. 3903 h) Compromise communication with the iSNS server. 3905 It is imperative to thwart these attacks, given that an iFCP 3906 gateway is the last line of defense for a whole fibre channel 3907 island, which may include several hosts and fibre channel switches. 3908 To do so, the iFCP gateway must implement and may use 3909 confidentiality, data origin authentication, integrity, and replay 3910 protection on a per-datagram basis. The iFCP gateway must implement 3911 and may use bi-directional authentication of the communication 3912 endpoints. Finally, it must implement and may use a scalable 3913 approach to key management. 3915 10.2.3 Interoperability with Security Gateways 3917 Enterprise data center networks are considered mission-critical 3918 facilities that must be isolated and protected from all possible 3919 security threats. Such networks are usually protected by security 3920 gateways, which at a minimum provide a shield against denial of 3921 service attacks. The iFCP security architecture is capable of 3922 leveraging the protective services of the existing security 3923 infrastructure, including firewall protection, NAT and NAPT 3924 services, and IPSec VPN services available on existing security 3925 gateways. Considerations regarding intervening NAT and NAPT boxes 3926 along the iFCP-iSNS path can be found in [iSNS]. 3928 10.2.4 Authentication 3930 iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by 3931 either or both peer gateways. Consequently, bi-directional 3932 authentication of peer gateways must be provided in accordance with 3933 the requirement levels specified in section 10.3.1. 3935 N_PORT identities used in the Port Login (PLOGI) process shall be 3936 considered authenticated provided the PLOGI request is received 3937 from the remote gateway over a secure, IPSec-protected connection 3939 There is no requirement that the identities used in authentication 3940 be kept confidential. 3942 10.2.5 Confidentiality 3944 iFCP traffic may traverse insecure public networks, and therefore 3945 implementations must have per-packet encryption capabilities to 3946 provide confidentiality in accordance with the requirements 3947 specified in section 10.3.1. 3949 10.2.6 Rekeying 3950 Due to the high data transfer rates and the amount of data 3951 involved, an iFCP implementation must support the capability to 3952 rekey each phase 2 security association in the time intervals 3953 dictated by sequence number space exhaustion at a given link rate. 3954 In the rekeying scenario described in [SECIPS], for example, 3955 rekeying events happen as often as every 27.5 seconds at 10 Gbps 3956 rates. 3958 The iFCP gateway must provide the capability for forward secrecy in 3959 the rekeying process. 3961 10.2.7 Authorization 3963 Basic access control properties stem from the requirement that two 3964 communicating iFCP gateways be known to one or more iSNS servers 3965 before they can engage in iFCP exchanges. The optional use of 3966 discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and 3967 certificate-based authentication (e.g., with X509v3 certificates) 3968 enables authorization schemas of increasing complexity. The 3969 definition of such schemas (e.g., role-based access control) is 3970 outside of the scope of this specification. 3972 10.2.8 Policy control 3974 This specification allows any and all security mechanisms in an 3975 iFCP gateway to be administratively disabled. Security policies 3976 MUST have at most iFCP Portal resolution. Administrators may gain 3977 control over security policies through an adequately secured 3978 interaction with a management interface or with iSNS. 3980 10.2.9 iSNS Role 3982 iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways 3983 MUST use iSNS for discovery services, and MAY use security policies 3984 configured in the iSNS database as the basis for algorithm 3985 negotiation in IKE. The iSNS specification defines mechanisms to 3986 secure communication between an iFCP gateway and iSNS server(s). 3987 Additionally, such specification indicates how elements of security 3988 policy concerning individual iFCP sessions can be retrieved from 3989 iSNS server(s). 3991 10.3 iFCP Security Design 3993 10.3.1 Enabling Technologies 3995 Applicable technology from IPsec and IKE is defined in the 3996 following suite of specifications: 3998 [RFC2401] Security Architecture for the Internet Protocol 4000 [RFC2402] IP Authentication Header 4002 [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH 4004 [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV 4006 [RFC2406] IP Encapsulating Security Payload 4008 [RFC2407] The Internet IP Security Domain of Interpretation for 4009 ISAKMP 4011 [RFC2408] Internet Security Association and Key Management 4012 Protocol (ISAKMP) 4014 [RFC2409] The Internet Key Exchange (IKE) 4016 [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC 4018 [RFC2451] The ESP CBC-Mode Cipher Algorithms 4020 [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains 4022 The implementation of IPsec and IKE is required according the 4023 following guidelines. 4025 Support for the IP Encapsulating Security Payload (ESP) [RFC2406] 4026 is MANDATORY to implement. When ESP is utilized, per-packet data 4027 origin authentication, integrity and replay protection MUST be 4028 used. 4030 For data origin authentication and integrity with ESP, HMAC with 4031 SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption 4032 Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining 4033 SHOULD be implemented in accordance with [AESCBC]. 4035 For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be 4036 implemented, and AES counter mode encryption [AESCTR] SHOULD be 4037 implemented. NULL encryption MUST be supported as well, as defined 4038 in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its 4039 inherent weakness. Since it is known to be crackable with modest 4040 computation resources, it is inappropriate for use in any iFCP 4041 deployment scenario. 4043 A conformant iFCP protocol implementation MUST implement IPsec ESP 4044 [RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in 4045 transport mode. 4047 Regarding key management, iFCP implementations MUST support IKE 4048 [RFC2409] for bi-directional peer authentication, negotiation of 4049 security associations, and key management, using the IPsec DOI. 4050 There is no requirement that the identities used in authentication 4051 be kept confidential. Manual keying MUST NOT be used since it does 4052 not provide the necessary keying support. According to [RFC2409], 4053 pre-shared secret key authentication is MANDATORY to implement, 4054 whereas certificate-based peer authentication using digital 4055 signatures MAY be implemented (see section 10.3.3 regarding the use 4056 of certificates). [RFC2409] defines the following requirement 4057 levels for IKE Modes: 4059 Phase-1 Main Mode MUST be implemented 4061 Phase-1 Aggressive Mode SHOULD be implemented 4063 Phase-2 Quick Mode MUST be implemented 4065 Phase-2 Quick Mode with key exchange payload MUST be implemented. 4067 With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with 4068 pre-shared keys, due to Main Mode�s vulnerability to man-in-the- 4069 middle-attackers when group pre-shared keys are used. In this 4070 scenario, Aggressive Mode SHOULD be used instead. Peer 4071 authentication using the public key encryption methods outlined in 4072 [RFC2409] SHOULD NOT be used. 4074 The DOI [RFC2407] provides for several types of Identification 4075 Payloads. 4077 When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the 4078 Identification Payload fields (IDii and IDir). Conformant iFCP 4079 implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the 4080 protocol stack supports IPv6), or ID_FQDN Identification Type 4081 values. The ID_USER_FQDN, IP Subnet, IP Address Range, 4082 ID_DER_ASN1_DN, ID_DER_ASN1_GN Identification Type values SHOULD 4083 NOT be used. The ID_KEY_ID Identification Type values MUST NOT be 4084 used. As described in [RFC2407], the port and protocol fields in 4085 the Identification Payload MUST be set to zero or UDP port 500. 4087 When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the 4088 Identification Payload fields (IDci and IDcr). Conformant iFCP 4089 implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR 4090 Identification Type values (according to the version of IP 4091 supported), and a non-zero port number. Other Identification Type 4092 values MUST NOT be used. As described in section 5.2.2, the 4093 gateway creating the iFCP session must query the iSNS server to 4094 determine the appropriate port on which to initiate the associated 4095 TCP connection. Upon a successful IKE Phase 2 exchange, the IKE 4096 responder enforces the negotiated selectors on the IPsec SAs. Any 4097 subsequent iFCP session creation requires the iFCP peer to query 4098 its iSNS server for access control (in accordance with the session 4099 creation requirements specified in section 5.2.2.1). 4101 10.3.2 Use of IKE and IPsec 4102 A conformant iFCP Portal is capable of establishing one or more IKE 4103 Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase- 4104 1 SA may be established when an iFCP Portal is initialized, or may 4105 be deferred until the first TCP connection with security 4106 requirements is established. 4108 An IKE Phase-2 SA protects one or more TCP connections within the 4109 same iFCP Portal. More specifically, the successful establishment 4110 of an IKE Phase-2 SA results in the creation of two uni-directional 4111 IPsec SAs fully qualified by the tuple . 4114 These SAs protect the setup process of the underlying TCP 4115 connections and all their subsequent TCP traffic. The number of TCP 4116 connections in an IPsec SA as well as the number of SAs is 4117 practically driven by security policy considerations (i.e., 4118 security services are defined at the granularity of an IPsec SA 4119 only), QoS considerations (e.g., multiple QoS classes within the 4120 same IPsec SA increase odds of packet reordering, possibly falling 4121 outside the replay window), and failure compartmentalization 4122 considerations. Each of the TCP connections protected by an IPsec 4123 SA is either in the unbound state, or is bound to a specific iFCP 4124 session. 4126 In summary, at any point in time: 4128 -- There exist 0..M IKE Phase-1 SAs between peer iFCP portals 4130 -- Each IKE Phase-1 SA has 0..N IKE Phase-2 SAs 4132 -- Each IKE Phase-2 SA protects 0..Z TCP connections 4134 The creation of an IKE Phase-2 SA may be triggered by a policy rule 4135 supplied through a management interface or by iFCP Portal 4136 properties registered with the iSNS server. Similarly, the use of a 4137 Key Exchange payload in Quick Mode for perfect forward secrecy may 4138 be dictated through a management interface or by an iFCP Portal 4139 policy rule registered with the iSNS server. 4141 If an iFCP implementation makes use of unbound TCP connections, and 4142 such connections belong to an iFCP Portal with security 4143 requirements, then the unbound connections MUST be protected by an 4144 SA at all times just like bound connections. 4146 Upon receiving an IKE Phase-2 delete message, there is no 4147 requirement to terminate the protected TCP connections or delete 4148 the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be 4149 associated with multiple TCP connections, terminating such 4150 connections might in fact be inappropriate and untimely. 4152 To minimize the number of active Phase-2 SAs, IKE Phase-2 delete 4153 messages may be sent for Phase-2 SAs whose TCP connections have not 4154 handled data traffic for a while. To minimize the use of SA 4155 resources while the associated TCP connections are idle, creation 4156 of a new SA should be deferred until new data are to be sent over 4157 the connections. 4159 10.3.3 Signatures and Certificate-based Authentication 4161 Conformant iFCP implementations MAY support peer authentication via 4162 digital signatures and certificates. When certificate 4163 authentication is chosen within IKE, each iFCP gateway needs the 4164 certificate credentials of each peer iFCP gateway in order to 4165 establish a security association with that peer. 4167 Certificate credentials used by iFCP gateways MUST be those of the 4168 machine. Certificate credentials MAY be bound to the interface (IP 4169 Address or FQDN) of the iFCP gateway used for the iFCP session, or 4170 the fabric WWN of the iFCP gateway itself. Since the value of a 4171 machine certificate is inversely proportional to the ease with 4172 which an attacker can obtain one under false pretenses, it is 4173 advisable that the machine certificate enrollment process be 4174 strictly controlled. For example, only administrators may have the 4175 ability to enroll a machine with a machine certificate. User 4176 certificates SHOULD NOT be used by iFCP gateways for establishment 4177 of SA's protecting iFCP sessions. 4179 If the gateway does not have the peer iFCP gateway's certificate 4180 credentials, then it can obtain them by 4182 a) Using the iSNS protocol to query for the peer gateway's 4183 certificate(s) stored in a trusted iSNS server, or 4185 b) Through use of the ISAKMP Certificate Request Payload (CRP) 4186 [RFC2408] to request the certificate(s) directly from the peer 4187 iFCP gateway. 4189 When certificate chains are long enough, then IKE exchanges using 4190 UDP as the underlying transport may yield IP fragments, which are 4191 known to work poorly across some intervening routers, firewalls, 4192 and NA(P)T boxes. As a result, the endpoints may be unable to 4193 establish an IPsec security association. 4195 Due to these fragmentation shortcomings, IKE is most appropriate 4196 for intra-domain usage. Known solutions to the fragmentation 4197 problem are to send the end-entry machine certificate rather than 4198 the chain, to reduce the size of the certificate chain, to use IKE 4199 implementations over a reliable transport protocol (e.g., TCP) 4200 assisted by Path MTU discovery and code against black-holing as in 4201 [RFC2923], or to install network components that can properly 4202 handle fragments. 4204 IKE negotiators SHOULD check the pertinent Certificate Revocation 4205 List (CRL) [RFC2408] before accepting a certificate for use in 4206 IKE's authentication procedures. 4208 10.4 iSNS and iFCP Security 4210 iFCP implementations MUST use iSNS for discovery and management 4211 services. Consequently, the security of the iSNS protocol has an 4212 impact on the security of iFCP gateways. For a discussion of 4213 potential threats to iFCP gateways through use of iSNS, see [ISNS]. 4215 To provide security for iFCP gateways using the iSNS protocol for 4216 discovery and management services, the IPSec ESP protocol in tunnel 4217 mode MUST be supported for iFCP gateways. Further discussion of 4218 iSNS security implementation requirements is found in [ISNS]. Note 4219 that iSNS security requirements match those for iFCP described in 4220 section 10.3. 4222 10.5 Use of iSNS to Distribute Security Policy 4224 Once communication between iFCP gateways and the iSNS server have 4225 been secured through use of IPSec, the iFCP gateways have the 4226 capability to discover the security settings that they need to use 4227 (or not use) to protect iFCP traffic. This provides a potential 4228 scaling advantage over device-by-device configuration of individual 4229 security policies for each iFCP gateway. It also provides an 4230 efficient means for each iFCP gateway of discovering the use or 4231 non-use of specific security capabilities by peer gateways. 4233 Further discussion on use of iSNS to distribute security policies 4234 is found in [ISNS]. 4236 10.6 Minimal Security Policy for an iFCP gateway 4238 An iFCP implementation may be able to administratively disable 4239 security mechanisms for an iFCP Portal through a management 4240 interface or through security policy elements set in the iSNS 4241 server. As a consequence, IKE or IPsec security associations will 4242 not be established for any iFCP sessions that traverse the portal. 4244 For most IP networks, it is inappropriate to assume physical 4245 security, administrative security, and correct configuration of the 4246 network and all attached nodes (a physically isolated network in a 4247 test lab may be an exception). Therefore, authentication SHOULD be 4248 used in order to provide a minimal assurance that connections have 4249 initially been opened with the intended counterpart. The minimal 4250 iFCP security policy thus only states that an iFCP gateway SHOULD 4251 authenticate its iSNS server(s) as described in [ISNS]. 4253 11. Quality of Service Considerations 4255 11.1 Minimal requirements 4256 Conforming iFCP protocol implementations SHALL correctly 4257 communicate gateway-to-gateway even across one or more intervening 4258 best-effort IP regions. The timings with which such gateway-to 4259 gateway communication is performed, however, will greatly depend 4260 upon BER, packet losses, latency, and jitter experienced throughout 4261 the best-effort IP regions. The higher these parameters, the higher 4262 will be the gap measured between iFCP observed behaviors and 4263 baseline iFCP behaviors (i.e., as produced by two iFCP gateways 4264 directly connected to one another). 4266 11.2 High-assurance 4268 It is expected that many iFCP deployments will benefit from a high 4269 degree of assurance regarding the behavior of intervening IP 4270 regions, with resulting high-assurance on the overall end-to-end 4271 path, as directly experienced by fibre channel applications. Such 4272 assurance on the IP behaviors stems from the intervening IP regions 4273 supporting standard Quality-of-Service (QoS) techniques, fully 4274 complementary to iFCP, such as: 4276 a) Congestion avoidance by over-provisioning of the network, 4278 b) Integrated Services [RFC1633] QoS, 4280 c) Differentiated Services [RFC2475] QoS 4282 d) Multi-Protocol Label Switching [RFC3031]. 4284 One may load an MPLS forwarding equivalence class (FEC) with QoS 4285 class significance, in addition to other considerations such as 4286 protection and diversity for the given path. The complementarity 4287 and compatibility of MPLS with Differentiated Services is 4288 explored in [MPSLDS], wherein the PHB bits are copied to the EXP 4289 bits of the MPLS shim header. 4291 In the most general definition, two iFCP gateways are separated by 4292 one or more independently managed IP regions, some of which 4293 implement some of the QoS solutions mentioned above. A QoS-capable 4294 IP region supports the negotiation and establishment of a service 4295 contract specifying the forwarding service through the region. Such 4296 contract and its negotiation rules are outside the scope of this 4297 document. In the case of IP regions with DiffServ QoS, the reader 4298 should refer to Service Level Specifications (SLS) and Traffic 4299 Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other 4300 aspects of a service contract are expected to be non-technical and 4301 thus outside of the IETF scope. 4303 Due to the fact that fibre channel Class 2 and Class 3 do not 4304 currently support fractional bandwidth guarantees, and that iFCP is 4305 committed to supporting fibre channel semantics, it is impossible 4306 for an iFCP gateway to autonomously infer bandwidth requirements 4307 from streaming fibre channel traffic. Rather, the requirements on 4308 bandwidth or other network parameters need to be administratively 4309 set into an iFCP gateway, or into the entity that will actually 4310 negotiate the forwarding service on the gateway's behalf. Depending 4311 on the QoS techniques available, the stipulation of a forwarding 4312 service may require interaction with network ancillary functions 4313 such admission control and bandwidth brokers (via RSVP or other 4314 signaling protocols that an IP region may accept). 4316 The administrator of a iFCP gateway may negotiate a forwarding 4317 service with IP region(s) for one, several, or all of an iFCP 4318 gateway's TCP sessions used by an iFCP gateway. Alternately, this 4319 responsibility may be delegated to a node downstream. Since one TCP 4320 connection is dedicated to each iFCP session, the traffic in an 4321 individual N_PORT to N_PORT session can be singled out by iFCP- 4322 unaware network equipment as well. 4324 To render the best emulation of fibre channel possible over IP, it 4325 is anticipated that typical forwarding services will specify a 4326 fixed amount of bandwidth, null losses, and, to a lesser degree of 4327 relevance, low latency, and low jitter. For example, an IP region 4328 using DiffServ QoS may support SLSs of this nature by applying EF 4329 DSCPs to the iFCP traffic. 4331 12. IANA Considerations 4333 The IANA-assigned port for iFCP traffic is port number 3420. 4335 An iFCP Portal may initiate a connection using any TCP port number 4336 consistent with its implementation of the TCP/IP stack, provided 4337 each port number is unique. To prevent the receipt of stale data 4338 associated with a previous connection using a given port number, 4339 the provisions of [RFC1323], Appendix B SHOULD be observed. 4341 13. Author's Addresses 4342 Charles Monia Franco Travostino 4343 Rod Mullendore Director, Content 4344 Internetworking Lab, 4345 Nishan Systems Nortel Networks 4346 3850 North First Street 3 Federal Street 4347 San Jose, CA 95134 Billerica, MA 01821 4348 Phone: 408-519-3986 Phone: 978-288-7708 4349 Email: Email: 4350 cmonia@nishansystems.com 4351 travos@nortelnetworks.com 4353 Wayland Jeong Mark Edwards 4354 Troika Networks Senior Systems Architect 4355 Vice President, Hardware Eurologic Development, Ltd. 4356 Engineering 4th Floor, Howard House 4357 2829 Townsgate Road Suite Queens Ave, UK. BS8 1SD 4358 200 Phone: +44 (0)117 930 9600 4359 Westlake Village, CA 91361 Email: 4360 Phone: 805-370-2614 medwards@eurologic.com 4361 Email: 4362 wayland@troikanetworks.com 4364 14. Normative References 4366 [AESCBC] Frankel, S., Hebert, H., "The AES Cipher Algorithm and Its 4367 Use with IPsec", Internet draft (work in progress), draft- 4368 ietf-ipsec-ciph-aes-xcbc-mac-02.txt, March 2002. 4370 [AESCTR] Walker, J., Moskowitz, R., "The AES128 CTR Mode of 4371 Operation and Its Use with Ipsec", Internet draft (work in 4372 progress), draft-moskowitz-aes128-ctr-00.txt, September 4373 2001. 4375 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- 4376 GS3)", revision 7.01, NCITS Project 1356-D, November 2000 4378 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- 4379 SW2)", revision 5.2, NCITS Project 1305-D, May 2001 4381 [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service", 4382 draft-ietf-ips-08.txt, February 2002 4384 [RFC1119] Mills, D., "Network Time Protocol (Version 3) 4385 Specification, Implementation and Analyses", RFC 1305, 4386 March 1992 4388 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 4389 3", BCP 9, RFC 2026, October 1996. 4391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4392 Requirement Levels", BCP 14, RFC 2119, March 1997 4394 [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture 4395 for the Internet Protocol", November 1998 4397 [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication 4398 Header", November 1998 4400 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4401 ESP and AH", RFC 2404, November 1998 4403 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4404 ESP and AH", RFC 2404, November 1998 4406 [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security 4407 Protocol", November 1998 4409 [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of 4410 Interpretation for ISAKMP", November 1998 4412 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 4413 RFC 2408, "Internet Security Association and Key Management 4414 Protocol (ISAKMP)" November 1998 4416 [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key 4417 Exchange (IKE)", November 1998 4419 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4420 Its use with IPSEC", RFC 2410, November 1998 4422 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4423 Algorithms", RFC 2451, November 1998 4425 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 4426 1981 4428 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 4429 September, 1981 4431 [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over 4432 IP", Internet draft (work in progress), draft-ietf-ips- 4433 security-12.txt, May 2002 4435 15. Non-Normative References 4437 [AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", 4438 Draft, 2001, Available from 4439 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf 4441 [DIFTERM] Grossman, D., "New Terminology and Clarifications for 4442 Diffserv", draft-ietf-diffserv-new-terms-07.txt, December 4443 2001 4445 [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 4446 2)", revision 7.0, NCITS Project 1133D, April 1999 4448 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- 4449 FLA)", revision 2.7, NCITS Project 1235-D, August 1997 4451 [KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated 4452 Loop", Robert W. Kembel, Northwest Learning Associates, 4453 2000, ISBN 0-931836-84-0 4455 [KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", 4456 Northwest Learning Associates Inc., 2000, ISBN 0-931836-84- 4457 0 4459 [MPSLDS] F. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. 4460 Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 4461 Differentiated Services", draft-ietf-mpls-diff-ext-09.txt, 4462 April 2001. 4464 [RFC1122] Braden, S., "Requirements for Internet Hosts -- 4465 Communication Layers", RFC 1122, October 1989 4467 [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High 4468 Performance", RFC 1323, May, 1992 4470 [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated 4471 Services in the Internet Architecture: an Overview", RFC 4472 1633, June 1994 4474 [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol 4475 (SNTP)" Version 4, October 1996 4477 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 4478 2131, March 1997 4480 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4481 Algorithm With Explicit IV" RFC 2405, November 1998 4483 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4484 Algorithm With Explicit IV" RFC 2405, November 1998 4486 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4487 and W. Weiss, "An Architecture for Differentiated 4488 Services", RFC 2475, December 1998 4490 [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre 4491 Channel", June 1999 4493 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 4494 NAT Domains", RFC 2709, October 1999 4496 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 4497 2923, September 2000 4499 [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi- 4500 Protocol Label Switching Architecture", RFC 3031, January 4501 2001 4503 [RFC896] Nagle, J., "Congestion Control in IP/TCP Networks", RFC 4504 896, January 1984 4505 Appendix A 4507 A. iFCP Support for Fibre Channel Link Services 4509 For reference purposes, this appendix enumerates all the fibre 4510 channel link services and the manner in which each shall be 4511 processed by an iFCP implementation. The iFCP processing policies 4512 are defined in section 7. 4514 In the following sections, the name of a link service specific to a 4515 particular FC-4 protocol is prefaced by a mnemonic identifying the 4516 protocol. 4518 A.1 Basic Link Services 4520 The basic link services are shown in the following table. 4522 Basic Link Services 4524 Name Description iFCP Policy 4525 ---- ----------- ---------- 4527 ABTS Abort Sequence Transparent 4528 BA_ACC Basic Accept Transparent 4529 BA_RJT Basic Reject Transparent 4530 NOP No Operation Transparent 4531 PRMT Preempted Rejected 4532 (Applies to 4533 Class 1 only) 4534 RMC Remove Connection Rejected 4535 (Applies to 4536 Class 1 only) 4538 A.2 Pass-Through Link Services 4540 As specified in section 7, the link service requests of Table 10 4541 and the associated ACC response frames MUST be passed through to 4542 the receiving N_PORT without altering the payload. 4544 Name Description 4545 ---- ----------- 4547 ADVC Advise Credit 4548 CSR Clock Synchronization Request 4549 CSU Clock Synchronization Update 4550 ECHO Echo 4551 ESTC Estimate Credit 4552 ESTS Establish Streaming 4553 FACT Fabric Activate Alias_ID 4554 FAN Fabric Address Notification 4555 FCP_RJT FCP FC-4 Link Service Reject 4556 FCP SRR FCP Sequence Retransmission 4557 Request 4558 FDACT Fabric Deactivate Alias_ID 4559 FDISC Discover F_Port Service 4560 Parameters 4561 FLOGI F_Port Login 4562 GAID Get Alias_ID 4563 LCLM Login Control List Management 4564 LINIT Loop Initialize 4565 LIRR Link Incident Record 4566 Registration 4567 LPC Loop Port Control 4568 LS_RJT Link Service Reject 4569 LSTS Loop Status 4570 NACT N_Port Activate Alias_ID 4571 NDACT N_Port Deactivate Alias_ID 4572 PDISC Discover N_Port Service 4573 Parameters 4574 PRLI Process Login 4575 PRLO Process Logout 4576 QoSR Quality of Service Request 4577 RCS Read Connection Status 4578 RLIR Registered Link Incident 4579 Report 4580 RNC Report Node Capability 4581 RNFT Report Node FC-4 Types 4582 RNID Request Node Identification 4583 Data 4584 RPL Read Port List 4585 RPS Read Port Status Block 4586 RPSC Report Port Speed 4587 Capabilities 4588 RSCN Registered State Change 4589 Notification 4590 RTV Read Timeout Value 4591 RVCS Read Virtual Circuit Status 4592 SBRP Set Bit-error Reporting 4593 Parameters 4594 SCN State Change Notification 4595 SCR State Change Registration 4596 TEST Test 4597 TPLS Test Process Login State 4598 Table 10 -- Pass-Through link Services 4600 A.3 Special Link Services 4602 The extended and FC-4 link services of Table 11 are processed by an 4603 iFCP implementation as described in the sections referenced in the 4604 table. 4606 Name Description Section 4607 ---- ----------- ------- 4609 ABTX Abort Exchange 7.3.1.1 4610 ADISC Discover Address 7.3.1.2 4611 ADISC Discover Address Accept 7.3.1.3 4612 ACC 4613 FARP- Fibre Channel Address 7.3.1.4 4614 REPLY Resolution Protocol 4615 Reply 4616 FARP- Fibre Channel Address 7.3.1.5 4617 REQ Resolution Protocol 4618 Request 4619 LOGO N_PORT Logout 7.3.1.6 4620 PLOGI Port Login 7.3.1.7 4621 FCP REC FCP Read Exchange 7.3.2.1.1 4622 Concise 4623 FCP REC FCP Read Exchange 7.3.2.1.2 4624 ACC Concise Accept 4625 RES Read Exchange Status 7.3.1.8 4626 Block 4627 RES ACC Read Exchange Status 7.3.1.9 4628 Block Accept 4629 RLS Read Link Error Status 7.3.1.10 4630 Block 4631 RRQ Reinstate Recovery 7.3.1.12 4632 Qualifier 4633 RSI Request Sequence 7.3.1.13 4634 Initiative 4635 RSS Read Sequence Status 7.3.1.11 4636 Block 4637 SRL Scan Remote Loop 7.3.1.14 4638 TPRLO Third Party Process 7.3.1.15 4639 Logout 4640 TPRLO Third Party Process 7.3.1.16 4641 ACC Logout Accept 4642 Table 11 -- Special Link Services 4643 Appendix B 4645 B. Supporting the Fibre Channel Loop Topology 4647 A loop topology may be optionally supported by a gateway 4648 implementation in one of the following ways: 4650 a) By implementing the FL_PORT public loop interface specified in 4651 [FC-FLA], 4653 b) By emulating the private loop environment specified in [FC- 4654 AL2]. 4656 Private loop emulation allows the attachment of fibre channel 4657 devices that do not support fabrics or public loops. The gateway 4658 presents such devices to the fabric as though they were fabric- 4659 attached. Conversely, the gateway presents devices on the fabric, 4660 whether locally or remotely attached, as though they were connected 4661 to the private loop. 4663 Private loop support requires gateway emulation of the loop 4664 primitives and control frames specified in [FC-AL2]. These frames 4665 and primitives MUST be locally emulated by the gateway. Loop 4666 control frames MUST NOT be sent over an iFCP session. 4668 B.1 Remote Control of a Public Loop 4670 A gateway MAY disclose that a remotely-attached device is connected 4671 to a public loop. If so, it MUST also provide aliases representing 4672 the corresponding Loop Fabric Address (LFA), DOMAIN_ID and FL_PORT 4673 Address Identifier through which the public loop may be remotely 4674 controlled. 4676 The LFA and FL_PORT address identifier both represent an N_PORT 4677 that services remote loop management requests contained in the 4678 LINIT and SRL extended link service messages. To support these 4679 messages, the gateway MUST allocate an NL_PORT alias such that the 4680 corresponding alias for the LFA or FL_PORT address identifier can 4681 be derived by setting the Port ID component of the NL_PORT alias to 4682 zero. 4684 Full Copyright Statement 4686 "Copyright (C) The Internet Society, June 2002. All Rights 4687 Reserved. This document and translations of it may be copied and 4688 furnished to others, and derivative works that comment on or 4689 otherwise explain it or assist in its implementation may be 4690 prepared, copied, published and distributed, in whole or in part, 4691 without restriction of any kind, provided that the above copyright 4692 notice and this paragraph are included on all such copies and 4693 derivative works. However, this document itself may not be modified 4694 in any way, such as by removing the copyright notice or references 4695 to the Internet Society or other Internet organizations, except as 4696 needed for the purpose of developing Internet standards in which 4697 case the procedures for copyrights defined in the Internet 4698 Standards process must be followed, or as required to translate it 4699 into languages other than English. 4701 The limited permissions granted above are perpetual and will not be 4702 revoked by the Internet Society or its successors or assigns. 4704 This document and the information contained herein is provided on 4705 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4706 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4707 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4708 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4711 Notice of Intellectual Property Rights 4713 The IETF has been notified of intellectual property rights claimed 4714 in regard to some or all of the specification contained in this 4715 document. For more information consult the online list of claimed 4716 rights.