idnits 2.17.1 draft-ietf-ips-ifcp-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 647 has weird spacing: '...t Field iFC...' == Line 1490 has weird spacing: '...rt Name iFCP ...' -- 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 2001) is 8471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 32 looks like a reference -- Missing reference section? '2' on line 74 looks like a reference -- Missing reference section? 'FC-FS' on line 142 looks like a reference -- Missing reference section? 'FGS' on line 184 looks like a reference -- Missing reference section? 'FC-PH' on line 1979 looks like a reference -- Missing reference section? 'FC-PH-2' on line 1982 looks like a reference -- Missing reference section? 'FC-PH-3' on line 1985 looks like a reference -- Missing reference section? 'FCP-2' on line 1970 looks like a reference -- Missing reference section? 'SAM' on line 1955 looks like a reference -- Missing reference section? 'SAM-2' on line 1957 looks like a reference -- Missing reference section? 'SPC' on line 1960 looks like a reference -- Missing reference section? 'SPC-2' on line 1962 looks like a reference -- Missing reference section? 'FCP' on line 1967 looks like a reference -- Missing reference section? 'FC-FG' on line 1988 looks like a reference -- Missing reference section? 'FC-GS-2' on line 1991 looks like a reference -- Missing reference section? 'FC-AL' on line 1994 looks like a reference -- Missing reference section? 'FC-AL-2' on line 1997 looks like a reference -- Missing reference section? 'FC-PLDA' on line 2000 looks like a reference -- Missing reference section? 'FC-FLA' on line 2003 looks like a reference -- Missing reference section? 'FC-TAPE' on line 2006 looks like a reference -- Missing reference section? 'RFC768' on line 2011 looks like a reference -- Missing reference section? 'RFC791' on line 2013 looks like a reference -- Missing reference section? 'RFC1146' on line 2016 looks like a reference -- Missing reference section? 'RFC2401' on line 2020 looks like a reference -- Missing reference section? 'RFC2402' on line 2022 looks like a reference -- Missing reference section? 'RFC2406' on line 2024 looks like a reference -- Missing reference section? 'RFC2407' on line 2026 looks like a reference -- Missing reference section? 'RFC2408' on line 2028 looks like a reference -- Missing reference section? 'RFC2409' on line 2031 looks like a reference -- Missing reference section? 'RFC2460' on line 2033 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Storage Working Group Charles Monia 2 INTERNET DRAFT Rod Mullendore 3 Expires August 2001 Josh Tseng 4 Nishan Systems 6 Franco Travostino 7 Nortel Networks 9 David Robinson 10 Sun Microsystems 12 Wayland Jeong 13 Troika Networks 15 Rory Bolt 16 Quantum/ATL 18 Paul Rutherford 19 ADIC 21 Mark Edwards 22 Eurologic 24 February 2001 26 iFCP - A Protocol for Internet Fibre Channel Storage Networking 28 Status of this Memo 30 This document is an Internet-Draft and is in full conformance with 31 all provisions of Section 10 of RFC2026 [1]. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. Internet-Drafts are draft documents valid for a maximum of 37 six months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as "work in 40 progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Comments 50 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 51 or to the author(s). 53 Monia, et al. Standard Track 1 54 1. Abstract 56 This document specifies iFCP, a gateway-to-gateway protocol for the 57 implementation of a Fibre Channel fabric in which TCP/IP switching 58 and routing elements replace Fibre Channel components. The 59 protocol enables the attachment of existing Fibre Channel storage 60 products to an IP network by supporting the subset of fabric 61 services required by such devices. 63 The encapsulation described in this version of the document is 64 obsolete. It will be replaced by an encapsulation format which 65 will be common to both the iFCP and FCIP protocols. 67 2. About This Document 69 2.1 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 73 this document are to be interpreted as described in RFC-2119 [2]. 75 All frame formats are in big endian network byte order. 77 2.2 Purpose of this document 79 This is a standards-track document, which specifies a protocol for 80 the implementation of Fibre Channel transport services on a TCP/IP 81 network. Some portions of this document contain material from 82 standards controlled by NCITS T10 and T11. This material is 83 included here for informational purposes only. The authoritative 84 information is given in the appropriate NCITS standards document. 86 The authoritative portions of this document specify the protocol 87 for mapping standards-compliant fibre Channel storage and adapter 88 implementations to TCP/IP. This mapping includes sections of this 89 document which describe the "iFCP Layer" (see section 4.1). 91 The Fibre Channel frame encapsulation described in section 5 of 92 this document is of general applicability, and can be used for 93 other applications that transport Fibre Channel frames over TCP. 94 One example of an alternate protocol which can leverage this 95 encapsulation is the FCIP tunneling protocol. FCIP, and other 96 examples of Fibre Channel protocols, are described in the 97 appendicies of this document. 99 3 iFCP Introduction 101 iFCP is a gateway-to-gateway protocol, which provides Fibre Channel 102 fabric services to FCP-based Fibre Channel devices over a TCP/IP 103 network. iFCP uses TCP to provide congestion control, error 104 detection and recovery. iFCP's primary objective is to allow 106 Monia Standards Track 2 107 interconnection and networking of existing Fibre Channel devices at 108 wire speeds over an IP network. 110 The protocols and method of frame translation described in this 111 document permit the transparent attachment of Fibre Channel storage 112 devices to an IP-based fabric by means of lightweight gateways. 114 The protocol achieves this transparency through an address 115 translation process that allows normal frame traffic to pass 116 through the gateway directly, with provisions for intercepting and 117 emulating the fabric services required by an FCP device. 119 3.1 Definitions 121 Terms needed to clarify the concepts presented in this section are 122 presented here. 124 Fibre Channel Network - A fabric and all attached Fibre Channel 125 devices. 127 Fabric - The part of a Fibre Channel network which provides the 128 transport services defined in the FC-FS specification. A fabric may 129 be implemented in the IP framework by means of the architecture and 130 protocols discussed in this document. 132 FC-2 - The Fibre Channel transport services layer described in the 133 FC-FS specification. 135 FCP Portal - An IP-addressable entity representing the point at 136 which a logical or physical iFCP device is attached to the IP 137 network. 139 N_PORT - An iFCP or Fibre Channel entity representing the interface 140 to Fibre Channel device functionality. This interface implements 141 the Fibre Channel N_PORT semantics specified in the FC-FS standard 142 [FC-FS]. 144 N_PORT fabric address - The address of an N_PORT within the Fibre 145 Channel fabric. 147 N_PORT Network Address - The address of an N_PORT in the IP fabric. 148 This address consists of the IP address of the FCP Portal and the 149 N_PORT ID of the directly-attached Fibre Channel device. 151 F_Port - The interface used by an N_PORT to access Fibre Channel 152 fabric and fabric services functionality. 154 iFCP - The protocol discussed in this document. 156 Logical FCP Device - The abstraction representing a single Fibre 157 Channel device as it appears on an iFCP network. 159 Monia Standards Track 3 160 iSNS - The protocol by which storage name services are implemented. 161 Resolution of Fibre Channel network object names is provided by an 162 iSNS name server. 164 N_PORT Session - An association created when two N_PORTS have 165 executed a PLOGI operation. It is comprised of the N_PORTs and TCP 166 connection that carries traffic between them. 168 iFCP Frame - The frame inserted into the TCP stream which contains 169 the Fibre Channel frame and iFCP header. 171 Port Login (PLOGI) - The Fibre Channel Extended Link Service (ELS) 172 that establishes an N_PORT login session through the exchange of 173 identification and operation parameters between an originating 174 N_PORT and a responding N_PORT. 176 3.2 The iFCP Network Model 178 The following diagram shows a Fibre Channel fabric with attached 179 devices. These are connected to the fabric through N_PORT and 180 F_PORT interfaces, whose behavior is specified in [FGS]. 182 Within the Fibre Channel device domain, fabric-addressable entities 183 consist of other N_PORTs and devices internal to the fabric that 184 perform the fabric services defined in [FGS]. In this case, the 185 N_PORT Fibre Channel addresses are 24-bit quantities that are 186 unique within the scope of the FC fabric. N_PORTs that perform 187 fabric services are assigned well-known addresses starting at the 188 top end of the 24-bit Fibre Channel address space. 190 Fibre Channel Network 192 +--------+ +--------+ 193 | FC | | FC | 194 | Device | | Device | 195 |........| |........| Fibre Channel 196 | N_PORT |<------>| N_PORT | Device Domain 197 +---+----+ +----+---+ ^ 198 | | | 199 +---+----+ +----+---+ | 200 | F_PORT | | F_PORT | | 201 ==========+========+========+========+============== 202 | Fabric & | | 203 | Fabric Services | v 204 | | Fibre Channel 205 +--------------------------+ Fabric Domain 207 Monia Standards Track 4 208 An iFCP Network with iFCP Gateways 210 Fibre Channel Devices Fibre Channel Devices 211 +--------+ +--------+ +--------+ +--------+ 212 | FC | | FC | | FC | | FC | 213 | Device | | Device | Fibre | Device | | Device | Fibre 214 |........| |........| Channel |........| |........| Channel 215 | N_PORT | | N_PORT |<--------->| N_PORT | | N_PORT | Device 216 +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain 217 | | | | ^ 218 +---+----+ +---+----+ +----+---+ +----+---+ | 219 | F_PORT | | F_PORT | | F_PORT | | F_PORT | | 220 =+========+==+====================+========+==+========+========== 221 | iFCP Layer |<--------->| iFCP Layer | | 222 |....................| ^ |....................| | 223 | FCP Portal | | | FCP Portal | v 224 +--------+-----------+ | +----------+---------+ IP Fabric 225 | Control | 226 | Data | 227 | | 228 | | 229 |<------Encapsulated Frames------->| 230 | +------------------+ | 231 | | | | 232 +------+ IP Network +--------+ 233 | | 234 +------------------+ 236 The above diagram shows the simplest implementation of an 237 equivalent iFCP fabric. Here, Fibre Channel devices are directly 238 connected to the iFCP fabric through F_PORTs implemented as part of 239 the edge switch or gateway. At the N_PORT interface on the Fibre 240 Channel side of the gateway, the network appears as a Fibre Channel 241 fabric. Here, the gateway presents remote N_PORTs as directly 242 attached devices. Conversely, on the IP-side, the gateway presents 243 each locally-connected N_PORT as a logical iFCP device on the IP 244 network. 246 An important property of this gateway architecture is that the 247 fabric configuration and topology on the FC-side are opaque to the 248 IP network. Consequently, support for FC fabric topologies, such 249 as switches or loops, becomes a gateway implementation option. In 250 such cases, the gateway incorporates whatever functionality is 251 required to distil and present locally attached N_PORTs (or 252 NL_PORTs) as logical iFCP devices. 254 N_PORT to N_PORT communications that traverse a TCP/IP network 255 require the intervention of the iFCP layer. This is done through 256 the following operations on Fibre Channel frames: 258 a) For outbound frames, translate Fibre Channel fabric addresses 259 imbedded in FC frames to N_PORT Network Addresses. 261 Monia Standards Track 5 262 b) For inbound frames, translate N_PORT Network Addresses to Fibre 263 Channel fabric addresses. 264 c) Redirect requests for fabric-supplied link services addressed to 265 one of the well-known Fibre Channel N_PORT addresses. 266 d) Generate control data in response to certain link service 267 requests or fabric control operations as described in section 268 7.1. 269 e) Encapsulate Fibre Channel frames for injection into the TCP/IP 270 network and de-encapsulate Fibre Channel frames received from 271 the TCP/IP network. 272 f) Direct de-encapsulated, FC frames to the appropriate N_PORT. 274 After address translation on outbound FC frames, the emulation 275 process generates two types of encapsulated FC frame traffic: 277 a) FC frames to be passed between N_PORTs unchanged, except for the 278 address field modifications described below. 279 b) Augmented FC frames generated in response to N_PORT Link Service 280 requests. These frames are passed between the iFCP layers. For 281 N_PORT link service requests, iFCP may modify the payload to 282 perform these operations in an IP fabric. 284 Control traffic is also generated in order to perform certain peer- 285 to-peer operations among FCP Portals, such as TCP/IP connection 286 setup and management. 288 3.3 Fibre Channel Frame Address Translation 290 An iFCP gateway is responsible for the mapping between N_PORT Fibre 291 Channel addresses and N_PORT network addresses in the IP fabric. 293 In the IP fabric, the network address of a N_PORT has two 294 components: the IP address of the FCP Portal to which the Fibre 295 Channel device is attached and an N_PORT ID that is unique within 296 the scope of the FCP Portal. When an FC frame is in transit, the 297 IP components of the source and destination FCP Portals are implied 298 from the TCP/IP connection context. The source and destination 299 N_PORT IDs are stored in the corresponding N_PORT address fields 300 that are part of the FC frame. 302 The iFCP gateway is responsible for assigning Fibre Channel N_PORT 303 IDs to directly-attached N_PORTs. 305 For external N_PORTs, the iFCP gateway is also responsible for 306 assigning an internal key used to look up the N_PORT network 307 address for the external device. To perform this function a 308 gateway or edge switch maintains a table which maps frame traffic 309 to the appropriate TCP/IP connection and N_PORT ID of all external 310 N_PORTs with active sessions. 312 The gateway builds the store of N_PORT network addresses for 313 external devices in the IP fabric by: 315 Monia Standards Track 6 316 a) Intercepting name service requests issued by directly-attached 317 N_PORTs and redirecting them to the iSNS name server or, 319 b) Intercepting incoming N_PORT login requests from external Fibre 320 Channel devices. 322 The TCP/IP connection context to a given FCP Portal may be 323 established during fabric initialization. 325 Subsequently, in response to name server requests, the iSNS server 326 returns the IP address and N_PORT ID pair. The IP address is mapped 327 to the connection context. After saving the context and N_PORT ID, 328 the iFCP layer then creates a 24-bit key that is returned to the 329 local N_PORT as the Fibre Channel address of the external device. 331 For outbound frames, the table of external N_Port network addresses 332 are referenced to map the Destination N_PORT address key and Source 333 N_PORT ID to a TCP connection identifier and N_PORT ID. The 334 translation process for outbound frames is shown below. 336 Raw Fibre Channel Frame 337 +--------+-----------------------------------+ +--------------+ 338 | | Destination N_PORT Address Key |---->| Lookup TCP | 339 +--------+-----------------------------------+ | connection | 340 | | Source N_PORT ID |---->| and N_PORT ID| 341 +--------+-----------------------------------+ +------+-------+ 342 | | | TCP 343 | Control information | | Conn 344 | and Payload | | & 345 +--------------------------------------------+ | N_PORT 346 | ID 347 | 348 After Address Translation and TCP/IP Encapsulation | 349 +--------------------------------------------+ Conn | 350 | iFCP Encapsulation |<-----------+ 351 | Header | Context | 352 +========+===================================+ | 353 | | Destination N_PORT ID |<-----------+ 354 +--------+-----------------------------------+ 355 | | Source N_PORT ID | 356 +--------+-----------------------------------+ 357 | | 358 | Control information | 359 | and Payload | 360 +--------------------------------------------+ 362 For inbound frames, the store regenerates the internal address key 363 from the TCP connection context and N_PORT ID contained in the 364 encapsulated FC frame. The translation process for inbound frames 365 is shown below. 367 Monia Standards Track 7 368 Network Format of Inbound Frame 369 +--------------------------------------------+ Conn. +---------+ 370 | iFCP Encapuslation Header |------>| Address | 371 | |Context| Key | 372 +========+===================================+ | Lookup | 373 | | Destination N_PORT ID | | | 374 +--------+-----------------------------------+ | | 375 | | Source N_PORT ID |------>| | 376 +--------+-----------------------------------+ +-----+---+ 377 | | |Address 378 | Control information | | Key 379 | and Payload | | 380 +--------------------------------------------+ | 381 | 382 | 383 | 384 Frame after Address Translation and De-encapsulation | 385 +--------+-----------------------------------+ | 386 | | Destination N_PORT ID | | 387 +--------+-----------------------------------+ | 388 | | Source N_PORT Key |<------------+ 389 +--------+-----------------------------------+ 390 | | 391 | Control information | 392 | and Payload | 393 +--------------------------------------------+ 395 3.4 iFCP Layered Services 397 The following diagram shows the functional layers for host devices 398 that support FCP. 400 As shown, iFCP provides a set of layered services that 401 transparently provide the transport services required by FCP 402 devices. Using the iFCP framework, any existing host FCP 403 implementation will execute with no modifications required. 405 The iFCP protocol layer consists of the data transport services and 406 iFCP-specific Link Services. This layer provides transport 407 services specific to Fibre Channel devices as specified in [FC-PH], 408 [FC-PH-2], and [FC-PH-3]. 410 This is illustrated in the following diagram, which shows the IP 411 Fabric consisting of the TCP/IP network and the iFCP Layer. The IP 412 Fabric provides the transport services for FCP, and is a direct 413 replacement for the transport services provided by a Fibre Channel 414 fabric. Meanwhile, the components in the Fibre Channel Device 415 Domain remain unchanged. 417 Monia Standards Track 8 418 +---------------------------------------+ - - - - - - - 419 | Storage & Backup Applications | 420 +---------------------------------------+ 421 | Operating System | Application 422 +--------------------+ | Layer 423 | SCSI | | 424 +--------------------+ | - - - - - - - 425 | FCP | | FC-4 Layer 426 +------------+-------+------------------+ - - - - - - - 427 | | Link Services | 428 | +--------------------------+ FC-2 Layer ^ 429 | | | 430 | N_PORT - F_PORT Interface | Fibre Channel 431 | | Device Domain 432 <=============================================================> 433 | | IP Fabric 434 | iFCP Data Transport Service | | 435 | | v 436 | +---------------+ 437 | |iFCP Specific | iFCP Layer 438 | |Link Services | 439 +-----------------------+---------------+ - - - - - - 440 | | 441 | TCP | Transport 442 | | Layer 443 +---------------------------------------+ - - - - - - 444 | | 445 | IP | Network 446 | | Layer 447 +---------------------------------------+ - - - - - - 448 | | 449 | Physical Transport | Link Layer 450 | | 451 +---------------------------------------+ - - - - - - 453 In the figure shown above, each layer leverages the services of the 454 layer below it. 456 3.4.1 Application Layer 458 This includes the operating system, Storage and Backup 459 applications, and the SCSI driver. This layer interfaces with FCP 460 and Link Services in the FC-2 and FC-4 layers. 462 3.4.2 FC-4 Layer (FCP) 464 FCP is the Fibre Channel FC-4 layer application protocol used to 465 communicate with devices implementing the SCSI-3 command set and 466 architectural model. Basically, FCP divides each SCSI I/O operation 467 into a series of information units to be transferred between the 468 initiator and target. 470 Monia Standards Track 9 471 3.4.3 FC-2 Layer 473 The FC-2 Layer provides the facilities for Link Services and 474 transfer of Fibre Channel information units as described below. 476 3.4.3.1 Link Service Messages 478 Fibre Channel defines a series of link services defined in Fibre 479 Channel Physical and Signaling Interface specification (FC-PH, FC- 480 PH-2, FC-PH-3). These Link Service Messages provide a set of 481 defined functions that allow a Fibre Channel port to send control 482 information, or to request another port to perform a specific 483 function. Some Link Service messages reference services provided 484 internally within the Fibre Channel fabric. 486 3.4.3.2 N_PORT Interface 488 This is an interface which provides access to Fibre Channel device 489 functionality. The N_PORT interface is responsible for 490 segmentation and reassembly of information units from Fibre Channel 491 frames. 493 3.4.3.3 F_PORT Interface 495 This is the interface through which the N_PORT accesses the Fibre 496 Channel fabric. 498 3.4.4 iFCP Layer 500 The iFCP layer provides three essential services for FCP-based 501 storage products: 503 a) Transport of Fibre Channel frames and Link Service messages 504 between N_PORTs. 506 b) Support for special Link Service messages needed by iFCP to 507 manage the transmission of storage data on a IP network. 509 c) Augmentation of some Link Service messages with additional data 510 needed in the iFCP environment. 512 The iFCP layer maps Fibre Channel frames to a predetermined TCP 513 connection for transport. Additionally, many link service messages 514 can similarly be transported without modification over a TCP 515 connection. 517 4. iFCP Protocol 519 4.1 Overview 521 4.1.1 iFCP Transport Services 523 Monia Standards Track 10 524 The iFCP transport services map the Fibre Channel frames comprising 525 each FCP IU and Link Service message to a predetermined TCP 526 connection for transport across an IP network. When receiving FCP- 527 based storage data from the network, the iFCP layer transports, and 528 delivers each resulting frame to the appropriate N_PORT via the 529 F_PORT. The iFCP layer never interprets the contents of the frame 530 payload. 532 For incoming iFCP frames with control data, iFCP interprets the 533 augmented information in the iFCP header, modifies the frame 534 content accordingly, and may forward the resulting frame to the 535 N_PORT for further processing. 537 For out-bound Fibre Channel frames that require control data, the 538 iFCP layer creates the augmented information based on frame 539 content, modifies the frame content, then transmits the resulting 540 Fibre Channel frame with augmented iFCP header through the 541 appropriate TCP connection. 543 4.1.2 iFCP Support for Link Services 545 Some Link Service messages reference constructs which are specific 546 to the Fibre Channel fabric environment, but are irrelevant in the 547 context of an IP fabric. When iFCP encounters such messages, it 548 will augment the information in the payload by adding additional 549 information in the iFCP header. The receiving iFCP layer will 550 reference the augmented information in order to reconstruct the 551 original Link Service message. The reconstructed frames are then 552 forwarded to the receiving N_PORT for further processing. 554 Section 7.1 describes augmented Link Services. 556 4.3 Mandatory FC-2 Functionality 558 [To be specified] 560 4.4 FC-2 Functionality Not Supported 562 [To be specified] 564 4.5 Optional FC-2 Functionality 566 [To be specified] 568 5. Encapsulation of Fibre Channel frames 570 This section describes the encapsulation method used for iFCP. 571 This encapsulation method may be leveraged for other applications 572 which transport Fibre Channel over TCP. 574 The frame encapsulation format is shown below. The iFCP header 575 encapsulates the iFCP payload containing the Fibre Channel frame. 577 Monia Standards Track 11 578 The length of the iFCP frame depends on the size of the 579 encapsulated Fibre Channel frame and the amount of augmentation 580 data (if any) in the iFCP header. Each Fibre Channel frame, in 581 turn, is comprised of a Fibre Channel header and payload whose 582 format is specified in the appropriate Fibre Channel standards [FC- 583 PH]. 585 Fibre Channel primitive signals (IDLE, R_RDY, ARB, OPN, CLS, and 586 MRK) and primitive sequences (OLS, NOS, LR, LRR, LIP, LPB, and LPE) 587 are stripped off and not encapsulated by iFCP. Fibre Channel frame 588 delimiters SOF and EOF are preserved by encoding them into a one- 589 byte opcode for transport in the iFCP header. 591 Byte MSb LSb 592 Offset 7 6 5 4 3 2 1 0 593 +----------------------------------+ - - - - - - - - - - - 594 0 | iFCP Header | N Bytes ^ 595 +----------------------------------+ - - - - - - - - | 596 | | ^ iFCP 597 N / Fibre Channel Header / 24 Bytes | Frame 598 | (described in section 5.1) | | | 599 +----------------------------------+ Fibre | 600 N+24 | | Channel | 601 / Fibre Channel Payload / L Bytes Frame | 602 | | | | 603 +----------------------------------+ | | 604 4 | iFCP CRC | | | 605 +----------------------------------+ - - - - - - - - - - - 606 Total Length = 28 + N + L 608 5.1 iFCP Header 610 The iFCP header for TCP is shown below. 612 |3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1|1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0| 613 |1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| 614 +-------+-------+---------------+-------------------------------+ 615 | CLASS | VERS | HEADER MARKER | FLAGS | 616 +-------+-------+---------------+-------------------------------+ 617 | iFCP HEADER LENGTH | iFCP DATA LENGTH | 618 +-------------------------------+-------------------------------+ 619 | HEADER CHECKSUM OR CRC (if present) | 620 +---------------------------------------------------------------+ 621 | iFCP AUGMENTATION DATA (if present) | 622 +---------------------------------------------------------------+ 624 CLASS - This 4-bit field indicates the class of service. Only the 625 values 2 and 3 are allowed and are equivalent to the class of 626 service for Fibre Channel. 628 VERS - This 4-bit field indicates the iFCP protocol version. The 629 version number shall be 1. 631 Monia Standards Track 12 632 HEADER MARKER - This 8-bit field shall be 0xAA if the HEADER 633 CHECKSUM OR CRC field contains the 32-bit header CRC field, 0xC3 if 634 the HEADER CHECKSUM OR CRC field contains a 32-bit header checksum, 635 or 0x3C if the HEADER CHECKSUM OR CRC field does not exist in the 636 header. Any other value in the HEADER MARKER indicates an error, 637 and shall result termination of the TCP connection in which the 638 error occurred. 640 FLAGS - This 16-bit field contains status flags that indicate 641 various parameters for the data frame. 643 iFCP HEADER LENGTH - This 16-bit field contains the length in 4- 644 byte words of the iFCP HEADER, including the iFCP AUGMENTATION DATA 645 field (if present) and the CHECKSUM OR CRC field (if present). 647 Bit Field iFCP Flag Description 648 --------- --------- ----------- 649 15 SEQUENCE END Indicates if frame terminates a 650 sequence. For Class 3 sequences, the 651 FCP_Portal sets this bit on 652 the last frame of the sequence. In 653 Class 2 sequences, this bit is set by 654 the recipient in the ACK frame that 655 terminates the sequence. 656 1=Last frame of sequence, 0=not 658 14 SEQUENCE START Indicates if frame is the first frame 659 of a sequence. 660 1=First frame of sequence, 0=not 662 13 non-iFCP This field indicates if the 663 payload contains a Fibre Channel frame 664 encapsulated for a non-iFCP compatible 665 application. An iFCP-compliant 666 implementation MUST discard the 667 frame if this bit is enabled. 668 1=non-iFCP compatible 0=iFCP compatible 670 9-12 RESERVED FOR NON-COMPATIBLE APPLICATIONS (see appendix A) 672 4-8 RESERVED FOR iFCP 674 3 iFCP DATA CRC Indicates if a trailing 32-bit CRC is 675 present at the end of the iFCP frame. 676 The CRC shall cover the iFCP payload, 677 with includes the Fibre Channel header 678 and Fibre Channel payload. 679 1=CRC present, 0=Not 681 Monia Standards Track 13 682 2 TCP ELS Indicates frame contains a TCP-specific 683 Link Service message. 684 1=TCP ELS, 0=Not 686 1 AUGMENTATION Indicates the iFCP Augmentation Data 687 PRESENT field is present in the iFCP header. 688 1=Present, 0=Not 690 0 COMPLIANCE This bit must be enabled. 691 1=Enabled, 0=Not 693 iFCP DATA LENGTH - This 16-bit field contains the length in 4-byte 694 words of the iFCP payload. This includes the FCP or Link Service 695 headers and the iFCP trailing CRC (if present), but does not 696 include the iFCP AUGMENTED DATA field or any other portion of the 697 iFCP Header. 699 HEADER CHECKSUM OR CRC - The presence and contents of this 32-bit 700 field is indicated by the HEADER MARKER field. If this field 701 contains a CRC, it shall be calculated over the iFCP header from 702 the CLASS field to the iFCP DATA LENGTH field (inclusive). The CRC 703 shall not include the iFCP AUGMENTED DATA. The CRC algorithm is 704 the same used for the Frame Check Sequence (FCS) of IEEE 802.3 705 Ethernet frames. If this field contains a Checksum, it shall be a 706 32-bit checksum calculated over the iFCP header from the CLASS 707 field to the iFCP DATA LENGTH field (inclusive). The checksum 708 shall not include the iFCP AUGMENTED DATA. 710 iFCP AUGMENTATION DATA - This is a variable-length field containing 711 augmentation data required for transport of some Link Service 712 messages over TCP/IP. 714 5.2 Fibre Channel Frame Header 716 The Fibre Channel frame header defined in FC-PH is used when 717 transporting FCP and Link Service frames in an IP fabric. Use of 718 the Fibre Channel frame header simplifies the connection of Fibre 719 Channel devices to a iFCP storage network. In iFCP, the only 720 modification to the basic Fibre Channel frame header is that the 721 contents of D_ID and S_ID fields are replaced with Destination and 722 Source N_PORT IDs as described in section 3.3. 724 The figure below shows the format of the header used for both FCP 725 and Link Service frames. The contents of D_ID and S_ID fields have 726 been replaced by the Destination and Source N_PORT IDs. 728 Monia Standards Track 14 729 3 3 3 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 730 |1 0 9 8 7 6 5 4|3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8|7 6 5 4 3 2 1 0| 731 +---------------+-----------------------------------------------+ 732 | R_CTL | Destination N_PORT ID | 733 +---------------+-----------------------------------------------+ 734 | CS_CTL | Source N_PORT ID | 735 +---------------+-----------------------------------------------+ 736 | Type | F_CTL | 737 +---------------+---------------+-------------------------------+ 738 | SEQ_ID | DF_CTL | SEQ_CNT | 739 +---------------+---------------+-------------------------------+ 740 | OX_ID | RX_ID | 741 +-------------------------------+-------------------------------+ 742 | PARAMETER | 743 +---------------------------------------------------------------+ 745 Other than Source and Destination N_PORT ID, descriptions of each 746 of the above fields can be found in [FC-PH]. 748 5.2.1 Destination N_PORT ID 750 This 24-bit value is stored in the Fibre Channel D_ID field. The 751 destination IP address, combined with the Destination N_PORT ID, 752 specifies the unique N_PORT network address of the device receiving 753 the Fibre Channel frame. 755 5.2.2 Source N_PORT ID 757 This 24-bit value is stored in the Fibre Channel S_ID field. The 758 source IP address, combined with the Source N_PORT ID specifies the 759 unique N_PORT network address of the device originating the Fibre 760 Channel frame. 762 5.3 Trailing iFCP CRC 764 This original Fibre Channel CRC shall not be encapsulated into the 765 iFCP message. Rather, iFCP MAY use a 32-bit field containing a CRC 766 calculated over the data contained in the frame from the iFCP 767 AUGMENTED DATA to the iFCP Payload (inclusive). This includes the 768 Fibre Channel header and payload. The iFCP CRC follows the iFCP 769 payload, and the CRC algorithm is the same used for the Frame Check 770 Sequence (FCS) of IEEE 802.3 Ethernet frames. A bit in the iFCP 771 FLAGS field in the iFCP header indicates the presence or absence of 772 this 32-bit trailing CRC. 774 6. TCP Stream Transport of iFCP Frames 776 TCP connections MAY be established between FCP_Portals that have 777 discovered each other through a naming service or through manual 778 configuration. If a TCP connection is not maintained between the 779 FCP_Portals, then a change in the status of remote N_PORTs must be 780 discovered through a central name server authority. 782 Monia Standards Track 15 783 Multiple TCP connections may exist between pairs of FCP Portals. 784 Such connections are either "bound" or "unbound". An unbound 785 connection is a TCP connection that is not actively supporting an 786 N_PORT login session. Pre-existing TCP connections between FCP 787 Portals remain unbound and uncommitted until a CBIND message (see 788 section 7.2.2) has been transmitted through them. 790 When the iFCP layer detects a Port Login (PLOGI) message creating a 791 login session between a pair of N_PORTs, it will select an existing 792 TCP connection (bound or unbound) or establish a new TCP 793 connection, and send the CBIND message down that TCP connection. 794 This allocates the TCP connection to that PLOGI login session. 795 Optionally, a TCP connection may be bound to more than one N_PORT 796 login session. 798 6.1 TCP Session Model 800 iFCP uses a single TCP connection to transport all Fibre Channel 801 frames between unique pairs of N_PORTs. 803 6.2 TCP Port Numbers 805 An FCP Portal uses a single port number to receive TCP connection 806 requests for iFCP over TCP. All TCP connections established 807 between FCP Portals must be directed to the registered well known 808 port number assigned by the IANA. Note that control and data 809 connections are established to the same port number with CBIND 810 messages used to distinguish the connection type. 812 An FCP Portal may use any TCP port number consistent with its 813 implementation of the TCP/IP stack to initiate a TCP connection, 814 but each port number must be unique. 816 7. Link Services 818 The link services provide a set of functions that allow a port to 819 send control information or request another port to perform a 820 specific function. 822 Each Link Service message (response and reply) is carried by a 823 Fibre Channel sequence, and can be segmented into multiple frames. 825 The iFCP Layer is responsible for transporting Link Service 826 messages across the IP fabric. This includes mapping Link Service 827 messages appropriately from the domain of the Fibre Channel 828 transport to that of the IP network. This process may involve 829 manipulation of field values as the Link Service message travels to 830 and from the IP and Fibre Channel fabrics. It also may involve the 831 inclusion of additional control data through use of the 832 AUGMENTATION DATA field in the iFCP header in order to make the 833 Link Service message significant in the IP fabric domain. 835 Monia Standards Track 16 837 [Editor's Note: The method for processing multi-frame Link Service 838 messages will be detailed in a subsequent draft] 840 7.1 Augmented Link Service Messages 842 The following Link Service Messages must be augmented with 843 additional control data carried in the iFCP header. When the iFCP 844 header encapsulates one of these Link Service messages in the iFCP 845 payload, the AUGMENTATION PRESENT bit must be enabled in the iFCP 846 FLAGS field, and the iFCP HEADER LENGTH must be adjusted 847 appropriately to account for the additional augmentation data in 848 the iFCP header. In addition, many ACC responses to the following 849 Link Service messages must also have control data carried in the 850 encapsulating iFCP header. 852 Link Service Message LS_COMMAND Short Name 853 -------------------- ---------- ---------- 854 Port Login 0x03000000 PLOGI 855 Read Exchange Status Block 0x08000000 RES 856 Read Sequence Status Block 0x09000000 RSS 857 Request Sequence Initiative 0x0A000000 RSI 858 Reinstate Recovery Qualifier 0x12000000 RRQ 859 Read Exchange Concise 0x13000000 REC 860 Third Party Process Logout 0x24 TPRLO 861 Discover Address 0x52000000 ADISC 863 The above Link Service messages use N_PORT fabric addresses in 864 their message format, and must have the corresponding World Wide 865 Port name (WWPN) carried in the AUGMENTATION DATA field of the iFCP 866 header. The N_PORT fabric address field shall then be cleared 867 while the Link Service message is carried in the iFCP frame. Upon 868 receipt of the iFCP frame, the iFCP layer shall use the WWPN data 869 in the iFCP header to replace the original N_PORT fabric address 870 with the appropriate value. 872 The following sections describe the contents and format of the iFCP 873 AUGMENTATION DATA field in the iFCP header. Note that if 874 appropriate, the augmentation may also apply to the corresponding 875 ACC or LS_RJT reply. 877 7.1.1 Port Login (PLOGI) 879 PLOGI provides the mechanism for establishing a login session 880 between two N_PORTs. The PLOGI request carries information 881 identifying the originating N_PORT, including specification of its 882 capabilities and limitations. If the destination N_PORT accepts 883 the login request, it sends an accept (an ACC frame with PLOGI 884 payload), specifying its capabilities and limitations. This 885 exchange establishes the operating environment for the two N_PORTs. 887 Monia Standards Track 17 888 The following figure is duplicated from FC-PH, and shows the PLOGI 889 message format for both request and accept (ACC) response. A port 890 will reject a PLOGI request by transmitting an LS_RJT message, 891 which contains no payload. 893 Byte MSb LSb 894 Offset 7 6 5 4 3 2 1 0 895 +----------------------------------+ 896 0 | LS_COMMAND | 4 Bytes 897 +----------------------------------+ 898 4 | COMMON SERVICE PARAMETERS | 16 Bytes 899 +----------------------------------+ 900 20 | PORT NAME | 8 Bytes 901 +----------------------------------+ 902 28 | NODE NAME | 8 Bytes 903 +----------------------------------+ 904 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes 905 +----------------------------------+ 906 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes 907 +----------------------------------+ 908 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes 909 +----------------------------------+ 910 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes 911 +----------------------------------+ 912 102 | VENDOR VERSION LEVEL | 16 Bytes 913 +----------------------------------+ 914 Total Length = 118 916 Details on the above fields, including common and class-based 917 service parameters, can be found in [FC-PH]. The above PLOGI 918 message is transported by the iFCP layer without modification. 919 However, additional accompanying information must be carried in the 920 encapsulating iFCP header. 922 The iFCP AUGMENTED DATA field in the iFCP header shall contain the 923 following information: 925 Byte MSb LSb 926 Offset 7 6 5 4 3 2 1 0 927 +----------------------------------+ 928 0 | DEVICE TYPE | 4 Bytes 929 +----------------------------------+ 930 Total Length = 4 932 DEVICE TYPE - This field contains a value indicating the type of 933 device. The allowed values are shown in the following table. A 934 Parallel SCSI type is assumed to be attached by a SCSI-iFCP Router, 935 while a Fibre Channel device is assumed to be attached by an iFCP 936 Edge Switch. iSCSI and mFCP devices are native IP-based storage 937 devices. 939 Monia Standards Track 18 940 DEVICE TYPE 941 Bit Field Device Type Values 942 --------- ------------------ 943 7:4 RESERVED 944 3 iSCSI DEVICE 945 2 mFCP DEVICE 946 1 FIBRE CHANNEL DEVICE 947 0 PARALLEL SCSI DEVICE 949 7.1.2 Third Party Process Logout (TPRLO) 951 TPRLO provides a mechanism for an N_PORT (third party) to remove 952 one or more login sessions that exists between the destination 953 N_PORT and other N_PORTs specified in the command. This command 954 includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which 955 when combined with the destination N_PORT identifies a SCSI login 956 session which shall be terminated by the command. 958 Byte MSb LSb 959 Offset 7 6 5 4 3 2 1 0 960 +----------------------------------+ 961 0 | LS_COMMAND | 1 Byte 962 +----------------------------------+ 963 1 | PAGE LENGTH (0x10) | 1 Byte 964 +----------------------------------+ 965 2 | PAYLOAD LENGTH (0x14) | 2 Bytes 966 +----------------------------------+ 967 4 | TPRLO LOGOUT PARAMETER PAGE 1 | 2-4 Bytes 968 +----------------------------------+ 969 | . . . . | M Bytes 970 +----------------------------------+ 971 | TPRLO LOGOUT PARAMETER PAGE N | 2-4 Bytes 972 +----------------------------------+ 973 Total Length = Variable 975 Each TPRLO LOGOUT PARAMETER PAGE identifies a remote N_PORT which 976 when combined with the destination N_PORT identifies a SCSI session 977 to be terminated. The TPRLO LOGOUT PARAMETER PAGE is of the 978 following format: 980 Monia Standards Track 19 981 Byte MSb LSb 982 Offset 7 6 5 4 3 2 1 0 983 +----------------------------------+ 984 0 | TYPE CODE | 1 Byte 985 +----------------------------------+ 986 1 | TYPE CODE EXTENSION | 1 Byte 987 +----------------------------------+ 988 2 | TPRLO FLAGS | 2 Bytes 989 +----------------------------------+ 990 4 | ORIG PROCESS ASSOC (if present) | 4 Bytes 991 +----------------------------------+ 992 8 | RESP PROCESS ASSOC (if present) | 4 Bytes 993 +----------------------------------+ 994 12 | RESERVED | 1 Byte 995 +----------------------------------+ 996 13 | THIRD PARTY ORIGINATOR N_PORT ID | 3 Bytes 997 +----------------------------------+ 999 When the iFCP header contains a TPRLO message (including the ACC 1000 response), the iFCP AUGMENTED DATA field will contain the 1001 PORT_NAME(s) (WWPN) identifying the N_PORT described by the 1002 equivalent TPRLO LOGOUT PARAMETER PAGE(s). If more than one TPRLO 1003 LOGOUT PARAMETER PAGE is contained in the Link Service message, 1004 equivalent additional PORT_NAME shall also be carried in the iFCP 1005 AUGMENTED DATA field. PORT_NAMEs shall be listed in the same order 1006 as the equivalent TPRLO LOGOUT PARAMETER PAGEs in the original Link 1007 Service message. 1009 The following diagram describes the PORT_NAME entries in the iFCP 1010 AUGMENTATION DATA field in the iFCP header: 1012 Byte MSb LSb 1013 Offset 7 6 5 4 3 2 1 0 1014 +----------------------------------+ 1015 0 | 3rd PARTY ORIG PORT NAME 1 | 8 Bytes 1016 +----------------------------------+ 1017 8 |3rd PTY ORIG PORT NAME 2 (if pres)| 8 Bytes 1018 +----------------------------------+ 1019 16 | . . . . | 1020 +----------------------------------+ 1022 Additionally, the THIRD PARTY ORIGINATOR N_PORT ID field in each 1023 TPRLO LOGOUT PARAMETER PAGE shall be cleared when it is carried by 1024 the iFCP header. This applies to both the original Link Service 1025 message and the ACC response. 1027 When the iFCP layer receives a TPRLO message with AUGMENTATION DATA 1028 in the iFCP header, it shall use the latter to replace the THIRD 1029 PARTY ORIGINATOR N_PORT ID in the original Link Service message, 1030 before forwarding it on to the upper Fibre Channel layers. 1032 Additional information on TPRLO can be found in [FC-PH-2]. 1034 Monia Standards Track 20 1035 7.1.3 Reinstate Recovery Qualifier (RRQ) 1037 RRQ is a request to release resources previously made unavailable 1038 as a result of an ABTS or ABTX. The following shows the format of 1039 an RRQ request message. 1041 Byte MSb LSb 1042 Offset 7 6 5 4 3 2 1 0 1043 +----------------------------------+ 1044 0 | LS_COMMAND | 4 Bytes 1045 +----------------------------------+ 1046 4 | RESERVED | 1 Bytes 1047 +----------------------------------+ 1048 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes 1049 +----------------------------------+ 1050 8 | RRQ OX_ID | 2 Bytes 1051 +----------------------------------+ 1052 10 | RRQ RX_ID | 2 Bytes 1053 +----------------------------------+ 1054 Total Length = 12 1056 Upon transmitting the RRQ Link Service message to the IP network, 1057 the iFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. 1058 Furthermore, the iFCP layer shall add the EXCHANGE ORIGINATOR to 1059 the iFCP AUGMENTED DATA field in the iFCP header. 1061 The EXCHANGE ORIGINATOR is a 4-byte field set to 0x00000001 to 1062 indicate that the RRQ originator is also the originator of the 1063 exchange for which the Recovery Qualifier is being reinstated. 1064 This field is set to 0x00000000 to indicate that the RRQ recipient 1065 is the originator of the exchange for which the Recovery Qualifier 1066 is being reinstated. 1068 RRQ OX_ID - The OX_ID of the exchange for which the Recovery 1069 Qualifier is being reinstated. 1071 RRQ RX_ID - The RX_ID of the exchange for which the Recovery 1072 Qualifier is being reinstated. 1074 Upon receipt of the RRQ Link Service message from the IP network, 1075 the iFCP layer shall use the N_PORT fabric addresses (in the Fibre 1076 Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP 1077 header) to replace the EXCHANGE ORIGINATOR S_ID field before 1078 forwarding the message on to the upper Fibre Channel layers. 1080 The ACC reply contains only the LS_COMMAND field as the payload, 1081 and does not require additional augmentation data. 1083 An LS_RJT reply may be sent in lieu of ACC, to indicate that the 1084 RRQ was rejected. 1086 Monia Standards Track 21 1087 7.1.4 Read Exchange Concise (REC) 1089 REC is a request for information on an exchange. The following 1090 shows the format of an REC request. 1092 Byte MSb LSb 1093 Offset 7 6 5 4 3 2 1 0 1094 +----------------------------------+ 1095 0 | LS_COMMAND | 4 Bytes 1096 +----------------------------------+ 1097 4 | RESERVED | 1 Bytes 1098 +----------------------------------+ 1099 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes 1100 +----------------------------------+ 1101 8 | REC OX_ID | 2 Bytes 1102 +----------------------------------+ 1103 10 | REC RX_ID | 2 Bytes 1104 +----------------------------------+ 1105 Total Length = 12 1107 Upon transmitting the REC Link Service message to the IP network, 1108 the iFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. 1109 Furthermore, the iFCP layer shall add the EXCHANGE ORIGINATOR to 1110 the iFCP AUGMENTED DATA field in the iFCP header. 1112 The EXCHANGE ORIGINATOR is a 4-byte field set to 0x00000001 to 1113 indicate that the REC originator is also the originator of the 1114 exchange for which status is being requested. This field is set to 1115 0x00000000 to indicate that the REC recipient is the originator of 1116 the exchange for which status is being requested. 1118 REC OX_ID - The OX_ID of the exchange for which information is 1119 being requested. 1121 REC RX_ID - The RX_ID of the exchange for which information is 1122 being requested. RX_ID may be 0xFFFF, indicating RX_ID is 1123 unassigned. 1125 Upon receipt of the REC Link Service message from the IP network, 1126 the iFCP layer shall use the N_PORT fabric addresses (in the Fibre 1127 Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP 1128 header) to replace the EXCHANGE ORIGINATOR S_ID field before 1129 forwarding the message on to the upper Fibre Channel layers. 1131 The following shows the format of the ACC payload in response to 1132 REC. 1134 Monia Standards Track 22 1135 Byte MSb LSb 1136 Offset 7 6 5 4 3 2 1 0 1137 +----------------------------------+ 1138 0 | LS_COMMAND (0x02000000) | 4 Bytes 1139 +----------------------------------+ 1140 4 | REC OX_ID | 2 Bytes 1141 +----------------------------------+ 1142 6 | REC RX_ID | 2 Bytes 1143 +----------------------------------+ 1144 8 | RESERVED | 1 Byte 1145 +----------------------------------+ 1146 9 | EXCHANGE ORIGINATOR N_PORT ID | 3 Bytes 1147 +----------------------------------+ 1148 12 | RESERVED | 1 Byte 1149 +----------------------------------+ 1150 12 | EXCHANGE RESPONDER N_PORT ID | 3 Bytes 1151 +----------------------------------+ 1152 16 | DATA TRANSFER COUNT | 4 Bytes 1153 +----------------------------------+ 1154 20 | E_STAT | 4 Bytes 1155 +----------------------------------+ 1156 Total Length = 24 1158 Upon transmitting the ACC response to the IP network, the iFCP 1159 layer shall clear the EXCHANGE ORIGINATOR N_PORT ID and EXCHANGE 1160 RESPONDER N_PORT ID fields when encapsulating the ACC message into 1161 iFCP. Furthermore, the iFCP AUGMENTED DATA field in the 1162 encapsulating iFCP header shall contain the EXCHANGE RESPONDER 1163 field, which is identical to the EXCHANGE ORIGINATOR value used to 1164 augment the original REC request message. 1166 REC OX_ID - The OX_ID of the exchange for which information is 1167 being returned. It should be identical to the REC OX_ID field in 1168 the REC request. 1170 REC RX_ID - The RX_ID of the exchange for which information is 1171 being returned. This field should also be identical to the REC 1172 RX_ID field in the REC request. 1174 When receiving the ACC response message from the IP network, the 1175 iFCP layer shall use the N_PORT fabric addresses (in the Fibre 1176 Channel header) and EXCHANGE RESPONDER (in the iFCP header) to 1177 replace the EXCHANGE ORIGINATOR N_PORT ID and EXCHANGE RESPONDER 1178 N_PORT ID fields before passing the Link Service message on to the 1179 upper Fibre Channel layers. 1181 DATA TRANSFER COUNT - The number of bytes received by a destination 1182 N_PORT for a write command, or the number of bytes received for a 1183 read command. 1185 E_STAT (Exchange Status) - Of the bits defined in this field, two 1186 are particularly significant to iFCP: 1188 Monia Standards Track 23 1189 Bit Field Description Significance 1190 --------- ----------- ------------ 1191 30 SEQUENCE INITIATIVE 0 = Other port holds sequence init 1192 1 = This port holds sequence init 1194 29 Completion 0 = Open 1195 1 = Closed 1197 An LS_RJT reply may be sent in lieu of ACC, to indicate that the 1198 REC was rejected. 1200 7.1.5 Discover Address (ADISC) 1202 ADISC allows devices to exchange name (Port and Node) information. 1203 This allows verification of Port and Node addresses. 1205 The following shows the format of the ADISC request message. The 1206 ACC response is identical except the command code is replaced with 1207 the ACC code (0x02000000), and the PORT_NAME and NODE_NAME fields 1208 are those of the responder. 1210 Byte MSb LSb 1211 Offset 7 6 5 4 3 2 1 0 1212 +----------------------------------+ 1213 0 | LS_COMMAND | 4 Bytes 1214 +----------------------------------+ 1215 4 | RESERVED | 1 Byte 1216 +----------------------------------+ 1217 5 | HARD ADDRESS | 3 Bytes 1218 +----------------------------------+ 1219 8 | ORIGINATOR/RESPONDER PORT NAME | 8 Bytes 1220 +----------------------------------+ 1221 16 | ORIGINATOR/RESPONDER NODE NAME | 8 Bytes 1222 +----------------------------------+ 1223 24 | RESERVED | 1 Byte 1224 +----------------------------------+ 1225 25 | ORIGINATOR N_PORT ID | 3 Bytes 1226 +----------------------------------+ 1227 Total Length = 28 1229 The HARD ADDRESS field has no meaning for iFCP. The field may 1230 contain non-zero values in the request message, but shall be zeroed 1231 in the ADISC response. 1233 Upon transmission to the IP network, the ORIGINATOR N_PORT ID shall 1234 be zeroed in both the request and ACC response messages. Upon 1235 receipt of the request or ACC response from the IP network, the 1236 iFCP layer shall use the ORIGINATOR/RESPONDER PORT_NAME and 1237 NODE_NAME to replace the ORIGINATOR N_PORT ID with the appropriate 1238 value, before forwarding the message on to upper Fibre Channel 1239 layers. 1241 Monia Standards Track 24 1242 The following parameters are used for the ADISC request message. 1244 ORIGINATOR PORT NAME - This field contains the World Wide Port Name 1245 (WWPN) of the iFCP port from which the ADISC request is being 1246 originated. 1248 ORIGINATOR NODE NAME - This field contains the WWPN of the N_PORT 1249 from which the ADISC request is being originated. 1251 7.1.6 Request Exchange Status (RES) 1253 RES requests the status of a specific exchange. The RES request is 1254 sent in a new exchange. The following shows the RES message 1255 format. 1257 Byte MSb LSb 1258 Offset 7 6 5 4 3 2 1 0 1259 +----------------------------------+ 1260 0 | LS_COMMAND (0x08000000) | 4 Bytes 1261 +----------------------------------+ 1262 4 | RESERVED | 1 Byte 1263 +----------------------------------+ 1264 7 | EXCHANGE ORIGINATOR S_ID | 3 Bytes 1265 +----------------------------------+ 1266 8 | RES OX_ID | 2 Bytes 1267 +----------------------------------+ 1268 10 | RES RX_ID | 2 Bytes 1269 +----------------------------------+ 1270 Total Length = 12 1272 Upon transmitting the RES Link Service message to the IP network, 1273 the iFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. 1274 Furthermore, the iFCP layer shall add the EXCHANGE ORIGINATOR to 1275 the iFCP AUGMENTED DATA field in the iFCP header. 1277 The EXCHANGE ORIGINATOR is a 4-byte field. When 0x00000001, 1278 itindicates that the RES requester is the originating N_PORT of the 1279 exchange for which status is being requested. When 0x00000000, 1280 indicates that the RES recipient is the originator of the exchange 1281 for which status is being requested. 1283 RES OX_ID - Specifies the OX_ID of the exchange for which status is 1284 being requested. 1286 RES_RX_ID - Specifies the RX_ID of the exchange for which status is 1287 being requested. 1289 If the RES recipient does not have an Exchange Status Block for the 1290 specified exchange, it shall respond with an LS_RJT message with a 1291 reason code of "UNABLE TO PERFORM COMMAND REQUEST". 1293 Monia Standards Track 25 1294 Upon receipt of the RES Link Service message from the IP network, 1295 the iFCP layer shall use the N_PORT fabric addresses (in the Fibre 1296 Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP 1297 header) to replace the EXCHANGE ORIGINATOR S_ID field before 1298 forwarding the message on to the upper Fibre Channel layers. 1300 The payload for the ACC response is a variable-length block of 1301 information called the EXCHANGE STATUS BLOCK. The Exchange Status 1302 Block (ESB) is used throughout an exchange to track the exchange's 1303 progress and identify which ports holds sequence initiative. The 1304 ESB has the following format shown below. 1306 Byte MSb LSb 1307 Offset 7 6 5 4 3 2 1 0 1308 +----------------------------------+ 1309 0 | ESB OX_ID | 1 Byte 1310 +----------------------------------+ 1311 2 | ESB RX_ID | 2 Bytes 1312 +----------------------------------+ 1313 4 | RESERVED | 1 Byte 1314 +----------------------------------+ 1315 5 | ORIGINATOR N_PORT ID | 3 Bytes 1316 +----------------------------------+ 1317 4 | RESERVED | 1 Byte 1318 +----------------------------------+ 1319 5 | RESPONDER N_PORT ID | 3 Bytes 1320 +----------------------------------+ 1321 6 | E_STAT | 4 Bytes 1322 +----------------------------------+ 1323 | RESERVED | 4 Bytes 1324 +----------------------------------+ 1325 8 | SERVICE PARAMETERS | 112 Bytes 1326 +----------------------------------+ 1327 88 | OLDEST SHORT SSB | 8 Bytes 1328 +----------------------------------+ 1329 96 | INTERMEDIATE SHORT SSB | X*8 Bytes 1330 +----------------------------------+ 1331 96 + X*8 | NEWEST SHORT SSB | 8 Bytes 1332 +----------------------------------+ 1333 Total Length = 104 + X*8 1335 ESB OX_ID - The OX_ID for the exchange status saved in the ESB. 1337 ESB RX_ID - The RX_ID for the exchange status saved in the ESB. 1339 Upon transmitting the ACC reply to the IP network, the iFCP layer 1340 shall clear the ORIGINATOR N_PORT_ID and RESPONDER N_PORT ID 1341 fields. Furthermore, the iFCP layer shall add a 4-byte EXCHANGE 1342 ORIGINATOR to the iFCP AUGMENTED DATA field in the iFCP header. 1343 When the EXCHANGE ORIGINATOR field is 0x00000001, this indicates 1344 that the port sending the RES message (or receiving the ACC reply) 1345 is the originator of the exchange whose status is saved in the ESB. 1347 Monia Standards Track 26 1348 When the EXCHANGE ORIGINATOR is 0x00000000, this indicates that the 1349 port receiving the RES message (or sending the ACC reply) is the 1350 originator of the exchange whose status is saved in the ESB. 1352 Upon receipt of the ACC reply from the IP network, the iFCP layer 1353 shall use the N_PORT fabric addresses (in the Fibre Channel header) 1354 and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace 1355 the ORIGINATOR and RESPONDER N_PORT ID fields before forwarding the 1356 message on to the upper Fibre Channel layers. 1358 More information on RES and the Exchange Status Block (ESB) can be 1359 found in [FC-PH]. 1361 7.1.7 Request Sequence Initiative (RSI) 1363 RSI allows a sequence recipient to request sequence initiative be 1364 passed for an open exchange. The RSI recipient responds in the 1365 following manner if the RSI request identifies an open exchange. 1367 The following shows the format of the RSI request message. 1369 Byte MSb LSb 1370 Offset 7 6 5 4 3 2 1 0 1371 +----------------------------------+ 1372 0 | LS_COMMAND (0x12000000) | 4 Bytes 1373 +----------------------------------+ 1374 4 | RESERVED | 1 Byte 1375 +----------------------------------+ 1376 7 | EXCHANGE ORIGINATOR S_ID | 3 Bytes 1377 +----------------------------------+ 1378 8 | RSI OX_ID | 2 Bytes 1379 +----------------------------------+ 1380 10 | RSI RX_ID | 2 Bytes 1381 +----------------------------------+ 1382 Total Length = 12 1384 Upon transmitting the RSI Link Service message to the IP network, 1385 the iFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. 1386 Furthermore, the iFCP layer shall add a 4-byte EXCHANGE ORIGINATOR 1387 to the iFCP AUGMENTED DATA field in the iFCP header. The EXCHANGE 1388 ORIGINATOR field, when 0x00000001, indicates that the RSI requester 1389 is the originator of the exchange for which initiative is being 1390 requested. When EXCHANGE ORIGINATOR is set to 0x00000000, this 1391 indicates the RSI recipient is the originator of the exchange for 1392 which initiative is being requested. 1394 RSI OX_ID - Specifies the OX_ID of the exchange for which sequence 1395 initiative is being requested. 1397 RSI RX_ID - Specifies the RX_ID of the exchange for which sequence 1398 initiative is being requested. 1400 Monia Standards Track 27 1401 Upon receipt of the RSI message from the IP network, the iFCP layer 1402 shall use the N_PORT fabric addresses (in the Fibre Channel header) 1403 and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace 1404 the EXCHANGE ORIGINATOR S_ID field before forwarding the message on 1405 to the upper Fibre Channel layers. 1407 An ACC response is sent after the sequence initiative has been 1408 transferred, or if it already has been transferred. The ACC 1409 response only has the 4-byte LS_COMMAND field as the payload. An 1410 LS_RJT response may be sent if the RSI parameters do not specify an 1411 open exchange (invalid OX_ID/RX_ID combination). 1413 7.1.8 Read Sequence Status (RSS) 1415 RSS requests the status of a specific sequence in an exchange. The 1416 following shows the format of the RSS request. 1418 Byte MSb LSb 1419 Offset 7 6 5 4 3 2 1 0 1420 +----------------------------------+ 1421 0 | LS_COMMAND (0x09000000) | 4 Bytes 1422 +----------------------------------+ 1423 4 | SEQ_ID | 1 Byte 1424 +----------------------------------+ 1425 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes 1426 +----------------------------------+ 1427 8 | RSS OX_ID | 2 Bytes 1428 +----------------------------------+ 1429 10 | RSS RX_ID | 2 Bytes 1430 +----------------------------------+ 1431 Total Length = 12 1433 Upon transmitting the RSS Link Service message to the IP network, 1434 the iFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. 1435 Furthermore, the iFCP layer shall add a 4-byte EXCHANGE ORIGINATOR 1436 to the iFCP AUGMENTED DATA field in the iFCP header. The EXCHANGE 1437 ORIGINATOR field, when 0x00000001, indicates that the RSS requester 1438 is the originator of the exchange for which sequence status is 1439 being requested. When EXCHANGE ORIGINATOR is set to 0x00000000, 1440 this indicates the RSS recipient is the originator of the exchange 1441 for which sequence status is being requested. 1443 SEQ_ID - Specifies the SEQ_ID of the sequence for which status is 1444 being requested. 1446 RSS OX_ID - Specifies the OX_ID of the exchange for which sequence 1447 status is being requested. 1449 RSS RX_ID - Specifies the RX_ID of the exchange for which sequence 1450 status is being requested. 1452 Monia Standards Track 28 1453 Upon receipt of the RSS message from the IP network, the iFCP layer 1454 shall use the N_PORT fabric addresses (in the Fibre Channel header) 1455 and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace 1456 the EXCHANGE ORIGINATOR S_ID field before forwarding the message on 1457 to the upper Fibre Channel layers. 1459 The ACC response payload for an RSS request consists of a single 1460 16-byte field, the Sequence Status Block (SSB), shown below. If 1461 the RSS recipient does not have a Sequence Status Block, it shall 1462 respond with an LS_RJT with a reason code of "UNABLE TO PERFORM 1463 COMMAND REQUEST". More information on the Sequence Status Block 1464 can be found in [FC-PH]. 1466 7.2 TCP Link Service Messages 1468 TCP Link Service Messages are used to manage TCP connections. They 1469 are passed between peer FCP Portals, and are only processed within 1470 the iFCP layer. The response to the TCP Link Service Message (if 1471 any) will echo the original request. The LS_COMMAND value for the 1472 response remains the same as that used for the request. 1473 Additionally, the ABTS request shall never be generated for any TCP 1474 Link Service Message. 1476 {Editor's note: Since these messages are never passed to the fibre 1477 channel device, the use of the FC ELS format is not required. 1478 However, leveraging the format may benefit a gateway 1479 implementation. Depending on the tradeoffs, therefore, the format 1480 may be modified to eliminate use of the ELS as a message template.] 1482 The Link Service frame carrying a TCP ELS message is identified by 1483 the TCP ELS bit being set in the iFCP FLAGS field of the iFCP 1484 header. Additionally, the TYPE field is 0x01 and R_CTL field is 1485 0x22 for the request, and 0x23 for the reply. 1487 The following lists the TCP Link Service messages and their 1488 corresponding LS_COMMAND values. 1490 Request LS_COMMAND Short Name iFCP Support 1491 ------- ---------- ---------- ------------ 1492 Control Connection Bind 0xE0 CBIND REQUIRED 1493 Unbind Connection 0xE4 UNBIND OPTIONAL 1494 TCP Message 0xE8 TCPMSG REQUIRED 1495 Network Connection Interfaces 0xED NINTF REQUIRED 1497 7.2.1 Network Connection Interfaces (NINTF) 1499 NINTF allows an FCP Portal to request information on other network 1500 interfaces that may be used to establish connections with the 1501 responding gateway implementation. This extended link service will 1502 return the number of network interfaces available, and an interface 1503 descriptor record for a single interface. Since each NINTF request 1505 Monia Standards Track 29 1506 returns information on one interface, multiple NINTF requests are 1507 required to obtain information on more than one interface. 1509 The following shows the format of the NINTF request message. 1511 Byte MSb LSb 1512 Offset 7 6 5 4 3 2 1 0 1513 +----------------------------------+ 1514 0 | LS_COMMAND (0xED000000) | 4 Bytes 1515 +----------------------------------+ 1516 4 | USER INFO | 4 Bytes 1517 +----------------------------------+ 1518 8 | INTERFACE KEY | 2 Bytes 1519 +----------------------------------+ 1520 10 | RESERVED | 2 Bytes 1521 +----------------------------------+ 1522 Total Length = 12 1524 USER INFO - Contains any data desired by the requester. The value 1525 will be echoed by the recipient. 1527 INTERFACE KEY - Contains an index to the interface for which the 1528 NINTF message is querying. Each interface at the destination shall 1529 be sequentially numbered beginning with 1. If the number of 1530 interfaces supported by the message recipient is unknown, then this 1531 field shall contain 0. In the NINTF response, the recipient will 1532 indicate the number of interfaces supported. Each of these 1533 interfaces can be referenced in subsequent NINTF messages by the 1534 sender by setting the INTERFACE KEY value up to the highest- 1535 numbered interface. 1537 The following shows the format of the NINTF response. 1539 Byte MSb LSb 1540 Offset 7 6 5 4 3 2 1 0 1541 +----------------------------------+ 1542 0 | LS_COMMAND (0xED000000) | 4 Bytes 1543 +----------------------------------+ 1544 4 | USER INFO | 4 Bytes 1545 +----------------------------------+ 1546 8 | RESERVED | 3 Bytes 1547 +----------------------------------+ 1548 11 | INTERFACES AVAILABLE (A) | 1 Byte 1549 +----------------------------------+ 1550 12 | INTERFACE RECORDS | X Bytes 1551 +----------------------------------+ 1552 Total Length = X + 12 1554 USER INFO - The 4-byte field is the same value as the USER INFO in 1555 the NINTF request. The recipient echoes this value back to the 1556 sender, and does not perform any operation using this field. 1558 Monia Standards Track 30 1559 INTERFACES AVAILABLE (A) - This parameter specifies the number of 1560 additional network interfaces that may be used to establish TCP 1561 connections. The value stored in this field also specifies the 1562 number (A) of network interface records that are present at the end 1563 of the message. 1565 INTERFACE RECORDS - This field contains A interface records 1566 describing each of the network interfaces. An interface record 1567 consists of 5 parameters as shown in below. 1569 Byte MSb LSb 1570 Offset 7 6 5 4 3 2 1 0 1571 +----------------------------------+ 1572 0 | RECORD LENGTH | 1 Byte 1573 +----------------------------------+ 1574 1 | IP ADDRESS TYPE | 1 Byte 1575 +----------------------------------+ 1576 2 | INTERFACE HANDLE | 2 Bytes 1577 +----------------------------------+ 1578 4 | RESERVED | 4 Bytes 1579 +----------------------------------+ 1580 8 | INTERFACE SPEED | 4 Bytes 1581 +----------------------------------+ 1582 | IP ADDRESS | X-12 Bytes 1583 +----------------------------------+ 1584 Total Length = X 1586 RECORD LENGTH - Defines the total length, in bytes, of the 1587 INTERFACE RECORD, including the RECORD LENGTH field. This value 1588 shall be a multiple of 4 bytes. 1590 IP ADDRESS TYPE - Defines the type of address in the IP ADDRESS 1591 field. 0x01 indicates IPv4, 0x02 indicates Ipv6. 1593 INTERFACE HANDLE - This 16-bit field contains an identifying number 1594 (i.e., handle) assigned to the interface by the destination N_PORT. 1595 INTERFACE SPEED - This parameter specifies the data rate of the 1596 interface in bits per second. The value in this field is the data 1597 rate divided by 1024. For example, a value of 1024 indicates a 1598 data rate of 1048576 bits per second. 1600 IP ADDRESS - This field contains the IP address of the network 1601 interface for which information is being returned. If the address 1602 type is N bytes long and the field is larger than N, the address 1603 shall be in the first N bytes of the field with the remainder of 1604 the field set to 0. 1606 7.2.2 Connection Bind (CBIND) 1608 The CBIND message binds an N_PORT login session to a specific TCP 1609 connection. In the CBIND request message, the source and 1610 destination N_Port is identified by its N_PORT network address. 1612 Monia Standards Track 31 1613 The following shows the format of the CBIND request. 1615 Byte MSb LSb 1616 Offset 7 6 5 4 3 2 1 0 1617 +----------------------------------+ 1618 0 | LS_COMMAND (0xE0000000) | 4 Bytes 1619 +----------------------------------+ 1620 4 | USER INFO | 4 Bytes 1621 +----------------------------------+ 1622 8 | SOURCE PORT NAME | 8 Bytes 1623 +----------------------------------+ 1624 Length = 16 1626 USER INFO - Contains any data desired by the requester. This info 1627 is echo-ed back by the recipient. 1629 SOURCE PORT NAME - Contains the originating N_PORT's World Wide 1630 Port Name (WWPN). The FCP Portal uses this to verify that there is 1631 no pre-existing N_PORT session between the source and destination 1632 N_PORTs. [The response to this error condition will be handled in 1633 a future release of this specification] 1635 The following shows the format of the CBIND response. 1637 Byte MSb LSb 1638 Offset 7 6 5 4 3 2 1 0 1639 +----------------------------------+ 1640 0 | LS_COMMAND (0xE0000000) | 4 Bytes 1641 +----------------------------------+ 1642 4 | USER INFO | 4 Bytes 1643 +----------------------------------+ 1644 8 | DESTINATION PORT NAME | 8 Bytes 1645 +----------------------------------+ 1646 16 | RESERVED | 2 Bytes 1647 +----------------------------------+ 1648 18 | CBIND STATUS | 2 Bytes 1649 +----------------------------------+ 1650 20 | RESERVED | 2 Bytes 1651 +----------------------------------+ 1652 22 | CONNECTION HANDLE | 4 Bytes 1653 +----------------------------------+ 1654 Total Length = 26 1656 USER INFO - Contains the same value received in the USER INFO field 1657 of the CBIND request message. 1659 DESTINATION PORT NAME - Contains the destination N_PORT's World 1660 Wide Port Name (WWPN). 1662 CBIND STATUS - Indicates success or failure of the CBIND request. 1663 CBIND values are shown below. 1665 Monia Standards Track 32 1666 Value Description 1667 ----- ----------- 1668 0 Successful - No Other Status 1669 1-15 Reserved 1670 16 Failed - Unspecified Reason 1671 17 Failed - No Such device 1672 18 Failed - N_PORT session already exists 1673 19 Failed - Lack of Resources 1674 Others Reserved 1676 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the FCP 1677 Portal to identify the control connection 1679 7.2.4 Unbind Connection (UNBIND) 1681 UNBIND is used to release a bound TCP connection and return it to 1682 the pool of unbound TCP connections. This message is transmitted 1683 in the connection that is to be unbound. 1685 The following is the format of the UNBIND request message. 1687 Byte MSb LSb 1688 Offset 7 6 5 4 3 2 1 0 1689 +----------------------------------+ 1690 0 | LS_COMMAND (0xE4000000) | 4 Bytes 1691 +----------------------------------+ 1692 4 | USER INFO | 4 Bytes 1693 +----------------------------------+ 1694 8 | CONNECTION HANDLE | 4 Bytes 1695 +----------------------------------+ 1696 12 | RESERVED | 8 Bytes 1697 +----------------------------------+ 1698 Total Length = 20 1700 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the FCP 1701 Portal to identify the connection 1703 The following shows the format of the UNBIND response message. 1705 Monia Standards Track 33 1706 Byte MSb LSb 1707 Offset 7 6 5 4 3 2 1 0 1708 +----------------------------------+ 1709 0 | LS_COMMAND (0xE4000000) | 4 Bytes 1710 +----------------------------------+ 1711 4 | USER INFO | 4 Bytes 1712 +----------------------------------+ 1713 8 | CONNECTION HANDLE | 4 Bytes 1714 +----------------------------------+ 1715 16 | RESERVED | 10 Bytes 1716 +----------------------------------+ 1717 26 | UNBIND STATUS | 2 Bytes 1718 +----------------------------------+ 1719 28 | RESERVED | 2 Bytes 1720 +----------------------------------+ 1721 Total Length = 26 1723 UNBIND STATUS - Indicates the success or failure of the UNBIND 1724 request. 1726 Value Description 1727 ----- ----------- 1728 0 Successful - No Other Status 1729 1-15 Reserved 1730 16 Failed - Unspecified Reason 1731 17 Failed - No Such device 1732 18 Failed - Connection ID Invalid 1733 Others Reserved 1735 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the FCP 1736 Portal to identify the unbound connection. 1738 7.2.5 TCP Message (TCPMSG) 1740 TCPMSG sends an error message to another iFCP port. TCPMSG differs 1741 from other messages in that there is no reply to TCPMSG (both the 1742 first and last sequence in a exchange). The primary purpose for 1743 TCPMSG is to generate a message informing an iFCP port that a fatal 1744 FCP/TCP protocol error was detected, and all connections 1745 established with the iFCP port are being closed. TCPMSG can also 1746 be used to send "Informative" or "Warning" messages that may be 1747 used for debugging or diagnostic purposes. 1749 The format of the TCPMSG request message follows. 1751 Monia Standards Track 34 1752 Byte MSb LSb 1753 Offset 7 6 5 4 3 2 1 0 1754 +----------------------------------+ 1755 0 | LS_COMMAND (0xEE000000) | 4 Bytes 1756 +----------------------------------+ 1757 4 | RESERVED | 4 Bytes 1758 +----------------------------------+ 1759 8 | ERROR CODE | 2 Bytes 1760 +----------------------------------+ 1761 10 | TCPMSG FLAGS | 1 Byte 1762 +----------------------------------+ 1763 11 | MSG LENGTH (L) | 1 Byte 1764 +----------------------------------+ 1765 12 | MSG | L Bytes 1766 +----------------------------------+ 1767 Total Length = L + 12 1769 ERROR CODE - Specifies one of the predefined error messages shown 1770 in the following table. This field is valid only if the FATAL bit 1771 is 1 and MSG LENGTH is 0 in the TCPMSG FLAGS field. 1773 Error Code Message 1774 ---------- ------- 1775 0x0001 Loss of Synchronization on Connection 1776 Others RESERVED 1778 TCPMSG FLAGS - This field contains 3 bit flags that specify how the 1779 recipient should interpret the received message. 1781 Bit Field Flag Description 1782 --------- ---- ----------- 1783 7:3 RESERVED 1785 2 INFORMATIVE Indicates the message is informative, 1786 usually for debugging purposes. These 1787 messages may be discarded. 1789 1 WARNING Indicates the message is a warning. 1790 Processing of warning messages is 1791 required and implementation-specific. 1793 0 FATAL Indicates a fatal protocol error has 1794 been detected. Sender is terminating 1795 login sessions with the recipient and 1796 closing all TCP connections. The 1797 recipient shall implicit logout the 1798 sender of the message and close TCP 1799 connections to the sender. 1801 A WARNING or INFORMATIVE message shall not cause the recipient to 1802 alter the operating environment. When more than one TCPMSG FLAG 1804 Monia Standards Track 35 1805 bit is set, the message shall be considered Fatal. When no flags 1806 are set, the message shall be discarded. 1808 MSG LENGTH - Specifies the length in bytes of the MSG field. The 1809 length must be a multiple of 4 and can be a value of between 0 and 1810 128. A value of 0 indicates the MSG field is not present. 1812 8 Error Detection and Recovery Procedures for iFCP 1814 8.1 Overview 1816 [FCP-2], [FC-PH], and [FC-PH-2] define error detection and recovery 1817 procedures. These Fibre Channel-defined mechanisms continue to be 1818 available in the iFCP environment. 1820 8.2 Timer Definitions 1822 8.2.1 Error_Detect_Timeout (E_D_TOV) 1824 E_D_TOV is "a reasonable timeout value for detection of a response 1825 to a time event". The default value specified by FC-PH of 10 1826 seconds will be also used as the iFCP default value. 1828 E_D_TOV is the maximum time allowed between the transmission of 1829 consecutive data frames within a sequence. For Class 2 service, 1830 E_D_TOV specifies the maximum time interval between transmission of 1831 a frame, and receipt of the ACK for that frame. 1833 [The policy for setting E_D_TOV for an IP fabric is TBS] 1835 8.2.2 Resource Allocation Timeout (R_A_TOV) 1837 R_A_TOV is defined in FC-PH-2 as "the maximum transit time within a 1838 fabric to guarantee that a lost frame will never emerge from the 1839 fabric". A value of 2 x R_A_TOV is the minimum time that the 1840 originator of an ELS request or FC-4 ELS request shall wait for the 1841 response to that request. 1843 [The policy for setting R_A_TOV for an IP fabric is TBS] 1845 8.2.3 Resource Recovery Timer (RR_TOV) 1847 [The content of this section is TBD] 1849 8.3 TCP Error Recovery Issues 1851 A failed TCP connection will result in a dropped N_PORT session. 1853 [The remainder of this section is TBD] 1855 8.4 iFCP Protocol Error 1857 Monia Standards Track 36 1858 iFCP protocol errors between FCP Portals shall be considered fatal 1859 errors resulting in the termination of the login sessions and 1860 closing of the TCP sessions. 1862 An iFCP protocol error occurs when Fibre Channel frames are sent on 1863 the wrong TCP connection. One example of a protocol error is 1864 receiving an FCP_CMND IU on the data connection. 1866 If an iFCP port detects an iFCP/TCP protocol error on a connection, 1867 the port shall transmit a TCPMSG message on the control connection 1868 (if one exists) with the appropriate error code. The FCP_Portal 1869 shall then implicitly log out and close all TCP connections 1870 established with the iFCP port, and ignore all data received on 1871 these TCP connections until they are reopened. 1873 [The information returned to the N_PORT upon occurence of an iFCP 1874 protocol error will be specified in the next revision of this 1875 specification] 1877 9. Security 1879 9.1 Overview 1881 As with any other IP-based network, an iFCP storage network has 1882 security issues which must be addressed with the appropriate 1883 security policies and enforcement resources. There are various 1884 levels of security paradigms which when applied appropriately to an 1885 iFCP network can provide sufficient levels of security, including 1886 data integrity, authentication, and privacy, depending on user 1887 needs. 1889 9.2 Physical Security 1891 Most existing SCSI and Fibre Channel interconnections are deployed 1892 in private, physically isolated environments where hostile entities 1893 are not provided access to the SCSI and Fibre Channel 1894 interconnects. This is the most basic security mechanism, and may 1895 be a sufficient model in some cases for an iFCP network. 1897 9.3 Controlling Access 1899 A second level of security is the use of zoning. Zoning specifies 1900 which devices are allowed to communicate, and is similar in concept 1901 to VLAN (Virtual Local Area Network) technology. Zoning 1902 information is maintained in a Name Server. 1904 9.4 Authentication and Encryption 1906 Where additional levels of data integrity and privacy are required 1907 for iFCP, existing IPSec specifications can be applied to iFCP. 1908 Because IPSec is a layer-3 technology and has no knowledge of TCP, 1909 UDP, or higher-level protocols such as iFCP and FCP, it can be 1911 Monia Standards Track 37 1912 applied transparently to iFCP. The following IETF documents 1913 describe the operational framework and automatic keying mechanisms 1914 for IPSec. 1916 RFC2401 Security Architecture for the Internet Protocol 1917 RFC2402 IP Authentication Header 1918 RFC2406 IP Encapsulating Security Payload 1919 RFC2407 The Internet IP Security Domain of Interpretation 1920 for ISAKMP 1921 RFC2408 Internet Security Association and Key Management 1922 Protocol (ISAKMP) 1923 RFC2409 The Internet Key Exchange (IKE) 1925 9.5 Storage Firewalls 1927 Firewalls are a common and proven methodology for securing access 1928 to IP-based networks, and they can be appropriate for use in IP- 1929 based storage networks as well. A firewall is a choke point 1930 through which all transit traffic must transit in order to pass 1931 between two separate networks. Since all iFCP traffic uses a well- 1932 known IANA-assigned TCP port number, it can easily be recognized 1933 and inspected. 1935 Access to storage resources can be secured by setting up a single 1936 gateway through which all outside non-secured traffic must pass 1937 through in order to access resources in the storage network. Such 1938 a firewall can be a proxy host operating at the session or 1939 application layer, requiring authentication before allowing traffic 1940 to pass. It can also be a stateful inspection gateway which 1941 understands the iFCP protocol, and can passively inspect and 1942 discover security threats as they transit the gateway. A third 1943 option is to use a standard router access control list to filter 1944 authorized traffic based upon static parameters such as IP 1945 addresses and TCP port numbers. 1947 10. References 1949 10.1 Relevant SCSI (T10) Specifications 1951 The following documents are available from: Global Engineering, 15 1952 Inverness Way East, Englewood, CO 80112-5704. Telephone (800) 1953 854-7179 or (303) 792-2181, Fax: (303) 792-2192 1955 [SAM] SCSI-3 Architecture Model (SAM), ANSI X3.270-1996 1957 [SAM-2] SCSI Architecture Model-2 (SAM-2), Project 1157-D, 1958 revision 11 1960 [SPC] SCSI Primary Commands (SPC), ANSI X3.301-1997 1962 [SPC-2] SCSI Primary Commands-2 (SPC-2), Project 1236-D, 1963 revision 16 1965 Monia Standards Track 38 1967 [FCP] Fibre Channel Protocol for SCSI (FCP), ANSI X3.269- 1968 1996 1970 [FCP-2] Fibre Channel Protocol for SCSI, Second Revision (FCP- 1971 2), Project 1144D, revision 04 1973 10.2 Relevant Fibre Channel (T11) Specifications 1975 The following documents are available from: Global Engineering, 15 1976 Inverness Way East, Englewood, CO 80112-5704. Telephone (800) 1977 854-7179 or (303) 792-2181, Fax: (303) 792-2192 1979 [FC-PH] Fibre Channel Physical and Signaling Interface (FC-PH) 1980 Rev 4.3, ANSI X3.230:1994 1982 [FC-PH-2] Fibre Channel Physical and Signaling Interface (FC-PH- 1983 2) Rev 7.4, ANSI X3.297:1997 1985 [FC-PH-3] Fibre Channel Physical and Signaling Interface (FC-PH- 1986 3) Rev 9.4, ANSI X3.303:1998 1988 [FC-FG] Fibre Channel Generic Requirements (FC-FG) Rev 3.5, 1989 ANSI X3.289:1996 1991 [FC-GS-2] Fibre Channel Generic Services (FC-GS-2) Rev 5.2, ANSI 1992 NCITS 288 1994 [FC-AL] Fibre Channel Arbitrated Loop (FC-AL) Rev 4.5, ANSI 1995 X3.272:1996 1997 [FC-AL-2] Fibre Channel Arbitrated Loop (FC-AL-2) Rev 7.0, NCITS 1998 332:1999 2000 [FC-PLDA] Fibre Channel Private Loop SCSI Direct Attachment (FC- 2001 PLDA), NCITS TR-19:1998 2003 [FC-FLA] Fibre Channel Fabric Loop Attachment (FC-FLA), NCITS 2004 TR-20:1998 2006 [FC-TAPE] Fibre Channel Tape and Tape Medium Changers (FC-TAPE), 2007 NCITS TR-24:1999 2009 10.3 Relevant RFC Documents 2011 [RFC768] User Datagram Protocol 2013 [RFC791] Internet Protocol, DARPA Internet Program Protocol 2014 Specification 2016 [RFC1146] TCP Alternate Checksum Options 2018 Monia Standards Track 39 2020 [RFC2401] Security Architecture for Internet Protocol 2022 [RFC2402] IP Authentication Header 2024 [RFC2406] Encapsulating Security Protocol (ESP) 2026 [RFC2407] The Internet IP Security Domain for ISAKMP 2028 [RFC2408] Internet Security Association and Key Management 2029 Protocol (ISAKMP) 2031 [RFC2409] The Internet Key Exchange (IKE) 2033 [RFC2460] Internet Protocol, Version 6 (IPv6) Specification 2035 10.4 Other Reference Documents 2037 Fibre Channel, Gigabit Communications and I/O for Computer 2038 Networks, Alan F. Beener, McGraw-Hill, ISBN 0-07-005669-2 2040 The Fibre Channel Consultant, A Comprehensive Introduction, Robert 2041 W. Kembel, Northwest Learning Associates, ISBN 0-931836-82-6 2043 The Fibre Channel Consultant, Arbitrated Loop, Rober W. Kembel, 2044 Connectivity Solutions, a division of Northwest Learning 2045 Associates, ISBN 0-931836-84-0 2047 Monia Standards Track 40 2048 11. Author's Addresses 2050 Charles Monia 2051 Rod Mullendore 2052 Josh Tseng 2053 Nishan Systems 2054 3850 North First Street 2055 San Jose, CA 95134 2056 Phone: 408-519-3986 2057 Email: cmonia@nishansystems.com 2059 Franco Travostino 2060 Nortel Networks 2061 Director, Content Internetworking Lab 2062 3 Federal Street 2063 Billerica, MA 01821 2064 Phone: 978-288-7708 2065 Email: travos@nortelnetworks.com 2067 David Robinson 2068 Sun Microsystems 2069 Senior Staff Engineer 2070 M/S UNWK02-107 2071 901 San Antonio Road 2072 Palo Alto, CA 94303-4900 2073 Phone: 510-574-9226 2074 Email: david.robinson@ebay.sun.com 2076 Wayland Jeong 2077 Troika Networks 2078 Vice President, Hardware Engineering 2079 2829 Townsgate Road Suite 200 2080 Westlake Village, CA 91361 2081 Phone: 805-370-2614 2082 Email: wayland@troikanetworks.com 2084 Rory Bolt 2085 Quantum/ATL 2086 Director, System Design 2087 101 Innovation Drive 2088 Irvine, CA 92612 2089 Phone: 949-856-7760 2090 Email: rbolt@atlp.com 2092 Monia Standards Track 41 2093 Paul Rutherford 2094 ADIC 2095 Vice President, Technology & Software 2096 1143 Willows Road N.E. 2097 P.O. Box 97057 2098 Redmond, WA 98073-9757 2099 Phone: 425-881-8004 2100 Email: paul.rutherford@adic.com 2102 Mark Edwards 2103 Senior Systems Architect 2104 Eurologic Development, Ltd. 2105 4th Floor, Howard House 2106 Queens Ave, UK. BS8 1SD 2107 Phone: +44 (0)117 930 9600 2108 Email: medwards@eurologic.com 2110 Monia Standards Track 42 2111 Full Copyright Statement 2113 "Copyright (C) The Internet Society (date). All Rights Reserved. 2114 This document and translations of it may be copied and furnished to 2115 others, and derivative works that comment on or otherwise explain 2116 it or assist in its implmentation may be prepared, copied, 2117 published and distributed, in whole or in part, without restriction 2118 of any kind, provided that the above copyright notice and this 2119 paragraph are included on all such copies and derivative works. 2120 However, this document itself may not be modified in any way, such 2121 as by removing the copyright notice or references to the Internet 2122 Society or other Internet organizations, except as needed for the 2123 purpose of developing Internet standards in which case the 2124 procedures for copyrights defined in the Internet Standards process 2125 must be followed, or as required to translate it into languages 2126 other than English. 2128 The limited permissions granted above are perpetual and will not be 2129 revoked by the Internet Society or its successors or assigns. 2131 This document and the information contained herein is provided on 2132 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 2133 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2134 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2135 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2136 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2138 Monia Standards Track 43 2139 Appendix A 2141 A. iFCP Transparent Mode 2143 [Editor's Note: This section is the initial draft of a proposed 2144 architectural extension to iFCP.] 2146 This section describes an architectural extension of iFCP which 2147 provides for the allocation of fabric-unique N_PORT addresses as 2148 alternative to the gateway-local N_PORT addressing method described 2149 in the main portion of the document. 2151 This alternative may be useful as the basis for iFCP 2152 implementations which support non-storage FC-4 protocols. 2154 One of the chief attributes of the basic iFCP protocol is the 2155 mapping of gateway-assigned Fibre Channel N_PORT IDs to global IPv4 2156 or IPv6 addresses along with the local assignment of N_PORT ID 2157 values within the scope of the gateway. 2159 This mapping allows the internetworking of a virtually unlimited 2160 number of Fibre Channel devices. It also simplifies management of 2161 the IP storage fabric configuration by eliminating the need for a 2162 centralized address-assignment authority. More importantly, by 2163 decoupling N_PORT network addresses from the constraints of Fibre 2164 Channel address space management, it improves the scalability of 2165 iFCP gateway configurations. 2167 These constraints are a result of the manner in which Fibre Channel 2168 fabrics manage address assignment. In a switched fabric, this is 2169 done hierarchically by subdividing the 24-bit address space into 2170 65K blocks, which are distributed to switch elements. A switch 2171 element, in turn, assigns N_PORT addresses out of this 65K pool as 2172 attached devices log into the fabric. A fabric using this address 2173 allocation scheme is limited to 239 switch elements. This is not a 2174 serious limitation for small fabrics. As the system expands, 2175 however, fabrics may consist of many switch elements distributed 2176 throughout the enterprise, each of which controls a small number of 2177 devices. In this case, the limitation in switch count may become a 2178 barrier to fully integrating the storage network. 2180 The alternative method for N_PORT address assignment described in 2181 this section, therefore, is proposed as an alternative where 2182 address transparency is considered more important than 2183 connectivity. 2185 A.1 Definitions 2187 Logical iFCP Fabric _ A collection of iFCP gateways that co- 2188 ordinate the assignment of N_PORT addresses such that each N_PORT 2189 address is unique within the scope of the fabric. 2191 Monia Standards Track 44 2192 DOMAIN_ID _ The value contained in the high-order byte of a 24-bit 2193 N_PORT address. 2195 A.2 Architectural Overview 2197 iFCP Transparent Mode is a variant of the basic iFCP protocol 2198 described in the main section of this document. 2200 A prerequisite for transparent mode operation is to create a 2201 logical iFCP fabric and configure it with the gateways to 2202 interoperate in transparent mode. This configuration may be done 2203 manually or through the services of an iSNS name server. 2205 Since a given IP network may contain several logical iFCP fabrics 2206 as well as gateways operating in non-transparent mode, it is likely 2207 that one or more N_PORTs within the IP network will have the same 2208 N_PORT ID. Consequently, it is necessary to prevent data corruption 2209 due to extraneous frame traffic entering the transparent-mode 2210 gateway from outside the logical fabric. Therefore, a gateway 2211 operating in transparent mode: 2213 a) MUST only be a member of one logical fabric. 2214 b) MUST NOT establish N_PORT login sessions with, send frames to or 2215 accept frames from gateways that are not a member of its logical 2216 fabric. 2217 c) MUST NOT accept or send frames to gateways not in transparent 2218 mode. 2220 In a logical iFCP fabric, unique N_PORT addresses are obtained by 2221 assigning a fabric-unique DOMAIN_ID to each member gateway. The 2222 gateway, in turn, assigns fabric-unique N_PORT ID's to each 2223 directly attached Fibre Channel device. 2225 Once each FC end node is addressed by unique N_PORT ID's, no 2226 modification of the S_ID and D_ID is required, and no augmentation 2227 of any Link Service Commands is needed. Destination IP addresses 2228 can be found with a quick table lookup using the destination N_PORT 2229 ID (i.e., D_ID) as the key. The original frame can then be 2230 encapsulated without modification and forwarded to the appropriate 2231 iFCP Portal. 2233 A.3 iFCP Transparent Mode Differences 2235 The following is a summary of differences in using Transparent Mode 2236 compared to basic iFCP: 2238 1) There is no need to augment any Link Service Commands, as 2239 specified in section 7 of the main iFCP document. 2241 2) No address translation of S_ID and D_ID values is needed in the 2242 transmission of iFCP frames between iFCP gateways. 2244 Monia Standards Track 45 2245 A.4 Important iFCP Transparent Mode Considerations 2247 There are important limitations for consideration when using iFCP 2248 Transparent Mode. These are as follows: 2250 1) A maximum of 238 DOMAIN_ID values are available for allocation 2251 to iFCP gateways. This provides a hard theoretical limit to the 2252 maximum size of the iFCP fabric operating in Transparent Mode. 2254 2) N_PORT fabric address space must be allocated in 65,536 address 2255 "chunks", likely leading to relatively inefficient use of the 2256 available 3-byte address space. 65,536 addresses must be allocated 2257 to each iFCP gateway requesting address space, regardless of the 2258 number of devices supported by the gateway. 2260 3) iFCP transparent mode increases the dependency on the iSNS, 2261 which is the central address-assignment authority. If connectivity 2262 with the iSNS is lost, new DOMAIN_ID values cannot be automatically 2263 allocated, and new iFCP gateways cannot be automatically added to 2264 the fabric. Of course, it is always possible to add and manage 2265 additional such gateways manually. 2267 4) Multiple iFCP gateways set up with independently-administered 2268 iSNS servers must be completely torn down and slaved under a single 2269 iSNS authority, before they can be configured into the same logical 2270 fabric. In contrast, the iFCP described in the main section of 2271 this document requires only that independent iSNS servers import 2272 client attributes from other iSNS servers, before clients under 2273 different iSNS authorities can be made to interoperate. 2275 5) iFCP gateways in transparent mode will not interoperate with 2276 iFCP gateways that are not in transparent mode. 2278 6) When interoperating with Fibre Channel fabrics, the iFCP 2279 gateway MUST assume control of DOMAIN_ID assignments in accordance 2280 with the appropriate Fibre Channel standard or specification. 2281 DOMAIN_ID values assigned to FC switches in attached fabrics must 2282 be acquired from the iSNS. 2284 A.5 iFCP Transparent Mode Requirements 2286 The following requirements exist for iFCP gateways operating in 2287 Transparent Mode: 2289 A.5.1 Allocation of DOMAIN_ID Values 2291 In Fibre Channel, addresses are 24-bit values. The high-order 8- 2292 bits of the address comprise the DOMAIN_ID, and may range in value 2293 between 1 and 239. 2295 Monia Standards Track 46 2296 In order to assign a fabric-unique value to each N_PORT ID, an iFCP 2297 gateway in transparent mode shall acquire a unique DOMAIN_ID by 2298 querying the iSNS server or through manual allocation. 2300 iFCP gateways in Transparent Mode SHALL only assign to N_PORTs 2301 address values which are globally-unique within the iFCP fabric. 2302 It accomplishes this by using its assigned DOMAIN_ID and creating 2303 addresses with values allocated from the lower-order 16-bits. 2304 Each N_PORT interface in the entire iFCP logical fabric SHALL have 2305 a unique N_PORT_ID value. 2307 A.5.2 Incompatibility with "Main Mode" iFCP 2309 iFCP gateways in transparent mode shall not originate or accept 2310 frames that do not have bit 9 ("iFCP TRANSPARENT MODE") set to one 2311 in the FLAG field. The iFCP gateway shall immediately terminate 2312 any N_PORT sessions with the iFCP gateway from which it receives 2313 such frames. 2315 A.5.3 Encapsulation Header FLAGS Settings 2317 The following values shall be considered legal and usable values in 2318 the FLAGS field of the encapsulation header: 2320 Bit Field FLAG Legal Value for FLAGS field 2321 --------- ---- --------------------------- 2322 13 non-iFCP MUST be 1 2323 10-12 RESERVED MUST be 1 2324 9 iFCP TRANSPARENT MODE MUST be 1 2325 4-8 RESERVED for iFCP MUST be 0 2326 3 iFCP DATA CRC MUST be 1 2327 2 TCP ELS MUST be 0 2328 1 AUGMENTATION PRES MUST be 0 2329 0 COMPLIANCE MUST be 1 2331 A.5.4 Fibre Channel CRC 2333 The iFCP Transparent Mode frame SHALL include the trailing CRC. 2334 This shall be indicated in the encapsulation header by enabling bit 2335 19 in the FLAGS field. Since there is no AUGMENTED DATA field in 2336 the encapsulation header, the value in the iFCP CRC field should be 2337 a copy of the CRC in the original Fibre Channel frame. 2338 Consequently, the original CRC can be used in the iFCP CRC field 2339 without recalculation. 2341 A.5.5 Applicability of Main iFCP Specification Sections 2343 iFCP gateways operating in Transparent Mode shall comply with all 2344 of the main sections of this iFCP document except for section 3.3 2345 (Address Translation), and section 7 (Augmented Link Services). In 2346 iFCP Transparent Mode, no Fibre Channel Address Translation shall 2348 Monia Standards Track 47 2349 take place, and no Link Service Messages shall be augmented with 2350 additional information by the iFCP layer. 2352 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2353 9, RFC 2026, October 1996. 2355 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2356 Levels", BCP 14, RFC 2119, March 1997 2358 Monia Standards Track 48