idnits 2.17.1 draft-ietf-ipfc-fibre-channel-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 278 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... and its wo...' == Line 19 has weird spacing: '...aterial or to...' == Line 125 has weird spacing: '... most of th...' == Line 139 has weird spacing: '...promote inter...' == Line 142 has weird spacing: '...packets over ...' == (9 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP and ARP Over FC Working Group Murali Rajagopal 3 INTERNET-DRAFT Raj Bhagwat 4 Wayne Rickard 5 (Expires May 1, 1999) (Gadzoox Networks) 7 IP and ARP over Fibre Channel 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as Reference 19 material or to cite them other than as ``work in progress''. 21 To view the entire list of current Internet-Draft, please check 22 the``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net ( Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 Fibre Channel (FC) is a high speed serial interface technology that 30 supports several higher layer protocols including Small Computer 31 System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI 32 has been the only widely used protocol over FC. Existing FC standards 33 [3] do not adequately specify how IP packets may be transported over 34 FC and how IP addresses are resolved to FC addresses. The purpose of 35 this document is to specify a way of encapsulating IP and Address 36 Resolution Protocol(ARP) over Fibre Channel and also to describe a 37 mechanism(s) for IP address resolution. 39 Contents 41 Status of this Memo ........................................... 1 42 Abstract ....................................................... 1 44 1. Introduction ............................................... 3 46 2. Problem Statement .......................................... 4 48 3. IP and ARP Encapsulation ................................... 4 49 3.1 FC Frame Format ........................................ 4 50 3.2 MTU .................................................... 5 51 3.3 FC Port and Node Network Addresses ..................... 6 52 3.4 FC Payload Format ...................................... 7 53 3.5 ARP Packet Format ...................................... 8 55 4. Address Resolution ......................................... 10 56 4.1 Problem Description .................................... 10 57 4.2 ARP layer Mapping and Operation ........................ 10 58 4.2.1 ARP Broadcast in a Point-to-Point Topology ....... 11 59 4.2.2 ARP Broadcast in a Private Loop Topology ......... 11 60 4.2.3 ARP Broadcast in a Public Loop Topology .......... 12 61 4.2.4 ARP Operation in a Fabric Topology ............... 12 63 5. Mechanism for Maintaining FC Layer Mappings ................ 13 64 5.1 Use of Name Server ..................................... 13 65 5.2 FARP ................................................... 13 67 6. FC Layer Address Validation ................................ 19 68 6.1 General Discussion ..................................... 19 69 6.2 FC Layer Address Validation in a Point-to-Point Topology 19 70 6.3 FC Layer Address Validation in a Private Loop Topology . 19 71 6.4 FC Layer Address Validation in a Public Loop Topology .. 20 72 6.5 FC layer Address Validation in a Fabric Topology ....... 20 74 7. Exchange Management ........................................ 21 75 7.1 Exchange Origination ................................... 21 76 7.2 Exchange Termination ................................... 21 78 8. Summary of Supported Features .............................. 21 79 8.1 FC-4 Header ............................................ 21 80 8.2 R_CTL .................................................. 22 81 8.3 F_CTL .................................................. 23 82 8.4 Sequences .............................................. 23 83 8.5 Exchanges .............................................. 24 84 8.6 ARP .................................................... 25 85 8.7 Extended Link Services (ELS) ........................... 25 86 8.8 Login Parameters ....................................... 26 87 8.8.1 Common Service Parameters - FLOGI ............... 26 88 8.8.2 Common Services Parameters - PLOGI ............... 26 89 8.8.3 Class Service Parameters - PLOGI ................. 26 91 9. Security Considerations .................................... 27 93 10. Acknowledgements .......................................... 27 95 11. References ................................................ 27 97 12. Authors' Addresses ........................................ 28 99 Appendix A: Fibre channel Overview ............................ 28 100 A.1 Brief Tutorial ......................................... 28 101 A.2 Fibre Channel Header Fields ............................ 29 102 A.3 Acronyms and Glossary of FC Terms ...................... 32 104 Appendix B: Fibre Channel Protocol Considerations.............. 34 105 B.1 Reliability in Class 3 ................................. 34 106 B.2 Continuously Increasing SEQ_CNT ........................ 34 108 Appendix C: Other Mechanisms for FC layer Mappings ............ 35 109 C.1 Login on cached Mapping Information .................... 36 110 C.2 Login on ARP parsing ................................... 36 111 C.3 Login to Everyone ...................................... 37 112 C.4 Static Table ........................................... 37 114 1. Introduction 116 FC is a gigabit speed networking technology primarily used for 117 Storage Area Networking (SAN). FC is standardized under American 118 National Standards Institute (ANSI)and has specified a number of 119 documents describing its protocols, operations, and services. 121 Need: 123 Currently, Fibre Channel is predominantly used for communication 124 between storage devices and servers using the SCSI protocol, with 125 most of the servers still communicating with each other over LANs. 126 Although, the Fibre Channel standard [3] has architecturally defined 127 support for IP encapsulation and address resolution, it is 128 inadequately specified. ([3] prohibits broadcasts thus loops are not 129 covered; [10] has no support for Class 3) 131 This has lead to a nonstandard way of using IP over FC in the past. 132 Once such a standard method is completely specified, servers can 133 directly communicate with each other using IP over FC, possibly 134 boosting performance in Server host-to-host communications. This 135 technique will be especially useful in a Clustering Application. 137 Objective: 139 The major objective of this specification is to promote inter- 140 operable implementations of IP over Fibre Channel. This 141 specification describes a method for encapsulating IPv4 and Address 142 Resolution Protocol (ARP) packets over Fibre Channel. This 143 specification accommodates any FC topology (loop, fabric, or point- 144 to-point) and any FC class of service (1, 2 or 3). Use of IEEE 802.2 145 LLC/SNAP encapsulation for IP and ARP as specified in this document 146 shall not preclude the use of same encapsulation technique for other 147 protocol stacks (e.g. IPX, AppleTalk). 149 Organization: 151 Section 2 states the problem that is solved in this specification. 152 Section 3 describes the techniques used for encapsulating IP and ARP 153 packets in a FC sequence. Section 4 discusses ARP (IP address to MAC 154 address) and the required mappings and operation. Section 5 155 discusses the FC Layer mappings (MAC address to Port_ID). Section 6 156 provides a discussion on validation of the FC-layer mapping for the 157 different FC topologies. Section 7 describes the "Exchange" 158 Management in FC. Section 8 is a summary section and provides a quick 159 summary of the FC header settings, FC Link Service Commands, and a 160 summarized reference to features supported in ARP, FC Sequences, FC 161 Exchanges, and FC Login Parameters. 163 Appendix A provides a brief overview of the FC Protocols and Networks 164 along with a list of acronyms and a glossary of FC Terms used in this 165 specification. Appendix B addresses reliability in Class 3. 167 2. Problem Statement 169 This draft addresses two problems: 170 - A sequence format definition and encapsulation mechanism for IP 171 and ARP packets over FC 172 - A mechanism(s) Address Resolution 174 As noted earlier, the existing FC Standards [3], [10] are inadequate. 175 A solution to both problems has been proposed by the Fibre Channel 176 Association (FCA)[1]. FCA is a industry consortium of Fibre Channel 177 vendor companies and not a standards body. This draft specification 178 is largely based on the proposed solution in [1] and is an attempt to 179 provide a standardized specification addressing both the above stated 180 problems. 182 3. IP and ARP Encapsulation 184 3.1 FC Frame Format 186 All FC frames have a standard format much like LAN 802.x protocols. 187 (See Appendix A for Fibre Channel related Acronyms and Glossary of 188 Terms.) However, the exact size of each frame varies depending on the 189 sizes of the variable fields. The FC frame structure is shown in 190 Fig. 1. 192 +-------+--------+-----------+----//-------+-----+-----+ 193 | SOF |Frame |Optional | Payload |CRC | EOF | 194 | (4B) |Header |Header | |(4B) |(4B) | 195 | |(24B) |<----------------------->| | | 196 | | | (0-2112B) | | | 197 +-------+--------+-----------+----//-------+-----+-----+ 199 Fig. 1 FC Frame Format 201 The Start of Frame (SOF) and End of Frame (EOF) are both 4 bytes long 202 and act as frame delimiters. 204 The CRC is 4 bytes long and uses the same 32-bit polynomial used in 205 FDDI and is specified in ANSI X3.139 Fiber Distributed Data 206 Interface. 208 The Frame Header is 24 bytes long and has several fields associated 209 with identification and control of the payload. The values and 210 options for the fields that are relevant to the IP and ARP payloads 211 will be discussed later. 213 A FC Optional Header allows up to 4 optional header fields: 215 - An Expiration Security Header (16 bytes) 216 - Network (16 bytes) 217 - Association (32 bytes) 218 - Device (up to 64 bytes). 220 The IP and ARP FC sequences are required to carry the Network_Header 221 optional header field which is 16 bytes long. Other types of optional 222 headers are prohibited. The use of the Network_Header for the IP and 223 ARP payload encapsulation is described below. 225 In FC, an application level payload is called a Sequence. Typically, 226 a Sequence consists of more than one frame. Larger user data is 227 segmented and reassembled using two methods: Sequence Count and 228 Relative Offset. Use of Sequence Count is straight forward and data 229 blocks are sent using frames with increasing sequence counts (modulo 230 16). With Relative Offset, frames could temporally arrive out of 231 order. 233 When IP and ARP form the FC payload then only the First Frame of the 234 logical Sequence shall include the FC Network_Header. (Care should 235 exercised when this is the case. Note that the physical temporal 236 ordering of the frames can be different as a result of traversing 237 through a "Fabric".) Fig. 2 shows the logical First Frame and 238 logical subsequent frames 240 First Frame of a Logical FC Sequence 241 ---+------------+---------------------------+----------//----------+--- 242 | FC Header | FC Network Header | FC Sequence Data | 243 ---+------------+---------------------------+---------//-----------+--- 245 Subsequent Frames of a Logical FC Sequence 246 --+-----------+----------//------+-- 247 | FC Header | FC Sequence Data | 248 --+-----------+----------//------+-- 250 Fig. 2 FC Network Header in a Frame Sequence 252 The SOF, CRC, EOF control fields and other optional headers have been 253 omitted in the figure for clarity. 255 3.2 MTU 257 The Maximum Transmission Unit (MTU) for IP is defined as the length 258 of the IP packet, including IP headers. The theoretical maximum size 259 of an IP Packet is 65,535 bytes. In FC-4 the transmission unit is a 260 "Information Unit" and not frames. An N_Port may transmit an 261 Information Unit using multiple frames. The receiving N_Port will 262 assemble the frames to reconstruct the sent Information Unit. The 263 size of a single Information Unit is limited to 2^32-1, which is very 264 large. However, restricting the IP over FC MTU helps in buffer 265 resource allocation at N_Ports. A MTU of 65,280 bytes allows for up 266 to 255 bytes of overhead. The IEEE 802.2 LLC/SNAP headers requires 8 267 bytes, leaving the rest 247 bytes for future uses. 269 All implementations shall support at least an MTU of 52 bytes 270 representing an ARP packet (28 bytes) + LLC/SNAP header (8 bytes) + 271 FC network header (16 bytes) 273 All implementations shall support at least an MTU of 44 bytes 274 representing the minimum IP packet size (20 bytes minimum header ) + 275 LLC/SNAP header (8 bytes) + FC Network header (16 bytes). The IP 276 level Maximum Transmission Unit is 65280 as noted above. 278 There shall be a one-to-one mapping between an IP packet and a FC 279 sequence. In other words, one IP packet shall always map to only one 280 FC Sequence. 282 Note that, although the FC physical frame MTU is limited to 2112 283 bytes, it is hidden from IP and does not affect the IP MTU at FC-4. 285 3.3 FC Port and Node Network Addresses 287 FC devices are identified by Nodes and Ports. A Node is a collection 288 of one or more Ports identified by a unique nonvolatile 64-bit World 289 Wide Node name (WW_NN). Each Port in a node, is identified with a 290 unique nonvolatile 64-bit World Wide Port name (WW_PN), and a 291 volatile Port_ID. 293 Port_ID are 24-bits. In a FC frame header, the Port_ID is referred to 294 as S_ID (Source ID) to identify the port originating a frame, and 295 D_ID to identify the destination port. The Port_ID of a given port is 296 volatile. (The mechanism(s) by which a Port_ID may change in a FC 297 topology is outside the scope of this document.) 299 FC specifies a Network Address Authority (NAA) to distinguish between 300 the various name registration authorities that may be used to 301 identify the WW_PN and the WW_NN. A 4-bit NAA identifier, 12-bit 302 field set to 0x000 and an IEEE 48-bit MAC address together make the 303 64-bit WW_NN or the WW_PN addresses [2]. In a single port Node, the 304 WW_NN and the WW_PN may be identical. 306 The WW_PN names of the source and destinations are carried in the FC 307 Network Header. The format of the FC Network Header is shown in Fig. 308 3 and defined in the FC standards [2]. 310 The Network header is normally optional in FC but mandatory in this 311 specification. The 4 most significant bits in each address denotes 312 the Network Address Authority (NAA) type. In this specification, the 313 source and destination NAA binary pattern '0001' indicates the 314 IEEE-48 bit MAC address and is the only code point that is valid. 315 This NAA field value allows FC networks to be bridged with other FC 316 networks or traditional LANs. The Source (Destination) MAC address 317 occupies the lower 48 bits of the Network_Source_Address 318 (Network_Dest_Address), and the upper 12 bits are set to 0x000. 320 +--------+---------------------------------------+ 321 | D_NAA |Network_Dest_Address (High-order bits) | 322 |(4 bits)| (28 bits) | 323 +--------+---------------------------------------+ 324 | Network_Dest_Address (Low-order bits) | 325 | (32 bits) | 326 +--------+---------------------------------------+ 327 | S_NAA |Network_Source_Address(High-order bits)| 328 |(4 bits)| (28 bits) | 329 +--------+---------------------------------------+ 330 | Network_Source_Address (Low-order bit) | 331 | (32 bits) | 332 +--------+---------------------------------------+ 334 Fig. 3 Format of the Network Header Field 336 3.4 FC Payload Format 338 The payload of an FC sequence carrying an IP packet shall use the 339 format shown in Fig. 4. Fig. 5 shows the format when the payload is 340 an ARP packet. However, both formats use the 8-byte LLC/SNAP header. 342 +-----------------+-----//----------+-------------//------------+ 343 | LLC/SNAP Header | IP Header | IP Data | 344 | (8 bytes) | (20 bytes min.) | (65280 -IP Header) bytes | 345 +-----------------+-----//----------+-------------//------------+ 346 Fig. 4 Format of FC Sequence Payload carrying IP 348 +-----------------+-------------------+ 349 | LLC/SNAP Header | ARP Packet | 350 | (8 bytes) | (28 bytes) | 351 +-----------------+-------------------+ 353 Fig. 5 Format of FC Sequence Payload carrying ARP 355 As noted earlier, since FC frames belonging to the same Sequence can 356 be delivered out of order over a Fabric, the IP Header must appear in 357 the frame that has relative offset of 0. 359 A Logical Link Control (LLC) field along with a Sub Network Access 360 Protocol (SNAP) field is a method used to identify routed and bridged 361 non-OSI protocol PDUs and is defined in IEEE 802.2 and applied to IP 362 in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless 363 mode), the LLC header is 3-bytes long and consists of a 1-byte 364 Destination Service Access Point (DSAP)field, a 1-byte Source Service 365 Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 366 6. 368 +----------+----------+----------+ 369 | DSAP | SSAP | CTRL | 370 | (1 byte) | (1 byte | (1 byte) | 371 +----------+----------+----------+ 372 Fig. 6 LLC Format 374 The LLC's DSAP and SSAP values of 0xAA indicate that a IEEE 802.2 375 SNAP header follows. The LLC's CTRL value equal to 0x03 specifies 376 Unnumbered Information Command PDU. The LLC header value shall be 377 0xAA-AA-03. Other values of DSAP/SSAP indicate support for other 378 protocols but are prohibited in this specification. 380 The SNAP header is 5 bytes long and consists of a 3-byte 381 Organizationally Unique Identifier (OUI) field and a 2-byte Protocol 382 Identifier as shown in Fig. 7 384 +------+------+-------+------+------+ 385 | OUI | PID | 386 | ( 3 bytes) | (2 bytes) | 387 +------+------+-------+------+------+ 389 Fig. 7 SNAP Format 391 SNAP was invented to "encapsulate" LAN frames within the payload. 392 The SNAP OUI value 0x00-00-00 specifies that the PID is an EtherType 393 (i.e., routed non-OSI protocol). An OUI value of 0x00-80-C2 indicates 394 Bridged Protocols. 396 When the OUI value equals 0x00-00-00, the SNAP PID value of 0x08-00 397 indicates IP and a SNAP PID value of 0x08-06 indicates ARP. The 398 complete LLC/SNAP header is shown in Fig. 8. 400 +----------+----------+----------+-------+-------+-------+-------+------+ 401 | DSAP | SSAP | CTRL | OUI | PID | 402 | (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes | 403 +----------+----------+----------+-------+-------+-------+-------+------+ 405 Fig. 8 LLC/SNAP Header 407 3.5 ARP Packet Format 409 The format of the encapsulated ARP packet is based on [9] and is 410 shown in Fig. 9. 412 The 'HW Type' field shall be set to 0x00-01 414 Note: Technically, the correct HW Type value should be set to 0x00-06 415 according to RFC 1700 indicating IEEE 802 networks. However, as a 416 practical matter a HW Type value of 0x00-06 is known to cause 417 rejections from some Ethernet end stations when FC is bridged to 418 Ethernet. Translational bridges are normally expected to change this 419 field from Type 6 to 1 and vice versa under these configurations but 420 many do not. It is because of this reason the Type Code is set to 1 421 rather than 6. However, both HW Type values of 0x00-01 and 0x00-06 422 shall be accepted. 424 The 'Protocol' field shall be set to 0x08-00 indicating IP protocol. 426 The 'HW Addr Length' field shall be set to 0x06 indicating 6 bytes of 427 HW address. 429 The 'Protocol Addr Length' field shall be set to 0x04 indicating 4 430 bytes of IP address. 432 The 'Operation' Code field shall be either 0x00-01 for Request or 433 0x00- 02 for Reply. 435 The 'HW Addr of Sender' field shall be the 6 byte IEEE MAC address of 436 the sender. 438 The 'Protocol Addr of Sender' field shall be the 4 byte IP address of 439 the sender. 441 The 'HW Addr of Target' field shall be set to zero if the 'Operation 442 Code' field is set to 1. Otherwise, it shall be set to the 6 byte 443 IEEE MAC address of the original sender of the ARP request. 445 The 'Protocol Addr of Target' field shall be set to the 4 byte IP 446 address of the target. 448 +-------------------------+ 449 | HW Type | 2 bytes 450 +-------------------------+ 451 | Protocol | 2 bytes 452 +-------------------------+ 453 | HW Addr Length | 1 byte 454 +-------------------------+ 455 | Protocol Addr Length | 1 byte 456 +-------------------------+ 457 | Op Code | 2 bytes 458 +-------------------------+ 459 | HW Addr of Sender | 6 bytes 460 +-------------------------+ 461 | Protocol Addr of Sender | 4 bytes 462 +-------------------------+ 463 | HW Addr of Target | 6 bytes 464 +-------------------------+ 465 | Protocol Addr of Target | 4 bytes 466 +-------------------------+ 467 Total 28 bytes 468 Fig. 9 ARP Packet Format 470 The ARP packet is 28 bytes long in this particular application. The 471 difference between an ARP Request Packet and an ARP Reply Packet is 472 given below: 474 1. ARP Request packet: 'Operation' Code field = 0x00-01 and the 'HW 475 Addr of Target' is set to 0x00-00-00-00-00-00. 477 2. ARP Reply packet: 'Operation' Code field = 0x00-02 and the 'HW 478 Addr of Target' is appropriately set to the extracted 'HW Addr 479 of Sender' field from the ARP Request packet; similarly, the 480 'Protocol Addr of Target' is set to the extracted 'Protocol 481 Addr of Sender' field from the ARP Request packet 483 An ARP Request message is defined as a FC broadcast sequence carrying 484 the ARP Request packet. The exact mechanism used to broadcast a FC 485 sequence depends on the topology and will be discussed in the next 486 section. Compliant ARP broadcast messages shall include Network 487 Headers. 489 An ARP Reply message is defined as an ARP Reply packet encapsulated 490 in a FC sequence. Compliant ARP Reply messages shall include Network 491 Headers. 493 4. Address Resolution 495 4.1 Problem Description 497 Address Resolution is concerned with associating IP addresses with FC 498 Port addresses. As described earlier, FC device ports have two 499 addresses: 500 - a non-volatile unique 64-bit address called World Wide Port_Name 501 (WW_PN) 503 - a volatile 24-bit address called a Port_ID (see Appendix A for a 504 definition of Port_ID) 506 The Address Resolution mechanism therefore will need two levels of 507 mapping: 509 1. A mapping from IP address to the WW_PN address(i.e., IEEE 510 48-bit MAC address) 512 2. A mapping from WW_PN to the Port_ID 514 The address resolution problem is compounded by the fact that the 515 Port_ID is volatile and the second mapping has to be validated before 516 use. Moreover, this validation process can be different depending on 517 the FC network topology used. 519 Architecturally, the first level of mapping and control operation is 520 handled by the ARP layer, and the second level of mapping and control 521 by the FC layer. 523 4.2 ARP Layer Mapping and Operation 525 Whenever a source FC port with a designated IP address wishes to send 526 IP data to a destination FC port also with a designated IP address 527 then, the following steps are taken: 528 1. The source port shall consult its local mapping tables to 529 determine the . 530 (Since the NAA= b'0001' the WW_PN address and 48-bit MAC address 531 conceptually mean the same thing in this discussion.) 533 2. If such a mapping is found, then the source shall send the IP 534 data to the port whose WW_PN address was found in the table. 536 3. If such a mapping is not found, then the source shall send an 537 ARP broadcast message to its connected FC network in 538 anticipation of getting a reply from the correct destination 539 along with its WW_PN address. 541 4. When an ARP broadcast message is received by the destination it 542 shall generate an ARP response. Since the ARP response must be 543 addressed to a specific destination Port_ID, the FC layer 544 mapping between the MAC address and Port_ID (of the ARP Request 545 orginator) must be valid before the reply is sent. 547 4.2.1 ARP Broadcast in a Point-to-Point Topology 549 The ARP Request (Broadcast) and Reply mechanism described in 550 Section 3.5 and 4.2 still applies, although there is only one node 551 that receives this. 553 4.2.2 ARP Broadcast in a Private Loop Topology 555 In a private loop, the ARP broadcast message is sent using the 556 broadcast method specified in the FC-AL [7]standard. 558 1. The source port shall first send an Open Broadcast 559 Replicate primitive (OPN(fr))Signal forcing all the ports in 560 the loop (except itself), to replicate the frames that they 561 receive while examining the frame header's Destination_ID 562 field. 564 2. The source port shall remove this OPN(fr) signal when it 565 returns to it. 567 3. The loop is now ready to receive the ARP broadcast message 568 and is sent as a broadcast sequence, that is using FC 569 frames. 571 4. The source shall now send a FC frame containing the ARP 572 Request (ARP broadcast message), as a sequence in a Class 3 573 frame with the following FC Header D_ID field and F_CTL bits 574 in the FC header set to: 576 Destination ID: D_ID = 0xFF-FF-FF 578 Sequence Initiative : SI=0 580 Last Sequence : LS=1 582 End Sequence : ES=1. 584 The above FCTL settings apply to single-frame broadcasts, 585 as used in ARP sequences. This information is provided to 586 clarify ARP Broadcast usage only, and should not be 587 interpreted as prohibiting the use of multiframe sequence 588 broadcasts for other applications. 590 5. Compliant ARP broadcast sequences shall include Network Headers 591 with destination MAC address in the Network Header set to 592 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 593 6. The destination port recognizing its IP address in the ARP 594 packet shall respond with an ARP Reply message. 596 4.2.3 ARP Broadcast in a Public Loop Topology 598 The following steps will be followed when a port is configured in a 599 public loop: 601 1. A public loop device attached to a fabric through an FL_Port 602 shall not use the OPN(fr) signal primitive. Rather, it shall 603 send the broadcast sequence to the FL_Port at AL_PA = 0x00. 605 2. A fabric shall propagate the broadcast to all other ports 606 including the FL_Port which the broadcast arrived on. This 607 includes all F_Ports, and other FL_Ports. 609 3. On each FL_Port, the fabric shall first propagate the 610 broadcast by first using the primitive signal OPNfr, in order 611 to prepare the loop to receive the broadcast sequence. 613 4. A broadcast sequence is now sent on all ports (all FL_ports, 614 F_Ports)in Class 3 frame with: 616 Destination ID : D_ID = 0xFF-FF-FF 618 Sequence Initiative : SI=0 620 Last Sequence : LS=1 622 End Sequence : ES=1. 624 5. Compliant ARP broadcast sequences shall include Network Headers 625 with destination MAC address in the Network Header set to 626 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 628 6. The destination port recognizing its IP address in the ARP 629 packet shall respond with an ARP Reply message. 631 4.2.4 ARP Operation in a Fabric Topology 633 1. Nodes directly attached to fabric do not require the OPN(fr) 634 primitive signal. 636 2. A broadcast sequence is now sent on all ports (all FL_ports, 637 F_Ports)in Class 3 frame with: 639 Destination ID : D_ID = 0xFF-FF-FF 641 Sequence Initiative : SI=0 643 Last Sequence : LS=1 644 End Sequence : ES=1. 646 3. Compliant ARP broadcast sequences shall include Network Headers 647 with destination MAC address in the Network Header set to 648 0xFF-FF-FF-FF-FF-FF and NAA = b'0001' 650 4. The destination port recognizing its IP address in 651 the ARP packet shall respond with an ARP Reply 653 5. Mechanisms for Maintaining FC Layer Mappings 655 FC layer mapping between the WW_PN and the Port_ID is independent of 656 the ARP mechanism and is more closely associated with the details of 657 the FC protocols. Two main mechanisms - Name Server and FARP that may 658 be used to create and maintain WW_PN to Port_ID tables are described 659 here. Other less formal mechanisms are described in Appendix C. 661 An implementation shall support at least one of the avove two methods 662 and the preferred method is a configuration and administration issue. 663 If an implementation supports only the the Name Server then it shall 664 also support a FARP-REPLY. 666 5.1 Use of Name Server 668 This method is used in environments where a Name Server is 669 available[4]. 671 1. A Name Server may be referenced to resolve unmapped WW_PN 672 addresses. 674 2. Any upper layer send request for which there is not a Port_ID 675 to WW_PN mapping can trigger a query to a name server. The 676 WW_PN must be re-formatted in the 64-bit WW_PN format before 677 the query is issued. 679 3. The format of the Name Server query and response is outside 680 the scope of this document. See[4] for a typical example and 681 [14] for a Name Server implementation. 683 4. The query response from the Name Server must contain the 684 Port_ID associated with the WW_PN specified in the query. 686 5. Normal Port Login procedures follow at this point before 687 packets can be forwarded to a port. 689 5.2 FARP 691 The Fibre Channel Address Resolution Protocol (FARP) is a method 692 using ELS commands to resolve mapping in environments 693 without a Name Server. That is, when the WW_PN is known, but not the 694 D_ID and a Name Server service doesn't exist. This situation arises, 695 for instance, when Login tables entries expire. 697 The FARP-REQ Extended Link Service Broadcast Request command shall 698 resolve Port_IDs of communicating Fibre Channel devices. A FARP-REQ 699 can be used to retrieve a specific N_Port's current Port_ID given the 700 unique WW_PN and WW_NN. This is accomplished by requesting either a 701 FARP-REPLY ELS Unicast command, or by indicating that the Responder 702 N_Port shall perform a login with the FARP-REQ Requester. No sequence 703 initiatives is transferred with the FARP-REQ and therefore no Reply 704 (ACCEPT or REJECT) is sent as a response. Reception of a FARP-REQ 705 causes a higher level entity at the responding host to send a FARP- 706 REPLY, which is an ELS command that transfers sequence initiative and 707 therefore expects an ELS response (ACCEPT or REJECT). 709 Protocol: 711 FARP-REQ (ELS broadcast) Request Sequence 713 No Reply Sequence 715 FARP-REPLY (ELS command) Sequence 717 Accept Reply Sequence 719 Format: FT-1 721 Addressing: 723 - For a FARP-REQ, The S_ID designates the Requester 724 N_Port requesting addressing information. The D_ID is the 725 broadcast identifier, 0xFF-FF-FF. 727 - For a FARP-REPLY, the S_ID designates the N_Port ID of the 728 device matching the Responder Address Information in the FARP 729 Request. The D_ID is the N_Port ID of the device that initiated 730 the FARP request. 732 Payload: There are 2 formats of the FARP-REQ payload depending on 733 the address information carried. 735 Both formats carry common fields: command code, Match Address Code 736 Point, Port_ID of Requester, Responder Flags, and Port_ID of 737 Responder. 739 The first format carries the WW_PN and WW_NN of both the Requester 740 and Responder while the second format carries the IP addresses of 741 Requester and Responder. Note that the NAA is implicitly assumed to 742 be defined to be equal to b'0001' indicating IEEE-48-bit MAC 743 addresses are contained in World Wide Port and Node Names. 745 In the first format the "WW_PN of Responder" and "WW_NN of Responder" 746 fields should be filled in with the Node and Port Names of the 747 desired Responder. 749 The Match Address Code Points define what addresses to match based on 750 these code points. 752 The Responder Flags define what Responder action if the result of the 753 Match Address Code Points is successful. 755 +-----------------------------------------------------------------+ 756 | FARP-REQ Payload | 757 +-----------------------------+---------+-------------------------+ 758 | Field | Size | | 759 | |(Bytes) | Remarks | 760 +-----------------------------+---------+-------------------------+ 761 | 0x54-00-00-00 | 4 | | 762 +-----------------------------+---------+-------------------------+ 763 | Match Address Code Points | 1 | | 764 +-----------------------------+---------+-------------------------+ 765 | Port_ID of Requester | 3 | | 766 +-----------------------------+---------+-------------------------+ 767 | Responder Flags | 1 | | 768 +-----------------------------+---------+-------------------------+ 769 | Port_ID of Responder | 3 | set to 0x00-00-00 | 770 +-----------------------------+---------+-------------------------+ 771 |WW_PN of Requester | 8 | | 772 |(FARP-REQ) | | | 773 +-----------------------------+---------+-------------------------+ 774 |WW_NN of Requester | 8 | | 775 |(FARP-REQ) | | | 776 +-----------------------------+---------+-------------------------+ 777 |WW_PN of Responder | 8 | | 778 +-----------------------------+---------+-------------------------+ 779 |WW_NN of Responder | 8 | | 780 +-----------------------------+---------+-------------------------+ 782 +-----------------------------------------------------------------+ 783 | FARP-REQ Payload | 784 +-----------------------------+---------+-------------------------+ 785 | Field | Size | | 786 | |(Bytes) | Remarks | 787 +-----------------------------+---------+-------------------------+ 788 | 0x54-00-00-00 | 4 | | 789 +-----------------------------+---------+-------------------------+ 790 | Match Address Code Points | 1 | | 791 +-----------------------------+---------+-------------------------+ 792 | Port_ID of Requester | 3 | | 793 +-----------------------------+---------+-------------------------+ 794 | Responder Flags | 1 | | 795 +-----------------------------+---------+-------------------------+ 796 | Port_ID of Responder | 3 | set to 0x00-00-00 | 797 +-----------------------------+---------+-------------------------+ 798 |IP Address of Requester | 16 |IPv4 Add.= lower 32 bits | 799 | (FARP-REQ) | | | 800 | | |Upper 96 bits reserved | 801 +-----------------------------+---------+-------------------------+ 802 |IP Address of Responder | 16 |IPv4 Add.= lower 32 bits | 803 | | | | 804 | | |Upper 96 bits reserved | 805 +-----------------------------+---------+-------------------------+ 807 In the first format, the FARP-REQ Requester supplies the WW_PN of the 808 Responder, the WW_NN of the Responder, or both. 810 WW_PN in FARP is the 8-byte WW_PN of the Requester/ Responder to the 811 FARP-REQ. 813 WW_NN in FARP is the 8-byte WW_NN of the Requester/ Responder to the 814 FARP-REQ. 816 In the second format, the FARP-REQ Requester supplies either a 32-bit 817 IPv4 Address (in future a 128-bit IPv6 address) of the Requester and 818 Responder. The upper 96 bits are set to '0' with the current use of 819 IPv4 address. 821 Port_ID of Requester: is the 24-bit Port_ID used in the S_ID field of 822 the FARP-REQ header. 824 Port_ID of Responder: is the 24-bit Port_ID used in the S_ID field of 825 the FARP-REPLY header. 827 Responder Flags: is an 8-bit field (bits 0-7) that defines the action 828 of the Responder. This field is only valid in a FARP-REQ. 830 FARP-REQ is an ELS broadcast command. You do not have to be logged 831 in to issue a FARP request. 833 Possible Responder Actions: 834 Port Login (P_LOGI) 835 Sent to the Port Identified by " Requester Port_ID" field 836 when responder bit 0 (INIT_PLOGI) == binary '1' 837 FARP-REPLY Sequence 838 Sent to the Port Identified by "Requester Port_ID" field 839 when responder bit 1 (INIT_FARP-REPLY) == binary '1' 841 Bits 0 (INIT-PLOGI) = binary '1' and Bit 1 (INIT_FARP-REPLY) = binary 842 '1' at the same time is prohibited. Recipients of the FARP Request 843 ELS shall not issue a Service Reject (LS_RJT) if FARP is not 844 supported. 846 Table below indicates the action performed for each bit. If no bits 847 are set, the Responder will take no action. 849 +----------+-------------------------------------------------------+ 850 | | FARP Responder Flag | 851 +----------+----------------+--------------------------------------+ 852 | Bit | Bit Name | Action | 853 | Position | | | 854 +----------+----------------+--------------------------------------+ 855 | 0 | INIT_PLOGI | Initiate P_LOGI to the Requester | 856 +----------+----------------+--------------------------------------+ 857 | 1 | INIT_FARP-REPLY| Send FARP_RES message to Requester | 858 +----------+----------------+--------------------------------------+ 859 | 2 to 7 | Reserved | | 860 +----------+----------------+--------------------------------------+ 861 For each recipient of the FARP-REQ Broadcast ELS, the recipients 862 match one or more addresses based on the encoded bits of the "FARP 863 Match Address Code Points" field. This is shown in the following 864 table: 866 +------------------------------------------------------------------+ 867 | FARP Match Address Code Points | 868 +------------------------------------------------------------------+ 869 | LSBits | Bit name | Action | 870 +-----------+------------------+-----------------------------------+ 871 | 0000 | Reserved | | 872 +-----------+------------------+-----------------------------------+ 873 | 0001 | MATCH_WW_PN | Match on WW_PN of Responder | 874 +-----------+------------------+-----------------------------------+ 875 | 0010 | MATCH_WW_NN | Match on WW_NN of Responder | 876 +-----------+------------------+-----------------------------------+ 877 | 0011 | MATCH_WW_PN & | Match on both WW_PN and | 878 | | MATCH_WW_NN | WW_NN of Responder | 879 +-----------+------------------+-----------------------------------+ 880 | 0100 to | Reserved | | 881 | 1000 | | | 882 +-----------+------------------+-----------------------------------+ 883 | 1001 | MATCH_IPv4 | Match on IPv4 Address of Responder| 884 +-----------+------------------+-----------------------------------+ 885 | 1010 | Reserved | Future use for MATCH_IPv6 | 886 | | | Match on IPv6 Address of Responder| 887 +-----------+------------------+-----------------------------------+ 888 | 1011 to | Reserved | | 889 | 1111 | | | 890 +-----------+------------------+-----------------------------------+ 892 Note that bit-3 of the LSB differentiates between World_Wide Names 893 and IP addresses. 895 If a Node receives a FARP-REQ with MATCH_WW_PN (0001) or MATCH_WW_NN 896 (0001) or both (0011) Match Address Code Points, then it may issue a 897 response according to the FARP Responder Flag. 899 - Support for the MATCH_WW_PN is mandatory. 900 - Support for the MATCH_WW_NN is optional. 901 - Support for both MATCH_WW_PN and MATCH_WW_NN at the same time 902 is optional 904 If a Node receives a FARP_REQ with MATCH_IPv4 (1001) Match Address 905 Code Points, then it may issue a response according to the FARP 906 Responder Flag. Support for the FARP with MATCH_IPv4 is optional. 908 If there are no matches or support is optional then a silent behavior 909 from the Responder is valid. 911 FARP-REPLY is an ELS command directed to the Port_ID of the FARP-REQ 912 Requester. You do not have to be logged in to the FARP-REQ Requester 913 to issue a FARP-REPLY. The format of the FARP-REPLY payload is as 914 follows: 916 +---------------------------------------------------------------------+ 917 | FARP-REPLY Payload with WW-Names | 918 +-------------------------------------+---------+---------------------+ 919 | Field | Size | Remarks | 920 | | (Bytes) | | 921 +-------------------------------------+---------+---------------------+ 922 | 0x55-00-00-00 | 4 | | 923 +-------------------------------------+---------+---------------------+ 924 | Match Address Code Points | 1 | | 925 +-------------------------------------+---------+---------------------+ 926 | Port_ID of Requester | 3 | | 927 +-------------------------------------+---------+---------------------+ 928 | Responder Flags | 1 | Not used | 929 +-------------------------------------+---------+---------------------+ 930 | Port_ID of Responder | 3 | | 931 +-------------------------------------+---------+---------------------+ 932 |WW_PN of Requester (FARP-REQ) | 8 | | 933 +-------------------------------------+---------+---------------------+ 934 |WW_NN of Requester (FARP-REQ) | 8 | | 935 +-------------------------------------+---------+---------------------+ 936 |WW_PN of Responder | 8 | | 937 +-------------------------------------+---------+---------------------+ 938 |WW_NN of Responder | 8 | | 939 +-------------------------------------+---------+---------------------+ 941 +--------------------------------------------------------------------+ 942 | FARP-REPLY Payload with IP Addresses | 943 +------------------------------------+---------+---------------------+ 944 | Field | Size | | 945 | | (Bytes) | Remarks | 946 +------------------------------------+---------+---------------------+ 947 | 0x55-00-00-00 | 4 | | 948 +------------------------------------+---------+---------------------+ 949 | Match Address Code Points | 1 | | 950 +------------------------------------+---------+---------------------+ 951 | Port_ID of Requester | 3 | | 952 +------------------------------------+---------+---------------------+ 953 | Responder Flags | 1 | Not used | 954 +------------------------------------+---------+---------------------+ 955 | Port_ID of Responder | 3 | | 956 +------------------------------------+---------+---------------------+ 957 |IP Address of Requester (FARP-REQ) | 16 |IPv4 Add.=low 32 bits| 958 | | |(In future | 959 | | |IPv6 Add.=128 bits) | 960 +------------------------------------+---------+---------------------+ 961 |IP Address of Responder | 16 |IPv4 Add.=low 32 bits| 962 | | |(In future | 963 | | |IPv6 Add.=128 bits ) | 964 +------------------------------------+---------+---------------------+ 966 6. FC Layer Address Validation 968 At all times, the mapping has to be validated 969 before use. There are many events that can invalidate this mapping. 970 The following discussion addresses conditions when such a validation 971 is required. 973 6.1 General Discussion 975 After a link interruption occurs, the Port_ID of a port may change. 976 After the interruption, the Port_IDs of all other ports that have 977 previously performed PLOGI (N_Port Login) with this port may have 978 changed, and its own Port_ID may have changed. 980 Because of this, address validation is required after a LIP in a loop 981 topology [7]or after NOS/OLS in a point-to-point topology [6]. 983 Port_IDs will not change as a result of Link Reset(LR),thus address 984 validation is not required. 986 In addition to actively validating devices after a link interruption, 987 if a port receives any FC-4 data frames (other than broadcast 988 frames), from a port that is not currently logged in, then it shall 989 send an explicit Extended Link Service (ELS) Request logout (LOGO) 990 command to that port. 992 ELS commands (Requests and Replies) are used by an N_Port to solicit 993 a destination port (F_Port or N_Port) to perform some link-level 994 function or service.) The LOGO Request is used to request 995 invalidation of the service parameters and Port_ID of the recipient 996 N_Port. 998 The level of initialization and subsequent validation and recovery 999 reported to the upper (FC-4) layers is implementation-specific. 1001 In general, an explicit Logout (LOGO) shall be sent whenever the FC- 1002 Layer mapping between the Port_ID and WW_PN of a remote port is 1003 removed. 1005 The effect of power-up or re-boot on the mapping tables is outside 1006 the scope of this specification. 1008 6.2 FC Layer Address Validation in a Point-to-Point Topology 1010 No validation is required after LR. In a point-to-point topology, 1011 NOS/OLS causes implicit logout of each port and after a NOS/OLS, each 1012 port must perform a PLOGI [2]. 1014 6.3 FC Layer Address Validation in a Private Loop Topology 1016 After a LIP, a port shall not transmit any link data to another port 1017 until the address of the other port has been validated. The 1018 validation consists of completing either ADISC or PDISC. (See 1019 Appendix A) 1020 ADISC (Address Discovery) is an ELS command for discovering the hard 1021 addresses - the 24-bit identifier- of NL_Ports [5], [6]. 1023 PDISC (Discover Port) is an ELS command for exchanging service 1024 parameters without affecting login state [5], [6]. 1026 As a requester, this specification prohibits PDISC and requires 1027 ADISC. 1029 As a responder, an implementation may need to respond to both ADISC 1030 and PDISC for compatibility with other FC specifications. 1032 If the three addresses, Port_ID, WW_PN, WW_NN, exactly match the 1033 values prior to the LIP, then any active exchanges may continue. 1035 If any of the three addresses have changed, then the node must be 1036 explicitly logged out [4], [5]. 1038 If a port's N_Port ID changes after a LIP, then all active Port-ID to 1039 WW_PN mappings at this port must be explicitly logged out. 1041 6.4 FC Layer Address Validation in a Public Loop Topology 1043 A FAN (Fabric Address Notification) ELS command is sent by the fabric 1044 to all known previously logged in ports following an initialization 1045 event. Therefore, after a LIP, hosts may wait for this notification 1046 to arrive or they may perform a FLOGI. 1048 The WW_PN and WW_NN of the fabric FL_Port contained in the FAN ELS or 1049 FLOGI response must exactly match the values before the LIP. In 1050 addition, the AL_PA obtained by the port must be the same as the one 1051 before the LIP. 1053 If the above conditions are met, the port may resume all exchanges. 1054 If not, then FLOGI (Fabric login) must be performed with the fabric 1055 and all nodes must be explicitly logged out. 1057 A public loop device will have to perform the private loop 1058 authentication to any nodes on the local loop which have an Area + 1059 Domain Address == 0x00-00-XX 1061 6.5 FC Layer Address Validation in a Fabric Topology 1063 No validation is required after LR (link reset). 1065 After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID 1066 of the port, the WW_PN of the fabric, and the WW_NN of the fabric are 1067 the same as before the NOS/OLS, then the port may resume all 1068 exchanges. If not, all nodes must be explicitly, logged out [2]. 1070 7. Exchange Management 1072 7.1 Exchange Origination 1074 FC Exchanges shall be established to transfer data between ports. 1075 Frames on IP exchanges shall not transfer Sequence Initiative. 1077 7.2 Exchange Termination 1079 With the exception of the recommendations in Appendix B, "Reliability 1080 in Class 3", the mechanism for aging or expiring exchanges based on 1081 activity, timeout, or other method is outside the scope of this 1082 document. 1084 Exchanges may be terminated by either port. 1086 The Exchange Originator may terminate Exchanges by setting the LS 1087 bit, following normal FC standard FC-PH [2] rules. This specification 1088 prohibits the use of the NOP ELS with LS set for Exchange 1089 termination. 1091 Exchanges may be torn down by the Exchange Originator or Exchange 1092 Responder by using the ABTS_LS protocol. The use of ABTS_LS for 1093 terminating aged exchanges or error recovery is outside the scope of 1094 this document. 1096 The termination of IP exchanges by Logout is discouraged, since this 1097 may terminate active exchanges on other FC-4s. 1099 8. Summary of Supported Features 1101 Note: 'Required' means the feature support is mandatory, 'Prohibited' 1102 means the feature support is not valid, and 'Settable' means support 1103 is as specified in the relevant standard. 1105 8.1 FC-4 Header 1106 +--------------------------------------------------------------------+ 1107 | Feature | Support | Notes | 1108 +--------------------------------------------------------------------+ 1109 | Type Code ( = 5) ISO8802-2 LLC/SNAP | Required | 2 | 1110 | Network Headers | Required | 3 | 1111 | Other Optional Headers | Prohibited | | 1112 +--------------------------------------------------------------------+ 1114 Notes: 1116 1. This table applies only to FC-4 related data, such as IP and 1117 ARP packets. This table does not apply to link services and 1118 other non-FC-4 sequences (PLOGI, for example) that must occur 1119 for normal operation. 1121 2. The TYPE field in the FC Header (Word 2 bits 31-24) must 1122 indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This 1123 revision of the document focuses solely on the issues related 1124 to running IP and ARP over FC. All other issues are outside 1125 the scope of this document, including full support for IEEE 1126 802.2 LLC. 1128 3. DF_CTL field (Word 3, bits 23-16 of FC-Header)must indicate 1129 the presence of a Network Header (0010 0000) on the First 1130 logical Frame of FC-4 sequences. 1132 8.2 R_CTL 1134 R_CTL in FC-Header: Word 0, bits 31-24 1136 +--------------------------------------------------------------------+ 1137 | Feature | Support | Notes | 1138 +--------------------------------------------------------------------+ 1139 | Information Category (R_CTL Routing): | | | 1140 | | | | 1141 | FC-4 Device Data | Required | 1 | 1142 | Extended Link Data | Required | 2 | 1143 | FC-4 Link Data | Prohibited | | 1144 | Video Data | Prohibited | | 1145 | Basic Link Data | Required | 3 | 1146 | Link Control | Required | 4 | 1147 | | | | 1148 | R_CTL information : | | | 1149 | | | | 1150 | Uncategorized | Prohibited | | 1151 | Solicited Data | Prohibited | | 1152 | Unsolicited Control | Required | 2 | 1153 | Solicited Control | Required | 2 | 1154 | Unsolicited Data | Required | 1 | 1155 | Data Descriptor | Prohibited | | 1156 | Unsolicited Command | Prohibited | | 1157 | Command Status | Prohibited | | 1158 +--------------------------------------------------------------------+ 1160 Notes: 1162 1. This is required for FC-4 (IP and ARP) packets 1164 - Routing bits of R_CTL field must indicate Device Data 1165 frames (0000) 1167 - Information Category of R_CTL field must indicate 1168 Unsolicited Data (0100) 1170 2. This is required for Extended Link Services. 1172 3. This is required for Basic Link Services. 1174 4. This is required for Link Control frames. 1176 8.3 F_CTL 1178 F_CTL in FC-Header: Word 2, bits 23-0 1179 +--------------------------------------------------------------------+ 1180 | Feature | Support | Notes | 1181 +--------------------------------------------------------------------+ 1182 | Exchange Context | Settable | | 1183 | Sequence Context | Settable | | 1184 | First / Last / End Sequence (FS/LS/ES) | Settable | | 1185 | Chained Sequence | Prohibited | | 1186 | Sequence Initiative (SI) | Settable | 1 | 1187 | X_ID Reassigned / Invalidate | Prohibited | | 1188 | Unidirectional Transmit | Settable | | 1189 | Continue Sequence Condition | Required | 2 | 1190 | Abort Seq. Condition -continue and single seq.| Required | 3 | 1191 | Relative Offset - Unsolicited Data | Settable | 4 | 1192 | Fill Bytes | Settable | | 1193 +--------------------------------------------------------------------+ 1194 Notes: 1195 1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for 1196 sending data to each N_Port in the network and a dedicated 1197 RX_ID for receiving data from each N_Port as well. Exchanges 1198 are used in a unidirectional mode, thus setting sequence 1199 initiative is not valid for FC-4 frames. Sequence initiative 1200 is valid when using Extended Link Services. 1201 2. This field is required to be 00, no information. 1202 3. Sequence error policy is requested by an exchange originator 1203 in the F_CTL Abort Sequence Condition bits in the first data 1204 frame of the exchange. For classes 1 and 2, ACK frame is 1205 required to be "continuous sequence". 1206 4. Relative offset prohibited on all other types (Information 1207 Category) of frames. 1209 8.4 Sequences 1210 +---------------------------------------------------------------------+ 1211 | Feature | Support |Notes | 1212 +---------------------------------------------------------------------+ 1213 | Class 2 open sequences / exchange | 1 | 1 | 1214 | Length of seq. not limited by end-to-end credit | Required | 2 | 1215 | Maximum sequence size - IP sequences | 65536 | 3 | 1216 | Maximum sequence size - ARP sequences | 532 | 4 | 1217 | Capability to receive sequence of maximum size | Optional | 5 | 1218 | Sequence Streaming | Prohibited | 6 | 1219 | Stop Sequence Protocol | Prohibited | | 1220 | ACK_0 support | Optional | 7 | 1221 | ACK_1 support | Required | 7 | 1222 | ACK_N support | Prohibited | | 1223 | Class of Service for transmitted sequences | 1, 2 or 3 | 8 | 1224 | Continuously Increasing Sequence Count | Optional | 9,10 | 1225 +---------------------------------------------------------------------+ 1226 Notes: 1227 1. Only one active sequence per exchange is optional. 1229 2. A sequence initiator shall be capable of transmitting 1230 sequences containing more frames than the available credit 1231 indicated by a sequence recipient at login. FC-PH [2] end-to 1232 end flow control rules will be followed when transmitting such 1233 sequences. 1235 3. Maximum sequence size is 65535 bytes. 1237 Minimum FC MTU for first FC Frame = 16 bytes Net. Hdr. + 8 1238 bytes 1239 LLC/SNAP + 20 Bytes IP header + 0 bytes IP payload = 44 bytes 1241 4. 8 bytes LLC/SNAP + ARP packet 28 bytes = 36 bytes. 1242 Minimum FC MTU = 16 bytes Net. Header + 36 bytes = 52 bytes 1244 5. Some OS environments may not handle the max MTU of 65535. It 1245 is up to the administrator to configure the Max MTU for all 1246 systems. 1248 6. All class 3 sequences are assumed to be non-streamed. 1250 7. Only applies for Class 1 and 2. Use of ACK_1 is default, 1251 ACK_0 used if indicated by sequence recipient at login. 1253 8. The administrator configured class of service is used, except 1254 where otherwise specified (e.g. Broadcasts are always sent in 1255 class 3). 1257 9. Review Appendix B, "Reliability in Class 3". 1259 10. The first frame of the first sequence of anew exchange must 1260 have SEQ_CNT = 0 [2]. 1262 8.5 Exchanges 1263 +--------------------------------------------------------------------+ 1264 | Feature | Support | Notes | 1265 +--------------------------------------------------------------------+ 1266 | X_ID interlock support | Optional | 1 | 1267 | OX_ID=FFFF | Prohibited | | 1268 | RX_ID=FFFF | Optional | 2 | 1269 | Action if no exchange resources available | P_RJT | 3 | 1270 | Long Lived Exchanges | Optional | 4 | 1271 | Reallocation of Idle Exchanges | Optional | | 1272 +--------------------------------------------------------------------+ 1273 Notes: 1274 1. Only applies to Classes 1 and 2, supported by the exchange 1275 originator. A Port shall be capable of interoperating with 1276 another Port that requires X_ID interlock. The exchange 1277 originator facility within the Port shall use the X_ID 1278 Interlock protocol in such cases. 1280 2. An exchange responder is not required to assign RX_IDs. If a 1281 RX_ID of FFFF is assigned, it is identifying exchanges based 1282 on S_ID / D_ID / OX_ID only. 1284 3. In Classes 1 and 2, a Port shall reject a frame that would 1285 create a new exchange with a P_RJT containing reason code 1286 "Unable to establish exchange". In Class 3, the frame would be 1287 dropped. 1289 4. When an exchange is created between 2 Ports for IP/ARP data, 1290 it remains active while the ports are logged in with each 1291 other. An exchange shall not transfer Sequence Initiative 1292 (SI). Broadcasts and ELS commands may use short lived 1293 exchanges. 1295 8.6 ARP 1296 +--------------------------------------------------------------------+ 1297 | Feature | Support | Notes | 1298 +--------------------------------------------------------------------+ 1299 | ARP Server Support | Prohibited | 1 | 1300 | Response to ARP requests | Required | 2 | 1301 | ARP requests transmitted as broadcast message | Required | | 1302 | Class of Service for ARP requests | 3 | 3 | 1303 | Class of Service for ARP replies | 1, 2 or 3 | 4 | 1304 +--------------------------------------------------------------------+ 1305 Notes: 1306 1. Well-known Address FFFFFC is not used for ARP requests. Frames 1307 from Well-known Address FFFFFC are not considered to be ARP 1308 frames. Broadcast support is required for ARP. 1310 2. The IP Address is mapped to a specific MAC address with ARP. 1312 3. An ARP request is a broadcast message, thus Class 3 is always 1313 used. 1315 4. An ARP reply is a normal sequence, thus the administrator 1316 configured class of service is used. 1318 8.7 Extended Link Services (ELS) 1319 +--------------------------------------------------------------------+ 1320 | Feature | Support | Notes | 1321 +--------------------------------------------------------------------+ 1322 | Class of service for ELS commands / responses | 1,2 or 3 | 1 | 1323 | Explicit N-Port Login | Required | | 1324 | Explicit F-Port Login | Required | | 1325 | FLOGI ELS command | Required | | 1326 | PLOGI ELS command | Required | | 1327 | ADISC ELS command | Required | | 1328 | PDISC ELS command | Optional | 2 | 1329 | FAN ELS command | Required | 6 | 1330 | LOGO ELS command | Required | | 1331 | FARP-REQ ELS command | Required | 3 | 1332 | FARP-REPLY ELS command | Required | 4 | 1333 | Other ELS command support | Optional | 5 | 1334 +-----------------------------------------------+------------+-------+ 1335 Notes: 1336 1. The administrator configured class of service is used. 1338 2. PDISC is prohibited as requester. ADISC should be used 1339 instead. As a responder, an implementation may need to respond 1340 to both ADISC and PDISC for compatibility with other 1341 specifications. 1343 3. Sending a FARP-REQ is optional as Requester, however, support 1344 for receiving a FARP-REQ is Required at the Responder 1346 4. Sending FARP-REPLY is required for MATCH_WW_PN, support for 1347 all other Match Address Code Points is optional. 1349 5. If other ELS commands are received an LS_RJT may be sent. NOP 1350 is not required by this specification, and should not be used 1351 as a mechanism to terminate exchanges. 1353 6. Required for FL_Ports 1355 8.8 Login Parameters 1357 Unless explicitly noted here, a compliant implementation shall use 1358 the login parameters as described in [4]. 1360 8.8.1 Common Service Parameters - FLOGI 1362 - FC-PH Version, lowest version may be 0x09 to indicate 1363 'minimum 4.3'. 1365 - Can't use BB_Credit=0 for N_Port on a switched Fabric 1366 (F_Port). 1368 8.8.2 Common Service Parameters - PLOGI 1370 - FC-PH Version, lowest version may be 0x09 to indicate 1371 'minimum 4.3'. 1372 - Can't use BB_Credit=0 for N_Port in a Point-to-Point 1373 configuration 1375 - Random Relative Offset is optional. 1377 - Note that the 'Receive Data Field Size' fields specified in 1378 the PLOGI represent both optional headers and payload. 1380 - The MAC Address can therefore be extracted from the 6 lower 1381 bytes of the WW_PN field (when the IEEE 48-bit Identifier 1382 format is chosen as the NAA) during PLOGI or ACC payload 1383 exchanged during Fibre Channel Login [2]. 1385 - The MAC Address can also be extracted from the WW_PN field in 1386 the Network Header during ADISC (and ADISC ACC), or PDISC 1387 (and PDISC ACC). 1389 8.8.3 Class Service Parameters - PLOGI 1391 - Discard error policy only. 1393 9. Security Considerations 1395 FC frames are CRC protected for the header and payload using ANSI 1396 X3.139 specified 32-polynomial used with FDDI. Manipulation of header 1397 information without regenerating a new one will be easily detected. 1398 Independent of IP and ARP, Fibre Channel protocols do have special 1399 issues with security. Use of IP or ARP over FC does not introduce 1400 new security threats and is for most part transparent 1402 10. Acknowledgement 1404 This specification is based on FCA IP Profile, Version 3.3. The FCA 1405 IP Profile was a joint work of the Fibre Channel Association (FCA) 1406 vendor community. The following companies and organizations have 1407 contributed to the creation of the FCA IP Profile: Adaptec, Ancor, 1408 Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar, 1409 Gadzoox, Hewlett Packard, Interphase, Jaycor, LLNL, McData, Migration 1410 Associates, Orca Systems, Prisa, Q-Logic, Symbios, Systran, 1411 Tektronix, Univ. of Minnesota, Univ. of New Hamshire. Jon Infante 1412 from Emulex deserves special mention for his extensive comments. 1414 11. References 1416 [1] FCA IP Profile, Revision 3.3, May 15, 1997 1418 [2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI 1419 X3.230-1994 1421 [3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1422 1996 1424 [4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.7, August 1425 12, 1997 1427 [5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), 1428 Rev. 2.1, September 22, 1997 1430 [6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), 1431 Rev. 7.4, ANSI X3.297-1996 1433 [7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996 1435 [8] Postel, J. and Reynolds, J., "A standard for the Transmission of 1436 IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, Feb, 1988 1438 [9] Plummer, D. "An Ethernet Address Resolution Protocol -or- 1439 Converting Network Addresses to 48-bit Ethernet Address for 1440 Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, Nov 1441 1982. 1443 [10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995 1445 [11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), 1446 Rev. 9.3, ANSI X3.xxx-199x 1448 [12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", 1449 Ancot Corporation 1451 [13] Fibre Channel -Gigabit Communications and I/O for Computers 1452 Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2 1454 [14] Fibre Channel Generic Services -2 (FC-GS-2), Rev. 5.2 1455 X3.288-199x 1457 12. Authors' Addresses 1458 Murali Rajagopal 1459 Gadzoox Networks, Inc. 1460 711 Kimberly Avenue, Suite 100 1461 Placentia, CA 92870 1463 Phone: +1 714 577 6805 1464 Fax: +1 714 524 8508 1465 Email: murali@gadzoox.com 1467 Raj Bhagwat 1468 Gadzoox Networks, Inc. 1469 711 Kimberly Avenue, Suite 100 1470 Placentia, CA 92870 1472 Phone: +1 714 577 6806 1473 Fax: +1 714 524 8508 1474 Email: raj@gadzoox.com 1476 Wayne Rickard 1477 Gadzoox Networks, Inc. 1478 711 Kimberly Avenue, Suite 100 1479 Placentia, CA 92870 1481 Phone: +1 714 577 6803 1482 Fax: +1 714 524 8508 1483 Email: wayne@gadzoox.com 1485 APPENDIX A: Fibre Channel Overview 1487 A.1 Brief Tutorial 1489 FC standard [2] defines 5 "levels" (not layers) for its protocol 1490 description: FC-0, FC-1, FC-2, FC-3, and FC-4. The first three levels 1491 (FC-0, FC-1, FC-2) are largely concerned with the physical formatting 1492 and control aspects of the protocol. FC-3 is architecturally defined 1493 but not unspecified at this time. FC-4 is meant for supporting profiles 1494 of higher protocols such as IP and Small Computer System Interface (SCSI) 1495 and supports a relatively small set of higher level protocols compared to 1496 LAN protocols such as IEEE 802.3. 1498 FC devices are called "Nodes", each of which has at least one "Port" to 1499 connect to other ports. A Node may be a workstation, a disk drive or 1500 disk array, a camera, a display unit, etc. The set of hardware components, 1501 and transceivers, connecting two or more node ports is called a topology. 1503 A "Link" is two unidirectional paths flowing in opposite directions and 1504 connecting two Ports within adjacent Nodes. 1506 FC Nodes communicate using higher layer protocols such as SCSI and IP 1507 and are configured to operate using one of the following 1508 networking topologies: 1510 - Point-to-Point 1511 - Private Loop 1512 - Public Loop (attachment to a Fabric) 1513 - Fabric 1515 The point-to-point is the simplest of the four topologies, where only 1516 two nodes communicate with each other. The private loop may connect a 1517 number of devices (max 126) in a logical ring much like Token Ring and 1518 is distinguished from a public loop by the absence of a Fabric Node 1519 participating in the loop. The Fabric topology is a switched network 1520 where any attached node can communicate with any other. 1522 Table below summarizes the usage of port types depending on its location 1523 [12]. Note that E-Port is not relevant to any discussion in this 1524 specification but is included below for completeness. 1526 +-----------+-------------+-----------------------------------------+ 1527 | Port Type | Location | Topology Associated with | 1528 +-----------+-------------+-----------------------------------------+ 1529 | N_Port | Node | Point-to-Point or Fabric | 1530 +-----------+-------------+-----------------------------------------+ 1531 | NL_Port | Node |In N_Port mode -Point-to-Point or Fabric | 1532 | | |In NL_Port mode - Arbitrated Loop | 1533 +-----------+-------------+-----------------------------------------+ 1534 | F_Port | Fabric | Fabric | 1535 +-----------+-------------+-----------------------------------------+ 1536 | FL_Port | Fabric | In F_Port mode - Fabric | 1537 | | | In FL_Port mode - Arbitrated Loop | 1538 +-----------+-------------+-----------------------------------------+ 1539 | E_Port | Fabric | Internal Fabric Expansion | 1540 +-----------+-------------+-----------------------------------------+ 1542 A.2 Fibre Channel Header Fields 1544 The FC header as shown in the diagrams below contains routing and other 1545 control information to manage frames, sequences, and exchanges. The 1546 frame header is sent as 6 transmission words immediately following an SOF 1547 delimiter and before the data field. 1549 D_ID and S_ID: 1551 FC uses destination address routing [12], [13]. Frame routing in 1552 a point-to-point topology is trivial. 1554 For the Arbitrated Loop topology, with the destination NL_Port on 1555 the same AL, the source port must pick the destination port, 1556 determine its AL Physical Address, and "Open" the destination 1557 port. The frames must pass through other NL_Ports or the FL_Port 1558 on the loop between the source and destination, but these ports 1559 do not capture the frames. They simply repeat and transmit the 1560 frame. Either communicating port may "Close" the circuit. 1562 When the destination port is not on the same AL, the source 1564 NL_Port must open the FL_Port attached to a Fabric. Once in the 1565 Fabric, the Fabric routes the frames again to the destination. 1567 In a Fabric topology, the Fabric looks into the frame header, 1568 extracts the destination address (D_ID), searches its own routing 1569 tables, and sends the frame to the destination port along the path 1570 chosen. The process of choosing a path may be performed at each 1571 fabric element or switch until the F_Port attached to the destination 1572 N_Port is reached. 1574 Fibre Channel Frame Header, Network Header, and payload carrying IP Packet 1576 +---+----------------+----------------+----------------+--------------+ 1577 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1578 +---+----------------+----------------+----------------+--------------+ 1579 |0 | R_CTL | D_ID | 1580 +---+----------------+----------------+----------------+--------------+ 1581 |1 | CS_CTL | S_ID | 1582 +---+----------------+----------------+----------------+--------------+ 1583 |2 | TYPE | F_CTL | 1584 +---+----------------+----------------+----------------+--------------+ 1585 |3 | SEQ_ID | DF_CTL | SEQ_CNT | 1586 +---+----------------+----------------+----------------+--------------+ 1587 |4 | OX_ID | RX_ID | 1588 +---+--------+-------+----------------+----------------+--------------+ 1589 |5 | Parameter (Control or Relative Offset for Data ) | 1590 +---+-----------------------------------------------------------------+ 1591 |6 | NAA | Network_Dest_Address (Hi order bits) | 1592 +---+--------+-------+----------------+----------------+--------------+ 1593 |7 | Network_Dest_Address (Lo order bits) | 1594 +---+--------+-------+----------------+----------------+--------------+ 1595 |8 | NAA | Network_Src_Address (Hi order bits) | 1596 +---+--------+-------+----------------+----------------+--------------+ 1597 |9 | Network_Src_Address (Lo order bits) | 1598 +---+----------------+----------------+----------------+--------------+ 1599 |10 | DSAP | SSAP | CTRL | OUI | 1600 +---+----------------+----------------+----------------+--------------+ 1601 |11 | OUI | PID | 1602 +---+----------------+----------------+----------------+--------------+ 1603 |12 | IP Packet Data | 1604 +---+----------------+----------------+----------------+--------------+ 1605 |13 | ... | 1606 +---+----------------+----------------+----------------+--------------+ 1607 R_CTL (Routing Control) and TYPE(data structure): 1609 Frames for each FC-4 can be easily distinguished from the others 1610 at the receiving port using the R_CTL (Routing Control) and TYPE 1611 (data structure) fields in the frame header. 1613 The R_CTL has two sub-fields: Routing bits and Information category. 1614 The Routing bits sub-field has specific values that mean FC-4 data 1615 follows and the Information Category tells the receiver the "Type" 1616 of data contained in the frame. The R_CTL and TYPE code points are 1617 shown in the diagrams. 1619 Other Header fields: 1621 F_CTL (Frame Control) and SEQ_ID (Sequence Identification), 1622 SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), 1623 RX_ID (Responder exchange Identifier), and Parameter fields are 1624 used to manage the contents of a frame, and mark information 1625 exchange boundaries for the destination port. 1627 F_CTL(Frame Control): 1629 The FC_CTL field is a 3-byte field that contains information 1630 relating to the frame content. Most of the other frame header 1631 fields are used for frame identification. Among other things, 1632 bits in this field indicate the first sequence, last sequence, or 1633 end sequence. Sequence Initiative bit is used to pass control of 1634 the next sequence in the exchange to the recipient. 1636 SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count): 1638 This is used to uniquely identify sequences within an Exchange. 1639 The uniquely identifies any active sequence. 1640 SEQ_CNT is used to uniquely identify frames within a Sequence to 1641 assure sequentiality of frame reception, and to allow unique 1642 correlation of link control frames with their related data frames. 1644 Originator Exchange Identifier (OX_ID) and Responder Exchange 1645 Identifier (RX_ID): 1647 The OX_ID value provides association of frames with specific 1648 Exchanges originating at a particular N_Port. The RX_ID field 1649 provides the same function that the OX_ID provides for the 1650 Exchange Originator. The OX_ID is meaningful on the Exchange 1651 Originator, and the RX_ID is meaningful on the Responder. 1653 DF_CTL (Data Field Control): 1655 The DF_CTL field specifies the presence or absence of optional 1656 headers between the Frame header and Frame Payload 1658 PARAMETER: 1660 The Parameter field has two meanings, depending on Frame type. 1662 For Link Control Frames, the Parameter field indicates the 1663 specific type of Link Control frame. For Data frames, this 1664 field contains the Relative Offset value. This specifies an 1665 offset from an Upper Layer Protocol buffer from a base address. 1667 Code Points for FC Frame with IP packet Data 1668 +---+----------------+----------------+----------------+--------------+ 1669 |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | 1670 +---+----------------+----------------+----------------+--------------+ 1671 | 0 | 0x04 | D_ID | 1672 +---+----------------+----------------+----------------+--------------+ 1673 | 1 | 0x00 | S_ID | 1674 +---+----------------+----------------+----------------+--------------+ 1675 | 2 | 0x05 | F_CTL | 1676 +---+----------------+----------------+----------------+--------------+ 1677 | 3 | SEQ_ID | 0x20 | SEQ_CNT | 1678 +---+----------------+----------------+----------------+--------------+ 1679 | 4 | OX_ID | RX_ID | 1680 +---+----------------+----------------+----------------+--------------+ 1681 | 5 | 0xXX-XX-XX-XX Parameter Relative Offset | 1682 +---+------+----------------------------------------------------------+ 1683 | 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) | 1684 +---+------+---------+----------------+----------------+--------------+ 1685 | 7 | Dest. MAC (Lo order bits) | 1686 +---+------+----------+----------------+------------------------------+ 1687 | 8 | 0001 | 0x000 | Src. MAC (Hi order bits) | 1688 +---+------+---------+----------------+----------------+--------------+ 1689 | 9 | Src. MAC (Lo order bits) | 1690 +---+----------------+----------------+----------------+--------------+ 1691 |10 | 0xAA | 0xAA | 0x03 | 0x00 | 1692 +---+----------------+----------------+----------------+--------------+ 1693 |11 | 0x00-00 | 0x08-00 | 1694 +---+----------------+----------------+----------------+--------------+ 1695 |12 | IP Packet Data | 1696 +---+----------------+----------------+----------------+--------------+ 1697 |13| ... | 1698 +---+----------------+----------------+----------------+--------------+ 1700 The Code Points for FC Frames with ARP packets are very similar to IP 1701 packets with the exception of PID value in Word 11 which is set to 1702 0x08-06. Also, the Network Header as shown above appears only in the 1703 first logical FC Sequence carrying IP. In the case, where FC frames 1704 carry ARP packets it is always present because these are single frame 1705 sequences. 1707 A.3 Acronyms and Glossary of FC Terms 1709 It is assumed that the reader is familiar with the terms and acronyms 1710 used in the FC protocol specification [2]. The following is provided for 1711 easy reference. 1713 First Frame: The frame that contains the SOFi field. This means a logical 1714 first and may not necessarily be the first frame temporally received in a 1715 sequence. 1717 Code Point: The coded bit pattern associated with control fields in frames 1718 or packets. 1720 PDU: Protocol Data Unit 1722 ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for 1723 aborting an exchange based on the ABTS recipient setting the 1724 Last_Sequence bit in the BA_ACC ELS to the ABTS 1726 ADISC: Discover Address. An ELS for discovering the Hard Addresses (the 1727 24 bit NL_Port Identifier) of N_Ports 1729 D_ID: Destination ID 1731 ES: End sequence. This FCTL bit in the FC header indicates this frame is 1732 the last frame of the sequence. 1734 FAN: Fabric Address Notification. An ELS sent by the fabric to all known 1735 previously logged in ports following an initialization event. 1737 FLOGI: Fabric Login. 1739 LIP: Loop Initialization. A primitive sequence used by a port to detect 1740 if it is part of a loop or to recover from certain loop errors. 1742 Link: Two unidirectional paths flowing in opposite directions and 1743 connecting two Ports within adjacent Nodes. 1745 LOGO: Logout. 1747 LR: Link reset. A primitive sequence transmitted by a port to initiate 1748 the link reset protocol or to recover from a link timeout. 1750 LS: Last sequence of Exchange. This FCTL bit in the FC header indicates 1751 the sequence is the last sequence of the exchange. 1753 Network Address Authority: A 4-bit field specified in Network Headers 1754 that distinguishes between various name registration authorities that 1755 may be used to identify the WW_PN and the WW_NN. NAA=b'0001' indicates 1756 IEEE-48-bit MAC addresses 1758 Node: A collection of one or more Ports identified by a unique World 1759 Wide Node Name (WW Node Name). 1761 NOS: Not Operational. A primitive sequence transmitted to indicate that 1762 the port transmitting this sequence has detected a link failure or is 1763 offline, waiting for OLS to be received. 1765 OLS: Off line. A primitive sequence transmitted to indicate that the 1766 port transmitting this sequence is either initiating the link 1767 initialization protocol, receiving and recognizing NOS, or entering the 1768 offline state. 1770 PDISC: Discover Port. An ELS for exchanging Service Parameters without 1771 affecting login state. 1773 Primitive Sequence: A primitive sequence is an Ordered Set that is 1774 transmitted repeatedly and continuously. 1776 Private Loop Device: A device that does not attempt fabric login (FLOGI) 1777 and usually adheres to PLDA. The Area and Domain components of the 1778 NL_Port ID must be 0x0000. These devices cannot communicate with any 1779 port not in the local loop. 1781 Public Loop Device: A device whose Area and Domain components of the 1782 NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the 1783 device must attempt to open AL_PA 0x00 and attempt FLOGI. These devices 1784 communicate with devices on the local loop as well as devices on the 1785 other side of a Fabric. 1787 Port: The transmitter, receiver and associated logic at either end of a 1788 link within a Node. There may be multiple Ports per Node. Each Port is 1789 identified by a unique Port_ID, which is volatile, and a unique World 1790 Wide Port Name (WW Port Name), which is unchangeable. In this document, 1791 the term "port" may be used interchangeably with NL_Port or N_Port. 1793 Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. In 1794 a Fibre Channel frame header, the Port_ID is referred to as S_ID (Source 1795 ID) to identify the port originating a frame, and D_ID to identify the 1796 destination port. The Port_ID of a given port is volatile (changeable). 1797 The mechanisms through which a Port_ID may change in a Fibre Channel 1798 topology are outside the scope of this document. 1800 PLOGI: Port Login. 1802 SI: Sequence Initiative 1804 World Wide Port_Name (WW_PN): Fibre Channel requires each Port to have 1805 an unchangeable WW_PN. Fibre Channel specifies a Network Address 1806 Authority (NAA) to distinguish between the various name registration 1807 authorities that may be used to identify the WW_PN. A 4-bit NAA 1808 identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address 1809 together make this a 64-bit field. 1811 World Wide Node_Name (WW_NN): Fibre Channel identifies each Node with a 1812 unchangeable WW_NN. In a single port Node, the WW_NN and the WW_PN may be 1813 identical. 1815 APPENDIX B: Fibre Channel Protocol Considerations 1817 B.1 RELIABILITY IN CLASS 3 1819 Problem: 1820 Sequence ID reuse in Class 3 can conceivably result in missing frame 1821 aliasing with no corresponding detection at the FC2 level. 1823 Prevention: 1825 This specification requires one of the following methods if Class 3 is 1826 used. 1828 - Continuously increasing Sequence Count (new Login Bit) - both 1829 sides must set When an N_Port sets the PLOGI login bit for 1830 continuously increasing SEQ_CNT, it is guaranteeing that it 1831 will transmit all frames within an exchange using a continuously 1832 increasing SEQ_CNT (see description below). 1834 - After using all SEQ_IDs (0-255) once, must start a new Exchange. 1835 It is recommended that a minimum of 4 Exchanges be used before 1836 an OX_ID can be reused. 1838 - Note: If an implementation is not checking the OX_ID when 1839 reassembling sequences, the problem can still occur. Cycling 1840 through some number of SEQ_IDs, then jumping to a new exchange 1841 does not solve the problem. SEQ_IDs must still be unique between 1842 two N_Ports, even across exchanges. 1844 - Use only single-frame Sequences. 1846 B.2 CONTINUOUSLY INCREASING SEQ_CNT 1848 This method allows the recipient to check incoming frames, knowing 1849 exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not 1850 repeat for 65,536 frames, the aliasing problem is significantly reduced. 1852 A login bit (PLOGI) is used to indicate that a device always uses a 1853 continuously increasing SEQ_CNT, even across transfers of sequence 1854 initiative. This bit is necessary for interoperability with some 1855 devices, and it provides other benefits as well. 1857 In the FC-PH-3 [11], the following is supported: 1859 Word 1, bit 17 - SEQ_CNT (S) 1860 0 = Normal FC-PH rules apply 1861 1 = Continuously Increasing SEQ_CNT 1863 Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will 1864 transmit all frames within an exchange using a continuously increasing 1865 SEQ_CNT. Each exchange shall start with SEQ_CNT = 0 in the first frame, 1866 and every frame transmitted after that shall increment the previous 1867 SEQ_CNT by one, even across transfers of sequence initiative. Any frames 1868 received from the other N_Port in the exchange shall have no effect on 1869 the transmitted SEQ_CNT. 1871 APPENDIX C: Other Mechanisms for FC Layer Mappings 1873 Each method should have some mechanism to ensure PLOGI has completed 1874 successfully before data is sent. A related concern in large networks is 1875 limiting concurrent logins to only those ports with active IP traffic. 1877 C.1 Login on Cached Mapping Information 1878 This method insulates the level performing LOGIN from the level 1879 interpreting ARP. It is more accommodating of non-ARP mechanisms for 1880 building the FC-layer mapping table. 1882 1. Broadcast messages that carry a Network Header contain 1883 the S_ID on the FC-header and WW_PN in the Network-header. 1884 Caching this information provides a correlation of Port_ID to 1885 WW_PN. If the received Broadcast message is compliant with this 1886 specification, the WW_PN will be the MAC Address. 1888 2. The WW_PN is "available" if Login has been performed to the 1889 Port_ID and flagged. If login has not been performed, the 1890 WW_PN is "unavailable". 1892 3. If an outbound packet is destined for a port that is 1893 "unavailable", the cached information (from broadcast) is used 1894 to look up the Port_ID. 1896 4. After sending an ELS PLOGI command (Port Login) to the Port (from 1897 a higher level entity at the host), waiting for an outbound packet 1898 before sending this Port Login conserves resources for only for 1899 those ports which wish to establish communication. 1901 5. After Port Login completes (ACC received), the outbound packet 1902 can be forwarded. At this point in time, both ends have the 1903 necessary information to complete their association. 1906 C.2 Login on ARP Parsing 1908 This method performs LOGIN sooner by parsing ARP before passing it up to 1909 higher levels for IP/MAC Address correlation. It requires a low-level 1910 awareness of the IP address, and is therefore protocol-specific. 1912 1. When an ARP Broadcast Message is received, the S_ID is extracted 1913 from the FC header and the corresponding Network_Source_Address 1914 from the Network Header. 1916 2. The ARP payload is parsed to determine if (a) this host is the 1917 target of the ARP request (Target IP Address match), and (b) if 1918 this host is currently logged in with the port (Port_ID = S_ID) 1919 originating the ARP broadcast. 1921 3. The ARP is passed to higher level for ARP Response generation. 1923 4. If a Port Login is required, an ELS PLOGI command (Port Login) 1924 is sent immediately to the Port originating the ARP Broadcast. 1926 5. After Port Login completes, an ARP response can be forwarded. 1927 Note that there are two possible scenarios: 1929 - The ACC to PLOGI returns before the ARP reply is processed 1930 and the ARP Reply is immediately forwarded. 1932 - The ARP reply is delayed, waiting for ACC (successful 1933 Login). 1935 6. At this point in time, both ends have the necessary 1936 information to complete their 1937 association. 1939 C.3 Login to Everyone 1941 In Fibre Channel topologies with a limited number of ports, it may be 1942 efficient to unconditionally login to each port. This method is 1943 discouraged in fabric and public loop environments. 1945 After Port Login completes, the MAC Address to Port_ID Address tables 1946 can be constructed. 1948 C.4 Static Table 1950 In some loop environments with a limited number of ports, a static 1951 mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be maintained. 1952 The FC layer will always know the destination Port_ID based on the 1953 table. The table is typically downloaded into the driver at 1954 configuration time. This method scales poorly, and is therefore not 1955 recommended. 1957 [draft-ietf-ipfc-fibre-channel-03.txt] 1958 [This INTERNET DRAFT expires on May 1, 1999]