idnits 2.17.1 draft-ietf-ips-ifcp-13.txt: -(772): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2679): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4258): 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 1284 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 1375 has weird spacing: '...sulates and d...' == Line 1810 has weird spacing: '... of the event...' == Line 2172 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 (February 2003) is 7739 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 3896, but not defined == Missing Reference: 'FCP-2' is mentioned on line 291, but not defined == Missing Reference: 'ENCAP' is mentioned on line 2084, but not defined == Missing Reference: '0x0' is mentioned on line 2205, but not defined == Missing Reference: '0x1' is mentioned on line 2207, but not defined -- Looks like a reference, but probably isn't: '0' on line 2207 == Missing Reference: '0x00' is mentioned on line 2209, but not defined == Missing Reference: '0x0000' is mentioned on line 2212, but not defined == Missing Reference: '0x01' is mentioned on line 2615, but not defined == Missing Reference: 'FC-VI' is mentioned on line 2999, but not defined == Missing Reference: 'FCS' is mentioned on line 3229, but not defined == Unused Reference: 'RFC1119' is defined on line 4587, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 4631, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 4686, 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 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-ciph-aes-ctr-00 -- 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 -- 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 (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 iFCP - A Protocol for Internet Fibre Channel Networking August 2002 3 IP Storage Working Group Charles Monia 4 INTERNET DRAFT Rod Mullendore 5 Expires February 2003 6 Document: draft-ietf-ips-ifcp-13.txt Nishan Systems 7 Category: Standards Track 8 Franco Travostino 9 Nortel Networks 11 Wayland Jeong 12 Troika Networks 14 Mark Edwards 15 Eurologic 17 August 2002 19 iFCP - A Protocol for Internet Fibre Channel Storage Networking 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC 2026 [RFC2026]. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. Internet-Drafts are draft documents valid for a maximum of 30 six months and may be updated, replaced, or made obsolete by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Comments 43 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 44 or to the author(s). 46 iFCP Revision 13 August 2002 48 Status of this Memo...................................................1 49 Comments..............................................................1 50 Abstract..............................................................5 51 Acknowledgements......................................................5 52 1. About This Document..........................................6 53 1.1 Conventions used in this document............................6 54 1.1.1 Data Structures Internal to an Implementation................6 55 1.2 Purpose of this document.....................................6 56 2. iFCP Introduction............................................6 57 2.1 Definitions..................................................7 58 3. Fibre Channel Communication Concepts.........................9 59 3.1 The Fibre Channel Network...................................10 60 3.2 Fibre Channel Network Topologies............................11 61 3.2.1 Switched Fibre Channel Fabrics..............................11 62 3.2.2 Mixed Fibre Channel Fabric..................................12 63 3.3 Fibre Channel Layers and Link Services......................13 64 3.3.1 Fabric-Supplied Link Services...............................14 65 3.4 Fibre Channel Nodes.........................................14 66 3.5 Fibre Channel Device Discovery..............................15 67 3.6 Fibre Channel Information Elements..........................15 68 3.7 Fibre Channel Frame Format..................................16 69 3.7.1 N_PORT Address Model........................................16 70 3.8 Fibre Channel Transport Services............................17 71 3.9 Login Processes.............................................18 72 4. The iFCP Network Model......................................18 73 4.1 iFCP Transport Services.....................................21 74 4.1.1 Fibre Channel Transport Services Supported by iFCP..........21 75 4.2 iFCP Device Discovery and Configuration Management..........21 76 4.3 iFCP Fabric Properties......................................21 77 4.3.1 Address Transparency........................................22 78 4.3.2 Configuration Scalability...................................22 79 4.3.3 Fault Tolerance.............................................23 80 4.4 The iFCP N_PORT Address Model...............................23 81 4.5 Operation in Address Transparent Mode.......................25 82 4.5.1 Transparent Mode Domain ID Management.......................25 83 4.5.2 Incompatibility with Address Translation Mode...............26 84 4.6 Operation in Address Translation Mode.......................26 85 4.6.1 Inbound Frame Address Translation...........................27 86 4.6.2 Incompatibility with Address Transparent Mode...............28 87 5. iFCP Protocol...............................................28 88 5.1 Overview....................................................28 89 5.1.1 iFCP Transport Services.....................................28 90 5.1.2 iFCP Support for Link Services..............................29 91 5.2 TCP Stream Transport of iFCP Frames.........................30 92 5.2.1 iFCP Session Model..........................................30 93 5.2.2 iFCP Session Management.....................................30 94 5.2.3 Terminating iFCP Sessions...................................37 95 5.3 Fibre Channel Frame Encapsulation...........................39 96 5.3.1 Encapsulation Header Format.................................39 97 5.3.2 SOF and EOF Delimiter Fields................................43 98 5.3.3 Frame Encapsulation.........................................44 99 5.3.4 Frame De-encapsulation......................................44 100 iFCP Revision 13 August 2002 102 6. TCP Session Control Messages................................45 103 6.1 Connection Bind (CBIND).....................................47 104 6.2 Unbind Connection (UNBIND)..................................50 105 6.3 LTEST -- Test Connection Liveness...........................52 106 7. Fibre Channel Link Services.................................53 107 7.1 Special Link Service Messages...............................54 108 7.2 Link Services Requiring Payload Address Translation.........56 109 7.3 Fibre Channel Link Services Processed by iFCP...............58 110 7.3.1 Special Extended Link Services..............................60 111 7.3.2 Special FC-4 Link Services..................................75 112 7.4 FLOGI Service Parameters Supported by an iFCP Gateway.......77 113 8. iFCP Error Detection........................................79 114 8.1 Overview....................................................79 115 8.2 Stale Frame Prevention......................................79 116 8.2.1 Enforcing R_A_TOV Limits....................................80 117 9. Fabric Services Supported by an iFCP implementation.........81 118 9.1 F_PORT Server...............................................82 119 9.2 Fabric Controller...........................................82 120 9.3 Directory/Name Server.......................................82 121 9.4 Broadcast Server............................................83 122 9.4.1 Establishing the Broadcast Configuration....................83 123 9.4.2 Broadcast Session Management................................84 124 9.4.3 Standby Global Broadcast Server.............................85 125 10. iFCP Security...............................................85 126 10.1 Overview....................................................85 127 10.2 iFCP Security Threats and Scope.............................85 128 10.2.1 Context.....................................................85 129 10.2.2 Security Threats............................................85 130 10.2.3 Interoperability with Security Gateways.....................86 131 10.2.4 Authentication..............................................86 132 10.2.5 Confidentiality.............................................86 133 10.2.6 Rekeying....................................................86 134 10.2.7 Authorization...............................................87 135 10.2.8 Policy control..............................................87 136 10.2.9 iSNS Role...................................................87 137 10.3 iFCP Security Design........................................87 138 10.3.1 Enabling Technologies.......................................87 139 10.3.2 Use of IKE and IPsec........................................89 140 10.3.3 Signatures and Certificate-based Authentication.............91 141 10.4 iSNS and iFCP Security......................................92 142 10.5 Use of iSNS to Distribute Security Policy...................92 143 10.6 Minimal Security Policy for an iFCP gateway.................92 144 11. Quality of Service Considerations...........................92 145 11.1 Minimal requirements........................................92 146 11.2 High-assurance..............................................93 147 12. IANA Considerations.........................................94 148 13. Author's Addresses..........................................94 149 14. Normative References........................................95 150 15. Non-Normative References....................................96 151 A. iFCP Support for Fibre Channel Link Services................99 152 A.1 Basic Link Services.........................................99 153 A.2 Pass-Through Link Services..................................99 154 iFCP Revision 13 August 2002 156 A.3 Special Link Services......................................100 157 B. Supporting the Fibre Channel Loop Topology.................102 158 B.1 Remote Control of a Public Loop............................102 159 Full Copyright Statement............................................103 160 Notice of Intellectual Property Rights..............................103 161 iFCP Revision 13 August 2002 163 Abstract 165 This document specifies an architecture and gateway-to-gateway 166 protocol for the implementation of fibre channel fabric 167 functionality over an IP network. This functionality is provided 168 through TCP protocols for fibre channel frame transport and the 169 distributed fabric services specified by the fibre channel 170 standards. The architecture enables internetworking of fibre 171 channel devices through gateway-accessed regions having the fault 172 isolation properties of autonomous systems and the scalability of 173 the IP network. 175 Acknowledgements 177 The authors are indebted to those who contributed material or who 178 took the time to carefully review and critique this specification 179 including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu 180 (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth 181 Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members 182 of the IPS working group. For review of the iFCP security policy, 183 the authors are further indebted to the authors of the IPS security 184 draft [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran 185 (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan 186 (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), 187 and Jesse Walker (Intel). 189 iFCP Revision 13 August 2002 191 1. About This Document 193 1.1 Conventions used in this document 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 197 this document are to be interpreted as described in RFC-2119 198 [RFC2119]. 200 Unless specified otherwise, numeric quantities are given as decimal 201 values. 203 All diagrams that portray bit and byte ordering, including the 204 depiction of structures defined by fibre channel standards, adhere 205 to the IETF conventions where bit 0 is the most significant bit and 206 the first addressable byte is in the upper left hand corner. This 207 IETF convention differs from that used for INCITS T11 fibre channel 208 standards, in which bit 0 is the least significant bit. 210 1.1.1 Data Structures Internal to an Implementation 212 To facilitate the specification of required behavior, this document 213 may define and refer to internal data structures within an iFCP 214 implementation. Such structures are intended for explanatory 215 purposes only and need not be instantiated within an implementation 216 as described in this specification. 218 1.2 Purpose of this document 220 This is a standards-track document, which specifies a protocol for 221 the implementation of fibre channel transport services on a TCP/IP 222 network. Some portions of this document contain material from 223 standards controlled by INCITS T10 and T11. This material is 224 included here for informational purposes only. The authoritative 225 information is given in the appropriate NCITS standards document. 227 The authoritative portions of this document specify the mapping of 228 standards-compliant fibre channel protocol implementations to 229 TCP/IP. This mapping includes sections of this document which 230 describe the "iFCP Protocol" (see section 5). 232 2. iFCP Introduction 234 iFCP is a gateway-to-gateway protocol, which provides fibre channel 235 fabric services to fibre channel devices over a TCP/IP network. 236 iFCP uses TCP to provide congestion control, error detection and 237 recovery. iFCP's primary objective is to allow interconnection and 238 networking of existing fibre channel devices at wire speeds over an 239 IP network. 241 iFCP Revision 13 August 2002 243 The protocol and method of frame address translation described in 244 this document permit the attachment of fibre channel storage 245 devices to an IP-based fabric by means of transparent gateways. 247 The protocol achieves this transparency by allowing normal fibre 248 channel frame traffic to pass through the gateway directly, with 249 provisions, where necessary, for intercepting and emulating the 250 fabric services required by a fibre channel device. 252 2.1 Definitions 254 Terms needed to describe the concepts presented in this document 255 are presented here. 257 Address-translation mode -- A mode of gateway operation in which 258 the scope of N_PORT fabric addresses for locally attached 259 devices are local to the iFCP gateway region in which the 260 devices reside. 262 Address-transparent mode -- A mode of gateway operation in which 263 the scope of N_PORT fabric addresses for all fibre channel 264 devices are unique to the bounded iFCP fabric to which the 265 gateway belongs. 267 Bounded iFCP Fabric -- The union of two or more gateway regions 268 configured to interoperate together in address-transparent 269 mode. 271 DOMAIN_ID -- The value contained in the high-order byte of a 24-bit 272 N_PORT fibre channel address. 274 F_PORT -- The interface used by an N_PORT to access fibre channel 275 switched fabric functionality. 277 Fabric -- From [FC-FS]: "The entity which interconnects N_PORTs 278 attached to it and is capable of routing frames by using 279 only the address information in the fibre channel frame." 281 Fabric Port -- The interface through which an N_PORT accesses a 282 fibre channel fabric. The type of fabric port depends on 283 the fibre channel fabric topology. In this specification, 284 all fabric port interfaces are considered to be 285 functionally equivalent. 287 FC-2 -- The fibre channel transport services layer described in 288 [FC-FS]. 290 FC-4 -- The fibre channel mapping of an upper layer protocol, such 291 as [FCP-2], the fibre channel to SCSI mapping. 293 Fibre Channel Device -- An entity implementing the functionality 295 iFCP Revision 13 August 2002 297 accessed through an FC-4 application protocol. 299 Fibre Channel Network -- A native fibre channel fabric and all 300 attached fibre channel nodes. 302 Fibre Channel Node -- A collection of one or more N_PORTs 303 controlled by a level above the FC-2 layer. A node is 304 attached to a fibre channel fabric by means of the N_PORT 305 interface described in [FC-FS]. 307 Gateway Region -- The portion of an iFCP fabric accessed through an 308 iFCP gateway by a remotely attached N_PORT. Fibre channel 309 devices in the region consist of all those locally attached 310 to the gateway. 312 iFCP -- The protocol discussed in this document. 314 iFCP Frame -- A fibre channel frame encapsulated in accordance with 315 the FC Frame Encapsulation Specification [ENCAP] and this 316 specification. 318 iFCP Portal -- An entity representing the point at which a logical 319 or physical iFCP device is attached to the IP network. The 320 network address of the iFCP portal consists of the IP 321 address and TCP port number to which a request is sent when 322 creating the TCP connection for an iFCP session (see 323 section 5.2.1). 325 iFCP Session -- An association comprised of a pair of N_PORTs and a 326 TCP connection that carries traffic between them. An iFCP 327 session may be created as the result of a PLOGI fibre 328 channel login operation. 330 iSNS -- The server functionality and IP protocol that provide 331 storage name services in an iFCP network. Fibre channel 332 name services are implemented by an iSNS name server as 333 described in [ISNS]. 335 Locally Attached Device -- With respect to a gateway, a fibre 336 channel device accessed through the fibre channel fabric to 337 which the gateway is attached. 339 Logical iFCP Device -- The abstraction representing a single fibre 340 channel device as it appears on an iFCP network. 342 N_PORT -- An iFCP or fibre channel entity representing the 343 interface to fibre channel device functionality. This 344 interface implements the fibre channel N_PORT semantics 345 specified in [FC-FS]. Fibre channel defines several 346 variants of this interface that depend on the fibre channel 347 fabric topology. As used in this document, the term 349 iFCP Revision 13 August 2002 351 applies equally to all variants. 353 N_PORT Alias -- The N_PORT address assigned by a gateway to 354 represent a remote N_PORT accessed via the iFCP protocol. 356 N_PORT fabric address -- The address of an N_PORT within the fibre 357 channel fabric. 359 N_PORT ID -- The address of a locally attached N_PORT within a 360 gateway region. N_PORT IDs are assigned in accordance with 361 the fibre channel rules for address assignment specified in 362 [FC-FS]. 364 N_PORT Network Address -- The address of an N_PORT in the iFCP 365 fabric. This address consists of the IP address and TCP 366 port number of the iFCP Portal and the N_PORT ID of the 367 locally attached fibre channel device. 369 Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS) 370 that establishes an iFCP session through the exchange of 371 identification and operation parameters between an 372 originating N_PORT and a responding N_PORT. 374 Remotely Attached Device -- With respect to a gateway, a fibre 375 channel device accessed from the gateway by means of the 376 iFCP protocol. 378 Unbounded iFCP Fabric -- The union of two or more gateway regions 379 configured to interoperate together in address-translation 380 mode. 382 3. Fibre Channel Communication Concepts 384 Fibre channel is a frame-based, serial technology designed for 385 peer-to-peer communication between devices at gigabit speeds and 386 with low overhead and latency. 388 This section contains a discussion of the fibre channel concepts 389 that form the basis for the iFCP network architecture and protocol 390 described in this document. Readers familiar with this material may 391 skip to section 4. 393 Material presented in this section is drawn from the following T11 394 specifications: 396 -- The Fibre Channel Framing and Signaling Interface, [FC-FS] 398 -- Fibre Channel Switch Fabric -2, [FC-SW2] 400 -- Fibre Channel Generic Services, [FC-GS3] 402 iFCP Revision 13 August 2002 404 -- Fibre Channel Fabric Loop Attachment, [FC-FLA] 406 The reader will find an in-depth treatment of the technology in 407 [KEMCMP] and [KEMALP]. 409 3.1 The Fibre Channel Network 411 The fundamental entity in fibre channel is the fibre channel 412 network. Unlike a layered network architecture, a fibre channel 413 network is largely specified by functional elements and the 414 interfaces between them. As shown in Figure 1, these consist, in 415 part, of the following: 417 a) N_PORTs -- The end points for fibre channel traffic. In the FC 418 standards, N_PORT interfaces have several variants, depending on 419 the topology of the fabric to which they are attached. As used 420 in this specification, the term applies to any one of the 421 variants. 423 b) FC Devices -- The fibre channel devices to which the N_PORTs 424 provide access. 426 c) Fabric Ports -- The interfaces within a fibre channel network 427 that provide attachment for an N_PORT. The types of fabric port 428 depend on the fabric topology and are discussed in section 3.2. 430 d) The network infrastructure for carrying frame traffic between 431 N_PORTs. 433 e) Within a switched or mixed fabric (see section 3.2), a set of 434 auxiliary servers, including a name server for device discovery 435 and network address resolution. The types of service depend on 436 the network topology. 438 +--------+ +--------+ +--------+ +--------+ 439 | FC | | FC | | FC | | FC | 440 | Device | | Device |<-------->| Device | | Device | 441 |........| |........| |........| |........| 442 | N_PORT | | N_PORT | | N_PORT | | N_PORT | 443 +---+----+ +----+---+ +----+---+ +----+---+ 444 | | | | 445 +---+----+ +----+---+ +----+---+ +----+---+ 446 | Fabric | | Fabric | | Fabric | | Fabric | 447 | Port | | Port | | Port | | Port | 448 +========+===+========+==========+========+==+========+ 449 | Fabric | 450 | & | 451 | Fabric Services | 452 +-----------------------------------------------------+ 453 Figure 1 -- A Fibre Channel Network 455 iFCP Revision 13 August 2002 457 The following sections describe fibre channel network topologies 458 and give an overview of the fibre channel communications model. 460 3.2 Fibre Channel Network Topologies 462 The principal fibre channel network topologies consist of the 463 following: 465 a) Arbitrated Loop -- A series of N_PORTs connected together in 466 daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are 467 referred to as NL_PORTs. Data transmission between NL_PORTs 468 requires arbitration for control of the loop in a manner 469 similar to a token ring network. 471 b) Switched Fabric -- A network consisting of switching elements, 472 as described in section 3.2.1. 474 c) Mixed Fabric -- A network consisting of switches and "fabric- 475 attached" loops. A description can be found in [FC-FLA]. A 476 loop-attached N_PORT (NL_PORT), is connected to the loop 477 through an L_PORT and accesses the fabric by way of an FL_PORT. 479 Depending on the topology, the N_PORT and its means of network 480 attachment may be one of the following: 482 FC Network Network Interface N_PORT Variant 483 Topology ----------------- -------------- 484 --------------- 485 Loop L_PORT NL_PORT 487 Switched F_PORT N_PORT 489 Mixed FL_PORT via L_PORT NL_PORT 491 F_PORT N_PORT 493 The differences in each N_PORT variant and its corresponding fabric 494 port are confined to the interactions between them. To an external 495 N_PORT, all fabric ports are transparent and all remote N_PORTs are 496 functionally identical. 498 3.2.1 Switched Fibre Channel Fabrics 500 An example of a multi-switch fibre channel fabric is shown in 501 Figure 2. 503 iFCP Revision 13 August 2002 505 +----------+ +----------+ 506 | FC | | FC | 507 | Device | | Device | 508 |..........| |..........| 509 | N_PORT |<........>| N_PORT | 510 +----+-----+ +-----+----+ 511 | | 512 +----+-----+ +-----+----+ 513 | F_PORT | | F_PORT | 514 ==========+==========+==========+==========+============== 515 | FC | | FC | 516 | Switch | | Switch | 517 +----------+ +----------+ Fibre Channel 518 |Inter- | |Inter- | Fabric 519 |Switch | |Switch | 520 |Interface | |Interface | 521 +-----+----+ +-----+----+ 522 | | 523 | | 524 +-----+----+----------+-----+----+ 525 |Inter- | |Inter- | 526 |Switch | |Switch | 527 |Interface | |Interface | 528 +----------+ +----------+ 529 | FC Switch | 530 | | 531 +--------------------------------+ 532 Figure 2 -- Multi-Switch Fibre Channel Fabric 534 The interface between switch elements is either proprietary or the 535 standards-compliant E_PORT interface described by the FC-SW2 536 specification, [FC-SW2]. 538 3.2.2 Mixed Fibre Channel Fabric 540 A mixed fabric contains one or more arbitrated loops connected to a 541 switched fabric as shown in Figure 3. 543 iFCP Revision 13 August 2002 545 +----------+ +----------+ +---------+ 546 | FC | | FC | | FC | 547 | Device | | Device | | Device | 548 |..........| FC |..........| |.........| 549 | N_PORT |<........>| NL_PORT +---+ NL_PORT | 550 +----+-----+ Traffic +-----+----+ +----+----+ 551 | | FC Loop | 552 +----+-----+ +-----+----+ | 553 | F_PORT | | FL_PORT +--------+ 554 | | | | 555 ==========+==========+==========+==========+============== 556 | FC | | FC | 557 | Switch | | Switch | 558 +----------+ +----------+ 559 |Inter- | |Inter- | 560 |Switch | |Switch | 561 |Interface | |Interface | 562 +-----+----+ +-----+----+ 563 | | 564 | | 565 +-----+----+----------+-----+----+ 566 |Inter- | |Inter- | 567 |Switch | |Switch | 568 |Interface | |Interface | 569 +----------+ +----------+ 570 | FC Switch | 571 | | 572 +--------------------------------+ 573 Figure 3 -- Mixed Fibre Channel Fabric 575 As noted previously, the protocol for communications between peer 576 N_PORTs is independent of the fabric topology, N_PORT variant and 577 type of fabric port to which an N_PORT is attached. 579 3.3 Fibre Channel Layers and Link Services 581 Fibre channel consists of the following layers: 583 FC-0 -- The interface to the physical media, 585 FC-1 -- The encoding and decoding of data and out-of-band physical 586 link control information for transmission over the physical media, 588 FC-2 -- The transfer of frames, sequences and Exchanges comprising 589 protocol information units. 591 FC-3 -- Common Services, 593 FC-4 -- Application protocols such as the fibre channel protocol 594 for SCSI (FCP). 596 iFCP Revision 13 August 2002 598 In addition to the layers defined above, fibre channel defines a 599 set of auxiliary operations, some of which are implemented within 600 the transport layer fabric, called link services. These are 601 required to manage the fibre channel environment, establish 602 communications with other devices, retrieve error information, 603 perform error recovery and other similar services. Some link 604 services are executed by the N_PORT. Others are implemented 605 internally within the fabric. These internal services are 606 described in the next section. 608 3.3.1 Fabric-Supplied Link Services 610 Servers internal to a switched fabric handle certain classes of 611 Link Service requests and service-specific commands. The servers 612 appear as N_PORTs located at the 'well-known' N_PORT fabric 613 addresses specified in [FC-FS]. Service requests use the standard 614 fibre channel mechanisms for N_PORT-to-N_PORT communications. 616 All switched fabrics must provide the following services: 618 Fabric F_PORT server -- Services N_PORT requests to access the 619 fabric for communications. 621 Fabric Controller -- Provides state change information to inform 622 other FC devices when an N_PORT exits or enters the fabric (see 623 section 3.5). 625 Directory/Name Server - Allows N_PORTs to register information 626 in a database, retrieve information about other N_PORTs and 627 discover other devices as described in section 3.5. 629 A switched fabric may also implement the following optional 630 services: 632 Broadcast Address/Server -- Transmits single-frame, class 3 633 sequences to all N_PORTs. 635 Time Server -- Intended for the management of fabric-wide 636 expiration timers or elapsed time values and not intended for 637 precise time synchronization. 639 Management Server - Collects and reports management information, 640 such as link usage, error statistics, link quality and similar 641 items. 643 Quality of Service Facilitator - Performs fabric-wide bandwidth 644 and latency management. 646 3.4 Fibre Channel Nodes 648 A fibre channel node has one or more fabric-attached N_PORTs. The 649 node and its N_PORTs have the following associated identifiers: 651 iFCP Revision 13 August 2002 653 a) A worldwide unique identifier for the node, 655 b) A worldwide unique identifier for each N_PORT associated with the 656 node, 658 c) For each N_PORT attached to a fabric, a 24-bit fabric-unique 659 address having the properties defined in section 3.7.1. The 660 fabric address is the address to which frames are sent. 662 Each worldwide unique identifier is a 64-bit binary quantity having 663 the format defined in [FC-FS]. 665 3.5 Fibre Channel Device Discovery 667 In a switched or mixed fabric, fibre channel devices and changes in 668 the device configuration may be discovered by means of services 669 provided by the fibre channel Name Server and Fabric Controller. 671 The Name Server provides registration and query services that allow 672 a fibre channel device to register its presence on the fabric and 673 discover the existence of other devices. For example, one type of 674 query obtains the fabric address of an N_PORT from its 64-bit 675 worldwide unique name. The full set of supported fibre channel name 676 server queries is specified in [FC-GS3]. 678 The Fabric Controller complements the static discovery capabilities 679 provided by the Name Server through a service that dynamically 680 alerts a fibre channel device whenever an N_PORT is added or 681 removed from the configuration. A fibre channel device receives 682 these notifications by subscribing to the service as specified in 683 [FC-FS]. 685 3.6 Fibre Channel Information Elements 687 The fundamental element of information in fibre channel is the 688 frame. A frame consists of a fixed header and up to 2112 bytes of 689 payload having the structure described in section 3.7. The maximum 690 frame size that may be transmitted between a pair of fibre channel 691 devices is negotiable up to the payload limit, based on the size of 692 the frame buffers in each fibre channel device and the path maximum 693 transmission unit (MTU) supported by the fabric. 695 Operations involving the transfer of information between N_PORT 696 pairs are performed through 'Exchanges'. In an Exchange, 697 information is transferred in one or more ordered series of frames 698 referred to as Sequences. 700 Within this framework, an upper layer protocol is defined in terms 701 of transactions carried by Exchanges. Each transaction, in turn, 702 consists of protocol information units, each of which is carried by 703 an individual Sequence within an Exchange. 705 iFCP Revision 13 August 2002 707 3.7 Fibre Channel Frame Format 709 A fibre channel frame consists of a header, payload and 32-bit CRC 710 bracketed by SOF and EOF delimiters. The header contains the 711 control information necessary to route frames between N_PORTs and 712 manage Exchanges and Sequences. The following diagram gives a 713 schematic view of the frame. 715 Bit 0 31 716 +-----------------------------+ 717 Word 0 | Start-of-frame Delimiter | 718 +-----+-----------------------+<----+ 719 | | Destination N_PORT | | 720 1 | | Fabric Address (D_ID) | | 721 | | (24 bits) | | 722 +-----+-----------------------+ 24-byte 723 | | Source N_PORT | Frame 724 2 | | Fabric Address (S_ID) | Header 725 | | (24 bits) | | 726 +-----+-----------------------+ | 727 3 | Control information for | | 728 . | frame type, Exchange | | 729 . | management, IU | | 730 . | segmentation and | | 731 6 | re-assembly | | 732 +-----------------------------+<----+ 733 7 | | 734 . | Frame payload | 735 . | (0 - 2112 bytes) | 736 . | | 737 . | | 738 . | | 739 +-----------------------------+ 740 . | CRC | 741 +-----------------------------+ 742 n | End-of-Frame Delimiter | 743 +-----------------------------+ 744 Figure 4 -- Fibre Channel Frame Format 746 The source and destination N_PORT fabric addresses embedded in the 747 S_ID and D_ID fields represent the physical addresses of 748 originating and receiving N_PORTs respectively. 750 3.7.1 N_PORT Address Model 752 N_PORT fabric addresses are 24-bit values having the following 753 format defined by the fibre channel specification [FC-FS]: 755 iFCP Revision 13 August 2002 757 Bit 0 7 8 15 16 23 758 +-----------+------------+----------+ 759 | Domain ID | Area ID | Port ID | 760 +-----------+------------+----------+ 761 Figure 5 -- Fibre Channel Address Format 763 A fibre channel device acquires an address when it logs into the 764 fabric. Such addresses are volatile and subject to change based on 765 modifications in the fabric configuration. 767 In a fibre channel fabric, each switch element has a unique Domain 768 ID assigned by the principal switch. The value of the Domain ID 769 ranges from 1 to 239 (0xEF). Each switch element, in turn, 770 administers a block of addresses divided into area and port IDs. An 771 N_PORT connected to a F_PORT receives a unique fabric address 772 consisting of the switch�s Domain ID concatenated with switch- 773 assigned area and port IDs. 775 A loop-attached NL_PORT (see Figure 3) obtains the Port ID 776 component of its address during the loop initialization process 777 described in [FC-AL2]. The area and domain IDs are supplied by the 778 fabric when the fabric login (FLOGI) is executed. 780 3.8 Fibre Channel Transport Services 782 N_PORTs communicate by means of the following classes of service 783 specified in the fibre channel standard ([FC-FS]): 785 Class 1 - A dedicated physical circuit connecting two N_PORTs. 787 Class 2 - A frame-multiplexed connection with end-to-end flow 788 control and delivery confirmation. 790 Class 3 - A frame-multiplexed connection with no provisions for 791 end-to-end flow control or delivery confirmation. 793 Class 4 -- A connection-oriented service, based on a virtual 794 circuit model, providing confirmed delivery with bandwidth and 795 latency guarantees. 797 Class 6 -- A reliable multicast service derived from class 1. 799 Class 2 and class 3 are the predominant services supported by 800 deployed fibre channel storage and clustering systems. 802 Class 3 service is similar to UDP or IP datagram service. Fibre 803 channel storage devices using this class of service rely on the ULP 804 implementation to detect and recover from transient device and 805 transport errors. 807 For class 2 and class 3 service, the fibre channel fabric is not 808 required to provide in-order delivery of frames unless explicitly 810 iFCP Revision 13 August 2002 812 requested by the frame originator (and supported by the fabric). If 813 ordered delivery is not in effect, it is the responsibility of the 814 frame recipient to reconstruct the order in which frames were sent 815 based on information in the frame header. 817 3.9 Login Processes 819 The Login processes are FC-2 operations that allow an N_PORT to 820 establish the operating environment necessary to communicate with 821 the fabric, other N_PORTs and ULP implementations accessed via the 822 N_PORT. Three login operations are supported: 824 a) Fabric Login (FLOGI) -- An operation whereby the N_PORT 825 registers its presence on the fabric, obtains fabric parameters 826 such as classes of service supported, and receives its N_PORT 827 address, 829 b) Port Login (PLOGI) -- An operation by which an N_PORT 830 establishes communication with another N_PORT. 832 c) Process Login (PRLOGI) -- An operation which establishes the 833 process-to-process communications associated with a specific 834 FC-4 ULP -- such as FCP-2, the fibre channel SCSI mapping. 836 Since N_PORT addresses are volatile, an N_PORT originating a login 837 (PLOGI) operation executes a Name Server query to discover the 838 fibre channel address of the remote device. A common query type 839 involves use of the worldwide unique name of an N_PORT to obtain 840 the 24-bit N_PORT fibre channel address to which the PLOGI request 841 is sent. 843 4. The iFCP Network Model 845 The iFCP protocol enables the implementation of fibre channel 846 fabric functionality on an IP network in which IP components and 847 technology replace the fibre channel switching and routing 848 infrastructure described in section 3.2. 850 The example of Figure 6 shows a fibre channel network with attached 851 devices. Each device accesses the network through an N_PORT 852 connected to an interface whose behavior is specified in [FC-FS] or 853 [FC-AL2]. In this case, the N_PORT represents any of the variants 854 described in section 3.2. The interface to the fabric may be an 855 L_PORT, F_PORT or FL_PORT. 857 Within the fibre channel device domain, addressable entities 858 consist of other N_PORTs and fibre channel devices internal to the 859 network that perform the fabric services defined in [FC-GS3]. 861 iFCP Revision 13 August 2002 863 Fibre Channel Network 864 +--------+ +--------+ 865 | FC | | FC | 866 | Device | | Device | 867 |........| FC |........| Fibre Channel 868 | N_PORT |<......>| N_PORT | Device Domain 869 +---+----+ Traffic+----+---+ ^ 870 | | | 871 +---+----+ +----+---+ | 872 | Fabric | | Fabric | | 873 | Port | | Port | | 874 ==========+========+========+========+============== 875 | FC Network & | | 876 | Fabric Services | v 877 | | Fibre Channel 878 +--------------------------+ Network Domain 879 Figure 6 -- A Fibre Channel Network 881 Gateway Region Gateway Region 882 +--------+ +--------+ +--------+ +--------+ 883 | FC | | FC | | FC | | FC | 884 | Device | | Device | | Device | | Device | Fibre 885 |........| |........| FC |........| |........| Channel 886 | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device 887 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 888 | | | | ^ 889 +---+----+ +---+----+ +----+---+ +----+---+ | 890 | F_PORT | | F_PORT | | F_PORT | | F_PORT | | 891 =+========+==+========+===========+========+==+========+========== 892 | iFCP Layer |<--------->| iFCP Layer | | 893 |....................| ^ |....................| | 894 | iFCP Portal | | | iFCP Portal | v 895 +--------+-----------+ | +----------+---------+ IP 896 iFCP|Gateway Control iFCP|Gateway Network 897 | Data | 898 | | 899 | | 900 |<------Encapsulated Frames------->| 901 | +------------------+ | 902 | | | | 903 +------+ IP Network +--------+ 904 | | 905 +------------------+ 906 Figure 7 -- An iFCP Fabric Example 908 One example of an equivalent iFCP fabric is shown in Figure 7. The 909 fabric consists of two gateway regions, each accessed by a single 910 iFCP gateway. 912 iFCP Revision 13 August 2002 914 Each gateway contains two standards-compliant F_PORTs and an iFCP 915 Portal for attachment to the IP network. Fibre channel devices in 916 the region are those locally connected to the iFCP fabric through 917 the gateway fabric ports. 919 Looking into the fabric port, the gateway appears as a fibre 920 channel switch element. At this interface, remote N_PORTs are 921 presented as fabric-attached devices. Conversely, on the IP network 922 side, the gateway presents each locally connected N_PORT as a 923 logical fibre channel device. 925 Extrapolating to the general case, each gateway region behaves like 926 an autonomous system whose configuration is invisible to the IP 927 network and other gateway regions. Consequently, in addition to the 928 F_PORT shown in the example, a gateway implementation may 929 transparently support the following fibre channel interfaces: 931 Inter-Switch Link -- A fibre channel switch-to-switch interface 932 used to access a region containing fibre channel switch 933 elements. An implementation may support the E_PORT defined 934 by [FC-SW2] or one of the proprietary interfaces provided 935 by various fibre channel switch vendors. In this case, the 936 gateway acts as a border switch connecting the gateway 937 region to the IP network. 939 FL_PORT -- An interface that provides fabric access for loop- 940 attached fibre channel devices as specified in [FC-FLA]. 942 L_PORT -- An interface through which a gateway may emulate the 943 fibre channel loop environment specified in [FC-AL2]. As 944 discussed in appendix B, the gateway presents remotely 945 accessed N_PORTS as loop-attached devices. 947 The manner in which these interfaces are provided by a gateway is 948 implementation-specific and therefore beyond the scope of this 949 document. 951 Although each region is connected to the IP network through one 952 gateway, a region may incorporate multiple gateways for added 953 performance and fault tolerance. To do so: 955 a) The gateways MUST coordinate the assignment of N_PORT IDs and 956 aliases such that each N_PORT has one and only one address and 958 b) All iFCP traffic between a given remote and local N_PORT pair 959 MUST flow through the same iFCP session (see section 5.2.1). 960 However, iFCP sessions to a given remotely attached N_PORT need 961 not traverse the same gateway. 963 Coordinating address assignments and managing the flow of traffic 964 is implementation-specific and outside the scope of this 965 specification. 967 iFCP Revision 13 August 2002 969 4.1 iFCP Transport Services 971 N_PORT to N_PORT communications that traverse a TCP/IP network 972 require the intervention of the iFCP layer within the gateway. This 973 consists of the following operations: 975 a) Execution of the frame addressing and mapping functions 976 described in section 4.4. 978 b) Encapsulation of fibre channel frames for injection into the 979 TCP/IP network and de-encapsulation of fibre channel frames 980 received from the TCP/IP network. 982 c) Establishment of an iFCP session in response to a PLOGI directed 983 to a remote device. 985 Section 4.4 discusses the iFCP frame addressing mechanism and the 986 way in which it is used to achieve communications transparency 987 between N_PORTs. 989 4.1.1 Fibre Channel Transport Services Supported by iFCP 991 An iFCP fabric supports Class 2 and Class 3 fibre channel transport 992 services as specified in [FC-FS]. An iFCP fabric does not support 993 class 4, class 6 or the Class 1 (dedicated connection) service. An 994 N_PORT discovers the classes of transport services supported by the 995 fabric during fabric login. 997 4.2 iFCP Device Discovery and Configuration Management 999 An iFCP implementation performs device discovery and iFCP fabric 1000 management through the Internet Storage Name Service defined in 1001 [ISNS]. Access to an iSNS server is required to perform the 1002 following functions: 1004 a) Emulate the services provided by the fibre channel name server 1005 described in section 3.3.1, including a mechanism for 1006 asynchronously notifying an N_PORT of changes in the iFCP fabric 1007 configuration, 1009 b) Aggregate gateways into iFCP fabrics for interoperation, 1011 c) Segment an iFCP fabric into fibre channel zones through the 1012 definition and management of device discovery scopes, referred 1013 to as 'discovery domains', 1015 d) Store and distribute security policies as described in section 1016 10.2.9. 1018 e) Implementation of the fibre channel broadcast mechanism. 1020 4.3 iFCP Fabric Properties 1021 iFCP Revision 13 August 2002 1023 A collection of iFCP gateways may be configured for interoperation 1024 as either a bounded or unbounded iFCP fabric. 1026 Gateways in a bounded iFCP fabric operate in address transparent 1027 mode as described in section 4.5. In this mode, the scope of a 1028 fibre channel N_PORT address is fabric-wide and is derived from 1029 domain IDs issued by the iSNS server from a common pool. As 1030 discussed in section 4.3.2, the maximum number of domain IDs 1031 allowed by fibre channel limits the configuration of a bounded iFCP 1032 fabric. 1034 Gateways in an unbounded iFCP fabric operate in address translation 1035 mode as described in section 4.6. In this mode, the scope of an 1036 N_PORT address is local to a gateway region. For fibre channel 1037 traffic between regions, the translation of frame-embedded N_PORT 1038 addresses is performed by the gateway. As discussed below, the 1039 number of switch elements and gateways in an unbounded iFCP fabric 1040 may exceed the limits of a conventional fibre channel fabric. 1042 All iFCP gateways MUST support unbounded iFCP fabrics. Support for 1043 bounded iFCP fabrics is OPTIONAL. 1045 The decision to support bounded iFCP fabrics in a gateway 1046 implementation depends on the address transparency, configuration 1047 scalability, and fault tolerance considerations given in the 1048 following sections. 1050 4.3.1 Address Transparency 1052 Although iFCP gateways in an unbounded fabric will convert N_PORT 1053 addresses in the frame header and payload of standard link service 1054 messages, a gateway cannot convert such addresses in the payload of 1055 vendor- or user-specific fibre channel frame traffic. 1057 Consequently, while both bounded and unbounded iFCP fabrics support 1058 standards-compliant FC-4 protocol implementations and link services 1059 used by mainstream fibre channel applications, a bounded iFCP 1060 fabric may also support vendor- or user-specific protocol and link 1061 service implementations that carry N_PORT IDs in the frame payload. 1063 4.3.2 Configuration Scalability 1065 The scalability limits of a bounded fabric configuration are a 1066 consequence of the fibre channel address allocation policy 1067 discussed in section 3.7.1. As noted, a bounded iFCP fabric using 1068 this address allocation scheme is limited to a combined total of 1069 239 gateways and fibre channel switch elements. As the system 1070 expands, the network may grow to include many switch elements and 1071 gateways, each of which controls a small number of devices. In 1072 this case, the limitation in switch and gateway count may become a 1073 barrier to extending and fully integrating the storage network. 1075 iFCP Revision 13 August 2002 1077 Since N_PORT fibre channel addresses in an unbounded iFCP fabric 1078 are not fabric-wide, the limits imposed by fibre channel address 1079 allocation only apply within the gateway region. Across regions, 1080 the number of iFCP gateways, fibre channel devices and switch 1081 elements that may be internetworked are not constrained by these 1082 limits. In exchange for improved scalability, however, 1083 implementations must consider the incremental overhead of address 1084 conversion as well as the address transparency issues discussed in 1085 section 4.3.1. 1087 4.3.3 Fault Tolerance 1089 In a bounded iFCP fabric, address reassignment caused by a fault or 1090 reconfiguration, such as the addition of a new gateway region, may 1091 cascade to other regions, causing fabric-wide disruption as new 1092 N_PORT addresses are assigned. Furthermore, before a new gateway 1093 can be merged into the fabric, its iSNS server must be slaved to 1094 the iSNS server in the bounded fabric to centralize the issuance of 1095 domain IDs. In an unbounded iFCP fabric coordinating the iSNS 1096 databases requires only that the iSNS servers exchange client 1097 attributes with one another. 1099 A bounded iFCP fabric also has an increased dependency on the 1100 availability of the iSNS server, which must act as the central 1101 address assignment authority. If connectivity with the server is 1102 lost, new DOMAIN_ID values cannot be automatically allocated as 1103 gateways and fibre channel switch elements are added. 1105 4.4 The iFCP N_PORT Address Model 1107 This section discusses iFCP extensions to the fibre channel 1108 addressing model of section 3.7.1, which are required for the 1109 transparent routing of frames between locally and remotely attached 1110 N_PORTs. 1112 In the iFCP protocol an N_PORT is represented by the following 1113 addresses: 1115 a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a 1116 locally attached device. Depending on the gateway addressing 1117 mode, the scope is either local to a region or a bounded iFCP 1118 fabric. In either mode, communications between N_PORTs in the 1119 same gateway region use the N_PORT ID. 1121 b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned 1122 by each gateway operating in address translation mode to 1123 identify a remotely attached N_PORT. Frame traffic is 1124 intercepted by an iFCP gateway and directed to a remotely 1125 attached N_PORT by means of the N_PORT alias. The address 1126 assigned by each gateway is unique within the scope of the 1127 gateway region. 1129 iFCP Revision 13 August 2002 1131 c) An N_PORT network address. A tuple consisting of the gateway IP 1132 address, TCP port number and N_PORT ID. The N_PORT network 1133 address identifies the source and destination N_PORTs for fibre 1134 channel traffic on the IP network. 1136 To provide transparent communications between a remote and local 1137 N_PORT, a gateway MUST maintain an iFCP session descriptor (see 1138 section 5.2.2.2) reflecting the association between the fibre 1139 channel address representing the remote N_PORT and the remote 1140 device's N_PORT network address. To establish this association the 1141 iFCP gateway assigns and manages fibre channel N_PORT fabric 1142 addresses as described in the following paragraphs. 1144 In an iFCP fabric, the iFCP gateway performs the address assignment 1145 and frame routing functions of an FC switch element. Unlike an FC 1146 switch, however, an iFCP gateway must also direct frames to 1147 external devices attached to remote gateways on the IP network. 1149 In order to be transparent to FC devices, the gateway must deliver 1150 such frames using only the 24-bit destination address in the frame 1151 header. By exploiting its control of address allocation and access 1152 to frame traffic entering or leaving the gateway region, the 1153 gateway is able to achieve the necessary transparency. 1155 N_PORT addresses within a gateway region may be allocated in one of 1156 two ways: 1158 a) Address Translation Mode - A mode of N_PORT address assignment 1159 in which the scope of an N_PORT fibre channel address is unique 1160 to the gateway region. The address of a remote device is 1161 represented in that gateway region by its gateway-assigned 1162 N_PORT alias. 1164 b) Address Transparent Mode - A mode of N_PORT address assignment 1165 in which the scope of an N_PORT fibre channel address is unique 1166 across the set of gateway regions comprising a bounded iFCP 1167 fabric. 1169 In address transparent mode, gateways within a bounded fabric 1170 cooperate in the assignment of addresses to locally attached 1171 N_PORTs. Each gateway in control of a region is responsible for 1172 obtaining and distributing unique domain IDs from the address 1173 assignment authority as described in section 4.5.1. Consequently, 1174 within the scope of a bounded fabric, the address of each N_PORT is 1175 unique. For that reason, gateway-assigned aliases are not required 1176 to represent remote N_PORTs. 1178 All iFCP implementations MUST support operation in address 1179 translation mode. Implementation of address transparent mode is 1180 OPTIONAL but, of course, must be provided if bounded iFCP fabric 1181 configurations are to be supported. 1183 iFCP Revision 13 August 2002 1185 The mode of gateway operation is settable in an implementation- 1186 specific manner. The implementation MUST NOT: 1188 a) Allow the mode to be changed after the gateway begins processing 1189 fibre channel frame traffic 1191 b) Permit operation in more than one mode at a time or 1193 c) Establish an iFCP session with a gateway that is not in the same 1194 mode. 1196 4.5 Operation in Address Transparent Mode 1198 The following considerations and requirements apply to this mode of 1199 operation: 1201 a) iFCP gateways in address transparent mode will not interoperate 1202 with iFCP gateways that are not in address transparent mode. 1204 b) When interoperating with locally attached fibre channel switch 1205 elements, each iFCP gateway MUST assume control of DOMAIN_ID 1206 assignments in accordance with the appropriate fibre channel 1207 standard or vendor-specific protocol specification. As 1208 described in section 4.5.1, DOMAIN_ID values assigned to FC 1209 switches internal to the gateway region must be issued by the 1210 iSNS server. 1212 c) When operating in address transparent Mode, fibre channel 1213 address translation SHALL NOT take place. 1215 When operating in address transparent mode, however, the gateway 1216 MUST establish and maintain the context of each iFCP session in 1217 accordance with section 5.2.2. 1219 4.5.1 Transparent Mode Domain ID Management 1221 As described in section 4.5, each gateway and fibre channel switch 1222 in a bounded iFCP fabric has a unique domain ID. In a gateway 1223 region containing fibre channel switch elements, each element 1224 obtains a domain ID by querying the principal switch as described 1225 in [FC-SW2] -- in this case the iFCP gateway itself. The gateway 1226 in turn obtains domain IDs on demand from the iSNS name server 1227 acting as the central address allocation authority. In effect, the 1228 iSNS server assumes the role of principal switch for the bounded 1229 fabric. In that case, the iSNS database contains: 1231 a) The definition for one or more bounded iFCP fabrics, 1233 b) For each bounded fabric, a worldwide unique name identifying 1234 each gateway in the fabric. A gateway in address transparent 1235 mode MUST reside in one and only one bounded fabric. 1237 iFCP Revision 13 August 2002 1239 As the Principal Switch within the gateway region, an iFCP gateway 1240 in address transparent mode SHALL obtain domain IDs for use in the 1241 gateway region by issuing the appropriate iSNS query using its 1242 worldwide name. 1244 4.5.2 Incompatibility with Address Translation Mode 1246 Except for the session control frames specified in section 6, iFCP 1247 gateways in address transparent mode SHALL NOT originate or accept 1248 frames that do not have the TRP bit set to one in the iFCP flags 1249 field of the encapsulation header (see section 5.3.1). The iFCP 1250 gateway SHALL immediately terminate all iFCP sessions with the iFCP 1251 gateway from which it receives such frames. 1253 4.6 Operation in Address Translation Mode 1255 This section describes the process for managing the assignment of 1256 addresses within a gateway region that is part of an unbounded iFCP 1257 fabric, including the modification of FC frame addresses embedded 1258 in the frame header for frames sent and received from remotely 1259 attached N_PORTs. 1261 As described in section 4.4, the scope of N_PORT addresses in this 1262 mode is local to the gateway region. A principal switch within the 1263 gateway region, possibly the iFCP gateway itself, oversees the 1264 assignment of such addresses in accordance with the rules specified 1265 in [FC-FS] and [FC-FLA]. 1267 The assignment of N_PORT addresses to locally attached devices is 1268 controlled by the switch element to which the device is connected. 1270 The assignment of N_PORT addresses for remotely attached devices is 1271 controlled by the gateway through which the remote device is 1272 accessed. In this case, the gateway MUST assign a locally 1273 significant N_PORT alias to be used in place of the N_PORT ID 1274 assigned by the remote gateway. The N_PORT alias is assigned during 1275 device discovery as described in section 5.2.2.1. 1277 To perform address conversion and enable the appropriate routing, 1278 the gateway MUST establish an iFCP session and generate the 1279 information required to map each N_PORT alias to the appropriate 1280 TCP/IP connection context and N_PORT ID of the remotely accessed 1281 N_PORT. The means by which these mappings are created and updated 1282 are specified in section 5.2.2.2. As described in that section, 1283 the required mapping information is represented by the iFCP session 1284 descriptor reproduced in Figure 8. 1286 iFCP Revision 13 August 2002 1288 +-----------------------+ 1289 |TCP Connection Context | 1290 +-----------------------+ 1291 | Local N_PORT ID | 1292 +-----------------------+ 1293 | Remote N_PORT ID | 1294 +-----------------------+ 1295 | Remote N_PORT Alias | 1296 +-----------------------+ 1297 Figure 8 -- iFCP Session Descriptor (from section 5.2.2.2) 1299 Except for frames comprising special link service messages (see 1300 section 7.2), outbound frames are encapsulated and sent without 1301 modification. Address translation is deferred until receipt from 1302 the IP network as specified in section 4.6.1. 1304 4.6.1 Inbound Frame Address Translation 1306 For inbound frames received from the IP network, the receiving 1307 gateway SHALL reference the session descriptor to fill in the D_ID 1308 field with the destination N_PORT ID and the S_ID field with the 1309 N_PORT alias it assigned. The translation process for inbound 1310 frames is shown in Figure 9. 1312 iFCP Revision 13 August 2002 1314 Network Format of Inbound Frame 1315 +--------------------------------------------+ iFCP 1316 | FC Encapsulation Header | Session 1317 +--------------------------------------------+ Descriptor 1318 | SOF Delimiter Word | | 1319 +========+===================================+ V 1320 | | D_ID Field | +--------+-----+ 1321 +--------+-----------------------------------+ | Lookup source| 1322 | | S_ID Field | | N_PORT Alias | 1323 +--------+-----------------------------------+ | and | 1324 | Control Information, Payload | | destination | 1325 | and FC CRC | | N_PORT ID | 1326 | | +--------+-----+ 1327 | | | 1328 | | | 1329 +============================================+ | 1330 | EOF Delimiter Word | | 1331 +--------------------------------------------+ | 1332 | 1333 | 1334 Frame after Address Translation and De-encapsulation | 1335 +--------+-----------------------------------+ | 1336 | | Destination N_PORT ID |<-------------+ 1337 +--------+-----------------------------------+ | 1338 | | Source N_PORT Alias |<-------------+ 1339 +--------+-----------------------------------+ 1340 | | 1341 | Control information, Payload, | 1342 | and FC CRC | 1343 +--------------------------------------------+ 1344 Figure 9 -- Inbound Frame Address Translation 1346 The receiving gateway SHALL consider the contents of the S_ID and 1347 D_ID fields to be undefined when received. After replacing these 1348 fields, the gateway MUST recalculate the FC CRC. 1350 4.6.2 Incompatibility with Address Transparent Mode 1352 iFCP gateways in address translation mode SHALL NOT originate or 1353 accept frames that have the TRP bit set to one in the iFCP flags 1354 field of the encapsulation header. The iFCP gateway SHALL 1355 immediately abort all iFCP sessions with the iFCP gateway from 1356 which it receives such frames as described in section 5.2.3. 1358 5. iFCP Protocol 1360 5.1 Overview 1362 5.1.1 iFCP Transport Services 1364 The main function of the iFCP protocol layer is to transport fibre 1365 channel frame images between locally and remotely attached N_PORTs. 1367 iFCP Revision 13 August 2002 1369 When transporting frames to a remote N_PORT, the iFCP layer 1370 encapsulates and routes the fibre channel frames comprising each 1371 fibre channel Information Unit via a predetermined TCP connection 1372 for transport across the IP network. 1374 When receiving fibre channel frame images from the IP network, the 1375 iFCP layer de-encapsulates and delivers each frame to the 1376 appropriate N_PORT. 1378 The iFCP layer processes the following types of traffic: 1380 a) FC-4 frame images associated with a fibre channel application 1381 protocol. 1383 b) FC-2 frames comprising fibre channel link service requests and 1384 responses 1386 c) Fibre channel broadcast frames 1388 d) iFCP control messages required to setup, manage or terminate an 1389 iFCP session. 1391 For FC-4 N_PORT traffic and most FC-2 messages the iFCP layer never 1392 interprets the contents of the frame payload. 1394 iFCP does interpret and process iFCP control messages and certain 1395 link service messages as described in section 5.1.2 1397 5.1.2 iFCP Support for Link Services 1399 iFCP must intervene in the processing of those fibre channel link 1400 service messages that contain N_PORT addresses in the message 1401 payload or require other special handling, such as an N_PORT login 1402 request (PLOGI). 1404 In the former case, an iFCP gateway operating in address 1405 translation mode MUST supplement the payload with additional 1406 information that enables the receiving gateway to convert such 1407 embedded N_PORT addresses to its frame of reference. 1409 For out-bound fibre channel frames comprising such a link service, 1410 the iFCP layer creates the supplemental information based on frame 1411 content, modifies the frame payload, then transmits the resulting 1412 fibre channel frame with supplemental data through the appropriate 1413 TCP connection. 1415 For incoming iFCP frames containing supplemented fibre channel link 1416 service frames, iFCP must interpret the frame, including any 1417 supplemental information, modify the frame content, and forward the 1418 resulting frame to the destination N_PORT for further processing. 1420 iFCP Revision 13 August 2002 1422 Section 7.1 describes the processing of these link service messages 1423 in detail. 1425 5.2 TCP Stream Transport of iFCP Frames 1427 5.2.1 iFCP Session Model 1429 An iFCP session consists of the pair of N_PORTs comprising the 1430 session endpoints joined by a single TCP/IP connection. No more 1431 than one iFCP session SHALL exist between a given pair of N_PORTs. 1433 An N_PORT is identified by its network address consisting of: 1435 a) The N_PORT ID assigned by the gateway to which the N_PORT is 1436 locally attached and 1438 b) The iFCP Portal address, consisting of its IP address and TCP 1439 port number. 1441 Since only one iFCP session may exist between a pair of N_PORTs, 1442 the iFCP session is uniquely identified by the network addresses of 1443 the session end points. 1445 TCP connections that may be used for iFCP sessions between pairs of 1446 iFCP portals are either "bound" or "unbound". An unbound 1447 connection is a TCP connection that is not actively supporting an 1448 iFCP session. A gateway implementation MAY establish a pool of 1449 unbound connections to reduce the session setup time. Such pre- 1450 existing TCP connections between iFCP Portals remain unbound and 1451 uncommitted until allocated to an iFCP session through a CBIND 1452 message (see section 6.1). 1454 When the iFCP layer creates an iFCP session, it may select an 1455 existing unbound TCP connection or establish a new TCP connection 1456 and send the CBIND message down that TCP connection. This 1457 allocates the TCP connection to that iFCP session. 1459 5.2.2 iFCP Session Management 1461 This section describes the protocols and data structures required 1462 to establish and terminate an iFCP session. 1464 5.2.2.1 The Remote N_PORT Descriptor 1466 In order to establish an iFCP session, an iFCP gateway MUST 1467 maintain information allowing it to locate a remotely attached 1468 N_PORT. For explanatory purposes, such information is assumed to 1469 reside in a descriptor having the format shown in Figure 10. 1471 iFCP Revision 13 August 2002 1473 +--------------------------------+ 1474 | N_PORT Worldwide Unique Name | 1475 +--------------------------------+ 1476 | iFCP Portal Address | 1477 +--------------------------------+ 1478 | N_PORT ID of Remote N_PORT | 1479 +--------------------------------+ 1480 | N_PORT Alias | 1481 +--------------------------------+ 1482 Figure 10 -- Remote N_PORT Descriptor 1484 Each descriptor aggregates the following information about a 1485 remotely attached N_PORT: 1487 N_PORT Worldwide Unique Name -- 64-bit N_PORT world wide name 1488 as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely 1489 identified by this parameter. 1491 iFCP Portal Address -- The IP address and TCP port number 1492 referenced when requesting creation of the TCP connection 1493 associated with an iFCP session. 1495 N_PORT ID -- N_PORT fibre channel address assigned to the 1496 remote device by the remote iFCP gateway. 1498 N_PORT Alias -- N_PORT fibre channel address assigned to the 1499 remote device by the 'local' iFCP gateway when operating in 1500 address translation mode. 1502 An iFCP gateway SHALL have one and only one descriptor for each 1503 remote N_PORT it accesses. If a descriptor does not exist, one 1504 SHALL be created using the information returned by an iSNS name 1505 server query. Such queries may be result from: 1507 a) A fibre channel Name Server request originated by a locally 1508 attached N_PORT (see sections 3.5 and 9.3), or 1510 b) A CBIND request received from a remote fibre channel device (see 1511 section 5.2.2.2). 1513 When creating a descriptor in response to an incoming CBIND 1514 request, the iFCP gateway SHALL perform an iSNS name server query 1515 using the worldwide port name of the remote N_PORT in the SOURCE 1516 N_PORT NAME field within the CBIND payload. The descriptor SHALL 1517 be filled in using the query results. 1519 After creating the descriptor, a gateway operating in address 1520 translation mode SHALL create and add the 24-bit N_PORT alias. 1522 5.2.2.1.1 Updating a Remote N_PORT Descriptor 1523 iFCP Revision 13 August 2002 1525 A Remote N_PORT descriptor SHALL only be updated as the result of 1526 an iSNS query to obtain information for the specified worldwide 1527 port name or from information returned by an iSNS state change 1528 notification. Following such an update, a new N_PORT alias SHALL 1529 NOT be assigned. 1531 Before such an update, the contents of a descriptor may have become 1532 stale as the result of an event that invalidated or triggered a 1533 change in the N_PORT network address of the remote device, such as 1534 a fabric reconfiguration or the device's removal or replacement. 1536 A collateral effect of such an event is that a fibre channel device 1537 that has been added or whose N_PORT ID has changed will have no 1538 active N_PORT logins. Consequently, FC-4 traffic directed to such 1539 an N_PORT as the result of a stale descriptor will be rejected or 1540 discarded. 1542 Once the originating N_PORT learns of the reconfiguration, usually 1543 through the name server state change notification mechanism, 1544 information returned in the notification or the subsequent name 1545 server lookup needed to reestablish the iFCP session will 1546 automatically purge such stale data from the gateway. 1548 5.2.2.1.2 Deleting a Remote N_PORT Descriptor 1550 Deleting a remote N_PORT descriptor is equivalent to freeing up the 1551 corresponding N_PORT alias for reuse, consequently the descriptor 1552 MUST NOT be deleted while there are any iFCP sessions that 1553 reference the remote N_PORT. 1555 Descriptors eligible for deletion should be removed based on a last 1556 in, first out policy. 1558 5.2.2.2 Creating an iFCP Session 1560 An iFCP session may be in one of the following states: 1562 OPEN -- The session state in which fibre channel frame images may 1563 be sent and received. 1565 OPEN PENDING -- The session state after a gateway has issued a 1566 CBIND request but no response has yet been received. No fibre 1567 channel frames may be sent. 1569 The session may be initiated in response to a PLOGI ELS (see 1570 section 7.3.1.7) or for any other implementation-specific reason. 1572 The gateway SHALL create the iFCP session as follows: 1574 a) Locate the remote N_PORT descriptor corresponding to the session 1575 end point. If creating the session in order to forward a fibre 1576 channel frame, the session endpoint may be obtained by 1578 iFCP Revision 13 August 2002 1580 referencing the remote N_PORT alias contained in the frame 1581 header D_ID field. If no descriptor exists, an iFCP session 1582 SHALL NOT be created. 1584 b) Allocate a TCP connection to the gateway to which the remote 1585 N_PORT is locally attached. An implementation may use an 1586 existing connection in the Unbound state or a new connection may 1587 be created and placed in the Unbound state. 1589 When creating a connection, the IP address and TCP Port number 1590 SHALL be obtained by referencing the remote N_PORT descriptor as 1591 specified in section 5.2.2.1. 1593 c) If the TCP connection cannot be allocated or cannot be created 1594 due to limited resources the gateway SHALL terminate session 1595 creation. 1597 d) If the TCP connection is aborted for any reason before the iFCP 1598 session enters the OPEN state, the gateway SHALL respond in 1599 accordance with section 5.2.3 and MAY terminate the attempt to 1600 create a session or MAY try again to establish the TCP 1601 connection. 1603 e) The gateway SHALL then issue a CBIND session control message 1604 (see section 6.1) and place the session in the OPEN PENDING 1605 state. 1607 f) If a CBIND response is returned with a status other than 1608 "Success" or "iFCP session already exists", the session SHALL be 1609 terminated and the TCP connection returned to the Unbound state. 1611 g) A CBIND STATUS of "iFCP session already exists" indicates that 1612 the remote gateway has concurrently initiated a CBIND request to 1613 create an iFCP session between the same pair of N_PORTs. A 1614 gateway receiving such a response SHALL terminate this attempt 1615 and process the incoming CBIND request in accordance with 1616 section 5.2.2.3. 1618 h) In response to a CBIND STATUS of "Success", the gateway SHALL 1619 place the session in the OPEN state. 1621 Once the session is placed in the OPEN state, an iFCP session 1622 descriptor SHALL be created containing the information shown in 1623 Figure 11: 1625 iFCP Revision 13 August 2002 1627 +-----------------------+ 1628 |TCP Connection Context | 1629 +-----------------------+ 1630 | Local N_PORT ID | 1631 +-----------------------+ 1632 | Remote N_PORT ID | 1633 +-----------------------+ 1634 | Remote N_PORT Alias | 1635 +-----------------------+ 1636 Figure 11 -- iFCP Session Descriptor 1638 TCP Connection Context -- Information required to identify the TCP 1639 connection associated with the iFCP session. 1641 Local N_PORT ID -- N_PORT ID of the locally attached fibre channel 1642 device. 1644 Remote N_PORT ID -- N_PORT ID assigned to the remote device by the 1645 remote gateway. 1647 Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the 1648 local gateway when operating in address translation mode. If in 1649 this mode, the gateway SHALL copy this parameter from the Remote 1650 N_PORT descriptor. Otherwise, it is not filled in. 1652 5.2.2.3 Responding to a CBIND Request 1654 The gateway receiving a CBIND request SHALL respond as follows: 1656 a) If the receiver has a duplicate iFCP session in the OPEN PENDING 1657 state, then the receiving gateway SHALL compare the Source 1658 N_PORT Name in the incoming CBIND payload with the Destination 1659 N_PORT Name. 1661 b) If the Source N_PORT Name is greater, the receiver SHALL issue a 1662 CBIND response of "Success" and SHALL place the session in the 1663 OPEN state. 1665 c) If the Source N_PORT Name is less, the receiver shall issue a 1666 CBIND RESPONSE of Failed - N_PORT session already exists. The 1667 state of the receiver-initiated iFCP session SHALL BE unchanged. 1669 d) If there is no duplicate iFCP session in the OPEN PENDING state, 1670 the receiving gateway SHALL issue a CBIND response. If a status 1671 of Success is returned, the receiving gateway SHALL create the 1672 iFCP session and place it in the OPEN state. An iFCP session 1673 descriptor SHALL be created as described in section 5.2.2.2. 1675 e) If a remote N_PORT descriptor does not exist, one SHALL be 1676 created and filled in as described in section 5.2.2.1. 1678 5.2.2.4 Monitoring iFCP Connectivity 1679 iFCP Revision 13 August 2002 1681 During extended periods of inactivity, an iFCP session may be 1682 terminated due to a hardware failure within the gateway or through 1683 loss of TCP/IP connectivity. The latter may occur when the session 1684 traverses a stateful intermediate device, such as a NA(P)T box or 1685 firewall, that detects and purges connections it believes are 1686 unused. 1688 To test session liveness, expedite the detection of connectivity 1689 failures, and avoid spontaneous connection termination, an iFCP 1690 gateway may maintain a low level of session activity and monitor 1691 the session by requesting that the remote gateway periodically 1692 transmit the LTEST message described in section 6.3. All iFCP 1693 gateways SHALL support liveness testing as described in this 1694 specification. 1696 A gateway requests the LTEST heartbeat by specifying a non-zero 1697 value for the LIVENESS TEST INTERVAL in the CBIND request or 1698 response message as described in section 6.1. If both gateways 1699 wish to monitor liveness, each must set the LIVENESS TEST INTERVAL 1700 in the CBIND request or response. 1702 Upon receiving such a request, the gateway providing the heartbeat 1703 SHALL transmit LTEST messages at the specified interval. The first 1704 message SHALL be sent as soon as the iFCP session enters the OPEN 1705 state. LTEST messages SHALL NOT be sent when the iFCP session is 1706 not in the OPEN state. 1708 An iFCP session SHALL be terminated as described in section 5.2.3 1709 if: 1711 a) The contents of the LTEST message are incorrect, or 1713 b) An LTEST message is not received within twice the specified 1714 interval or the iFCP session has been quiescent for longer than 1715 twice the specified interval. 1717 The gateway to receive the LTEST message SHALL measure the 1718 interval for the first expected LTEST message from when the 1719 session is placed in the OPEN state. Thereafter, the interval 1720 SHALL be measured relative to the last LTEST message received. 1722 To maximize liveness test coverage, LTEST messages SHOULD flow 1723 through all the gateway components used to enter and retrieve fibre 1724 channel frames from the IP network, including the mechanisms for 1725 encapsulating and de-encapsulating fibre channel frames. 1727 In addition to monitoring a session, information in the LTEST 1728 message encapsulation header may also be used to compute an 1729 estimate of network propagation delay as described in section 1730 8.2.1. However, the propagation delay limit SHALL NOT be enforced 1731 for LTEST traffic. 1733 iFCP Revision 13 August 2002 1735 5.2.2.5 Use of TCP Features and Settings 1737 This section describes ground rules for the use of TCP features in 1738 an iFCP session. The core TCP protocol is defined in [RFC793]. 1739 TCP implementation requirements and guidelines are specified in 1740 [RFC1122]. 1742 +-----------+------------+--------------+------------+------------+ 1743 | Feature | Applicable | RFC | Peer-wise | Requirement| 1744 | | RFCs | Status | agreement | Level | 1745 | | | | required? | | 1746 +===========+============+==============+============+============+ 1747 | Keep Alive| [RFC1122] | None | No | Should not | 1748 | |(discussion)| | | use | 1749 +-----------+------------+--------------+------------+------------+ 1750 | Tiny | [RFC896] | Standard | No | Should not | 1751 | Segment | | | | use | 1752 | Avoidance | | | | | 1753 | (Nagle) | | | | | 1754 +-----------+------------+--------------+------------+------------+ 1755 | Window | [RFC1323] | Proposed | No | Should use | 1756 | Scale | | Standard | | | 1757 +-----------+------------+--------------+------------+------------+ 1758 | Wrapped | [RFC1323] | Proposed | No | SHOULD use | 1759 | Sequence | | Standard | | | 1760 | Protection| | | | | 1761 | (PAWS) | | | | | 1762 +-----------+------------+--------------+------------+------------+ 1763 Table 1 -- Usage of Optional TCP Features 1765 The following sections describe these options in greater detail. 1767 5.2.2.5.1 Keep Alive 1769 Keep Alive speeds the detection and cleanup of dysfunctional TCP 1770 connections by sending traffic when a connection would otherwise be 1771 idle. The issues are discussed in [RFC1122]. 1773 In order to test the device more comprehensively, fibre channel 1774 applications, such as storage, may implement an equivalent keep 1775 alive function at the FC-4 level. Alternatively, periodic liveness 1776 test messages may be issued as described in section 5.2.2.4. 1777 Because of these more comprehensive end-to-end mechanisms and the 1778 considerations described in [RFC1122], keep alive at the transport 1779 layer should not be implemented. 1781 5.2.2.5.2 'Tiny' Segment Avoidance (Nagle) 1783 The Nagle algorithm described in [RFC896] is designed to avoid the 1784 overhead of small segments by delaying transmission in order to 1785 agglomerate transfer requests into a large segment. In iFCP, such 1786 small transfers often contain I/O requests. Hence, the 1788 iFCP Revision 13 August 2002 1790 transmission delay of the Nagle algorithm may decrease I/O 1791 throughput. Therefore, the Nagle algorithm should not be used. 1793 5.2.2.5.3 Window Scale 1795 Window scaling, as specified in [RFC1323], allows full utilization 1796 of links with large bandwidth - delay products and should be 1797 supported by an iFCP implementation. 1799 5.2.2.5.4 Wrapped Sequence Protection (PAWS) 1801 TCP segments are identified with 32-bit sequence numbers. In 1802 networks with large bandwidth - delay products, it is possible for 1803 more than one TCP segment with the same sequence number to be in 1804 flight. In iFCP, receipt of such a sequence out of order may cause 1805 out-of-order frame delivery or data corruption. Consequently, this 1806 feature SHOULD be supported as described in [RFC1323]. 1808 5.2.3 Terminating iFCP Sessions 1810 iFCP sessions SHALL be terminated in response to one of the events 1811 in Table 2: 1813 iFCP Revision 13 August 2002 1815 +-------------------------------------------+---------------------+ 1816 | Event | iFCP Sessions | 1817 | | to Terminate | 1818 +===========================================+=====================+ 1819 | PLOGI terminated with LS_RJT response | Peer N_PORT | 1820 +-------------------------------------------+---------------------+ 1821 | State change notification indicating | All iFCP Sessions | 1822 | N_PORT removal or reconfiguration. | from the | 1823 | | reconfigured N_PORT | 1824 +-------------------------------------------+---------------------+ 1825 | LOGO ACC response from peer N_PORT | Peer N_PORT | 1826 +-------------------------------------------+---------------------+ 1827 | ACC response to LOGO ELS sent to F_PORT | All iFCP sessions | 1828 | server (D_ID = 0xFF-FF-FE) (fabric | from the originating| 1829 | logout) | N_PORT | 1830 +-------------------------------------------+---------------------+ 1831 | Implicit N_PORT LOGO as defined in | All iFCP sessions | 1832 | [FC-FS] | from the N_PORT | 1833 | | logged out | 1834 +-------------------------------------------+---------------------+ 1835 | LTEST Message Error (see section 5.2.2.4) | Peer N_PORT | 1836 +-------------------------------------------+---------------------+ 1837 | Non fatal encapsulation error as | Peer N_PORT | 1838 | specified in section 5.3.3 | | 1839 +-------------------------------------------+---------------------+ 1840 | Failure of the TCP connection associated | Peer N_PORT | 1841 | with the iFCP session | | 1842 +-------------------------------------------+---------------------+ 1843 | Receipt of an UNBIND session control | Peer N_PORT | 1844 | message | | 1845 +-------------------------------------------+---------------------+ 1846 | Gateway enters the Unsynchronized state | All iFCP sessions | 1847 | (see section 8.2.1) | | 1848 +-------------------------------------------+---------------------+ 1849 | Gateway detects incorrect address mode | All iFCP sessions | 1850 | to peer gateway(see section 4.6.2) | with peer gateway | 1851 +-------------------------------------------+---------------------+ 1852 Table 2-- Session Termination Events 1854 If a session is being terminated due to an incorrect address mode 1855 with the peer gateway, the TCP connection SHALL be aborted by means 1856 of a connection reset (RST) without performing an UNBIND. 1857 Otherwise, if the TCP connection is still open following the event, 1858 the gateway SHALL shut down the connection as follows: 1860 a) Stop sending fibre channel frames over the TCP connection. 1862 b) Discard all incoming traffic, except for an UNBIND session 1863 control message. 1865 c) If an UNBIND message is received at any time, return a response 1866 in accordance with section 6.2. 1868 iFCP Revision 13 August 2002 1870 d) If session termination was not triggered by an UNBIND message, 1871 issue the UNBIND session control message as described in section 1872 6.2. 1874 e) If the UNBIND message completes with a status of Success, the 1875 TCP connection MAY remain open at the discretion of either 1876 gateway and may be kept in a pool of unbound connections in 1877 order to speed the creation of a new iFCP session. 1879 If the UNBIND fails for any reason, the TCP connection MUST be 1880 terminated. In this case, the connection SHOULD be aborted with 1881 a connection reset (RST). 1883 For each terminated session, the session descriptor SHALL be 1884 deleted. If a session was terminated by an event other than an 1885 implicit LOGO or a LOGO ACC response, the gateway shall issue a 1886 LOGO to the locally attached N_PORT on behalf of the remote N_PORT. 1888 To recover resources, either gateway may spontaneously close an 1889 unbound TCP connection at any time. If a gateway terminates a 1890 connection with a TCP close operation, the peer gateway MUST 1891 respond by executing a TCP close. 1893 5.3 Fibre Channel Frame Encapsulation 1895 This section describes the iFCP encapsulation of fibre channel 1896 frames. The encapsulation complies with the common encapsulation 1897 format defined in [ENCAP], portions of which are included here for 1898 convenience. 1900 The format of an encapsulated frame is shown below: 1902 +--------------------+ 1903 | Header | 1904 +--------------------+-----+ 1905 | SOF | f | 1906 +--------------------+ F r | 1907 | FC frame content | C a | 1908 +--------------------+ m | 1909 | EOF | e | 1910 +--------------------+-----+ 1911 Figure 12 -- Encapsulation Format 1913 The encapsulation consists of a 7-word header, an SOF delimiter 1914 word, the FC frame (including the fibre channel CRC), and an EOF 1915 delimiter word. The header and delimiter formats are described in 1916 the following sections. 1918 5.3.1 Encapsulation Header Format 1919 iFCP Revision 13 August 2002 1921 W|------------------------------Bit------------------------------| 1922 o| | 1923 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| 1924 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| 1925 +---------------+---------------+---------------+---------------+ 1926 0| Protocol# | Version | -Protocol# | -Version | 1927 +---------------+---------------+---------------+---------------+ 1928 1| Reserved (must be zero) | 1929 +---------------+---------------+---------------+---------------+ 1930 2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF | 1931 +-----------+---+---------------+-----------+---+---------------+ 1932 3| Flags | Frame Length | -Flags | -Frame Length | 1933 +-----------+-------------------+-----------+-------------------+ 1934 4| Time Stamp [integer] | 1935 +---------------------------------------------------------------+ 1936 5| Time Stamp [fraction] | 1937 +---------------------------------------------------------------+ 1938 6| CRC | 1939 +---------------------------------------------------------------+ 1940 Figure 13 --- Encapsulation Header Format 1942 Common Encapsulation Fields: 1944 iFCP Revision 13 August 2002 1946 Protocol# IANA-assigned protocol number 1947 identifying the protocol using the 1948 encapsulation. For iFCP, the value 1949 assigned by [ENCAP] is 2. 1951 Version Encapsulation version as specified in 1952 [ENCAP] 1954 -Protocol# Ones complement of the protocol# 1956 -Version Ones complement of the version 1958 Flags Encapsulation flags (see 5.3.1.1) 1960 Frame Length Contains the length of the entire FC 1961 Encapsulated frame including the FC 1962 Encapsulation Header and the FC frame 1963 (including SOF and EOF words) in units 1964 of 32-bit words. 1966 -Flags Ones-complement of the Flags field. 1968 -Frame Length Ones-complement of the Frame Length 1969 field. 1971 Time Stamp [integer] Integer component of the frame time 1972 stamp as specified in [ENCAP]. 1974 Time Stamp Fractional component of the time stamp 1975 [fraction] as specified in [ENCAP]. 1977 CRC Header CRC. MUST be valid for iFCP. 1979 The time stamp fields are used to enforce the limit on the 1980 lifetime of a fibre channel frame as described in section 1981 8.2.1. 1983 iFCP-specific fields: 1985 iFCP Revision 13 August 2002 1987 LS_COMMAND_ACC For a special link service ACC 1988 response to be processed by iFCP, the 1989 LS_COMMAND_ACC field SHALL contain a 1990 copy of bits 0 through 7 of the 1991 LS_COMMAND to which the ACC applies. 1992 Otherwise the LS_COMMAND_ACC field 1993 SHALL be set to zero. 1995 iFCP Flags iFCP-specific flags (see below) 1997 SOF Copy of the SOF delimiter encoding 1998 (see section 5.3.2) 2000 EOF Copy of the EOF delimiter encoding 2001 (see section 5.3.2) 2003 The iFCP flags word has the following format: 2005 |------------------------Bit----------------------------| 2006 | | 2007 | 8 9 10 11 12 13 14 15 | 2008 +------+------+------+------+------+------+------+------+ 2009 | Reserved | SES | TRP | SPC | 2010 +------+------+------+------+------+------+------+------+ 2011 Figure 14 -- iFCP Flags Word 2013 iFCP Flags: 2015 SES 1 = Session control frame (TRP and SPC MUST be 2016 0) 2018 TRP 1 = Address transparent mode enabled 2020 0 = Address translation mode enabled 2022 SPC 1 = Frame is part of a link service message 2023 requiring special processing by iFCP prior 2024 to forwarding to the destination N_PORT. 2026 5.3.1.1 Common Encapsulation Flags 2028 The iFCP usage of the common encapsulation flags defined in [ENCAP] 2029 is shown in Figure 15: 2031 iFCP Revision 13 August 2002 2033 |------------------------Bit--------------------------| 2034 | | 2035 | 0 1 2 3 4 5 | 2036 +--------------------------------------------+--------+ 2037 | Reserved | CRCV | 2038 +--------------------------------------------+--------+ 2039 Figure 15 -- iFCP Common Encapsulation Flags 2041 For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 2043 5.3.2 SOF and EOF Delimiter Fields 2045 The format of the delimiter fields is shown below. 2047 W|------------------------------Bit------------------------------| 2048 o| | 2049 r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3| 2050 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| 2051 +---------------+---------------+---------------+---------------+ 2052 0| SOF | SOF | -SOF | -SOF | 2053 +---------------+---------------+---------------+---------------+ 2054 1| | 2055 +----- FC frame content -----+ 2056 | | 2057 +---------------+---------------+---------------+---------------+ 2058 n| EOF | EOF | -EOF | -EOF | 2059 +---------------+---------------+---------------+---------------+ 2060 Figure 16 -- FC Frame Encapsulation Format 2062 SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following 2063 subset of the SOF fields specified in [ENCAP]. For convenience, 2064 these are reproduced in Table 3. The authoritative encodings 2065 should be obtained from [ENCAP]. 2067 +-------+----------+ 2068 | FC | | 2069 | SOF | SOF Code | 2070 +-------+----------+ 2071 | SOFi2 | 0x2D | 2072 | SOFn2 | 0x35 | 2073 | SOFi3 | 0x2E | 2074 | SOFn3 | 0x36 | 2075 +-------+----------+ 2076 Table 3-- Translation of FC SOF Values to SOF Field Contents 2078 -SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the 2079 ones complement of the value in the SOF fields. 2081 EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset 2082 of EOF fields specified in [ENCAP]. For convenience, these are 2083 reproduced in Table 4. The authoritative encodings should be 2084 obtained from [ENCAP]. 2086 iFCP Revision 13 August 2002 2088 +-------+----------+ 2089 | FC | | 2090 | EOF | EOF Code | 2091 +-------+----------+ 2092 | EOFn | 0x41 | 2093 | EOFt | 0x42 | 2094 +-------+----------+ 2095 Table 4 -- Translation of FC EOF Values to EOF Field Contents 2097 -EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the 2098 one's complement of the value in the EOF fields. 2100 iFCP implementations SHALL place a copy of the SOF and EOF 2101 delimiter codes in the appropriate header fields. 2103 5.3.3 Frame Encapsulation 2105 A fibre channel Frame to be encapsulated MUST first be validated as 2106 described in [FC-FS]. Any frames received from a locally attached 2107 fibre channel device that do not pass the validity tests in [FC-FS] 2108 SHALL be discarded by the gateway. 2110 If the frame is a PLOGI ELS, the creation of an iFCP session as 2111 described in section 7.3.1.7 may precede encapsulation. Once the 2112 session has been created, frame encapsulation SHALL proceed as 2113 follows. 2115 The S_ID and D_ID fields in the frame header SHALL be referenced to 2116 lookup the iFCP session descriptor (see section 5.2.2.2). If no 2117 iFCP session descriptor exists, the frame SHALL be discarded. 2119 Frame types submitted for encapsulation and forwarding on the IP 2120 network SHALL have one of the SOF delimiters in Table 3 and an EOF 2121 delimiter from Table 4. Other valid frame types MUST be processed 2122 internally by the gateway as specified in the appropriate fibre 2123 channel specification. 2125 If operating in address translation mode and processing a special 2126 link service message requiring the inclusion of supplemental data, 2127 the gateway SHALL format the frame payload and add the supplemental 2128 information specified in section 7.1. The gateway SHALL then 2129 calculate a new FC CRC on the reformatted frame. 2131 Otherwise, the frame contents SHALL NOT be modified and the gateway 2132 MAY encapsulate and transmit the frame image without recalculating 2133 the FC CRC. 2135 The frame originator MUST then create and fill in the header and 2136 the SOF and EOF delimiter words as specified in sections 5.3.1 and 2137 5.3.2. 2139 5.3.4 Frame De-encapsulation 2140 iFCP Revision 13 August 2002 2142 The receiving gateway SHALL perform de-encapsulation as follows: 2144 Upon receiving the encapsulated frame, the gateway SHALL check the 2145 header CRC. If the header CRC is valid, the receiving gateway SHALL 2146 check the iFCP flags field. If one of the error conditions in Table 2147 5 is detected, the gateway SHALL handle the error as specified in 2148 section 5.2.3. 2150 +------------------------------+-------------------------+ 2151 | Condition | Error Type | 2152 +==============================+=========================+ 2153 | Header CRC Invalid | Encapsulation error | 2154 +------------------------------+-------------------------+ 2155 | SES = 1, TRP or SPC not 0 | Encapsulation error | 2156 +------------------------------+-------------------------+ 2157 | SES = 0, TRP set incorrectly | Incorrect address mode | 2158 +------------------------------+-------------------------+ 2159 Table 5 -- Encapsulation Header Errors 2161 The receiving gateway SHALL then verify the frame propagation delay 2162 as described in section 8.2.1. If the propagation delay is too 2163 long, the frame SHALL be discarded. Otherwise, the gateway SHALL 2164 check the SOF and EOF in the encapsulation header. A frame SHALL 2165 be discarded if it has an SOF code that is not in Table 3 or an EOF 2166 code that is not in Table 4. 2168 The gateway SHALL then de-encapsulate the frame as follows: 2170 a) Check the FC CRC and discard the frame if the CRC is invalid. 2172 b) If operating in address translation mode, replace the S_ID 2173 field with the N_PORT alias of the frame originator and the D_ID 2174 with the N_PORT ID of the frame recipient. Both parameters 2175 SHALL be obtained from the iFCP session descriptor. 2177 c) If processing a special link service message, replace the frame 2178 with a copy whose payload has been modified as specified in 2179 section 7.1. 2181 The de-encapsulated frame SHALL then be forwarded to the N_PORT 2182 specified in the D_ID field. If the frame contents have been 2183 modified by the receiving gateway, a new FC CRC SHALL be 2184 calculated. 2186 6. TCP Session Control Messages 2188 TCP session control messages are used to create and manage an iFCP 2189 session as described in section 5.2.2. They are passed between peer 2190 iFCP Portals and are only processed within the iFCP layer. 2192 The message format is based on the fibre channel extended link 2193 service message template shown below. 2195 iFCP Revision 13 August 2002 2197 Word 2198 0<--Bits-->7 8<---------------Bits------------------------>31 2199 +------------+------------------------------------------------+ 2200 0| R_CTL | D_ID [0x00 00 00] | 2201 |[Req = 0x22]| [Destination of extended link Service request] | 2202 |[Rep = 0x23]| | 2203 +------------+------------------------------------------------+ 2204 1| CS_CTL | S_ID [0x00 00 00] | 2205 | [0x0] | [Source of extended link service request] | 2206 +------------+------------------------------------------------+ 2207 2|TYPE [0x1] | F_CTL [0] | 2208 +------------+------------------+-----------------------------+ 2209 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | 2210 |[0x0] | | | 2211 +------------+------------------+-----------------------------+ 2212 4| OX_ID [0x0000] | RX_ID_[0x0000] | 2213 +-------------------------------+-----------------------------+ 2214 5| Parameter | 2215 | [ 00 00 00 00 ] | 2216 +-------------------------------------------------------------+ 2217 6| LS_COMMAND | 2218 | [Session Control Command Code] | 2219 +-------------------------------------------------------------+ 2220 7| | 2221 .| Additional Session Control Parameters | 2222 .| ( if any ) | 2223 n| | 2224 +=============================================================+ 2225 n| Fibre Channel CRC | 2226 +| | 2227 1+=============================================================+ 2228 Figure 17 -- Format of Session Control Message 2230 The LS_COMMAND value for the response remains the same as that used 2231 for the request. 2233 The session control frame is terminated with a fibre channel CRC. 2234 The frame SHALL be encapsulated and de-encapsulated according to 2235 the rules specified in section 5.3. 2237 The encapsulation header for the link Service frame carrying a 2238 session control message SHALL be set as follows: 2240 Encapsulation Header Fields: 2242 iFCP Revision 13 August 2002 2244 LS_COMMAND_ACC 0 2246 iFCP Flags SES = 1 2248 TRP = 0 2250 INT = 0 2252 SOF code SOFi3 encoding (0x2E) 2254 EOF code EOFt encoding (0x42) 2256 The encapsulation time stamp words SHALL be set as described for 2257 each message type. 2259 The SOF and EOF delimiter words SHALL be set based on the SOF and 2260 EOF codes specified above. 2262 Table 6 lists the values assigned to byte 0 of the LS_COMMAND field 2263 for iFCP session control messages. 2265 +--------------+-------------------------+----------+-------------+ 2266 | LS_COMMAND | Function | Mnemonic | iFCP | 2267 | field, byte 0| | | Support | 2268 +--------------+-------------------------+----------+-------------+ 2269 | 0xE0 | Connection Bind | CBIND | REQUIRED | 2270 +--------------+-------------------------+----------+-------------+ 2271 | 0xE4 | Unbind Connection | UNBIND | REQUIRED | 2272 +--------------+-------------------------+----------+-------------+ 2273 | 0xE5 | Test Connection Liveness| LTEST | REQUIRED | 2274 +--------------+-------------------------+----------+-------------+ 2275 | 0x01-0x7F | Vendor-specific | | | 2276 +--------------+-------------------------+----------+-------------+ 2277 | 0x00 | Reserved -- Unassignable| | | 2278 +--------------+-------------------------+----------+-------------+ 2279 | All other | Reserved | | | 2280 | values | | | | 2281 +--------------+-------------------------+----------+-------------+ 2282 Table 6 -- Session Control LS_COMMAND Field, Byte 0 Values 2284 6.1 Connection Bind (CBIND) 2286 As described in section 5.2.2.2, the CBIND message and response are 2287 used to bind an N_PORT login to a specific TCP connection and 2288 establish an iFCP session. In the CBIND request message, the 2289 source and destination N_PORTs are identified by their worldwide 2290 port names. The time stamp words in the encapsulation header SHALL 2291 be set to zero in the request and response message frames. 2293 The following shows the format of the CBIND request. 2295 iFCP Revision 13 August 2002 2297 +------+------------+------------+-----------+----------+ 2298 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2299 +------+------------+------------+-----------+----------+ 2300 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2301 +------+------------+------------+-----------+----------+ 2302 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2303 | | (Seconds) | | | 2304 +------+-------------------------+-----------+----------+ 2305 | 2 | USER INFO | 2306 +------+------------+------------+-----------+----------+ 2307 | 3 | | 2308 +------+ SOURCE N_PORT NAME | 2309 | 4 | | 2310 +------+------------------------------------------------+ 2311 | 5 | | 2312 +------+ DESTINATION N_PORT NAME | 2313 | 6 | | 2314 +------+------------------------------------------------+ 2316 Addr Mode: The addressing mode of the originating 2317 gateway. 0 = Address Translation mode, 1 = 2318 Address Transparent mode. 2320 iFCP Ver: iFCP version number. SHALL be set to 1. 2322 LIVENESS TEST If non-zero, requests that the receiving 2323 INTERVAL: gateway transmit an LTEST message at the 2324 specified interval in seconds. If set to 2325 zero, LTEST messages SHALL NOT be sent. 2327 USER INFO: Contains any data desired by the requestor. 2328 This information MUST be echoed by the 2329 recipient in the CBIND response message. 2331 SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the 2332 N_PORT locally attached to the gateway 2333 originating the CBIND request. 2335 DESTINATION N_PORT The Worldwide Port Name (WWPN) of the 2336 NAME: N_PORT locally attached to the gateway 2337 receiving the CBIND request. 2339 The following shows the format of the CBIND response. 2341 iFCP Revision 13 August 2002 2343 +------+------------+------------+-----------+----------+ 2344 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2345 +------+------------+------------+-----------+----------+ 2346 | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | 2347 +------+------------+------------+-----------+----------+ 2348 | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | 2349 | | (Seconds) | | | 2350 +------+-------------------------+-----------+----------+ 2351 | 2 | USER INFO | 2352 +------+------------+------------+-----------+----------+ 2353 | 3 | | 2354 +------+ SOURCE N_PORT NAME | 2355 | 4 | | 2356 +------+------------------------------------------------+ 2357 | 5 | | 2358 +------+ DESTINATION N_PORT NAME | 2359 | 6 | | 2360 +------+-------------------------+----------------------+ 2361 | 7 | Reserved | CBIND Status | 2362 +------+-------------------------+----------------------+ 2363 | 8 | Reserved | CONNECTION HANDLE | 2364 +------+-------------------------+----------------------+ 2365 Total Length = 36 2367 iFCP Revision 13 August 2002 2369 Addr Mode: The address translation mode of the 2370 responding gateway. 0 = Address 2371 Translation mode, 1 = Address Transparent 2372 mode. 2374 iFCP Ver: iFCP version number. Shall be set to 1. 2376 LIVENESS TEST If non-zero, requests that the gateway 2377 INTERVAL: receiving the CBIND RESPONSE transmit an 2378 LTEST message at the specified interval in 2379 seconds. If zero, LTEST messages SHALL NOT 2380 be sent. 2382 USER INFO: Echoes the value received in the USER INFO 2383 field of the CBIND request message. 2385 SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of 2386 the N_PORT locally attached to the gateway 2387 issuing the CBIND request. 2389 DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of 2390 NAME: the N_PORT locally attached to the gateway 2391 issuing the CBIND response. 2393 CBIND STATUS: Indicates success or failure of the CBIND 2394 request. CBIND values are shown below. 2396 CONNECTION HANDLE: Contains a value assigned by the gateway to 2397 identify the connection. The connection 2398 handle is required when issuing the UNBIND 2399 request. 2401 CBIND Status Description 2402 ------------ ----------- 2404 0 Success 2405 1 - 15 Reserved 2406 16 Failed - Unspecified Reason 2407 17 Failed - No such device 2408 18 Failed - iFCP session already exists 2409 19 Failed - Lack of resources 2410 20 Failed - Incompatible address translation mode 2411 21 Failed - Incorrect protocol version number 2412 22 Failed - Gateway not Synchronized (see section 2413 8.2) 2414 Others Reserved 2416 6.2 Unbind Connection (UNBIND) 2417 iFCP Revision 13 August 2002 2419 UNBIND is used to terminate an iFCP session and disassociate the 2420 TCP connection as described in section 5.2.3. 2422 The UNBIND message is transmitted over the connection that is to be 2423 unbound. The time stamp words in the encapsulation header shall be 2424 set to zero in the request and response message frames. 2426 The following is the format of the UNBIND request message. 2428 +------+------------+------------+-----------+----------+ 2429 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2430 +------+------------+------------+-----------+----------+ 2431 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2432 +------+------------+------------+-----------+----------+ 2433 | 1 | USER INFO | 2434 +------+------------+------------+-----------+----------+ 2435 | 2 | Reserved | CONNECTION HANDLE | 2436 +------+------------+------------+----------------------+ 2437 | 3 | Reserved | 2438 +------+------------+------------+-----------+----------+ 2439 | 4 | Reserved | 2440 +------+------------+------------+-----------+----------+ 2442 USER INFO Contains any data desired by the requestor. 2443 This information MUST be echoed by the 2444 recipient in the UNBIND response message. 2446 CONNECTION HANDLE: Contains the gateway-assigned value from 2447 the CBIND request. 2449 The following shows the format of the UNBIND response message. 2451 +------+------------+------------+-----------+----------+ 2452 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2453 +------+------------+------------+-----------+----------+ 2454 | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | 2455 +------+------------+------------+-----------+----------+ 2456 | 1 | USER INFO | 2457 +------+------------+------------+-----------+----------+ 2458 | 2 | Reserved | CONNECTION HANDLE | 2459 +------+------------+------------+-----------+----------+ 2460 | 3 | Reserved | 2461 +------+------------+------------+-----------+----------+ 2462 | 4 | Reserved | 2463 +------+------------+------------+-----------+----------+ 2464 | 5 | Reserved | UNBIND STATUS | 2465 +------+------------+------------+-----------+----------+ 2467 iFCP Revision 13 August 2002 2469 USER INFO Echoes the value received in the USER INFO 2470 field of the UNBIND request message. 2472 CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in 2473 the UNBIND request message. 2475 UNBIND STATUS: Indicates the success or failure of the 2476 UNBIND request as follows: 2478 Unbind Status Description 2479 ------------- ----------- 2481 0 Successful - No other status 2482 1 - 15 Reserved 2483 16 Failed - Unspecified Reason 2484 18 Failed - Connection ID Invalid 2485 Others Reserved 2487 6.3 LTEST -- Test Connection Liveness 2489 The LTEST message is sent at the interval specified in the CBIND 2490 request or response payload. The LTEST encapsulation time stamp 2491 SHALL be set as described in section 8.2.1 and may be used by the 2492 receiver to compute an estimate of propagation delay. However, the 2493 propagation delay limit SHALL NOT be enforced. 2495 iFCP Revision 13 August 2002 2497 +------+------------+------------+-----------+----------+ 2498 | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | 2499 +------+------------+------------+-----------+----------+ 2500 | 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 | 2501 +------+------------+------------+-----------+----------+ 2502 | 1 | LIVENESS TEST INTERVAL | Reserved | 2503 | | (Seconds) | | 2504 +------+-------------------------+----------------------+ 2505 | 2 | COUNT | 2506 +------+------------+------------+-----------+----------+ 2507 | 3 | | 2508 +------+ SOURCE N_PORT NAME | 2509 | 4 | | 2510 +------+------------------------------------------------+ 2511 | 5 | | 2512 +------+ DESTINATION N_PORT NAME | 2513 | 6 | | 2514 +------+------------------------------------------------+ 2516 LIVENESS TEST Copy of the LIVENESS TEST INTERVAL 2517 INTERVAL: specified in the CBIND request or reply 2518 message. 2520 COUNT: Monotonically increasing value, initialized 2521 to 0 and incremented by one for each 2522 successive LTEST message. 2524 SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME 2525 specified in the CBIND request. 2527 DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT 2528 NAME: NAME specified in the CBIND request. 2530 7. Fibre Channel Link Services 2532 Link services provide a set of fibre channel functions that allow a 2533 port to send control information or request another port to perform 2534 a specific control function. 2536 There are three types of link services: 2538 a) Basic 2540 b) Extended 2542 c) ULP-specific (FC-4) 2544 Each link service message (request and reply) is carried by a fibre 2545 channel sequence, and can be segmented into multiple frames. 2547 iFCP Revision 13 August 2002 2549 The iFCP Layer is responsible for transporting link service 2550 messages across the IP network. This includes mapping Link Service 2551 messages appropriately from the domain of the fibre channel 2552 transport to that of the IP network. This process may require 2553 special processing and the inclusion of supplemental data by the 2554 iFCP layer. 2556 Each link service MUST be processed according to one of the 2557 following rules: 2559 a) Pass-through - The link service message and reply MUST be 2560 delivered to the receiving N_PORT by the iFCP protocol layer 2561 without altering the message payload. The link service message 2562 and reply are not processed by the iFCP protocol layer. 2564 b) Special - Applies to a link service reply or request requiring 2565 the intervention of the iFCP layer before forwarding to the 2566 destination N_PORT. Such messages may contain fibre channel 2567 addresses in the payload or may require other special 2568 processing. 2570 c) Rejected - When issued by a locally attached N_PORT, the 2571 specified link service request MUST be rejected by the iFCP 2572 gateway. The gateway SHALL return an LS_RJT response with a 2573 Reason Code of 0x0B (Command Not Supported) and a Reason Code 2574 Explanation of 0x0 (No Additional Explanation). 2576 This section describes the processing for special link services, 2577 including the manner in which supplemental data is added to the 2578 message payload. 2580 Appendix A enumerates all link services and the iFCP processing 2581 policy that applies to each. 2583 7.1 Special Link Service Messages 2585 Special link service messages require the intervention of the iFCP 2586 layer before forwarding to the destination N_PORT. Such 2587 intervention is required in order to: 2589 a) Service any link service message that requires special handling, 2590 such as a PLOGI. 2592 b) In address translation mode only, service any link service 2593 message that has an N_PORT address in the payload. 2595 Unless otherwise specified in the link service description, support 2596 for each special link service is MANDATORY. 2598 Such messages SHALL be transmitted in a fibre channel frame having 2599 the format shown in Figure 18 for extended link services or Figure 2600 19 for FC-4 link services. 2602 iFCP Revision 13 August 2002 2604 Word 2605 0<---Bit-->7 8<-------------------------------------------->31 2606 +------------+------------------------------------------------+ 2607 0| R_CTL | D_ID | 2608 |[Req = 0x22]|[Destination of extended link Service request] | 2609 |[Rep = 0x23]| | 2610 +------------+------------------------------------------------+ 2611 1| CS_CTL | S_ID | 2612 | | [Source of extended link service request] | 2613 +------------+------------------------------------------------+ 2614 2| TYPE | F_CTL | 2615 | [0x01] | | 2616 +------------+------------------+-----------------------------+ 2617 3| SEQ_ID | DF_CTL | SEQ_CNT | 2618 +------------+------------------+-----------------------------+ 2619 4| OX_ID | RX_ID | 2620 +-------------------------------+-----------------------------+ 2621 5| Parameter | 2622 | [ 00 00 00 00 ] | 2623 +-------------------------------------------------------------+ 2624 6| LS_COMMAND | 2625 | [Extended Link Service Command Code] | 2626 +-------------==----------------------------------------------+ 2627 7| | 2628 .| Additional Service Request Parameters | 2629 .| ( if any ) | 2630 n| | 2631 +-------------------------------------------------------------+ 2632 Figure 18 -- Format of an Extended Link Service Frame 2634 iFCP Revision 13 August 2002 2636 Word 2637 0<---Bit-->7 8<-------------------------------------------->31 2638 +------------+------------------------------------------------+ 2639 0| R_CTL | D_ID | 2640 |[Req = 0x32]| [Destination of FC-4 link Service request] | 2641 |[Rep = 0x33]| | 2642 +------------+------------------------------------------------+ 2643 1| CS_CTL | S_ID | 2644 | | [Source of FC-4 link service request] | 2645 +------------+------------------------------------------------+ 2646 2| TYPE | F_CTL | 2647 | (FC-4 | | 2648 | specific) | | 2649 +------------+------------------+-----------------------------+ 2650 3| SEQ_ID | DF_CTL | SEQ_CNT | 2651 +------------+------------------+-----------------------------+ 2652 4| OX_ID | RX_ID | 2653 +-------------------------------+-----------------------------+ 2654 5| Parameter | 2655 | [ 00 00 00 00 ] | 2656 +-------------------------------------------------------------+ 2657 6| LS_COMMAND | 2658 | [FC-4 Link Service Command Code] | 2659 +-------------------------------------------------------------+ 2660 7| | 2661 .| Additional Service Request Parameters | 2662 .| ( if any ) | 2663 n| | 2664 +-------------------------------------------------------------+ 2665 Figure 19 -- Format of an FC-4 Link Service Frame 2667 7.2 Link Services Requiring Payload Address Translation 2669 This section describes the handling for link service frames 2670 containing N_PORT addresses in the frame payload. Such addresses 2671 SHALL only be translated when the gateway is operating in address 2672 translation mode. When operating in address transparent mode, 2673 these addresses SHALL NOT be translated and such link service 2674 messages SHALL NOT be sent as special frames unless other 2675 processing by the iFCP layer is required. 2677 Supplemental data includes information required by the receiving 2678 gateway to convert an N_PORT address in the payload to an N_PORT 2679 address in the receiving gateway�s address space. The following 2680 rules define the manner in which such supplemental data shall be 2681 packaged and referenced. 2683 For an N_PORT address field, the gateway originating the frame MUST 2684 set the value in the payload to identify the address translation 2685 type as follows: 2687 iFCP Revision 13 August 2002 2689 0x00 00 01 - The gateway receiving the frame from the IP 2690 network MUST replace the contents of the field with the N_PORT 2691 alias of the frame originator. This translation type MUST be 2692 used when the address to be converted is that of the source 2693 N_PORT. 2695 0x00 00 02 - The gateway receiving the frame from the IP 2696 network MUST replace the contents of the field with the N_PORT 2697 ID of the destination N_PORT. This translation type MUST be 2698 used when the address to be converted is that of the 2699 destination N_PORT 2701 0x00 00 03 - The gateway receiving the frame from the IP 2702 network MUST reference the specified supplemental data to set 2703 the field contents. The supplemental information is the 64-bit 2704 world wide identifier of the N_PORT as set forth in the fibre 2705 channel specification [FC-FS]. If not otherwise part of the 2706 link service payload, this information MUST be appended in 2707 accordance with the applicable link service description. Unless 2708 specified otherwise, this translation type SHALL NOT be used if 2709 the address to be converted corresponds to that of the frame 2710 originator or recipient. 2712 Since fibre channel addressing rules prohibit the assignment of 2713 fabric addresses with a domain ID of 0, the above codes will never 2714 correspond to valid N_PORT fabric IDs. 2716 If the sending gateway cannot obtain the worldwide identifier of an 2717 N_PORT, the gateway SHALL terminate the request with an LS_RJT 2718 message as described in [FC-FS]. The Reason Code SHALL be set to 2719 0x07 (protocol error) and the Reason Explanation SHALL be set to 2720 0x1F (Invalid N_PORT identifier). 2722 Supplemental data is sent with the link service request or ACC 2723 frames in one of the following ways: 2725 a) By appending the necessary data to the end of the link service 2726 frame. 2728 b) By extending the sequence with additional frames. 2730 In the first case, a new frame SHALL be created whose length 2731 includes the supplemental data. The procedure for extending the 2732 link service sequence with additional frames is dependent on the 2733 link service type. 2735 For each field requiring address translation, the receiving gateway 2736 SHALL reference the translation type encoded in the field and 2737 replace it with the N_PORT address as shown in Table 7: 2739 iFCP Revision 13 August 2002 2741 +------------------+------------------------------------+ 2742 | Translation | N_PORT Translation | 2743 | Type Code | | 2744 +------------------+------------------------------------+ 2745 | 0x00 00 01 | Replace field contents with N_PORT | 2746 | | alias of frame originator. | 2747 +------------------+------------------------------------+ 2748 | 0x00 00 02 | Replace field contents with N_PORT | 2749 | | ID of frame recipient. | 2750 +------------------+------------------------------------+ 2751 | | Lookup N_PORT via iSNS query. | 2752 | | If locally attached, replace with | 2753 | 0x00 00 03 | N_PORT ID. | 2754 | | If remotely attached, replace with | 2755 | | N_PORT alias from remote N_PORT . | 2756 | | descriptor (see section 5.2.2.1). | 2757 +------------------+------------------------------------+ 2758 Table 7 -- Link Service Address Translation 2760 For translation type 3, the receiving gateway SHALL obtain the 2761 information needed to fill in the field in the link service frame 2762 payload by converting the specified N_PORT worldwide identifier to 2763 a gateway IP address and N_PORT ID. This information MUST be 2764 obtained through an iSNS name server query. If the query is 2765 unsuccessful, the gateway SHALL terminate the request with an 2766 LS_RJT response message as described in [FC-FS]. The Reason Code 2767 SHALL be set to 0x07 (protocol error) and the Reason Explanation 2768 SHALL be set to 0x1F (Invalid N_PORT identifier). 2770 After applying the supplemental data, the receiving gateway SHALL 2771 forward the resulting link service frames to the destination N_PORT 2772 with the supplemental information removed. 2774 7.3 Fibre Channel Link Services Processed by iFCP 2776 The following Extended and FC-4 Link Service Messages must receive 2777 special processing. 2779 iFCP Revision 13 August 2002 2781 Extended Link Service LS_COMMAND Mnemonic 2782 Messages ---------- -------- 2783 ---------------------- 2784 Abort Exchange 0x06 00 00 00 ABTX 2785 Discover Address 0x52 00 00 00 ADISC 2786 Discover Address Accept 0x02 00 00 00 ADISC ACC 2787 FC Address Resolution 0x55 00 00 00 FARP-REPLY 2788 Protocol Reply 2789 FC Address Resolution 0x54 00 00 00 FARP-REQ 2790 Protocol Request 2791 Logout 0x05 00 00 00 LOGO 2792 Port Login 0x30 00 00 00 PLOGI 2793 Read Exchange Status Block 0x08 00 00 00 RES 2794 Read Exchange Status Block 0x02 00 00 00 RES ACC 2795 Accept 2796 Read Link Error Status 0x0F 00 00 00 RLS 2797 Block 2798 Read Sequence Status Block 0x09 00 00 00 RSS 2799 Reinstate Recovery 0x12 00 00 00 RRQ 2800 Qualifier 2801 Request Sequence 0x0A 00 00 00 RSI 2802 Initiative 2803 Scan Remote Loop 0x7B 00 00 00 SRL 2804 Third Party Process Logout 0x24 00 00 00 TPRLO 2805 Third Party Process Logout 0x02 00 00 00 TPRLO ACC 2806 Accept 2808 FC-4 Link Service Messages LS_COMMAND Mnemonic 2809 -------------------------- ---------- -------- 2810 FCP Read Exchange Concise 0x13 00 00 00 REC 2811 FCP Read Exchange Concise 0x02 00 00 00 REC ACC 2812 Accept 2814 Each encapsulated fibre channel frame that is part of a special 2815 link service MUST have the SPC bit set to one in the iFCP FLAGS 2816 field of the encapsulation header as specified in section 5.3.1. 2817 If an ACC link service response requires special processing, the 2818 responding gateway SHALL place a copy of LS_COMMAND bits 0 through 2819 7 from the link service request frame in the LS_COMMAND_ACC field 2820 of the ACC encapsulation header. Supplemental data (if any) MUST be 2821 appended as described in the following section. 2823 The format of each special link service message, including 2824 supplemental data where applicable, is shown in the following 2825 sections. Each description shows the basic format, as specified in 2826 the applicable FC standard, followed by supplemental data as shown 2827 in the example below. 2829 iFCP Revision 13 August 2002 2831 +------+------------+------------+-----------+----------+ 2832 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2833 +------+------------+------------+-----------+----------+ 2834 | 0 | LS_COMMAND | 2835 +------+------------+------------+-----------+----------+ 2836 | 1 | | 2837 | . | | 2838 | . | Link Service Frame Payload | 2839 | | | 2840 | n | | 2841 +======+============+============+===========+==========+ 2842 | n+1 | | 2843 | . | Supplemental Data | 2844 | . | (if any) | 2845 | n+k | | 2846 +======+================================================+ 2847 Figure 20 -- Special Link Service Frame Payload 2849 7.3.1 Special Extended Link Services 2851 The following sections define extended link services for which 2852 special processing is required. 2854 7.3.1.1 Abort Exchange (ABTX) 2856 ELS Format: 2858 +------+------------+------------+-----------+----------+ 2859 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2860 +------+------------+------------+-----------+----------+ 2861 | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | 2862 +------+------------+------------+-----------+----------+ 2863 | 1 | RRQ Status | Exchange Originator S_ID | 2864 +------+------------+------------+-----------+----------+ 2865 | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| 2866 +------+------------+------------+-----------+----------+ 2867 | 3-10 | Optional association header (32 bytes | 2868 +======+============+============+===========+==========+ 2870 Fields Requiring Translation Supplemental Data 2871 Address Translation Type (see (type 3 only) 2872 ------------------- section 7.2) ------------ 2873 ----------- 2875 Exchange Originator 1, 2 N/A 2876 S_ID 2878 Other Special Processing: 2880 iFCP Revision 13 August 2002 2882 None 2884 7.3.1.2 Discover Address (ADISC) 2886 Format of ADISC ELS: 2888 +------+------------+------------+-----------+----------+ 2889 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2890 +------+------------+------------+-----------+----------+ 2891 | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | 2892 +------+------------+------------+-----------+----------+ 2893 | 1 | Reserved | Hard address of ELS Originator | 2894 +------+------------+------------+-----------+----------+ 2895 | 2-3 | Port Name of Originator | 2896 +------+------------+------------+-----------+----------+ 2897 | 4-5 | Node Name of originator | 2898 +------+------------+------------+-----------+----------+ 2899 | 6 | Rsvd | N_PORT ID of ELS Originator | 2900 +======+============+============+===========+==========+ 2902 Fields Requiring Translation Supplemental Data 2903 Address Translation Type (see (type 3 only) 2904 ------------------- section 7.2) ------------ 2905 ------------- 2907 N_PORT ID of ELS 1 N/A 2908 Originator 2910 Other Special Processing: 2912 The Hard Address of the ELS originator SHALL be set to 0. 2914 7.3.1.3 Discover Address Accept (ADISC ACC) 2916 Format of ADISC ACC ELS: 2918 iFCP Revision 13 August 2002 2920 +------+------------+------------+-----------+----------+ 2921 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2922 +------+------------+------------+-----------+----------+ 2923 | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | 2924 +------+------------+------------+-----------+----------+ 2925 | 1 | Reserved | Hard address of ELS Originator | 2926 +------+------------+------------+-----------+----------+ 2927 | 2-3 | Port Name of Originator | 2928 +------+------------+------------+-----------+----------+ 2929 | 4-5 | Node Name of originator | 2930 +------+------------+------------+-----------+----------+ 2931 | 6 | Rsvd | N_PORT ID of ELS Originator | 2932 +======+============+============+===========+==========+ 2934 Fields Requiring Translation Supplemental Data 2935 Address Translation Type (see (type 3 only) 2936 ------------------- section 7.2) ------------ 2937 ------------ 2939 N_PORT ID of ELS 1 N/A 2940 Originator 2942 Other Special Processing: 2944 The Hard Address of the ELS originator SHALL be set to 0. 2946 7.3.1.4 FC Address Resolution Protocol Reply (FARP-REPLY) 2948 The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS 2949 (see section 7.3.1.5) to perform the address resolution services 2950 required by the FC-VI protocol [FC-VI] and the fibre channel 2951 mapping of IP and ARP specified in RFC 2625 [RFC2625]. 2953 Format of FARP-REPLY ELS: 2955 iFCP Revision 13 August 2002 2957 +------+------------+------------+-----------+----------+ 2958 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 2959 +------+------------+------------+-----------+----------+ 2960 | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | 2961 +------+------------+------------+-----------+----------+ 2962 | 1 | Match Addr | Requesting N_PORT Identifier | 2963 | | Code Points| | 2964 +------+------------+------------+-----------+----------+ 2965 | 2 | Responder | Responding N_PORT Identifier | 2966 | | Action | | 2967 +------+------------+------------+-----------+----------+ 2968 | 3-4 | Requesting N_PORT Port_Name | 2969 +------+------------+------------+-----------+----------+ 2970 | 5-6 | Requesting N_PORT Node_Name | 2971 +------+------------+------------+-----------+----------+ 2972 | 7-8 | Responding N_PORT Port_Name | 2973 +------+------------+------------+-----------+----------+ 2974 | 9-10 | Responding N_PORT Node_Name | 2975 +------+------------+------------+-----------+----------+ 2976 | 11-14| Requesting N_PORT IP Address | 2977 +------+------------+------------+-----------+----------+ 2978 | 15-18| Responding N_PORT IP Address | 2979 +======+============+============+===========+==========+ 2981 Fields Requiring Translation Supplemental Data 2982 Address Translation Type (see (type 3 only) 2983 ------------------- section 7.2) ----------------- 2984 ------------- 2986 Requesting N_PORT 2 N/A 2987 Identifier 2989 Responding N_PORT 1 N/A 2990 identifier 2992 Other Special Processing: 2994 None. 2996 7.3.1.5 FC Address Resolution Protocol Request (FARP-REQ) 2998 The FARP-REQ ELS is used to in conjunction with the FC-VI protocol 2999 [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP 3000 and FC address resolution in an FC fabric. The FARP-REQ ELS is 3001 usually directed to the fabric broadcast server at well-known 3002 address 0xFF-FF-FF for retransmission to all attached N_PORTs. 3004 iFCP Revision 13 August 2002 3006 Section 9.4 describes the iFCP implementation of FC broadcast 3007 server functionality in an iFCP fabric. 3009 Format of FARP_REQ ELS: 3011 +------+------------+------------+-----------+----------+ 3012 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3013 +------+------------+------------+-----------+----------+ 3014 | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | 3015 +------+------------+------------+-----------+----------+ 3016 | 1 | Match Addr | Requesting N_PORT Identifier | 3017 | | Code Points| | 3018 +------+------------+------------+-----------+----------+ 3019 | 2 | Responder | Responding N_PORT Identifier | 3020 | | Action | | 3021 +------+------------+------------+-----------+----------+ 3022 | 3-4 | Requesting N_PORT Port_Name | 3023 +------+------------+------------+-----------+----------+ 3024 | 5-6 | Requesting N_PORT Node_Name | 3025 +------+------------+------------+-----------+----------+ 3026 | 7-8 | Responding N_PORT Port_Name | 3027 +------+------------+------------+-----------+----------+ 3028 | 9-10 | Responding N_PORT Node_Name | 3029 +------+------------+------------+-----------+----------+ 3030 | 11-14| Requesting N_PORT IP Address | 3031 +------+------------+------------+-----------+----------+ 3032 | 15-18| Responding N_PORT IP Address | 3033 +======+============+============+===========+==========+ 3035 Fields Requiring Translation Supplemental Data 3036 Address Translation Type (see (type 3 only) 3037 ------------------- section 7.2) ----------------- 3038 ----------- 3040 Requesting N_PORT 3 Requesting N_PORT 3041 Identifier Port Name 3043 Responding N_PORT 3 Responding N_PORT 3044 Identifier Port Name 3046 Other Special Processing: 3048 None. 3050 7.3.1.6 Logout (LOGO) and LOGO ACC 3052 ELS Format: 3054 iFCP Revision 13 August 2002 3056 +------+------------+------------+-----------+----------+ 3057 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3058 +------+------------+------------+-----------+----------+ 3059 | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | 3060 +------+------------+------------+-----------+----------+ 3061 | 1 | Rsvd | N_PORT ID being logged out | 3062 +------+------------+------------+-----------+----------+ 3063 | 2-3 | Port name of the LOGO originator (8 bytes) | 3064 +======+============+============+===========+==========+ 3066 This ELS SHALL always be sent as a special ELS regardless of the 3067 translation mode in effect. 3069 Fields Requiring Translation Supplemental Data 3070 Address Translation Type(see (type 3 only) 3071 ------------------- section 7.2) -------------- 3072 ----------- 3074 N_PORT ID Being 1 N/A 3075 Logged Out 3077 Other Special Processing: 3079 See section 5.2.3. 3081 7.3.1.7 Port Login (PLOGI) and PLOGI ACC 3083 A PLOGI ELS establishes fibre channel communications between two 3084 N_PORTs and triggers the creation of an iFCP session if one does 3085 not exist. 3087 The PLOGI request and ACC response carry information identifying 3088 the originating N_PORT, including a specification of its 3089 capabilities. If the destination N_PORT accepts the login request, 3090 it sends an Accept response (an ACC frame with PLOGI payload), 3091 specifying its capabilities. This exchange establishes the 3092 operating environment for the two N_PORTs. 3094 The following figure is duplicated from [FC-FS], and shows the 3095 PLOGI message format for both the request and Accept (ACC) 3096 response. An N_PORT will reject a PLOGI request by transmitting an 3097 LS_RJT message containing no payload. 3099 iFCP Revision 13 August 2002 3101 +------+------------+------------+-----------+----------+ 3102 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3103 +------+------------+------------+-----------+----------+ 3104 | 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 | 3105 | | Acc = 0x2 | | | | 3106 +------+------------+------------+-----------+----------+ 3107 | 1-4 | Common Service Parameters | 3108 +------+------------+------------+-----------+----------+ 3109 | 5-6 | N_PORT Name | 3110 +------+------------+------------+-----------+----------+ 3111 | 7-8 | Node Name | 3112 +------+------------+------------+-----------+----------+ 3113 | 9-12 | Class 1 Service Parameters | 3114 +------+------------+------------+-----------+----------+ 3115 |13-17 | Class 2 Service Parameters | 3116 +------+------------+------------+-----------+----------+ 3117 |18-21 | Class 3 Service Parameters | 3118 +------+------------+------------+-----------+----------+ 3119 |22-25 | Class 4 Service Parameters | 3120 +------+------------+------------+-----------+----------+ 3121 |26-29 | Vendor Version Level | 3122 +======+============+============+===========+==========+ 3123 Figure 21 -- Format of PLOGI Request and ACC Payloads 3125 Details of the above fields, including common and class-based 3126 service parameters, can be found in [FC-FS]. 3128 Special Processing 3130 As specified in section 5.2.2.2, a PLOGI request addressed to a 3131 remotely attached N_PORT MUST cause the creation of an iFCP 3132 session if one does not exist. Otherwise, the PLOGI and PLOGI 3133 ACC payloads MUST be passed through without modification to the 3134 destination N_PORT using the existing iFCP session. In either 3135 case, the SPC bit must be set in the frame encapsulation header 3136 as specified in 5.3.3. 3138 If the CBIND to create the iFCP session fails, the issuing 3139 gateway SHALL terminate the PLOGI with an LS_RJT response. The 3140 Reason Code and Reason Code Explanation SHALL be selected from 3141 Table 8 based on the CBIND failure status. 3143 iFCP Revision 13 August 2002 3145 +---------------+-------------------+---------------------+ 3146 | CBIND Failure | LS_RJT Reason | LS_RJT Reason Code | 3147 | Status | Code | Explanation | 3148 +===============+===================+=====================+ 3149 | Unspecified | Unable to Perform | No additional | 3150 | Reason (16) | Command Request | explanation (0x00) | 3151 | | (0x09) | | 3152 +---------------+-------------------+---------------------+ 3153 | No Such | Unable to Perform | Invalid N_PORT | 3154 | Device (17) | Command Request | Name (0x0D) | 3155 | | (0x09) | | 3156 +---------------+-------------------+---------------------+ 3157 | Lack of | Unable to Perform | Insufficient | 3158 | Resources (19)| Command Request | Resources to Support| 3159 | | (0x09) | Login (0x29) | 3160 +---------------+-------------------+---------------------+ 3161 | Incompatible | Unable to Perform | No additional | 3162 | Address | Command Request | explanation (0x00) | 3163 | Translation | (0x09) | | 3164 | Mode (20) | | | 3165 +---------------+-------------------+---------------------+ 3166 | Incorrect iFCP| Unable to Perform | No additional | 3167 | Protocol | Command Request | explanation (0x00) | 3168 | version number| (0x09) | | 3169 | (21) | | | 3170 +---------------+-------------------+---------------------+ 3171 | Gateway not | Unable to Perform | No additional | 3172 | Synchronized | Command Request | explanation (0x00) | 3173 | (22) | (0x09) | | 3174 +---------------+-------------------+---------------------+ 3175 Table 8 -- PLOGI LS_RJT Status for CBIND Failures 3177 7.3.1.8 Read Exchange Status Block (RES) 3179 ELS Format: 3181 +------+------------+------------+-----------+----------+ 3182 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3183 +------+------------+------------+-----------+----------+ 3184 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3185 +------+------------+------------+-----------+----------+ 3186 | 1 | Rsvd | Exchange Originator S_ID | 3187 +------+------------+------------+-----------+----------+ 3188 | 2 | OX_ID | RX_ID | 3189 +------+------------+------------+-----------+----------+ 3190 | 3-10 | Association header (may be optionally req�d) | 3191 +======+============+============+===========+==========+ 3192 | 11-12| Port name of the Exchange Originator (8 bytes) | 3193 +======+============+============+===========+==========+ 3195 iFCP Revision 13 August 2002 3197 Fields Requiring Translation Supplemental Data 3198 Address Translation Type(see (type 3 only) 3199 ------------------- section 7.2) ------------------ 3200 ----------- 3202 Exchange Originator 1, 2 or 3 Port Name of the 3203 S_ID Exchange Originator 3205 Other Special Processing: 3207 None. 3209 7.3.1.9 Read Exchange Status Block Accept (RES ACC) 3211 Format of ELS Accept Response: 3213 +------+------------+------------+-----------+----------+ 3214 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3215 +------+------------+------------+-----------+----------+ 3216 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3217 +------+------------+------------+-----------+----------+ 3218 | 1 | OX_ID | RX_ID | 3219 +------+------------+------------+-----------+----------+ 3220 | 2 | Rsvd | Exchange Originator N_PORT ID | 3221 +------+------------+------------+-----------+----------+ 3222 | 3 | Rsvd | Exchange Responder N_PORT ID | 3223 +------+------------+------------+-----------+----------+ 3224 | 4 | Exchange Status Bits | 3225 +------+------------+------------+-----------+----------+ 3226 | 5 | Reserved | 3227 +------+------------+------------+-----------+----------+ 3228 | 6-n | Service Parameters and Sequence Statuses | 3229 | | as described in [FCS] | 3230 +======+============+============+===========+==========+ 3231 |n+1- | Port name of the Exchange Originator (8 bytes) | 3232 |n+2 | | 3233 +======+============+============+===========+==========+ 3234 |n+3- | Port name of the Exchange Responder (8 bytes) | 3235 |n+4 | | 3236 +======+============+============+===========+==========+ 3238 iFCP Revision 13 August 2002 3240 Fields Requiring Translation Supplemental Data 3241 Address Translation Type(see (type 3 only) 3242 ------------------- section 7.2) ------------------ 3243 ----------- 3245 Exchange Originator 1, 2 or 3 Port Name of the 3246 N_PORT ID Exchange Originator 3248 Exchange Responder 1, 2 or 3 Port Name of the 3249 N_PORT ID Exchange Responder 3251 When supplemental data is required, the ELS SHALL be extended by 4 3252 words as shown above. If the translation type for the Exchange 3253 Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, 3254 the corresponding 8-byte port name SHALL be set to all zeros. 3256 Other Special Processing: 3258 None. 3260 7.3.1.10 Read Link Error Status (RLS) 3262 ELS Format: 3264 +------+------------+------------+-----------+----------+ 3265 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3266 +------+------------+------------+-----------+----------+ 3267 | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | 3268 +------+------------+------------+-----------+----------+ 3269 | 1 | Rsvd | N_PORT Identifier | 3270 +======+============+============+===========+==========+ 3271 | 2-3 | Port name of the N_PORT (8 bytes) | 3272 +======+============+============+===========+==========+ 3274 Fields Requiring Translation Supplemental Data (type 3275 Address Translation Type(see 3 only) 3276 ------------------- section 7.2) ------------------ 3277 ----------- 3279 N_PORT Identifier 1, 2 or 3 Port Name of the N_PORT 3281 Other Special Processing: 3283 None. 3285 7.3.1.11 Read Sequence Status Block (RSS) 3287 ELS Format: 3289 iFCP Revision 13 August 2002 3291 +------+------------+------------+-----------+----------+ 3292 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3293 +------+------------+------------+-----------+----------+ 3294 | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | 3295 +------+------------+------------+-----------+----------+ 3296 | 1 | SEQ_ID | Exchange Originator S_ID | 3297 +------+------------+------------+-----------+----------+ 3298 | 2 | OX_ID | RX_ID | 3299 +======+============+============+===========+==========+ 3300 | 3-4 |Port name of the Exchange Originator (8 bytes) | 3301 +======+============+============+===========+==========+ 3303 Fields Requiring Translation Supplemental Data 3304 Address Translation Type(see (type 3 only) 3305 ------------------- section 7.2) ------------------ 3306 ----------- 3308 Exchange Originator 1, 2 or 3 Port Name of the 3309 S_ID Exchange Originator 3311 Other Special Processing: 3313 None. 3315 7.3.1.12 Reinstate Recovery Qualifier (RRQ) 3317 ELS Format: 3319 +------+------------+------------+-----------+----------+ 3320 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3321 +------+------------+------------+-----------+----------+ 3322 | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | 3323 +------+------------+------------+-----------+----------+ 3324 | 1 | Rsvd | Exchange Originator S_ID | 3325 +------+------------+------------+-----------+----------+ 3326 | 2 | OX_ID | RX_ID | 3327 +------+------------+------------+-----------+----------+ 3328 | 3-10 | Association header (may be optionally req�d) | 3329 +======+============+============+===========+==========+ 3331 Fields Requiring Translation Supplemental Data 3332 Address Translation Type(see (type 3 only) 3333 ------------------- section 7.2) ------------------ 3334 ----------- 3336 Exchange Originator 1 or 2 N/A 3337 S_ID 3339 iFCP Revision 13 August 2002 3341 Other Special Processing: 3343 None. 3345 7.3.1.13 Request Sequence Initiative (RSI) 3347 ELS Format: 3349 +------+------------+------------+-----------+----------+ 3350 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3351 +------+------------+------------+-----------+----------+ 3352 | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | 3353 +------+------------+------------+-----------+----------+ 3354 | 1 | Rsvd | Exchange Originator S_ID | 3355 +------+------------+------------+-----------+----------+ 3356 | 2 | OX_ID | RX_ID | 3357 +------+------------+------------+-----------+----------+ 3358 | 3-10 | Association header (may be optionally req�d) | 3359 +======+============+============+===========+==========+ 3361 Fields Requiring Translation Supplemental Data 3362 Address Translation Type(see (type 3 only) 3363 ------------------- section 7.2) ------------------ 3364 ----------- 3366 Exchange Originator 1 or 2 N/A 3367 S_ID 3369 Other Special Processing: 3371 None. 3373 7.3.1.14 Scan Remote Loop (SRL) 3375 SRL allows a remote loop to be scanned to detect changes in the 3376 device configuration. Any changes will trigger a fibre channel 3377 state change notification and subsequent update of the iSNS 3378 database. 3380 ELS Format: 3382 iFCP Revision 13 August 2002 3384 +------+------------+------------+-----------+----------+ 3385 | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| 3386 +------+------------+------------+-----------+----------+ 3387 | 0 | Cmd = 0x7B | Reserved | 3388 +------+------------+------------+-----------+----------+ 3389 | 1 | Flag | Address Identifier of the FL_PORT | 3390 | | | (see B.1) | 3391 +======+============+============+===========+==========+ 3392 | 2-3 | World-Wide Name of the Remote FL_PORT | 3393 +======+============+============+===========+==========+ 3395 Fields Requiring Translation Supplemental Data 3396 Address Translation Type(see (type 3 only) 3397 ------------------- section 7.2) ------------------ 3398 ----------- 3400 Address Identifier 3 World-Wide Name of 3401 of the FL_PORT the remote FL_PORT 3403 Other Special Processing: 3405 The D_ID field is the address of the Domain Controller associated 3406 with the remote loop. The format of the Domain Controller address 3407 is hex �FF FC' || Domain_ID, where Domain_ID is the gateway- 3408 assigned alias representing. the remote gateway or switch element 3409 being queried. The D_ID after translation by the remote gateway 3410 identifies the gateway or switch element to be scanned within the 3411 remote gateway region. 3413 The FLAG field defines the scope of the SRL. If set to 0, all loop 3414 port interfaces on the given switch element or gateway are scanned. 3415 If set to one, the loop port interface on the gateway or switch 3416 element to be scanned MUST be specified in bits 8 through 31. 3418 If the Flag field is zero the SRL request SHALL NOT be sent as a 3419 special ELS. 3421 If the Domain_ID represents a remote switch or gateway and an iFCP 3422 session to the remote Domain Controller does not exist, the 3423 requesting gateway SHALL create the iFCP session. 3425 7.3.1.15 Third Party Process Logout (TPRLO) 3427 TPRLO provides a mechanism for an N_PORT (third party) to remove 3428 one or more process login sessions that exist between the 3429 destination N_PORT and other N_PORTs specified in the command. 3430 This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, 3431 each of which when combined with the destination N_PORT identifies 3432 a process login to be terminated by the command. 3434 iFCP Revision 13 August 2002 3436 +--------+------------+--------------------+----------------------+ 3437 | Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 | 3438 +--------+------------+--------------------+----------------------+ 3439 | 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length | 3440 +--------+------------+--------------------+----------------------+ 3441 | 1 | TPRLO Logout Parameter Page 0 | 3442 +--------+--------------------------------------------------------+ 3443 | 5 | TPRLO Logout Parameter Page 1 | 3444 +--------+--------------------------------------------------------+ 3445 .... 3446 +--------+--------------------------------------------------------+ 3447 |(4*n)+1 | TPRLO Logout Parameter page n | 3448 +--------+--------------------------------------------------------+ 3449 Figure 22 -- Format of TPRLO ELS 3451 Each TPRLO parameter page contains parameters identifying one or 3452 more image pairs and may be associated with a single FC-4 protocol 3453 type, common to all FC-4 protocol types between the specified image 3454 pair, or global to all specified image pairs. The format of a TPRLO 3455 page requiring address translation is shown in Figure 23. 3456 Additional information on TPRLO can be found in [FC-FS]. 3458 +------+------------+------------+-----------+----------+ 3459 | Word | Bits 0-7 | Bits 8-15 | Bits 16-31 | 3460 +------+------------+------------+-----------+----------+ 3461 | 0 | TYPE Code | TYPE CODE | | 3462 | | or | EXTENSION | TPRLO Flags | 3463 | | Common SVC | | | 3464 | | Parameters | | | 3465 +------+------------+------------+-----------+----------+ 3466 | 1 | Third Party Process Associator | 3467 +------+------------+------------+-----------+----------+ 3468 | 2 | Responder Process Associator | 3469 +------+------------+------------+-----------+----------+ 3470 | 3 | Reserved | Third Party Originator N_PORT ID | 3471 +======+============+============+===========+==========+ 3472 | 4-5 | Worldwide Name of Third Party Originator | 3473 | | N_PORT | 3474 +------+------------------------------------------------+ 3475 Figure 23 -- Format of an Augmented TPRLO Parameter Page 3477 The TPRLO flags that affect supplemented ELS processing are as 3478 follows: 3480 Bit 18: Third party Originator N_PORT Validity. When set to 3481 one, this bit indicates that word 3, bits 8-31 (Third 3482 Party Originator N_PORT ID) are meaningful. 3484 Bit 19: Global Process logout. When set to one, this bit 3485 indicates that all image pairs for all N_PORTs of the 3486 specified FC-4 protocol shall be invalidated. When the 3487 value of this bit is one, only one logout parameter page 3489 iFCP Revision 13 August 2002 3491 is permitted in the TPRLO payload. 3493 If bit 18 has a value of zero and bit 19 has a value of one in the 3494 TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. 3496 Otherwise the originating gateway SHALL process the ELS as follows: 3498 a) The first word of the TPRLO payload SHALL NOT be modified. 3500 b) Each TPRLO parameter page shall be extended by two words as 3501 shown in Figure 23. 3503 c) If word 0, bit 18 (Third Party Originator N_PORT ID validity) 3504 in the TPRLO flags field has a value of one, then the sender 3505 shall place the worldwide port name of the fibre channel 3506 device's N_PORT in the extension words. The N_PORT ID SHALL be 3507 set to 3. Otherwise, the contents of the extension words and 3508 the Third Party Originator N_PORT ID SHALL be set to zero. 3510 d) The ELS originator SHALL set the SPC bit in the encapsulation 3511 header of each augmented frame comprising the ELS (see section 3512 5.3.1). 3514 e) If the ELS contains a single TPRLO parameter page, the 3515 originator SHALL increase the frame length as necessary to 3516 include the extended parameter page. 3518 f) If the ELS to be augmented contains multiple TPRLO parameter 3519 pages, the FC frames created to contain the augmented ELS 3520 payload SHALL NOT exceed the maximum frame size that can be 3521 accepted by the destination N_PORT. 3523 Each fibre channel frame SHALL contain an integer number of 3524 extended TPRLO parameter pages. The maximum number of extended 3525 TPRLO parameter pages in a frame SHALL be limited to the number 3526 that can be held without exceeding the above upper limit. New 3527 frames resulting from the extension of the TPRLO pages to 3528 include the supplemental data SHALL be created by extending the 3529 SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT 3530 be modified. 3532 The gateway receiving the augmented TPRLO ELS SHALL generate ELS 3533 frames to be sent to the destination N_PORT by copying word 0 of 3534 the ELS payload and processing each augmented parameter page as 3535 follows: 3537 a) If word 0, bit 18 has a value of one, create a parameter page by 3538 copying words 0 through 2 of the augmented parameter page. The 3539 Third Party Originator N_PORT ID in word 3 shall be generated by 3540 referencing the supplemental data as described in section 7.2. 3542 iFCP Revision 13 August 2002 3544 b) If word 0, bit 18 has a value of zero, create a parameter page 3545 by copying words 0 through 3 of the augmented parameter page. 3547 The size of each frame to be sent to the destination N_PORT MUST 3548 NOT exceed the maximum frame size that the destination N_PORT can 3549 accept. The sequence identifier in each frame header SHALL be 3550 copied from the augmented ELS and the sequence count SHALL be 3551 monotonically increasing. 3553 7.3.1.16 Third Party Logout Accept (TPRLO ACC) 3555 The format of the TPRLO ACC frame is shown in Figure 24. 3557 +--------+------------+--------------------+----------------------+ 3558 | Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 | 3559 +--------+------------+--------------------+----------------------+ 3560 | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | 3561 +--------+------------+--------------------+----------------------+ 3562 | 1 | TPRLO Logout Parameter Page 0 | 3563 +--------+--------------------------------------------------------+ 3564 | 5 | TPRLO Logout Parameter Page 1 | 3565 +--------+--------------------------------------------------------+ 3566 .... 3567 +--------+--------------------------------------------------------+ 3568 |(4*n)+1 | TPRLO Logout Parameter page n | 3569 +--------+--------------------------------------------------------+ 3570 Figure 24 -- Format of TPRLO ACC ELS 3572 The format of the parameter page and rules for parameter page 3573 augmentation are as specified in section 7.3.1.15. 3575 7.3.2 Special FC-4 Link Services 3577 The following sections define FC-4 link services for which special 3578 processing is required. 3580 7.3.2.1 FC-4 Link Services defined by FCP 3582 7.3.2.1.1 Read Exchange Concise (REC) 3584 Link Service Request Format: 3586 iFCP Revision 13 August 2002 3588 +------+------------+------------+-----------+----------+ 3589 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3590 +------+------------+------------+-----------+----------+ 3591 | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | 3592 +------+------------+------------+-----------+----------+ 3593 | 1 | Rsvd | Exchange Originator S_ID | 3594 +------+------------+------------+-----------+----------+ 3595 | 2 | OX_ID | RX_ID | 3596 +======+============+============+===========+==========+ 3597 | 3-4 |Port name of the exchange originator (8 bytes) | 3598 | | (present only for translation type 3) | 3599 +======+============+============+===========+==========+ 3601 Fields Requiring Translation Supplemental Data 3602 Address Translation Type(see (type 3 only) 3603 ------------------- section 7.2) ------------------ 3604 ----------- 3606 Exchange Originator 1, 2 or 3 Port Name of the 3607 S_ID Exchange 3608 Originator 3610 Other Special Processing: 3612 None. 3614 7.3.2.1.2 Read Exchange Concise Accept (REC ACC) 3616 Format of REC ACC Response: 3618 iFCP Revision 13 August 2002 3620 +------+------------+------------+-----------+----------+ 3621 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3622 +------+------------+------------+-----------+----------+ 3623 | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | 3624 +------+------------+------------+-----------+----------+ 3625 | 1 | OX_ID | RX_ID | 3626 +------+------------+------------+-----------+----------+ 3627 | 2 | Rsvd | Exchange Originator N_PORT ID | 3628 +------+------------+------------+-----------+----------+ 3629 | 3 | Rsvd | Exchange Responder N_PORT ID | 3630 +------+------------+------------+-----------+----------+ 3631 | 4 | Data Transfer Count | 3632 +------+------------+------------+-----------+----------+ 3633 | 5 | Exchange Status | 3634 +======+============+============+===========+==========+ 3635 | 6-7 |Port name of the Exchange Originator (8 bytes) | 3636 +======+============+============+===========+==========+ 3637 | 8-9 |Port name of the Exchange Responder (8 bytes) | 3638 +======+============+============+===========+==========+ 3640 Fields Requiring Translation Supplemental Data 3641 Address Translation Type(see (type 3 only) 3642 ------------------- section 7.2) ------------------ 3643 ----------- 3645 Exchange Originator 1, 2 or 3 Port Name of the 3646 N_PORT ID Exchange Originator 3648 Exchange Responder 1, 2 or 3 Port Name of the 3649 N_PORT ID Exchange Responder 3651 When supplemental data is required, the frame SHALL always be 3652 extended by 4 words as shown above. If the translation type for 3653 the Exchange Originator N_PORT ID or the Exchange Responder N_PORT 3654 ID is 1 or 2, the corresponding 8-byte port name SHALL be set to 3655 all zeros. 3657 Other Special Processing: 3659 None. 3661 7.4 FLOGI Service Parameters Supported by an iFCP Gateway 3663 The FLOGI ELS is issued by an N_PORT that wishes to access the 3664 fabric transport services. 3666 The format of the FLOGI request and FLOGI ACC payloads are 3667 identical to the PLOGI request and ACC payloads described in 3668 section 7.3.1.7. 3670 iFCP Revision 13 August 2002 3672 +------+------------+------------+-----------+----------+ 3673 | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| 3674 +------+------------+------------+-----------+----------+ 3675 | 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 | 3676 | | Acc = 0x2 | | | | 3677 +------+------------+------------+-----------+----------+ 3678 | 1-4 | Common Service Parameters | 3679 +------+------------+------------+-----------+----------+ 3680 | 5-6 | N_PORT Name | 3681 +------+------------+------------+-----------+----------+ 3682 | 7-8 | Node Name | 3683 +------+------------+------------+-----------+----------+ 3684 | 9-12 | Class 1 Service Parameters | 3685 +------+------------+------------+-----------+----------+ 3686 |13-17 | Class 2 Service Parameters | 3687 +------+------------+------------+-----------+----------+ 3688 |18-21 | Class 3 Service Parameters | 3689 +------+------------+------------+-----------+----------+ 3690 |22-25 | Class 4 Service Parameters | 3691 +------+------------+------------+-----------+----------+ 3692 |26-29 | Vendor Version Level | 3693 +======+============+============+===========+==========+ 3694 Figure 25 -- FLOGI Request and ACC Payload Format 3696 A full description of each parameter is given in [FC-FS]. 3698 This section tabulates the protocol-dependent service parameters 3699 supported by a fabric port attached to an iFCP gateway. 3701 The service parameters carried in the payload of an FLOGI extended 3702 link service request MUST be set in accordance with 3703 Table 9. 3705 iFCP Revision 13 August 2002 3707 +-----------------------------------------+---------------+ 3708 | | Fabric Login | 3709 | Service Parameter | Class | 3710 | +---+---+---+---+ 3711 | | 1 | 2 | 3 | 4 | 3712 +-----------------------------------------+---+---+---+---+ 3713 | Class Validity | n | M | M | n | 3714 +-----------------------------------------+---+---+---+---+ 3715 | Service Options | | 3716 +-----------------------------------------+---+---+---+---+ 3717 | Intermix Mode | n | n | n | n | 3718 +-----------------------------------------+---+---+---+---+ 3719 | Stacked Connect-Requests | n | n | n | n | 3720 +-----------------------------------------+---+---+---+---+ 3721 | Sequential Delivery | n | M | M | n | 3722 +-----------------------------------------+---+---+---+---+ 3723 | Dedicated Simplex | n | n | n | n | 3724 +-----------------------------------------+---+---+---+---+ 3725 | Camp on | n | n | n | n | 3726 +-----------------------------------------+---+---+---+---+ 3727 | Buffered Class 1 | n | n | n | n | 3728 +-----------------------------------------+---+---+---+---+ 3729 | Priority | n | n | n | n | 3730 +-----------------------------------------+---+---+---+---+ 3731 | Initiator/Recipient Control | | 3732 +-----------------------------------------+---+---+---+---+ 3733 | Clock synchronization ELS capable | n | n | n | n | 3734 +-----------------------------------------+---+---+---+---+ 3735 Table 9 -- FLOGI Service Parameter Settings 3737 Notes: 3739 1) "n" indicates a parameter or capability that is not 3740 supported by the iFCP protocol. 3742 2) "M" indicates an applicable parameter that MUST be 3743 supported by an iFCP gateway. 3745 8. iFCP Error Detection 3747 8.1 Overview 3749 This section specifies provisions for error detection and recovery 3750 in addition to those in [FC-FS], which continue to be available in 3751 the iFCP network environment. 3753 8.2 Stale Frame Prevention 3755 Recovery from fibre channel protocol error conditions requires that 3756 frames associated with a failed or aborted exchange drain from the 3757 fabric before exchange resources can be safely reused. 3759 iFCP Revision 13 August 2002 3761 Since a fibre channel fabric may not preserve frame order, there is 3762 no deterministic way to purge such frames. Instead, the fabric 3763 guarantees that frame the lifetime will not exceed a specific limit 3764 (R_A_TOV). 3766 R_A_TOV is defined in [FC-FS] as "the maximum transit time within a 3767 fabric to guarantee that a lost frame will never emerge from the 3768 fabric". For example, a value of 2 x R_A_TOV is the minimum time 3769 that the originator of an ELS request or FC-4 link service request 3770 must wait for the response to that request. The fibre channel 3771 default value for R_A_TOV is 10 seconds. 3773 An iFCP gateway SHALL actively enforce limits on R_A_TOV as 3774 described in section 8.2.1. 3776 8.2.1 Enforcing R_A_TOV Limits 3778 The R_A_TOV limit on frame lifetimes SHALL be enforced by means of 3779 the time stamp in the encapsulation header (see section 5.3.1) as 3780 described in this section. 3782 The budget for R_A_TOV SHOULD include allowances for the 3783 propagation delay through the gateway regions of the sending and 3784 receiving N_PORTs plus the propagation delay through the IP 3785 network. This latter component is referred to in this 3786 specification as IP_TOV. 3788 IP_TOV should be set well below the value of R_A_TOV specified for 3789 the iFCP fabric and should be stored in the iSNS server. IP_TOV 3790 should be set to 50 percent of R_A_TOV. 3792 The following paragraphs describe the requirements for 3793 synchronizing gateway time bases and the rules for measuring and 3794 enforcing propagation delay limits. 3796 The protocol for synchronizing a gateway time base is SNTP 3797 [RFC2030]. In order to insure that all gateways are time-aligned, a 3798 gateway SHOULD obtain the address of an SNTP-compatible time server 3799 via an iSNS query. If multiple time server addresses are returned 3800 by the query, the servers must be synchronized and the gateway may 3801 use any server in the list. Alternatively, the server may return a 3802 multicast group address in support of operation in Anycast mode. 3803 Implementation of Anycast mode is as specified in [RFC2030], 3804 including the precautions defined in that document. Multicast mode 3805 SHOULD NOT be used. 3807 An SNTP server may use any one of the time reference sources listed 3808 in [RFC2030]. The resolution of the time reference MUST be 125 3809 milliseconds or better. 3811 Stability of the SNTP server and gateway time bases should be 100 3812 ppm or better. 3814 iFCP Revision 13 August 2002 3816 With regard to its time base, the gateway is in either the Synchronized 3817 or Unsynchronized state. 3819 When in the synchronized state, the gateway SHALL 3821 a) Set the time stamp field for each outgoing frame in accordance 3822 with the gateway's internal time base 3824 b) Check the time stamp field of each incoming frame, following 3825 validation of the encapsulation header CRC as described in 3826 section 5.3.4. 3828 c) If the incoming frame has a time stamp of 0,0 and is not one of 3829 the session control frames that require a 0,0 time stamp (see 3830 section 6), the frame SHALL be discarded. 3832 d) If the incoming frame has a non-zero time stamp, the receiving 3833 gateway SHALL compute the absolute value of the time in flight 3834 and SHALL compare it against the value of IP_TOV specified for 3835 the IP fabric. 3837 e) If the result in step (d) exceeds IP_TOV, the encapsulated 3838 frame shall be discarded. Otherwise, the frame shall be de- 3839 encapsulated as described in section 5.3.4. 3841 A gateway SHALL enter the Synchronized state upon receiving a 3842 successful response to an SNTP query. 3844 A gateway shall enter the Unsynchronized state: 3846 a) Upon power up and before successful completion of an SNTP query 3848 b) Whenever the gateway looses contact with the SNTP server such 3849 that the gateway's time base may no longer be in alignment with 3850 that of the SNTP server. The criterion for determining loss of 3851 contact is implementation specific. 3853 Following loss of contact, it is recommended that the gateway enter 3854 the Unsynchronized state when the estimated time base drift 3855 relative to the SNTP reference is greater than ten percent of the 3856 IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and 3857 IP_TOV equals 5 seconds, the maximum allowable loss of contact 3858 duration would be about 42 minutes.) 3860 As the result of a transition from the Synchronized to the 3861 Unsynchronized state, a gateway MUST abort all iFCP sessions as 3862 described in section 5.2.3. While in the Unsynchronized state, a 3863 gateway SHALL NOT permit the creation of new iFCP sessions. 3865 9. Fabric Services Supported by an iFCP implementation 3866 iFCP Revision 13 August 2002 3868 An iFCP gateway implementation MUST support the following fabric 3869 services: 3871 N_PORT ID Value Description Section 3872 --------------- ----------- ------- 3873 0xFF-FF-FE F_PORT Server 9.1 3875 0xFF-FF-FD Fabric Controller 9.2 3877 0xFF-FF-FC Directory/Name Server 9.3 3879 In addition, an iFCP gateway MAY support the FC broadcast server 3880 functionality described in section 9.4. 3882 9.1 F_PORT Server 3884 The F_PORT server SHALL support the FLOGI ELS as described in 3885 section 7.4 as well as the following ELSs specified in [FC-FS]: 3887 a) Request for fabric service parameters (FDISC), 3889 b) Request for the link error status (RLS), 3891 c) Read Fabric Timeout Values (RTV). 3893 9.2 Fabric Controller 3895 The Fabric Controller SHALL support the following ELSs as specified 3896 in [FC-FS]: 3898 a) State Change Notification (SCN), 3900 b) Registered State Change Notification (RSCN), 3902 c) State Change Registration (SCR). 3904 9.3 Directory/Name Server 3906 The Directory/Name server provides a registration service allowing 3907 an N_PORT to record or query the database for information about 3908 other N_PORTs. The services are defined in [FC-GS3]. The queries 3909 are issued as FC-4 transactions using the FC-CT command transport 3910 protocol specified in [FC-GS3]. 3912 In iFCP, each name server request MUST be translated to the 3913 appropriate iSNS query defined in [ISNS]. The definitions of name 3914 server objects are specified in [FC-GS3]. 3916 iFCP Revision 13 August 2002 3918 The name server SHALL support record and query operations for 3919 directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) 3920 and MAY support the FC-4 specific services as defined in [FC-GS3]. 3922 9.4 Broadcast Server 3924 Fibre channel frames are broadcast throughout the fabric by 3925 addressing them to the fibre channel broadcast server at well-known 3926 fibre channel address 0xFF-FF-FF. The broadcast server then 3927 replicates and delivers the frame to each attached N_PORT in all 3928 zones to which the originating device belongs. Only class 3 3929 (datagram) service is supported. 3931 In an iFCP system, the fibre channel broadcast function is emulated 3932 by means of a two-tier architecture comprised of the following 3933 elements: 3935 a) A local broadcast server residing in each iFCP gateway. The 3936 local server distributes broadcast traffic within the gateway 3937 region and forwards outgoing broadcast traffic to a global 3938 server for distribution throughout the iFCP fabric. 3940 b) A global broadcast server which re-distributes broadcast 3941 traffic to the local server in each participating gateway. 3943 c) An iSNS discovery domain defining the scope over which 3944 broadcast traffic is propagated. The discovery domain is 3945 populated with a global broadcast server and the set of local 3946 servers it supports. 3948 The local and global broadcast servers are logical iFCP devices 3949 that communicate using the iFCP protocol. The servers have an 3950 N_PORT Network Address consisting of an iFCP portal address and an 3951 N_PORT ID set to the well-known fibre channel address of the FC 3952 broadcast server (0xFF-FF-FF). 3954 As noted above, an N_PORT originates a broadcast by directing frame 3955 traffic to the fibre channel broadcast server. The gateway-resident 3956 local server distributes a copy of the frame locally and forwards a 3957 copy to the global server for redistribution to the local servers 3958 on other gateways. The global server MUST NOT echo a broadcast 3959 frame to the originating local server. 3961 9.4.1 Establishing the Broadcast Configuration 3963 The broadcast configuration is managed using facilities provided by 3964 the iSNS server. Specifically: 3966 a) An iSNS discovery domain is created and seeded with the network 3967 address of the global broadcast server N_PORT. The global 3968 server is identified as such by setting the appropriate N_PORT 3969 entity attribute. 3971 iFCP Revision 13 August 2002 3973 b) Using the management interface, each broadcast server is preset 3974 with the identity of the broadcast domain. 3976 During power up, each gateway SHALL invoke the iSNS service to 3977 register its local broadcast server in the broadcast discovery 3978 domain. After registration, the local server SHALL wait for the 3979 global broadcast server to establish an iFCP session. 3981 The global server SHALL register with the iSNS server as follows: 3983 a) The server SHALL query the iSNS name server by attribute to 3984 obtain the worldwide port name of the N_PORT pre-configured to 3985 provide global broadcast services. 3987 b) If the worldwide port name obtained above does not correspond to 3988 that of the server issuing the query, the N_PORT SHALL NOT 3989 perform global broadcast functions for N_PORTs in that discovery 3990 domain. 3992 c) Otherwise, the global server N_PORT SHALL register with the 3993 discovery domain and query the iSNS server to identify all 3994 currently-registered local servers. 3996 d) The global broadcast server SHALL initiate an iFCP session with 3997 each local broadcast server in the domain. When a new local 3998 server registers, the global server SHALL receive a state change 3999 notification and respond by initiating an iFCP session with the 4000 newly added server. The gateway SHALL obtain these 4001 notifications using the iSNS provisions for lossless delivery. 4003 Upon receiving the CBIND request to initiate the iFCP session, the 4004 local server SHALL record the worldwide port name and N_PORT 4005 network address of the global server. 4007 9.4.2 Broadcast Session Management 4009 After the initial broadcast session is established, the local or 4010 global broadcast server MAY choose to manage the session in one of 4011 the following ways depending on resource requirements and the 4012 anticipated level of broadcast traffic: 4014 a) A server MAY keep the session open continuously. Since 4015 broadcast sessions are often quiescent for long periods of 4016 time, the server SHOULD monitor session connectivity as 4017 described in section 5.2.2.4. 4019 b) A server MAY open the broadcast session on demand only when 4020 broadcast traffic is to be sent. If the session is reopened by 4021 the global server, the local server SHALL replace the 4022 previously recorded network address of the global broadcast 4023 server. 4025 iFCP Revision 13 August 2002 4027 9.4.3 Standby Global Broadcast Server 4029 An implementation may designate a local server to assume the duties 4030 of the global broadcast server in the event of a failure. The 4031 local server may use the LTEST message to determine if the global 4032 server is functioning and may assume control if not. 4034 When assuming control, the standby server must register with the 4035 iSNS server as the global broadcast server in place of the failed 4036 server and must install itself in the broadcast discovery domain as 4037 specified in steps c) and d)of section 9.4.1. 4039 10. iFCP Security 4041 10.1 Overview 4043 iFCP relies upon the IPSec protocol suite to provide data 4044 confidentiality and authentication services, and IKE as the key 4045 management protocol. Section 10.2 describes the security 4046 requirements arising from iFCP�s operating environment while 4047 Section 10.3 describes the resulting design choices, their 4048 requirement levels, and how they apply to the iFCP protocol. 4050 Detailed considerations for use of IPsec and IKE with the iFCP 4051 protocol can be found in [SECIPS]. 4053 10.2 iFCP Security Threats and Scope 4055 10.2.1 Context 4057 iFCP is a protocol designed for use by gateway devices deployed in 4058 enterprise data centers. Such environments typically have security 4059 gateways designed to provide network security through isolation 4060 from public networks. Furthermore, iFCP data may need to traverse 4061 security gateways in order to support SAN-to-SAN connectivity 4062 across public networks. 4064 10.2.2 Security Threats 4066 Communicating iFCP gateways may be subjected to attacks, including 4067 attempts by an adversary to: 4069 a) Acquire confidential data and identities by snooping data 4070 packets. 4072 b) Modify packets containing iFCP data and control messages. 4074 c) Inject new packets into the iFCP session. 4076 d) Hijack the TCP connection carrying the iFCP session. 4078 e) Launch denial of service attacks against the iFCP gateway. 4080 iFCP Revision 13 August 2002 4082 f) Disrupt the security negotiation process. 4084 g) Impersonate a legitimate security gateway. 4086 h) Compromise communication with the iSNS server. 4088 It is imperative to thwart these attacks, given that an iFCP 4089 gateway is the last line of defense for a whole fibre channel 4090 island, which may include several hosts and fibre channel switches. 4091 To do so, the iFCP gateway must implement and may use 4092 confidentiality, data origin authentication, integrity, and replay 4093 protection on a per-datagram basis. The iFCP gateway must implement 4094 and may use bi-directional authentication of the communication 4095 endpoints. Finally, it must implement and may use a scalable 4096 approach to key management. 4098 10.2.3 Interoperability with Security Gateways 4100 Enterprise data center networks are considered mission-critical 4101 facilities that must be isolated and protected from all possible 4102 security threats. Such networks are usually protected by security 4103 gateways, which at a minimum provide a shield against denial of 4104 service attacks. The iFCP security architecture is capable of 4105 leveraging the protective services of the existing security 4106 infrastructure, including firewall protection, NAT and NAPT 4107 services, and IPSec VPN services available on existing security 4108 gateways. Considerations regarding intervening NAT and NAPT boxes 4109 along the iFCP-iSNS path can be found in [iSNS]. 4111 10.2.4 Authentication 4113 iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by 4114 either or both peer gateways. Consequently, bi-directional 4115 authentication of peer gateways must be provided in accordance with 4116 the requirement levels specified in section 10.3.1. 4118 N_PORT identities used in the Port Login (PLOGI) process shall be 4119 considered authenticated provided the PLOGI request is received 4120 from the remote gateway over a secure, IPSec-protected connection 4122 There is no requirement that the identities used in authentication 4123 be kept confidential. 4125 10.2.5 Confidentiality 4127 iFCP traffic may traverse insecure public networks, and therefore 4128 implementations must have per-packet encryption capabilities to 4129 provide confidentiality in accordance with the requirements 4130 specified in section 10.3.1. 4132 10.2.6 Rekeying 4133 iFCP Revision 13 August 2002 4135 Due to the high data transfer rates and the amount of data 4136 involved, an iFCP implementation must support the capability to 4137 rekey each phase 2 security association in the time intervals 4138 dictated by sequence number space exhaustion at a given link rate. 4139 In the rekeying scenario described in [SECIPS], for example, 4140 rekeying events happen as often as every 27.5 seconds at 10 Gbps 4141 rates. 4143 The iFCP gateway must provide the capability for forward secrecy in 4144 the rekeying process. 4146 10.2.7 Authorization 4148 Basic access control properties stem from the requirement that two 4149 communicating iFCP gateways be known to one or more iSNS servers 4150 before they can engage in iFCP exchanges. The optional use of 4151 discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and 4152 certificate-based authentication (e.g., with X509v3 certificates) 4153 enables authorization schemas of increasing complexity. The 4154 definition of such schemas (e.g., role-based access control) is 4155 outside of the scope of this specification. 4157 10.2.8 Policy control 4159 This specification allows any and all security mechanisms in an 4160 iFCP gateway to be administratively disabled. Security policies 4161 MUST have at most iFCP Portal resolution. Administrators may gain 4162 control over security policies through an adequately secured 4163 interaction with a management interface or with iSNS. 4165 10.2.9 iSNS Role 4167 iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways 4168 MUST use iSNS for discovery services, and MAY use security policies 4169 configured in the iSNS database as the basis for algorithm 4170 negotiation in IKE. The iSNS specification defines mechanisms to 4171 secure communication between an iFCP gateway and iSNS server(s). 4172 Additionally, such specification indicates how elements of security 4173 policy concerning individual iFCP sessions can be retrieved from 4174 iSNS server(s). 4176 10.3 iFCP Security Design 4178 10.3.1 Enabling Technologies 4180 Applicable technology from IPsec and IKE is defined in the 4181 following suite of specifications: 4183 [RFC2401] Security Architecture for the Internet Protocol 4185 [RFC2402] IP Authentication Header 4187 iFCP Revision 13 August 2002 4189 [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH 4191 [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV 4193 [RFC2406] IP Encapsulating Security Payload 4195 [RFC2407] The Internet IP Security Domain of Interpretation for 4196 ISAKMP 4198 [RFC2408] Internet Security Association and Key Management 4199 Protocol (ISAKMP) 4201 [RFC2409] The Internet Key Exchange (IKE) 4203 [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC 4205 [RFC2451] The ESP CBC-Mode Cipher Algorithms 4207 [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains 4209 The implementation of IPsec and IKE is required according the 4210 following guidelines. 4212 Support for the IP Encapsulating Security Payload (ESP) [RFC2406] 4213 is MANDATORY to implement. When ESP is utilized, per-packet data 4214 origin authentication, integrity and replay protection MUST be 4215 used. 4217 For data origin authentication and integrity with ESP, HMAC with 4218 SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption 4219 Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining 4220 SHOULD be implemented in accordance with [AESCBC]. 4222 For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be 4223 implemented, and AES counter mode encryption [AESCTR] SHOULD be 4224 implemented. NULL encryption MUST be supported as well, as defined 4225 in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its 4226 inherent weakness. Since it is known to be crackable with modest 4227 computation resources, it is inappropriate for use in any iFCP 4228 deployment scenario. 4230 A conformant iFCP protocol implementation MUST implement IPsec ESP 4231 [RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in 4232 transport mode. 4234 Regarding key management, iFCP implementations MUST support IKE 4235 [RFC2409] for bi-directional peer authentication, negotiation of 4236 security associations, and key management, using the IPsec DOI. 4237 There is no requirement that the identities used in authentication 4238 be kept confidential. Manual keying MUST NOT be used since it does 4240 iFCP Revision 13 August 2002 4242 not provide the necessary keying support. According to [RFC2409], 4243 pre-shared secret key authentication is MANDATORY to implement, 4244 whereas certificate-based peer authentication using digital 4245 signatures MAY be implemented (see section 10.3.3 regarding the use 4246 of certificates). [RFC2409] defines the following requirement 4247 levels for IKE Modes: 4249 Phase-1 Main Mode MUST be implemented 4251 Phase-1 Aggressive Mode SHOULD be implemented 4253 Phase-2 Quick Mode MUST be implemented 4255 Phase-2 Quick Mode with key exchange payload MUST be implemented. 4257 With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with 4258 pre-shared keys, due to Main Mode�s vulnerability to man-in-the- 4259 middle-attackers when group pre-shared keys are used. In this 4260 scenario, Aggressive Mode SHOULD be used instead. Peer 4261 authentication using the public key encryption methods outlined in 4262 [RFC2409] SHOULD NOT be used. 4264 The DOI [RFC2407] provides for several types of Identification 4265 Payloads. 4267 When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the 4268 Identification Payload fields (IDii and IDir). Conformant iFCP 4269 implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the 4270 protocol stack supports IPv6), or ID_FQDN Identification Type 4271 values. The ID_USER_FQDN, IP Subnet, IP Address Range, 4272 ID_DER_ASN1_DN, ID_DER_ASN1_GN Identification Type values SHOULD 4273 NOT be used. The ID_KEY_ID Identification Type values MUST NOT be 4274 used. As described in [RFC2407], the port and protocol fields in 4275 the Identification Payload MUST be set to zero or UDP port 500. 4277 When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the 4278 Identification Payload fields (IDci and IDcr). Conformant iFCP 4279 implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR 4280 Identification Type values (according to the version of IP 4281 supported). Other Identification Type values MUST NOT be used. As 4282 described in section 5.2.2, the gateway creating the iFCP session 4283 must query the iSNS server to determine the appropriate port on 4284 which to initiate the associated TCP connection. Upon a successful 4285 IKE Phase 2 exchange, the IKE responder enforces the negotiated 4286 selectors on the IPsec SAs. Any subsequent iFCP session creation 4287 requires the iFCP peer to query its iSNS server for access control 4288 (in accordance with the session creation requirements specified in 4289 section 5.2.2.1). 4291 10.3.2 Use of IKE and IPsec 4292 iFCP Revision 13 August 2002 4294 A conformant iFCP Portal is capable of establishing one or more IKE 4295 Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase- 4296 1 SA may be established when an iFCP Portal is initialized, or may 4297 be deferred until the first TCP connection with security 4298 requirements is established. 4300 An IKE Phase-2 SA protects one or more TCP connections within the 4301 same iFCP Portal. More specifically, the successful establishment 4302 of an IKE Phase-2 SA results in the creation of two uni-directional 4303 IPsec SAs fully qualified by the tuple . 4306 These SAs protect the setup process of the underlying TCP 4307 connections and all their subsequent TCP traffic. The number of TCP 4308 connections in an IPsec SA as well as the number of SAs is 4309 practically driven by security policy considerations (i.e., 4310 security services are defined at the granularity of an IPsec SA 4311 only), QoS considerations (e.g., multiple QoS classes within the 4312 same IPsec SA increase odds of packet reordering, possibly falling 4313 outside the replay window), and failure compartmentalization 4314 considerations. Each of the TCP connections protected by an IPsec 4315 SA is either in the unbound state, or is bound to a specific iFCP 4316 session. 4318 In summary, at any point in time: 4320 -- There exist 0..M IKE Phase-1 SAs between peer iFCP portals 4322 -- Each IKE Phase-1 SA has 0..N IKE Phase-2 SAs 4324 -- Each IKE Phase-2 SA protects 0..Z TCP connections 4326 The creation of an IKE Phase-2 SA may be triggered by a policy rule 4327 supplied through a management interface or by iFCP Portal 4328 properties registered with the iSNS server. Similarly, the use of a 4329 Key Exchange payload in Quick Mode for perfect forward secrecy may 4330 be dictated through a management interface or by an iFCP Portal 4331 policy rule registered with the iSNS server. 4333 If an iFCP implementation makes use of unbound TCP connections, and 4334 such connections belong to an iFCP Portal with security 4335 requirements, then the unbound connections MUST be protected by an 4336 SA at all times just like bound connections. 4338 Upon receiving an IKE Phase-2 delete message, there is no 4339 requirement to terminate the protected TCP connections or delete 4340 the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be 4341 associated with multiple TCP connections, terminating such 4342 connections might in fact be inappropriate and untimely. 4344 To minimize the number of active Phase-2 SAs, IKE Phase-2 delete 4345 messages may be sent for Phase-2 SAs whose TCP connections have not 4347 iFCP Revision 13 August 2002 4349 handled data traffic for a while. To minimize the use of SA 4350 resources while the associated TCP connections are idle, creation 4351 of a new SA should be deferred until new data are to be sent over 4352 the connections. 4354 10.3.3 Signatures and Certificate-based Authentication 4356 Conformant iFCP implementations MAY support peer authentication via 4357 digital signatures and certificates. When certificate 4358 authentication is chosen within IKE, each iFCP gateway needs the 4359 certificate credentials of each peer iFCP gateway in order to 4360 establish a security association with that peer. 4362 Certificate credentials used by iFCP gateways MUST be those of the 4363 machine. Certificate credentials MAY be bound to the interface (IP 4364 Address or FQDN) of the iFCP gateway used for the iFCP session, or 4365 the fabric WWN of the iFCP gateway itself. Since the value of a 4366 machine certificate is inversely proportional to the ease with 4367 which an attacker can obtain one under false pretenses, it is 4368 advisable that the machine certificate enrollment process be 4369 strictly controlled. For example, only administrators may have the 4370 ability to enroll a machine with a machine certificate. User 4371 certificates SHOULD NOT be used by iFCP gateways for establishment 4372 of SA's protecting iFCP sessions. 4374 If the gateway does not have the peer iFCP gateway's certificate 4375 credentials, then it can obtain them by 4377 a) Using the iSNS protocol to query for the peer gateway's 4378 certificate(s) stored in a trusted iSNS server, or 4380 b) Through use of the ISAKMP Certificate Request Payload (CRP) 4381 [RFC2408] to request the certificate(s) directly from the peer 4382 iFCP gateway. 4384 When certificate chains are long enough, then IKE exchanges using 4385 UDP as the underlying transport may yield IP fragments, which are 4386 known to work poorly across some intervening routers, firewalls, 4387 and NA(P)T boxes. As a result, the endpoints may be unable to 4388 establish an IPsec security association. 4390 Due to these fragmentation shortcomings, IKE is most appropriate 4391 for intra-domain usage. Known solutions to the fragmentation 4392 problem are to send the end-entry machine certificate rather than 4393 the chain, to reduce the size of the certificate chain, to use IKE 4394 implementations over a reliable transport protocol (e.g., TCP) 4395 assisted by Path MTU discovery and code against black-holing as in 4396 [RFC2923], or to install network components that can properly 4397 handle fragments. 4399 iFCP Revision 13 August 2002 4401 IKE negotiators SHOULD check the pertinent Certificate Revocation 4402 List (CRL) [RFC2408] before accepting a certificate for use in 4403 IKE's authentication procedures. 4405 10.4 iSNS and iFCP Security 4407 iFCP implementations MUST use iSNS for discovery and management 4408 services. Consequently, the security of the iSNS protocol has an 4409 impact on the security of iFCP gateways. For a discussion of 4410 potential threats to iFCP gateways through use of iSNS, see [ISNS]. 4412 To provide security for iFCP gateways using the iSNS protocol for 4413 discovery and management services, the IPSec ESP protocol in tunnel 4414 mode MUST be supported for iFCP gateways. Further discussion of 4415 iSNS security implementation requirements is found in [ISNS]. Note 4416 that iSNS security requirements match those for iFCP described in 4417 section 10.3. 4419 10.5 Use of iSNS to Distribute Security Policy 4421 Once communication between iFCP gateways and the iSNS server have 4422 been secured through use of IPSec, the iFCP gateways have the 4423 capability to discover the security settings that they need to use 4424 (or not use) to protect iFCP traffic. This provides a potential 4425 scaling advantage over device-by-device configuration of individual 4426 security policies for each iFCP gateway. It also provides an 4427 efficient means for each iFCP gateway of discovering the use or 4428 non-use of specific security capabilities by peer gateways. 4430 Further discussion on use of iSNS to distribute security policies 4431 is found in [ISNS]. 4433 10.6 Minimal Security Policy for an iFCP gateway 4435 An iFCP implementation may be able to administratively disable 4436 security mechanisms for an iFCP Portal through a management 4437 interface or through security policy elements set in the iSNS 4438 server. As a consequence, IKE or IPsec security associations will 4439 not be established for any iFCP sessions that traverse the portal. 4441 For most IP networks, it is inappropriate to assume physical 4442 security, administrative security, and correct configuration of the 4443 network and all attached nodes (a physically isolated network in a 4444 test lab may be an exception). Therefore, authentication SHOULD be 4445 used in order to provide a minimal assurance that connections have 4446 initially been opened with the intended counterpart. The minimal 4447 iFCP security policy thus only states that an iFCP gateway SHOULD 4448 authenticate its iSNS server(s) as described in [ISNS]. 4450 11. Quality of Service Considerations 4452 11.1 Minimal requirements 4453 iFCP Revision 13 August 2002 4455 Conforming iFCP protocol implementations SHALL correctly 4456 communicate gateway-to-gateway even across one or more intervening 4457 best-effort IP regions. The timings with which such gateway-to 4458 gateway communication is performed, however, will greatly depend 4459 upon BER, packet losses, latency, and jitter experienced throughout 4460 the best-effort IP regions. The higher these parameters, the higher 4461 will be the gap measured between iFCP observed behaviors and 4462 baseline iFCP behaviors (i.e., as produced by two iFCP gateways 4463 directly connected to one another). 4465 11.2 High-assurance 4467 It is expected that many iFCP deployments will benefit from a high 4468 degree of assurance regarding the behavior of intervening IP 4469 regions, with resulting high-assurance on the overall end-to-end 4470 path, as directly experienced by fibre channel applications. Such 4471 assurance on the IP behaviors stems from the intervening IP regions 4472 supporting standard Quality-of-Service (QoS) techniques, fully 4473 complementary to iFCP, such as: 4475 a) Congestion avoidance by over-provisioning of the network, 4477 b) Integrated Services [RFC1633] QoS, 4479 c) Differentiated Services [RFC2475] QoS 4481 d) Multi-Protocol Label Switching [RFC3031]. 4483 One may load an MPLS forwarding equivalence class (FEC) with QoS 4484 class significance, in addition to other considerations such as 4485 protection and diversity for the given path. The complementarity 4486 and compatibility of MPLS with Differentiated Services is 4487 explored in [MPSLDS], wherein the PHB bits are copied to the EXP 4488 bits of the MPLS shim header. 4490 In the most general definition, two iFCP gateways are separated by 4491 one or more independently managed IP regions, some of which 4492 implement some of the QoS solutions mentioned above. A QoS-capable 4493 IP region supports the negotiation and establishment of a service 4494 contract specifying the forwarding service through the region. Such 4495 contract and its negotiation rules are outside the scope of this 4496 document. In the case of IP regions with DiffServ QoS, the reader 4497 should refer to Service Level Specifications (SLS) and Traffic 4498 Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other 4499 aspects of a service contract are expected to be non-technical and 4500 thus outside of the IETF scope. 4502 Due to the fact that fibre channel Class 2 and Class 3 do not 4503 currently support fractional bandwidth guarantees, and that iFCP is 4504 committed to supporting fibre channel semantics, it is impossible 4505 for an iFCP gateway to autonomously infer bandwidth requirements 4506 from streaming fibre channel traffic. Rather, the requirements on 4508 iFCP Revision 13 August 2002 4510 bandwidth or other network parameters need to be administratively 4511 set into an iFCP gateway, or into the entity that will actually 4512 negotiate the forwarding service on the gateway's behalf. Depending 4513 on the QoS techniques available, the stipulation of a forwarding 4514 service may require interaction with network ancillary functions 4515 such admission control and bandwidth brokers (via RSVP or other 4516 signaling protocols that an IP region may accept). 4518 The administrator of a iFCP gateway may negotiate a forwarding 4519 service with IP region(s) for one, several, or all of an iFCP 4520 gateway's TCP sessions used by an iFCP gateway. Alternately, this 4521 responsibility may be delegated to a node downstream. Since one TCP 4522 connection is dedicated to each iFCP session, the traffic in an 4523 individual N_PORT to N_PORT session can be singled out by iFCP- 4524 unaware network equipment as well. 4526 To render the best emulation of fibre channel possible over IP, it 4527 is anticipated that typical forwarding services will specify a 4528 fixed amount of bandwidth, null losses, and, to a lesser degree of 4529 relevance, low latency, and low jitter. For example, an IP region 4530 using DiffServ QoS may support SLSs of this nature by applying EF 4531 DSCPs to the iFCP traffic. 4533 12. IANA Considerations 4535 The IANA-assigned port for iFCP traffic is port number 3420. 4537 An iFCP Portal may initiate a connection using any TCP port number 4538 consistent with its implementation of the TCP/IP stack, provided 4539 each port number is unique. To prevent the receipt of stale data 4540 associated with a previous connection using a given port number, 4541 the provisions of [RFC1323], Appendix B SHOULD be observed. 4543 13. Author's Addresses 4544 iFCP Revision 13 August 2002 4546 Charles Monia Franco Travostino 4547 Rod Mullendore Director, Content 4548 Internetworking Lab, 4549 Nishan Systems Nortel Networks 4550 3850 North First Street 3 Federal Street 4551 San Jose, CA 95134 Billerica, MA 01821 4552 Phone: 408-519-3986 Phone: 978-288-7708 4553 Email: Email: 4554 cmonia@nishansystems.com 4555 travos@nortelnetworks.com 4557 Wayland Jeong Mark Edwards 4558 Troika Networks Senior Systems Architect 4559 Vice President, Hardware Eurologic Development, Ltd. 4560 Engineering 4th Floor, Howard House 4561 2829 Townsgate Road Suite Queens Ave, UK. BS8 1SD 4562 200 Phone: +44 (0)117 930 9600 4563 Westlake Village, CA 91361 Email: 4564 Phone: 805-370-2614 medwards@eurologic.com 4565 Email: 4566 wayland@troikanetworks.com 4568 14. Normative References 4570 [AESCBC] Frankel, S., Hebert, H., "The AES Cipher Algorithm and Its 4571 Use with IPsec", Internet draft (work in progress), draft- 4572 ietf-ipsec-ciph-aes-xcbc-mac-02.txt, June 2002. 4574 [AESCTR] Housley, R., "Using AES Counter Mode With IPsec ESP", 4575 Internet draft (work in progress), draft-ietf-ipsec-ciph- 4576 aes-ctr-00.txt, July 2002 4578 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- 4579 GS3)", revision 7.01, NCITS Project 1356-D, November 2000 4581 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- 4582 SW2)", revision 5.2, NCITS Project 1305-D, May 2001 4584 [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service", 4585 draft-ietf-ips-08.txt, February 2002 4587 [RFC1119] Mills, D., "Network Time Protocol (Version 3) 4588 Specification, Implementation and Analyses", RFC 1305, 4589 March 1992 4591 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 4592 3", BCP 9, RFC 2026, October 1996. 4594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4596 iFCP Revision 13 August 2002 4598 Requirement Levels", BCP 14, RFC 2119, March 1997 4600 [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture 4601 for the Internet Protocol", November 1998 4603 [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication 4604 Header", November 1998 4606 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4607 ESP and AH", RFC 2404, November 1998 4609 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within 4610 ESP and AH", RFC 2404, November 1998 4612 [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security 4613 Protocol", November 1998 4615 [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of 4616 Interpretation for ISAKMP", November 1998 4618 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 4619 RFC 2408, "Internet Security Association and Key Management 4620 Protocol (ISAKMP)" November 1998 4622 [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key 4623 Exchange (IKE)", November 1998 4625 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and 4626 Its use with IPSEC", RFC 2410, November 1998 4628 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher 4629 Algorithms", RFC 2451, November 1998 4631 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 4632 1981 4634 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 4635 September, 1981 4637 [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over 4638 IP", Internet draft (work in progress), draft-ietf-ips- 4639 security-12.txt, May 2002 4641 15. Non-Normative References 4643 [AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", 4644 Draft, 2001, Available from 4645 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf 4647 [DIFTERM] Grossman, D., "New Terminology and Clarifications for 4649 iFCP Revision 13 August 2002 4651 Diffserv", draft-ietf-diffserv-new-terms-07.txt, December 4652 2001 4654 [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 4655 2)", revision 7.0, NCITS Project 1133D, April 1999 4657 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- 4658 FLA)", revision 2.7, NCITS Project 1235-D, August 1997 4660 [KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated 4661 Loop", Robert W. Kembel, Northwest Learning Associates, 4662 2000, ISBN 0-931836-84-0 4664 [KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", 4665 Northwest Learning Associates Inc., 2000, ISBN 0-931836-84- 4666 0 4668 [MPSLDS] F. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. 4669 Krishnan, P. Cheval, J. Heinanen, "MPLS Support of 4670 Differentiated Services", draft-ietf-mpls-diff-ext-09.txt, 4671 April 2001. 4673 [RFC1122] Braden, S., "Requirements for Internet Hosts -- 4674 Communication Layers", RFC 1122, October 1989 4676 [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High 4677 Performance", RFC 1323, May, 1992 4679 [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated 4680 Services in the Internet Architecture: an Overview", RFC 4681 1633, June 1994 4683 [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol 4684 (SNTP)" Version 4, October 1996 4686 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 4687 2131, March 1997 4689 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4690 Algorithm With Explicit IV" RFC 2405, November 1998 4692 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher 4693 Algorithm With Explicit IV" RFC 2405, November 1998 4695 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 4696 and W. Weiss, "An Architecture for Differentiated 4697 Services", RFC 2475, December 1998 4699 [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre 4700 Channel", June 1999 4702 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 4704 iFCP Revision 13 August 2002 4706 NAT Domains", RFC 2709, October 1999 4708 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 4709 2923, September 2000 4711 [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi- 4712 Protocol Label Switching Architecture", RFC 3031, January 4713 2001 4715 [RFC896] Nagle, J., "Congestion Control in IP/TCP Networks", RFC 4716 896, January 1984 4718 iFCP Revision 13 August 2002 4720 Appendix A 4722 A. iFCP Support for Fibre Channel Link Services 4724 For reference purposes, this appendix enumerates all the fibre 4725 channel link services and the manner in which each shall be 4726 processed by an iFCP implementation. The iFCP processing policies 4727 are defined in section 7. 4729 In the following sections, the name of a link service specific to a 4730 particular FC-4 protocol is prefaced by a mnemonic identifying the 4731 protocol. 4733 A.1 Basic Link Services 4735 The basic link services are shown in the following table. 4737 Basic Link Services 4739 Name Description iFCP Policy 4740 ---- ----------- ---------- 4742 ABTS Abort Sequence Transparent 4743 BA_ACC Basic Accept Transparent 4744 BA_RJT Basic Reject Transparent 4745 NOP No Operation Transparent 4746 PRMT Preempted Rejected 4747 (Applies to 4748 Class 1 only) 4749 RMC Remove Connection Rejected 4750 (Applies to 4751 Class 1 only) 4753 A.2 Pass-Through Link Services 4755 As specified in section 7, the link service requests of Table 10 4756 and the associated ACC response frames MUST be passed through to 4757 the receiving N_PORT without altering the payload. 4759 Name Description 4760 ---- ----------- 4762 ADVC Advise Credit 4763 CSR Clock Synchronization Request 4764 CSU Clock Synchronization Update 4765 ECHO Echo 4766 ESTC Estimate Credit 4767 ESTS Establish Streaming 4768 FACT Fabric Activate Alias_ID 4769 FAN Fabric Address Notification 4770 FCP_RJT FCP FC-4 Link Service Reject 4772 iFCP Revision 13 August 2002 4774 FCP SRR FCP Sequence Retransmission 4775 Request 4776 FDACT Fabric Deactivate Alias_ID 4777 FDISC Discover F_Port Service 4778 Parameters 4779 FLOGI F_Port Login 4780 GAID Get Alias_ID 4781 LCLM Login Control List Management 4782 LINIT Loop Initialize 4783 LIRR Link Incident Record 4784 Registration 4785 LPC Loop Port Control 4786 LS_RJT Link Service Reject 4787 LSTS Loop Status 4788 NACT N_Port Activate Alias_ID 4789 NDACT N_Port Deactivate Alias_ID 4790 PDISC Discover N_Port Service 4791 Parameters 4792 PRLI Process Login 4793 PRLO Process Logout 4794 QoSR Quality of Service Request 4795 RCS Read Connection Status 4796 RLIR Registered Link Incident 4797 Report 4798 RNC Report Node Capability 4799 RNFT Report Node FC-4 Types 4800 RNID Request Node Identification 4801 Data 4802 RPL Read Port List 4803 RPS Read Port Status Block 4804 RPSC Report Port Speed 4805 Capabilities 4806 RSCN Registered State Change 4807 Notification 4808 RTV Read Timeout Value 4809 RVCS Read Virtual Circuit Status 4810 SBRP Set Bit-error Reporting 4811 Parameters 4812 SCN State Change Notification 4813 SCR State Change Registration 4814 TEST Test 4815 TPLS Test Process Login State 4816 Table 10 -- Pass-Through link Services 4818 A.3 Special Link Services 4820 The extended and FC-4 link services of Table 11 are processed by an 4821 iFCP implementation as described in the sections referenced in the 4822 table. 4824 iFCP Revision 13 August 2002 4826 Name Description Section 4827 ---- ----------- ------- 4829 ABTX Abort Exchange 7.3.1.1 4830 ADISC Discover Address 7.3.1.2 4831 ADISC Discover Address Accept 7.3.1.3 4832 ACC 4833 FARP- Fibre Channel Address 7.3.1.4 4834 REPLY Resolution Protocol 4835 Reply 4836 FARP- Fibre Channel Address 7.3.1.5 4837 REQ Resolution Protocol 4838 Request 4839 LOGO N_PORT Logout 7.3.1.6 4840 PLOGI Port Login 7.3.1.7 4841 FCP REC FCP Read Exchange 7.3.2.1.1 4842 Concise 4843 FCP REC FCP Read Exchange 7.3.2.1.2 4844 ACC Concise Accept 4845 RES Read Exchange Status 7.3.1.8 4846 Block 4847 RES ACC Read Exchange Status 7.3.1.9 4848 Block Accept 4849 RLS Read Link Error Status 7.3.1.10 4850 Block 4851 RRQ Reinstate Recovery 7.3.1.12 4852 Qualifier 4853 RSI Request Sequence 7.3.1.13 4854 Initiative 4855 RSS Read Sequence Status 7.3.1.11 4856 Block 4857 SRL Scan Remote Loop 7.3.1.14 4858 TPRLO Third Party Process 7.3.1.15 4859 Logout 4860 TPRLO Third Party Process 7.3.1.16 4861 ACC Logout Accept 4862 Table 11 -- Special Link Services 4864 iFCP Revision 13 August 2002 4866 Appendix B 4868 B. Supporting the Fibre Channel Loop Topology 4870 A loop topology may be optionally supported by a gateway 4871 implementation in one of the following ways: 4873 a) By implementing the FL_PORT public loop interface specified in 4874 [FC-FLA], 4876 b) By emulating the private loop environment specified in [FC- 4877 AL2]. 4879 Private loop emulation allows the attachment of fibre channel 4880 devices that do not support fabrics or public loops. The gateway 4881 presents such devices to the fabric as though they were fabric- 4882 attached. Conversely, the gateway presents devices on the fabric, 4883 whether locally or remotely attached, as though they were connected 4884 to the private loop. 4886 Private loop support requires gateway emulation of the loop 4887 primitives and control frames specified in [FC-AL2]. These frames 4888 and primitives MUST be locally emulated by the gateway. Loop 4889 control frames MUST NOT be sent over an iFCP session. 4891 B.1 Remote Control of a Public Loop 4893 A gateway MAY disclose that a remotely-attached device is connected 4894 to a public loop. If so, it MUST also provide aliases representing 4895 the corresponding Loop Fabric Address (LFA), DOMAIN_ID and FL_PORT 4896 Address Identifier through which the public loop may be remotely 4897 controlled. 4899 The LFA and FL_PORT address identifier both represent an N_PORT 4900 that services remote loop management requests contained in the 4901 LINIT and SRL extended link service messages. To support these 4902 messages, the gateway MUST allocate an NL_PORT alias such that the 4903 corresponding alias for the LFA or FL_PORT address identifier can 4904 be derived by setting the Port ID component of the NL_PORT alias to 4905 zero. 4907 iFCP Revision 13 August 2002 4909 Full Copyright Statement 4911 "Copyright (C) The Internet Society, August 2002. All Rights 4912 Reserved. This document and translations of it may be copied and 4913 furnished to others, and derivative works that comment on or 4914 otherwise explain it or assist in its implementation may be 4915 prepared, copied, published and distributed, in whole or in part, 4916 without restriction of any kind, provided that the above copyright 4917 notice and this paragraph are included on all such copies and 4918 derivative works. However, this document itself may not be modified 4919 in any way, such as by removing the copyright notice or references 4920 to the Internet Society or other Internet organizations, except as 4921 needed for the purpose of developing Internet standards in which 4922 case the procedures for copyrights defined in the Internet 4923 Standards process must be followed, or as required to translate it 4924 into languages other than English. 4926 The limited permissions granted above are perpetual and will not be 4927 revoked by the Internet Society or its successors or assigns. 4929 This document and the information contained herein is provided on 4930 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4931 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4932 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4933 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4934 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4936 Notice of Intellectual Property Rights 4938 The IETF has been notified of intellectual property rights claimed 4939 in regard to some or all of the specification contained in this 4940 document. For more information consult the online list of claimed 4941 rights. 4943 iFCP Revision 13 August 2002